Mac - assigned user randomly changing

Hi @mnickels,

You are not alone in experiencing this. I would advise reaching out to Jamf Support to dive into it further.

Thank you for the response.

I have opened a ticket last week but haven't heard back yet. I've opened tickets in the past, but since I could never duplicate the problem they were ultimately just closed.

Are there any other details I could reference to point support in the right direction? I'd be interested if anyone had a reliable way to duplicate this issue.

There are some differences in how our environments are setup in relation to the LDAP settings, but my guess is your User ID attribute is mapped to uSNCreated, which is what the official documentation currently recommends. Around the time of the 10.20 update, we began noticing the user associated with some computer objects changing without a clear reason as to why. Following some discussion with Jamf Support, we changed the mapping for the User ID attribute to cn, manually corrected the records of the systems we knew were incorrect, and haven't noticed ongoing issues with it.

If you can hang in there on the case you have open with support, get them to link the issue to a PI (and make sure they let you know the PI #) before it gets closed out so the issue gets the attention it deserves.

You are correct - I do use the default uSNCreated and thank you for pointing me in that direction.

It looks like the "random" users that get assigned have a uSNCreated that is either plus or minus 1 of the currently assigned user. Perhaps there is a bug where this attribute is changing somewhere in the process.

And now, I believe I have found the issue. According to http://www.selfadsi.org/ads-attributes/user-usnCreated.htm:
"The Active Directory attribute uSNCreated stores the local update sequence number (USN) of the regarding domain controller at the time of the creation of that user object. Since each DC has its own USN values, the value of uSNChanged for a user differs on each domain controller - the attribute is not replicated between DCs!"

Sure enough - depending on the DC I query, I get a different username returned for the same uSNCreated. I have over 90,000 users in my environment, so it makes sense that users are often created in batches, and this attribute could be different for each user.

I believe my solution will be changing the uSNCreated configuration to something that is truly unique and replicated across AD. The "cn" attribute looks like it's just the user's name, which could change, so I am thinking of using "objectGUID" instead which is unique and never changes. That is the same attribute a different MDM uses and seems to work well.

Off I go to start testing!

PI-008110

@mnickels Wow this makes perfect sense. I was looking at a computer in a Jamf instance I used to admin and the assigned user changed. I swore I didn't do it - not I remember our LDAP server was configured round robin so it was hitting one of the 3 DCs the campus had. Very frustrating lol, not my problem anymore! Guess that is for the new admin to figure out!

@mnickels , I am experiencing the exact same issue. I reached out to Jamf support and they said it is indeed a bug and they would be fixing this with the next update.

Indeed - to close the gap on this, due to a bug in 10.20 I haven't made progress on testing (LDAP extension attributes aren't working, and I want to do some testing with that before flipping the LDAP configuration over).

I was told by Jamf that they recommend "uSNCreated" because most of their customers have a small environment with a single domain controller (where this wouldn't be an issue). I'm not sure why they wouldn't just change the default/documentation to "objectGUID" considering it is truly unique, but at least we have the capability of manually changing it. I've also noticed that the group mappings use "uSNCreated" so that will have to be updated as well.

Once I get on 10.21 I plan on changing my LDAP configuration over - I need to do testing to determine if this means I need to reassign all of my computers manually so that the old attribute is replaced with the new attribute.

I have been noticing this randomly happen in my environment and i map to uSNCreated. We have tons of DCs, so it sounds like this would make sense to impact us. not sure if i should change anything or just wait for it to be fixed

edit: verified cn and uSNCreated are same values in AD and went ahead and changed it. everything passed the test, gonna manually update some of these machines that stand out as wrong and hope this doesn't come back

I just switched over the attribute from uSNCreated to objectGUID for both users and groups.

I would recommend using objectGUID over cn as a cn could change, the objectGUID cannot.

After I made this change, I had to manually go through all of my devices and re-assign each user. The devices still had the old user information, but things like LDAP extension attributes would not work until I re-assigned each user. I'm assuming the database keeps the old uSNCreated value, and it's not replaced with the new objectGUID value until I manually reassigned the users. There might be a way to script this process with the API, but I didn't have that many devices so I just did it manually.

The advice from @mnickels is bang-on. Using uSNCreated is one of the worst recommendations I've come across in over 20 years.

Even in environments with a single domain controller, and a single domain-single forest environments, the uSNCreated can easily change in a number of operational scenarios. Disaster recovery and side-by-side migrations (as is recommended for operating system upgrades) are just two basic examples that will break the uSNCreated relationship.

When it comes to Microsoft's Active Directory, objectGUID is the only unique identifier suitable for inter- and intra-forest identification - as per the 20+ year old specification from the vendor.

Additional information
objectSid can be a viable fall-back if you're confident you're only ever going to have a single domain within the forest - which has become far more common since Server 2003 kicked in and Microsoft recommended sticking to that design if possible (again, seriously old best practice advice that hasn't changed since). But it remains less resilient than objectGUID.

I'm not hands-on with JAMF meaning I'm coming at this from the AD side of the fence. In that context, here's some additional per attribute notes based on JAMF's "LDAP Attribute Mappings Reference":

• Username: userPrincipalName, if your organisation is invested in cloud adoption (I'm coming from the Azure AD context);
• Email address: mail. Hijacking userPrincipalName is inappropriate since it can legitimately differ from mail;
• Append to e-mail results: This shouldn't be used in an Active Directory context;
• Room: roomNumber (not as clear-cut - see below).

An important data design requirement is to ensure that attributes are used as per the vendor's (in this case Microsoft) documented intention. But this is complicated in practice as only a fraction of the attributes are surfaced in common management tools like Active Directory Users and Computers (ADUC) - which is still commonly used by people.

This presents an issue for "room" since there is a perfectly-aligned attribute (roomNumber) that can be used, but in smaller environments where IT admin are only comfortable with a basic approach to administration, it's not "easy" to access.

If you are okay using PowerShell, or enabling the "Attribute Editor" tab within ADUC (under View menu | Advanced Features) then you can readily manage the "roomNumber" attribute, map JAMF to it and consider it "job done". Similarly, if you run an identity management system, populating the roomNumber attribute also means job done.

If you must use a non-specific attribute though, I wouldn't recommend streetAddress. If you are using JAMF across all devices then at least for your "staff" users, you'll find that attribute may well be used by other applications, such as automated signature generators or even line-of-business applications that do actually expect to find the workplace's street address in it.

Instead, look for a less-used alternative to "streetAddress" that still shows up in the ADUC user properties screen under the "Address" or "Organization" tabs.