0

On some windows server I would like to set different password complexity depending for exemple on the password length. Is it possible to make conditions, so I can have a high level of complexity with password length=8 and a low level or no complexity with password length=16 or more.

thanks for your advices.

dominix
  • 366
  • 2
  • 3
  • 12
  • Are you referring to Active Directory Accounts, or local User Accounts? – Semicolon Dec 19 '19 at 21:51
  • If AD accounts, then no you cannot --- unequivocally --- have different passwords for the same accounts depending upon which computer the user logs into. – Semicolon Dec 19 '19 at 21:52
  • hi @Semicolon , I don't want different passwords, I want different Policies. – dominix Dec 19 '19 at 23:15
  • For local accounts on different machines- yes. For domain accounts, you can't do it based upon computer, but you can use Fine-Grained Poassword Policies to configure different minimum lengths per user or geoup. – Semicolon Dec 20 '19 at 00:05
  • Local accounts cannot have different password policies; all local accounts use the same requirements – Semicolon Dec 20 '19 at 00:05
  • I'll try to explain differently. Is it possible to have a policy validated by code, like a regex for example – dominix Dec 20 '19 at 17:46

2 Answers2

2

It is possible to write your own code for password criteria. The DLL can be registered on member computers or domain controllers.

https://docs.microsoft.com/en-us/windows/win32/secmgmt/installing-and-registering-a-password-filter-dll

This would not work if "Additional LSA Protection" is enabled due to it requires LSA DLL's to be signed by Microsoft.

https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection

Greg Askew
  • 34,339
  • 3
  • 52
  • 81
0

As pointed out, it is possible to leverage a custom password filter leveraging the passfilt.dll. In fact, I make use of one such filter (or one of its forks) available on GitHub. It is called OpenPasswordFilter. I opted to use this filter because documentation for system administrators as to how to create and manage a custom password filter is sparse. While I generally have seen this used to configure a blacklist of passwords, one should be able to perform the validation of which you ask. The question would be how difficult is it to do so using a custom password filter?

However, these changes need to be rolled out to each Domain Controller and each new Domain Controller. Given today's level of automation and configuration management, it is likely not super difficult, but it is something else that has to be monitored and maintained.

All in all, it is a fine solution, but one with limited documentation. Your successor's may also have difficulty supporting, updating and extending this solution - a factor to consider when deciding to implement it.

I believe the most straightforward solution to your question is the use of Fine-Grained Password Policies. This can be implemented very quickly with minimal testing; these settings are automatically replicated among all Domain Controllers. The down side; however, is that it does require some end-user participation/election.

My solution would be the following:

  • Create two new FGPPs
    • 1: minimum legnth of 8; complexity enabled
    • 2: minimum length of 16; complexity disabled
  • Create two new security groups
    • 1: pso_MinLength08
    • 2: pso_MinLength16
  • Assign each group as a subject of the appropriate FGPP
  • Inform end users of thier options -- either a short "complex" password or a long "easy" password. They can switch back and forth whenever they want, with notice to you.
  • Add users to the corresponding group based upon their election; you can default them to the short complex group.
  • Change as necessary

Some notes on the above, or other considerations:

You can achieve the same thing with a single group. My preference for visibility is to use two, but by ensuring the Default Domain Password Policy is configured with a minimum length of 8 and complexity enabled, you limit the number of group changes that need to be made. - you only have to add users to a group if they make an election - you do not have to ensure that users are members of only one group, or - you do not have to configure different precedece values on each FGPP

While I am onboard with NIST and Microsoft (for the most part) when it comes to password rotation, my employer does still mandates password rotation. I have chosen to "reward" users who accept longer password minimums by only rotating passwords once per year. Those with shorter password requirements are "penalized" with quarterly password change. In my mind, this is too frequent to be usefull, but I hope that this annoyance provides sufficient incentive for users to swith to longer password minimums.

While not noted above, if you do use FGPPs in this manner, I would certainly configure a different precedence on each of the Password Settings Options to ensure that there is no unexpected behavior when changing passwords. This would address the issue that one might experience if they are a member of both groups, and the precendce on both FGPPs was equal.

Regardless of what method you choose, I would point out that you should be sure to exclude the account "krbtgt" from any such password complexity validations. I have a separate FGPP for this account and those similar accounts used by Read-Only Domain Controllers to ensure that their password changes are not impacted. My krbtgt FGPP as no length, age, or complexity requirements.

Semicolon
  • 1,646
  • 7
  • 7