Windows Server 2008

Uwierzytelnianie w Windows Vista / Windows Server 2008 Udostępnij na: Facebook

Opublikowano: 5 lutego 2008

Zawartość strony
Wstęp  Wstęp
Czasy zamierzchłe  Czasy zamierzchłe
Czasy współczesne  Czasy współczesne
Zgodność  Zgodność
Czy GINA była zła  Czy GINA była zła
Podsumowanie  Podsumowanie

Wstęp

Po kilkunastu miesiącach od premiery Windows Vista każdy już powinien wiedzieć, że ten system to nie tylko nowy interfejs Aero. O ile część zmian wynika z naturalnego rozwoju, o tyle inne (a wśród nich właśnie mechanizm uwierzytelniania) zostały całkowicie przebudowane. Niniejszy artykuł ma na celu pokazanie nowej architektury. Po co, dla kogo, ile można na tym zyskać, a ile stracić – na te pytania postaram się odpowiedzieć w tym artykule.

 Do początku strony Do początku strony

Czasy zamierzchłe

Grzebiąc w historii mechanizmów uwierzytelniania, systemy Windows 9x i starsze, można całkowicie pominąć. Nawet, jeżeli ktoś uzna, że uwierzytelnianie w nich istniało, to nikt w obecnych czasach nie uzna, że gwarantowało ono jakiekolwiek bezpieczeństwo.

Równolegle istniejąca linia systemów Windows NT oraz Windows 2000 mocno się pod tym względem różniła. Tam bezpieczeństwo (i zgodność z C2) było na pierwszym miejscu, o czym każdy łatwo się mógł przekonać po paru chwilach pracy.

Zbudowany na ich podstawie system WindowsXP (oraz Windows Server 2003) odziedziczył najlepsze ówczesne rozwiązania. Warto wiedzieć, że od Windows NT 4.0 aż do Windows 2003 mechanizm uwierzytelniania niemal się nie zmienił.

Oczywiście, stopniowo udoskonalano pewne rozwiązania (na przykład obsługę kart inteligentnych), jednak architektura wyglądała za każdym razem tak samo:

  1. Najpierw wyświetlana jest prośba o Ctrl+Alt+Del. W WindowsNT 4.0 obowiązkowo, w późniejszych systemach zależnie od lokalnych polityk. Zestaw klawiszy Ctrl+Alt+Del zdefiniowany jest domyślnie, jednak można ustalić niemal dowolny inny. Ogólnie nosi on nazwę SAS, czyli Secure Attention Sequence i zawsze reaguje na niego Winlogon. Dzięki temu, niezależnie od sytuacji, po naciśnięciu tych klawiszy wyświetli się to, co Winlogon ma do zaoferowania. Zabezpiecza to przed niezauważonym przez użytkowników uruchomieniem programu przypominającego ekran logowania. Po prostu po naciśnięciu SAS i tak zgłosi się Winlogon.
  2. Po naciśnięciu SAS, Winlogon pyta bibliotekę MSGINA.DLL o to, co ma zrobić i w efekcie pojawia się okno wyświetlające pytanie o konto i hasło.
  3. Podane konto i hasło jest przez Winlogon przekazywane do LSA (Local Security Athority).
  4. LSA używa zdefiniowanej w systemie metody uwierzytelniania (MSV1_0) do sprawdzenia w bazie SAM czy podane konto i hasło są w porządku. Co ciekawe, MSV1_0 sprawdza najpierw ustawienia konta (godziny logowania i inne podobne restrykcje) i dopiero, jeżeli pozwalają one na logowanie – weryfikuje poprawność hasła.
  5. Jeżeli uwierzytelnianie przez MSV1_0 przebiegło pomyślnie, LSA dostaje komplet informacji, generuje token i przekazuje go do Winlogon.
  6. Winlogon po otrzymaniu od LSA informacji, że użytkownika można wpuścić, przyznaje użytkownikowi jego sesję. Opiera się przy tym na otrzymanych od LSA informacjach, dotyczących uprawnień użytkownika w systemie, jego tokenu itd.

Mechanizm ten był w pewnym stopniu rozszerzalny, przede wszystkim w dwóch obszarach: dla metod uwierzytelniania oraz dla wyświetlanego interfejsu. W przypadku metod uwierzytelniania, oprócz MSV1_0 podpiąć można było dowolne własne biblioteki, które otrzymywały od LSA konto i hasło i które miały wydać decyzję czy użytkownika wolno wpuścić, czy nie. Jako że biblioteki były niemal dowolne, uwierzytelnianie wcale nie musiało opierać się na bazie SAM, co otwierało spore możliwości.

