samba - Jun 2019 - Fwd: Re: Fwd: Re: Kerberos and NTLMv2 authentication

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.

On 17/06/2019 21:49, Goetz, Patrick G via samba wrote:
> 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.
>
>
>
As far as I am aware, very little. One thing I am now aware of is GPO 
for Unix, there is also the caching of sudo rules from AD, but sudo now 
has a command to create sudo rules from ldap and I am sure that this 
could be scripted around to cache them instead. The one thing I am 
unsure about is the one real thing you mention, security groups, and 
this is only because I have never tried it, I do feel that you should be 
able to do this with winbindd, if only because sssd can do it and they 
use a version of part of the winbindd code. I will do some testing and 
get back to you ;-)

Rowland

On 17/06/2019 22:12, Rowland penny via samba wrote:
> As far as I am aware, very little. One thing I am now aware of is GPO 
> for Unix, there is also the caching of sudo rules from AD, but sudo 
> now has a command to create sudo rules from ldap and I am sure that 
> this could be scripted around to cache them instead. The one thing I 
> am unsure about is the one real thing you mention, security groups, 
> and this is only because I have never tried it, I do feel that you 
> should be able to do this with winbindd, if only because sssd can do 
> it and they use a version of part of the winbindd code. I will do some 
> testing and get back to you ;-)
OK, I created a new share and two new unix groups and set ownership to 
'root' and one of the new groups. I added the second group to the first 
group as a member (and its only member) and then added a user to the 
second group.

Logged into win7 as the user, opened Windows Explorer -> Network and 
navigated to the share and created a new txt document, which worked. So, 
yes, it looks like nested groups work with winbindd.

Rowland