[kwlug disc.] Authenticating both local and ADS users in Samba

Tue Feb 5 09:20:24 EST 2008

I'm kind of a newbie, but....

Can't you use RADIUS for authentication in this type situation?

Date: Mon, 4 Feb 2008 08:48:22 -0500
From: john at netdirect.ca
To: kwlug-disc at kwlug.org
Subject: Re: [kwlug disc.] Authenticating both local and ADS users in Samba

unsolicited wrote:
Paul Nijjar
wrote, On 02/03/2008 2:28 AM:

>From an smb point of view:

(1) Isn't this just two levels of pam authentication? e.g. AD plus
local /etc/group & password? Pam is supposed to allow multiple
authentication methods to multiple authenticators. Is this only coming
in? i.e. Used for dis/allowing access to local things, not for sending
out access requests?

For most services this is just two levels of Pam. Samba (/Microsoft)
require two passwords and these passwords are encrypted and used
differently than typical Linux passwords. Also the concept of groups is
different. As a result Samba works seamlessly with AD only when you
configure Samba to use AD.  If you chose to use the PAM method you
should have to duplicate the passwords on the Linux system using
"smbpasswd" and you may not be able to handle nested group membership.
Also some of the password controls will go away.

The seamless issue would involve configuring Samba to use two levels of
authentication. AD and a local database.

(2) The
machine to authenticate with is inherent to the request. i.e.
\\{machine}\{share} really causes the machine/client to figure out
who/how to authenticate. If you go to an AD member, it will go to AD.

    If you go to a workgroup, there is no central authority, so you are
always authenticating against the local machine.

    Therefore, the answer to you question is, it shouldn't matter. But
that's not quite correct.

    I don't have experience enough myself, but if you're setting up
local samba authentication files under linux, you should be able to
specify the ad or workgroup 'authenticating' agent. (i.e. windows
<-> linux userid mappings.) So joedomain -> ad/domain, and
joemachine -> workgroup/user.

    If you are expecting to not have to maintain such files, then the
request to connect to the samba share should just figure itself out.
Evidently, from your notes below, that isn't happening.

    An issue I frequently run into is forgetting to put the domain on
the userid. e.g. '/workgroup/me' or '/domain/me' instead of just 'me'.
Inevitably the sharing machines default authenticator ends up being not
the one I expected / wanted.

  I can put up smb.conf files and such on
request, but at this point I

am not even sure Samba can be configured to do what I want. By

including the following in my configuration:

security = ADS

domain logons = no 

I can get the Linux machine viewed as a client on the AD network, and

other AD members can log in -- but I can't figure out how to

authenticate local users. If I go: 

security = user 

then I can get clients to log in using local accounts, but I lose

Active Directory authentication. If I try to get fancy with things

like

security = ADS domain logons = yes 

things break in frustrating ways -- it looks like my Linux client

becomes a domain controller (which is the documented behaviour).

Maybe

that is okay, but then I get other errors (e.g. problems getting

Kerberos tickets and winbind failures). 

Samba is samba.

For your purposes, you don't really care whether it's a domain logon or
not. i.e. It's up to the receiving machine to determine if it
authenticates locally or via AD. By any chance, if you say security =
user, domain logons = no, and pass the entire \\machine\share string in
the userid, does it all just start to work?

    Validating against the domain is only really useful in the sense of
getting your security ticket once, then connecting to multiple shares
using that ticket, rather than authenticating each time. 
Windows as a client takes care of this even if AD is not there. I
negotiates with new servers using challenge-based authentication using
your existing ID/password. It matters under the covers whether it's AD
or not, but this works with Workgroup setups.

Any chance OpenLDAP makes sense here, as a local Linux authenticator,
configured to talk to AD (as well)? Is that even possible? [If I
remember John correctly, AD vs. LDAP only really matters to either
Linux or Windows once you involve exchange. Beyond that, LDAP is LDAP,
and authentication is authentication.]

I don't know of a way to get exactly where you want but you could think
about duplicating the authentication information. As long as the user
IDs and passwords match it should appear seamless. There are some
migration tools available in Samba. You could automate userID migration
so that it occurs on a regular basis.  You would have to keep a list of
non-AD users, pull those out of the smbpasswd file and merge in the
migrated account info. It's not perfect but it could work.

LDAP could be used this way by replicating AD information to OpenLDAP.
Local accounts could exist in an adjacent tree and you could configure
Samba to use the parent so that both authenticates. This is pretty
academic, I haven't seen it done but it should be possible.

Other ideas are: run two Samba servers on the same machine. Have them
bind to different IP addresses, have two distinct names and configure
the authentication for each separately. Then configure the shares
identically. I think samba will take care of Oplock contention in that
circumstance but if it doesn't you could turn them off.

-- 

      John Van Ostrand
      Net Direct Inc.

      CTO, co-CEO
      564 Weber St. N. Unit 12
      map

      Waterloo, ON N2L 5C6

      john at netdirect.ca
      Ph: 866-883-1172
      ext.5102

      Linux Solutions / IBM Hardware
      Fx: 519-883-8533

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserv.ccjclearline.com/pipermail/kwlug-disc/attachments/20080205/e711588c/attachment.htm