With more integration of applications and systems into Active Directory, hardening the security of a Windows domain is now more important than ever. The aspects of security controlled by business users (i.e. setting passwords) are often the weakest elements in a business’ cybersecurity programme. This is where resources such as penetration testing, advisory services, and software for risk management are most valuable – providing expert help in identifying vulnerabilities and helping you manage security success ongoing.
Penetration Testing to Identify Weak Passwords
When conducting penetration tests, we often find that accounts with Domain Admins privilege (or equivalent, such as Enterprise Admins or Built-in Domain Administrators) are using passwords that are not secure.
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 feature that allows you to implement multi-grained password policies. Unfortunately, it’s still impossible to control the complexity requirements with this feature (for example, additional special character requirements); 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), but this is out of the scope of this article.
The steps outlined below give a quick and straightforward way to implement the Active Directory features for high privilege accounts, such as those with Administrative privileges. We have also included 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 as a minimum.
Implementation of Secure Password Policies
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. For this example, we will be implementing a 15-character minimum password requirement:
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 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 in 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 to become active.
The following PowerShell command will assign the password policy to the ‘Administrators’ group. This will apply to both the ‘Domain Admins’ and ‘Enterprise Admins’ groups in most standard configurations.
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.
Including 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
Penetration Testing, Advisory Services, and Software for Risk Management
SureCloud offers a range of security services and products that aim to guide you in protecting your digital assets. As this example demonstrates, we can test for gaps in your security measures and advise on how to remedy them. In addition, our software for risk management allows you to manage all security elements in-house in one central system.
To find out which of our products or services would be best for your business, fill in the contact form below.
While every effort is made to ensure the accuracy and robustness of any information presented, it is not possible for SureCloud to test every possible scenario an organisation may face, and SureCloud cannot be held liable for any loss or damage which may arise from taking action on any of the contents provided. SureCloud 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.