ADFS Federations Service rename with Azure Pack as Relying Party Trust

A week ago I was confronted to an issue with ADFS with Forms Based Authentication(FBA) and Windows Azure Pack.


The environment was setup several months ago for a Proof of Concept of Windows Azure Pack and only working with ADFS and Windows Authentication because there was no requirement to used FBA and there was also no Web Application Proxy involved. All was working fine but the customer decided to setup FBA and a web application proxy. Unfortunately, the web application proxy was not working and keeps prompting the FBA login page.

After several hours of troubleshooting the issue was drilled down to a problem with the FBA on the ADFS server. But why was Windows Authentication working and FBA not. To exclude possible Windows Azure Pack/relying pary issue’s I started testing with the page.

Eventually it turned out that the Federations Service FQDN had changed. From to The rename was not done correctly and since I had a lot of trouble figuring it out with some colleague’s i decided to write a blog about it.


So when renaming the ADFS FQDN from to the SPN was forgotten for the ADFS Service account. The SPN was left on http/ and needed to be changed to http/

After this was fixed, I still received logon screens on the FBA page and could not login. Next problem, the Token-Signing and Token-Decrypting certificates were incorrect. Since there are lots of blogs discussing how to update the Token Certificates in ADFS I will not discuss this but I renewed the Token-Signing en Token-Decrypting certificates. Restarted the ADFS service and tried a logon on the now i was able to logon!

Now I was able to login correctly through the FBA login page for the Windows Azure Pack Admin and Tenant sites, but after login both sites threw an Error 500 page.
The event logs of the Azure pack web servers gave the following errors:


Log Name: Microsoft-WindowsAzurePack-MgmtSvc-TenantSite/Operational
Source:  Microsoft-WindowsAzurePack-MgmtSvc-TenantSite
Date: 8/13/2015 2:27:09 PM
Event ID: 12
Task Category: (65522)
Level: Error
Keywords: None
User: IIS APPPOOL\MgmtSvc-TenantSite
Computer: DMZTEN01.domain.local
Error:ErrorController: Url:, operationName:Error.Index, version:, accept language:en-US, subscription Id:, client request Id:, principal Id:, page request Id:, server request id:


Log Name:  Microsoft-WindowsAzurePack-MgmtSvc-TenantSite/Operational
Source:        Microsoft-WindowsAzurePack-MgmtSvc-TenantSite
Date:          8/13/2015 2:27:09 PM
Event ID:      12
Task Category: (65522)
Level:         Error
Keywords:      None
User:          IIS APPPOOL\MgmtSvc-TenantSite
Computer:      DMZTEN01.domain.local

Description:Error:Unhandled exception: SecurityTokenValidationException: Jwt10329: Unable to validate signature, Configuration.IssuerTokenResolver.ResolveToken returned null. jwt.Header.SigningKeyIdentifier: ‘SecurityKeyIdentifier


Since the Windows Azure Pack websites have their relying party trust information in a database we need to run some powershell commands to get the new certificate information in the database. On the Azure Pack web server (were the Azure Pack Powershell API is installed) run the following PowerShell command:

$connectionstring ='Server=DMZSQL01;Initial Catalog=Microsoft.MgmtSvc.Config;Integrated Security=SSPI'
Set-MgmtSvcRelyingPartySettings -Target Tenant -MetadataEndpoint ‘‘ -ConnectionString $ConnectionString
Set-MgmtSvcRelyingPartySettings -Target Admin -MetadataEndpoint ‘‘ -ConnectionString $ConnectionString

If you’re SQL server uses SQL authentication instead of Windows Auhtentication you need:

$ConnectionString = ‘Data Source=DMZSQL01;Initial Catalog=Microsoft.MgmtSvc.Config;User ID=sa;Password=putyourpasswordhere′

This wil update the database with the new token certificates. After this the new token certificate information is in the database and both portals are accessable again.

Specials Thanks to: @Sander Berkhouwer, @Mark Scholman and @Ronny de Jong for assisting with throubleshooting!

Leave a Comment