- Azure Sentinel—A real-world example - Tue, Oct 12 2021
- Deploying Windows Hello for Business - Wed, Aug 4 2021
- Azure Purview: Data governance for on-premises, multicloud, and SaaS data - Wed, Feb 17 2021
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.
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.
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.
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.
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.
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.
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.
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!
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.