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

[John Van Ostrand]

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 
<http://maps.google.ca/maps?q=564+Weber+Street+North+Unit+12,+Waterloo,+ON+N2L+5C6,+Canada&ll=43.494599,-80.548222&spn=0.038450,0.073956&iwloc=A&hl=en> 

  	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/20080204/270fa4ff/attachment.htm