Step by Step – Complete Guide to Configure ADFS 2.0 Integration with SharePoint 2013 on Windows Server 2008 R2

This article outlines the high level steps for ADFS 2.0 integration with SharePoint 2013 farm on Windows Server 2008 R2 & detailed steps required to fine tune SharePoint platform for ADFS 2.0 including User Profile Sync and Search Service. Unfortunately this article doesn’t have any visual guidance but packed with lots of real world information. I am hoping to update this article with more visuals and screenshots for easy to follow guidance.

In this article, we will install ADFS single server environment, configure ADFS 2.0 and SharePoint 2013 integration for two SharePoint web applications – Intranet.niks.local and my.niks.local, and resolve some of the issues with User Profile Sync service and Search Service Crawling due to ADFS 2.0 & SAML 2.0 integration. In addition to UPS and Search, there are issues like People Picker Resolve issues. This article does not cover resolving People Picker and how to write custom claims provider. Final list of ADFS 2.0 and SAML 2.0 issues with SharePoint 2013, please see here.

Step by Step ADFS 2.0 Install Guide on Windows Server 2008 R2

  • Pre-requisites
  • Install ADFS
    • Login to the box as Niks\adfs_install
    • Install the ADFS application from the downloaded file. Note, do not install the ADFS role in server Windows Server 2008 R2.  That will install ADFS 1.0.  ADFS 2.0 must be installed from downloader from Microsoft’s site.
    • To install ADFS 2.0, run ADFSSetup.exe as administrator, Use shift+right click on ADFS 2.0 Management and run as domain administrator
      • Federation server – For the “internal” domain-joined ADFS server, you will install the Federation Server role.
      • Uncheck the start ADFS 2.0 management snap-in when this wizard closes on the final page of installation, Uncheck the box when ADFS finishes. The CU 3 will be installed before the actual configuration of ADFS takes place.
    • Install ADFS 2.0 RU 3 Hotfix – Run Windows6.1-KB2790338-v2-x64 to update. The Hotfix may require a reboot of the server.  Do so before continuing with additional configuration steps.
  • Prepare IIS for ADFS
    • Ensure Niks\adfs_install has access to CA and Web Server template
    • Request Domain cert – adfs.niks.local or Import the federation service URL cert on the Server. You can either import it directly into IIS, or into the Personal Store of the Local computer using the Certificates Snap-in in an MMC.  The certificate needs to be in PFX format, with the private key when importing into the ADFS proxy servers.  Accomplish this by first importing the cert into the server that created the CSR, then export it as a .pfx with the private key.
    • Update IIS bindings on default web site for 443 and run iisreset
  • Configure ADFS 2.0 Federation service
    • Run ADFS 2.0 Management Console, Use shift+right click on ADFS 2.0 Management and run as domain administrator
    • Run ADFS config wizard – Create new federation service, New federation server farm, specify adfs_install service account
    • ADFS uses windows internal databases
    • This should create new federation service at https://adfs.niks.local
  • Verify ADFS 2.0 installation
  • After connecting back and forth between home/work network, was getting Error – 1053 – AD FS Service fails to start when configuring AD FS on Windows 2008 SP2, fixed by adding registry entry mentioned in this blog – http://www.amintavakoli.com/2012/12/ad-fs-service-fails-to-start-when.html

