Procesy poświadczeń w uwierzytelnianiu systemu Windows

Uwierzytelnianie systemu Windows jest podstawą bezpiecznego dostępu w środowiskach przedsiębiorstwa, umożliwiając użytkownikom i usługom interakcję z systemami przy jednoczesnym ochronie poufnych informacji. Ten artykuł oferuje specjalistom IT kompleksowy przegląd przetwarzania poświadczeń przez system Windows podczas uwierzytelniania. Obejmuje ona kluczowe składniki, mechanizmy i architektury związane z zarządzaniem poświadczeniami, walidacją i magazynem, zapewniając jasne zrozumienie procesu uwierzytelniania w różnych systemach operacyjnych Windows.

W szczególności te składniki są omówione:

• Omówienie uwierzytelniania poświadczeń systemu Windows

• Wprowadzanie poświadczeń dla logowania użytkownika

• Wprowadzanie poświadczeń dla logowania aplikacji i usługi

• Urząd zabezpieczeń lokalnych

• Buforowane poświadczenia i walidacja

• Przechowywanie i walidacja poświadczeń

• Baza danych Menedżera kont zabezpieczeń

• Domeny lokalne i zaufane domeny

• Certyfikaty w uwierzytelnianiu systemu Windows

Omówienie uwierzytelniania poświadczeń systemu Windows

Zarządzanie poświadczeniami systemu Windows to proces, za pomocą którego system operacyjny odbiera poświadczenia z usługi lub użytkownika i zabezpiecza te informacje na potrzeby przyszłej prezentacji do uwierzytelniania docelowego. Jeśli komputer jest przyłączony do domeny, element docelowy uwierzytelniania jest kontrolerem domeny. Poświadczenia używane w uwierzytelnianiu to dokumenty cyfrowe, które kojarzą tożsamość użytkownika z jakąś formą potwierdzenia autentyczności, na przykład certyfikatu, hasła lub numeru PIN.

Domyślnie poświadczenia systemu Windows są weryfikowane względem bazy danych Menedżera kont zabezpieczeń (SAM) na komputerze lokalnym lub w usłudze Active Directory na komputerze przyłączonym do domeny za pośrednictwem usługi Winlogon. Poświadczenia są zbierane za pośrednictwem danych wejściowych użytkownika w interfejsie użytkownika logowania lub programowo za pośrednictwem interfejsu programowania aplikacji (API) do prezentowania elementu docelowego uwierzytelniania.

Informacje o zabezpieczeniach lokalnych są przechowywane w rejestrze pod HKEY_LOCAL_MACHINE\SECURITY. Przechowywane informacje obejmują ustawienia zasad, domyślne wartości zabezpieczeń i informacje o koncie, takie jak buforowane poświadczenia logowania. Kopia bazy danych SAM jest również przechowywana w tym miejscu, chociaż jest chroniona przed zapisem.

Na poniższym diagramie przedstawiono wymagane składniki oraz ścieżki, które poświadczenia przechodzą przez system w celu uwierzytelnienia użytkownika lub procesu pomyślnego logowania.

W poniższej tabeli opisano każdy składnik, który zarządza poświadczeniami w procesie uwierzytelniania w punkcie logowania dla wszystkich systemów.

Składnik	Opis
Logowanie użytkownika	Winlogon.exe to plik wykonywalny odpowiedzialny za zarządzanie bezpiecznymi interakcjami użytkowników. Usługa Winlogon inicjuje proces logowania dla systemów operacyjnych Windows przez przekazanie poświadczeń zebranych przez akcję użytkownika na bezpiecznym pulpicie (interfejs logowania) do Lokalnego Urzędu ds. Bezpieczeństwa (LSA) za pośrednictwem secur32.dll.
Logowanie aplikacji	Logowania aplikacji lub usługi, które nie wymagają logowania interakcyjnego. Większość procesów inicjowanych przez użytkownika działa w trybie użytkownika przy użyciu secur32.dll procesów inicjowanych podczas uruchamiania, takich jak usługi, są uruchamiane w trybie jądra przy użyciu Ksecdd.sys. Aby uzyskać więcej informacji na temat trybu użytkownika i trybu jądra, zobacz Aplikacje i tryb użytkownika lub Usługi i Tryb jądra.
secur32.dll	Wielu dostawców uwierzytelniania, którzy tworzą podstawę procesu uwierzytelniania.
lsasrv.dll	Usługa serwera LSA, która wymusza zasady zabezpieczeń i działa jako menedżer pakietów zabezpieczeń dla LSA. LSA zawiera funkcję Negotiate, która wybiera protokół NTLM lub Kerberos po ustaleniu, który protokół ma zakończyć się powodzeniem.
Dostawcy pomocy technicznej zabezpieczeń	Zestaw dostawców, którzy mogą indywidualnie wywoływać jeden lub więcej protokołów uwierzytelniania. Domyślny zestaw dostawców może ulec zmianie z każdą wersją systemu operacyjnego Windows, a dostawców niestandardowych można tworzyć.
netlogon.dll	Usługi wykonywane przez usługę Net Logon są następujące: Utrzymuje bezpieczny kanał komputera (nie należy go mylić z Schannel) z kontrolerem domeny. Przekazuje poświadczenia użytkownika za pośrednictwem bezpiecznego kanału do kontrolera domeny i zwraca identyfikatory zabezpieczeń domeny (SID) i prawa użytkownika dla użytkownika. Publikuje rekordy zasobów usługi w systemie nazw domen (DNS) i używa systemu DNS do rozpoznawania nazw do adresów IP (Internet Protocol) kontrolerów domeny. Implementuje protokół replikacji na podstawie zdalnego wywołania procedury (RPC) do synchronizacji podstawowego kontrolera domeny (PDC) i zapasowego kontrolera domeny (BDC).
samsrv.dll	Menedżer kont zabezpieczeń (SAM), który przechowuje lokalne konta zabezpieczeń, wymusza zasady przechowywane lokalnie i obsługuje interfejsy API.
Rejestr	Rejestr zawiera kopię bazy danych SAM, ustawień lokalnych zasad zabezpieczeń, domyślnych wartości zabezpieczeń i informacji o koncie, które są dostępne tylko dla systemu.

Wprowadzanie poświadczeń dla logowania użytkownika

Architektura dostawcy poświadczeń, która została wprowadzona w systemie Windows Server 2008, jest podstawowym mechanizmem zbierania poświadczeń użytkownika podczas logowania. Umożliwia elastyczne i rozszerzalne sposób zbierania poświadczeń od użytkowników, takich jak hasła, karty inteligentne lub biometryczne. Architektura dostawcy poświadczeń zastępuje starszą architekturę identyfikacji graficznej i uwierzytelniania (GINA) używaną we wcześniejszych wersjach systemu Windows.

Aby dowiedzieć się więcej o architekturze identyfikacji graficznej i uwierzytelniania (GINA) w starszych wersjach systemu Windows, rozwiń tę sekcję.

Architektura identyfikacji graficznej i uwierzytelniania (GINA) dotyczy systemów operacyjnych Windows Server 2003, Microsoft Windows 2000 Server, Windows XP i Windows 2000 Professional. W tych systemach każda interaktywna sesja logowania tworzy oddzielne wystąpienie usługi Winlogon. Architektura GINA jest ładowana do przestrzeni procesowej używanej przez winlogon, odbiera i przetwarza poświadczenia oraz wykonuje wywołania interfejsów uwierzytelniania za pośrednictwem LSALogonUser.

Wystąpienia usługi Winlogon dla interakcyjnego logowania są uruchamiane w sesji 0. Sesja 0 hostuje usługi systemowe i inne krytyczne procesy, w tym proces urzędu zabezpieczeń lokalnych (LSA).

Na poniższym diagramie przedstawiono proces poświadczeń dla systemów Windows Server 2003, Microsoft Windows 2000 Server, Windows XP i Microsoft Windows 2000 Professional.

Architektura dostawcy poświadczeń

Architektura dostawcy poświadczeń używa rozszerzalnego projektu przy użyciu dostawców poświadczeń. Różne kafelki logowania reprezentują tych dostawców na bezpiecznym pulpicie, który zezwala na dowolną liczbę scenariuszy logowania, w tym różne konta dla tego samego użytkownika i różnych metod uwierzytelniania, takich jak hasło, karta inteligentna i biometria.

Na poniższym diagramie przedstawiono proces poświadczeń dla architektury dostawcy poświadczeń:

Winlogon zawsze uruchamia proces interfejsu logowania po otrzymaniu zdarzenia sekwencji zabezpieczającej. Interfejs użytkownika logowania odpytyje każdego dostawcę poświadczeń o liczbę różnych typów poświadczeń, które dostawca ma skonfigurowane do wyliczania. Dostawcy poświadczeń mają możliwość określenia jednego z tych kafelków jako domyślnego. Po wyliczeniu kafelków przez wszystkich dostawców interfejs logowania użytkownika wyświetla je użytkownikowi. Użytkownik wchodzi w interakcję z kafelkiem, aby podać swoje poświadczenia. Interfejs użytkownika logowania przesyła te poświadczenia do uwierzytelniania.

Dostawcy poświadczeń nie są mechanizmami wymuszania; są one używane do zbierania i serializacji poświadczeń. Pakiety uwierzytelniania i lokalny organ zabezpieczeń wymuszają bezpieczeństwo.

Dostawcy poświadczeń są zarejestrowani na komputerze i są odpowiedzialni za następujące zadania:

• Opis informacji o poświadczeniach wymaganych do uwierzytelniania.

• Obsługa komunikacji i logiki z zewnętrznymi organami uwierzytelniania.

• Pakowanie poświadczeń na potrzeby logowania interakcyjnego i sieciowego.

Pakowanie poświadczeń na potrzeby logowania interakcyjnego i sieciowego obejmuje proces serializacji. Dzięki serializacji poświadczeń można wyświetlić użytkownikowi wiele kafelków logowania. W związku z tym organizacja może kontrolować ekran logowania, takie jak użytkownicy, docelowe systemy logowania, dostęp do sieci przed zalogowaniem oraz zasady blokady i odblokowywania stacji roboczej, przy użyciu niestandardowych dostawców poświadczeń. Wielu dostawców poświadczeń może współistnieć na tym samym komputerze. Dostawcy logowania jednokrotnego (SSO) mogą być opracowani jako standardowy dostawca poświadczeń lub jako dostawca dostępu przed logowaniem (PLAP).

Każda wersja systemu Windows zawiera jednego domyślnego dostawcę poświadczeń i jednego domyślnego dostawcy dostępu przed logowaniem, znanego również jako dostawca logowania jednokrotnego. Dostawca logowania jednokrotnego umożliwia użytkownikom nawiązywanie połączenia z siecią przed zalogowaniem się na komputerze lokalnym. Po zaimplementowaniu tego dostawcy dostawca nie wylicza kafelków w interfejsie użytkownika logowania.

Dostawca logowania jednokrotnego ma być używany w następujących scenariuszach:

• Uwierzytelnianie sieciowe i logowanie komputera są obsługiwane przez różnych dostawców poświadczeń, w tym następujące odmiany tego scenariusza:

  • Użytkownik ma możliwość nawiązania połączenia z siecią, np. z wirtualną siecią prywatną (VPN), przed zalogowaniem się do komputera, ale nie jest to konieczne.

  • Uwierzytelnianie sieciowe jest wymagane do pobrania informacji używanych podczas uwierzytelniania interakcyjnego na komputerze lokalnym.

  • Po wielu uwierzytelnieniach sieciowych następuje jeden z innych scenariuszy. Na przykład użytkownik uwierzytelnia się u dostawcy usług internetowych (ISP), uwierzytelnia się w sieci VPN, a następnie loguje się lokalnie przy użyciu poświadczeń konta użytkownika.

  • Poświadczenia buforowane są wyłączone, a połączenie usług dostępu zdalnego za pośrednictwem sieci VPN jest wymagane przed logowaniem lokalnym w celu uwierzytelnienia użytkownika.

  • Użytkownik domeny nie ma konta lokalnego skonfigurowanego na komputerze przyłączonym do domeny i musi ustanowić połączenie usług dostępu zdalnego za pośrednictwem połączenia sieci VPN przed ukończeniem logowania interakcyjnego.

• Uwierzytelnianie sieciowe i logowanie komputera są obsługiwane przez tego samego dostawcę poświadczeń, gdzie użytkownik jest wymagany do nawiązania połączenia z siecią przed zalogowaniem się do komputera.

Wyliczanie kafelków logowania

Dostawca poświadczeń wylicza kafelki logowania w następujących przypadkach:

• Do logowania na stacji roboczej. Dostawca poświadczeń zazwyczaj serializuje poświadczenia na potrzeby uwierzytelniania w lokalnym urzędzie zabezpieczeń. Ten proces wyświetla kafelki specyficzne dla każdego użytkownika i specyficzne dla systemów docelowych każdego użytkownika.

• Architektura logowania i uwierzytelniania umożliwia użytkownikowi używanie kafelków wyliczanych przez dostawcę poświadczeń w celu odblokowania stacji roboczej. Zazwyczaj aktualnie zalogowany użytkownik jest kafelkiem domyślnym, ale jeśli jest zalogowany więcej niż jeden użytkownik, wyświetlane są liczne kafelki.

• Dostawca poświadczeń wylicza kafelki w odpowiedzi na żądanie użytkownika o zmianę hasła lub inne dane osobowe, takie jak numer PIN. Zazwyczaj aktualnie zalogowany użytkownik jest kafelkiem domyślnym, ale jeśli jest zalogowany więcej niż jeden użytkownik, wyświetlane są liczne kafelki.

• Dostawca poświadczeń wylicza kafelki na podstawie serializowanych poświadczeń używanych do uwierzytelniania na komputerach zdalnych. Interfejs użytkownika poświadczeń nie używa tego samego wystąpienia dostawcy co interfejs użytkownika logowania, odblokowanie stacji roboczej lub zmiana hasła. W związku z tym informacje o stanie nie mogą być przechowywane w dostawcy między instancjami interfejsu użytkownika poświadczeń. Ta struktura powoduje wyświetlenie jednego kafelka dla każdego logowania komputera zdalnego, przy założeniu, że poświadczenia są poprawnie serializowane. Ten scenariusz jest również używany w kontroli konta użytkownika (UAC), co może pomóc zapobiec nieautoryzowanym zmianom komputera, monitując użytkownika o uprawnienia lub hasło administratora przed zezwoleniem na akcje, które mogą potencjalnie wpłynąć na operację komputera lub które mogą zmienić ustawienia wpływające na innych użytkowników komputera.

Wprowadzanie poświadczeń dla logowania aplikacji i usługi

Uwierzytelnianie systemu Windows jest przeznaczone do zarządzania poświadczeniami dla aplikacji lub usług, które nie wymagają interakcji z użytkownikiem. Aplikacje w trybie użytkownika są ograniczone pod względem zasobów systemowych, do których mają dostęp, podczas gdy usługi mogą mieć nieograniczony dostęp do pamięci systemowej i urządzeń zewnętrznych.

Usługi systemowe i aplikacje na poziomie transportu uzyskują dostęp do dostawcy obsługi zabezpieczeń (SSP) za pośrednictwem interfejsu dostawcy obsługi zabezpieczeń (SSPI) w systemie Windows, który udostępnia funkcje wyliczania pakietów zabezpieczeń dostępnych w systemie, wybierania pakietu i używania tego pakietu do uzyskania uwierzytelnionego połączenia.

