Share via

How to Override the Default Name Resolution and Claims Provider in SharePoint 2010

  • Article

An issue that has frustrated a lot of folks since SharePoint 2007 and the WebSSO provider, and that continues today in SharePoint 2010 when using claims authentication with something like ADFS v2, is name resolution.  Meaning that in most cases you can type in any random value you want into the search box, and the people picker will act like it is valid - it will underline what you typed in and treat it as a resolved name.  Of course, this is a problem for your users because whether they had a typo or just flat out had no idea who they are looking for, we tell them "yep, that's a valid name".

Fortunately SharePoint 2010 and its inherent support for claims providers supplies relief for this scenario.  I've explained in other posts how one can create a custom claims provider for both augmenting claims, as well as providing custom search and name resolution capabilities.  So to work around this issue in SharePoint 2010 there's really two things you need to do:

  1. Write a custom claims provider.  See https://blogs.technet.com/speschka/archive/2010/03/13/writing-a-custom-claims-provider-for-sharepoint-2010-part-1.aspx to get started with that.
  2. Replace the default claims provider with your own.  That's the point of this posting.

To replace the default claims provider with your own, you really just need to execute a pretty simple PowerShell script.  Super bonus kudos to Chris for explaining this part to me.  Here's what the script looks like:

$trusted = Get-SPTrustedIdentityTokenIssuer -Identity "Trusted Login Provider Name Goes Here"
$trusted.ClaimProviderName = “name of your custom claim provider”  //in your claim provider you need to override the SPClaimProvider.Name; use that value here
$trusted.Update()

That's it.  After you do that we'll start using your custom claims provider as the default provider for that SPTrustedIdentityTokenIssuer.  I know this is an important feature to a lot of folks so I hope you all find this information helpful.

NOTE:   Important additional information has been added to this topic.  Please see https://blogs.technet.com/b/speschka/archive/2010/05/25/replacing-the-out-of-box-name-resolution-in-sharepoint-2010-part-2.aspx.

Comments

  • Anonymous
    January 01, 2003
    Hi Steve,

    Is there any way to reset the claim provider to default?

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    thanks

  • Anonymous
    September 23, 2010
    Hi! I have created a custom ClaimProvider that provides custom search and resolution for roles. I connected this with the method you described but it seems like when I add the resolved roles to a group/permission in sharepoint it seems that it don't get resolved correctly. The user don't get the permissions assigned to the role. I have not implemented the augmenting part (FillClaimsForEntity). Is this nesseccary since these claims (role) are added to the trusted login provider. I have checked the default SPTrustedClaimsProvider that is used if no claim provider is assigned to the TIP and it hasn't implemented it.

  • Anonymous
    May 23, 2011
    Thanks!  This is what I've been looking for.

  • Anonymous
    July 16, 2011
    I deployed my custom claim provider and used $trusted.ClaimProviderName = “name of your custom claim provider”. After that I retracted and removed the farm solution that I used to deploy my claims provider and now the default claims provider does not show up in people picker. How can I restore default OOB claims provider? I tried $trusted.ClaimProviderName = “SPAllUserClaimProvider” but it does not like that name. Thanks.

  • Anonymous
    September 06, 2011
    We tried this with a ADFS Claims  To setup the ADFS we followed this:  blogs.technet.com/.../configuring-sharepoint-2010-and-adfs-v2-end-to-end.aspx We have a working Customs Claim that resolves names and when we run the PS commands in your post the custom claim provider fails to work.

  • Anonymous
    September 18, 2014
    The comment has been removed

  • Anonymous
    February 28, 2015
    This is a topic that continues to generate swirl, because as soon as you make one change you may want

  • Anonymous
    March 01, 2015
    I recently witnessed a problem that proved to be fairly difficult to track down so I thought I would

  • Anonymous
    March 02, 2015
    In Part 1 of this series, we went through how to configure SharePoint to use ACS and Azure Active Directory