Use SDK Cmdlets to Create or Update Password Protection Policy Settings

A reader asks if the script written for the article about updating the Entra ID banned password list can be used to update other settings in the Entra ID password protection policy. The answer is “of course.” The code is PowerShell, and it can be adapted to update any of the password protection settings found in the Entra admin center (Figure 1).

A few considerations must be remembered when updating the Entra ID password protection policy:

• You don’t need additional licenses to use the default password protection policy. If you create a custom policy by updating settings, user accounts must be licensed with Entra P1 or P2.
• Custom password policy settings are immediately effective across the entire tenant. You can’t assign a custom password policy to specific users or groups.
• In a hybrid environment, password protection can extend to Active Directory.

Creating a Password Protection Policy

The underlying concepts for creating a custom password policy are similar to the management of other Entra ID policies (like the Microsoft 365 groups policy):

Check if a custom policy exists, or rather, a directory setting object created using the directory setting template for password rules. The template always has the identifier 5cf42378-d67d-4f36-ba46-e8b86229381d, so we can check if a custom password protection policy exists follows:

$Policy = (Get-MgBetaDirectorySetting | Where-Object {$_.TemplateId -eq "5cf42378-d67d-4f36-ba46-e8b86229381d"})

A client-side filter is used because the Graph API does not support server-side filtering against template identifiers.

If a password policy object is not available, you can create a new password policy object. The values for the policy settings are in a hash table containing an array of values. Each value (a setting) is a hash table consisting of the setting name and its value. For example, this code creates the hash table to hold the setting for lockout duration:

$Value5 = @{}
$Value5.Add("Name", "LockoutDurationInSeconds")
$Value5.Add("Value", $LockoutDuration -as [int32])

After populating values for all settings (or just the ones that are different from the default), run the New-MgBetaDirectorySetting cmdlet to create the new custom password policy:

$NewBannedListParameters = @{}
$NewBannedListParameters.Add("templateId", "5cf42378-d67d-4f36-ba46-e8b86229381d")
$NewBannedListParameters.Add("values", ($Value1, $Value2, $Value3, $Value4, $Value5, $Value6))
$Policy = New-MgBetaDirectorySetting -BodyParameter $NewBannedListParameters -ErrorAction Stop

Updating the Password Protection Policy

If a custom policy already exists, fetch the policy settings, update the value for the settings that you want to change, and use the Update-MgBetaDirectorySetting cmdlet to update the policy. This example changes the lock out duration time to 120 seconds (the default is 60 seconds):

[array]$PolicyValues = Get-MgBetaDirectorySetting -DirectorySettingId $Policy.Id | Select-Object -ExpandProperty Values
($PolicyValues | Where-Object {$_.Name -eq "LockOutDurationInSeconds"}).Value = 120
Update-MgBetaDirectorySetting -DirectorySettingId $Policy.id -Values $PolicyValues -ErrorAction Stop

The code for these operations is the same as used in the script to update the banned passwords list. Grab what you need from that script and repurpose it to do whatever you need to. For instance, some organizations like to validate that the password policy settings in the tenants that they manage are consistent and up to date. This is easily done on a periodic basis by creating a PowerShell runbook in Azure Automation. I imagine that checking the password policy would only be one of the Entra ID configuration checks that such a runbook would process. At least, that’s how I would do it.

Next Step – Testing Configurations

The Maester utility includes some checks against the password policy and it would be easy to expand test coverage to whatever aspect of the password policy you consider needs to be checked. Once you’ve mastered programmatic manipulation of the Entra ID password protection policy settings, anything is possible.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365. Only humans contribute to our work!

Use Microsoft Graph PowerShell SDK Cmdlets to Maintain the Entra ID Custom Banned Password List

Vasil Michev is busy these days. Apart from his day job, he’s doing the technical reviews for the Office 365 for IT Pros (2026 edition) and Automating Microsoft 365 with PowerShell (2^nd edition) eBooks, both due for release on July 1, 2025. Technical editing is an important part of our publication process because it’s an annual end-to-end review of all content to help authors refine their chapters, eliminate old and unnecessary text, and consider what they should be covering.

