This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1255250 - force group not working when winbind use default domain = true
force group not working when winbind use default domain = true
Status: CLOSED DUPLICATE of bug 1252180
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: samba (Show other bugs)
6.7
x86_64 Linux
unspecified Severity high
: rc
: ---
Assigned To: Andreas Schneider
qe-baseos-daemons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-20 02:39 EDT by Shane
Modified: 2015-08-27 18:24 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-20 05:37:55 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Shane 2015-08-20 02:39:38 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):
samba-3.6.23-20.el6.x86_64

How reproducible:
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

Actual results:
Windows client fails to access the share with the error "The specified group does not exist."

Expected results:
Access to the share should be granted.

Additional info:
Comment 2 Andreas Schneider 2015-08-20 05:37:55 EDT

*** This bug has been marked as a duplicate of bug 1252180 ***
Comment 3 Shane 2015-08-20 23:54:26 EDT
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.
Comment 4 Andreas Schneider 2015-08-24 11:57:20 EDT
The upstream bug fixing the issue is:

https://bugzilla.samba.org/show_bug.cgi?id=11320
Comment 5 Dietrich Streifert 2015-08-27 04:51:46 EDT
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

to

    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 ....
Comment 6 Shane 2015-08-27 18:24:21 EDT
Thanks Dietrich, that's great. I was hoping it would be that easy, but could not find the correct prefix to use.

Note You need to log in before you can comment on or make changes to this bug.