No login window icon if your UID is too large

by Eric Hemmeter
in macOS, Xsan
01 Dec 2021

We ran into an interesting problem on some of our Xsan connected systems.  We created mobile accounts, but some of them wouldn’t show up at the Mac’s Login Window. These Macs are bound to an LDAP server and the user’s UniqueID (UID) comes from the LDAP server.  The UIDs are assigned based on user type, so while employees are small numbers, contractors have ended up with UIDs like 2320327132.  This number is larger than the maximum signed 32-bit number (this means there are 31 bits for the value and 1 bit for the sign) 2^31-1 = 2,147,483,647.  Things get pretty weird when a UID is larger than this.

macOS already has many system users that already don’t have icons at the Login Window.  For example, there is a _spotlight user with Unique ID = 89.  Only users with UIDs above 500 are shown.  When the UID gets larger than 2,147,483,647, the first bit is set to 1 and the Mac interprets the value as negative.  There is already an “Unprivileged User” (or nobody) with UID = -2, so macOS has experience with negative UIDs.  When the account with UID = 2320327132 is read, the system sees that as a user with UID = -1974640164 and of course doesn’t show that at the Login Window since it is less than 501.

There are some other side effects as well.  We create the user’s account with createmobileaccount and something in this process can’t handle the out of range UID. 

% sudo /System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount -D -h /Users/eric_hemmeter -vn eric_hemmeter
Password:
verbose output on.
user name = "eric_hemmeter"
home path = "/Users/eric_hemmeter"
user password = "(null)"
prompt for password = FALSE
SecureToken admin information was not set up via params.  Checking Bootstrap Token.
SecureToken admin information was not set up.

Mobile account record:
dsAttrTypeStandard:RealName = "Eric Hemmeter"
dsAttrTypeStandard:RecordName = "eric_hemmeter"
dsAttrTypeStandard:GeneratedUID = "B558A647-67E1-DDCE-590F-46A62704E64D"
dsAttrTypeStandard:UniqueID = "2320327132"
dsAttrTypeStandard:PrimaryGroupID = "18010"
dsAttrTypeStandard:NFSHomeDirectory = "/Users/eric_hemmeter"
dsAttrTypeStandard:OriginalNFSHomeDirectory = "/Users/eric_hemmeter"

% ls -l /Users 
total 0
drwxrwxrwt   5 root        wheel     160 Nov  1 09:25 Shared
drwxr-x---+ 11 2147483647  ga        352 Nov 11 13:32 eric_hemmeter

Notice dsAttrTypeStandard:UniqueID = "2320327132", but the home folder that gets created is owned by a user with the max possible UID.  This is what eventually led us to the explanation for what is happening. [edit] Big thank you to MacAdmin Slack user Frogor for this insight![/edit]  Interestingly, this situation can be fixed by deleting the home folder and asking a different mechanism to create it. [edit] For more detail on how different pieces of macOS handle UIDs, see the comments in mkuser() from MacAdmin Slack user Pico[/edit]

% sudo rm -r /Users/eric_hemmeter
% sudo createhomedir -c -u eric_hemmeter
% sudo chown -R eric_hemmeter:staff /Users/eric_hemmeter

Trying to fix the first home folder directly with the chown fails if Terminal doesn’t have full disk access.  The second time around it works as needed.  chown doesn’t seem to care that my UID is “too large”.  But all this doesn’t make the account show at the Login Window.  The only thing we’ve found for that is to request a UID change to a smaller value.  Then the home folder needs to be re-chowned, but nicely group membership isn’t modified, since that is all based on the GeneratedUID (GUID) which wasn’t changed.

After some playing around, we discovered something else fun.  If you change a user’s UID to 4294967296 (2^32), it wraps all the way around to 0 and the system thinks you are root.  It takes root access to make this change, so I don’t think it is a security issue, just a funny byproduct of how the system handles large UIDs.

% dscl . read /Users/badaccount UniqueID
UniqueID: 503
% sudo dscl . create /Users/badaccount UniqueID 4294967296
Password:
% dscl . read /Users/badaccount UniqueID 
UniqueID: 4294967296
% su badaccount
Password:
# whoami
root

I don’t expect many Mac users to run into this.  Apple’s Active Directory connector handles this for AD bound Macs so it isn’t an issue.  This will only impact other Macs tied to an LDAP server with very large UIDs.

Share

Eric Hemmeter