Step by Step Guide for ADFS 2.0 and SharePoint 2013 Integration

  • Reference – Configuring SharePoint 2010 and ADFS v2 End to End – http://blogs.technet.com/b/speschka/archive/2010/07/30/configuring-sharepoint-2010-and-adfs-v2-end-to-end.aspx
  • It is important to note that this article uses Email as ADFS login and requires mail attribute populated in AD. If you are using UPN, make sure you use UPN instead of Email through this article while creating relaying parties claim rules and registering SharePoint STS Provider.
  • Create Trusted Relying Parties
    • Open the ADFS 2.0 management console on de Federation Server.
    • Select Trust Relationships. Right click Relying Party Trusts and select Add Relying Party Trust.
    • Intranet.niks.local
      • Use the following settings in the wizard :
        • Select Data Source : Enter data about the relying party manually
        • Specify Display Name : intranet.niks.local
        • Choose Profile : AD FS 2.0 profile
        • Configure certificate : next (do not select a certificate)
        • Configure URL
        • Relying party trust identifiers :
        • Choose Issuance Authorization Rules : Permit all users to access this relying party
        • Review settings
        • Check : Open the edit Claims Rules Dialog for this relying party trust when the wizard closes
      • Next start the Edit Claims Rules Dialog. Select the tab Issuance Transform Rules and choose Add Rule
        • Use the following settings in the Add Transform Claims Rule wizard :
        • Select Rule Template : Send LDAP Attributes as Claims
        • Configure Rule :
          • Claim Rule Name : Pass-through LDAP Claims
          • Attribute Store : Active Directory
          • Ldap Attribute : E-Mail-Addresses | Outgoing Claim Type : E-mail Address
    • my.niks.local
      • Select Trust Relationships. Right click Relying Party Trusts and select Add Relying Party Trust.
      • Use the following settings in the wizard :
        • Select Data Source : Enter data about the relying party manually
        • Specify Display Name : my.niks.local
        • Choose Profile : AD FS 2.0 profile
        • Configure certificate : next (do not select a certificate)
        • Configure URL :
        • Relying party trust identifiers :
        • Choose Issuance Authorization Rules : Permit all users to access this relying party
        • Review settings
        • Check : Open the edit Claims Rules Dialog for this relying party trust when the wizard closes
      • Next start the Edit Claims Rules Dialog. Select the tab Issuance Transform Rules and choose Add Rule
        • Use the following settings in the Add Transform Claims Rule wizard :
        • Select Rule Template : Send LDAP Attributes as Claims
        • Configure Rule :
          • Claim Rule Name : Pass-through LDAP Claims
          • Attribute Store : Active Directory
          • Ldap Attribute : E-Mail-Addresses | Outgoing Claim Type : E-mail Address
  • Trust and Export Token Signing Certificate
    • If Token Signing Certificate is not trusted, Install it on the local trusted root certification authorities
    • Export Token Signing Certificate for SharePoint farm
  • Install Token Signing Certificate on SharePoint
    • Login to the Central Admin box
    • Run following PowerShell command from SharePoint PowerShell Management Shell as An administrator, This should add “ADFS SAML Provider” as Trusted Identity Provider

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\Host\ADFS Signing.cer")
New-SPTrustedRootAuthority -Name "Niks ADFS Token Signing Cert" -Certificate $cert
$map1 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
$realm = "urn:sharepoint:intranet"
$signinurl = "https://adfs.niks.local/adfs/ls/"
$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS SAML Provider" -Description "ADFS 2.0 Federated Server" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
$uri = new-object System.Uri("https://my.niks.local")
$ap.ProviderRealms.Add($uri, “urn:sharepoint:mysite”)
$ap.Update()

  • Prepare SharePoint Web Apps to Test
    • Update SharePoint Web Applications – Intranet and My Site
      • For both web apps, Uncheck NTLM as Authentication Provider and Select ADFS SAML Provider as Authentication Provider
      • Add “Everyone”  from ADFS SAML provider in web application user policy
      • This should create “trust” directory in IIS web root for both web apps
    • Update Site Collection Admins – Primary and Secondary Admins from ADFS SAML provider
  • Major issues after initial setup
    • Login with windows logon prompt (not adfs logon form, this is ADFS issue)
    • User Profile Sync and Welcome Users, Existing User Profiles, User Info List, and My Sites cleanup/migration
    • Search Crawling
    • People Picker resolves everything
  • Verification of Access
    • Verify login with admin/non-admin accounts to both My Site and Intranet web app
      • By default, after initial integration, browser prompts logon option same as NTLM integration (this is ADFS logon option)
      • It should work for both email (npatel@niks.local) and windows credential (e.g. Niks\npatel) format
    • Issues
      • Welcome menu shows “email”, not full name
      • Users can log with both email (npatel@niks.local) and windows credential (e.g. Niks\npatel) format
      • Multiple My Sites may be created (one for existing Niks\npatel (windows credential) and second for naptel@niks.local (ADFS credential))
      • Multiple User Profiles may be created (one for existing Niks\npatel (windows credential) and second for naptel@niks.local (ADFS credential)) – If you are logging in with ADFS, your incoming userid (email address) won’t match NTLM synced user profile, it would create another user profile on demand. Since SAML based email profile is not synced from AD, it doesn’t have properties like Name (preferred Name) with Full Name. This will cause email showing up in Welcome user control. Please note User Profile – Name property shows up in Welcome User control.

