Authentifizierung bei Windows 7 und Server 2008 Release 2
31. August 2010
Wer als Administrator auf Windows-Plattformen agiert, der sollte die beiden wichtigen Authentifizierung-Protokolle im Windows-Umfeld bereits kennen: das NTLM (kurz für NT LAN Manager)und Kerberos. In diesem Beitrag wird gezeigt, wie Windows 7 und Windows Server 2008 Release 2 (R2) diese beiden Protokolle unterstützen. Dabei kommen auch die grundlegenden Unterschiede zwischen den beiden Authentifizierungs-Mechanismen zur Sprache. Kerberos ist dabei die weitaus bessere Wahl. Der Administrator sollte seine Benutzer wenn möglich dazu zwingen, den besseren Ansatz zu nehmen. Hierbei helfen ihm die Einschränkungen für NTLM weiter, wie sie bei Windows 7 und Windows Server 2008 R2 zur Verfügung stehen.
Die Unterstützung für Kerberos hat Microsoft mit Windows 2000 ins Spiel gebracht. Das NTLM stammt dagegen noch aus den frühen Tagen von Windows NT. Bei Kerberos handelt es sich um ein Authentifizierungs-Protokoll, das auf dem Prinzip des „Trusted Third Party“ (TTP) basiert. Dagegen arbeitet NTLM mit einem Challenge-Response-basierten Authentifizierungs-Protokoll. In der Tabelle sind einige Unterschiede zwischen den beiden Ansätzen zu sehen.
Im Verlauf eines Authentifizierungs-Austauschs via NTLM erzeugt der Ressourcen-Server (wie zum Beispiel ein Dateiserver) eine NTLM-Challenge, die an den Client weitergeleitet wird. Der Client erzeugt seinerseits eine NTLM-Response. In dieser Antwort liegt ein Hash-Wert für das Kennwort des Benutzers und der Server überprüft diese Antwort.
Wenn der Client ein lokales Konto verwendet, überprüft der Server die Antwort des Benutzers mit dem Hash-Wert des Benutzerkennworts, das in seiner lokalen SAM-Datenbank (Security Account Manager) gespeichert ist. Kommt beim Client dagegen ein Domänenkonto zum Einsatz, leitet der Server die Antwort an einen Domänencontroller (DC) weiter, der die Überprüfung ausführt. Denn nur die DCs besitzen eine Kopie des Hash-Wert für das Benutzerkennwort in ihrer Active Directory Datenbank.
Bei der Kerberos-Implementierung von Windows übernimmt ein DC mit Windows 2000 (oder einer neueren Version), der den Dienst Kerberos Key Distribution Center (KDC) bereitstellt, die Rolle der TTP. Der KDC-Dienst übernimmt dann die Authentifizierung zwischen einem Kerberos-fähigen Client und einem Server. Dazu wird der KDC-Dienst automatisch im Zuge der AD-Installation aufgespielt. Dieser Dienst besteht seinerseits aus zwei untergeordneten Diensten: dem Authentication Service (AS) und dem Ticket-Granting Service (TGS).
Wenn sich nun ein Benutzer an einer Windows-Domäne mit Hilfe von Kerberos anmeldet, dann wird der Windows-Client zuerst den Benutzer gegen einen DC authentifizieren und er verwendet dazu das Benutzer-Kennwort. Zur selben Zeit wird der Client ein Ticket Grant Ticket (TGT) vom AS anfordern. Das TGT kann man sich als ein temporäres Kennwort vorstellen (die standardmäßige Lebensdauer für ein TGT liegt bei acht Stunden), das das eigentliche Kennwort des Benutzers in allen weiteren Authentifizierungs-Anfragen ersetzt.
Möchte ein Benutzer auf einen Ressourcen-Server zugreifen, präsentiert der Client das TGT an den TGS und bekommt dann ein Session-Ticket für die Authentifizierung am Ressourcen-Server. Im Gegensatz zu NTLM kommt Kerberos immer nur bei einer Domänen-basierten Authentifizierung (über einen DC) zum Einsatz – nicht dagegen bei einer lokalen Anmeldung gegen die Windows-SAM.
Ab Windows 2000 ist Kerberos das standardmäßige Authentifizierungs-Protokoll im Microsoft-Umfeld. Windows verwendet einen Verhandlungs-Mechanismus, um zu bestimmen, welches Authentifizierungs-Protokoll zum Einsatz kommt. Falls das standardmäßige Kerberos fehlschlägt oder von einem der Client- beziehungsweise Server-Komponenten, die in einem Authentifizierungsvorgang involviert sind, nicht unterstützt, dann erfolgt der Einsatz des NTLM – also eine Art von Fallback-Lösung.
Kerberos ist die beste Option
Einige Gründe sprechen dafür, dass Kerberos das bessere Authentifizierungs-Protokoll ist, verglichen mit NTLM. Bei Kerberos wird der Kennwort-Hash-Wert des Benutzerkontos nicht so häufig verwendet im Vergleich zu NTLM. Lediglich beim Anfordern eines TGT wird dieser Hash-Wert genommen – und somit prinzipiell nur alle acht Stunden einmal.
Der Kennwort-Hash-Wert beim NTLM wird dagegen jedes Mal verwendet, wenn der Client sich über NTLM an einem Server authentifiziert. Daraus leitet sich ein großer Sicherheitsvorteil für Kerberos (im Vergleich zu NTLM) ab. Denn es gibt Tools, die den Netzwerkverkehr scannen und darin Kennwort-Hash-Werte herausfinden können. Sind diese Hash-Werte dann in den falschen Händen, kann man auf sie einen Brute-Force-Angriff ausführen und so recht zügig das Kennwort des Benutzers ermitteln.
Ein weiterer Vorteil von Kerberos ist der Einsatz von Zeitstempeln, um einen Schutz vor Replay-Attacken zu gewährleisten. Das ist auch der Grund, warum der Zeitsynchronisationsdienst in einer Kerberos-basierten Windows-Umgebung perfekt arbeiten muss. Ab Windows 2000 ist diese Zeitsynchronisation bereits im System enthalten. Laufen die Zeitgeber von Systemen nicht synchron, kann das zu einer höheren Belastung in Folge des Authentifizierungs-Verkehrs führen. Und im schlimmsten Fall kann die Authentifizierung über Kerberos sogar ganz ausfallen.
Erweiterte Authentifizierungs-Möglichkeiten sind bei Kerberos ebenfalls machbar. Die gegenseitige Authentifizierung zum Beispiel hat zur Folge, dass sich der Benutzer und der angesprochene Dienst gegenseitig authentifizieren. Beim NTLM ist dagegen nur die Authentifizierung des Anwenders machbar. Ohne eine gegenseitige Authentifizierung lassen sich Angriffe fahren, bei denen ein Server dem Client vorgaukelt, er wäre ein anderes System (ein so genannter Bogus Server). Wenn der Benutzer an diesen falschen Server seine Anmeldeinformationen sendet, öffnen sich die Pforten für den Angreifer.
Ein Dienst kann auf entfernte Ressourcen anstelle eines Benutzers zugreifen. Dazu muss aber die Authentifizierung delegiert werden können. Anders ausgedrückt: Ein Benutzer kann seine Rechte zeitweise an ein zwischengeschaltetes System weiter geben, damit es sich anstelle des Benutzers an einem Applikations-Server anmelden kann.
Damit ist der Applikations-Server in der Lage, Entscheidungen zum Erlauben des Zugriffs basierend auf der Identität des Benutzers und nicht des zwischengeschalteten Systems zu machen. Diese Funktionalität erweist sich vor allem bei Multi-tier-Applikationen als eine wertvolle Ergänzung – etwa wenn der Zugriff auf eine Datenbank über ein web-basiertes Frontend-System erfolgt.
Ein weiterer Vorteil von Kerberos liegt im Einsatz der Verschlüsselungs-Algorithmen. Selbst wenn Microsoft mit der Version 2 von NTLM (NTLMv2, es ist ab dem Servicepack 4 von Windows NT im Einsatz) einige Verbesserungen einfließen hat lassen, so greift Kerberos doch auf aktuellere Algorithmen zurück.
Einschränkungen für das NTLM
Die Frage nach dem besseren Authentifizierungs-Protokoll entscheidet Kerberos ganz klar für sich. Doch selbst in einer Umgebung mit Windows Server 2008 Release 2 (R2) wird oft noch auf NTLM zurückgegriffen. Zum Beispiel wird auf NTLM zurückgegriffen, wenn es eine Verbindung zu einem System mit einer Betriebssystemversion vor Windows 2000 herzustellen gilt.
Eine andere Situation für den NTLM-Einsatz ist das Verbinden mit einer Netzfreigabe mit Hilfe von „net use“ und einer IP-Adresse (anstelle eines NetBIOS-Namens). Aber auch Applikationen, bei denen keine sauber konfigurierten SPNs (Service Principal Names) vorliegen, verwenden das NTLM.
Ein Administrator kann herausfinden, ob Kerberos oder NTLM verwendet wird. Dazu muss er einen Netzwerk-Tracer wie Netmon verwenden, um sich den NTLM-Verkehr anzeigen zu lassen. Oder aber er kann den Inhalt des Kerberos Ticket Cache prüfen. Dazu gibt es das Tool „klist“ (es ist bei Windows 7 und Windows Server 2008 enthalten).
Bei Windows 7 und Windows Server 2008 bringt Microsoft Gruppenrichtlinien ins Spiel, mit denen man den Einsatz von NTLM verfolgen und sogar blockieren kann – für Benutzer und für Applikationen. Generell stehen drei dieser Richtlinien zur Verfügung:
- eine für den eingehenden NTLM-Verkehr (für das Verfolgen und Absperren auf Server-Ebene),
- eine für den ausgehenden NTLM-Verkehr (für das Verfolgen und Absperren auf Client-Ebene) und
- eine für den Domänen-Verkehr (für das Verfolgen und Absperren auf DC-Ebene).
Die Richtlinien liegen unter Computerkonfiguration/Windows-Einstellungen/Sicherheitseinstellungen/Lokale Richtlinien/Sicherheitsoptionen. Sie beginnen mit dem Text: Netzwerksicherheit: Beschränken von NTLM
Eine jede Richtlinieneinstellung verfügt über Optionen für das Überwachen und Blockieren (sprich Deaktivieren). Wird die NTLM-Überwachung aktiviert, erfolgen Einträge im Ereignisprotokoll, bei denen die Quelle NTLM ist und die Ereigniskennungen (Event IDs) 8001, 8002, 8003 sowie 8004 lauten. Diese Protokolleinträge liegen in der lokalen Ereignisanzeige und dort im Container zu den Applikationen und Diensten (Microsoft/Windows/NTLM/Operational).
Wer NTLM überwachen möchte, sollte das zuerst in einer Testumgebung ausprobieren. Dabei sollte die Testumgebung aber auch einigermaßen repräsentativ für die Produktivumgebung mit allen Applikationen sein. Dann kann man dazu übergehen, einzelne Aspekte einzuschränken. Unter Umständen wird dann auch die eine oder andere Applikation nicht mehr funktionieren.
Um sicherzustellen, dass keine Protokolleinträge verloren gehen, sollte noch ein Tool das Sammeln der Protokolleinträge übernehmen, ehe man an das Überwachen des NTLM geht. Hierzu verfügt Windows selbst über den Event Collector Service. Ansonsten stehen Werkzeuge von Drittanbietern – wie etwa Event Subscriptions – zur Verfügung.
Des Weiteren sollte man zuerst das Überwachen des NTLM bei seinen Servern aktivieren. Die detaillierte Analyse auch im Client-Bereich sollte man als zweiten Schritt vorsehen. Denn das wird einfacher, wenn der Einsatz des NTLM bei den Servern einem schon klar ist. Nachdem so ermittelt wurde, welche Applikationen noch NTLM verwenden, kann man sich eine Strategie für das Blockieren des NTLM überlegen. Dabei sollte der Administrator die älteren Applikationen von diesem Blockiervorgang ausschließen, die sich nicht umkonfigurieren oder gar neu schreiben lassen. Denn sie werden nach wie vor NTLM benötigen.
Leider lassen sich diese Einschränkungen für NTLM nicht auf älteren Windows-Systemen verwenden. Doch es steht einem frei, die NTLM-Protokollversionen auf diesen älteren Systemen zu kontrollieren. Dabei kann der Administrator den LM-Anteil (LAN Manager) des Authentifizierungsprotokolls NTLM (der sich als sehr schwach herausgestellt hat) deaktivieren oder aber man kann den Einsatz von NTLMv2 erzwingen.
Dazu gibt es im Bereich der Netzwerksicherheit eine Einstellung in den Richtlinien (wieder unter Computerkonfiguration/Windows-Einstellungen/Sicherheitseinstellungen/Lokale Richtlinien/Sicherheitsoptionen) mit der Bezeichnung LAN Manager Authentifizierungsebene.
Verschlüsselung bei Kerberos
Die Verschlüsselungs-Protokolle, die bei den Authentifizierungs-Protokollen zum Einsatz kommen, bestimmen im hohen Maß die Qualität der Lösung – und somit ihre Sicherheit. Kerberos schneidet hier weitaus besser ab als NTLM. Der RC4-Verschlüsselungs-Algorithmus wurde bei Kerberos bereits seit Windows 2000 unterstützt. Dies gilt heute noch für Windows Server 2008 und Windows 7 – genauer gesagt wird RC4_HMAC_MD5 unterstützt.
Dazu hat Microsoft noch den Advanced Encryption Standard (AES) in Windows Server 2008, Windows Vista und neueren Windows-Versionen eingebaut. Für Windows 7 und Windows Server 2008 R2 finden AES128_HMAC_SHA1 und AES256_HMAC_SHA1 Unterstützung. Beim AES handelt es sich um einen stärkeren Algorithmus als beim DES. Die Kerberos-Logik auf den DCs wird auf den AES-Verschlüsselungstyp umgestellt, wenn man die AD-Domäne auf das „Domain Functional Level“ von Windows 2008 bringt.
Die DES-Verschlüsselungstypen für Kerberos werden bei Windows 7 und Windows Server 2008 R2 standardmäßig deaktiviert. Dadurch kann es unter Umständen zu Kompatibilitätsproblemen kommen, wenn zum Beispiel eine ältere Applikation eine Verschlüsselung nach DES „erwartet“.
Es kann aber auch sein, dass ein Windows-Konto, das einen Dienst ausführt (also ein Dienstkonto, Service Account) so konfiguriert ist, dass es DES verwendet. Dann werden diese Applikationen oder Dienste nicht funktionieren – solange man den Dienst oder die Anwendung nicht auf die Unterstützung von anderen Verschlüsselungstypen (wie eben AES oder als „Fallback“ das alte RC4) umstellen kann. Ein anderer Ausweg – allerdings nicht mehr zeitgemäß – ist das erneute Aktivieren der DES-Unterstützung.
Um herauszufinden, ob eine Applikation oder ein Dienst unbedingt die DES-Verschlüsselung benötigen, muss der Administrator einen Netzwerk-Trace ziehen. Wichtig sind die Zeitpunkte für das Starten des Services oder der Anwendung. Hier ist im Kerberos-Authentifizierungs-Header der Inhalt des Feld Etype zu prüfen
Um zu bestimmen ob ein AD-Benutzer oder -Computerkonto beziehungsweise ein Computerkonto nur für die DES-Verschlüsselung konfiguriert ist, bedarf es des Einsatzes des Snap-ins ASD Benutzer und-Computer. Hier lässt sich im Reiter Konten der Objekteigenschaften ersehen, welche Verschlüsselungstypen gesetzt sind.
Wer diese Test gemacht hat und bemerkt, dass er dieses Problem hat, der kann den DES-Verschlüsselungstyp für die Kerberos-Authentifizierung aktivieren. Bei Systemen mit Windows 7 oder Windows Server 2008 R2 ist das erneut unter Netzwerksicherheit (unter Computerkonfiguration/Windows-Einstellungen/Sicherheitseinstellungen/Lokale Richtlinien/Sicherheitsoptionen) zu tun. Hier gibt es die Richtlinie „Für Kerberos zulässige Verschlüsselungstypen konfigurieren“ (siehe Abbildung 2), die sich über einen Dialog mit Checkboxen ändern lässt.
