Skip to content

Access O365 on Demand, Part 3

November 19, 2013

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:

image

Rule 2:

image

Rule 3:

image

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:

image

  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!

Advertisements
3 Comments
  1. Rod Marr permalink

    Great stuff. How could this scenario be expanded upon if the Fabrikam external partner had their own Azure AD directory? They might themselves be an Office 365 customer with their own federation back to their own ADDS. Could the Fabrikam Azure AD tenant be federated to to complete the authentication?

    • Rod, the external IDP cannot be another WAAD Tenant. Browser will get “confused”, ie it will see that you are already authenticated into Azure with recognized account and as it tries to authN into target Tenant you’ll get a message stating that you already authenticated. It is all happening in the same session.

Trackbacks & Pingbacks

  1. Logging into AAD via 3rd level Federated Account | Security and Identity in the Cloud

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: