Red Hat Bugzilla – Bug 1255250
force group not working when winbind use default domain = true
Last modified: 2015-08-27 18:24:21 EDT
Description of problem:
Since updating to the latest Samba (from RHEL 6.6 to 6.7) at time of writing, Samba shares can no longer be accessed from a Windows guest using active directory credentials if "winbind use default domain = true" is set along with the share specific settings "force user = admin", and "force group = admin". Samba is setup with security = ads, using kerberos auth, and wbinfo shows all things to be as they should.
Either disabling "force group" on the share or setting "winbind use default domain = false" resolve the issue and the share can be accessed. Obviously this isn't ideal.
The error presented on Windows client is: "The specified group does not exist.". No errors are shown in /var/log/messages, nor any in samba log files with default logging levels set.
In this case, 'admin' is a local user/group (no 501 for both) account. Nsswitch (probably isn't relevant) has correct ordering of files before winbind.
Before updating to this newer Samba (admittedly lots of other rpm's were also updated as part of a transition to 6.7, so I can't be 100% sure it's samba specific) everything was peachy.
Version-Release number of selected component (if applicable):
Every time, on multiple servers
Steps to Reproduce:
1. Setup AD, Kerberos, winbind integration
2. set security = ads, winbind use default domain = true in smb.conf
3. set share specific options valid users = @"DOMAIN\ad_goup", force user = admin and force group = admin
Windows client fails to access the share with the error "The specified group does not exist."
Access to the share should be granted.
*** This bug has been marked as a duplicate of bug 1252180 ***
Because the referred bug is internal to Redhat and therefore inaccessible to me, I'll add some additional notes here in-case they haven't been identified in bug 1252180.
It seems as if "force group" can no longer reference the name of a group that matches a username. For example, "force group = builder" works, whereas "force group = bob" does not because there is a user named "bob", even though there is also an associated group named "bob" and thus it should be ok.
The problem occurs in the opposite fashion with "force user", where if "force user = webdev" is set and there is an AD Security Group called "webdev", the share cannot be accessed.
The upstream bug fixing the issue is:
As a workaround for our use case, with the local user and group apache, we used the local domain prefix "Unix Group" to work around the bug. So we changed the share configuration from
force group = apache
force group = Unix Group\apache
Note that the separator (here backslash) is configurable. You can use wbinfo --separator to get the value for your installation.
While waiting for the fix ....
Thanks Dietrich, that's great. I was hoping it would be that easy, but could not find the correct prefix to use.