Passwords

Azure AD Password Protection Setup Summary

Posted on by Adam Fowler

Update 27th November 2023:
The below information may be a bit dated now, so please refer to the lastest official guide here: https://learn.microsoft.com/en-us/entra/identity/authentication/howto-password-ban-bad-on-premises-deploy

Original Post:
Microsoft have a nice way of preventing the use of bad passwords. Yes, all passwords are bad, but some are worse than others :)

Azure Active Directory Password Protection is a service that looks at password changes and blocks passwords it deems as weak. This could be from checking it’s an easy password to break using a dictionary attack, or other easily guessable variants. It leverages Microsoft online services to do so, which requires some setup and agents installed on the on-premises environment.

Microsoft’s documentation for this is detailed and fairly easy to follow, but I thought I’d do a quick rundown.

Installing the agents:

  • There are two agents – the ‘Azure AD Password Protection DC agent’ and the ‘Azure AD Password Protection proxy service’. Both can be downloaded here.
  • The ‘Azure AD Password Protection DC agent’ needs to be installed on all Domain Controllers (DCs), but the ‘Azure AD Password Protection proxy service’ only needs to be installed somewhere once. You CAN install it on a Domain Controller, and you can install it on ALL Domain Controllers, but Microsoft highlighted this as a potential security risk allowing any DC internet access. At least two installs of this is recommended for redundancy.
  • The ‘Azure AD Password Protection proxy service’ can’t be installed alongside (on the same server) as ‘Azure AD App Proxy Service’ – which is probably the same utility server you’d think of putting this on.
  • After installing the ‘Azure AD Password Protection proxy service’ you’ll need to run a few PowerShell commands to register it with global admin rights – you don’t need to create a service account for this, it’s just a one time registration process.

    The commands are:

    Register-AzureADPasswordProtectionProxy -AccountUpn ‘[email protected]’
    (run this on each install)

    Register-AzureADPasswordProtectionForest -AccountUpn ‘[email protected]’
    (run this after the first install only)
  • Installing the ‘Azure AD Password Protection DC agent’ is easier again, but will need a reboot of the DC to start working.
  • Both clients automatically update themselves.

Configuring in Azure Active Directory

  • You’ll need to enable on-premises Azure Active Directory Password Protection on the Azure AD portal – that link should take you right to ‘Password Protection’ but it’s located under Azure Active Directory > Security > Authentication methods > Password protection.
  • Start with ‘Audit mode’ rather than ‘Enforced Mode’ so you can get an idea of how many users might get affected by this change, and allow you to communicate this out before forcing.
  • You can also add custom banned passwords which might include your company name and common terms in your business and industry, to ensure easily guessed passwords aren’t used.

There are other catches to this, like making sure your domain is using DFSR rather than FRSR so please go through the official documenation carfeully.

Once set up, you can either read through the logs on a DC, or run this PowerShell command on each DC to see the results.:

Get-AzureADPasswordProtectionSummaryReport

You’ll need to either wait for users to change their passwords, or do some yourself and work out which DC the changes were done against. These stats will give you an idea of how many ‘failures’ were audited, so you can decide how much of a user impact enforcing the policy will be.

You could of course ship these event viewer logs to a central repository, but the service should just do it’s thing and just block users from setting a new password that’s really bad.

Passwordless Sign-In with FIDO2 Security Key and Microsoft

Posted on by Adam Fowler

We all know passwords are bad. Microsoft’s leading answer to this is Windows Hello – or Windows Hello for Business. Using a PIN or biometrics (fingerprint reader or facial recognition) is trying to move towards a passwordless world. We’ve still got a long way to go, but we’re off to a solid start with viable alternatives.

Source: Microsoft

FIDO2 Security Keys support true passwordless login, and supported devices can be used for both consumer Office 365, and Azure AD. eWBM makes these keys, and by the claim on their website are “world’s first and currently only FIDO2 Level 2 certified security keys”. They offered to send these out to Microsoft MVPs free of charge, so I took the opportunity to accept one, test it and write about my experience.

