I have 4 Samba 4.7.0 DCs. I have 3 clients using samba-winbind.x86_64
0:4.6.2-11.el7_4 with an identical configuration, which produce
inconsistent user group membership for multiple users. I've tried using
all 4 DCs explicitly (e.g., realm = dc01.mediture.dom), net cache flush
and restarting winbind. I've also tested cloning a user and setting up
the user as identical as possible: the cloned user showed the correct
membership but not the original. The ldapcmp tools finds no relevant
differences between DCs.
I've had this issue through multiple versions of Samba on each side,
which I believe includes winbind from samba 3.
Client config:
[global]
#--authconfig--start-line--
workgroup = MEDITURE
password server = dc01.mediture.dom vsc-dc02.mediture.dom
aws-dc01.mediture.dom epo-dc01.mediture.dom
realm = MEDITURE.DOM
security = ads
template homedir = /home/%U
template shell = /bin/bash
winbind use default domain = true
#--authconfig--end-line--
server string = Samba Server Version %v
# logs split per machine
log file = /var/log/samba/log.%m
# max 50KB per log file, then rotate
max log size = 50
passdb backend = tdbsam
winbind cache time = 900
winbind refresh tickets = yes
winbind offline logon = yes
winbind use default domain = yes
winbind nss info = rfc2307
winbind enum users = yes
winbind enum groups = yes
winbind nested groups = yes
kerberos method = secrets and keytab
idmap config *: backend = tdb
idmap config *: range = 90000001-100000000
idmap config MEDITURE: backend = ad
idmap config MEDITURE: range = 10000-49999
idmap config MEDITURE: schema mode = rfc2307
DC config:
[global]
log level = 1 auth_audit:3
workgroup = MEDITURE
realm = MEDITURE.DOM
netbios name = DC01
server role = active directory domain controller
server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd,
ntp_signd, kcc, dnsupdate
tls enabled = yes
tls keyfile = tls/key.pem
tls certfile = tls/cert.pem
tls cafile = tls/ca.pem
template homedir = /home/%U
template shell = /bin/bash
server string = Samba Server Version %v
server max protocol = SMB3
# allow trusted domains = no
ldap server require strong auth = no
winbind refresh tickets = yes
winbind offline logon = yes
winbind use default domain = yes
winbind nss info = rfc2307
winbind enum users = yes
winbind enum groups = yes
winbind nested groups = yes
kerberos method = secrets and keytab
idmap_ldb:use rfc2307 = yes
# idmap config *: backend = tdb
# idmap config *: range = 90000001-100000000
# idmap config MEDITURE: backend = ad
# idmap config MEDITURE: range = 10000-49999
# idmap config MEDITURE: schema mode = rfc2307
kccsrv:samba_kcc = false
[netlogon]
path = /usr/local/samba/var/locks/sysvol/mediture.dom/scripts
read only = No
[sysvol]
path = /usr/local/samba/var/locks/sysvol
read only = No
[deploy]
path = /usr/local/samba/var/deploy
read only = No
Example:
[root at appdb03 ~]# wbinfo -r mikes
10513
11143
10516
11162
90000002
[root at qa503 ~]# wbinfo -r mikes
10513
90000002
[root at great02 ~]# wbinfo -r mikes
10513
90000002
Thanks,
Arthur
This e-mail and any attachments may contain CONFIDENTIAL information, including
PROTECTED HEALTH INFORMATION. If you are not the intended recipient, any use or
disclosure of this information is STRICTLY PROHIBITED; you are requested to
delete this e-mail and any attachments, notify the sender immediately, and
notify the Mediture Privacy Officer at privacyofficer at mediture.com.
On Tue, 10 Oct 2017 12:54:11 -0500 Arthur Ramsey via samba <samba at lists.samba.org> wrote:> I have 4 Samba 4.7.0 DCs. I have 3 clients using > samba-winbind.x86_64 0:4.6.2-11.el7_4 with an identical > configuration, which produce inconsistent user group membership for > multiple users. I've tried using all 4 DCs explicitly (e.g., realm > dc01.mediture.dom), net cache flush and restarting winbind. I've > also tested cloning a user and setting up the user as identical as > possible: the cloned user showed the correct membership but not the > original. The ldapcmp tools finds no relevant differences between > DCs. > > I've had this issue through multiple versions of Samba on each side, > which I believe includes winbind from samba 3. >This is a known problem, if you go here: https://wiki.samba.org/index.php/Samba_4.6_Features_added/changed#Samba_4.6.0 Amongst the information, is this: winbind changes winbind contains code that tries to emulate the group membership calculation that domain controllers do when a user logs in. This group membership calculation is a very complex process, in particular for domain trust relationship situations. Also, in many scenarios it is impossible for winbind to correctly do this calculation due to access restrictions in the domains: winbind using its machine account simply does not have the rights to ask for an arbitrary user's group memberships. When a user logs in to a Samba server, the domain controller correctly calculates the user's group memberships authoritatively and makes the information available to the Samba server. This is the only reliable way Samba can get informed about the groups a user is member of. Because of its flakiness, the fallback group membership code is unwished, and our code pathes try hard to only use of the group memberships calculated by the domain controller. However, a lot of admins rely on the fallback behavior in order to support access for nfs access, ssh public key authentication and passwordless sudo. That's the reason for changing this back between 4.6.0rc4 and 4.6.0 (See BUG #12612). The winbind change to simplify the calculation of supplementary groups to make it more reliable and predictable has been deferred to 4.7 or later. This means that "id <username>" without the user having logged in previously stops showing any supplementary groups. Also, it will show "DOMAIN\Domain Users" as the primary group. Once the user has logged in, "id <username>" will correctly show the primary group and supplementary group list. Or to put it another way, you cannot rely on the user groups from winbind. Rowland
Thank you Rowland. Would you recommend another configuration e.g. sssd or ldap? This e-mail and any attachments may contain CONFIDENTIAL information, including PROTECTED HEALTH INFORMATION. If you are not the intended recipient, any use or disclosure of this information is STRICTLY PROHIBITED; you are requested to delete this e-mail and any attachments, notify the sender immediately, and notify the Mediture Privacy Officer at privacyofficer at mediture.com.
On Tue, 10 Oct 2017 14:43:08 -0500 Arthur Ramsey via samba <samba at lists.samba.org> wrote:> Thank you Rowland. Would you recommend another configuration e.g. > sssd or ldap? >You will probably find the same problem with sssd, it uses a version of libwinbind. If you must know what groups a user is a member of, this easiest way would be to search the users object for the attribute 'memberof'. The problem with this is, the groups the user is a member of, can also be members of another group, so it would be up to you to decide just how deep you want to go in this nesting. Rowland