We have a few Samba servers joined to an Active Directory environment, using Winbind, while our other RHEL and Ubuntu systems use SSSD. We are migrating away from an OpenLDAP setup that was synchronized from AD and caused frequent authentication problems. To preserve existing permissions, we imported the old UID and GID values into AD and currently use POSIX attributes across the Linux systems.
The uncertainty is around Linux desktops and new users. Students frequently join and leave, so assigning uidNumber and gidNumber manually for every account could become a maintenance problem. Should POSIX attributes be created for every AD user, or only for people who need Linux access? Has anyone automated assigning these values when accounts are created, perhaps with PowerShell or another provisioning process?
I would prefer consistent identity and permissions across both SSSD and Winbind systems, especially since Samba still has to provide file access to Windows clients. I am considering leaving LDAP/POSIX mapping disabled on some shared desktops, but a fully controlled setup seems safer than allowing unrestricted access.
4 Answers
Automate the process instead of maintaining a spreadsheet. A PowerShell step in the user-creation workflow can calculate or assign uidNumber and gidNumber from the account SID, and a scheduled reconciliation script can find users or groups with missing values and fill them in. This approach works at large directory sizes and lets you provision only the objects that need Linux access. The same workflow can also manage related Unix properties such as login shell, home directory, and SSH keys.
SSSD can derive UID and GID values from the AD object's SID, so machines joined to the same domain can calculate the same values without manually storing POSIX attributes. The important caveat is to keep the domain configuration and ID ranges consistent across systems. Also avoid enabling broad directory enumeration unnecessarily, especially if the directory is large, since commands that enumerate every user and group can put significant load on the infrastructure.
I would still use POSIX attributes when predictable, centrally managed IDs are important. They make primary groups and cross-domain mappings more flexible, and they can be useful when different Linux services must agree on ownership. You do not necessarily need to populate them for every account, though—limit them to users and groups that require Linux access. That can also provide an additional access-control layer, although group membership and login policy should remain the primary controls.
Samba can map Windows SIDs to Unix IDs through its configured idmap backend. If Samba is acting as a file server, Winbind is generally the right choice. With a single domain, the RID backend can often provide stable mappings without storing RFC 2307 attributes in AD; autorid is useful when multiple domains are involved. That avoids manually maintaining UID and GID values, but the backend configuration must be consistent anywhere shared file ownership needs to match.
The downside is operational overhead: someone must populate the attributes before a newly authorized user can log in. That is manageable if it is part of the account-provisioning workflow rather than a manual ticket.