Is one system observing Daylight Savings Time and the other is not?
> On Sep 17, 2021, at 08:14, Jonathan Charles <jonv...@gmail.com> wrote: > > > Here is another one that failed... but the timestamp is not off... > > 2021-09-15 16:06:26,226 DEBUG [http-nio-81-exec-4] fappend.SamlLogger - > SAML2Utils.checkConditions: NotOnOrAfter Condition = Wed Sep 15 22:06:26 UTC > 2021 > > 2021-09-15 16:06:26,226 DEBUG [http-nio-81-exec-4] fappend.SamlLogger - > SAML2Utils.checkConditions: NotBefore Condition = Wed Sep 15 21:06:26 UTC 2021 > > 2021-09-15 16:06:26,226 DEBUG [http-nio-81-exec-4] fappend.SamlLogger - > SAML2Utils.checkConditions: The assertion does not meet NotOnOrAfter or > NotBefore condition. > > > >> On Fri, Sep 17, 2021 at 8:00 AM Jonathan Charles <jonv...@gmail.com> wrote: >> The error message in the Cisco traces (SSO) is: >> >> 2021-09-15 16:07:43,791 DEBUG [http-nio-81-exec-22] fappend.SamlLogger - >> SAML2Utils.checkConditions: NotOnOrAfter Condition = Wed Sep 15 22:07:44 UTC >> 2021 - this time is 17:07:44 CDT >> >> 2021-09-15 16:07:43,791 DEBUG [http-nio-81-exec-22] fappend.SamlLogger - >> SAML2Utils.checkConditions: NotBefore Condition = Wed Sep 15 21:07:44 UTC >> 2021 - this time is 16:07:44 CDT >> >> >> 2021-09-15 15:25:10,642 ERROR [http-nio-81-exec-10] >> authentication.SAMLAuthenticator - Error while processing saml response The >> time in the Assertion's Condition is invalid. >> com.sun.identity.saml2.common.SAML2Exception: The time in the Assertion's >> Condition is invalid. >> >> Basically what appears to be occurring is we get a NotBefore of 1 second >> after our request came in (16:07:43) and it gets killed.... >> >> The real question is what they need to do on the ADFS side to fix this... >> why are they sending us a time in the future? The argument is NTP is off by >> one second for one of the servers (all of them show synched)... >> >> >> Jonathan >> >>> On Thu, Sep 16, 2021 at 8:29 PM Kent Roberts <k...@fredf.org> wrote: >>> Oh, ok if I mis-understood then, yes a SAML trace would be good, as well as >>> knowing is this new or did it work. Seems similar to what I have seen in >>> UCCE with the packet stuff not signed or wrong encryption type… course >>> thats UCCE vs CUCM, but usually cucm just works… >>> >>> >>>> On Sep 16, 2021, at 6:45 PM, Johnson, Tim <johns...@cmich.edu> wrote: >>>> >>>> Nah, looks like he said logging into CCM Admin pages, with AD accounts, so >>>> all areas of the web UI (I believe). The NTP errors that I’ve seen are >>>> presented as SAML assertion errors. >>>> >>>> I’m curious if this is a new SSO config, or if it was working properly and >>>> something’s changed. >>>> >>>> From: cisco-voip <cisco-voip-boun...@puck.nether.net> On Behalf Of Kent >>>> Roberts >>>> Sent: Thursday, September 16, 2021 8:37 PM >>>> To: Matthew Loraditch <mloradi...@heliontechnologies.com> >>>> Cc: cisco-voip@puck.nether.net >>>> Subject: [External] Re: [cisco-voip] Error Processing SAML Response >>>> >>>> Remember he said it also was happening on the CUCM Admin account which has >>>> nothing to do with SSO/SAML. So means its most likely internal to cucm... >>>> >>>> >>>> On Sep 16, 2021, at 4:36 PM, Matthew Loraditch >>>> <mloradi...@heliontechnologies.com> wrote: >>>> >>>> The logs are pretty clear when its a time difference as the error. I’ve >>>> not seen it randomly occur but definitely the error will be it’s time and >>>> may even show the difference. >>>> >>>> Its the 4j log file for sso I believe >>>> >>>> Get Outlook for iOS >>>> >>>> Matthew Loraditch >>>> Sr. Network Engineer >>>> (He/Him/His) >>>> p: 443.541.1518 >>>> w: www.heliontechnologies.com >>>> | >>>> e: mloradi...@heliontechnologies.com >>>> <image657209.png> >>>> <image487691.png> >>>> <image529913.png> >>>> <image776611.png> >>>> From: cisco-voip <cisco-voip-boun...@puck.nether.net> on behalf of Lelio >>>> Fulgenzi <le...@uoguelph.ca> >>>> Sent: Thursday, September 16, 2021 4:32:12 PM >>>> To: Jonathan Charles <jonv...@gmail.com>; Benjamin Turner >>>> <benmtur...@hotmail.com> >>>> Cc: cisco-voip@puck.nether.net <cisco-voip@puck.nether.net> >>>> Subject: Re: [cisco-voip] Error Processing SAML Response >>>> >>>> >>>> [EXTERNAL] >>>> >>>> >>>> Have you been able to confirm the time difference? >>>> >>>> I’m not trying to take their side of things, but if it’s minutes off, I >>>> wouldn’t doubt that’s possible. SSO is highly secure, right? A time >>>> difference might be enough to throw it off? >>>> >>>> Here’s reference: >>>> >>>> https://support.pingidentity.com/s/article/Accounting-for-Time-Drift-Between-SAML-Endpoints50907 >>>> >>>> >>>> >>>> From: cisco-voip <cisco-voip-boun...@puck.nether.net> On Behalf Of >>>> Jonathan Charles >>>> Sent: Thursday, September 16, 2021 6:23 PM >>>> To: Benjamin Turner <benmtur...@hotmail.com> >>>> Cc: cisco-voip@puck.nether.net >>>> Subject: Re: [cisco-voip] Error Processing SAML Response >>>> >>>> CAUTION: This email originated from outside of the University of Guelph. >>>> Do not click links or open attachments unless you recognize the sender and >>>> know the content is safe. If in doubt, forward suspicious emails to >>>> ith...@uoguelph.ca >>>> >>>> No... TBH, I have never heard of it... >>>> >>>> TAC is hyper-asserting that the issue is time mismatch between CUCM/CUC >>>> and ADFS... >>>> >>>> >>>> Jonathan >>>> >>>> On Thu, Sep 16, 2021 at 4:08 PM Benjamin Turner <benmtur...@hotmail.com> >>>> wrote: >>>> Have you tried to run a SAML Tracer? >>>> >>>> Sincerely, >>>> Benjamin M. Turner >>>> From: cisco-voip <cisco-voip-boun...@puck.nether.net> on behalf of >>>> Jonathan Charles <jonv...@gmail.com> >>>> Sent: Thursday, September 16, 2021 4:56:48 PM >>>> To: cisco-voip@puck.nether.net <cisco-voip@puck.nether.net> >>>> Subject: [cisco-voip] Error Processing SAML Response >>>> >>>> So, users are randomly getting the above error when logging into CUCM >>>> UCMUser or CUC Inbox... we are also getting it using AD credentials into >>>> admin pages for CUCM/CUC/etc. >>>> >>>> For a user, it will work find repeatedly, then you will get the error, >>>> close your browser, and reopen, still get the error for a few minutes. >>>> Then later it will work. When a user is affected, other users work fine. >>>> >>>> TAC is saying it is an NTP issue, however, NTP between CUCM 12.5 and IdP >>>> (ADFS 2.0) is fine. >>>> >>>> Pings are around 1ms between servers. >>>> >>>> Any ideas? >>>> >>>> >>>> Jonathan >>>> >>>> >>>> >>>> _______________________________________________ >>>> cisco-voip mailing list >>>> cisco-voip@puck.nether.net >>>> https://puck.nether.net/mailman/listinfo/cisco-voip >>> >>> _______________________________________________ >>> cisco-voip mailing list >>> cisco-voip@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/cisco-voip > _______________________________________________ > cisco-voip mailing list > cisco-voip@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
