[Samba] Fwd: Re: Fwd: Re: Kerberos and NTLMv2 authentication

Goetz, Patrick G pgoetz at math.utexas.edu
Mon Jun 17 20:49:10 UTC 2019


On 6/17/19 2:26 PM, Rowland penny via samba wrote:
> Don't think this is going to happen (but what do I know ?), I could sort 
> of understand dropping 'nmbd' but 'smbd' & 'winbindd' will give you just 
> the same as using sssd with Samba, with only one config file. Can I ask 
> you what you use sssd for ? is it just for authentication, or something 
> else as well ?
> 


Sure, initially we used an OpenLDAP LDAP server (on an AD-based campus) 
for just our department, which worked very well, including with Samba 
(security = user) despite a fair amount of turmoil in the requisite PAM 
modules and especially the name service caching daemon, which generally 
left something to be desired.  Of course without such a cache, even a 
moderate sized environment becomes unusable: a simple home directory ls 
can take 1-2 minutes (personal experience).

After some IT consolidations we found ourselves in a very mixed 
environment, with dozens of independent LDAP serers, groups that just 
used file-based (/etc/passwd|group), and -- since a majority of users 
use desktop Windows PCs/Macs -- a lot of stuff bound to the campus AD 
domain.  Given available human resources, this is nearly impossible to 
manage.

The initial interest in sssd was because

   A) a large commercial linux vendor was supporting its development
   B) It has been and is under very active development
   C) it combined authentication and caching
   D) it allowed you to authenticate against multiple different 
directory services.
   E) appears to be the future of linux authentication

D) is pretty important, as we decided that the only sensible solution 
was to switch to using AD authentication nearly everywhere (while 
retaining the ability, at least on linux machines, to have local 
accounts for instrumentation, guest scientists, etc.).  However, we 
needed a way to transition users without disruption.  sssd would allow 
us to configure their existing LDAP service as well as AD, so that they 
can keep authenticating against their LDAP server until we have time to 
switch them over to use their AD account.  (This in nontrivial, as at 
the very least it generally necessitates a change in username.)

But once we got into it we discovered that sssd supports AD security 
groups, which is is huge.  In Active Directory we can create a GPO 
restricting access to a host domain member to a particular security 
group or set of security groups (i.e. groups of domain users).  The 
machines can be configured and installed generically, but only 
authorized users will be able to authenticate because of the GPO.  And 
because these security groups can be nested (however not sure sssd 
supports more than one level of nesting at this time) and grouped, If, 
say, math and physics are sharing a compute lab, we can easily apply 
both security groups to the same set of hosts.

We're making use of AD security groups with dual factor authentication 
as well.

Moreover, I can assign file/directory group mode bit group ownership to 
AD security groups.  If cns-bio-joneslab is a security group defined in 
AD, I can

    chgrp cns-bio-joneslab some_data-dir
    chmod 770 some_data_dir
    chmod g+s some-data-dir

on a domain-joined host, and only members of the Jones Lab will be able 
to access this shared data.  It all works as expected.  Haven't tested 
POSIX ACLs; will do that next, since we're forced to use these in the 
absence of RichACLs.

There are 2 important things that Samba provides:  The first is an open 
source AD domain controller alternative.  At least so far, idM doesn't 
provide this. The second unique functionality is SMB.  NTLM, Netbios and 
hence nmbd are basically dead.

 From an architectural perspective, if Samba is going to be in charge of 
the entire authentication stack, then fine.  I believe sssd has a 
winbind idmap plugin, so you can probably even use sssd clients with a 
Samba AD domain controller.  Otherwise, the focus should just be on 
providing optimal SMB 3.x filesystem performance.  Since authentication 
has been a modular function in linux for at least a decade, it makes 
most sense to use the existing linux infrastructure (which now looks to 
be headed to sssd) for authentication; i.e. a version of smbd that 
DOESN'T call check_ntlm_password -- ever -- and instead relies on 
someone else to provides yes/no answers to authentication and 
authorization questions.

I might be missing something, but at the moment I don't know what.  Let 
me turn the question around:  what service does winbind provide that 
sssd doesn't?  Stating that Samba > 4.8 domain members must use winbind 
isn't an answer; right now I'm seeing that as an unfortunate design 
decision and hence a bug.





More information about the samba mailing list