1. Introduction
AD Starter Scan – Unconstrained delegation is a dangerous Kerberos delegation setting that allows compromised servers to impersonate users on your network. This can lead to complete account takeover and privilege escalation, impacting the confidentiality, integrity, and availability of Active Directory resources. It typically affects smaller Active Directory deployments (up to 5000 users) used for preliminary analysis.
2. Technical Explanation
Kerberos allows servers to request tickets on behalf of users. Trusted for delegation means a server can obtain a user’s credentials and use them to access other resources. Unconstrained delegation occurs when this trust is granted without restrictions, allowing any service on the server to impersonate any user. An attacker compromising a server with unconstrained delegation enabled can steal user credentials and move laterally through the network.
- Root cause: Kerberos delegation is allowed without proper constraints, specifically Trusted for Delegation being set on servers that are not domain controllers.
- Exploit mechanism: An attacker compromises a server trusted for unconstrained delegation, then uses its credentials to authenticate to other services as any user.
- Scope: Active Directory environments using Kerberos authentication, particularly smaller deployments (up to 5000 users) where preliminary analysis is being performed with AD Starter Scan plugins.
3. Detection and Assessment
You can confirm unconstrained delegation by checking which accounts are trusted for delegation. A thorough assessment involves reviewing all servers configured for Kerberos delegation.
- Quick checks: Use PowerShell to list computers with unconstrained delegation enabled:
Get-ADComputer -Filter 'msDS-AllowedToDelegateTo *' -Properties msDS-AllowedToDelegateTo | Where {$_.msDS-AllowedToDelegateTo} - Scanning: Nessus vulnerability ID c3b56c92 can identify unconstrained delegation.
- Logs and evidence: Security event logs on domain controllers may show Kerberos requests for delegated credentials. Look for Event ID 4761 (Kerberos Authentication Ticket Requested) with Delegation flags set.
Get-ADComputer -Filter 'msDS-AllowedToDelegateTo *' -Properties msDS-AllowedToDelegateTo | Where {$_.msDS-AllowedToDelegateTo}4. Solution / Remediation Steps
Restrict unconstrained delegation to only domain controller accounts and protect administrators against dangerous delegation types.
4.1 Preparation
- Ensure you have documented the current configuration for roll back purposes. A roll back plan involves restoring the previous configuration from the backup/snapshot.
- Changes should be approved by a senior administrator or security team member.
4.2 Implementation
- Step 1: Remove ‘Trusted for Delegation’ permission from all non-domain controller accounts. Use Active Directory Users and Computers (ADUC) to modify the account properties.
- Step 2: Add domain controller accounts to the ‘Protected Users’ group. This prevents attackers from relaying their credentials.
- Step 3: Set the ‘Account is sensitive and cannot be delegated’ flag on all administrator user accounts. This further protects against delegation attacks.
4.3 Config or Code Example
Before
msDS-AllowedToDelegateTo: *After
msDS-AllowedToDelegateTo: 4.4 Security Practices Relevant to This Vulnerability
Several security practices can help prevent this issue.
- Practice 1: Least privilege – grant only the necessary permissions to accounts, reducing the impact if compromised.
- Practice 2: Secure defaults – configure Active Directory with secure settings from the start, minimizing unnecessary delegation trusts.
4.5 Automation (Optional)
PowerShell can be used to automate the removal of unconstrained delegation permissions.
# Get all computers with unconstrained delegation
$Computers = Get-ADComputer -Filter 'msDS-AllowedToDelegateTo *' -Properties msDS-AllowedToDelegateTo
# Loop through each computer and clear the permission if it is not a domain controller
foreach ($Computer in $Computers) {
if ($Computer.ObjectClass -eq "computer") {
$ComputerName = $Computer.Name
Write-Host "Removing unconstrained delegation from: $ComputerName"
Set-ADComputer -Identity $ComputerName -ClearProperty msDS-AllowedToDelegateTo
}
}5. Verification / Validation
Confirm the fix by re-running the PowerShell command and verifying that no non-domain controller accounts have unconstrained delegation enabled.
- Post-fix check: Run
Get-ADComputer -Filter 'msDS-AllowedToDelegateTo *' -Properties msDS-AllowedToDelegateTo | Where {$_.msDS-AllowedToDelegateTo}and confirm the output only lists domain controller accounts. - Re-test: Re-run the Nessus scan (c3b56c92) to verify that the vulnerability is no longer detected.
- Smoke test: Verify users can still authenticate to key services like email, file shares, and applications.
- Monitoring: Monitor security event logs for Kerberos authentication events with delegation flags set, looking for any unexpected activity.
Get-ADComputer -Filter 'msDS-AllowedToDelegateTo *' -Properties msDS-AllowedToDelegateTo | Where {$_.msDS-AllowedToDelegateTo}6. Preventive Measures and Monitoring
Update security baselines to prevent unconstrained delegation, add checks in CI/CD pipelines, and implement a regular patch review cycle.
- Baselines: Update your Active Directory security baseline or Group Policy Object (GPO) to enforce restrictions on Kerberos delegation.
- Pipelines: Add checks in your CI/CD pipeline to scan for misconfigured accounts with unconstrained delegation permissions.
- Asset and patch process: Implement a regular review cycle (e.g., monthly) to identify and remediate any new instances of unconstrained delegation.
7. Risks, Side Effects, and Roll Back
Removing ‘Trusted for Delegation’ from accounts may break applications or services that rely on Kerberos delegation. A roll back involves restoring the original configuration from your backup/snapshot.
- Roll back: Restore Active Directory from the backup/snapshot taken prior to making any changes.
8. References and Resources
Links only to sources that match this exact vulnerability.
- Vendor advisory or bulletin: https://adsecurity.org/?p=1667
- NVD or CVE entry: Not applicable for this specific scan finding.
- Product or platform documentation relevant to the fix: https://learn.microsoft.com/en-us/windows