Configure ADFS 2.0 Login Page for SharePoint 2013

  • The ADFS default is to present a Windows popup box when the user is redirected there. This expects a login in the form of domain\user. As the user email address does not follow this pattern typically we want ADFS to present the user with a form – otherwise you may find that the user will not be able to login successfully.
  • To replace login prompt with form, only thing you have to do is change the sequence of local authentication type for ADFS server, On the ADFS server: Open IIS Manager, Expand the Default Site – adfs – ls, Right-Click the site and Explore to get to the web.config folder. Here we want to put the forms login above the integrated login. Swap the first two lines so that the localauthentication section looks like this:
  • Default XML

<localAuthenticationTypes>
<add name="Integrated" page="auth/integrated/" />
<add name="Forms" page="FormsSignIn.aspx" />
<add name="TlsClient" page="auth/sslclient/" />
<add name="Basic" page="auth/basic/" />
</localAuthenticationTypes>

  • Login Page XML

<localAuthenticationTypes>
<add name="Forms" page="FormsSignIn.aspx" />
<add name="Integrated" page="auth/integrated/" />
<add name="TlsClient" page="auth/sslclient/" />
<add name="Basic" page="auth/basic/" />
</localAuthenticationTypes>

  • After saving above changes, ADFS will present form instead of login prompt.
  • Please note that – you can still login with both email and domain\user format. This step just changes the UI for login.

Fine Tune User Profile Sync Service to work with ADFS 2.0

  • User Profiles & My Sites – Needs to cleanup from NTLM to ADFS SAML integration
  • For Non-Production, Newly Configured Farm
    • Cleanup Manually all the NTLM data
      • Delete all existing accounts from Site Collection User Info List – https://intranet.niks.local/_catalogs/users/detail.aspx, this is because sometimes Timer job not able to sync User Profiles to Site collections due to differences between NTLM and SAML IDs.
      • Delete all existing My Sites
      • Delete all existing User Profiles – Search domain name (e.g. Niks)
      • Delete Existing UPS Connections for NTLM AD
    • Create ADFS UPS Connection – Step by Step Guide
      • Create UPS Connection – Niks ADFS Connection and Sync user profiles
      • Select “Active Directory” as Type, , “niks.local” as forest, “Trusted Claims Provider Authentication” as Authentication Provider Type, “ADFS SAML Provider” as Authentication Provider Instance, and “niks\sp_upssync” as Sync account
      • Update User Profile Properties – Claim User Identifier – Mail (ADFS SAML Provider).  Please note that if Claims User Identifier doesn’t match Trusted Claims Provider unique identifier, it will sync users with NTLM format
      • Run the Full Profile Sync, It should have all the User Profiles in SAML format with additional properties like First Name, Last Name, and Full Name
    • Syncing Welcome User
      • There are two timer jobs – “User Profile Service Application – User Profile to SharePoint Full Synchronization ” and “User Profile Service Application – User Profile to SharePoint Quick Synchronization”, You can manually Full Sync or Quick Sync job to manually sync user profiles from Central Admin to Site Collections
  • Verify User Profile Implementation
    • User Profiles are created => All Service accounts in NTLM (Domain\User) format since they don’t have mail attribute populated in AD, All Users are in SAML format since all users have mail attribute populated in AD
    • Once you login with either NTLM credentials or Email in login prompt, It should create only 1 version of My Site (with domainUserID format, not email) and should show Full Name in Welcome User Control (after few minutes when site collection user list gets synced with My site user profiles)

Fine Tune Search Crawling to work with ADFS 2.0

SharePoint 2013 doesn’t support search crawling on SAML enabled web applications. You must crawl search on NTLM enabled web applications

  • Extend the Web Apps
    • Intranet
      • Create a new IIS web site – SharePoint – 4087
      • Port – 4087
      • No Host Header
      • Allow Anonymous – No
      • Use SSL – No
      • Enable Windows Authentication – NTLM
      • Public URL – http://NIKS-SP13-APP1:4087
      • Zone – Intranet
    • My Site
      • Create a new IIS web site – SharePoint – 5298
      • Port – 5298
      • No Host Header
      • Allow Anonymous – No
      • Use SSL – No
      • Enable Windows Authentication – NTLM
      • Public URL – http://NIKS-SP13-APP1:5298
      • Zone – Intranet
    • What happens under the hood?
      • You should be able to access Intranet and My sites with default zone same way as before
      • Extending web apps shouldn’t add new SharePoint web apps (Manage Web Applications in Central Admin)
      • This should add couple of Alternate Access mappings for extended web apps with intranet zones
      • This should add two IIS web sites/wss virtual directories on WFE servers with same app pool as their default zone counterpart
        • SharePoint – 4087 (App Pool – Intranet)
        • SharePoint – 5298 (App Pool – MySites)
  • Modify Content Source URLs for NTLM URLs to crawl
  • Add Server Mapping for NTLM URLs to Public URLs
  • Since extended web URL is one of the application server, enable “SharePoint Foundation Web Application” from Services on Server Page on App1 Server to ensure search can crawl http://NIKS-SP13-APP1:4087 and http://NIKS-SP13-APP1:5298 URLs
  • Reset the Index and Perform Full Crawl on NTLM enabled sites
    • There should be no major errors in Crawl log
    • Verify the search results – conversations, people, everything in documents works fine as intended.

