samba - Mar 2016 - Samba 4 with sssd - primary Windows group membership not honored

Thanks for the reply!  I'm confused on a few bits:


To change a users primary group is a bit like jumping through hoops,
you
> have to add the user to the group that you want to be the new primary
> group, then change the primaryGroupID attribute to contain the RID of the
> new group and then finally add the user to the 'Domain Users'
group. If I
> were you, I wouldn't bother, as AD expects every users primary group to
be
> 'Domain Users'.

I've since come up with a theory.. I'm relying on the NT ACL lists for
permissions management, but that creates some hassles with making sure that
smbd still has the needed UNIX permissions.   I'm using force group = users
in my smb.conf, combined with a mask that makes sure files are created as
group writable at the UNIX level.  It appears that since "force group"
changes the user's effective primary group, it is replacing the fact that
the user is a member of "Domain Users".  This doesn't seem like
correct
behavior, but I'm not sure.  I'm having trouble thinking of a way to
work
around it without making my files world writeable at the UNIX level..

You shouldn't really be using winbind and sssd together, select one
and
> then remove the other.

I've never seen a succinct description of how this should work in the Samba
4 world.  What I've read over and over is that even if you aren't using
winbind for UNIX integration (PAM, NSS, etc) that it needs to be running in
order for smbd to operate properly.. caching of domain controller
connections, etc.  In my limited experience, if I stop winbind I start to
see all sorts of strange behaviors including raw SIDs listed in Security
Panes etc...

The way I have it currently set up, sssd is being used for the integration
piece (nss, pam) but winbind is running for smbd to use.  As best I can
tell, that's the recommended configuration..  is there documentation that
might clear it up?  I've tried digging through the docs I can find and
unfortunately it seems to leave most of the guts of this process in the
dark, so it's pretty hard to see the most correct/recommended way to
configure Samba 4 as a transparent-ish file server replacement..

Thanks!

--
*Joseph Dickson*
Director of IT Systems, Evolve Tele-Services, Inc.

On 23/03/16 16:18, Joseph Dickson wrote:
> Thanks for the reply!  I'm confused on a few bits:
>
>
> To change a users primary group is a bit like jumping through hoops, you
>> have to add the user to the group that you want to be the new primary
>> group, then change the primaryGroupID attribute to contain the RID of
the
>> new group and then finally add the user to the 'Domain Users'
group. If I
>> were you, I wouldn't bother, as AD expects every users primary
group to be
>> 'Domain Users'.
>
> I've since come up with a theory.. I'm relying on the NT ACL lists
for
> permissions management, but that creates some hassles with making sure that
> smbd still has the needed UNIX permissions.   I'm using force group =
users
> in my smb.conf, combined with a mask that makes sure files are created as
> group writable at the UNIX level.  It appears that since "force
group"
> changes the user's effective primary group, it is replacing the fact
that
> the user is a member of "Domain Users".  This doesn't seem
like correct
> behavior, but I'm not sure.  I'm having trouble thinking of a way
to work
> around it without making my files world writeable at the UNIX level..
OK, you should use the standard 'rwx' permissions *or* ACLs, not both. 
If you create a directory on Unix that you want to share, set the 
owner:group to root:'Domain Admins' and permissions to 0770. You will 
then be able to set the permissions from windows or with setfacl on the 
Unix machine, you do not need the 'force group' lines in smb.conf, there
is a wiki page for this, see here:

https://wiki.samba.org/index.php/Shares_with_Windows_ACLs
>
> You shouldn't really be using winbind and sssd together, select one and
>> then remove the other.
>
> I've never seen a succinct description of how this should work in the
Samba
> 4 world.  What I've read over and over is that even if you aren't
using
> winbind for UNIX integration (PAM, NSS, etc) that it needs to be running in
> order for smbd to operate properly.. caching of domain controller
> connections, etc.  In my limited experience, if I stop winbind I start to
> see all sorts of strange behaviors including raw SIDs listed in Security
> Panes etc...
>
> The way I have it currently set up, sssd is being used for the integration
> piece (nss, pam) but winbind is running for smbd to use.  As best I can
> tell, that's the recommended configuration..  is there documentation
that
> might clear it up?  I've tried digging through the docs I can find and
> unfortunately it seems to leave most of the guts of this process in the
> dark, so it's pretty hard to see the most correct/recommended way to
> configure Samba 4 as a transparent-ish file server replacement..
>
> Thanks!
On a Domain member you do not need sssd, winbind will do everything that 
sssd does, but on an AD DC it is a bit different, winbind there ignores 
all the RFC2307 attributes except for uidNumber & gidNumber.

