Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W tym temacie referencyjnym dla specjalistów IT opisano protokoły uwierzytelniania systemu Windows, które są używane w architekturze interfejsu dostawcy obsługi zabezpieczeń (SSPI).
Interfejs dostawcy obsługi zabezpieczeń firmy Microsoft (SSPI) jest podstawą uwierzytelniania systemu Windows. Aplikacje i usługi infrastruktury, które wymagają uwierzytelniania, używają interfejsu SSPI do zapewnienia go.
SSPI to implementacja ogólnego interfejsu API usługi zabezpieczeń (GSSAPI) w systemach operacyjnych Windows Server. Aby uzyskać więcej informacji na temat interfejsu GSSAPI, zobacz RFC 2743 i RFC 2744 w bazie danych IETF RFC.
Domyślni dostawcy obsługi zabezpieczeń (SSP), którzy wywołują określone protokoły uwierzytelniania w systemie Windows, są wbudowani do interfejsu SSPI jako biblioteki DLL. Te domyślne ustawienia SSP są opisane w poniższych sekcjach. Dodatkowe SSP można zintegrować, jeśli mogą działać z interfejsem SSPI.
Jak pokazano na poniższej ilustracji, interfejs SSPI w systemie Windows udostępnia mechanizm, który prowadzi tokeny uwierzytelniania za pośrednictwem istniejącego kanału komunikacyjnego między komputerem klienckim a serwerem. Gdy dwa komputery lub urządzenia muszą zostać uwierzytelnione, aby mogły bezpiecznie komunikować się, żądania uwierzytelniania są kierowane do interfejsu SSPI, który kończy proces uwierzytelniania, niezależnie od używanego obecnie protokołu sieciowego. Interfejs SSPI zwraca przezroczyste duże obiekty binarne. Są one przekazywane między aplikacjami, w którym momencie można je przekazać do warstwy SSPI. W związku z tym interfejs SSPI umożliwia aplikacji korzystanie z różnych modeli zabezpieczeń dostępnych na komputerze lub sieci bez zmiany interfejsu na system zabezpieczeń.
W poniższych sekcjach opisano domyślne SSP, które współdziałają z SSPI. SSP są używane na różne sposoby w systemach operacyjnych Windows, aby wspierać bezpieczną komunikację w niezabezpieczonym środowisku sieciowym.
W tym temacie zawarto również następujące elementy:
Wybór dostawcy pomocy technicznej zabezpieczeń
Dostawca obsługi zabezpieczeń protokołu Kerberos
Ten SSP używa tylko protokołu Kerberos w wersji 5 zgodnie z implementacją firmy Microsoft. Ten protokół jest oparty na RFC 4120 sieciowej grupy roboczej i projektach rewizji. Jest to standardowy protokół branżowy, który jest używany z hasłem lub kartą inteligentną na potrzeby logowania interakcyjnego. Jest to również preferowana metoda uwierzytelniania dla usług w systemie Windows.
Ponieważ protokół Kerberos jest domyślnym protokołem uwierzytelniania od systemu Windows 2000, wszystkie usługi domenowe obsługują dostawcę SSP protokołu Kerberos. Te usługi obejmują:
Zapytania usługi Active Directory korzystające z protokołu LDAP (Lightweight Directory Access Protocol)
Zdalne zarządzanie serwerem lub stacją roboczą korzystającą z usługi Remote Procedure Call
Usługi drukowania
Uwierzytelnianie klient-serwer
Zdalny dostęp do plików korzystający z protokołu SMB (Server Message Block) (znany również jako wspólny internetowy system plików lub CIFS)
Rozproszone zarządzanie systemem plików i odwołania
Uwierzytelnianie intranetowe w usługach Internet Information Services (IIS)
Uwierzytelnianie autorytetu bezpieczeństwa dla zabezpieczeń protokołu internetowego (IPsec)
Żądania certyfikatów do usług certyfikatów Active Directory dla użytkowników i komputerów domeny
Lokalizacja: %Windir%\System32\kerberos.dll
Ten dostawca jest domyślnie uwzględniony w wersjach określonych na liście Dotyczy na początku tego tematu oraz Windows Server 2003 i Windows XP.
Dodatkowe zasoby dla protokołu Kerberos i dostawcy SSP protokołu Kerberos
Ulepszenia protokołu Kerberos dla systemu Windows Vista
Zmiany uwierzytelniania Kerberos dla systemu Windows 7
Dostawca obsługi zabezpieczeń NTLM
NTLM Security Support Provider (NTLM SSP) to binarny protokół wiadomości używany w interfejsie dostawcy obsługi zabezpieczeń (SSPI), umożliwiający uwierzytelnianie typu wyzwanie-odpowiedź NTLM oraz negocjowanie opcji zapewniających integralność i poufność. Protokół NTLM jest używany wszędzie tam, gdzie jest używane uwierzytelnianie SSPI, w tym na potrzeby uwierzytelniania bloku komunikatów serwera lub uwierzytelniania CIFS, uwierzytelniania HTTP Negotiate (na przykład uwierzytelniania internetowego sieci Web) i usługi zdalnego wywołania procedury. Moduł SSP NTLM zawiera protokoły uwierzytelniania NTLM oraz wersję 2 NTLM (NTLMv2).
Obsługiwane systemy operacyjne Windows mogą używać dostawcy SSP NTLM w następujących celach:
Uwierzytelnianie klienta/serwera
Usługi drukowania
Dostęp do plików przy użyciu protokołu CIFS (SMB)
Usługa zabezpieczonego zdalnego wywoływania procedur lub usługa DCOM
Lokalizacja: %Windir%\System32\msv1_0.dll
Ten dostawca jest domyślnie uwzględniony w wersjach określonych na liście Dotyczy na początku tego tematu oraz Windows Server 2003 i Windows XP.
Dodatkowe zasoby dla protokołu NTLM i dostawcy SSP NTLM
Zmiany uwierzytelniania NTLM w systemie Windows 7
Dostawca wsparcia zabezpieczeń Digest
Uwierzytelnianie metodą Digest jest standardem branżowym używanym do uwierzytelniania LDAP (Lightweight Directory Access Protocol) i uwierzytelniania sieci Web. Uwierzytelnianie typu digest przesyła poświadczenia w sieci jako skrót MD5 lub skrót komunikatu.
Digest SSP (Wdigest.dll) jest używany w następujących przypadkach:
Dostęp do usług Internet Explorer i Internet Information Services (IIS)
Zapytania LDAP
Lokalizacja: %Windir%\System32\Wdigest.dll
Ten dostawca jest domyślnie uwzględniony w wersjach określonych na liście Dotyczy na początku tego tematu oraz Windows Server 2003 i Windows XP.
Dodatkowe zasoby dla protokołu Digest i usług SSP Digest
Dostawca pomocy technicznej zabezpieczeń Schannel
Protokół Secure Channel (Schannel) jest używany do uwierzytelniania serwera internetowego, takiego jak próba uzyskania przez użytkownika dostępu do bezpiecznego serwera internetowego.
Protokół TLS, protokół SSL , protokół PRIVATE Communications Technology (PCT) i protokół Datagram Transport Layer (DTLS) są oparte na kryptografii klucza publicznego. Schannel udostępnia wszystkie te protokoły. Wszystkie protokoły Schannel używają modelu klienta/serwera. Dostawca SSP Schannel używa certyfikatów kluczy publicznych do uwierzytelniania stron. Podczas uwierzytelniania stron dostawca SSP Schannel wybiera protokół w następującej kolejności preferencji:
Transport Layer Security (TLS) w wersji 1.0
Transport Layer Security (TLS) w wersji 1.1
Transport Layer Security (TLS) w wersji 1.2
Secure Socket Layer (SSL) w wersji 2.0
Secure Socket Layer (SSL) w wersji 3.0
Technologia komunikacji prywatnej (PCT)
Uwaga PCT jest domyślnie wyłączony.
Wybrany protokół jest preferowanym protokołem uwierzytelniania, który może obsługiwać klient i serwer. Jeśli na przykład serwer obsługuje wszystkie protokoły Schannel, a klient obsługuje tylko protokoły SSL 3.0 i SSL 2.0, proces uwierzytelniania używa protokołu SSL 3.0.
Protokół DTLS jest używany podczas jawnego wywołania przez aplikację. Aby uzyskać więcej informacji na temat DTLS i innych protokołów używanych przez dostawcę Schannel, zobacz Dokumentacja techniczna dostawcy wsparcia Schannel.
Lokalizacja: %Windir%\System32\Schannel.dll
Ten dostawca jest domyślnie uwzględniony w wersjach określonych na liście Dotyczy na początku tego tematu oraz Windows Server 2003 i Windows XP.
Uwaga / Notatka
Protokół TLS 1.2 został wprowadzony w tym dostawcy w systemach Windows Server 2008 R2 i Windows 7. Usługa DTLS została wprowadzona w tym dostawcy w systemach Windows Server 2012 i Windows 8.
Dodatkowe zasoby dla protokołów TLS i SSL oraz dostawcy SSP Schannel
Negocjowanie dostawcy wsparcia zabezpieczeń
Prosty i chroniony mechanizm negocjacji GSS-API (SPNEGO) stanowi podstawę dla Negotiate SSP, który może być używany do negocjowania określonego protokołu uwierzytelniania. Gdy aplikacja wywołuje interfejs SSPI w celu zalogowania się do sieci, może określić dostawcę zabezpieczeń do przetworzenia żądania. Jeśli aplikacja określa Negotiate SSP, analizuje żądanie i wybiera odpowiedniego dostawcę do obsługi tego żądania, uwzględniając zasady bezpieczeństwa skonfigurowane przez klienta.
SPNEGO jest określony w RFC 2478.
W obsługiwanych wersjach systemów operacyjnych Windows dostawca obsługi zabezpieczeń Negotiate wybiera między protokołem Kerberos i NTLM. Negocjacja wybiera protokół Kerberos domyślnie, chyba że protokół ten nie może być używany przez jeden z systemów zaangażowanych w uwierzytelnianie lub aplikacja wywołująca nie dostarczyła wystarczających informacji do korzystania z protokołu Kerberos.
Lokalizacja: %Windir%\System32\lsasrv.dll
Ten dostawca jest domyślnie uwzględniony w wersjach określonych na liście Dotyczy na początku tego tematu oraz Windows Server 2003 i Windows XP.
Dodatkowe zasoby dla Negotiate SSP
[MS-SPNG]: Rozszerzenia prostego i chronionego mechanizmu negocjacji GSS-API (SPNEGO)
[MS-N2HT]: Specyfikacja protokołu uwierzytelniania HTTP Negotiate i Nego2
Dostawca obsługi zabezpieczeń poświadczeń
Dostawca usług zabezpieczeń poświadczeń (CredSSP) zapewnia doświadczenie użytkownika logowania jednokrotnego, gdy uruchamia nowe sesje usług terminalowych i usług pulpitu zdalnego. CredSSP umożliwia aplikacjom delegowanie poświadczeń użytkowników z komputera klienckiego (przy użyciu dostawcy SSP po stronie klienta) do serwera docelowego (za pośrednictwem dostawcy usług udostępnionych po stronie serwera) na podstawie zasad klienta. Zasady CredSSP są konfigurowane przy użyciu zasad grupy, a delegowanie poświadczeń jest domyślnie wyłączone.
Lokalizacja: %Windir%\System32\credssp.dll
Ten dostawca jest domyślnie uwzględniany w wersjach wyznaczonych na liście Dotyczy na początku tego tematu.
Dodatkowe zasoby dla dostawcy wsparcia zabezpieczeń poświadczeń
[MS-CSSP]: Specyfikacja protokołu credSSP (Credential Security Support Provider)
Dostawca usług zabezpieczeń poświadczeń i jednokrotne logowanie dla usług terminalowych
Negocjowanie usług dostawcy wsparcia zabezpieczeń dla rozszerzeń
Negotiate Extensions (NegoExts) to pakiet uwierzytelniania, który negocjuje użycie dostawców SSPs, innych niż NTLM lub protokół Kerberos, dla aplikacji i scenariuszy implementowanych przez firmę Microsoft i inne firmy programowe.
To rozszerzenie pakietu Negotiate zezwala na następujące scenariusze:
Bogata dostępność klienta w systemie federacyjnym. Dostęp do dokumentów można uzyskać w witrynach programu SharePoint i można je edytować przy użyciu w pełni funkcjonalnej aplikacji pakietu Microsoft Office.
Bogata obsługa klienta usług pakietu Microsoft Office. Użytkownicy mogą logować się do usług pakietu Microsoft Office i korzystać z w pełni funkcjonalnej aplikacji pakietu Microsoft Office.
Hostowane programy Microsoft Exchange Server i Outlook. Nie ustalono zaufania do domeny, ponieważ serwer Exchange jest hostowany w Internecie. Program Outlook używa usługi Windows Live do uwierzytelniania użytkowników.
Pełna dostępność klienta pomiędzy komputerami klienckimi a serwerami. Używane są składniki sieciowe i uwierzytelniania systemu operacyjnego.
Pakiet Windows Negotiate traktuje pakiet SSP NegoExts w taki sam sposób, jak protokoły Kerberos i NTLM. NegoExts.dll jest ładowany do lokalnego urzędu systemowego (LSA) podczas uruchamiania. Po odebraniu żądania uwierzytelniania, na podstawie jego źródła, NegoExts negocjuje między obsługiwanymi dostawcami usług zabezpieczeń. Zbiera poświadczenia i zasady, szyfruje je i wysyła te informacje do odpowiedniego dostawcy usług udostępnionych, w którym jest tworzony token zabezpieczający.
Usługi SSP obsługiwane przez NegoExts nie są samodzielnymi systemami SSP, takimi jak Kerberos i NTLM. W związku z tym w ramach dostawcy SSP NegoExts, gdy metoda uwierzytelniania zakończy się niepowodzeniem z jakiegokolwiek powodu, zostanie wyświetlony lub zarejestrowany komunikat o niepowodzeniu uwierzytelniania. Nie ma możliwości renegocjacji ani stosowania rezerwowych metod uwierzytelniania.
Lokalizacja: %Windir%\System32\negoexts.dll
Ten dostawca jest domyślnie uwzględniony w wersjach określonych na liście Dotyczy na początku tego tematu, z wyłączeniem systemu Windows Server 2008 i Windows Vista.
Dostawca obsługi zabezpieczeń PKU2U
Protokół PKU2U został wprowadzony i zaimplementowany jako dostawca wsparcia zabezpieczeń w systemach Windows 7 i Windows Server 2008 R2. Ten dostawca usług udostępnionych umożliwia uwierzytelnianie równorzędne, szczególnie za pośrednictwem funkcji udostępniania multimediów i plików o nazwie HomeGroup, która została wprowadzona w systemie Windows 7. Funkcja umożliwia udostępnianie między komputerami, które nie są członkami domeny.
Lokalizacja: %Windir%\System32\pku2u.dll
Ten dostawca jest domyślnie uwzględniony w wersjach określonych na liście Dotyczy na początku tego tematu, z wyłączeniem systemu Windows Server 2008 i Windows Vista.
Dodatkowe zasoby dla protokołu PKU2U oraz PKU2U SSP
Wybór dostawcy pomocy technicznej zabezpieczeń
Interfejs SSPI systemu Windows może używać dowolnego z protokołów obsługiwanych przez zainstalowanych dostawców pomocy technicznej zabezpieczeń. Jednak ze względu na to, że nie wszystkie systemy operacyjne obsługują te same pakiety SSP jak dowolny komputer działający pod kontrolą Windows Server, klienci i serwery muszą negocjować, aby korzystać z protokołu, który obie strony obsługują. System Windows Server preferuje komputery klienckie i aplikacje do korzystania z protokołu Kerberos, silnego protokołu opartego na standardach, jeśli to możliwe, ale system operacyjny nadal zezwala na uwierzytelnianie komputerów klienckich i aplikacji klienckich, które nie obsługują protokołu Kerberos.
Przed rozpoczęciem uwierzytelniania dwa komunikujące się komputery muszą uzgodnić protokół, który może obsługiwać oba komputery. Aby każdy protokół mógł być używany za pośrednictwem interfejsu SSPI, każdy komputer musi mieć odpowiedniego dostawcę usług bezpieczeństwa. Na przykład aby komputer kliencki i serwer używał protokołu uwierzytelniania Kerberos, muszą obsługiwać protokół Kerberos v5. System Windows Server używa funkcji EnumerateSecurityPackages , aby zidentyfikować, które dostawcy SSPs są obsługiwane na komputerze i jakie są możliwości tych dostawców SSPs.
Wybór protokołu uwierzytelniania można obsłużyć na jeden z następujących dwóch sposobów:
Protokół uwierzytelniania jednokrotnego
Jeśli na serwerze określono jeden akceptowalny protokół, komputer kliencki musi obsługiwać określony protokół lub komunikacja kończy się niepowodzeniem. Po określeniu jednego dopuszczalnego protokołu następuje wymiana uwierzytelniania w następujący sposób:
Komputer kliencki żąda dostępu do usługi.
Serwer odpowiada na żądanie i określa protokół, który będzie używany.
Komputer kliencki sprawdza zawartość odpowiedzi i sprawdza, czy obsługuje określony protokół. Jeśli komputer kliencki obsługuje określony protokół, uwierzytelnianie będzie kontynuowane. Jeśli komputer kliencki nie obsługuje protokołu, uwierzytelnianie nie powiedzie się, niezależnie od tego, czy komputer kliencki ma autoryzację dostępu do zasobu.
Opcja negocjowania
Opcja negocjowania może służyć do umożliwienia klientowi i serwerowi próby znalezienia akceptowalnego protokołu. Jest to oparte na prostym i chronionym mechanizmie negocjacji GSS-API (SPNEGO). Gdy uwierzytelnianie rozpoczyna się od opcji negocjowania protokołu uwierzytelniania, wymiana SPNEGO odbywa się w następujący sposób:
Komputer kliencki żąda dostępu do usługi.
Serwer odpowiada listą protokołów uwierzytelniania, które może obsługiwać, oraz żądanie uwierzytelniania lub odpowiedź na podstawie protokołu, który jest jego pierwszym wyborem. Na przykład serwer może wyświetlić listę protokołów Kerberos i NTLM oraz wysłać odpowiedź uwierzytelniania Kerberos.
Komputer kliencki sprawdza zawartość odpowiedzi i sprawdza, czy obsługuje którykolwiek z określonych protokołów.
Jeśli komputer kliencki obsługuje preferowany protokół, uwierzytelnianie będzie kontynuowane.
Jeśli komputer kliencki nie obsługuje preferowanego protokołu, ale obsługuje jeden z innych protokołów wymienionych przez serwer, komputer kliencki informuje serwer o tym, który protokół uwierzytelniania obsługuje, a uwierzytelnianie jest kontynuowane.
Jeśli komputer kliencki nie obsługuje żadnego z wymienionych protokołów, wymiana uwierzytelniania zakończy się niepowodzeniem.