Identity is the most important aspect of your organisation. It’s crucial that you configure this as best and as safe as possible to make the environment secure and to make your job easier in the end. That’s why i’ve created an Azure Active Directory: Best Practices guide and I’m happy to share it with all you guys. Be sure to leave a comment if you don’t agree so we all can do a better job.
This blog post is a brief summary and will be updated constantly. Be sure to bookmark this if you want to stay up-to-date! Azure Governance is beyond the scope of this article.
Update (01/04/2020): Added Azure AD Password policy post.
Update (30/03/2020): Added more information about blocking legacy authentication.
Update (29/03/2020): Added more information about Azure AD Identity Protection.
Microsoft Secure Score
The Microsoft Secure Score is a number that indicates how secure your environment is. A higher means a more secure tenant. The secure score comes with a lot of recommendations that can protect your organization from threats. A Lot of features below are mentioned in it.
The Microsoft Secure Score is completely free but keep in mind that you might need additional licenses in order to complete some requirements. Also, the secure score is just a number – it’s just an indication. External or third party solutions won’t be taken into account.
You should centralize your identity management. This means you need to install Azure AD Connect when an on-premises Active Directory exists. I won’t discuss Azure AD Connect in detail but there are a few things I want to highlight.
- Use password hash synchronization or pass-through authentication (try to get rid of your AD FS servers). Both have their advantages, but be sure to configure at least 2 agents when using PTA.
- Deploy Seamless Single Sign-On to make your users happy. For classic AD you need a GPO – for devices joined to Azure AD you don’t need to do anything.
- Be sure to create a cloud-only administrator (with a .onmicrosoft.com domain). If you encounter problems with your sync/PTA you won’t be locked out.
I Highly recommend to configure self-service password reset on your tenant – look below for more information.
Not sure if you need to use Active Directory, Azure Active Directory or Azure Active Directory Domain Services? Have a look at my posts that talks about the differences between all services.
Enable a Password Policy
When using Azure AD only (no Azure AD connect) a password policy is in place. When using Azure AD Connect, you should configure an on-premises Password Policy. Please keep in mind that the modern password policy has changed over the years.
- Do not expire passwords. Passwords that expire every x-days is an old security standard.
- Deploy the on-premises Azure Active Directory Password agent to fully use cloud security.
And even beter.. go passwordless. Passwordless authentication is the new and secure way of signig in. Have a look at the whitepaper provided by Microsoft.
Being locked out of your own (or you customers’) organisation isn’t fun (it’s a disaster) – that’s why you need to create an emergency access – or break glass – account. an emergency access account will give you full administrator rights on a tenant, in a secure way (less secure than you want), without MFA.
- Monitor sign-ins and created alert rules to notify other admins.
- Make use of passwordless authentication if possible – a FIDO2 key stored in a safe place is great.
If you’re a CSP partner, you should enable Multi-Factor Authentication for all user accounts in your partner tenant. That’s why creating an emergency access account without MFA is not possible in the Partner Tenant. Microsoft should fix this as soon as possible.
Manage your Global Administrators
In large tenants, you need more then one Global Administrator. Having more then one global administrator allows admins the ability to monitor each other for signs of a breach.
That said, you should limit your global administrators. Microsoft recommends no more then 5 global administrators in a tenant.
It’s advisable to use Role-Based Access Control to grant fine-grained permissions to users. This least-privileged approached will greatly enhance the security of your environment while also avoiding user mistakes.
- Never assign Global Administrator roles to your ‘normal’ useraccount. Create an extra account like email@example.com that you can use if you need Administrator rights.
- Always work with a least-privileged approach.
Enable Azure AD Identity Protection
Azure AD Identity Protection requires Azure AD P2 licenses. Identity Protection is not included with Microsoft 365 Business Premium.
Azure AD Identity Protection is a premium feature that allows you to detect potential vulnerabilities affecting your organization’s identities. The tenant administrator will be able to monitor risky users or risky sign-ins and can configure automated responses like blocking a user or enforcing multi-factor authentication. Risk detections in Azure AD Identity Protection include any identified suspicious actions related to user accounts in the directory.
Azure AD Identity Protection has a neat feature/report where you can estimated the impact on your environment. Before enabling these policies you should take user adoption in account.
Enable Modern Authentication
Modern Authentication is fully enabled for all tenans created after August 1, 2017. If you’re on an older tenant you should manually enable modern authentication for Exchange Online. This is a requirements for enabling multi-factor authentication.
Enforce Multi-Factor Authentication
Multi-factor authentication is free for every tenant and should be enabled on every tenant. Accounts are more than 99.9% less likely to be compromised if you use multi-factor authentication
If multi-factor authentication isn’t enabled for all your admins, stop reading this blog and do this now. MFA for administrators is free and is the first thing you should do after creating your tenant. User adoption is key while enabling MFA – have a look at the rollout material provided by Microsoft.
You can enable MFA in two different ways. Enable each user for MFA individually or Configure Conditional Access policies. Enabling by configuring conditional access policies is the recommended and best approach. Already using per user MFA and want to switch? Don’t forget to convert your users. Try enabling Combined Security Registration to enable multi-factor and self-service password reset in one go.
If you don’t have Azure AD Premium licenses you can activate MFA by enabling the
baseline policies baseline Policies are now replace by Security Defaults. With security defaults you won’t be able to tailer to settings to your environment (enabled for everyone from any location).
Block Legacy Authentication
If you are using the security defaults, legacy authentication is already blocked. When using custom conditional access policies, you should add en extra policy to block legacy authentication. Deploying MFA without blocking legacy authentication is useless. Some numbers from Microsoft:
- 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
Also, don’t forget to block legacy authentication in Exchange Online! Look at my blog post on legacy authentication and how to block this.
Configure Conditional Access
Conditional Access requires at least Azure AD P1 Licenses.
Besides enabling multi-factor authentication and blocking legay authentication there are some more access policies you can configure to enhance security. Start with a base set of policies and add custom policies tailored to your environment. Click the button below to have a look at my best practices excel sheet.
Enable Admin Consent Requests
By default, all users can consent an application to Azure AD. To put it simply, every user can grant access to an application to resources in your tenant. This can be dangerous because of OAuth phishing attacks. There’s an easy way to stop this.
- Set Users can register applications to no.
- Set Users can consent to apps accessing company data on their behalf to no.
- Configure Admin consent requests.
After enabling these settings, a administrator needs to allow (or disallow) an unmanaged application that wants access to your tenant.
Enable Self-Service Password Reset
Self-Service Password Reset requires Azure AD P1 licenses.
SSPR will make you/your helpdesk happy. No more tickets to request a password change. Be aware that as soon you enable this service, users need to register for SSPR – so user adoption is important!
This blog post is a work in progress – updates should drop on a regular basis! Got questions? Leave a comment or send me an email!
Like the post? Consider a donation that will be used for hosting this page.