Kerberos-Troubleshooting

Nicht alle Schwierigkeiten, die im Zusammenhang mit Kerberos auftreten, sind auf den ersten Blick als Kerberos-Probleme zu identifizieren. Grundsätzlich gilt, dass jedes Authentifizierungsproblem, ob lokal oder über das Netzwerk, ebenso wie der Zugriff auf Netzwerkressourcen ein Problem bei Kerberos sein kann, weil Kerberos in vielen Situationen als Authentifizierungsprotokoll genutzt wird.

Auf der anderen Seite sind viele Kerberos-Fehler eigentlich keine Probleme bei Kerberos, sondern Folgefehler, weil erforderliche Basisdienste im Netzwerk nicht funktionieren. Folgende Dienste sind für Kerberos zwingend erforderlich:

• Die Netzwerkinfrastruktur muss funktionieren, so dass alle Systeme im Netzwerk erreichbar sind.

• Die Domänencontroller, die als KDCs fungieren, müssen erreichbar sein.

• DNS muss korrekt konfiguriert sein und die Hostnamen und Dienstnamen korrekt auflösen. Insbesondere müssen auch die Dienstnamen korrekt gesetzt sein.

• Die Uhren müssen innerhalb des für Kerberos zulässigen Intervalls synchronisiert sein. Gerade dieser Punkt führt vor allem bei der Nutzung von Kerberos über die Grenzen von Forests hinweg öfter zu Fehlern.

Voraussetzungen für das Troubleshooting

Um Kerberos-Probleme oder Fehler, die mit Kerberos in Zusammenhang stehen könnten, erfolgreich zu analysieren, müssen einige Voraussetzungen erfüllt sein:

• Es müssen administrative Berechtigungen für das System, auf dem die Fehleranalyse erfolgt, vorliegen. Andernfalls können keine Kerberosbezogenen Einstellungen angepasst werden.

• Es sollten alle kritischen Updates und Sicherheits-Patches installiert sein, sowohl für das Betriebssystem als auch für Anwendungen, die Kerberos nutzen („kerberized applications“). Außerdem sollten auch Nicht-Microsoft-Komponenten in der Kerberos-Infrastruktur entsprechend aktualisiert werden.

• Das Funktionieren der oben genannten Dienste und der Zeitsynchronisation sollte sichergestellt werden – es macht keinen Sinn, im Detail nach Kerberos-Fehlern zu suchen, wenn man nicht einmal weiß, ob DNS korrekt arbeitet.

Auf dem System sollten die Windows Support-Tools und die im vorangegangenen Artikel genannten Resource-Kit-Tools installiert sein. Außerdem sollte die Überwachung von Anmeldeereignissen laufen, um Fehler besser nachvollziehen zu können.

Fehlerhafte SPNs

Ein häufiger Fehler im Zusammenhang mit Kerberos sind nicht korrekt gesetzte SPNs (Service Principal Names). Für jeden Dienst sollte genau ein SPN definiert sein. Mehrere SPNs können dazu führen, dass Clients ein fehlerhaftes Service Ticket erhalten, das beispielsweise mit einem Schlüssel eines anderen SPNs verschlüsselt ist. Es gibt eine Reihe von Fehlermeldungen im Zusammenhang mit nicht korrekt gesetzten SPNs, die an die aufrufenden Anwendungen zurückgeliefert werden. Die Anwendung muss solche Meldungen verarbeiten. Die typischen Fehlermeldungen weisen darauf hin, dass entweder ein Client oder Server nicht in der Kerberos-Datenbank gefunden wurde, was schlicht daran liegt, dass im Active Directory das SPN-Attribut nicht gesetzt ist und entsprechend der SPN nicht aufgelöst werden kann.

NTLM statt Kerberos

Ein weiteres Problem kann dadurch entstehen, dass mit NTLM statt Kerberos gearbeitet wird. Auf die Anpassung der entsprechenden Einstellungen bei der Authentifizierung über die IIS wurde bereits im Artikel Kerberos-Konfiguration in diesem Heft eingegangen.

Betroffen davon ist ansonsten noch der Internet Explorer. Bei diesem lassen sich die Einstellungen bei den Internet-Optionen im Register Erweitert anpassen. Dort findet sich die Option Integrierte Windows-Authentifizierung aktivieren (erfordert Neustart). Sie ist standardmäßig aktiviert. Wenn sie nicht aktiviert ist, wird Kerberos nicht verwendet.

Ein weiteres Problem beim Internet Explorer entsteht, wenn eine Website nicht zur lokalen Intranet-Zone gehört. Die integrierte Authentifizierung und damit auch Kerberos wird nur für diese Zone genutzt.

Als Workaround gibt es ab dem Windows Server 2003 außerdem immer die Möglichkeit, mit der Umsetzung der Authentifizierung auf Kerberos auf der Ebene des IIS zu arbeiten, wenn die Client-Konfiguration nicht entsprechend angepasst werden kann.

Für den SQL Server 2005 wird unter http://support.microsoft.com/kb/090801/en-us erklärt, wie geprüft werden kann, ob mit Kerberos gearbeitet wird.

Zu große Tickets

In gemischten Umgebungen mit Windows und UNIX oder Linux sind auch zu große Tickets ein potenzielles Problem. Bei etwas älteren Kerberos-Implementierungen unter UNIX kann beispielsweise nur mit UDP gearbeitet werden und damit die Übertragung größerer Kerberos-Tickets scheitern. Solche Tickets entstehen, wenn sehr viele SIDs eingebunden werden müssen, was vor allem bei Benutzern mit vielen Gruppenmitgliedschaften der Fall ist. Windows wechselt automatisch auf TCP und kann auch so konfiguriert werden, dass generell nur TCP zum Einsatz kommt. Bei den MIT-Distributionen wird dies nur in den neueren Releases unterstützt.

