From domain data to defensible identity security decisions.
This report provides visibility into the security posture of the organization's Active Directory environment, enabling stakeholders to identify risk, evaluate security controls, and prioritize remediation efforts.
At a Glance
A high-level read on where risk concentrates and where you can move the needle quickly.
Pass / Fail
Overall checks passed versus failed.
Findings by Risk Level
Distribution of findings by risk level.
Findings by Category
Distribution of findings by category, sorted by highest count.
Quick Wins
Highest-impact, lowest-effort remediations.
Top 10 Riskiest Findings
Highest-severity findings, ordered by impact.
Since Last Scan
How findings have shifted since the previous scan, and severity across recent runs.
Severity Trend Over Time
Critical / High / Moderate / Low across recent scans.
Change Highlights
How findings shifted since the previous scan (July 22, 2026).
Assessment Journey
Each milestone summarizes risk posture, changes, and key takeaways.
- Critical8
- High23
- Moderate18
- Low12
- Initial baseline established
- Use this scan as the starting point for measuring remediation progress, ownership, and risk reduction.
- Prioritize critical and high findings first before expanding effort to moderate and low exposure.
- Critical8
- High19
- Moderate13
- Low17
- Risk Score increased (+14)
- Total findings decreased (-4)
- Severity shift: High -4, Moderate -5, Low +5
- Continue the remediation approach that reduced risk and validate that fixes remain in place.
- Shift attention to persistent findings that have not changed across recent scans.
Findings
Every issue identified by the scan, grouped by category. Click any card for the description, attacker context, and remediation guidance.
Authentication and Authorization
8 findings
Accounts with Non-Expiring Passwords
Accounts with Non-Expiring Passwords
Accounts with Non-Expiring Passwords
Password expiration is not enforced on the reported accounts. The longer a password is in use, the longer attackers have to crack password hashes, actively control the account, or perform credential-based attacks against them. These accounts are often service accounts which typically have additional privileges and are targeted by attackers.
Account hashes are often obtained via network poisoning attacks or Kerberos-based attacks. Some of these attacks are difficult to detect, giving adversaries plenty of time to conduct password cracking. With today’s processing power, accounts without password rotation will eventually be compromised.
Recommendation
Remove the Password Never Expires flag from affected accounts, apply an approved rotation model, and document any business-approved exceptions.
Prerequisites
- Domain Admin or Account Operators rights to modify account attributes.
- Service owner identification and sign-off for all service accounts in scope.
- Inventory of services and applications dependent on each account.
- PAM solution enrollment considered as a preferred alternative for service accounts.
- Change control approval obtained.
Remediation Objective
- Enable password expiration for all accounts identified with the Password Never Expires flag.
- Coordinate with service owners to update service configurations after password resets.
- Enroll service accounts in a PAM solution or migrate to Group Managed Service Accounts (gMSA) where supported.
- Establish a password rotation schedule for accounts that cannot use gMSA.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Enable password expiration on a single account.
# Replace <SamAccountName> with the target account.
Set-ADUser -Identity "<SamAccountName>" -PasswordNeverExpires $false# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed list of accounts to remediate.
# CSV must contain a column named SamAccountName.
$Accounts = Import-Csv -Path ".\ApprovedAccounts.csv"
foreach ($Account in $Accounts) {
Set-ADUser -Identity $Account.SamAccountName -PasswordNeverExpires $false -WhatIf
Write-Output "Processed: $($Account.SamAccountName)"
}
# Remove -WhatIf after reviewing.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Locate the affected accountNavigate to the OU or container containing the account identified in the report.
- Open account propertiesDouble-click the account and navigate to the Account tab.
- Clear the password never expires optionIn the Account options list, uncheck the option Password never expires.
- Save changesClick OK or Apply. Coordinate with the service owner to update the service configuration before the password next expiration date.
Validation
- Confirm the PasswordNeverExpires attribute is False: Get-ADUser -Properties PasswordNeverExpires.
- Verify the account is subject to the domain password policy or a Fine-Grained Password Policy.
- Confirm dependent services are updated with a rotation plan in place.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the account dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Before-and-after PasswordNeverExpires attribute export.
- Service health validation confirming rotation plan is in place.
- Change ticket and approval record.
- Follow-up scan results showing finding resolved.
Additional Guidance
Non-expiring passwords should be limited to documented exceptions with compensating controls. Prioritize privileged, service, and externally exposed accounts, then move toward managed service accounts, vaulting, or PAM where long-lived credentials are currently required.
Accounts With Stale Passwords
Accounts With Stale Passwords
Accounts With Stale Passwords
Stale passwords provide attackers with additional opportunities to perform credential-based attacks and can prolong access to systems if compromised.
Attackers use credential stuffing, password spraying, or brute-force attacks to crack weak or outdated passwords that remain unchanged for extended periods. Tools like Mimikatz, Impacket, or Kerbrute can help identify and exploit these accounts, especially if they have elevated privileges. Once compromised, attackers can use the account for lateral movement, persistence, and privilege escalation, often going undetected due to a lack of regular password audits.
Recommendation
Reset stale active account passwords, apply standard lifecycle controls, and document any approved exceptions.
Prerequisites
- Domain Administrator credentials required.
- Distinguish between user accounts and service accounts, as the remediation approach differs.
- Confirm with account owners or service teams whether each account is still in active use.
- Obtain change control approval.
Remediation Objective
- Reset passwords for active accounts that have not had a password change within the defined policy threshold.
- Disable accounts confirmed as inactive that have stale passwords.
- Ensure all active user accounts adhere to the organization's password change policy.
- Reduce the risk of credential compromise through aged passwords that may have been exposed in prior incidents.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Force a password reset on next logon for a stale account.
# Replace <SamAccountName> with the target account.
Set-ADUser -Identity "<SamAccountName>" -ChangePasswordAtLogon $true
# Or disable the account if confirmed inactive:
# Disable-ADAccount -Identity "<SamAccountName>"# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed and approved list of accounts with stale passwords.
# Required CSV columns: SamAccountName, Action (Reset or Disable)
$Accounts = Import-Csv -Path ".\ApprovedAccounts.csv"
foreach ($Account in $Accounts) {
if ($Account.Action -eq "Reset") {
Set-ADUser -Identity $Account.SamAccountName -ChangePasswordAtLogon $true -WhatIf
} elseif ($Account.Action -eq "Disable") {
Disable-ADAccount -Identity $Account.SamAccountName -WhatIf
}
}
# Remove -WhatIf after reviewing output.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.msc. - Locate the affected accountNavigate to the OU containing the account.
- Force a password resetRight-click the account and select Reset Password. Set a temporary password and check 'User must change password at next logon'.
- Or disable the account if inactiveRight-click the account and select Disable Account.
- Repeat for approved affected accountsComplete the same GUI process for each account listed in the approved remediation plan.
Validation
- Confirm password last set date is updated: Get-ADUser -Identity <SamAccountName> -Properties PasswordLastSet
- Verify inactive accounts are disabled.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the account dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Export of PasswordLastSet values for affected accounts before remediation.
- Change ticket and approval record.
- PowerShell output confirming password resets or account disables.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Threat actors frequently search for stale credentials as an easy entry point into Active Directory environments. These accounts often go unnoticed in security monitoring, making them valuable for long-term persistence. Once compromised, they can be leveraged to access sensitive resources or conduct further attacks while appearing as legitimate users. Many organizations find that utilizing a PAM (Privileged Access Management) tool helps to better manage domain-based credentials.
Kerberos Armoring Not Enabled
Kerberos Armoring Not Enabled
Kerberos Armoring Not Enabled
Not enabling Kerberos armoring leaves the Kerberos authentication process vulnerable to pre-authentication attacks, such as AS-REP Roasting. Kerberos armoring enhances the security of the protocol by protecting the pre-authentication steps and ensures stronger protection during authentication.
Ransomware groups utilize this tactic to obtain an authenticated position within Active Directory, which then leads to more advanced attacks. It's often one of the first attacks carried out once access to the internal network is obtained.
Recommendation
Enable Kerberos Armoring where supported, validate client and service compatibility, and document any systems that require exception.
Prerequisites
- Locate any legacy clients or services that may not support Kerberos Armoring before enabling enforcement.
- Back up affected GPO before modification.
- Obtain change control approval.
- Test in a pilot OU before broad deployment if legacy systems are present.
Remediation Objective
- Enable Kerberos Armoring (FAST) to protect Kerberos pre-authentication exchanges from offline attacks.
- Prevent downgrade attacks against Kerberos by enforcing armored ticket exchanges between clients and domain controllers.
- Reduce the attack surface for credential harvesting techniques that target Kerberos AS-REQ traffic.
- Align domain authentication configuration with current Microsoft Kerberos security guidance.
Remediation Path 1: Command-Line
Not applicable. A command-line remediation is not the preferred remediation method for this finding because Kerberos armoring should be enabled through Group Policy so KDC and client compatibility settings are scoped, tested, and rolled back through standard policy management.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Group Policy Management ConsoleLaunch
gpmc.mscfrom an administrative workstation. - Edit or create the relevant GPORight-click the GPO linked to the Domain Controllers OU and select Edit.
- Navigate to Kerberos Armoring settingsGo to Computer Configuration > Administrative Templates > System > KDC.
- Enable Kerberos ArmoringOpen 'KDC support for claims, compound authentication and Kerberos armoring' and set it to Enabled. Select 'Supported' to enable without enforcing for legacy compatibility, or 'Always provide claims and fail unarmored authentication requests' for full enforcement.
- Configure client-side policyIn the same GPO or a client-targeted GPO, navigate to Computer Configuration > Administrative Templates > System > Kerberos. Enable 'Kerberos client support for claims, compound authentication and Kerberos armoring' and set to Supported or Required.
- Apply and testUse the organization-approved policy refresh process on a test domain controller and client. Confirm Kerberos authentication is successful.
Validation
- Confirm the KDC Kerberos Armoring GPO setting is applied on domain controllers using gpresult /r.
- Verify Kerberos Armoring is active by reviewing Kerberos authentication events on domain controllers (Event ID 4768).
- Confirm no authentication failures are occurring on clients after GPO application.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the authentication dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- GPO backup before and after modification.
- gpresult output confirming GPO application on domain controllers and test clients.
- Kerberos authentication event log review confirming no failures.
- Change ticket and approval record.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Kerberos Armoring, also known as FAST (Flexible Authentication Secure Tunneling), wraps Kerberos pre-authentication exchanges in a secure tunnel, preventing offline cracking of AS-REQ traffic and protecting against certain downgrade attacks. It is a supported feature in Windows Server 2012 and later environments and should be enabled in any modern domain.
Non-Expiring Passwords in Domain Admins Group
Non-Expiring Passwords in Domain Admins Group
Non-Expiring Passwords in Domain Admins Group
Non-expiring passwords in the Domain Admins group pose a risk, as these static credentials can be easily targeted by attackers with credential-based attacks. Passwords that are not rotated for long periods of time increase the likelihood for compromise and persistence.
Once attackers obtain password hashes, they use password lists and rulesets to crack them. Non-expiring passwords are especially risky, as modern graphics cards provide the computational power to crack hashes more easily.
Recommendation
Remove non-expiring password settings from Domain Admin accounts, rotate affected credentials, and document any approved break-glass exception.
Prerequisites
- Domain Admin rights to modify account attributes.
- All affected Domain Admins notified in advance.
- Service accounts in Domain Admins group (if any) coordinated with service owners.
- PAM solution enrollment prepared as a preferred alternative.
- Change control approval obtained.
Remediation Objective
- Enable password expiration for all Domain Admin accounts with the Password Never Expires flag set.
- Enroll Domain Admin accounts in a PAM solution or enforce a rotation schedule of 90 days or less.
- Coordinate with all affected administrators to ensure they are aware of and prepared for the upcoming expiration.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Enable password expiration on a Domain Admin account.
# Replace <SamAccountName> with the target admin account.
Set-ADUser -Identity "<SamAccountName>" -PasswordNeverExpires $false# Import the Active Directory module.
Import-Module ActiveDirectory
# Get all Domain Admins with non-expiring passwords.
$DomainAdmins = Get-ADGroupMember -Identity "Domain Admins" -Recursive |
Get-ADUser -Properties PasswordNeverExpires |
Where-Object { $_.PasswordNeverExpires -eq $true }
# Display the accounts identified.
$DomainAdmins | Select SamAccountName, PasswordNeverExpires
# Apply the change from an approved CSV.
# CSV must contain a column named SamAccountName.
$Accounts = Import-Csv -Path ".\ApprovedDomainAdmins.csv"
foreach ($Account in $Accounts) {
Set-ADUser -Identity $Account.SamAccountName -PasswordNeverExpires $false -WhatIf
Write-Output "Processed: $($Account.SamAccountName)"
}
# Remove -WhatIf after reviewing.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Navigate to the Domain Admins groupLocate and open the Domain Admins group. Review the Members tab and locate accounts with non-expiring passwords.
- Update each accountOpen each account's properties, navigate to the Account tab, and uncheck Password never expires.
- Communicate to affected administratorsNotify each administrator of the change and the upcoming password expiration timeline.
Validation
- Confirm PasswordNeverExpires is False for all Domain Admin accounts: Get-ADGroupMember -Identity 'Domain Admins' | Get-ADUser -Properties PasswordNeverExpires.
- Verify administrators can authenticate and that no service disruptions occurred.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the privileged access dependency and justification.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Before-and-after PasswordNeverExpires attribute export for all Domain Admin accounts.
- Administrator notification records.
- Change ticket and approval record.
- Follow-up scan results showing finding resolved.
Additional Guidance
Enforce password expiration policies for all accounts in the Domain Admins group to ensure regular password updates and reduce the risk of long-term compromise. Review service accounts with non-expiring passwords, and where possible, replace them with managed service accounts (MSAs) or third-party applications such as Privileged Access Management (PAM) toolsets.
NTLMv1 or LM is Permitted
NTLMv1 or LM is Permitted
NTLMv1 or LM is Permitted
Allowing NTLMv1 or LM authentication on domain controllers poses a significant security risk, as these outdated protocols are vulnerable to cryptographic attacks. Attackers can capture and exploit NTLMv1 hashes to impersonate users and gain unauthorized access to critical systems, potentially compromising the entire domain through attacks like coerced authentication.
Using outdated protocols like NTLMv1 or LM authentication increases the risk of attacks, such as network poisoning, where attackers can capture hashes or force authentications from sensitive assets like domain controllers. These attacks can easily occur from an unauthenticated position within the domain.
Recommendation
Configure LAN Manager authentication to refuse LM and NTLMv1, validate client compatibility, and monitor for legacy authentication failures.
Prerequisites
- Domain Admin or Group Policy rights to configure GPOs.
- Inventory of systems and applications using NTLMv1 or LM authentication completed.
- Change control approval obtained.
- Testing performed in a non-production environment or limited pilot scope before domain-wide enforcement.
Remediation Objective
- Configure the Network security: LAN Manager authentication level GPO policy to Send NTLMv2 response only and refuse LM and NTLM.
- Deploy the policy change in phases, monitoring for authentication failures before enforcing broadly.
- Remediate or isolate legacy systems that cannot support NTLMv2.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Set the NTLM authentication level via registry on a single system.
# This is an alternative to GPO for standalone systems.
$RegistryPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"
Set-ItemProperty -Path $RegistryPath -Name "LmCompatibilityLevel" -Value 5 -Type DWord
# LmCompatibilityLevel values:
# 0 = Send LM and NTLM
# 1 = Send LM and NTLMv2
# 2 = Send NTLM only
# 3 = Send NTLMv2 only
# 4 = Send NTLMv2, refuse LM
# 5 = Send NTLMv2, refuse LM and NTLM (most secure)
Write-Output "NTLM level set to 5 on $env:COMPUTERNAME"Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Group Policy Management ConsoleLaunch
gpmc.mscfrom an administrative workstation. - Create or edit a GPO linked to the domain or Domain Controllers OURight-click the appropriate location and edit or create a GPO.
- Navigate to the NTLM authentication level settingGo to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.
- Configure the NTLM levelLocate Network security: LAN Manager authentication level. Double-click and set the value to Send NTLMv2 response only. Refuse LM and NTLM.
- Deploy in phasesApply the GPO to a test OU first, monitor for authentication failures, and then extend the scope to the domain after validating compatibility.
Validation
- Confirm the LmCompatibilityLevel registry value is 5 on domain controllers.
- Monitor Event ID 4624 and 4625 for authentication failures after the policy is applied.
- Verify no legacy systems or applications are experiencing authentication failures.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the authentication dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Before-and-after LmCompatibilityLevel registry export from domain controllers.
- GPO backup showing the authentication level policy.
- Authentication event monitoring results confirming no unexpected failures.
- Change ticket and approval record.
Additional Guidance
NTLMv1 and LM authentication protocols are vulnerable to capture-and-relay attacks and offline cracking. An attacker who can intercept NTLMv1 authentication can use it to authenticate to other systems without cracking the password. Modern environments should operate exclusively on NTLMv2 at minimum, with Kerberos as the preferred protocol for all internal authentication.
Organizations should assess their broader NTLM usage and work toward reducing reliance on NTLM authentication entirely where Kerberos is available. Network monitoring should be configured to detect NTLMv1 authentication events and alert when they are observed, as this may indicate legacy systems or active downgrade attacks.
Privileged Users with Stale Passwords
Privileged Users with Stale Passwords
Privileged Users with Stale Passwords
Stale administrative passwords provide attackers with additional opportunities to perform credential-based attacks and if compromised, can prolong system access.
Organizations that properly tier and enforce best practices around privileged accounts typically take significantly more time to compromise. This forces the attacker to rely on other attack avenues such as network poisoning or social engineering.
Recommendation
Reset stale privileged account passwords, enforce appropriate rotation or lifecycle controls, and validate updated password timestamps.
Prerequisites
- Domain Admin or Password Reset rights for privileged accounts in scope.
- Notification sent to affected privileged users prior to password reset.
- Service owner identification and sign-off for any service accounts in scope.
- Change control approval obtained.
- PAM solution enrollment prepared if available.
Remediation Objective
- Reset passwords on all privileged accounts with stale credentials.
- Enforce a password rotation policy for privileged accounts, or enroll accounts in a PAM solution for automated credential management.
- Confirm dependent services are updated with new credentials where applicable.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Reset the password on a privileged user account.
# Replace <SamAccountName> with the target privileged account.
Set-ADAccountPassword -Identity "<SamAccountName>" -Reset -NewPassword (Read-Host -AsSecureString "Enter new password") -PassThru# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed list of privileged accounts with stale passwords.
# CSV must contain a column named SamAccountName.
$Accounts = Import-Csv -Path ".\ApprovedPrivilegedAccounts.csv"
foreach ($Account in $Accounts) {
Set-ADAccountPassword -Identity $Account.SamAccountName -Reset `
-NewPassword (Read-Host -AsSecureString "New password for $($Account.SamAccountName)") -WhatIf
Write-Output "Processed: $($Account.SamAccountName)"
}
# Remove -WhatIf after reviewing.
# Get each new password to the account's owner securely.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Locate the affected privileged accountNavigate to the OU containing the privileged account identified in the report.
- Reset the passwordRight-click the account and select Reset Password. Enter a strong password meeting complexity requirements. Uncheck User must change password at next logon for service accounts; check it for human user accounts where appropriate.
- Notify the account ownerContact the account owner through a secure channel to provide the new password or initiate a self-service reset flow.
- Update dependent servicesFor service accounts, update the service logon credentials on all dependent systems and restart the services as needed.
Validation
- Confirm the PasswordLastSet attribute has been updated for affected accounts.
- Verify that any dependent services are running and authenticating successfully.
- Confirm the account owner has successfully authenticated with the new credential.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the privileged access dependency and justification.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Before-and-after PasswordLastSet attribute export for affected accounts.
- Service health validation results.
- Change ticket and approval record.
- Follow-up scan results showing finding resolved.
Additional Guidance
Stale privileged passwords increase the value of old credential material and should be addressed through a privileged account lifecycle process. Use PAM, strong rotation standards, and periodic review to ensure administrative accounts do not retain long-lived secrets.
Stale krbtgt Account Password
Stale krbtgt Account Password
Stale krbtgt Account Password
The krbtgt account is a crucial component in the Kerberos authentication system in Active Directory, as its password is used to sign Kerberos tickets. A stale krbtgt password increases the risk of a “Golden Ticket” attack, where attackers can forge valid Kerberos tickets, granting unauthorized access to any resource in the domain.
Attackers will remotely dump domain controllers upon achieving domain administrator level access with toolsets like Impacket’s secretsdump.py. The krbtgt account is one of the most powerful accounts within Active Directory, and is one of the first hashes to be dumped. Attackers will then use this password hash to perform Golden Ticket attacks. It is particularly valuable for persistence, allowing attackers to stay in your environment even after remediation has occurred.
Recommendation
Rotate the krbtgt password using a controlled two-reset process and confirm domain controller replication.
Prerequisites
- Domain Admin or equivalent rights to reset the krbtgt account password.
- Confirm all writable domain controllers are healthy and replicating successfully.
- Download and review Microsoft’s published krbtgt reset script before execution.
- Obtain change approval and schedule a maintenance window for the reset.
Remediation Objective
- Rotate the krbtgt account password in a controlled manner to reduce Golden Ticket risk.
- Use the Microsoft-published script to validate domain controller reachability and replication.
- Perform two resets with the required wait period between resets to clear old keys from password history.
- Monitor authentication and replication health after each reset.
Remediation Path 1: Command-Line
Microsoft and the security community recommend using either New-KrbtgtKeys.ps1 or Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1. Both scripts include health checks, simulation modes, replication monitoring, and RODC account handling.
Script repositories: https://github.com/microsoftarchive/New-KrbtgtKeys.ps1, https://github.com/zjorz/Public-AD-Scripts/blob/master/Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1
# Instructions for New-KrbtgtKeys.ps1
# Review the script, test the informational/simulation modes, and run from an approved admin workstation.
# Example workflow:
# 1. Run informational mode to review writable domain controllers and krbtgt status.
# 2. Run simulation mode to validate replication before making changes.
# 3. Run the production reset mode for the first krbtgt reset.
# 4. Wait longer than the domain Kerberos ticket lifetime, then repeat production reset mode.
# 5. Save the script transcript and validate replication after each reset.
.\New-KrbtgtKeys.ps1Remediation Path 2: GUI
The scripted remediation path is preferred as it provides checks, features, and controls that make this change safer for most environments.
- Open Active Directory Users and ComputersOn an administrative workstation or writable domain controller, open Active Directory Users and Computers.
- Enable Advanced FeaturesSelect View, then select Advanced Features so the krbtgt account is visible and manageable.
- Locate the krbtgt accountExpand the domain container, select Users, and locate the krbtgt user account. Do not reset any RODC-specific krbtgt_number account unless separately instructed as part of an RODC recovery process.
- Reset the krbtgt passwordRight-click the krbtgt account and select Reset Password. Enter and confirm a new password, then click OK. The specific password entered is not significant because Windows generates the actual strong password value automatically.
- Allow ticket lifetime and replication delayWait at least 10 hours before performing the second reset, or longer if the domain uses a longer maximum lifetime for user or service tickets. Confirm replication health before proceeding.
- Reset the password a second timeRepeat the password reset on the krbtgt account after the waiting period. The second reset clears older krbtgt password material from history and helps invalidate previously issued Kerberos tickets.
- Monitor authenticationAfter each reset, monitor domain controller replication, Kerberos authentication, and service authentication for errors before closing the change.
Validation
- Confirm the script reports successful replication to all writable domain controllers.
- Review the krbtgt PasswordLastSet value after each reset.
- Run repadmin /replsummary and confirm replication is healthy.
- Review domain controller security event logs for Event IDs 4724 and 4738 to confirm both resets.
- Monitor domain controller and authentication logs for Kerberos or service failures.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- There are no broadly accepted exceptions for this control that justifies indefinite deferral.
- Document the business reason for delaying krbtgt rotation.
- Assign an owner and target remediation date.
- Increase monitoring for Golden Ticket indicators until rotation is complete.
- Require formal risk acceptance for any extended deferral.
Evidence
- Script transcript or log showing informational, simulation, and reset execution.
- repadmin /replsummary output before and after each reset.
- krbtgt PasswordLastSet evidence captured after both resets.
- Change ticket, approval record, and maintenance window documentation.
- Follow-up scan results showing the finding resolved.
Additional Guidance
The krbtgt account is the foundation of Kerberos authentication in Active Directory. Its password hash is used to sign every Kerberos ticket issued in the domain, and its compromise enables a Golden Ticket attack that grants persistent, domain-wide administrative access. A forged ticket created from a compromised krbtgt hash remains valid until the password has been rotated twice, because the domain retains the two most recent password versions in its history. A single reset is not sufficient for full remediation.
Organizations should establish a formal rotation schedule at a cadence of at least every 180 days, and immediately following any domain controller compromise, privileged account compromise, or security incident in which domain credential exposure is possible. Routine rotations should be treated as planned maintenance events: confirm replication health, allow full convergence between resets, and notify the service desk.
User Accounts with DES Enabled
User Accounts with DES Enabled
User Accounts with DES Enabled
DES is an outdated and weak encryption algorithm that is easily cracked, due to its weak 56-bit key length. Attackers can exploit this weakness by cracking Kerberos tickets encrypted with DES, allowing them to steal user credentials and escalate privileges within the domain.
DES-enabled accounts are easily detected with hacker toolsets and once observed, typically result in a successful password crack.
Recommendation
Disable DES encryption on affected user accounts, confirm compatible Kerberos encryption settings, and validate authentication after the change.
Prerequisites
- Domain Admin or Account Operators rights to modify account attributes.
- Review of affected accounts completed to locate any legacy Kerberos application dependencies.
- Change control approval obtained.
Remediation Objective
- Disable DES encryption on all identified user accounts by clearing the Use DES encryption types for this account flag.
- Confirm accounts are configured to use AES or stronger encryption algorithms.
- Verify dependent services continue to function after the change.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Disable DES encryption on a single user account.
# Replace <SamAccountName> with the target account.
Set-ADUser -Identity "<SamAccountName>" -KerberosEncryptionType "RC4", "AES128", "AES256"
# Alternatively, clear the USE_DES_KEY_ONLY flag from UserAccountControl.
$Account = Get-ADUser -Identity "<SamAccountName>" -Properties UserAccountControl
$NewUAC = $Account.UserAccountControl -band -bnot 0x200000
Set-ADUser -Identity "<SamAccountName>" -Replace @{UserAccountControl = $NewUAC}# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed list of accounts to remediate.
# CSV must contain a column named SamAccountName.
$Accounts = Import-Csv -Path ".\ApprovedAccounts.csv"
foreach ($Account in $Accounts) {
Set-ADUser -Identity $Account.SamAccountName -KerberosEncryptionType "RC4", "AES128", "AES256" -WhatIf
Write-Output "Processed: $($Account.SamAccountName)"
}
# Remove -WhatIf after reviewing.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Locate the affected accountNavigate to the OU or container containing the account identified in the report.
- Open account propertiesDouble-click the account and navigate to the Account tab.
- Locate the DES optionIn the Account options list, uncheck the option Use DES encryption types for this account.
- Save changesClick OK or Apply.
Validation
- Confirm the USE_DES_KEY_ONLY flag is cleared: Get-ADUser -Properties UserAccountControl and verify bit 0x200000 is not set.
- Verify the account can authenticate successfully using Kerberos.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the authentication dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Before-and-after export of UserAccountControl and KerberosEncryptionType attributes.
- Change ticket and approval record.
- PowerShell transcript of remediation commands.
- Follow-up scan results showing finding resolved.
Additional Guidance
DES is a 56-bit symmetric encryption algorithm that is no longer considered secure for any purpose. Kerberos implementations using DES are vulnerable to practical brute-force attacks with modern hardware.
Directory Services Issues
8 findings
Accidental Deletion Protection Not On OUs
Accidental Deletion Protection Not On OUs
Accidental Deletion Protection Not On OUs
Organizational Units (OUs) in Active Directory that lack accidental deletion protection are vulnerable to unintentional deletion. This could lead to significant disruptions and data loss, as the deleting OUs can remove key objects and resources in the domain. Accidental deletion protection is a safeguard that prevents the deletion of OUs unless this protection is intentionally removed.
Accidental deletion protection guards against mistakes, not attackers: it is a deny entry in the OU's permissions, and anyone who controls the OU can remove it before deleting. Its value is operational. Deleting an OU deletes every user, computer, and group in it, and recovering them takes the Active Directory Recycle Bin or an authoritative restore, during which the affected accounts cannot sign in.
Recommendation
Enable accidental deletion protection on organizational units and validate critical OU objects cannot be deleted without explicit protection removal.
Prerequisites
- Domain Administrator credentials required.
- Locate all OUs that do not currently have accidental deletion protection enabled.
- Obtain change control approval (low risk; typically included in routine hygiene work).
Remediation Objective
- Enable the 'Protect object from accidental deletion' setting on all Active Directory Organizational Units.
- Prevent inadvertent deletion of OUs that would cascade to all objects contained within them.
- Ensure OU structure integrity by requiring an explicit additional step before deletion is permitted.
- Apply consistent protection across all OUs in the domain.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Enable accidental deletion protection on a single OU.
# Replace <OUDN> with the DistinguishedName of the target OU.
Set-ADObject -Identity "<OUDN>" -ProtectedFromAccidentalDeletion $true# Import the required module for the remediation.
Import-Module ActiveDirectory
# Import a reviewed and approved list of affected objects to remediate.
$Items = Import-Csv -Path ".\ApprovedObjects.csv"
# Update only the objects included in the approved input file.
foreach ($Item in $Items) {
# Replace the placeholder command with the approved single-object remediation command for Accidental Deletion Protection Not On OU's.
# Use -WhatIf when supported before applying the change.
<Approved-Remediation-Command> -Identity $Item.DistinguishedName -WhatIf
}Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch Active Directory Users and Computers from an administrative workstation and enable Advanced Features from the View menu.
- Locate the affected OUNavigate to the OU identified in the report.
- Open OU propertiesRight-click the OU and select Properties.
- Enable deletion protectionSelect the Object tab and check Protect object from accidental deletion.
- Save the changeClick OK and repeat the same GUI process for each approved OU listed in the remediation plan.
Validation
- Confirm protection is enabled on all OUs: Get-ADOrganizationalUnit -Filter * | Select-Object Name, ProtectedFromAccidentalDeletion
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Do not approve permanent exceptions for this condition.
- Document any temporary delay with owner and target date.
- Track formal risk acceptance until remediation is complete.
Evidence
- List of OUs without protection before remediation.
- PowerShell output confirming all OUs are protected.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Accidental deletion protection should be enabled on important OUs to reduce the risk of disruptive administrative mistakes. Pair the setting with change control and periodic OU reviews so protection does not interfere with planned lifecycle management.
| Object | Type |
|---|---|
| Domain Controllers | Organizational unit |
LDAPS Channel Binding Disabled
LDAPS Channel Binding Disabled
LDAPS Channel Binding Disabled
Disabling LDAPS channel binding creates a vulnerability where an attacker can perform relay attacks by intercepting and forwarding LDAP packets through an LDAPS connection without proper verification. Channel binding helps secure LDAPS by tying the TLS channel to the LDAP authentication process, preventing unauthorized packet relay.
This misconfiguration is typically attacked through network poisoning to elevate privileges. In some configurations it is possible to force authentication from critical assets which can then be relayed.
Recommendation
Enable LDAPS channel binding, test dependent LDAP clients, and validate domain controllers enforce the approved binding configuration.
Prerequisites
- Domain Admin or local admin rights on domain controllers.
- Review of LDAPS client applications to confirm they support channel binding.
- Change control approval obtained.
Remediation Objective
- Enable LDAPS channel binding on all domain controllers by setting the LdapEnforceChannelBinding registry value.
- Verify that all LDAPS clients support channel binding before enforcing.
- Confirm LDAPS connectivity is unaffected after the change.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Enable LDAPS channel binding on a domain controller.
$RegistryPath = "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters"
Set-ItemProperty -Path $RegistryPath -Name "LdapEnforceChannelBinding" -Value 2 -Type DWord
# Values: 0 = Disabled, 1 = Enabled when supported, 2 = Always required
Write-Output "LDAPS channel binding enforced on $env:COMPUTERNAME"# Apply LDAPS channel binding to multiple domain controllers.
# CSV must contain a column named ServerName.
$Servers = Import-Csv -Path ".\ApprovedDomainControllers.csv"
foreach ($Server in $Servers) {
Invoke-Command -ComputerName $Server.ServerName -ScriptBlock {
$Path = "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters"
Set-ItemProperty -Path $Path -Name "LdapEnforceChannelBinding" -Value 2 -Type DWord -WhatIf
Write-Output "Processed: $env:COMPUTERNAME"
}
}
# Remove -WhatIf after the change has been reviewed and approved.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Registry EditorLaunch regedit on the domain controller.
- Navigate to the NTDS Parameters keyGo to HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.
- Create or modify LdapEnforceChannelBindingLocate or create the DWORD value LdapEnforceChannelBinding. Set it to 2 to enforce channel binding for all LDAPS connections.
- Apply the changeClose Registry Editor. A restart may be required. Monitor the Directory Service event log for any LDAPS connection failures after the change.
Validation
- Confirm LdapEnforceChannelBinding is set to 2 on all domain controllers.
- Test LDAPS connectivity from known applications to confirm no disruptions.
- Review Directory Service event logs for any channel binding failure events.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the authentication dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Registry export confirming LdapEnforceChannelBinding is set to 2.
- LDAPS connectivity test results.
- Event log review confirming no connection failures.
- Change ticket and approval record.
Additional Guidance
LDAPS channel binding ties the TLS negotiation to the LDAP authentication session, preventing an attacker who intercepts a TLS session from relaying it to a different LDAP session. This control, combined with LDAP signing, provides comprehensive protection against LDAP relay attacks. Microsoft began rolling out default channel binding requirements in 2020, and organizations should align with or exceed these defaults.
Enabling channel binding should be coordinated with the enforcement of LDAP signing, as the two controls work together to protect LDAP communications. Organizations should test both controls together in a pilot environment before enforcing domain-wide.
LDAP Signing Not Enforced on Domain Controllers
LDAP Signing Not Enforced on Domain Controllers
LDAP Signing Not Enforced on Domain Controllers
When LDAP signing is not enforced on domain controllers, the LDAP traffic is vulnerable to man-in-the-middle (MitM) attacks, where attackers can intercept and modify requests between clients and servers. This allows attackers to manipulate LDAP queries, potentially gaining unauthorized access or modifying sensitive directory data, such as adding users to privileged groups.
Malicious actors look to perform MitM attacks in this fashion to add themselves to the Domain Administrators group.
Recommendation
Identify clients using unsigned LDAP binds, enable LDAP signing enforcement, and validate that dependent applications continue to authenticate successfully.
Prerequisites
- Domain Admin or Group Policy rights to create and modify GPOs linked to domain controllers.
- LDAP event monitoring enabled (Event ID 2886, 2887, 2888, 2889) to locate unsigned LDAP clients before enforcing.
- Application and device owner review completed.
- Change control approval obtained.
- Rollback plan documented.
Remediation Objective
- Enable LDAP event logging on domain controllers to locate clients using unsigned or unencrypted LDAP binds.
- Remediate or update all identified clients before enforcing LDAP signing.
- Set the LDAP server signing requirements policy to Require signing on all domain controllers.
- Verify that all legitimate LDAP clients continue to function after enforcement.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Enable LDAP signing enforcement on domain controllers via registry.
# This is an alternative to GPO for individual domain controllers.
$RegistryPath = "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters"
Set-ItemProperty -Path $RegistryPath -Name "LDAPServerIntegrity" -Value 2 -Type DWord
Write-Output "LDAP signing set to Require on $env:COMPUTERNAME"
# Values: 0 = None, 1 = Negotiate signing, 2 = Require signingRemediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Event ViewerOn domain controllers, open Event Viewer and review the Directory Service log for LDAP signing-related events collected during the approved monitoring period.
- Open Group Policy Management ConsoleLaunch Group Policy Management Console from an administrative workstation.
- Edit the domain controller policyRight-click the Default Domain Controllers Policy or the approved hardening GPO linked to the Domain Controllers OU and select Edit.
- Navigate to the LDAP signing settingGo to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.
- Require LDAP signingOpen Domain controller: LDAP server signing requirements, set it to Require signing, and save the setting.
- Review post-change eventsAfter normal policy refresh occurs, use Event Viewer to monitor the Directory Service log for rejected unsigned bind events and coordinate remediation for any affected applications.
Validation
- Confirm the LDAPServerIntegrity registry value is set to 2 on all domain controllers.
- Verify no Event ID 2889 (simple bind without SSL) entries appear in the Directory Service log after enforcement.
- Test LDAP connectivity from known applications to confirm they continue to function.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the dependency and business justification.
- Assign a server owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- LDAP event log review output showing no unsigned bind events after enforcement.
- GPO backup showing LDAP signing requirement.
- Application connectivity test results.
- Change ticket and approval record.
Additional Guidance
LDAP signing is a foundational control that ensures the integrity of directory queries and authentication exchanges between clients and domain controllers. Without it, an attacker in a network-adjacent position can intercept and modify LDAP traffic, potentially injecting privilege escalation commands or harvesting credentials. Microsoft has been progressively tightening default LDAP signing requirements, and organizations should align with current best practices.
The recommended approach is to enable LDAP diagnostic logging first, monitor for unsigned bind events over several weeks, remediate any non-compliant clients, and then enforce signing. This phased approach minimizes the risk of service disruption while ensuring full protection is achieved.
No Domain Controller Redundancy
No Domain Controller Redundancy
No Domain Controller Redundancy
Relying on a single domain controller for managing Active Directory services significantly increases the risk of a single point of failure. If a domain controller becomes inoperable, this practice could cause significant downtime and a lack of service availability.
Single point of failures signify poor security posture and embolden attackers, particularly relating to ransomware attacks.
Recommendation
Deploy an additional domain controller and confirm replication and authentication health.
Prerequisites
- Domain or Enterprise Admin rights required to promote an additional domain controller.
- A server (physical or virtual) meeting hardware.
- Change control approval obtained prior to domain controller promotion.
- Rollback plan documented in case of promotion failure.
Remediation Objective
- Deploy a minimum of two domain controllers to eliminate the single point of failure.
- Configure replication between domain controllers to ensure consistent directory state.
- Verify DNS registration for the new domain controller.
- Confirm Flexible Single Master Operations (FSMO) roles are distributed appropriately across available domain controllers.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Promote a new server to a domain controller (run on the target server).
Import-Module ADDSDeployment
# Install the AD Domain Services role on the target server.
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
# Promote the server as an additional domain controller in the existing domain.
# Replace <DomainName> with your domain FQDN.
# You'll be prompted for the DSRM password. Save it in your password manager first.
Install-ADDSDomainController `
-DomainName "<DomainName>" `
-InstallDns:$true `
-Credential (Get-Credential) `
-SafeModeAdministratorPassword (Read-Host -AsSecureString "DSRM password") `
-Force:$trueRemediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Server ManagerLaunch Server Manager on the server designated as the new domain controller.
- Add the Active Directory Domain Services roleClick Manage, then Add Roles and Features. Select Active Directory Domain Services and complete the wizard.
- Promote the server to a domain controllerAfter role installation, click the notification flag in Server Manager and select Promote this server to a domain controller.
- Select deployment operationChoose Add a domain controller to an existing domain, then enter the domain name and credentials for a Domain Admin or Enterprise Admin account.
- Configure additional optionsConfirm DNS and Global Catalog options are enabled. Set the Directory Services Restore Mode (DSRM) password and select a replication source.
- Complete promotionReview settings and click Install. The server will restart and complete promotion automatically.
Validation
- Verify the new domain controller appears in Active Directory Sites and Services.
- Confirm DNS records for the new domain controller are registered using nslookup or Get-DnsClientCache.
- Run repadmin /replsummary to confirm replication is healthy between all domain controllers.
- Verify FSMO role placement is appropriate using netdom query fsmo.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the dependency and business justification.
- Assign a server owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Change ticket and approval record for domain controller promotion.
- Screenshot or export of AD Sites and Services showing both domain controllers.
- repadmin /replsummary output confirming healthy replication.
- FSMO role assignment record (netdom query fsmo output).
- Follow-up scan results showing finding resolved.
Additional Guidance
Domain controller redundancy supports both authentication availability and operational resilience. Plan additional domain controller deployment with site placement, DNS, replication health, and backup coverage in mind so the environment does not rely on a single authentication path.
Recycle Bin is Disabled
Recycle Bin is Disabled
Recycle Bin is Disabled
The Recycle Bin within Active Directory allows for restoration and extends traceability in the event objects need to be recovered.
Recycle bin disablement signify to attackers that configurations may not be at baseline and embolden attacker actions.
Recommendation
Enable the Active Directory Recycle Bin, confirm forest readiness, and validate object recovery procedures.
Prerequisites
- Enterprise Administrator credentials required.
- Confirm the domain functional level is Windows Server 2008 R2 or higher.
- Note that enabling the AD Recycle Bin is irreversible.
- Obtain change control approval.
Remediation Objective
- Enable the Active Directory Recycle Bin to support recovery of accidentally deleted objects without requiring authoritative restore.
- Reduce recovery time and administrative risk in the event of accidental or malicious object deletion.
- Ensure deleted objects are retained in a recoverable state for a configurable tombstone lifetime period.
- Align AD configuration with Microsoft-recommended resilience practices.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Enable the AD Recycle Bin for the domain.
# Must be run as Enterprise Administrator.
Import-Module ActiveDirectory
Enable-ADOptionalFeature -Identity "Recycle Bin Feature" `
-Scope ForestOrConfigurationSet `
-Target (Get-ADForest).Name -Confirm:$false
Write-Output "AD Recycle Bin enabled."# Import the required module for the remediation.
Import-Module ActiveDirectory
# Import a reviewed and approved list of affected objects to remediate.
$Items = Import-Csv -Path ".\ApprovedObjects.csv"
# Update only the objects included in the approved input file.
foreach ($Item in $Items) {
# Replace the placeholder command with the approved single-object remediation command for Recycle Bin is Disabled.
# Use -WhatIf when supported before applying the change.
<Approved-Remediation-Command> -Identity $Item.DistinguishedName -WhatIf
}Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open the Active Directory Administrative CenterLaunch
dsac.exefrom an administrative workstation. - Navigate to the domainIn the left pane, click the domain name.
- Enable Recycle BinIn the Tasks pane on the right, click 'Enable Recycle Bin...'.
- Confirm the operationRead the warning that this action is irreversible and click OK to proceed.
- ValidateRefresh the domain view and confirm the Recycle Bin feature appears as enabled.
Validation
- Confirm Recycle Bin is enabled: Get-ADOptionalFeature -Filter {Name -eq 'Recycle Bin Feature'} | Select-Object Name, EnabledScopes
- Verify a deleted test object can be recovered: remove a test OU, then restore it using Restore-ADObject.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Do not approve permanent exceptions for this condition.
- Document any temporary delay with owner and target date.
- Track formal risk acceptance until remediation is complete.
Evidence
- Current domain and forest functional level confirmation.
- Change ticket and approval record.
- PowerShell output confirming Recycle Bin is enabled.
- Test object recovery confirmation.
Additional Guidance
The Active Directory Recycle Bin improves recovery options for deleted objects and should be enabled after confirming forest readiness. Because the change is irreversible, validate prerequisites and communicate the operational impact before enabling it.
Stale AD Backup
Stale AD Backup
Stale AD Backup
Backups of the Active Directory database are not updated or maintained according to best practices. Outdated backups can fail to capture recent changes in the environment, making them unreliable for recovery or rollback in the event of a failure or security incident.
Stale AD backups signify poor security posture and embolden attackers, particularly relating to ransomware attacks.
Recommendation
Restore regular Active Directory backup coverage, confirm recent successful System State or full server backups, and retain evidence for recovery readiness.
Prerequisites
- Domain Admin or equivalent rights to access backup configuration on domain controllers.
- Access to the backup solution used for Active Directory (Windows Server Backup, third-party agent, or similar).
- Change control approval if modifying backup schedules in a production environment.
- Locate which domain controllers are included in the current backup scope.
Remediation Objective
- Ensure that Active Directory System State or full server backups are being performed for all domain controllers.
- Verify that backup jobs are completing successfully and that backup media is current.
- Establish or enforce a backup schedule that meets Microsoft's recommended standards (at minimum, daily backups).
- Configure alerting for failed or overdue backup jobs.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Run from an elevated command prompt or PowerShell session on the affected domain controller.
# Replace <BackupTargetVolumeOrShare> with the approved backup destination.
wbadmin start systemstatebackup -backupTarget:<BackupTargetVolumeOrShare> -quiet
# Optional: review backup versions after the job completes.
wbadmin get versionsRemediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Windows Server BackupLaunch Windows Server Backup from Server Manager on the domain controller.
- Review the backup scheduleIn the Windows Server Backup console, click Backup Schedule and confirm that a scheduled backup job exists and is configured to include the System State or full server backup.
- Verify the last backup statusReview the backup job history to confirm that the most recent backup completed successfully and is within the acceptable window.
- Configure alertingIf your backup solution supports email or SIEM alerting, configure notifications for failed or overdue backup jobs.
- Document the backup configurationRecord the backup schedule, scope, retention period, and storage location in your change management or configuration documentation.
Validation
- Confirm the most recent backup timestamp using repadmin /showbackup or the backup solution console.
- Verify the last backup completed without errors by reviewing the backup job history.
- Confirm alerting is configured for failed backup jobs.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the business justification for any exception.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Backup job history export or screenshot confirming successful completion.
- repadmin /showbackup output captured before and after remediation.
- Change ticket and approval record for backup schedule modification.
- Alerting configuration documentation.
Additional Guidance
Active Directory backups should be treated as a critical recovery control, not just an infrastructure task. Review backup freshness, restore test results, and ownership regularly so the organization can recover from directory corruption, ransomware, or accidental administrative changes.
Unknown Account within Delegation
Unknown Account within Delegation
Unknown Account within Delegation
An account linked to a delegation cannot be resolved or does not exist. This situation may occur if the account has been deleted or is from another domain. Unknown accounts in delegations can pose a security risk, as it is unclear who has the delegated permissions, potentially leading to unauthorized access.
While this is more of an AD hygiene issue, attackers could exploit the ambiguity around who holds the delegated permissions. This lack of clarity can allow them to gain unauthorized access while remaining undetected.
Recommendation
Remove unknown or unresolved SIDs from delegation settings and validate that only approved principals retain delegated permissions.
Prerequisites
- Domain Administrator credentials required.
- Review the account or SID listed in the delegation attribute and attempt to resolve it to a known account.
- Confirm with the system owner that the SID is genuinely orphaned and not a valid account from a trusted domain.
- Back up the affected delegation attribute value before clearing.
- Obtain change control approval.
Remediation Objective
- Remove unknown or unresolvable account SIDs from Active Directory delegation attributes.
- Eliminate orphaned SID entries in delegation configurations that could indicate a former privileged account or a trust-based escalation path.
- Ensure all delegation assignments are attributable to known, active, and documented accounts.
- Reduce the risk of stale delegation entries being exploited or causing confusion in access control analysis.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Review delegation-related attributes for a specific computer account.
# Replace <ComputerName> with the target computer name.
Get-ADComputer -Identity "<ComputerName>" `
-Properties msDS-AllowedToDelegateTo, msDS-AllowedToActOnBehalfOfOtherIdentity `
| Select-Object Name, msDS-AllowedToDelegateTo, msDS-AllowedToActOnBehalfOfOtherIdentity
# To clear the resource-based constrained delegation attribute:
Set-ADComputer -Identity "<ComputerName>" `
-Clear msDS-AllowedToActOnBehalfOfOtherIdentity# Import the required module for the remediation.
Import-Module ActiveDirectory
# Import a reviewed and approved list of affected objects to remediate.
$Items = Import-Csv -Path ".\ApprovedObjects.csv"
# Update only the objects included in the approved input file.
foreach ($Item in $Items) {
# Replace the placeholder command with the approved single-object remediation command for Unknown Account within Delegation.
# Use -WhatIf when supported before applying the change.
<Approved-Remediation-Command> -Identity $Item.DistinguishedName -WhatIf
}Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open ADSI Edit or Active Directory Users and Computers (with Advanced Features enabled)Launch
adsiedit.mscordsa.msc. - Locate the affected objectNavigate to the computer or user account identified in the report.
- Open the Attribute EditorRight-click the object and select Properties, then click the Attribute Editor tab.
- Review delegation attributesLocate msDS-AllowedToDelegateTo or msDS-AllowedToActOnBehalfOfOtherIdentity and review the listed values.
- Remove the unknown SIDEdit the attribute and remove the unresolvable SID entry.
- Save and validateClick OK. Confirm with the system owner that delegation for valid services is unaffected.
Validation
- Confirm the delegation attribute no longer contains the unknown SID: Get-ADComputer -Identity <ComputerName> -Properties msDS-AllowedToActOnBehalfOfOtherIdentity
- Verify that legitimate Kerberos delegation for valid service accounts is unaffected.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the privileged access dependency and justification.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Export of delegation attribute values before changes.
- Change ticket and approval record.
- PowerShell output confirming delegation attribute is updated.
- Confirmation from system owner that valid delegation is unaffected.
Additional Guidance
Unknown account SIDs in delegation attributes typically result from deleted accounts that held delegation permissions. While a deleted account cannot be used for authentication, its SID remaining in a delegation configuration may indicate that delegation was granted to an account without proper lifecycle management. In rare cases, an unresolvable SID could represent an account from a removed trusted domain that was granted delegation rights, which represents a residual trust-based access path worth investigating.
| Object | Type |
|---|---|
| CN=AdminSDHolder,CN=System,DC=snaplabs,DC=local | AdminSdHolder |
| Administrators | Group |
| Domain Admins | Group |
| Group Policy Creator Owners | Group |
| Key Admins | Group |
| Schema Admins | Group |
| Enterprise Admins | Group |
| Enterprise Key Admins | Group |
| DC$ | Account |
Weak LDAP Encryption
Weak LDAP Encryption
Weak LDAP Encryption
Weak LDAP encryption occurs when outdated and vulnerable SSL protocols, such as SSLv2 or SSLv3, are used to secure LDAP traffic. These protocols are considered weak and can be exploited by attackers to intercept and decrypt sensitive directory information, potentially leading to unauthorized access or data manipulation.
This misconfiguration is typically attacked through network poisoning to elevate privileges or obtain an initial foothold within the domain.
Recommendation
Disable weak SSL protocols on domain controllers, enable modern TLS settings, and validate LDAPS connectivity from dependent applications.
Prerequisites
- Domain Admin or local admin rights on domain controllers.
- Inventory of applications and devices using LDAPS with weak protocols completed.
- Change control approval obtained.
- Rollback plan documented (re-enabling via registry if compatibility issues arise).
Remediation Objective
- Disable SSLv2 and SSLv3 on all domain controllers via Schannel registry settings.
- Ensure TLS 1.2 or higher is enabled and functioning.
- Verify LDAPS connectivity continues to work after the change.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
Operational caution: Disabling legacy protocols may affect older LDAPS clients. Test application compatibility before broad deployment.
# Configure Schannel protocol settings on one approved domain controller.
# Run during a maintenance window and restart the server after the change.
$ProtocolsPath = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols"
$Settings = @(
@{ Path = "SSL 2.0\Server"; Enabled = 0; DisabledByDefault = 1 },
@{ Path = "SSL 3.0\Server"; Enabled = 0; DisabledByDefault = 1 },
@{ Path = "TLS 1.2\Server"; Enabled = 1; DisabledByDefault = 0 }
)
foreach ($Setting in $Settings) {
$Path = Join-Path $ProtocolsPath $Setting.Path
New-Item -Path $Path -Force | Out-Null
Set-ItemProperty -Path $Path -Name Enabled -Value $Setting.Enabled -Type DWord
Set-ItemProperty -Path $Path -Name DisabledByDefault -Value $Setting.DisabledByDefault -Type DWord
}# Import reviewed domain controllers for Schannel updates.
# CSV column: ServerName.
$Servers = Import-Csv -Path ".\ApprovedDomainControllers.csv"
foreach ($Server in $Servers) {
Invoke-Command -ComputerName $Server.ServerName -ScriptBlock {
$ProtocolsPath = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols"
$Settings = @(
@{ Path = "SSL 2.0\Server"; Enabled = 0; DisabledByDefault = 1 },
@{ Path = "SSL 3.0\Server"; Enabled = 0; DisabledByDefault = 1 },
@{ Path = "TLS 1.2\Server"; Enabled = 1; DisabledByDefault = 0 }
)
foreach ($Setting in $Settings) {
$Path = Join-Path $ProtocolsPath $Setting.Path
if (-not (Test-Path $Path)) { New-Item -Path $Path -Force -WhatIf | Out-Null }
if (Test-Path $Path) {
Set-ItemProperty -Path $Path -Name Enabled -Value $Setting.Enabled -Type DWord -WhatIf
Set-ItemProperty -Path $Path -Name DisabledByDefault -Value $Setting.DisabledByDefault -Type DWord -WhatIf
}
}
}
}
# Remove every -WhatIf after the change has been reviewed and approved.
# In the dry run, keys that don't exist yet only show the New-Item step.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Registry EditorLaunch regedit on the domain controller with administrative rights.
- Navigate to Schannel ProtocolsGo to HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols.
- Disable SSLv2Create or navigate to the SSL 2.0\Server subkey. Set Enabled to 0 and DisabledByDefault to 1.
- Disable SSLv3Create or navigate to the SSL 3.0\Server subkey. Set Enabled to 0 and DisabledByDefault to 1.
- Enable TLS 1.2Create or navigate to the TLS 1.2\Server subkey. Set Enabled to 1 and DisabledByDefault to 0.
- Restart the serverA restart is required for Schannel changes to take effect. Schedule during a maintenance window.
Validation
- Confirm SSLv2 and SSLv3 are disabled by testing with an SSL scanner or using openssl s_client against the LDAPS port.
- Verify TLS 1.2 is functioning correctly by testing LDAPS connectivity from known applications.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the authentication dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Before-and-after Schannel registry export.
- SSL scanner output confirming weak protocols are disabled.
- LDAPS connectivity test results.
- Server restart documentation.
- Change ticket and approval record.
- Follow-up scan results showing finding resolved.
Additional Guidance
SSLv2 and SSLv3 contain fundamental cryptographic weaknesses that make them vulnerable to decryption attacks. Organizations should configure all domain controllers to support only TLS 1.2 or higher for LDAPS connections. IIS Crypto or similar tools can provide a convenient interface for managing Schannel settings across multiple servers.
Organizations should also review TLS cipher suite configuration to ensure that weak cipher suites are disabled alongside weak protocol versions. A comprehensive Schannel hardening exercise should cover protocol versions, cipher suites, and key exchange algorithms to ensure the LDAPS implementation meets current security standards.
Hybrid Identity
18 findings
Disabled Synchronization Account Retains Sensitive Permissions
Disabled Synchronization Account Retains Sensitive Permissions
Disabled Synchronization Account Retains Sensitive Permissions
A disabled recognized synchronization account still has privileged group membership, replication rights, password reset rights, group modification rights, or other sensitive permissions in Active Directory.
Disabling an account blocks new interactive sign-in but does nothing to the AD rights already granted to it, so a disabled sync account that still sits in a privileged group or holds DCSync rights is functionally still a live credential to anyone who captured its hash before it was disabled. Attackers specifically look past the Enabled flag during reconnaissance for this exact reason: a disabled account with retained privilege is often assumed safe and excluded from monitoring, even though re-enabling it or replaying a previously captured Kerberos ticket works exactly as it did before.
Recommendation
Confirm the account is retired, then remove its privileged memberships and delegated permissions before deleting it according to policy.
Prerequisites
- Domain Admin or equivalent delegated rights to review and modify the affected Active Directory object.
- Confirm the account is not a staged or recovery connector account that is expected to be reactivated.
- Change control approval obtained before modifying production identity or synchronization settings.
- Service owner or identity platform owner confirmation of the affected dependency.
Remediation Objective
- Remove standing directory authority from disabled synchronization identities.
- Correct the configuration identified by Disabled Synchronization Account Retains Sensitive Permissions.
- Reduce the associated hybrid identity attack path while preserving required business functionality.
- Document the final configuration and validation results.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Disabled Synchronization Account Retains Sensitive Permissions
# Review account status and memberships
Get-ADUser '<Account>' -Properties Enabled,memberOf
# Remove unnecessary memberships and ACEs after ownership confirmation.Bulk remediation:
Export the affected objects from Insight Recon, validate each dependency and approved scope, then apply the same change through a reviewed PowerShell script. Use `-WhatIf` where supported and retain the transcript with the change record.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open the management consoleOpen the disabled account in Active Directory Users and Computers, remove unnecessary group memberships, and review each reported object or container under Security > Advanced to remove the account’s ACEs.
Validation
- Confirm no sensitive group memberships or ACEs reference the disabled account.
- Re-run Insight Recon.
- Confirm the affected configuration now matches the approved standard.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- A disabled staging or recovery account may temporarily retain approved permissions.
- Document the recovery purpose, owner, controls, and review date.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Account status.
- Memberships and ACLs before and after remediation.
- Retirement or recovery documentation.
Additional Guidance
Disabling a synchronization account prevents normal authentication but does not remove group memberships, delegated permissions, or replication rights. Residual privileges can become active again if the account is re-enabled, restored, or otherwise abused.
Organizations should make permission removal part of the account decommissioning process rather than relying on disablement alone. Review ACLs for the account SID, remove unnecessary privileged memberships, and retain evidence that no sensitive rights remain before deleting the object.
Recognized Entra Connect Account Is Privileged
Recognized Entra Connect Account Is Privileged
Recognized Entra Connect Account Is Privileged
A recognized Microsoft Entra synchronization account is directly or transitively privileged in Active Directory. The account is a member of a Tier 0 or built-in administrative group, or otherwise receives administrative authority through nested group membership.
MSOL_ and AAD_ prefixed accounts are recognizable to any attacker who has run even a basic LDAP enumeration pass, tools like BloodHound flag accounts matching these patterns automatically. Finding one nested in Domain Admins or another Tier 0 group turns a well-known, purpose-built account into an early checkbox in a privilege-escalation path, since compromising the sync account through NTLM relay, Kerberoasting, or its own weak permissions becomes functionally equivalent to compromising Domain Admins directly.
Recommendation
Remove the synchronization account from privileged groups and delegate only the specific directory permissions required for its approved function.
Prerequisites
- Domain Admin or equivalent delegated rights to review and modify the affected Active Directory object.
- Confirm the account is used by an active synchronization component and document the required permissions.
- Change control approval obtained before modifying production identity or synchronization settings.
- Service owner or identity platform owner confirmation of the affected dependency.
Remediation Objective
- Eliminate standing Tier 0 group membership from synchronization accounts.
- Correct the configuration identified by Recognized Entra Connect Account Is Privileged.
- Reduce the associated hybrid identity attack path while preserving required business functionality.
- Document the final configuration and validation results.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Recognized Entra Connect Account Is Privileged
# Review recursive group membership
Get-ADPrincipalGroupMembership '<Account>' | Select-Object Name,DistinguishedName
# Remove an unnecessary membership
Remove-ADGroupMember -Identity '<Privileged Group>' -Members '<Account>' -Confirm:$falseBulk remediation:
Export the affected objects from Insight Recon, validate each dependency and approved scope, then apply the same change through a reviewed PowerShell script. Use `-WhatIf` where supported and retain the transcript with the change record.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open the management consoleIn Active Directory Users and Computers, open the synchronization account > Member Of.
- Locate the affected objectRemove privileged memberships that are not explicitly required, then apply scoped delegation at the intended OU or object level.
Validation
- Confirm the account is no longer a direct or nested member of privileged groups and synchronization continues successfully.
- Confirm the affected configuration now matches the approved standard.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Avoid exceptions.
- If a vendor-supported design requires a privileged membership, document the exact requirement, account owner, and compensating controls.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Group membership before and after remediation.
- Permission design.
- Successful synchronization validation.
Additional Guidance
Microsoft Entra synchronization accounts should not hold standing membership in Domain Admins, Enterprise Admins, Administrators, or other Tier 0 groups. The connector should receive narrowly scoped directory permissions instead of broad administrative membership.
Organizations should regularly review direct and nested group memberships for synchronization identities and alert on any privileged group addition. Where possible, separate connector administration from ordinary domain administration and ensure that only dedicated Tier 0 operators can manage the account.
Multiple Entra Seamless SSO Account Objects Detected
Multiple Entra Seamless SSO Account Objects Detected
Multiple Entra Seamless SSO Account Objects Detected
More than one active-directory computer object matches the AZUREADSSOACC$ name or recognized Microsoft Entra Seamless SSO account pattern within the evaluated forest. One account per synchronized forest is expected, so duplicates may indicate an incomplete migration, abandoned configuration, or naming collision.
A duplicate AZUREADSSOACC-pattern object is an easy way to hide in plain sight, most tooling assumes exactly one object per synchronized forest, so a second one can go unmonitored indefinitely. An attacker who plants a look-alike object, or repurposes a stale one left over from a migration, gains a persistence mechanism that blends into what already looks like expected hybrid identity infrastructure. Because the real trust anchor and the duplicate share a naming convention, defenders scanning by name alone can miss which one is actually live.
Recommendation
Determine which AZUREADSSOACC$ object is active for each forest and securely retire unnecessary or duplicate objects.
Prerequisites
- Domain Admin or equivalent delegated rights to review and modify the affected Active Directory object.
- Confirm the forest design and current Seamless SSO configuration before removing an object.
- Change control approval obtained before modifying production identity or synchronization settings.
- Service owner or identity platform owner confirmation of the affected dependency.
Remediation Objective
- Maintain only the intended Seamless SSO account for each synchronized forest.
- Correct the configuration identified by Multiple Entra Seamless SSO Account Objects Detected.
- Reduce the associated hybrid identity attack path while preserving required business functionality.
- Document the final configuration and validation results.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Multiple Entra Seamless SSO Account Objects Detected
Get-ADForest | Select-Object -ExpandProperty Domains | ForEach-Object {
Get-ADComputer -Server $_ -Filter "Name -like 'AZUREADSSOACC*'" -Properties Enabled,pwdLastSet,msDS-SupportedEncryptionTypesBulk remediation:
Export the affected objects from Insight Recon, validate each dependency and approved scope, then apply the same change through a reviewed PowerShell script. Use `-WhatIf` where supported and retain the transcript with the change record.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open the management consoleSearch each domain in Active Directory Users and Computers for AZUREADSSOACC.
- Locate the affected objectCompare the objects with the documented Seamless SSO configuration and retire only those confirmed to be unused.
Validation
- Confirm one intended Seamless SSO account remains per synchronized forest and that Seamless SSO operates normally.
- Confirm the affected configuration now matches the approved standard.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Multiple objects may be valid across separate forests.
- Document each object’s forest and active purpose.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Forest inventory.
- Object properties.
- Owner confirmation.
- Retirement record.
Additional Guidance
One Microsoft Entra Seamless SSO account is generally expected per synchronized forest. Additional matching objects may be legitimate in separate forests, but duplicates within the same design can indicate an incomplete migration, abandoned trust configuration, or naming collision.
Organizations should maintain a forest-to-account inventory and securely retire unused objects after confirming the active configuration. Duplicate objects should also be reviewed for stale passwords, weak encryption, dangerous delegation, and permissive ACLs because forgotten trust objects often receive less monitoring.
Multiple Enabled Synchronization Accounts Detected
Multiple Enabled Synchronization Accounts Detected
Multiple Enabled Synchronization Accounts Detected
Multiple enabled accounts match recognized Microsoft Entra synchronization account patterns. Multiple accounts can be valid for separate connectors, forests, staging designs, or Cloud Sync agents, so the finding identifies an inventory condition that requires ownership validation rather than proving misconfiguration.
Every extra enabled sync-pattern account is a fully separate, often forgotten credential carrying the same class of sensitive AD rights as the legitimate one, without adding any real synchronization capability. Attackers who find several accounts matching this naming convention will simply target whichever one has the weakest password, the broadest permissions, or the least monitoring, since compromising any one of them is equally effective.
Recommendation
Map each enabled synchronization account to an active connector, forest, staging server, or provisioning agent. Disable and retire accounts with no confirmed dependency.
Prerequisites
- Domain Admin or equivalent delegated rights to review and modify the affected Active Directory object.
- Obtain the organization’s connector, staging, forest, and Cloud Sync agent inventory.
- Change control approval obtained before modifying production identity or synchronization settings.
- Service owner or identity platform owner confirmation of the affected dependency.
Remediation Objective
- Maintain an owned and justified inventory of enabled synchronization identities.
- Correct the configuration identified by Multiple Enabled Synchronization Accounts Detected.
- Reduce the associated hybrid identity attack path while preserving required business functionality.
- Document the final configuration and validation results.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Multiple Enabled Synchronization Accounts Detected
Get-ADUser -LDAPFilter '(|(sAMAccountName=MSOL_*)(sAMAccountName=AAD_*)(sAMAccountName=ADToAADSyncServiceAccount*))' -Properties Enabled,pwdLastSet,lastLogonTimestamp,memberOfBulk remediation:
Export the affected objects from Insight Recon, validate each dependency and approved scope, then apply the same change through a reviewed PowerShell script. Use `-WhatIf` where supported and retain the transcript with the change record.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open the management consoleSearch Active Directory Users and Computers for known synchronization-account patterns.
- Locate the affected objectRecord the owner and active dependency for each account, then disable confirmed leftovers.
Validation
- Confirm every enabled account has a documented active dependency and unnecessary accounts have been disabled or removed.
- Confirm the affected configuration now matches the approved standard.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Multiple accounts are acceptable when each maps to a documented active connector, forest, staging design, or agent.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Account inventory.
- Connector-to-account mapping.
- Owner approvals.
- Retirement records.
Additional Guidance
Multiple enabled synchronization accounts may be valid in environments with multiple forests, staging servers, Cloud Sync agents, or separate provisioning connectors. The security concern is not the count alone, but whether each identity has an active owner, justified purpose, and appropriately scoped permissions.
Organizations should maintain a connector-to-account inventory and reconcile it during architecture reviews and migrations. Accounts that cannot be mapped to an active component should be disabled, monitored for impact, and evaluated for residual replication or writeback permissions.
Non-Privileged Principal Controls Synchronization Account
Non-Privileged Principal Controls Synchronization Account
Non-Privileged Principal Controls Synchronization Account
A non-Tier 0 principal can control a recognized synchronization account through password reset, GenericAll, GenericWrite, WriteDACL, WriteOwner, or another sensitive object right.
A help-desk or delegated OU-admin account with Reset Password or WriteDACL on the sync account is a shadow path to everything the sync account itself can touch, including DCSync rights if the related permissions finding is also present. An attacker only needs to compromise the lower-tier principal, reset the sync account's password, and inherit its full privilege, no direct attack on Tier 0 required. This kind of indirect path is exactly what attack-path tools like BloodHound are built to surface, and exactly what a group-membership-only review misses.
Recommendation
Remove non-Tier 0 control over the synchronization account and narrow any inherited account-management delegation that created the exposure.
Prerequisites
- Identify the approved administrators for synchronization identities and trace inherited rights to their source.
- Change control approval obtained before modifying production identity or synchronization settings.
- Service owner or identity platform owner confirmation of the affected dependency.
Remediation Objective
- Restrict administrative control of synchronization accounts to approved Tier 0 principals.
- Correct the configuration identified by Non-Privileged Principal Controls Synchronization Account.
- Reduce the associated hybrid identity attack path while preserving required business functionality.
- Document the final configuration and validation results.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Non-Privileged Principal Controls Synchronization Account
dsacls '<Synchronization account distinguished name>'
# Review the parent OU when the reported ACE is inherited.Bulk remediation:
Export the affected objects from Insight Recon, validate each dependency and approved scope, then apply the same change through a reviewed PowerShell script. Use `-WhatIf` where supported and retain the transcript with the change record.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open the management consoleOpen the synchronization account in Active Directory Users and Computers > Security > Advanced.
- Locate the affected objectRemove or narrow the risky ACE at its source, including the parent OU when inherited.
Validation
- Confirm no non-Tier 0 principal retains sensitive control rights and re-run Insight Recon.
- Confirm the affected configuration now matches the approved standard.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document any delegated operator with the exact required rights, scope, owner, and review date.
- Avoid broad help desk or account-operator delegation.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- ACL exports before and after remediation.
- Approved administrative group list.
- Change record.
Additional Guidance
A synchronization account inherits the security posture of every principal that can control it. Reset Password, GenericAll, GenericWrite, WriteDACL, or WriteOwner granted to a lower-tier administrator can provide indirect access to all replication or writeback rights held by the connector identity.
Organizations should evaluate effective control paths, not only the account’s direct permissions and group memberships. Help desk, server administration, and delegated account-management groups should not be able to manage synchronization identities unless they are formally included in the Tier 0 administrative boundary.
Inactive or Orphaned Synchronization Account
Inactive or Orphaned Synchronization Account
Inactive or Orphaned Synchronization Account
One or more enabled accounts match known Microsoft Entra synchronization account patterns but appear stale or no longer required. This check uses on-premises indicators such as account status, password age, logon activity, naming patterns, group membership, and retained directory permissions. Because the active connector configuration is not available from Active Directory alone, the finding identifies a likely orphan that requires ownership validation.
Attackers specifically hunt for exactly this kind of forgotten identity during reconnaissance: an enabled account that nobody is watching, still carrying whatever AD rights its original sync role required. A captured hash or Kerberos ticket for an orphaned sync account works exactly as well as one for an actively used account, and because nobody expects it to authenticate, unusual activity from it is far less likely to trigger a second look.
Recommendation
Confirm whether the account is still used by an active synchronization component. Disable unnecessary accounts, monitor for impact, remove retained permissions, and delete the account after the organization’s retention period.
Prerequisites
- Domain Admin or equivalent delegated rights to review and modify the affected Active Directory object.
- Identify the account owner and confirm whether Microsoft Entra Connect, Cloud Sync, or another provisioning component still depends on the account.
- Change control approval obtained before modifying production identity or synchronization settings.
Remediation Objective
- Remove unused synchronization identities and eliminate any sensitive permissions they retain.
- Correct the configuration identified by Inactive or Orphaned Synchronization Account.
- Reduce the associated hybrid identity attack path while preserving required business functionality.
- Document the final configuration and validation results.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Inactive or Orphaned Synchronization Account
# Review likely synchronization accounts
Get-ADUser -LDAPFilter '(|(sAMAccountName=MSOL_*)(sAMAccountName=AAD_*)(sAMAccountName=ADToAADSyncServiceAccount*))' -Properties Enabled,pwdLastSet,lastLogonTimestamp,memberOf
# Disable a confirmed orphan
Disable-ADAccount -Identity '<Account>'Bulk remediation:
Export the affected objects from Insight Recon, validate each dependency and approved scope, then apply the same change through a reviewed PowerShell script. Use `-WhatIf` where supported and retain the transcript with the change record.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open the management consoleIn Active Directory Users and Computers, locate the affected account and review its description, group memberships, password age, and recent activity.
- Locate the affected objectAfter confirming that no active synchronization service uses it, disable the account.
- Review the current configurationRemove delegated permissions and delete it after the approved observation period.
Validation
- Confirm the account is disabled or removed, no sensitive ACEs reference it, and synchronization operations continue normally during the observation period.
- Confirm the affected configuration now matches the approved standard.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document an exception only when the account is confirmed to support an active synchronization or provisioning component.
- Record the owner, dependency, and review date.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Account properties before and after remediation.
- Owner confirmation.
- Exported group membership and ACL data.
- Observation-period results.
Additional Guidance
Synchronization accounts should be treated as managed service identities with a documented owner, purpose, and retirement process. Accounts left behind after Microsoft Entra Connect migrations, Cloud Sync deployments, or connector replacements may retain replication, password reset, group modification, or other delegated rights long after administrators stop monitoring them.
Organizations should maintain an inventory that maps each synchronization account to an active connector or provisioning component. Disabled or apparently inactive accounts should be reviewed for residual group memberships and ACL entries, then removed through a controlled decommissioning process once the dependency has been ruled out.
Unexpected SPNs on Entra Seamless SSO Account
Unexpected SPNs on Entra Seamless SSO Account
Unexpected SPNs on Entra Seamless SSO Account
AZUREADSSOACC$ has service principal names that are not expected for the organization’s Microsoft Entra Seamless SSO deployment. Unexpected SPNs can redirect Kerberos service authentication or indicate that the account is being used for an unrelated service.
AZUREADSSOACC$ has a long, randomly generated password, so a service ticket requested for one of its SPNs cannot be cracked offline the way an ordinary service account's can. The account matters for a different reason: its Kerberos key is what Microsoft Entra ID uses to validate Seamless SSO tickets, and an attacker who obtains that key, for example through DCSync, can forge tickets that Microsoft Entra ID accepts for any synchronized user. An SPN that Microsoft does not register is either a configuration error or a sign that someone with write access to the account has changed it, so investigate it before removing it.
Recommendation
Validate each SPN on AZUREADSSOACC$ and remove registrations that are not required by the supported Seamless SSO configuration.
Prerequisites
- Domain Admin or equivalent delegated rights to review and modify the affected Active Directory object.
- Confirm the expected Seamless SSO configuration and preserve the existing SPN list for investigation.
- Change control approval obtained before modifying production identity or synchronization settings.
- Service owner or identity platform owner confirmation of the affected dependency.
Remediation Objective
- Ensure AZUREADSSOACC$ is not used to register unrelated or malicious Kerberos services.
- Correct the configuration identified by Unexpected SPNs on Entra Seamless SSO Account.
- Reduce the associated hybrid identity attack path while preserving required business functionality.
- Document the final configuration and validation results.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Unexpected SPNs on Entra Seamless SSO Account
# Review SPNs
Get-ADComputer 'AZUREADSSOACC' -Properties servicePrincipalName | Select-Object -ExpandProperty servicePrincipalName
# Remove a confirmed unexpected SPN
setspn -D '<SPN>' 'AZUREADSSOACC$'Bulk remediation:
Export the affected objects from Insight Recon, validate each dependency and approved scope, then apply the same change through a reviewed PowerShell script. Use `-WhatIf` where supported and retain the transcript with the change record.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open the management consoleIn Active Directory Users and Computers, enable Advanced Features and open AZUREADSSOACC$ > Attribute Editor.
- Locate the affected objectReview servicePrincipalName and remove only entries confirmed to be unexpected.
Validation
- Confirm only approved SPNs remain, no duplicate registrations exist, and Seamless SSO continues to operate.
- Confirm the affected configuration now matches the approved standard.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document any nonstandard SPN with its application owner, purpose, and Microsoft or vendor support basis.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- SPN list before and after remediation.
- Owner confirmation.
- Successful authentication test.
Additional Guidance
Service principal names on AZUREADSSOACC$ should match the supported Microsoft Entra Seamless SSO design. Unexpected SPNs can redirect Kerberos service authentication, create ticket-abuse opportunities, or indicate that the account is being used for an unrelated service.
Organizations should maintain a documented baseline of expected SPNs and alert on additions or removals. Review who has validated write access to servicePrincipalName, and investigate newly registered SPNs before removing them to determine whether they were part of an attack or unsupported application change.
Dangerous Kerberos Delegation on the Entra Seamless SSO Account
Dangerous Kerberos Delegation on the Entra Seamless SSO Account
Dangerous Kerberos Delegation on the Entra Seamless SSO Account
The AZUREADSSOACC$ computer account is configured for unconstrained or constrained Kerberos delegation. Resource-based constrained delegation is evaluated separately. Microsoft recommends disabling Kerberos delegation on this account.
An attacker who compromises AZUREADSSOACC$, or any system it is configured to delegate to, inherits far more than the account's own rights. Unconstrained delegation leaves a forwardable copy of every ticket that authenticates to it sitting in memory for the taking, while constrained delegation lets the holder request a ticket as any user to the configured service via S4U2self and S4U2proxy. On an account this close to the hybrid trust boundary, either path turns a single compromise into a much larger foothold with no password ever needed.
Recommendation
Remove unconstrained and constrained delegation from AZUREADSSOACC$ and investigate how the setting was introduced.
Prerequisites
- Domain Admin or equivalent delegated rights to review and modify the affected Active Directory object.
- Capture the current delegation configuration and confirm no unsupported application dependency was created around the account.
- Change control approval obtained before modifying production identity or synchronization settings.
Remediation Objective
- Ensure AZUREADSSOACC$ is not configured for Kerberos delegation.
- Correct the configuration identified by Dangerous Kerberos Delegation on the Entra Seamless SSO Account.
- Reduce the associated hybrid identity attack path while preserving required business functionality.
- Document the final configuration and validation results.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Dangerous Kerberos Delegation on the Entra Seamless SSO Account
# Review delegation
Get-ADComputer 'AZUREADSSOACC' -Properties TrustedForDelegation,TrustedToAuthForDelegation,msDS-AllowedToDelegateTo
# Disable unconstrained delegation
Set-ADAccountControl 'AZUREADSSOACC$' -TrustedForDelegation $false
# Clear constrained delegation
Set-ADComputer 'AZUREADSSOACC' -Clear 'msDS-AllowedToDelegateTo'Bulk remediation:
Export the affected objects from Insight Recon, validate each dependency and approved scope, then apply the same change through a reviewed PowerShell script. Use `-WhatIf` where supported and retain the transcript with the change record.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open the management consoleIn Active Directory Users and Computers, open AZUREADSSOACC$ > Delegation and select Do not trust this computer for delegation.
- Locate the affected objectConfirm no constrained service entries remain.
Validation
- Confirm delegation flags are disabled, msDS-AllowedToDelegateTo is empty, and Seamless SSO continues to function.
- Confirm the affected configuration now matches the approved standard.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- None expected for a standard Microsoft Entra Seamless SSO deployment.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Delegation attributes before and after remediation.
- Investigation notes.
- Successful Seamless SSO test.
Additional Guidance
Unconstrained or constrained delegation should not be configured on the Microsoft Entra Seamless SSO account. Delegation can expose or forward Kerberos authentication context and creates an unnecessary impersonation path around a hybrid identity trust object.
Organizations should remove unsupported delegation settings and monitor for future changes to userAccountControl and msDS-AllowedToDelegateTo. Any exception should be treated as Tier 0 risk and require explicit documentation, strong monitoring, and confirmation that the design is supported by Microsoft.
Entra Seamless SSO Account Is Not Protected from Delegation
Entra Seamless SSO Account Is Not Protected from Delegation
Entra Seamless SSO Account Is Not Protected from Delegation
The AZUREADSSOACC$ computer account is not marked as sensitive and cannot be delegated. This protection reduces the chance that credentials or authentication context associated with the account can be forwarded through Kerberos delegation.
Without the 'sensitive and cannot be delegated' flag, a captured ticket for AZUREADSSOACC$ can be forwarded and reused by any other system in the domain that is configured for unconstrained delegation, a far more common misconfiguration than one on this account itself. An attacker doesn't need to touch AZUREADSSOACC$ directly; they only need to compromise one of those other systems and wait for it to authenticate. This flag is the one control standing between the account and a delegation path it never chose.
Recommendation
Enable the Account is sensitive and cannot be delegated option on AZUREADSSOACC$.
Prerequisites
- Domain Admin or equivalent delegated rights to review and modify the affected Active Directory object.
- Confirm the account is the Microsoft Entra Seamless SSO account and review existing delegation settings.
- Change control approval obtained before modifying production identity or synchronization settings.
- Service owner or identity platform owner confirmation of the affected dependency.
Remediation Objective
- Prevent AZUREADSSOACC$ from being used through Kerberos delegation.
- Correct the configuration identified by Entra Seamless SSO Account Is Not Protected from Delegation.
- Reduce the associated hybrid identity attack path while preserving required business functionality.
- Document the final configuration and validation results.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Entra Seamless SSO Account Is Not Protected from Delegation
Set-ADAccountControl -Identity 'AZUREADSSOACC$' -AccountNotDelegated $trueBulk remediation:
Export the affected objects from Insight Recon, validate each dependency and approved scope, then apply the same change through a reviewed PowerShell script. Use `-WhatIf` where supported and retain the transcript with the change record.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open the management consoleIn Active Directory Users and Computers, open AZUREADSSOACC$ > Account and enable Account is sensitive and cannot be delegated.
Validation
- Confirm ACCOUNT_NOT_DELEGATED is set and no dangerous delegation attributes are configured.
- Confirm the affected configuration now matches the approved standard.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- None expected unless Microsoft documents a specific dependency for the environment.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Account control flags before and after remediation.
- Change record.
- Change ticket and approval record.
- Follow-up Insight Recon scan results showing the finding resolved.
Additional Guidance
Marking AZUREADSSOACC$ as sensitive and not delegatable provides defense in depth against Kerberos credential forwarding. This setting does not replace removal of explicit delegation, but it reduces the likelihood that the account’s authentication context can be reused through another delegation path.
Organizations should enforce the protection flag as part of the standard Seamless SSO account baseline and alert if it is removed. Review the account together with unconstrained, constrained, and resource-based constrained delegation findings so all delegation exposure is addressed consistently.
Entra Seamless SSO Account Supports Weak Kerberos Encryption
Entra Seamless SSO Account Supports Weak Kerberos Encryption
Entra Seamless SSO Account Supports Weak Kerberos Encryption
The AZUREADSSOACC$ computer account used by Microsoft Entra seamless single sign-on permits RC4 or DES Kerberos encryption. Microsoft recommends moving this account to AES-based encryption and rotating its Kerberos decryption key as part of the change.
RC4-encrypted tickets derive their key directly from the account's NTLM hash, which is comparatively cheap to crack offline with Hashcat compared to AES. An attacker who captures an RC4 service ticket for AZUREADSSOACC$ through Kerberoasting or a network capture gains a materially easier path to recovering the account's password than AES-only encryption would allow, on an account that already sits at a sensitive trust boundary.
Recommendation
Rotate the Seamless SSO Kerberos decryption key and configure AZUREADSSOACC$ to use supported AES encryption.
Prerequisites
- Domain Admin or equivalent delegated rights to review and modify the affected Active Directory object.
- Confirm domain controllers and dependent clients support AES Kerberos encryption.
- Plan a Seamless SSO maintenance window.
- Change control approval obtained before modifying production identity or synchronization settings.
- Service owner or identity platform owner confirmation of the affected dependency.
Remediation Objective
- Remove DES and RC4 support from the Microsoft Entra Seamless SSO trust account.
- Correct the configuration identified by Entra Seamless SSO Account Supports Weak Kerberos Encryption.
- Reduce the associated hybrid identity attack path while preserving required business functionality.
- Document the final configuration and validation results.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Entra Seamless SSO Account Supports Weak Kerberos Encryption
# Review the current encryption setting
Get-ADComputer 'AZUREADSSOACC' -Properties msDS-SupportedEncryptionTypes,pwdLastSet
# Follow Microsoft guidance to roll over the Seamless SSO key before enforcing AES.Bulk remediation:
Export the affected objects from Insight Recon, validate each dependency and approved scope, then apply the same change through a reviewed PowerShell script. Use `-WhatIf` where supported and retain the transcript with the change record.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open the management consoleUse Microsoft’s Seamless SSO key rollover procedure.
- Locate the affected objectAfter rollover, review AZUREADSSOACC$ in Active Directory Users and Computers with Advanced Features enabled and confirm the encryption attribute permits only approved AES types.
Validation
- Confirm the account permits the approved AES encryption types and that Seamless SSO authentication succeeds after the key rollover.
- Confirm the affected configuration now matches the approved standard.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- A temporary exception may be necessary where unsupported legacy domain controllers or clients prevent AES use.
- Document the dependency and a dated remediation plan.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Encryption setting before and after remediation.
- Key rollover record.
- Successful Seamless SSO test.
Additional Guidance
The AZUREADSSOACC$ account is a hybrid trust object used by Microsoft Entra seamless single sign-on and should be protected with current Kerberos encryption. RC4 and DES increase exposure to offline cracking and ticket-forging techniques compared with AES-based encryption.
Organizations should pair encryption hardening with the Microsoft-supported Seamless SSO key rollover process. Review the account’s encryption settings and password age regularly, and monitor for unauthorized changes to msDS-SupportedEncryptionTypes or other Kerberos-related attributes.
Synchronization Permissions Reach AdminSDHolder-Protected Objects
Synchronization Permissions Reach AdminSDHolder-Protected Objects
Synchronization Permissions Reach AdminSDHolder-Protected Objects
A recognized synchronization account has elevated permissions over AdminSDHolder or one or more AdminSDHolder-protected objects. These permissions may allow password resets, group changes, ACL modification, ownership changes, or other control of protected administrative identities.
An attacker who finds a sync account ACE on AdminSDHolder gets a backdoor that survives ordinary cleanup: SDProp reapplies the AdminSDHolder template to every protected object on roughly a 60-minute cycle, so removing the grant from an individual Domain Admin account only lasts until the next cycle silently restores it. Defenders who clean up the symptom instead of the AdminSDHolder source keep losing this fight without realizing why.
Recommendation
Remove synchronization permissions from AdminSDHolder and protected Tier 0 objects unless a documented Microsoft-supported requirement exists.
Prerequisites
- Domain Admin or equivalent delegated rights to review and modify the affected Active Directory object.
- Determine whether the ACE is applied through AdminSDHolder, directly on the object, or through a synchronization permission configuration that included protected accounts.
- Change control approval obtained before modifying production identity or synchronization settings.
- Service owner or identity platform owner confirmation of the affected dependency.
Remediation Objective
- Restore the AdminSDHolder protection boundary and prevent synchronization identities from controlling protected accounts or groups.
- Correct the configuration identified by Synchronization Permissions Reach AdminSDHolder-Protected Objects.
- Reduce the associated hybrid identity attack path while preserving required business functionality.
- Document the final configuration and validation results.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Synchronization Permissions Reach AdminSDHolder-Protected Objects
# Review AdminSDHolder ACL
dsacls 'CN=AdminSDHolder,CN=System,<Domain DN>'
# List protected objects
Get-ADObject -LDAPFilter '(adminCount=1)' -Properties nTSecurityDescriptorBulk remediation:
Export the affected objects from Insight Recon, validate each dependency and approved scope, then apply the same change through a reviewed PowerShell script. Use `-WhatIf` where supported and retain the transcript with the change record.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open the management consoleIn Active Directory Users and Computers, enable Advanced Features.
- Locate the affected objectReview CN=AdminSDHolder under the System container and each reported protected object.
- Review the current configurationRemove the synchronization ACE from its true source, then allow SDProp to reapply the corrected template.
Validation
- After a completed SDProp cycle, confirm the synchronization account no longer has the reported rights on AdminSDHolder or protected objects.
- Re-run Insight Recon.
- Confirm the affected configuration now matches the approved standard.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Avoid exceptions.
- If a supported feature was intentionally configured to include protected accounts, document the exact requirement and obtain explicit Tier 0 risk acceptance.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- AdminSDHolder and affected-object ACLs before and after remediation.
- SDProp validation.
- Approved exception documentation if applicable.
Additional Guidance
AdminSDHolder protects privileged users and groups by periodically applying a controlled security descriptor through SDProp. Synchronization permissions applied to AdminSDHolder can therefore propagate to many Tier 0 objects and may return after administrators remove the permission from an individual account or group.
Organizations should review AdminSDHolder separately from ordinary synchronization scopes and avoid including protected accounts in writeback or connector delegations. After remediation, allow SDProp to complete and revalidate the affected objects to confirm that the permission does not reappear.
Synchronization Account Holds DCSync Rights
Synchronization Account Holds DCSync Rights
Synchronization Account Holds DCSync Rights
A recognized synchronization account holds directory replication rights (DCSync) on a domain naming context. Password Hash Synchronization requires these rights, and an Express installation of Microsoft Entra Connect grants them by default. They also let the account read the password hash of every account in the domain, so the account is functionally Tier 0 whether or not the feature is in use. Active Directory alone cannot confirm whether Password Hash Synchronization is enabled.
Replicating Directory Changes All is the exact right DCSync abuses to pull every account's password hash straight from a domain controller, tools like Mimikatz and Impacket's secretsdump automate the process end to end. A sync account holding this right when Password Hash Synchronization isn't even enabled is pure unused attack surface: compromise the account once, and an attacker walks away with the entire domain's credential material in a single request. When Password Hash Synchronization is enabled the right has to stay, so attackers go after the holder instead: the connector account's password is stored on the Microsoft Entra Connect server, and local administrator access to that server is enough to recover it.
Recommendation
Confirm whether Password Hash Synchronization is in use. If it is, keep the rights and protect the connector account and the Microsoft Entra Connect server as Tier 0 assets. If it is not, remove the rights.
Prerequisites
- Domain Admin or equivalent delegated rights to review and modify the affected Active Directory object.
- Confirm the active connector account and whether Password Hash Synchronization is enabled for the affected domain.
- Change control approval obtained before modifying production identity or synchronization settings.
- Service owner or identity platform owner confirmation of the affected dependency.
Remediation Objective
- Ensure replication rights exist only for active synchronization accounts that require them and only at the intended domain scope.
- Where Password Hash Synchronization requires the rights, manage the connector account and the Microsoft Entra Connect server as Tier 0 assets.
- Correct the configuration identified by Synchronization Account Holds DCSync Rights.
- Reduce the associated hybrid identity attack path while preserving required business functionality.
- Document the final configuration and validation results.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Synchronization Account Holds DCSync Rights
# Review replication-related ACEs on the domain root
dsacls '<Domain DN>' | Select-String 'Replicating Directory Changes'
# Confirm the account SID and effective scope
Get-ADUser '<Account>' -Properties SID,EnabledBulk remediation:
Export the affected objects from Insight Recon, validate each dependency and approved scope, then apply the same change through a reviewed PowerShell script. Use `-WhatIf` where supported and retain the transcript with the change record.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open the management consoleIn Active Directory Users and Computers, enable Advanced Features.
- Locate the affected objectOpen the domain root object, select Security > Advanced, and review replication extended rights granted to the synchronization account.
- Review the current configurationRemove them only after confirming they are not required for Password Hash Synchronization.
Validation
- Confirm the account has only the replication rights required for the intended domain.
- Run synchronization validation and re-run Insight Recon.
- Confirm the affected configuration now matches the approved standard.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Replication rights are required when the account is the active AD DS Connector account for Password Hash Synchronization. Keep them, protect the account and the Microsoft Entra Connect server as Tier 0 assets, and record the risk acceptance.
- The exception must document the feature, account, domain scope, and owner.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Domain-root ACL before and after remediation.
- Confirmation of Password Hash Synchronization status.
- Successful synchronization results.
Additional Guidance
Directory replication rights are highly sensitive because they allow an account to retrieve password-related data from domain controllers through normal replication interfaces. Password Hash Synchronization may legitimately require these rights, but they should never be granted more broadly than the intended domain scope or retained by inactive connector accounts.
When Password Hash Synchronization is in use the rights are required, so protection belongs on the holder. Microsoft states that the Microsoft Entra Connect server must be treated as a Tier 0 component; manage the connector account with the same controls as other Tier 0 accounts. When the feature is not in use, remove the rights. Monitor for replication requests from systems other than domain controllers and the Microsoft Entra Connect server, and review any new assignment of Replicating Directory Changes permissions as a privileged access event.
Synchronization Account Is Delegatable
Synchronization Account Is Delegatable
Synchronization Account Is Delegatable
A recognized synchronization account can participate in Kerberos delegation because it is not protected from delegation or has unconstrained, constrained, or resource-based constrained delegation configured.
A delegatable sync account extends the same Kerberos ticket-forwarding risk described for AZUREADSSOACC$ to an account that, in many environments, holds even broader AD rights than the SSO account. An attacker who compromises a system this account is configured to delegate to, or one configured to delegate to it, can request a ticket as any user through S4U2self and S4U2proxy without ever touching the sync account's own credential directly.
Recommendation
Remove unnecessary delegation configuration and mark the synchronization account as sensitive and cannot be delegated where supported.
Prerequisites
- Domain Admin or equivalent delegated rights to review and modify the affected Active Directory object.
- Confirm the synchronization product and service design do not require delegation for the affected account.
- Change control approval obtained before modifying production identity or synchronization settings.
- Service owner or identity platform owner confirmation of the affected dependency.
Remediation Objective
- Prevent synchronization credentials from being forwarded or impersonated through Kerberos delegation.
- Correct the configuration identified by Synchronization Account Is Delegatable.
- Reduce the associated hybrid identity attack path while preserving required business functionality.
- Document the final configuration and validation results.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Synchronization Account Is Delegatable
# Review delegation settings
Get-ADUser '<Account>' -Properties AccountNotDelegated,TrustedForDelegation,TrustedToAuthForDelegation,msDS-AllowedToDelegateTo,msDS-AllowedToActOnBehalfOfOtherIdentity
# Apply delegation protection
Set-ADAccountControl '<Account>' -AccountNotDelegated $trueBulk remediation:
Export the affected objects from Insight Recon, validate each dependency and approved scope, then apply the same change through a reviewed PowerShell script. Use `-WhatIf` where supported and retain the transcript with the change record.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open the management consoleIn Active Directory Users and Computers, open the account > Account and enable Account is sensitive and cannot be delegated.
- Locate the affected objectRemove unsupported delegation entries after confirming service requirements.
Validation
- Confirm delegation attributes are clear or approved, ACCOUNT_NOT_DELEGATED is set where supported, and synchronization continues normally.
- Confirm the affected configuration now matches the approved standard.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document a delegation requirement only when it is explicitly required by the supported connector design and tightly scoped.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Delegation settings before and after remediation.
- Service-owner confirmation.
- Successful synchronization validation.
Additional Guidance
Synchronization accounts often hold broad directory access and should not be exposed through Kerberos delegation. Unconstrained, constrained, or resource-based constrained delegation can allow another system or principal to impersonate the account and inherit its synchronization permissions.
Organizations should mark eligible connector identities as sensitive and cannot be delegated, remove unsupported delegation entries, and monitor delegation-related attribute changes. Exceptions should be limited to documented, vendor-supported designs and treated as privileged access risks.
Synchronization Account Has Excessive AD Permissions
Synchronization Account Has Excessive AD Permissions
Synchronization Account Has Excessive AD Permissions
A recognized synchronization account has privileged group membership or broad Active Directory rights that can affect objects beyond its expected synchronization scope. This check evaluates group membership and effective permissions visible in Active Directory, including Full Control, GenericWrite, WriteDACL, WriteOwner, password reset, group membership modification, and object creation or deletion rights. A right inherited from a container is reported once, at the container where it is granted, such as the domain root.
Entra Connect's installer has historically requested broader rights than many enabled features actually need, and an attacker who compromises the sync account inherits whatever excess was left in place. Depending on what's granted, that can mean resetting passwords, modifying group membership, or altering ACLs on objects the sync engine was never meant to reach, all without needing Domain Admin credentials directly.
Recommendation
Remove privileged group memberships, and replace Express installation permissions with ADSyncConfig grants for the synchronization features in use.
Prerequisites
- Domain Admin or equivalent delegated rights to review and modify the affected Active Directory object.
- Confirm the active AD DS Connector account and document the synchronization and writeback features currently enabled.
- Change control approval obtained before modifying production identity or synchronization settings.
- Service owner or identity platform owner confirmation of the affected dependency.
Remediation Objective
- Limit the synchronization account to the minimum permissions required for its approved function.
- Replace Express installation grants at the domain root with ADSyncConfig grants for the features in use.
- Correct the configuration identified by Synchronization Account Has Excessive AD Permissions.
- Reduce the associated hybrid identity attack path while preserving required business functionality.
- Document the final configuration and validation results.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Synchronization Account Has Excessive AD Permissions
# Review group membership
Get-ADUser '<Account>' -Properties memberOf | Select-Object -ExpandProperty memberOf
# Review permissions on a target scope
dsacls '<Target DN>'
# Remove an unnecessary privileged membership
Remove-ADGroupMember -Identity '<Privileged Group>' -Members '<Account>' -Confirm:$false
# Replace the Express installation grants (run on the Microsoft Entra Connect server)
Import-Module 'C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1'
Show-ADSyncADObjectPermissions -ADobjectDN '<Domain DN>'
# Removes every grant to the account at the domain root, replication rights included
dsacls '<Domain DN>' /R '<Domain>\<Account>'
# Re-grant per feature: basic read always, each of the others only if that feature is enabled
Set-ADSyncBasicReadPermissions -ADConnectorAccountDN '<Account DN>'
Set-ADSyncMsDsConsistencyGuidPermissions -ADConnectorAccountDN '<Account DN>'
Set-ADSyncPasswordHashSyncPermissions -ADConnectorAccountDN '<Account DN>'
Set-ADSyncPasswordWritebackPermissions -ADConnectorAccountDN '<Account DN>'
Set-ADSyncExchangeHybridPermissions -ADConnectorAccountDN '<Account DN>'Bulk remediation:
Export the affected objects from Insight Recon, validate each dependency and approved scope, then apply the same change through a reviewed PowerShell script. Use `-WhatIf` where supported and retain the transcript with the change record.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open the management consoleReview the account’s group memberships in Active Directory Users and Computers.
- Locate the affected objectOn each affected domain, OU, or object, open Security > Advanced and remove rights that are not required by the documented synchronization design.
- Review the current configurationTest changes in stages.
Validation
- Run an approved synchronization cycle and confirm that imports, exports, password synchronization, and any enabled writeback functions continue successfully.
- Re-run Insight Recon to verify that excess rights are removed.
- Confirm the affected configuration now matches the approved standard.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Retain a permission only when it is explicitly required by an enabled feature and scoped to the intended objects.
- Document the feature, scope, owner, and supporting Microsoft guidance.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Before and after group membership.
- ACL exports.
- Permission-to-feature mapping.
- Successful synchronization validation.
Additional Guidance
Synchronization accounts should be granted only the permissions required for the specific synchronization and writeback features in use. Broad rights such as Full Control, WriteDACL, WriteOwner, password reset, or privileged group membership can turn compromise of a connector identity into direct control of large portions of Active Directory.
An Express installation of Microsoft Entra Connect grants its MSOL_ connector account Read/Write all properties on User, iNetOrgPerson, Group, and Contact objects, and Reset Password, at the domain root, so every object below the root that inherits permissions receives them. Microsoft lists these permissions as used for import, Exchange hybrid, and preparation for password writeback, so most deployments need only part of the set. The ADSyncConfig PowerShell module installed with Microsoft Entra Connect grants the permissions for each enabled feature separately; use it to replace the Express grants with the subset the deployment needs.
Organizations should document the permission baseline for each connector account and review it after upgrades, topology changes, and feature enablement. Permission reductions should be tested in stages because overly aggressive changes can interrupt synchronization, password writeback, group writeback, or Exchange hybrid functionality.
| Object | Type | Details |
|---|---|---|
| Administrators | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Print Operators | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Backup Operators | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Replicator | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Domain Controllers | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Schema Admins | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Enterprise Admins | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Domain Admins | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Server Operators | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Account Operators | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Read-only Domain Controllers | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Key Admins | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Enterprise Key Admins | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
Synchronization Account Can Reset Privileged Passwords
Synchronization Account Can Reset Privileged Passwords
Synchronization Account Can Reset Privileged Passwords
A recognized synchronization account can reset passwords or modify password-related attributes on Tier 0, AdminSDHolder-protected, or other privileged accounts. This may result from password writeback permissions being scoped too broadly or intentionally extended to protected accounts.
Whether or not password writeback is actually enabled, if the sync account holds the raw Reset Password right on a Domain Admin or other Tier 0 account, an attacker who compromises it can reset that privileged account's password directly, no phishing or credential theft against the target required. This is a favorite shadow-admin pattern: the account looks like ordinary infrastructure, appears in no privileged group listing, and yet functionally owns whatever it can reset the password on.
Recommendation
Remove password writeback permissions from privileged accounts and Tier 0 scopes. Limit the connector account to approved nonprivileged user OUs.
Prerequisites
- Domain Admin or equivalent delegated rights to review and modify the affected Active Directory object.
- Confirm the active connector account, password writeback design, and intended target OUs.
- Change control approval obtained before modifying production identity or synchronization settings.
- Service owner or identity platform owner confirmation of the affected dependency.
Remediation Objective
- Prevent synchronization identities from resetting passwords for privileged AD accounts.
- Correct the configuration identified by Synchronization Account Can Reset Privileged Passwords.
- Reduce the associated hybrid identity attack path while preserving required business functionality.
- Document the final configuration and validation results.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Synchronization Account Can Reset Privileged Passwords
# Review reported permissions
dsacls '<Affected OU or object DN>'
# Review protected accounts
Get-ADObject -LDAPFilter '(adminCount=1)' -Properties DistinguishedNameBulk remediation:
Export the affected objects from Insight Recon, validate each dependency and approved scope, then apply the same change through a reviewed PowerShell script. Use `-WhatIf` where supported and retain the transcript with the change record.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open the management consoleIn Active Directory Users and Computers, enable Advanced Features.
- Locate the affected objectReview the affected OU or account under Security > Advanced and remove the synchronization account’s password reset or password-property rights from privileged scope.
Validation
- Confirm the account no longer has password reset rights over protected identities and that password writeback still functions for approved users.
- Confirm the affected configuration now matches the approved standard.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Avoid exceptions for Tier 0 accounts.
- If a supported business requirement exists, require explicit risk acceptance and compensating controls.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- ACLs before and after remediation.
- Affected account list.
- Password writeback test for an approved nonprivileged account.
Additional Guidance
Password reset rights over privileged accounts create a direct path from compromise of the synchronization identity to domain takeover. Password writeback should be limited to approved nonprivileged user scopes and should not include Domain Admins, emergency access accounts, service administrators, or other Tier 0 identities.
Organizations should separate privileged accounts into excluded or tightly controlled OUs and regularly validate the effective password reset scope of connector accounts. Any attempt to extend writeback permissions into privileged areas should require security review and explicit risk acceptance.
Synchronization Account Can Modify Privileged Groups
Synchronization Account Can Modify Privileged Groups
Synchronization Account Can Modify Privileged Groups
A recognized synchronization account can change membership or exercise administrative control over a Tier 0 or otherwise privileged group. Relevant rights include WriteProperty on member, GenericWrite, GenericAll, WriteDACL, WriteOwner, and group creation or deletion within a privileged scope.
An attacker who compromises the sync account and finds it holds WriteProperty or GenericWrite on Domain Admins can add themselves to the group directly, no group writeback feature or cloud-side action required. Because the sync account isn't itself a group member, this path doesn't surface in a standard privileged-group membership review and is only visible to an ACL-level check like this one.
Recommendation
Remove group-management and object-control rights from privileged groups and their parent containers. Scope any required group writeback permissions to dedicated nonprivileged OUs.
Prerequisites
- Domain Admin or equivalent delegated rights to review and modify the affected Active Directory object.
- Confirm the active connector account and intended group writeback scope.
- Change control approval obtained before modifying production identity or synchronization settings.
- Service owner or identity platform owner confirmation of the affected dependency.
Remediation Objective
- Prevent synchronization identities from modifying Tier 0 group membership or control.
- Correct the configuration identified by Synchronization Account Can Modify Privileged Groups.
- Reduce the associated hybrid identity attack path while preserving required business functionality.
- Document the final configuration and validation results.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Synchronization Account Can Modify Privileged Groups
# Review the affected group ACL
dsacls '<Privileged group DN>'
# Review group membership after remediation
Get-ADGroupMember '<Privileged Group>'Bulk remediation:
Export the affected objects from Insight Recon, validate each dependency and approved scope, then apply the same change through a reviewed PowerShell script. Use `-WhatIf` where supported and retain the transcript with the change record.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open the management consoleOpen the reported group or parent OU in Active Directory Users and Computers > Security > Advanced.
- Locate the affected objectRemove the synchronization account’s membership-write or administrative ACE and narrow writeback permissions to the approved scope.
Validation
- Confirm the synchronization account cannot modify the privileged group and approved synchronization functions continue normally.
- Confirm the affected configuration now matches the approved standard.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- No routine synchronization or group writeback requirement should include Tier 0 groups.
- Require explicit risk acceptance for any exception.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- ACL before and after remediation.
- Affected group list.
- Successful test in an approved nonprivileged writeback scope.
Additional Guidance
A synchronization account that can modify privileged group membership can elevate an attacker-controlled identity without needing Domain Admin membership. Group writeback and other automated group-management permissions should be isolated from Tier 0 groups and privileged administrative containers.
Organizations should review both direct rights on privileged groups and inherited rights from parent OUs. Monitor membership changes to Tier 0 groups and alert when the initiating identity is a synchronization or provisioning account.
| Object | Type | Details |
|---|---|---|
| Administrators | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Print Operators | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Backup Operators | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Replicator | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Domain Controllers | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Schema Admins | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Enterprise Admins | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Domain Admins | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Server Operators | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Account Operators | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Read-only Domain Controllers | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Key Admins | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
| Enterprise Key Admins | Group | synchronization account MSOL_demo01 holds write access to the group member attribute (granted directly) |
Synchronization Principal Can Control Tier 0 Objects
Synchronization Principal Can Control Tier 0 Objects
Synchronization Principal Can Control Tier 0 Objects
A recognized synchronization principal, or a principal that can control it, has a direct or indirect Active Directory permission path to a Tier 0 object. Paths may include password reset, group modification, ownership, DACL modification, delegation, object creation, or control of another intermediary principal.
This is the finding that catches what the individually scoped checks miss in combination: a chain of unremarkable-looking permissions, sync account to nested group to GPO to the Domain Controllers OU, can add up to full Tier 0 control even when no single hop looks alarming on its own. Attack-path tools like BloodHound are built specifically to find and exploit exactly this kind of multi-hop chain, which is why an aggregate check like this one matters as much as the individual permission findings it's built from.
Recommendation
Break the shortest and highest-impact control paths by removing excessive rights, nested privilege, unsafe ownership, and lower-tier control of synchronization identities.
Prerequisites
- Domain Admin or equivalent delegated rights to review and modify the affected Active Directory object.
- Validate the attack-path calculation and identify the business owner for each permission edge before making changes.
- Change control approval obtained before modifying production identity or synchronization settings.
Remediation Objective
- Ensure synchronization principals and their administrators cannot reach Tier 0 through direct or transitive control.
- Correct the configuration identified by Synchronization Principal Can Control Tier 0 Objects.
- Reduce the associated hybrid identity attack path while preserving required business functionality.
- Document the final configuration and validation results.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Synchronization Principal Can Control Tier 0 Objects
# Review each reported path edge using the relevant object ACL and group membership cmdlets.
Get-ADPrincipalGroupMembership '<Principal>'
dsacls '<Target DN>'Bulk remediation:
Export the affected objects from Insight Recon, validate each dependency and approved scope, then apply the same change through a reviewed PowerShell script. Use `-WhatIf` where supported and retain the transcript with the change record.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open the management consoleFollow the reported path from the synchronization principal to the Tier 0 target.
- Locate the affected objectAt each object, review group membership and Security > Advanced, then remove the least disruptive permission edge that breaks the path.
Validation
- Recalculate the attack path and confirm no synchronization principal or controlling non-Tier 0 principal can reach the reported Tier 0 object.
- Confirm the affected configuration now matches the approved standard.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document only unavoidable paths with named owners, least-privilege justification, monitoring, and formal Tier 0 risk acceptance.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Attack path before and after remediation.
- ACL and membership changes.
- Owner approvals.
Additional Guidance
Hybrid identity risk often results from a chain of individually overlooked permissions rather than a single obvious administrative grant. A synchronization account, or a lower-tier principal that controls it, should not have a direct or transitive path to domain controllers, privileged groups, AD CS authorities, or other Tier 0 assets.
Organizations should use attack-path reviews to validate the complete administrative boundary around synchronization identities. Break the shortest and highest-impact paths first, then monitor for new ACL, ownership, delegation, and nested group changes that could recreate the route.
Stale "AzureAD SSO" Account Password
Stale "AzureAD SSO" Account Password
Stale "AzureAD SSO" Account Password
A stale password for the AzureAD SSO account (AZUREADSSOACC) poses a significant security risk, as this account is critical for converting Kerberos tickets into SAML tokens for Azure AD single sign-on. If the password is not rotated regularly, attackers could extract it and use it to impersonate users, potentially compromising the entire Azure AD environment.
Stale passwords signify poor security posture and embolden attackers, particularly relating to ransomware attacks.
Recommendation
Rotate the AzureADSSOACC password using the supported Azure AD Connect process and validate Seamless SSO functionality after rotation.
Prerequisites
- Azure AD Connect administrator rights.
- Azure AD Global Administrator or Hybrid Identity Administrator rights.
- Confirm Azure AD Connect is healthy and synchronization is working before proceeding.
- Change control approval obtained.
- User communication plan prepared for potential brief SSO disruption during rotation.
- Rollback plan documented.
Remediation Objective
- Rotate the AZUREADSSOACC computer account password using the Azure AD Connect PowerShell module.
- Verify that Seamless SSO is functioning correctly after the rotation.
- Confirm the default 30-day automatic rotation schedule is operational.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
Operational caution: Seamless SSO changes can affect authentication behavior. Perform the change during an approved maintenance window and validate sign-in afterward.
# Rotate the Seamless SSO Kerberos decryption key for the approved tenant.
# Run from an administrative workstation with the required Azure AD Connect permissions.
Import-Module AzureADSSO
New-AzureADSSOAuthenticationContext
Update-AzureADSSOForest -OnPremCredentials (Get-Credential)Remediation Path 2: GUI
Not applicable. A GUI-only remediation path is not the preferred method for this finding because rotating the AzureADSSO account password is normally performed with the Microsoft Entra Connect PowerShell module from the Entra Connect server. The GUI can support post-change synchronization review, but it does not provide a complete GUI-only remediation path.
Validation
- Confirm the AZUREADSSOACC account's password was updated by checking its PasswordLastSet attribute in Active Directory.
- Verify Seamless SSO is functioning by testing authentication from a domain-joined machine to an Azure AD application.
- Confirm Azure AD Connect synchronization completed successfully after the rotation.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the account dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Before-and-after PasswordLastSet attribute for AZUREADSSOACC.
- Azure AD Connect sync cycle confirmation screenshot.
- Change ticket and approval record.
- Seamless SSO functionality test results.
- Follow-up scan results showing finding resolved.
Additional Guidance
The AZUREADSSOACC account holds the Kerberos decryption key used to convert domain Kerberos tickets into Azure AD SAML tokens for Seamless SSO. If this account's password is not regularly rotated, a compromise of the domain could allow an attacker to forge Seamless SSO tokens and gain unauthorized access to Azure AD resources. By default, Azure AD Connect rotates this password automatically every 30 days, and organizations should verify this automatic rotation is functioning correctly.
Any significant domain security incident, particularly one involving domain controller compromise, should trigger an immediate out-of-cycle rotation of the AZUREADSSOACC password as part of the incident response process.
| Object | Type |
|---|---|
| AZUREADSSOACC | Computer |
Policy and Configuration Management
8 findings
DES/RC4 Support Enabled
DES/RC4 Support Enabled
DES/RC4 Support Enabled
Outdated and insecure encryption algorithms, such as DES (Data Encryption Standard) and RC4, are still supported within the domain. These algorithms are vulnerable to cryptographic attacks, allowing attackers to exploit weaknesses in Kerberos authentication or intercept and decrypt sensitive data. Modern cryptographic standards should be used to prevent such vulnerabilities.
Attackers leverage weak encryption algorithms like DES or RC4 to intercept and decrypt sensitive data, such as authentication traffic. By cracking or manipulating these outdated encryption methods, they could gain unauthorized access to the network, escalate privileges, and maintain persistence within the organization.
Recommendation
Disable DES and RC4 encryption support where possible, update dependent services, and validate Kerberos uses stronger encryption.
Prerequisites
- Inventory affected accounts, service principals, and legacy clients that may rely on DES or RC4.
- Confirm AES keys are available for service accounts before disabling weak encryption.
- Coordinate testing with application and service owners in a pilot OU or controlled scope.
- Back up relevant GPOs and obtain change approval before production enforcement.
Remediation Objective
- Disable DES and RC4 Kerberos encryption types for user and service accounts.
- Enforce AES-128 and AES-256 as the only permitted Kerberos encryption algorithms.
- Reduce exposure to Kerberoasting and offline hash cracking techniques that target RC4-encrypted tickets.
- Align domain encryption configuration with current Microsoft security guidance.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Set Kerberos encryption type to AES only for a single account.
# Replace <SamAccountName> with the target account name.
Set-ADUser -Identity "<SamAccountName>" -KerberosEncryptionType AES128,AES256
# For computer accounts:
# Set-ADComputer -Identity "<ComputerName>" -KerberosEncryptionType AES128,AES256# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed and approved list of accounts to update.
# Required CSV columns: SamAccountName, AccountType (User or Computer)
$Accounts = Import-Csv -Path ".\ApprovedAccounts.csv"
# Set AES-only Kerberos encryption for each listed account.
foreach ($Account in $Accounts) {
if ($Account.AccountType -eq "User") {
Set-ADUser -Identity $Account.SamAccountName `
-KerberosEncryptionType AES128,AES256 -WhatIf
} elseif ($Account.AccountType -eq "Computer") {
Set-ADComputer -Identity $Account.SamAccountName `
-KerberosEncryptionType AES128,AES256 -WhatIf
}
}
# Remove -WhatIf after reviewing output and confirming no service impact.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Group Policy Management ConsoleLaunch
gpmc.mscfrom an administrative workstation. - Edit the relevant GPORight-click the GPO linked to the Domain Controllers OU or the domain and select Edit.
- Navigate to Kerberos encryption settingsGo to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.
- Configure permitted encryption typesOpen 'Network security: Configure encryption types allowed for Kerberos' and enable only AES128_HMAC_SHA1 and AES256_HMAC_SHA1. Uncheck DES_CBC_CRC, DES_CBC_MD5, and RC4_HMAC_MD5.
- Apply the GPOClose the editor and Use the organization-approved policy refresh process on domain controllers after testing.
- ValidateConfirm that Kerberos tickets are issued using AES encryption only.
Validation
- Verify account-level encryption types: Get-ADUser -Identity <SamAccountName> -Properties KerberosEncryptionType
- Confirm Kerberos tickets are using AES: use klist.exe on a test client.
- Monitor domain controller authentication event logs (Event ID 4769) for any failures following the change.
- Confirm all dependent services are authenticating successfully.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the authentication dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Before/after export of account KerberosEncryptionType values.
- GPO backup before and after modification.
- Change ticket and approval record.
- klist output confirming AES ticket issuance.
- Event ID 4769 review confirming no authentication failures.
- Follow-up scan results confirming finding resolution.
Additional Guidance
DES and RC4 Kerberos encryption types are cryptographically weak and are primary targets for Kerberoasting attacks, where an attacker requests service tickets encrypted with the weaker algorithm and cracks them offline. Enforcing AES-128 and AES-256 eliminates this attack vector for accounts that are properly configured. Organizations should treat this change as part of a broader Kerberos hardening initiative alongside disabling NTLM and enforcing Kerberos pre-authentication.
Hardened UNC Paths Not Enforced
Hardened UNC Paths Not Enforced
Hardened UNC Paths Not Enforced
Hardened UNC paths are not enforced for SYSVOL and NETLOGON through Group Policy. Without these protections, clients may be more exposed to tampering or interception when retrieving Group Policy and logon script content from domain controllers. Hardened UNC path settings should require mutual authentication and integrity for these critical shares.
SYSVOL and NETLOGON are trusted sources for Group Policy and logon content across the domain. Without hardened UNC path requirements, attackers who can interfere with network traffic (fore example through ARP, LLMNR, or DNS spoofing) may have more opportunity to tamper with or impersonate these paths. This can affect many domain-joined systems because they routinely retrieve policy from these shares.
Recommendation
Enforce Hardened UNC Paths for SYSVOL and NETLOGON via domain-wide Group Policy.
Prerequisites
- Rights to edit and link a domain-level GPO.
- Confirmation that domain controllers support the required SMB features (all supported Windows Server versions do).
- Obtain change control approval.
Remediation Objective
- Configure Hardened UNC Paths for \\*\SYSVOL and \\*\NETLOGON requiring mutual authentication and integrity.
- Link the GPO so it applies to all domain-joined computers.
- Confirm clients receive and apply the setting.
Remediation Path 1: Command-Line
Hardened UNC Paths are a Group Policy setting; configure them centrally rather than per machine.
# Hardened UNC Paths are normally set via Group Policy (see the GUI steps). They write these registry
# values under HKLM, which a GPO should deploy to every machine rather than setting them host-by-host.
$Key = "HKLM:\Software\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths"
New-Item -Path $Key -Force | Out-Null
New-ItemProperty -Path $Key -Name "\\*\SYSVOL" -Value "RequireMutualAuthentication=1, RequireIntegrity=1" -PropertyType String -Force
New-ItemProperty -Path $Key -Name "\\*\NETLOGON" -Value "RequireMutualAuthentication=1, RequireIntegrity=1" -PropertyType String -Force# Confirm the policy is present on a domain-joined machine.
Get-Item "HKLM:\Software\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths" |
Select-Object -ExpandProperty PropertyRemediation Path 2: GUI
Use this path to configure the setting in Group Policy so it applies domain-wide.
- Open the Group Policy Management ConsoleLaunch gpmc.msc and edit (or create) a GPO linked at the domain.
- Navigate to Hardened UNC PathsGo to Computer Configuration > Policies > Administrative Templates > Network > Network Provider > Hardened UNC Paths.
- Enable the policySet the policy to Enabled.
- Add the SYSVOL and NETLOGON pathsAdd \\*\SYSVOL and \\*\NETLOGON, each with the value RequireMutualAuthentication=1, RequireIntegrity=1.
- Link and confirmEnsure the GPO is linked so all domain-joined computers receive it, then run gpupdate on a client to confirm.
Validation
- Confirm the Hardened UNC Paths policy is applied (gpresult or the registry key on a client).
- Verify clients still access SYSVOL and NETLOGON normally.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- If a legacy client cannot meet the requirement, scope the exception narrowly and document it.
- Record owner and target date for any deferral.
- Track formal risk acceptance.
Evidence
- GPO settings report and a client-side registry/gpresult capture.
- Confirmation that policy and script delivery still function.
- Follow-up scan results confirming resolution.
Additional Guidance
Hardened UNC paths defend the delivery channel; also enable SMB signing domain-wide and reduce name-resolution spoofing by disabling LLMNR and NBT-NS, which are the usual ways an attacker gets into a position to man-in-the-middle SYSVOL traffic.
Insufficient Domain Controller Logging
Insufficient Domain Controller Logging
Insufficient Domain Controller Logging
Insufficient Domain Controller logging weakens the ability to detect, investigate, and respond to attacks on Active Directory. Without comprehensive logging, critical events, such as unauthorized access attempts or changes to privileged accounts, may go unnoticed, leaving the domain vulnerable to compromise. Furthermore, domain controller logs are essential for post-incident analysis, helping to assess the scope of a compromise and informing remediation efforts.
As organizations increasingly rely on Endpoint Detection and Response (EDR) tools, attacks on Active Directory are expected to rise. It is crucial to ensure that proper logging from domain controllers is sent to a SIEM and alerting is in place.
Recommendation
Enable comprehensive domain controller audit policies, confirm security event generation, and forward logs to centralized monitoring.
Prerequisites
- Domain Admin or Group Policy rights to configure audit policies.
- SIEM log collection capacity assessed.
- Change control approval obtained.
Remediation Objective
- Configure comprehensive advanced audit policies on domain controllers covering logon events, account management, privilege use, and directory service changes.
- Forward domain controller security event logs to a SIEM.
- Configure alerting for high-priority events such as Domain Admin logons and privileged account changes.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Enable key domain controller audit subcategories on the affected domain controller.
# Run from an elevated command prompt or PowerShell session.
auditpol /set /subcategory:"Directory Service Access" /success:enable /failure:enable
auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable
auditpol /set /subcategory:"Account Management" /success:enable /failure:enable
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
# Optional: confirm the updated audit policy.
auditpol /get /category:*Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Group Policy Management ConsoleLaunch
gpmc.mscfrom an administrative workstation. - Edit the Default Domain Controllers PolicyRight-click the Default Domain Controllers Policy and select Edit.
- Navigate to Advanced Audit Policy ConfigurationGo to Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies.
- Configure key audit categoriesEnable success and failure auditing for: Account Logon, Account Management, DS Access, Logon/Logoff, Privilege Use, and Policy Change.
- Apply and forwardClose the editor. Configure Windows Event Forwarding or SIEM agents to collect Security event logs from domain controllers.
Validation
- Run auditpol /get /category:* on domain controllers to confirm audit policies are correctly configured.
- Verify Event IDs 4624, 4625, 4768, 4769, 4776, 4720, 4732 are being generated and forwarded to the SIEM.
- Confirm alerting is configured for high-priority events.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the dependency and business justification.
- Assign a server owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- auditpol /get output before and after confirming policy changes.
- GPO backup showing audit policy settings.
- SIEM log collection confirmation.
- Sample high-priority event log entries.
Additional Guidance
Comprehensive domain controller logging is the foundation of Active Directory incident detection and response. Without adequate logging, attackers can operate within the domain for extended periods without triggering any detectable evidence. Organizations should treat domain controller audit policy configuration as a baseline security requirement, not an optional enhancement.
Beyond enabling the policies, organizations must ensure that logs are forwarded to a SIEM and that alerting is configured for the events most indicative of attack activity. Log retention should be configured to retain domain controller security logs for at least 90 days to support incident investigations and forensic analysis.
Password Policy Set for Less than 8 Characters
Password Policy Set for Less than 8 Characters
Password Policy Set for Less than 8 Characters
Shorter passwords are more susceptible to brute-force or password spraying attacks. Enforcing a minimum password length of at least 8 characters, which is a Microsoft default, is a fundamental security measure to protect against unauthorized access.
With the computational power of password cracking systems and advanced software, short passwords are considered weak and at high risk. In reality, passwords that are less than 12 characters are quite easily cracked with even hobbyist-level cracking machines.
Recommendation
Increase the minimum password length in domain or fine-grained password policy and validate that the effective policy meets an approved standard.
Prerequisites
- Domain Admin rights to modify the Default Domain Policy or Fine-Grained Password Policies.
- User communication plan prepared to notify users of the upcoming password policy change.
- Change control approval obtained.
- Confirm whether Fine-Grained Password Policies (PSOs) are in use that may override the domain policy.
Remediation Objective
- Set the minimum password length in the Default Domain Policy or applicable Fine-Grained Password Policy to at least 8 characters, with 12 or more recommended.
- Set a minimum of 15 characters for privileged accounts where applicable.
- Communicate the policy change to users in advance.
- Enforce the policy update at the next password change cycle.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Update the minimum password length in the Default Domain Policy.
# Replace <DomainName> with your domain FQDN (e.g., contoso.com).
Import-Module ActiveDirectory
Import-Module GroupPolicy
# Set the minimum password length to 14 characters in the Default Domain Policy.
# Adjust the value as appropriate for your organization's policy requirements.
Set-GPRegistryValue -Name "Default Domain Policy" -Key "HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" `
-ValueName "MinimumPasswordLength" -Type DWord -Value 14
# Alternatively, use the Set-ADDefaultDomainPasswordPolicy cmdlet.
Set-ADDefaultDomainPasswordPolicy -Identity "<DomainName>" -MinPasswordLength 14Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Group Policy Management ConsoleLaunch
gpmc.mscfrom an administrative workstation. - Edit the Default Domain PolicyExpand the domain, right-click Default Domain Policy, and select Edit.
- Navigate to the Password PolicyGo to Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy.
- Update the Minimum Password LengthDouble-click Minimum password length and set the value to at least 8 characters (14 or more is recommended for enhanced security).
- Apply changesClose the Group Policy Management Editor. The policy will apply at the next Group Policy refresh or on the next user logon.
Validation
- Confirm the updated minimum password length using Get-ADDefaultDomainPasswordPolicy.
- Verify the policy is applied using gpresult /r on a domain-joined workstation.
- Confirm Fine-Grained Password Policies are also updated if applicable.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the account dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Before-and-after Get-ADDefaultDomainPasswordPolicy output.
- GPO backup showing updated password policy settings.
- Change ticket and approval record.
- Follow-up scan results showing finding resolved.
Additional Guidance
Password length requirements should reflect current organizational risk and identity controls. Align the domain policy with modern password standards, consider privileged account requirements separately, and monitor for weaker fine-grained policies that bypass the intended baseline.
| Object | Type |
|---|---|
| Default Domain Policy | Group policy |
Print spooler service is enabled on a Domain Controller
Print spooler service is enabled on a Domain Controller
Print spooler service is enabled on a Domain Controller
If the Print Spooler service is enabled on a Domain Controller, attackers can exploit vulnerabilities in the service to extract domain controller credentials. This can lead to the compromise of the entire domain, allowing attackers to conduct privilege escalation or launch attacks like DCSync to retrieve all user password hashes.
Ransomware groups leveraged vulnerabilities such as “PrintNightmare” which were highly effective in achieving domain takeover. Combining this configuration with accounts with delegations makes for a straightforward privilege escalation pathway that is seldom detected.
Recommendation
Disable the Print Spooler service on domain controllers, prevent automatic restart, and validate that printing dependencies do not rely on domain controllers.
Prerequisites
- Domain Admin or local administrator rights on the domain controller.
- Confirm printer pruning functionality is not required on the domain controller.
- Change control approval obtained.
Remediation Objective
- Disable and stop the Print Spooler service on all domain controllers.
- Set the service startup type to Disabled to prevent automatic restart.
- Verify domain controller functionality is unaffected after the change.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Disable the Print Spooler service on a domain controller.
# Run with administrative rights on the target domain controller.
# Stop the service immediately.
Stop-Service -Name Spooler -Force
# Set the startup type to Disabled to prevent it from restarting.
Set-Service -Name Spooler -StartupType Disabled
Write-Output "Print Spooler service disabled on $env:COMPUTERNAME"# Disable the Print Spooler service on multiple domain controllers remotely.
# CSV must contain a column named ServerName.
$Servers = Import-Csv -Path ".\ApprovedDomainControllers.csv"
foreach ($Server in $Servers) {
Invoke-Command -ComputerName $Server.ServerName -ScriptBlock {
Stop-Service -Name Spooler -Force -ErrorAction SilentlyContinue
Set-Service -Name Spooler -StartupType Disabled
Write-Output "Print Spooler disabled on $env:COMPUTERNAME"
}
}Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open the Services ConsoleLog in to the domain controller and open
services.mscor navigate to Server Manager > Tools > Services. - Locate the Print Spooler serviceScroll to Print Spooler in the services list.
- Stop and disable the serviceRight-click Print Spooler and select Properties. Set the Startup type to Disabled, then click Stop to stop the service immediately. Click OK.
Validation
- Confirm the Print Spooler service is stopped and set to Disabled: Get-Service Spooler.
- Verify domain controller authentication services are functioning normally.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the dependency and business justification.
- Assign a server owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Service status export confirming Print Spooler is disabled.
- Change ticket and approval record.
- Domain controller service health confirmation.
- Follow-up scan results showing finding resolved.
Additional Guidance
The Print Spooler service has been the source of multiple critical vulnerabilities, most notably PrintNightmare (CVE-2021-1675 and CVE-2021-34527), which allowed unauthenticated remote code execution on domain controllers. Microsoft recommends disabling the Print Spooler service on domain controllers as a baseline hardening measure because printing functionality is not a required domain controller role.
Organizations should also audit the Print Spooler service status on other servers in the environment as part of a broader hardening initiative. Printer services should be consolidated onto dedicated print servers rather than domain controllers, separating the printing function from the directory service function.
Unrestricted certificate template with any purpose in ADCS (ESC2)
Unrestricted certificate template with any purpose in ADCS (ESC2)
Unrestricted certificate template with any purpose in ADCS (ESC2)
Permissive certificate templates in Active Directory Certificate Services (ADCS) can allow low-privileged users to request certificates with elevated permissions, potentially enabling them to impersonate high-privileged accounts, like domain administrators. This often occurs when templates are configured with the "Any Purpose" Extended Key Usage (EKU) or without any EKU at all.
Attackers could exploit this vulnerability in several ways. For instance, if they can specify a Subject Alternative Name (SAN), they may perform attacks similar to ESC1, where they generate certificates impersonating other accounts. This also allows them to request certificates on behalf of other users, as seen in ESC3. In rarer cases, the "Any Purpose" value has been leveraged to target applications like SAML and ADFS, enabling misuse in code signing and server authentication scenarios.
Recommendation
Remove Any Purpose or SubCA EKUs from vulnerable templates, restrict enrollment, and validate templates cannot issue broadly usable certificates.
Prerequisites
- Locate all services and clients consuming certificates issued from affected template.
- Coordinate with application and service owners before modifying the template.
- Back up the certificate template configuration before changes.
- Obtain change control approval.
Remediation Objective
- Remove the Any Purpose EKU or SubCA EKU from the affected certificate template.
- Restrict the template to specific, required EKUs that reflect its intended use.
- Prevent the template from being used to issue certificates that can be used for any purpose, including code signing and smart card logon.
- Eliminate the ESC2 attack vector where any authenticated user can request an unrestricted certificate.
Remediation Path 1: Command-Line
Not applicable. A command-line remediation is not the preferred remediation method for this finding because certificate template EKU and issuance changes should be made through the Certificate Templates Console or a documented PKI change process to reduce certificate issuance and compatibility risk.
Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Certificate Templates ConsoleRun
certtmpl.msc. - Duplicate the template (if built-in)Right-click the affected template and select Duplicate Template.
- Open template propertiesRight-click the duplicated template and select Properties.
- Update EKU settingsClick the Extensions tab, select Application Policies, and click Edit. Remove the Any Purpose entry and add only the specific EKU(s) required for the template's intended use.
- Restrict enrollment permissionsOn the Security tab, confirm that enrollment rights are limited to the required principals.
- Publish the updated templateIn
certsrv.msc, add the new template to the CA and remove the old unrestricted template. - Trigger re-enrollmentConfigure autoenrollment via Group Policy to re-enroll consuming services.
Validation
- Confirm the updated template no longer includes Any Purpose EKU: certutil -template <TemplateName>
- Verify newly issued certificates have only the specific required EKUs.
- Confirm consuming services have re-enrolled successfully.
- Run a follow-up scan to confirm the ESC2 finding is resolved.
Exceptions
- Document the certificate dependency and business justification.
- Assign a PKI owner and target remediation date.
- Restrict enrollment or access until remediation is complete.
Evidence
- Template configuration export before changes.
- Change ticket and approval record.
- certutil output confirming updated EKU settings.
- Re-enrollment confirmation from consuming services.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Configure certificate templates to limit permissions and specify purpose-specific EKUs. Regular audits of template permissions and close monitoring of certificate requests are essential for maintaining secure certificate issuance. As multiple conditions must align for this vulnerability to be exploited, disrupting any one of these conditions effectively prevents this escalation attack. • Low-Privileged Enrollment Rights: The Certificate Authority (CA) permits enrollment requests from low-privileged groups, such as "Authenticated Users" or "Domain Users," which broadens the potential for misuse. • Lack of Approval Mechanisms: When certificates are issued without requiring manager approval or authorized signatures, the process lacks oversight, allowing unauthorized users to request high-privilege certificates without detection. • Unrestricted EKU Settings: If a certificate template is configured with "Any Purpose" as the Extended Key Usage (EKU) or lacks an EKU designation, it allows users to request certificates without restriction, which can be exploited to gain escalated access.
| Object | Type | Details |
|---|---|---|
| Template-ESC1 | Certificate template | |
Domain Users | Account | Enroll |
Weak Certificate Encryption or Signing
Weak Certificate Encryption or Signing
Weak Certificate Encryption or Signing
Certificates should not use outdated or insufficiently strong encryption algorithms, such as RSA keys under 2048 bits. Certificates with weak encryption can be exploited by attackers, compromising the security of the systems that rely on them. RSA keys below 1024 bits are especially vulnerable.
Attackers exploit this by breaking weaker cryptographic protections to impersonate trusted services or decrypt sensitive data. Using tools like RsaCtfTool or John the Ripper, they can factorize short RSA keys, allowing them to forge signatures or eavesdrop on encrypted communications. This enables them to compromise secure channels, intercept confidential information, and gain unauthorized access to critical systems.
Recommendation
Update certificate templates to require strong algorithms and key sizes, then reissue certificates where weak cryptography remains in use.
Prerequisites
- Inventory all services, devices, and users consuming certificates issued from affected templates.
- Coordinate with application and service owners before modifying templates.
- Back up certificate template configurations before making changes.
- Obtain change control approval.
Remediation Objective
- Update ADCS certificate templates to require strong cryptographic algorithms (SHA-256 or higher, RSA 2048-bit minimum or equivalent).
- Revoke or phase out certificates issued under weak cryptographic settings.
- Ensure all new certificate issuances use templates configured with current algorithm standards.
- Reduce exposure to certificate forgery and signature weakness attacks.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Run from an elevated command prompt on the issuing Certification Authority.
# Configure the CA to use SHA256 for certificate signing where supported.
certutil -setreg CA\CSP\CNGHashAlgorithm SHA256
# Restart Certificate Services to apply the change.
net stop certsvc
net start certsvcRemediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Certificate Templates ConsoleRun
certtmpl.mscfrom an administrative workstation. - Locate the affected templateFind the template identified in the report.
- Duplicate if neededIf the template is a built-in template, right-click and select Duplicate Template before making changes.
- Open template propertiesRight-click the template (or its duplicate) and select Properties.
- Update cryptographic settingsClick the Cryptography tab. Set the Minimum key size to 2048 or higher. Set the Request hash to SHA256 or stronger. Select an appropriate CSP or Key Storage Provider that supports strong algorithms.
- Publish the updated templateIn the Certification Authority console (
certsrv.msc), right-click Certificate Templates, select New > Certificate Template to Issue, and publish the updated template. - Trigger re-enrollmentConfigure autoenrollment via Group Policy or manually re-enroll consuming services.
Validation
- Confirm updated template settings using certutil -template <TemplateName>.
- Verify newly issued certificates use SHA-256 and meet minimum key size requirements.
- Confirm consuming services have re-enrolled and are using updated certificates.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the certificate dependency and business justification.
- Assign a PKI owner and target remediation date.
- Restrict enrollment or access until remediation is complete.
Evidence
- Certificate template configuration export before changes.
- Change ticket and approval record.
- certutil output confirming updated template cryptographic settings.
- Sample certificate inspection confirming new issuances use strong algorithms.
- Re-enrollment confirmation from consuming services.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Weak certificate encryption increases the risk of certificate forgery or interception, which can undermine authentication and data integrity. Regularly audit certificates for strong encryption standards and replace any with weak algorithms, particularly in critical systems. Update certificates to use modern cryptographic standards, such as 2048-bit RSA or higher. Administrators should monitor upcoming security guidelines for future-proofing encryption practices.
| Object | Type | Details |
|---|---|---|
| CN=snaplabs-DC-CA, DC=snaplabs, DC=local | Trusted root certificate | RSA 2048-bit key valid past 2031 (expires 2031-08-14) (Certification Authorities store) |
Weak PowerShell Logging
Weak PowerShell Logging
Weak PowerShell Logging
Enabling PowerShell logging offers comprehensive insights into executed commands, the parameters used, and their execution context. This level of detail is critical for detecting malicious actions like security control bypasses, privilege escalations, and data exfiltration. Additionally, PowerShell logs are often essential for post-incident analysis, aiding in understanding the scope of a compromise and guiding appropriate remediation efforts.
PowerShell has become highly popular among hackers due to its extensive functionality, leading to the creation of numerous tools that leverage it. It is commonly used by malicious attackers as part of their toolkit.
Recommendation
Enable PowerShell Script Block Logging and related audit settings, forward events to monitoring, and validate command execution visibility.
Prerequisites
- Domain Admin or Group Policy rights to create and modify GPOs.
- SIEM or log collection capacity assessed to accommodate increased log volume.
- Change control approval obtained.
Remediation Objective
- Enable PowerShell Script Block Logging to capture the content of all executed scripts and commands.
- Enable PowerShell Module Logging to record pipeline execution details.
- Enable Protected Event Logging to protect script block log content from tampering.
- Forward PowerShell event logs to a SIEM and configure alerting for suspicious patterns.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Enable PowerShell logging via registry on a single system.
# The GPO method is preferred for domain-wide enforcement.
$PSLoggingPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell"
# Enable Script Block Logging.
$SBLPath = "$PSLoggingPath\ScriptBlockLogging"
New-Item -Path $SBLPath -Force | Out-Null
Set-ItemProperty -Path $SBLPath -Name "EnableScriptBlockLogging" -Value 1 -Type DWord
# Enable Module Logging.
$MLPath = "$PSLoggingPath\ModuleLogging"
New-Item -Path $MLPath -Force | Out-Null
Set-ItemProperty -Path $MLPath -Name "EnableModuleLogging" -Value 1 -Type DWord
Write-Output "PowerShell logging enabled on $env:COMPUTERNAME"Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Group Policy Management ConsoleLaunch
gpmc.mscfrom an administrative workstation. - Create or edit a GPORight-click the domain or target OU and create or edit a security baseline GPO.
- Navigate to PowerShell logging settingsGo to Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell.
- Enable Script Block LoggingDouble-click Turn on PowerShell Script Block Logging and set it to Enabled.
- Enable Module LoggingDouble-click Turn on Module Logging, set it to Enabled, and specify the approved module logging scope.
- Link and validate the GPOLink the GPO to the approved scope and confirm the settings appear in Group Policy Results.
Validation
- Confirm PowerShell Script Block Logging is enabled: check HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging\EnableScriptBlockLogging.
- Verify Event ID 4104 events are being generated in the Microsoft-Windows-PowerShell/Operational log.
- Confirm events are being forwarded to the SIEM.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the authentication dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- GPO backup showing PowerShell logging settings.
- Sample Event ID 4104 output confirming script block logging is active.
- SIEM ingestion confirmation.
- Change ticket and approval record.
- Follow-up scan results showing finding resolved.
Additional Guidance
PowerShell logging is a foundational detective control for identifying malicious activity, as PowerShell is one of the most commonly used tools in post-exploitation attack chains. Script Block Logging captures the decoded content of all executed PowerShell commands, making it far more useful than basic command history and enabling detection of obfuscated or encoded scripts. Organizations should ensure PowerShell event logs are forwarded to a centralized SIEM with alerting configured for known malicious patterns, such as encoded command execution, AMSI bypass attempts, and offensive tooling signatures.
| Object | Type |
|---|---|
| Default Domain Policy | Group policy |
Privileged Access Management
15 findings
Custom "Pre-Windows 2000 Compatible Access" Group Membership
Custom "Pre-Windows 2000 Compatible Access" Group Membership
Custom "Pre-Windows 2000 Compatible Access" Group Membership
The "Pre-Windows 2000 Compatible Access" group grants access to certain legacy calls, which can expose vulnerabilities if improperly configured. Custom membership in this group, particularly the addition of accounts beyond the default settings, can increase the risk of unauthorized access to sensitive domain resources by exploiting legacy protocols.
Attackers leverage the "Pre-Windows 2000 Compatible Access" group to gain broad read access to directory information, including user and group details. They use this access to gather intelligence on the organization’s structure and potentially escalate privileges or craft targeted attacks.
Recently tools have been released focusing on exploiting Pre-Windows 2000 computer accounts, making it a common technique for gaining an initial foothold in a network. These accounts can sometimes obtain an authenticated domain account, as their default password is defaulted to the hostname in all lowercase letters. If these accounts were created but never used, they are likely still configured with this default setting.
Recommendation
Review custom Pre-Windows 2000 Compatible Access membership, remove unjustified entries, and document any approved legacy dependency.
Prerequisites
- Review the current membership of the Pre-Windows 2000 Compatible Access group to locate non-default or c.
- Consult with application and service owners to determine whether each custom member has a legitimate ope.
- Back up current group membership before making changes.
- Plan a rollback if application authentication failures occur after membership changes.
Remediation Objective
- Remove custom or non-default members from the Pre-Windows 2000 Compatible Access group that do not have a documented business justification.
- Prevent unauthorized or undocumented accounts from retaining broad AD read access via this legacy group.
- Ensure group membership reflects only operationally justified entries with documented approval.
- Reduce the risk of AD enumeration and unauthorized information gathering by limiting this group's effective membership.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Remove a custom member from the Pre-Windows 2000 Compatible Access group.
# Replace <MemberName> with the account or group to remove.
Remove-ADGroupMember -Identity "Pre-Windows 2000 Compatible Access" `
-Members "<MemberName>" -Confirm:$false -WhatIf
# Remove -WhatIf after reviewing output and confirming no application dependency.# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed and approved list of custom members to remove.
# Required CSV columns: MemberName
$Members = Import-Csv -Path ".\ApprovedRemovals.csv"
# Remove each custom member from the Pre-Windows 2000 Compatible Access group.
foreach ($Member in $Members) {
Remove-ADGroupMember -Identity "Pre-Windows 2000 Compatible Access" `
-Members $Member.MemberName -Confirm:$false -WhatIf
}
# Remove -WhatIf after reviewing output.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Locate the groupNavigate to Builtin and find the 'Pre-Windows 2000 Compatible Access' group.
- Open group propertiesRight-click the group and select Properties, then click the Members tab.
- Locate custom membersReview the membership list for any non-default or custom accounts or groups that are not operationally justified.
- Remove unjustified custom membersSelect the member and click Remove for each custom entry that lacks documented justification.
- Save and testClick OK. Monitor for application authentication failures following the change.
Validation
- Confirm updated group membership: Get-ADGroupMember -Identity 'Pre-Windows 2000 Compatible Access'
- Monitor application and service logs for authentication failures.
- Verify no new custom members have been added to the group after remediation.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the account dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Export of Pre-Windows 2000 Compatible Access group membership before changes.
- Change ticket and approval record.
- PowerShell output confirming updated membership after changes.
- Application and service monitoring confirming no authentication failures.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Custom membership in the Pre-Windows 2000 Compatible Access group is frequently introduced without documented justification and can persist for years after the original need has passed. Each custom member retains the broad AD read access that this group provides, including the ability to enumerate user, computer, and group attributes that would otherwise require authenticated access. Organizations should treat this group as a zero-membership target and require formal justification for any entry.
| Object | Type |
|---|---|
| Pre-Windows 2000 Compatible Access | Group |
Dangerous Control Over Privileged Objects
Dangerous Control Over Privileged Objects
Dangerous Control Over Privileged Objects
One or more non-standard principals have dangerous control over privileged Active Directory objects. Permissions such as full control, ownership, password reset, or permission modification can provide administrative influence without visible privileged group membership. These hidden control paths, often referred to as "shadow admins" should be treated as privileged access and removed unless explicitly required.
Shadow admins are a favorite attacker foothold. A help-desk account with WriteDacl on Domain Admins, or the right to reset a Domain Admin's password, is functionally a Domain Admin yet appears in no privileged group listing. One ACL edit and they own the domain.
Recommendation
Remove admin-equivalent ACL access held by non-default principals over Tier 0 objects.
Prerequisites
- Domain Admin rights to modify the ACLs of Tier 0 objects.
- Knowledge of any legitimate delegation so it is not removed by mistake.
- Obtain change control approval.
Remediation Objective
- Remove the dangerous ACE for each non-default principal from the affected Tier 0 object.
- Restore the object to its default, AdminSDHolder-protected permissions.
- Investigate how the access was granted and whether it was abused.
Remediation Path 1: Command-Line
Use this path to review and remove the dangerous access.
REM Review who holds rights on a privileged object (example: Domain Admins).
dsacls "CN=Domain Admins,CN=Users,DC=contoso,DC=com"
REM Remove all ACEs for the non-default principal from that object.
dsacls "CN=Domain Admins,CN=Users,DC=contoso,DC=com" /R "CONTOSO\suspectAccount"# Inspect the security descriptor of a privileged object before editing it.
Import-Module ActiveDirectory
(Get-Acl "AD:CN=Domain Admins,CN=Users,DC=contoso,DC=com").Access |
Where-Object { $_.AccessControlType -eq 'Allow' } |
Select-Object IdentityReference, ActiveDirectoryRights, ObjectTypeRemediation Path 2: GUI
Use this path to remove the access through the console.
- Open Active Directory Users and ComputersLaunch ADUC and enable Advanced Features from the View menu.
- Locate the privileged objectNavigate to the Tier 0 object identified in the report.
- Open the Security tabRight-click the object, select Properties, and open the Security tab.
- Remove the non-default principalSelect the flagged principal and remove it, or remove only the dangerous permissions it holds.
- Confirm protectionVerify the object's permissions match the AdminSDHolder template and save.
Validation
- Confirm the non-default principal no longer holds control over the object.
- Verify legitimate administration still functions.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- If the access is legitimate delegation, document the business reason and scope it as tightly as possible.
- Investigate any unexplained access as a potential compromise.
- Track formal risk acceptance.
Evidence
- Security-descriptor export of each object before and after.
- Investigation notes on how the access was granted.
- Follow-up scan results confirming resolution.
Additional Guidance
AdminSDHolder and the SDProp process re-stamp the ACLs of protected objects roughly every hour. After cleaning up an object, confirm it is covered by AdminSDHolder, and audit the AdminSDHolder object itself, since access granted there propagates to every privileged object.
Disabled Privileged Accounts
Disabled Privileged Accounts
Disabled Privileged Accounts
Disabled privileged accounts present a security risk when they retain group memberships that grant elevated access. Attackers who gain control of such accounts can re-enable them and immediately inherit their previous privileges, bypassing normal escalation processes. Since disabled accounts are often overlooked in security monitoring, they are prime targets for exploitation, allowing adversaries to operate with high-level access while evading detection.
Attackers can exploit disabled privileged accounts by reactivating them or extracting their credentials for unauthorized access. Using tools like Mimikatz or BloodHound, they identify disabled accounts with historical administrative privileges and attempt to reset their passwords, modify account attributes, or leverage cached credentials for authentication. If security monitoring overlooks disabled accounts, attackers can use them for stealthy privilege escalation, lateral movement, and persistent access within the organization.
Recommendation
Remove privileged group memberships from disabled accounts and validate disabled objects no longer retain standing administrative access.
Prerequisites
- Domain Administrator credentials required.
- Confirm each disabled account is genuinely inactive and not held for retention or compliance purposes.
- Verify that no services, scheduled tasks, or applications reference the disabled accounts.
- Coordinate with HR or the account owner if the account was associated with a departed employee.
- Obtain change control approval before deleting accounts (less required for group membership removal only).
Remediation Objective
- Remove privileged group memberships from disabled accounts.
- Delete disabled privileged accounts that are confirmed as no longer required.
- Eliminate the risk of disabled privileged accounts being re-enabled and used for unauthorized access.
- Ensure the privileged group membership inventory reflects only active, operationally justified accounts.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Remove all privileged group memberships from a disabled account.
# Replace <SamAccountName> with the disabled account name.
$Account = Get-ADUser -Identity "<SamAccountName>" -Properties MemberOf
foreach ($Group in $Account.MemberOf) {
Remove-ADGroupMember -Identity $Group -Members "<SamAccountName>" -Confirm:$false -WhatIf
}
# Optionally delete the account after removing memberships:
# Remove-ADUser -Identity "<SamAccountName>" -Confirm:$false -WhatIf
# Remove -WhatIf after reviewing output and confirming with relevant stakeholders.# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed and approved list of disabled privileged accounts.
# Required CSV columns: SamAccountName
$Accounts = Import-Csv -Path ".\ApprovedAccounts.csv"
foreach ($Account in $Accounts) {
$ADAccount = Get-ADUser -Identity $Account.SamAccountName -Properties MemberOf
foreach ($Group in $ADAccount.MemberOf) {
Remove-ADGroupMember -Identity $Group `
-Members $Account.SamAccountName -Confirm:$false -WhatIf
}
}
# Remove -WhatIf after reviewing output.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.msc. - Locate the disabled privileged accountNavigate to the OU containing the account.
- Review group membershipRight-click the account, select Properties, and click the Member Of tab. Remove all privileged group memberships.
- Delete the account if appropriateAfter removing memberships, right-click the account and select Delete if it is confirmed as no longer needed.
- Repeat for approved affected accountsComplete the same GUI process for each account listed in the approved remediation plan.
Validation
- Confirm privileged group memberships have been removed: Get-ADUser -Identity <SamAccountName> -Properties MemberOf
- Confirm accounts are deleted or remain disabled with no group memberships.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the privileged access dependency and justification.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Export of disabled privileged account group memberships before changes.
- Change ticket and approval record.
- PowerShell output confirming group memberships removed.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Threat actors actively seek out disabled privileged accounts as a means of gaining privileged access within Active Directory. Once re-enabled, these accounts provide an immediate pathway to critical systems, often without triggering the same level of scrutiny as active privileged users. Organizations should maintain visibility over disabled accounts, especially those with administrative access, as they can become a silent entry point for attackers. Identify suspicious activity before it leads to a full domain compromise by performing regular audits and setting up automated alerts for privilege changes.
gMSA Not In Use
gMSA Not In Use
gMSA Not In Use
No group managed service accounts were identified in the domain. This may indicate that services continue to rely on traditional service accounts with static passwords, which are often difficult to rotate and protect. Group managed service accounts rotate their own passwords automatically and cannot be used for interactive logon. gMSAs should be considered for eligible services to reduce password management and credential theft risk.
Static service-account passwords are a perennial weak point: they are often weak, shared, embedded in scripts, and never rotated, which makes them ideal Kerberoasting targets and lateral-movement credentials.
Recommendation
Adopt group managed service accounts for service accounts so passwords rotate automatically.
Prerequisites
- Domain Admin (or delegated) rights to create the KDS root key and service accounts.
- An inventory of services running under static-password accounts.
- Obtain change control approval.
Remediation Objective
- Create the KDS root key for the forest (one-time).
- Create gMSAs and authorize only the hosts that run each service.
- Migrate services from static-password accounts to gMSAs.
Remediation Path 1: Command-Line
Use this path to enable gMSAs and create the first service accounts.
Import-Module ActiveDirectory
# One-time per forest. In production the key needs ~10 hours to replicate before use.
Add-KdsRootKey -EffectiveImmediately
# Create a gMSA and authorize the hosts that may retrieve its password (computer accounts end with $).
New-ADServiceAccount -Name "svc-example" -DNSHostName "svc-example.contoso.com" -PrincipalsAllowedToRetrieveManagedPassword "Host1$","Host2$"# Create gMSAs from an approved list (columns: Name, DnsHostName, AllowedHosts as semicolon-separated $ accounts).
Import-Module ActiveDirectory
$Items = Import-Csv -Path ".\ApprovedObjects.csv"
foreach ($Item in $Items) {
$hosts = $Item.AllowedHosts -split ';'
New-ADServiceAccount -Name $Item.Name -DNSHostName $Item.DnsHostName -PrincipalsAllowedToRetrieveManagedPassword $hosts -WhatIf
}Remediation Path 2: GUI
Use this path to create gMSAs through the management console.
- Create the KDS root keyOn a domain controller, run Add-KdsRootKey once for the forest (PowerShell; there is no console step for this).
- Open Active Directory Administrative CenterLaunch dsac.exe and browse to the Managed Service Accounts container.
- Create a new gMSACreate a group managed service account and set the hosts allowed to retrieve its password.
- Install on the service hostsOn each host, run Install-ADServiceAccount for the new gMSA.
- Migrate the serviceReconfigure the service to run as the gMSA (DOMAIN\svc-example$ with no password).
Validation
- Confirm gMSAs exist and services run under them.
- Confirm the static-password accounts they replaced are disabled or removed.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- If a service cannot use a gMSA (no AES, non-Windows host), document it and use a long random password with periodic rotation.
- Record owner and target date for the migration.
- Track formal risk acceptance.
Evidence
- Inventory of gMSAs created and services migrated.
- Confirmation that static-password accounts were retired.
- Follow-up scan results confirming resolution.
Additional Guidance
Group managed service accounts are the standard remediation for static service-account passwords. Prioritize migrating privileged or internet-reachable service accounts first, and authorize each gMSA to only the specific hosts that run the service.
High Number of Privileged Users
High Number of Privileged Users
High Number of Privileged Users
Each privileged user account increases the attack surface. Organizations are urged to follow best practices such as least privilege, particularly involving administrative accounts.
Organizations that have fewer administrative accounts are more resistant to privilege escalation attacks such as token impersonation and pass-the-hash. When there are a multitude of privileged accounts, it’s easier to blend in with normal day-to-day operations, which allows for stealthier attacks and persistence.
Recommendation
Recertify privileged group membership, remove unnecessary administrative access, and establish recurring privileged access reviews.
Prerequisites
- Domain Admin rights to modify group memberships.
- Access recertification process initiated with business and IT stakeholders.
- Inventory of privileged group memberships and business justifications prepared.
- Change control approval obtained for each removal action.
- Rollback plan documented for any access removals that cause operational issues.
Remediation Objective
- Conduct a formal access recertification to locate accounts with unnecessary privileged group memberships.
- Remove accounts from privileged groups where membership is not justified by current role requirements.
- Implement a tiered administration model to isolate privileged access from daily user activity.
- Enforce just-in-time (JIT) access or PAM-managed shared accounts where possible.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Remove a user from a privileged group.
# Replace <SamAccountName> with the target account.
# Replace <GroupName> with the privileged group name (e.g., Domain Admins).
Remove-ADGroupMember -Identity "<GroupName>" -Members "<SamAccountName>" -Confirm:$false# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed list of accounts to remove from privileged groups.
# CSV must contain columns: SamAccountName, GroupName
$Members = Import-Csv -Path ".\ApprovedRemovals.csv"
foreach ($Member in $Members) {
Remove-ADGroupMember -Identity $Member.GroupName -Members $Member.SamAccountName -Confirm:$false -WhatIf
Write-Output "Processed removal: $($Member.SamAccountName) from $($Member.GroupName)"
}
# Remove -WhatIf after reviewing.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Locate the privileged groupNavigate to the appropriate container (typically CN=Users or a dedicated admin OU) and open the privileged group's properties.
- Review the Members tabLocate accounts whose membership is not justified by a current business or operational requirement.
- Remove unjustified membersSelect the accounts to remove and click Remove.
- Document each removalRecord each removal in the change management system with the approving manager's acknowledgment.
Validation
- Confirm group membership has been updated: Get-ADGroupMember -Identity <GroupName>.
- Verify removed users retain the access necessary for their role through appropriate non-privileged accounts.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the privileged access dependency and justification.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Before-and-after privileged group membership export.
- Access recertification sign-off records.
- Change ticket and approval record for each removal.
- Follow-up scan results showing finding resolved.
Additional Guidance
Restrict the number of privileged users, granting only essential personnel elevated rights. Implementing a tiered administration model can further protect these accounts by isolating their use and reducing the impact of compromise. Perform regular audits to review privileged accounts and ensure their necessity in the environment. Many organizations choose to practice Just-In-Time (JIT) provisioning or leverage PAM (Privileged Access Management) toolsets to manage shared or limited administrative accounts.
LAPS Not In Use
LAPS Not In Use
LAPS Not In Use
The absence of LAPS (Local Administrator Password Solution) means that local administrator passwords across workstations and servers are not securely managed, leaving them vulnerable to password reuse and compromise. Without LAPS, attackers who gain access to one local admin password or password hash may use it to escalate privileges across multiple machines within the domain
Once a machine is compromised, a common first attack is to pull the local administrator hash, which is then sprayed across the network to identify other machines with a matching username and password.
Recommendation
Deploy and enforce Microsoft LAPS for managed systems, restrict password read permissions, and validate local administrator password rotation.
Prerequisites
- Domain Admin or equivalent rights to install LAPS and configure GPOs.
- Access to Group Policy Management Console (GPMC).
- Change control approval obtained prior to production rollout.
- Schema extension requires Enterprise Admin rights; coordinate with schema owner.
- Staged rollout plan prepared; start with a pilot OU before broad enforcement.
- Rollback plan documented in the event of access disruption.
Remediation Objective
- Extend the Active Directory schema to support the LAPS ms-Mcs-AdmPwd attribute.
- Deploy the LAPS agent to all managed workstations and servers.
- Configure Group Policy to enforce LAPS password settings, including complexity and rotation interval.
- Restrict read access to the ms-Mcs-AdmPwd attribute to authorized administrative accounts only.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the required modules.
Import-Module ActiveDirectory
# Grant LAPS password read permission on one approved OU.
Set-AdmPwdReadPasswordPermission `
-OrgUnit "<OUDistinguishedName>" `
-AllowedPrincipals "<AdminGroupName>"# Import the required modules.
Import-Module ActiveDirectory
# Import a reviewed and approved list of OUs that will receive LAPS permissions.
# Required CSV columns: OUDistinguishedName, AdminGroupName
$OUs = Import-Csv -Path ".\ApprovedLapsOUs.csv"
# Grant LAPS password read permission only to the approved administrative group for each approved OU.
foreach ($OU in $OUs) {
Set-AdmPwdReadPasswordPermission `
-OrgUnit $OU.OUDistinguishedName `
-AllowedPrincipals $OU.AdminGroupName `
-WhatIf
}
# Remove -WhatIf after the OU list, delegated group, change ticket, and pilot results are approved.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Group Policy Management ConsoleLaunch
gpmc.mscfrom an administrative workstation. - Create a new GPO for LAPSRight-click the target OU and select Create a GPO in this domain, and Link it here. Name it appropriately (for example, LAPS Policy).
- Configure the LAPS settingsNavigate to Computer Configuration > Administrative Templates > LAPS. Enable Password Settings and configure the password age, length, and complexity per your organization's policy.
- Enable the password expiration protection optionWithin the same LAPS policy node, enable the Do not allow password expiration time longer than required by policy setting.
- Link and enforce the GPOConfirm the GPO is linked to all OUs containing managed workstations and servers. Apply enforcement if necessary to prevent override.
Validation
- Confirm the LAPS GPO is applied to target computers using gpresult /r or Get-GPResultantSetOfPolicy.
- Verify the ms-Mcs-AdmPwd attribute is populated on computer objects in Active Directory Users and Computers.
- Confirm read access is restricted by testing retrieval with a non-privileged account (access should be denied).
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document any LAPS deployment exception and business justification.
- Assign an owner and target remediation date.
- Use compensating controls until LAPS is enforced.
Evidence
- Before-and-after export of LAPS GPO settings (GPO Backup).
- Screenshot or export of ms-Mcs-AdmPwd attribute permissions.
- Change ticket number and approval record.
- PowerShell transcript of permission configuration commands.
- Validation output confirming attribute population.
- Follow-up scan results showing finding resolved.
Additional Guidance
LAPS provides a straightforward, Microsoft-supported mechanism for eliminating shared local administrator passwords across the environment. Organizations should treat LAPS deployment as a baseline control rather than an optional enhancement, given the significant lateral movement risk associated with credential reuse. Governance should include automated alerting for systems where the LAPS attribute is absent or where the password has not rotated within the configured interval.
For environments using a Privileged Access Management (PAM) solution, LAPS can complement PAM by managing the built-in Administrator account while the PAM solution governs other privileged credentials. Periodic review of read access permissions on the ms-Mcs-AdmPwd attribute should be included in the organization's access review cycle.
Non-administrative users can add computer accounts
Non-administrative users can add computer accounts
Non-administrative users can add computer accounts
By default, non-administrative users can add up to 10 computer accounts to the domain. This capability allows basic users to introduce uncontrolled machines into the domain, which can be exploited by attackers to gain unauthorized access or launch additional attacks.
Organizations are often over reliant on EDR (endpoint detection and response) tools which attackers can bypass by adding a malicious computer to the domain. These attacks often are conducted by adding a virtual machine to the environment and performing Kerberos-based attacks. These attacks become even more effective if they can poison network traffic and direct it to the malicious device.
Recommendation
Set MachineAccountQuota to zero, move computer joins into an approved process, and validate that non-administrators can no longer create computer accounts.
Prerequisites
- Domain Admin rights to modify the ms-DS-MachineAccountQuota attribute and Group Policy.
- Confirm that existing computer joining processes use administrative accounts and will not be impacted.
- Change control approval obtained.
Remediation Objective
- Set the ms-DS-MachineAccountQuota attribute on the domain root to 0 to prevent non-administrative users from adding computers.
- Configure Group Policy to restrict the Add workstations to domain privilege (SeMachineAccountPrivilege) to authorized administrators only.
- Confirm the change does not impact legitimate computer provisioning processes.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Set the ms-DS-MachineAccountQuota attribute to 0 on the domain root.
# Replace <DomainDN> with your domain distinguished name (e.g., DC=contoso,DC=com).
Set-ADDomain -Identity "<DomainDN>" -Replace @{"ms-DS-MachineAccountQuota" = "0"}Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open ADSI EditLaunch
adsiedit.mscfrom an administrative workstation. - Connect to the domain naming contextRight-click ADSI Edit, select Connect to, and choose Default naming context.
- Locate the domain root objectExpand the domain naming context and right-click the domain root object (e.g., DC=contoso,DC=com). Select Properties.
- Modify the ms-DS-MachineAccountQuota attributeScroll to ms-DS-MachineAccountQuota in the attribute list. Double-click to edit and set the value to 0. Click OK.
- Configure GPO to restrict SeMachineAccountPrivilegeOpen
gpmc.msc, create or edit a GPO linked to the domain. Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment. Locate Add workstations to domain and configure it to include only Domain Admins or the appropriate administrative group.
Validation
- Confirm the ms-DS-MachineAccountQuota value is 0 using Get-ADDomain | Select AllowedDNSSuffixes or Get-ADObject.
- Attempt to join a computer to the domain with a non-administrative account to confirm the change is effective (access should be denied).
- Verify legitimate computer provisioning processes still function correctly.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the privileged access dependency and justification.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Before-and-after export of ms-DS-MachineAccountQuota attribute value.
- GPO backup and settings report for SeMachineAccountPrivilege.
- Change ticket and approval record.
- Validation test output confirming non-admin join is blocked.
Additional Guidance
Allowing non-administrative users to add computer accounts to the domain enables low-effort attack techniques that can bypass endpoint protections and be used as a foothold for further compromise. This capability should be restricted to dedicated administrative accounts as a baseline hardening measure.
Organizations should also monitor for anomalous computer account creation events (Event ID 4741) to detect any attempts to exploit this capability before it is fully restricted. Computer provisioning workflows should be reviewed to ensure they use dedicated administrative accounts with appropriately scoped permissions rather than broad domain admin rights.
Over permissioned "Pre-Windows 2000 Compatible Access" Group
Over permissioned "Pre-Windows 2000 Compatible Access" Group
Over permissioned "Pre-Windows 2000 Compatible Access" Group
The "Pre-Windows 2000 Compatible Access" group grants access to certain legacy protocols and services. If this group includes "Authenticated Users," it increases the risk of exploitation through vulnerabilities in outdated protocols, potentially allowing unauthorized access to sensitive resources within the domain.
The "Pre-Windows 2000 Compatible Access" group is typically leveraged to gain broad read access to directory information, including user and group details. With access, attackers can gather intelligence on the organization’s structure and potentially escalate privileges, or craft targeted attacks, such as spear phishing or password attacks.
Recently, tools have been released to exploit Pre-Windows 2000 computer accounts, making it a common technique for gaining an initial foothold in a network. These accounts can sometimes be used to obtain an authenticated domain account, as their default password is defaulted to the hostname in all lowercase letters. If these accounts were created but never used, they are likely still configured with this default setting.
Recommendation
Remove unnecessary members from Pre-Windows 2000 Compatible Access and validate that legacy application access is not dependent on broad directory visibility.
Prerequisites
- Review the current membership of the Pre-Windows 2000 Compatible Access group.
- Locate any applications, services, or systems that may rely on the permissions granted by this group.
- Coordinate with application owners before removing membership.
- Plan a rollback if application authentication failures occur after membership changes.
Remediation Objective
- Remove unnecessary members from the Pre-Windows 2000 Compatible Access built-in group.
- Eliminate overly broad read access to Active Directory attributes granted by membership in this group.
- Reduce the risk of unauthenticated or low-privileged enumeration of AD objects.
- Align group membership with the principle of least privilege.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Remove a specific member from the Pre-Windows 2000 Compatible Access group.
# Replace <MemberName> with the account or group to remove.
Remove-ADGroupMember -Identity "Pre-Windows 2000 Compatible Access" `
-Members "<MemberName>" -Confirm:$false -WhatIf
# Remove -WhatIf after reviewing the output and confirming no application dependency.# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed and approved list of members to remove.
# Required CSV columns: MemberName
$Members = Import-Csv -Path ".\ApprovedRemovals.csv"
# Remove each member from the Pre-Windows 2000 Compatible Access group.
foreach ($Member in $Members) {
Remove-ADGroupMember -Identity "Pre-Windows 2000 Compatible Access" `
-Members $Member.MemberName -Confirm:$false -WhatIf
}
# Remove -WhatIf after reviewing output.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Locate the groupNavigate to Builtin and find the 'Pre-Windows 2000 Compatible Access' group.
- Open group propertiesRight-click the group and select Properties.
- Review Members tabClick the Members tab and review all listed members.
- Remove unnecessary membersSelect members that are not required for operational purposes and click Remove.
- Save and testClick OK. Validate that no dependent applications experience authentication failures following the change.
Validation
- Confirm updated group membership: Get-ADGroupMember -Identity 'Pre-Windows 2000 Compatible Access'
- Monitor application and service authentication logs for failures following the change.
- Verify that no new members have been added to the group following remediation.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the account dependency and business justification.
- Assign an owner and target remediation date.
- Apply compensating controls until remediation is complete.
Evidence
- Export of Pre-Windows 2000 Compatible Access group membership before changes.
- Change ticket and approval record.
- PowerShell output confirming updated membership after changes.
- Application and service monitoring results confirming no authentication failures.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Review and restrict the membership of the "Pre-Windows 2000 Compatible Access" group, ensuring that unnecessary users, such as "Authenticated Users," are removed. While removing members can enhance security, be aware that it may impact legacy applications relying on this group. Conduct thorough testing before making changes to avoid disruptions to services.
| Object | Type |
|---|---|
| Pre-Windows 2000 Compatible Access | Group |
Privileged Users Allowed to Be Delegated
Privileged Users Allowed to Be Delegated
Privileged Users Allowed to Be Delegated
One or more privileged accounts are not protected from Kerberos delegation as they lack the "Account is sensitive and cannot be delegated" flag or not members of the Protected Users group. When these accounts authenticate to a service trusted for delegation, that service may be able to obtain and reuse their Kerberos tickets. For highly privileged accounts such as Domain Admins, compromise of a delegated service can lead to full domain compromise.
An attacker who controls, or can configure delegation on, a service that a privileged account authenticates to captures that account's forwarded ticket and replays it as the privileged user. Unconstrained delegation makes this trivial; resource-based and constrained delegation make it targeted.
Recommendation
Mark all privileged accounts as sensitive and cannot be delegated, or add them to Protected Users.
Prerequisites
- Rights to modify the privileged accounts.
- Confirm no privileged account legitimately requires delegation.
- Obtain change control approval.
Remediation Objective
- Set "Account is sensitive and cannot be delegated" on every privileged account.
- Where supported, add privileged accounts to the Protected Users group, which also blocks delegation.
- Verify the accounts are excluded from delegation.
Remediation Path 1: Command-Line
Use this path to mark accounts as sensitive across the privileged population.
Import-Module ActiveDirectory
Set-ADUser -Identity "<SamAccountName>" -AccountNotDelegated $true# Mark all members of a privileged group as sensitive (review membership first).
Import-Module ActiveDirectory
Get-ADGroupMember -Identity "Domain Admins" -Recursive |
Where-Object { $_.objectClass -eq 'user' } |
ForEach-Object { Set-ADUser -Identity $_.SID -AccountNotDelegated $true -WhatIf }Remediation Path 2: GUI
Use this path when changing a small number of accounts.
- Open Active Directory Users and ComputersLaunch ADUC from an administrative workstation.
- Locate the privileged accountNavigate to the account identified in the report.
- Open the Account tabRight-click the account, select Properties, and open the Account tab.
- Set the sensitive flagUnder Account options, check "Account is sensitive and cannot be delegated".
- Save the changeClick OK and repeat for each privileged account.
Validation
- Confirm AccountNotDelegated is true (or the account is in Protected Users).
- Verify the account still authenticates to required services.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- If an account genuinely requires delegation, scope the delegation tightly and document the dependency.
- Record owner and target date for any temporary delay.
- Track formal risk acceptance.
Evidence
- Export of AccountNotDelegated / Protected Users membership before and after.
- Confirmation that authentication still works.
- Follow-up scan results confirming resolution.
Additional Guidance
Add privileged accounts to the Protected Users group where compatible (it blocks delegation, NTLM, and weak Kerberos ciphers), and keep the sensitive flag set on every Tier 0 account as a baseline.
Protected Users Group Not Utilized
Protected Users Group Not Utilized
Protected Users Group Not Utilized
The Protected Users group is designed to provide enhanced security for privileged accounts by limiting the use of vulnerable authentication methods like NTLM and reducing exposure to credential theft attacks. If privileged accounts are not members of this group, they remain susceptible to common attacks such as credential caching, Kerberos delegation, and weaker encryption algorithms.
Organizations that properly tier their environments and enforce best practices, like using the Protected Users group, are generally more difficult and time-consuming to compromise. This forces attackers to rely on alternative methods, such as social engineering.
Recommendation
Enroll appropriate privileged accounts in the Protected Users group, validate authentication compatibility, and document accounts that require exception.
Prerequisites
- Domain Admin rights to modify group membership.
- Review of all candidate accounts to confirm they are human user accounts and not service accounts.
- Testing environment available to validate no service disruptions.
- Notification to affected privileged users.
- Change control approval obtained.
Remediation Objective
- Locate privileged user accounts that should be enrolled in the Protected Users group.
- Exclude service accounts, accounts running services, and any account used for non-interactive authentication.
- Add the reviewed and approved accounts to the Protected Users group.
- Monitor for authentication issues after enrollment and document any service impacts.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Add a privileged user account to the Protected Users group.
# Replace <SamAccountName> with the target account.
Add-ADGroupMember -Identity "Protected Users" -Members "<SamAccountName>"# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed list of privileged accounts to add to Protected Users.
# CSV must contain a column named SamAccountName.
# IMPORTANT: Only include human user accounts. Exclude service accounts.
$Accounts = Import-Csv -Path ".\ApprovedProtectedUsers.csv"
foreach ($Account in $Accounts) {
Add-ADGroupMember -Identity "Protected Users" -Members $Account.SamAccountName -WhatIf
Write-Output "Processed: $($Account.SamAccountName)"
}
# Remove -WhatIf after reviewing.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Locate the Protected Users groupNavigate to CN=Users in the domain and open the Protected Users group.
- Add membersClick the Members tab and click Add. Enter the names of the privileged accounts to enroll.
- Save and monitorClick OK. Monitor the affected accounts for authentication issues in the days following enrollment.
Validation
- Confirm Protected Users group membership: Get-ADGroupMember -Identity 'Protected Users'.
- Verify affected accounts can authenticate via Kerberos and that no service disruptions occurred.
- Confirm NTLM authentication is blocked for Protected Users members by testing with an NTLM-only authentication attempt.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the privileged access dependency and justification.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Before-and-after Protected Users group membership export.
- Authentication test results confirming no service disruptions.
- Change ticket and approval record.
- Follow-up scan results showing finding resolved.
Additional Guidance
The Protected Users group is one of the most effective credential protection controls available in Active Directory, automatically blocking NTLM authentication, Kerberos delegation, DES and RC4 encryption. These protections significantly raise the cost of credential theft for the covered accounts. Do not add service accounts without testing, as Protected Users restrictions will likely disrupt service authentication. Prioritize human or user-related accounts when implementing this group as the impact should be lessened.
Risky AdminSDHolder Permissions
Risky AdminSDHolder Permissions
Risky AdminSDHolder Permissions
The AdminSDHolder object has non-standard permissions that grant dangerous control to one or more principals. Because AdminSDHolder permissions are periodically applied to protected administrative accounts and groups, improper access can propagate across privileged objects. This condition can create both privilege escalation and persistence risk within the domain.
AdminSDHolder is a classic persistence mechanism. An attacker with write access adds an access control entry granting themselves full control; within about an hour SDProp copies that entry onto Domain Admins, Administrators, and every other protected object. Even after defenders remove the access from those groups, SDProp re-adds it on the next cycle, so the backdoor survives cleanup until the AdminSDHolder ACL itself is fixed.
Recommendation
Restrict the AdminSDHolder ACL to default privileged principals only.
Prerequisites
- Domain Admin rights.
- Identify the non-default access control entries from the report.
- Obtain change control approval.
Remediation Objective
- Remove non-default full-control, write, write-DACL, and write-owner entries from the AdminSDHolder object.
- Leave only SYSTEM, Administrators, Domain Admins, and Enterprise Admins.
- Inspect current privileged accounts and groups for the same entry that SDProp may already have propagated.
Remediation Path 1: Command-Line
Use this path when remediating multiple entries or when changes need to be executed, exported, and tracked.
# Review the AdminSDHolder ACL.
dsacls "CN=AdminSDHolder,CN=System,<DomainDN>"
# Remove a non-default principal's permissions.
dsacls "CN=AdminSDHolder,CN=System,<DomainDN>" /R "<DOMAIN\Principal>"# Remove approved principals (column: Principal) from AdminSDHolder.
$Items = Import-Csv -Path ".\ApprovedObjects.csv"
foreach ($Item in $Items) {
<Approved-Remediation-Command> "CN=AdminSDHolder,CN=System,<DomainDN>" /R $Item.Principal
}Remediation Path 2: GUI
Use this path to review and correct the AdminSDHolder ACL visually.
- Open ADSI EditRun adsiedit.msc and connect to the Default naming context.
- Locate AdminSDHolderBrowse to CN=System, then CN=AdminSDHolder.
- Open SecurityRight-click AdminSDHolder, select Properties, and open the Security tab.
- Remove non-default entriesRemove any principal other than SYSTEM, Administrators, Domain Admins, and Enterprise Admins that holds full control, write, write-DACL, or write-owner.
- Save the changeClick OK; SDProp will propagate the corrected descriptor on its next cycle.
Validation
- Re-review the AdminSDHolder ACL and confirm only default principals remain.
- Inspect protected accounts and groups for the unwanted entry and remove it where propagated.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Do not approve permanent exceptions for write access by non-default principals.
- Document any temporary delay with owner and target date.
- Track formal risk acceptance until remediation is complete.
Evidence
- AdminSDHolder ACL export before and after remediation.
- List of protected objects checked for propagated entries.
- Follow-up scan results confirming resolution.
Additional Guidance
Because SDProp propagation makes AdminSDHolder a single point of control for all privileged objects, treat its ACL as Tier 0 and monitor it for change. Auditing directory service changes on the AdminSDHolder object detects both the initial tampering and ongoing persistence attempts.
Risky DCSync Permissions
Risky DCSync Permissions
Risky DCSync Permissions
Non-standard users with DCSync permissions pose a significant security risk, as they can replicate credentials for any account within the domain, including domain administrators. Attackers who obtain these privileges can execute a DCSync attack, extracting NTLM password hashes and Kerberos keys without triggering typical authentication-based alerts. This access enables adversaries to conduct credential theft attacks such as Golden Ticket and Silver Ticket attacks, granting long-term control over Active Directory.
Accounts with DCSync permissions are highly sought after by attackers as they have the ability to impersonate a domain controller. Attackers use tools like Mimikatz or Impacket to perform a DCSync attack, tricking the domain controller into replicating password hashes. With these hashes, they can escalate privileges, create Golden Tickets, and maintain persistent control over the entire Active Directory environment. Once access is obtained, domain controller hashes can be remotely dumped, rendering many EDR defenses ineffective.
Recommendation
Remove unauthorized DCSync rights from the domain root and validate only approved replication principals can request directory replication data.
Prerequisites
- Domain Administrator or Enterprise Administrator credentials required.
- Locate all accounts or groups with Replicating Directory Changes and Replicating Directory Changes All rights on the domain object.
- Confirm which accounts legitimately require these rights (e.g., Azure AD Connect sync account, specific replication tools).
- Coordinate with the directory services team before removing any ACEs.
- Back up the domain object ACL before making any changes.
- Obtain change control approval.
Remediation Objective
- Remove unauthorized accounts or groups from the DCSync permission set (Replicating Directory Changes and Replicating Directory Changes All) on the Active Directory domain object.
- Ensure these rights are held only by domain controllers, the Azure AD Connect sync account (if applicable), and other explicitly authorized replication accounts.
- Eliminate the risk of credential harvesting via DCSync attacks by accounts that should not hold replication rights.
- Reduce the domain's exposure to full credential database extraction.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Remove approved unauthorized DCSync extended rights from the domain root object.
# Replace <DOMAIN\AccountOrGroup> with the account or group approved for removal.
$DomainDN = (Get-ADDomain).DistinguishedName
$Principal = "<DOMAIN\AccountOrGroup>"
$DCSyncRightGuids = @(
[Guid]"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",
[Guid]"1131f6ab-9c07-11d1-f79f-00c04fc2dcd2",
[Guid]"89e95b76-444d-4c62-991a-0facbeda640c"
)
$Acl = Get-Acl -Path ("AD:\" + $DomainDN)
$RulesToRemove = $Acl.Access | Where-Object {
$_.IdentityReference -eq $Principal -and $DCSyncRightGuids -contains $_.ObjectType
}
foreach ($Rule in $RulesToRemove) {
[void]$Acl.RemoveAccessRuleSpecific($Rule)
}
Set-Acl -Path ("AD:\" + $DomainDN) -AclObject $Acl# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed and approved list of principals to remove from DCSync rights.
# Required CSV column: Principal
$Principals = Import-Csv -Path ".\ApprovedDCSyncRemovals.csv"
$DomainDN = (Get-ADDomain).DistinguishedName
$DCSyncRightGuids = @(
[Guid]"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",
[Guid]"1131f6ab-9c07-11d1-f79f-00c04fc2dcd2",
[Guid]"89e95b76-444d-4c62-991a-0facbeda640c"
)
foreach ($Item in $Principals) {
$Acl = Get-Acl -Path ("AD:\" + $DomainDN)
$RulesToRemove = $Acl.Access | Where-Object {
$_.IdentityReference -eq $Item.Principal -and $DCSyncRightGuids -contains $_.ObjectType
}
foreach ($Rule in $RulesToRemove) {
[void]$Acl.RemoveAccessRuleSpecific($Rule)
}
# Preview the affected principal before applying the ACL update.
Write-Output "Prepared DCSync permission removal for $($Item.Principal)"
# Remove the comment on the next line only after approval.
# Set-Acl -Path ("AD:\" + $DomainDN) -AclObject $Acl
}Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open ADSI EditLaunch
adsiedit.mscconnected to the Default Naming Context. - Locate the domain objectRight-click the domain root object (DC=<domain>,DC=<tld>) and select Properties.
- Review SecurityClick the Security tab, then Advanced to see all ACEs.
- Locate unauthorized DCSync entriesLook for entries with 'Replicating Directory Changes' or 'Replicating Directory Changes All' extended rights. Confirm each entry against the list of authorized replication accounts.
- Remove unauthorized entriesSelect the unauthorized ACE and click Remove.
- Save and validateClick OK. Monitor replication health after changes.
Validation
- Confirm unauthorized DCSync ACEs have been removed from the domain object ACL.
- Verify AD replication is healthy after changes: repadmin /replsummary
- Confirm Azure AD Connect or other sync tools are still functioning if applicable.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Document the dependency and business justification.
- Assign a server owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Domain object ACL export before changes.
- Change ticket and approval record.
- Post-change ACL review confirming unauthorized DCSync ACEs are removed.
- repadmin /replsummary output confirming replication health.
- Azure AD Connect sync validation if applicable.
- Follow-up scan results confirming finding resolution.
Additional Guidance
DCSync rights should be restricted to domain controllers and explicitly approved replication or directory synchronization accounts. An account with these rights can request password data from the domain, which can expose krbtgt and privileged account hashes without interactive access to a domain controller.
Review DCSync permissions during privileged access reviews and after any directory synchronization, backup, or monitoring tool deployment. Treat new or unexpected DCSync permissions as a high-priority access governance event that requires owner approval, documented justification, and follow-up validation.
Schema Admins Group Not Empty
Schema Admins Group Not Empty
Schema Admins Group Not Empty
The "Schema Admins" group allows members to modify the Active Directory schema, which defines the structure of AD objects. These changes are permanent and can have far-reaching consequences. For security, this group should remain empty unless a schema update is necessary, and membership should be strictly controlled.
Schema group members are a prime target for attackers, specifically if they are looking to cause denial of service attacks.
Recommendation
Remove standing membership from Schema Admins, use temporary access for approved schema changes, and validate the group remains empty afterward.
Prerequisites
- Domain Administrator or Enterprise Administrator credentials required.
- Confirm that no active schema extension operations are in progress before removing members.
- Locate each current member and confirm with the account owner that the membership is no longer required.
- Obtain change control approval.
Remediation Objective
- Remove all accounts from the Schema Admins group when schema modification operations are not actively in progress.
- Ensure the Schema Admins group is empty except during planned, approved schema extension projects.
- Reduce the risk of unauthorized or accidental schema changes that could affect the entire forest.
- Apply the principle of just-in-time access for schema modification privileges.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Remove a specific member from Schema Admins.
# Replace <MemberName> with the account to remove.
Remove-ADGroupMember -Identity "Schema Admins" -Members "<MemberName>" -Confirm:$false -WhatIf
# Remove -WhatIf after reviewing output and confirming no active schema operation.# Import the required module for the remediation.
Import-Module ActiveDirectory
# Import a reviewed and approved list of affected objects to remediate.
$Items = Import-Csv -Path ".\ApprovedObjects.csv"
# Update only the objects included in the approved input file.
foreach ($Item in $Items) {
# Replace the placeholder command with the approved single-object remediation command for Schema Admins Group Not Empty.
# Use -WhatIf when supported before applying the change.
<Approved-Remediation-Command> -Identity $Item.DistinguishedName -WhatIf
}Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. - Navigate to the Users containerLocate the Schema Admins group.
- Open group propertiesRight-click Schema Admins and select Properties, then click the Members tab.
- Remove all membersSelect each member and click Remove.
- Save and validateClick OK. Confirm the group is empty.
Validation
- Confirm Schema Admins is empty: Get-ADGroupMember -Identity 'Schema Admins'
- Verify no authentication or directory operation failures occur following the change.
- Run a follow-up scan to confirm the finding is resolved.
Exceptions
- Do not approve permanent exceptions for this condition.
- Document any temporary delay with owner and target date.
- Track formal risk acceptance until remediation is complete.
Evidence
- Export of Schema Admins membership before changes.
- Change ticket and approval record.
- PowerShell output confirming empty group membership.
- Follow-up scan results confirming finding resolution.
Additional Guidance
Schema Admins should normally remain empty except during approved schema changes. Remove standing membership, use time-bound access for schema updates, and monitor the group for unexpected additions.
Unconstrained Delegations Detected
Unconstrained Delegations Detected
Unconstrained Delegations Detected
Unconstrained delegation allows a service or account to impersonate any user that interacts with it by caching their Kerberos ticket-granting tickets (TGT). This creates a significant security risk, as attackers who compromise a service trusted for unconstrained delegation can extract these TGTs and impersonate privileged accounts, leading to domain take over.
Unconstrained delegation is often combined with network poisoning attacks and endpoint configuration abuse to force communication from sensitive assets such as domain controllers. The attack path typically involves immediately dumping the domain controller of hashes which can be passed or cracked offline.
Recommendation
Remove unconstrained delegations or replace it with constrained delegation where required.
Prerequisites
- Domain Admin rights to modify delegation settings on accounts and computers.
- Service owner identification and sign-off for each affected account.
- Testing environment available to validate service functionality after delegation change.
- Change control approval obtained.
- Rollback plan documented.
Remediation Objective
- Remove unconstrained delegation from all non-domain controller accounts and computers where it is identified.
- Replace unconstrained delegation with constrained delegation scoped to the minimum required services.
- Confirm affected services continue to function correctly after the change.
- Implement monitoring for TGT requests from accounts with delegation enabled.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Import the Active Directory module.
Import-Module ActiveDirectory
# Remove unconstrained delegation from a specific user or computer account.
# Replace <SamAccountName> with the target account.
# For a computer account, append $ to the name (e.g., SERVER01$).
# Disable unconstrained delegation by setting TrustedForDelegation to $false.
Set-ADAccountControl -Identity "<SamAccountName>" -TrustedForDelegation $false# Import the Active Directory module.
Import-Module ActiveDirectory
# Import a reviewed list of accounts with unconstrained delegation to remediate.
# CSV must contain a column named SamAccountName.
$Accounts = Import-Csv -Path ".\ApprovedDelegationAccounts.csv"
# Remove unconstrained delegation from each account in the approved input file.
foreach ($Account in $Accounts) {
Set-ADAccountControl -Identity $Account.SamAccountName -TrustedForDelegation $false -WhatIf
Write-Output "Processed: $($Account.SamAccountName)"
}
# Remove -WhatIf after the change has been reviewed and approved.Remediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Active Directory Users and ComputersLaunch
dsa.mscfrom an administrative workstation. Enable Advanced Features under the View menu. - Locate the affected accountNavigate to the OU or container containing the account identified in the report.
- Open account propertiesDouble-click the account to open its properties.
- Navigate to the Delegation tabSelect the Delegation tab.
- Remove unconstrained delegationSelect Do not trust this computer for delegation, or select Use Kerberos only constrained delegation if the service requires delegation to specific services.
- Configure constrained delegation (if required)If the service requires delegation, select Use Kerberos only and add the specific SPNs to the Services to which this account can present delegated credentials list.
- Save changesClick OK or Apply.
Validation
- Confirm unconstrained delegation is removed using Get-ADUser or Get-ADComputer with -Properties TrustedForDelegation.
- Verify that affected services are functioning correctly after the change.
- Confirm no new TGT caching is occurring for the account by reviewing Kerberos event logs.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the privileged access dependency and justification.
- Assign an owner and target remediation date.
- Apply compensating controls and track risk acceptance.
Evidence
- Before-and-after export of delegation settings for affected accounts.
- Service validation test results confirming functionality after change.
- Change ticket and approval record.
- PowerShell transcript of remediation commands.
Additional Guidance
Unconstrained delegation is a dangerous configuration that should be avoided in most environments due to its susceptibility to Kerberos-based attacks. Conduct regular audits to detect and remove any accounts with unconstrained delegation and implement monitoring to detect suspicious activity related to TGT requests. If a delegation must be kept, consider moving to a “constrained delegation” which will restrict which services can be delegated to. If choosing this option, ensure additional monitoring and alerting is configured for this service. Any unconstrained or constrained delegated account should be treated as a domain administrator or equivalent.
User-controlled certificate template subject in ADCS (ESC1)
User-controlled certificate template subject in ADCS (ESC1)
User-controlled certificate template subject in ADCS (ESC1)
This is a critical security issue where low-level users can exploit certificate request settings to impersonate higher-privileged accounts, like domain administrators. This occurs when certificate templates are configured with weak permissions that allow users to input key identity details themselves. If these conditions align, users can request certificates that allow them to assume the identity of others.
This misconfiguration is highly sought after by attackers, as it requires minimal skill to exploit and has a high success rate for privilege escalation. Once authenticated, attackers use tools like Certipy, Certify, or Rubeus, to identify vulnerable certificate templates, generate a certificate as a domain administrator, and retrieve the user’s NT hash. This hash can then be used in Pass-the-Hash attacks or cracked offline. Attackers may then employ tools like CrackMapExec or Impacket’s secretsdump.py to remotely extract hashes from the domain controller.
Recommendation
Remove enrollee-supplied subject settings from vulnerable templates, restrict enrollment, and validate that authentication certificates cannot be requested for arbitrary identities.
Prerequisites
- Enterprise Admin or CA Administrator rights to modify certificate templates.
- Inventory of services and applications using affected certificate template.
- Testing environment available to validate template changes.
- Change control approval obtained.
Remediation Objective
- Remove or restrict the Supply in Request (SAN) flag from vulnerable certificate templates.
- Require manager approval for certificate issuance on sensitive templates.
- Restrict enrollment rights to remove low-privileged groups such as Authenticated Users or Domain Users.
- Ensure that at least one of the ESC1 enabling conditions is broken to prevent exploitation.
Remediation Path 1: Command-Line
Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.
# Disable the Supply in Request flag on a vulnerable certificate template.
# This must be run with Enterprise Admin or CA Administrator rights.
# Load the PSPKI module (install if not present).
Install-Module -Name PSPKI -Force -AllowClobber
Import-Module PSPKI
# Retrieve the certificate template by name.
# Replace <TemplateName> with the display name of the vulnerable template.
$Template = Get-CertificateTemplate -Name "<TemplateName>"
# Remove the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag (0x1) from the template.
# This prevents users from specifying a Subject Alternative Name in their request.
$Flags = $Template.pKIDefaultKeySpec
Set-CertificateTemplateAcl -Template $TemplateRemediation Path 2: GUI
Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.
- Open Certificate Templates ConsoleRun
certtmpl.mscfrom an administrative workstation with Enterprise Admin rights. - Locate the affected templateLocate the certificate template named in the report. Right-click the template and select Duplicate Template to create a test copy, or Properties to modify directly.
- Review the Subject Name tabSelect the Subject Name tab. If Supply in the request is selected, change this to Build from this Active Directory information to prevent users from supplying their own SAN.
- Review the Security tabOn the Security tab, remove Authenticated Users or Domain Users from the enrollment permissions if they are present. Restrict enrollment to specific groups with a documented business need.
- Enable manager approvalOn the Issuance Requirements tab, check CA certificate manager approval to require manual approval of certificate requests.
- Apply changes and republishClick OK to save the template changes. In the Certification Authority console (
certsrv.msc), right-click Certificate Templates and reissue the updated template.
Validation
- Confirm the ENROLLEE_SUPPLIES_SUBJECT flag is no longer set on the template using Get-CertificateTemplate or certutil -v -dump.
- Attempt to enroll a certificate with a custom SAN using a low-privileged account to confirm the vulnerability is no longer exploitable.
- Verify that legitimate enrollment processes continue to function correctly.
- Run Insight Recon AD against the same scope to confirm the finding is resolved.
Exceptions
- Document the certificate dependency and business justification.
- Assign a PKI owner and target remediation date.
- Restrict enrollment or access until remediation is complete.
Evidence
- CA database backup confirmation prior to template changes.
- Before-and-after certutil output showing template flag changes.
- Certificate enrollment test results.
- Change ticket and approval record.
- Follow-up scan results showing finding resolved.
Additional Guidance
ESC1 is one of the most commonly exploited ADCS vulnerabilities because it requires minimal skill to exploit and reliably results in domain administrator-level compromise. The vulnerability exists at the intersection of multiple template configuration weaknesses, and organizations can break the attack chain by correcting any single condition. The highest-priority change is removing the ability for low-privileged users to supply a Subject Alternative Name in certificate requests.
Organizations operating an Active Directory Certificate Services infrastructure should conduct a regular PKI security review that includes assessment of all certificate template configurations. Template permissions should be reviewed quarterly, and any new template should be subject to a formal security review before publication to the CA.
For this vulnerability to be exploitable, several conditions must be met: 1. Enrollment Rights for Low-Privileged Users 2. No Manager Approval or Authorized Signatures 3. Overly Permissive Security Descriptors 4. Authentication-Enabled EKUs 5. User-Specified Subject Alternative Name (SAN)
| Object | Type | Details |
|---|---|---|
| Template-ESC1 | Certificate template | |
Domain Users | Account | Enroll |
Environment Overview
Scope and inventory of the Active Directory tenant scanned. Use this to confirm the right environment was assessed and quickly spot foundational gaps.
Domain Configuration
Forest, schema, and naming details.
Infrastructure Status
Health checks across core AD services.
Accounts & Groups
Accounts, privileged groups, and special service identities.
Privileged Groups
High-level overview of privileged groups and their membership.
| Name | Count | Enabled | Disabled | Inactive | Password Never Expires | Service Accounts | Can be Delegated | Protected Users | External Users |
|---|---|---|---|---|---|---|---|---|---|
| Account Operators | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| Administrators | 3 | 3 | 0 | 0 | 1 | 0 | 1 | 0 | 2 |
| Backup Operators | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| Domain Admins | 4 | 3 | 1 | 1 | 3 | 0 | 4 | 0 | 0 |
| Enterprise Admins | 2 | 2 | 0 | 0 | 2 | 0 | 2 | 0 | 0 |
| Print Operators | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| Schema Admins | 1 | 1 | 0 | 0 | 1 | 0 | 1 | 0 | 0 |
| Server Operators | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Account Operators Count: 0
| Name | Risk | Enabled | Active | Password Never Expires | Locked | Service Account | Can be Delegated | In Protected Users | Creation Date | Last Login | Last Password Change | DN |
|---|
Administrators Count: 3
| Name | Risk | Enabled | Active | Password Never Expires | Locked | Service Account | Can be Delegated | In Protected Users | Creation Date | Last Login | Last Password Change | DN |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Administrator | 77.4Critical | Yes | Yes | Yes | No | No | Yes | No | 2021-06-30 | 2026-08-14 19:42 | 2021-10-07 | CN=Administrator,CN=Users,DC=snaplabs,DC=local |
| Domain Admins | — | Yes | No | No | No | No | No | No | CN=Domain Admins,CN=Users,DC=snaplabs,DC=local | |||
| Enterprise Admins | — | Yes | No | No | No | No | No | No | CN=Enterprise Admins,CN=Users,DC=snaplabs,DC=local |
Backup Operators Count: 0
| Name | Risk | Enabled | Active | Password Never Expires | Locked | Service Account | Can be Delegated | In Protected Users | Creation Date | Last Login | Last Password Change | DN |
|---|
Domain Admins Count: 4
| Name | Risk | Enabled | Active | Password Never Expires | Locked | Service Account | Can be Delegated | In Protected Users | Creation Date | Last Login | Last Password Change | DN |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Administrator | 77.4Critical | Yes | Yes | Yes | No | No | Yes | No | 2021-06-30 | 2026-08-14 19:42 | 2021-10-07 | CN=Administrator,CN=Users,DC=snaplabs,DC=local |
| demouser | 72.9Critical | Yes | Yes | Yes | No | No | Yes | No | 2026-07-27 | 2026-10-20 19:33 | 2026-07-27 | CN=Demo User,CN=Users,DC=snaplabs,DC=local |
| domain_admin | 76.5Critical | Yes | Yes | Yes | No | No | Yes | No | 2021-06-30 | 2026-08-13 17:41 | 2021-06-30 | CN=domain admin,CN=Users,DC=snaplabs,DC=local |
| Sync_disabled01 | 74.7Critical | No | No | No | No | No | Yes | No | 2026-08-13 | Never | 2026-08-13 | CN=Sync_disabled01,CN=Users,DC=snaplabs,DC=local |
Enterprise Admins Count: 2
| Name | Risk | Enabled | Active | Password Never Expires | Locked | Service Account | Can be Delegated | In Protected Users | Creation Date | Last Login | Last Password Change | DN |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Administrator | 77.4Critical | Yes | Yes | Yes | No | No | Yes | No | 2021-06-30 | 2026-08-14 19:42 | 2021-10-07 | CN=Administrator,CN=Users,DC=snaplabs,DC=local |
| domain_admin | 76.5Critical | Yes | Yes | Yes | No | No | Yes | No | 2021-06-30 | 2026-08-13 17:41 | 2021-06-30 | CN=domain admin,CN=Users,DC=snaplabs,DC=local |
Print Operators Count: 0
| Name | Risk | Enabled | Active | Password Never Expires | Locked | Service Account | Can be Delegated | In Protected Users | Creation Date | Last Login | Last Password Change | DN |
|---|
Schema Admins Count: 1
| Name | Risk | Enabled | Active | Password Never Expires | Locked | Service Account | Can be Delegated | In Protected Users | Creation Date | Last Login | Last Password Change | DN |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Administrator | 77.4Critical | Yes | Yes | Yes | No | No | Yes | No | 2021-06-30 | 2026-08-14 19:42 | 2021-10-07 | CN=Administrator,CN=Users,DC=snaplabs,DC=local |
Server Operators Count: 0
| Name | Risk | Enabled | Active | Password Never Expires | Locked | Service Account | Can be Delegated | In Protected Users | Creation Date | Last Login | Last Password Change | DN |
|---|
User Accounts
Detailed information about user accounts in the environment.
User Accounts User Accounts: 9
Computer Accounts
Detailed information about computer accounts in the environment.
Computer Accounts Computer Accounts: 4
Infrastructure & Cloud
Cloud sync, endpoint management, and update services. Detached or misconfigured here usually means slower patching and weaker visibility.
Cloud Services
Hybrid sync to Microsoft Entra (Azure AD).
Entra ID Sync Enabled
Entra Connect Enabled
Management Tools
Overview and configuration status of management and update tools.
Trusts
Active Directory trust relationships with external domains and forests.
PKI & Certificates
Overview and configuration status of PKI infrastructure and certificates.
Certificate Authorities
Certificate authority infrastructure and issued certificate counts.
Certificate Authorities CAs: 1 Certificates: 1
| CA Name | DNS Hostname | Certificates |
|---|---|---|
| snaplabs-DC-CA | DC.snaplabs.local | 1 |
Certificate Templates
Certificate template configuration and enrollment risk indicators. Flags highlight enrollment misconfigurations associated with ADCS escalation paths.
Certificate Templates Templates: 34
| Name | Destination | Manager Approval | Enrollee Can Supply Subject | Issuance Requirements | Vulnerable ACL | Everyone Can Enroll | Agent Template | Any Purpose | For Authentication |
|---|---|---|---|---|---|---|---|---|---|
| Administrator | User | No | No | No | No | No | No | No | Yes |
| Authenticated Session | User | No | No | No | No | Yes | No | No | Yes |
| Basic EFS | User | No | No | No | No | Yes | No | No | No |
| CA Exchange | Computer | No | Yes | No | No | No | No | No | No |
| CEP Encryption | Computer | No | Yes | No | No | No | Yes | No | No |
| Code Signing | User | No | No | No | No | No | No | No | No |
| Computer | Computer | No | No | No | No | Yes | No | No | Yes |
| Cross Certification Authority | User | No | Yes | Yes | No | No | No | Yes | Yes |
| Directory Email Replication | Computer | No | No | No | No | No | No | No | No |
| Domain Controller | Computer | No | No | No | No | No | No | No | Yes |
| Domain Controller Authentication | Computer | No | No | No | No | No | No | No | Yes |
| EFS Recovery Agent | User | No | No | No | No | No | No | No | No |
| Enrollment Agent | User | No | No | No | No | No | Yes | No | No |
| Enrollment Agent (Computer) | Computer | No | No | No | No | No | Yes | No | No |
| Exchange Enrollment Agent (Offline request) | User | No | Yes | No | No | No | Yes | No | No |
| Exchange Signature Only | User | No | Yes | No | No | No | No | No | No |
| Exchange User | User | No | Yes | No | No | No | No | No | No |
| IPSec | Computer | No | No | No | No | Yes | No | No | No |
| IPSec (Offline request) | Computer | No | Yes | No | No | No | No | No | No |
| Kerberos Authentication | Computer | No | No | No | No | No | No | No | Yes |
| Key Recovery Agent | User | Yes | No | No | No | No | No | No | No |
| OCSP Response Signing | Computer | No | No | No | No | No | No | No | No |
| RAS and IAS Server | Computer | No | No | No | No | No | No | No | Yes |
| Root Certification Authority | Computer | No | Yes | No | No | No | No | Yes | Yes |
| Router (Offline request) | Computer | No | Yes | No | No | No | No | No | Yes |
| Smartcard Logon | User | No | No | No | No | No | No | No | Yes |
| Smartcard User | User | No | No | No | No | No | No | No | Yes |
| Subordinate Certification Authority | Computer | No | Yes | No | No | No | No | Yes | Yes |
| Template-ESC1 | User | No | Yes | No | No | Yes | No | Yes | Yes |
| Trust List Signing | User | No | No | No | No | No | No | No | No |
| User | User | No | No | No | No | Yes | No | No | Yes |
| User Signature Only | User | No | No | No | No | Yes | No | No | Yes |
| Web Server | Computer | No | Yes | No | No | No | No | No | No |
| Workstation Authentication | Computer | No | No | No | No | Yes | No | No | Yes |
Trusted Certificates
Enterprise trusted certificate stores and authentication-related certificates.
Trusted Certificates Certificates: 3
| Source | Store | Subject | Issuer | Valid From | Valid Until | Key Length | Signature Algorithm | Smart Card Logon |
|---|---|---|---|---|---|---|---|---|
| Enterprise NTAuth | NTAuthCertificates | CN=snaplabs-DC-CA, DC=snaplabs, DC=local | CN=snaplabs-DC-CA, DC=snaplabs, DC=local | Aug 14, 2026 | Aug 14, 2031 | 2048 | sha256RSA | Disabled |
| Enterprise Root | Certification Authorities | CN=snaplabs-DC-CA, DC=snaplabs, DC=local | CN=snaplabs-DC-CA, DC=snaplabs, DC=local | Aug 14, 2026 | Aug 14, 2031 | 2048 | sha256RSA | Disabled |
| Enterprise AIA | AIA | CN=snaplabs-DC-CA, DC=snaplabs, DC=local | CN=snaplabs-DC-CA, DC=snaplabs, DC=local | Aug 14, 2026 | Aug 14, 2031 | 2048 | sha256RSA | Disabled |
Group Policy
Overview and configuration status of domain group policies.
Password Policies
Domain password and account lockout policy configuration.
Password Policies Policies: 1
| Policy Name | Policy Type | Password Complexity Enabled | Maximum Password Age | Minimum Password Length | Password History Length | Reversible Encryption | Account Lockout Threshold | Account Lockout Duration |
|---|---|---|---|---|---|---|---|---|
| Default Domain Policy | Default | Yes | 42 days | 7 | 24 | Disabled | — | 30 minutes |
Screensaver Policies
Screen lock and inactivity timeout settings applied through Group Policy.
Firewall Policies
Windows Firewall policy settings and inbound access controls.
Group Policy Objects
2 GPO(s) in the domain.
| Name | Enabled | Modified |
|---|---|---|
| Default Domain Controllers Policy | Yes | Jun 30, 2021 |
| Default Domain Policy | Yes | Jun 30, 2021 |
Silenced Findings
Findings the team has deliberately silenced as accepted risk or not applicable. They are excluded from the score, counts, and findings above, and are listed here as the evidence trail for that decision.
| Finding | Category | Scope | Mode | Reason | Silenced By | Date |
|---|---|---|---|---|---|---|
| LLMNR Enabled | Policy and Configuration Management | snaplabs.local | Silenced until material change | Compensating control in place. | [email protected] | Sep 30, 2026 |