I was asked to troubleshoot an interesting problem today where the Windows Security event log was being "flooded" by one particular sort of event. By flooded, I mean about 20 duplicate entries logged per second. The biggest problem with this is that it was making the Security log on that server useless, as the log would fill up within 45 minutes at that rate. Click to enlarge the screenshot below:
*Names were changed to protect the guilty*
The operating system is Windows 2008 R2. The server is a domain member. The server also runs SQL Server 2008 R2. The server is a cluster node in a failover cluster. I started Googling and Binging the event ID and description, and I didn't get much at first.
As an aside, I can't believe I just used the word "Binging," and I much prefer Google for almost everything, but if you want to search Technet, MSDN, and other Microsoft sites, the built-in Bing search on those sites actually does tend to produce better results on those sites than a general Google search. For me anyway. Maybe a "site:technet.com xyz" search on Google would do just as well. Anyway... onward:
So the only solid clue I found in my searching was this Technet article. The Windows Password Policy Checking API was being called at a staggering rate, but why? By whom? How do I make it stop? The same SQL service account was being named in the events, so it obviously must have something to do with SQL. Well, I could turn off the auditing of "Other Account Management Events," either by way of domain GPO or local security policy on that server... but that would only suppress the logging of that behavior. It does nothing to stop the actual behavior. Plus I would also lose any other events of that same category on the system.
I also knew that there was an "Enforce Password Policy" option that can be configured on each SQL account. So I fired up SQL Management Studio on that server and did some testing, and as it turns out, that option was enabled on several accounts, including service accounts that are designed to hit the database rapidly. It appears that every time an authentication attempt is made by one of those SQL accounts that has that Enforce Policy option checked, the SQL service makes a call to that Windows API to do some password policy checking, and that event is logged.
I tactically identified a few key service accounts that I knew to be very active on that database, and I disabled the "Enforce Password Policy" option on those accounts one by one. I confirmed that with each account I changed, the rate at which those Security event 4793's were coming in decreased. Until finally, they stopped completely.
That's all for today. On one final note, I wish we did cool things like this in the United States, especially as a resident of a state that cuts science funding.