Active Directory Issues: The Ones That Look Simple But Aren't

Active Directory Issues: The Ones That Look Simple But Aren't

The ticket says "user can't log in." You unlock the account. Twenty minutes later, the same ticket is back. The account is locked again. You unlock it a second time. Third ticket, same user, same issue.

At this point you know it is not a password problem. Something is locking the account repeatedly and the user has no idea what it is. Neither do you yet, but you know where to look.

Active Directory tickets have a specific quality that makes them harder than they appear: the symptom is almost never the cause. An account lockout is not caused by a locked account. A login failure is not always a credential problem. A group policy that stopped applying is not always a GPO issue. The surface symptom points you at the wrong layer if you follow it directly.

This post covers the four AD ticket types that consistently take longer than they should, and the diagnostic approach that gets to the real cause faster.

The Account Lockout That Keeps Coming Back

A one-time account lockout is usually a mistyped password. An account that locks repeatedly within the same day is a different problem entirely.

The cause is almost always one of three things: a device with cached credentials that are now wrong, a service or scheduled task running under the user's credentials, or a mapped network drive with saved credentials from an old password.

Step 1: Find what is causing the lockout

On your domain controller, open Event Viewer and filter the Security log for Event ID 4740. This event is generated every time an account is locked out and it includes the Caller Computer Name, which tells you which machine is generating the bad authentication attempts.

Note: Always query the PDC Emulator for lockout events. Get the PDC Emulator first with: $PDCEmulator = (Get-ADDomain).PDCEmulator

powershell

Get-WinEvent -ComputerName $PDCEmulator -FilterHashtable @{
LogName = 'Security'
Id = 4740
} | ForEach-Object {
[PSCustomObject]@{
TimeStamp = $.TimeCreated
LockedAccount = $.Properties[0].Value
CallerMachine = $_.Properties[1].Value
}
} | Select-Object -First 20

The Caller Machine is your starting point. Go to that machine before doing anything else.

Step 2: Check the identified machine

On the machine generating the lockouts, check in this order:

Saved credentials in Credential Manager: Control Panel, Credential Manager, Windows Credentials. Look for any entries with the user's name or domain. Remove stale entries and replace with current credentials.

Mapped drives with saved credentials: open File Explorer, check mapped drives, disconnect and reconnect any that are mapped with saved credentials.

Services running as the user: open Services, filter by Log On As column, check for any service running under the affected user account. Update the password on any that match.

Scheduled tasks: Task Scheduler, look for tasks running under the user's credentials. Update passwords there as well.

Step 3: Use Microsoft's Lockout Status tool

For persistent or complex lockout cases, the Microsoft Lockout and Bad Password Status tool (LockoutStatus.exe from the legacy RSAT toolkit) shows lockout status across all domain controllers simultaneously, which is useful in multi-DC environments where replication lag can cause inconsistent lockout behavior.

Replication Lag: The Invisible Cause of Visible Problems

Replication issues are responsible for a category of AD tickets that look completely unrelated: a user whose password reset works on one machine but not another, a group policy that applies in one site but not another, a new user account that can authenticate in one office but gets "account not found" in a different location.

The tell is inconsistency. If the same action works for some users or some machines but not others, and those users or machines are in different physical locations or connected to different domain controllers, replication lag is the likely cause.

Check replication status:

cmd

repadmin /replsummary
repadmin /showrepl

repadmin /replsummary gives you a quick health overview. Look for any replication partners showing failures or high fail counts. repadmin /showrepl gives you the detailed replication history between specific domain controllers.

Force replication if needed:

cmd

repadmin /syncall /AdeP

This forces synchronization across all domain controllers. Use with awareness: in large environments with many DCs, this generates significant network traffic.

If replication is consistently failing rather than just lagging, the cause is usually network connectivity between DCs, DNS resolution problems, or a time synchronization issue. AD Kerberos authentication requires clocks to be within five minutes of each other across all domain controllers and member machines. A machine with a clock skew beyond five minutes will fail Kerberos authentication in ways that look like credential problems.

Check time sync:

cmd

w32tm /query /status
w32tm /resync

