While doing some unrelated troubleshooting (at least I think so, shared-printer issues) I came across a set of Event Log entries that have me concerned.
Machine Name: labcomputer82 Source: Security-Kerberos Event ID: 4 Event Description:
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server labcomputer143$. The target name used was RPCSS/imagemaster4.ad.domain.edu. 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. Please ensure that the target SPN is registered on, and only registered on, the account used by the server. This error can also happen when the target service is using a different password for the target service account than what the Kerberos Key Distribution Center (KDC) has for the target service account. Please ensure that the service on the server and the KDC are both updated to use the current password. If the server name is not fully qualified, and the target domain (AD.DOMAIN.EDU) is different from the client domain (AD.DOMAIN.EDU), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.
There are three machine names used in this message. It's generated on labcomputer82, it's attempting to talk to another lab workstation called labcomputer143, and the service in question (RPCSS) refers to the name of the machine that this machine was imaged from (and possibly also that of labcomputer143, I'm not sure). The thing that has me raising both eyebrows is that the machine named
labcomputer82 is attempting to use an SPN of
The SPN attribute on the computer object in AD looks just fine. It has all the names it should have.
These machines are imaged using Ghost and (at least in this specific case) sysprep was not used. Of the over 3,000 computer objects in our AD domain, somewhere around 1,700 of them are computer-lab seats that are frequently imaged and as of September the majority were imaged using the Ghost/Profile-Copy method instead of the Ghost/sysprep method Microsoft recommends. If this error report is something major that Windows is quietly working around, perhaps kerberos is broken for these machines and it's failing back to NTLMv2, I'd like to know so I can add pressure in my drive for sysprep adoption.