Learn Active Directory - Common Active Directory Issues

#Introduction

In episode 21 you learned about the troubleshooting toolbox — dcdiag, repadmin, nltest, and friends. Now it's time to practice on real cases. In episode 22 we dissect common Active Directory issues: the problems most frequently reported at the helpdesk desk and in the server room, from DCs that stop replicating to krbtgt falling victim to administrative error.

The troubleshooting pattern is always the same: identify the symptom, gather evidence with the right tools, find the root cause, then fix it. Here you'll see that pattern repeated across eight different scenarios.

#DC Not Replicating

Symptom: changes on one DC don't appear on another. Check with repadmin /replsummary then repadmin /showrepl on the problematic DC. The most common causes:

Failed connection — the DC can't reach its partner because a firewall blocks RPC port 135 and 49152-65535.
Wrong DNS — the DC uses a DNS server that doesn't know the _msdcs zone.
Expired credentials — a replication partner account that's too old causes access errors.

Check replication failures and force sync

Get-ADReplicationFailure -Scope Domain
repadmin /syncall dc02 /AdeP

Warning

If the error mentions USN rollback or a DC restored from a snapshot, don't force sync. That's an emergency condition requiring special recovery — forcing replication could spread incorrect data.

A failed login symptom can come from many directions. Trace through in order:

Broken secure channel — "trust relationship failed" on a computer. Fix with Reset-ComputerMachinePassword on the machine or netdom resetpwd /s:server /ud:domain\user /pd:* from the server side.
Locked-out account — check event 4740 in the Security log to see the source of wrong password attempts. Unlock with Unlock-ADAccount.
Expired password — reset or extend it with Set-ADAccountPassword.

Tip

A locked-out account isn't unlocked without investigation — first find where the attempts came from, because it's often an old script or a drive mapping using stale credentials.

#GPO Not Applying

Symptom: Group Policy settings don't appear on the computer or user. First verify what's actually applied:

gpresult /r — shows applied and blocked GPOs, complete with LSDOU order.
gpupdate /force — forces a refresh to test whether new GPOs come in.
Check events 6005 and 1058 in the application log — 1058 indicates a GPO file in SYSVOL can't be read.

Common causes of a GPO not applying: the GPO object in SYSVOL isn't synced between DCs (related to the SYSVOL issue below), wrong security filtering, or an overly strict WMI filter.

#Time Skew

Kerberos rejects tickets if the clock difference between client and DC exceeds 5 minutes. The classic symptom: "clock skew too great" or error 0x80090304 during authentication.

The fix is systemic: make sure all servers synchronize time to the same source. On DCs, the PDC Emulator is the domain's time authority, and other DCs sync from it.

Check and resync time

w32tm /query /status
w32tm /config /manualpeerlist:pool.ntp.org /syncfromflags:manual /reliable:yes
w32tm /resync

#DNS Registration Failure

Symptom: a computer doesn't appear in DNS, dcdiag /test:dns fails, or clients can't find a DC. Main causes:

Dynamic update disabled — the DNS zone doesn't allow secure dynamic updates.
Zone not AD-integrated — changes only exist on specific servers.
Wrong IP address — a computer uses the wrong DNS server and registers itself in the wrong zone.

Check DNS records with nslookup -type=SRV _ldap._tcp.corp.local. Make sure the corp.local zone is AD-integrated and set to Secure only for dynamic updates.

#SYSVOL Issues

SYSVOL is the shared folder that stores Group Policy templates and logon scripts. Common issues:

FRS vs DFSR — older DCs use FRS, which Microsoft has deprecated since Windows Server 2012 R2. Migration to DFSR is required: dfsrmig /getglobalstate to see the status, then dfsrmig /setglobalstate 1 to advance a stage.
Missing SYSVOL share — users can't read policy; check that the \\server\SYSVOL share still exists and the GPT.INI file is present.

Important

If SYSVOL isn't in sync between DCs, GPOs will differ from one DC to another. Fix the DFSR migration before adding new GPOs.

#krbtgt Issues

The krbtgt account is the key that signs all Kerberos tickets in the domain — it's the foundation of authentication. Problems arise when:

The krbtgt password is reset carelessly — all still-valid tickets immediately become invalid, and the entire domain seems to "log out".
A reset happens unintentionally because of a buggy script.

If krbtgt needs to be reset (e.g. after a compromise), do it twice with at least a 12-hour gap between resets, and make sure replication completes in between. This discards old tickets while preventing tickets issued before the first reset from staying valid.

Warning

Resetting krbtgt isn't a routine operation — it's an emergency one. Always document the reason and time of the reset, and never reset krbtgt on both DCs almost simultaneously without ensuring replication.

#Conclusion

In this episode you practiced handling the eight most common problems:

Replication: check repadmin /replsummary and fix connection, DNS, or credentials.
Login: repair the secure channel, unlock accounts, and manage password expiration.
GPO: verify with gpresult /r and investigate SYSVOL.
Time skew: synchronize time to a single common source.
DNS: make sure zones are AD-integrated and dynamic updates are secure.
SYSVOL: complete the FRS to DFSR migration.
krbtgt: handle it carefully and only for emergency reasons.

The same problems can be prevented before they happen — and that requires observation, not just fixes. In episode 23, we become the watchmen: Active Directory security monitoring — advanced audit policy, Windows Event Forwarding, Sysmon, SIEM integration, and how to detect Kerberoasting, golden tickets, and pass-the-hash. See you there!