We have the most wonderful spring weather here in Sweden right now and I’ve been putting some work into my latest outdoor project, a small cabin near the woods just outside of Örebro. In time, this will be the location of me and my families future home as we also will build a larger house next to the cabin. Sometimes, it’s nice to get away from an otherwise very geeky lifestyle for a while (though the house probably will become my IoT playground).
Updated Conditional Access Policy Design Baseline
A couple of month ago I published the first version of my Conditional Access Policy Design Baseline which purpose is to help people get started with their Conditional Access design. Since then, I’ve implemented the baseline in multiple customer tenants with more on the way and it has proven to be a solid foundation for many common CA scenarios. There are some new features in Conditional Access and i’ve updated the baseline with these. I’ve also made some minor changes based on the deployment experience from the last couple of months. Feel free to use this for your own implementations.
New Features: Authentication Session Management with Conditional Access
Microsoft recently added the possibility to control authentication sessions. Two new controls were added under Session Controls.
- Sign-in frequency
- Persistent browser session
Sign-in frequency defines the time period before a user is asked to sign in again when attempting to access a resource. The default session expiration in Azure AD is 90 days which is fine for scenarios where the users uses a trusted device. If users are prompted for credentials too often they learn to act without questioning the prompt (not good for avoiding phishing). However, sometimes you might want to prompt the user more often than 90 days. Now you can! With Sign-in frequency you can set the session expiration period in days or even hours. I’ve added a couple of examples to the baseline where managed devices requires re-authentication every 180 days.
Persistent browser session, as the name implies, lets you decide if the login session for the user is allowed to persist when the browser is closed and re-opened. Normally the user decides if the session will persist when checking “Stay signed in? at logon”. Now you can control this with Conditional Access and make sure sessions always persists or never persists. From the top of my head, this can be useful for making sure sessions on unmanaged devices never persist.
Note that the Persistent browser session-setting requires a policy that targets all apps. It is not possible to use different persistent settings for different apps.
Read more about Authentication Session Management here.
Please follow me here, on LinkedIn and on Twitter.
2 thoughts on “Updated Conditional Access Policy Design Baseline and Some CA news”