ADFS & SharePoint 2013

Image Title

posted by Phi-lac Nguyen
on Jun 15, 2015

NIFTIT worked on multiple projects to implement Single Sign On on SharePoint 2013 with such solutions as OneLogin, Ping Identity (external solution), and ADFS on-premises. The main goal was simple: To improve the user’s experience with SharePoint Web applications. To achieve this, we wanted to give users the freedom to navigate between SharePoint Web applications without the distraction of having to login with each application jump.

While the idea seems simple enough, the actual implementation was anything but. Here is an explanation of the process and some of the major fixes tackled.

1) ADFS and ADFS proxy

You need at least two servers to provide SSO (Microsoft best practice) from internal and external networks. The ADFS proxy is not a domain joined and should be located in the DMZ; this way, the ADFS in the LAN is not exposed to the internet. Only SSL can be allowed on the ADFS proxy server (default port 443).

It is best to use the ADFS version 3.0 (Windows 2012 R2 has ADFS 3.0) because SharePoint Application is generating a random ID like apps-random as URL. With ADFS 3.0 you can add https://*
Three certificates are required:

  • ADFS portal for the Sign-In Page
  • Token-decrypting
  • Token-signing

The certificate for the token-signing has to be exported on the SharePoint Server and will be configured through PowerShell for the Trusted Identity Provider.

2) SharePoint

NIFTIT followed this link to create the trusted identity provider. Once the Identity Provider is configured, the new UPS has to be configured for the new Trusted Claims Provider as well. The UPS connection is important because the Claims Provider Identifier has to be defined for the property mapping. Usually for SSO, the email attribute is used for the authentication.


One unexpected side effect is that each claim mapped has an entry.


To avoid this situation, NIFTIT used LDAPCP Solution and then associated LDAPCP with the Trusted Claims Provider. Once that is done, the ADFS identities are properly resolved within SharePoint using SAML claims authentication.


Here is a link explaining how to install and deploy LDAPCP.

LDAPCP has a notable limitation, which is that it can be associated with more than one SPTrustedIdentityTokenIssuer. This required us to use only one trust party with many configured endpoints. Using many endpoints will cause another unexpected issue to arise: The default endpoint is used every time.


Hopefully, a PowerShell exists to use the wreply parameter and fix the issue.


3) Rewrite URL: HTTP to HTTPS

The following request was made of the NIFTIT team: “Can you add a rewrite rule on IIS? This way if the users forget to use HTTPS protocol it will work.”

ADFS required SSL; if HTTP protocol was used, a permission error appeared after authentication. We tried two methods for the URL rewrite on IIS:

  • Edit and add the rewrite rule into the web.config
  • Use the UI from IIS

We realized that the sign-in page was coming before the rewrite rule from IIS. The URL of the sign-in page should contain https after login.


We managed the rewrite URL by modifying the onload.js from the theme of the portal page. Here is the link from Microsoft to customize the onload.js, as well as how to customize the ADFS portal. Alternatively, one could remove the binding on port 80; if the user is trying to gain access through HTTP, they will be met with “page not found”.


Need help with SharePoint? We’re here to help.