Microsoft Windows domain security systems generate the user and group SID as part of the process of creation of an account. Windows does not have a concept of the UNIX UID or a GID; rather, it has its own type of security descriptor. When Samba is used as a domain controller, it provides a method of producing a unique SID for each user and group. Samba generates a machine and a domain SID to which it adds an RID that is calculated algorithmically from a base value that can be specified in the smb.conf file, plus twice (2x) the UID or GID. This method is called “algorithmic mapping”.

For example, if a user has a UID of 4321, and the algorithmic RID base has a value of 1000, the RID will be 1000 + (2 x 4321) = 9642. Thus, if the domain SID is S-1-5-21-89238497-92787123-12341112, the resulting SID is S-1-5-21-89238497-92787123-12341112-9642.

The foregoing type of SID is produced by Samba as an automatic function and is either produced on the fly (as is the case when using a passdb backend = [tdbsam | smbpasswd] ), or may be stored as a permanent part of an account in an LDAP-based ldapsam.

ADS uses a directory schema that can be extended to accommodate additional account attributes such as UIDs and GIDs. The installation of Microsoft Service for UNIX 3.5 will expand the normal ADS schema to include UNIX account attributes. These must of course be managed separately through a snap-in module to the normal ADS account management MMC interface.

Security identifiers used within a domain must be managed to avoid conflict and to preserve itegrity. In an NT4 domain context, the PDC manages the distribution of all security credentials to the backup domain controllers (BDCs). At this time the only passdb backend for a Samba domain controller that is suitable for such information is an LDAP backend.