Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
Office 365 & Single Sign-On: How to Handle Different UserPrincipalName (UPN) Values
Published Sep 19 2018 04:18 PM 1,166 Views

First published on TechNet on Sep 01, 2013

Hey folks, Keith Brewer here to discuss an issue I encountered while working with a Microsoft Premier Customer . As a PFE we are often asked to assist our Premier customers with a specific technology. In this instance I was asked to assist with Active Directory Federation Services (ADFS). Fellow PFE Jasmin Amirali recently blogged an ADFS FAQ on ASKPFEPLAT here . Now you ask what this has to do with Office365 and UPN values. Well after ADFS was up and running, validated with a sample claims aware application in the cloud an issue arose with finalizing Single Sign-On (SSO) with their email provider O365. While not an ADFS issue the below information may be helpful if you were to find yourself in the same situation.

 

Their particular configuration is described as Scenario 2 here:

How to pilot single sign-on in a production user forest http://community.office365.com/en-us/wikis/sso/357.aspx

 

Scenario 2: The organization has decided initially not to use single sign-on (identity federation). Instead the organization’s users are using Microsoft Online cloud IDs (i.e. non-federated IDs) to sign in to Office 365 services. At some point later the organization decides that they want to start using single sign-on, by converting their existing users from standard Microsoft Online cloud IDs to federated IDs.

While the ADFS infrastructure was validated another problem was lurking waiting to rear its ugly head just shortly after the online domain was converted from Standard (Managed) to Federated.

 

Problem:

Users within an IT organization receive 8004786C from O365 error shortly after converting the online from standard (Managed) to Federated.

In troubleshooting you may come across:

Troubleshoot Active Directory user accounts that are piloted as Office 365 SSO-enabled user IDs http://support.microsoft.com/kb/2392130

Now you may or may not have piloted these users but the key for this scenario was:

•The on-premises Active Directory user account should use the federated domain name as the user principal name (UPN) suffix

•The UPN of the on-premises Active Directory user account and the Office 365 user ID must match.

In this customers scenario the on premise user accounts value for UserPrincipalName mapped to the internal Active Directory domain which was different then their online domain within O365.

It is highly recommended to run through some readiness checks before enabling SSO (creating or converting) to ensure accurate functionality with SSO for Office365.

Microsoft Premier Customers can engage with their TAM and have an Office365 Migration Readiness Assessment (OMRA) completed.

Additionally there are some other utilities and articles that can help expose situations like this one prior to encountering an issue.

Office365 Ramp Tool

https://onramp.office365.com/onramp/

Office365 Advanced Deployment Guide

http://technet.microsoft.com/en-us/library/hh852483.aspx

 

Solution:

There are a number of potential solutions to this issue as discussed in the above articles

This customer decided to change all users on premise UPN value to match that of the online domain within O365.

*** This is not a subtle change and can have massive repercussions to user authentication and/or 3 rd party applications leveraging the current UPN value ***

 

Now to move onto how to wholesale change the UPN value for numerous users quickly.

I have written a PowerShell script to evaluate the current UPN suffix for a specific administrator provided string (OldUPNString) and if present to replace it with an administrator provided string (NewUPNString). It will perform this operation on all user accounts found starting at an administrator provided location (TargetDN). This script is available here:

http://gallery.technet.microsoft.com/Change-On-Premise-Active-93d5cc2d

Notes: The value provided with OldUPNString is case sensitive.

Which means a value provided of Contoso.com will not match contoso.com.

This is by Design.

Additionally Line 55 of this script Contains the –whatif switch:

 

This switch ensures that the script in its default configuration will make no changes to the Active Directory. The –whatif switch must be removed from the script in order for any changes to be made.

I will re-state the earlier warning here:

*** Changing a user’s UPN value is not a subtle change and can have massive repercussions to user authentication and/or 3 rd party applications leveraging the current UPN value ***

 

Script in use:

Some Information on the users being queried:

 

Run the script targeting the UPNChangeTest OU

 

Screen output shows that all user accounts including those located in Sub OU’s. The script will output to the screen each user account and appropriate action taken.

Here is the resulting configuration:

 

In addition to the screen output the script will create a log file with the SAMAccountName of each user where the userprincipalname suffix was changed.

If adding a new suffix it is also recommended to add this new suffix to the Active Directory Configuration.

 

See:

HOW TO: Add UPN Suffixes to a Forest

http://support.microsoft.com/kb/243629

 

Hope this helps

 

Keith “Do you know you’re UPN?” Brewer

Version history
Last update:
‎Feb 19 2020 08:01 PM
Updated by: