Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

First let me start by saying I feel like this is an easy question, but I am beating my head against the wall on it.

I am trying to get SharePoint 2013 to accept claims from another organization's ADFS environment. So far I have done the following (names replaced where appropriate):

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("partnersts.cer")
New-SPTrustedRootAuthority -Name "Partner ADFS Signing Certificate" -Certificate $cert
$emailClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://sts.company.org/user/EmailAddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
$fnClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://sts.company.org/user/FirstName" -IncomingClaimTypeDisplayName "FirstName" -SameAsIncoming
$lnClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://sts.company.org/user/LastName" -IncomingClaimTypeDisplayName "LastName" -SameAsIncoming
$groupClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://sts.company.org/user/Group" -IncomingClaimTypeDisplayName "Group" -SameAsIncoming
$realm = "https://our.local.sharepoint"
$signInURL = "https://sts.company.com/adfs/ls"
$ap = New-SPTrustedIdentityTokenIssuer -Name "Partner ADFS" -Description "Partner Corporate ADFS Provider"  -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $emailClaimMap,$fnClaimMap,$lnClaimMap,$groupClaimMap -SignInUrl $signInURL -IdentifierClaim $emailClaimmap.InputClaimType

Everything looks fine when I Get-SPTrustedIdentityTokenIssuer and Get-SPTrustedRootAuthority, and I have confirmed through network capture that the certificate matches the certificate being used by the remote provider in the SAML response and that the list of claims supplied matches the list I have mapped. Also the realm, while not urn:something, is what is being used by the partner and is visible in the SAML response, so that's not the issue. (We had the wrong at first and the error is different in that case anyway.)

However I am getting what apparently is a common message when I try to use the provider:

System.IdentityModel.Tokens.SecurityTokenException: The issuer of the token is not a trusted issuer.   
 at Microsoft.SharePoint.IdentityModel.SPLocalIssuerNameRegistry.GetIssuerName(SecurityToken securityToken)    
 at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.CreateClaims(SamlSecurityToken samlSecurityToken)    
 at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ValidateToken(SecurityToken token)    
 at Microsoft.IdentityModel.Tokens.SecurityTokenHandlerCollection.ValidateToken(SecurityToken token)    
 at Microsoft.IdentityModel.Web.TokenReceiver.AuthenticateToken(SecurityToken token, Boolean ensureBearerToken, String endpointUri)    
 at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequest request)    
 at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)    
 at Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs eventArgs)    
 at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()    
 at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

I know it's not the same issue as The Token Issuer is not a trusted issuer because there's no issue with importing the certificate.

I feel like I'm close but there's something I'm missing. There are a million walkthroughs online including the official one at http://technet.microsoft.com/en-us/library/hh305235(v=office.15) but they are just not getting me there. There's a lot of web hits on the specific error message but so far I don't see any that answer this in my case.

share|improve this question
add comment

2 Answers

up vote 1 down vote accepted

I've come across this error before, it was because the ADFS server was not configured correctly. When configuring the relying party in ADFS - for SharePoint - you have to add "/_trust" to the "WS-Federation Passive protocol URL" field. See step 11 in this guide.

Steve Peschka also mentions it on his blog:

http://blogs.technet.com/b/speschka/archive/2012/05/17/the-issuer-of-a-token-is-not-a-trusted-issuer-craziness-with-saml-claims-in-sharepoint-2010.aspx

Hope that helps...

share|improve this answer
    
I saw this post, but since I don't have control over the remote ADFS endpoint there wasn't much I could do with it. I'll reach out to the other side and see if they have this set. –  MikeBaz Jan 15 '13 at 13:08
    
I contacted the remote side and they changed the configuration. That was indeed the issue. –  MikeBaz Jan 23 '13 at 18:23
add comment

Did you check the certificate chain. When you look at the certificate properties, you can see if there are any root certificates that need to be imported as well in the SharePoint certificate store.

Hope it helps

share|improve this answer
    
I did not show above, but I added each parent in the chain through New-SPTrustedRootAuthority. Is there another store I need to worry about? I saw mentions of the SharePoint folder in the machine store, but none of the ones I added through PowerShell are there, only the ones SP made for itself. –  MikeBaz Jan 14 '13 at 22:25
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.