Forum Discussion

tommihovi's avatar
tommihovi
Copper Contributor
May 17, 2022

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 handle the situation where user has changed their last name and wants to have the new last name in email address, display name and login UPN. If UPN is changed, how likely is everything from SharePoint permissions, Teams channels and to other 3rd party software depending on Azure AD authentication to break down and burn in fire?

 

Thanks for your reply!
Tommi

  • tommihovi 

     

    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 ASystem B
    objectId586654ba-976b-42f3-bfb3-e7e6f01768df586654ba-976b-42f3-bfb3-e7e6f01768df
    userPrincipalNamelain.robertson@robertsonpayne.comlain.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 ASystem B
    objectId586654ba-976b-42f3-bfb3-e7e6f01768df586654ba-976b-42f3-bfb3-e7e6f01768df
    userPrincipalNamelain.robertsonpayne@robertsonpayne.comlain.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 ASystem B
    objectId586654ba-976b-42f3-bfb3-e7e6f01768df586654ba-976b-42f3-bfb3-e7e6f01768df
    userPrincipalNamelain.robertsonpayne@robertsonpayne.comlain.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

  • LainRobertson's avatar
    LainRobertson
    Silver Contributor

    tommihovi 

     

    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 ASystem B
    objectId586654ba-976b-42f3-bfb3-e7e6f01768df586654ba-976b-42f3-bfb3-e7e6f01768df
    userPrincipalNamelain.robertson@robertsonpayne.comlain.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 ASystem B
    objectId586654ba-976b-42f3-bfb3-e7e6f01768df586654ba-976b-42f3-bfb3-e7e6f01768df
    userPrincipalNamelain.robertsonpayne@robertsonpayne.comlain.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 ASystem B
    objectId586654ba-976b-42f3-bfb3-e7e6f01768df586654ba-976b-42f3-bfb3-e7e6f01768df
    userPrincipalNamelain.robertsonpayne@robertsonpayne.comlain.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's avatar
      deanbennett
      Copper Contributor

      LainRobertson - How does this effect the users Windows 10 profile?  I have a situation where the users primary email address was changed in proxyAddresses and that was fine but now that are being step in a service which the username and the email address 'should' be the same to prevent confusion...  also, the domain.root changed as well as the user.

       

      Thanks for your post.  VERY helpful.

      • LainRobertson's avatar
        LainRobertson
        Silver Contributor

        deanbennett 

         

        Hi, Dean.

         

        Do you mean the user profile typically found under C:\Users?

         

        If so, then this isn't impacted at all by renaming the user's sAMAccountName (which is what the profile directory name is based off, not userPrincipalName as that didn't exist prior to Windows 2000) - and this has been true since the Windows NT 4 days.

         

        Under the hood, Windows clients map the user profile directory to the user through referencing the objectSid value, as shown below. So, renaming sAMAccountName, or any of that others (even though they're irrelevant) like userPrincipalName, mail, etc. will not impact the user profile location.

         

        I should add some context here, which is that I'm talking about Active Directory domain-joined users (which also encompasses hybrid-joined devices).

         

        I don't work with Azure AD native environments meaning I'm not sure to what extent - if any - this advice holds true for users signing into such clients. My assumption would be that there should still be no impact, however, the mechanic used by Windows may be different to the one I've just described here.

         

         

        Cheers,

        Lain

    • tommihovi's avatar
      tommihovi
      Copper Contributor
      Thank you so much for this very profound answer, I'm sure someone else will also find this information useful!

Resources