DC lost connection

[Erik Verheuvel]

Our network contains a number of sites.
On one of the sites the domain controller isn't
replicating Active Directory data.

I get the following error message:

The kerberos client received a KRB_AP_ERR_MODIFIED error
from the server host/S04.corp.com. The target name used
was LDAP/S04.corp.com/corp...@corp.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.COM), and the client
realm.

Does anybody have any idee what needs to be done to solve
this problem?

Greetings,
Erik (http://www.shiftingviews.nl)

[Steven L Umbach]

Below is a link to a Microsoft white paper that should be able to help you
out. Your specific error is described [ I pasted details below link] in the
paper and possible resolutions. You may need to enable kerberos debugging to
get more details about the error. It mentions dns as a possible problem
which so often is with Active Directory. I would also run the support tools
netdiag and dcdiag on that domain controller for further information which
could help you pinpoint the problem. Netdiag performs a kerberos test and if
you use [ netdiag /test:kerberos /debug ] you may get more detailed
nfo. --- Steve

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx
0x29 - KRB_AP_ERR_MODIFIED: Message stream modified
Associated internal Windows error codes
. SEC_E_WRONG_PRINCIPAL

. STATUS_WRONG_PASSWORD

Corresponding debug output messages
. DebugLog("Failed to verify message: %x\n",Status)

. DebugLog(""Failed to encrypt message: %x\n",Status)

. DebugLog("Failed to encrypt message (crypto mismatch?): %x\n")

. DebugLog("Checksum on TGS request body did not match\n")

. D_DebugLog("Failed to create S4U checksum\n")

. DebugLog("S4U PA checksum doesn't match!\n")

. DebugLog("Pac was modified - server checksum doesn't match\n")

. D_DebugLog(DEB_TRACE,"Could not decrypt the ticket\n")

Possible Causes and Resolutions
Some encrypted Kerberos authentication data sent by the client did not
decrypt properly at the server because:

. A service ticket is issued to the local computer account, for which
a host/ SPN is automatically created, instead of to the service account, for
which no SPN has been created. The reason for this is that a service does
not register an SPN for itself, yet the service belongs to a service class
for which the computer will automatically map the SPN to a host/service
class. (Examples of this are the HTTP and Common Internet File System (CIFS)
service classes.) The result is that the service cannot decrypt the
resultant ticket.

Resolution

If the root cause appears to be that an SPN has not been set, verify
that each service running on the target computer has an SPN set. Those
services that do not have SPNs set might have had their SPNs remapped to the
computer's host SPN. For more information about SPNs and how to set them,
see Need an SPN Set earlier in this white paper.

. The authentication data was encrypted with the wrong key for the
intended server.

. The authentication data was modified in transit by a hardware or
software error, or by an attacker.

. The client sent the authentication data to the wrong server because
incorrect DNS data caused the client to send the request to the wrong
server.

Resolution

Verify that DNS is functioning properly.

. The client sent the authentication data to the wrong server because
DNS data was out-of-date on the client.

Resolution

Verify that DNS is functioning properly.

. Two computers in different domains have the same name and the client
sent the authentication data to the wrong computer.

Resolution

Verify that there are not multiple computers with the same name,
including NetBIOS names, anywhere on the network.

"Erik Verheuvel" <hc...@tiscali.nl> wrote in message
news:1b8f01c50b7e$0609af50$a401...@phx.gbl...

[Lesley Kipling [MSFT]]

Hi. As Steve says, thsi may be due to a duplicate SPN, but can often be
caused by a machine account password mismatch. I have found that the
following method works well - if the problem is on a DC

1. stop the KDC service on the DC that is getting the error,

2. Use netdom to reset the machine account password as per-
How To Use Netdom.exe to Reset Machine Account Passwords of a Windows
WGID:493
ID: 325850

Hope this helps,

Cheers, Les

This posting is provided "AS IS" with no warranties, and confers no rights.

"Erik Verheuvel" <hc...@tiscali.nl> wrote in message
news:1b8f01c50b7e$0609af50$a401...@phx.gbl...