Access O365 on Demand, Part 3

This is the third installment, please read the prior two posts (Part1 and Part2) to get up to date on what this is all about.

So while the following solution will likely work as described, as far as I know it is not officially supported. So if you implement it and have some issues and contact Microsoft support services, you’ll more likely be asked to reproduce the same issue without external federation.

The following concept design will allow to extend authentication to the external identity providers.

1. First, we federate our O365 Tenant. To do this we will need to have ADDS where we implement DirSync and synchronize accounts from ADDS into Windows Azure Active Directory tenant. Then we install ADFS and federate it with the same tenant.

Now when users try to use accounts for this O365 tenant they will be redirected to the ADFS for authentication.

2. Next, create accounts for external users in ADDS. Link external accounts to their corresponding accounts in ADDS. In this example I’m taking UPN of the external account and put it the “comment” attribute of the ADDS account. This step is obviously the most difficult one in this whole solution. You can do it by hand or come up with some type of Identity Management solution that automates it. As accounts get created in ADDS they will get synchronized into Azure Active Directory via DirSync that was implemented in first step. By default DirSync runs every three hours. If it needs to be more often then you’ll have to trigger it on more frequent schedule.

3. You have to figure out how you are going to activate accounts in O365, as DirSync does not do that for you. You can do it by hand or via PowerShell script.

So far nothing different from any other basic implementation of the O365 and federated ADDS.

4. Next we are going to extend this solution with external Identity Providers. We create normal trust with ADFS acting as RP and external Identity Provider as IdP. One of the super important things to know is that external IdP must be able to provide Authentication Information to the ADFS – ie it must provide information on how user authenticated to IdP and the time stamp of the authentication,  AuthenticationMethod and AuthenticationInstant. For example, none of the Social IdPs are providing such info. Without these assertions it will not work, as O365 requires these assertions.

5. On the incoming trust claims rule of the IdP in ADFS, create the following three rules:

Rule 1:

Rule 2:

Rule 3:

These rules will use incoming UPN from the external IDP and lookup corresponding account in ADDS, and fetch its samAccountName. The result of these rules is the windowsaccountname claim that contains value of the linked user. This claim is used as input claim by the default ADFS O365 claims rules to lookup user UPN and ObjectGUID in ADDS.

That is pretty much all to it.

After implementing above steps, here is how authentication should work:

1. User goes to the https://portal.microsoftonline.com and type their ID for the O365 SharePoint portal (for example, MikeJonesFabrikam@contoso.com)
2. Since O365 tenant is federated, it redirects user to AD FS. Instead of authenticating directly to AD FS they are redirected to their home IdP – Fabrikam.
3. They authenticate to their IDP, for example with smart card.
4. Their home IdP issues required claims and sends user back to AD FS.
5. AD FS does AD DS account lookup, does all the claim transformations and issue outgoing claims for O365.
6. User authenticates into O365 with token issued by AD FS.

Give it a try and see if it works!