Thanks for visiting.

I've decided to move all of this content to my own site: https://joshroark.com/

All the posts you see here should also be available there. I'll keep this site on Technet available for a while until the migration is complete.

First off, non-imported profiles are well… not imported. They were not created by Profile Sync / AD Import / Sync with External Identity Manager. We also refer to these as "unmanaged", or "stub" profiles because they typically only contain the minimum amount of user data -- usually just the users account name.

Note: in this article, I will use the terms profile import / profile sync interchangeably. For our purposes here, it does not matter whether AD Import or FIM Sync is used to get profiles into SharePoint.

Where do they come from?

There are a few ways to create user profiles that are "unmanaged". I will list them here from most common to least:

1. Users just browsing to their profile page or mysite. If a user tries to access any user profile-related pages, and they don't already have a user profile in the UPA, one will be created for them automatically. This will be a "stub" profile with a limited set of data for the user.
2. From a different farm or different UPA. You example, maybe you had profiles imported in a SharePoint 2013 farm. If you then migrate that UPA to a 2016 farm, but you don't select all the same OUs / containers that you had in the 2013 farm, all of the users that live in the containers you missed will become "unmanaged profiles".
3. Created programmatically. You can use PowerShell or object model code to create user profiles. Unless you are also filling in additional data at creation time, these will be "stub"-looking profiles as well.
4. By a 3rd party. This is really just a variation of #3, but 3rd party solutions (Newsgator comes to mind in particular) can create profiles programmatically.

What's the harm?

There's not much really. The main ticket generator that we see is that someone will notice that a certain users profile shows up in people search results, or in the organization chart, or somewhere else unexpectedly. They may be considered "unexpected" for one of several reasons:

• They are not in an OU selected for import / sync.
• They are deleted or disabled in Active Directory.
• They should be subject to an import / sync connection filter.

A second scenario we see is that a profile that belongs to a valid user will not be getting any updates from Active Directory. For example, their title changes in AD, but stays the same in their user profile. This will happen if their profile is "unmanaged". Since it's not being Synched, it won't get any updates from AD.

What to do?

Depends on what your goal is for these profiles. You're typically going to have one of these two objectives:

I -- Turn them into managed profiles so profile import / sync can update and maintain them.

If you intended these user profiles to be imported, but they weren't (and therefore were created as "stub" profiles) then you need to start by determining why they were not imported We also refer to this condition as being "out of scope" for the import. There are only a few reasons:

1. They are in an OU that is not included in the import connection. No really, go double-check the distinguished name of the user in question, and compare against the OUs selected in your import connection. -- I've seen too many assumptions on where the user currently exists in AD and what the connection should be importing.

   Seriously, don't assume, go check. You can use the following PowerShell to look up a given user and output their Distinguished Name (DN):

   $accountName = "josh"

   $prop = ([adsisearcher]"samAccountName=$($accountName)").FindOne().Properties

   $prop.displayname

   $prop.distinguishedname

    

   The output will look something like this:

   Josh Roark

   CN=Josh Roark,OU=Admins,OU=MyUsers,DC=joroar,DC=local

    

   The part of the DN starting with "OU" indicates the container this user exists in. You need to select that container ("Admins"). Selecting its parent container ("MyUsers") by default, will also select any child containers and will also result in the user being imported.

   

2. They are subject to an import connection filter. This is one place where there is a significant difference between FIM Sync and AD import. The filtering is done entirely differently. AD Import uses a standard LDAP filter, so you can use tools like LDP.exe or LDAP Explorer to verify whether or not the filter in place should return the user. With FIM Sync, exclusion filters are used, so it's a matter of understanding the filters and checking against the AD attribute values for the user.

    

3. This is rare, but there is a known issue where if the LastKnownParent attribute is set on the user in Active Directory, it could result in the user not being imported. Read more here: https://support.microsoft.com/en-us/help/313301

Note: It is not necessary to delete these "stub" profiles first. If a profile was first created as a "stub" / "unmanaged" / "non-imported" profile, but then later profile import / sync pulls that user in, the existing profile will be updated by the sync, and will become a "managed" profile from that point forward.

II -- Remove them.

If you don't want these profiles around, then you need to take some action to get rid of them.

Number one, you should not be looking to profile import / sync to fix this for you. Remember, these profiles were not imported, so the profile sync process does not manage them at all. In general, if profile sync did not create the profile, it can't delete it either.

Get a list of non-imported profiles. This is rather easy. Just run PowerShell like this:

$upa = Get-spserviceapplication | ?{$_.typename -match "profile"}

Set-SPProfileServiceApplication $upa -GetNonImportedObjects $true | out-file c:\temp\NonImportedProfiles.txt

Then go have a look at the NonImportedProfiles.txt file.

