[adde] Antwort: [adde] AW: [adde] Antwort: [adde] AW: [adde] Kerberos Probleme nach installation zusätzlichem DC
- From: CBarth@xxxxxxxxxxxxxxxx
- To: adde@xxxxxxxxxxxxx
- Date: Fri, 10 Sep 2010 10:51:58 +0200
Ja DNS läuft, sauber.
Von: <Thomas.Stemick@xxxxxxxxxxxxxx>
An: <adde@xxxxxxxxxxxxx>
Datum: 10.09.2010 10:38
Betreff: [adde] AW: [adde] Antwort: [adde] AW: [adde] Kerberos Probleme
nach installation zusätzlichem DC
Gesendet von: adde-ml@xxxxxxxxxxxxx
Hallo,
hast Du den DNS schon mal überprüft? Sind Host- und Pointereinträge für DCs
und betroffene Memberserver korrekt?
Mit freundlichen Grüßen/Best Regards
Thomas Stemick
-----Ursprüngliche Nachricht-----
Von: adde-ml@xxxxxxxxxxxxx [mailto:adde-ml@xxxxxxxxxxxxx] Im Auftrag von
CBarth@xxxxxxxxxxxxxxxx
Gesendet: Freitag, 10. September 2010 10:29
An: adde@xxxxxxxxxxxxx
Betreff: [adde] Antwort: [adde] AW: [adde] Kerberos Probleme nach
installation zusätzlichem DC
es ist ganz willkürlich, verschiedene Memberserver. Allerdings alle mit
2008R2 unter 2003 ist das Problem noch nicht aufgetreten.
Von: Andreas Michelfeit <Andreas.Michelfeit@xxxxxxxxxxxxx>
An: "adde@xxxxxxxxxxxxx" <adde@xxxxxxxxxxxxx>
Datum: 10.09.2010 10:09
Betreff: [adde] AW: [adde] Kerberos Probleme nach installation
zusätzlichem DC
Gesendet von: adde-ml@xxxxxxxxxxxxx
Stimmt,
betrifft es eigentlich immer die gleichen Member Server oder sind das
verschiedene?
Von: adde-ml@xxxxxxxxxxxxx [mailto:adde-ml@xxxxxxxxxxxxx] Im Auftrag von
Fischer, Lars
Gesendet: Freitag, 10. September 2010 09:52
An: adde@xxxxxxxxxxxxx
Betreff: [adde] AW: [adde] Kerberos Probleme nach installation zusätzlichem
DC
Also im Dokument vom Microsoft „Troubleshooting Kerberos Errors“ steht zu
dem Fehler folgendes:
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.
Von: adde-ml@xxxxxxxxxxxxx [mailto:adde-ml@xxxxxxxxxxxxx] Im Auftrag von
Andreas Michelfeit
Gesendet: Freitag, 10. September 2010 09:43
An: adde@xxxxxxxxxxxxx
Betreff: [adde] AW: [adde] Kerberos Probleme nach installation zusätzlichem
DC
Guten Morgen,
ich denke, daß Du eventuell doppelte SPNs hast.
Kannst Du mal auf dem DC setspn -X ausführen?
Vermutlich hast Du irgendwo noch einen SPN mit dem Namen Memberserver$, das
solltest Du durch setspn herausfinden können.
Diese Artikel könnten helfen:
http://technet.microsoft.com/en-us/library/cc733987(WS.10).aspx
http://msdn.microsoft.com/en-us/library/ms677949(VS.85).aspx
Andreas
-----Ursprüngliche Nachricht-----
Von: adde-ml@xxxxxxxxxxxxx [mailto:adde-ml@xxxxxxxxxxxxx] Im Auftrag von
CBarth@xxxxxxxxxxxxxxxx
Gesendet: Freitag, 10. September 2010 09:35
An: adde@xxxxxxxxxxxxx
Betreff: [adde] Kerberos Probleme nach installation zusätzlichem DC
Hallo AD Profis,
ich habe in unserem AD einen zusätzlichen DC mit 2008R2 installiert
(allerdings nicht der erste R2).
Seitdem habe ich bei einigen Server hin und wieder das Problem, dass die
Anmeldung nicht funktioniert. Man kann sich dann nur noch lokal anmelden.
Nach einem Reboot funktioniert es wieder.
Im Eventlog der Member Server und dem DC erscheint:
Protokollname: System
Quelle: Microsoft-Windows-Security-Kerberos
Datum: 09.09.2010 20:34:04
Ereignis-ID: 4
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Beschreibung:
Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server
"memberserver$" empfangen. Der verwendete Zielname war memberserver$. Dies
deutet darauf hin, dass der Zielserver das vom Client bereitgestellte Token
nicht entschlüsseln konnte. Dies kann auftreten, wenn der
Ziel-Serverprinzipalname (SPN) nicht bei dem Konto registriert ist, dass
der Zieldienst verwendet. Stellen Sie sicher, dass der Ziel-SPN bei dem
Konto registriert ist, das vom Server verwendet wird, und zwar
ausschließlich bei diesem Konto. Dieser Fehler kann auch auftreten, wenn
der Zieldienst ein anderes Kennwort für das Zieldienstkonto verwendet als
das Kennwort, das vom Kerberos-KDC (Key Distribution Center) für das
Zieldienstkonto verwendet wird. Stellen Sie sicher, dass der Dienst auf dem
Server und im KDC beide für die Verwendung des aktuellen Kennworts
aktualisiert wurden. Wenn der Servername nicht vollqualifiziert ist und
sich die Zieldomäne (AD.local) von der Clientdomäne (AD.local)
unterscheidet, prüfen Sie, ob sich in diesen beiden Domänen Serverkonten
mit gleichem Namen befinden, oder verwenden Sie den vollqualifizierten
Namen, um den Server zu identifizieren.
Ich vermute ein Problem mit der Kerberos Verschlüsselung, aber die
Einstellung kommt doch eigentlich durch die Default Domain Controller
Policy? Und müsste dann auf allen DC´s auftreten?
Viele Grüße
Carsten
________________________________
Der Inhalt dieser Nachricht oder eventueller Anlagen ist vertraulich und
ausschließlich für den bezeichneten Adressaten bestimmt. Bitte stellen Sie
sicher, dass die Information in dieser Nachricht ausschließlich an die
adressierten Personen gelangt. Sollte diese Nachricht versehentlich an Sie
gesendet worden sein, dann informieren Sie bitte umgehend den Absender und
löschen Sie die Nachricht. Vielen Dank.
The information in this e-mail and any attachments is confidential. The
information must only be held in areas that have controlled and limited
access to the addressed persons. If this e-mail has been sent to you in
error, please immediately notify the sender and delete the e-mail. Thanks.
Other related posts:
- » [adde] Antwort: [adde] AW: [adde] Antwort: [adde] AW: [adde] Kerberos Probleme nach installation zusätzlichem DC - CBarth
