Behandeln von Problemen in Verbindung mit Kerberos in IIS

In diesem Artikel wird die Problembehandlung in Verbindung mit Kerberosauthentifizierung auf Servern mit IIS (Internet-Informationsdienste) beschrieben. Es handelt sich hierbei zwar nicht um einen vollständigen Leitfaden, doch werden Sie hier zahlreiche Verweise auf andere Quellen finden, die bei der Behandlung der meisten Probleme mit Kerberos hilfreich sein können.

Standardmäßig wird bei der Installation von IIS auf Microsoft Windows 2000 in der Metabasis der Schlüssel NTAuthenticationProviders auf Negotiate, NTLM gesetzt. Das bedeutet, dass IIS diese beiden Werte im Header WWW-Authenticate zurückgibt, wenn ein Client mit Microsoft Internet Explorer 5.0 oder höher eine Verbindung mit der Website herstellt. Dabei ermittelt der Client, mit welcher Authentifizierungsmethode er die Verbindung herstellen kann. Wenn der Client entscheidet, sich mit der Methode Verhandeln (Negotiate) zu verbinden, handelt er mit dem Server aus, ob für die Authentifizierung Kerberos oder NTLM verwendet werden soll. Wenn der Client die Methode Verhandeln nicht unterstützt, wird NTLM verwendet.

Dies ist jedoch nur eine sehr allgemeine Beschreibung des Ablaufs dieses Vorgangs. Wenn Kerberos beteiligt ist, gibt es noch eine Vielzahl weiterer Ereignisse, die Sie möglicherweise gar nicht bemerken.

Wenn Internet Explorer keine Verbindung mit Kerberos herstellen kann, werden einige weitere Sicherheitsüberprüfungen ausgeführt. Beispielsweise erhält der Client ein Ticket vom TGS (Ticket Granting Service) und verwendet dieses Ticket dann für die Authentifizierung.

Weitere Informationen zum Ablauf dieses Vorgangs finden Sie im folgenden Artikel der Microsoft Knowledge Base: Weitere Informationen hierzu finden Sie auf folgender Website von Microsoft: Mit diesen beiden Dokumentationen sollten Sie bei der Behandlung von Problemen mit Kerberos vertraut sein.

Hinweis: Falls Sie vor kurzem auf Internet Explorer 6.0 aktualisiert haben, stellen Sie möglicherweise fest, dass Probleme in Verbindung mit Kerberos auftreten, weil das Kontrollkästchen Integrierte Windows-Authentifizierung aktivieren nicht standardmäßig aktiviert ist. Weitere Informationen dazu, wie Sie sicherstellen können, dass diese Option richtig konfiguriert ist, finden Sie im folgenden Artikel der Microsoft Knowledge Base:

Überprüfen der Authentifizierungsmethoden

Vergewissern Sie sich, dass in der Metabasis die richtigen Authentifizierungsmethoden für den IIS-Server oder die fragliche Website aufgeführt sind. Wenn der Server von Microsoft Windows NT 4.0 auf Windows 2000 aktualisiert wurde, ist die Authentifizierungsmethode Verhandeln nicht verfügbar und muss manuell hinzugefügt werden. Wurde der Computer nicht von Windows NT 4.0 auf Windows 2000 aktualisiert, vergewissern Sie sich, dass die geeigneten Authentifizierungsmethoden verfügbar sind. Weitere Informationen dazu, wie Sie überprüfen können, ob die Authentifizierungsmethode "Verhandeln" verfügbar ist, und wie Sie sie gegebenenfalls hinzufügen können, finden Sie im folgenden Artikel der Microsoft Knowledge Base: Diese Authentifizierungsmethode muss nicht unbedingt für den gesamten IIS-Server, sondern kann auch nur auf Websiteebene aktiviert werden. Verwenden Sie dazu das Skript "Adsutil.vbs" mit Angabe der Websitenummer. Verwenden Sie beispielsweise den folgenden Befehl, um die Authentifizierungsmethode nur für die Standardwebsite zu aktivieren:

Die Zahl "1" nach "w3svc" ist die Websitenummer, wie sie auch im Internetdienste-Manager aufgeführt ist.

Ermitteln des Servernamens

