Resolved: Passwords must meet complexity requirements

Resolved: Passwords must meet complexity requirements

Recently we were working on synchronizing passwords between an onPremise AD deployment and Azure Directory Services. As part of that we had to enable a strong password policy (You can configure this security setting by opening the appropriate policy and expanding the console tree: Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\) which resulted in lots of “Passwords must meet complexity requirements” errors.

Reading and lurking around we found that a strong password policy is defined on a Windows Server as a policy that at a minimum complies with the following requirements:

• Passwords must not contain the user’s entire samAccountName (Account Name) value or entire displayName (Full Name) value. Both checks are not case sensitive: 
  • The samAccountName is checked in its entirety only to determine whether it is part of the password. If the samAccountName is less than three characters long, this check is skipped.
  • The displayName is parsed for delimiters: commas, periods, dashes or hyphens, underscores, spaces, pound signs, and tabs. If any of these delimiters are found, the displayName is split and all parsed sections (tokens) are confirmed not to be included in the password. Tokens that are less than three characters in length are ignored, and substrings of the tokens are not checked. For example, the name “Erin M. Hagens” is split into three tokens: “Erin,” “M,” and “Hagens.” Because the second token is only one character long, it is ignored. Therefore, this user could not have a password that included either “erin” or “hagens” as a substring anywhere in the password.
• Passwords must contain characters from three of the following five categories:
  • Uppercase characters of European languages (A through Z, with diacritic marks, Greek and Cyrillic characters)
  • Lowercase characters of European languages (a through z, sharp-s, with diacritic marks, Greek and Cyrillic characters)
  • Base 10 digits (0 through 9)
  • Nonalphanumeric characters: ~!@#$%^&*_-+=`|\(){}[]:;”‘<>,.?/
  • Any Unicode character that is categorized as an alphabetic character but is not uppercase or lowercase. This includes Unicode characters from Asian languages.

We actually got a randomly generated password that to our best knowledge complied with all the policies. So what were we doing wrong? After several ties and failures, we concluded that the issue was the password length. This seems ironic as the longer the password is the safest it results… but apparently there are limits. We were using 25 characters and then 30 characters in order to provide several of the required character categories multiple times.

We finally resolved that a password cannot be longer than 16 characters in length when using Azure Directory Services via Windows Essentials Experience. I am actually not sure if that applies as well in regular scenarios or if it is particular of this method. We generally recommend long passwords for service accounts and I don’t remember encountering this issue before. The one thing that blows my mind is why you get the message “Passwords must meet complexity requirements” when really the problem is the length not its complexity.

When you install Windows Server Essentials or 2012 R2 with Essentials Experience you are taken through a wizard that at some point informs you that in order to proceed with the sync you need to enable the strong password policy. At that point possibly the restriction is put in place but I’m not sure if it was there all along or not.