Using Azure AD as an Identity Provider with ADFS for SharePoint 2013

I had someone ask me about this topic a couple times in the last few weeks so I decided it was time to spin up another blog post.  The question is about how you can connect your on premises SharePoint farm to Azure Active Directory (AAD) using ADFS.  Now I had blogged about how to do this with ACS some time ago (https://samlman.wordpress.com/2015/03/02/integrating-sharepoint-2013-with-azure-active-directory-part-1-configuration/).  However, as most folks know ACS is coming off the Christmas card list as it starts a slow spiral downwards to deprecation and irrelevance.  Thus the questions about using ADFS instead.  Fortunately this all quite possible, but there are quite a few steps, so it just takes some patience.  I’ll supply the steps, you supply the patience.  And with that, here we go.

STEP 1:  Set up DirSync between Your On Premises Active Directory and Azure AD

I’m not really going to cover this in any detail here because a) I think there are lots of places out there where you can find this info and b) it would really bloat this post and it’s going to be a little long as is.

STEP 2:  Add ADFS as an Application in Azure AD

In this step you’re going to add your on premises ADFS server as an application in your Azure AD directory.

  1. Go to the Azure Management portal
  2. Click on Active Directory in the left navigation
  3. Click on the name of your Active Directory tenant in the main pane.
  4. Click on Applications in the top navigation.
  5. Click the ADD button to create a new application.
  6. Click on Add an application my organization is developing

bp11

  1. Type a name for the application and define it as a web application.

bp12

  1. Type the following values on the next page of the wizard to add an application:
    1. SIGN-ON URL:  Use https://%5BYour ADFS Farm Name]/adfs/ls, where “[Your ADFS Farm Name]” is the DNS name of the ADFS farm to which users should be redirected.  For example, if your ADFS farm name is “adfs.contoso.com”, then you would enter https://adfs.contoso.com/adfs/ls for this value.
    2. APP ID URI:  Use http://%5BYour ADFS Farm Name]/adfs/services/trust, where “[Your ADFS Farm Name]” is the DNS name of the ADFS farm to which users should be redirected.  For example, if your ADFS farm name is “adfs.contoso.com”, then you would enter http://adfs.contoso.com/ adfs/services/trust for this value.  IMPORTANT:  Make sure you use “http” and NOT “https” when entering this value!

bp13

You’re done with this step now; your Azure AD application is configured.

STEP 3:  Add Azure AD as an Identity Provider in ADFS

In this step we’re going to add Azure AD as an identity provider in ADFS.

  1.  Open the AD FS Management tool.
  2. Expand the AD FS…Trust Relationships…Claims Provider Trusts node.
  3. Click on Add Claims Provider Trust.

bp14

  1. Click the Start button to start the wizard.
  2. Use the first option to import data about the claims provider.  For the Url use https://accounts.accesscontrol.windows.net/%5BYourTenantName%5D/FederationMetadata/2007-06/FederationMetadata.xml, where [YourTenantName] is something like contoso.com.  Click the Next button.

bp15

  1. Type a display name for the claims provider, then click the Next button.
  2. Click the Next button.
  3. The option to open the Edit Claim Rules dialog should be checked by default; click the Close button to close the wizard and open the Edit Claim Rules dialog.
  4. Click on Add Rule.
  5. Select the Transform an Incoming Claim in the Claim Rule Template drop down and click the Next button.
  6. Configure the rule as follows:
    1. Claim Name – I called mine “Transform Name to Email”, but you can call it whatever you want.
    2. Incoming Claim Type – select Name
    3. Outgoing Claim Type – select E-Mail Address
    4. Click the Finish button to save your rule.  You can ignore the warning dialog that appears when you click the Finish button by clicking Yes.

bp21

You’re now done configuring the Azure AD part of this.  The next thing you need to do is create a relying party for SharePoint and add a rule to it to pass through the email claim.

STEP 4:  Create Relying Party in SharePoint and Add Pass Thru Rule

Okay, now I’m not going to go through the detailed process of creating a relying party for SharePoint in ADFS…for the same reason I didn’t include detailed steps for setting up DirSync.  If you have questions about how to do that then you can refer to my earlier post on this topic:  https://samlman.wordpress.com/2015/02/28/configuring-sharepoint-2010-and-adfs-v2-end-to-end/.  Instead, we’ll assume your relying party is created and we’re going to create the pass through claim rule.  Here’s how to do that.

  1. In the AD FS Management tool, click on the SharePoint relying party to select it, then click on the Edit Claim Rules link.
  2. Click on the Add Rule… button.
  3. Select Pass Through or Filter an Incoming Claim in the Claim rule template drop down and click the Next button.
  4. Configure the rule as follows:
    1. Claim Name – name it “Pass Through Email Claim” (or whatever you want).
    2. Incoming claim type – select Email Address.
    3. Click the Finish button to save the rule.

bp17

STEP 5:  Create Your SPTrustedIdentityTokenIssuer in SharePoint and Configure

