How to Troubleshoot ADFS 2016/2019 and Wrong Federation Service Name (www)

November 7, 2019 Don Young

While installing Active Directory Federation Services 2016 (ADFS) recently, I ran into a problem where, after importing the certificate, the Federation Service Name defaulted to a namespace starting with ‘www’.  I could not change the name or the drop-down to select a different name.

As it turns out, the certificate provider automatically adds the ‘www’ DNS address as a subject alternative name on the cert.  For some reason, that is the name that the ADFS configuration is latching on to.  Maybe because the subject name of my cert is ‘enterpriseregistration.blah.com’ (long story) and it assumes that cannot be the right name to use?

 

 

 

 

 

Piecing several articles together I was able to find 2 ways to get the install completed with the correct name. Additionally, this also happens with ADFS 2019 and the workaround is the same.

Option 1 – Install ADFS 2016 Using Powershell

  1. Perform all the normal prerequisites required if you were going to use the GUI
    1. This is an absolutely fantastic article on how to do this: https://blogs.technet.microsoft.com/rmilne/2017/04/28/how-to-install-ad-fs-2016-for-office-365/
  2. Open Powershell and import the ADFS module
  3. If using a gMSA service account run the following substituting the correct values:

Install-AdfsFarm -CertificateThumbprint:"B67B94AF83WILLNOTWORK24652AFCF4C63B054D5" -FederationServiceDisplayName:"Blah STS" -FederationServiceName:"sts.blah.com" -GroupServiceAccountIdentifier:"BLAH\gMSA-STS$"

  1. If using a standard service account run the following substituting the correct values:

$serviceAccountCredential = Get-Credential -Message "Enter the credential for the Federation Service Account."

Install-AdfsFarm -CertificateThumbprint:"B67B94AF83WILLNOTWORK24652AFCF4C63B054D5" -FederationServiceDisplayName:"Blah STS" -FederationServiceName:"sts.blah.com" -ServiceAccountCredential:$serviceAccountCredential

  1. Complete the rest of the install as you normally would

Option 2 – Install ADFS Using GUI then update ADFS to use the correct Federation Service Name

  1. Perform the ADFS 2016 install using the GUI
    1. This is an absolutely fantastic article on how to do this: https://blogs.technet.microsoft.com/rmilne/2017/04/28/how-to-install-ad-fs-2016-for-office-365/
    2. When you import the cert and the wrong Federation Service Name is chosen, continue as if it were correct
  2. With the install complete, we can now update ADFS
  3. In the ADFS Console, right-click the top ‘ADFS’ folder and select ‘Edit Federation Service Properties’
  4. Update the ‘Federation Service Name’ and ‘Federation Service Identifier’ (easy enough)
  5. Running ‘Get-ADFSProperties’ you can see the updates have gone through
  6. Unfortunately, looking at the certs through the ADFS GUI, you will see the old address for the Token-decrypting and Token-signing certs
    1. This is because those certs were generated when the original Federation Service Name was used by the installer
  7. We can generate new certs by performing the following via Powershell:

Update-AdfsCertificate -CertificateType Token-decrypting

Update-AdfsCertificate -CertificateType Token-signing

  1. Great! …but now the GUI shows 2 certs for each service, the wrong one is set to the primary and it cannot be changed or deleted
  2. Before these can be updated, you must turn off the automatic certificate rollover feature by running the following command in PS:

Set-ADFSProperties -AutoCertificateRollover $false

  1. Using the GUI, you can now set the correct cert to be primary and remove the old one that has the wrong name
  2. Now you’ll want to turn automatic certificate rollover back on:

Set-ADFSProperties -AutoCertificateRollover $true

  1. Restart the ADFS service
  2. Now there’s one lingering item to cleanup. The certs still exist in the underlying OS.  In the past we would remove them using IIS but since ADFS 2016 does not use IIS, we must use NETSH
    1. Open a command prompt as an admin
    2. Run: NETSH SHOW HTTP SSLCERT
    3. You’ll notice that the old certs are still there
    4. To remove them, run the following commands:

NETSH HTTP DELETE SSLCERT hostnameport=www.blah.com:443

NETSH HTTP DELETE SSLCERT hostnameport=www.blah.com:49443

  1. Complete the rest of the install as you normally would

To me, the options are the lesser of two evils.  The Powershell method seems easier but you lose a lot of the interaction that happens through the GUI.

Previous Article
Office Explorers Special Edition – Episode 12: Top 10 Announcements at Microsoft Ignite
Office Explorers Special Edition – Episode 12: Top 10 Announcements at Microsoft Ignite

Kat and Rob are back with a special episode on Microsoft Ignite. There were a lot of exciting announcements...

Next Article
Thinking of Building a Digital Operating Model using the Cloud Adoption Framework for Azure? Ask the Smart Questions
Thinking of Building a Digital Operating Model using the Cloud Adoption Framework for Azure? Ask the Smart Questions

We talked before about the six decade war between agility and control.  That idea set a spark. A spark that...