Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
While experimenting with Windows Identity Foundation and SharePoint 2010, I was attempting to configure SharePoint to use a customer Security Token Provider (STS) I had written. The STS worked perfectly with a normal Federation enabled ASP.NET web site, but I got the error “The issuer of the token is not a trusted issuer” when I tried to use the STS with SharePoint.
The solution was to ensure the correct certificate was added to the SharePoint SPTrustedRootAuthority collection; however, in the process of doing that I had corrupted the collection. The following tips are provided to assist others going down this path.
As is typical in a lab environment, I was recycling through issues at a rapid pace; reissuing certificates, recompiling the IP-STS, and recreating SPTrustedRootAuthorities and SPTrustedIdentityTokenIssuers.
1. Don’t ever, ever, clear the SPTrustedRootAuthority collection. It holds some self-issued SharePoint certificates. Things won’t work if these self-issued certificates aren’t there. I had to add back the SharePoint Services certificate, which SharePoint uses internally as a self-signed certificate for authentication between web applications and service applications:
2. If you issue a new signing certificate for your STS to replace an old one, you have to update the certificate in 2 places:
a. Add the new signing certificate as a SPTrustedRootAuthority
b. Update the SPTrustedIdentityTokenIssuer.SigningCertificate if you are not creating a new issuer. I was able to update an existing issuer with the following PowerShell commands
3. Look in the application event log for errors. I found some very good error descriptions there.
4. Similarly, the ULS logs capture much of the certificate activity, that can help you determine what thumbprints are known to SharePoint:
5. Always, always test in a simulated ___domain environment with separate VMs for the ___domain controller, SharePoint, the STS, and the client. I found many issues don’t surface when testing everything on a single VM. You have to hope between VMs and use separate certificates for each role (signing, encryption, ___domain root, etc.); and of course as we all know, the golden rule to use separate least privileged accounts for each role/service rather than running everything as administrator.
Comments
- Anonymous
October 11, 2010
the "The issuer of the token is not a trusted issuer" is any solution step by step