You are viewing limited content. For full access, please sign in.

Question

Question

Okta NotOnOrfter condition is not satisfied

asked on December 3, 2024 Show version history

Wondering if anyone out there that has worked with Okta has seen the following error. I am configuring a dev Okta account as a SAML idP in Directory Server. Everything was going great until I tried to authenticate. When I click the SAML login button on the LFDSSTS page I am taken to the Okta login page as expected and am able to authenticate, but after doing so I am taken to mydomain/LFDSSTS/SAML2/SSO and presented with this error:

{"ErrorCode":null,"ShowReturnLink":true,"Error":true,"Message":"The identity provider may not be configured correctly.  Contact your administrator: ID4148: The Saml2SecurityToken is rejected because the SAML2:Assertion\u0027s NotOnOrAfter condition is not satisfied.\nNotOnOrAfter: \u002712/4/2024 2:52:12 AM\u0027\nCurrent time: \u002712/4/2024 3:47:11 AM\u0027"}

From what I have gathered from searching the internet is that there is some kind of a time issue. I have verified that the time on my server is correct, so I'm not sure what else to check. Any help would be appreciated. I am using Directory Server 12.0.2410.65.

0 0

Answer

SELECTED ANSWER
replied on January 10

To add to this, for the clarity of other readers:

SAML handshakes exclusively use UTC. You can verify this by observing that all timestamps in both SAML requests and responses have the trailing “Z” character that indicates UTC. Time zones are not involved in the interaction, and changing the time zone settings on the machine didn’t change any SAML behavior.

The root issue was that the actual UTC clock was off by an hour. This looked like an incorrect time zone (offset of 1h more than expected). Manually changing the system clock hour through the timedate.cbl (classic Control Panel Date/Time) interface to match current local time corrected the underlying UTC time being wrong.

1 0

Replies

replied on January 10

In case anyone else comes across this, we were able to find a resolution.

The issue was that the UTC time reference on the LFDS server was an hour off, which caused a mismatch in the SAML token response. To correct this, I changed the machine clock by opening a PowerShell window and typing in timedate.cpl, which opens the old Control Panel clock settings. From there I adjusted the time zone to be correct and then also edited the time itself to the correct time.

2 0
SELECTED ANSWER
replied on January 10

To add to this, for the clarity of other readers:

SAML handshakes exclusively use UTC. You can verify this by observing that all timestamps in both SAML requests and responses have the trailing “Z” character that indicates UTC. Time zones are not involved in the interaction, and changing the time zone settings on the machine didn’t change any SAML behavior.

The root issue was that the actual UTC clock was off by an hour. This looked like an incorrect time zone (offset of 1h more than expected). Manually changing the system clock hour through the timedate.cbl (classic Control Panel Date/Time) interface to match current local time corrected the underlying UTC time being wrong.

1 0
replied on December 4, 2024

It looks to me like an expired cert that Okta is using to encrypt the response.

replied on December 4, 2024

Well, it gives you the timestamps it's working with right in the error message:

NotOnOrAfter: 12/4/2024 2:52:12 AM
Current time: 12/4/2024 3:47:11 AM

That looks very suspiciously like a five-minute validity period where one of the servers/services is off by an hour to me. I don't know when you made that specific request so couldn't say which is right.

I'd take a look at the actual Okta SAML response "NotOnOrAfter" Condition property and sanity check it against a known valid time source (NIST etc.) to verify that Okta isn't sending out responses that are already invalid at time of issue.

0 0
replied on December 4, 2024

I created an app in Okta using the same Okta tenant and connected it to Laserfiche Cloud and it works as expected, so I don't believe it is an Okta issue. I'll keep testing.

0 0
replied on January 10 Show version history

Just have to say - I totally called it from the start =P

0 0
replied on January 10

laugh

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.