reesejl
asked on
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?
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?
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.
http://msdn2.microsoft.com/en-us/library/aa198198(SQL.80).aspx
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.
http://www.certfaq.com/bb/ftopic26525.html
If neither of those helps, check out this MS KB article about Kerberos tokens and IIS. http://support.microsoft.com/default.aspx?scid=kb;en-us;287537
I hope that something in these helps you out.
Jappo
You can disable this feature with the instructions in this article.
http://msdn2.microsoft.com/en-us/library/aa198198(SQL.80).aspx
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.
http://www.certfaq.com/bb/ftopic26525.html
If neither of those helps, check out this MS KB article about Kerberos tokens and IIS. http://support.microsoft.com/default.aspx?scid=kb;en-us;287537
I hope that something in these helps you out.
Jappo
ASKER
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:
User Name: SERVERNAME$
Domain: DOMAINNAME
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>
riteheer:
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?
Thanks
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:
User Name: SERVERNAME$
Domain: DOMAINNAME
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>
riteheer:
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?
Thanks
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: http://support.microsoft.com/kb/822774
Look at this KB from MS for the 540: http://support.microsoft.com/kb/300692
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.
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: http://support.microsoft.com/kb/822774
Look at this KB from MS for the 540: http://support.microsoft.com/kb/300692
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.
ASKER
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.
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.
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.
ASKER
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.
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
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.
modus_operandi
Community Support Moderator
modus_operandi
Community Support Moderator
http://www.monitorware.com/Common/en/SecurityReference/Event-ID-538-Explained.php