Azure Active Directory (Azure AD) is Microsoft’s cloud-based identity and access management service, which helps your employees sign in and access resources in:
External resources, such as Microsoft 365, the Azure portal, and thousands of other SaaS applications.
Internal resources, such as apps on your corporate network and intranet, along with any cloud apps developed by your own organization.
The default Azure Active Directory configuration is tuned to make your enterprise and users collaborative and productive from the get-go. This does leave some flaws in the perspective of security, which you should address immediately upon leveraging from the Azure Active Directory.
I have chosen the following two subjects in a mix of what those misconfigurations attackers usually takes advantage of, and common misunderstandings plus lack of experience at our customers.
Multi-factor Authentication
According to Microsoft, 99.9% of attacks on your Azure Active Directory identity, which is used for authentication to your Microsoft/Office 365 and includes such as Outlook Online, SharePoint Online, OneDrive and various Microsoft Portals, can be prevented with enabling and enforcing Multi-Factor Authentication.
Multi-Factor authentication is a process where a user is prompted during the sign-in process for an additional form of identification, such as to enter a code on their cell phone or to provide a fingerprint scan. Azure Multi-Factor Authentication works by requiring two or more of the following authentication methods:
Something you know, typically a password.
Something you have, such as a trusted device that is not easily duplicated, like a phone or hardware key.
Something you are - biometrics like a fingerprint or face scan.
Unfortunately, what I usually experience is Azure Multi-Factor being enabled and enforced, but only on high-privileged users and roles, which is to be fair a major improvement in strengthening the security posture of your identities compared to no use of Azure Multi-Factor authentication, but not quite good enough. You need to take into consideration that an attacker likes to target your regular users first (or the CEO), because they are usually prone to get phished, and then create and form a trust between the victim and the potential higher-privileged user, and then move laterally through internal phishing.
Enforcing Azure Multi-Factor authentication
The best and most effective way to enforce Azure Multi-Factor authentication for users and groups, is through Conditional Access policies. Conditional Access policies can be granular and specific, and for this purpose you should create a policy that simply enforces an Azure Multi-Factor authentication challenge when a user (regular or administrator) tries to access a cloud resource, which could be the Azure Portal, OneDrive, SharePoint Online or Outlook Online.
Go to:
Azure Active Directory portal -> Security -> Conditional Access -> New Policy
In this scenario, we want to create a simple Conditional Access policy which enforces Azure Multi-Factor authentication on all users except our break glass account, on All cloud apps and on both Browsers and Mobile apps and desktop clients.
In the new Conditional Access policy configuration, insert the following:
Name: Give it an appropriate name according to the purpose of the policy
Users and groups: Choose all users included and exclude your break glass account
This can be approached in different ways. The two most common one are the Include all users and groups and exclude specific targeted users and groups, or simply just create an cloud group including only the normal users and administrator accounts who should be MFA enrolled, and by this leaving out your break glass account and the On-premises directory synchronization service account if you leverage from Azure Active Directory Connect, plus any other cloud service accounts.
Cloud apps or actions: Choose All cloud apps
Conditions: Configure Client apps and choose Browser and Mobile apps and desktop clients
Grant: Grant Access and check Require multi-factor authentication
Enable policy: Choose On and hit Save
If the Conditional Access policy is configured correctly, you should be able to use the “What if” located in the Conditional Access policy section and confirm the policies effect.
By now you should also see your Microsoft Secure Score increase
Action
Let’s be practical and see what an attacker actually experiences trying to attack identities protected by MFA.
This is from an attacker’s perspective trying to password spray against your tenant:
The picture above clearly indicates which identities are protected by MFA, and which aren’t.
The admin victim will then be able to query these sign-ins, and as you can see some of them failed, and some of them succeeded, which gives us an clear picture of which identities could potentially be compromised:
Block Legacy Authentication protocols
When Multi-factor Authentication (MFA) is configured and enforced, you obviously wish to leverage from this great security feature which you should, and this is where we need to make sure that no application should be allowed to authenticate solely through a legacy protocol. Why is this important you may ask? Legacy protocols simply does not support MFA, and this is because legacy authentication protocols like POP, SMTP, IMAP and MPAPI cannot enforce MFA, making them preferred entry points for adversaries attacking your organization. To put it into perspective:
More than 99 percent of password spray attacks use legacy authentication protocols
More than 97 percent of credential stuffing attacks use legacy authentication
Azure AD accounts in organizations that have disabled legacy authentication experience 67 percent fewer compromises than those where legacy authentication is enabled
Legacy vs. Modern authentication
Legacy authentication is a term Microsoft uses to describe basic authentication when used with its cloud-based services. Modern authentication provides more security and capabilities, and is the way going forward, and at this point Microsoft is already slowly deprecating legacy authentication protocols on their services.
Legacy Authentication Protocols
The following options are considered legacy authentication protocols:
Authenticated SMTP - Used by POP and IMAP clients to send email messages.
Autodiscover - Used by Outlook and EAS clients to find and connect to mailboxes in Exchange Online.
Exchange ActiveSync (EAS) - Used to 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.
Other clients - Other protocols identified as utilizing legacy authentication.
Modern Authentication
Modern authentication is characterized by:
a client and service capable of using OpenID Connect, SAML, and/or OAuth 2.0 for authentication
a client and service which can accept redirects to the identity provider for all authentication interactions and can work with authentication tokens of the protocols above
Is your organization ready for this?
At this point you could ask yourself: “Phew, this sounds like a no brainer. Let’s block those legacy protocols and feel safe”. The reality is that some users, service accounts and/or older integrated systems such as old phones and computers with outdated native browsers, and conference & meeting room schedulers might still only support the legacy protocols. In this case we can simply just exclude them from our design, until they are either upgraded to newer software which supports modern authentication, or completely migrated to a more modern solution, which should be addressed and done as soon as possible.
To identify these potential users, service accounts and systems, you should query your Azure AD sign-ins. This can be done by going to:
Azure Active Directory portal -> Sign-ins
Now we add a filter to isolate our query for utilization of legacy protocols. Hit Add Filters and choose Client App.
Make sure all Legacy Authentication Clients are checked, and the filtering will only show you sign-in attempts that were made by legacy authentication protocols. Clicking on each individual sign-in attempt will show you additional details. The Client App field under the Basic Info tab will indicate which legacy authentication protocol was used.
Directly block Legacy Authentication
How can you prevent apps using legacy authentication from accessing your tenant's resources? The recommendation is to just block them with a Conditional Access policy.
As with the previously created Conditional Access Policy, head over to:
Azure Active Directory portal -> Security -> Conditional Access -> New Policy
In the new Conditional Access policy configuration, insert the following:
Name: Give it an appropriate name according to the purpose of the policy
Users and groups: Choose all users included and exclude your break glass account plus the ones you identified in the sign-in query
Cloud apps or actions: Choose All cloud apps
Conditions: Configure Client apps and choose Exchange ActiveSync clients and Other clients
Grant: Block Access
Enable policy: Choose On and hit Save
You have now strengthened your identity security posture by a big margin, and your user identities are now less vulnerable of being compromised, and as a bonus your Microsoft Secure Score has now been increased
