Jump to content

Help please - strange error messages on W2k3 server


Recommended Posts

Posted

We recently had a power cut which shut down the entire campus, all servers were powered down via UPS.

 

When the power was restored I restarted the DC's and everything appears to be working fine BUT I am getting lots of the following error messages on my PDC.

 

The kerberos client received a KRB_AP_ERR_MODIFIED error from the server SCI-ICT-14$. The target name used was cifs/GRAPHICS8A.cowplain.hants.sch.uk. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (COWPLAIN.HANTS.SCH.UK), and the client realm. Please contact your system administrator.

 

As I said above everything seems to be working fine on the network but I don't like having all of these error messages.

 

Any ideas?

Posted
A few pointers (possibly). Check that the clocks on the clients are synchronised properly with the DCs and that the servers themselves are all showing the same time. You could also try renewing all the DHCP leases and also perform a manual scavenge of DNS addresses. You might equally find that this settles down after a day or two by itself - these tetchy servers really don't appreciate being distured in their work!
Posted
I have this ocasionally, the machines in my case have never been imaged in there entire life, but threw a wobbly, I just removed them both from the domain, deleted the accounts and put them back on again and then they stopped moaning so all was good, but when it was doing the moaning, I didnt notice any issues with the clients, they seemed all good and fine.
Posted
Thanks I will give that a try when I get a moment, open evening tonight aaargh!

 

Nothing in the client event logs on one of the 'named' workstations?

Posted

Explanation of the Error

========================

This event will occur if you present a service ticket to a principal (target

computer) which cannot decrypt it. Normally the service ticket is encrypted using the shared secret of the machine account's password as a basis for the encryption used to encrypt the service ticket. The password is known only to the KDC (Domain controllers) and the target machine. The client presents encrypted session ticket it received from the KDC to the target server. If the server can decrypt the ticket, the server then knows that it was encrypted by a trusted source (the DC) and the presenter (the client) is also trusted. If the target server has a different password than the DCs, the session ticket cannot be decrypted and the

failure occurs.

 

As someone previously mentioned, the easiest way to resolve this is to remove the client from the domain, make sure the account is deleted in active directory and re-join the client to the domain.

Posted

Hmm, thanks for the info and suggestion. However to do this I would have to possibly remove and rejoin all 600+ machines from the network as most are now experiencing this error.

 

During term time this is not going to be possible as there is only myself and one technician unless opf course we do a night shift!

 

I have continued to investigate this and I have noticed anomalies within DNS on both DNS servers. We appear to have multiple computers with the same IP addresses listed in both the forward and reverse lookup zones so I assume the problem is getting worse. DCDiag and Netdiag both show no errors when run on the servers. I am considering stopping one of the DNS servers, removing the incorrect entries by cross referencing with DHCP and reloading on the remaining DNS server, restarting the second DNS server and copying the reconfigured zone across.

 

Any thoughts?

Posted

Scavenging the stale records from DNS sounds like a good place to start, get one of the DNS servers sorted, delete the zones on the other server and rebuild it.

 

If there is an issue with the DC’s replicating, you may have difficulties transferring zones and this could indicate a more serious problem.

Posted

My plan seems to have worked, after two hours of cross referencing DHCP and DNS to delete incorrect entries everything now appears to be running without error, replication is working well across the four DC's.

 

I'm still not happy with the second DNS server as the zones listed are not identical to the First DNS server, I uninstalled and reinstalled DNS but it just recollated the zones it had before.

 

Should I delete the DNS server entries from the registry before reinstalling DNS?

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...