What All Admins Must Know About Microsoft Active Directory

Azure AD is the directory for your Microsoft 365 tenant, as well as the Identity as a Service (IDaaS) platform for your Azure PaaS and SaaS deployments. As such, it’s vital to use its security features wisely to protect your users, applications, data and devices.

Recently we covered Azure AD security in a webinar and we received many good questions. In this article, we’ll answer all of these questions and expand on them to cover the essential aspects of Azure AD all admins must know. Please also refer to the two blog posts we have on the topic, Managing Identities and Passwords in Azure Active Directory and Secure Your Apps and Data with Azure Active Directory. Let’s get started.

Illicit Consent Grants

The risk of your users granting permissions to an OAuth app should not be underestimated and was one of the main risks we looked at in the webinar, along with mitigations, either using just Azure AD (AAD) or adding Microsoft Cloud App Security (MCAS).

Licensing is always a challenging area (I have actually been referred to a “licensing engineer” at Microsoft once – imagine being proud of that title), MCAS comes in three flavors, Office 365 App Security (details), Azure AD Cloud App Security Discovery (details) and Microsoft Cloud App Security. Only the last one provides OAuth app policies and is available either as a standalone add-on or as part of the Microsoft 365 E5 license. Read more here about OAuth policies and investigation using MCAS.

One question around application permissions asked if there was an option to time-limit them – and there isn’t (yet).

Password Protection

Updating your password policies to 2020 and banning common/bad passwords is another important security step that AAD can help you with. Use Password Protection for your cloud users, and extend the protection to your on-premises Domain Controllers. A couple of questions arose around implementing this on-premises and the answer is that your DCs need to be Windows Server 2012 or later, no internet connectivity is required on your DCs but you need to deploy the agent on each DC for complete protection, as you can’t control which DC a particular user connects to when they’re resetting their password. Read our blog post on deploying Password Protection on-premises. Once deployed, Password Protection will stop users from resetting their password to a common one (from Microsoft’s list of about 2000, plus your custom one with up to an additional 1000).

We got a question around application permissions and how to check what’s been assigned to which users and today in AAD it’s a per-app approach, whereas MCAS offers a better search experience. Another question was around exporting and importing security settings for an application which is not available through the UI, but it should be possible to script using PowerShell.

Currently, Microsoft has verified around 600 publishers of Azure OAuth apps which will show a tick in the permissions screen which tells the user or the administrator that the company publishing that application is indeed the maker of this application. Someone asked if it’d be possible to spoof this verification which I think is highly unlikely.

Multi-Factor Authentication

We got many excellent questions about Multi-Factor Authentication (MFA). Some were around licensing and availability of MFA; it’s available for all licensed Office 365 users and you can enable user accounts for MFA, individually or in bulk. However, if you want to use Conditional Access (CA) to enforce MFA, (for particular applications, or logins from particular locations etc.), rather than enabling a user for it, you need AAD Premium P1, which is part of Microsoft 365 E3.

One important point that we mentioned in the presentation is that MFA only works for applications that support “Modern Authentication” and for complete protection, you also need to disable legacy authentication.

Some questions were around MFA methods: phone call, text message, code from your authenticator app/hardware token or push notification in the app/on your phone. The least secure method is text message, as the phone network has numerous vulnerabilities and attacks such as SIM swapping can be used to bypass text message MFA. Note that username, password and SMS is still more secure than just username and password. The most secure option is arguably FIDO2 security keys, now supported in AAD.

While free, the Microsoft Authenticator app is somewhat limiting but to enable MFA as frictionless as possible for your business, it’s hard to beat. Another question was around enforcing MFA for guest users (B2B) in your tenant which is possible.

If you’re an MSP and managing multiple tenants, the best approach is to use Azure Lighthouse and enforce MFA that way – and if your company is a Microsoft partner you already must use MFA (or an equivalent third-party service) as one attendee pointed out.

New Microsoft tenants will have Security Default policies applied, in particular one that enforces MFA for all administrative users. Note that this policy doesn’t allow exclusions and it’s important to have at least one, preferably two, break glass accounts with very long passwords that are exempt from MFA, and any CA policies so that you can access AAD if MFA or CA is down. Creating your own custom CA security policy will let you then disable Microsoft’s security default policy.

Another question touched upon using MFA for on-premises sign-in which isn’t possible today with the retirement of MFA Server, in AAD, but of course, third-party vendors such as DUO offers this functionality.

There was a question around registering someone for MFA as an administrator. In the AAD workflow, an administrator enables the user for MFA or MFA is enforced by a CA policy and the next time the user logs in they are directed to a page where they register their mobile phone and the authenticator app themselves to be able to perform MFA when prompted.

Random Questions

There were a few good questions that didn’t fit into a category, such as whether Azure AD was secure from attack. Nothing is a 100% secure but I do know that Microsoft spends a lot of money making sure AAD is secure against intruders, including using external penetration test companies to test it, along with their own red team (internal teams of “attackers” who’s only job it is to test defenses continuously). I think AAD is being managed, maintained and secured in a MUCH better fashion than any on-premises AD implementation I’ve ever seen.

We looked at Sign-in an User risk policies and while they are a great option (if you have AAD Premium P2) to increase security, they should be used in conjunction with other CA policies to improve the overall security posture. Unless you really plan your policies badly, they shouldn’t interfere and cause havoc which was another question, the Report only mode helps here as well to show you what will happen when you enforce the policy before you actually turn it on.

One question touched on ransomware attacking Microsoft 365 and another attendee chimed in with this video, one of my colleagues have also told me of one of his client’s being hit by ransomware that encrypted files in OneDrive for Business.

Some countries in the EU don’t allow biometrics which will hamper Windows Hello (and decrease security – go figure) but this shouldn’t stop you from deploying (non-biometric) MFA. Also, with Windows Hello the biometric “gesture” (your face/fingerprint/iris scan) never leaves the device/is never sent over the network and isn’t “stealable”.

As a Microsoft Certified Trainer (MCT) I was happy to see a question around certification, there’s one for Azure security (AZ-500) and one for Microsoft 365 security (MS-500), both cover AAD.

We had one migration question where the attendee had Office 365 accounts and Windows Server 2016 on-premises but was apparently not synchronizing them. If you have AD on-premises you can sync accounts to AAD using the free AAD Connect tool so that users have a single sign-on experience with the same username and password. If, however, you have already created cloud accounts for them and are NOT synchronising them from AD on-premises AND you’re a smaller business that can migrate away from AD on-premises altogether, my recommendation would be to do so.

One attendee asked about Microsoft Defender for Endpoint as a replacement for the offerings from larger enterprise security vendors. There are two considerations, if you’re just using a traditional anti-virus product on your Windows / Mac endpoints you’re outgunned for today’s threats. What you need is a complete Endpoint Detection and Response tool (EDR) for ALL your endpoints, including iOS and Android, along with Windows, Linux and Mac. This EDR tool also needs to use Machine Learning to identify suspicious behavior, because relying on signatures from previously identified malware isn’t sufficient. Microsoft Defender fulfils all the above criteria (iOS agent is in preview) and is very capable. My only gripe would be that it requires some skill in Kusto Query Language (KQL) to hunt efficiently in the data from Defender, but then again, those KQL skills will stand you in good stead when you adopt Sentinel 😊.

I’ll end this post with a quote from one of the attendees which I 100% endorse: “All admins that aren’t using MFA should be sacked and banned from the industry”.