Again, I’m not going to go through every detailed step for this because you can get that from my other post: https://samlman.wordpress.com/2015/02/28/configuring-sharepoint-2010-and-adfs-v2-end-to-end/. The only key takeaway here is that I have only one claim in my claim mappings collection, and that is email address.   After you configure the SPTrustedIdentityTokenIssuer, create and configure a web app to use it, and then create a site collection, just add the email address of an AD user to a SharePoint group for the site and try logging in.  If everything is configured correctly you should get right in.  Here’s what the login process looked like for me:

1.  On the ADFS page I selected the Azure Active Directory provider I created as described above:

bp18

2.  Log into Azure Active Directory:

bp19

3.  Kaboom – I’m in my SharePoint site!! 🙂

bp20

15 thoughts on “Using Azure AD as an Identity Provider with ADFS for SharePoint 2013

  1. Steve, great blog post. One question I have: When SharePoint receives the Identity claims does that appear to come directly from the ADFS server or does the claim appear to come from Azure AD?

    Like

  2. Hi steve, and thanks for that article, brilliant as always.
    I’ve setup ADFS with my SharePoint and can succefully auth (using AD). I want to use AAD as an external user repository, so i don’t sync anything yet. Adding AAD as another IDP in ADFS will not need another trusted id provider in SharePoint? (it is federated by ADFS if I follow)
    two questions :
    1. AAD users can only have emails registered in the tenant. Could you map another identifier to use in ADFS, for example a second email?
    2. I noticed most samples using a custom provider extend the SharePoint zone (default NTLM, extended ADFS) for crawling, but if you handle the auth dropdown and the people picker side effects (which I did), you can perfectly keep one default zone and both NTLM and ADFS activated.Any side effects I didn’t see?🙂

    Thanks for any input

    Like

    • Hey Emmanuel. WRT having ADFS map another identifier to use in ADFS, that’s complete feasible. You can take whatever value you want in AD and send it out as any claim value after authentication. As far as #2, I’m not entirely sure I understand your scenario so I will just say this. You will break “some” search features if you don’t have NTLM enabled on the default zone. You will break “some” features (I forget the list, it was a couple / three things last time I looked, including one or two SharePoint social features) if you don’t have your users authenticate through the default zone. So that’s why you see most things working through the default zone, it’s just the safest (and most tested) option.

      Liked by 1 person

  3. Thanks for the response. to precise,

    for #1, AAD request us to use a tenant registered domain for upn. I want to register external users on AAD, but using their personal email as login. From my point of vue, nothing prevents identifying users via the tenant email, but authenticating them with their email (another claim)
    as in john@contoso-external.com logs in with john@caramail.com🙂

    for #2, my purpose is to keep *BOTH* AD and ADFS activated in the default zone to prevent extending it.
    Side effects i have managed :

    1. – the auth dropdown has to be bypassed, because all users, except the crawler, use the ADFS provider.
    Can be accomplished without code (custom sign in page = “/_trust/Default.aspx”), or with code (check user agent, if it’s the crawler, use IWA, else ADFS)

    2. – the internal users appears twice in the people picker (since they are resolved both by AD and ADFS)
    there is a supported way of hiding a provider :
    $cpm = Get-SPClaimProviderManager
    $ad = get-spclaimprovider -identity “AD”
    $ad.IsVisible = $false
    $cpm.Update()

    on my lab machine, it crawls and i have a functional people picker.🙂

    You auth with ADFS, but the only provider i setup is the default AD one.
    Now, i want to register AAD as another IDP, and i don’t find many guidance on that, especially as my lab VM has no public adress yet, so i work on paper ^^

    here are my assumptions :

    – you’ll need to exchange the STS certificate between your ADFS and AAD? namely, if i follow, the contoso domain must be registered in your tenant, and you upload the ADFS STS to it (and possibly another if encrypting tokens)

    – you’ll need ADFS sign in page to be exposed via a public adress, obviously

    – no code is needed, as you’ll use AAD webservices when declaring the IDP

    – the custom identity provider i created for ADFS will consume tokens from AAD transparently because it’s ADFS that does the “plumbing”.

    -lastly, i’ll have to map claims differently in the IDPs to solve #1

    Sorry for the wall of text, if you have any thoughts on this, it’d help, as MS ressources in france are few and not easily reachable (if any)

    -Emmanuel

    Like

  4. Hi Steve,

    Great article! I configured my SP and ADFS this way but SharePoint returns an error “System.IdentityModel.Tokens.SecurityTokenException: ID4014: A SecurityTokenHandler is not registered to read security token (‘Assertion’, ‘urn:oasis:names:tc:SAML:2.0:assertion’)..”
    Does SharePoint works with SAML 2.0? Do I need to configure something? Any advice will be much appreciated. Thank you in advance.

    Olga

    Like

  5. Hi Steve,

    is there also any possibility to synchronize the users to SharePoint directly from AAD (User Profile Sync), maybe with AD Import?

    Like

  6. Hi Steve, have you tried to use the Azure B2B with SharePoint OnPremises? I have seen that it is possible to attack to the APIs, but reading all the documentation I do not see nothing related with SharePoint OnPremises, all references point to SharePoint Online😦

    Like

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