Windows 2003 domain controller security event log filling with 538 576 and 540 events.

I know that this question has been asked here before, but here goes.
I am working on a Windows 2003 domain where we have a domain controller that has thousands of event IDs 538, 576, and 540 filling up the security log.  The username is always the servername followed by a $

The events stream into the log at a rate of about 30-40 a second.

We are required to audit successful logon and logoffs. We cannot turn off auditing to solve this problem.

What causes all of these events and what can I do to stop them at the source?
Who is Participating?
reesejlConnect With a Mentor Author Commented:
We have determined the cause of the problem... The server causing all of the entries has NFS services installed on it.  There is a checkbox on it set to "Active Directory Lookup".  None of our other servers with NFS on it has that checked.  When we removed the check, the messages stopped....
Thanks everyone for your ideas...
Jeff PerkinsOwnerCommented:
ARe you running SQL on this machine as well?  If so there's a polling feature in SQL that could very well cause these events.
You can disable this feature with the instructions in this article. 

  If you are running hp toolbox on this machine, that might be causing your issue as well.  
See this post for an explanation of both. the last two posts in the forum at the bottom are talking about both of these solutions.

If neither of those helps, check out this MS KB article about Kerberos tokens and IIS.;en-us;287537

I hope that something in these helps you out.
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

reesejlAuthor Commented:
lazarus98..  I checked the logoff type and it is a type 3.  
I ran a "netstat -a" on the domain controller in question and found that there were ports from about 1026 up to 5000 that are coming from the suspect IP address, in a "TIME_WAIT" state.

The events that are ID 540 are as follows:

Successful Network Logon:
Logon ID: (0x0,0x337xxx)    <--- this number changes
Logon Type: 3
Logon Process: Kerberos
Authentication Package: Kerberos
Workstation Name:
Logon GUID: (GUID....)
Caller User Name:
Caller Domain:
Caller Logon ID:
Caller Process ID:
Transited Services:
Source Network Address:  <the IP of the server sending all the events>
Source Port: <different every time, but looks like it increments by 2 each time>

We don't have IIS, HP Toolbox, or SQL server on this machine.

I ran network monitor, and tried to isolate the packets that were going to that port on those two servers, and found that they are mostly LDAP packets.

Any other ideas?
Check your domain controllers policy for Auditing configuration:
Audit logon events:
538 unsuccessful logon
540 successful logon
576 audit privilege use

Not much you can do about 538

Look at this KB from MS for the 576:
Look at this KB from MS for the 540:

The problem is not going to be something easy to fix, as LDAP used a lot. You can fiddle with your audit policy, but if your not allowed to you may well have to put up with it and filter out the bad info for reporting. issues.
reesejlAuthor Commented:
That seems to be the consensus for a solution to this problem. But unfortunately we are not allowed to turn off that auditing.  

The thing is that the huge amount of packets are coming from ONE server. So there must be something going on that we can mitigate. Or at least understand what's causing it.
This is just a guess.

Clients can cache domain logons. If they used that cache logon of a user's domian credentials that are no longer valid, they will have a problem logging onto the domain controller. Authentication will fail. If you get a call from someone saying they are having problems logging on to the domain, check and see if they have the domain credintials cached on their computer.  You can do this by going into control pannel>>Users, click on the advanced tab and click on manage passwords. This applies for XP boxes. Other OS versions may be different.
reesejlAuthor Commented:
Could the use of Vintela on a server cause this type of problem?
Thats possible, but you would probably need to go to Quest' site and see if they have any known issues like that. But with the complexity of bringing Unix/Linux clients into the fray it could be very possible on a single sign setup like Vintela uses.
You have to love when something simple like that bring everything to a screaming halt. Makes you wonder why they don't ask questions like that in the setup.
Closed, 500 points refunded.
Community Support Moderator
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.