Po uwierzytelnieniu połączenia klienta/serwera:

• Aplikacja po stronie klienta połączenia wysyła poświadczenia do serwera przy użyciu funkcji InitializeSecurityContext (General)SSPI .

• Aplikacja po stronie serwera połączenia odpowiada za pomocą funkcji AcceptSecurityContext (General)SSPI .

• Funkcje InitializeSecurityContext (General) SSPI i AcceptSecurityContext (General) są powtarzane do momentu wymiany wszystkich niezbędnych komunikatów uwierzytelniania w celu pomyślnego lub niepowodzenia uwierzytelniania.

• Po uwierzytelnieniu połączenia LSA na serwerze używa informacji od klienta do utworzenia kontekstu zabezpieczeń, który zawiera token dostępu.

• Następnie serwer może wywołać funkcję SSPI ImpersonateSecurityContext, aby dołączyć token dostępu do wątku impersonacji dla usługi.

Aplikacje i tryb użytkownika

Tryb użytkownika w systemie Windows składa się z dwóch systemów, które umożliwiają przekazywanie żądań we/wy do odpowiednich sterowników trybu jądra: system środowiska, który uruchamia aplikacje napisane dla wielu różnych typów systemów operacyjnych i system całkowity, który obsługuje funkcje specyficzne dla systemu w imieniu systemu środowiska.

System całkowity zarządza funkcjami specyficznymi dla systemu operacyjnego w imieniu systemu środowiskowego i składa się z procesu systemu zabezpieczeń (LSA), usługi stacji roboczej i usługi serwera. Proces systemu zabezpieczeń dotyczy tokenów zabezpieczających, udziela lub odmawia uprawnień dostępu do kont użytkowników na podstawie uprawnień zasobów, obsługuje żądania logowania i inicjuje uwierzytelnianie logowania i określa, które zasoby systemu operacyjnego wymagają inspekcji.

Aplikacje mogą działać w trybie użytkownika, w którym aplikacja może działać z uprawnieniami dowolnego podmiotu, w tym w kontekście zabezpieczeń Local System (SYSTEM). Aplikacje mogą również działać w trybie jądra, w którym aplikacja może działać w kontekście zabezpieczeń systemu lokalnego (SYSTEM).

Interfejs SSPI jest dostępny za pośrednictwem modułu secur32.dll , który jest interfejsem API używanym do uzyskiwania zintegrowanych usług zabezpieczeń na potrzeby uwierzytelniania, integralności komunikatów i prywatności komunikatów. Zapewnia warstwę abstrakcji między protokołami na poziomie aplikacji i protokołami zabezpieczeń. Ze względu na to, że różne aplikacje wymagają różnych sposobów identyfikowania lub uwierzytelniania użytkowników oraz różnych sposobów szyfrowania danych podczas podróży przez sieć, interfejs SSPI umożliwia dostęp do bibliotek linków dynamicznych (DLL), które zawierają różne funkcje uwierzytelniania i kryptograficzne. Te biblioteki DLL są nazywane dostawcami obsługi zabezpieczeń (SSP).

Zarządzane konta usług i konta wirtualne zostały wprowadzone w systemach Windows Server 2008 R2 i Windows 7 w celu zapewnienia kluczowych aplikacji, takich jak Microsoft SQL Server i Internet Information Services (IIS), z izolacją własnych kont domeny, jednocześnie eliminując konieczność ręcznego administrowania główną nazwą usługi (SPN) i poświadczeniami dla tych kont. Aby uzyskać więcej informacji na temat tych funkcji i ich roli w uwierzytelnianiu, zobacz Dokumentację zarządzanych kont usług dla systemów Windows 7 i Windows Server 2008 R2 i kont usług zarządzanych przez grupę — omówienie.

Usługi systemowe i tryb jądra

Mimo że większość aplikacji systemu Windows działa w kontekście zabezpieczeń użytkownika, który je uruchamia, nie jest to prawdą o usługach. Kontroler usług uruchamia wiele usług systemu Windows, takich jak usługi sieciowe i drukowania, gdy użytkownik uruchamia komputer. Te usługi mogą działać jako usługa lokalna lub system lokalny i mogą nadal działać po wylogowaniu ostatniego użytkownika ludzkiego.

Uwaga

Usługi zwykle działają w kontekstach zabezpieczeń nazywanych systemem lokalnym (SYSTEM), usługą sieciową lub usługą lokalną. System Windows Server 2008 R2 wprowadził usługi działające na zarządzanym koncie usługi, które są jednostkami domeny.