Drugim obszarem był interfejs. Aby go wyświetlić, Winlogon ładował bibliotekę MSGINA.DLL. Użytkownik mógł zmienić taką bibliotekę na własną i przy jej pomocy wpływać na to, jak wygląda i zachowuje się ekran logowania.

O ile wykorzystywane przez LSA biblioteki uwierzytelniające mogły istnieć w dość dużej ilości, o tyle obsługa ekranu logowania mogła być tylko jedna. Standardowa albo niestandardowa. Jeżeli użytkownik miał bibliotekę GINA do uwierzytelniania odciskiem palca i drugą do uwierzytelniania w serwerach Novell – musiał wybierać. Dodatkowo, wadą takiej architektury było to, że biblioteka GINA miała naprawdę dużą władzę i mogła wpływać na proces logowania w stopniu większym niż tylko zmiana wyświetlanego interfejsu. Przykładowo, nie stanowiło problemu stworzenie takiej biblioteki, która mimo że zainstalowana, będzie całkowicie niewidoczna, za to chętnie zapisze na dysku wszystkie wprowadzone hasła logowania.

Alternatywne biblioteki GINA miały jeszcze jedną cechę charakterystyczną: ich stworzenie wymagało naprawdę dobrej znajomości mechanizmów systemu operacyjnego. Wprawdzie są ludzie mający taką wiedzę, jednak stosunkowo rzadko pracują jako programiści. W efekcie, niemal każdy programista zapytany o możliwość stworzenia takiej biblioteki, uciekał przed projektem tak skutecznie, jak tylko mógł. Dla inżynierów systemowych stworzenie odpowiedniej DLL nie byłoby bardzo trudne, ale ich zazwyczaj nikt nie pyta o pisanie oprogramowania.

 Do początku strony Do początku strony

Czasy współczesne

To, co w Windows Vista i Windows Server 2008 stało się z uwierzytelnianiem, określić można tylko jednym słowem: rewolucja.

Po pierwsze, należy zapomnieć skrót GINA. Dzisiaj nazywa się to Credential Provider. Czyli coś, co daje systemowi pobrane od użytkownika atrybuty, którymi usiłuje on przekonać system Windows, że to naprawdę on. Co to jest, zależy wyłącznie od fantazji twórców. Może to być: hasło, odcisk palca, skan siatkówki, ton głosu, wygląd twarzy, wybrane z ekranu obrazki, hasła jednorazowe czy SMS-owe itp. Dzięki nowemu mechanizmowi, możliwe jest rozdzielenie samej logiki pobrania danych uwierzytelniających od jej obsługi w systemie, czyli wyświetlania na ekranie i przekazania do innych modułów. Można to zobrazować na diagramie (patrz rysunek 1.).

Rys. 1. Diagram przedstawiający mechanizm logiki pobrania danych uwierzytelniających.

Rys. 1. Diagram przedstawiający mechanizm logiki pobrania danych uwierzytelniających.

Tematem niniejszego artykułu jest Credential Provider. To ten moduł zbiera dane uwierzytelniające, które przez LogonUI przekazywane są do Winlogon. W starej strukturze to Winlogon zbierał dane. Wbrew pozorom jest to niemała różnica, zwłaszcza, kiedy pomyśli się o innej nowości, jaką jest izolacja sesji 0.

W tej chwili każda sesja ma swoją instancję Winlogon, swój zestaw Credential Provider i swoje biblioteki uwierzytelniające. W efekcie, sesje użytkowników są odizolowanie nie tylko w czasie pracy, ale i w czasie podawania konta czy hasła. Ponadto niemożliwe jest zakłócenie pracy Winlogon, co źle napisana GINA mogła zrobić często wbrew woli twórców.

Chcąc w nowej strukturze napisać własny mechanizm uwierzytelniania, nie trzeba wnikać w detale dotyczące przepływu danych od między poszczególnymi modułami. To może być bardzo ciekawe, ale dla programisty tworzącego nową metodę logowania do systemu jest zazwyczaj nieistotne.

Programista chce wyświetlić ekran logowania a zebrane z niego dane oddać systemowi, niech się system martwi. Aby było to możliwe, Windows Vista/2008 oferuje zupełnie nowy sposób rozmowy z modułami pobierającymi dane. Zamiast oddać im pełnię władzy (jak to miało miejsce w Windows XP), moduły te mają jedno proste zadanie: przekazać do AuthUI informację na temat tego, jak programista wyobraża sobie zawartość ekranu logowania. Tak naprawdę, wystarczy zaprojektować wygląd i opisać to w kodzie. Nie trzeba pośredniczyć w wymianie wszystkich systemowych wywołań funkcji, co dotąd było obowiązkiem każdego, kto wymieniał bibliotekę GINA na własną.

Teraz Credential Provider wysyła zapytanie do wszystkich zarejestrowanych metod uwierzytelniania z pytaniem, jak ma wyglądać interfejs, po czym wyświetla go. I tyle. Używa do tego COM zamiast ładowania bibliotek, jak robiła to GINA. Jako że artykuł przeznaczony jest bardziej dla inżynierów niż programistów, nie będzie szczegółowo opisywał struktur danych. Wystarczy wyobrazić sobie tabelkę z informacjami, jak ma wyglądać interfejs użytkownika. Kolumny w tabelce to identyfikator (liczbowy), typ elementu oraz jego nazwa. I to wystarczy. Programista mówi, co wyświetlić, a system wie, jak to zrobić. I to jest zdrowy podział.

Przykładowo, można wyobrazić sobie jakiś interfejs, który opisać da się jako jedno pole tekstowe, jedno pole na hasło (z niewidocznym tekstem), dwa statyczne napisy i dwa checkboxy. W przypadku biblioteki GINA wymagało to niemało pracy. Obecnie – stworzenia jednej prostej tabelki. Warto zwrócić uwagę na kolumnę definiującą typ elementu. Kilka z nich zostało powyżej wspomniane, ale warto wiedzieć, że do dyspozycji twórcy interfejsów pozostają:

  • Duży tekst,
  • Mały tekst,
  • Pole tekstowe z widocznym wprowadzanym tekstem,
  • Pole tekstowe z niewidocznym wprowadzanym tekstem (hasłem),
  • Emblemat (obrazek) użytkownika,
  • Checkbox,
  • Lista rozwijalna,
  • Linki – pełniące rolę zbliżoną przycisków.

Okno logowania, wykorzystujące niestandardowe rodzaje pól, wyglądać może na przykład tak, jak na rysunku nr 2.

Rys. 2. Okno logowania.

Rys. 2. Okno logowania.

Lista rozwijalna działa w standardowy sposób (rys. 3.).

Rys. 3. Rozwijalna lista.

Rys. 3. Rozwijalna lista.

A kliknięcie w „Command Link” wywołuje dodatkowe zdefiniowane akcje (rys. 4.).

Rys. 4. Zdefiniowane akcje wywołane po kliknięciu „Command Link”.

Rys. 4. Zdefiniowane akcje wywołane po kliknięciu „Command Link”.

Programista ma do dyspozycji parę wskazówek, którymi przekazuje systemowi czy życzy sobie daną kontrolkę wyświetlać, schować, czy ustawić w trybie tylko do odczy itp. Cenną informacją, którą również można przekazać, jest poinformowanie, kiedy dana kontrolka powinna się pojawić. Tu sytuacje są dość oczywiste:

  • Logowanie,
  • Odblokowanie konsoli,
  • Zmiana hasła.

Oczywiste jest, że w każdej z sytuacji ten sam sposób uwierzytelniania może zupełnie inaczej wyglądać.

Warto tu zwrócić uwagę, że taka metoda projektowania interfejsu nie daje programiście praktycznie żadnej kontroli nad tym, co faktycznie pojawi się na ekranie. To nie jest problem programisty. Programista ma tylko wyliczyć elementy potrzebne w określonej sytuacji a resztą zajmie się system. W praktyce, interfejsy wyglądają zupełnie dobrze i jest to wynik testów, które objęły ogromną ilość kombinacji dostępnych pól.

Rolą programisty jest za to skuteczne obsłużenie rozmaitych metod uwierzytelniania. Na tym ma się znać i skupiać. Do tej pory większość czasu tracona była na wniknięcie w architekturę systemu. W Windows Vista/2008 najważniejsze jest właściwe obsłużenie samego procesu pobrania informacji od użytkownika. Czyli w to, czym własne rozwiązanie różni się od domyślnie zainstalowanego systemu.

W praktyce, zajmując się alternatywnymi metodami logowania warto wiedzieć, że biblioteka odpowiedzialna za interfejs ładowana jest przez LogonUI.exe podczas startu systemu. Dlatego jej wyrejestrowanie lub usunięcie wymaga restartu. Z drugiej jednak strony, zawsze można spróbować zabić proces LogonUI.exe. Zazwyczaj pomaga, choć nie jest to oficjalna metoda.

 Do początku strony Do początku strony

