Problem : DCDIAG’s kccevent test fails
We have a very simple network with a single Microsoft Small Business Server 2003, which is acting as the DC and provides DNS, DHCP, SQL Server 2005, and IIS (as well as other) services. Our users are able to log in out of their desktop computers, but a web application that we are using will randomly fail AD authentication, even though the users can log into their workstations. I have been investigating this issue, which seems to be related to LDAP or DNS. When I ran DCDIAG, the kccevent test failed with the following message:
A Warning event occured. EventID: 0x800004C0
Event String: Internal event: An LDAP Client connection was closed because of an error.
Client Id: 12168
Additional Data: Error Value: 995. The I/O operation has been aborted because of either a thread exit or an application request.
I’ve cleared the Kerberos cache and have reviewed DNS configuration. When I do an nslookup on our DC object GUID._msdcs.OURDOMAIN.org, the IP address of our DC is returned, but the non-authoritative answer is our WAN IP Address, which is used for our SBS e-mail server. I do not know whether or not this is an issue. I’ve attached images of our DNS configuration as well as the results of nslookup for your review.
I have scoured the Internet for ideas about how to correct the error that I’ve mentioned, but haven’t found an answer for a simple, single DC situation. I am also unsure whether the results of my nslookup are correct. The first part seems good, but the non-authoritative answer seems strange to me. I’d really appreciate any help.
Solution : DCDIAG’s kccevent test fails
There can be multiple causes of your problem:
You just brought a new server on line. To complete the process, the server has to register its own host A record and SVR record in DNS. To do this, Type the following at the command prompt:
net stop netlogon
net start netlogon
flushing DNS will remove all old or improper DNS records
registering dns records registers your Host A record
restarting the netlogon will register your SVR records.
Speaking of SVR records, here is your second potential problem:
The cause or your problem may be the result of a faulty default DNS server cached record Cityofabbeville,int.
2003 server has a quirk in it. When the netlogon service is restarted it registers the SRV record of both NICs on the DNS server. As you know DNS is the service that provides the DNS translation to the Authenticating server. If DNS sees two SRV records, Cityofabbeville,int picks up on the NIC that shouldn’t be providing DNS to the clients, you may get “no netlogon servers can be found” for your authentication server and see the errors above.
The quirk in 2003 server is regardless of deselecting the option registering the SRV record when netlogon is restarted, it will still register the SRV record. There is a patch to resolve this. But, let’s make sure this is the problem. Go into DNS and see if your multihomed DNS server has two SRV records. One will be internal and the other external of your LAN. If you have an SRV record that doesn’t belong, you should remove these records. This is only a temp fix for troubleshooting because upon a restart of the netlogon service will put those records back in DNS.
Then, I would go to the XP clients and check out the IPconfig /all. See if you have picked up on a DNS server that is not correct. If so, you will not be able to get the DNS query for the Authenticating server to propogate back. So, you will not be able to communicate with the Authenticating server. Hence, you will not be able to authenticate and recieve errors like you are seeing. Flush the DNS cache and manually configure your list of preferred DNS servers to the correct NICS.
There is a fix to the 2003 server. It is a patch.
Have a look at this:
I hope this helps