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 Thumbprinton the primary AD FS server. - Run
netsh http show sslcerton 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.
- Run
- 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.