We use a User-ID agent on a Windows server to read logon audit events from domain controllers and map IP addresses to usernames. The setup works at four of our five sites, but the domain controllers at the remaining site only record computer-account logons and not interactive or network user logons.
The audit policy is configured through the default domain controller Group Policy, GPResult confirms that the policy applies, and the same service account and software configuration work elsewhere. The service account has Log on as a service permission and is an Event Log Readers member. Remote PowerShell queries work, and we have ruled out Windows Firewall, network firewalls, software version issues, and basic permissions.
Interestingly, the agent can read domain controllers at the other sites across the tunnels. Active Directory Sites and Services appears to direct the affected subnet to the local domain controllers. What could cause these domain controllers to omit user logon events even though the audit policy appears to be applied?
2 Answers
Check the actual Security log events and the effective advanced audit policy directly on each affected controller. Look specifically for event 4624 and the relevant Logon Type values, then run `auditpol /get /category:*` locally. A domain policy can appear in GPResult while another policy or legacy-versus-advanced audit setting changes the effective result. Also verify that the clients are generating user authentications against these DCs rather than only machine-account activity.
First confirm that users at the affected site are actually authenticating against those domain controllers. Run `echo %LOGONSERVER%` on several user machines and compare the results with a working site. You can also run `nltest /dsgetdc:yourdomain` to see which controller the client discovers. Domain controller selection can be affected by subnet definitions, site links, DNS, and cached logon behavior, so the local controllers may not be handling the user authentications you expect.
The discovery command returns one of the domain controllers at that site, and Sites and Services has the subnet assigned there. I’ll compare the actual LOGONSERVER values from several clients with the working site.
The fact that the service can query the logs remotely shows that log access and connectivity are probably fine; the important distinction is whether the expected user logon events are being generated on those controllers in the first place.