Azure AD Signin Issue

MrEco 6

We have made a setup where we logon our users with Azure AD and MFA to VPN.
The works excellent.
Howeweer, since a couple of weeks we have some users that report that they cannot logon.
The message that appears in the sign-in log in Azure AD is:

The session has expired or is invalid due to sign-in frequency checks by conditional access.
MFA requirement satisfied by claim in the token.

If we then revoke the user session, the user can logon again.

The sign-in frequency for the application is set to 1 hour in the conditional access policy.

We can't find the source of this problem.

AmanpreetSingh-MSFT 56,616 Reputation points

2022-05-18T05:29:05.137+00:00

@MrEco • Please share Correlation ID, Request ID, and Timestamp from the sign-in log. I will try to debug and track the source for you.
MrEco 6 Reputation points

2022-05-18T07:20:45.26+00:00

E.g. these attempts were made:

Date
5/17/2022, 10:03:13 AM
Request ID
c35b519c-abe8-4e5f-99dd-2e29bc3d0800
Correlation ID
99d2c19f-101c-4931-8f68-9e16b02a3813

Date
5/17/2022, 10:21:29 AM
Request ID
792d1a49-f7ab-41c8-b203-1ff83c0c0900
Correlation ID
7c1d594b-5bf6-4356-8191-38d51eaa3906

Date
5/17/2022, 10:24:57 AM
Request ID
4560c035-d8cb-45ed-9768-567616350b00
Correlation ID
ec40ceee-2c42-45ae-8bb4-1f143376173e

Date
5/17/2022, 10:32:49 AM
Request ID
993306f1-c65d-4659-bd02-a91327230600
Correlation ID
df736062-0661-454a-8fc2-c90942c46969

And then after a revoke the signin works.

The revoke:

Date
Invalid DateTime
Activity Type
Update StsRefreshTokenValidFrom Timestamp
Correlation ID
eda65aec-e166-4fea-8119-736a1e30f64c

And then the signin:

Date
5/17/2022, 10:43:45 AM
Request ID
1eb44828-a8f6-4266-a466-7db545d10000
Correlation ID
2faa13c0-1d28-4986-af91-0339a90717e7

Please note that the revoke took place at 10:13 and after that the login failed for three times and then succeeded only half an hour later.
AmanpreetSingh-MSFT 56,616 Reputation points

2022-05-18T16:54:45.02+00:00

@MrEco • What is the timezone for the timestamp?
MrEco 6 Reputation points

2022-05-19T07:45:56.993+00:00

It's UTC+2.

1 answer

AmanpreetSingh-MSFT 56,616 Reputation points

2022-05-20T07:02:12.007+00:00
Hi @MrEco • Thank you for providing the required information.

By tracking the requests (before and after session revocation) at our backend, I can see that the conditional access policy "MFA for VPN Rxx Winxxxx" conditional access policy with the sign-in frequency of 1 hour is getting applied. In both cases, the user presented a credential authenticated at 4:16:50 PM on May 16, 2022, and the request was made at 8:03:13 AM and 8:42:57 AM on May 17, 2022. As this was beyond the sign-in frequency window of 1 hour, the credential was ignored. This resulted in the below error:

AADSTS70044: The session has expired or is invalid due to sign-in frequency checks by conditional access.

To resolve the issue, this error needs to be handled by the application and the user should be prompted to get re-authenticated. I would suggest you engage with the application vendor to get this logic added to the application.

-----------------------------------------------------------------------------------------------------------

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.
Please sign in to rate this answer.
MrEco 6 Reputation points

2022-05-20T09:55:35.903+00:00

Hello @AmanpreetSingh-MSFT ,

Thank you for responding.
The thing is that the user is actually prompted to re-authenticate by the application, but apparently each time the 'old' credential is being sent.
What else could the application do, except prompt for re-authentication?

AmanpreetSingh-MSFT 56,616 Reputation points