The GetNonImportedObjects flag will only return unmanaged / "stub" profiles. If a user account is in this list, it means they were most certainly not imported, so if there's any question as to whether or not a certain user has been imported by AD Import / Sync, these results should be definitive.

If the contents of NonImportedProfiles.txt looks like the list of user profiles you'd like to remove, then you can run this:

$upa = Get-spserviceapplication | ?{$_.typename -match "profile"}

Set-SPProfileServiceApplication $upa -PurgeNonImportedObjects $true

Please note that this is all or nothing. The PurgeNonImportedObjects command will mark all of the profiles for deletion that GetNonImportedObjects returned. If there are legitimate user profiles returned by GetNonImportedObjects, then you should see the "Turn them into managed profiles…" section above for ideas on how to get them imported.

PurgeNonImportedObjects does not immediately delete the non-imported profiles. It just marks them for deletion (bdeleted = 1 in the UserProfile_Full table of the Profile database). Once they have been marked for deletion, it is the responsibility of the "My Site Cleanup Job" timer job to remove them, which is no different for "managed" profiles that have been marked for deletion by profile import / sync.

Consider the following scenario:

• You have two Trusted Providers (SAML auth) and are using them both for the same web application.
  • For example, you have an Internal zone using URL https://teamsInternal.contoso.com that uses Trusted Provider "ADFS-Internal"
  • And an External zone using URL https://teams.contoso.com, and Trusted Provider "ADFS-External"
• You create both Trusted Identity Token Issuers using the same token signing certificate, creating the "ADFS-External" one first.
• When internal users browse to the site, they are authenticated, but receive the "Sorry, this site has not been shared with you" Access Denied page.
• In reviewing the ULS logs and /or a Fiddler trace, you see that the Internal user is indeed authenticated, but is authenticated as an External user, which does not have permission to the site, thus the "access denied".

Notes:

• I cannot come up with a practical scenario for using two separate providers instead of handling both user types with one trusted provider, but it has happened. More than once.
• Please forgive the references to SharePoint 2010 and ADFS 2.0 in the above link. The steps are still valid for the most recent version of both.
• I'll use "ADFS" as my Trusted Provider example, but the same rules apply to all SAML providers (SiteMinder, Ping Federate, Okta, etc).

That's weird, why does that happen?

Both the Internal ("ADFS-Internal") and External ("ADFS-External") Trusted Identity Token Issuers have been configured to use the same token signing certificate.

Because SharePoint uses the certificate it receives from ADFS to match the Trusted Identity Token Issuer within SharePoint, it will match that certificate to only the first Trusted Identity Token Issuer in the list that uses that same certificate.

In this case, the result is that it will always match the certificate to the "ADFS-External" Token Issuer because it was the first one created, and appears first in the list.

The result is that every user will be authenticated as an External user, even when accessing the site using the Internal URL.

You're saying the user is Authenticated. Why do they get Access Denied?

Most of this goes back to the concept of Authentication (who are you) vs Authorization (what permission do you have).

However, in SharePoint, I find it's even more easily confused because the same physical person can authenticate to SharePoint as multiple different "users".

Continuing with my example above, the same person can authenticate using the External URL with the "ADFS-External" trusted provider, and with the Internal URL with the "ADFS-Internal" trusted provider. SharePoint sees those two users as completely separate. Knowing that SharePoint uses the name of the Trusted Provider as part of the users account name, it should become clear why:

i:0e.t|adfs-internal|josh@joroar.local is not the same user as i:0e.t|adfs-external|josh@joroar.local

Those two user accounts will always be treated by SharePoint as separate. There's no way to "merge" their permission sets, or anything of the like.

This concept is really just a variation on one I blogged about previously: https://joshroark.com/sharepoint-windows-user-not-equal-to-adfs-user/

How can I tell if I have this issue?

You should be able to run the following PowerShell to check which certificate each Trusted Identity Token Issuer is using:

Get-SPTrustedIdentityTokenIssuer | select name, signingcertificate | fl

Check the "Thumbprint" value on the SigningCertificate for both Token Issuers. If it's the same value, it's the same certificate.

What can be done?

If you're set on using two different Trusted Providers within the same web application, then one of them must use a different token signing certificate. How you do that on the SAML provider side varies by implementation (ADFS, SiteMinder, Ping, OKTA, etc), so I won't get into that here.

However, once you have a new token-signing certificate, updating SharePoint to match is quite simple. It's the same steps you would use when your token signing certificate expires and you need to update SharePoint to use a new one.

The example below assumes I got a new certificate for the "Internal" trusted provider, and I'm leaving the External one alone.

-- Update the Internal Token Issuer to use the new certificate using PowerShell:

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\newInternalCert.cer")

$ti = Get-SPTrustedIdentityTokenIssuer "ADFS-Internal"

Set-SPTrustedIdentityTokenIssuer $ti -ImportTrustCertificate $cert

