Forum Discussion
SharePoint 2016 on-premise - trouble with ADFS : user appears as deleted
Hi!
It seems that we are encountering a problem with our SharePoint 2016 on-premise installation where we use ADFS. Sometimes, for a reason that we cannot figure out, some users appear as DELETED in the Central Administration. For example, a user can suddenly appear like so in the User Profile Service Application: i:0e.t|adfs provider for sharepoint|user@domain.com-DELETED-FBED8861-B321-4078-B0FB-DADA6EC29A6A. The best hint that we have found in the logs is something like so:
08.08.2018 10:26:19.37 w3wp.exe (0x2988) 0x242C SharePoint Portal Server User Profiles axefd Medium UserProfileManager::GetUserProfile: profile with requested UPN 'i:0e.t|adfs provider for sharepoint|user@domain.com' does not exist in UPA. 1aad829e-1395-60cf-e43d-c6ae94faf5f4 08.08.2018 10:26:19.37 w3wp.exe (0x2988) 0x242C SharePoint Portal Server User Profiles ogdg Medium UserPicker.GetUserPropCollectionByAccountName(). It could be due to Non_AD environment: Microsoft.Office.Server.UserProfiles.UserNotFoundException: A user with the specified SID could not be found in the domain. Check the spelling of the account name « i:0e.t|adfs provider for sharepoint|user@domain.com », and try again. ---> System.ComponentModel.Win32Exception: No mapping between account names and security IDs was done at Microsoft.Office.Server.Utilities.Win32.AdvApi.LookupAccountName(String lpSystemName, String lpAccountName, IntPtr Sid, Int32& cbSid, StringBuilder ReferencedDomainName, Int32& cchReferencedDomainName, SID_NAME_USE& peUse) at Microsoft.Office.Server.UserProfiles.UserProfileGlobal.GetSidFromAccount(String strAccountName, SID_NAME_USE[] IntendedAccountType, SID_NAME_USE& sidUse) --- End of inner exception stack trace --- at Microsoft.Office.Server.UserProfiles.UserProfileGlobal.GetSidFromAccount(String strAccountName, SID_NAME_USE[] IntendedAccountType, SID_NAME_USE& sidUse) at Microsoft.Office.Server.UserProfiles.UserProfileGlobal.GetSidFromAccount(String strAccountName) at Microsoft.Office.Server.UserProfiles.DS.GetUserPropCollectionByAccountName(String strAccountName, UserFormat unt). 1aad829e-1395-60cf-e43d-c6ae94faf5f4 08.08.2018 10:26:19.37 w3wp.exe (0x2988) 0x242C SharePoint Foundation User Key ayswp High Successfully got user key for user. User key and userNameSuffix are identical. UserNameSuffix: '0e.t|adfs provider for sharepoint|user@domain.com'. 1aad829e-1395-60cf-e43d-c6ae94faf5f4 08.08.2018 10:26:19.37 w3wp.exe (0x2988) 0x242C SharePoint Portal Server Personal Site Instantiation ajo5l Medium Property get of UserProfile.PersonalSiteInstantiationState for user i:0e.t|adfs provider for sharepoint|user@domain.com -DELETED-F4E8EAC5-10A7-4200-AABA-349F82B29EA3. Returning: Created 1aad829e-1395-60cf-e43d-c6ae94faf5f4
Of course, in such a situation the affected users lose their rights on our Intranet installation. We have to delete their profile in the User Profile Service Application, then the users can log back in again. From that moment, the users can navigate through our Intranet installation for a while before the problem occurs once again. It seems that from the moment a user has this problem, it never goes away. Another odd thing is that the “super admin” user have also the same problem, but can take back his rights after a page refresh while the other users cannot.
Our installation is pretty classic. We have one Load Balancer, two Front End servers with distributed cache, two servers for the applications and the search engine, one server for the Office Web App and two database servers (mirrored databases). Our configuration database version is 16.0.4744.1000 and we use Windows Server 2016 where we have IIS 10.
Has someone ever encountered such a problem?
Many thanks in advance.
Best regards,
- If anyone finds this post and has the same problem, the solution was more "simple" than we thought. The users marked as deleted were in such a state because their OU was not synchronized in the UPSA (https://blogs.technet.microsoft.com/spjr/2018/04/08/sharepoint-the-complete-guide-to-user-profile-cleanup-part1).
4 Replies
- If anyone finds this post and has the same problem, the solution was more "simple" than we thought. The users marked as deleted were in such a state because their OU was not synchronized in the UPSA (https://blogs.technet.microsoft.com/spjr/2018/04/08/sharepoint-the-complete-guide-to-user-profile-cleanup-part1).
Typically you will see this when you have duplicated imported objects. Can you describe how you've configured AD FS & SharePoint as well as the UPSA import process?
Thanks for your message!
I think I have to check a few things with our system administrators to fully answer the question. However, from what I know and from what I can see, the “synchronization connection” in the UPSA is set as an “Active Directory Import”. The “authentication provider type” is marked as “Trusted Claims Provider Authentication” and the provider instance as “ADFS Provider for SharePoint”.
We have an incremental synchronization that runs every day. We do not have particular policies or audiences. We did not change a lot of settings in this service. However, users have a “My Site”.
For our Intranet we have two WeApplications, one for the main part and another for the “My Sites” part. Both use the same authentication providers settings. Because we use ADFS, we set the sign in page URL as “/trust/default.aspx”.
Trevor Sewardis very knowledgeable about those types of problems, maybe he can provide some advice