Przed uruchomieniem usługi kontroler usługi loguje się przy użyciu konta wyznaczonego dla usługi, a następnie przedstawia poświadczenia usługi do uwierzytelniania przez LSA. Usługa systemu Windows implementuje interfejs programowy, którego menedżer kontrolera usług może używać do kontrolowania usługi. Usługa systemu Windows może być uruchamiana automatycznie po uruchomieniu systemu lub ręcznie za pomocą programu sterowania usługą. Na przykład gdy komputer kliencki z systemem Windows przyłącza się do domeny, usługa messengera na komputerze łączy się z kontrolerem domeny i otwiera bezpieczny kanał. Aby uzyskać uwierzytelnione połączenie, usługa musi posiadać poświadczenia, którym ufają lokalny organ zabezpieczeń (LSA) komputera zdalnego. Podczas komunikacji z innymi komputerami w sieci LSA używa poświadczeń dla konta domeny komputera lokalnego, podobnie jak wszystkie inne usługi uruchomione w kontekście zabezpieczeń systemu lokalnego i usługi sieciowej. Usługi na komputerze lokalnym działają jako SYSTEM, więc poświadczenia nie muszą być przedstawiane do LSA.

Plik ksecdd.sys zarządza tymi poświadczeniami, szyfruje je oraz używa lokalnego wywołania procedury do LSA. Typ pliku to DRV (sterownik) i jest znany jako dostawca obsługi zabezpieczeń trybu jądra (SSP), zgodny ze standardem FIPS 140-2 Level 1 począwszy od systemu Windows Server 2008.

Tryb jądra ma pełny dostęp do zasobów sprzętowych i systemowych komputera. Tryb jądra uniemożliwia usługom i aplikacjom trybu użytkownika uzyskiwanie dostępu do krytycznych obszarów systemu operacyjnego, do których nie powinny mieć dostępu.

Urząd zabezpieczeń lokalnych

Urząd zabezpieczeń lokalnych (LSA) to chroniony proces systemu, który uwierzytelnia i rejestruje użytkowników na komputerze lokalnym. Ponadto LSA przechowuje informacje o wszystkich aspektach zabezpieczeń lokalnych na komputerze (te aspekty są wspólnie znane jako lokalne zasady zabezpieczeń) i udostępnia różne usługi tłumaczenia nazw i identyfikatorów zabezpieczeń (SID). Proces systemu zabezpieczeń, Usługa Serwera Lokalnego Urzędu Zabezpieczeń (LSASS), śledzi zasady zabezpieczeń i konta, które są aktywne na systemie komputerowym.

LSA weryfikuje tożsamość użytkownika na podstawie której z następujących dwóch jednostek wystawiono konto użytkownika:

• Lokalny urząd zabezpieczeń: LSA może zweryfikować informacje o użytkowniku, sprawdzając bazę danych Menedżera kont zabezpieczeń (SAM) znajdującą się na tym samym komputerze. Wszystkie stacje robocze lub serwer członkowski mogą przechowywać lokalne konta użytkowników i informacje o grupach lokalnych. Jednak te konta mogą być używane do uzyskiwania dostępu tylko do tej stacji roboczej lub komputera.

• Urząd zabezpieczeń domeny lokalnej lub zaufanej domeny: LSA kontaktuje się z jednostką, która wystawiła konto i żąda weryfikacji, czy konto jest prawidłowe i czy żądanie pochodzi od właściciela konta.

Usługa podsystemu lokalnego urzędu zabezpieczeń (LSASS) przechowuje poświadczenia w pamięci w imieniu użytkowników z aktywnymi sesjami systemu Windows. Przechowywane poświadczenia umożliwiają użytkownikom bezproblemowy dostęp do zasobów sieciowych, takich jak udziały plików, skrzynki pocztowe programu Exchange Server i witryny programu SharePoint, bez konieczności ponownego wprowadzania poświadczeń dla każdej usługi zdalnej.

Usługa LSASS może przechowywać poświadczenia w wielu formularzach, w tym:

• Tekst jawny szyfrowany odwracalnie.

• Bilety protokołu Kerberos (bilety przyznawania biletów (TGT), bilety usługi).

• Hasz NT

• Skrót programu LAN Manager (LM).

Jeśli użytkownik loguje się do systemu Windows przy użyciu karty inteligentnej, LSASSS nie przechowuje hasła w postaci zwykłego tekstu, ale przechowuje odpowiednią wartość skrótu NT dla konta i numer PIN w postaci zwykłego tekstu dla karty inteligentnej. Jeśli atrybut konta jest włączony dla karty inteligentnej wymaganej do logowania interakcyjnego, losowa wartość skrótu NT jest generowana automatycznie dla konta zamiast oryginalnego skrótu hasła. Skrót hasła, który jest generowany automatycznie, gdy atrybut jest ustawiony, nie zmienia się.

Jeśli użytkownik loguje się na komputerze z systemem Windows przy użyciu hasła zgodnego ze skrótami programu LAN Manager (LM), to uwierzytelnienie jest obecne w pamięci. Nie można wyłączyć przechowywania poświadczeń w tekstowej formie jawnej w pamięci, nawet jeśli dostawcy poświadczeń, którzy ich wymagają, są wyłączeni.

Przechowywane poświadczenia są bezpośrednio skojarzone z sesjami logowania lokalnego podsystemu urzędu zabezpieczeń (LSASS), które są uruchamiane po ostatnim ponownym uruchomieniu i nie są zamknięte. Na przykład sesje LSA z przechowywanymi poświadczeniami LSA są tworzone, gdy użytkownik wykonuje dowolną z następujących akcji:

• Zaloguje się do sesji lokalnej lub sesji protokołu RDP na komputerze.

