Yep, this is totally it for that issue. Very undocumented. I added some more details and the relevant logs/other commands below. 5 time sources seems overkill. Segal's Law: A man with a watch knows what time it is. A man with two watches is never sure. Much appreciate the pointers though. Did you wind up using the Skew or the Multiple NTP Servers or both? This is an article on setting up the functionality re: multiple NTP Services. I didn't use it because the skew solved it for me. https://blogs.msdn.microsoft.com/w32time/2008/02/26/configuring-the-time-service-ntpserver-and-specialpollinterval/ I feel like using this config with SAML might confuse the issue more since it's pretty clearly some kind of latency/process time issue, IMO, instead of just a clock sync issue. ... View more

I can confirm at this time that changing the NotBefore to skew by 1-2 minutes resolves the clock issue.   Some Domain Admins likely won't allow this, but, I'm in a lab at the moment, so it's fine.   In any case, to account for the overly zealous lockdown of the instants involved, you can skew your NotBefore time to some other period of time besides 0 (the default).   This param isn't exposed by the ADFS GUI (at least in ADFS 2.0; unconfirmed in 3.0) so you have to use Powershell.   The relevant commands are:   List all Relying Party Trusts Get-ADFSRelyingPartyTrust List the specific Relying Party Trust Get-ADFSRelyingPartyTrust -identifier <the "Identifier" you found above> Change the NotBefore Skew Set-ADFSRelyingPartyTrust -TargetIdentifier <the "Identifier" again> -NotBeforeSkew 2   The value is in minutes.   As soon as I changed the Skew, I hit F5 on the browser and the previously failing response was successful. ... View more

Hey Bill,   It's specific to the IdS which is coresident on CUIC.   The issue appears to be that all of our machines are sync'ing to a single NTP source.   In the IdP response (ADFS 2.0 on the domain controller) I'm seeing a failure of:   2019-01-02 14:54:55.414 CST(-0600) [IdSEndPoints-SAML-13] INFO com.cisco.ccbu.ids SAML2SPAdapter.java:82 - SSO Failure response from fedlet <...snip...> <Conditions NotBefore="2019-01-02T20:54:55.624Z" NotOnOrAfter="2019-01-02T21:54:55.624Z"> <...snip...> <AuthnStatement AuthnInstant="2019-01-02T20:54:55.542Z" <snip>   This produces this error:   2019-01-02 14:54:55.414 CST(-0600) [IdSEndPoints-SAML-13]         ERROR com.cisco.ccbu.ids IdSSAMLAsyncServlet.java:302 - SAML response processing failed with exception com.sun.identity.saml2.common.SAML2Exception: The time in the Assertion's Condition is invalid.   By the rules of how SAML works,  NotBefore is a time instant that says the request can not be confirmed before that time  and NotOnOrAfter is another time instant after which the subject can no longer be confirmed.   So I can see where the assertion is going sideways because its restricted to a very limited window.   I'm looking into the above suggestion of using multiple NTP sources at this time though I'm not entirely sure how that might solve it.   What I *do* know that works is rebooting the CUIC/IdS node, which allows successful responses for a period of time.   That's obviously not optimal so I am still looking for a real fix.   I believe that it may have to do with modifying the SAML response to allow a broader NotBefore value but will report back here once I confirm either of the above (NTP or NotBefore) ... View more