krbtgt Password Rotation, Trust Account, Domain Controller Machine Password: The Three AD Secrets That Never Rotate Themselves

Active Directory looks like a system that keeps its own secrets fresh. Domain-joined computers change their passwords on a schedule, trusts renew themselves in the background, and nobody ever gets a ticket about it. That impression is exactly why krbtgt password rotation, trust account, domain controller machine password hygiene is the quietest gap in most AD estates: one of those three secrets has no automatic rotation at all, and the other two rotate only for as long as nothing is silently broken. This article covers what each mechanism actually does, how to check all three in a few minutes, and how to fix them without causing a domain-wide authentication outage.

krbtgt Password Rotation, Trust Account, Domain Controller Machine Password: Who Rotates What

The trap is a perfectly reasonable inference. Microsoft's policy documentation states that "in Active Directory-based domains, each device has an account and password. By default, the domain members submit a password change every 30 days" (Domain member: Maximum machine account password age). Machines really do maintain themselves, so administrators generalise: the directory handles its own secrets.

Two of the three above are indeed automatic. But automatic here means automatic while everything is healthy, and the single most valuable secret in the domain was never automatic in the first place.

krbtgt: The Password Active Directory Never Changes for You

The krbtgt account is where the domain's Kerberos key material lives — every TGT in the domain is encrypted and signed with its key. Microsoft describes the account in exactly those terms: it "supports key storage in all Kerberos Key Distribution Centers (KDCs)", and "[t]o renew the Kerberos keys for TGT encryption, periodically change the krbtgt account password" (Accounts security posture assessment). Nothing in the directory performs that change on your behalf: there is no Netlogon timer and no policy setting behind it, only an administrator running the reset by hand.

That is the whole problem. With no rotation, the blast radius of a single historic copy of the account database never shrinks, and Microsoft spells out the consequence: "If the KRBTGT account's password is compromised, an attacker can use its hash to generate valid Kerberos authentication tickets, allowing them to perform Golden Ticket attacks and gain access to any resource in the AD domain. Since Kerberos relies on the KRBTGT password to sign all tickets, closely monitoring and regularly changing this password is essential to mitigating the risk of such attacks." Its own baseline puts a number on regularly: Defender for Identity ships a recommendation called Change password for krbtgt account, which "lists any krbtgt account within your environment with password last set over 180 days ago". Which algorithms those keys use is the other half of the story, covered in our guide to Kerberos RC4 fallback.

What an attacker does with that key is covered in depth in our Golden Ticket attack guide — this article is about the rotation hygiene that makes the forged ticket expire instead of living forever.

Trust Passwords: Automatic From One Side Only

Inter-domain trusts do rotate, and they do it without anyone asking. Microsoft's trust internals documentation describes the mechanism: "Both domains in a trust relationship share a password, which is stored in the TDO object in Active Directory. As part of the account maintenance process, every thirty days, the trusting domain controller changes the password stored in the TDO" (How Domain and Forest Trusts Work — an archived Windows Server 2003 document, still the most detailed public description of the process).

Three details from that document matter operationally:

• Only one side drives it. "A domain controller in the trusted domain never initiates the password change; it is always initiated by the trusting domain PDC emulator."
• The old password is deliberately kept. If authentication with the new password fails, the trusting domain controller "tries to authenticate using the old password", and if that succeeds it "resumes the password change process within 15 minutes" — which is why both the old and new values live in the TDO.
• Replication has a hard deadline. "Trust password updates need to replicate to the domain controllers of both sides of the trust within 30 days. If the trust password is changed after 30 days and a domain controller then only has the N-2 password, it cannot use the trust from the trusting side and cannot create a secure channel on the trusted side."

The secret itself is not a normal password attribute: Microsoft notes that trust secrets "are represented by special attributes on the interdomain trust accounts", trustAuthIncoming on the trusted side and trustAuthOutgoing on the trusting side, and that they "are maintained by the domain controller which is the primary domain controller (PDC) emulator Flexible Single Master Operation (FSMO) role in the trusting domain" (UserAccountControl property flags).

What you can read is the interdomain trust account that goes with the TDO. Per MS-ADTS, trusts whose trustDirection is inbound or bidirectional have an associated user account in the default users container, and the two objects are linked by the partner's NetBIOS name: the TDO's flatName equals the account's sAMAccountName minus the trailing $. ANSSI's checkpoint Trust account passwords unchanged for more than a year reads exactly that account's pwdLastSet, and its verdict is worth quoting: a stale value "may be indicative of deleted trust relationships while their corresponding trust accounts are still present", and where the trust is still live, "the cause for the lack of an automatic renewal should be investigated".

If you are auditing trusts more broadly, pair this with our trust attack paths and SID filtering and selective authentication audit articles.

Domain Controller Machine Passwords: Automatic Until Something Blocks Them

Domain controllers are domain members too, and their computer accounts rotate on the same Netlogon schedule as a workstation. Microsoft's KB 154501 states it plainly: "Starting with Windows 2000-based computers, the machine account password automatically changes every 30 days" (Disable machine account password changes). The policy that governs the interval allows a "user-defined number of days between 1 and 999", with an effective default of 30 days on domain controllers, member servers and clients alike.

A DC whose computer password has not moved in months is therefore not a policy choice — it is a signal. ANSSI's checkpoint Domain controllers with passwords unchanged for more than 45 days is unambiguous: "Some domain controllers have not changed their password for more than 45 days, indicating their secrets are not renewed", and "the reason for this change not to occur properly must be investigated as it may be indicative of a compromise."

The usual culprits are local to the machine:

• DisablePasswordChange set to 1 under HKLM\System\CurrentControlSet\Services\Netlogon\Parameters, which stops the machine from ever submitting a change — this is the one that freezes a domain controller's own secret.
• A MaximumPasswordAge value pushed far out, or a GPO quietly setting either value.
• The Netlogon service not running, or a secure channel that is already broken.

One registry value gets blamed here and does not belong. RefusePasswordChange set to 1 "causes the domain controller to refuse password change requests only from workstations or member servers that run Windows NT version 4.0 or later" — it freezes your members' computer passwords, not the DC's own. Check it when member objects stop rotating: with RefusePasswordChange, "the replication traffic will stop, but not the client traffic", whereas DisablePasswordChange stops both.

Microsoft's own warning about switching this off is worth repeating: "If you disable machine account password changes, there are security risks because the security channel is used for pass-through authentication. If someone discovers a password, he or she can potentially perform pass-through authentication to the domain controller." The policy documentation adds the other half: "Significantly increasing the password change interval (or disabling password changes) gives an attacker more time to undertake a brute-force password-guessing attack against one of the machine accounts."

A machine account secret is also service-ticket material for everything running on that host, which is the mechanism behind a Silver Ticket attack — and on a domain controller, anomalies around the computer object deserve the same scrutiny as an unexpected replication source, the trick used by DCShadow. For the wider machine-identity picture, see our computer objects attack surface breakdown.

Detection

Three queries, run from a domain-joined admin workstation with RSAT, cover the whole trio.

1. The krbtgt accounts, including the per-RODC ones:

Get-ADUser -Filter "SamAccountName -like 'krbtgt*'" -Properties PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet, Enabled

2. The interdomain trust accounts, resolved from the TDOs themselves:

Get-ADObject -Filter "objectClass -eq 'trustedDomain'" -Properties flatName, trustDirection |
    ForEach-Object {
        Get-ADUser -Identity ('{0}$' -f $_.flatName) -Properties PasswordLastSet -ErrorAction SilentlyContinue |
            Select-Object SamAccountName, PasswordLastSet
    }

The same accounts can be listed directly through the INTERDOMAIN_TRUST_ACCOUNT flag — decimal 2048, hexadecimal 0x0800 — using the LDAP_MATCHING_RULE_BIT_AND matching rule OID 1.2.840.113556.1.4.803 (Search Filter Syntax):

Get-ADUser -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=2048)" -Properties PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet

3. Every domain controller computer object:

Get-ADDomainController -Filter * | ForEach-Object {
    Get-ADComputer $_.ComputerObjectDN -Properties PasswordLastSet |
        Select-Object Name, PasswordLastSet
}

Read the output against these thresholds:

The matching event-log signals:

Event 4742 "generates only on domain controllers", which makes DC-side collection sufficient for this check. On a suspect machine, nltest /sc_query:<domain> returns ERROR_ACCESS_DENIED when the secure channel is broken (Broken trust relationship between a domain-joined device and its domain).

Remediation

🚨 Danger: Never run the two krbtgt resets back to back. The second reset before the first has fully replicated invalidates tickets across the domain and can take authentication down with it.

Rotate krbtgt, in stages

