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:
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:
- User goes to the https://portal.microsoftonline.com and type their ID for the O365 SharePoint portal (for example, MikeJonesFabrikam@contoso.com)
- 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.
- They authenticate to their IDP, for example with smart card.
- Their home IdP issues required claims and sends user back to AD FS.
- AD FS does AD DS account lookup, does all the claim transformations and issue outgoing claims for O365.
- User authenticates into O365 with token issued by AD FS.
Give it a try and see if it works!
This is the second installment on extending access to O365, read the first installment to get a better idea of what I’m discussing here. In the first part I shared what type of functionality this customer wanted and asked if there are any ways to do it.
So before we dig deep into any type of solution solving their needs we need to examine how O365 authenticates users and see if we can use it in our solution.
Probably the main thing to understand about authentication into O365 SharePoint is that it must start at O365 site: https://portal.microsoftonline.com and you must have an account with O365. You can’t start authentication into it from other portals or identity providers (if you know how I’m all ears!).
So the most basic configuration to access the site is to have an account in it and authenticate with this account into the site. The O365 subscription administrator would create such account for the user and provide initial password. The account can be in two different formats:
Most customers would add their <customerdomainname> as the suffix in the account name. This is what my customer is doing with their O365 at this moment as well. They create accounts for external users and communicate account information to them. As I discussed in the first part, they would like to get out of manual account creation and account management.
The next possible authentication solution for O365 is the integration with customer on-premises AD DS via DirSync. The DirSync is installed on one of the on-premises servers and it is used to synchronize accounts from on-premises AD DS into the Azure Active Directory. The latest version of the DirSync even can synchronize passwords. User is still authenticating into O365 via O365 based accounts, by typing their user account and password. The good part here is that those users use the same user account (their UPN) and password as they would use on their internal network. With this option, account must be in the form of yourname>@<customerdomainname>, this is required for DirSync functionality.
As you can see, it does not provide any benefit to the problem that my customer is trying to solve. They would still have to create accounts manually and deal with password management.
The third possible authentication solution is to enable federation between O365 and the customer on-premises environment. This is probably most used option in enterprise environments. Federation is added to the configuration with DirSync already in place (in large environments FIM 2010 R2 is used often as well). After federation is added, when user types their user account at O365 logon page, they are redirected to the Identity Provider STS implemented at on-premises customer environment. If user is connected to the internal on-premises environment then they’ll more likely get single sign on (SSO) experience. If they are outside, then they will be prompted to authenticate to their company Identity STS and then they’ll get into O365. The most commonly used STS is AD FS 2.0, but other vendor products supported as well (like Shibboleth).
So we have three options to authenticate into O365. The first option is what my customer is using right now. The second option will not solve their problem. The third option might provide a foundation for what they are trying to do with their strategy to provide access to their O365 SharePoint environment.
The question is, can we do another hop in federation and extend the third option to external trusted Identity providers?
In the next installment I’ll share what I have learned so far in my trial and errors of extending federated O365 to second level Identity Providers.
Recently one of my customers posed the following problem.
They have O365 SharePoint Online and they need to provide access to this site to many of their external customers.
They want to ensure high level of assurance of those users and it requires some type of multi factor authentication. One of their requirements is that external users should be able to access to their O365 SharePoint site on demand, without a long verification process for account creation.
The customers would come from a known set of e-mail domains or from a set of the trusted Identity Providers.
With O365 there is really no build in process to automate any of it so right now they have to create accounts in O365 for each of the new users by hand and provide full account management to these users, such as password management.
They are not happy about all of this overhead for multiple reasons:
- Account creation for external users takes too long. They have to verify the identity of the user via some type of out of bound process.
- They don’t want to get into business of managing passwords and other account management issues.
- They would have to pay premium for multifactor authentication with O365 for all those external users.
So they posed a question – is there any type of solution that would allow some type of automated account creation in O365 for external users, as long as they are coming from trusted known Identity Provider or they belong to organization with trusted known e-mail domain name?
While the requirements might sound not very complicated, in reality it is actually fairly hard problem to solve. I started thinking about possible solutions to this problem, trying to figure out if some of other integration solutions would allow us to provide a solution to this customer.
To satisfy the first requirement we’d have to come up with self registration solution. This is actually have been done and we can create accounts for external users based on their e-mail domain or register them if they are coming from trusted Identity Provider.
The second problem can be addressed by implementing SSPR solution with the account creation system or it can be fully outsourced to the trusted Identity Provider who manages accounts for those users.
The third problem can be addressed if the trusted Identity Provider can assure that they use some type of multifactor authentication.
And of course on top of all of this we have to figure out all the technical details and see if any of the possible solutions will actually work with O365.
Stay tuned for the next installment. I’ll share some details on how it can be done and some limitations.
If you want to see and learn how to deploy new AD DS Forest into Azure IaaS then check out my new video demonstration. Make sure to watch it in HD.
In my prior two posts I demonstrated how WAAD can be configured as IdP. In this post we document this on paper. The configuration is very simple, but so far I could not find it documented anywhere, so here it is for anyone interested.
In first scenario we will configure WAAD as IdP for Azure ACS. Like shown on this diagram:
To configure ACS as relying party in WAAD you need to do the following:
- Add new application in your WAAD tenant
- Name it whatever you like it
- For App URL:, put the following URL https://<your-acs-name>.accesscontrol.windows.net/ , where <your-acs-name> is the name of the ACS you created in your Azure subscription.
- For App ID URI:, put the same URL as in previous step.
- Save configuration.
Of course you’ll need to add WAAD in ACS as IdP as well.
In second scenario we will configure WAAD as IdP for AD FS. Like shown on this diagram:
To configure AD FS as relying party in WAAD you need to do the following:
- Add new application in your WAAD tenant
- Name it whatever you like it
- For App URL:, put the following URL https://<your-sts-dns-name>/adfs/ls/ , where <your-sts-dns-name> is the URL for your AD FS server (for example sts.cloudidentityblog.com)
- For App ID URI:, put the following http://<your-sts-dns-name>/adfs/services/trust, where <your-sts-dns-name> is the URL for your AD FS server (for example sts.cloudidentityblog.com).
- Save configuration.
Of course you’ll need to add WAAD in AD FS as IdP as well.
There is no mechanism to configure WAAD as to what type of claims it will provide to RP. It is hard coded to provide half a dozen claims for the user. If you need to get information about the user that is not passed via claims you’ll have to use Graph API to query WAAD and find that information programmatically (your app will have to do this).
So I’m somewhat on the roll here and last night recorded another quick thirty minutes demonstration for you guys. This one is very similar to the last one, we are still using Azure AD as an Identity Provider, but this time we putting Access Control Service between AAD and ADFS/ application. Just like on this diagram.
So if you want to see how it works and more importantly how it can be configured then check out my latest video. Make sure to watch it in full screen and HD. Have fun and let me know if you have any questions.
Thanks, Dmitrii Lezine.
In my previous post I showed to you how easy it is to configure Azure AD to act as Identity Provider to Relying Party applications via AD FS. There were questions about ability to configure applications directly with AAD. If it is possible and if it is, then why would anyone want to use AD FS in the middle. The answer is yes, of course it is possible to configure applications to work directly with AAD, in fact most of the AAD online documentation provides examples on how to do that. The second part of this, ok, since we can configure apps to work directly with AAD, why put AD FS in the middle? The simple fact is that not all applications will be configured directly with AAD, and there are a lot of applications that are already configured in some type of federated topology. Lets take a look at the following diagram, here we have hub/spoke environment with a few Identity Providers, central hub and a few applications. Users at each IdP are able to use applications via the central hub. The fact of the matter here is that those IdPs can be any compatible Security Token Service and those IdPs do not care how other IdP are configured. As long as IdP-HUB RP relationship is working, users will be able to access target applications.
This design accommodates requirement to add any number of new Identity Providers and get them to access target applications. So if we have a new customer who uses AAD as their primary user directory and they need to get access to some existing apps, the primary solution would be to configure AAD as another IdP against our hub RP AD FS. Now users in AAD will be able to gain access to the applications. Hub RP claim rules can even transform incoming assertions from one claim type to another, to whatever is required by the target application.
Thanks for stopping by!