samba - Jun 2019 - Samba + sssd deployment: success and failure

I agree with putting the sssd discussion to bed, but am still interested 
in clearing up some confusion, as I'm concerned I might be missing 
something.

On 6/12/19 12:44 PM, Rowland penny via samba wrote:
> 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.
Yes, but that's part of the point.  I don't *want* a local Samba 
database.  I want all authentication to occur through one of the AD 
domain controllers, assisted by ephemeral cache files.

>>
>> 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 ;-)
How so?  I have exactly one daemon in charge of authentication, I don't 
want or need nmbd, and I want smbd to just use NSS for authentication. 
This seems like a streamlined deployment, and of course the 
authorization agent could be sssd or winbind.

>> 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'
Yes, you're right.  The Windows people seem to use the terms synonymously.


>> ? 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.
Actually, this is handled using an AD GPO, which sssd is able to read 
and use.  Doing this via GPO means we can simplify the configuration of 
hundreds of 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.
> 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.
Let me clarify.  It would be nice to assign AD Security Groups as 
file/folder groups even if they can't own files on linux.

> 
> Rowland
> 
> 
>

On 12/06/2019 20:40, Goetz, Patrick G via samba wrote:
> I agree with putting the sssd discussion to bed, but am still interested
> in clearing up some confusion, as I'm concerned I might be missing
> something.
>
> Yes, but that's part of the point.  I don't *want* a local Samba
> database.  I want all authentication to occur through one of the AD
> domain controllers, assisted by ephemeral cache files.
Winbind doesn't authenticate locally (unless it is consulting its cache) 
it does the same as sssd, it authenticates from an AD
DC.
>
>
>>> 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 ;-)
> How so?  I have exactly one daemon in charge of authentication, I don't
> want or need nmbd, and I want smbd to just use NSS for authentication.
> This seems like a streamlined deployment, and of course the
> authorization agent could be sssd or winbind.
But you aren't using NSS with winbind, smbd used to be able to fall back 
to the DC, but, from Samba 4.8.0, you now have to run winbind as
well.
>> I think you mean 'RID' instead of 'SID'
> Yes, you're right.  The Windows people seem to use the terms
synonymously.
I cannot help that, the SID identifies the domain and the RID is 
appended to the end of the SID and identifies the object (user, 
group,computer etc)
>
>
>
>>>  ? 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.
> Actually, this is handled using an AD GPO, which sssd is able to read
> and use.  Doing this via GPO means we can simplify the configuration of
> hundreds of machines.
That is something new since I last used sssd, does it work on Linux
?
> Let me clarify.  It would be nice to assign AD Security Groups as
> file/folder groups even if they can't own files on linux.
>
So you want to use AD groups on Linux ?

Something like:

getent group Domain\ Users
domain users:x:10000:user31

You don't get much more of an AD group than Domain Users ;-)

Rowland

On 6/12/19 3:06 PM, Rowland penny via samba wrote:
>> Actually, this is handled using an AD GPO, which sssd is able to read
>> and use.? Doing this via GPO means we can simplify the configuration of
>> hundreds of machines.
> That is something new since I last used sssd, does it work on Linux ?
Yes, it works with sssd version 1.16.1; that was one of the main selling 
points for us, as we have dozens of research group spread out across the 
college and would like to create a streamlined linux configuration that 
works for all of them (with legacy/tempermental software buried in LXD 
or Singularity containers).  Currently, however only the login GPOs are 
supported by sssd.

The evolution of this software has been pretty rapid.  If you used it a 
couple of years ago, you haven't really used it.  <;)

https://docs.pagure.org/SSSD.sssd/design_pages/index.html#implemented-in-2-0-x


>> Let me clarify.? It would be nice to assign AD Security Groups as
>> file/folder groups even if they can't own files on linux.
>>
> So you want to use AD groups on Linux ?
> 
> Something like:
> 
> getent group Domain\ Users
> domain users:x:10000:user31
> 
> You don't get much more of an AD group than Domain Users ;-)
>
Yep, I want to be able to set up security groups and then have group 
ownership assigned to those security groups.

When I ls -l the files of a domain user on this system, the group shows 
up as Domain Users.  Many thanks to Robert Marcano for pointing out that 
there is a way with sssd to set up synthetic private groups per user -- 
that was one of the details still bothering me considerably because 
without it, the default umask needs to be 077 instead of 007, making it 
harder to facilitate shared folders, a necessity in our context.

Looking at the release notes posted above, apparently they added support 
for non-POSIX groups in v. 1.15, but I'm not sure it's flexible enough 
to capture the security groups.  Deferring that question to one of my 
colleagues who is a Windows expert.

Thanks for the helpful discussion.  I've got a much better handle on how 
all this works.
> Rowland
> 
> 
>

On Wednesday, 12 June 2019 13:07:56 PDT Rowland penny via samba
wrote:
> >> I think you mean 'RID' instead of 'SID'
> 
> > Yes, you're right.  The Windows people seem to use the terms
synonymously.
> I cannot help that, the SID identifies the domain and the RID is 
> appended to the end of the SID and identifies the object (user, 
> group,computer etc)
> 
I believe a small clarification is due here: SID does identify individual
objects. It has a 96-bit (12-byte) pseudo-random section that identifies a
domain or an individual computer relative to which the RID is effective (IIRC
some sources refer to it as 'source of authority') as well as a 32-bit
RID (relative ID, similar to UID/GID in POSIX except it is a single 32-bit space
for any and all security principals in a domain/machine) itself as its
components. AFAIK the only exceptions to the rule of SID including RID as its
necessary part are Service SIDs and Machine SIDs. The Service SIDs are used to
manage permissions for individual services (longer than typical SID and is based
on SHA1 hash of the service name) and Machine SIDs are effectively just a
special case of the SID prefix without RID. That said the machine accounts in AD
will have full SID with RID, and that SID will not match the local machine SID
at all.

If any of the above is a misconception I have - please correct me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.samba.org/pipermail/samba/attachments/20190612/6dd751c0/signature.sig>

On Wed, 2019-06-12 at 21:06 +0100, Rowland penny via samba
wrote:
> > > I think you mean 'RID' instead of 'SID'
> > Yes, you're right.  The Windows people seem to use the terms
synonymously.
> I cannot help that, the SID identifies the domain and the RID is 
> appended to the end of the SID and identifies the object (user, 
> group,computer etc)
Rowland,
using the term SID is more correct, especially when talking about
Windows Forests, or domains with trusts.
RIDs are not globally unique only the full SID is, and any mapping maps
SIDs (ie domain part + RID) to a UID or GID, not just the RID.

Simo.