[Samba] Samba + sssd deployment: success and failure

[Rowland penny]

On 12/06/2019 17:43, 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.
Yes, but this will be different from the local Samba database.
>
> In particular, it's not actually a standalone server but rather an AD
> domain member
No, it is schizophrenic server, it is in two minds ;-)
> 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 --
Don't read that, it is 2019 (just in case you missed it) and that book 
is well out of date.
> 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:
So why are you using two programs when just one will do ?
>
>
>
>       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.
So what ? just because they are Unix domain members, this doesn't mean 
you have to use everything AD provides.
> 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)?
Unless you are talking standalone Unix machines (in which case they will 
not be domain members), then yes. I cannot understand your problem here, 
you are quite prepared to install Samba & sssd on the same computer and 
configure both, but don't want to just configure Samba alone to do the 
same thing.
>
> 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 think you mean 'RID' instead of '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.
Definitely doable with winbind, you just need to set the permissions 
from Windows.
>
>    - 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.
A 'local' group is unknown to AD (whether you use winbind or sssd), so 
connecting an AD user to a local group isn't going to work.

Rowland