Inconsistent UID/GID Mapping Across Two Samba Member Servers
CORP.EXAMPLE.COM is an Active Directory domain with Samba 4.20 AD DCs. Two member servers, app01 and app02, run Samba 4.20 with winbind and mount the same NFSv4 export from nas01. app01 uses idmap config CORP : backend = rid with range = 100000-199999; app02 uses idmap config CORP : backend = ad with schema_mode = rfc2307, range = 5000-999999, and ldap ssl = start tls. Both use idmap config * : range = 3000-4999. AD user CORP\jsmith has uidNumber 6001 and a RID that maps to 142003 under app01's RID range. On app01, wbinfo -i CORP\jsmith returns 142003; on app02 it returns 6001. Files created through Samba on app01 appear as owner 142003 on app02 and as nobody on NFS clients. Files created on app02 show uid 6001 on app01, but jsmith cannot modify them through Samba. Both servers serve the same project tree to Windows clients.
1. Explain why the two servers assign different UIDs to the same AD user and why authentication still succeeds on both.
Read the worked answer
Authentication uses Kerberos and the user's SID; it does not depend on the POSIX UID. Authorization on the filesystem does. Winbind's idmap backend translates the SID to a local UID/GID. The RID backend on app01 computes a deterministic ID from the RID inside 100000-199999, producing 142003. The AD backend on app02 reads uidNumber/gidNumber from AD via RFC2307, producing 6001. Both mappings are internally consistent on their own host, so logins succeed, but the NFS export stores numeric IDs. app02 and NFS see 142003 as an unknown user, often nobody, and app01 sees 6001 as a different local identity. File ownership is therefore not portable between the servers.
2. Which mapping strategy should be standardized, and what must be verified before changing app01?
Read the worked answer
Standardize on the RFC2307 ad backend if AD uidNumber/gidNumber attributes are complete, unique, and maintained; that aligns Samba with SSSD, NFS clients, and other Unix systems. Before changing app01, verify every AD user and group that needs access has a uidNumber/gidNumber within 5000-999999, that the values are unique, and that they do not collide with idmap config * 3000-4999 or local accounts. Confirm that the DCs expose the RFC2307 attributes over LDAP and that ldap ssl = start tls works. Changing the backend changes IDs, so plan a chown and ACL migration: stop writes, map old IDs to new IDs, and back up the tree. If RFC2307 data is incomplete, the alternative is RID everywhere, but then SSSD and NFS clients must use the same deterministic RID mapping; mixing backends is the defect.
3. How would you verify the fix and prevent the mismatch from recurring?
Read the worked answer
On both servers run wbinfo -i CORP\jsmith, getent passwd jsmith, and id jsmith; all must return 6001. Compare wbinfo -n CORP\jsmith for the SID and wbinfo -s <SID> to confirm the same object. Check files with stat and getfacl, and test Samba access as jsmith from a Windows client and NFS access from a render node. Flush caches with net cache flush and restart winbind after config changes. Remove legacy idmap config entries, keep ranges non-overlapping, and manage smb.conf with configuration management. Add a monitoring check that compares winbind-resolved IDs on app01 and app02 against the authoritative AD uidNumber; alert on drift. Migrate existing files with an explicit UID map, not with a blind recursive chown.