The eWBM key isn’t very large – on the smaller side of your standard USB flash drive. It’s designed to be plugged in (and comes in both USB-C and USB type A flavours) and then verified with a touch on the fingerprint reader.

To set up a key on Azure AD, it’s a matter of adding it as a sign in method, just like you would with other methods such as SMS or the Authenticator app. eWBM have a quick video on how to do this:

Once set up, using the key is pretty simple too. If you’re logging onto a site using your Azure AD account, instead of entering a password, you choose the ‘Sign in with a security key’ option, plug in and scan your fingerprint on the key, and you’re on.

If you’re wondering why you don’t even need to type the password, where you would with an SMS code – that’s because you’ve got two different authentication methods already built into the USB. Your unique fingerprint, and the unique USB key. Your fingerprint is tied to just that key, it won’t work anywhere else unless you configure another device separately. Combine that with needing to know which username those are tied to makes it a secure combination.

Source: Microsoft

The example above and what I’ve also tested, is a web login. There’s also a PC login option, but that’s currently in beta and you’ll need to be running a insider’s build of Windows 10 to try it.

I can see this working as an actual ‘password replacement’ solution because it provides less of an inconvenience than first logging in with a password, then using something else (SMS/Email/Code/Authenticator App). Instead it’s a single thing to do – plug in your USB key and put your fingerprint on it. The process of doing this is very quick, with the added benefit of being able to do it from any computer – web based sign ins will work from any PC.

A USB-C variant is also available and on it’s way to me, so you can pick from those two standards as to which is more fitting for your requirements.

eWBM sell the keys on their website and there should be more key makers on the way.

Update 28/02/2020

I’ve now received the USB-C version of the eWBM Goldengate Security Key – G320, pictured below against the G310.

Force Multi-Factor Authentication Registration in Azure Active Directory

Posted on by Adam Fowler

If you’ve gone down the path of Azure Active Directory (Azure AD), then I dare say you’re not at the end. It’s a long but rewarding path, with new features constantly being added to enhance a critical service in the Microsoft offerings.

It’s also likely you didn’t start with Mutli-Factor Authentication (MFA) in place and ready to go. Maybe you did and well done! For the rest of us though, we slowly move into these systems while turning more options on.

Just enabling MFA with Conditional Access is great, but getting all users to actually register for MFA https://aka.ms/mfasetup can be a challenge. If you’re fortunate enough to have Azure AD Premium P2 licensing, you can use a MFA registration policy to do a nicely managed rollout and force people on. Those without P2 however, have an option that’s a bit hidden, not as well known and slightly scary:

Require users to register when signing in?


Under the question mark: Designates whether unregistered users are prompted to register their own authentication information when they sign in for the first time. If set to “No,” administrators must manually specify the necessary password reset authentication information in the properties for each user in this directory, or instruct users to go to the registration portal URL directly.

The description for this option is a bit misleading, it actually means that they’ll be prompted the NEXT time they log in, rather than the first time.

This option is found under Azure Active Directory > Password reset > Registration, and is off by default.

Turning this option on is a company wide setting and from my testing, worked pretty much immediately. As soon as someone who hadn’t signed up for MFA logged onto office.com, they were prompted to go through the MFA registration process. There’s no way to point this at certain users or test it, you just have that one little switch to turn it on for every single account in your tenant.

For someone who had signed up for MFA, they were asked to confirm the details entered previously.

I’d recommend letting your staff know before this option is toggled, but at least it can easily be turned off again if you run into any issues.

Update 2nd May:

After publishing this, Sean Flahie on Twitter mentioned his experience if Azure Self-Service Password Reset (SSPR) wasn’t enabled for users, and enabling the combined experience – both of which I have in place already. If you’re having any issues then please look into both of these.

Microsoft DOESN’T admit expiring-password rules are useless

Posted on by Adam Fowler

Update 5th August 2019: Another great blog post from Alex Weinert at Microsoft on real world data from Azure AD, common password attacks and where passwords do and don’t matter: Your Pa$$word doesn’t matter

