How to remediate – Active Directory – Enumerate User Account Policy

1. Introduction

The vulnerability “Active Directory – Enumerate User Account Policy” allows retrieval of settings from the ‘Default Domain Policy’ Group Policy Object (GPO) via Active Directory Service Interfaces (ADSI). This can expose sensitive information about password policies, account lockout configurations, and Kerberos settings. Affected systems are typically Windows domain controllers running Active Directory. A successful exploit could lead to unauthorized access to user account details and potential compromise of the entire domain. Confidentiality, integrity, and availability may be impacted if attackers use this information for reconnaissance or further attacks.

2. Technical Explanation

The vulnerability occurs because the ‘Default Domain Policy’ GPO settings are accessible via ADSI queries without sufficient access controls. An attacker with domain user privileges can query Active Directory to retrieve these policy details. There is no known CVE associated with this specific enumeration, but it represents a common information disclosure risk in Active Directory environments. An example attack involves using PowerShell or other scripting tools to read the attributes of the ‘Default Domain Policy’ object and extract password complexity requirements, account lockout duration, and Kerberos ticket lifetime settings.

• Root cause: Insufficient access controls on the ‘Default Domain Policy’ GPO via ADSI queries.
• Exploit mechanism: An attacker uses tools like PowerShell to query Active Directory for the attributes of the ‘Default Domain Policy’.
• Scope: Windows domain controllers running Active Directory.

3. Detection and Assessment

You can confirm vulnerability by checking if the ‘Default Domain Policy’ settings are readable via ADSI queries. A thorough method involves attempting to retrieve specific policy attributes using PowerShell.

• Quick checks: Check the version of your Active Directory schema.
• Scanning: Nessus plugin ID 139628 can identify this issue as an example, but results may vary.
• Logs and evidence: Review Active Directory event logs for unusual queries targeting the ‘Default Domain Policy’ object. Look for Event IDs related to ADSI access.

Get-ADObject -Filter "objectClass = groupPolicyContainer" -LDAPFilter "(name='Default Domain Policy')" | Select-Object name, distinguishedName

4. Solution / Remediation Steps

The primary solution is to restrict access to the ‘Default Domain Policy’ GPO settings via ADSI queries. This involves modifying permissions on the object in Active Directory.

4.1 Preparation

• Ensure you have appropriate administrative credentials to modify Active Directory permissions. Roll back plan: Restore from snapshot if issues occur.
• A change window may be required, and approval should be sought from security or infrastructure teams.

4.2 Implementation

1. Step 1: Open ‘Active Directory Users and Computers’.
2. Step 2: Navigate to the ‘Default Domain Policy’ container within the domain.
3. Step 3: Right-click on ‘Default Domain Policy’ and select ‘Properties’.
4. Step 4: Go to the ‘Security’ tab.
5. Step 5: Edit permissions for the ‘Authenticated Users’ group.
6. Step 6: Remove ‘Read’ permission from the ‘Authenticated Users’ group.
7. Step 7: Apply and OK all changes.

4.3 Config or Code Example

Before

Authenticated Users - Read & Write

After

Authenticated Users - No Access

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege is crucial to limit the impact of potential exploits. Input validation, while not directly applicable here, helps protect against other Active Directory attacks. Secure defaults and a regular patch cadence are also important for overall system security.

• Practice 1: Implement least privilege principles by granting only necessary permissions to users and groups.
• Practice 2: Regularly review and audit Active Directory permissions to identify and correct overly permissive settings.

4.5 Automation (Optional)

PowerShell can be used to automate permission changes, but caution is advised due to the potential for unintended consequences.

# Example PowerShell script - use with caution!
# Get-ADObject -Filter "name='Default Domain Policy'" | Set-Acl -Access $(Get-ACL).SetAccessRuleProtection($true, 'Authenticated Users', 'Deny')

5. Verification / Validation

• Post-fix check: Run `Get-ADObject -Filter “objectClass = groupPolicyContainer” -LDAPFilter “(name=’Default Domain Policy’)” | Select-Object name, distinguishedName` as a standard domain user and verify access is denied.
• Re-test: Re-run the earlier detection command to confirm that you can no longer retrieve policy attributes without elevated privileges.
• Smoke test: Verify core Active Directory functionality such as user login and group membership still work as expected.
• Monitoring: Monitor Active Directory event logs for failed ADSI queries targeting the ‘Default Domain Policy’ object, which could indicate attempted exploitation.

Get-ADObject -Filter "objectClass = groupPolicyContainer" -LDAPFilter "(name='Default Domain Policy')" | Select-Object name, distinguishedName # Should return an access denied error as a standard user

6. Preventive Measures and Monitoring

Update security baselines to include restrictions on ‘Default Domain Policy’ permissions. Implement checks in CI/CD pipelines to ensure that Active Directory configurations adhere to these baselines. A sensible patch or config review cycle should be established based on the risk profile of your organization.

• Baselines: Update a CIS benchmark or internal security policy to enforce restrictive permissions on ‘Default Domain Policy’.
• Pipelines: Add checks in CI/CD pipelines to validate Active Directory configurations against security baselines.

7. Risks, Side Effects, and Roll Back

• Roll back: Restore the domain controller from the snapshot taken prior to making any changes.

8. References and Resources

• Vendor advisory or bulletin: Microsoft Documentation on Default Domain Policy
• NVD or CVE entry: No specific CVE is associated with this enumeration vulnerability.
• Product or platform documentation relevant to the fix: Managing Permissions in Active Directory