1. Verify replication first. The two-reset procedure only works if every domain controller has seen the first new password before the second one lands, so confirm replication is healthy before you start. repadmin /replsummary "identifies domain controllers that are failing inbound replication or outbound replication, and summarizes the results in a report".
2. Reset once, using the supported procedure in AD Forest Recovery - Reset the krbtgt password. The password you type is irrelevant: "the system generates a strong password automatically independent of the password that you specify".
3. Wait. Microsoft: "You should perform this operation twice. You must wait 10 hours between password resets. 10 hours are the default Maximum lifetime for user ticket and Maximum lifetime for service ticket policy settings, hence in a case where the Maximum lifetime period changes, the minimum waiting period between resets should be greater than the configured value." Treat 10 hours as a floor rather than a target: in a large or slow-replicating forest, leaving a full day between the two resets costs nothing.
4. Reset a second time. Both resets are required because "the password history value for the krbtgt account is 2, meaning it includes the two most recent passwords" — one reset leaves the previous key sitting in history and still usable. Microsoft: "By resetting the password twice you effectively clear any old passwords from the history, so there's no way another DC replicates with this DC by using an old password."
5. Put it on a calendar. Defender for Identity starts flagging the account at 180 days, which makes a twice-yearly rotation a defensible default. Whatever interval you choose, the rotation only exists if someone owns it.

Fix a stale trust password

1. Decide whether the trust still exists. Compare the trust accounts you found with the live TDOs. ANSSI's remediation for orphans is direct: "Some trust accounts may remain while their trust relationships have been removed. They should be deleted manually."
2. For a live trust, verify the secure channel before touching anything: netdom trust <TrustingDomain> /domain:<TrustedDomain> /verify — the /verify parameter "verifies the secure channel secrets for a specific trust relationship" (netdom trust).
3. Investigate before resetting. A trust password that has not moved in months means the trusting domain's PDC emulator could not complete the exchange — check connectivity to the partner, the health of the PDC emulator role, and TDO replication on both sides, remembering the N-2 rule above.
4. Reset the trust secret only in a change window, with credentials on both sides: netdom trust <TrustingDomain> /domain:<TrustedDomain> /userd:<TrustedDomain>\admin /passwordd:* /reset. The /reset parameter "resets the trust secret between trusted domains or between the domain controller (DC) and the workstation".

Get a domain controller rotating again

1. Confirm the service is running: sc.exe query netlogon.
2. Check the two Netlogon registry values under HKLM\System\CurrentControlSet\Services\Netlogon\Parameters — ANSSI's remediation expects DisablePasswordChange to be 0 or absent and MaximumPasswordAge to be 30, and tells you to confirm no GPO is overriding them.
3. Verify the machine password matches the directory: nltest /sc_verify:<NetBIOSDomainName> should return 0 0x0 NERR_Success.
4. If the DC is out of sync because it was restored from an older state, treat it as a secure-channel repair, not a rotation problem — Microsoft documents both directions of the mismatch (the device newer than AD, and AD newer than the device).

Rotation hygiene sits alongside the rest of your credential posture — weak policies, non-expiring passwords and cleartext storage are covered in Active Directory password security, and the three checks above slot straight into a broader Active Directory security audit.

How EtcSec Detects This

An EtcSec audit checks all three secrets in the same pass. ANSSI_R28_KRBTGT_NOT_ROTATED (Critical) reads pwdLastSet on every krbtgt account and flags domains past the 180-day mark. ANSSI_R42_TRUST_PASSWORD_OLD (High) resolves each trusted domain object to its interdomain trust account and reports passwords that stopped rotating — including the orphaned accounts left behind by deleted trusts. ANSSI_R43_DC_PASSWORD_OLD (High) and COMPUTER_PASSWORD_OLD compare every domain controller and member computer object against the 30-day Netlogon cadence, so a blocked secure channel surfaces as a finding instead of a support ticket six months later. GOLDEN_TICKET_RISK ties the krbtgt result back to what an attacker actually does with a key that never changes.

References

• Microsoft — AD Forest Recovery: Reset the krbtgt password
• Microsoft — Accounts security posture assessment (Defender for Identity)
• Microsoft — How Domain and Forest Trusts Work
• Microsoft — UserAccountControl property flags (KB 305144)
• Microsoft — Disable machine account password changes (KB 154501)
• Microsoft — Domain member: Maximum machine account password age
• Microsoft — MS-ADTS: Essential Attributes of Interdomain Trust Accounts
• Microsoft — 4742(S): A computer account was changed and 4724(S, F): An attempt was made to reset an account's password
• Microsoft (archived) — New-KrbtgtKeys.ps1, read-only since 8 March 2024
• ANSSI / CERT-FR — Points de controle Active Directory (CERTFR-2020-DUR-001), checkpoint collection at cert.ssi.gouv.fr/uploads/ad_checklist.html — checkpoints Trust account passwords unchanged for more than a year and Domain controllers with passwords unchanged for more than 45 days