Stellen Sie als nächstes fest, ob Sie die Verbindung mit der Website unter Verwendung des NetBIOS-Namens des Servers oder mittels eines Aliasnamens herstellen. Zum Beispiel mit einem DNS-Namen wie "www.microsoft.com". Wenn Sie auf den Webserver unter einem anderen Namen als dem eigentlichen (NetBIOS-) Namen des Servers zugreifen, muss davor ein neuer Dienstprinzipalname (Service Principal Name, SPN) registriert worden sein. Dies erfolgt mithilfe des Programms "Setspn" aus dem Windows 2000 Server Resource Kit. Da dieser Dienstname in Active Directory nicht bekannt ist, stellt der TGS dem Benutzer kein Ticket zur Authentifizierung aus. Der Client ist somit gezwungen, für das erneute Verhandeln die nächste verfügbare Authentifizierungsmethode, also NTLM, zu verwenden. Wenn der Server beispielsweise auf den DNS-Namen "www.microsoft.com" antwortet, aber eigentlich "webserver1.development.microsoft.com" heißt, muss "www.microsoft.com" für jeden IIS-Server in Active Directory registriert werden. Dazu müssen Sie das Dienstprogramm "Setspn" herunterladen und auf dem IIS-Server installieren.

Weitere Informationen zum Download des Dienstprogramms "Setspn" finden Sie auf folgender Website von Microsoft: Setspn.exehttp://www.microsoft.com/downloads/details.aspx?FamilyID=5fd831fd-ab77-46a3-9cfe-ff01d29e5c46&DisplayLang=en (http://www.microsoft.com/downloads/details.aspx?FamilyID=5fd831fd-ab77-46a3-9cfe-ff01d29e5c46&DisplayLang=en) Versuchen Sie, eine Verbindung mit dem Server unter Verwendung seines eigentlichen Namens herzustellen, um zu überprüfen, ob dieser Name anstatt des DNS-Namens verwendet wird. Wenn keine Verbindung zu dem Server hergestellt werden kann, fahren Sie mit dem Abschnitt Überprüfen, ob dem Computer für Delegierungszwecke vertraut wird fort. Wenn die Verbindung zum Server hergestellt werden kann, führen Sie die folgenden Schritte aus, um einen SPN für den DNS-Namen festzulegen, unter dem auf den Server zugegriffen wird:

1. Installieren Sie das Dienstprogramm "Setspn".
2. Öffnen Sie auf dem IIS-Server eine Eingabeaufforderung, und wechseln Sie in das Verzeichnis "C:\Programme\Resource Kit".
3. Führen Sie den folgenden Befehl aus, um den neuen SPN (z. B. "www.microsoft.com") in Active Directory für den Server hinzuzufügen, wobei Webserver1 für den NetBIOS-Namen des Servers steht:
   
   Setspn -A HTTP/www.microsoft.com Webserver1
   You receive output that is similar to the following:

   Registering ServicePrincipalNames for (Registrierung von SPNs für) CN=webserver1,OU=Domain Controllers,DC=microsoft,DC=com
   HTTP/www.microsoft.com
   Updated object (Objekt aktualisiert)
   							

4. Geben Sie auf dem IIS-Server die folgende Befehlszeile ein, um eine Liste der SPNs auf dem Server mit diesem neu hinzugefügten Wert anzuzeigen: Setspn -L webservername

Beachten Sie, dass nicht alle Dienste registriert werden müssen. Viele Diensttypen, wie z. B. HTTP, W3SVC, WWW, RPC, CIFS (Dateizugriff), WINS und UPS (Unterbrechungsfreie Stromversorgung) werden dem Standarddiensttyp unter der Bezeichnung HOST zugeordnet. Wenn Ihre Clientsoftware z. B. den SPN "HTTP/webserver1.microsoft.com" zum Herstellen einer HTTP-Verbindung mit dem Webserver auf dem Server "webserver1.microsoft.com" verwendet, dieser SPN aber nicht auf dem Server registriert ist, ordnet ein Domänencontroller mit Windows 2000 die Verbindung automatisch "HOST/webserver1.microsoft.com" zu. Diese Zuordnung gilt nur, wenn der Webserver-Dienst unter dem lokalen Systemkonto ausgeführt wird.

