This article looks at various password attacks, good password policies and management, and how you can improve your Microsoft 365 tenants' security stance in just a few clicks by enabling Azure AD Password Protection.

You've probably heard the saying "identity is the new firewall." It's true, especially today, when many of us are working from home without the protection of the big blinky light firewall at the corporate office. If you look at newsworthy data breaches over the last few years, the same trend can be seen. Most breaches started with a compromised credential.

The first step toward solving this issue isn't an expensive, advanced AI and machine learning-powered solution from an infosec startup; it's getting the basics of your security posture right. Patch all the things, all the time. Train your users. Block legacy authentication and implement Multi Factor Authentication (MFA).

MFA "upgrades" the threat actor from someone who just bought some stolen credentials on a hacker forum and is now logged in as Jane in your HR department (and who will soon be Jill, your AD domain admin) to an attacker who now needs to do SIM hijacking or some other method to bypass your MFA. In other words, it's a lot harder to accomplish, meaning most attackers will simply move on to softer targets.

Apart from MFA to protect your users' identities until we are in a passwordless future utopia, another basic step is modernizing your password policies and, especially, banning bad passwords.

P@$$words ^

One of the most important points to understand is that the way we've been enforcing password policies for the last few decades isn't making users pick good passwords. Forcing users to change their passwords every month just makes them (us) use the same password with a different number at the end or the name of the month. Mandating uppercase means the first letter is nearly always a capital, and having to include special characters means "a" becomes "@" or an "!" is added at the end. Attackers know these predictable patterns and tailor their attacks accordingly. Stop enforcing password changes. Microsoft, for instance, now has a one-year internal policy.

Another crucial point is that in modern life, people have dozens or even hundreds of accounts across different services. Creating, remembering, and managing individual passwords for all of them is impossible, so people use the same password in multiple places. Password reuse has led to many breaches. A dating webservice is compromised, for example, and the attackers take those email addresses and passwords and try to access your Microsoft 365 tenant. And in many cases, it'll work.

Time for some myth busting. Focusing on password complexity is a (nearly) total waste of time. In most successful attacks today, even the best password won't save you. In the password reuse example above, the criminals have the password so its complexity doesn't matter.

Phishing is another incredibly successful attack vector. A user is tricked into visiting a fake login page and handing over their fantastic 20-character complex password. Again, it's game over.

Less common attacks are keystroke logging, local discovery, and extortion. Again, in all those attacks, a complex password won't save you. For a more in-depth look, see this excellent article.

One attack where your password quality helps somewhat is brute force. A criminal has broken into your network and obtained your AD database (or another directory). Now they use a cracking rig, powered by modern GPUs, to get the plain-text passwords. Note that nearly all the attacks described here are easier to perform than this one. If the attackers have access to your domain controllers to steal your database, they already own your network, so why bother? But if they do, modern hardware will extract most passwords quite quickly, unless it's a very good one.

Another attack where a good password will help you, but not your organization, is password spray. Criminals use common passwords across a list of all your users' accounts, only trying a few, every few minutes or hours ("low and slow") to avoid detection. Your long password might not be on the list of the 100 most common ones, but are you willing to bet that no one in your business uses "Password1?" And all the attackers need is one foothold. The rest of this article will help you with the issue of common bad passwords.

Most people reading this are probably aware that for tech-savvy individuals, the solution in our personal life is a password manager such as LastPass, 1Password, and many others.

This isn't just me making this stuff up. GHCQ in the UK has updated guidelines for password policies, and NIST covers the changes we need around passwords in its SP 800-63-3 "Digital Identity Guidelines" (good summary here).

What they advocate is a minimum of 8 and a maximum of 64 characters, options to use special characters but not enforcing them, restricting context-specific and commonly used passwords (the point of this article), and banning passwords that have been seen in previous breaches.

The Azure AD approach ^

If you're a Global Administrator in your Office/Microsoft 365 tenant, go to the Azure AD portal, click the Security link, and select Authentication methods.

Azure AD portal

Azure AD portal

Select Password protection to configure smart lockout, which locks an account after 10 wrong password attempts (by default) and keeps it locked for 60 seconds. The "smart lockout" is that if the wrong password is entered once after the lockout, it'll lock again, and then increase the time that the account is locked with each wrong attempt.

If your user accounts were created in AAD directly, Microsoft already bans approximately 2,000 common passwords. If one of your users tries to reset their password and it's on the list, it'll be blocked. This list is regularly updated by Microsoft and is based on common passwords in breaches that are in use by criminals.

