0

I need advisory support on my issue with registered application on AAD. When we registered the app with AAD for SSO using SAML it was working fine initially. But now it throws error whenever we tried to login to that app using AAD user cred. The login was working good in edge,chrome private mode but it is not working in normal mode. When we check the saml trace. We see that there is incorrect date & Time showing in SAML response from AAD. It shows 2020 year in response when the app is configured on AAD. I dont have the app access as it is of our client which we support. So need an advice as why incorrect date and time is showing in SAML response (when in normal mode) but in private mode login works without any issues.

Tried clearing cache and cookies, resync edge profiles but still the error reoccurs again.

Chinook'93
  • 1
  • 1
  • Can you show us exactly what you saw (with redactions, as necessary)? **Exactly** which parts of the SAML response had incorrect dates/times? I'm wondering if you maybe saw a benign old date (e.g. a not-valid-before) or something else (e.g. many Azure services use ISO 8601-style datetimes as API or service version indicators (e.g. all my Azure SAS URIs have `sv=2021-10-04` in them, which is confusing when one is looking for the expiry datetime. – Dai May 08 '23 at 13:04
  • Hi we trace the saml response. There is no ADSTS error showing in login. It just says incorrect username and password. However in SAML response AuthnInstant='2023-01-25T01:14:06.098Z' as it is of JAN 23 value so app is rejecting the auth in edge browser (normal mode) , working fine in chrome in normal and private mode. Just want to know why AAD is sending Jan 23 value in AuthnInstant='2023-01-25T01:14:06.098Z' in SAML response eventhough we did fresh auth to app. – Chinook'93 May 08 '23 at 17:39
  • Perhaps there's a dodgy browser extension (extensions are disabled by default in Incognito mode) that's breaking things? Also, you should file a support ticket in the Azure Portal over this. – Dai May 08 '23 at 17:41
  • can we check what browser ext is causing this. We are with MS Support from last 6 months but no success. We are still stuck in this from the time when we onboarded this app on AAD. – Chinook'93 May 09 '23 at 07:20
  • Can you reliably reproduce this issue in a controlled environment, such as a VM? If so, that’s all you need - just attach the VHD to the Azure ticket. – Dai May 09 '23 at 07:46
  • sure will look into this. also we are using hybrid infra with adfs. auth is taking at adfs for synced on-prem users. could fresh registration of app again resolve the issue? – Chinook'93 May 09 '23 at 08:21
  • I cannot offer any more advice without knowing all the details of your application - as well as your entire authX infrastructure - and even then there's thousands of possible causes. Currently your best (and probably only) option is to be able to reproduce it in a VM that the Azure support people can run themselves to see the issue - and then fix it. – Dai May 09 '23 at 08:27

1 Answers1

0

Ran into this recently. AuthnInstant is the original login date for the session and Azure does not change it even as you refresh your session over time. With a private mode azure updates the date

It is fairly easy to work around. In Azure Enterprise Applications access the application and then create a new Conditional Access policy

Ensure that only the one app is specified and set the Session Sign in frequency to a low enough value. For our app we finally had to set it to 1 hour. Four hours was too long but I did not try 2 hours.

This forces a new azure login after one hour when you try to access the application again. AuthnInstant is updated to the new time and everything works. You may need to play with the time frame to get a value that works.

Timothy Legge
  • 459
  • 1
  • 4
  • 5