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-Authentifizierung Protokolle beschrieben, die in der SSPI-Architektur (Security Support Provider Interface) verwendet werden.
Die Microsoft Security Support Provider Interface (SSPI) ist die Grundlage für Windows-Authentifizierung. Anwendungen und Infrastrukturdienste, die die Authentifizierung erfordern, verwenden SSPI, um sie bereitzustellen.
SSPI ist die Implementierung der generic Security Service API (GSSAPI) in Windows Serverbetriebssystemen. Weitere Informationen zu GSSAPI finden Sie unter RFC 2743 und RFC 2744 in der IETF RFC-Datenbank.
Die Standardmäßigen Sicherheitsunterstützungsanbieter (SSPs), die bestimmte Authentifizierungsprotokolle in Windows aufrufen, werden als DLLs in den SSPI integriert. Diese Standard-SSPs werden in den folgenden Abschnitten beschrieben. Zusätzliche SSPs können integriert werden, wenn sie mit dem SSPI arbeiten können.
Wie in der folgenden Abbildung dargestellt, stellt der SSPI in Windows einen Mechanismus bereit, der Authentifizierungstoken über den vorhandenen Kommunikationskanal zwischen dem Clientcomputer und dem Server trägt. Wenn zwei Computer oder Geräte authentifiziert werden müssen, damit sie sicher kommunizieren können, werden die Anforderungen für die Authentifizierung an den SSPI weitergeleitet, der den Authentifizierungsprozess abgeschlossen hat, unabhängig vom derzeit verwendeten Netzwerkprotokoll. Der SSPI gibt transparente binär große Objekte zurück. Diese werden zwischen den Anwendungen übergeben, an welcher Stelle sie an die SSPI-Ebene übergeben werden können. Damit ermöglicht der SSPI eine Anwendung, verschiedene Sicherheitsmodelle zu verwenden, die auf einem Computer oder Netzwerk verfügbar sind, ohne die Schnittstelle zum Sicherheitssystem zu ändern.
In den folgenden Abschnitten werden die Standard-SSPs beschrieben, die mit dem SSPI interagieren. Die SSPs werden auf unterschiedliche Weise in Windows Betriebssystemen verwendet, um die sichere Kommunikation in einer unsicheren Netzwerkumgebung zu fördern.
Auch in diesem Thema enthalten:
Auswahl des Sicherheitssupportanbieters
Kerberos-Sicherheitsunterstützungsanbieter
Dieser SSP verwendet nur das Kerberos Version 5-Protokoll, wie von Microsoft implementiert. Dieses Protokoll basiert auf der RFC 4120 der Netzwerkarbeitsgruppe und der Überarbeitungen. Es handelt sich um ein Branchenstandardprotokoll, das mit einem Kennwort oder einer Smartcard für eine interaktive Anmeldung verwendet wird. Es ist auch die bevorzugte Authentifizierungsmethode für Dienste in Windows.
Da das Kerberos-Protokoll seit Windows 2000 das Standardauthentifizierungsprotokoll ist, unterstützen alle Domänendienste den Kerberos-SSP. Zu diesen Diensten gehören:
Active Directory-Abfragen, die das Lightweight Directory Access Protocol (LDAP) verwenden
Remoteserver- oder Arbeitsstationsverwaltung, die den Remoteprozeduraufrufdienst verwendet
Druckdienste
Clientserverauthentifizierung
Remotedateizugriff, der das SMB-Protokoll (Server Message Block) verwendet (auch bekannt als Common Internet File System oder CIFS)
Verteilte Dateisystemverwaltung und -empfehlung
Intranetauthentifizierung für Internetinformationsdienste (IIS)
Authentifizierung der Sicherheitsbehörde für die Internetprotokollsicherheit (IPsec)
Zertifikatanforderungen an Active Directory-Zertifikatdienste für Domänenbenutzer und Computer
Standort: %Windir%\System32\kerberos.dll
Dieser Anbieter ist standardmäßig in Versionen enthalten, die in der Liste "Gilt für" am Anfang dieses Themas festgelegt sind, sowie Windows Server 2003 und Windows XP.
Zusätzliche Ressourcen für das Kerberos-Protokoll und den Kerberos-SSP
Kerberos-Verbesserungen für Windows Vista
Änderungen an 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 (Security Support Provider Interface) verwendet wird, um die NTLM-Antwortauthentifizierung zu ermöglichen und Integritäts- und Vertraulichkeitsoptionen auszuhandeln. NTLM wird verwendet, wo die SSPI-Authentifizierung verwendet wird, einschließlich der Servernachrichtenblock- oder CIFS-Authentifizierung, der HTTP-Verhandlungsauthentifizierung (z. B. Internetwebauthentifizierung) und dem Remoteprozeduraufrufdienst. Der NTLM-SSP enthält die NTLM- und NTLM-Authentifizierungsprotokolle 2 (NTLMv2).
Die unterstützten Windows Betriebssysteme können den NTLM-SSP für folgendes verwenden:
Client-/Serverauthentifizierung
Druckdienste
Dateizugriff mithilfe von CIFS (SMB)
Anrufdienst für sichere Remoteprozeduren oder DCOM-Dienst
Standort: %Windir%\System32\msv1_0.dll
Dieser Anbieter ist standardmäßig in Versionen enthalten, die in der Liste "Gilt für" am Anfang dieses Themas festgelegt sind, sowie Windows Server 2003 und Windows XP.
Zusätzliche Ressourcen für das NTLM-Protokoll und den NTLM-SSP
Änderungen der NTLM-Authentifizierung in Windows 7
Handbuch zur Überwachung und Einschränkung der NTLM-Verwendung
Digest Security Support Provider
Die Digestauthentifizierung ist ein Branchenstandard, der für das Lightweight Directory Access Protocol (LDAP) und die Webauthentifizierung verwendet wird. Die Digestauthentifizierung überträgt Anmeldeinformationen über das Netzwerk hinweg als MD5-Hash- oder Nachrichtendigest.
Digest-SSP (Wdigest.dll) wird für Folgendes verwendet:
Internet Explorer und Internetinformationsdienste (IIS)-Zugriff
LDAP-Abfragen
Standort: %Windir%\System32\Wdigest.dll
Dieser Anbieter ist standardmäßig in Versionen enthalten, die in der Liste "Gilt für" am Anfang dieses Themas festgelegt sind, sowie Windows Server 2003 und Windows XP.
Zusätzliche Ressourcen für das Digestprotokoll und den Digest-SSP
Schannel Security Support Provider
Der Secure Channel (Schannel) wird für die webbasierte Serverauthentifizierung verwendet, z. B. wenn ein Benutzer versucht, auf einen sicheren Webserver zuzugreifen.
Das TLS-Protokoll, das SSL-Protokoll, das PCT-Protokoll (Private Communications Technology) und das Datagram Transport Layer (DTLS)-Protokoll basieren auf der Kryptografie für öffentliche Schlüssel. Schannel stellt alle 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 von Parteien wählt Schannel SSP ein Protokoll in der folgenden Präferenzreihenfolge aus:
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 werden kann. Wenn ein Server beispielsweise alle Schannel-Protokolle unterstützt und der Client nur SSL 3.0 und SSL 2.0 unterstützt, verwendet der Authentifizierungsprozess SSL 3.0.
DTLS wird verwendet, wenn die Anwendung explizit aufgerufen wird. Weitere Informationen zu DTLS und den anderen Protokollen, die vom Schannel-Anbieter verwendet werden, finden Sie unter Technische Referenz zu Schannel Security Support Provider.
Standort: %Windir%\System32\Schannel.dll
Dieser Anbieter ist standardmäßig in versionen enthalten, die am Anfang dieses Themas aufgeführt sind, sowie Windows Server 2003 und Windows XP.
Hinweis
TLS 1.2 wurde in diesem Anbieter in Windows Server 2008 R2 und Windows 7 eingeführt. DTLS wurde in diesem Anbieter in Windows Server 2012 und Windows 8 eingeführt.
Zusätzliche Ressourcen für die TLS- und SSL-Protokolle und die Schannel-SSP
Sicherheitsunterstützungsanbieter aushandeln
Der einfache und geschützte GSS-API-Verhandlungsmechanismus (SPNEGO) bildet die Grundlage für das Verhandlungs-SSP, das zum Verhandeln eines bestimmten Authentifizierungsprotokolls verwendet werden kann. 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 Verhandlungs-SSP angibt, analysiert sie die Anforderung und wählt den entsprechenden Anbieter aus, um die Anforderung zu behandeln, basierend auf kundenkonfigurierten Sicherheitsrichtlinien.
SPNEGO wird in RFC 2478 angegeben.
In unterstützten Versionen der Windows Betriebssysteme wählt der Sicherheitsunterstützungsanbieter zwischen dem Kerberos-Protokoll und NTLM aus. Die Verhandlungen wählen das Kerberos-Protokoll standardmäßig aus, es sei denn, dieses Protokoll kann nicht von einem der Systeme verwendet werden, die an der Authentifizierung beteiligt sind, oder die aufrufende Anwendung hat keine ausreichenden Informationen zur Verwendung des Kerberos-Protokolls bereitgestellt.
Standort: %Windir%\System32\lsasrv.dll
Dieser Anbieter ist standardmäßig in versionen enthalten, die am Anfang dieses Themas aufgeführt sind, sowie Windows Server 2003 und Windows XP.
Zusätzliche Ressourcen für den Verhandlungs-SSP
[MS-SPNG]: Einfache und geschützte GSS-API-Verhandlungsmechanismus (SPNEGO) Erweiterungen
[MS-N2HT]: Verhandlungen und Nego2 HTTP-Authentifizierungsprotokollspezifikation
Credential Security Support Provider
Der Credential Security Service Provider (CredSSP) bietet eine einmalige Anmeldung (SSO) beim Starten neuer Terminaldienste- und Remotedesktopdienste-Sitzungen. CredSSP ermöglicht Anwendungen, die Anmeldeinformationen von Benutzern vom Clientcomputer (mithilfe des clientseitigen SSP) an den Zielserver (über den serverseitigen SSP) zu delegieren, basierend auf den Richtlinien des Clients. CredSSP-Richtlinien werden mithilfe von Gruppenrichtlinie konfiguriert, und die Delegierung von Anmeldeinformationen ist standardmäßig deaktiviert.
Standort: %Windir%\System32\credssp.dll
Dieser Anbieter ist standardmäßig in versionen enthalten , die in der Liste am Anfang dieses Themas festgelegt sind.
Zusätzliche Ressourcen für den Anmeldeinformationen-SSP
[MS-CSSP]: Credential Security Support Provider (CredSSP) Protokollspezifikation
Credential Security Service Provider und SSO for Terminal Services Logon
Anbieter von Erweiterungen zur Unterstützung von Erweiterungen
Negotiate Extensions (NegoExts) ist ein Authentifizierungspaket, das die Verwendung von SSPs aushandelt, außer NTLM oder das Kerberos-Protokoll, für Anwendungen und Szenarien, die von Microsoft und anderen Softwareunternehmen implementiert wurden.
Diese Erweiterung des Verhandlungspakets ermöglicht folgende Szenarien:
Rich-Clientverfügbarkeit innerhalb eines Verbundsystems. Dokumente können auf SharePoint Websites zugegriffen werden, und sie können mithilfe einer vollständigen Microsoft Office Anwendung bearbeitet werden.
Rich Client Support für Microsoft Office Dienste. Benutzer können sich bei Microsoft Office Diensten anmelden und eine vollständige Microsoft Office Anwendung verwenden.
Gehostet Microsoft Exchange Server und Outlook. Es gibt keine Domäne vertrauen, da Exchange Server im Web gehostet wird. Outlook verwendet den Windows Live-Dienst, um Benutzer zu authentifizieren.
Rich-Clientverfügbarkeit zwischen Clientcomputern und Servern. Die Netzwerk- und Authentifizierungskomponenten des Betriebssystems werden verwendet.
Das Windows Negotiate-Paket behandelt den NegoExts SSP auf dieselbe Weise wie bei Kerberos und NTLM. NegoExts.dll wird am Start in die Lokale Systembehörde (LSA) geladen. Wenn eine Authentifizierungsanforderung empfangen wird, basierend auf der Quelle der Anforderung, wird NegoExts zwischen den unterstützten SSPs ausgehandelt. Sie sammelt 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 nicht eigenständige SSPs wie Kerberos und NTLM. Daher wird innerhalb des NegoExts SSP, wenn die Authentifizierungsmethode aus irgendeinem Grund fehlschlägt, eine Authentifizierungsfehlernachricht angezeigt oder protokolliert. Es sind keine Neuverhandelungs- oder Fallbackauthentifizierungsmethoden möglich.
Standort: %Windir%\System32\negoexts.dll
Dieser Anbieter ist standardmäßig in versionen enthalten, die am Anfang dieses Themas aufgeführt sind, ohne 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 durch das Feature "Medien- und Dateifreigabe", das in Windows 7 eingeführt wurde. Das Feature ermöglicht die Freigabe zwischen Computern, die keine Mitglieder einer Domäne sind.
Standort: %Windir%\System32\pku2u.dll
Dieser Anbieter ist standardmäßig in versionen enthalten, die am Anfang dieses Themas aufgeführt sind, ohne Windows Server 2008 und Windows Vista.
Zusätzliche Ressourcen für das PKU2U-Protokoll und den PKU2U-SSP
Auswahl des Sicherheitssupportanbieters
Die Windows SSPI kann alle Protokolle verwenden, die über die installierten Sicherheitssupportanbieter unterstützt werden. Da jedoch nicht alle Betriebssysteme die gleichen SSP-Pakete unterstützen wie jeder bestimmte Computer, auf dem Windows Server ausgeführt wird, müssen Clients und Server eine Protokoll verwenden, das beide unterstützen. Windows Server bevorzugt Clientcomputer und Anwendungen, um das Kerberos-Protokoll zu verwenden, ein starkes standardsbasiertes Protokoll, wenn möglich, aber das Betriebssystem erlaubt weiterhin Clientcomputer und Clientanwendungen, die das Kerberos-Protokoll nicht unterstützen, zu authentifizieren.
Bevor die Authentifizierung stattfinden kann, müssen sich die beiden kommunizierenden Computer mit einem Protokoll einverstanden machen, das beide unterstützen können. Für jedes Protokoll, das über den SSPI verwendet werden soll, muss jeder Computer über den entsprechenden SSP verfügen. Beispielsweise muss ein Clientcomputer und ein Server zum Verwenden des Kerberos-Authentifizierungsprotokolls sowohl Kerberos v5 unterstützen. Windows Server verwendet die Funktion EnumerateSecurityPackages, um zu identifizieren, welche SSPs auf einem Computer unterstützt werden und welche Funktionen diese SSPs sind.
Die Auswahl eines Authentifizierungsprotokolls kann auf eine der folgenden beiden Arten behandelt werden:
Einzelnes Authentifizierungsprotokoll
Wenn ein einzelnes zulässiges Protokoll auf dem Server angegeben wird, muss der Clientcomputer das angegebene Protokoll unterstützen oder die Kommunikation fehlschlägt. Wenn ein einzelnes zulässiges Protokoll angegeben wird, erfolgt der Authentifizierungsaustausch wie folgt:
Der Clientcomputer fordert den Zugriff auf einen Dienst an.
Der Server antwortet auf die Anforderung und gibt das Protokoll an, das verwendet wird.
Der Clientcomputer untersucht den Inhalt der Antwort und überprü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 autorisiert ist, auf die Ressource zuzugreifen.
Option "Verhandlungen"
Die Verhandlungsoption kann verwendet werden, um dem Client und dem Server zu ermöglichen, ein akzeptables Protokoll zu finden. Dies basiert auf dem Einfachen und geschützten GSS-API-Verhandlungsmechanismus (SPNEGO). Wenn die Authentifizierung mit der Möglichkeit beginnt, für ein Authentifizierungsprotokoll zu verhandeln, erfolgt der SPNEGO-Austausch wie folgt:
Der Clientcomputer fordert den Zugriff auf einen Dienst an.
Der Server antwortet mit einer Liste von Authentifizierungsprotokollen, die er unterstützen kann und eine Authentifizierungsanfrage oder Antwort basierend auf dem Protokoll, das seine erste Wahl ist. Der Server kann beispielsweise das Kerberos-Protokoll und NTLM auflisten und eine Kerberos-Authentifizierungsantwort senden.
Der Clientcomputer untersucht den Inhalt der Antwort und überprüft, ob es eine 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 eine der anderen Protokolle unterstützt, die vom Server aufgelistet sind, lässt der Clientcomputer den Server wissen, welches Authentifizierungsprotokoll er unterstützt, und die Authentifizierung wird fortgesetzt.
Wenn der Clientcomputer keine der aufgeführten Protokolle unterstützt, schlägt der Authentifizierungsaustausch fehl.