Group Policy Failures That Look Like User Error

A user reports that a software package is not installed, a drive is not mapped, or a setting they should have is missing. The temptation is to push the policy manually or add the user to the group. The better first step is finding out whether the policy is applying at all.

cmd

gpresult /r

Run this on the affected machine logged in as the affected user. The output shows which GPOs are applying and which are not, and for any that are not applying, it shows the reason.

Common reasons a GPO is not applying:

The computer or user is not in the correct OU. GPOs are linked to OUs: if the object is not in the right OU, the policy does not apply regardless of security group membership.

Security filtering is excluding the user. Check the GPO's Security Filtering in Group Policy Management Console. The user or their machine needs either direct permission or membership in a group that has Apply Group Policy permission.

WMI filtering is blocking application. If the GPO has a WMI filter, the filter may be evaluating to false on the affected machine.

cmd

gpupdate /force

Run this after confirming the object is in the correct OU and security filtering is correct. Then run gpresult /r again to confirm the policy now appears in the Applied GPOs list.

Login Failures That Aren't Credential Problems

Login failures that persist after a verified password reset are almost always one of three things:

Kerberos ticket cache: The user has a cached Kerberos ticket that was issued before an account change (password reset, group membership change, account enable). The cached ticket is still being presented and being rejected. Solution: the user needs to fully log off and log back on, not just lock and unlock the screen. In stubborn cases, klist purge from a command prompt clears the Kerberos ticket cache immediately.

Account restrictions: Check the account properties in ADUC (Active Directory Users and Computers). Under Account tab, check for Log On To restrictions (limiting which machines the account can authenticate to), Account expires settings, and Logon Hours restrictions. Any of these can produce a login failure that looks identical to a bad password.

UPN mismatch: In hybrid environments with Azure AD Connect, a mismatch between the on-premises UPN and the Azure AD UPN produces login failures specifically for cloud-connected services while on-premises authentication still works. Check both environments if the failure is service-specific.

Using AI Research on AD Tickets Across Unfamiliar Environments

AD environments vary significantly between organizations: domain functional level, trust relationships, hybrid configurations, third-party MFA overlays, and custom schema extensions all change the diagnostic landscape. The same symptom in two different environments can have completely different root causes.

Running a structured description through AI Tech Pal before starting diagnostics is particularly useful for AD tickets in unfamiliar environments. The combination of symptom, event ID, domain functional level, and whether the environment is hybrid or on-premises only produces a targeted starting point rather than a generic checklist. June, the software specialist agent, handles Active Directory and identity issues as part of her Microsoft 365 and enterprise identity expertise.

If you want to try it: aitechpal.com/register. 15 days free, no credit card.

Frequently Asked Questions

Why does an Active Directory account keep locking out?

Repeated lockouts are almost always caused by a device with cached stale credentials, a service or scheduled task running under the user's account with an old password, or a mapped drive with saved credentials. Event ID 4740 on the domain controller identifies which machine is generating the bad authentication attempts.

What causes AD login failures that aren't password issues?

Kerberos ticket cache presenting an outdated ticket, account restrictions such as Logon Hours or Log On To settings, UPN mismatches in hybrid environments, and clock skew beyond five minutes between the client and domain controller are the most common non-credential causes.

How do you diagnose Active Directory replication problems?

repadmin /replsummary for a quick health overview and repadmin /showrepl for detailed replication history between specific domain controllers. Inconsistent behavior across sites or machines is the primary indicator of a replication issue.

What's the fastest way to check AD health?

repadmin /replsummary for replication, dcdiag /test:replications for a detailed diagnostic, and netlogon log on the domain controller for authentication failures. These three cover the majority of AD health issues quickly.

How do group policy failures show up in user tickets?

As missing software, missing drive mappings, missing settings, or application behavior that differs from what the policy should enforce. gpresult /r on the affected machine logged in as the affected user is the fastest diagnostic step.

Related reading:

https://aitechpal.com/blog/how-i-use-ai-to-research-it-issues-before-i-touch-anything
https://aitechpal.com/blog/the-it-professionals-guide-to-using-ai-as-a-second-opinion