Wichtig: Falls der SPN, den Sie registrieren möchten, für das Computerkonto gilt (die Website wird unter dem Konto "LocalSystem" oder dem Konto "NetworkService" ausgeführt), dürfen Sie die vorhandenen SPNs des Computers nicht ändern. Fügen Sie stattdessen nur den neuen HTTP-SPN hinzu. Wenn der Name der Website dem Hostnamen entspricht, müssen die SPNs nicht geändert werden. Wenn die Standardnamen "HOST/Server" und "HOST/FQDN des Servers" fehlen, müssen Sie die Probleme untersuchen, die der Netlogon-Dienst auf dem Server beim Registrieren der erforderlichen SPNs hat. Es sollten Fehlermeldungen in der Protokolldatei angezeigt werden, wenn Sie die Protokollierung des Dienstes aktivieren. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: Außerdem sollten durch "Netlogon" im Systemereignisprotokoll Ereignismeldungen zu Registrierungsfehlern protokolliert werden.

Überprüfen, ob dem Computer für Delegierungszwecke vertraut wird

Wenn der IIS-Server ein Mitglied der Domäne, aber kein Domänencontroller ist, muss dem Computer für Delegierungszwecke vertraut werden, damit Kerberos ordnungsgemäß funktioniert. Gehen Sie folgendermaßen vor, um dies zu aktivieren:

1. Klicken Sie auf dem Domänencontroller auf Start, zeigen Sie auf Einstellungen, und klicken Sie auf Systemsteuerung.
2. Doppelklicken Sie auf den Ordner Verwaltung, und doppelklicken Sie auf Active Directory-Benutzer und -Computer.
3. Klicken Sie unter Ihrer Domäne auf den Ordner Computer.
4. Suchen Sie in der Liste den IIS-Server. Klicken Sie mit der rechten Maustaste auf den Servernamen, und klicken Sie auf Eigenschaften.
5. Klicken Sie auf die Registerkarte Allgemein, aktivieren Sie das Kontrollkästchen Für Delegierungszwecke vertraut, und klicken Sie auf OK.

Verwenden von Kerbtray

Ein weiteres sehr hilfreiches Dienstprogramm bei der Behandlung von Problemen mit Kerberos ist "Kerbtray.exe". Es ist im Windows 2000 Resource Kit enthalten. Mit Kerbtray können Sie die Kerberos-Tickets anzeigen, die aus dem lokalen Cache ausgestellt wurden. Sie können das Dienstprogramm von folgender Microsoft-Website herunterladen: Weitere Informationen zu diesem Programm und Tipps zur Behandlung von Problemen mit Kerberos finden Sie auf folgender Website von Microsoft:

Aktivieren der Protokollierung von Sicherheitsereignissen

Das Protokollieren von Sicherheitsereignissen kann bei der Problembehandlung wegen fehlgeschlagener Authentifizierungsversuche via Kerberos überaus hilfreich sein. Wenn diese Option aktiviert ist, können Sie fehlgeschlagene Benutzeranmeldungen bei Authentifizierung über IIS anzeigen lassen. Dies liefert möglicherweise eine Erklärung der Ereignisse während des Authentifizierungsvorgangs und lässt Rückschlüsse auf den Grund für die fehlgeschlagene Authentifizierung zu.

Der Rest dieses Abschnitts wurde direkt aus dem Buch Desiging Secure Web Based Applications for Windows 2000 (Entwickeln sicherer webbasierter Anwendungen für Windows 2000) von Michael Howard übernommen. Da alle Verbindungen unter Windows 2000 authentifiziert werden, ist das richtige Interpretieren von Anmeldeereignissen eine wichtige Fertigkeit. Dieser Abschnitt erklärt die unterschiedlichen Variablen, aus denen ein Anmeldeereignis besteht.

Überwachungseinstellungen für Anmeldung und Abmeldung

Microsoft Windows NT sieht nur eine Überwachungskategorie für Anmeldung und Abmeldung vor. Mit Windows 2000 wurde eine zweite eingeführt. Die beiden Kategorien ? "An-/Abmeldung" und "Kontoanmeldung" ? werden in den folgenden Abschnitten erklärt.

Überwachen von Anmeldeereignissen (Kategorie "An-/Abmeldung")

