Share-n-dipity

SharePoint serendipity is the effect by which one accidentally discovers something fortunate, especially while looking for something else entirely. In this case, it is the occassional musings, observations, and Ouija board readings about the phabulously

TrustedMissingIdentityClaimSource Error with Claims Auth in SharePoint 2010

TrustedMissingIdentityClaimSource Error with Claims Auth in SharePoint 2010

  • Comments 5
  • Likes

I've seen this error happen a few times to myself and others so I thought I would share the likely culprit.  The scenario is, you set up claims authentication in SharePoint 2010...and you're pretty sure you've configured everything correctly.  :-)   When you actually try and navigate to the site though you may get the standard ASP.NET error page that says something along the lines of a TrustedMissingIdentityClaimSource error (assuming you have custom errors turned off).  Most frequently I've seen this error when you have configured EmailAddress to be the identity claim, but the person you are trying to log in with does not have an email address in Active Directory (or whatever directory you're using).  It can be confusing of course because you see yourself getting redirected to ADFS (for purposes of this conversation, could be any IP-STS), you see that you've been authenticated there, but then SharePoint blows up.  It serves as a reminder as the difference between who I am (the identity you log in with), and things about me (attributes like EmailAddress and other claims that can be used for permissions provisioning now).

So, if you get this error, the first thing I would recommend checking is whether your user account that you logged in with has a value in the identity claim it is expecting.  Remember too, if there's no value in that attribute, the claim will typically not even get sent over to SharePoint (i.e. as an empty string value for example).

Comments
  • Steve - great posts, here and with the end-to-end config guide.  

    A few questions regarding claims configured to use EmailAddress as the Identity Claim:  

    I have a user set as the Primary Site Collection Admin, and have confirmed an email address exists for the user.  

    Note that the email address has been changed at a point during the Web Application setup & config process, from email1@contoso.com to email2@contoso.com.

    When selecting the user account in the People Picker to deisgnate as SIte Collection Admin, simply searched for the term "email2," which showed one entry in Active Directory, and one from the SAML feed... selected the one from the SAML  feed.

    In both instances, below, I have provided the same domain\user credentials in the logon window:

    Access the site using Windows(NTLM) Auth, and I am able to successfully access the site with admin rights, but "My Settings" shows my email address as email1@contoso.com (old email address)

    Access the site using SAML Auth, and I get "Access Denied" for current user email2@contoso.com (correct/new email address)

    So unsure why:

    1 - The same user account can access SP as Windows Auth, but not as SAML Auth

    2 - SP doesn't see the updated email address that appears in my AD user properties

    How often does SP look back at AD to validate/sync the values in the various fields from an SP user with the AD user?  Can I manually tell it to update?  Is this through User Profile Sync (do I need to set this up separately?)

    Thanks for any direction you can provide!

  • Also, if you get "this error" (TrustedMissingIdentityClaimSource Error), what's the second thing you'd check, after you've verified that the account that you logged in with DOES have a value in the identity claim it is expecting...?

    From the ULS Viewer:

    Name=Request (GET:sptest.resource.com/.../default.aspx)

    System.Web.HttpException: The file '/_layouts/_login/default.aspx' does not exist.  

    Site=/

    Unknown SPRequest error occurred. More information: 0x80070005

    Leaving Monitored Scope (Request (GET:sptest.resource.com/.../default.aspx)). Execution Time=24.2155776781686

  • So to answer my own question... the second thing you check (after you've verified that the account that you logged in with DOES have a value in the identity claim it is expecting) is to confirm you're actually PASSING said value(s) all the way to SharePoint.

    In our example, you could successfully get:

    From RESOURCE browser, to SP in RESOURCE Forest, using RESOURCE Windows Credentials

    From RESOURCE browser, to RESOURCE Forest ADFS, to SP in RESOURCE Forest, using RESOURCE SAML Claim

    From ACCOUNT browser, to RESOURCE Forest ADFS, using ACCOUNT SAML Claim, but Fails at SP, throwing an error about "An exception occurred when trying to issue security token: The trusted login provider did not supply a token accepted by this farm"

    We seemed to have missed the step to configure the Claim Rules on the RESOURCE Relying Party Trust to pass-through the email address and role information.

    So...

    Check 1 - make sure the account that you logged in with DOES have a value in the identity claim it is expecting

    Check 2 - make sure that the value is making it all the way through to the Consuming Party.

    HTH.

    McD

  • I also updated the emailaddress in AD properties later and SP doesnt seem to be getting it.

    Any way to fire update to get it ?

  • All the comments above are more reasons why email address should not be used as the identity claim for AD sources IMO.  UPN is guaranteed unique and guaranteed to exist on an AD source.  It is even formatted like an email address.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment