Often the Windows Security Event log disappoints people when they’re trying to find clues to some kind of permissions or rights problem–to a 401 unauthorized response from IIS, for a common example.
They open the log up, they see dozens of events, but they don’t usually see the type of information they expected to see. And so it’s common for Admins to think, “Oh, that’s a worthless log.” And so most people don’t pay attention to this log.
This event log can be very helpful however. And often the real problem may be that there is no auditing going on. Perhaps this is because the default settings don’t pump much noise into the security event log.
If you’re working with a domain controller, you’d want to open the Domain Controller policy. Otherwise you’ll want to open the local security policy. There are many ways to get there. By force of habit I just tend to run “secpol.msc.”
Drill down into Local Policies > Audit Policy
Note where there is no auditing, where only successes are being audited, and where only failures are being audited, as seen below.
If there is no auditing going on, or if you’re only auditing successes, perhaps that’s why you’re not seeing much in the Security Event log.
If you attempt to add checkmarks to “success” or “failure” for one of these auditing options and find that the checkboxes are greyed out as seen below. . .
. . . then you may need to talk to the domain admin who controls group policies to see about getting it adjusted.
After changes are made, I tend to prefer to run gpupdate /force and run IISRESET (I usually work with web servers) or reboot.
Local Policy Settings > Audit Policy
How to enable and apply security auditing in Windows 2000
Security auditing settings are not applied to Windows Vista-based and Window Server 2008-based computers when you deploy a domain-based policy