Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2019-10-28) Azure AD Password Protection (A.k.a. Banned Password List) – Optimizing The Custom Per Tenant List (Part 6)

Posted by Jorge on 2019-10-28


The main goal of Azure AD Password Protection is to prevent users from using passwords that are (too) common and predictable. Because those passwords are too common or predictable those are always used in attacks like or similar to password spraying. Looking at the past “January2018” is considered complex as it has characters from three out of four character sets. Most likely the next password is “February2018“, etc. The same is true for “Pa$$w0rd”. Those combinations are too easy and nobody is fooled by character substitutions.

Azure AD Password Protection has a specific algorithm and it works like:

  1. Normalize password
    1. all letters in password to lower case (e.g. A->a, B->b, etc.) and compare with banned password list. If true, deny!
    2. Replace special characters to normal letters (e.g. @->a, 1->I, etc.) and compare with banned password list. If true, deny!
  2. Fuzzy matching –> Check the password against the banned password list taking 1 edit distance into account (e.g. "abcdef" vs. "abcdeg"). If true, deny!
  3. Check if password contains:
    1. First Name. If true, deny!
    2. Last Name. If true, deny!
    3. Tenant Name. If true, deny!
  4. If still not denied, calculate the score of the password
    1. Minimum allowed score for passing is 5 points
    2. Check which words on BPL (e.g. motor, cycle, helmet) are in password, assign 1 point for each
      1. Found substrings (“m0torcyc1ehelmetU63”) = 1 point each –> 3 points in this example
    3. For every remaining individual characters, assign 1 point for each character
      1. Found individual characters (“m0torcyc1ehelmetU63”) = 1 point each –> 3 points in this example
    4. Total = 6 points –> PASS

REMARK: if the BPL has the words ”motor”, “cycle” and “motorcycle” and you are trying to use the password “m0torcycleY6k”, it will fail (4 points and not 5 points). In this case it check against the word “motorcycle” instead of “motor” and “cycle”. If the BPL contains 2 or more words that combined also exists as an individual word, it will always prefer to check against the longer word as with it will end up with lower amount of points.

The BPL consists of 2 lists, being the global MSFT list and the custom per tenant list. The custom per tenant list has a maximum of 1000 words, each word must be at least 4 characters long and not be longer than 16 characters. It is also not possible to tweak the algorithm. This is it and that’s what you can use.

With regards to the global MSFT list, which is maintained by MSFT, nobody, except MSFT, knows the content of that list. So when you need to populate the custom per-tenant list how do you know it is not already included in the global MSFT list and you are not wasting valuable space in the custom per-tenant list? Easy answer! You don’t! But, I found a way to test words to determine if those are already included in the global MSFT list or not! THAT will help YOU determine if any of your words are already included in the global MSFT list or not. I even wrote a PowerShell script for that you can use.

Yes I know it is against bad practice! But I did not want to complicate the script to get things done. In general this script requires “Domain Admins” equivalent permissions if you have a single AD domain in your AD forest! If you have multiple AD domains in your AD forest, then it really depends on your scenario which depends between needing “Domain Admins” or needing “Enterprise Admins”. You would just need “Domain Admins” if the executing account of the script is in the same AD domain as the account you are using to test the words against. You would just need “Enterprise Admins” if the executing account of the script is in some other AD domain then the account you are using to test the words against.

To really be concrete about what you need, you need the following:

  • Reset Password” Control Access Right, a.k.a. Extended Right, on the targeted AD user account
  • Permissions to read/query the Microsoft-AzureADPasswordProtection-DCAgent/Admin Event Log

As you can see, either “Domain Admins” or “Enterprise Admins” will get the job done, but I really can imagine if you want to cut down those permissions to delegated rights. Is that possible? Hell yes, it is possible. Feel free to use the contact form to get more info about delegating this. At this point I was just too lazy to write it all down in addition to this.

Other things to note when using Azure AD Password Protection:

  • You cannot change anything in this algorithm. This is it and you need to use as-is
  • Only populate lower version of words. Do not specify upper characters or special character to replace normal characters
  • Changes in Azure AD, may take some hours before those get down to the RWDCs. The easy way to propagate faster is to restart the Azure AD Password Protection DC Agent service on at least 1 RWDC per AD domain. That action makes sure that RWDC triggers the instant download of the newest policies for that AD domain. Remember, although this is a per AD forest registration, the consumption of all this is per AD domain!
  • Something else to note is localization. Unfortunately it is not fully localized (English Only). For example, it prohibits "welkom" and allows "wachtwoord", while it denies both "password" and "welcome". Weird, but true.
  • Another unfortunate thing is that it does not integrate directly with external solutions such as “Have I Been Pwned”. MSFT however may have some integration in the background where the newest compromised password are included. Unfortunately, nobody knows, except MSFT. You can check the latest version of the global MSFT list after restarting the Azure AD Password Protection DC Agent service as at that point in time it will specify in the Microsoft-AzureADPasswordProtection-DCAgent/Admin event log which policy date version is being used for the global MSFT list and the custom per tenant list.
  • Not easy to test passwords against it (please do continue reading!)

As mentioned earlier I found a way to check candidate words for the custom per-tenant list and check if those are already on that list and/or on the global MSFT list.

This is what you need:

  • Create an input text file with all the (new) candidate words for the custom per tenant list
  • Create an user account in some AD domain in the AD forest that is registered in Azure AD, and make sure that user account is disabled (security measure!)
  • If you want to use delegated permissions instead of the Domain/Enterprise Admins “will always work” permissions, you need at least the following delegated permissions
    • Reset Password” Control Access Right, a.k.a. Extended Right, on the targeted AD user account
    • Permissions to read/query the Microsoft-AzureADPasswordProtection-DCAgent/Admin Event Log
  • Create a PSO that allows a minimum password length of 7 characters (minimum word length of 4 + 3 additional characters)
  • Assign the user account directly to that PSO
  • ActiveDirectory PowerShell CMDlets

image

Figure 1: Example Details Of The AD User Account To Test Words Against

image

Figure 2: Example Details Of The AD User Account To Test Words Against

.\AAD-Password-Protection-Check-Custom-AAD-Banned-Word-List.ps1 –accountName <Domain FQDN>\<sAMAccountName> -inputFileWordsFullPath <Input File With Candicate Words To Test>

image

Figure 3: PowerShell Script That Checks Every Word In The Input File And Reports On It

You can download the script from here

Have fun!

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

2 Responses to “(2019-10-28) Azure AD Password Protection (A.k.a. Banned Password List) – Optimizing The Custom Per Tenant List (Part 6)”

  1. […] « (2019-10-28) Azure AD Password Protection (A.k.a. Banned Password List) – Optimizing The Custo… […]

    Like

  2. […] would be easy to determine what is already on the global MSFT list (also see: (2019-10-28) Azure AD Password Protection (A.k.a. Banned Password List) – Optimizing The Custom Pe… […]

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

 
%d bloggers like this: