it-swarm.com.de

Warum Kerberos anstelle von NTLM in IIS verwenden?

Dies ist etwas, das ich nie so gut beantworten konnte, wie ich möchte: Was ist der wahre Vorteil der Verwendung der Kerberos-Authentifizierung in IIS anstelle von NTLM?

Ich habe viele Leute gesehen, die wirklich Schwierigkeiten hatten, es einzurichten (ich selbst eingeschlossen), und ich konnte keinen guten Grund finden, es zu verwenden. Es muss jedoch einige ziemlich bedeutende Vorteile geben, sonst wäre es nicht die Mühe wert, es einzurichten, oder?

42
Infotekka

Nur aus Windows-Sicht:

NTLM

  • funktioniert mit both external (non-domain) und internal Kunden
  • funktioniert sowohl mit Domänenkonten als auch mit lokalen Benutzerkonten auf dem IIS box
    • bei Verwendung von Domänenkonten erfordert nur der Server eine direkte Verbindung zu einem Domänencontroller (DC).
    • wenn Sie lokale Konten verwenden, benötigen Sie nirgendwo Konnektivität :)
    • sie müssen nicht als der betreffende Benutzer angemeldet sein, um einen Berechtigungsnachweis zu verwenden
    • Nebenbei: Es ist nicht ungewöhnlich, dass ein DC von einem ausgelasteten NTLM-Server (IIS, Exchange, TMG/ISA usw.) mit dem Volumen von überfordert ist NTLM-Anforderungen (um Folgendes zu mildern: MaxConcurrentAPI , AuthPersistSingleRequest (false) , schnellere DCs.) ( Selbstreferenzieller Bonus .)
  • erfordert Client-Konnektivität nur zum IIS Server (am Site-Port, nichts anderes. dh Alles geschieht über HTTP (oder HTTPS).)
  • kann jeden Proxy durchlaufen, der HTTP Keep-Alive s unterstützt.
    • möglicherweise können Sie TLS/SSL verwenden, um andere zu umgehen
  • erfordert mehrere Roundtrips zur Authentifizierung mit kleinen Paketen
    • (Protokollmuster ist 401.2, 401.1, 200 mit Benutzername)
  • kann nicht in Szenarien verwendet werden, in denen eine Double-Hop-Authentifizierung erforderlich ist
    • d.h. die Anmeldeinformationen des Benutzers sollen an einen Dienst auf einem anderen Computer weitergeleitet werden
  • unterstützt ältere Clients (<Win2000)
  • Ist anfällig für Abweichungen auf der LM Auth-Ebene (nicht übereinstimmend lmcompatibilitylevel )
  • wird vom Negotiate-Paket als Fallback verwendet, wenn Curb fehlschlägt.
    • ( nicht "Wenn der Zugriff verweigert mit Curb ist", muss Curb break für die Verwendung von NTLM - normalerweise sieht es so aus, als würde man kein Ticket bekommen. Wenn der Kunde ein Ticket erhält und es nicht perfekt ist, führt dies nicht zu einem Fallback.)

