What AD Validated DNS Hostname Rights Mean
AD validated DNS hostname rights govern a constrained update to dNSHostName on a directory object. An ACE containing the associated GUID is a reason to inspect a delegation. Before changing it, establish who receives the permission, whether its mask actually grants the validated write, whether it applies to the computer, and which provisioning operation needs it.
Microsoft identifies Validated-DNS-Host-Name by GUID 72e39547-7b18-11d1-adef-00c04fd8d5cd. The permission allows a DNS hostname consistent with the computer and domain naming constraints. It does not establish permission to edit a DNS zone or demonstrate that someone has redirected traffic.
The useful outcome of this review is a recorded decision: an approved delegation, a confirmed unnecessary grant to remove, or an unresolved collection or authorization question. A list of matching GUIDs alone cannot make that decision. Keep the computer object's identity, the ACE and the legitimate workflow together throughout the investigation.
How It Works: Validated Write Versus WriteProperty
MS-ADTS validated-write semantics distinguish ordinary RIGHT_DS_WRITE_PROPERTY access from validated writes. Ordinary property-write access permits values allowed by the attribute schema without the additional validated-write value checks. A validated-write ACE combines the RIGHT_DS_WRITE_PROPERTY_EXTENDED access-mask bit with an identifying GUID in ObjectType; an ACE without an ObjectType GUID can cover all validated writes on the object.
The GUID is also the schema identifier of the dNSHostName attribute. Consequently, the GUID alone cannot distinguish an ACE scoped to writing that property from one scoped to its validated-write operation. Interpret the mask and scope together.
For the validated path, MS-ADTS specifies the dNSHostName constraints: the object must be a computer or server, or a subclass; in AD DS, the hostname combines the current sAMAccountName without its trailing dollar sign with the domain naming context's DNS name or an allowed msDS-AllowedDNSSuffixes value. The requester must hold the validated-write right. Review these naming inputs when assessing the intended operation.
For the broader owner and DACL investigation, use the computer-object DACL and ownership review. This review focuses on the particular validated-write authorization. DNS zone transfers and dynamic-update configuration concern another surface; changing a computer-object ACE does not verify those zone settings.
Detection: Collect the Object and Review the Complete ACE
Step 1: Establish the collection boundary
Start with the affected DN and the intended computer population. Record the domain controller, collection time, credentials used for the read, search base and any excluded OUs. Reconcile the population with the administrator's intended scope. A successful read of one object establishes nothing about computers omitted from the inventory.
Use a Windows administrative workstation with the ActiveDirectory PowerShell module for object reads. The following documentation-based example uses the supported Identity, Server and Properties parameters of Get-ADObject, with illustrative values to replace for your environment:
Get-ADObject -Identity "CN=APP01,OU=Servers,DC=example,DC=com" -Server "dc01.example.com" -Properties objectClass,sAMAccountName,dNSHostName,nTSecurityDescriptor
Confirm the returned DN and class before interpreting the permissions. Retain the descriptor for detailed inspection, along with the account and hostname values. Do not label an unavailable descriptor an empty DACL. Record failed reads separately and repeat them with an authorized collection identity before drawing a coverage conclusion.
Step 2: Inventory the ACL
Microsoft's Dsacls reference documents displaying an object's ACEs by supplying its quoted DN without change switches. Run from an elevated Windows command prompt with directory read permissions:
dsacls "\\dc01.example.com\CN=APP01,OU=Servers,DC=example,DC=com"
This is a syntax example adapted to an illustrative computer DN, not an executed environment check. Inspect the complete permission entries, using the object's Security tab for detailed scope review when necessary. Record each trustee's SID and resolved identity, ACE type, access mask, ObjectType, inheritance source and applicability. Keep the original descriptor rather than retaining only a filtered display of the GUID.
Step 3: Resolve mask, trustee and inheritance
Microsoft's domain-join permissions guidance illustrates the DNS validated-write ACE with mask 0x00000008, named ACTRL_DS_SELF, and the DNS hostname GUID. That mask name is distinct from the trustee named SELF: a join account can receive the validated-write bit too. Check whether the relevant bit is present in the collected mask; a different or combined mask needs its own interpretation.
MS-ADTS Checking Access explains Principal Self, SID S-1-5-10: on a security-principal object, it represents that object's principal and is substituted with the object's SID during the access check. The DC evaluates the requester's security context, requested access and appropriate descriptor. Resolving a display name or seeing an allow ACE is not that complete evaluation.
Review group-based trustees against the actual joining or provisioning identity. Ask the workflow owner which identity performs each step and which machines it may manage. Do not treat a group named after deployment as proof that every member needs access to every computer.
Microsoft's inheritance rules distinguish inherited ACEs from inherit-only ACEs. An inherit-only entry does not apply to the object bearing it. Trace the source container and object-class scope; evaluate the entry as it appears on the target computer rather than assuming a parent entry has identical applicability everywhere.
Step 4: Keep expected, observed and unknown evidence separate
Use this worksheet for each affected computer. It is a review template, not a report of measured results:
| Review point | Expected | Observed evidence to retain | Unknown requiring follow-up |
|---|---|---|---|
| Collection | Every intended computer and its DACL were read | Scope, DC, time, successful reads and failures | Missing computers, access errors or absent descriptors |
| Trustee | An approved machine or provisioning identity | SID, resolved account and workflow owner | Unresolved SID or unexplained group access |
| Permission | The right required by the documented operation | Full mask and ObjectType together | GUID-only output or unreviewed property-write access |
| Applicability | Entry applies to the intended objects | ACE type, inheritance source, class scope, inherit-only state | Unclear inherited scope or other applicable ACEs |
| Business purpose | Join or provisioning requirement remains current | Runbook, account owner and approved target population | Retired service, unidentified operator or excessive scope |
| Decision | Retain justified access or remove a confirmed excess | Change record and functional validation | Authorization or operational test still pending |
Remediation: Review the Workflow, Then Change the Delegation
Step 1: Preserve the baseline and establish necessity
Save the original descriptor and the review worksheet. Agree on the required operation with the machine and provisioning owners before editing. Separate creation of a new computer account from reuse of an existing one. Microsoft's domain-join guidance includes DNS validated-write permission among the rights needed by the joining identity when reusing an account; the presence of that right can therefore be intentional.
For a retained exception, record the trustee SID, exact right, object population, inheritance source, purpose, owner and review date. Include the evidence supporting that decision and outstanding questions. An exception should explain why the delegation is needed on these computers, rather than merely say that the scanner reported it before.
Step 2: Remove or narrow the confirmed unnecessary entry
Use the object's Security tab to edit the specific unnecessary permission. If it is inherited, review and correct the source delegation with the OU owner, checking the other recipients before applying the change. Preserve permissions needed by the remaining workflow and verify the resulting ACE scope.
dsacls /R is documented to remove all ACEs for the specified trustee. It is unsuitable for removing only DNS validated-write access from a trustee that must retain other permissions. Do not substitute a whole-trustee removal for a reviewed ACE edit, or reset the object's entire security descriptor to make a finding disappear.
Step 3: Verify permissions and intended operation
Read the computer and its ACL again against the chosen DC. Compare the resulting descriptor with the baseline and document precisely which entry changed. Confirm that the reviewed trustee no longer has the unwanted effective authorization through another applicable entry. For inherited changes, sample the relevant recipient population and verify the intended object-class boundary.
Test the approved join or provisioning workflow on a representative test computer, with the actual delegated identity. Record which operation ran, whether it succeeded, and any directory errors. On a domain member, Microsoft's secure-channel test supplies an additional functional check, run locally in elevated Windows PowerShell:
Test-ComputerSecureChannel -Verbose
This checks the member's domain relationship; it does not establish that hostname provisioning works or that the ACL review is complete. Microsoft cautions that the cmdlet returns false positive errors on domain controllers. These commands were cited from documentation, not executed on a customer environment.
How EtcSec Detects This
The etc-collector check ACL_COMPUTER_WRITE_VALIDATED_DNS, reviewed at commit 15fc6399c215eabc415c370b762303cfcd7a353a, builds a case-insensitive set of collected computer DNs. It retains ACLEntry records whose ObjectType equals 72e39547-7b18-11d1-adef-00c04fd8d5cd and whose ObjectDN belongs to that set. Count represents distinct affected computers; when different, TotalInstances records the number of matching entries.
Detect() does not filter SELF or other trustees, test the validated-write mask, evaluate inherit-only applicability, or calculate effective rights. Its output is an inventory starting point for the review above. The detector's description mentions DNS spoofing and MITM, but the implemented predicate does not prove either outcome.
Collection also limits interpretation. The LDAP provider requests OWNER, GROUP and DACL with security-descriptor flags 0x07, without the SACL. It skips per-object errors and missing descriptors; network errors instead abort the core call and can trigger reconnect and retry. The parser retains allowed standard and object ACEs, preserving mask, inherited state and InheritOnly, while excluding denied ACEs. The detector does not use those distinctions to complete an authorization check.
GetComputers and its parser supply the DNs used for the join. An incomplete computer inventory leaves an incomplete detector scope. A zero result means no matching entries in the supplied data, not proof that all computers were read or no principal can modify the attribute. Broad validated-write entries without this specific GUID also fall outside the matching predicate. Reconcile collection failures and scope before accepting a zero, and record the authorization decision separately from the scanner count.
Explore the identity security pages that support this topic