@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 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