Kerberos

  • funktioniert mit derzeit nur Domain-verbundenen Clients
    • erfordert Client-Konnektivität zu einem AD DC (tcp/udp 88) UND dem Server (Tickets werden vom Client vom DC über den Curb-Port abgerufen und dann über HTTP an den Server gesendet)
  • könnte in der Lage sein, einen Proxy zu durchlaufen, aber siehe DC Punkt oben: Sie müssen es noch sein im selben Netzwerk wie ein aktiver DC, ebenso wie der Server.

    • also theoretisch Wenn Sie eine Domain hatten, in der mit dem Internet verbundene Clients direkt mit einem mit dem Internet verbundenen DC chatten, ist dies funktionsfähig. Aber tu das nicht es sei denn, du wusstest das schon.
    • In Reverse-Proxy-Szenarien (ISA/TMG) ​​muss sich der Server Protokollübergang in diesem Netzwerk befinden, dh nicht der Client ... aber dann ist der Client nicht wirklich derjenige, der das Kerberos-Bit ausführt ( unbedingt - denken Sie, Forms auth to Curb Transition).
  • Ticket ist langlebig (10h) bedeutet weniger DC Kommunikation während der Lebensdauer des Tickets - und um zu betonen: Dies könnte Tausende bis Millionen von Anfragen einsparen pro Kunde während dieser Lebensdauer - - (AuthPersistNonNTLM ist immer noch eine Sache; Kerberos PAC-Validierung war früher eine Sache)

  • erfordert eine einzelne Hin- und Rückfahrt zur Authentifizierung, aber die Nutzlast der Authentifizierung ist relativ groß (üblicherweise 6-16 KB) ( 401 , {(codierte) Tokengröße} 200 )
  • kann mit (bitte immer eingeschränkt) Delegierung verwendet werden, um die Windows-Authentifizierung des verbindenden Benutzers zum nächsten Dienst zu aktivieren
    • um beispielsweise UserA den Zugriff auf IIS zu ermöglichen und dasselbe Benutzerkonto zu verwenden, wenn IIS greift auf SQL Server zu, ist dies "Delegierung der Authentifizierung".
    • ( Eingeschränkt bedeutet in diesem Zusammenhang "aber nichts anderes", z. B. Exchange oder eine andere SQL-Box)
  • ist derzeit das primäre Sicherheitspaket für die Verhandlungsauthentifizierung
    • dies bedeutet, dass Windows-Domänenmitglieder es bevorzugen, wenn sie es erhalten können
  • erfordert die Registrierung von SPNs , was schwierig sein kann. Regeln, die helfen .
  • erfordert die Verwendung eines Namens als Ziel, nicht einer IP-Adresse
  • gründe, warum Curb fehlschlagen könnte:
    • verwenden einer IP-Adresse anstelle eines Namens
    • kein SPN registriert
    • doppelte SPNs registriert
    • SPN gegen falsches Konto registriert (KRB_ERR_AP_MODIFIED)
    • kein Client-DNS/DC Konnektivität
    • client-Proxy-Einstellung/Lokale Intranetzone wird nicht für den Zielstandort verwendet

Während wir gerade dabei sind:

Basic

  • kann Multi-Hop. Dies geschieht jedoch, indem Sie Ihren Benutzernamen und Ihr Passwort direkt der Ziel-Web-App Offenlegen.
    • die dann mit ihnen alles machen können, was sie wollen. Alles.
    • "Oh, hat ein Domain-Administrator gerade meine App verwendet? Und habe ich gerade ihre E-Mail gelesen? Dann ihr Passwort zurückgesetzt? Awww. Schade"
  • benötigt Transportschichtsicherheit (d. h. TLS/SSL) für jede Form von Sicherheit.
    • und dann siehe vorherige Ausgabe
  • funktioniert mit jedem Browser
    • (aber siehe erste Ausgabe)
  • erfordert eine einzelne Hin- und Rückfahrt zur Authentifizierung ( 401 , 200 )
  • kann in Multi-Hop-Szenarien verwendet werden, da Windows eine interaktive Anmeldung mit grundlegenden Anmeldeinformationen durchführen kann
    • Möglicherweise muss das LogonType konfiguriert werden, um dies zu erreichen (denken Sie, dass die Standardeinstellung zwischen 2000 und 2003 in Netzwerk-Klartext geändert wurde, sich aber möglicherweise falsch erinnert).
    • aber wieder, siehe erste Ausgabe.
    • Den Eindruck bekommen, dass die erste Ausgabe wirklich sehr, sehr wichtig ist? Es ist.

Zusammenfassend:

Die Einrichtung von Curb kann schwierig sein, aber es gibt eine Menge Anleitungen ( meine ), die versuchen, den Prozess zu vereinfachen, und die Tools haben sich verbessert erheblich von 2003 bis 2008 (SetSPN kann nach Duplikaten suchen, was das häufigste Problem ist; benutze SETSPN -S wann immer Sie eine Anleitung zur Verwendung von -A sehen und das Leben glücklicher wird).

Eine eingeschränkte Delegation ist die Eintrittskosten wert.

