Are the machines installed from images?
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.
Are the machines installed from images?
Yes, all machines are loaded using Norton Ghost
And did you sysprep them afterwards?
Yes, we haven't imaged any of the pcs since the summer break though
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!
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.
running netdiag on one of the affected clients might also yield clues.
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?Originally Posted by Cowman
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
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.
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.
Make sure you enable DNS scavenging/aging.
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.
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?
There are currently 1 users browsing this thread. (0 members and 1 guests)