Partilhar via


What You Need to Know About Using EnsureUser In Claims-Based Web Apps in SharePoint 2010 and SharePoint 2013

We ran across an interesting wrinkle in some code last week where someone was using the EnsureUser API, which is a method off of the SPWeb. Yes, we are talking about full trust code again, something which we haven't talked about as much lately but which still has a role in certain circumstances in SharePoint 2013 and which had a major role in SharePoint 2010. This scenario has to do with calling EnsureUser for Windows claims users. The key to understand here is that you should NOT be passing in the user name in the format domain\username when you are using a claims-based web application. If you are only using Windows claims on the zone then the call will likely succeed when you pass in domain\username. However if you add other authentication types like FBA or SAML, then this call will typically fail with a "user not found" error.

To be safe, you need to get the encoded claim value for the user and pass that into the EnsureUser method. Here's an example of how you would do that doing full trust code:        

SPClaimProviderManager cpm = SPClaimProviderManager.Local;

SPClaim userClaim = cpm.ConvertIdentifierToClaim("domain\\username",

SPIdentifierTypes.WindowsSamAccountName);

using (SPSite theSite = newSPSite("https://www.contoso.com"))

{

     SPWeb theWeb = theSite.OpenWeb();

     SPUser theUser = theWeb.EnsureUser(userClaim.ToEncodedString());

}

If you wanted to do this in PowerShell, it would look something like this:

$claim = New-SPClaimsPrincipal -Identity corp\servero -IdentityType WindowsSamAccountName
$web.EnsureUser($claim.ToEncodedString());

The ToEncodedString() method returns a value like this: i:0#.w|domain\\username

It's very important you follow this advice, or you will in all likelihood end up in a broken state when your code is used on a zone with more than one authentication method.

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Good work on including a PowerShell example in addition to C#!

  • Anonymous
    January 01, 2003
    Thank you for adding the powershell script as well. Very helpful and Much appreciated!

  • Anonymous
    January 01, 2003
    Excellent point, Steve! Thanks.

  • Anonymous
    September 18, 2014
    The comment has been removed

  • Anonymous
    November 03, 2014
    The comment has been removed

  • Anonymous
    November 13, 2014

    Hi,

    I am trying to add users to SharePoint 2013 Group.

    Lets say my user name is (jitendra-1987jitendra) and Group is testing_Group.

    I have used .Net Client Object model. The user is add to testing_Group. But when i tried to open the SharePoint Site, access denied error is coming(Site is not shred).

    To figure out the issue, i have deleted the user and added the same user (jitendra-1987jitendra) to the same group manually(SharePoint UI). I can able to access the SharePoint Site.

    Here i have seen the small difference, that is Account value of the User(Click on the User--> Account is the column).

    If add user manually, the Account value is like showing like (.xw|jitendra-1987jitendra).I can access site collection.

    If i add user via code the Account value is like showing like (jitendra-1987jitendra).I am unable to access site collection.

    So as i said earlier, i am using SharePoint 2013. I am able to add users to sharepoint group. but the users are unable to access SharePoint site.

    Do i need to do anything else??

    Please share me if any one have the code snippet(server object model code also fine) to this email id jitendra.sampath@gmail.com.

    Thanks in advance.

  • Anonymous
    March 01, 2015
    NOTE: Please download the attachment to get a Word doc with this posting in human readable format.

  • Anonymous
    March 01, 2015
    I had a friend send me kind of an interesting problem the other day. He was trying to add a new user