-- Add the new certificate to the farm trust (Central Admin | Security | Manage Trust).

-- Make sure it's trusted at the Windows level by importing it (and any parent certificates in the cert chain) to the Trusted Root Authorities certificate store on the SharePoint servers.

This was a special situation where most of the site appeared to work, but certain links under Site Settings would fail with 403 Forbidden. For example:

• Themes
• Master Pages
• Solutions
• Composed looks
• List Templates
• Most document libraries

Actually, in some cases, the page request would result in Access Denied, and redirect the user to the Access Denied page (_layouts/15/AccessDenied.aspx), and that request would fail with 403 Forbidden.

This would occur for users with full control permission on the site, even site collection administrators.

Cause:

This turned out to be a configuration problem with Host-Named Site Collections (HNSC).

Due to a host header / IIS binding configuration issue, the request was actually being served by a different SharePoint web app / IIS site than the one we expected. That other IIS site was running in a different application pool, which was running as a different service account. That service account did not have enough permission to the SharePoint content to access the site. In that case, most requests were working, but any request that called into the "SPSecurity.RunWithElevatedPrivileges" method would fail because "RunWithElevatedPrivileges" runs as the application pool account instead of the logged-on user.

Resolution:

Configure your Web Apps and IIS bindings properly for HNSCs.

Typically, host-named site collections do not use host header bindings in IIS as described here: https://docs.microsoft.com/en-us/SharePoint/administration/host-named-site-collection-architecture-and-deployment#use-host-headers-and-host-named-site-collections

Host-named site collections should ideally all be hosted under the same SharePoint web application, in which case, host header bindings in IIS are unnecessary.  Or if there are multiple HNSC web apps, they all should run as the same service account, which would also avoid this problem.

Here's a sample of the error sequence seen in the SharePoint ULS logs.

The giveaway is that every access denied stack contains a call to SPSecurity.RunWithElevatedPrivileges:

10/29/2018 10:16:01.47    w3wp.exe (0x51F4)    0x41D0    SharePoint Foundation    Authentication Authorization    ajmmv    VerboseEx    VsecurableObject: EffectiveRightsMask=0x00000000, OriginalEffectiveRightsMask=0x00000000    922c9d9e-f771-9026-a024-8163eefb3d05

10/29/2018 10:16:01.47    w3wp.exe (0x51F4)    0x41D0    SharePoint Foundation    General    8xfr    Verbose    PermissionMask check failed. asking for 0x08000000, have 0x00000000    922c9d9e-f771-9026-a024-8163eefb3d05

10/29/2018 10:16:01.47    w3wp.exe (0x51F4)    0x41D0    SharePoint Foundation    General    8e2s    Medium    Unknown SPRequest error occurred. More information: 0x80070005    922c9d9e-f771-9026-a024-8163eefb3d05

10/29/2018 10:16:01.47    w3wp.exe (0x51F4)    0x41D0    SharePoint Foundation    General    aix9j    High    SPRequest.GetUsersDataAsSafeArray: UserPrincipalName=, AppPrincipalName= ,bstrUrl=https://teams.contoso.com ,dwUsersScope=5 ,dwUserCollectionFlags=0 ,bstrValue= ,dwValue=1073741823    922c9d9e-f771-9026-a024-8163eefb3d05

10/29/2018 10:16:01.47    w3wp.exe (0x51F4)    0x41D0    SharePoint Foundation    General    ai1wu    Medium    System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)), StackTrace:

at Microsoft.SharePoint.SPUser.InitMember()

at Microsoft.SharePoint.SPUser..ctor(SPWeb web, SPSecurableObject scope, String strIdentifier, Object[,] arrUsersData, UInt32 index, Int32 iByParamId, String strByParamSID, String strByParamEmail, SPUserCollectionType userCollectionType, SPUserCollectionFlags ucf, Boolean isSiteAuditor)

at Microsoft.SharePoint.SPUserCollection.GetByIDNoThrow(Int32 id)

at SharePointBoost.SharePoint.Security.SecurityUtility. . ()

at Microsoft.SharePoint.SPSecurity.<>c__DisplayClass5.<RunWithElevatedPrivileges>b__3()

at Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess(CodeToRunElevated secureCode)

at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(WaitCallback secureCode, Object param)

at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(CodeToRunElevated secureCode)

<stack truncated>

10/29/2018 10:16:01.47    w3wp.exe (0x51F4)    0x41D0    SharePoint Foundation    General    aep94    High    UnauthorizedAccessException for the request. 403 Forbidden will be returned. Error=Exception of type 'System.Web.HttpUnhandledException' was thrown.

at System.Web.UI.Page.HandleError(Exception e)

at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

at System.Web.UI.Page.ProcessRequest()

at System.Web.UI.Page.ProcessRequest(HttpContext context)

