Anomalies

A-LAPS-Not-Installed

What it means

Every Windows computer has a built-in local Administrator account. By default, this account often has the same password across all machines, or a password that never changes. If an attacker compromises one machine, they can reuse that password to access all the others.

LAPS (Local Administrator Password Solution) solves this by automatically setting a unique, randomly generated password on each computer and storing it securely in Active Directory. Only authorized administrators can retrieve it.

What the scan checks

The AD Scan looks for evidence that LAPS has been set up in your Active Directory. Specifically, it checks whether the necessary LAPS data fields exist in your AD configuration. If they don't, it means LAPS was never installed.

Why the alert may persist

• LAPS managed through Intune only: If you use Microsoft Intune to manage LAPS passwords in the cloud (without configuring the on-premises AD), the AD Scan cannot detect it. The scan only looks at your local Active Directory.

• LAPS was partially installed: The LAPS setup may have been started but not completed.

How to diagnose

# Check if LAPS is set up in your Active Directory
Get-ADObject -SearchBase (Get-ADRootDSE).SchemaNamingContext `
  -Filter "name -like 'ms-Mcs-AdmPwd' -or name -eq 'ms-LAPS-Password'" |
  Select-Object Name, whenCreated

If this returns no results, LAPS is not installed.

How to fix

For Windows Server 2019 and later (recommended): Modern LAPS is built into Windows. Enable it via Group Policy:

1. Open gpmc.msc (Group Policy Management)

2. Edit or create a GPO linked to your computer OUs

3. Navigate to: Computer Configuration > Administrative Templates > System > LAPS

4. Configure the LAPS settings (enable, set password complexity, etc.)

For older environments: Download Legacy LAPS from Microsoft and run the schema extension:

Update-LapsADSchema

Note: If you manage local admin passwords through a different tool (CyberArk, Intune-only LAPS, etc.), contact Stoïk support to document this as an accepted exception.

A-LAPS-Joined-Computers

What it means

When someone adds ("joins") a computer to the Active Directory domain, that person becomes the creator of the computer object in AD. By default, the creator gets special permissions on that object.

The problem is: when LAPS is installed, the local admin password is stored on that same computer object. If the creator still has the right permissions, they can read the LAPS password, even if they are not an administrator. This means a regular user who once joined a PC to the domain could retrieve the local admin password for that machine.

What the scan checks

For each enabled computer with LAPS deployed, the AD Scan checks two things:

1. Is the person who joined the computer still the "owner" of the computer object? Owners can grant themselves any permission, including reading the LAPS password.

2. Does the creator still have explicit permissions on the computer object such as All Extended Rights (which allows reading the LAPS password), WriteDacl (which allows modifying permissions), WriteOwner (which allows taking back ownership), or GenericWrite?

The alert triggers if either condition is true.

Why the alert may persist

This is the most common source of confusion: changing the owner is only half the fix.

Many administrators change the owner to "Domain Admins" and expect the alert to disappear. But the AD Scan also checks for leftover permissions (called ACEs, or Access Control Entries) that were granted to the original creator. These permissions stay in place even after changing the owner and must be removed separately.

How to diagnose

# List computers where the creator still has risky permissions
Get-ADComputer -Filter "Enabled -eq `$true" `
  -Properties "mS-DS-CreatorSID", "nTSecurityDescriptor" |
  Where-Object { $_."mS-DS-CreatorSID" -ne $null } |
  ForEach-Object {
    $comp = $_
    $acl = $comp.nTSecurityDescriptor
    $creatorSid = $comp."mS-DS-CreatorSID"
    $owner = $acl.GetOwner([System.Security.Principal.SecurityIdentifier])

    $isOwner = ($owner.Value -eq $creatorSid.Value)

    $riskyAces = $acl.Access | Where-Object {
      -not $_.IsInherited -and
      $_.IdentityReference.Value -eq $creatorSid.Value -and
      ($_.ActiveDirectoryRights -match 'WriteDacl|WriteOwner|GenericWrite|ExtendedRight')
    }

    if ($isOwner -or $riskyAces) {
      [PSCustomObject]@{
        Computer       = $comp.Name
        CreatorIsOwner = $isOwner
        RiskyRights    = ($riskyAces | ForEach-Object { $_.ActiveDirectoryRights }) -join ", "
      }
    }
  } | Format-Table -AutoSize

How to fix

You need to do both of these for each affected computer:

1. Change the owner to Domain Admins

2. Remove the creator's explicit permissions

The following script does both automatically:

#Requires -Modules ActiveDirectory

$affectedComputers = Get-ADComputer -Filter "Enabled -eq `$true" `
  -Properties "mS-DS-CreatorSID", "nTSecurityDescriptor" |
  Where-Object { $_."mS-DS-CreatorSID" -ne $null }

foreach ($comp in $affectedComputers) {
  $path = "AD:$($comp.DistinguishedName)"
  $acl = Get-Acl -Path $path
  $creatorSid = $comp."mS-DS-CreatorSID"
  $modified = $false

  # Step 1: Change owner to Domain Admins
  $domainAdmins = New-Object System.Security.Principal.NTAccount("$env:USERDOMAIN", "Domain Admins")
  $acl.SetOwner($domainAdmins)
  $modified = $true

  # Step 2: Remove explicit permissions granted to the creator (and orphaned SIDs)
  $toRemove = @($acl.Access | Where-Object {
    -not $_.IsInherited -and
    ($_.IdentityReference.Value -eq $creatorSid.Value -or
     $_.IdentityReference.Value -match '^S-1-5-21-')  # Orphaned SIDs (deleted accounts)
  })

  foreach ($ace in $toRemove) {
    $acl.RemoveAccessRuleSpecific($ace)
    Write-Host "$($comp.Name): Removed [$($ace.ActiveDirectoryRights)] for $($ace.IdentityReference)"
  }

  if ($modified) {
    Set-Acl -Path $path -AclObject $acl
    Write-Host "$($comp.Name): Fixed" -ForegroundColor Green
  }
}

Tip: Run the diagnostic command first to review the list of affected computers before applying the fix.

A-NoServicePolicy

What it means

Service accounts are accounts used by applications and services (e.g., SQL Server, backup agents) to authenticate in Active Directory. Unlike regular user accounts, service accounts are high-value targets: they often have elevated permissions and their passwords are rarely changed.

A Fine-Grained Password Policy (PSO) is a special password rule that you can apply to specific groups of accounts. The AD Scan expects that your service accounts are covered by a PSO requiring passwords of at least 20 characters, making them much harder to crack.

What the scan checks

The AD Scan looks for at least one password policy (GPO or PSO) that enforces a minimum password length of 20 characters or more.

Why the alert may persist

1. The scan account doesn't have permission to read the PSO. Password policies are stored in a protected area of AD that only Domain Admins can read by default. If the scan runs with a less-privileged account, it simply cannot see the PSO, even though it exists.

2. The PSO exists but the minimum length is below 20 (e.g., 12 or 15 characters).

3. The PSO exists but is not assigned to any group or user.

How to diagnose

# List all Fine-Grained Password Policies and their settings
Get-ADFineGrainedPasswordPolicy -Filter * |
  Select-Object Name, MinPasswordLength, @{N="AppliedTo"; E={$_.AppliesTo -join ", "}}, Precedence

If this returns nothing, either no PSO exists or the account running the command lacks permissions to see it. Try running with a Domain Admin account.

How to fix

If the PSO exists but the scan can't see it: Run the AD Scan with a Domain Admin account.

If no PSO exists: Create one and assign it to your service accounts:

# Create a password policy for service accounts
New-ADFineGrainedPasswordPolicy -Name "Service Accounts - Strong Password" `
  -Precedence 10 `
  -MinPasswordLength 20 `
  -MaxPasswordAge "90.00:00:00" `
  -MinPasswordAge "1.00:00:00" `
  -PasswordHistoryCount 24 `
  -ComplexityEnabled $true `
  -ReversibleEncryptionEnabled $false `
  -LockoutDuration "00:30:00" `
  -LockoutObservationWindow "00:30:00" `
  -LockoutThreshold 5

# Assign it to a security group containing your service accounts
Add-ADFineGrainedPasswordPolicySubject `
  -Identity "Service Accounts - Strong Password" `
  -Subjects "SG_ServiceAccounts"

Note: Creating a PSO does not immediately force password changes. Existing passwords will continue to work until they expire or are manually reset. At that point, the new 20-character minimum will apply.

A-AuditDC

What it means

Audit policies determine what events are logged on your Domain Controllers. Without proper auditing, attacks like credential theft, unauthorized group changes, or replication abuse (DCSync) can happen without leaving any trace in the logs.

The AD Scan verifies that your Domain Controllers are configured to log the most important security events.

What the scan checks

The scan looks for 13 specific audit subcategories that should be enabled via Group Policy on all Domain Controllers:

Category	What it logs
Kerberos Authentication Service	Login attempts via Kerberos
Kerberos Service Ticket Operations	Service ticket requests (detects Kerberoasting)
Computer Account Management	Computer joins/changes in AD
Security Group Management	Group membership changes
User Account Management	User creation, deletion, password resets
DPAPI Activity	Data protection API usage (credential access)
Process Creation	New processes started (detects malicious tools)
Logon / Logoff	Interactive and remote logins
Special Logon	Logins with elevated privileges
Authentication Policy Change	Changes to authentication settings
Sensitive Privilege Use	Use of sensitive permissions
Security System Extension	Security subsystem changes

Why the alert may persist

1. Settings applied via auditpol directly on the DC are not detected. The AD Scan reads Group Policy files, not the local DC configuration. You must use a GPO.

2. Conflicting GPOs: One GPO enables the setting, but another GPO with higher priority disables it.

3. GPO not linked to the Domain Controllers OU: The GPO exists but is linked to a different OU.

How to diagnose

# Check the effective audit policy on a Domain Controller
auditpol /get /category:*

If the local settings look correct but the alert persists, check that the settings come from a GPO (not a local override):

# Verify which GPOs are linked to the Domain Controllers OU
Get-GPInheritance -Target "OU=Domain Controllers,$($(Get-ADDomain).DistinguishedName)"

How to fix

1. Open gpmc.msc (Group Policy Management Console)

2. Create or edit a GPO linked to OU=Domain Controllers

3. Navigate to: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies

4. Enable Success and Failure for all subcategories listed above

5. Run gpupdate /force on all Domain Controllers

Verify the fix:

auditpol /get /category:"Account Logon"
auditpol /get /category:"Account Management"
auditpol /get /category:"Logon/Logoff"

A-BadSuccessor

What it means

Windows Server 2025 introduced a new type of service account called dMSA (Delegated Managed Service Account). A security flaw was discovered where a regular user with certain permissions on an Active Directory folder (called an Organizational Unit, or OU) could create a dMSA and use it to gain full administrator access to the domain.

This attack is only possible when:

• You have at least one Windows Server 2025 Domain Controller

• A KDS Root Key exists (required for managed service accounts)

• A non-admin user has the right to create objects in an OU

What the scan checks

The AD Scan looks for non-privileged users or groups that have permissions to create or control dMSA objects on any OU such as CreateChild, GenericAll, WriteDacl, or WriteOwner.

Why the alert may persist

• The fix must be applied on every affected OU, not just one.

• Permissions inherited from parent OUs still apply to child OUs.

• Custom admin groups may not be recognized as "privileged" by the scan.

How to diagnose

# Check prerequisites
Get-KdsRootKey  # KDS Root Key must exist for the attack to be possible

Get-ADDomainController -Filter * |
  Where-Object { $_.OperatingSystem -like "*2025*" } |
  Select-Object Name, OperatingSystem  # At least one Win2025 DC

# Find OUs with risky delegations
Get-ADOrganizationalUnit -Filter * -Properties nTSecurityDescriptor |
  ForEach-Object {
    $ou = $_
    $ou.nTSecurityDescriptor.Access |
      Where-Object {
        -not $_.IsInherited -and
        $_.ActiveDirectoryRights -match 'GenericAll|CreateChild|WriteDacl|WriteOwner'
      } | ForEach-Object {
        [PSCustomObject]@{
          OU        = $ou.Name
          Principal = $_.IdentityReference
          Rights    = $_.ActiveDirectoryRights
        }
      }
  } | Format-Table -AutoSize

How to fix

For each flagged OU, remove the risky permissions from non-admin users:

$ouDN = "OU=Servers,DC=yourdomain,DC=com"  # Replace with your OU
$path = "AD:$ouDN"
$acl = Get-Acl -Path $path

# Remove risky rights for a specific group
$identity = New-Object System.Security.Principal.NTAccount("YOURDOMAIN", "HelpDeskTeam")
$toRemove = $acl.Access | Where-Object {
  $_.IdentityReference -eq $identity -and
  $_.ActiveDirectoryRights -match 'CreateChild|GenericAll'
}

foreach ($ace in $toRemove) {
  $acl.RemoveAccessRuleSpecific($ace)
}
Set-Acl -Path $path -AclObject $acl

A-AdminSDHolder

What it means

When a user is added to a privileged group in Active Directory (like Domain Admins), the system automatically marks their account with a flag called adminCount = 1. This flag is part of a built-in protection mechanism.

The problem is: when you remove that user from the admin group, the flag is NOT automatically cleared. It stays forever, unless you explicitly remove it.

The AD Scan flags accounts that have this leftover adminCount marker but are no longer actual administrators. This can indicate:

• A user who was temporarily made admin and the cleanup was incomplete

• A potential security concern: these accounts may still have elevated permissions in certain areas

What the scan checks

The scan finds enabled user accounts where adminCount = 1 but the account is not currently a member of any privileged group.

How to diagnose

# Build a list of all current privileged users
$privilegedMembers = @()
@("Domain Admins", "Enterprise Admins", "Schema Admins", "Administrators",
  "Account Operators", "Server Operators", "Backup Operators", "Print Operators"
) | ForEach-Object {
  try { $privilegedMembers += (Get-ADGroupMember $_ -Recursive).DistinguishedName } catch {}
}

# Find accounts with the leftover adminCount flag
Get-ADUser -LDAPFilter "(&(admincount=1)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))" `
  -Properties adminCount |
  Where-Object { $_.DistinguishedName -notin $privilegedMembers } |
  Select-Object SamAccountName, Name

How to fix

After confirming that these accounts should no longer be administrators, clear the flag:

# Clear adminCount for a single user
Set-ADUser -Identity "username" -Clear adminCount

# Or clear it for all non-privileged users at once
Get-ADUser -LDAPFilter "(&(admincount=1)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))" |
  Where-Object { $_.DistinguishedName -notin $privilegedMembers } |
  ForEach-Object {
    Set-ADUser -Identity $_ -Clear adminCount
    Write-Host "Cleared adminCount for $($_.SamAccountName)"
  }

A-NoGPOLLMNR

What it means

LLMNR (Link-Local Multicast Name Resolution) is a protocol that Windows uses to find other computers on the network when DNS doesn't have the answer. It works by broadcasting a question to all nearby machines: "Does anyone know where servername is?"

The problem is: an attacker on the same network can respond to these broadcasts pretending to be the target server, tricking the victim into sending their credentials to the attacker. This is called an LLMNR poisoning attack and is one of the most common techniques used during internal network attacks.

LLMNR is a legacy protocol that modern networks don't need (DNS handles everything). It should be disabled via Group Policy.

What the scan checks

The AD Scan looks for an enabled and linked GPO that disables LLMNR by setting the EnableMulticast registry value to 0.

Why the alert may persist

1. GPO exists but is not linked to any OU.

2. GPO is disabled, even if linked.

3. LLMNR was disabled manually (via registry or netsh) but not through Group Policy. The AD Scan reads GPO files, not local machine settings.

How to diagnose

Import-Module GroupPolicy
Get-GPO -All | ForEach-Object {
  [xml]$r = Get-GPOReport -Guid $_.Id -ReportType Xml
  if ($r.InnerXml -match "EnableMulticast") {
    Write-Host "GPO '$($_.DisplayName)' - Status: $($_.GpoStatus) - Contains LLMNR setting"
  }
}

How to fix

$gpoName = "Disable LLMNR"
$gpo = Get-GPO -Name $gpoName -ErrorAction SilentlyContinue
if (-not $gpo) { $gpo = New-GPO -Name $gpoName }

Set-GPRegistryValue -Name $gpoName `
  -Key "HKLM\Software\Policies\Microsoft\Windows NT\DNSClient" `
  -ValueName "EnableMulticast" -Type DWord -Value 0

# Link to the domain root so it applies to all computers
New-GPLink -Name $gpoName `
  -Target (Get-ADDomain).DistinguishedName `
  -LinkEnabled Yes

After linking the GPO, run gpupdate /force on machines or wait for the next Group Policy refresh cycle (typically 90 minutes).