The kerberos client received a KRB_AP_ERR_MODIFIED error

This is what I got in the event logs yesterday afternoon:


Event Type: Error
Event Source: Kerberos
Event Category: None
Event ID: 4
Computer: SE-SMURF01
Description:
The kerberos client received a KRB_AP_ERR_MODIFIED error from the server PC-BLABLA09$.  The target name used was . 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 (FOO.BAR.STRIPE.LOCAL), and the client realm.   Please contact your system administrator.


Event Type: Error
Event Source: Kerberos
Event Category: None
Event ID: 4
Computer: SE-SMURF01
Description:
The kerberos client received a KRB_AP_ERR_MODIFIED error from the server PC-BLA09$.  The target name used was RPCSS/PC-BLA10. 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 (FOO.BAR.STRIPE.LOCAL), and the client realm.   Please contact your system administrator.


I had replaced those machines a week ago, and everything seemed to work fine. So I didn’t understand why these errors were suddenly popping up. The applications running on those computers where throwing a wobbler as well. Some googling later I found 2 remarks that were useful.


The first one was that someone fixed it by taking the computer out of the domain, renaming it, changing the SID, and changing the IP address. While this is overkill on the scale of killing a mouse with a thermonuclear weapon, it pointed in the direction of a network level problem.


The second remark was by a Microsoft employee who explained that DNS misconfiguration can be the source of problems like this. If kerberos thinks it is communicating with pcA it encrypts the kerb ticket with the password of pcA. but if the ticket then ends up on pcB because of the DNS mismatch, the above events will be logged.


At that moment I realized that I had changed the IP address of an adapter on PC-BLA10 because it conflicted with PC-BLA09. The reason everything worked fine initially was because that port had been left disconnected until 2 days ago when I configured the correct IP address. The conflict was resolved and the DNS information was updated, but that didn’t mean that the DNS caches were up to date. So I cleared the DNS cache of the DNS server, and used ipconfig /flushdns to clear the resolver cache on the domain controller and PC-BLA10, and the problem disappeared.


 

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>