Monthly Archives: March 2013

Log Message: Kerberos client received a KRB_AP_ERR_MODIFIED error from the server

I was working on a client’s server the other day and I finally decided I would look at and resolve one of the more common error messages I see when I’m working on a remediation project:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server reception-win7$. The target name used was cifs/ceo-computer.domain.local. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using.

The message evaded me for quite a long time – it seemed to indicate a mismatch in computer names, but I knew quite well both were properly joined to the domain. I wondered what would happen if I tried a basic operation on the target machine?

C:\System>dir \\ceo-computer\c$
Logon Failure: The target account name is incorrect.

Interesting – something was going on with the account for ceo-computer$ I wonder if the machine is online and resolves to an IP address?

C:\System>ping -n 1 ceo-computer
Pinging ceo-computer.domain.local [10.0.0.36] with 32 bytes of data:
Reply from 10.0.0.36: bytes=32 time<1ms TTL=128

Interesting – the machine is online. I wonder if they mean the computer account? A quick check would show me the NetBIOS machine name of that host:

C:\System>nbtstat -A 10.0.0.36

Local Area Connection:
Node IpAddress: [10.0.0.2] Scope Id: []

NetBIOS Remote Machine Name Table

Name Type Status
———————————————
RECEPTION-WIN7 <00> UNIQUE Registered
DOMAIN      <00> GROUP Registered
RECEPTION-WIN7 <20> UNIQUE Registered
DOMAIN      <1E> GROUP Registered

MAC Address = 00-0F-FB-F3-CF-73

And there we have it. When I issue the DIR command for the above UNC, it looks up the SPN for that machine and then looks the machine name up in DNS. The machine returned the IP address for a different computer, with the destination rejecting the connection because the login account for that computer was incorrect.

A quick check showed what I immediately suspected – DHCP was not updating DNS when an DHCP Renew request was processed and was using (very) old values. I fixed DHCP and checked later – viola! – the problem was resolved.