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 Security And Authentication Part 3 – Claims Authentication Design And Services

With SharePoint Server 2010, claims based authentication and classic mode authentication are both supported. Claims based authentication is part of the Microsoft Windows Identity Foundation (WIF). This is a set of .NET classes that allow for claims to be processed with WS Federation authentication. WS-Federation is a type of protocol for authentication that builds on the WS-Security and WS-Trust. It supports a token based authentication structures so that a web application required to offer security tokens can be accessed. With SharePoint Server 2010, you have the chose if you want to use claims based or classic mode authentication each time you create a new web applications. With classic mode authentication you will have the Integrated Windows model that was supported by SharePoint Server 2007. There aren’t any claims changes that are performed so the new claims authentication features can’t be supported. When you choose to use classic mode authentication you will be able to implement all of the method that were supported by SharePoint Server 2007. You are also under this pretense going to be limited to the use of one form of authentication for each of the zones. With claims based authentication for SharePoint Server 2010, you will be able to use authentication for the entire span of Windows based systems. You can also use it across those systems that aren’t Windows based as well. With claims based authentication, you will support the delegation of a user identity between applications. This allows you to implement multiple forms for authentication in a particular zone.

It is important to understand the basic components of claims based authentication. Yeah this has been covered a lot on the site but its critical. A security token is the main component of claims based authentication. This security token consists of sets of identities about a user. This can include their user name, the role they have in the organization, an employee ID that has been assigned, and other variables that an organization uses. The values of these identities are assigned a value that is in a text string. The security tokens are created and also managed by a Security Token Service (STS). Policies are implemented based on the decisions of the organization about how those security tokens can be distributed based on authentication of a user that proves they are authorized.

With a claims based application, WIF is able to create a WS Federation authentication request. WS-Federation is an authentication protocol used to build on what WS-Security and WS-Trust have instilled. WS-Federation supports the overall architecture of this token based authentication. This process allows the web application to require a security token before the authentication process can be completed. Without it, a user will never be able to gain access to the resources. Once the Windows user identity is created it is converted to WindowsIdentity by SharePoint Server 2010. From there it is converted to ClaimsIdentity. The object is then able to use used for the purpose of creating a token.

A Security Token Service takes on the role of responding when requests for authentication are made. The security tokens for identity claims are evaluated based on the user account information that has been stored in an Active Directory Domain Service, arbitrary LDAP Store, or an SQL Database. Each security token has content in it that is determined by the types of requirements for authentication requests that have been determined with the Security Token Service and the SharePoint web application. The claim rules are also the policies that will be used as requirements to be met before a web application can be accessible. There are two function of a Security Token Service. It can serve as a local Identity Provider Security Token Service when they are in the same web application as the SharePoint farm. When they are located in different farms though the function of the Security Token Service is that of Relying Party Security Token Service.

With Identity Provider Security Token Service, the identity providers and the web application have the same farm through SharePoint. They will provide tokens to users that have been authenticated and that are in the same local stores.

With Relying Party Security Token Service, the partner identity provider has a trust relationship with the Identity Providers Security Token Service as well as the web application. These entities can be located in different SharePoint farms. This is a trusted relationship that allows the Relying Party Security Token Service to authorize an external user even if the credentials of that user aren’t locally stored. As long as the Identity Providers Security Token Service of a user is able to issue a valid security token that process will take place without any problems. It is possible for a new token to be issued that is able to validate a web application that may be local to the Relying Party Security Token Service but external to the user.

There are two types of claims based authentication topologies that can take place. One of them is a single farm that requires the use of a Security Token Service that is local. There is also the use of a multiple farm topology that uses both a local Security Token Service and a Relying Party Security Token Service.

Assume an incoming request for authentication that comes from an external user. The credentials are going to be accessible by Security Token Services. The request is then submitted and processed by the local Security Token Service. In order for that to happen, the policy for a given web application must create a token. This is going to be based on the identity of the user and the values of the store. A valid token will be returned to the user and then it can be submitted to the web application once a cookie has been returned to the user.

When a user has credentials that aren’t directly accessible by a local Security Token Service, the web application is going to respond to the authentication request from an redirect to a partner Security Token Service. This request is submitted due to the trust relationship that exists. An Identity Provider Security Token Service is created for the user and then submitted to the local Security Token Service. There it is deciphered for the token and then it is returned to the external user. Then the web application will return a cookie to the user.

In order to successfully complete crawls of content for any web application, it is important to understand how the authentication works for it. The indexing element of the search server is what is referred to as the crawler. Successfully configuring the authentication for web applications ensures that the content in those applications has been crawled. A farm administrator will create a web application that uses all of the default settings. The zone for that default is created through a web application using NTLM. The farm administrator can change the method of authentication for the default zone through any of the SharePoint Server 2010 supported methods. The farm administrator also have the ability to extend any web application several times so that additional zones can be offered. As many as five zones can be offered for any particular web application. These zone are configured through the use of any of the SharePoint Server 2010 authentication methods. The planning zones for a given web application has to be considered in order for the access zones to be displayed in an orderly fashion. This process will occur then an attempt to authenticate is completed. The order is very important so that the crawler is able to get through the zones that are configured. If the crawler can’t gain access through one of the zones, the authentication will fail and then there is going to be content on the web application that isn’t crawled. It is a good idea to have NTLM zoning configured early in the order. It should be before authentication for basic, digest, or Kerberos.

The zones that the crawler will access will occur in this order:

  1. Default zone
  2. Intranet zone
  3. Internet zone
  4. Custom zone
  5. Extranet zone

These are the actions that will be associated with the call out process:

  1. Crawler uses the default zone to attempt authentication. The crawler will always attempt to use the default zone first for any particular web application.
  2. If a zone has been configured for NTLM then the crawler will move on to try to authenticate that in the next phase.
  3. If a zone has been configured for basic, digest, or Kerberos authentication then the crawler may fail and not continue to crawl all of the remaining content within a web application.
  4. If there aren’t more zones in the order the authentication may fail.
  5. The crawler will them attempt to complete the authentication by moving into the next zone in that order. You must create at least one more zone and configure it use NTLM authentication.

Next in this SharePoint security series, the last post in it, we will be talking about how to build the security design, and what SharePoint security best practices should be implemented in particular environments.