UID, GID, SID and RID

... who are you.

© 2012 Dennis Leeuw dleeuw at made-it dot com
License: GPLv2 or later

Index

    1. Introduction
      2.
    2. POSIX IDs
      3.
      1. The problem(s)
        2.
      2. Our configuration suggestion
        3.
      3. User Personal Groups (UPG)
        4.
    3. Windows SIDs
      4.
    4. SAMBA UID/GID and SID Mapping
      5.
      1. The Guest account
        2.

Introduction

One of the more complex parts of interoperability is probably dealing with UIDs and GIDs for Unix-like environments and SIDs on Windows-like environments.

Unix-like filesystems are often shared through NFS and the problem is how do you make all systems deal with every system having their own user and group database. The initial solution was NIS, and today you see more people use LDAP to solve the problem.

On Windows-like systems (Windows, SAMBA) we have more or less the same problem, which is overcome by using Domains.

Another type of problem arises if you want to mix Unix-like systems with Windows-like systems. The Unix-systems use UID and GID numbers to map usernames and groupnames to numbers. For both groups there is an identical set of numbers that van be used, and they are treated as different entities. Due to this setup groupnames and usernames can be the same, or can be different and have the same number. This is not the case on Windows-systems. Windows maps account names and group names to a SID, which is globally unique. So there can never be 2 identical SIDs within one network. Next to that a name must be unique too.

As you can imagine mixing those two systems can be a real challenge. This document will try to shed some light on the different systems and how you can arrange your systems such that problems or conflicts are less likely to happen. The only thing we assume is the use of LDAP as the database for atleast the POSIX accounts.

POSIX IDs

The problem(s)

Different systems are created differently, even within the GNU/Linux world. Debian based systems regard all IDs below 1000 to be system IDs, while Red Hat uses all IDs below 500 to be system IDs.

Even more complex is the situation around nobody. The user nobody and group nogroup came from the NFS software and was defined as being having the highest ID, since the function was oposite to the root. However a 16-bit system has another highest number then a 32-bit system:

This resulted in some confusion. To this confusion was added the use of using -2 for the nobody ID, as was done by the software itself if nobody and nogroup where not defined. GNU/Linux distribution creators defined the account as 65534, however Red Hat supplied under that ID nfsnobody with another nobody having ID 99. And there is nogroup usage, but also groups that are called nobody.

All in all a rough overview of what is used where can be created like this:
IDsUsage
-2nobody on AIX and Mac OS X
0-99Unix local users and groups, statically asigned
99Red Hat based system nobody user and group ID
100-499Unix local users and groups, dynamic
529Used as ID for nobody on some systems (and not used by Microsoft)
32767Historic reservation for nobody (have not find any use)
60001Nobody on IRIX and SunOS
65530-65535Unix nobody user and (no)group (Debian and nfsnobody RHEL)
4294967292Group-owner on Isilon BSD
4294967293Null user on Isilon BSD
4294967294Everyone on Isilon BSD
4294967295Nobody (32-bit)

Our configuration suggestion

Different systems are created differently, even within the GNU/Linux world. Debian based systems regard all IDs below 1000 to be system IDs, while Red Hat uses all IDs below 500 to be system IDs.

Even more complex is the situation around nobody. The user nobody and group nogroup came from the NFS software and was defined as being having the highest ID, since the function was oposite to the root. However a 16-bit system has another highest number then a 32-bit system:

This resulted in some confusion. To this confusion was added the use of using -2 for the nobody ID, as was done by the software itself if nobody and nogroup where not defined. GNU/Linux distribution creators defined the account as 65534, however Red Hat supplied under that ID nfsnobody with another nobody having ID 99. And there is nogroup usage, but also groups that are called nobody.

All in all a rough overview of what is used where can be created like this:
IDsUsage
-2nobody on AIX and Mac OS X
0-99Unix local users and groups, statically asigned
99Red Hat based system nobody user and group ID
100-499Unix local users and groups, dynamic
500-999Microsoft RIDs for LOCAL, DOMAIN and BUILTIN, static
529Used as ID for nobody on some systems (and not used by Microsoft)
32767Historic reservation for nobody (have not find any use)
60001Nobody on IRIX and SunOS
65530-65535Unix nobody user and (no)group (Debian and nfsnobody RHEL)
4294967292Group-owner on Isilon BSD
4294967293Null user on Isilon BSD
4294967294Everyone on Isilon BSD
4294967295Nobody (32-bit)

On Mac OS X Apple put everything into the DirectoryService which can be accessed by using dscl. By using: 

dscl /Local/Default -list /Users UniqueID

The design with the biggest amount of UIDs and GIDs on 32-bit systems and better can be designed like this:
IDsFunction
0-99Static system UIDs and GIDs
100-499Dynamic system UIDs and GIDs
500-999Reserved for Windows RIDs for LOCAL, DOMAIN and BUILTIN, static
1000-65535Reserved and used for legacy systems
7000-4000000000Dynamic allocation of UIDs and GIDs from LDAP
4294967290-4294967295Reserved

We will design with the following assumptions: 0-999 is reserved for use by the different systems in the network, and we will not use 60000-65535 to make our Debian and RHEL based machines happy and make extra room to support other OSes if needed. IDs 1000-59999 are reserved for local system users, meaning these are only available to the local system, they are not part of LDAP.

