Score:0

Active Directory Sync: Change user's UPN

mx flag

How do I reconfigure Azure AD sync, used for making single-sign-on possible for Office365 from inside the domain, so that the domain name part of a user's UPN can change when synchronized?

E.g. assume the local domain is ad.contosolocal.com, and the external domain is contoso.com. Currently, only exact copying works, by matching its ID, e.g. by using MSonline;

$username="bob"
$UPN = (-join($username, "contoso.com"))
$guid=(get-ADUser $username).Objectguid
$immutableID=[system.convert]::ToBase64String($guid.tobytearray())
Set-MsolUser -UserPrincipalName $UPN -ImmutableId $immutableID

This does not work very smoothly or reliably: it takes multiple sync attempts, manually fully synchronizing and running each possible option twice for both connectors, for a total of 16 synchronizations (2x2x import, export, sync, and delta), before Azure AD decides to set the UPN to the correct value, and not immediately but about 15 minutes later. It seems to want to set the UPN to bob instead of [email protected] for some to me as-of-yet inexplicable reason. Dealing with this for many users is frustrating for them as logins break while values are not set correctly.

Then I want:

+--------------------------+------------------+------------------+
|       Local value        |  Sent to Azure   |   Azure Value    |
+--------------------------+------------------+------------------+
| [email protected]  | [email protected]  | [email protected]  |
| [email protected] | [email protected] | [email protected] |
+--------------------------+------------------+------------------+

If this is naïvely done by making my own 'Synchronization rules' it breaks passwords (users are no longer able to log in, with 'password invalid' errors). Passwords only work when the user's UPN matches what it is online, even if password sync is turned off (seems like this is a bug). Of course, the e-mail domain matches that of the website, which means if local paths start doing the same this leads to DNS problems; no longer being able to access the company's website from the local domain.

The other way around, using ad.contosolocal.com as the login online is also not really a viable option, users want to login using the 'real' domain name. (Aside from the number of support hours it would take to get all of them to change the login domain in all their programs on all their devices)

It is also possible for me to place the user's remote-UPN in a different local-AD-attribute (typically the mail attribute), in that case I could change the sync to match mail to UPN.

Unfortunately, re-running the Azure AD Connect wizard; it does not give me any options to change what I've got the UPN mapped to. It seems to simply not display the option after the first time you've ran it.

I want this to happen:

  • Passwords and usernames are synchronized from local AD to Azure AD.
  • The local domain part of UPNs is always a fixed value.
  • The remote domain part of the matched UPNs is always a fixed (different value)
  • Users need to be able to log in to Office365 from both outside the internal network, as well as inside.
  • Office-365 uses Single-Sign On; local outlook/word/etc. automatically logs into office-365 without having to provide credentials.

Q: How?

cn flag
How often have you been performing this ridiculous procedure?
Score:0
in flag

That sounds like "Prepare a non-routable domain for directory synchronization". In essence, you need to add the domain.com into "Active Directory Domains and Trusts" MMC. Righ-click, go to properties and add UPN. Overall have a look here: https://docs.microsoft.com/en-us/microsoft-365/enterprise/prepare-for-directory-synchronization?view=o365-worldwide

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.