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

[Rowland penny]

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