[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