2022-05-23T09:52:01.567+00:00

@MrEco • Old credentials are usually sent when the authentication happens silently using Refresh Token/Primary Refresh Token (PRT), which are long-lived tokens. In order to avoid that and to force interactive authentication, the application must be configured to use the prompt=login parameter in the authentication request. The prompt parameter is an OAuth/OIDC parameter to force interactive authentication and bypass cookies/PRT. If your application is federated using SAML protocol, your application must include forceAuthN=true in the authentication request for this purpose.

AmanpreetSingh-MSFT 56,616 Reputation points

2022-05-30T07:27:44.967+00:00

Hi @MrEco • Just checking if you had a chance to test it out.

MrEco 6 Reputation points

2022-05-30T13:12:38.447+00:00

Hello @AmanpreetSingh-MSFT ,

Thank you for your explanation. I was on leave last week, but will test this week.
We do use SAML and I do see the application support 'force authentication', so we should be able to test this.
I'll let you know the outcome.

MrEco 6 Reputation points

2022-05-30T13:50:36.673+00:00

@AmanpreetSingh-MSFT ,

I have tested this and the login procedure works just fine, but there's a undesirable side effect.
With 'forceAuthN=true' the user is also asked for his username.
With our SSO policy, we want to require this as infrequent as possible.
Without 'forceAuthN=true' the user has this experience:

Start application

Choose the account that is already connected to Windows

Logon to ADFS (e-mail pre-filled), we use ADFS for Azure AD authentication

Provide MFA

Logged in

With 'forceAuthN=true' the user has this experience:

Start application

Enter account to logon with

Logon to ADFS (e-mail pre-filled), we use ADFS for Azure AD authentication

Provide MFA

Logged in

So, the user is now prompted to enter his e-mailaddress (username) which is not desirable.

I haven't tested it for the concerned users in our production environment (3 or 4 users out of 2000 users experience the issue), but I'm sure it will solve it for them.
The question is, do we want to bother all users with entering the username again, if it only happens to a couple of users.

The strange part is that is only happens to a few of the users (and to them it occurs on a daily basis). After revoking the sessions in Azure AD, they can login just fine, but next day it's the same over again.

Why would this be happening to these individual users?

AmanpreetSingh-MSFT 56,616 Reputation points

2022-05-31T15:01:58.06+00:00

@MrEco • If few users are affected, you should consider comparing the working vs non-working users. Based on the desirable behavior, I suppose the devices are Hybrid Joined and get Primary Refresh Token (PRT) to facilitate SSO. Try to compare Event Viewer > Application and Services logs > Microsoft > Windows > AAD > operational logs of working and non-working users to identify why credentials from the previous day are being submitted as the PRT should get renewed when the users sign in the next day.

MrEco 6 Reputation points

2022-06-02T07:14:52.957+00:00

Thanks for pointing that out.
I'll dig into that event log to see if I can find the reason.

Bart van den Donk 1 Reputation point

2024-07-09T08:04:48.9+00:00

MrEco,
We have experienced a similar problem.
Users use SSO.
As soon as they start Outlook they are logged-out of Outlook and have to reauthenticate.
This only happens for a small amount of users.
Did you find the source?
Which Event-ID's should I look for.
Thanks in advance.

P.S.
In my search for a solution I came across this link from Mfst:
https://learn.microsoft.com/en-GB/outlook/troubleshoot/connectivity/outlook-shows-disconnected-if-ipv6-is-enabled

MrEco 6 Reputation points

2024-07-16T09:58:02.1166667+00:00

In our case, if I recall correctly, we had the ADFS extranet lockout feature enabled, which caused the issue. If believe we had certain users that got lockout due to an incorrect password on e.g. a phone and then (because of the signin attempt every few seconds / minutes) got locked every once and a while. ADFS didn't tell the account was locked, it just told that the signin information was not correct.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Azure AD Signin Issue

1 answer

Your answer