IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
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.
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
Office365 Advanced Deployment Guide
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 3rd 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:
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 3rd 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.
HOW TO: Add UPN Suffixes to a Forest
Hope this helps
Keith “Do you know you’re UPN?” Brewer