Managing Identities and Passwords in Azure Active Directory

Due to the lockdown imposed by the coronavirus pandemic, many of us have had to move (parts of) our IT platforms to the cloud very quickly and are now taking a second breath to ask, how can we secure our hybrid estate? How can we make sure that the people we have working from home and accessing our systems and our data are kept secure? How can we control access effectively and have the right monitoring in place? The answer lies in carefully managing identities and enforcing a secure password system.

Before we continue, if you haven’t already signed up to our webinar on October 7 How to Fortify your Business with Azure Active Directory, do that now. I will be presenting that event along with longtime Altaro presenter Andy Syrewicze and we’ve got some really great content lined up for anyone who manages Microsoft-based cloud infrastructure accessed by multiple users. The threats to your data are growing, make sure you’re prepared – save your seat now!

We in IT share something with everyone on the planet at this time – we live in interesting times. And this is very evident in the way that we’re saddled with managing big transitions, most notably with the digital transformation of how our businesses run and the shift to supporting work from home in lockdown.

In this article, we’ll cover Privileged Identity Management (PIM) and Identity Protection, the new My Sign-ins page and how to ban bad passwords.

We’re focusing on identity and AAD because in the hybrid cloud world we all live in today – identity is the new firewall – and most attack methods are aimed at obtaining credentials and thus should be the first thing we protect.

Privileged Identity Management

We’ll start with ourselves because any attacker worth their salt is aiming for us administrators. They might start with compromising an ordinary user through a phishing email, a fake OAUTH app, password spray or some other avenue but once in – their goal is elevating their privileges to administrator.

In the on-premises world, the recommendation for many years was to have separate accounts (some of you probably operate like this today) so I’d have a day to day PaulS account for checking email and writing reports and then switch to a PaulS admin account (with a different password) when I needed to access AD to do admin work. This works but it’s cumbersome to use and it still leaves the administrator accounts active 24/7 (“standing access”) which means that if this credential is compromised, attackers have access for extended periods of time.

Making a user eligible to be Global Administrator in PIM

A better solution (which only stretches your budget to Azure AD Premium P2 licenses for your IT admin team) is Privileged Identity Management (PIM). It gives you a list of all your current Global Administrators (or Exchange administrators etc.) and lets you change them from permanent to eligible. Their one user account is now a general user with no special admin access, when they need to do IT admin tasks they logon to the AAD portal, ask to be elevated to an admin role (which can involve approval by another admin but doesn’t have to), perform Multi-Factor Authentication (MFA) and they’re now administrators for a limited amount of time, usually a few hours. This dramatically lowers the risk profile of your administrative users but does involve some extra steps for these users. Given that only about 8% of all Office 365 tenants have MFA enabled for their privileged accounts, enforcing PIM will put your business way ahead of the pack.

Remember, it’s not about running faster than the Fancy Bear, it’s about running faster than your hiking companions, or in other words, present a more difficult target than another business down the road.

Activating an eligible user to Global Admin

In the real world, there’s no doubt that using PIM (or just MFA for that matter) is an extra step that’ll take a few seconds and have your IT staff grumble but honestly, there’s no excuse for not using it. It’s like insurance or backup – a drudge to do, but boy are you grateful the day it’s needed. Also note that you’ll want to create a couple of break glass accounts that are permanent Global Administrators and not protected by MFA, nor subject to Conditional Access, with very long passwords, that are only to be used in an emergency when MFA is down in AAD.

Identity Protection

Microsoft gathers lots of signals (6 ½ trillion per day) across all their cloud systems, building a risk profile for each of your user’s accounts and for each sign in that’s performed against AAD. If you have AAD Premium P2 you should enable Identity Protection (IdP) for your users.

IdP lets you build sign-in and user risk policies so automated actions can be taken when risks are detected. These risks include atypical travel (isn’t all travel “atypical” now?), logging in from an anonymous or malware linked IP address, the sign-in has unfamiliar properties for this user or password spray attacks. If your accounts are cloud-only or if you’re using AAD Connect to synchronize users from on-premises to AAD with Password Hash Sync (PHS) you also get leaked credentials. This is when a user uses their M365 account and password to sign up for another service, this service is compromised and these credentials are now public or available for purchase on the dark web. Microsoft will take the leaked password and do the same hashing operations and compare the results. If it matches, the user’s risk score is immediately increased and if you have the right user risk policies configured, they’ll automatically be forced to perform an MFA and then reset their password.

Identity Protection User Risk Policy

Note that even if you don’t have AAD Premium P2 licensing you get some of the benefits of IdP but only P2 gives you the rich reporting, insight into the signals behind risk score changes, and with notifications of users at risk.

My Sign Ins

This feature was released early August 2020 and I call it “self-service identity security insight”. It was certainly a shock to me to see that my account was being attacked on a regular basis (unsuccessfully, I have MFA turned on) as you can see in this screenshot.

My Sign Ins report

The My Sign-in page also has handy shortcuts to manage Security info for your account (phone for MFA, backup authentication email etc.), organizations that you are a member or a guest in, with a link to leave an org if required and a list of your devices with the ability to disable your account on them. Incorporate this page in your user’s training, it’s a great way to make security personal, seeing attackers going after your account.

The problem with passwords

