Eliminating passwords with conditional access: Never login again

There’s long been a dream of eliminating passwords, and so we added MFA to those passwords, and then we added YubiKeys and facial recognition and fingerprints and better and more accurate finger and face recognition and texts and — oh my, it’s gotten ugly out there! No one loves this current reality more than they loved their password. We answered this challenge by adding trust IPs to MFA, so if we’re in the office (which we aren’t in 2021), then MFA wouldn’t prompt us, but that pesky password issue was still there. As we took each of these steps, though, it was promised to be a step toward that glorious day when passwords would be behind us. Instead, our authentication would remain valid until something about our activity changed or was suspicious. Well, we’re getting closer and closer to that day. Now is the time to take a big step forward in that direction. Microsoft describes it this way. Azure AD conditional access evaluates signals from user and location, device, application, and real-time risk to determine what type of verification is required to access apps and data.

conditional access

There’s an important consideration to the above, and that is real-time risk. Below I’m showing you what licensing you need to make this work, but risk-based conditional access policies are only available in the highest licensing tier. Most smaller businesses don’t have that tier. If you’re OK with making this a three-legged stool rather than the four-legged table Microsoft shows above, then continue reducing the number of password prompts. If you have E5 or Azure Ad P2 licensing, then you’re ready to fly.

Licensing and requirements

To start, you’ll need some appropriate licensing:

  • Azure AD Premium 1
  • Or Microsoft 365 Business Premium or above
  • Azure AD Premium 2, if you want to also use risk-based conditional access

Users are also required to use the Microsoft Authenticator app. If you have them using the now insecure text or phone methods, give that up for the app. It’s the more secure way to go, according to Microsoft.

Additive conditional access

Remember that what I’m about to describe should be used in conjunction with Microsoft Cloud App Security and Endpoint Manager. We don’t want to give away the farm for the sake of not dealing with logins. We still want to remain safe; we’re just going to do it in a new modern way.

We’re going to add two new conditional access policies that use session controls. Technically you could make them one policy, but I like to keep them separate. The first policy applies to devices that are joined or registered. The second policy applies to browsers and mobile devices.

Conditional access: Sign-in frequency

In this policy, we’re going to define how long we want the authentication token to last. Microsoft most often uses 90 days in their examples, so we’ll use that too. In practice, you may need several of these policies to provide different lengths to different groups based on the sensitivity of the information they typically handle.

We’ll call this policy Sign-in Frequency and assign it to our all-users group. We will also select All cloud apps, as shown below.

conditional access

In the Access controls section, we will use a Session control and set it for 90 days.

Press Select and then Save to create this policy.

Conditional access: Persistent browser control

Let’s create another new conditional access policy. This one we’ll call Persistent browser control. We’ll assign this one to our all-users group and All cloud apps as we did with the previous policy.

This time in the Access controls section, we will use the Session control Persistent browser session.

conditional accessconditional access

Recall from above that this is going to apply to mobile devices and apps accessed in the browser.

Other settings adjustments

Microsoft sometimes doesn’t know where to put something, or maybe it once made sense in simpler times, but we have a setting found in Company Branding to modify. Scroll all the way down to the bottom of your company branding policy and make sure that the “Show option to remain signed in” setting is set to Yes.

We also need to adjust MFA. Usually, you don’t go in here unless you’re configuring an on-premises MFA solution, but there’s something in here for cloud MFA that we need. Here we’re going to open MFA under Azure AD/Security — notice the link for Additional cloud-based MFA settings under the heading Configure.

Here we need to remove a couple of legacy settings that you might be using. First, we can remove any trusted IPs, which is actually trust IPs.

conditional access

Next, if you will use this for everyone, then recall that they’ll need the Microsoft Authenticator app for this all to work, so you could remove the options for call to phone and text message as verification options. If you won’t have all groups on this new method, you may need to keep them.

Finally, we need to uncheck the box under remember multifactor authentication on the trusted device box.

You can see Microsoft even has a note present here that encourages you to use the conditional access method that we just configured instead of this setting. Save your policy after making these changes.

Risk-based conditional access

To enhance our conditional access, we will add a risk-based policy that says if the user’s risk level is medium or high, then deny access. Start by creating a new conditional access policy and call it Deny risky login.

As we did above, we’ll configure it to apply to all of our users and all cloud apps. This time we will also configure a condition and select the Sign-in Risk condition. In Sign-in Risk, we select to configure and then choose High and Medium.

In the Access controls section, we’re going to simply use Block.

As this policy is a risk for getting yourself locked out of your tenant, Microsoft will default this policy to Report-only. Leave it there to test and select “On” when you’re ready to go live.

Here’s where we are now. We have configured conditional access policies and MFA to not prompt for reauthentication for 90 days unless the user’s status changes to Medium or High risk or the user location, device, or application falls out of compliance with our other settings. We’ve set the necessary controls so that both our mobile and static users can enjoy the benefit of less frequent login prompts.

I will add this. Please don’t use this in isolation from other security controls. You need to have at least a basic set of policies and profiles set up in Endpoint Manager security, you should have more conditional access policies, you should have Cloud App Security configured to send alerts and manage data access, and you should be working toward implementation of adopting data loss prevention classifications and protections.

Security is a big job, and it’s not someone else job. It’s everyone’s job. The security portion won’t get any less complex, but we don’t necessarily have to take that out on our users. The goal of IT should be to make things as secure as possible while maintaining ease of work. Walking that line gets more difficult by the day, but the configurations we made here should help.

Featured image: Shutterstock

About The Author

6 thoughts on “Eliminating passwords with conditional access: Never login again”

  1. I think this will work great with cloud apps, but what about MFA when I want to use it to log into a Windows laptop ? Microsoft doesn’t have MFA server available anymore.

    1. Jaap, Windows Hello is what you’re after for that use case. I used a FIDO key for my laptop and it is configured in conditional access in Azure AD.

  2. Why would I want to keep the option to “Keep me Signed in”? In theory our session control should do that for us. Correct me if I’m wrong…..

  3. MR, I have the same question especially since later we are unchecking that the option be shown. But this is part of the documentation as I read it. The only thing I can figure is that it is enabling something that we don’t see.

  4. I find it still a shame that we need a P1 license for conditional access. Blocking access based on user location should be able without the extra license. Not all companies are willing to pay the extra dollars for it. Would be great if we can just block all sign-ins from specific countries. My users are all based in the Netherlands, so a sign-in attempt from Africa is always malicious.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top