• Uruchamia zadanie przy użyciu opcji Uruchom jako.

• Uruchamia aktywną usługę systemu Windows na komputerze.

• Uruchamia zaplanowane zadanie lub zadanie wsadowe.

• Uruchamia zadanie na komputerze lokalnym przy użyciu narzędzia administracji zdalnej.

W niektórych okolicznościach tajemnice LSA, dostępne tylko dla procesów konta SYSTEM, są przechowywane na dysku twardym. Niektóre z tych wpisów tajnych to poświadczenia, które muszą być utrwalane po ponownym uruchomieniu i są przechowywane w postaci zaszyfrowanej na dysku twardym. Poświadczenia przechowywane jako wpisy tajne LSA mogą obejmować:

• Hasło konta dla konta usług Active Directory Domain Services (AD DS) komputera.

• Hasła konta dla usług systemu Windows skonfigurowanych na komputerze.

• Hasła konta do skonfigurowanych zaplanowanych zadań.

• Hasła konta dla pul aplikacji i witryn internetowych usług IIS.

• Hasła dla kont Microsoft.

System operacyjny klienta systemu Windows zapewnia dodatkową ochronę LSA, aby zapobiec odczytywaniu pamięci i iniekcji kodu przez procesy niezachodowane, które zostały wprowadzone w systemie Windows 8.1. Ta ochrona zwiększa bezpieczeństwo poświadczeń przechowywanych i zarządzanych przez LSA.

Aby uzyskać więcej informacji na temat tych dodatkowych zabezpieczeń, zobacz Konfigurowanie dodatkowej ochrony LSA.

Buforowane poświadczenia i walidacja

Mechanizmy weryfikacji polegają na prezentacji poświadczeń w momencie logowania. Jeśli jednak komputer zostanie odłączony od kontrolera domeny, a użytkownik przedstawia poświadczenia domeny, system Windows używa procesu buforowanych poświadczeń w mechanizmie weryfikacji.

Za każdym razem, gdy użytkownik loguje się do domeny, system Windows buforuje podane poświadczenia i przechowuje je w gałęzi zabezpieczeń w rejestrze systemu operacyjnego. Dzięki poświadczeniom buforowanym użytkownik może zalogować się do członka domeny bez połączenia z kontrolerem domeny w tej domenie.

Przechowywanie i walidacja poświadczeń

Nie zawsze pożądane jest użycie jednego zestawu poświadczeń w celu uzyskania dostępu do różnych zasobów. Na przykład administrator może chcieć użyć poświadczeń administracyjnych, a nie poświadczeń użytkownika podczas uzyskiwania dostępu do serwera zdalnego. Podobnie, jeśli użytkownik uzyskuje dostęp do zasobów zewnętrznych, takich jak konto bankowe, może używać tylko poświadczeń innych niż poświadczenia domeny.

Zdalne procesy poświadczeń logowania

Protokół RDP (Remote Desktop Protocol) zarządza poświadczeniami użytkownika, który łączy się z komputerem zdalnym przy użyciu klienta pulpitu zdalnego, który został wprowadzony w systemie Windows 8. Poświadczenia w postaci zwykłego tekstu są wysyłane do hosta docelowego, na którym host próbuje wykonać proces uwierzytelniania, a w przypadku powodzenia łączy użytkownika z dozwolonymi zasobami. Protokół RDP nie przechowuje poświadczeń na kliencie, ale poświadczenia domeny użytkownika są przechowywane w usłudze LSASS.

Tryb administratora z ograniczeniami zapewnia dodatkowe zabezpieczenia scenariuszy logowania zdalnego, które zostały wprowadzone w systemach Windows Server 2012 R2 i Windows 8.1. Ten tryb pulpitu zdalnego powoduje, że aplikacja kliencka wykonuje odpowiedź na żądanie logowania sieciowego za pomocą funkcji jednokierunkowej NT (NTOWF) lub używa biletu usługi Kerberos podczas uwierzytelniania na hoście zdalnym. Po uwierzytelnieniu administratora administrator nie ma odpowiednich poświadczeń konta w usłudze LSASS, ponieważ nie zostały dostarczone do hosta zdalnego. Zamiast tego administrator ma poświadczenia konta komputera dla sesji. Dane uwierzytelniające administratora nie są dostarczane do zdalnego hosta, więc akcje są wykonywane z użyciem konta komputera. Zasoby są również ograniczone do konta komputera, a administrator nie może uzyskać dostępu do zasobów przy użyciu własnego konta.

Proces automatycznego ponownego uruchamiania logowania

Gdy użytkownik się zaloguje, LSA zapisuje poświadczenia użytkownika w zaszyfrowanej pamięci, które są dostępne tylko przez LSASS.exe, który został wprowadzony w systemie Windows 8.1. Gdy usługa Windows Update inicjuje automatyczne ponowne uruchamianie bez obecności użytkownika, te poświadczenia są używane do konfigurowania autologonu dla użytkownika.

Po ponownym uruchomieniu użytkownik jest automatycznie zalogowany za pośrednictwem mechanizmu autologonu, a następnie komputer jest dodatkowo zablokowany w celu ochrony sesji użytkownika. Blokowanie jest inicjowane za pośrednictwem usługi Winlogon, natomiast zarządzanie poświadczeniami odbywa się przez LSA. Automatycznie logując się i blokując sesję użytkownika w konsoli, aplikacje ekranu blokady użytkownika są ponownie uruchamiane i dostępne.

