Architektur der Security Support Provider-Schnittstelle
Gilt für: Windows Server 2022, Windows Server 2019, Windows Server 2016
In diesem Referenzthema für IT-Experten werden die Windows-Authentifizierungsprotokolle beschrieben, die in der Security Support Provider Interface (SSPI)-Architektur verwendet werden.
Die Microsoft Security Support Provider Interface (SSPI) ist die Grundlage der Windows-Authentifizierung. Anwendungen und Infrastrukturdienste, die eine Authentifizierung erfordern, nutzen dafür SSPI.
SSPI ist die Implementierung der Generic Security Services-API (GSSAPI) in Windows Server-Betriebssystemen. Weitere Informationen zu GSSAPI finden Sie in der IETF-RFC-Datenbank in RFC 2743 und RFC 2744.
Die standardmäßigen Sicherheitsunterstützungsanbieter (Security Service Providers, SSPs), die bestimmte Authentifizierungsprotokolle in Windows aufrufen, sind als DLLs in die SSPI integriert. Diese Standard-SSPs werden in den nächsten Abschnitten beschrieben. Zusätzliche SSPs können integriert werden, wenn sie mit der SSPI kompatibel sind.
Wie in der folgenden Abbildung gezeigt, stellt die SSPI in Windows einen Mechanismus bereits, der Authentifizierungstoken über den vorhandenen Kommunikationskanal zwischen dem Clientcomputer und dem Server überträgt. Wenn sich zwei Computer oder Geräte authentifizieren müssen, um sicher kommunizieren zu können, werden die Authentifizierungsanforderungen an die SSPI weitergeleitet, die den Authentifizierungsvorgang abschließt. Welches Netzwerkprotokoll gerade verwendet wird, ist dabei nicht relevant. Die SSPI gibt transparente große Binärobjekte zurück. Diese Objekte werden zwischen den Anwendungen übergeben und können dann an die SSPI-Schicht übergeben werden. Dank der SSPI kann eine Anwendung also die verschiedenen Sicherheitsmodelle verwenden, die auf einem Computer oder in einem Netzwerk verfügbar sind, ohne die Schnittstelle des Sicherheitssystems ändern zu müssen.
In den folgenden Abschnitten werden die Standard-SSPs beschrieben, die mit der SSPI interagieren. Die SSPs werden in Windows-Betriebssystemen unterschiedlich eingesetzt, um die sichere Kommunikation in einer unsicheren Netzwerkumgebung zu fördern.
Ebenfalls in diesem Thema enthalten:
Auswahl des Security Support Providers
Kerberos Security Support Provider
Dieser SSP verwendet nur das Protokoll Kerberos V5 in der Microsoft-Implementierung. Dieses Protokoll basiert auf dem RFC 4120 der Networking Working Group und Entwürfen für Überarbeitungen. Es handelt sich um ein Protokoll nach Branchenstandard, das zusammen mit einem Kennwort oder einer Smartcard für interaktive Anmeldungen genutzt wird. Es ist auch die bevorzugte Authentifizierungsmethode für Dienste in Windows.
Da das Kerberos-Protokoll seit Windows 2000 als standardmäßiges Authentifizierungsprotokoll verwendet wird, unterstützen alle Domänendienste den Kerberos-SSP. Zu diesen Diensten gehören:
Active Directory-Abfragen, die LDAP verwenden
Remoteserver- oder Arbeitsstationsverwaltung, die den Remoteprozeduraufruf-Dienst verwendet
Druckdienste
Client-Serverauthentifizierung
Remotedateizugriff, der das SMB-Protokoll (CIFS) verwendet
DFS-Verwaltung und -Empfehlung
Intranetauthentifizierung bei Internetinformationsdiensten (ISS)
Sicherheitsbehörden-Authentifizierung für IPsec
Zertifikatanforderungen an Active Directory-Zertifikatdienste für Domänenbenutzer und Computer
Speicherort: %Windir%\System32\kerberos.dll
Dieser Anbieter ist standardmäßig in den Versionen enthalten, die in der Liste Gilt für am Anfang dieses Themas aufgeführt sind, sowie in Windows Server 2003 und Windows XP.
Weitere Ressourcen zum Kerberos-Protokoll und Kerberos-SSP
Kerberos-Erweiterungen für Windows Vista
Änderungen bei der Kerberos-Authentifizierung für Windows 7
NTLM Security Support Provider
Der NTLM Security Support Provider (NTLM-SSP) ist ein binäres Messagingprotokoll, das von der SSPI genutzt wird, um die NTLM-Challenge-Response-Authentifizierung zuzulassen und die Integritäts- und Verwendet zu verhandeln. NTLM wird überall verwendet, wo die SSPI-Authentifizierung verwendet wird, u. a. für die SMB- bzw. CIFS-Authentifizierung, die HTTP-Negotiate-Authentifizierung (z. B. Internet-Webauthentifizierung) und für den Remoteprozeduraufruf-Dienst Der NTLM-SSP umfasst die Authentifizierungsprotokolle NTLM und NTLM Version 2 (NTLMv2).
Die unterstützten Windows-Betriebssysteme können den NTLM-SSP für Folgendes verwenden:
Client-Serverauthentifizierung
Druckdienste
Dateizugriff mit CIFS (SMB)
Sicherer Remoteprozeduraufruf-Dienst oder DCOM-Dienst
Speicherort: %Windir%\System32\msv1_0.dll
Dieser Anbieter ist standardmäßig in den Versionen enthalten, die in der Liste Gilt für am Anfang dieses Themas aufgeführt sind, sowie in Windows Server 2003 und Windows XP.
Weitere Ressourcen zum NTLM-Protokoll und NTLM-SSP
Änderungen bei der NTLM-Authentifizierung in Windows 7
Handbuch zur Überwachung und Einschränkung der NTLM-Verwendung
Digest Security Support Provider
Die Digest-Authentifizierung ist ein Branchenstandard, der für die LDAP- und Web-Authentifizierung verwendet wird. Bei der Digest-Authentifizierung werden Anmeldeinformationen als MD5-Hash oder Nachrichtenhash im Netzwerk übertragen.
Der Digest-SSP (Wdigest.dll) wird für Folgendes verwendet:
Internet Explorer und IIS-Zugriff
LDAP-Abfragen
Speicherort: %Windir%\System32\Wdigest.dll
Dieser Anbieter ist standardmäßig in den Versionen enthalten, die in der Liste Gilt für am Anfang dieses Themas aufgeführt sind, sowie in Windows Server 2003 und Windows XP.
Weitere Ressourcen zum Digest-Protokoll und Digest-SSP
Schannel Security Support Provider
Der Secure Channel (Schannel) wird für die webbasierte Serverauthentifizierung verwendet, also beispielsweise, wenn ein Benutzer auf einen sicheren Webserver zugreifen will.
Das TLS-Protokoll, das SSL-Protokoll, das Private Communications Technology (PCT)-Protokoll und das Datagram Transport Layer (DTLS)-Protokoll basieren auf einer Kryptografie mit einem öffentlichen Schlüssel. Schannel stellt all diese Protokolle bereit. Alle Schannel-Protokolle verwenden ein Client/Server-Modell. Der Schannel SSP verwendet Zertifikate für öffentliche Schlüssel zum Authentifizieren von Parteien. Bei der Authentifizierung wählt der Schannel-SSP in der folgenden bevorzugten Reihenfolge:
Transport Layer Security (TLS) Version 1.0
Transport Layer Security (TLS) Version 1.1
Transport Layer Security (TLS) Version 1.2
Secure Socket Layer (SSL) Version 2.0
Secure Socket Layer (SSL) Version 3.0
Private Communications Technology (PCT)
Hinweis PCT ist standardmäßig deaktiviert.
Das ausgewählte Protokoll ist das bevorzugte Authentifizierungsprotokoll, das vom Client und vom Server unterstützt wird. Wenn z. B. ein Server alle Schannel-Protokolle unterstützt und der Client nur SSL 3.0 und SSL 2.0, verwendet der Authentifizierungsprozess SSL 3.0.
DTLS wird verwendet, wenn es explizit von der Anwendung aufgerufen wird. Weitere Informationen zu DTLS und den anderen Protokollen, die der Schannel-Anbieter verwendet, finden Sie unter Schannel-Sicherheitssupportanbieter: Technische Referenz.
Speicherort: %Windir%\System32\Schannel.dll
Dieser Anbieter ist standardmäßig in den Versionen enthalten, die in der Liste Gilt für am Anfang dieses Themas aufgeführt sind, sowie in Windows Server 2003 und Windows XP.
Hinweis
TLS 1.2 wurde bei diesem Anbieter in Windows Server 2008 R2 und Windows 7 eingeführt. DTLS wurde bei diesem Anbieter in Windows Server 2012 und Windows 8 eingeführt.
Weitere Ressourcen zum TLS- und SSL-Protokoll und Schannel-SSP
Negotiate Security Support Provider
Der Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) bildet die Grundlage für den Negotiate-SSP, der zum Verhandeln eines bestimmten Authentifizierungsprotokolls verwendet wird. Wenn eine SSPI zur Anmeldung bei einem Netzwerk von einer Anwendung aufgerufen wird, kann ein SSP zur Verarbeitung der Anforderung angegeben werden. Wenn die Anwendung den Negotiate-SSP angibt, wird die Anforderung analysiert und der richtige Anbieter für die Verarbeitung der Anforderung ausgewählt, basierend auf den vom Kunden konfigurierten Sicherheitsrichtlinien.
SPNEGO ist in RFC 2478 beschrieben.
In unterstützten Versionen des Windows-Betriebssystems trifft der Negotiate-SSP eine Auswahl zwischen dem Kerberos-Protokoll und NTLM. Negotiate wählt standardmäßig das Kerberos-Protokoll aus, es sei denn, dass eines der bei der Authentifizierung beteiligten Systeme das Protokoll nicht verwenden kann oder die aufrufende Anwendung keine ausreichenden Informationen zur Verwendung des Kerberos-Protokolls bereitgestellt hat.
Speicherort: %Windir%\System32\lsasrv.dll
Dieser Anbieter ist standardmäßig in den Versionen enthalten, die in der Liste Gilt für am Anfang dieses Themas aufgeführt sind, sowie in Windows Server 2003 und Windows XP.
Weitere Ressourcen zum Negotiate-SSP
[MS-SPNG]: Simple and Protected GSS-API Negotiation Mechanism (SPNEGO)-Erweiterungen
[MS-N2HT]: Spezifikation des Negotiate and Nego2 HTTP-Authentifizierungsprotokolls
Credential Security Support Provider
Der Credential-SSP (CredSSP) ermöglicht Benutzern beim Starten neuer Terminaldienst- und Remotedesktopdienst-Sitzungen das einmalige Anmelden (SSO). Mit CredSSP können Anwendungen die Anmeldeinformationen von Benutzern vom Clientcomputer (mit einem clientseitigen SSP) an den Zielserver (über den serverseitigen SSP) delegieren, basierend auf den Richtlinien des Clients. Die CredSSP-Richtlinien werden mit einer Gruppenrichtlinie konfiguriert, und die Delegierung von Anmeldeinformationen ist standardmäßig deaktiviert.
Speicherort: %Windir%\System32\credssp.dll
Dieser Anbieter ist standardmäßig in den Versionen enthalten, die in der Liste Gilt für am Anfang dieses Themas aufgeführt sind.
Weitere Ressourcen zum Credentials-SSP
[MS-CSSP]: Spezifikation des Credential Security Support Provider (CredSSP)-Protokolls
Anmeldeinformationen-SSP und SSO für die Anmeldung bei Terminaldiensten
Negotiate Extensions Security Support Provider
Negotiate Extensions (NegoExts) ist ein Authentifizierungspaket, das die Verwendung von anderen SSPs als dem NTLM- und Kerberos-Protokoll für Anwendungen und Szenarien verhandelt, die von Microsoft und anderen Softwareunternehmen implementiert wurden.
Diese Erweiterung des Negotiate-Pakets erlaubt die folgenden Szenarien:
Rich-Client-Verfügbarkeit in einem Verbundsystem. Der Zugriff auf Dokumente ist auf SharePoint-Websites möglich, und die Dokumente können mit einer Microsoft Office-Anwendung mit vollem Funktionsumfang bearbeitet werden.
Rich-Client-Unterstützung für Microsoft Office-Dienste. Benutzer können sich bei Microsoft Office-Diensten anmelden und eine Microsoft Office-Anwendung mit vollem Funktionsumfang verwenden.
Gehosteter Microsoft Exchange Server und Outlook. Es wird keine Domänenvertrauensstellung hergestellt, da Exchange Server im Web gehostet wird. Outlook verwendet für die Authentifizierung von Benutzern den Windows Live-Dienst.
Rich-Client-Verfügbarkeit zwischen Clientcomputern und Servern. Die Netzwerk- und Authentifizierungskomponenten des Betriebssystems werden verwendet.
Das Windows Negotiate-Paket behandelt den NegoExts-SSP genauso wie Kerberos und NTLM. Die Datei NegoExts.dll wird beim Start in die LSA (Local System Authority) geladen. Wenn eine Authentifizierungsanforderung eingeht, verhandelt NegoExts basierend auf der Quelle der Anforderung zwischen den unterstützten SSPs. NegoExts erfasst die Anmeldeinformationen und Richtlinien, verschlüsselt sie und sendet diese Informationen an den entsprechenden SSP, wo das Sicherheitstoken erstellt wird.
Die von NegoExts unterstützten SSPs sind keine eigenständigen SSPs wie Kerberos und NTLM. Daher wird im NegoExts-SSP eine Authentifizierungsfehlermeldung angezeigt oder protokolliert, wenn die Authentifizierungsmethode fehlschlägt. Eine erneute Verhandlung oder Fallbackauthentifizierung ist nicht möglich.
Speicherort: %Windir%\System32\negoexts.dll
Dieser Anbieter ist standardmäßig in den Versionen enthalten, die in der Liste Gilt für am Anfang dieses Themas aufgeführt sind, mit Ausnahme von Windows Server 2008 und Windows Vista.
PKU2U Security Support Provider
Das PKU2U-Protokoll wurde in Windows 7 und Windows Server 2008 R2 als SSP eingeführt und implementiert. Dieser SSP ermöglicht die Peer-to-Peer-Authentifizierung, insbesondere über die Medien- und Dateifreigabefunktion „Heimnetzgruppe“, die in Windows 7 eingeführt wurde. Diese Funktion ermöglicht die Dateifreigabe zwischen Computern, die keine Mitglieder einer Domäne sind.
Speicherort: %Windir%\System32\pku2u.dll
Dieser Anbieter ist standardmäßig in den Versionen enthalten, die in der Liste Gilt für am Anfang dieses Themas aufgeführt sind, mit Ausnahme von Windows Server 2008 und Windows Vista.
Weitere Ressourcen zum PKU2U-Protokoll und PKU2U-SSP
Auswahl des Security Support Providers
Die Windows-SSPI kann alle Protokolle verwenden, die über die installierten SSPs unterstützt werden. Da jedoch nicht alle Betriebssysteme dieselben SSP-Pakete wie ein Computer mit Windows Server, müssen Clients und Server verhandeln, um ein Protokoll zu verwenden, das beide unterstützen. Windows Server bevorzugt es, wenn Clientcomputer und -anwendungen nach Möglichkeit das Kerberos-Protokolls verwenden, ein starkes, standardbasiertes Protokoll. Das Betriebssystem lässt aber auch weiterhin Clientcomputer und Clientanwendungen zu, die für die Authentifizierung nicht das Kerberos-Protokoll verwenden.
Vor der Authentifizierung müssen sich die zwei miteinander kommunizierenden Computer auf ein Protokoll einigen, das beide unterstützen. Damit ein Protokoll über die SSPI verwendet werden kann, muss jeder Computer über den entsprechenden SSP verfügen. Beispielsweise müssen ein Clientcomputer und ein Server beide Kerberos v5 unterstützen, um das Kerberos-Authentifizierungsprotokoll verwenden zu können. Windows ermittelt mit der Funktion EnumerateSecurityPackages, welche SSPs auf einem Computer unterstützt werden und welche Funktionen diese SSPs bieten.
Für die Auswahl eines Authentifizierungsprotokolls gibt es die folgenden beiden Methoden:
Ein einziges Authentifizierungsprotokoll
Wenn ein einziges akzeptables Protokoll auf dem Server angegeben ist, muss der Clientcomputer dieses Protokoll unterstützen, andernfalls schlägt die Kommunikation fehl. Wenn ein einziges akzeptables Protokoll angegeben ist, läuft der Authentifizierungsaustausch wie folgt ab:
Der Clientcomputer fordert Zugriff auf einen Dienst an.
Der Server antwortet auf die Anforderung und gibt das Protokoll an, das verwendet werden soll.
Der Clientcomputer untersucht den Inhalt der Antwort und prüft, ob er das angegebene Protokoll unterstützt. Wenn der Clientcomputer das angegebene Protokoll unterstützt, wird die Authentifizierung fortgesetzt. Wenn der Clientcomputer das Protokoll nicht unterstützt, schlägt die Authentifizierung fehl, unabhängig davon, ob der Clientcomputer zum Zugriff auf die Ressource autorisiert ist.
Verhandlungsoption
Mit der Verhandlungsoption können der Client und der Server versuchen, ein akzeptables Protokoll zu finden. Dies basiert auf dem Simple and Protected GSS-API Negotiation Mechanismus (SPNEGO). Wenn die Authentifizierung mit der Option zum Verhandeln eines Authentifizierungsprotokolls beginnt, läuft der SPNEGO-Austausch wie folgt ab:
Der Clientcomputer fordert Zugriff auf einen Dienst an.
Der Server antwortet mit einer Liste von Authentifizierungprotokollen, die er unterstützt, und einer Authentifizierungsanforderung oder -antwort, basierend auf dem Protokoll, das seine erste Wahl ist. Beispiel: Der Server führt das Kerberos-Protokoll und NTLM auf und sendet eine Kerberos-Authentifizierungsantwort.
Der Clientcomputer untersucht den Inhalt der Antwort und prüft, ob er eines der angegebenen Protokolle unterstützt.
Wenn der Clientcomputer das bevorzugte Protokoll unterstützt, wird die Authentifizierung fortgesetzt.
Wenn der Clientcomputer das bevorzugte Protokoll nicht unterstützt, aber eines der anderen vom Server aufgeführten Protokolle, teilt der Clientcomputer dem Server mit, welches Authentifizierungsprotokoll er unterstützt, und die Authentifizierung wird fortgesetzt.
Wenn der Clientcomputer keines der aufgeführten Protokolle unterstützt, schlägt der Authentifizierungsaustausch fehl.