Password resets are a common first move after a suspected account compromise. They are fast, familiar, and often necessary. But in an Active Directory environment, changing a password should not be treated as proof that an attacker has been removed.
That distinction matters during incident response. Active Directory and hybrid Entra ID environments can keep authentication material alive in more than one place. Cached credentials, active Kerberos tickets, service accounts, and directory permissions can all give an attacker ways to continue operating after a reset.
A password change may close one route back in. It does not automatically clear every session, invalidate every ticket, rotate every privileged credential, or undo every permission change made during the intrusion.
For security architects, identity teams, and IT administrators, the practical question is not whether password resets are useful. They are. The question is what else has to happen before the organization can reasonably say the attacker’s access has been cut off.
The Password Reset Gap
In Active Directory, password state is not always updated everywhere at the same moment. Windows systems can store cached credential material locally so users can sign in when a device is offline or temporarily unable to reach a domain controller. Hybrid environments add another timing issue: password changes made in AD may take a short period to synchronize to Entra ID.
That creates several states after a reset:
- The user signs in with the new password while connected to the domain, allowing the local cached credential store to update.
- The user has not signed in to a specific machine since the reset, so older cached credential material may still exist on that endpoint.
- In a hybrid deployment, the reset has occurred in Active Directory but has not yet fully synchronized to Entra ID.
The synchronization window is usually short, but incident responders should avoid assuming that “short” means “irrelevant.” If an attacker already collected hashes, tickets, tokens, or privileged access, the password reset may only affect part of the attacker’s working set.
That is why a reset should be treated as the beginning of containment, not the end of it.
Cached Credentials Can Keep Old Access Useful
Cached credentials are meant to support legitimate users, especially laptop users and remote workers who may not always have domain connectivity. The same design can complicate breach response.
If credential material was captured before the reset, changing the password may not immediately invalidate it in every location where it can be abused. This is especially relevant in scenarios involving pass-the-hash techniques, where the attacker uses a password hash rather than the plaintext password.
The risk is not that every cached credential automatically gives an attacker unlimited access. The risk is that defenders may believe the reset has closed the door when some endpoints or authentication paths have not yet caught up.
Endpoint state matters. A corporate laptop that has not reconnected, a remote device that has not received updated policy, or a machine where an attacker already has local access may still deserve separate review.
Security teams should include cached credential exposure in their containment checklist. That may mean forcing reconnection, clearing cached material where appropriate, validating endpoint health, and confirming that affected users have signed in under the new credential state.
Yubico Security Key C NFC
For privileged or recently recovered accounts, a FIDO2 security key can reduce dependence on passwords alone. It does not clear Kerberos tickets or rotate service credentials, but it can strengthen the account after containment work is complete.
As an Amazon Associate I earn from qualifying purchases.
Active Sessions and Kerberos Tickets Need Separate Handling
Password authentication is only one part of how access works in an AD environment. Kerberos relies on tickets that remain valid for a configured period. Once a user or attacker has a valid ticket, they may be able to continue accessing resources without immediately presenting the new password.
That means an attacker with an active session may remain authenticated after the password changes, at least until the relevant ticket or session expires or is explicitly cleared. In a real incident, that window can be enough time to move laterally, collect more credentials, or set up another path back into the environment.
Responders should look beyond the account object and ask what is already in circulation:
- Which hosts has the account accessed recently?
- Are there active sessions on servers, workstations, VPN gateways, or administrative tools?
- Are Kerberos tickets still valid on affected systems?
- Has the user been forced to sign out everywhere practical?
- Have high-risk endpoints been rebooted or otherwise cleared of active authentication material?
For many compromises, forcing logoff, rebooting affected systems, and purging tickets are more meaningful than another password reset. The goal is to remove currently valid access, not only prevent the next password-based login.
Service Accounts Are Often the Harder Problem
User passwords tend to get attention during an incident. Service accounts often move more slowly because they are tied to applications, scheduled tasks, scripts, databases, and infrastructure services.
That operational dependency makes service accounts attractive to attackers. They may have broad privileges, old passwords, weak monitoring, and business owners who are hesitant to rotate them because a failed change can break production systems.
If attackers discover a service account during lateral movement, a user password reset may do little to limit their options. The compromised user may be contained while the attacker continues using a separate credential with more durable access.
Incident response should identify service accounts touched by the compromised user, exposed on affected hosts, or visible in logs around the time of suspicious activity. High-privilege service accounts deserve special attention because they can become fallback access even after normal user credentials are locked down.
Practical response steps include:
- Inventorying service accounts with elevated privileges.
- Checking where those accounts are used before rotation.
- Prioritizing accounts found on compromised systems.
- Rotating passwords in a controlled order to reduce outage risk.
- Moving long-lived service credentials toward managed service accounts where appropriate.
A password reset plan that ignores service accounts is incomplete in most serious AD investigations.
Forged Tickets Can Bypass Password Changes
Kerberos ticket attacks create another problem. If an attacker can forge valid tickets, they may not need the current password for the account they appear to be using.
Golden Ticket attacks are associated with compromise of the KRBTGT account, which is central to the domain’s Kerberos trust model. Silver Ticket attacks are narrower and target access to specific services. In both cases, the defender’s problem is larger than a single user password.
Resetting an individual user password will not reliably invalidate forged tickets if the underlying Kerberos compromise remains unresolved. In severe domain compromise scenarios, responders may need to reset the KRBTGT account twice, following a careful process to avoid disrupting legitimate authentication.
This is not a routine help desk step. It belongs in a controlled incident response plan with awareness of domain controllers, replication, service dependencies, and ticket lifetimes.
Directory Permissions Can Preserve the Backdoor
Active Directory is permission-heavy. Access Control Lists determine who can reset passwords, modify groups, change object attributes, delegate rights, and control sensitive parts of the directory.
If an attacker changes permissions during the intrusion, the original compromised password may become almost irrelevant. They may grant a controlled account the right to reset other users’ passwords, add members to privileged groups, or maintain control through delegated access that looks ordinary at a glance.
AdminSDHolder is one area that deserves attention in privileged-account investigations. Accounts protected by AdminSDHolder can inherit permissions from a protected template, and changes there can be reapplied by SDProp. If an attacker tampers with those permissions, access may come back even after responders clean up the obvious account.
Teams should review directory changes around the suspected compromise window, including:
- New or modified privileged group memberships.
- Unexpected delegated rights on organizational units.
- Changes to AdminSDHolder permissions.
- New accounts with unusual privileges.
- Password reset rights granted to unexpected users or groups.
- Suspicious changes to service principal names.
The key is to look for ways access could be re-established without knowing the new password.
What Full Containment Should Include
A strong response starts by resetting the affected password, but it should continue through session control, credential rotation, endpoint review, and directory auditing.
A practical containment checklist should include:
- Reset the compromised user password and require a new sign-in.
- Terminate active sessions where supported by the platform or application.
- Force logoff or reboot affected endpoints and servers when appropriate.
- Purge Kerberos tickets on systems tied to the compromise.
- Review recent logons, lateral movement, and administrative activity.
- Rotate exposed service account credentials, starting with privileged accounts.
- Check privileged group membership and delegated permissions.
- Review AdminSDHolder and other sensitive ACLs.
- Validate hybrid identity synchronization status where Entra ID is involved.
- Confirm that endpoint controls and logs show no continued attacker activity.
For serious breaches, the answer is rarely one action. Eviction usually depends on several coordinated steps that remove both current access and future re-entry paths.
Where Password Reset Tools Fit
Self-service password reset tools can help reduce response time and support safer user recovery, especially when they include strong identity verification and clear audit trails. In environments with remote users, tools that update local cached credential state on the device where the reset occurs may also reduce one specific exposure window.
Those capabilities should be evaluated carefully. Buyers should ask how a product handles user verification, cached credentials, endpoint connectivity, audit logging, help desk workflows, and hybrid AD-Entra ID synchronization. They should also ask what the tool does not do, because password reset tooling is not a substitute for session invalidation, service account rotation, or AD permission review.
The useful way to frame these products is as part of identity incident response, not as a complete breach-removal mechanism.
The Bottom Line
Changing a password is necessary in many Active Directory incidents, but it is not proof that the attacker is gone. Cached credentials may still exist on endpoints. Kerberos tickets and active sessions may remain valid for a time. Service accounts may provide another route. Directory permissions may preserve access even after the original credential is no longer useful.
A better response treats the password reset as one containment action among several. Cut off active sessions, clear tickets, rotate exposed credentials, inspect privileged access, and verify that no hidden directory changes remain.
That is the difference between changing the lock and confirming the intruder no longer has another way inside.