68
TristanK
  • Kerberos hat den Ruf, ein schnellerer und sicherer Authentifizierungsmechanismus als NTLM zu sein.
  • Aufgrund der verbindungsbasierten Natur von NTLM war es in der Vergangenheit auch einfacher, eine Verbindung über Proxyserver herzustellen als über NTLM.
  • Wie Sie bemerken, ist Kerberos jedoch schwieriger in Betrieb zu nehmen und erfordert eine Verbindung zum AD, die nicht immer praktisch ist.

Ein anderer Ansatz wäre, die Authentifizierung auf negotiate zu setzen und beide anstelle des einen anstelle des anderen zu verwenden.

10
nedm

Aus dem Microsoft Application Verifier , der häufige Entwicklerfehler erkennt. Einer dieser Fehler ist die Verwendung von NTLM :

NTLM ist ein veraltetes Authentifizierungsprotokoll mit Fehlern, die möglicherweise die Sicherheit von Anwendungen und des Betriebssystems gefährden. Das wichtigste Manko ist das Fehlen einer Serverauthentifizierung, die es einem Angreifer ermöglichen könnte, Benutzer dazu zu verleiten, eine Verbindung zu einem gefälschten Server herzustellen. Als Folge der fehlenden Serverauthentifizierung können Anwendungen, die NTLM verwenden, auch für eine Art von Angriff anfällig sein, der als "Reflection" -Angriff bezeichnet wird. Letzteres ermöglicht es einem Angreifer, die Authentifizierungskonversation eines Benutzers an einen legitimen Server zu entführen und damit den Angreifer beim Computer des Benutzers zu authentifizieren. Die Schwachstellen und Möglichkeiten von NTLM, sie auszunutzen, sind das Ziel einer Steigerung der Forschungstätigkeit in der Sicherheitsgemeinschaft.

Obwohl Kerberos seit vielen Jahren verfügbar ist, sind viele Anwendungen immer noch so geschrieben, dass sie nur NTLM verwenden. Dies verringert unnötig die Sicherheit von Anwendungen. Kerberos kann NTLM jedoch nicht in allen Szenarien ersetzen - hauptsächlich in solchen, in denen sich ein Client bei Systemen authentifizieren muss, die keiner Domäne angehören (ein Heimnetzwerk ist möglicherweise das häufigste davon). Das Negotiate-Sicherheitspaket ermöglicht einen abwärtskompatiblen Kompromiss, bei dem Kerberos nach Möglichkeit verwendet wird und nur dann auf NTLM zurückgegriffen wird, wenn keine andere Option vorhanden ist. Durch die Umstellung des Codes auf Negotiate anstelle von NTLM wird die Sicherheit für unsere Kunden erheblich erhöht, während nur wenige oder keine Anwendungskompatibilitäten eingeführt werden. Verhandeln an sich ist keine Wunderwaffe - es gibt Fälle, in denen ein Angreifer ein Downgrade auf NTLM erzwingen kann, aber diese sind wesentlich schwieriger auszunutzen. Eine sofortige Verbesserung besteht jedoch darin, dass Anwendungen, die für die korrekte Verwendung von Negotiate geschrieben wurden, automatisch gegen NTLM-Reflexionsangriffe immun sind.

Als letzte Warnung vor der Verwendung von NTLM: In zukünftigen Windows-Versionen kann die Verwendung von NTLM unter dem Betriebssystem deaktiviert werden. Wenn Anwendungen eine starke Abhängigkeit von NTLM haben, können sie sich einfach nicht authentifizieren, wenn NTLM deaktiviert ist.

10
Ian Boyd

Sie sollten einen sehr wichtigen Punkt hinzufügen:

Kerberos ist seit über 20 Jahren ein Standard- und offenes Protokoll in Unix, während NTLM eine rein proprietäre Lösung von Microsoft ist und nur Microsoft bekannt ist.

4
Michael-O

Kerberos ist erforderlich, wenn Sie sich als Benutzer ausgeben müssen, um auf Ressourcen zuzugreifen, die sich nicht auf dem iis-Server befinden.

1
Greg Askew