With ever more integration of applications and systems into Active Directory, hardening the security of a Windows domain is now more important than ever. When conducting penetration tests we find that accounts that have the Domain Admins privilege (or equivalent, such as Enterprise Admins or Built-in Domain Administrators) often use passwords that are weak. One way to combat this would be to alter the password policy, however forcing all users to adhere to a ‘strong’ password policy is not always feasible, and may encounter resistance from the organisation.
Active Directory has a feature that allows you to implement fine-grained password policies. Unfortunately, it’s still not possible to completely control the complexity requirements with this feature, for example requiring additional special characters, however you can alter the minimum character limit. It is possible to change the complexity requirements using a password filter DLL (Dynamic-Link Library), however that is out of scope of this article.
The steps outlined below give a quick and simple way to implement these features for high privilege accounts, such as those with Administrative privileges over the Domain; this includes some suggestions for additional groups for you to consider. It’s worth noting that this feature requires a minimum domain functional level of Windows Server 2008 or above.
Entra/M365 offers a feature called Azure AD Password Protection, which can help enforce global banned password lists and custom password policies. This protection operates independently of on-premises fine-grained password policies but can complement password security across both environments if configured.
When a password is reset in Entra/M365, it is not subject to the on-premises fine-grained password policies; the reset will follow Entra/M365’s password policies. The new password, once written back to on-premises Active Directory, will still be subject to on-premises FGPPs for future changes (eg. for password expiration).
Log onto a Domain Controller and open a PowerShell window, ensuring you are running as an Administrator.
Run the following command to create the new policy (with 15-character minimum password required):
NOTE: Additional settings have been set in the above command, which are based on recommended values; however, these options may differ slightly from the password settings currently in use in your own environment. Please ensure each setting reflects the desired policy for administrators on your own domain.
Confirm the password policy has been created, by opening ADSIEdit.
The password policy has now been created, and must be assigned to a security group in order to become active.
The following PowerShell command will assign the password policy to the ‘Administrators’ group. In most standard configurations, this will then apply to both the ‘Domain Admins’ and ‘Enterprise Admins’ groups.
Additional security groups can be added where required, for example the “SQL Administrators” group. Other security groups to consider are, for example, groups where local administrator privileges are granted, or where groups contain higher privileged user accounts such as service desk users.
You can edit the password policy by navigating to it using ADSIEdit. To produce a list of objects which are assigned the policy using PowerShell, use the following command example:
Note: Ensure the policy name (“PrivAccessPWPolicy” in this example) matches the name you specified in the command when you created the policy.
With the aforementioned password policies implemented in the Domain we have hardened various accounts of differing privilege levels; Administrators, Standard Users, and Domain Administrators.
The inclusion of a stronger password requirement for privileged accounts increases the likelihood that administrators will choose to use a different password between these accounts. This in turn reduces the possibility of an attacker successfully escalating privileges to Domain Admin whilst also making the passwords more difficult to crack in the event an attacker is able to capture a hash of the password from the network.
Additional technical information is provided via several Microsoft help pages:
https://technet.microsoft.com/en-us/library/cc770394(v=ws.10).aspx
https://technet.microsoft.com/en-us/library/cc770842(v=ws.10).aspx
Whilst every effort is made to ensure the accuracy and robustness of any information presented, it is not possible for CSA to test every possible scenario an organisation may face, and CSA cannot be held liable for any loss or damage which may arise from taking action on any of the contents provided. CSA strongly advises that all recommendations, solutions and detection methods detailed, are thoroughly reviewed and tested in non-production environments before being considered suitable for production release, in-line with any existing internal change control procedures.