To make your local machines use the right UIDs and GIDs when they create local accounts set in /etc/login.defs: 

SYS_UID_MIN    100
SYS_UID_MAX    499

SYS_GID_MIN    100
SYS_GID_MAX    499

UID_MIN      1000
UID_MAX      59999

GID_MIN      1000
GID_MAX      59999
On Debian based systems also adjust /etc/adduser.conf: 
FIRST_SYSTEM_UID=100
LAST_SYSTEM_UID=499

FIRST_SYSTEM_GID=100
LAST_SYSTEM_GID=499

FIRST_UID=1000
LAST_UID=59999

FIRST_GID=1000
LAST_GID=59999

User Personal Groups (UPG)

If you would like to work with Personal User Groups on your POSIX systems, I would suggest using:

This means you need two numbers for every entry. But it gives you the benefit that you can use domainSID-uidNumber or domainSID-gidNumber as the SID for the object. But in the end this is only cosmetics.

Windows SIDs

Before we add users and groups to LDAP, we first need to explain the SID and RID used in the Microsoft environment. SID stands for Security IDentifier. Within an Microsoft networking environment the SID is globally unique. In comparision with Unix-like systems, you could create a group with gid 99 and a user with uid 99, meaning that on a system level both have an ID of 99. This is not possible in a Microsoft world. It should also be noted that you can not have a group with name "test" and a user called "test". Also the naming has to be unique within your domain.

RID is a Relative IDentifier. Relative to the SID that is. The RID is the last part and should be unique for a certain object within a domain.

The structure of the SID looks like this: 

S-[Revision]-[IdentifierAuthority]-[SubAuthority0]-[SubAuthority1]-...-[SubAuthority[SubAuthorityCount]](-RID).
The components in this structure are:
Revision
The revision is always 1 for current NT versions.
Identifier Authorities and SubAuthorities
SID RID Description
S-1 0 NULL SID authority: used to hold the "null" account SID
S-1-0 0 The null account
S-1 1 World SID authority: used for the "Everyone" group, which is the only account in this authority.
S-1-1 0 The Everyone group (\EVERYONE)
S-1 2 Local SID authority: used for the "Local" group, which is the only account in this group.
S-1-2 0 The Local group
S-1 3 Creator SID authority: responsible for the CREATOR_OWNER, CREATOR_GROUP, CREATOR_OWNER_SERVER and CREATOR_GROUP_SERVER well known SIDs. These SIDs are used as placeholders in an access control list (ACL) and are replaced by the user, group, and machine SIDs of the security principal.
S-1-3 0 Creator Owner account (\CREATOR OWNER)
S-1-3 1 Creator Group account (\CREATOR GROUP)
S-1-3 2 Creator Owner Server account (\CREATOR SERVER OWNER)
S-1-3 3 Creator Group Server account (\CREATOR SERVER GROUP)
S-1 4 Non-unique authority: Not used by NT
S-1 5 NT authority: accounts that are managed by the NT security subsystem.
S-1-5 2 NT authority: Network (AUTHORITY\NETWORK)
S-1-5 4 NT authority: Interactive (AUTHORITY\INTERACTIVE)
S-1-5 11 NT authority: Authenicated users (AUTHORITY\AUTHENTICATED USERS)
S-1-5 18 NT authority: System (AUTHORITY\SYSTEM)
S-1-5 19 NT authority: Local service (AUTHORITY\LOCAL SERVICE)
S-1-5 20 NT authority: Network service (AUTHORITY\NETWORK SERVICE)
S-1-5 21 Non-unique SIDs, used for domain SIDs: The SID S-1-5-21 is followed by 3 RIDs (96 bytes) that defines the domain. Which could look like this S-1-5-21-0123456789-0123456789-0123456789. The 3 RIDs are created during initial domain installation. Since it is a random number duplicates can exist, there is no such thing as a central domain number authority. The domain SID is followed by a RID identifying the account within the domain. This RID is just a simple counter assigning a new RID to an account. There are however a couple well known RIDs:
RIDNameType
500DOMAINNAME\AdministratorUser
501DOMAINNAME\GuestUser
512DOMAINNAME\Domain AdminsGroup
513DOMAINNAME\Domain UsersGroup
514DOMAINNAME\Domain GuestsGroup
S-1-5 32 Builtin resources:
RIDNameType
544BUILTIN\AdministratorsGroup
545BUILTIN\UsersGroup
546BUILTIN\GroupsGroup
548BUILTIN\Account OperatorsGroup
549BUILTIN\Server OperatorsGroup
550BUILTIN\Print OperatorsGroup
551BUILTIN\Backup OperatorsGroup
552BUILTIN\ReplicatorGroup
S-1 9 Resource manager authority: is a catch-all that is used for 3rd party resource managers.

SAMBA UID/GID and SID Mapping

The idmap ranges for UID and GID are applicable only for local accounts. They should not be used at all when AD accounts are mapped into the UNIX UID/GID name space, when SAMBA is tied to LDAP it might depend on your setup and / or configuration if you need the idmap configuration parameters.

Mixing local accounts and AD accounts within the same name space, although this works, can confuse management of UNIX file system permissions as seen from a Windows client. Strong advise: do not use idmap entries when you tie SAMBA to AD.

The Guest account

Make sure the Windows Guest account is mapped to the Unix nobody account by using the following in the [global] section of your smb.conf file: 

	Guest account = nobody