One of the areas that have worked within for quite some time is Security and more so Authentication for SharePoint. I truly believe that selecting and implementing the correct Authentication providers and approaches goes a long way to better adoption and security for end users.

One of the core platforms I am advocate of is Active Directory Federated Services (ADFS). Having worked with it before it even became the Product it is today, it has been nice to see it mature and advance in features and abilities.

Most recently I have been working on using ADFS as the federation gateway to other systems for authentication. What has become apparent to me is that ADFS plays really well with the Microsoft Stack, especially when it comes to SharePoint and its other platforms. As such it makes sense to use ADFS direct to SharePoint, and then use other federated platforms for the actual authentication. This means that for most organizations that may already have a federated platform that is probably not SharePoint ready, it can still be used with it passing through ADFS that is supported within SharePoint. I have worked with organizations where federation has been done using products like Site Minder, Ping Federate, Oracle and others direct to ADFS. The chain for authentication then looks like this:

SharePoint > ADFS > 3rd Party Federation Platform

SharePoint > ADFS > Active Directory


With these authentication flows, SharePoint in reality does not care where you came from, how you authenticated, simply needs to know that you have the claim that you mapped for permissions.

SharePoint is only concerned with the end user that is mapped and appears from ADFS. So when adding users in the people picker they are added using the following claim format:

i:05.t|{Trusted Identity Token Issuer Name}|{Selected Claim}

When a user is picked using the People Picker, this is how SharePoint is referencing me and allowing me access. Now to the dilemma, let’s say we want to use ADFS to SharePoint but then allow multiple Authentication options within ADFS but still allow the user to be seen as the same person.

Let’s explain this a little more first. As you know if we enable ADFS to SharePoint, then enable standard Windows NTLM through ADFS, along with a different Authentication provider like Site Minder, the end user is presented back to SharePoint as two different users. It is this way because the configuration for standard Windows NTLM over ADFS uses the “User Principal Name” (normally) or something else that is not in the same format as the unique identifier. Doing it this way, SharePoint sees me in the following format:

i:05.t|{Trusted Identity Token Issuer Name}|{User Principal Name}

e.g. i:05.t|ADFS|USER@DOMAIN

So in my example I have ADFS to SharePoint with regular Windows NTLM through ADFS, and then a Federated platform. They both output two different claims, as the requirement was to use the “sAMAccountName” as the name identifier claim. Showing the claims side by side, you can see why SharePoint sees me as two different users.

Windows NTLM over ADFS: i:05.t|ADFS|USER@DOMAIN

Federation over ADFS: i:05.t|ADFS|ACCOUNT

So the question is how do we fix this, so when I login with Windows NTLM credentials through ADFS or the other Federated Platform the claim is the same?
To fix this issue we need to not use the standard claim rules picker but write a custom rule. Out of the box when configuring Window NTLM over ADFS we would typically use the picker to set these values:

The above works perfect for Windows NTLM but for the other Federated platform it does match, so we have to choose which claim format we wish to use. The above is using Email Address and Security Groups, but could be using any number of attributes such as direct “User Principal Name (UPN)“.

For SharePoint to see me as a single user, we will make the Windows NTLM one return the same as the Federated platform which is configured for “sAMAccountName“. For this change we need to remove the above attributes and choose to create a new rule but choose the “Send Claims Using a Custom Rule“.

Next we need to add the custom rule, which is based on some very specific syntax. To learn about the syntax you read about this on TechNet and MSDN, by looking for ADFS Transformation rules.

https://technet.microsoft.com/en-us/library/ee913567.aspx

For our example we need to use the following:

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”, Issuer == “AD AUTHORITY”] => issue(store = “Active Directory”,
types = (“http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress”),
query = “sAMAccountName={0}; sAMAccountName;{1}”,
param = regexreplace(c.Value, “(?<domain>[^\\]+)\\(?<user>.+)”, “${user}”),
param = c.Value);

If we break this down, we are looking up the user who authenticated using “Windows Account Name”, then populating the “Email Address” claim (this should be changed to whatever the claim name and type are in SharePoint) with the “sAMAccountName“, using a regex to just end up with the account ID, and no domain. Now this can be cleaned up to remove extra pieces but for now we will just leave it like this.

Now with this configured and populating the same claim as the federated platform identically we can now test. The first test is adding the user from the People Picker (I am using a custom Claim Provider as well) which allows me to add the user in the following format:

i:05.t|ADFS|ACCOUNT

Now when we test login we can use either option, Windows NTLM through ADFS or a Federated Platform through ADFS and SharePoint will see me as a single user, so no duplicate user profiles or permissions needed.

Windows NTLM Forms over ADFS

3rd Party Federated Authentication through ADFS

SharePoint sees me as the following now:

Using my Claims Viewer Web Part, I can expand down and see all of the claims to ensure that each login matches what is needed.

Now that they are set the same I can now come in from any Federated Provider or Windows NTLM over ADFS and I am seen as the same user.