Scenario
You are attempting to add a relying party (RP) trust to your Active Directory Federation Services (AD FS) 2.0 federation service (FS) and you get the following error:
Textually:
An error occurred during an attempt to access the AD FS configuration database.
MSIS7613: The signing certificate of the relying party trust is not unique across all relying party trusts in AD FS 2.0 configuration.
Issue
The token signing certificate is already used in one of the other RP trusts.
AD FS expects and requires that each RP application utilise a unique token signing certificate.
Other FS do not however, and this is a bit of a common issue. The workaround of removing the signing certificate is not a great solution and often the push back to get two certificates won’t be implemented (for good reason as there’s likely a whole raft of systems using it without issue).
Resolution
AD FS Update Rollup #3 (issue #3). Here’s some verbiage from the KB:
Issue 3
Some relying parties require that signature certificates are applied to the relying party for SAML requests, as signature certificates provide a critical security validation function and are defined in the SAML 2.0 specification. AD FS 2.0 is capable of allowing unique signature certificates to be applied to a relying party trust, but it only allows the same certificate to be applied to one relying party trust per AD FS 2.0 farm. This restriction may allow multiple relying parties to use the same signing certificate for SAML requests. AD FS 2.0 update rollup 3 removes this restriction and allows multiple relying parties to use the same signing certificate for SAML request.
Post-update configuration
Note however that simply applying the update rollup doesn’t allow you to implement multiple relying party trusts with the same certificate. After applying the update you have to run the script PostReleaseSchemaChanges.ps1.
The script is located under the AD FS binaries directory:
C:\Program Files\Active Directory Federation Services 2.0\SQL
If you have a WID backend you need to run the script on the primary FS. You can run it on any FS if you have a SQL backend. Before running the script load the AD FS PowerShell snapin, e.g.:
cd "$env:programfiles\active directory federation services 2.0\sql" Add-PSSnapin microsoft.adfs.powershell .\PostReleaseSchemaChanges.ps1
After running the script – which runs SQL scripts and outputs a lot of text to the shell – you can create RP trusts with the same signing certificate.
Here I create two RP trusts to Oracle Taleo with the same certificate, as evidenced from the highlighted thumbprint.
