Manage authentication sessions in Azure AD conditional access is now in public preview!
Published May 01 2019 09:00 AM 43.7K Views

Howdy folks,


I’m excited to announce public preview of authentication sessions management capabilities for Azure AD conditional access. Authentication session management capabilities allow you to configure how often your users need to provide sign-in credentials and whether they need to provide credentials after closing and reopening browsers—giving you fined-grained controls that can offer more security and flexibility in your environment. Authentication session management capabilities require Azure AD Premium P1 subscription.


Getting started
To get started, set the sign-in frequency, which defines the time period before a user is asked to sign-in again when attempting to access a resource. You can set the value from 1 hour to 365 days.
You can also set a persistent browser session. This allows users to remain signed in after closing and reopening their browser window. We support two new settings: always persist or never persist. In both cases, you’ll make the decision on behalf of your users and they won’t see a “Stay signed in?” prompt.

 

Manage authentication sessions in Azure AD conditional access 1.png

 

Configuring authentication sessions for your environment
Configuring how often your users need to provide credentials for sign-in and if their browser sessions will be persisted is a delicate balance between security and productivity. For most deployments, the Azure AD default configuration for authentication session already provides the necessary security while balancing a productive user experience. Asking users to frequently sign-in may not make sessions more secure and can hinder a productive user experience. So it’s important to consider if changing the default configuration is necessary for your environment.


For complex deployments, you might have a real need to restrict authentication sessions. Fine grained conditional access controls allow you to create policies that target specific use cases within your organization such as data access from unmanaged or shared devices, without affecting productivity of compliant users. With conditional access you can now adapt authentication session lifetime depending on sensitivity of a resource, user account privilege, authentication strength, device configuration, location and many other conditions.


We’re excited to provide these new enhancements to our customers and as always, we’d love to hear any feedback or suggestions you have. Let us know what you think in the comments below.


Best regards,

 

Alex Simons (@Alex_A_Simons)
Corporate VP of Program Management
Microsoft Identity Division


Note: This feature replaces the Configurable Token Lifetimes feature currently in public preview. If you’re using Configurable Token Lifetimes, please make plans to transition to conditional access for authentication sessions management. Configurable Token Lifetime will be retired six months from now on October 15, 2019.

20 Comments
Brass Contributor

This is awesome. A more user-friendly way of managing token lifetimes!

 

Also, FYI, when I click on the "Click here to learn more" section of the "Persistent Browser session (Preview)", I brought to the Microsoft store page, not an article, well at least for me.

Deleted
Not applicable

What is the default session lifetime if I set the "Persistent browser session" option to "Always persist"?

Copper Contributor

Awesome feature!

@Deleted  I think the default session lifetime for persistent browser sessions will match the current default for Single sign-on session tokens with KMSI enabled. That is 180 days.

Copper Contributor

what happen if the tenant does not have P1 license?

Copper Contributor

Hi,

 

When we set the Sign-In Frequency what portion of the oauth flow are we changing?  

 

Is it the Access Token or Refresh Token length that is being altered? 

 

Using an federated identity provider will we be forcing the client back through that identity provider?

 

Thanks

 

Andy

Iron Contributor

could you please provide more clarity for following scenarios?

 

1. For federated users using ADFS, which settings apply. ADFS PSSO or conditional access sign-in frequency and persistence browser

2. What are the defaults PSSO & refresh token lifetimes. Is it 90 days or 180 days max inactive time with max age 'until-revoked'?

3. What happens to 'Stay signed in' dialog if conditional access settings are set to 'Persist' browser session. Does it still show up or is it up-to an administrator to hide this dialog box in company branding and simply use conditional access to either persist or not persist a browser session

Brass Contributor

Thanks Alex. This is good news! A clarification/question on using Sign-ins Frequency in CA rules

  • If I configure the new Conditional Access policy with Sign-In Frequency set to 30 days for devices connecting to Exchange Online from an external network, users would be required to perform an interactive login (user must type in Id/password) every 30 days. AND if MFA was required on the CA rule as condition, the user would also be MFA challenged every 30 days. Correct?
    • The authentication and MFA challenge above would be scoped to EXO and therefore if a separate CA rule had the same Sign-in Frequency and MFA configuration but set for Sharepoint Online, user would be authenticating and MFA challenged on 2 separate cycles, one cycle for EXO and another for SPO
  • If the above are accurate, then I believe 1 CA rule for all O365 clouds apps (EXO, SPO, Yammer etc) with the same Sign-in and MFA configurations would have the effect of creating 1 sign-in/MFA challenge cycle for all the apps in the policy. Correct?
