Microsoft Office Tutorials and References
In Depth Information
Remediating the UPN suffix
Note
User Principal Name (UPN) is the most common problem we see in AD. Most
companies implemented AD many years ago when the Internet was still young and cloud
computing was virtually unheard of. The Internet was considered the wild west with all
its promises and dangers. Back then, a common security best practice was to give AD
a non-routable UPN. The common UPN suffix used is typically .lcl or .local. The reason
why Office 365 requires a valid UPN suffix is twofold. One, we will be creating a
federation between Office 365 and the local AD during the AD FS installation. This requires the
domain to be added to Office 365 as we saw earlier in the chapter. Adding the domain
to Office 365 requires the validation of a TXT or MX record through DNS, so the domain
needs to be valid and routable. Second, when we install directory synchronization, the
user name for an Office 365 account is in UPN format (example < User Alias >@adatum.
com). The Directory Sync tool uses the UPN of the local AD to create the user account
in Office 365. If the UPN of the local AD is not added and verified in Office 365, as will
be the case with a non-routable UPN, then the user will be created with the default
onmicrosoft.com UPN suffix that was created when the Office 365 tenant was created
(example: < User >@adatum.onmicrosoft.com).
Follow these general steps to implement SSO using AD FS:
Remediate your AD UPN suffix.
Install IIS on the server that will host AD FS.
Protect IIS with an Secure Sockets Layer (SSL) certificate.
Install and configure AD FS 2.0.
Remediating the UPN suffix
The good news about remediating the UPN suffix in AD is that you do not need to replace
your old UPN suffix if it is not federated with Office 365. In fact, you are not able to replace
the original UPN that was used when you first created a forest.
Search JabSto ::




Custom Search