SharePoint Claim base authentication Ensureuser without Claim (i:0#.w|) User Failed

Environmental information:

　　with Form base authentication (FBA), A hybrid certified SharePoint environment for Active Directory Federation Services (ADFS), and Windows authentication.

Specific description of the problem:

In this environment, calling Ensureuser to add a normal ad user,sharepoint will throw "The specified user Userloginname could not being found.", of course, here the user login Name is not with claim (i:0#.w|), as shown:

To view the problem cause process:

In fact, when I first saw the problem, I looked at SharePoint log, but I didn't find any useful information in log, and after that I tested the ensureuser operation on the user login name with claim (i:0#.w|). It is found that for user with claim (i:0#.w|) can be added to SharePoint normally, we can basically conclude that the problem should be caused by mixed authentication, but this is certainly not enough, we need to analyze the root cause of the problem, Why would a user with claim be added to a SharePoint environment without claim but throw a exception?

The problem analysis here is that simply invoking the SharePoint API is no longer helping us, and we need to sacrifice the artifact: Reflector to analyze Ensureuser This method, look at the internal logic of SharePoint to find the root cause of the problem, the specific analysis process is not here to repeat, nothing more than a quiet heart to gnaw at Microsoft code.

Here is a brief explanation of the significance of claim for Userloginname in Eusueruser:

　　if Userloginname has claim (i:0#.w|domain\username): The claim object is generated internally by the Ensureuser method, which specifies the type of Spclaim, As a result, SharePoint can filter the provider that are available in the current environment through Spclaim objects, and only the provider that meet Spclaim.claimtype will attempt to get user information.

　　If Userloginname does not have claim (domain\username): Unable to create Spclaim object because there is no claim, Then only the spprincipaltype inside the Ensureuser method is passed in (the Ensureuser method internally is spprincipaltype.securitygroup| Spprincipaltype.user) to filter the provider, as long as provider that support both types attempt to get the User information, filtering provider through Spclaim is clearly more accurate than filtering through Spprincipaltype ( one thing to note here: For large batches of ensureuser, it is recommended to use the Userloginname format with Cliam, which allows for more precise positioning of the provider, and thus fewer calls to provider resolve user, And then improve the efficiency of ensureuser.

　Said so much seems to have nothing to do with our problem, we want to add the user is an ordinary ad user,windows authentication corresponding provider should be able to get to this user, but why will throw Where's exception?

We think that the corresponding provider of Windows authentication can get the user information through the user login name, and SharePoint does not actually get the user information, since it is inconsistent with what we think Then it is necessary to write the program to verify that the user information can be obtained, through the previous analysis of the code inside the Ensueruser method, I found the SharePoint internal call provider Resolve user method, see:

This method is Ensureuser internal call method, and its role is to call the provider resolve method to get the user, so the problem is simple, we reflect the simulation of the method to confirm whether the provider can be retrieved through the login name of the user on the line, Reflection simulation of the code is relatively simple, here do not repeat, directly on the result:

Note that the green section for Provier gets the user information, through the results we can find that the corresponding provider of Windows authentication has actually obtained the relevant user information, and the returned user login The name is already formatted with claim, and since it gets the user information why is the Ensureuser method bad? In fact, the problem here is more obvious, through the results, we will find that not only the Windows authentication corresponding provider get the user information, ADFS corresponding to the provider also get the user's information (this is ADFS normal normal logic, for ADFS, regardless of whether the query user exists, will return a user, if you want to avoid this problem, you can configure LDAP, the specific configuration method is shown in the Portal: LDAP configuration method), since we believe that hybrid authentication is causing the ad user without claim to add normally, could it be that ADFS also gets the user information caused by the problem? , we look back at the logic inside the Ensureuser method, and it should not be difficult to find this method:

Note that in the two red boxes, the first red box is actually the method we have just reflected the simulation, the method of the final access to the user-related information saved in the Entityarray, and the next red box is actually some special handling of Entityarray, With this special treatment it is not difficult to see that the user information obtained by provider is converted to a Spprincipalinfo object only when Entityarray.lenth==1 is available, and if the IF condition in the red box is not met, Then the IF statement under the Red box (if (info = = null) info=user;) is executed, but the actual user is null, so that the info object obtained by the Resolveprincipalclaims method is also a UNLL value, Naturally, there's no way to talk about adding the user to SharePoint, and then throw the specified user userloginname could not be found.

summarize the cause of the problem: This problem is actually due to the existence of multiple authentication methods in the SharePoint environment, which causes SharePoint to add the user to the same user by using each provider when the API is called. Name gets more than one user, but SharePoint doesn't know which user we want to add to SharePoint, so it's not as good as which user is added, which in turn causes the add user to fail.

PS: The problem for my research results, if there are any mistakes, welcome you greatly corrected ^_^

　

　　

SharePoint Claim base authentication Ensureuser without Claim (i:0#.w|) User Failed