That’s it. If you have made it so far, hopefully you have working environment for ADFS 2.0 and SharePoint 2013 on Windows Server 2008 R2.

Advertisements
This entry was posted in ADFS, SharePoint 2013, SP2013 Admin, VM Scripts. Bookmark the permalink.

18 Responses to Step by Step – Complete Guide to Configure ADFS 2.0 Integration with SharePoint 2013 on Windows Server 2008 R2

  1. This is excellent. Thanks Nik!

  2. Excellent article, but extending the webapp will have side effects on alerts (and possibly WAC), everything that isnt remapped by SPS 2013. What about activating both NTLM and AFDS on the default zone?

    • Nik Patel says:

      Interesting thoughts. I haven’t tried yet but can see some logistics issues especially login prompt and how search internally reach out to NTLM zone for crawling.. Let me know if you give it a try.. I believe I have tried and encountered some issues but can’t recall.

  3. Hi nik, bypassing the auth dropdown and setting the AD provider to visible=false in the people picker seems to resolve it for me. I can’t see no side effect and it crawls. From an architecture POV, i’d gladly prefer one IIS site (one webapp) and wonder why 100% of the web extends the application to an ADFS zone?

  4. my comment disappeared ^^
    it works, and bypassing the auth dropdown and hiding the AD provider in the people picker (no code). I wonder why everyone on the web extends the app with ADFS, can’t see the reason

    • Nik Patel says:

      Hi Emmanuel, Sorry it never disappeared.. It requires my approval before someone posts comments.. Interesting architecture. I have never tried that option. It would be great if you document and share with others.

      As far as bypassing the auth drop down and setting AD provider to visible=false.. where do you configure that? how would you do that? I agree – 1 IIS site would be better option.. Only NTLM crawling requires additional web app.

  5. Hi Nik, sorry for the double post. You can delete either 🙂
    I found those solutions documented in an obscure part of technet 🙂
    [https://msdn.microsoft.com/en-us/library/office/hh237665(v=office.14).aspx]

    For bypassing the auth dropdown, you either :

    1.- declare “/_trust/Default.aspx” as a custom signing page (no code, quick and dirty)
    2.- use https://spautomaticsignin.codeplex.com/ for example

    To hide a provider in the people picker (leaving only ADFS in this case), it is trivial :

    $cpm = Get-SPClaimProviderManager
    $ad = get-spclaimprovider -identity “AD”
    $ad.IsVisible = $false
    $cpm.Update()

    lastly, you’ll want to implement name resolution if you use people picker with ADFS.
    for internal ADFS (LDAP) https://ldapcp.codeplex.com/
    for online ADFS (365) https://azurecp.codeplex.com/

    there’s an awesome post here if you want to write it yourselves: http://blogs.msdn.com/b/kaevans/archive/2013/05/26/fixing-people-picker-for-saml-claims-users-using-ldap.aspx

  6. The url from adfs is not working on my server “https://spt.***.local/adfs/ls/” . I have configured ADFS 2.0 (as I have SharePoint 2013) on the same server that we have SharePoint. And due to this the login url from the SharePoint site does not work.

  7. Mario Alvares says:

    Hi Nik – In your search crawl steps, you extend the web app to the (non-default) Intranet zone, enable Windows authentication on the Intranet zone, use the Intranet zone public URL for the search crawl, and configure server name mappings to fix search result URLs.

    However, this blog post from MS PFE Brian Pendergrass strongly advises to NOT crawl a non-default and to NOT use server name mappings for SharePoint content: http://blogs.msdn.com/b/sharepoint_strategery/archive/2014/07/08/problems-when-crawling-the-non-default-zone-explained.aspx

    He recommends one of 2 approaches in his blog post:
    A) Configure search crawl on the the Default zone using Windows Authentication and configure the extended zone to use your custom claims provider OR
    B) Enable BOTH Windows and claims authentication on the Default zone, crawl the Default zone, and enable a custom login form as described here: http://blogs.msdn.com/b/russmax/archive/2014/10/31/bypassing-multiple-authentication-providers-in-sharepoint-2013.aspx

    However, with approach A, based on what I’ve read, it sounds like there are issues with administrative emails (such as alerts) being sent with links to the Default zone (instead of links to the extended zone). Immanuel Issaly hinted at this in 1-Jul-2015 comment on this post. He also mentioned potential issues with WAC (Office Web Apps), but I’m not sure what specific WAC issues he was referring to.

    With approach B – There seem to be 2 issues:
    1) Since both Windows auth and SAML auth are enabled on the web app, the People Picker will resolve names from both AD as well as the custom claims provider (We don’t want names from AD to resolve, otherwise we’ll see duplicates in the People Picker) . I think this issue can be resolved by using the PowerShell code Emmanuel provided in his 9-Jul-2015 comment on this post
    2) Setting “/_trust/Default.aspx” as a custom sign-in page in the web app settings seems easy enough. However, in the same blog post by Brian Pendergrass linked to above, he states the following:
    “Avoid using “/_trust/default.aspx?trust=name-of-your-trusted-identity-provider” as the Custom Sign in Page as this will break Office integration and users will not be redirected properly for authentication when opening client application”
    Immanuel – If you’re still reading this, I wonder if you faced any of the MS Office client issues alluded to by Brian when setting the custom sign in page for the web app to “/_trust/Default.aspx”

    Finally, I’m also using host-named site collections (HNSCs) in SharePoint 2013, and wondering if anything additional needs to be done to support search with SAML auth for HNSCs.

    Appreciate any feedback Nik, Immanuel or any one else may have. Thanks !

    Twitter: @marioal

    • Nik Patel says:

      Mario, I think you have hit the points what I came across too. I had opted for option 2 first but didn’t wanted to create custom login form. As far as option 1, I had came across some issues which I don’t recall at this moment. I had configured this environment back in summer 2013 and there has been some innovations in this field especially what Emmanuel mentioned above. One thing I would say, regardless of whichever approach you take, you will require to modify search results from NTLM to SAML based. Even in my configuration, we ended up changing display templates to display office web apps URLs properly in preview mode. Thanks for posting such a insightful comment. This will definitely adds value to this post.

  8. Hello Mario. I have used option B in my current project, the fixes we had to do were :
    A) hide the AD provider in the people picker. Declare LDAP connexions in either LDAPCP or AZURECP (depending if you use ADFS or ACS)
    B) code a custom sign-in page to bypass the auth dropdown.
    So far, it’s working. You have a choice between having two zones or one, i think both will work. If you’re looking for native sharepoint thou, only the two zone approach will be supported.
    Finaly, don’t forget if your users are “online” (365), you can setup azure ad app proxy to give them transparent sso to your on premise apps. In that case, you’ll have integrated windows only, saving you the trouble of a custom provider 🙂

    • Nik Patel says:

      Thank you for these very valuable comments. I think this is going to far useful along with what I had posted. My goal was to post my deployment notes and these comments made it even richer.

    • Mario Alvares says:

      Thanks Emmanuel. We are currently on-prem only. Regarding the ‘custom sign-in page’ option – Did you just set the custom sign-in page to ‘/_trust/Default.aspx’ or did you have to use custom code for the sign-in page ? Do you know of pros / cons of one versus the other, and any issues with either of these options ? I’ve seen recommendations for custom code for the sign-in page (for example, https://spautomaticsignin.codeplex.com ), and I’m wondering why anyone would prefer to use custom code if just setting the custom sign-in page option on the web application page to ‘/_trust/Default.aspx’ works ?

  9. Nik Patel says:

    Hey Emmanuel and Mario, do you have blogs? I would love to link your learning from this blog. Having comments are absolutely helpful for readers but if you have end of end guidance like mine, it would be even more valuable. Keep up the great work. Based on your comments and given time, I may able to build out updated version of this guide for Windows Server 2012 R2 and new ADFS version.

  10. hi nik, i’m not blogging much, and it’s in french 🙂
    http://eissaly.blogspot.fr/

  11. Pingback: How To Install ADFS 2012 R2 For Office 365 - xandi's blog

Leave a Reply

Please log in using one of these methods to post your comment:

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