Kerberos Errors

[egnilk66]

I have a ton of Kerberos errors... I think the password got changed. Is there a way to reset Kerberos so that it matches the other DCs? An example of the errors is:




Event Type: Error
Event Source: Kerberos
Event Category: None
Event ID: 4
Date: 4/27/2005
Time: 9:00:08 AM
User: N/A
Computer: HERMES
Description:
The kerberos client received a KRB_AP_ERR_MODIFIED error from the server DTPRD114$. The target name used was cifs/WIN2K.CORP.domain.COM. 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 (CORP.domain.COM), and the client realm. Please contact your system administrator.

For more information, see Help and Support Center at

http://go.microsoft.com/fwlink/events.asp.

 

[PScottC]

Is DTPRD114 a DC? If not, remove the box from the domain, deleted the computer account from AD (In all parent and child domains), then re-add the system to the domain.

PSC

Governments and corporations need people like you and me. We are samurai. The keyboard cowboys. And all those other people out there who have no idea what's going on are the cattle. Mooo! --Mr. The Plague, from the movie "Hackers

 

[egnilk66]

If that's the case, I would need to do that to every machine on the domain.....over 100....I'm getting errors for all sorts of them.

 

[PScottC]

Researching the error, I'm finding a lot of hits like this:

Key version numbers also enable Windows Server 2003 to provide more informative errors when a message cannot be decrypted. In general cases, when information can not be decrypted, the system provides the error KRB_AP_ERR_MODIFIED, meaning that the encrypted information is not accessible, but with no further information. For example, the data could have been modified in transit, the data could have been malformed initially, or there could be no available key. Each of these possible causes requires troubleshooting at different locations and using different techniques.

Is DNS running properly on your domain? Are all the "SRV" records correct?

PSC

Governments and corporations need people like you and me. We are samurai. The keyboard cowboys. And all those other people out there who have no idea what's going on are the cattle. Mooo! --Mr. The Plague, from the movie "Hackers

 

[egnilk66]

DNS runs famously. I honestly think the password on the KRBGT account was changed, accidentally.

 

[PScottC]

Never had this problem myself... Maybe someone else on the forum can pick up this thread. I'm stumped.

PSC

Governments and corporations need people like you and me. We are samurai. The keyboard cowboys. And all those other people out there who have no idea what's going on are the cattle. Mooo! --Mr. The Plague, from the movie "Hackers

 

[CowboysFan87]

Do you have WINS installed? Sounds like the problem described here...

http://support.microsoft.com/default.aspx?scid=kb;en-us;837391

Hope that helps.
CBF'87



Thanks,
CBF '87

 

[egnilk66]

Beauty. WINS was installed but some of the machines that have static IPs didn't have it in their WINS tab in the TCP/IP stack. Thanks!!!

 

[egnilk66]

Nope. I was wrong...still getting errors...




The kerberos client received a KRB_AP_ERR_MODIFIED error from the server ARBORMED-0VZR8K$. The target name used was cifs/WNXP7.CORP.MORFGROUP.COM. 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 (CORP.MORFGROUP.COM), and the client realm. Please contact your system administrator.

 

[PScottC]

Are you hosting multiple domains in your forest? (domain.com and corp.domain.com?) If yes, did you copy the computer accounts from one domain to another, or remove from one and add to the other?

I've looked at a number of articles, and yes, its possible that the krbtgt account had it's password reset, but all systems should receive new Kerberos tickets in 10 hours. Unless of course you changed the timeout period for the tickets to something huge, like 10000 hours. Is your "Default Domain Policy" active? Are there any policies that might override it?

PSC

Governments and corporations need people like you and me. We are samurai. The keyboard cowboys. And all those other people out there who have no idea what's going on are the cattle. Mooo! --Mr. The Plague, from the movie "Hackers

 

[egnilk66]

No on the multiple domains. Yes the default domain policy is active but I don't think there's any others that may override it. Were is the timeout period set for the Kerberos Account?

 

[weezy6902]

im having the same problem. anyone else have any ideas on the fix for this?

 

[xmsre]

Kerberos interoperability with a foreign system, probably some eunuchs NAS variant. cifs/win2k.corp.domain.com gives it away. You won't see cifs/ prefix for Windows because that's a default.

So, if we're saying the problem is ineroperability, there are a few things that have to happen.

First, you have to have a common key type. By default Windows only has RC4, which of course no one else does. Eunuchs wants DES_CBC_CRC which windows doesn't have. The commonality is usually DES_CBC_MD5, which isn't there by default. You have to change useraccountcontrol to add it, then change the password th generate the key on the user account.

Next, in your case, sounds like DES is enabled. the KRB_AP_ERR_MODIFIED error implies a problem with encryption of preauthentication data. I've seen this in a couple of different cases, one where the SPNs on the servers in the domain were messed up, and the other where the krbtgt account did not have a DES key. I suspect in your case, the krbtgt account does not have a DES key.

You can make the krbtgt account get a DES key, but it's avery tricky operation and you risk invalidating all the kerberos tickets in your realm. I'd contact Microsoft PSS for some hand holding on this one.

I've specifically seen this exact issue with Celerra joining a domain. The NAS vendor is also well aware of the problem and resolution. If this is the product, you could alternatively call the vendor for hand holding...