SharePoint: Windows user not equal to ADFS 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 (2010, 2013, 2016, 2019, -- doesn't matter) web application using Windows-Claims authentication: https://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 https://share.contoso.com web application to use that authentication type as well.
Note: In this article, I talk about "ADFS", but this applies to any "Trusted Provider" (SAML / WS-FED) authentication provider like SiteMinder, OKTA, PING, ForgeRock, etc.
You browse to the site and log in via ADFS and you're greeted with the Access Denied page:
"Sorry, this site hasn't been shared with you"
You then log out and log into the same site using your Windows Credentials, and you get the access you expect.
A Common Misconception:
As far as SharePoint is concerned, your Windows auth account and your ADFS auth account are completely separate users.
As such, your ADFS 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.
I don't blame you for expecting the ADFS account to have the same permissions as the Windows 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.
What to do?
There are a few options:
1. Re-permission all of your accounts separately so that the ADFS version of the user has the same access as the Windows version.
Note: This is by far the worst option, especially if you plan to allow users to continue using both auth methods. 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. This is pretty much unmanageable. 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://blogs.technet.microsoft.com/adamsorenson/2018/01/17/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, and has implications for all of your web applications and even some of your service applications, in particular, the User Profile Service App. User profiles are also aligned with an authentication provider. You can have Windows-auth profiles and Trusted Provider-auth profiles. There are a few problems you can run into if you have multiple profiles for the same user. Most commonly, it can result in Workflows failing with 401 - unauthorized.
See: /en-us/SharePoint/security-for-sharepoint-server/plan-for-app-authentication-in-sharepoint-server Excerpt: "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 Trusted Provider Auth, it's best to have separate User Profile Service Apps for each web app type.
3. Use Web Application Proxy (WAP) 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 Window 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 it's still using Windows auth by the time you get to SharePoint. References:
https://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/