SharePoint: Windows auth user not equal to SAML auth user
I’ve been over this concept with customers and support engineers so many times, that I’m not sure why I haven’t posted about it before.
My colleague Adam posted on this topic a while back, but I wanted to expand on that a bit.
The Setup:
Let’s say you have a SharePoint (2013, 2016, 2019, Subscription Edition — doesn’t matter) web application using Windows-Claims authentication: http://share.contoso.com
You’ve been using this for years, assigning permissions all over the sites.
You then decide to make the site available externally, so you configure Active Directory Federation Services (aka: ADFS or AD FS) and configure the http://share.contoso.com web application to use that authentication type as well.
Note: In this article, I use “ADFS” as the example, but this same concept applies to any “Trusted Provider” (SAML / WS-FED) authentication provider like SiteMinder, OKTA, PING, ForgeRock, Azure AD, etc. I may use the terms “ADFS”, “SAML” and “Trusted Provider” interchangeably.
You browse to the site and log in via your Trusted Provider (for example ADFS) and you’re greeted with the Access Denied page:
“Sorry, this site hasn’t been shared with you”
Or maybe you can access the site, but you don’t have the same permissions as when you log in using your Windows auth account. You then log out and log into the same site using your Windows auth credentials, and you get the access you expect.
A Common Misconception:
As far as SharePoint is concerned, your Windows auth account and your ADFS / SAML auth account are completely separate users.
As such, your ADFS / SAML auth account must be permissioned separately. It has none of the access that your Windows auth account has, and there is no way to “link” the two.
IMPORTANT! This concept does not just apply to a Windows auth / SAML auth scenario. It applies to any situation where the account name you’re using to authenticate has changed. For example, you would have the same problem if you were using email address as your SAML auth identity claim, and then changed it to UPN. That would result in a different account name, which would be treated as a different user within SharePoint. Example:
i:05.t|adfs|user1@contoso.com != i:0e.t|adfs|user1@contoso.com
Likewise, if you change the name of the trusted provider, the account name will change and SharePoint will not see those accounts as the same identity. Example:
i:05.t|adfs|user1@contoso.com != i:05.t|Azure AD|user1@contoso.com
I don’t blame you for expecting the ADFS / SAML account to have the same permissions as the Windows auth account. After all, they both come from the same user object in Active Directory. However, SharePoint doesn’t actually know that you’re using Active Directory or ADFS. All SharePoint knows is that you’re using “Trusted Provider” authentication and it received a SAML token that was signed by a trusted certificate. That SAML token could be from ADFS with an Active Directory back-end, or it could be from Ping Federate with a SUN LDAP back-end, or anything in between.
If you look at the account names used in each case, it should become clear:
As you can see, the account names are different. As far as SharePoint is concerned, they’re as different as “Bob” and “Jeff”, and will never “share” permissions.
SharePoint Auth Rule 0:
Allowing the same set of users to access a given SharePoint web application using more than one authentication method is not a good plan. You will have problems. The only time it works to have both Trusted Provider and Windows authentication enabled on a web application is when they represent different user bases. For example: your internal corporate users use Windows auth and a partner company uses Trusted Provider / SAML auth.
What to do?
There are a few options:
1. Re-permission all of your accounts separately so that the ADFS / SAML auth version of the user has the same access as the Windows auth version.
This is by far the worst option, especially if you plan to allow users to continue using both authentication methods — you’re breaking “Auth Rule 0” above. There’s nothing to “link” the accounts or keep their permissions in sync. Not to mention, ‘person or group’ list columns (like “Modified By”) will show different user accounts depending on how the user authenticated.
Also, this will result in users having “duplicate” user profiles in the User Profile Service Application (UPA). The profiles will have different account names, but will have the same email address and UPN. That situation will cause OAuth claims augmentation scenarios to fail because as part of the claims augmentation process, it looks up your profile in the UPA using email address and UPN. It needs to find one profile, and only one profile. If it finds more than one, it fails with an error like this:
Error trying to search in the UPA. The exception message is ‘Microsoft.Office.Server.UserProfiles.DuplicateEntryException: GetUserProfileByPropertyValue: Multiple User Profiles found with propertyName ‘SPS-UserPrincipalName’ of specified value
The set of claims could not be mapped to a single user identity. Exception GetUserProfileByPropertyValue: Multiple User Profiles found with propertyName ‘SPS-UserPrincipalName’ of specified value has occured.There are several built-in functionalities that rely on OAuth. The most widely used are 2013-platform workflows, and working with Office documents in the browser using Office Web Apps / Office Online Server.
This is pretty much unmanageable from a permission perspective, and will break claims augmentation scenarios. I only mention it first to get it out of the way.
2. Use one authentication method or the other, not both.
You would want to migrate all of your Windows accounts to their respective ADFS accounts within SharePoint. There are a few different ways to do this including the Convert-SPWebApplication command, and Move-SPuser. See this post from my colleague Adam, where he walks through it: https://adamsorenson.com/sharepoint-20132016-migrate-from-windows-claims-to-adfs/
If you decide to go the Convert-SPWebApplication route, see this KB article I wrote a while back: https://support.microsoft.com/en-us/help/3042604/
IMPORTANT! Please keep in mind that migrating accounts in SharePoint using Move-SPUser or $farm.MigrateUserAccount is a farm-wide operation. It will migrate that user in all of your web applications.
Migration even has implications for some of your service applications, in particular, the User Profile Service App (UPA). User profiles are also aligned with an authentication provider. You can have Windows-auth profiles and Trusted Provider-auth profiles, but the same user should not have both in a single UPA. As described in #1 above, OAuth claims augmentation scenarios will break if you have multiple profiles for the same user. The most common “symptom” of this “duplicate profile” problem is 2013-platform workflows failing with 401 – unauthorized.
See: https://docs.microsoft.com/en-us/SharePoint/security-for-sharepoint-server/plan-for-app-authentication-in-sharepoint-server This is the important part: “Furthermore, SharePoint Server expects only one entry in the User Profile service application for a given lookup query that is based on one or more of these four attributes. Otherwise, it returns an error condition that multiple user profiles were found. Therefore, you should delete obsolete user profiles in the User Profile service application periodically to avoid multiple user profiles.”
Therefore, if you’re going to run your farm in a “mixed mode”, with some web apps using Windows Auth and some using ADFS / SAML Auth, it’s best to have separate User Profile Service Applications for each web app type.
3. Use Web Application Proxy (WAP) or Azure AD Application Proxy to separate the ADFS authentication piece from SharePoint.
The idea here is that you use ADFS to authenticate to WAP, which then translates you into a Windows auth token, and passes that on to SharePoint. This is kind of “the best of both worlds”. You can use it to enable external access to SharePoint and authenticate via ADFS, yet you don’t have to migrate any of your users within SharePoint because you’re still using Windows auth by the time you get to SharePoint. You only have one user record at the site level and one profile in the UPA, which is the ideal scenario.
References:
http://www.sharepoint4developers.net/en-nz/post/wap-adfs-sp2013-kerberos.aspx
https://blogs.msdn.microsoft.com/sambetts/2017/04/04/sharepoint-web-application-proxy-2016-edition/