WAP ADFS login loop due to clock skew breaking token cookie validation. How to adjust validation tolerance?

Question

WAP ADFS login loop due to clock skew breaking token cookie validation. How to adjust validation tolerance?

Manish Rahul 60

0 comments

2 answers

Your answer

Answer 1

Welcome to Microsoft Q&A!

Thank you for your question.

There is no supported or documented setting in AD FS or Web Application Proxy (WAP) to increase token or cookie validation tolerance for clock skew. The recommended approach is to correct time synchronization between all AD FS, WAP, and domain controller systems rather than attempting to adjust a validation window.

Authentication loops can occur when a WAP server's clock differs significantly from the AD FS farm. A time skew greater than 10 minutes between WAP and AD FS can result in login loops. The recommended resolution is to synchronize the system clocks and restart the WAP server to clear cached authentication state.

I would like to share the following recommended solutions that may you:

Verifying there is no time skew between AD FS and WAP servers.
Synchronizing all systems with a reliable enterprise NTP source.
Validating WAP trust and SSL certificate configuration if the issue persists.

If the environment uses SAML relying party trusts and the issue is related to strict NotBefore timestamp validation, AD FS provides a NotBeforeSkew setting on individual relying party trusts. However, this setting affects the timestamps on issued SAML assertions and is not a WAP token or cookie validation tolerance setting. As a result, it typically does not resolve WAP login-loop scenarios caused by server clock drift.

Reference: AD FS Troubleshooting - Proxy Trust Between WAP and AD FS Is Broken | Microsoft Learn

Configure the Root PDC with an Authoritative Time Source and Avoid a Widespread Time Skew - Microsoft Engage Center | Microsoft Learn

If the information provided is helpful, please click Accept Answer.

Thank you for choosing Microsoft Q&A!

Answer 2

There is no documented setting in the provided material to increase WAP or AD FS token/cookie validation tolerance for clock skew.

The supported fix is to remove the skew:

Check the time on all AD FS and WAP servers.
Sync all system clocks with the organization’s reliable time source.
Re-test sign-in after time is aligned.

If the issue is specifically affecting token acceptance because one server clock is ahead of another, that behavior is documented for AD FS-integrated scenarios. In that case, correcting the server clocks is the resolution rather than changing a tolerance value.

If the loop is occurring through WAP, also verify the WAP trust path basics that are called out for this symptom set:

Confirm there is no time skew between AD FS and WAP servers.
Check TLS/SSL certificate bindings on AD FS and WAP servers:
- Run Get-AdfsCertificate -CertificateType Service-Communications | select Thumbprint on the primary AD FS server.
- Run netsh http show sslcert on each AD FS and WAP server.
- Verify the hostname matches the federation service name.
- Verify the certificate thumbprint matches the certhash.
- Verify the CTL store name is AdfsTrustedDevices.
If needed, regenerate the AD FS SSL certificate bindings with:
- Set-AdfsSslCertificate -Thumbprint <thumbprint>
Check that there is no TLS/SSL termination device between WAP and AD FS, because that breaks WAP and AD FS communication based on client certificates.

For AD FS loop detection itself, the configurable values are only the loop detection thresholds, not token validation skew tolerance:

Set-AdfsProperties -LoopDetectionMaximumTokensIssuedInterval 5 -LoopDetectionTimeIntervalInSeconds 20
Set-AdfsProperties -EnableLoopDetection $false

Disabling loop detection is only for performance testing and should not be left disabled permanently, because it prevents protection against infinite loop states.