- A Power Automate example: Pushing Microsoft 365 status notifications from Twitter to Microsoft Teams - Thu, Oct 29 2020
- Specops Key Recovery: Self-service for unlocking BitLocker-encrypted devices - Thu, Oct 24 2019
- Automating Remote Desktop Services certificate installation with PowerShell - Thu, Sep 5 2019
However, if you are not using Microsoft 365 and are still using the Office 365 plans, Conditional Access is still available to you albeit in a more limited fashion.
Logging into my own tenant as an administrator, heading to Azure AD and then Security, I can see the Conditional Access heading.
You can see I have several predefined (preview) policies to choose from, but the rest of the settings are grayed out, and a heading says I need an Azure AD Premium subscription. With the Azure AD subscription or Microsoft 365, you would have full access to Conditional Access, but let's take a quick look at these preview policies.
Block legacy authentication ^
This policy blocks all sign-ins using legacy authentication protocols that don't support multi-factor authentication (MFA), such as IMAP, POP, or SMTP. The policy does not block Exchange ActiveSync.
You may have seen some information recently recommending the disabling of basic authentication in Exchange Online. This took place via PowerShell, creating a new authentication policy for Exchange Online, and then applying the policy to your users. Here, we can accomplish the same result with a simple on or off button.
Disabling Basic or Legacy authentication really should be the default position.
Require MFA for admins ^
This policy requires MFA for certain directory roles. Again, rather than relying on manually enabling MFA for your admin accounts, enabling his policy will prompt those with any administrator role to enable MFA and block them from logging in until completing this.
End user protection ^
This policy protects users by requiring MFA during risky sign-in attempts to all applications. It blocks users with leaked credentials from signing in until a password reset.
Enabling the policy requires users to register for MFA within 14 days of their first login attempt. The default method of MFA registration is via the Microsoft Authenticator app.
Similar to the "Require MFA for admins" policy, this policy will encourage users to set up MFA on their accounts and insist upon it after 14 days. I have had some pushback from some of my clients about insisting they use MFA for their accounts.
The most common complaint is having to install an app on their personal phones, even if they do not want their work email on their phones. For these staff, we have compromised on either disabling all access to their accounts except MAPI or preferably having them receive an SMS code for authentication. It is also worth remembering that MFA can call you on a mobile or a desk phone.
Require MFA for Service Management ^
This policy requires users logging into services that rely on the Azure Resource Manager API to perform MFA.
This policy seems a little redundant to me since chances are, if you are logging into either the Azure Portal, Azure CLI, or PowerShell, you will be doing some sort of service administration. This would mean you were using an administrator account covered by a previous policy. However, I think that is more a reflection of my client base than actual use cases, as people who use Azure to manage web hosting or development may not be administrators of your tenant.
Although these policies may seem limited when compared to what you get in the "full" Conditional Access policies, these are a very strong baseline to build on for your clients who may be small enough to be using only an Exchange Online license but still need the extra protection of enforcing MFA for admins or blocking legacy authentication mechanisms.