Aby uzyskać więcej informacji na temat usługi ARSO, zobacz Winlogon Automatic Restart Sign-On (ARSO).

Magazyn systemu Windows i Menedżer poświadczeń

Menedżer poświadczeń to funkcja Panelu sterowania do przechowywania nazw użytkowników i haseł oraz zarządzania nimi, która została wprowadzona w systemach Windows Server 2008 R2 i Windows 7. Menedżer poświadczeń umożliwia użytkownikom przechowywanie poświadczeń istotnych dla innych systemów i witryn internetowych w bezpiecznym magazynie systemu Windows.

Użytkownicy mogą zapisywać i przechowywać poświadczenia z obsługiwanych przeglądarek i aplikacji systemu Windows na komputerze lokalnym, aby ułatwić logowanie się do tych zasobów. Poświadczenia są zapisywane w specjalnych zaszyfrowanych folderach na komputerze w profilu użytkownika. Aplikacje, które obsługują tę funkcję (przy użyciu interfejsów API menedżera poświadczeń), takie jak przeglądarki internetowe i aplikacje, mogą prezentować poprawne poświadczenia innym komputerom i witrynom internetowym podczas procesu logowania.

Gdy witryna internetowa, aplikacja lub inny komputer żąda uwierzytelniania za pośrednictwem protokołu NTLM lub Protokołu Kerberos, zostanie wyświetlone okno dialogowe, w którym zostanie zaznaczone pole wyboru Aktualizuj poświadczenia domyślne lub Zapisz hasło . Aplikacja, która obsługuje interfejsy API menedżera poświadczeń, generuje to okno dialogowe, które umożliwia użytkownikowi zapisywanie poświadczeń lokalnie. Jeśli użytkownik zaznaczy pole wyboru Zapisz hasło , Menedżer poświadczeń śledzi nazwę użytkownika, hasło i powiązane informacje dotyczące używanej usługi uwierzytelniania.

Przy następnym użyciu usługi Menedżer poświadczeń automatycznie dostarcza poświadczenia przechowywane w magazynie systemu Windows. Jeśli nie zostanie zaakceptowana, zostanie wyświetlony monit o podanie poprawnych informacji o dostępie. Jeśli dostęp zostanie udzielony przy użyciu nowych poświadczeń, Menedżer poświadczeń zastąpi poprzednie poświadczenie nowym, a następnie zapisze nowe poświadczenie w magazynie systemu Windows.

Baza danych Menedżera kont zabezpieczeń

Menedżer kont zabezpieczeń (SAM) to baza danych, która przechowuje lokalne konta użytkowników i grupy. Jest obecny w każdym systemie operacyjnym Windows; jednak po dołączeniu komputera do domeny usługa Active Directory zarządza kontami domeny w domenach usługi Active Directory.

Na przykład komputery klienckie z systemem operacyjnym Windows uczestniczą w domenie sieciowej, komunikując się z kontrolerem domeny nawet wtedy, gdy żaden użytkownik nie jest zalogowany. Aby zainicjować komunikację, komputer musi mieć aktywne konto w domenie. Przed zaakceptowaniem komunikacji od komputera LSA na kontrolerze domeny uwierzytelnia tożsamość komputera, a następnie tworzy jego kontekst zabezpieczeń tak jak dla ludzkiego podmiotu zabezpieczeń. Ten kontekst zabezpieczeń definiuje tożsamość i możliwości użytkownika lub usługi na określonym komputerze, usłudze lub komputerze w sieci. Na przykład token dostępu zawarty w kontekście zabezpieczeń definiuje zasoby (takie jak zasób sieciowy lub drukarka), do których można mieć dostęp, oraz akcje (Odczyt, Zapis, Modyfikowanie), które podmiot (użytkownik, komputer lub usługa) może wykonywać do tych zasobów.

Kontekst zabezpieczeń użytkownika lub komputera może się różnić od jednego komputera do innego, na przykład gdy użytkownik loguje się do serwera lub stacji roboczej innej niż podstawowa stacja robocza użytkownika. Może również różnić się od jednej sesji do innej, na przykład gdy administrator modyfikuje prawa i uprawnienia użytkownika. Ponadto kontekst zabezpieczeń jest zwykle inny, gdy użytkownik lub komputer działa autonomicznie, w sieci lub w ramach domeny usługi Active Directory.

Domeny lokalne i zaufane domeny

Jeśli relacja zaufania istnieje między dwiema domenami, mechanizmy uwierzytelniania dla każdej domeny zależą od ważności uwierzytelnień pochodzących z innej domeny. Zaufanie pomaga zapewnić kontrolowany dostęp do zasobów udostępnionych w domenie zasobów (domenie zaufania), sprawdzając, czy przychodzące żądania uwierzytelniania pochodzą z zaufanego urzędu (zaufanej domeny). W ten sposób relacje zaufania działają jako mostki, które umożliwiają tylko weryfikowanie żądań uwierzytelniania przesyłanych między domenami.

