Passwords have long been the de facto authentication mechanism for identities. Length and complexity plagued us as we struggled to produce an acceptable password that we could easily remember and type when prompted. Although we’re moving closer to a passwordless and much more secure world, for now, we must still create these memorable, complex dinosaurs to authenticate to many of the resources we use.
Humans are quite predictable. We create memorable passwords based on our interests, such as popular sports teams, names of famous celebrities, lines from movies, or even catchphrases from the recent global pandemic. This behavior makes predicting passwords easier. When we use familiar words to fashion passwords, we potentially open ourselves and our organizations up to hackers. Those familiar words and phrases can be placed within a dictionary and used in a password spray attack to guess a user’s password and gain access to the network.
Banned Password Filtering for Azure and Active Directory
Customers with Entra ID (formerly Azure Active Directory) Premium subscriptions can take advantage of Microsoft Entra Password Protection. This is a service available to Entra ID Premium subscribers that complements the AD domain password policy to further ensure that users are creating strong passwords. To understand the service and why you need it, see the blog post “Password Spray Attack Defense with Entra ID” by Brian Desmond, principal at Ravenswood Technology Group.
Understanding the Impact of Microsoft Entra Password Protection
Although enabling the Microsoft Entra Password Protection service is straightforward, large organizations with several thousand users should proceed cautiously and assess the impact on their end-user population prior to employing it. For this reason, Entra Password Protection can be deployed in two modes: Audit and Enforced.
Microsoft recommends starting with Audit mode, to assess the end-user impact before enforcing password filtering. After you assess the impact, you’ll have a clearer picture of the problem and an idea about how impactful enforcement will be. A new log is created when you install the DC agent on your domain controllers (DCs), under \Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent.
Several events will be useful in better understanding the struggles end users might have as they create new passwords. Detailed analysis can also reveal bad habits; for example, event IDs 10016, 10017, 30021, and 30022 indicate that the password contains the user’s account name. A full list of event IDs can be found on the Microsoft website, at “Monitor and review logs for on-premises Entra Password Protection environments.”
Organizations with Security Information and Event Management (SIEM) can collect the logs and create reports or generate alerts based on certain thresholds or event IDs, such as the event IDs indicating that the password contains the account name. Another option is to export the logs to Azure Log Analytics, where you can run queries to obtain better insight.
Microsoft also provides a PowerShell cmdlet that’s installed with the DC agent:
Get-AzureADPasswordProtectionSummaryReport
This command queries each DC to provide a high-level overview of the password events occurring on each DC. PowerShell remoting must be enabled on each DC, and you must have sufficient privileges to read the event log.
The utility queries each DC and returns a total number for each of the events recorded in the log. The following output shows a sample of that report from our test lab.
PS C:\Users\SomeDAAccount> Get-AzureADPasswordProtectionSummaryReport DomainController : DC-1.SampleDomain.com PasswordChangesValidated : 1 PasswordSetsValidated : 494 PasswordChangesRejected : 0 PasswordSetsRejected : 0 PasswordChangeAuditOnlyFailures : 0 PasswordSetAuditOnlyFailures : 32 PasswordChangeErrors : 0 PasswordSetErrors : 0 DomainController : DC-2.SampleDomain.com PasswordChangesValidated : 0 PasswordSetsValidated : 0 PasswordChangesRejected : 0 PasswordSetsRejected : 0 PasswordChangeAuditOnlyFailures : 0 PasswordSetAuditOnlyFailures : 1 PasswordChangeErrors : 0 PasswordSetErrors : 0
Smaller organizations without SIEM or those that prefer not to use Azure Log Analytics can use the following PowerShell script to gather detailed information into a Microsoft Excel spreadsheet. From there, you can perform further analysis on the types of events and who the target users are for each event. Try filtering on the event ID to see who is failing password changes for a specific reason, such as including their account name in the password.
[cmdletbinding()]
Param()
$forestDCs = ((get-adforest).domains | foreach-object {Get-ADDomainController -filter *}).name
$eventArray = @()
Foreach ($DC in $ForestDCs) {
Write-Verbose "Working on $DC" -Verbose
$PPEvents = Get-WinEvent -LogName 'Microsoft-AzureADPasswordProtection-DCAgent/Admin' -ComputerName $DC | Where-Object {$_.id -notlike "30006"}
foreach ($event in $PPEvents) {
$eventXML = [xml]$event.ToXml()
$eventArray += New-Object -TypeName PSObject -Property @{
EventID = $event.id
EventTime = $event.timecreated
Description = $event.Message
Computer = $eventXML.Event.System.Computer
UserName = $eventXML.Event.EventData.Data[0]
}
}
}
$eventArray | select Computer,EventID,EventTime,Description -ExpandProperty UserName
Code language: PowerShell (powershell)An Example
Running this PowerShell script as-is will output the data to the screen. For smaller deployments, this may be enough. But for a more powerful feature, as the following screenshot shows, you can pipe:
$eventArray | select Computer,EventID,EventTime,Description -ExpandProperty UserName to Out-Gridview
This creates an interactive table that you can filter on the data you want. For larger data sets, you can use:
Export-CSV -Path
Then open the file in Excel. You can then use advanced features such as data filtering or a pivot table to display the data in a more readable format.
Conclusion
Passwords are still around and will be with us for a while longer. Organizations should take advantage of technologies such as password filtering to prevent the use of simple and commonly used passwords. Using a password filter like Microsoft Entra Password Protection complements existing password policies to provide an additional layer of security.
The need for better control over the passwords users are creating has never been greater. However, administrators should carefully consider the tools they deploy, to avoid negative impacts on end users. Observe the effects that password filtering will have using your own SIEM, Azure Log Analytics, the PowerShell cmdlet provided in this blog, or a script to collect the logs for analysis. This will help identify some of the pain points you’ll experience when it’s time to enforce your new policies.
For a successful implementation, it’s important to understand the effects, communicate effectively, and prepare the help desk for a potential flood of calls. If you need assistance with implementing password filtering in your environment, contact the experts at Ravenswood Technology. We’re here to help!
