Monitoring and Troubleshooting Identity

What to log, and where it lives

Identity problems and identity attacks look the same at first: someone cannot sign in, or someone signed in who should not have. Both are solved from logs, so the logs must exist, be kept long enough and be searchable in one place. Logging basics are on what to log; this section covers the identity sources.

Microsoft Entra sign-in and audit logs

A sign-in log records every authentication attempt against an identity provider: who, when, from which IP address and device, to which application, which authentication methods were used, which Conditional Access policies applied, and whether it succeeded — with an error code when it did not. Microsoft Entra ID splits them into four kinds:

• Interactive user sign-ins — a person typed a password, used a passkey or approved a prompt.
• Non-interactive user sign-ins — an app renewed a token on the user's behalf; there are many more of these.
• Service principal sign-ins — an application signed in with its own credentials.
• Managed identity sign-ins — an Azure resource signed in with its managed identity.

The Entra audit log is the audit log of the directory: users created, group memberships changed, roles assigned, app consents granted, Conditional Access policies edited. When a sign-in suddenly fails for everyone, the audit log often shows the policy change that caused it.

Retention in the portal is short — as of 2026 roughly a week on the free tier and 30 days with P1 or P2 licenses; check Microsoft's data retention page for current values. For investigations that start months later, send the logs elsewhere with a diagnostic setting: to a Log Analytics workspace (queried with KQL, the Kusto Query Language), a storage account for archive, or an event hub feeding a SIEM.

// Sources where many different accounts failed with a wrong password in the last hour
SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType == "50126"
| summarize FailedUsers = dcount(UserPrincipalName), Attempts = count() by IPAddress
| where FailedUsers >= 10
| order by FailedUsers desc

The Windows Security log on domain controllers

For Active Directory, the evidence is in the Security event log of each domain controller (DC), viewed in Event Viewer (see Event Viewer) or queried with Get-WinEvent. Two things catch people out. Each DC logs only what it handled itself, so one sign-in story is spread over several DCs. And what is logged depends on the audit policy: the "Advanced Audit Policy Configuration" subcategories such as Kerberos Authentication Service, Credential Validation, User Account Management and Security Group Management must be enabled, normally through a Group Policy Object linked to the Domain Controllers OU. On Linux hosts, PAM and SSSD write to the journal (see Linux and Identity).

Key Windows security events

Memorize a dozen event IDs and most identity questions become a filter on the Security log:

The events that point at attacks — 4662 for directory replication, 4769 with RC4 encryption, 4768 without preauthentication — are on Attacks on Identity. A filter for one event ID on the PDC emulator looks like this (not run here):

$pdc = (Get-ADDomain).PDCEmulator
Get-WinEvent -ComputerName $pdc -FilterHashtable @{LogName = 'Security'; Id = 4740} -MaxEvents 5 |
    Select-Object TimeCreated, @{n = 'User'; e = {$_.Properties[0].Value}},
                  @{n = 'CallerComputer'; e = {$_.Properties[1].Value}}

TimeCreated          User    CallerComputer
-----------          ----    --------------
10/1/2026 9:12:44 AM hrahimi KE-LT-0412
10/1/2026 8:41:03 AM hrahimi KE-LT-0412

Account lockouts: finding the source

An account lockout is the state in which a directory refuses all sign-ins for an account after too many failed password attempts within a set time, either until an administrator unlocks it or until the lockout duration has passed. It slows down password guessing, at the price of a denial of service when the wrong attempts come from the user's own forgotten devices. In AD, the threshold, duration and counter-reset time are set in the domain's password policy (or a fine-grained password policy). Entra ID uses smart lockout instead, which tries to lock out the attacker's sign-ins while letting the real user in from familiar locations.

In AD, the PDC emulator is the referee. When a DC sees a wrong password, it checks with the PDC emulator before rejecting the attempt, because the user may have just changed the password there. The PDC emulator therefore sees failures from the whole domain, decides the lockout, and logs event 4740.

The usual sources after a password change are a phone syncing mail with the old password, a mapped network drive or saved credential in Windows Credential Manager, a disconnected remote desktop session still signed in, a scheduled task or service running as the user, and a script with the password in it. The routine:

