Azure-docs: Link to more technical detail

[cronq]

I understand this is a HowTo page, but it references being successor to 'Configuration token lifetimes'. Please link to similar/deeper documentation referencing how the sign-in frequency control actually interacts with token lifetimes, which token(s) are changed, etc. I think it would also be useful to describe how/if this impacts MFA claims/tokens.

(Thanks for the work, this is a great new feature!)

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 9561a367-20d8-62e9-57e5-694bab4c0878
• Version Independent ID: a7c757e0-052b-fc42-70c5-030081baa573
• Content: Configure authentication session management with Azure Active Directory conditional access
• Content Source: articles/active-directory/conditional-access/howto-conditional-access-session-lifetime.md
• Service: active-directory
• Sub-service: conditional-access
• GitHub Login: @MicrosoftGuyJFlo
• Microsoft Alias: joflore

[SaurabhSharma-MSFT]

@cronq Thanks for the feedback ! I have assigned this issue to content author to investigate and update the document as appropriate.

[officechris]

Can someone easily answer if the above "session lifetime" policies impacts MFA claims/tokens? I assume YES, anyone tested / confirmed?

[cronq]

I have both the force MFA and sign-in frequency enable in my CA policy (not sure if that makes a difference). When the token expires and I try to access a resource, I'm prompted for both password and MFA. That said, how is that actually impacting the underlying tokens? Is it changing the lifetime of the refresh token, MF refresh token, SF or MF session token...or some combo of these.

[officechris]

I have both the force MFA and sign-in frequency enable in my CA policy (not sure if that makes a difference). When the token expires and I try to access a resource, I'm prompted for both password and MFA. That said, how is that actually impacting the underlying tokens? Is it changing the lifetime of the refresh token, MF refresh token, SF or MF session token...or some combo of these.

I assume this is also the case if you use the "remember Multi-Factor Authentication" checkbox if you have that configured? Say that's set to the default 7 days, I assume your CA policy overrides that and forces for Login/MFA when the Session Timeout value is hit?

[cblomart]

We have similar questions regarding Sharepoint Online (SPO):
Is SPO Idle-Timeout in any way comparable to sign-in frequency of Contditional Access (CA).

Having a clear explanation of that would help us decide where the configuration should be done. Currently we configured it in both places SPO & CA.

[MicrosoftGuyJFlo]

Forwarded to the product group for them to respond. #product-question

[elcarlosadrian]

SignIn frequency is just about user's authentication timestamp: this feature doesn't change token lifetimes, nor controls MFA lifetime: it's just about when to prompt the user to re-authenticate.

[MicrosoftGuyJFlo]

Thanks @elcarlosadrian! @cronq does this answer your question?

[annabarh]

SPO Idle Timeout is a different feature. It controls how long a session stays alive after user became inactive. This feature controls how often users are prompted for credentials whether users are active in the session. They are complimentary but different features.

[cblomart]

Thanks,

it a bit clearer to me know.

One thing that led me to confusion about sign in frequency is the mention of a rolling window (default is a rolling window of 90 days).

• There is no indication on how this window rolls.
• As the sign in frequency setting is purely a time frame (i.e. 1 day), it was not clear if the notion of rolling window stays.

Cédric

PS: i would have prefered to have this kind of settings only in one place but it looks liks CA + SPO is better.

[annabarh]

the rolling window is only applicable to the default sign-in frequency.As for the having two different places for the setting: these are different settings even though they are related. The inactivity timeout is a per app setting as it requires the app to detect that user is being inactive. Does it make sense?

[cblomart]

I get that an app has the finer degree of control over the session. So it makes sense that inactivity is decided there.

I still don’t get what is meant by rolling Windows. Maybe is it less important as we have no control over it (and maybe don’t require it).

You know customer imagination... I dumbly thought that token refresh could be a sign of activity and maybe were involved in the notion of rolling window. Silly me.

[cronq]

SignIn frequency is just about user's authentication timestamp: this feature doesn't change token lifetimes, nor controls MFA lifetime: it's just about when to prompt the user to re-authenticate.

Thanks @elcarlosadrian! @cronq does this answer your question?

I suppose it answers the question but I am not clear at all on how it actually works. When I talked to support, they said the it changed the lifetime of the session token, which I guess is wrong. The point of this thread is that while the howto describes the feature, it doesn't link to deeper technical references like this: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow#protocol-diagram. And when reviewing this type of documentation, I still don't understand where the auth timestamp is set. Is it a claim in a token or just something stored in an auth table on the backend? And when is that timestamp referenced? I assume when requesting a new access token, right?

[MicrosoftGuyJFlo]

@annabarh can you help provide some additional clarity for @cblomart and @cronq ?

[KlaBier]

Hi,
I want to modify the AccessTokenLifetime to 30min. I understand that the "configurable token lifetimes feature" will be depricated and that I have to use then the "authentication session management capabilities" functionality. But I can not see how I can modify the AccessTokenLifetime? Maybe I have a wrong understanding. Can someone help? Thanks a lot :-)

[RaghuramP]

@KlaBier refer below article, it has details to get default policy and how to change ATL.
https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-configurable-token-lifetimes

[KlaBier]

@RaghuramP: thanks for sharing this. I understand from the article that ATL is not longer supported after Nov, 1. This will be replaced then with functionality in Azure Active Directory Conditional Access. Isn't it correct? When I check the CA Policy today I cannot see a possibility to manipulate ATL.

[KehindeOwens]

I have the same issue as KlaBier. Microsoft is mentioning that these conditional access rules will supersede ATL but I don't see how sign-in frequency or persistent sessions correlate with setting ATL to let's say "an hour". I'm not saying it doesn't, i'm just curious as to where this documentation is.

[MicrosoftGuyJFlo]

Assign @annabarh

[rynothopter]

How will these new Conditional Access controls impact customers that don't have Azure P1/P2 licensing?

Will customers who are currently federating O365 to an on-prem SSO like AD FS still be bound by the access/refresh token model or will this particular CA policy be made available to all non-Premium licensing levels?

[annabarh]

@cblomart, here is how rolling window works. When a refresh token is originally issued it has a lifetime of 90 days from the time it was issued. When it redeemed for an access token, a new refresh token issued it's lifetime of 90 days from the moment of issuance. So this 90 days window consistently rolls forward on every new token.

@cronq: the auth timestamp is in the token itself, it is not stored in the backend. elcarlosadrian actually implemented the feature, his reply is the correct one.

@KlaBier and @KehindeOwens, we updated the information: we have decided not to deprecate access token configurability for now.

@rynothopter, this policy is only available to Azure P1/P2 customers. Free customers will not be able to modify sign-in frequency and browser persistence

[daveba]

@annabarh has answered all questions pertaining to this issue. #please-close, but feel free to reopen if her answers don't solve your problem.

[allanwith]

I think it would be beneficial if the answer could be integrated into the main doc itself. I've already seen another website try to explain this, but they had misunderstood what signin frequency does. They thought it meant that you'd always get prompted after said period even if you'd been signed in in the mean time, but actually this seems to work exactly as before with the refresh tokens where it would get renewed with every new access. The difference seems to be that you can have different policies for different conditions, which is smart, but the article is not very clear on this.