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

On 6/17/19 12:37 PM, Edouard Guign? via samba wrote:
> On my linux box (centos 7), I set Samba + Winbind against AD.
> But I also set SSSD against AD for an other purpose (sftp access).
> 
> I am wondering if there is no risk to disable sftpd/sssd if I add 
> winbind in /etc/nsswitch.conf
> 
> Can Winbind and SSSD be installed on the same system if they are not 
> used for the same purpose ?

I'm wondering this myself.  Regarding nsswitch.conf, the options are 
searched in order.  So


    passwd: compat  systemd  sss  winbind
    shadow: compat sss windbind

would presumably look in the local /etc/passwd|shadow files first for 
authentication, then check sssd, and finally winbind.  The question is 
will a Samba mount fail trying to use sssd?  You could try putting 
winbind before sssd, or in theory winbind should be able to handle ssh 
authentication?  Can someone confirm this?

I'm still confused by the RHEL documentation on this.  Rowland is 
correct, the RHEL 8 documentation states this:

"Red Hat only supports running Samba as a server with the winbindd 
service to provide domain users and groups to the local system. Due to 
certain limitations, such as missing Windows access control list (ACL) 
support and NT LAN Manager (NTLM) fallback, SSSD is not supported."

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/assembly_using-samba-as-a-server_deploying-different-types-of-servers

What's confusing is that the RHEL 7 documentation says:

"Prior to Red Hat Enterprise Linux 7.1, only Winbind provided this 
functionality. In Red Hat Enterprise Linux 7.1 and later, you no longer 
need to run Winbind and SSSD in parallel to access SMB shares. For 
example, accessing the Access Control Lists (ACLs) no longer requires 
Winbind on SSSD clients."

and

"4.2.2. Determining Whether to Use SSSD or Winbind for SMB Shares
For most SSSD clients, using SSSD is recommended:"

and most worrisome, in my use case:

"In environments with direct Active Directory integration where the 
clients use SSSD for general Active Directory user mappings, using 
Winbind for the SMB ID mapping instead of SSSD can result in 
inconsistent mapping."


What changed between versions 7 and 8 of RHEL/Cent OS?  Is it just the 
upgrade from Samba 4.7.x to 4.8.x?  What's especially weird is that RHEL 
does not support the use of Samba as an AD domain controller:

"Red Hat does not support running Samba as an AD domain controller
(DC)."

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/assembly_using-samba-as-a-server_deploying-different-types-of-servers


They want you to use idM, which is closely associated with sssd, which 
begs the question "are they assuming no one is going to want to serve 
files from a linux box to Windows systems?  At least in my environment, 
that's a very poor assumption indeed.


Question:  How feasible would it be to have a version of smbd that just 
works with sssd.  I understand a big feature of Samba 4 is providing a 
standalone AD domain controller, but for environments that already have 
AD, kind of all you really need is file services, and it would be very 
convenient to be able to install a version of smbd that just works with 
sssd out of the box.

On 17/06/2019 20:05, Goetz, Patrick G via samba wrote:
> On 6/17/19 12:37 PM, Edouard Guign? via samba wrote:
>> On my linux box (centos 7), I set Samba + Winbind against AD.
>> But I also set SSSD against AD for an other purpose (sftp access).
>>
>> I am wondering if there is no risk to disable sftpd/sssd if I add
>> winbind in /etc/nsswitch.conf
>>
>> Can Winbind and SSSD be installed on the same system if they are not
>> used for the same purpose ?
>
> I'm wondering this myself.  Regarding nsswitch.conf, the options are
> searched in order.  So
>
>
>      passwd: compat  systemd  sss  winbind
>      shadow: compat sss windbind
>
> would presumably look in the local /etc/passwd|shadow files first for
> authentication, then check sssd, and finally winbind.  The question is
> will a Samba mount fail trying to use sssd?
Possibly it could fail.
> You could try putting
> winbind before sssd, or in theory winbind should be able to handle ssh
> authentication?  Can someone confirm this?
It does, at least it always has for me ;-)
>
> I'm still confused by the RHEL documentation on this.  Rowland is
> correct, the RHEL 8 documentation states this:
>
> "Red Hat only supports running Samba as a server with the winbindd
> service to provide domain users and groups to the local system. Due to
> certain limitations, such as missing Windows access control list (ACL)
> support and NT LAN Manager (NTLM) fallback, SSSD is not supported."
>
>
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/assembly_using-samba-as-a-server_deploying-different-types-of-servers
>
> What's confusing is that the RHEL 7 documentation says:
>
> "Prior to Red Hat Enterprise Linux 7.1, only Winbind provided this
> functionality. In Red Hat Enterprise Linux 7.1 and later, you no longer
> need to run Winbind and SSSD in parallel to access SMB shares. For
> example, accessing the Access Control Lists (ACLs) no longer requires
> Winbind on SSSD clients."
>
> and
>
> "4.2.2. Determining Whether to Use SSSD or Winbind for SMB Shares
> For most SSSD clients, using SSSD is recommended:"
>
> and most worrisome, in my use case:
>
> "In environments with direct Active Directory integration where the
> clients use SSSD for general Active Directory user mappings, using
> Winbind for the SMB ID mapping instead of SSSD can result in
> inconsistent mapping."
I think there they were talking about using winbind on one client and 
sssd on another and yes, you would get different numeric ID's in that
case.
>
>
> What changed between versions 7 and 8 of RHEL/Cent OS?  Is it just the
> upgrade from Samba 4.7.x to 4.8.x?
Yes, smbd used to be able to connect to AD without winbindd, but from 
Samba 4.8.0, this was removed and winbind now needs to be run on a Unix 
domain member.
>   What's especially weird is that RHEL
> does not support the use of Samba as an AD domain controller:
>
> "Red Hat does not support running Samba as an AD domain controller
(DC)."
>
>
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/assembly_using-samba-as-a-server_deploying-different-types-of-servers
>
>
> They want you to use idM, which is closely associated with sssd, which
> begs the question "are they assuming no one is going to want to serve
> files from a linux box to Windows systems?  At least in my environment,
> that's a very poor assumption indeed.
I thought something similar myself, but when you consider that their 
target audience is business and they can sort of dictate/recommend what 
to use and what they will support.
>
>
> Question:  How feasible would it be to have a version of smbd that just
> works with sssd.  I understand a big feature of Samba 4 is providing a
> standalone AD domain controller, but for environments that already have
> AD, kind of all you really need is file services, and it would be very
> convenient to be able to install a version of smbd that just works with
> sssd out of the box.
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 ?

What you also have to remember is that sssd is not a Samba product and 
we have no control over its development.

Rowland

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.