[Samba] Samba + sssd deployment: success and failure

[Goetz, Patrick G]

Bug fix: I meant if you set security = user,

On 6/12/19 11:43 AM, Goetz, Patrick G via samba wrote:
> On 6/12/19 11:10 AM, Rowland penny via samba wrote:
>>
>> Why are you using sssd on a standalone server ?
>>
>> your users will be in /etc/passwd and the Samba database, I don't think
>> sssd can talk to the Samba database.
>>
> 
> I'm pretty sure what happens when you set [server role = standalone] is
> that Samba then defers to /etc/nsswitch.conf for how authorization
> should happen, and since sss is listed there and is set up to query the
> AD domain, that's how users get authenticated.
> 
> In particular, it's not actually a standalone server but rather an AD
> domain member so that Security Group-authorized domain users can use
> their AD domain credentials for authentication on the machine.  There is
> an entire lab of linux workstations set up this way.  Users log in to a
> workstation using their AD credentials and their home directory (and
> various data/software directories) are automounted from the same
> fileserver we're trying to set Samba up on.  sssd also provides a
> caching service to assist with timely authorization.  As I mentioned
> previously, sssd bundles together the functionality of pam_ldap, nscd,
> and probably some other tools.  This was all working fine until we
> acquired the need to mount filesystems to a few Windows machines as well
> (due to some compute-intensive analysis software that runs only on Windows).
> 
> After doing some more reading about winbind (the 2007 Carter "Using
> Samba" book -- aside: why don't we have any updated Samba
> documentation?!  Will post separately about the state of the smb.conf
> man page), I have no a priori objections to using winbind instead of
> sssd.  In particular, I wasn't aware that winbind had a PAM hook
> allowing it to provide authentication for other services.  I do care
> about clean, modular system design, though:
> 
> 
> 
>       Other Services           | Autonomous     |
>         Requiring     ------>  | Authentication | <-----  Samba smbd
>       Authentication           | Service        |
>                                     |
>                                     |
>                                     v
>                        Can interface with LDAP/AD
> 
> 
> It looks like the thing in the middle could be sssd or winbind; however
> most of our linux boxes which are AD domain members don't provide SMB
> file sharing services.  I only want to have to debug one
> AD-authentication service (that's headache enough, believe me), so would
> it make sense to run winbind on machines that are only using Samba for
> administrative local use (i.e. no need to install full-blown Samba)?
> 
> I looked at the winbind rid service, and am worried this will map SIDs.
> The other features I'm looking for:
> 
>    - We don't have and can't get the POSIX subsystem in our AD deployment,
>      so I want the UID = SID; i.e not mapped in any way in order to
>      facilitate subsequent aggregation (say of storage) of what are
>      now independent labs.
> 
>    - Must support AD Security Groups because this is how we limit access
> to particular machines.
> 
>    - It would be nice to be able to use AD groups for authorization; then
> I wouldn't have to manage local groups in /etc/group (although ansible
> makes this less of a chore than it used to be).  Right now this doesn't
> seem to work with sssd; i.e. you can't chgrp files/folders to the AD
> groups listed using, say `id pgoetz` on the domain-bound linux machine.
> 
>    - It would be super awesome if nested groups were supported.  Right
> now sssd can't do this.
> 
> 
> 
>