Microsoft

When these 2 features will be launched. My question is whether "User will be asked for MFA Authentication or Single Factor Sign IN with CA policy enabled for Sign in Frequency as 1hour. And MFA is enabled for this user."  

Microsoft

@Tony Rogers, the default lifetime is until the session revoked with 90 days of inactivity window. 

 

@Andrew Liggett, this affects refresh tokens and session cookies. User will need to re-authenticate, including redirection to the federated IDP.  

@Gurdev Singh , I believe your questions have been covered in the public documentation for the feature. Please take a look. 

@Manoj Sood, your points are correct

@anubha23, if MFA is enabled user will be prompted for both factors. 

Brass Contributor

This is a good step but how would this condition be satisfied:

 

We have several (not ALL) applications that we want to force MFA on every sign-in, including if they close and relaunch the browser (persistent cookie).

The risk here is someone logs in to the app, reviews what they need, and then closes the browser and walks away from their desk.  Someone else then sits down and opens the browser to the same web site and automatically gets in due to the persistent cookie.

We would not want to have to remove the token for every application and therefore force login/MFA for all apps every time.

Any way to handle this situation with the controls we have available?

we have configured Sign in frequency in conditional access for 1 hour , but the session timed out even it is active after 1 hour. 

 

we thought it will be timed out only if it is inactive. Please let us know your suggestions

Brass Contributor

@Sankarasubramanian Parameswaran "The default setting is a rolling window of 90 days, i.e. users will be asked to re-authenticate on the first attempt to access a resource after being inactive on their machine for 90 days or longer". I think the inactive period is only for the default of 90 Days. If you set this value the user is signed out regardless of inactivity. Some clarity would be good on this though. 

Copper Contributor

I no longer see the "Sign-in frequency" and "Persistent browser session" settings in portal.

I had a trial policy set up and that one seems to still exist.

 

Any changes made regarding this?

Copper Contributor

Same here, I no longer see the "Sign-in frequency" ... Is it a bug ?

 

Any changes ? 

Copper Contributor

I guess it was a "bug", today they are back again. 

Copper Contributor

Exact ! That came back to normal late last night. I notice that  Sign-in option frequency is no more "preview" ... 

 

dlongpre_0-1582730071420.png

 

Copper Contributor

I recently used conditional access to enforce MFA. I set Sign-in frequency to 30 days and I set persistent browser session to always persistent.

 

However my Microsoft Flow / Power Automate flows are now failing because I am not authenticated. I tried to exclude Flow in the conditional access settings, but it gave me an error that said "Invalid session control."

 

This post talks about the tokens: https://support.microsoft.com/en-us/help/4467879/conditional-access-and-multi-factor-authentication-...

 

Should I be following that post or doing something else?

Copper Contributor

Hi, 

 

this is wonderful. I have a question regarding the policy execution.

 

If we set policy

AllowUser|EXO+EnterpriseApp|Windows|Browser|RequireHybrid

and I create another

AllowUser|AllApps|Grant(without any additional requirement)|PersistentBrowser:Never ,

 

it somehow lets us to our Ent. application without MFA and Hybrid. Can you explain why. Shouldn't all info from CAs be collected and users should be asked to satisfy additional requirements - which is MFA and Hybrid, and nevertheless browser session policy should be applied?

 

Can you tell us if this setting could soon be available per app basis and not global?

 

Thank you once again for your post and best regards

Copper Contributor

@kwilcox93  the persistent browser session control works only if you select all cloud apps if you try to exclude an application you will get invalid session control. 

Brass Contributor

we have exactly the same situation as @kwilcox93 .

 

Is there a supported way to have MFA enabled for a user and using it in Power Automate Flows and Logic Apps?

e..g securing a service account with MFA but still use full functionality (and no re-signin topics) in Flow and Logic Apps?

Version history
Last update:
‎Jul 24 2020 01:37 AM
Updated by: