Computer accounts: Machine passwords, join permissions, ownership, and secure channel maintenance

1. Core mechanism

A computer account lives in two places: an object in Active Directory (objectClass=computer, sAMAccountName ending with '$, e.g. WS-A7$) and a machine secret (LSA secret) stored locally on the member machine. These two nodes map to the member-initiated Netlogon secure channel. The limit of the lesson is 'machine password and state of secure channel': Kerberos ticket flow detail remains in 06.xx lessons, SPN ownership remains in 08.04, password policy mechanics remain in 08.02. The focus here is on how the machine carries its identity and where the health of that identity is seen.

Interfaces and specifications

• computer object: objectClass=computer; sAMAccountName ends with '<host>$; Each domain member has an account and password.
• userAccountControl: WORKSTATION_TRUST_ACCOUNT 0x1000 (workstation/member server), SERVER_TRUST_ACCOUNT 0x2000 (domain controller) — distinguishes the type of account.
• machine password: the local secret stored by the member must be the same as the password of the account in AD; Netlogon secure channel relies on this matching.
• Netlogon secure channel: It is established between the member and the DC via the MS-NRPC RPC interface (\PIPE\NETLOGON named pipe, ncacn_ip_tcp dynamic endpoint, Netlogon SSP).
• Maximum machine account password age: default 30 days, allowed range 1-999; The member initiates the change, DC does not force it.
• ms-DS-MachineAccountQuota: number of accounts an authenticated user can create, default 10.
• Kerberos clock skew constrains ticket/authenticator validation; the default allowance is five minutes. It is a separate check from Netlogon secure-channel credential verification.
• audit trail: 4741 (account created) and 4742 (account changed) are produced only on DCs, in the Audit Computer Account Management subcategory.

What does the machine account solve: the device's own identity

A user enters the domain with his password; So what kind of identity does the device itself carry against the domain? The answer is computer account. Each workstation and member server joining the domain receives an account with a name ending in '$' (WS-A7$) and a machine password for this account. In Microsoft's words, 'every device has an account and password'. This password is not a password written by a human; produced by machine, stored and regularly renewed.

The function of the machine password is to feed the secure channel between the member and the domain controller. Netlogon secure channel is the channel in which the member tells the DC 'I really am this account' and the DC carries out operations such as group memberships, trust verification and password change. The shared secret of the channel is the machine password: as long as the secret held locally by the member and the password of the account in AD are the same, the channel can be established.

Therefore, computer account is not just an 'inventory record'. He is a security principal; It has its own SID, its own password, and its own userAccountControl flags. The WORKSTATION_TRUST_ACCOUNT (0x1000) bit for workstations and member servers and the SERVER_TRUST_ACCOUNT (0x2000) bit for domain controllers determine the role of the account. We will be monitoring a single account, WS-A7$, throughout the course.

Password lifecycle: who changes it, when

The most misunderstood aspect of the machine password is who initiates the change. The 'Maximum machine account password age' policy defaults to 30 days (allowed range 1-999 days). But this is not an expiration date enforcement: the member machine changes the password via its Netlogon service. DC does not unilaterally reset the password because it 'expired'; The change request comes from the member and DC processes it over the secure channel.

Windows machines retain current and previous machine-password history. If the peer has not received a change, the previous value can help communication continue. This is not a fixed short grace window or a guarantee that both peers accept both values simultaneously. During diagnosis, verify the member’s local-secret version, the directory account at the contacted DC and DC replication separately.

A machine account can also use Kerberos, but that is a different authentication path from the Netlogon secure channel. On the Netlogon RPC path, both ends verify credentials based on shared machine-account password information; a session key then protects further RPC communication. The Kerberos path applies ticket and authenticator time checks. Clock skew can cause a Kerberos rejection without proving that the Netlogon channel or machine password is broken.

Who created the account: join authority and ownership

Before a machine can join the domain, its computer account must be created. There are two ways to do this: an administrator account pre-creates the object (delegated, controlled model), or the participating user account creates the object itself within the ms-DS-MachineAccountQuota quota. This quota is 10 by default: any authenticated user can create up to 10 computer accounts, even if no separate authorization is granted.

Ownership matters, but do not assume that the account which created a computer object is its owner. Verify the creator/owner position and the object's actual security descriptor separately: Microsoft notes that an object's creator or owner can set its ACL independently of permissions inherited from the parent. Review domain-join/create delegation together with the resulting object's owner and DACL; creating a computer account alone does not grant local administrator rights on that computer.

Event 4741 records computer-account creation; many computer-object changes produce4742. These events are collected on DCs under Audit Computer Account Management. Event 4742 is not an exhaustive record of every change: Microsoft documents exceptions such as some changes through ADUC’s Managed By tab. A DACL change can produce4742 with Changed Attributes remaining “-”. Event absence does not prove the object was unchanged.

Directory change and secure channel health are not the same thing

The core distinction of the course is this: the change of a computer object in AD and the operation of that machine's secure channel are two separate facts. 4742 tells you that an attribute of the object held in the DC has changed; does not prove that the machine's local secret and the password in AD still match. Conversely, the health of the secure channel is largely determined on the member side (local secret and Netlogon RPC reachability), and a DC-side directory event does not measure this directly.

For example, an administrator changes the DACL of a computer object: 4742 is generated, but the 'Changed Attributes' fields may all be '-' because the DACL change is not listed separately. Likewise, when an SPN is added, the ServicePrincipalNames field is filled. These signals tell about the change; but it doesn't answer the question 'can this machine talk to DC now?'

The practical consequence of this distinction: directory events and secure channel status must be read together when diagnosing a malfunction related to machine identity. The channel may be broken (the local secret has shifted) while the object appears 'correct', or the channel may be fine while the object has just changed. In the Artifact section we will show exactly which areas of these two worlds we can read.

State and data flow

1. Join: WS-A7$ computer account is created (administrator in advance or within user quota); The first machine password is set.
2. The member stores the machine secret locally (LSA secret); This secret matches the password of the account in AD.
3. Netlogon secure channel: the member establishes a secure channel with the DC using the machine password as proof.
4. Maintenance: default ~ every 30 days, the member initiates a password change via their Netlogon service.
5. Rollover boundary: previous password history may help when a change has not reached the peer; verify secret versions at both ends and DC replication separately. This alone does not establish channel health.
6. Evidence: In DC, object change is recorded as 4741/4742; however, this does not measure channel health on the member side.
7. Investigate the failure paths separately: Netlogon credential verification depends on shared machine-account password information; Kerberos ticket authentication can fail on clock skew. A failure on one path does not establish failure on the other.

2. Exploitation

Broken trust assumption

Reliable assumption: 'computer account is an ordinary inventory record, creating it or changing its attributes is not a privilege.' Where it breaks: the machine password and certain attributes of the computer object (such as delegation, SPN, msDS-KeyCredentialLink) are directly tied to the identity and secure channel; Whoever creates the object or has writing rights has a say in the identity of that machine.

Technical prerequisites

• The default ms-DS-MachineAccountQuota of 10 is one account-creation path; explicit container/OU delegation can also authorize creation. Do not assume the computer-object creator is automatically its owner; inspect the effective owner and DACL.
• A principal has write rights (e.g. GenericWrite/GenericAll) or owner status on the target computer object.
• The changed attribute is related to the identity: e.g. delegation flags/attributes (08.04) or password-related fields.
• None of these conditions alone means 'the domain has been taken over'; the scope is limited by the target's privilege and inhibitory controls.

Exploitation mechanism

Since the computer account is a security principal, write rights on it are available to change the behavior of that identity. The owner, or a principal with writing rights, can manipulate the target machine's identity in its favor by changing the delegation relationships or authentication-related attributes of the target machine. This is not to say 'every write right is automatic disaster': the impact depends on the access the target machine has, the version and the blocking controls in place. The delegation specific detail of the mechanism here links to the 08.04 and 06.xx lessons; The emphasis is on evaluating account-creation authority separately from the object's actual owner and DACL. Writing to the object does not establish local administrator access to the device.

Quota + ownership: the door that silently opens

The default MachineAccountQuota value of 10 allows an authenticated user to create an account without separate object-creation delegation in some configurations. But do not infer that every creator automatically becomes owner: verify the actual owner and DACL on the object. Because an object's creator or owner can affect its ACL, manage the creation permission and resulting security descriptor together.

This is not an attack by itself; it is a condition and an authorization boundary. If a principal can create an object or has write/owner rights on an existing computer object, identity behavior may be affected only to the extent allowed by the target attribute and ACL. The actual owner/DACL, changed attribute, and trust relationship determine impact—not merely the existence of a computer account or the creator's identity.

Boundary and inhibitory control

The scope limit is clear: control over a computer object does not automatically grant the entire domain. Influence is surrounded by the resources that machine has access to and the controls in place. Setting MachineAccountQuota to 0 or delegating account creation only to certain admin groups closes the door in the first place.

The second preventive control is tightening write rights on computer objects and checking owners. Answering the question of who created which machine and who can write it is possible with the audit trail discussed in the Blue section of this course.

3. Defense & Detection

Telemetry scope

• When the Audit Computer Account Management subcategory is enabled, events 4741 (creation) and 4742 (change) are generated.
• These events occur only on domain controllers; It is not searched on member machines.
• Event 4742 records many computer-object changes, with documented exceptions. A DACL change can produce4742 while all Changed Attributes are “-”. Verify both audit/collection coverage and which changes the event represents; event absence does not establish no change occurred.
• If a user-specific attribute on a computer account is manually changed, the account reverts to NORMAL_USER_ACCOUNT and 4738 (user account changed) appears instead of 4742.
• Secure channel health is evaluated not by a DC-side audit event, but by the Netlogon status and associated operational evidence on the member side.

Events and relevant fields

• 4741 — A computer account was created (new computer object; SubjectUserSid creating principal).
• 4742 — A computer account was changed (attribute change; ServicePrincipalNames, DnsHostName, OldUacValue/NewUacValue, PasswordLastSet fields).
• 4738 — A user account was changed (you see this instead of 4742 when a computer object is forced to the user-type attribute).
• TimeCreated (System) — time context of the event with DC clock; It is not a machine password or proof of channel health.

What you see, what you don't see

4742 is a powerful directory signal, but it is limited: immutable attributes are preceded by '-', the DACL substitution is not listed as a separate field, and the event is generated only on the DC. In other words, it gives the information 'this computer object has changed'; It does not provide the information 'this machine can establish a secure channel with DC'. Maintaining this distinction when making a diagnosis prevents misdirection.

The time context comes from the System/TimeCreated field of the event; this tells you when the change was committed relative to DC time. It does not prove when the machine password was reset or that the local secret is still valid. Keeping these two questions separate is also the purpose of the artifact section.

verification path

After performing a hardening (e.g., reducing the quota to 0), verification is done by ensuring that attempts to create new computer accounts are successful as expected only by authorized groups; The SubjectUserSid distribution of 4741 events demonstrates this. The change must be reversible: quota and delegation settings are documented and phased in.

On the secure channel side, authentication is done in the context of the member machine; Since this course focuses on directory evidence, we would like to point out that channel health is measured by separate tools on the member side. It is wrong to synchronize the Directory event and the channel state in a single panel.

Detection logic · XPath

<QueryList>
  <Query Id="0" Path="Security">
    <!-- Bu XPath yalnız yerel Security kanalındaki 4742 olaylarını seçer; -->
    <!-- ServicePrincipalNames alanı '-' olmayan (yani SPN'i değişen) computer -->
    <!-- account değişikliklerini daraltır. Çok-host korelasyonu YAPMAZ. -->
    <Select Path="Security">
      *[System[(EventID=4742)]]
      and
      *[EventData[Data[@Name='ServicePrincipalNames'] and (Data[@Name='ServicePrincipalNames'] != '-')]]
    </Select>
  </Query>
</QueryList>

Query assumptions

• Source: local Security channel of a domain controller; Audit Computer Account Management must be open.
• XPath only selects fields from a single event document; does not correlate across multiple DCs or time windows.
• If the field does not exist (e.g., EventData does not contain ServicePrincipalNames), the condition will not match; The missing area is silently left out.

False positives

• Legitimate SPN maintenance (new service registration, host rename) produces the same 4742/ServicePrincipalNames projection; benign baseline required.
• During bulk client onboarding periods, 4741/4742 volume naturally increases; The alarm threshold must be adjusted according to the context.
• Forcing a computer account to the user-type attribute shifts the event to 4738; If only 4742 is dialed, this situation will be missed.

Hardening

• Reduce ms-DS-MachineAccountQuota to 0 and delegate the authority to join the domain only to specified administrator groups; Verify the change through the inventory and approval process.
• Regularly review write rights and owners on computer objects; Fix unexpected owners.
• Determine the maximum machine account password age according to corporate need; unnecessarily turning off password change — turning it off leaves an immutable machine secret that does not refresh.
• Monitor time synchronization and clock-skew tolerance for Kerberos; assess Netlogon separately using its RPC/credential evidence. A clock-related Kerberos rejection alone is not proof of a machine-password failure.
• Keep Audit Computer Account Management enabled on DCs; Establish a meaningful baseline by normalizing the 4741/4742 volume on the SIEM side.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}"/><EventID>4742</EventID><Version>0</Version><Level>0</Level><Task>13825</Task><Opcode>0</Opcode><Keywords>0x8020000000000000</Keywords><TimeCreated SystemTime="2026-09-29T06:12:44.918273400Z"/><EventRecordID>884213</EventRecordID><Correlation/><Execution ProcessID="720" ThreadID="4188"/><Channel>Security</Channel><Computer>DC01.outreason.example</Computer><Security/></System><EventData><Data Name="TargetUserName">WS-A7$</Data><Data Name="TargetDomainName">OUTREASON</Data><Data Name="TargetSid">S-1-5-21-1109110911-2202220222-3303330333-6218</Data><Data Name="SubjectUserSid">S-1-5-21-1109110911-2202220222-3303330333-6218</Data><Data Name="SubjectUserName">WS-A7$</Data><Data Name="SubjectDomainName">OUTREASON</Data><Data Name="SubjectLogonId">0x3e7</Data><Data Name="PrivilegeList">-</Data><Data Name="SamAccountName">-</Data><Data Name="DisplayName">-</Data><Data Name="UserPrincipalName">-</Data><Data Name="PasswordLastSet">-</Data><Data Name="AccountExpires">-</Data><Data Name="PrimaryGroupId">-</Data><Data Name="AllowedToDelegateTo">-</Data><Data Name="UserAccountControl">-</Data><Data Name="DnsHostName">ws-a7.outreason.example</Data><Data Name="ServicePrincipalNames">HOST/ws-a7.outreason.example	HOST/WS-A7</Data></EventData></Event>

Two reality checks

Assumption: The domain controller automatically resets the machine password when it expires.

In fact: The member machine initiates the machine password change via its own Netlogon service; 'Maximum machine account password age' (default 30 days) is an upper limit, not a DC enforced hard-reset. A member who remains offline for a long time may not have changed their password, and this alone does not invalidate the account.

Assumption: Seeing event 4742 proves that the secure channel of that machine is healthy.

In fact: 4742 only saves a change of the computer object held in the DC; It does not indicate that the member's local secret and AD password still match. Channel health is largely determined on the member side (local secret, time, network); The directory event does not measure this.

Sources

• Microsoft · Domain member: Maximum machine account password age
  Every device has an account and password; domain members send a password change every 30 days by default; range 1-999.
• Microsoft Open Specifications · [MS-NRPC]: Netlogon Remote Protocol
  Overview and Section 2.1 Transport: \PIPE\NETLOGON named pipe, ncacn_ip_tcp dynamic endpoint, Netlogon SSP (secure channel carrier).
• Microsoft · Maximum tolerance for computer clock synchronization
  Kerberos V5 client-DC clock skew tolerance; default 5 minutes; replay protection.
• Microsoft · 4742(S) A computer account was changed
  Event XML (Version 0); DCs only; Audit Computer Account Management; fields ServicePrincipalNames, DnsHostName, OldUacValue/NewUacValue, PasswordLastSet; unchanged fields are '-'; user-type changes move to 4738.
• Microsoft · 4741(S) A computer account was created
  DCs only; Audit Computer Account Management; SubjectUserSid, SamAccountName, PrimaryGroupId 515, NewUacValue, ServicePrincipalNames.
• Microsoft · UserAccountControl property flags
  userAccountControl bit values including WORKSTATION_TRUST_ACCOUNT 0x1000 and SERVER_TRUST_ACCOUNT 0x2000.
• Microsoft · Default limit to number of workstations a user can join to the domain (MachineAccountQuota)
  ms-DS-MachineAccountQuota default 10; every authenticated user can create up to 10 computer accounts.
• Microsoft · Active Directory domain join permissions
  Quota-managed Add workstations to domain and explicit Create Computer Objects permission on an OU/container are distinct domain-join authorization paths.
• Microsoft · Delegating Administration of Account OUs and Resource OUs
  An object's creator or owner can set its ACL independently of inherited parent permissions; control of an account object is not local-computer administrator authority.
• Microsoft Open Specifications · [MS-NRPC] Netlogon Common Authentication Details
  §3.1: mutual Netlogon credential verification from shared machine-password information and a session key for subsequent RPC.