Frage Warum Kerberos anstelle von NTLM in IIS verwenden?


Das ist etwas, was ich nie wirklich so gut beantworten konnte: Was ist der eigentliche Vorteil der Kerberos-Authentifizierung in IIS anstelle von NTLM?

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


38
2018-04-01 23:04


Ursprung




Antworten:


Nur aus einer Windows-Perspektive:

NTLM

  • arbeitet mit beide  extern (Nicht-Domäne) und intern Kunden
  • arbeitet mit beiden zusammen Domänenkonten und lokale Benutzerkonten auf dem IIS-Feld
    • Verwenden von Domänenkonten nur der Server erfordert direkte Verbindung zu einem Domänencontroller (DC)
    • Mit lokalen Accounts brauchen Sie nirgends Konnektivität :)
    • Sie müssen nicht als Benutzer angemeldet sein, um einen Berechtigungsnachweis zu verwenden
    • Beiseite: Es ist nicht ungewöhnlich, dass ein Domänencontroller von einem ausgelasteten NTLM-Server (IIS, Exchange, TMG / ISA usw.) mit dem Volume von NTLM-Anforderungen überlastet wird (um Folgendes zu mindern: MaxConcurrentAPI, AuthPersistSingleRequest (falsch), schnellere DCs.) (Selbstreferenzieller Bonus.)
  • erfordert Client-Konnektivität nur zum IIS Server (auf dem Standort-Port, nichts anderes. Alles passiert über HTTP (oder HTTPS).)
  • kann jeden Proxy-Support durchlaufen HTTP-Keep-Alives
    • Möglicherweise können Sie TLS / SSL verwenden, um andere zu umgehen
  • erfordert mehrere Rundreisen authentifizieren, mit kleine Pakete
    • (Protokollmuster ist 401.2, 401.1, 200 mit Benutzername)
  • kann nicht in Szenarien verwendet werden, in denen eine Doppelsprung-Authentifizierung erforderlich ist
    • d.h. die Anmeldeinformationen des Benutzers müssen an einen Dienst auf einem anderen Computer weitergeleitet werden
  • unterstützt ältere Clients (<Win2000)
  • Ist anfällig für LM Auth Level Diskrepanzen (nicht übereinstimmend lmcompatibilitylevel)
  • Wird vom Negotiate-Paket als Fallback verwendet, wenn Curb nicht funktioniert.
    • (nicht "Wenn der Zugang ist abgelehnt mit Curb ", muss Curb brechen für NTLM verwendet werden - normalerweise sieht das so aus, als ob man kein Ticket bekommt. Wenn der Kunde ein Ticket bekommt und es nicht perfekt ist, verursacht das keinen Fallback.

Kerberos

  • arbeitet mit zur Zeit Nur für Domänen verbundene Clients
    • erfordert Client-Konnektivität zu einem AD DC (tcp / udp 88) UND der Server (Tickets werden vom Client vom DC über den Curb-Port abgerufen und dann über HTTP an den Server übermittelt)
  • könnte in der Lage sein, einen Proxy zu durchlaufen, aber siehe DC-Punkt oben: Sie müssen sich immer noch im selben Netzwerk wie ein aktiver Domänencontroller befinden, genau wie der Server.

    • so in der Theorie Wenn Sie eine Domäne haben, in der mit dem Internet verbundene Clients direkt mit einem mit dem Internet verbundenen DC chatten, ist dies praktikabel. Aber Tu das nicht Es sei denn, du wusstest das schon.
    • In Reverse-Proxy-Szenarien (ISA / TMG) ​​ist der Protokollübergang Server muss in diesem Netzwerk sein, d. h. nicht der Client ... aber dann ist der Client nicht wirklich derjenige, der das Kerberos-Bit tut (notwendigerweise - denke, dass Forms Auth zum Curb-Übergang ist).
  • Ticket ist langlebig (10h) Bedeutung weniger DC-Kommunikation während der Ticket-Lebensdauer - und zu betonen: dies könnte Tausende von Millionen von Anfragen speichern  pro Kunde über dieses Leben - (AuthPersistNonNTLM ist immer noch eine Sache; Kerberos-PAC-Validierung war mal eine Sache)

  • benötigt ein einfache Hin- und Rückfahrt zu authentifizieren, aber die Authentifizierung Nutzlastgröße ist relativ groß (gewöhnlich 6-16K) (401, {(codierte) Tokengröße} 200)
  • kann mit verwendet werden (bitte immer eingeschränkt) Delegation Aktivieren der Windows-Authentifizierung des verbindenden Benutzers für den nächsten Dienst
    • zum Beispiel zu ermöglichen UserA Um auf IIS zuzugreifen und dasselbe Benutzerkonto zu verwenden, wenn IIS auf SQL Server zugreift, handelt es sich um "Delegierung der Authentifizierung".
    • (Eingeschränkt bedeutet in diesem Zusammenhang "aber nichts anderes", zB Exchange oder eine andere SQL-Box
  • ist derzeit das primäre Sicherheitspaket für die Negotiate-Authentifizierung
    • Das bedeutet, dass Windows-Domänenmitglieder es bevorzugen, wenn sie es bekommen können
  • erfordert Registrierung von SPNs, was schwierig sein kann. Regeln, die helfen.
  • erfordert die Verwendung von a Name als Ziel, keine IP-Adresse
  • Gründe, warum Curb versagen könnte:
    • Verwenden einer IP-Adresse anstelle eines Namens
    • Kein SPN registriert
    • doppelte SPNs registriert
    • SPN registriert gegen falsches Konto (KRB_ERR_AP_MODIFIED)
    • Keine Client-DNS / DC-Verbindung
    • Client-Proxy-Einstellung / Lokale Intranetzone wird nicht für die Zielsite verwendet

Während wir dabei sind:

Basic

  • kann Multi-Hop. Tut es aber durch Den Benutzernamen und das Passwort direkt angeben zur Ziel-Web-App
    • was dann alles mit ihnen machen kann. Etwas.
    • "Oh, hat ein Domänenadministrator nur meine App verwendet? Und habe ich gerade ihre E-Mail gelesen? Dann setzen Sie ihr Passwort zurück? Awww. Das Mitleid"
  • braucht Sicherheit der Transportschicht (d. h. TLS / SSL) für irgendeine Form von Sicherheit.
    • und dann, siehe vorherige Ausgabe
  • funktioniert mit jedem Browser
    • (aber siehe erste Ausgabe)
  • benötigt ein einfache Hin- und Rückfahrt authentifizieren (401, 200)
  • kann in Multi-Hop-Szenarien verwendet werden, da Windows eine interaktive Anmeldung mit grundlegenden Anmeldeinformationen ausführen kann
    • Kann das brauchen LogonType konfiguriert werden, um dies zu erreichen (denken Sie daran, dass die Standardeinstellung zwischen 2000 und 2003 in Netzwerk-Klartext geändert wurde, aber möglicherweise falsch ist)
    • aber nochmal, siehe erste Ausgabe.
    • Der Eindruck entsteht, dass die erste Ausgabe ist wirklich, wirklich wichtig? Es ist.

Um zusammenzufassen:

Curb kann schwierig einzurichten sein, aber es gibt viele Guides (mein einer) da draußen, die versuchen, den Prozess zu vereinfachen, und die Werkzeuge haben sich verbessert erheblich von 2003 bis 2008 (SetSPN kann nach Duplikaten suchen, was das gebräuchlichste Problem ist; benutzen SETSPN -S Wann immer Sie eine Anleitung zur Verwendung von A sehen, und das Leben wird glücklicher sein.

Eine eingeschränkte Delegation ist die Kosten der Aufnahme wert.


64
2018-04-02 02:06



Technisch, Curb Client's nicht haben mit der Domäne / dem Bereich verbunden werden, den sie verwenden möchten. Solange sie Konnektivität mit dem Domänencontroller haben, können Sie beispielsweise runas mit dem Flag / netonly verwenden und einen Prozess im Kontext eines Domänenbenutzers starten, der immer noch ein gültiges TGT zieht, wenn die Domänencontroller über DNS-Abfragen gefunden werden können . Und selbst wenn DNS aufgebrochen ist, können Sie technisch mit Registrierungshinweisen mit ksetup.exe umgehen. Sie können ähnliche Dinge auch mit einem Linux-Client tun. Natürlich sind dies Kantenfälle. - Ryan Bolger


  • Kerberos hat den Ruf, ein schnellerer und sicherer Authentifizierungsmechanismus als NTLM zu sein.
  • Historisch war es aufgrund der verbindungsbasierten Natur von NTLM auch einfacher, eine Verbindung zu Proxy-Servern als NTLM herzustellen.
  • Wie Sie jedoch bemerken, ist Kerberos schwieriger aufzusetzen und erfordert eine Verbindung mit dem AD, die nicht immer praktisch ist.

Ein anderer Ansatz wäre das Festlegen der Authentifizierung negotiate und benutze beide statt einer statt der anderen.


10
2018-04-01 23:50





Von dem Microsoft-Anwendungsüberprüfer, die häufige Entwicklerfehler erkennt. Einer dieser Fehler ist die Verwendung von NTLM:

NTLM ist ein veraltetes Authentifizierungsprotokoll mit Fehlern   gefährden möglicherweise die Sicherheit der Anwendungen und des Betriebs   System. Der wichtigste Mangel ist der Mangel an Server   Authentifizierung, die es einem Angreifer ermöglichen könnte, Benutzer hereinzulegen   Verbindung zu einem gefälschten Server herstellen. Als eine Folge von fehlenden Server   Authentifizierung, Anwendungen mit NTLM können auch anfällig für eine sein   Art des Angriffs, der als "Reflektions" -Angriff bezeichnet wird. Letzteres ermöglicht ein   Angreifer, um die Authentifizierungskonversation eines Benutzers zu übernehmen   legitimer Server und verwenden Sie es, um den Angreifer zu authentifizieren   Computer des Benutzers. NTLMs Schwachstellen und Möglichkeiten, sie zu nutzen   sind das Ziel der zunehmenden Forschungstätigkeit in der Sicherheit   Gemeinschaft.

Obwohl Kerberos seit vielen Jahren viele Anwendungen verfügbar ist   werden immer noch geschrieben, um nur NTLM zu verwenden. Dies reduziert unnötig die   Sicherheit von Anwendungen. Kerberos kann NTLM jedoch nicht ersetzen   Szenarien - hauptsächlich solche, bei denen sich ein Client authentifizieren muss   Systeme, die nicht mit einer Domäne verbunden sind (ein Heimnetzwerk ist möglicherweise)   die häufigste von diesen). Das Negotiate-Sicherheitspaket ermöglicht a   rückwärtskompatibler Kompromiss, der Kerberos wann immer möglich verwendet   und kehrt nur zu NTLM zurück, wenn keine andere Option verfügbar ist. Codeumschaltung   Negotiate anstelle von NTLM zu verwenden, wird das deutlich erhöhen   Sicherheit für unsere Kunden bei gleichzeitiger Einführung von wenigen oder gar keinen Anwendungen   Kompatibilitäten. Verhandeln an sich ist keine Wunderwaffe - da   In Fällen, in denen ein Angreifer das Downgrade auf NTLM erzwingen kann, sind dies jedoch die Fälle   wesentlich schwieriger zu nutzen. Jedoch sofort   Verbesserung ist, dass Anwendungen geschrieben werden, um Negotiate richtig zu verwenden   sind automatisch gegen NTLM-Reflektionsangriffe immun.

Als letztes Wort der Vorsicht vor dem Einsatz von NTLM: in Zukunft   Versionen von Windows wird es möglich sein, die Verwendung von NTLM unter zu deaktivieren   das Betriebssystem. Wenn Anwendungen eine harte Abhängigkeit von NTLM haben   Sie werden einfach nicht authentifizieren, wenn NTLM deaktiviert ist.


9
2018-04-30 21:27



Schreckliches Zitat. Markierte es. - Michael-O


Sie sollten einen sehr wichtigen Punkt hinzufügen:

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


4
2017-08-09 19:17



Es ist von fast allen Desktop (Mac und Windows) und (modernen) mobilen Browsern bekannt. Also nicht nur "Microsoft". - Aardvark
Nein, nur aufgrund von Reverse Engineering. NTLM ist nicht offen, nicht öffentlich von Microsoft dokumentiert. Also, das ist ein sinnloser Sicherheitsmechanismus. - Michael-O
Ich weiß nicht, was drin ist, aber: msdn.microsoft.com/en-us/library/cc236621.aspx - thinkOfaNumber
@ ThinkOfaNumber, das ist bestätigt, wurde vor Jahren veröffentlicht, obwohl es keine einzige vollständige Open Source-NTLM-Implementierung gibt. Denk warum nicht? - Michael-O


Kerberos ist erforderlich, wenn Sie die Identität des Benutzers für den Zugriff auf Ressourcen benötigen, die sich nicht auf dem iis-Server befinden.


1
2018-04-02 04:00