Deploying and Monitoring Azure AD Password Protection

As another layer in protecting against insecure passwords I’d been waiting for Microsoft’s Azure AD Password Protection to come out of Preview for some time but now it’s moved to full GA release we’ve implemented it into our AD \ Office 365 environment.

https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Azure-AD-Password-Protection-is-now-generally-available/ba-p/377487

The premise of the product is simple; when a password is set or changed check it against a list of bad \ known breached passwords in Microsoft’s password database. If the password is unsuitable then prevent it being set.

This should help add a bit more protection against the use of breached passwords. For example reuse of credentials between personal and work accounts, which users are slowly becoming more aware of thanks to services such as https://haveibeenpwned.com

Deployment

The installation went pretty much as the Microsoft documentation describes. We installed the Proxy service on our Azure AD Application Proxy servers as the GitHub docs suggest this is a supported configuration.

https://docs.microsoft.com/en-gb/azure/active-directory/authentication/howto-password-ban-bad-on-premises-deploy

A couple of things need to be watched out for though so check your environment particularly for…

• .NET 4.7.2 is required on the Proxy Servers and 4.5 on Domain Controllers running the DC Agent Service
  check this via registry in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full
• not strictly related to Password Protection but if you’re planning on enabling Password Writeback in Azure AD around the same time (we were as it all comes in as part of the Azure AD Premium P1 license) make sure your version of Azure AD Connect is up to date

If all goes well you’ll get this…

and after running the PowerShell commands to register the service this…

Monitoring with PRTG

As per the Microsoft documentation the Password Protection service creates its own Event Logs, which can be used to check how many times banned passwords have been detected and by whom. Although the output of the PowerShell summary command works well…

Get-AzureADPasswordProtectionSummaryReport

…I wanted to see if I could get something a bit more real-time using PRTG to monitor the logs.

Initially I was pleased to see the native WMI EventLog sensor but then hugely disappointed to see it only works on the standard Windows categories and not additional Applications and Services logs. Need to try harder there PRTG, I expect more from you!

Fortunately they do have a workaround EXE/Script Sensor that effectively runs a PowerShell script (quite ironic!) to monitor these additional logs. Under the hood the script is using a native Windows function called Get-WinEvent and then pushing the output to PRTG.

https://kb.paessler.com/en/topic/62379-how-can-i-monitor-my-historic-windows-events

For some (still unknown) reason the script wouldn’t return output when searching for multiple events so to save time and frustration I’ve split the monitoring into two sensors. One for password set events and another for password change events. The code for both is below. Remember to update the sensor settings as you move from Audit to Enforcement mode!

AUDIT MODE

-ComputerName %host -Username "%windowsdomain\%windowsuser" -Password "%windowspassword" -ProviderName "Microsoft-AzureADPasswordProtection-DCAgent" -Channel "Microsoft-AzureADPasswordProtection-DCAgent/Admin" -MaxAge 1 -EventID 10024 -Level 4
-ComputerName %host -Username "%windowsdomain\%windowsuser" -Password "%windowspassword" -ProviderName "Microsoft-AzureADPasswordProtection-DCAgent" -Channel "Microsoft-AzureADPasswordProtection-DCAgent/Admin" -MaxAge 1 -EventID 10025 -Level 4

ENFORCEMENT MODE

-ComputerName %host -Username "%windowsdomain\%windowsuser" -Password "%windowspassword" -ProviderName "Microsoft-AzureADPasswordProtection-DCAgent" -Channel "Microsoft-AzureADPasswordProtection-DCAgent/Admin" -MaxAge 1 -EventID 10016 -Level 4
-ComputerName %host -Username "%windowsdomain\%windowsuser" -Password "%windowspassword" -ProviderName "Microsoft-AzureADPasswordProtection-DCAgent" -Channel "Microsoft-AzureADPasswordProtection-DCAgent/Admin" -MaxAge 1 -EventID 10017 -Level 4

Password Protection in action

Here’s a couple of screenshots of how the service presents itself to a user attempting to change to an insecure password:

On a PC using CTRL+ALT+DEL

From within Office 365 using Password writeback

Observations

During my testing I was surprised to get a password through that I expected to be banned given it’s a popular UK football team and in the top 10 most used passwords for football teams. On haveibeenpwned the password I used was shown as breached but not so in Azure AD Password Protection. For good measure I tried adding the names of all the current (for the next week or so at least!) Premiership sides to the custom banned list…

The character limit is interesting as although something like manchesterunited or tottenhamhotspur are perfectly valid in terms of length they’re terrible choices in terms of dictionary attacks.

Would be interested to hear a bit more feedback from the Password Protection team on how we can protect against this and why all the haveibeenpwned passwords haven’t yet added to the Azure AD Password Protection database, as you surely wouldn’t want any of those being set by your users?

 

Cover image credit: Photo by Matthew Brodeur on Unsplash