Samba only recommends using winbind, sssd is not supplied or supported 
by Samba.

I don't know if you have read the Samba wiki pages, there is a lot of 
info about using Samba, it starts here:

https://wiki.samba.org/index.php/Main_Page

Rowland

>
> OK, you should use the standard 'rwx' permissions *or* ACLs, not
both. If
> you create a directory on Unix that you want to share, set the owner:group
> to root:'Domain Admins' and permissions to 0770. You will then be
able to
> set the permissions from windows or with setfacl on the Unix machine, you
> do not need the 'force group' lines in smb.conf, there is a wiki
page for
> this, see here:
> https://wiki.samba.org/index.php/Shares_with_Windows_ACLs

I've tried following this page, and have not managed to have any luck.  I
even figured out the new syntax to add SeDiskOperatorPrivilege (net sam as
opposed to net rpc.. at least that's the command that ended up working..
net rpc always returned permission denied)

As soon as I try to set the Windows ACLs, I lose access to the folder
unless I'm defined as an admin user.  The first step that I try to do is to
set the root share permissions, and I remove everything except a full
control entry for Domain Admins (the domain group, not the Unix
Group\Domain Admins that it shows up with by default -- I remove that
one).  As soon as I hit OK, I lose access to the share.

On a Domain member you do not need sssd, winbind will do everything
that
> sssd does, but on an AD DC it is a bit different, winbind there ignores all
> the RFC2307 attributes except for uidNumber & gidNumber.

I will try setting up a test server that uses winbind for nss instead of
sssd, but it doesn't seem like that's the problem as wbinfo and sssd
(via
getent) are returning the same UID/GID numbers.  I don't have uid/gid
attributes added to my active directory schema, so it's using the
algorithmic method of computing them based on SID..

Samba only recommends using winbind, sssd is not supplied or supported
by
> Samba.
> I don't know if you have read the Samba wiki pages, there is a lot of
info
> about using Samba, it starts here:
> https://wiki.samba.org/index.php/Main_Page

Yes I've definitely spent quite a bit of time looking through the wiki
pages and other documentation sources.. unfortunately many times they
haven't been updated for new command syntaxes, and there is very little
information that digs into what's going on behind the scenes so it's
pretty
tough to connect the dots yourself.

What I'm trying to achieve is as close to a drop in replacement for an MS
fileserver as possible -- all access managed by NT ACLs rather than posix.
I'm unclear how I can get this functionality without being forced to allow
world writeable at the posix level...

I'll work on creating a setup without sssd and see if the results vary, but
it doesn't feel like that's the issue..

--
*Joseph Dickson*
Director of IT Systems, Evolve Tele-Services, Inc.

I just wanted to write a quick followup to button up this thread...

On Wed, Mar 23, 2016 at 12:40 PM, Rowland penny <rpenny at samba.org>
wrote:
>
> On a Domain member you do not need sssd, winbind will do everything that
> sssd does, but on an AD DC it is a bit different, winbind there ignores all
> the RFC2307 attributes except for uidNumber & gidNumber.
>
> Samba only recommends using winbind, sssd is not supplied or supported by
> Samba.
>

I went ahead and followed Rowland and Mathias's recommendations to use
winbind alone, and that has indeed cleared up all the original issues I was
experiencing.  I definitely wish there were a succinct documentation page
somewhere that explained more about the pitfalls of sssd and why you ought
to stick with Winbind in the general case, and the expected corner cases
that each deals with less-well than the other, etc..  maybe some day I'll
have enough knowledge about it to write one :-)

Bottom line though -- thanks for the steer toward winbind only.  Things are
working much better now!

--
*Joseph Dickson*
Director of IT Systems, Evolve Tele-Services, Inc.