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 <https://aka.ms/o0ukef> >> >> *Matthew Loraditch*** >> *Sr. Network Engineer* >> *(He/Him/His)* >> p: *443.541.1518* <443.541.1518> >> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/> >> | >> e: *mloradi...@heliontechnologies.com* >> <mloradi...@heliontechnologies.com> >> <image657209.png> <http://www.heliontechnologies.com/> >> <image487691.png> <https://facebook.com/heliontech> >> <image529913.png> <https://twitter.com/heliontech> >> <image776611.png> <https://www.linkedin.com/company/helion-technologies> >> ------------------------------ >> *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