[Samba] Samba 4 with sssd - primary Windows group membership not honored

[Joseph Dickson]

Greetings!

I am working with Samba 4 as a domain member fileserver (not a domain
controller, just a normal ads member fileserver). Operating system is
Centos 7. SSSD is configured and pulling information correctly.

I had to work around a bug that wasn't fixed in a released version, so I am
using a recent copy from git.. smbd -V:
Version 4.5.0pre1-GIT-c06058a

I'm relying on Windows ACLs for access control. Many of my ACLs reference
the Domain Users group. What I'm seeing is that if a user has "Domain
Users" as their primary group (which is common here) that the "Domain
Users" group doesn't show up in their list of SIDs. If a different group
is primary for that user, then "Domain Users" will show up in the SID list
and Samba will allow access properly (though the new primary group won't
work correctly)

Is there some magic somewhere that I'm missing with how Samba 4 treats the
primary windows group? It's definitely hard to keep straight which parts
of the system are responsible for SID mapping and management once you add
in winbind and sssd..

Any pointers would be very appreciated. If there is any debug output that
I can provide, I would be happy to..

Thanks!

Joe

--
*Joseph Dickson*
Director of IT Systems, Evolve Tele-Services, Inc.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

[Rowland penny]

See inline comments

On 23/03/16 15:32, Joseph Dickson wrote:
> Greetings!
>
> I am working with Samba 4 as a domain member fileserver (not a domain
> controller, just a normal ads member fileserver). Operating system is
> Centos 7. SSSD is configured and pulling information correctly.
>
> I had to work around a bug that wasn't fixed in a released version, so I am
> using a recent copy from git.. smbd -V:
> Version 4.5.0pre1-GIT-c06058a
>
> I'm relying on Windows ACLs for access control. Many of my ACLs reference
> the Domain Users group. What I'm seeing is that if a user has "Domain
> Users" as their primary group (which is common here)

As standard, every domain users primary group is 'Domain Users'

> that the "Domain
> Users" group doesn't show up in their list of SIDs.

Again, as standard, no user shows as being a member of 'Domain Users'

> If a different group
> is primary for that user, then "Domain Users" will show up in the SID list
> and Samba will allow access properly (though the new primary group won't
> work correctly)

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'.

>
> Is there some magic somewhere that I'm missing with how Samba 4 treats the
> primary windows group? It's definitely hard to keep straight which parts
> of the system are responsible for SID mapping and management once you add
> in winbind and sssd..

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

>
> Any pointers would be very appreciated. If there is any debug output that
> I can provide, I would be happy to..

If you decide to stick with sssd, then I would suggest you will get more
and better help from the sssd users mailing list, but if you decide to
use winbind instead, then this is the place to ask.

Rowland

[Joseph Dickson]

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.

[Rowland penny]

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

[Joseph Dickson]

>
> 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.

[Rowland penny]

Can you check if this file exists:

/usr/local/samba/lib/security/pam_winbind.so

Rowland

[Joseph Dickson]

>
> Can you check if this file exists:
> /usr/local/samba/lib/security/pam_winbind.so

For historical reasons, I used a prefix of /opt/samba when I compiled:

[root@smbfs1 shares]# ls -al /opt/samba/lib/security/pam_winbind.so
-rwxr-xr-x 1 root root 63837 Mar 17 19:54
/opt/samba/lib/security/pam_winbind.so

relevant config lines in case they are helpful:
[global]
lock directory = /srv/fs_main/var/lock
state directory = /srv/fs_main/var/state
cache directory = /var/lib/samba/cache
private dir = /srv/fs_main/var/priv
vfs objects = acl_xattr
inherit acls = yes
map acl inherit = yes
hide dot files = no
winbind enum users = yes
winbind enum groups = yes

workgroup = EVOLVETSI
server string = smbfs cluster
netbios name = SMBFS

map archive = no
map hidden = no
map read only = no
map system = no
store dos attributes = yes