at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

10/29/2018 10:16:01.47    w3wp.exe (0x51F4)    0x41D0    SharePoint Foundation    General    b6p2    VerboseEx    Sending HTTP response 403 - text/plain:403 FORBIDDEN.    922c9d9e-f771-9026-a024-8163eefb3d05

• I'll be talking about Active Directory Federation Service (ADFS), but the same concepts apply to other SAML auth providers like SiteMinder, Ping Federate, etc.
• "Check Permissions" is not the only function that utilizes the External Token to determine user permissions.  Pretty much any non-interactive function in SharePoint that must determine a users permission will use the External Token.  Examples:
  • Alerts
  • Workflow
  • SQL Server Reporting Services (SSRS) report subscriptions.

First some background:

How is Trusted Provider / SAML / ADFS auth different?

Prerequisites:

Check which claims you're passing:

Get-SPTrustedIdentityTokenIssuer |select claimtypeinformation -ExpandProperty claimtypeinformation

Do I have a Custom Claims Provider?

Get-SPTrustedIdentityTokenIssuer | select name, claimprovidername

Troubleshooting:

Troubleshooting Check Permissions with LDAPCP:

1. Make sure you're adding your groups (role claims) to site permissions correctly.

2. Enable Augmentation in LDAPCP

3. Upgrade .NET.

• .NET Framework 4.6 is supported for SharePoint 2013 as long as you have SP1 installed.
• You can check which version of .NET Framework you have installed using steps here.
• It's important that you upgrade .NET on every SharePoint server in the farm.

4. Upgrade LDAPCP.

5. Check other known-issues.

Consider the following scenario:

You break permission inheritance on a list and give some users permission to only that list.

The users can browse to the list, but when they try to add an item to the list or edit an existing item, the following error occurs:

The server was unable to save the form at this time. Please try again

Cause:

This happens if the "UseRemoteAPIs" permission is removed from the "Limited Access" permission level.

"UseRemoteAPIs" is required to add and edit items in SharePoint 2013 and 2016 because a Client-Side Object Model (CSOM) call is made to complete the update.

The "UseRemoteAPIs" permission can be either removed manually, or by activating the "Limited-access user permission lockdown mode" (ViewFormPagesLockDown) site collection feature.

Note: Sites created using the "Publishing Portal" site template will have this feature activated by default.

This feature removes the ViewFormPages and UseRemoteAPIs permissions from the "Limited Access" permission level, in which case, "Limited Access" will only contain these permissions:

Open, BrowseUserInfo, UseClientIntegration

Turning off the feature results in an update to the Limited Access permission level to match an out-of-box Team site:

Open, BrowseUserInfo, UseClientIntegration, UseRemoteAPIs, ViewFormPages

You can use this PowerShell to check the Limited Access permission level on the problem site:

$siteCollectionUrl = Get-SPWeb -Identity "https://team.contoso.com"

$lmtd = $siteCollectionUrl.RoleDefinitions['Limited Access']

$lmtd.BasePermissions

Resolution:

Deactivate the "Limited-access user permission lockdown mode" site collection feature.

This can be done in Site Settings | Site Collection Features, or by using PowerShell like this:

Disable-SPFeature -URL "https://team.contoso.com" -Identity ViewFormPagesLockDown

If the feature is already disabled, then you could try toggling it, or simply use the following PowerShell to manually add the proper permissions back to the "Limited Access" permission level:

$siteCollectionUrl = Get-SPWeb -Identity "https://team.contoso.com"

$lmtd = $siteCollectionUrl.RoleDefinitions['Limited Access']

$b1 = [Microsoft.sharepoint.spbasepermissions]::ViewFormPages

$b2 = [Microsoft.sharepoint.spbasepermissions]::Open

$b3 = [Microsoft.sharepoint.spbasepermissions]::BrowseUserInfo

$b4 = [Microsoft.sharepoint.spbasepermissions]::UseClientIntegration

$b5 = [Microsoft.sharepoint.spbasepermissions]::UseRemoteAPIs

$lmtd.BasePermissions = "$b1,$b2,$b3,$b4,$b5"

$lmtd.Update()

Data Capture:

This is what you'd see in a Fiddler trace:

