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 :)


ADFS Timeouts – Keep Above 10 Minutes When Testing

I ran into this issue very recently when helping with an ADFS environment setup that was using a federation proxy to an internal federation service farm. The timeout desire was to be 15 minutes, after a user would have to re-authenticate to the ADFS box. To expedite the testing, we were attempting to set short intervals of timeouts, 1-2 minutes…up to 5, however nothing was timing out fumbling the proof of concept. Over around 8 minutes was timing out though. Furthermore, there was never a concrete timeout; there was always some level of skew.

This behavior seemed erratic. The problem is ADFS has a Cache Scavenge interval, which is the process for purging out-of-date cache records from the client cache. If your timeouts are configured in a pretty orthodox way, for example a ten minute timeout:

On the SharePoint box:

$sts = Get-SPSecurityTokenServiceConfig
$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan –minutes 1)

And on the ADFS box:

Set-ADFSRelyingPartyTrust -TargetName Relying Party Common Name -TokenLifeTime 10

But you have your TokenLifeTime set to a ridiculously low value (it always has to be above the LoginTokenCacheExpirationWindow btw) such as two, resulting in a difference of a one minute timeout; the Cache Scavenge will never fire. Thus the issued ticket will be considered valid.

Take away is always just test with something like 10 minutes and deal with the wait time for verification.