Forum Discussion
tommihovi
May 17, 2022Copper Contributor
Best practice for changing domain user name
Hi folks, What is the current best practice with Windows Server 2016 domain functional level to handle user name change? Changing the UPN seems a bit risky. Do we have a best practice on how to hand...
- May 18, 2022
Hey, Tommi.
Changing a surname isn't really a "best practice" scenario. It's more a cause-and-effect scenario.
Under default circumstances, renaming names - even prominent ones like userPrincipalName, sAMAccountName, mail, etc. - is safe.
Things like SharePoint permissions are not an issue as they do not hinge on the value of something like "userPrincipalName". Under the hood, these systems use different identifiers to ensure they remain joined to one another and that renaming scenarios don't break their interconnectedness.
Third-party software is much harder to speak to. You'd have to do your own due diligence on that front.
If they use the same strategy as Microsoft and use these "under the hood" identifiers then you likely won't have an issue, but if they use things like userPrincipalName to perform their joining, they will almost certainly break should userPrincipalName be renamed.
It's important to differentiate between the platforms themselves versus what you might have done with the platforms. For example, consider SharePoint.
Let's say you create a list within SharePoint that imports the "userPrincipalName" attribute from Azure AD. If you then go and rename the value for userPrincipalName in Azure AD, SharePoint will automatically pick this up and recognise it, and there will be no issues with permissions whatsoever. However, the duplicated copy stored in the SharePoint list will still reflected the old value until someone (or something) updates it.
In short, if you limit your discussion to the out-of-the-box configurations of things like Azure AD, Exchange Online, Teams, SharePoint, etc. and concepts within them such as permissions, then renaming key attributes like userPrincipalName, mail, etc. is fine. While it's possible you may run into application-level issues (think about the SharePoint list example from above), you won't run into platform-level issues.
As mentioned above, third-party systems are too inconsistent for me to make any sweeping generalisations about. All I can say is I've seen enough examples of particularly bad design from vendors you'd expect to know better that I stick to the old adage of "test, test, test".
In-depth explanation
Systems like AD, Exchange, etc. aren't joined together by the attributes like userPrincipalName (deliberately setting aside AD-AAD soft matching), but rather "primary key" identifiers like objectGUID or objectSid (on-premise Active Directory), or objectID/Id (Azure AD/Graph). These are generally referred to as "immutable identifiers" as they cannot change over the course of their life.
Using these immutable identifiers allows actions like renames to take place and be reflected across all those integrated systems without breaking anything.
Where things start falling apart at a platform level is where systems joined using identifiers that are not immutable, such as userPrincpalName, mail, etc. etc. We already looked at the SharePoint list scenario as an example of an application-level failure, so I won't re-hash that again here.
Here's an overly-simplistic example of the renaming of the userPrincipalName for a user (me) and the relevance of the immutable identifier (objectId in this case) versus userPrincipalName.
Before rename
Currently, all values are the same in both connected systems.
System A System B objectId 586654ba-976b-42f3-bfb3-e7e6f01768df 586654ba-976b-42f3-bfb3-e7e6f01768df userPrincipalName lain.robertson@robertsonpayne.com lain.robertson@robertsonpayne.com userPrincipalName is renamed in System A
We go ahead and rename userPrincipalName in System A.
Note how objectId remains unchanged and therefore matching in both systems, but userPrincipalName now no longer matches.
System A System B objectId 586654ba-976b-42f3-bfb3-e7e6f01768df 586654ba-976b-42f3-bfb3-e7e6f01768df userPrincipalName lain.robertsonpayne@robertsonpayne.com lain.robertson@robertsonpayne.com userPrincipalName synchronises from System A to System B
If objectId is used to connect both systems, the rename in system A synchronises across to system B and everything is fine again.
If userPrincipalName is used as the joining field then this step does not happen since the relationship was broken in the previous step.
System A System B objectId 586654ba-976b-42f3-bfb3-e7e6f01768df 586654ba-976b-42f3-bfb3-e7e6f01768df userPrincipalName lain.robertsonpayne@robertsonpayne.com lain.robertsonpayne@robertsonpayne.com Again, this is a deliberately over-simplified example but it shows why large vendors such as Microsoft and Google rely on immutable identifiers for integrating systems and not name-based attributes.
If you imagine System A is Azure AD and System B is Teams, you can see how a rename in Azure AD simply flows through to Teams without any issues, since they're joined by objectId, which remains unchanged.
Cheers,
Lain
deanbennett
Sep 21, 2023Copper Contributor
LainRobertson Thank you for responding! Not something I'm used to (if I'm being honest).
The concern I have is at one point, when I changed the name of a woman who had gotten married, when I changed her AD user information, including her login name, when she logged in with that new login, Windows 10 created a new profile. I changed it back in AD and she was able to log in just fine. Could it have anything to do with an alias?
Thanks again,
Dean
LainRobertson
Sep 22, 2023Silver Contributor
Hi, Dean.
I've run a quick test to ensure what I've recounted hasn't changed (it's been a very long time since I've personally renamed an account) and it hasn't - at least in the specific context I mentioned above.
I renamed my account, logged in with the new sAMAccountName (again, since userPrincipalName is irrelevant to the profile) and no new profile was created.
The specifics of my client environment are (details taken from dsregcmd.exe):
Device | Windows 10 Enterprise 22H2 (19045.3448) |
AzureAdJoined | No |
EnterpriseJoined | No |
DomainJoined | Yes |
I'm not currently in a position to test against hybrid- or Azure natively-joined devices, nor can I test with Azure-native user accounts. My guess is the latter would be handled differently but like any guess, it's 50/50 that I'm right/wrong.
Cheers,
Lain