There are many issues with passwords but one that falls squarely on our shoulders in IT is that the advice we’ve been giving, and the password policies we’ve been enforcing for the last few decades aren’t resulting in good password habits.

Forcing users to change their passwords monthly results in people (us) using the same password with the month or a number at the end, forcing uppercase and lowercase nearly always means the first letter is a capital, forcing users to use special characters leads to an ! at the end, or an ”a” replaced by an @. And if we know this – so do the attackers. On top of this, users have many accounts, on many services, so password re-use is a common problem, leading to the issue where a credential is compromised in a poorly protected service (Ashley Madison) and then used successfully against Office 365.

Furthermore, in most modern attacks, your password complexity is irrelevant. In password re-use, the criminals have the password and in phishing attacks, the user is giving their fantastic 25 characters “unbreakable” password to the attacker’s fake login site. Other attacks include keystroke logging, extortion and local discovery, where again your password strength doesn’t matter.

One attack where password strength will matter (a little bit) is a brute force attack where an attacker obtains a copy of your AD database (or another directory) and uses a GPU powered cracking rig to get plaintext passwords. Note that in nearly all scenarios, for the attacker to get that database, they have already got full access to your network, so why bother with this extra step? Furthermore, all the attacks above are easier to perform and generally faster. If they do go this far though, modern hardware will crack passwords fairly rapidly, unless it’s a very long and complex password.

Another attack where password quality will matter is password spray, where attackers use common passwords across a list of accounts in your tenant, trying a few, very common passwords infrequently (so as not to trip defenses) to see if anyone is using “qwerty”, “ILoveYou!” or “LetMeIn” or any of the other very common passwords. If your password is good, yours probably won’t be the account they compromise first but do you want to bet that no-one in your business uses a bad password?

For technically savvy people the answer in our personal life is a password manager like LastPass or 1Password. If you need “official” ammunition when tackling the hardest policy in IT to change, your password policy (that was probably formulated circa 1999), check NISTs SP 800-63-3 “Digital Identity Guidelines” (here is a good write up, if you’re interested) or UK’s GHCQ guidelines. The basic gist is minimum 8 characters and at least 64 for maximum, options to use special characters but not enforcing them (works well with password managers), not forcing regular password changes, and restricting commonly used passwords and passwords seen in previous breaches, and the easiest way to do this last bit is using Password Protection.

Password Protection

Let’s start with AAD Password Protection in the cloud. If you have cloud-only users (not synced from AD on-premises) they’re automatically blocked from picking popular, bad, passwords. This feature relies on a list of about 2000 common passwords that Microsoft has compiled from breach data and that they keep up to date. Further, you can add a list of up to 1000 words that are specific to your business. Make the overall protection better by adding brand names, notable people in your organization and local sports teams. Note that it uses fuzzy matching, so you don’t need to add variations for each word.

If you’re a Global Administrator for your tenant simply head over to add.portal.azure.com, login and click Security, Authentication Methods. Here you can enable the custom list (as long as you have at least one AAD Premium P1 or P2 license in your tenant) and add the words. You can also fine-tune smart lockout which will temporarily lock an account after X (default 10) incorrect tries and lock it for Y time (default 60s), but if the 11^th try is also incorrect (unless it’s the same as a previously tried password which won’t increment the counter), the account will lock again, for a longer time, and so on.

AAD Password Protection settings

When a user tries to enter a new password it’s evaluated according to these rules.

To extend this protection to on-premises there are a few pre-requisites, such as the DCs being Windows Server 2012 or later (domain and forest functional level can be older) and replication must be upgraded to DFSR. You don’t need any inbound ports opened, the AD schema doesn’t need updating, the clear-text password that users are typing never leaves the DC and your DCs don’t need internet connectivity. There are two agents that need to be installed. In a very small environment, they can live on the same server and that can be a DC (with outbound internet connectivity) but in most cases, you’ll want to install proxy agents (at least two for HA) on member servers that have internet connectivity.

On each DC you’ll need to install its agent. If you select to pilot this on a smaller number of DCs, be aware that if a user is performing a password reset against a DC without the agent, a common password won’t be blocked. Both agents can co-exist with AAD connect and the DC agent will work with other password filter DLLs you may have deployed. The proxy agent doesn’t require a restart, but the DC agent does. Once you have deployed the agents and registered them with AAD, turn on Password Protection in the AAD portal.

Start with the deployment in Audit mode where bad passwords won’t be blocked but you can track the number of them either in the event log or using the handy PowerShell (Get-AzureADPasswordProtectionSummaryReport) report cmdlet.

Get-AzureADPasswordProtectionSummaryReport output

Here you can see a production domain in Audit mode where five password changes would have been rejected had we switched to Enforced mode. Make sure to include some user training in your deployment plan or your helpdesk is going to field a lot of calls from users who are trying to understand why they can’t use their favourite password.

Conclusion

The best password is one that doesn’t even exist and Microsoft is on a journey towards a password-less future with support for FIDO2 security keys, authenticator apps and biometrics in AAD, but until we get there, increase the security of your organization by implementing Password Protection, PIM and IdP.

The next step in securing your Azure infrastructure concerns fake OAUTH applications, how to educate users, what you can do technically to stop these, plus how to use MFA and Conditional Access to protect your business. I’ll be following up on these in my next article.

And a final reminder to sign up to our webinar on October 7 How to Fortify your Business with Azure Active Directory. See you there!