SharePoint And ADFS: SecurityTokenException – The issuer of the token is not a trusted issuer

This is a pretty common ADFS error, and there are all sorts of reasons that it could happen.

The stack trace will be this:


Microsoft.SharePoint.IdentityModel.SPTrustedIssuerNameRegistry.GetIssuerName(SecurityToken securityToken)

   at Microsoft.SharePoint.IdentityModel.SPPassiveIssuerNameRegistry.GetIssuerName(SecurityToken securityToken)

   at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.CreateClaims(SamlSecurityToken samlSecurityToken)

   at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.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 System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)


At the end of the day though, don’t sit around and fiddle with the SharePoint trusted authorities and yada yada yada, it boils down to a certificate problem. Basically the one that was specified as the signing certificate, when exported during the ADFS setup, is either malformed (the certificate chain is incomplete) or plainwrong wrong when the trusted issuer was being built up in SharePoint ala powershell. So to get around the error follow two pretty basic steps.

  1. Verify the appropriate certificate chain is present on the SharePoint server in both the trusted root authorities as well as in the SharePoint folder within the Certificate MMC snap-in. Never ever, ever delete the self issued ones that SharePoint provisioned within that folder. You will cause a Micheal Bay-spolosion. To verify the chain, just popup open the certificate details within some interface (like, the MMC :) ) doesn’t really matter what and verify that the chain is trusted and existent.
  2. Next, verify that you actually used the right certificate when specifying the certificate path when building the System.Security.Cryptography.X509Certificates.X509Certificate2 object to pass into your SPTrustedIdentityTokenIssuer. This is pretty easy to mess up when troubleshooting if you are swapping certs all over the place.

Both of these are in place, then that error will go away. Not that another won’t popup :)


SharePoint Kerberos Buddy Update – Release Created On CodePlex

Whoops. Sorry folks! I had just uploaded the .MSI and related setup files to the CodePlex site source control. I forgot to created a release with them which made it a pain to download. I should probably zip up the files so it’s one download but the MSI and setup.exe are now sorta easily available.


TMG Web publishing for SharePoint HTTPS, No Certificate Usage On TMG

This question came up with a client this morning, which is the first time I have had to answer it but it’s a very straightforward issue.

What if one is trying to use TMG to publish a SharePoint environment for both HTTP and HTTP access, while the certificate is appropriately setup in the SharePoint server it is not desirable to have the web publishing rule bound to the certificate, i.e. certificate stuff should be handled by the SharePoint environment. So, breaking the question down even more, they wanted to publish the HTTPS SharePoint instance WITHOUT using the certificate in the TMG instance.

This obviously is not a supported route, because logically it doesn’t make a ton of sense. One can’t use a HTTP web publishing rule without having the appropriate certificate accessibly and appropriately in place, and clearly is not a TMG limitation because it is the same requirement for ISA and Proxy Server stuff.