Diese Ereigniskategorie steht in allen Versionen von Windows NT und Windows 2000 zur Verfügung. Ihre Ereignisse weisen darauf hin, dass unter einem Konto eine Anmeldung bzw. Abmeldung erfolgt oder eine Verbindung zum Computer hergestellt worden ist. Das Überwachungsereignis wird also auf dem Computer ausgelöst, auf dem die Anmeldung erfolgt. Die Kategorie "An-/Abmeldung" ist von Bedeutung, weil sie bei der Verwendung von IIS, SQL Server und COM+ die meisten Informationen liefert.

Die wichtigsten Ereignisse in der Kategorie "An-/Abmeldung" sind:

• An-/Abmeldungsereignis 529 (Anmeldung fehlgeschlagen)
• An-/Abmeldungsereignis 528 (Anmeldung erfolgreich)
• An-/Abmeldungsereignis 540 (Netzwerkanmeldung erfolgreich)

Die folgenden Abschnitte zeigen diese Ereignisse, und in Tabelle 1 werden die einzelnen Felder der Ereignisse erklärt.

An-/Abmeldungsereignis 529 (Anmeldung fehlgeschlagen)

An-/Abmeldungsereignis 528 (Anmeldung erfolgreich) und An-/Abmeldungsereignis 540 (Netzwerkanmeldung erfolgreich)

Überwachen von Anmeldeereignissen (Kategorie "An-/Abmeldung")

Die Ereignisse in dieser Ereigniskategorie weisen darauf hin, dass ein Konto angemeldet bzw. abgemeldet wurde, und dass der Computer zur Bestätigung des Kontos verwendet wurde. In diesem Fall wird das Überwachungsereignis also auf dem Computer ausgelöst, auf dem sich das Konto befindet. Viele Ereignisse in Verbindung mit Kerberos, z. B. das Ausstellen von Tickets, werden protokolliert, wenn diese Überwachungskategorie aktiviert ist.

Die folgenden Abschnitte zeigen zwei häufige Ereignisse bei fehlgeschlagener Anmeldung.

Kontoanmeldungsereignis 676 (Anmeldung fehlgeschlagen) (Account Logon event 676 (logon failure)): Fehlgeschlagene Anfrage für Authentifizierungsticket Hinweis: Das Konto "NT-AUTORITÄT\SYSTEM" bedarf möglicherweise einer weiteren Erklärung. Dieses Konto wird normalerweise als lokales Systemkonto bezeichnet. Unter diesem Konto werden die meisten Dienste ausgeführt. Im Sicherheitsprotokoll finden sich viele Verweise auf dieses Konto.

Ereignis 676 weist darauf hin, dass "Benutzer" vom Kerberos-Schlüsselverteilungscenter (KDC) kein anfänglich ausgestelltes Ticket, das wiederum Tickets ausstellt (Ticket Granting Ticket, TGT), erhalten konnte. Der wichtigste Teil des Ereignisses ist der Fehlercode. Diese Codes sind identisch mit den Codes von MIT Kerberos. In Tabelle 2 werden einige der häufigsten Fehlercodes beschrieben; eine vollständige Liste finden Sie in folgendem Dokument: http://www.ietf.org/rfc/rfc1510 (http://www.ietf.org/rfc/rfc1510) .

Tabelle 2 - Einige häufige Fehlercodes von Kerberos

Anmeldeereignis 681 (Anmeldung fehlgeschlagen) (Account Logon event 681 (logon failure)) mit einer großen Zahl als Fehlercode.

Möglicherweise sehen Sie manchmal einen Fehler wie den folgenden. Das Problem dabei ist, dass der Fehlercode praktisch keine Aussagekraft hat. Tabelle 3 - Beispiele für Fehlercodes bei Kontoanmeldung


Bei Korrelation der oben stehenden Fehlerereignisse ? die Anforderung eines TGT seitens "Benutzer" schlägt bei Anmeldeversuch mit Fehlercode "6" fehl (Client in Kerberos-Datenbank nicht gefunden) und allgemeiner Anmeldefehler mit Fehlercode 3221225572 (Der angegebene Benutzer ist nicht vorhanden) ? wird schnell klar, wo das Problem liegt: "Benutzer" ist kein gültiges Konto!

Weitere Informationen zu Kerberos finden Sie in den folgenden Artikeln der Microsoft Knowledge Base: Die Kerberos FAQ-Website (Häufig gestellte Fragen zu Kerberos) enthält weitere Informationen zum Kerberos-Protokoll: