There have been a few things that have lead to this post, one of them was the Conditional Access Baseline Policies which retire in the next few days, and the other was conversations around this topic I’ve had recently at Microsoft Ignite The Tour Sydney. This series of posts will initially focus on building some base Conditional Access policies that will be good starting points for M365B or AADP P1 users, and then I’ll focus on adding device compliance requirements that will enhance leverage Intune.
There are (or were, depending on when you read this) four baseline policies which I have previously posted about, which allow you to apply policies that cannot be scoped, only enabled or disabled. This allowed for some flexibility if all four policies couldn’t be enabled.
If you don’t have Conditional Access as part of your M365B or AAD Premium P1 license, you can jump into your directory properties and enable the security defaults, but you need to consider a few things. One is that it’s a Yes/No option for enabling admin protection, user protection, blocking legacy auth and protecting privileged access. Effectively what were four baseline policies are now rolled into one. Most of the conversations I’ve had about this have ended up focusing on the legacy authentication blocking being the most problematic for an organization, which means you really should be looking towards conditional access to block where needed and allow exceptions if absolutely required. As of the time of writing this, there isn’t a PowerShell option to enable security defaults so you will need to use the portal.
That leads us to where should you get started with Conditional Access policies? For today’s post, let’s focus on setting up blocking legacy authentication, and then discuss adding some refinements. I’ve already created this, so let’s walk through the settings to see what I settled on.
The big difference you see right out of the gate is that we get granularity, and here I can choose which users to include, and if required, which users to exclude. I’ve selected all users, which could generate support calls if we rolled it out without prior testing. In my case I wasn’t too concerned, because I was running it in Report Only Mode as per the image above, and I still had the baseline policies in place. Generally you would want to start with a pilot group of users and expand from there.
Up next we need to decide what workload(s) are going to have legacy authentication blocked, and here I’ve selected Office 365 (preview). I’ve selected this one for simplicity’s sake, I could choose the individual services if I wanted, but again you can see that we have an exclude option to exclude particular apps.
Right now that Office 365 (preview) includes the following these key Office 365 services:
- Microsoft Flow
- Microsoft Forms
- Microsoft Stream
- Microsoft To-Do
- Microsoft Teams
- Office 365 Exchange Online
- Office 365 SharePoint Online
- Office 365 Search Service
- Office 365 Yammer
- Office Delve
- Office Online
- Office.com
- OneDrive
- PowerApps
- Skype for Business Online
- Sway
As this is a list that is likely to change, make sure you check for updates through the portal or via the Conditional Access: Cloud apps or actions page. Yes, the documentation still says Microsoft Flow, it’s not me! One last thing with this option, you could choose All cloud apps instead of selecting Office 365 (preview) if you want broader protection across other Microsoft and 3rd party SaaS offerings, but I’ll keep it limited for now.
Moving on to Conditions I only have on option set here to start with, which is Client apps. We just configured the cloud apps that we want it work against, let’s choose the client side applications.
We need to make some decisions here, but I’ve gone with keeping ActiveSync open for now, just in case we haven’t completely rolled out Outlook on iOS and Android, for example, and people are still relying on other apps there. If you know it’s safe to block that now, I would definitely recommend blocking it from the start. What is covered by Other clients?
Let’s take a look at what is over on Conditional Access: Conditions
- Authenticated SMTP – Used by POP and IMAP client’s to send email messages.
- Autodiscover – Used by Outlook and EAS clients to find and connect to mailboxes in Exchange Online.
- Exchange Online PowerShell – Used to connect to Exchange Online with remote PowerShell. If you block Basic authentication for Exchange Online PowerShell, you need to use the Exchange Online PowerShell Module to connect. For instructions, see Connect to Exchange Online PowerShell using multi-factor authentication.
- Exchange Web Services (EWS) – A programming interface that’s used by Outlook, Outlook for Mac, and third-party apps.
- IMAP4 – Used by IMAP email clients.
- MAPI over HTTP (MAPI/HTTP) – Used by Outlook 2010 and later.
- Offline Address Book (OAB) – A copy of address list collections that are downloaded and used by Outlook.
- Outlook Anywhere (RPC over HTTP) – Used by Outlook 2016 and earlier.
- Outlook Service – Used by the Mail and Calendar app for Windows 10.
- POP3 – Used by POP email clients.
- Reporting Web Services – Used to retrieve report data in Exchange Online.
You can see that Exchange Online is going to be impacted by this option. Legacy authentication options start getting blocked in Exchange Online from October 2020 onwards, so at a minimum enable this in report only mode to catch anything that you haven’t seen in your AAD sign in logs yet.
The last setting I have enabled in this Conditional Access policy is Grant, and I have selected Block access. This really is the goal of this policy, so that shouldn’t come as a surprise. What you can also see though is that once we start setting up allow policies we can either require single or multiple requirements be met, and we will discuss some of those in further posts.
The final step after we’ve created the policy settings is whether we want to Enable the policy, or whether we want it in Report only mode or turned off altogether. If you aren’t ready to turn it on, I suggest putting it into report-only mode to help identify problematic applications that are still in use.
One bit of advice I need to give here for those of you who are running Microsoft 365 Business, who aren’t licensed for Azure Active Directory Premium, is that it’s much easier to collect sign-in details. Without AAD Premium P1 or P2 you need to view it per user instead, which isn’t a great experience. It’s been announced that 7 days of sign in log information will be available for non-premium AAD users in the future, but if you need it now, add an AAD Premium P1 or P2 trial to your tenant, and you can start with that information immediately.
Normally you would get the sign in logs by clicking on the Sign-ins graph or under Sign-ins under monitoring in the directory overview page.
But both of those options will take you to an Access denied page, suggesting you set up a premium trial.
What if you don’t want to add the trial? In the user profile you can click on the User Sign-ins graph or Sign-ins under Activity.
This brings you to the details of the user sign-ins, which are available for up to 7 days, and you can download them per user if you want to collate them for further analysis inside Excel, for example.
It’s easy to start filtering, just click on Add filters and select Client app
Then start choosing what you want to filter on, which is most likely going to be most of these options, except for Browser and Mobile Apps and Desktop Clients. The Exchange team just blogged about this in more detail, so take a look at Basic Auth and Exchange Online – February 2020 Update. Note that their instructions are based on having AADP P1 or P2, but it’s easy enough to adjust to per user instead of the tenancy if you want to.
That brings us to the end of Part 1, where we’ve effectively replicated the block legacy authentication baselines policy. Later in the series I’ll cover making exceptions where needed, primarily with a view of things that will need to hang around after the October 2020 deadline for most Exchange Online basic authentication elimination.
intunedin.net 