Generell kritisch sind Benutzer, die Mitglied in mehr als 70 bis 120 Gruppen sind. Die Zahl hängt vom Typ der Gruppen ab. Mit dem Utility tokensz.exe, das von http://go.microsoft.com/fwlink/?LinkId=42933 geladen werden kann, lässt sich die Token-Größe berechnen. Falls solche Probleme auftreten, kann einerseits die Zahl der Gruppen reduziert werden – was in Fällen mit sehr vielen Gruppen meist keine schlechte Idee ist, denn in diesem Fall ist das Gruppenkonzept tendenziell überarbeitungsbedürftig, weil viel zu komplex. Daneben bietet Microsoft auch einen Hotfix unter http://go.microsoft.com/fwlink/?Link-Id=23044 an.

Prä-Authentifizierung

Ein weiterer potenzieller Fehler in heterogenen Umgebungen steht im Zusammenhang mit der Prä-Authentifizierung. Bei der Prä-Authentifizierung werden vorab bestimmte Authentifizierungsinformationen gesendet, die bestätigen, dass der Client das Kennwort kennt. Damit wird eine zusätzliche Sicherheitsstufe geschaffen, weil Authentifizierungsanforderungen überhaupt nur durchgeführt werden, wenn es wahrscheinlich ist, dass diese erfolgreich sein kann.

Die Prä-Authentifizierung ist bei Windows standardmäßig aktiviert, während sie bei Kerberos-Clients auf anderen Plattformen oft nicht als Regelfall genutzt wird. Die meisten Clients reagieren aber auf eine Kerberos-Fehlermeldung, die auf die fehlende Prä-Authentifizierung hinweist, mit dem Senden der erforderlichen Daten. In den Fällen, in denen das nicht funktioniert, hat man zwei Optionen:

• Der Client wird aktualisiert, so dass er mit Prä-Authentifizierung arbeiten kann.

• Die Prä-Authentifizierung wird für die Benutzerkonten deaktiviert, die über Clients ohne entsprechende Unterstützung arbeiten. Das reduziert allerdings die Sicherheit des Systems. Die Konfiguration erfolgt über das Register Konto bei den Eigenschaften eines Benutzers und dort die Option Keine Kerberos-Präauthentifizierung erforderlich.

Verschlüsselungsprobleme

Im heterogenen Umfeld treten gelegentlich auch Schwierigkeiten mit der Verschlüsselung auf. Sie entstehen entweder, wenn das UNIX- oder Linux-System mit 3DES (Triple DES) arbeitet. Windows unterstützt nur DES und RC4. In diesem Fall muss die Konfiguration des KDC angepasst werden. Sie können aber auch entstehen, wenn ein Client keinen Schlüssel des richtigen Verschlüsselungsprotokolls besitzt. In diesem Fall lässt sich das Problem in der Regel durch eine Kennwortänderung beseitigen, weil dann neue Schlüssel generiert werden.

Problemfelder bei der Delegation

Bei der Delegation gibt es ebenfalls eine Reihe von Fehlerquellen. Besonders wichtig ist hier, dass alle Voraussetzungen erfüllt sind. Neben den generellen Anforderungen, die Kerberos beispielsweise an die Zeitsynchronisation stellt, sind das:

• Das Benutzerkonto, über das der Zugriff erfolgt, muss die Delegation zulassen. Das ist standardmäßig der Fall.

• Dem Computerkonto oder Benutzerkonto, in dessen Kontext der Dienst auf dem Middle-Tier-, also beispielsweise dem Application Server ausgeführt wird, muss für die Delegierung vertraut werden. Das ist keine Standardkonfiguration.

• Der SPN sowohl der Systeme am Middle-Tier als auch am Back-End muss registriert sein.

• Die Client-Anwendung muss Kerberos unterstützen, um entsprechende Service-Tickets anfordern zu können. Alternativ kann mit der Umsetzung auf dem Middle-Tier gearbeitet werden, falls Kerberos beispielsweise bei Zugriffen vom Browser nicht genutzt werden kann.

• Der Dienst auf dem Middle-Tier muss mit der Impersonisation arbeiten.

• Auf dem Back-End müssen die Berechtigungen für impersonisierte Benutzer und nicht für generische Accounts wie root, Administrator, sa oder dba definiert sein.

• Die Middle-Tier- und Back-End-Systeme müssen „kerberized“ sein.

In dieser Kette von Abhängigkeiten kann natürlich einiges schief gehen. Die meisten Probleme entstehen aber dadurch, dass an einer Stelle nicht alle erforderlichen Aspekte konfiguriert worden sind.

Troubleshooting-Whitepaper

Microsoft hat gleich zwei umfangreiche Whitepapers herausgegeben, die sich mit dem Troubleshooting von Kerberos beschäftigen.

• Das Whitepaper „Troubleshooting Kerberos Errors“ behandelt den Umgang mit Kerberos-Fehlern und nennt Lösungen.

• Das Whitepaper „Troubleshooting Kerberos Delegation“ beschäftigt sich speziell mit der Delegation über Kerberos.

Beide Whitepapers werden mit der aktuellen CD-ROM von Expert’s inside Windows NT/2000 geliefert.