Looking at the image closely, it appears that at least one of those audit entries were logging "an attempt to query the existence of a blank password for an account." Whenever somebody logs on (or UAC-elevates, if I remember correctly), one or more of these events are logged as the system checks to see if people have blank passwords; it wouldn't make much sense for the logon UI to prompt for a password if the user didn't have one.
These aren't a problem unless you have an insane amount of logons (or, perhaps, automated Run As invocations) happening all the time. But, since you asked how to get rid of them, here we go:
The Local Security Policy UI lies to you about certain audited activities. (There are actually several activities involved in each of those categories; it generalizes.) To see exactly what is audited, run auditpol /get /category:*
at an administrative command prompt. To fully disable auditing, run auditpol /clear
, then reboot.
You can back up and restore the audit policy (if you think somebody legitimately and purposefully set up a custom policy) using the /backup
and /restore
switches on auditpol
, both of which require a /file:"\path\to\file"
argument immediately following.
Read more about auditing at TechNet.
This can be done by an
Administrator
domain user. – Ramhound – 2015-03-03T19:29:10.363I right click and ran as administrator the local security policy (secpol.msc) as a local account Administrator. All accounts on this machine are local accounts. – Jake – 2015-03-03T19:34:48.867