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:

[code]

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)

[/code]

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

Share

Invoking The RMS Bulk Protection Tool Remotely

I don’t understand why this was so hard, but it really is. And honestly who wants to use this tool directly on the server? It is more useful when you can bake it into client applications, in my case a VSTO add-in. Furthermore, the Microsoft site says this will work on XP, this is not the case since it will just throw Skipped, file type not supported. I don’t know what that’s about. Furthermore, if you try to invoke the encryption routines on the box while pointing to a network share hosting the application, like this:

[csharp]
var start = new ProcessStartInfo
{
WorkingDirectory=Whatever
Arguments = @” /encrypt \\server\shareimencrypting\ Rights.xml”,
FileName = @”RmsBulk.exe”,
WindowStyle = ProcessWindowStyle.Normal,
CreateNoWindow = false,
UseShellExecute = false
};
using (Process p = Process.Start(start))
{
p.WaitForExit();
}
[/csharp]

It will not work since it can’t hydrate the template file. Returns an error like “you do not have access to the template file or it does not exist”. Or something to that effect.  So, the only real way to do is to execute the task remotely. Since the standard output from the tool is pretty important for interaction purposes (tells supported file types and gives a report of failed / succeeded decryption routines, that pretty much means WMI is out the door since it won’t out a return. So, PSExec comes to the rescue! Or maybe something else this was just what the SP MVP group said would be the path of least resistance.

Long and short of it is, to execute it remotely make two local executables that reside in the shared RMSBulk tool directory (or as long as the wrapper classes for the IRM protector are relative to the tool), respectively:

[csharp]
var start = new ProcessStartInfo
{
Arguments = @” /encrypt \\server\share\ Placitum_Rights.xml”,
FileName = @”RmsBulk.exe”,
WindowStyle = ProcessWindowStyle.Normal,
CreateNoWindow = false,
UseShellExecute = false
};
using (Process p = Process.Start(start))
{
p.WaitForExit();
}
[/csharp]

And for the decryption:

[csharp]

var start = new ProcessStartInfo
{
Arguments = @” /decrypt \\server\share\”,
FileName = @”RmsBulk.exe”,
WindowStyle = ProcessWindowStyle.Normal,
CreateNoWindow = false,
UseShellExecute = false
};
Process p = Process.Start(start);
p.WaitForExit();

}
[/csharp]

Then in your client app, make the appropriate PSExec calls.

For the encryption:

[csharp]
ProcessStartInfo startEncrypt = new ProcessStartInfo
{
WorkingDirectory = @”
“,
FileName = @”
\PsExec.exe”,
WindowStyle = ProcessWindowStyle.Normal,
CreateNoWindow = false,
Arguments = @”\\ -u username -p password -w “”C:\Program Files (x86)\AD RMS Bulk Protection Tool”” “”C:\Program Files (x86)\AD RMS Bulk Protection Tool\Encrypt.exe”””,
UseShellExecute = false
};

Process process = new Process();

process.StartInfo = startEncrypt;
process.Start();
process.WaitForExit();
process.Close();
[/csharp]

For the decryption:

[csharp]
var startDecrypt = new ProcessStartInfo
{
WorkingDirectory = @”

FileName = @”
\PsExec.exe”,
WindowStyle = ProcessWindowStyle.Normal,
CreateNoWindow = false,
Arguments = @”\\ -u username -p password -w “”C:\Program Files (x86)\AD RMS Bulk Protection Tool”” “”C:\Program Files (x86)\AD RMS Bulk Protection Tool\Decrypt.exe”””,
UseShellExecute = false
};

Process process = new Process();
process.StartInfo = startDecrypt;
process.Start();
process.WaitForExit();
process.Close();
[/csharp]

And you can get around 99% of the limitations of the tool. It’s pretty cool when you combine it with FCI, then really get fancy by ad-hoc provisioning plain-text indexing to support encrypted searching routines.

Share