For accounts created in on-premises AD, however, Azure AD respects your AD password policies; see below.

End user message

End user message

On top of this protection, if you have AD Premium P1/P2 for at least one user, you can (and should) improve on this list by adding common words for your users. Local sports teams, products and brands, and prominent people's names in your business are all commonly used by your users and should be added. You can add up to 1,000. Remember: you don't need to worry about universal common passwords like "qwerty" or "starwars" (really); they're already on Microsoft's list. Words are also fuzzy matched, so you don't need to add variations (4Sysops, FourSysops, 4Sysop, etc.).

To understand the specifics of how a new password is evaluated, see here.

Password protection enabled

Password protection enabled

Most organizations don't have all their accounts created in AAD; however, 90% of businesses rely on on-premises AD and synchronize accounts (and probably password hashes) to AAD using AAD Connect. Don't worry, there's a solution for that as well.

The AD approach ^

Azure AD Password Protection for Active Directory Domain Services builds on Microsoft's and your custom list to make sure that password changes and resets against your on-premises AD Domain Controllers (DCs) block bad passwords too. It doesn't require a specific domain or forest functional level, although the DCs that you deploy the agent on must be 2012 or later. It doesn't require inbound ports, AD schema updates, or Internet connectivity for your DCs. The clear-text password that the user enters never leaves the DC. Note that you must have upgraded your DCs to use DFSR for replication.

It relies on two agents: the first is a proxy agent that connects outbound to Azure AD, and the second is an agent on each DC. If you only have a single DC, you can put the proxy on the DC alongside the agent (as long as the DC has outbound Internet connectivity); both can also coexist with AAD Connect. When you're piloting this, you can choose to only put the agent on a subset of DCs; just know that this means you won't block bad passwords (or get an event log message) for resets that are performed against DCs that don't have the agent yet.

The default mode, Audit, is probably best to start with as it doesn't block bad passwords. It just logs bad passwords in the event log, giving you ammunition to switch to Enforcement mode. User training is also key, so that users understand why they're not able to use "Summer69" as their password.

You want to deploy the Azure AD Password Protection proxy service agent on a minimum of two member servers, using the included PowerShell module to configure it. Step-by-step instructions are found here (note that this installation doesn't require a reboot). If your Global Administrator account is protected by MFA, make sure you use the right authentication mechanism during the registration.

AAD Password Protection Proxy installation

AAD Password Protection Proxy installation

This is followed by installing the agent on the DCs, which does require a reboot. Note that the password filter DLL works with any other password filter DLLs you might have deployed, and it's an AND situation; a prospective password has to pass all the filters you have configured.

In Audit mode, you can use the Event log to see information from the DC agent and the proxy agent.

Event log from password protection

Event log from password protection

There's also a handy PowerShell cmdlet that gives you a summary report on password changes, how many were checked, and how many would have failed in Enforcement mode.

Subscribe to 4sysops newsletter!

PowerShell summary report

PowerShell summary report

AAD Password Protection architecture

AAD Password Protection architecture

A passwordless utopia? ^

The best way to avoid password issues is not to have them at all. Microsoft (and others) have been talking about moving beyond passwords altogether. Some building blocks are in place, such as support for FIDO2 security keys , authenticator apps, and of course, biometrics in Azure AD. We're still some ways off from eliminating passwords altogether, though. Until we get there, take some simple precautions, and help your users pick better passwords.

  1. Matt Berg 2 years ago

    Nice write up Paul, great information. My org made the change to using the Azure AD Password Protection along with the NIST framework a couple years ago and it has great. Complaints always happen in the beginning, but overall the pain seemed to be minimal for our end users.

  2. Author
    Paul Schnackenburg 2 years ago

    Hi Matt,

    Thanks for the kind words and I'm very glad to hear that it worked out for your org. It really makes sense but it always takes time to change "best practise truths" that have been around for a long time. 

  3. William Sparing 2 years ago

    I believe this is an all or nothing approach.  I liked what third party has to offer for this area, more flexibility.  This is free though.

  4. Author
    Paul Schnackenburg 2 years ago

    Hi William, 

    Thanks for the feedback, which I agree with. 

    Many small and medium businesses won't look beyond a built in capability like this and for a small investment in effort they'll increase their security a great deal. But yes, if you're a large enterprise or you need very specific security functionality there are third party services available. 




Leave a reply

Your email address will not be published.


© 4sysops 2006 - 2022


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account