Office 365 federation with .local UPN

Recently I came across a scenario where they wanted to host Exchange and Lync In  Office 365. They wanted to use federation (passive authentication) since it doesn’ t really make sense to have you domain passwords in the cloud especially since we’re living in a post Snowden world.

Now to the problem. They have a domain.local upn and bacause of some legacy applications they were unable or at least unwilling to change the upn as this would require a longer period of time to implement than they had before needing to go In production with Office 365.

Microsoft’s recommendation in this case is to add an additional upn suffix that is the external domain name (internet routable) and than configure the accounts to use it as login.

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

Since that solution was ruled out, the only option left (from a Microsoft point of view) is to sync the passwords to the cloud instead of using federation.

I was unwilling to accept this solution as the only one. My main approach when people tell me it can’t be done is to prove them wrong. And i did.

Here is what i did, first of all i made sure that the upn In Office 365 is set to the external internet routable domain name.

Now it’t time for you to go “hey, but you just said don’t change the UPN”
Yes i did, and I’m not talking about changing the upn In the local domain. I’m talking about making sure that the upn that is synced to the cloud is the internet routable external domain name.

So how do we do this?

You’ll need to use the miisclient. You’ll find it on the server you’ve used for dirsync. It’s located in C:\Program Files \Microsoft Online Directory Sync \Syncbus\Synchronization Service\UIshell\

Start it and go to the management agents tab.

Now dubble click the ActiveDirectory

Next locate the Metaverse Attribute that is userPrincipalName and then remove it.

Now we’ll create a new flow that will use the mail attribute as Data source and map it to the userPrincipalName as a Metaverse object.

Once this is done all new objects will be synced and the UPN in Office 365 will be set to the mailattribute on-prem.

When this is done we won’t yet be able to authenticate using passive authentication with adfs federation. This is because the upn in cloud and on-prem differ as earlier explained.

What we need to do to fix this is to edit the pre defined claim that you get when creating the trust between Office 365 and your ADFS server. You’ll find it by clicking “edit claims rules” on the Ralaying Party Trust for Microsoft Office office 365.

Select to edit the first claim, that number 1 in the order.

Then change the userPrincipalName to mail. It’s the highlighted part in the picture.

Once the the value userPrincipalName is changed to mail we tell the ADFS server to  build the claim but to use the mail attribute as the UPN. The mail attribute will match the UPN in cloud using the internet routable external domain name.

Tada! Now we can login using passive authentication without having to change our internal UPN. This also works when using a 3rd party IDP providing two factor authentication like Pointsharp .