Update 6th June 2019: The final version of the Security Baseline has been released by Microsoft, and explains the password recommendations very clearly. Here’s one paragraph quoted, bold is my emphasis, but please go and read the whole article:

Periodic password expiration is an ancient and obsolete mitigation of very low value, and we don’t believe it’s worthwhile for our baseline to enforce any specific value. By removing it from our baseline rather than recommending a particular value or no expiration, organizations can choose whatever best suits their perceived needs without contradicting our guidance. At the same time, we must reiterate that we strongly recommend additional protections even though they cannot be expressed in our baselines.

Original blogpost:

CNET has an article titled “Microsoft admits expiring-password rules are useless” which I strongly disagree with, and thought it was worth explaining why.

Beyond the actual blog post from Aaron Margosis at Microsoft not actually containing the word ‘useless’, it’s an inaccurate summary of what is a well written and clear write-up from where I sit.

This all came out of publishing the draft of the Security Baseline recommendations for Windows 10 1903, which details out what settings Microsoft recommend and why. If you’re managing a Windows environment, these are a must read, and should be reviewed with each version of Windows 10 you plan to move to.

The general take of the CNET article was that password changes have been useless for years, suggests Microsoft should completely ‘yank’ the ability to force passwords to expire, and if your IT staff don’t remove password expiry immediately, they’re living in a ‘security Stone Age’. It’s rather insulting and coming from someone in my opinion, who doesn’t know what they’re talking about. They might say the same about me, of course :)

On the other hand, Microsoft’s blog post tells a different story. Yes, passwords are problematic and forcing them to change frequently causes other issues where people just change the number on the end by ‘1’, but they aren’t saying password changes are useless.

Microsoft used to recommend 90 day expiries, then to 60 days. The idea there was that if a credential is leaked somehow, the smaller window that the password is known by third parties, the better. But, if your password M0nkey34! is now M0nkey35!, that’s probably going to be the first thing a targeted attacker tries if the password they had for you didn’t work.

Although all this is true, it works on the assumption that someone is actively targeting you. It happens, but it’s much more common for attackers to just do spray attacks based on millions of credentials they have. Why are they going to pick your account and try a bunch of combinations of passwords, when they could just go through stupid amounts of records with no effort and find weaknesses there?

Say you are a target for some reason; it’s likely that the password leaked from somewhere isn’t new – it’s probably months or years old. If you’d never changed your password because your company never forced it to change, then the attacker now has a valid password for you.

It’s also much more likely your password was stolen from a 3rd party service, nothing to do with your corporate systems. You might have signed up with your work email address, but the password ‘should’ be unique to the service signed up for. We all know users don’t work that way, and use the same password all over the place. Having a password they know will change frequently, may mean that they use something at least unique, even if it does increment.

All of this is moot of course, if you have multi-factor authentication (MFA) in place, because the requirement of something else (a phone, bio-metrics etc) means a username and password by themselves are actually useless. However, most companies do have systems in place that have no options around MFA, so what do they do?

To re-iterate, I agree with everything said in Microsoft’s blog post. This is where one paragraph in the blog post sums it up nicely:

Periodic password expiration is an ancient and obsolete mitigation of very low value, and we don’t believe it’s worthwhile for our baseline to enforce any specific value. By removing it from our baseline rather than recommending a particular value or no expiration, organizations can choose whatever best suits their perceived needs without contradicting our guidance. At the same time, we must reiterate that we strongly recommend additional protections even though they cannot be expressed in our baselines.

Work out your risks, your userbase, what systems might be impacted, what extra protection you have in place and make an informed decision around what frequency works for you.

The focus shouldn’t be on password changes, but should be on implementing those other protections in all scenarios – but before that happens (which for many companies can easily take several years), you’ll need to work out what policy you do. There is no single best-fit recommendation on what that is when using pure passwords, because they’re inherently bad however you look at them.

Look at Conditional Access, Password Protection and Azure AD Identity Protection for starters on adding in these extra protections!

The answer isn’t a pure ‘password changes are useless’, and it’s irresponsible to say so.

Protect Your Office 365 Accounts By Disabling Basic Authentication

Posted on by Adam Fowler

