ADFS Token Signing Error (Time Driven)

ADFS servers are comprised for Federation servers which are in your domain and do the "federation" and the ADS WAP (Web Application proxy) servers that present the website to the user when you are federated.

The ADFS WAP server talks to the Federation server to sign your login request with the token signing request which is protected by a certificate that signs the request, however this can go wrong and it can use a lot of issues, especially if your domain is federated and people need to use the ADFS to login to resources.


This means certificates and therefore time are critical to the ADFS services, so if for example you clock skews to the future, and in this this example lets use the date 01/08/2055 and that actual date is 06/06/2023 this will cause lots of issues with your ADFS service, also if you have "certificate rollover enabled" which you can check with this command, from the ADFS federation server:


Get-AdfsProperties | fl *roll*

If this return this:


AutoCertificateRollover     : True
CertificateRolloverInterval : 360

Then you will likely need to make to immediate changes to keep ADFS online, or if in my example you have already lost ADFS as a service, so first see the thresholds for when this process is activated with this command:

Get-AdfsProperties | fl *Threshold*

This will return this, as below with the important stuff in green:

CertificateCriticalThreshold   : 2
CertificateGenerationThreshold : 20
CertificatePromotionThreshold  : 5

This tells us that in 20 days from the certificate expiring the token signing and the decryption certificate will generate new ones in 20 days and make then active 5 days after that, which means as 2051 is more than 25 days in the future, this system has already automatically activated those new certificates and removed the old ones, amaing.

This means all your federated services including Office 365 are now using a "new" token signing certificate that starts in the future, and based on the date these new token signing certificates will be active from the year 2051 - that is bad, this means all your federated logins are offline, if people have authenticated when they next require an authentication it will fail and future authentication will also fail.

I observed the error as shown below, in many cases updating the time on the affected server will resolve the issue, but if you are unlukcy to have it happen at the wrong time and the "auto rollover" has activated, you need to take action, like now.....

Federation Server Errors

Error 1

The Federation Service encountered an error while processing the WS-Trust request.
Request type: http://schemas.microsoft.com/idfx/requesttype/issue 

Additional Data
Exception details:
System.ArgumentNullException: Value cannot be null.

Parameter name: certificate
   at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
   at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result)
   at
Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet)


Error 2

The federation server proxy was not able to authenticate to the Federation Service. 

User Action 

Ensure that the proxy is trusted by the Federation Service. To do this, log on to the proxy computer with the host name that is identified in the certificate subject name and re-establish trust between the proxy and the Federation Service using the Install-WebApplicationProxy cmdlet. 

Additional Data 

Subject Name:
CN=ADFS-WAP-1

Thumbprint:
<certificate thumbprint>

ADFS WAP Errors

Error 1

Unable to retrieve proxy configuration data from the Federation Service. 

Additional Data 

Trust Certificate Thumbprint:
<certificate thumbprint>

Status Code:
Unauthorized 

Exception details:
System.Net.WebException: The remote server returned an error: (401) Unauthorized.
   at System.Net.HttpWebRequest.GetResponse()
   at Microsoft.IdentityServer.Management.Proxy.StsConfigurationProvider.GetStsProxyConfiguration()

Error 2

The federation server proxy was unable to complete a request to the Federation Service at address 'https://adfs.bear.cloud/adfs/ls/IdpInitiatedSignOn.aspx' because of a time-out. This might mean that the Federation Service is currently unavailable. 

User Action 

Verify that the Federation Service is running.

Resolution 

Update Federation Certificates

This fix will only fix the issues outline above, so if you symptoms are different, do just not run these commands in the hope it will fix you issue, it could make it worse, but if they are the same and you cannot on the "ADFS WAP servers" start the "WAP service" with Unauthorised and the ADFS cannot start due to "certificates being outside the system clock requirements" then read on....

First we need to generate new certificates in the date range that is valid, so to do this we need these commands, if you do not have rollover enabled you need to enable it to manually generate the certificates.....

Set-ADFSProperties -AutoCertificateRollover $true
Update-AdfsCertificate -CertificateType Token-Decrypting
Update-AdfsCertificate -CertificateType Token-Signing
Set-ADFSProperties -AutoCertificateRollover $false

Right once that is done, you need to start to "AD FS" console on the Federation server, and navigate Services and Certificates,  you will see the certificates, in this example you can only see Primary, but you will have a Secondary as well, right click the secondary and choose "Set as Primary" 

This needs to be done for both the token signing and token decrypting....



Caution: Once the correct Primary certificate is selected, this will update all your federation servers, however you will need to restart the ADFS Federation server on ALL servers for this change to take effect.

Update XML with Office 365

If you are using Office 365, you will need to update the Federation with Offfice 365 to include the new certificate, to complete this follow these steps:

Connect-Msolservice
Set-MSOLADFSContext –Computer:<AD FS Server Name>
Update-MSOLFederatedDomain –DomainName:<domain name> 

The <AD FS Server Name> will need the be the computer name of one of your Federation servers, and the <domain name> will need to be the primary domain in Office 365.

The Set-MSOLADFSContext requires you to be a local administrator on the ADFS federation server.

Once this command is complete, you will then be able to authenticate to Office 365 once again with the new certificate.

Rebuild Federation with ADFS WAP

Now you need to re-establish the trust from the WAP to the Federation, to complete this start a powershell window as a administrator and run this:

Install-WebApplicationProxy

This will then ask you for the following details, which are shown below as a guide, this is interactive.

Credentials <ADFS administrator credentials>
FederationServiceName <adfs service name>
CertificateThumbprint <service communication certtificate thumbprint>

This will then rebuild the trust and get the WAP server back online, it will automatically start the service as well, then you should be all back online.

Previous Post Next Post

نموذج الاتصال