Client Request: (POST:https://team.contoso.com/_vti_bin/client.svc/ProcessQuery)

Server Response:

[

{

"SchemaVersion":"15.0.0.0","LibraryVersion":"15.0.4905.1000","ErrorInfo":{

"ErrorMessage":"Access denied. You do not have permission to perform this action or access this resource.","ErrorValue":null,"TraceCorrelationId":" f682929e-089c-0012-0b83-1d144a5deb75","ErrorCode":-2147024891,"ErrorTypeName":"System.UnauthorizedAccessException"

},"TraceCorrelationId":"f682929e-089c-0012-0b83-1d144a5deb75"

}

]

And this is what you'd see in the SharePoint ULS logs:

09/26/2018 08:12:39.10 w3wp.exe (0x29F0) 0x0868 SharePoint Foundation CSOM ajwqj Medium Request does not have SPBasePermissions.UseRemoteAPIs permission. Need to check it when each API is accessed f682929e-089c-0012-0b83-1d144a5deb75

09/26/2018 08:12:39.10 w3wp.exe (0x29F0) 0x0868 SharePoint Foundation CSOM ajwqh High The request does not have required permission to access SP.RequestContext.Current f682929e-089c-0012-0b83-1d144a5deb75

09/26/2018 08:12:39.10 w3wp.exe (0x29F0) 0x0868 SharePoint Foundation CSOM ahjq1 High Exception occured in scope Microsoft.SharePoint.SPContext.get_Current. Exception=System.UnauthorizedAccessException: Attempted to perform an unauthorized operation. at Microsoft.SharePoint.Client.ServerStub.CheckRequiredResourceRight(ProxyContext proxyContext, String memberName, ResourceRight right) at Microsoft.SharePoint.Client.ServerStub.CheckBlockedGetProperty(String propName, ProxyContext proxyContext) at Microsoft.SharePoint.ServerStub.SPContextServerStub.GetStaticProperty(String propName, ProxyContext proxyContext) at Microsoft.SharePoint.Client.ServerStub.GetStaticPropertyWithMonitoredScope(String propertyName, ProxyContext proxyContext) f682929e-089c-0012-0b83-1d144a5deb75

09/26/2018 08:12:39.10 w3wp.exe (0x29F0) 0x0868 SharePoint Foundation CSOM agmjp High Original error: System.UnauthorizedAccessException: Attempted to perform an unauthorized operation. at Microsoft.SharePoint.Client.ServerStub.CheckRequiredResourceRight(ProxyContext proxyContext, String memberName, ResourceRight right) at Microsoft.SharePoint.Client.ServerStub.CheckBlockedGetProperty(String propName, ProxyContext proxyContext) at Microsoft.SharePoint.ServerStub.SPContextServerStub.GetStaticProperty(String propName, ProxyContext proxyContext) at Microsoft.SharePoint.Client.ServerStub.GetStaticPropertyWithMonitoredScope(String propertyName, ProxyContext proxyContext) f682929e-089c-0012-0b83-1d144a5deb75

09/26/2018 08:12:39.10 w3wp.exe (0x29F0) 0x0868 SharePoint Portal Server Microfeeds aizmo Medium SocialRESTExceptionProcessingHandler.DoServerExceptionProcessing - SharePoint Server Exception [System.UnauthorizedAccessException: Attempted to perform an unauthorized operation. at Microsoft.SharePoint.Client.ServerStub.CheckRequiredResourceRight(ProxyContext proxyContext, String memberName, ResourceRight right) at Microsoft.SharePoint.Client.ServerStub.CheckBlockedGetProperty(String propName, ProxyContext proxyContext) at Microsoft.SharePoint.ServerStub.SPContextServerStub.GetStaticProperty(String propName, ProxyContext proxyContext) at Microsoft.SharePoint.Client.ServerStub.GetStaticPropertyWithMonitoredScope(String propertyName, ProxyContext proxyContext)] f682929e-089c-0012-0b83-1d144a5deb75

09/26/2018 08:12:39.10 w3wp.exe (0x29F0) 0x0868 SharePoint Foundation Authentication Authorization alkvd Medium Throw UnauthorizedAccessException instead of SPUtilityInternal.Send401 for client.svc request. f682929e-089c-0012-0b83-1d144a5deb75

09/26/2018 08:12:39.10 w3wp.exe (0x29F0) 0x0868 SharePoint Foundation CSOM agmjp High Original error: System.UnauthorizedAccessException: Attempted to perform an unauthorized operation. at Microsoft.SharePoint.Client.ServerStub.CheckRequiredResourceRight(ProxyContext proxyContext, String memberName, ResourceRight right) at Microsoft.SharePoint.Client.ServerStub.CheckBlockedGetProperty(String propName, ProxyContext proxyContext) at Microsoft.SharePoint.ServerStub.SPContextServerStub.GetStaticProperty(String propName, ProxyContext proxyContext) at Microsoft.SharePoint.Client.ServerStub.GetStaticPropertyWithMonitoredScope(String propertyName, ProxyContext proxyContext) at Microsoft.SharePoint.Client.ClientMethodsProcessor.InvokeStaticGetProperty(String typeId, String propName) at Microsoft.SharePoint.Client.ClientMethodsProcessor.GetObjectFromObjectPath(XmlElement xe) at Microsoft.SharePoint.Client.ClientMethodsProcessor.GetObjectFromObjectPathId(String objectPathId) at Microsoft.SharePoint.Client.ClientMethodsProcessor.ProcessInstantiateObjectPath(XmlElement xe) at Microsoft.SharePoint.Client.ClientMethodsProcessor.ProcessOne(XmlElement xe) at Microsoft.SharePoint.Client.ClientMethodsProcessor.ProcessStatements(XmlNode xe) at Microsoft.SharePoint.Client.ClientMethodsProcessor.Process() f682929e-089c-0012-0b83-1d144a5deb75

09/26/2018 08:12:39.10 w3wp.exe (0x29F0) 0x0868 SharePoint Portal Server Microfeeds aizmo Medium SocialRESTExceptionProcessingHandler.DoServerExceptionProcessing - SharePoint Server Exception [System.UnauthorizedAccessException: Attempted to perform an unauthorized operation. at Microsoft.SharePoint.Client.ServerStub.CheckRequiredResourceRight(ProxyContext proxyContext, String memberName, ResourceRight right) at Microsoft.SharePoint.Client.ServerStub.CheckBlockedGetProperty(String propName, ProxyContext proxyContext) at Microsoft.SharePoint.ServerStub.SPContextServerStub.GetStaticProperty(String propName, ProxyContext proxyContext) at Microsoft.SharePoint.Client.ServerStub.GetStaticPropertyWithMonitoredScope(String propertyName, ProxyContext proxyContext) at Microsoft.SharePoint.Client.ClientMethodsProcessor.InvokeStaticGetProperty(String typeId, String propName) at Microsoft.SharePoint.Client.ClientMethodsProcessor.GetObjectFromObjectPath(XmlElement xe) at Microsoft.SharePoint.Client.ClientMethodsProcessor.GetObjectFromObjectPathId(String objectPathId) at Microsoft.SharePoint.Client.ClientMethodsProcessor.ProcessInstantiateObjectPath(XmlElement xe) at Microsoft.SharePoint.Client.ClientMethodsProcessor.ProcessOne(XmlElement xe) at Microsoft.SharePoint.Client.ClientMethodsProcessor.ProcessStatements(XmlNode xe) at Microsoft.SharePoint.Client.ClientMethodsProcessor.Process()] f682929e-089c-0012-0b83-1d144a5deb75

Randomly, when a user browses to a resource (site, list, etc) that they are supposed to have access to, they receive "Sorry, this site hasn't been shared with you" (access denied).

The users continue to get Access Denied for a period of time, and then it starts working again after making no changes.

You check site permissions and the user appears to have the appropriate permission on the site.

Important: The user shows correct permission and automatically gets access again, which is in contrast to a similar behavior I wrote about here: https://blogs.technet.microsoft.com/spjr/2017/07/12/sharepoint-users-randomly-lose-permission-are-deleted-from-site/

Odd behavior… Why?

This issue occurs on Publishing sites where permission inheritance is broken, and the affected users have access only to a sub-site, and not the top-level site in the site collection.

It occurs when the built-in SharePoint group "Style Resource Readers" has been messed with in some way.

When a user browses to a sub-site within a Publishing site collection, the Master Page, CSS files, etc that are stored in the top-level site are used to render the sub-site page. Therefore, users at the sub-site level must have access to (at least) these items in the top-level site.

The "Style Resource Readers" group is used to give that limited permission to the required resources on the top-level site. These resources include the Master Page Gallery, Style Library, and Site Collection Images.

Fix: Verify Style Resource Readers group permissions and membership are intact:

Note: In this example, affected users have permission only at sub-site https://team.contoso.com/sites/TL/Stuff. They have no permission at top-level site https://team.contoso.com/sites/TL.

• Make sure the Style Resource Readers group is in place and has proper permission:
  • Browse to top-level site: https://team.contoso.com/sites/TL
  • Go to Site Settings | People and Groups.
  • There should be a group called "Style Resource Readers".
  • That group should contain "Everyone" and "NT AUTHORITY\authenticated users". If it doesn't, add those back.

   

• Make sure Style Resource Readers has proper permission to the Master Page Gallery.
  • Browse to top-level site: https://team.contoso.com/sites/TL
  • Go to Site Settings |Master Pages and Page Layouts | Library Settings | Permissions for this document library.
  • Verify that "Style Resource Readers" is listed there with "Read" permission. If it isn't, add it back.

   

• Make sure Style Resource Readers has proper permission to the Style Library.
  • Browse to top-level site: https://team.contoso.com/sites/TL
  • Go to Site Contents | Style Library | Library Settings | Permissions for this document library.
  • Verify that "Style Resource Readers" is listed there with "Restricted Read" permission. If it isn't, add it back.

     

     

Explanation of why this access denied behavior may be intermittent:  

• The affected users don't have any access to the top-level site in the site collection: https://team.contoso.com/sites/TL
• There are publishing controls at the sub-site level: https://team.contoso.com/sites/TL/Stuff that occasionally require access to items in the top-level site.
• These controls are cached, so the user does not need access to the top-level site on every request. – That's why it works sometimes.
• The application pool for the site recycles, usually sometime between 1am and 3am, local server time.
• These controls are no longer cached.  It now fails because the end-user doesn't have any permission to the top-level site.
• Then a user that does have permission to the top-level site logs in and the controls are cached again, making it work for all users.
• This continues to work until the app pool recycles again.

A few other "Style Resource Readers" references:

https://blogs.msdn.microsoft.com/joetalksmicrosoft/2017/06/28/do-not-delete-style-resource-readers-group/

https://brmorris.blogspot.com/2012/04/access-denied-editing-or-creating-pages.html

https://support.office.com/en-us/article/Default-SharePoint-groups-in-SharePoint-Server-50855943-C151-42BF-B6EA-07F2BB366ECC

You have a SharePoint 2013 or 2016 web application that has both Windows and Trusted Provider / SAML authentication (ADFS, etc) enabled.

You have a list with a "Person or Group"-type (aka: "people picker") column in it.

You edit the list using the "Quick Edit" / "edit this list" functionality to edit the list in a datasheet-style view.

You search for a user account in the Person or Group column and it resolves correctly:

You hit enter to go to the next row and you get an error on the first row that says: "The user does not exist or is not unique".

This seems very odd since you just, seconds before, successfully resolved that to a single user account.

Note: This may only occur for users not already added to the site collection. More on that later…

So why does this happen?

When you hit enter to go to the next row, the "Quick Edit" control tries to update the list item. It must re-resolve the user that you entered into the People Picker column.

It does so using the users email address. It calls into all available claims providers including Active Directory and your Trusted Provider, which both return results.

That's why we get the "The user does not exist or is not unique" error.  We did not get a single unique result.

Solutions:

This one does not have an ideal solution at the moment.

It only occurs when there are multiple authentication providers enabled on the web application, and only when using the "Quick Edit" control, so if you avoid either of those, you won't see the problem. That's more like "problem avoidance" than a "solution", but I do have a workaround.

Workaround: For the user account that fails to resolve, add them to any SharePoint group or "person or group"-type list column in the site. It doesn't have to be the same list, you can add them anywhere in the entire site collection, and then "Quick Edit" should be able to properly resolve them.

Here I'm just using the normal new item form to add my "Test 1" user to my list.

Not only does that work to add the user to the "person or group" column, after doing so, I'm also able to successfully add the same user using "Quick Edit":

Why this works: When the user already exists in the site collection, the "Quick Edit" control still re-resolves the user and gets multiple matches, but it then uses those results to match to the User Information List for the site collection and resolve it to a single unique user account. So all you have to do is use the normal (non-quick edit) new item or edit item forms to add the user to any person or group column. After doing that once, you then should be able to add that same user using the "Quick Edit" view on the same list or any other list in the site collection.

Technical details:

Note: While I've seen this happen in both SharePoint 2013 and 2016, all my testing was done on SharePoint 2016 at build 16.0.4639.1002.

In your SharePoint ULS logs, you'll see something like this:

08/14/2018 09:28:46.95 w3wp.exe (0x18E8) 0x2E70 SharePoint Foundation Resolve ax7nk Medium Found multiple matches for resolution. Web: 'd21a207d-0726-4779-8e8d-c0cb97011805', WebApp: 'null', Input: 'test1@contoso.com', PrincipalType: 'User, SecurityGroup, SharePointGroup', PrincipalSource: 'UserInfoList, MembershipProvider, RoleProvider', MatchCount: '3'. 3ab0849e-e089-e088-a10e-e4e9a4c5effc

08/14/2018 09:28:46.95 w3wp.exe (0x18E8) 0x2E70 SharePoint Foundation General 8kh7 High The user does not exist or is not unique. 3ab0849e-e089-e088-a10e-e4e9a4c5effc

08/14/2018 09:28:46.95 w3wp.exe (0x18E8) 0x2E70 SharePoint Foundation General art2g High ListItemUpdate ExpectedFailure: Microsoft.SharePoint.SPException: The user does not exist or is not unique. ---> System.Runtime.InteropServices.COMException: The user does not exist or is not unique. at Microsoft.SharePoint.Library.SPRequestInternalClass.AddOrUpdateItem(String bstrUrl, String bstrListName, Boolean bAdd, Boolean bSystemUpdate, Boolean bPreserveItemVersion, Boolean bPreserveItemUIVersion, Boolean bUpdateNoVersion, Int32& plID, String& pbstrGuid, Guid pbstrNewDocId, Boolean bHasNewDocId, String bstrVersion, Object& pvarAttachmentNames, Object& pvarAttachmentContents, Object& pvarProperties, Boolean bCheckOut, Boolean bCheckin, Boolean bUnRestrictedUpdateInProgress, Boolean bMigration, Boolean bPublish, String bstrFileName, ISP2DSafeArrayWriter pListDataValidationCallback, ISP2DSafeArrayWriter pRestrictInsertCallback, ISP2DSafeArrayWriter pUniqueFieldCallback) at Microsoft.SharePoint.Library.SPRequest.AddOrUpdateItem(String bstrUrl, String bstrListName, Boolean bAdd, Boolean bSystemUpdate, Boolean bPreserveItemVersion, Boolean bPreserveItemUIVersion, Boolean bUpdateNoVersion, Int32& plID, String& pbstrGuid, Guid pbstrNewDocId, Boolean bHasNewDocId, String bstrVersion, Object& pvarAttachmentNames, Object& pvarAttachmentContents, Object& pvarProperties, Boolean bCheckOut, Boolean bCheckin, Boolean bUnRestrictedUpdateInProgress, Boolean bMigration, Boolean bPublish, String bstrFileName, ISP2DSafeArrayWriter pListDataValidationCallback, ISP2DSafeArrayWriter pRestrictInsertCallback, ISP2DSafeArrayWriter pUniqueFieldCallback) --- End of inner exception stack trace --- at Microsoft.SharePoint.SPGlobal.HandleComException(COMException comEx) at Microsoft.SharePoint.Library.SPRequest.AddOrUpdateItem(String bstrUrl, String bstrListName, Boolean bAdd, Boolean bSystemUpdate, Boolean bPreserveItemVersion, Boolean bPreserveItemUIVersion, Boolean bUpdateNoVersion, Int32& plID, String& pbstrGuid, Guid pbstrNewDocId, Boolean bHasNewDocId, String bstrVersion, Object& pvarAttachmentNames, Object& pvarAttachmentContents, Object& pvarProperties, Boolean bCheckOut, Boolean bCheckin, Boolean bUnRestrictedUpdateInProgress, Boolean bMigration, Boolean bPublish, String bstrFileName, ISP2DSafeArrayWriter pListDataValidationCallback, ISP2DSafeArrayWriter pRestrictInsertCallback, ISP2DSafeArrayWriter pUniqueFieldCallback) at Microsoft.SharePoint.SPListItem.AddOrUpdateItem(Boolean bAdd, Boolean bSystem, Boolean bPreserveItemVersion, Boolean bNoVersion, Boolean bMigration, Boolean bPublish, Boolean bCheckOut, Boolean bCheckin, Guid newGuidOnAdd, Int32& ulID, Object& objAttachmentNames, Object& objAttachmentContents, Boolean suppressAfterEvents, String filename, Boolean bPreserveItemUIVersion) at Microsoft.SharePoint.SPListItem.UpdateInternal(Boolean bSystem, Boolean bPreserveItemVersion, Guid newGuidOnAdd, Boolean bMigration, Boolean bPublish, Boolean bNoVersion, Boolean bCheckOut, Boolean bCheckin, Boolean suppressAfterEvents, String filename, Boolean bPreserveItemUIVersion) 3ab0849e-e089-e088-a10e-e4e9a4c5effc

The Issue:

Users were given permission to the site using a group that had other groups nested in it. The users were not direct members of the group being used for permission. For example:

Contoso\Level1 – Users are direct members of this group.

Contoso\Level2 – No users in this group, only the "Level1" group and some other groups. This is the group used in SharePoint site permissions.

So we got a Fiddler trace of the user logging in via SAML auth and found that their SAML assertion only contained Role claims for the "Level1" group, and not the "Level2" groups. If your SAML assertion does not contain a certain group, then SharePoint does not believe you are a member of that group, and you will not get any permission that has been assigned to that group within SharePoint.

Research:

In my research, I wasn't finding any definitive answers about whether or not nested groups should typically be part of a users Role claims, so I tested it. Short answer: it depends on which attribute you have mapped to your Role claim in your Relying Party Trust.

Testing:

I tested this in my lab with Active Directory Federation Services (AD FS) as my Trusted Provider, and found that as long as I was using the standard "Token-Groups" attributes mapped to "Role" in my claim rules, all groups, including nested groups showed in my SAML assertion.

Upon further investigation, I found that in my customers case, they were not using ADFS. They were using a 3^rd-party trusted provider that was using the "MemberOf" Active Directory attribute to map to the Role claim. The problem with that is the MemberOf AD attribute only contains groups the user is a direct member of.

The Fix:

Either change the claims mappings for Role to use the Token-Groups attribute, or only use groups in site permissions that users are direct members of.

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: https://docs.microsoft.com/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/

https://blogs.msdn.microsoft.com/sambetts/2015/07/01/sharepoint-server-and-web-application-proxy-continued/