Integrierte Windows-Authentifizierung mit erweitertem Schutz
Es wurden Verbesserungen vorgenommen, die beeinflussen, wie die integrierte Windows-Authentifizierung durch HttpWebRequest, HttpListener, SmtpClient, SslStream, NegotiateStream und verknüpfte Klassen in System.Net sowie verknüpfte Namespaces behandelt wird. Unterstützung für erweiterten Schutz wurde zur Verbesserung der Sicherheit hinzugefügt.
Diese Änderungen können sich auf Anwendungen auswirken, die diese Klassen für Webanforderungen und den Empfang der Antworten verwenden, in denen die integrierte Windows-Authentifizierung verwendet wird. Die Änderung kann sich auch auf Webserver und Clientanwendungen auswirken, die für die Verwendung der integrierten Windows-Authentifizierung konfiguriert sind.
Zudem können sich die Änderungen auf Anwendungen auswirken, die diese Klassen für andere Anforderungstypen verwenden und Antworten erhalten, in denen die integrierte Windows-Authentifizierung verwendet wird.
Die Änderungen zur Unterstützung des erweiterten Schutzes sind nur für Anwendungen verfügbar, die Windows 7 und Windows Server 2008 R2 ausführen. Die erweiterten Schutzfunktionen sind nicht für frühere Windows-Versionen verfügbar.
Übersicht
Durch die Gestaltung der integrierten Windows-Authentifizierung sind einige Abfragerückmeldungen zu Anmeldeinformationen universell, d.h. sie können wiederverwendet oder weitergeleitet werden. Die Abfragerückmeldungen sollten so konstruiert sein, dass sie mindestens über zielspezifische Informationen verfügen, vorzugsweise auch über einige kanalspezifische Informationen. Der erweiterte Schutz kann dann von Diensten bereitgestellt werden, damit Abfragerückmeldungen zu Anmeldeinformationen auch sicher dienstspezifische Informationen, wie z.B. einen Dienstprinzipalnamen (Service Principal Name, SPN), enthalten. Enthält der Austausch von Anmeldedaten diese Informationen, können die Dienste besser vor einer böswilligen Verwendung von Abfragerückmeldungen zu Anmeldeinformationen schützen, die möglicherweise nicht ordnungsgemäß verwendet wurden.
Die Gestaltung des erweiterten Schutzes stellt eine Verbesserung der Authentifizierungsprotokolle dar, um Relay-Angriffe auf die Authentifizierung zu verringern. Sie basiert auf Kanalbindungs- und Dienstbindungsinformationen.
Die Hauptziele lauten wie folgt:
Unterstützt der Client nach der Aktualisierung den erweiterten Schutz, sollten die Anwendungen allen unterstützten Authentifizierungsprotokollen Kanalbindungs- und Dienstbindungsinformationen bereitstellen. Kanalbindungsinformationen können nur bereitgestellt werden, wenn ein Kanal (TLS) vorhanden ist, an den sie sich binden können. Dienstbindungsinformationen sollten immer bereitgestellt werden.
Aktualisierte und ordnungsgemäß konfigurierte Server überprüfen möglicherweise die Kanalbindungs- und die Dienstbindungsinformationen, wenn sie im Clientauthentifizierungstoken vorhanden sind. Stimmen die Kanalbindungen nicht überein, wird der Authentifizierungsversuch abgelehnt. Je nach Bereitstellungsszenario überprüfen die Server möglicherweise die Kanalbindung, die Dienstbindung oder beides.
Aktualisierte Server können abwärtskompatible Clientanforderungen, die die Kanalbindungsinformationen der Richtlinie nicht enthalten, annehmen oder ablehnen.
Die durch den erweiterten Schutz verwendeten Informationen bestehen aus einem oder beiden der folgenden zwei Elemente:
einem Kanalbindungstoken oder CBT (Channel Binding Token)
Dienstbindungsinformationen in Form eines Dienstprinzipalnamens oder SPN (Service Principal Name)
Dienstbindungsinformationen deuten darauf hin, dass sich ein Client bei einem bestimmten Dienstendpunkt authentifizieren möchte. Sie werden mit den folgenden Eigenschaften vom Client zum Server übermittelt:
Der SPN-Wert muss für den Server, der die Clientauthentifizierung durchführt, als Klartext verfügbar sein.
Der SPN-Wert ist öffentlich.
Der SPN muss während der Übertragung kryptografisch geschützt sein, damit der Wert bei einem Man-in-the-Middle-Angriff nicht eingefügt, entfernt oder geändert werden kann.
Ein CBT ist eine Eigenschaft des gesicherten Außenkanals (z.B. TLS), die zur Kopplung (Bindung) an eine Konversation über einen clientauthentifizierten Innenkanal verwendet wird. Das CBT muss über die folgenden Eigenschaften verfügen (auch durch IETF RFC 5056 definiert):
Ist ein Außenkanal vorhanden, muss der CBT-Wert eine Eigenschaft sein, die entweder den Außenkanal oder den Serverendpunkt identifiziert. Sie muss auf beiden Seiten der Konversation unabhängig empfangen werden, sowohl beim Client als auch beim Server.
Der Wert des vom Client gesendeten CBT darf nicht von einem Angreifer beeinflusst werden können.
Es kann nicht garantiert werden, dass der CBT-Wert geheim bleibt. Dies bedeutet jedoch nicht, dass der Wert der Dienstbindungs- sowie der Kanalbindungsinformationen immer von einem beliebigen anderen Server als dem überprüft werden kann, der die Authentifizierung ausführt. Das Protokoll, das das CBT enthält, verschlüsselt ihn möglicherweise.
Das CBT muss während der Übertragung kryptografisch geschützt sein, damit der Wert von einem Angreifer nicht eingefügt, entfernt oder geändert werden kann.
Die Kanalbindung erfolgt durch den Client, der den SPN und das CBT manipulationsgeschützt an den Server überträgt. Der Server überprüft die Kanalbindungsinformationen anhand der Richtlinie und lehnt Authentifizierungsversuche ab, die er als nicht an ihn gerichtet einstuft. So werden die beiden Kanäle kryptografisch miteinander verbunden.
Damit die Kompatibilität mit vorhandenen Clients und Anwendungen erhalten bleibt, kann ein Server so konfiguriert werden, dass er Authentifizierungsversuche von Clients zulässt, die noch nicht den erweiterten Schutz unterstützen. Diese Konfiguration wird als „teilweise gehärtet“ bezeichnet, im Gegensatz zu einer „vollständig gehärteten“ Konfiguration.
Mehrere Komponenten der Namespaces System.Net und System.Net.Security führen die integrierte Windows-Authentifizierung für eine aufrufende Anwendung aus. In diesem Abschnitt werden die erforderlichen Änderungen an System.Net-Komponenten beschrieben, um den erweiterten Schutz ihrer Verwendung der integrierten Windows-Authentifizierung hinzuzufügen.
Der erweiterte Schutz wird derzeit für Windows 7 unterstützt. Über einen bereitgestellten Mechanismus ermittelt eine Anwendung, ob das Betriebssystem den erweiterten Schutz unterstützt.
Erforderliche Änderungen für den erweiterten Schutz
Der bei der integrierten Windows-Authentifizierung verwendete Authentifizierungsvorgang enthält je nach Authentifizierungsprotokoll häufig eine Abfrage, die vom Zielcomputer ausgegeben und an den Clientcomputer zurückgesendet wird. Der erweiterte Schutz fügt diesem Authentifizierungsvorgang neue Funktionen hinzu.
Der Namespace System.Security.Authentication.ExtendedProtection stellt Unterstützung für die Authentifizierung mit erweitertem Schutz für Anwendungen bereit. In diesem Namespace stellt die Klasse ChannelBinding die Kanalbindung dar. Die Klasse ExtendedProtectionPolicy stellt in diesem Namespace die erweiterte Schutzrichtlinie dar, die vom Server zur Validierung eingehender Clientverbindungen verwendet wird. Andere Klassenmember werden mit erweitertem Schutz verwendet.
Bei Serveranwendungen beinhalten diese Klassen:
Eine ExtendedProtectionPolicy mit den folgenden Elementen:
Eine OSSupportsExtendedProtection-Eigenschaft, die angibt, ob das Betriebssystem die integrierte Windows-Authentifizierung mit erweitertem Schutz unterstützt.
Ein PolicyEnforcement-Wert, der angibt, wann die erweiterte Schutzrichtlinie erzwungen werden soll.
Ein ProtectionScenario-Wert, der das Bereitstellungsszenario angibt. Dieser wirkt sich darauf aus, wie der erweiterte Schutz aktiviert wird.
Eine optionale ServiceNameCollection mit der benutzerdefinierten SPN-Liste für einen Abgleich mit dem vom Client bereitgestellten SPN als beabsichtigtem Ziel der Authentifizierung.
Eine optionale ChannelBinding mit einer benutzerdefinierten Kanalbindung zur Validierung. Dies ist kein häufiges Szenario.
Der Namespace System.Security.Authentication.ExtendedProtection.Configuration stellt Unterstützung für die Konfiguration der Authentifizierung mit erweitertem Schutz für Anwendungen bereit.
Bei einer Reihe von Funktionen wurden Änderungen vorgenommen, um den erweiterten Schutz im vorhandenen Namespace System.Net zu unterstützen. Dazu gehören folgende Änderungen:
Eine neue TransportContext-Klasse, die einen Transportkontext darstellt, im Namespace System.Net.
Neue Überladungsmethoden EndGetRequestStream und GetRequestStream in der Klasse HttpWebRequest zum Abrufen von TransportContext für die Unterstützung des erweiterten Schutzes bei Clientanwendungen.
Erweiterungen für die Klassen HttpListener und HttpListenerRequest zur Unterstützung von Serveranwendungen.
Eine Funktionsänderung wurde vorgenommen, um den erweiterten Schutz für SMTP-Clientanwendungen im vorhandenen Namespace System.Net.Mail zu unterstützen:
- Eine TargetName-Eigenschaft in der Klasse SmtpClient, die den zur Authentifizierung verwendeten SPN bei der Verwendung des erweiterten Schutzes in SMTP-Clientanwendungen darstellt.
Bei einer Reihe von Funktionen wurden Änderungen vorgenommen, um den erweiterten Schutz im vorhandenen Namespace System.Net.Security zu unterstützen. Dazu gehören folgende Änderungen:
Neue Überladungsmethoden BeginAuthenticateAsClient und AuthenticateAsClient in der Klasse NegotiateStream zur Übergabe eines CBT für die Unterstützung des erweiterten Schutzes bei Clientanwendungen.
Neue Überladungsmethoden BeginAuthenticateAsServer und AuthenticateAsServer in der Klasse NegotiateStream zur Übergabe einer ExtendedProtectionPolicy für die Unterstützung des erweiterten Schutzes bei Serveranwendungen.
Eine neue TransportContext-Eigenschaft in der Klasse SslStream für die Unterstützung des erweiterten Schutzes bei Client- und Serveranwendungen.
Eine SmtpNetworkElement-Eigenschaft wurde hinzugefügt, um die Konfiguration des erweiterten Schutzes für SMTP-Clients im Namespace System.Net.Security zu unterstützen.
Erweiterter Schutz für Clientanwendungen
Der erweiterte Schutz wird bei den meisten Clientanwendungen automatisch unterstützt. Die Klassen HttpWebRequest und SmtpClient unterstützen den erweiterten Schutz, wenn die zugrunde liegende Windows-Version den erweiterten Schutz unterstützt. Eine HttpWebRequest-Instanz sendet einen SPN, der aus dem Uri erstellt wird. Eine SmtpClient-Instanz sendet standardmäßig einen SPN, der aus dem Hostnamen des SMTP-Mailservers erstellt wird.
Clientanwendungen können zur benutzerdefinierten Authentifizierung die Methoden HttpWebRequest.EndGetRequestStream(IAsyncResult, TransportContext) oder HttpWebRequest.GetRequestStream(TransportContext) in der Klasse HttpWebRequest verwenden, die den TransportContext und das CBT mithilfe der Methode GetChannelBinding abrufen.
Sie können den von einer HttpWebRequest-Instanz an einen bestimmten Server gesendeten SPN zur integrierten Windows-Authentifizierung überschreiben, indem Sie die Eigenschaft CustomTargetNameDictionary festlegen.
Mit der Eigenschaft TargetName kann ein benutzerdefinierter SPN zur integrierten Windows-Authentifizierung für die SMTP-Verbindung festgelegt werden.
Erweiterter Schutz für Serveranwendungen
HttpListener stellt automatisch Mechanismen zur Validierung von Dienstbindungen bereit, wenn die HTTP-Authentifizierung ausgeführt wird.
Das sicherste Szenario ist die Aktivierung des erweiterten Schutzes für die Präfixe HTTPS://
. Legen Sie in diesem Fall HttpListener.ExtendedProtectionPolicy auf ExtendedProtectionPolicy fest, für das PolicyEnforcement auf WhenSupported oder Always festgelegt ist, sowie ProtectionScenario auf TransportSelected. Ein Wert von WhenSupported versetzt HttpListener in den teilweise gehärteten Modus, während Always dem vollständig gehärteten Modus entspricht.
Wird in dieser Konfiguration eine Anforderung über einen sicheren Außenkanal an den Server gesendet, wird der Außenkanal nach einer Kanalbindung abgefragt. Diese Kanalbindung wird an die SSPI-Authentifizierungsaufrufe übergeben, die überprüfen, ob die Kanalbindung im Authentifizierungsblob übereinstimmt. Es gibt drei mögliche Ergebnisse:
Das zugrunde liegende Betriebssystem des Servers unterstützt den erweiterten Schutz nicht. Die Anforderung wird der Anwendung nicht verfügbar gemacht, und die Antwort „Nicht autorisiert (401).“ wird an den Client zurückgegeben. Eine Nachricht mit dem Grund für den Fehler wird in der Ablaufverfolgungsquelle HttpListener protokolliert.
Es tritt beim SSPI-Aufruf ein Fehler auf. Dies bedeutet entweder, dass die vom Client angegebene Kanalbindung nicht mit dem erwarteten Wert übereinstimmt, der aus dem Außenkanal abgerufen wurde, oder dass der Client bei der Konfiguration der erweiterten Schutzrichtlinie auf dem Server für Always keine Kanalbindung bereitgestellt hat. In beiden Fällen wird die Anforderung der Anwendung nicht verfügbar gemacht, und die Antwort „Nicht autorisiert (401)“ wird an den Client zurückgegeben. Eine Nachricht mit dem Grund für den Fehler wird in der Ablaufverfolgungsquelle HttpListener protokolliert.
Der Client gibt die richtige Kanalbindung an oder kann ohne Angabe einer Kanalbindung die Verbindung herstellen, da die erweiterte Schutzrichtlinie auf dem Server mit WhenSupported konfiguriert ist. Die Anforderung wird für die Verarbeitung an die Anwendung zurückgegeben. Die Dienstnamenüberprüfung wird nicht automatisch ausgeführt. Eine Anwendung führt möglicherweise eine eigene Überprüfung des Dienstnamens mithilfe der ServiceName-Eigenschaft durch. Dies ist unter diesen Umständen jedoch redundant.
Führt eine Anwendung eigene SSPI-Aufrufe zur Durchführung der Authentifizierung auf der Basis von Blobs durch, die im Text einer HTTP-Anforderung ausgetauscht werden, und ist eine Unterstützung der Kanalbindung erwünscht, muss die Anwendung die erwartete Kanalbindung vom sicheren Außenkanal mithilfe von HttpListener abrufen, um sie an die native Win32-Funktion AcceptSecurityContext zu übergeben. Verwenden Sie hierfür die Eigenschaft TransportContext, und rufen Sie zum Abrufen des CBT die Methode GetChannelBinding auf. Nur Endpunktbindungen werden unterstützt. Wird etwas anderes als Endpoint angegeben, wird eine NotSupportedException ausgelöst. Unterstützt das zugrunde liegende Betriebssystem die Kanalbindung, gibt die Methode GetChannelBinding ein ChannelBindingSafeHandle zurück, das einen Zeiger mit einer Kanalbindung umschließt, die an die Funktion AcceptSecurityContext als im Parameter pInput
übergebener Member „PvBuffer“ einer Struktur „SecBuffer“ übergeben wird. Die Eigenschaft Size enthält die Länge der Kanalbindung in Bytes. Unterstützt das zugrunde liegende Betriebssystem keine Kanalbindungen, gibt die Funktion null
zurück.
Ein anderes mögliches Szenario ist die Aktivierung des erweiterten Schutz für die Präfixe HTTP://
, wenn keine Proxys verwendet werden. Legen Sie in diesem Fall HttpListener.ExtendedProtectionPolicy auf ExtendedProtectionPolicy fest, für das PolicyEnforcement auf WhenSupported oder Always festgelegt ist, sowie ProtectionScenario auf TransportSelected. Ein Wert von WhenSupported versetzt HttpListener in den teilweise gehärteten Modus, während Always dem vollständig gehärteten Modus entspricht.
Eine Standardliste mit den zulässigen Dienstnamen wird auf Grundlage der Präfixe erstellt, die mit HttpListener registriert wurden. Diese Standardliste kann mit der Eigenschaft DefaultServiceNames überprüft werden. Ist die Liste nicht vollständig, kann eine Anwendung im Konstruktor für die Klasse ExtendedProtectionPolicy eine benutzerdefinierte Dienstnamensammlung angeben, die anstelle der Standard-Dienstnamenliste verwendet wird.
Wird in dieser Konfiguration eine Anforderung ohne sicheren Außenkanal an den Server gesendet, erfolgt die Authentifizierung üblicherweise ohne Überprüfung der Kanalbindung. Bei erfolgreicher Authentifizierung wird der Kontext nach dem vom Client bereitgestellten Dienstnamen abgefragt und anhand der Liste der zulässigen Dienstnamen überprüft. Es gibt vier mögliche Ergebnisse:
Das zugrunde liegende Betriebssystem des Servers unterstützt den erweiterten Schutz nicht. Die Anforderung wird der Anwendung nicht verfügbar gemacht, und die Antwort „Nicht autorisiert (401).“ wird an den Client zurückgegeben. Eine Nachricht mit dem Grund für den Fehler wird in der Ablaufverfolgungsquelle HttpListener protokolliert.
Das zugrunde liegende Betriebssystem des Clients unterstützt den erweiterten Schutz nicht. Der Authentifizierungsversuch wird in der WhenSupported-Konfiguration erfolgreich ausgeführt, und die Anforderung wird an die Anwendung zurückgegeben. Es tritt in der Always-Konfiguration beim Authentifizierungsversuch ein Fehler auf. Die Anforderung wird der Anwendung nicht verfügbar gemacht, und die Antwort „Nicht autorisiert (401).“ wird an den Client zurückgegeben. Eine Nachricht mit dem Grund für den Fehler wird in der Ablaufverfolgungsquelle HttpListener protokolliert.
Das zugrunde liegende Betriebssystem des Clients unterstützt den erweiterten Schutz, doch in der Anwendung wurde keine Dienstbindung angegeben. Die Anforderung wird der Anwendung nicht verfügbar gemacht, und die Antwort „Nicht autorisiert (401).“ wird an den Client zurückgegeben. Eine Nachricht mit dem Grund für den Fehler wird in der Ablaufverfolgungsquelle HttpListener protokolliert.
Es wurde vom Client eine Dienstbindung angegeben. Die Dienstbindung wird mit der Liste der zulässigen Dienstbindungen verglichen. Bei einer Übereinstimmung wird die Anforderung an die Anwendung zurückgegeben. Andernfalls wird die Anforderung der Anwendung nicht verfügbar gemacht, und die Antwort „Nicht autorisiert (401)“ wird automatisch an den Client zurückgegeben. Eine Nachricht mit dem Grund für den Fehler wird in der Ablaufverfolgungsquelle HttpListener protokolliert.
Reicht diese einfache Vorgehensweise mit einer Liste aus zulässigen Dienstnamen nicht aus, kann eine Anwendung durch Abfragen der Eigenschaft ServiceName möglicherweise eine eigene Überprüfung der Dienstnamen bereitstellen. Im 1. und 2. Fall gibt die Eigenschaft null
zurück. Im 3. Fall wird eine leere Zeichenfolge zurückgegeben. Im 4. Fall wird der vom Client angegebene Dienstname zurückgegeben.
Diese erweiterten Schutzfunktionen können auch von Serveranwendungen für die Authentifizierung mit anderen Anforderungstypen und bei vertrauenswürdigen Proxys verwendet werden.