Zgodność

Nawet po pobieżnym przyjrzeniu się, jasne jest, że zmiany w architekturze uwierzytelniania muszą mieć wpływ na zgodność Windows Vista/2008 ze starszymi rozwiązaniami. I mają! Jeżeli w jakimkolwiek systemie biblioteka GINA była zmieniana, w przypadku Vista/2008 można mieć pewność, że to nie zadziała.

To poważny problem, ale zazwyczaj okazuje się, że jeżeli tylko rozwiązanie nie jest bardzo archaiczne, to dawno już istnieje wersja oparta na Credential Providers. Nowa architektura jest tak prosta, że przepisanie starszych bibliotek nie zajmuje dużo czasu.

Zdarzyć się jednak może, że nowe wersje po prostu nie istnieją. Wtedy albo należy się pogodzić z utratą funkcjonalności (co zazwyczaj jest trudne), albo wstrzymać migrację do nowego systemu. Decyzja ta poparta jednak zawsze musi być dokładną analizą potrzeb i możliwości.

Należy również zdawać sobie sprawę, że proste mechanizmy, niejednokrotnie pomagające w przypadku niezgodnych aplikacji, całkowicie zawiodą w przypadku ich zastosowania do bibliotek uwierzytelniających.

 Do początku strony Do początku strony

Czy GINA była zła

Pytanie dlaczego GINA musiała odejść nie jest proste. Ten mechanizm działał i sprawdzał się, jednak stanowił niemały problem dla twórców rozwiązań. Każdy musi przyznać, że od czasów Windows NT, sposoby uwierzytelniania zmieniły się dość mocno. Producenci oprogramowania od dawna wiedzą, jakie zmiany miały zajść, mieli szansę na dostosowanie się i zazwyczaj to zrobili. Obecnie system często wspiera logowanie biometryczne, kartami inteligentnymi, hasłami jednorazowymi, a co więcej niejednokrotnie kilkoma z tych metod równolegle. W starym modelu uwierzytelniania to nie miało szans powodzenia.

Ponadto, nie wolno zapominać, że zaszły bardzo poważne zmiany w architekturze całego procesu uwierzytelniania. Odizolowano sesję 0 i uwierzytelnianie przeniesiono do sesji użytkownika. To był najlepszy moment, żeby rozstać się z ograniczającą wszystkich starą koncepcją biblioteki GINA.

 Do początku strony Do początku strony

Podsumowanie

Podsumowując, przypomnieć należy dwa najważniejsze fakty.

Pierwszy, że architektura uwierzytelniania została gruntownie przebudowana. Drugi, że konsekwencją zmiany architektury jest całkowita niezgodność bibliotek GINA.DLL z nowymi systemami. Warto przy tym zaznaczyć, że nowa architektura znacząco upraszcza tworzenie nowych bibliotek, przez co problem w praktyce nie jest dotkliwy.

Większość opracowań o zbliżonej tematyce zawiera mniej lub więcej kodu objaśniającego całą ideę. Mają one niestety tę wadę, że są niemal niezrozumiałe dla inżynierów systemowych, którzy nie programują. Założeniem niniejszego artykułu było nieumieszczanie w nim kodu. Dzięki temu inżynier powinien pojąć, jak to działa i czego może oczekiwać. Nie musząc przy tym wiedzieć, jak to samodzielnie napisać. W efekcie, artykuł tylko przybliża nowe mechanizmy, pokazując najważniejsze ich aspekty. Jeżeli jednak ktoś zainteresowany jest szczegółami – całość dokładnie opisana jest w MSDN.


Grzegorz Tworek Grzegorz Tworek (Konsultant ISCG, MVP)
Inżynier systemowy, komputerowiec w drugim pokoleniu. Od wielu lat aktywnie promuje idee związane z bezpieczeństwem informatyki, zwłaszcza w powiązaniu z systemami Microsoft. Autor artykułów i książek na temat security, prelegent na rozmaitych konferencjach. Aktywnie uczestniczy w działaniach SEClub. Równie duży zapał do tworzenia jak i do psucia systemów sprawia, że w projektach najchętniej uczestniczy jako audytor. W lipcu 2007 został nagrodzony tytułem Most Valuable Professional w kategorii Enterprise Security. Prowadzi polski blog TechNet.
 Do początku strony Do początku strony

Windows Server 2008