And still Vasil finds time for his own writing, such as a recent article about using the Microsoft Graph PowerShell SDK to update the banned password list for Entra ID accounts. Given that the Graph PowerShell SDK is a major topic for Automating Microsoft with PowerShell, my attention was immediately drawn to the article to understand what it described and consider it for inclusion in the book. It is now, along with 350+ pages of other PowerShell content about automating different aspects of Microsoft 365 activities.

Global Banned Password List

The Entra ID password protection feature maintains a global list of banned passwords. Microsoft maintains the list and updates it on an ongoing basis from telemetry for Entra ID authentication. All attempts to change account passwords are checked against the global banned list to make sure that the new password is reasonably strong. In other words, it’s not something like “Mypassword” or “Cats.” Tenant administrators cannot affect how Entra ID uses the global list of banned passwords, nor can they add or remove values from the list. It’s just part of how Entra ID works, and this part of password protection is included in the version of Entra ID included with all Microsoft 365 tenants.

Custom Banned Password List

If a tenant has Entra P1 or P2 licenses, they can implement a custom banned password list. The custom list supplements the global banned password list. The custom list is limited to 1,000 entries, but those entries are “key base terms” of between 4 and 16 characters. In other words, Entra ID blocks variations and combinations of the terms in the custom banned password list.

When a custom banned password list is available, Entra ID combines its entries with the global banned password list. The idea is that tenants might want to stop people using organization-specific terms like the names of locations or buildings in passwords because these terms might be easy for attackers to guess in a spray attack. Of course, you shouldn’t be depending on passwords and should deploy multifactor authentication to protect accounts, but it’s worthwhile protecting passwords as much as possible.

Blocking Passwords

Figure 1 shows some of the entries in the custom banned password list as viewed through the Entra admin center. You can see that the last entry is for “VictorMeldrew.” This is a key base term for password checking.

In Figure 2, an administrator has attempted to change an account password through the Microsoft 365 admin center. The password looks strong, but Entra ID rejects it because it includes a key base term. Telling the administrator that the password is easily guessable is just the way Microsoft chose to say: “can’t use that password.”

Updating the Custom Banned Password List with a Script

Vasil’s article covers the basics of creating a directory settings object to hold password protection settings, including the custom banned password list. I used that information to create a script that’s more like something you might use as production code, which you can download from GitHub.

The code:

• Checks if the correct permission (Directory.ReadWrite.All) is available to read, create, and update directory settings. This is a very high-level permission that should be restricted as tightly as possible. You should also monitor the apps that hold this permission to make sure that they are used correctly.
• Import a list of key base terms from a CSV file and checks that each term is at least 4 and no more than 16 characters long.
• Uses the Get-MgBetaDirectorySetting cmdlet to check if a directory setting object for password protection is defined in the tenant. If not, the script runs the New-MgBetaDirectorySetting cmdlet to create and populate a new directory setting object with the list of key base terms (and other default values). The directory setting object is derived from the directory settings template for password rules. The template always has an identifier of 5cf42378-d67d-4f36-ba46-e8b86229381d.
• If a directory setting object for password protection is available, fetch the list of current key base terms and combine it with the new list to generate a combined list. The Update-MgBetaDirectorySetting cmdlet then updates the directory setting object with the combined list.
• Export the newly-updated list to a CSV file.

If you prefer to use the input CSV file as the definitive set of key base terms and not combine the input set with the current set, it’s easy to comment out the two lines that create a combined list.

The only semi-weird thing about the list of key base terms is that it uses tabs for delimitation (which is why the code splits the list using [char]9).

Hopefully the script is of some use. If not, I won’t be offended. Check out the 320-plus scripts in the Office365Itpros GitHub repository. You might find something more useful there!

Need some assistance to write and manage PowerShell scripts for Microsoft 365? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Office 365 for IT Pros eBook bundle.