With 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 insecure. 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 can cause issues of its own.
Active Directory within Windows Server 2008 brought with it a new feature that allows you to implement multi-grained password policies. Unfortunately, it’s still not possible to control the complexity requirements with this feature, for example requiring additional special characters, however you can alter the minimum character limit. It is also possible to change the complexity requirements using a password filter DLL (Dynamic-Link Library), however this 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 domain functional level of Windows Server 2008 or above and of course would require the Domain level to that as a minimum.
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):
New-ADFineGrainedPasswordPolicy -Name “PrivAccessPWPolicy” -Precedence 100 -ComplexityEnabled $true -Description “Custom Password Policy for Privileged Users” -DisplayName “Privileged Access Password Policy” -LockoutDuration “0.12:00:00” -LockoutObservationWindow “0.00:15:00” -LockoutThreshold 5 -MaxPasswordAge “60.00:00:00” -MinPasswordAge “0.00:00:00” -MinPasswordLength 15 -PasswordHistoryCount 24 -ReversibleEncryptionEnabled $false
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.
Start -> Run -> Adsiedit.msc
Default naming context -> [Your Domain] -> CN=System -> CN=Password Settings Container
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.
Add-ADFineGrainedPasswordPolicySubject PrivAccessPWPolicy -Subjects ‘Administrators’
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:
$Domain=(Get-ADDomain).DistinguishedName; (Get-ADObject -identity “CN=PrivAccessPWPolicy,CN=Password Settings Container,CN=System,$Domain” -properties msDS-PSOAppliesTo).”msDS-PSOAppliesTo”
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: