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.
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.
To start, you’ll need some appropriate licensing:
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.
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.
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.
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.
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.
Recall from above that this is going to apply to mobile devices and apps accessed in the browser.
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.
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.
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
While going on leave is good for both organization and employee, there are cybersecurity dangers…
While many work-from-home employees enjoy the new normal, it is not without its hurdles. These…
Limiting administrative scope is surprisingly difficult in Microsoft 365. Luckily, Azure AD administrative units can…
We’ve previously showed you how to add a Windows file server to VMM. In this…