Dies ist etwas, das ich nie so gut beantworten konnte, wie es mir gefällt: Was ist der wahre Vorteil der Verwendung der Kerberos-Authentifizierung in IIS anstelle von NTLM?
Ich habe viele Leute gesehen, die wirklich Mühe hatten, es einzurichten (ich selbst eingeschlossen), und ich konnte keinen guten Grund finden, es zu benutzen. Es muss aber einige ziemlich bedeutende Vorteile geben, sonst wäre es den ganzen Aufwand nicht wert, es einzurichten, oder?
Antworten:
Nur aus Windows-Sicht:
MaxConcurrentAPI, AuthPersistSingleRequest(false) ., Schneller DCs) ( Self- Referenzbonus .)lmcompatibilitylevel)Möglicherweise kann ein Proxy durchlaufen werden. Beachten Sie jedoch den obigen DC-Punkt: Sie müssen sich ebenso wie der Server im selben Netzwerk wie ein aktiver DC befinden .
Ticket ist langlebig (10h) , was bedeutet weniger DC - Kommunikation bei der Ticket Lebensdauer - und betont: diese Tausende bis Millionen von Anfragen retten konnte pro Client über dieses Leben - ( AuthPersistNonNTLMist immer noch eine Sache, die Kerberos - PAC Validierung verwendet , um eine Sache zu sein)
UserAden Zugriff auf IIS zuzulassen und dasselbe Benutzerkonto zu verwenden, wenn IIS auf SQL Server zugreift, wird die Authentifizierung delegiert.KRB_ERR_AP_MODIFIED)Während wir gerade dabei sind:
LogonTypeMöglicherweise muss das konfiguriert werden, um dies zu erreichen. (Denken Sie, die Standardeinstellung wurde zwischen 2000 und 2003 in Netzwerkklartext geändert, kann aber falsch sein.)Um zusammenzufassen:
Das Einrichten von Curb kann schwierig sein, aber es gibt viele Anleitungen ( meine ), die versuchen, den Prozess zu vereinfachen, und die Tools haben sich von 2003 bis 2008 erheblich verbessert ( SetSPNSuche nach Duplikaten, was das häufigste Problem ist) ; VerwendenSETSPN -S Sie diese Option, wenn Sie eine Anleitung zur Verwendung von -A sehen, und das Leben wird glücklicher).
Eine eingeschränkte Delegation ist die Eintrittskosten wert.
Ein anderer Ansatz wäre, die Authentifizierung auf negotiatebeide anstatt auf einen anderen zu setzen und diesen zu verwenden.
Aus dem Microsoft Application Verifier , der häufig auftretende 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 beeinträchtigen. Das wichtigste Manko ist die fehlende Serverauthentifizierung, durch die ein Angreifer Benutzer dazu verleiten kann, 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, die als Reflexionsangriff bezeichnet wird. Letzteres ermöglicht es einem Angreifer, die Authentifizierungskonversation eines Benutzers mit einem legitimen Server zu missbrauchen und den Angreifer auf dem Computer des Benutzers zu authentifizieren. Die Schwachstellen von NTLM und ihre Ausnutzung sind das Ziel einer verstärkten 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 die Sicherheit von Anwendungen unnötig. Kerberos kann jedoch NTLM nicht in allen Szenarien ersetzen - vor allem dann, wenn ein Client sich bei Systemen authentifizieren muss, die keiner Domäne angehören (wobei ein Heimnetzwerk möglicherweise das häufigste ist). Das Negotiate-Sicherheitspaket ermöglicht einen abwärtskompatiblen Kompromiss, der nach Möglichkeit Kerberos verwendet und nur dann zu NTLM zurückkehrt, wenn es keine andere Option gibt. Durch die Umstellung des Codes auf Negotiate anstelle von NTLM wird die Sicherheit für unsere Kunden erheblich erhöht, und es werden nur wenige oder keine Anwendungskompatibilitäten eingeführt. Allein zu verhandeln ist kein Wundermittel - es gibt Fälle, in denen ein Angreifer ein Downgrade auf NTLM erzwingen kann, die jedoch erheblich schwieriger auszunutzen sind. Eine sofortige Verbesserung ist jedoch, dass Anwendungen, die für die korrekte Verwendung von Negotiate geschrieben wurden, automatisch immun gegen NTLM-Reflexionsangriffe sind.
Ein letzter Hinweis, der vor der Verwendung von NTLM warnt: In zukünftigen Versionen von Windows wird es möglich sein, die Verwendung von NTLM unter dem Betriebssystem zu deaktivieren. Wenn Anwendungen eine harte Abhängigkeit von NTLM haben, können sie sich einfach nicht authentifizieren, wenn NTLM deaktiviert ist.
Sie sollten einen sehr wichtigen Punkt hinzufügen:
Kerberos ist seit über 20 Jahren Standard und offenes Protokoll in Unix, wohingegen NTLM eine reine proprietäre Lösung von Microsoft ist und nur Microsoft bekannt ist.
Kerberos ist erforderlich, wenn Sie sich als Benutzer ausgeben müssen, um auf Ressourcen zuzugreifen, die sich nicht auf dem iis-Server befinden.