Sposób, w jaki określone zaufanie przekazuje żądania uwierzytelniania, zależy od konfiguracji. Relacje zaufania mogą być jednokierunkowe, zapewniając dostęp z zaufanej domeny do zasobów w domenie zaufania lub dwukierunkowo, zapewniając dostęp z każdej domeny do zasobów w innej domenie. Relacje zaufania są również albo nieprzechodnie, czyli relacja zaufania istnieje tylko między dwiema domenami partnerów zaufania, lub przechodnie, w takim przypadku relacja zaufania automatycznie rozszerza się na wszystkie inne domeny, którym ufa jeden z partnerów.

Aby uzyskać informacje na temat relacji zaufania w domenie i lesie dotyczących uwierzytelniania, zobacz Delegowanie uwierzytelniania i relacji zaufania.

Certyfikaty w uwierzytelnianiu systemu Windows

Infrastruktura kluczy publicznych (PKI) to połączenie oprogramowania, technologii szyfrowania, procesów i usług, które umożliwiają organizacji zabezpieczanie komunikacji i transakcji biznesowych. Zdolność infrastruktury kluczy publicznych do zabezpieczania komunikacji i transakcji biznesowych opiera się na wymianie certyfikatów cyfrowych między uwierzytelnionymi użytkownikami a zaufanymi zasobami.

Certyfikat cyfrowy jest dokumentem elektronicznym zawierającym informacje o jednostce, do których należy, jednostce, która ją wydała, unikatowym numerze seryjnym lub innym unikatowym numerze identyfikacyjnym, wystawianiu i wygasaniu oraz cyfrowym odciskiem palca.

Uwierzytelnianie to proces określania, czy host zdalny może być zaufany. Aby ustalić jego wiarygodność, host zdalny musi dostarczyć akceptowalny certyfikat uwierzytelniania.

Hosty zdalne ustanawiają swoją wiarygodność, uzyskując certyfikat z urzędu certyfikacji. Urząd certyfikacji może z kolei mieć certyfikat z wyższego urzędu, który tworzy łańcuch zaufania. Aby określić, czy certyfikat jest godny zaufania, aplikacja musi określić tożsamość głównego urzędu certyfikacji, a następnie określić, czy jest godna zaufania.

Podobnie host zdalny lub komputer lokalny musi określić, czy certyfikat przedstawiony przez użytkownika lub aplikację jest autentyczny. Certyfikat przedstawiony przez użytkownika za pośrednictwem LSA i SSPI jest oceniany pod kątem autentyczności na komputerze lokalnym na potrzeby logowania lokalnego, w sieci lub w domenie za pośrednictwem magazynów certyfikatów w usłudze Active Directory.

** Aby utworzyć certyfikat, dane uwierzytelniania przechodzą przez algorytmy skrótu, takie jak Secure Hash Algorithm (SHA), aby wygenerować skrót komunikatu. Szyfrowany komunikat jest następnie podpisany cyfrowo przy użyciu klucza prywatnego nadawcy, aby udowodnić, że nadawca wygenerował skrót wiadomości.

Uwierzytelnianie przy użyciu kart inteligentnych

Technologia kart inteligentnych jest przykładem uwierzytelniania opartego na certyfikatach. Logowanie do sieci za pomocą karty inteligentnej zapewnia silną formę uwierzytelniania, ponieważ używa identyfikacji opartej na kryptografii i dowodu posiadania podczas uwierzytelniania użytkownika w domenie. Usługi certyfikatów Active Directory (AD CS) zapewniają kryptograficzną identyfikację za pośrednictwem wystawiania certyfikatu logowania dla każdej karty inteligentnej.

Technologia wirtualnej karty inteligentnej została wprowadzona w systemie Windows 8. Przechowuje certyfikat karty inteligentnej na komputerze, a następnie chroni go za pomocą odpornego na manipulacje mikroukładu zabezpieczeń TPM (Trusted Platform Module) wbudowanego w komputer. W ten sposób komputer staje się kartą inteligentną, która musi otrzymać numer PIN użytkownika w celu uwierzytelnienia.

Informacje o uwierzytelnianiu kart inteligentnych można znaleźć w dokumentacji technicznej karty inteligentnej systemu Windows.

Zdalne i bezprzewodowe uwierzytelnianie

Uwierzytelnianie sieci zdalnej i bezprzewodowej to inna technologia, która używa certyfikatów do uwierzytelniania. Usługi uwierzytelniania internetowego (IAS) i wirtualnych serwerów sieci prywatnej używają zabezpieczeń uwierzytelniania rozszerzonego Protocol-Transport poziomu (EAP-TLS), chronionego protokołu uwierzytelniania rozszerzonego (PEAP) lub zabezpieczeń protokołu internetowego (IPsec) do przeprowadzania uwierzytelniania opartego na certyfikatach dla wielu typów dostępu do sieci, w tym wirtualnej sieci prywatnej (VPN) i połączeń bezprzewodowych.

Aby uzyskać informacje na temat uwierzytelniania opartego na certyfikatach w sieci, zobacz Uwierzytelnianie i certyfikaty dostępu do sieci.

Treści powiązane

• Pojęcia dotyczące uwierzytelniania systemu Windows
• Omówienie techniczne uwierzytelniania systemu Windows