(AKA Legacy Authentication)

This had been on my to-do list for a little while since I heard about it (mostly from Daniel Streefkerk who quite rightly has been drawing attention to this via Twitter, thanks!)– and it should be on yours too.

By default, Basic Authentication is allowed as an authentication method in Exchange Online. This is because that’s the ‘standard’ way things have worked for a very long time – you want to get your emails, you provide a username and password and you’re done.

In our modern world, that doesn’t work too well anymore. It’s too risky in that many ways, and things like 2FA and Conditional Access add an extra layer of security when logging in. That’s great, but many systems weren’t built or haven’t been updated to support this – they’ll just fail when logging in.

What this leaves us with, is an internet exposed authentication system that accepts username and password logins without any other layers of authentication, even if you have 2FA and conditional access turned on.

As per Microsoft’s documentation around disabling basic authentication covers, this lets attackers use brute force or spray attacks to try different credentials to get into your tenant. With the amount of leaks we see these days (register on Troy Hunt’s https://haveibeenpwned.com/ if you haven’t already), it’s likely attackers are hitting Microsoft servers with correct accounts of your staff members. If they manage to get the right password – which is very possible if people end up using an old password they used years ago, or password changes were disabled because you thought you were covered with 2FA – they now have valid credentials to get in and pretend to be that staff member, often to then send emails to all their contacts with a malicious link or some other scam.

If you want to see what’s going on for your tenant, go to the Azure portal and into Azure Active Directory > Monitoring – Sign-ins. Set the Status to ‘failure’ and apply, and see what’s there.

Here’s an example, where you can see the client app is ‘Other clients, IMAP’. This account is disabled, and if you look in the device info there’s no data.

Once you have a look here, you might start to get worried – so it’s time to see if you can disable basic auth!

Only certain email clients will work without basic auth, so your first step is to work out what people are using, and get approval to force the usage of only these:

  • Outlook 2013 or later (Outlook 2013 requires a registry key change)
  • Outlook 2016 for Mac or later
  • Outlook for iOS and Android
  • Mail for iOS 11.3.1 or later

That can be a tough ask, and you’ll need to weigh up the risk of leaving basic authentication in place (to me this is an easy choice, but can still be difficult to get approved and implement).

Again, the Microsoft documentation explains how to do this quite easily – create a new Authentication Profile which has Basic Auth disabled by default, and apply it to test users:

New-AuthenticationPolicy -Name “Block Basic Auth”

Set-User -Identity [email protected] -AuthenticationPolicy “Block Basic Auth”

Set-User -Identity [email protected] -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)

That’s all you need to do to test. The third command forces an immediate refresh on the test user.

I would recommend leaving this in place for a while, and get as many test users on as possible as you might find certain systems using basic authentication that you weren’t aware of.

If you need to drop the policy off of a user, use this command:

Set-User -Identity [email protected] -AuthenticationPolicy $null

If you’re then ready to apply this policy to all accounts company wide, these three commands will do it:

$users = Get-User -ResultSize unlimited
$usersid = $users.MicrosoftOnlineServicesID
$usersid | foreach {Set-User -Identity $_ -AuthenticationPolicy “Block Basic Auth”}

You’ll also want any new accounts to get your new policy by default, which can be done with this command:

Set-OrganizationConfig -DefaultAuthenticationPolicy “Block Basic Auth”

And with that, you’ll have all existing and future accounts protected from the risks of leaving Basic Auth enabled. Of course if you have a special requirement where a few accounts do need Basic Auth, create another policy, enable basic auth on it, and apply it to those accounts. Your attack surface will still be greatly decreased, and hopefully you’ll eventually be able to disable basic auth on those too.

Note: There’s also an option for OneDrive for Business around this same setting, more details here: https://www.adamfowlerit.com/2019/03/onedrive-for-business-rollout-considerations/

Update 26th April 2019:

There’s also now a Conditional Access option that supports ‘other clients’ –
“This includes older office clients, other mail protocols(POP, IMAP, SMTP, etc), and ACS”. This might help you if you either want to block those older clients, or allow them through in certain circumstances: