Active Directory Vulnerability Assessment with Purple Knight: Domain Controller Owner Is Not an Administrator

The Hidden Backdoor: Auditing Domain Controller Ownership with Purple Knight. In today’s threat landscape, Active Directory (AD) remains one of the most critical and most targeted components of enterprise infrastructure. In this guide, we shall discuss “Active Directory Vulnerability Assessment with Purple Knight: Domain Controller Owner Is Not an Administrator”. Please see Set Special File Permissions with SUID or GUID and Sticky Bit, and how to run Apps as an administrator on Windows.

As the backbone of identity and access management in Windows environments. A compromised AD environment can mean full organizational takeover in a matter of minutes. Yet despite its central role, many organizations still overlook subtle but dangerous misconfigurations that quietly undermine their security posture.

Also see, How to Install all Editions of Microsoft SQL Server 2025, how to troubleshoot Active Directory Replication issues, and how to fix unable to contact Server: This may be the server does not exist.

Purple Knight

This is where tools like Purple Knight become indispensable. Developed by Semperis, Purple Knight is a free Active Directory security assessment tool. It is designed to surface indicators of exposure (IoEs) and indicators of compromise (IoCs) that traditional security scanners often miss. By running targeted queries against AD objects, permissions, and relationships. Purple Knight provides defenders with actionable intelligence grounded in the real-world tactics used by threat actors.

Among the many findings Purple Knight can surface, one stands out for its insidious nature and its potential for privilege escalation. The Domain Controller (DC) object being owned by a non-Administrator principal.

At first glance, this may appear to be a benign misconfiguration . Perhaps the result of an automated provisioning process, a legacy script, or an overlooked delegation. In practice, however, it represents a hidden attack path that a skilled adversary can exploit to gain persistent. Stealthy control over the most sensitive machines in the domain.

In this article, we will walk through what this finding means. Why it matters, how Purple Knight detects it, and most importantly how to remediate it before it becomes a liability. Whether you are a security engineer performing a routine AD audit or a blue teamer looking to harden your environment against advanced persistent threats, understanding object ownership in Active Directory is not optional. It is foundational.

Please see AGMP extended support ends April 2026: Find alternative solution, Steps to customize Windows PE boot images, and Tape Backup Troubleshooting in Veeam: Real Cases.

Request and Procedure: Domain Controller owner is not an Administrator

During the Active Directory assessment. It was identified that 8 Domain Controllers have an object “owner” that does not belong to the standard Tier-0 groups (Domain Admins, Enterprise Admins, or Administrators).

In certain instances, the Domain Controllers report even indicates “Could not read owner,“. Which is a significant anomaly in its own right.

Why this is a risk?

The owner of an AD object has inherent rights that bypass standard security settings:

• Permission Modification: An owner can always modify the object’s ACLs (Access Control Lists). Even if the current ACLs do not explicitly grant them permission.
• Privilege Escalation: They can grant themselves additional privileges at any time.
• Domain Compromise: This creates potential escalation paths that could lead to the compromise of the entire domain.

If a Domain Controller has an invalid owner, an attacker could obtain elevated privileges without being a member of administrative groups, directly compromising Tier-0 assets. This specific condition is explicitly flagged as critical by ANSSI in the document “Dangerous ACLs expose domain controller objects.”

Required Action for the AD Team

We kindly request that you verify and correct the ownership of the listed Domain Controllers, reverting them to their default administrative values.

Affected Domain Controllers

AzureADKerberos
XXX-XXX-ADDC-01
XXX-XXX-ADDC-02
XXX-XXX-ADDC-03
XXX-XXX-ADDC-04
XXX-XXX-ADDC-05
XXX-XXX-ADDC-06
XXX-XXX-ADDC-07
XXX-XXX-ADDC-08

Verify the current owner of each DC

Run the following PowerShell command on a privileged (Tier 0) workstation:

Get-ADComputer YOUR-DC-NAME -Properties * | Select Name, DistinguishedName, Owner
Get-ADComputer XXX-XXX-ADDC-02 -Properties * | Select Name, DistinguishedName, Owner
Get-ADComputer XXX-XXX-ADDC-03 -Properties * | Select Name, DistinguishedName, Owner
Get-ADComputer XXX-XXX-ADDC-04 -Properties * | Select Name, DistinguishedName, Owner
Get-ADComputer XXX-XXX-ADDC-05 -Properties * | Select Name, DistinguishedName, Owner
Get-ADComputer XXX-XXX-ADDC-06 -Properties * | Select Name, DistinguishedName, Owner
Get-ADComputer XXX-XXX-ADDC-07 -Properties * | Select Name, DistinguishedName, Owner
Get-ADComputer XXX-XXX-ADDC-08 -Properties * | Select Name, DistinguishedName, Owner

If the Owner is not one of the following:

• Domain Admins
• Enterprise Admins
• Administrators (Built-in)
• NT AUTHORITY\SYSTEM
• Check

“This PowerShell script is a security auditing tool focused on Domain Controllers (DCs). In short, it is used to identify the Owner of the computer objects that represent your Active Directory servers.

Why is this command important? In a secure Active Directory environment, the owner of the Domain Controllers should typically be the Domain Admins or Enterprise Admins group.

If the owner turns out to be a specific user or an unauthorized group, that individual would have the inherent right to modify permissions on the Domain Controller itself, representing a serious security risk (privilege escalation).”

$DCs = @(
“XXX-XXX-ADDC-01”,
“XXX-XXX-ADDC-02”,
“XXX-XXX-ADDC-01”,
“XXX-XXX-ADDC-02”,
“XXX-XXX-ADDC-01”,
“XXX-XXX-ADDC-02”,
“XXX-XXX-ADDC-01”,
“XXX-XXX-ADDC-02”
)

foreach ($dc in $DCs) {
$obj = Get-ADComputer -Identity $dc
$acl = Get-ACL -Path (“AD:\” + $obj.DistinguishedName)
[PSCustomObject]@{
Computer = $dc
Owner = $acl.Owner
}
}

I have extracted the owner of the Domain Controller computer objects via PowerShell. And they are assigned to the ‘Domain Admins’ group.

Please see [World Backup Day] V13 Upgrade Failure: Veeam Configuration Backup Saved the Day, and Fix unable to contact Server: This may be the server does not exist.

Verifying ownership using the GUI (Example):

Right-click on the Domain Controller computer object > Properties > Security > Advanced

Owner → “Could not read owner”
Ignored → False

This could mean that Purple Knight was unable to read the AD object’s ACL (specifically the nTSecurityDescriptor field).

Performing this read operation requires specific privileges that are not granted to all user accounts.

Technical Note for your report:

In an Active Directory context, if a tool like Purple Knight or PingCastle returns “Could not read owner,”. It usually suggests that the account used to run the scan lacks the Read Permissions (READ_CONTROL) right on those specific Tier-0 objects. Or that the objects have explicitly restricted permissions that block standard domain users from viewing the security descriptor.

I hope you found this guide on “Active Directory Vulnerability Assessment with Purple Knight: Domain Controller Owner Is Not an Administrator” very useful. Please feel free to leave a comment below.