1. Find the PDC emulator and read event 4740 for the user: the Caller Computer Name is the source machine.
2. If the caller is a server such as a mail or VPN server, the source is a client behind it; look at that server's own logs for the client address.
3. On the source machine, check saved credentials, mapped drives, services, scheduled tasks and other sessions for the user.
4. Remove or update the stale credential, then unlock the account (Unlock-ADAccount). Unlocking first just starts the cycle again.

In a SIEM, the same question is a count. This sketch counts lockouts and failed logons from sample events collected from the domain controllers:

from collections import Counter

# Security events collected from the DCs and servers: (event ID, account, source)
# 4625/4771: failed logon (source = workstation or client address)
# 4740: account locked out (source = Caller Computer Name)
EVENTS = [
    (4771, "hrahimi", "192.0.2.41"),
    (4771, "hrahimi", "192.0.2.41"),
    (4625, "hrahimi", "KE-FS01"),
    (4771, "hrahimi", "192.0.2.41"),
    (4771, "hrahimi", "192.0.2.41"),
    (4740, "hrahimi", "KE-LT-0412"),
    (4625, "mchen", "KE-LT-0388"),
    (4771, "hrahimi", "192.0.2.41"),
    (4740, "hrahimi", "KE-LT-0412"),
]

lockouts = Counter((acct, src) for eid, acct, src in EVENTS if eid == 4740)
failures = Counter((acct, src) for eid, acct, src in EVENTS if eid in (4625, 4771))

print("Lockouts (4740) by account and caller computer:")
for (account, source), count in sorted(lockouts.items()):
    print(f"  {account:<8} {source:<12} {count}")

print("Failed logons (4625/4771) by account and source:")
ranked = sorted(failures.items(), key=lambda item: (-item[1], item[0]))
for (account, source), count in ranked:
    print(f"  {account:<8} {source:<12} {count}")

Lockouts (4740) by account and caller computer:
  hrahimi  KE-LT-0412   2
Failed logons (4625/4771) by account and source:
  hrahimi  192.0.2.41   5
  hrahimi  KE-FS01      1
  mchen    KE-LT-0388   1

The Kerberos failures (4771) show a client address rather than a name; a DNS lookup shows that 192.0.2.41 is KE-LT-0412, the same laptop the lockout event names. The single failures elsewhere are ordinary typing mistakes. If one source instead produced failures for many accounts, you would be looking at password spraying, not a stale credential.

Time and clock skew

Kerberos tickets carry timestamps, and AD rejects requests when the clocks of client and DC differ by more than 5 minutes by default (see Kerberos and NTLM). The symptom is confusing: the password is right, yet logons fail, often with event 4771 failure code 0x25 (clock skew too great) or "the time difference is too great" errors on Linux.

AD has a built-in time hierarchy: members sync from a DC, DCs sync from the PDC emulator of their domain, and the PDC emulator of the forest root domain syncs from a reliable external source (see NTP). Problems start when someone points a server at a different source, when a virtual machine takes its time from the hypervisor host instead, or when the PDC emulator role moves to a DC that has no external source configured. The tool is w32tm (not run here):

w32tm /query /status
w32tm /query /source
w32tm /monitor /domain:ad.example.com
w32tm /resync

Leap Indicator: 0(no warning)
Stratum: 4 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0312500s
Root Dispersion: 0.0451234s
ReferenceId: 0xC000020A (source IP:  192.0.2.10)
Last Successful Sync Time: 10/1/2026 8:52:14 AM
Source: dc01.ad.example.com
Poll Interval: 10 (1024s)

A source of "Local CMOS Clock" or "Free-running System Clock" means the machine is not synchronizing with any time source. On a domain member that is a fault; on the forest root PDC emulator it means the whole forest drifts along with one unsynchronized clock.

Replication and trust problems

AD replication health

AD replication is the process by which domain controllers copy directory changes — new users, password changes, group memberships, Group Policy — to each other, so every DC eventually holds the same data. It is multi-master: a change can be made on any writable DC. When replication breaks, DCs drift apart, and symptoms look random: a new user can log on in one office but not another, a group change works for half the servers, a password reset "does not take".

Check it with repadmin and dcdiag on a DC or a machine with the AD tools (not run here):

repadmin /replsummary
repadmin /showrepl DC02
dcdiag /v /c /e /f:C:\Temp\dcdiag.txt

Replication Summary Start Time: 2026-10-01 09:14:02

Beginning data collection for replication summary, this may take awhile:
  ....


Source DSA          largest delta    fails/total %%   error
 DC01                      08m:12s    0 /   5    0
 DC02                  03d.02h:41m    5 /   5  100  (1722) The RPC server is unavailable.

Destination DSA     largest delta    fails/total %%   error
 DC01                  03d.02h:41m    5 /   5  100  (1722) The RPC server is unavailable.
 DC02                      08m:12s    0 /   5    0

DC01 has not received changes from DC02 for three days, and error 1722 says DC01 cannot reach DC02's RPC (remote procedure call) service — typically a firewall, DNS pointing at the wrong address, or DC02 being down. dcdiag runs a broader set of tests (DNS registration, services, SYSVOL, FSMO roles) on each DC. Act quickly: a DC that has not replicated for longer than the tombstone lifetime (180 days by default in forests created on Windows Server 2003 SP1 or later) must not simply be reconnected, as it can reintroduce deleted objects ("lingering objects").

The computer's secure channel

Every domain-joined computer has its own account and password in AD, which it changes automatically. If the copies get out of step — a machine restored from an old snapshot, or reimaged with the same name — the user sees "The trust relationship between this workstation and the primary domain failed." The computer can no longer authenticate, so nobody can log on with a domain account. Test and repair it (not run here):

Test-ComputerSecureChannel -Verbose
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

nltest /sc_verify:ad.example.com does the same check from the command line. Rejoining the domain also works, but needs a local administrator account on the machine and a restart.

Entra sign-in errors

Failed Entra ID sign-ins carry an AADSTS error code, shown to the user on the error page and in the sign-in log. A few that the service desk sees every day, per Microsoft's error code reference:

For a Conditional Access block, the sign-in log entry lists every policy that was evaluated with its result, which is far quicker than reading the policies. The "What If" tool in Conditional Access answers the same question for a sign-in that has not happened yet (see Conditional Access and Zero Trust).

A troubleshooting routine

"I can log on here but not there" is the classic identity ticket. Apply the general method (see OS Troubleshooting) with identity-specific checks, cheapest first:

1. Scope. One user or many? One machine, one site or everywhere? Cloud apps, on-premises, or both? One user on one machine points at that machine; everyone at one site points at a DC, DNS or the network there.
2. Recent changes. Password changed, group membership changed, new Conditional Access or Group Policy, a DC added or retired? Check the audit logs.
3. The exact error. The AADSTS code, event 4625 status code or 4771 failure code usually names the cause: wrong password, locked, disabled, expired, clock skew, policy.
4. DNS. Can the machine find a DC (nltest /dsgetdc:ad.example.com)? Is it using internal DNS? See DNS and Active Directory.
5. Time. Is the clock within 5 minutes of the DC?
6. Replication and sync. Did the change reach the DC this machine uses, and, for cloud apps, has it synchronized to Entra ID yet?
7. Policy. Logon rights from Group Policy, Conditional Access, the allowed groups on a Linux host. gpresult /r shows which Group Policy Objects applied (see Group Policy).
8. The machine itself. Secure channel, cached credentials, a stale Kerberos ticket (klist purge and log on again).

Forwarding identity logs to a SIEM

Each DC and each cloud tenant only sees its own part of the story. A SIEM (security information and event management system; see SIEM) brings them together: Entra sign-in and audit logs through a diagnostic setting or a connector, DC security events through Windows Event Forwarding or an agent, Linux authentication logs through syslog. Microsoft Sentinel, for example, is a SIEM built on Log Analytics, so the KQL above works there; Microsoft Defender for Identity adds sensors on the DCs that detect attacks such as DCSync and pass-the-ticket from the traffic itself.

Good first rules for identity: lockouts and failures per source across many accounts (spraying), any change to tier 0 groups (4728/4732/4756 for Domain Admins, Enterprise Admins, Administrators), sign-ins by break-glass accounts, new Conditional Access exclusions, and replication requests from non-DCs. Make sure the clocks of all sources are synchronized too — correlation across systems is only as good as their timestamps.