[test]
path = /srv/fs_main/shares/test
read only = no


and outputs from the test dir:

[root@smbfs1 shares]# ls -ald test
drwxrwx---+ 2 root domain adm...@Evolvetsi.local 6 Mar 23 16:48 test

[root@smbfs1 shares]# getfacl test
# file: test
# owner: root
# group: domain\040a...@Evolvetsi.local
user::rwx
group::rwx
other::---
default:user::rwx
default:group::r-x
default:group:domain\040a...@Evolvetsi.local:rwx
default:mask::rwx
default:other::r-x

Thanks!

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

[Rowland penny]

On 23/03/16 20:51, Joseph Dickson wrote:
>> Can you check if this file exists:
>> /usr/local/samba/lib/security/pam_winbind.so
>
> For historical reasons, I used a prefix of /opt/samba when I compiled:
>
> [root@smbfs1 shares]# ls -al /opt/samba/lib/security/pam_winbind.so
> -rwxr-xr-x 1 root root 63837 Mar 17 19:54
> /opt/samba/lib/security/pam_winbind.so

You need to have a symbolic link in /usr/lib64 (/usr/lib on i386)

ln -s /opt/samba/lib/security/pam_winbind.so
/usr/lib64/security/pam_winbind.so

>
> relevant config lines in case they are helpful:
> [global]
> lock directory = /srv/fs_main/var/lock
> state directory = /srv/fs_main/var/state
> cache directory = /var/lib/samba/cache
> private dir = /srv/fs_main/var/priv
> vfs objects = acl_xattr
> inherit acls = yes
> map acl inherit = yes
> hide dot files = no
> winbind enum users = yes
> winbind enum groups = yes
>
> workgroup = EVOLVETSI
> server string = smbfs cluster
> netbios name = SMBFS
>
> map archive = no
> map hidden = no
> map read only = no
> map system = no
> store dos attributes = yes
>
> [test]
> path = /srv/fs_main/shares/test
> read only = no
>

See here for idmap set up (required for winbind) :

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

Rowland

[Harry Jede]

Hi Joe,

> Greetings!
>
> I am working with Samba 4 as a domain member fileserver (not a domain
> controller, just a normal ads member fileserver). Operating system
> is Centos 7. SSSD is configured and pulling information correctly.
>
> I had to work around a bug that wasn't fixed in a released version,
> so I am using a recent copy from git.. smbd -V:
> Version 4.5.0pre1-GIT-c06058a
>
> I'm relying on Windows ACLs for access control. Many of my ACLs
> reference the Domain Users group. What I'm seeing is that if a user
> has "Domain Users" as their primary group (which is common here)
> that the "Domain Users" group doesn't show up in their list of SIDs.
> If a different group is primary for that user, then "Domain Users"
> will show up in the SID list and Samba will allow access properly
> (though the new primary group won't work correctly)
>
> Is there some magic somewhere that I'm missing with how Samba 4
> treats the primary windows group?

No, I believe the magic you are searching for is nss.

Their is one group which is defined two times, the name of this group is
users. The nss stops searching if a definition is found.

You may have 3 possiblities:

1) change the order in /etc/nsswitch.conf
*Not recommended*

2) rename/delete users in /etc/group
*Not really recommended* but will work

3) use an other group name for users in ad and map Domain Users
to this group, choose a gid other then 100

> It's definitely hard to keep
> straight which parts of the system are responsible for SID mapping
> and management once you add in winbind and sssd..
>
> Any pointers would be very appreciated. If there is any debug output
> that I can provide, I would be happy to..
>
> Thanks!
>
> Joe
>
> --
> *Joseph Dickson*
> Director of IT Systems, Evolve Tele-Services, Inc.


--

Regards
Harry Jede

[Joseph Dickson]

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

On Wed, Mar 23, 2016 at 12:40 PM, Rowland penny <rpe...@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.