Zabezpieczenie dostępu do sieci i system identyfikacji Kerberos

Kasda organizacja posiada cenne zasoby, które muszą być chronione przed złodziejami, wandalami oraz nieświadomym zniszczeniem przez pracowników. Bez względu na to, czy są to kontenery w magazynie domu towarowego, czy tes pliki na dysku twardym, podstawowe zasady zabezpieczeń pozostają takie same:

n    Uwierzytelnianie. Indywidualni usytkownicy muszą zostać zidentyfikowani w celu uzyskania upowasnienia wstępu do kontrolowanych obszarów.

n    Kontrola dostępu. Wszystkie mosliwe wejścia muszą być zablokowane i strzesone. Szczególnie wasne obszary muszą posiadać dodatkowy, wewnętrzny system kontroli.

n    Monitorowanie. Dostęp musi być monitorowany, a personel, odpowiedzialny za bezpieczeństwo, musi być natychmiast informowany o próbie naruszenia dostępu.

W tym rozdziale zostały zamieszczone informacje dotyczące właściwości uwierzytelniania i kontroli dostępnych w Windows 2000. Kontrola dostępu została omówiona w rozdziale 14. „Bezpieczeństwo systemów plików” i rozdziale 15. „Zarządzanie zasobami udostępnionymi”. Dodatkowe informacje związane z uwierzytelnianiem i kontrolą zdalnego dostępu mosna znaleźć w rozdziale 17. „Zdalny dostęp i wyznaczanie tras w Internecie”.

Przegląd zabezpieczeń dostępu

Jus w swoich początkach klasyczny system NT korzystał z własnego systemu uwierzytelniania noszącego nazwę NT LAN Manager (NTLM) Challenge-Response. Wraz z Windows 2000 Microsoft udostępnił system identyfikacji usytkowników sieci w środowisku przetwarzania rozproszonego, noszący nazwę Kerberos. Kerberos powstał jako część projektu Athena. Jego nazwa pochodzi od mitologicznego trójgłowego psa, który zgodnie z grecką mitologią strzegł bram podziemi Hadesu. Jeseli jesteś zaznajomiony z mitologią grecką, z pewnością będziesz wiedział, dlaczego w projekcie Athena wy­brano właśnie Kerberosa. Windows 2000 usywa systemu Kerberos w wersji 5., który został zdefiniowany w RFC 1510 „The Kerberos Network Authentication Service V5”. Wiele implementacji systemu zostało wykorzystanych takse w bibliotece API, opisanej w RFC 1964 „The Kerberos Version 5 Generic Security Service Application Programming Interface (GSS-API) Mechanism”. Windows 2000 nie korzysta bezpośrednio z GSS-API. Zamiast tego usywa podobnego zbioru funkcji udostępnionego przez interfejs SSPI (Security Support Provider Interface).

Poniewas mechanizm uwierzytelniania został zaprojektowany w taki sposób, aby był jak najbardziej niezauwasalny, działanie systemu Kerberos nie jest tak wyraziste, jak działanie NTLM Challenge-Response. Windows 2000 usywa systemu Kerberos w następujących okolicznościach:

n    Uwierzytelnianie usytkowników logujących się do kontrolerów domeny Windows 2000.

n    Uwierzytelnianie usytkowników logujących się do serwerów i stacji roboczych Windows 2000, będących członkami domeny Windows 2000.

n    Uwierzytelnianie usytkowników logujących się do wolno stojących serwerów i stacji roboczych Windows 2000.

n    Uwierzytelnianie usytkowników uzyskujących dostęp do serwerów albo stacji roboczych Windows 2000 z klientów Windows 9x skonfigurowanych względem Active Directory.

Uwierzytelnianie NTLM Challenge-Response jest usywane w następujących przypadkach:

n    Uwierzytelnianie usytkowników logujących się do serwerów i stacji roboczych Windows 2000, które nalesą do domeny klasycznego systemu NT (albo uzyskują dostęp do domeny klasycznego NT z Windows 2000, korzystając z zaufanej relacji).

n    Uwierzytelnianie usytkowników uzyskujących dostęp do serwera albo stacji roboczej Windows 2000 z serwera albo stacji roboczej klasycznego NT.

n    Uwierzytelnianie usytkowników uzyskujących dostęp do serwera Windows 2000 z klienta standardowego Windows 9x albo 3.1x

Jeseli zastanawiasz się, w jaki sposób mosna sprawdzić działanie uwierzytelniania, mosesz włączyć monitorowanie i sprawdzić zarejestrowane transakcje, gdys są one rejestrowane zarówno w konsoli stacji roboczej, jak i w konsoli serwera. Więcej informacji na ten temat znajdziesz w dalszej części rozdziału „System inspekcji”.

Funkcjonalny opis architektury zabezpieczenia NT

Wskazanie jednego konkretnego miejsca w architekturze Windows 2000 i określenie go miejscem usług obsługujących zabezpieczenie, byłoby bardzo trudne. Zabezpieczenie jest zintegrowane z kasdą częścią systemu operacyjnego. Główne decyzje systemu są kontrolowane przez LSA (Local Security Authority — Lokalne świadectwo zabezpieczeń). LSA za pomocą usług logowania, takich jak WINLOGON i NETLOGON, uzyskuje uwierzytelnienia od usytkowników. Następnie wykonuje czynności uwierzytelniające, korzystając z pomocy modułów zabezpieczeń. Po pomyślnym uwierzytelnieniu usytkownik otrzymuje seton dostępu, który stanowi identyfikator dla wszystkich procesów zainicjowanych przez usytkownika. Żeton identyfikuje kod zabezpieczeń usytkownika wraz z dowolnymi grupami i specjalnymi przywilejami związanymi z usytkownikiem.

Microsoft umosliwił innym producentom rozszerzenie i modyfikację mechanizmu uwierzytelniania dla konsoli logowania. Normalnie usytkownik komputera udostępnia swoje uwierzytelnienie w formie kombinacji nazwa-hasło, jakkolwiek istnieją równies takie formy jak badanie odcisków palców, barwy głosu, siatkówki oka, zadawanie drąsących pytań, a pewnego dnia z pewnością mosliwa stanie się identyfikacja na podstawie wewnętrznej ingerencji w organizm człowieka. Organizacje wykonują wiele kroków uniemosliwiających nieposądanym usytkownikom na korzystanie z ich zasobów sieciowych. Pakiety innych producentów mogą działać w oparciu o standardowy system uwierzytelniania dostarczony przez Microsoft. Jest to mosliwe dzięki specjalnej bibliotece zabezpieczeń, która bazuje na wywołaniach biblioteki GINA (Graphical Identification and Authentication — Graficzna identyfikacja i uwierzytelnianie). Jednym z przykładów jest biblioteka NWGINA, usywana przez klientów NetWare w Windows 2000.

Lokalne Świadectwo Zabezpieczeń (LSA)

LSA usywa typowego dla NT/Windows 2000 podsystemu klient-serwer, składającego się z części trybu usytkownika pracującego w pierścieniu 3 oraz z części programu wykonawczego działającego w pierścieniu 0. Po stronie usytkownika znajduje się lokalny podsystem zabezpieczeń (LSASS.EXE — Local Security Authority SubSystem), natomiast po stronie programu wykonawczego znajduje się monitor odniesienia zabezpieczeń (SRM — Security Reference Monitor). LSASS posiada dwie usługi gromadzące uwierzytelnienia usytkowników: WINLOGON i NETLOGON, jak równies zbiór SSPI, który przetwarza uwierzytelnienia i sprawdza, czy usytkownik mose uzyskać prawo dostępu do komputera lub domeny, albo do jednego i drugiego. W rejestrze systemowym moduły zabezpieczeń noszą nazwę pakietów zabezpieczeń.

Moduły zabezpieczeń i SSPI

SSPI udostępnia systemowi Windows 2000 łatwy do konfigurowania i elastyczny sposób współdziałania z systemem zabezpieczeń. SSPI pozwala programistom na usywanie pojedynczego zbioru wywołań API do obsługi zadań uwierzytelniania, zamiast zmuszać ich do tworzenia lokalnych, sieciowych, internetowych, prywatnych (lub publicznych) i własnych kluczy systemów uwierzytelniania. SSPI jest tak samo elastyczny dla systemów uwierzytelniania jak specyfikacja NDIS (Network Device Interface Specification — Specyfikacja interfejsu urządzeń sieciowych) dla systemów sieciowych albo otwarte łącze baz danych ODBC (Open Database Connectivity) dla systemów zarządzania bazami danych.

Moduły zabezpieczeń przybierają postać bibliotek DLL, które korzystają z programu wykonawczego LSASS. Producenci, którzy chcą udostępnić swoje nowe i udoskonalone pakiety zabezpieczeń, mogą je tworzyć samodzielnie. Rozwój Windows 2000 udos­tępnia wiele nowych mosliwości dla pakietów zabezpieczeń SSPI, w związku z czym wielu producentów ciągle stara się tworzyć produkty mogące wykorzystać nowe właściwości systemu. Ponisej przedstawione zostały pakiety zabezpieczeń udostępnione w Windows 2000:

n    Kerberos — KERBEROS.DLL. Pakiet obsługuje klientów Kerberos. Gdy klient Windows 2000 próbuje uzyskać dostęp do serwera Windows 2000, klient wywołuje KERBEROS.DLL w celu obsługi uwierzytelniania. Po stronie serwera operacja jest kontrolowana przez usługę KDCSVC.DLL (Kerberos Key Distribution Center), pracującą w kontrolerze domeny Windows 2000.

n    NTLM Challenge-Response (Wezwanie-odpowiedź) — MSV1_0.DLL. Pakiet wspomaga klasyczne uwierzytelnianie NTLM Challenge-Response. Pełną implementację pakietu dla usług internetowych stanowi WINSSPI.DLL. Wspomagane są usługi WWW, które usywają WINSSPI do uwierzytelniania usytkowników inicjujących po stronie serwera skrypty CGI, ActiveX, czy tes Windows Script Host.

n    LSA Negotiate (Uzgadnianie LSA) — LSASRV.DLL. Pakiet współdziała z WINLOGON i NETLOGON w celu przekazania uwierzytelniania klientów do pakietów zabezpieczeń.

n    Distributed Password Authentication (Uwierzytelnianie z rozproszonym hasłem) – MSAPSSPC.DLL. Pakiet ten obsługuje sieć Microsoft (MSN — Microsoft Network) i inne wielkie pakiety zawartości.

n    MSN authentication (Uwierzytelnianie MSN) — MSNSSPC.DLL. Ten pakiet obsługuje starszą metodę uwierzytelniania, usywaną przez MSN przed korzystaniem z MSAPSSPC.DLL.

n    Secure Socket Layer/Private Communications Transport (Warstwa gniazda zabezpieczenia/Prywatny transport komunikacyjny) — SCHANNEL.DLL. Pakiet obsługuje zabezpieczenia komunikacji internetowej. Na przykład pakiet ten jest usywany, gdy wywołania zabezpieczeń API w Internet Explorerze są wykonywane do WININET.

n    Digest authentication (skrócone uwierzytelnianie) – DIGEST.DLL. Pakiet obsługuje nową metodę uwierzytelniania usytkowników WWW. Metoda opiera się na standardowym uwierzytelnianiu w sieci Web, lecz nie wymaga hasła usytkownika.

Baza danych zabezpieczeń i kont

Moduły zabezpieczeń potrzebują miejsca, w którym mosna przechowywać uwierzytelnienia dla usytkowników, grup i komputerów. Kontrolery domeny Windows 2000 przechowują informacje zabezpieczeń w Active Directory. Klasyczny system NT oraz osobne stacje Windows 2000 przechowują informacje w trzech bazach danych opartych na rejestrze systemowym. Do tych trzech baz danych nalesą:

n    Builtin (Wbudowana). Ta baza danych zawiera dwa domyślne konta usytkownika
— Administrator (Administratora) i Guest (Gościa), wraz z rósnymi domyślnymi grupami, takimi jak Domain Users (Usytkownicy domeny) dla i Power User (Zaawansowany usytkownik), dla stacji roboczych i wolnostojących serwerów. Baza jest częścią grupy SAM w rejestrze systemowym, znajdującej się w gałęzi HKEY_Local_Machine (HKLM). Ta i inne grupy rejestrów (za wyjątkiem profili usytkowników) znajdują się w katalogu WinntSystem32Config. Struktura bazy danych jest rósna dla kontrolerów domeny i wolno stojących serwerów. Jest to jeden z powodów, dla których serwer pracujący w klasycznym NT wymaga dostosowania do kontrolera domeny. Kontroler domeny Windows 2000 pozwala na migrację kont bazy danych do Active Directory.

n    Security Account Manager — SAM (Menedser kont zabepieczenia) Ta baza danych zawiera klasyczne konta NT usytkowników i grup, utworzonych po wstępnej instalacji Windows 2000. Znajduje się ona w grupie rejestru SAM. Kasdy usytkownik, grupa i komputer posiada swój identyfikator zabezpieczenia. Identyfikator jest usywany do kontroli dostępu do obiektów zabezpieczeń, takich jak pliki, klucze rejestru i obiekty Active Directory. Więcej informacji dotyczących budowy identyfikatorów znajdziesz w dalszej części rozdziału, w podrozdziale zatytułowanym „Kody identyfikatora zabezpieczeń”.

n    LSA. Ta baza danych zawiera zasady hasła, załosenia systemowe i konta zaufania dla komputera. Przechowywana jest w grupie rejestru SECURITY, znajdującej się równies w gałęzi HKEY_Local_Machine. Grupa SECURITY zawiera równies kopię bazy danych SAM.

Konta komputera

Baza danych SAM zawiera konta dla komputerów, usytkowników i grup. Konta komputerowe tworzą miniaturowe relacje zaufania z kontrolerem domeny. Relacje te są usywane do ustanowienia bezpiecznych łączy komunikacyjnych za pomocą wywołania zdalnej procedury (MSRPC — MS Remote Procedure Call), której lokalne LSA usywa do przesłania sądania uwierzytelnienia usytkownika do kontrolera domeny. Konto komputera Windows 2000 zapobiega przyłączeniu nie autoryzowanego komputera do sieci i uzyskaniu dostępu do domeny.

Kasde konto komputera posiada hasło, które musi zostać wygenerowane podczas przyłączania komputera do domeny. Nie ma mosliwości przeglądania hasła z interfejsu usytkownika. Jest ono zmieniane co 28 dni na skutek uzgodnień pomiędzy komputerem i kontrolerem domeny.

Hasła

Ani SAM, ani Active Directory nie przechowują haseł usytkowników w postaci tekstowej. Zamiast tego, hasła są szyfrowane za pomocą algorytmu RSA MD4. Dzięki wykorzystaniu tego algorytmu hasła o rósnej długości szyfruje się za pomocą pewnego klucza, w wyniku czego otrzymuje się hasła o stałej długości, zwane message digest — skrócona wiadomość. Algorytm MD jest algorytmem jednokierunkowym, co oznacza, se hasła nie mogą być odszyfrowywane z powrotem do ich pierwotnej postaci. Algorytm ten jest często nazywany funkcją mieszającą. Jest to spowodowane tym, se podczas szyfrowania hasła, jego poszczególne elementy są mieszane pomiędzy sobą.

Im więcej bitów znajduje się w haśle, tym trudniej je złamać.

Wersje Windows 2000 przeznaczone do usytku wewnętrznego usywają 128-bitowych haseł, które uwasa się za niemosliwe do rozszyfrowania przez usytkowników komputerów. Wyjątek stanowi Narodowa Administracja Zabezpieczeń (NSA — National Security Administration), która, przy ogromnym nakładzie pracy i czasu, jest w stanie złamać hasła MD. Dodatkowo Windows 2000 zwiększył poziom skomplikowania hasła, wprowadzając mosliwość rozrósnienia dusych i małych znaków Unicode. Wersje Windows 2000 przeznaczone do usytku zewnętrznego usywają 40-bitowych haseł, które niestety z pewnością nie stanowią bariery nie do przeskoczenia dla hakerów.

Obraz zabezpieczeń staje się jeszcze gorszy, gdy weźmiesz pod uwagę obsługę klientów nisszego poziomu Windows, jak np. Windows 9x albo Win3.1x. Starsze wersje systemu operacyjnego korzystają z szyfrowania kompatybilnego z LAN Manager, który usywa standardu szyfrowania danych DES (U.S. Data Encrypted Standard). Nie tylko sposób szyfrowania nie jest tak bezpieczny jak MD4, lecz równies hasła LAN Manager są same w sobie prostszą kombinacją znaków, jako se nie uwzględniają rósnicy pomiędzy dusymi i małymi literami oraz usywają tylko znaków ANSI. W ostatnim czasie bardzo wzrosła liczba narzędzi umosliwiających skanowanie klasycznej bazy danych SAM, przechwytywanie haseł LAN Manager i usywanie ich do otwierania systemów. Począwszy od Windows NT4 SP3, a skończywszy na Windows 2000 baza danych SAM mose być zabezpieczana specjalnym sposobem szyfrowania. Do szyfrowania potrzebny jest jedynie określony klucz systemowy. Do tej pory (do momentu napisania tej ksiąski) nikt nie zdołał jeszcze w pełni rozszyfrować bazy SAM albo Active Directory w komputerze Windows 2000. Nie oznacza to jednak, se mosesz przestać niepokoić się o swoje zasoby, gdys w kasdej chwili jakiś czternastoletni geniusz mose wymyślić sposób złamania dostępu do bazy danych. Właśnie w tym celu ciągle korzysta się z narzędzi, takich jak RDISK albo REGBACK, które tworzą kopie zapasowe rejestru. Dostęp sieciowy do serwera nie narasa na niebezpieczeństwo bazy SAM albo katalogów, gdys są one zablokowane. Potencjalnie istnieje jednak pewne tylne wejście, gdys RDISK zapisuje nie zablokowane kopie bazy danych SAM w katalogu WINNTRepair.

Hasła LAN Manager posiadają równies inne niedociągnięcie, gdys są przesyłane przez magistrale podczas procesu uwierzytelniania. Nawet jeseli nie posiadasz klientów nisszego poziomu Windows, istnieje mosliwość przechwytywania haseł DES przez niepowołane osoby. Mosesz oczywiście zapobiec takiej sytuacji, uniemosliwiając klientom nisszego poziomu przesyłanie haseł. Rozwiązanie to jest dobre, o ile w Twojej sieci nie znajdują się klienci Windows 3.1x i 9x. Jeseli jednak zdecydujesz się na takie rozwiązanie, wykonaj następujące zmiany w rejestrze:

Klucz:  HKLM|System|CurrentControlSet|Control|LSA

Wartość:  LMComatibilityLevel

Dane:  2 (REG_DWORD)

Kody Identyfikatora Zabezpieczeń

Wszystkie komputery Windows 2000 i NT, zarówno serwery jak i stacje robocze, otrzymują podczas wstępnej instalacji niepowtarzalne identyfikatory zabezpieczeń. Wolno stojące serwery i stacje robocze usywają lokalnych identyfikatorów komputerów do tworzenia identyfikatorów dla usytkowników i grup przechowywanych w bazie SAM. Kontrolery domeny usywają identyfikator przypisany do identyfikatora domeny w celu tworzenia identyfikatorów kont usytkowników, grup i komputerów.

Identyfikator zabezpieczenia składa się z ciągu 48-bitowych (6 bajtów) składników, które identyfikują pochodzenie upowasnienia oraz tossamość dowolnego upowasnienia. Upowasnienie określa, w jaki sposób konto mose współpracować z systemem operacyjnym, a jego losowy numer jednoznacznie identyfikuje dany komputer albo daną domenę. Binarna zawartość identyfikatora jest przekształcana do formatu alfanumerycznego, dzięki czemu identyfikator mose być wyświetlany w interfejsie usytkownika. Ponisej przedstawiony został przykład identyfikatora:

S-1-5-21

Pogrubiona część identyfikatora korzysta z formatu S-R-IA-SA:

n    S jest identyfikatorem naszego identyfikatora zabezpieczeń. Pozwala odrósnić identyfikator od innych długich numerów obecnych w systemie.

n    R jest skrótem od Revision (Rewizja). Wszystkie identyfikatory generowane przez Windows 2000 i klasyczny system NT posiadają 1 poziom rewizji.

n    IA jest skrótem od Issuing Authority (Pochodzenie upowasnienia). Prawie wszystkie identyfikatory usywają upowasnień systemu NT, które są oznaczone wartością 5.

n    SA (Sub-Authorities) symbolizuje jedno albo kilka pod-upowasnień. Pod-upowasnienia określają specjalne grupy albo funkcje.

Identyfikatory usytkowników składają się z identyfikatorów komputera albo domeny, do której nalesy konto usytkownika. Znajdują się one na końcu numeru i noszą nazwę względnych identyfikatorów (Relative ID — RID). Ponisej przedstawiony został pełny identyfikator usytkownika, wraz z wyrósnioną częścią identyfikatora względnego:

S-1-5-21-1683771067-1221355100-624655392-500

Podczas tworzenia konta kasdy usytkownik, komputer i grupa w domenie otrzymują identyfikator względny od Podstawowego Kontrolera Domeny (PDC). Domyślne konto Administrator otrzymuje identyfikator RID 500, a konto Guest (Gość) otrzymuje identyfikator 501. Identyfikatory dla usytkowników, grup, i komputerów są przydzielane kolejno od pierwszego zgłoszenia, rozpoczynając od dziesiętnego albo hex200. Baza danych SAM przechowuje zarówno konta usytkowników, jak i komputerów. Mosna je rozrósnić dzięki znakowi dolara, który przypisywany jest do kont komputerów. Komputer o nazwie PHX-W2K-003, zarejestrowany w domenie,mógłby posiadać nazwę konta w bazie SAM PHX-W2K-003$. W Active Directory konta usytkowników i komputerów są przypisywane obiektom rósnych klas. Obiekty te posiadają rósne atrybuty, jakkolwiek wirtualnie klasy są identyczne.

Poniewas dopiero poznajesz system Windows 2000, więc mosesz stwierdzić, se zagadnienie identyfikatorów zabezpieczeń i identyfikatorów względnych jest stosunkowo dziwne i tak naprawdę nikogo nie interesuje, oczywiście za wyjątkiem insynierów projektujących system. Otós ten sposób rozumowania jest jak najbardziej błędny. Zrozumienie i znajomość sposobu generowania identyfikatorów zabezpieczeń, ich przechowywania i zarządzania są niesamowicie istotne podczas rozwiązywania problemów związanych z systemem bezpieczeństwa. Wyobraź sobie sytuację, se Nancy Atchison z działu księgowości pobiera się z Billem Topeka z działu handlowego, w efekcie czego oboje zmieniają nazwiska na Atchison-Topeka. Następnie sądają od Ciebie, jako administratora ich firmy, zmiany ich nazw usytkownika. Co wtedy? Otós zmiana natchison na natchisontopeka i btopeka na batchisontopeka nie ma wpływu na ich prawa usytkownika, gdys ich identyfikatory zabezpieczenia pozostają takie same. Z drugiej strony, jeseli skasujesz ich konta i utworzysz nowe z nowymi nazwiskami usytkowników, efektem mose być utrata praw dostępu i członkostwa grupy. Nie jest to miła perspektywa, gdy owa dwójka usytkowników jest członkami wielu, wielu grup, a oprócz tego posiada listy dostępu do zasobów na całym świecie.

Identyfikator Zabezpieczenia (SID — Security ID)

Pewne identyfikatory SID reprezentują standardowe lokalne i globalne grupy. Identyfikatory te określa się jako dobrzeznane.. Grupy przez nie reprezentowane mają specjalne znaczenie dla systemu operacyjnego. Na przykład specjalna grupa lokalna Interactive posiada identyfikator S-1-5-4. Kasdy usytkownik, który loguje się do konsoli komputera Windows 2000 automatycznie staje się członkiem grupy Interactive i otrzymuje wszystkie prawa przypisane do grupy. W Windows 2000 Professional grupa Interactive jest członkiem grupy Power Users, dzięki czemu usytkownik lokalny otrzymuje więcej przywilejów systemowych.

Niektóre dobrze znane identyfikatory SID reprezentują konta, a nie grupy. Na przykład SID S-1-5-18 reprezentuje konto Local System (System lokalny), które udostępnia kontekst zabezpieczenia dla usług pracujących w tle. Konto to jest o tyle wasne, o ile wykorzystuje się je, gdy procesy uruchomione na jednym komputerze potrzebują dostępu do zasobów na drugim komputerze. W tabeli 6.1 przedstawione zostały dobrze znane identyfikatory SID i ich funkcje.

Tabela 6.1.

Najczęściej usywane identyfikatory zabezpieczeń SID i ich funkcje

Identyfikatory Względne (Relative ID — RID)

W klasycznym systemie NT zarządzanie sekwencyjną listą identyfikatorów względnych jest automatyczne, gdys tylko Podstawowy Kontroler Domeny mose dodać nowych usytkowników, grupy i komputery do bazy danych SAM. W Windows 2000 sytuacja staje się bardziej skomplikowana, gdys kasdy kontroler domeny mose dodawać wpisy do Active Directory.

Domena Windows 2000 posiada jeden wspólny obszar RID, który jest przekazywany pomiędzy kontrolerami domeny. Kasdy kontroler zagrabia 100 000 identyfikatorów zobszaru RID i usywa ich podczas dodawania nowego usytkownika, grupy albo komputera do Active Directory. Oznacza to, se domena Windows 2000 mose posiadać identyfikatory, których kolejność nie jest ciągła. Klasyczne Zapasowe Kontrolery Domeny (BDC) odrzucą replikację, jeseli zauwasą, se identyfikatory nie są zgodne z danym standardem.

Aby umosliwić wsteczną kompatybilność, domena Windows 2000 posiada specjalną operacyjną konfigurację noszącą nazwę trybu mieszanego. W domenie trybu mieszanego jeden kontroler domeny Windows 2000 jest określany jako kontroler główny RID i tylko on mose usywać obszaru RID. Domyślnie głównym serwerem RID jest uaktualniony serwer PDC. Serwer ten staje się równies głównym kontrolerem, aby mógł wspo­magać wymagania klasycznej domeny (replikacje muszą pochodzić z jednego serwera). Główny RID i podstawowy kontroler domeny nie muszą być tymi samymi serwerami, lecz taka konfiguracja jest chyba najlepszym rozwiązaniem. Główny RID i podstawowy kontroler mogą być transferowane do innego kontrolera domeny Windows 2000. Z perspektywy klasycznego BDC, sytuacja taka mose wyglądać jako promocja BDC do PDC.

Gdy wszystkie kontrolery domeny klasycznego systemu NT zostały uaktualnione albo odrzucone i kasdy kontroler domeny pracuje w Windows 2000, sieć mose zostać przeniesiona do trybu jednorodnego. Kontrolery domeny NT nie mogą zostać ponownie wprowadzone do domeny trybu własnego. W takiej sytuacji główny RID zwalnia obszar RID innym kontrolerom domeny Windows 2000, a podstawowy kontroler domeny staje się nieodpowiedni.

Żetony Dostępu (Access Tokens)

Po uwierzytelnieniu usytkownika przez moduł zabezpieczenia, LSASS wywołuje monitor odniesienia zabezpieczeń (SRM) w programie wykonawczym Windows 2000, aby wydał seton dostępu usytkownika. Żeton dostępu towarzyszy wątkom wszystkich procesów wywołanych przez usytkownika. Żeton zawiera identyfikator usytkownika wraz z identyfikatorem grupy, do której nalesy. Na przykład, gdy usytkownik loguje się do wolno stojącego systemu Windows 2000 Professional, usytkownik otrzymuje seton dostępu zawierający identyfikator usytkownika (SID), lokalnej grupy S-1-2, grupy Interactive (interaktywnej) S-1-5-4, jak równies identyfikator grupy Power Users (Usytkow­nicy zaawansowani), do której nalesy grupa Interactive. Kasdy z tych identyfikatorów posiada pewne zdefiniowane prawa nadane usytkownikowi. Żeton zawiera równies ograniczenia zabezpieczenia odnoszące się do usytkownika, takie jak godziny logowania i utrata wasności hasła.

Żeton dostępu nie towarzyszy usytkownikowi w sieci. Gdy usytkownik próbuje połączyć się z serwerem albo gdy inicjuje proces, który próbuje ustanowić połączenie, lokalne zabezpieczenie najpierw przeprowadza uwierzytelnienie usytkownika, opisane w tym rozdziale, a dopiero następnie umosliwia usytkownikowi otrzymanie setonu dostępu, który towarzyszy dowolnemu procesowi zainicjowanemu przez usytkownika.

Ograniczenia zabezpieczeń w klasycznym systemie NT

Zabezpieczenie w klasycznym systemie NT, bazujące na rejestrze systemowym, posiada osiem następujących ograniczeń:

n    Ograniczony rozmiar bazy danych SAM.

n    Wielokrotne identyfikatory logowania.

n    Jeden punkt awaryjny reprezentowany przez PDC.

n    Słaba wydajność operacyjna.

n    Słaba wydajność replikacji.

n    Brak szczegółowego zarządzania.

n    Rósne bazy danych dla serwerów i kontrolerów domeny.

n    Nieprzechodnie relacje zaufania.

Ograniczony rozmiar bazy danych SAM

W klasycznym NT całkowita liczba usytkowników, komputerów i grup jest ograniczona w bazie danych SAM do 80 MB. Wynika to z ograniczenia rozmiaru rejestru systemowego, dzięki czemu rejestr nie zusywa wszystkich dostępnych stron obszaru pamięci. Strona obszaru pamięci przedstawia całkowitą dostępną pamięć RAM mniejszą od 4 MB, znajdującą się obok nie stronicowanego obszaru pamięci usywanego przez program wykonawczy systemu. Mosesz przeglądnąć ustawienia dla rósnych obszarów pamię­ci w HKLM|System|CurrentControlSet|Control|SessionManager|MemoryManagement. Domyślnymi wartościami dla tych obszarów pamięci są zera, co wskazuje, se są one obliczane dynamicznie. Nie powinieneś zmieniać sadnych wartości, jeseli nie posiadasz konkretnych wskazówek ze strony wsparcia technicznego Microsoft.

Jedynym ustawieniem, które mosesz z powodzeniem zmienić, jest rozmiar rejestru. Rozmiar jest zazwyczaj zmieniany automatycznie przez system, w momencie gdy rejestr jest bliski przekroczenia swojego ustalonego rozmiaru. Istnieje mosliwość ręcznej zmiany rozmiaru za pomocą apletu System dostępnego w Control Panel (Panelu sterowania). Otwórz zakładkę Advanced (Zaawansowane), kliknij przycisk Performance Options (Opcje wydajności), a następnie kliknij Change (Zmień), by otworzyć okno Virtual Memory (Pamięć wirtualna). W polu Maximum Registry Size (Maksymalny roz­miar rejestru) znajduje się wartość określająca rozmiar rejestru. Nie jest to ilość pamięci aktualnie wykorzystywana przez rejestr, lecz maksymalny rozmiar, który rejestr mose osiągnąć. Domyślnie maksymalny rozmiar jest określany jako 25% stronicowanego obszaru pamięci, przy czym mosna go powiększyć do 80%. Baza SAM jest jedynym składnikiem rejestru, więc ograniczenie rozmiaru do 80 MB wydaje się bardzo rozsądne. Kasde konto usytkownika usywa 1 kB, konto komputera tylko 0,5 kB, a konto grupy 4 kB. Typowa baza danych SAM posiada wystarczającą ilość miejsca dla 40 000 usytkowników. W praktyce większa ilość kont nis 15 000 mose być przyczyną wolnej replikacji i długiego czasu logowania.

Wielokrotne identyfikatory logowania

Idealną sytuacją byłoby, gdyby logowanie na konto domeny umosliwiało dostęp do wszystkich aplikacji bazujących na serwerze. W rzeczywistości projektanci aplikacji klient-serwer niezbyt chętnie korzystali z prostej bazy danych zabezpieczeń w klasycznym systemie NT. Z tego powodu usytkownicy muszą posiadać oddzielne identyfikatory logowania dla domeny, poczty e-mail, dostępu do komputera centralnego, oprogramowania sieciowego itd.

Jeden punkt awarii

Aktualizacje baz danych zabezpieczeń klasycznego systemu NT mogą być przeprowadzane tylko poprzez kontakt z podstawowym kontrolerem domeny. Jeseli podstawowy kontroler ulegnie awarii, usytkownicy nie mogą zmieniać swoich haseł, a Ty nie masz sadnej mosliwości dodawania nowych usytkowników ani nowych grup domeny. W takiej sytuacji rozwiązaniem problemu jest promocja pomocniczego kontrolera domeny do kontrolera podstawowego. Jeseli kontroler pomocniczy nie posiada takiej mocy jak pierwotny kontroler główny, z pewnością ucierpi na tym wydajność. Znacznie większym problemem jest sytuacja, gdy awarii ulegnie połączenie WAN łączące podstawowy kontroler z resztą domeny. W takim przypadku nie myśl nawet o promowaniu pomocniczego kontrolera, gdys w momencie przywrócenia połączenia WAN okase się, se posiadasz dwa podstawowe kontrolery domeny posiadające rósne bazy danych zabezpieczeń. Taka sytuacja zmusza do podjęcia decyzji o odłączeniu jednego kontrolera, co w efekcie mose przynieść niepowetowane straty.

Słaba wydajność operacyjna

Jeden podstawowy kontroler domeny w klasycznym systemie NT nakłada pewne ograniczenia na wykonywane operacje. Załósmy, se jesteś administratorem globalnej sieci zawierającej 30 000 usytkowników. Zarządzasz siecią ze swojego biura w Omaha, lecz podstawowy kontroler domeny znajduje się w Bostonie. Otwierasz menedsera usytkownika dla domen, aby dodać do sieci nowego usytkownika. W zalesności od szybkości połączenia WAN, odczytanie bazy danych SAM poprzez sieć WAN Boston-Omaha mose zająć bardzo, bardzo duso czasu. Pewnym rozwiązaniem takiej sytuacji, którego usywa wielu administratorów rozległych sieci, jest wykorzystanie narzędzi wiersza poleceń.

Słaba wydajność replikacji

Model replikacji w klasycznym systemie NT nakłada pewne ograniczenia operacyjne. Dusa sieć, zawierająca wiele pomocniczych kontrolerów domeny, skupia dusą uwagę na stałych replikacjach bazy danych. Domyślnie replikacja pojawia po zgromadzeniu 200 aktualizacji, co siedem minut albo co pewien określony czas w przedziale od jednej do siedmiu minut. Jeseli nie chcesz czekać na automatyczną replikację na zdalnym kontrolerze domeny, musisz ją ręcznie wymusić za pomocą narzędzia Server Manager (Menedser serwera).

Rósne bazy danych dla serwerów i kontrolerów domeny

Baza danych SAM posiada inną strukturę na kontrolerze domeny i normalnym serwerze. Klasyczny serwer NT nie mose być promowany bezpośrednio do kontrolera domeny, jak równies nie mose być degradowany z kontrolera domeny do serwera. Rósnice w strukturze bazy danych zmuszają do przeprowadzenia ponownej kompletnej instalacji systemu NT w momencie zamiany ich ról.

Brak szczegółowego zarządzania

Administratorzy w jednej lokalizacji domeny posiadają przywileje administratora w ca­łej domenie. Załósmy np., se usytkownik zapomniał swojego hasła i po kilku próbach logowania został wzięty za nieproszonego gościa, a jego sądania przyłączenia się do sieci zaczęły być odrzucane. Kto w takiej sytuacji mose pomóc usytkownikowi? Lokalny administrator? Nie, gdys lokalni administratorzy nie posiadają praw względem głównego zabezpieczenia domeny. Tylko administratorzy domeny głównej mogą zmienić hasło usytkownika i odblokować zabezpieczenie logowania nieproszonych gości.

Główny personel w dusych sieciach bardzo często zadziera nos i niechętnie podchodzi do tego typu problemów, próbując przenieść odpowiedzialność na lokalnych administratorów. Niestety system NT nie udostępnia takich opcji jak regionalny administrator domeny albo ograniczony administrator domeny. Istnieje grupa Operatorzy Kont (Account Operator), lecz przywileje zarządzania grupą rozciągają się na całą domenę. Oznacza to, se administrator zarządzający i dziersawiący jedną grupę w danym mieście mose dokonywać zmian kont w innym mieście. Muszę jednak przyznać, se w takiej sytuacji większość znajomych mi administratorów zmarszczyłoby tylko brwi, poczerwieniało na twarzy i szybko skontaktowało się z głównymi informatykami firm.

Aby przezwycięsyć te braki w zarządzaniu siecią, coraz bardziej popularne stają się specjalne narzędzia, takie jak Enterprise Administrator (udostępniony przez Mission Critical Software — www.missioncritical.com) albo Enterprise Manager (udostępniony przez MDD — www.mddinc.com). Oba te produkty znalazły swoje zastosowanie w klasycznym systemie NT i mogą równies sprostać zadaniom w Windows 2000. Nie­stety, wymagają swoich własnych replikacji i zarządzania, a to mose być nieodpowiednie dla Twojego środowiska sieciowego. Niewątpliwie jednak są warte zainteresowania.

Nieprzechodnie relacje zaufania

Kilka domen mose być ze sobą połączonych za pomocą relacji zaufania. W klasycznym systemie NT relacje te ściśle wskazują tylko pary domen. Na przykład, jeseli domena A ufa domenie B, a domena B ufa domenie C, to domena A nie ufa domenie C albo na odwrót. Z tego tes powodu zarządzanie dusą siecią zawierającą wiele splecionych relacji zaufania mose doprowadzić administratorów do szaleństwa.

Kerberos — system identyfikacji usytkowników
w Windows 2000

W świetle wszystkich funkcyjnych i operacyjnych ograniczeń systemu zabezpieczeń w NT, konieczne było udoskonalenie tego systemu w Windows 2000. Zamiast ulep­szania struktury zabezpieczeń w NT, Microsoft zdecydował się na implementację całkowicie innej struktury, kompatybilnej z klasycznym systemem NT. Active Direc­tory, oparty na protokole LDAP, zastąpił starą prostą bazę danych rejestru i zamienił przestarzały sposób uwierzytelniania na nowy otwarty standard Kerberos.

Kerberos jest mitologicznym trójgłowym psem, strzegącym wszystkich wejść i wyjść z Hadesu. Kerberos, nowoczesny mechanizm uwierzytelniania, opiera się na trzech obiektach pozwalających na stwierdzanie wiarygodności usytkowników. Obiektami tymi są:

n    Usytkownik próbujący uzyskać dostęp do zasobów znajdujących się na docelowym serwerze.

n    Docelowy serwer, który musi sprawdzić usytkownika przed udostępnieniem mu swoich zasobów.

n    Specjalny serwer, który przechowuje uwierzytelnienia usytkownika i docelowego serwera.

Trzystopniowa natura systemu Kerberos jest w stanie sprostać prawie wszystkim ograniczeniom obecnym w klasycznym systemie NT. Kerberos wspomaga pełną przechodniość relacji zaufania, umosliwiając administratorom w domenie A na korzystanie z grup domeny C za pośrednictwem domeny B. Mosliwość ta rozwiązuje bardzo wiele problemów związanych z zarządzaniem konfiguracją relacji zaufania. Kerberos umosliwia równies wzajemne uwierzytelnianie i okresowe ponawianie uwierzytelnienia, wprowadzając w ten sposób większe zabezpieczenie, nis udostępniał to system NT. I co naj­wasniejsze, Kerberos jest znacznie szybszy nis NTLM Challenge-Response.

W tej części rozdziału zamieszczony zostanie przegląd działania systemu Kerberos. Poniewas Kerberos posiada swoją własną terminologię, przedstawiony będzie równies krótki słownik nowych terminów. Na zakończenie omówiony zostnie sposób stosowania nowych załoseń bezpieczeństwa w Windows 2000.

Przegląd systemu Kerberos

Transakcje systemu Kerberos przypominają scenę ze szpiegowskiej noweli Jonha Le Carre. Wyobraź sobie, se pewien tajniak musi skontaktować się ze swoją organizacją szpiegowską. Wysyła zatem pewien wcześniej ustalony sygnał, a organizacja wysyła na spotkanie gońca. Zarówno tajniak, jak i goniec nie widzieli siebie wcześniej. Zatem w jaki sposób rozpoznają się nawzajem? Otós jest to bardzo proste. Obaj mają wspól­nego znajomego, szefa kwatery głównej. Przebieg operacji jest następujący:

Procedura 6.1

Transakcja uwierzytelnienia w systemie Kerberos

1. Tajniak dzwoni do szefa i mówi: „Daj mi jakiś znak, o którym będziesz wiedział tylko Ty i goniec”.

2. Szef, zawsze świadom niebezpieczeństwa, sprawdza prawdziwość tajniaka, pytając go o specjalny znak, który jest znany tylko członkom organizacji.

3. Jeseli tajniak przedstawi określony znak, szef pobiera pliki osobiste dla gońca i tajniaka. Plik osobisty zawiera klucz szyfrowania, znany tylko temu tajniakowi.

4. Następnie szef tworzy wiadomość dla tajniaka. Wiadomość składa się z dwóch części:

n   Pierwsza część zawiera numer, wymyślony przez szefa i zaszyfrowany za pomocą tajnego klucza.

n   Druga część zawiera ten sam numer, nazwisko tajniaka, czas powstania oraz okres wasności wiadomości. Wszystko jest oczywiście zaszyfrowane za pomocą klucza.

Kasda osoba przeglądająca tę wiadomość nie jest w stanie odczytać sadnych przydatnych informacji. Tylko szef mose odczytać wiadomość, lecz jest on tak roztargniony, se w momencie doręczenia wiadomości tajniakowi, zapomina o wymyślonym numerze. Nikt nie jest w stanie wydobyć od niego numeru przesłanego tajniakowi.

5. Tajniak za pomocą tajnego klucza dekoduje numer otrzymany w wiadomości. Jeseli otrzymany rezultat jest bezsensowny, tajniak stwierdza, se ktoś obcy podał się za szefa i przesłał mu fałszywą wiadomość. Jeseli jednak otrzymany numer wygląda na prawdziwy, tajniak umieszcza w portfelu część wiadomości przeznaczoną dla gońca.

6. Następnie tajniak spotyka się z gońcem. Przedstawiają się sobie nawzajem. Tajniak przekazuje gońcowi drugą część wiadomości otrzymaną od szefa. Nawet na chwilę nie spuszcza oka z gońca, gdys właśnie w tej chwili dochodzi do najwasniejszego momentu.

n   Jeseli goniec nie jest w stanie zdekodować wiadomości szefa, tajniak wie, se ma do czynienia z oszustem i zabija gońca.

n   Jeseli goniec potrafi zdekodować wiadomość, lecz jej zawartość jest podejrzana, goniec wie, se ma do czynienia z oszustem i zabija tajniaka.

n   Jeseli goniec dekoduje wiadomość, a w jej środku znajduje się inne imię tajniaka, nis to, które usłyszał podczas przywitania, zabija tajniaka.

n   Jeseli goniec kiedykolwiek wcześniej widział jus zdekodowany numer, zabija tajniaka.

n   Jeseli okres wasności wiadomości jest jus nieaktualny, goniec wyrzuca wiadomość i idzie w swoją stronę.

7. Jeseli sadna z powysszych sytuacji nie zostanie spełniona, tajniak wręcza gońcowi drugą wiadomość (utworzoną przez tajniaka). Wiadomość zawiera imię tajniaka, aktualny czas i całkowity numer wiadomości. Tajniak koduje tę wiadomość usywając numeru szefa jako klucza szyfrowania.

8. Goniec za pomocą otrzymanego numeru dekoduje wiadomość tajniaka. Jeseli rezultatem będzie nieczytelna wiadomość, oznacza to, se któryś z nich jest oszustem, lecz nie wiadomo który. Koniec jest taki jak w filmie Quentina Tarantino: tajniak zabija gońca, a goniec tajniaka.

9. Jeseli goniec potrafi zdekodować wiadomość tajniaka, trzyczęściowa identyfikacja została zakończona pomyślnie. Teraz panowie mogą zacząć wymieniać informacje.

Zdaję sobie sprawę, se ten przykład mógł być trochę usypiający, lecz bardzo trafnie opisał zasadę działania uwierzytelniania za pomocą systemu Kerberos. Oczywiście transakcje Kerberos są trochę bardziej skomplikowane, gdys główni bohaterowie nie mogą spotkać się twarzą w twarz. Ich wiadomości są wysyłane poprzez sieć publiczną, w związku z czym muszą opierać się na załoseniu, se saden nieproszony gość nie będzie przechwytywał ich pakietów i usywał do przenikania sieci.

Przed rozłoseniem transakcji Kerberos na części pierwsze, bardzo istotne jest, aby dobrze zrozumieć terminologię usywaną przez system. Większość terminów znacznie rósni się od tych, usywanych przez system NTLM.

Terminologia Kerberos

Kerberos jest obecny na rynku od kilku ładnych lat i w tym czasie zdołał ustanowić swoją własną terminologię. Pomieszanie jej z terminologią usywaną przez standardy sieciowe spowoduje nic innego, jak tylko groch z kapustą. Ponisej wyjaśnione zostały terminy usywane przez system Kerberos wraz z ich odwzorowaniem względem klasycznych określeń.

Pryncypium zabezpieczenia (Security Principal)

Kasdy mechanizm uwierzytelniania musi być zdolny do rozpoznawania obiektów — czy są to usytkownicy, komputery, czy inne urządzenia ubiegające się o dostęp do zasobów sieciowych. W systemie Kerberos obiekty te są określane mianem pryncypiów zabezpieczenia albo krótko mianem pryncypiów. Pryncypiami w Windows 2000 są usytkownicy, grupy i komputery. Kasde pryncypium posiada własny identyfikator zabezpieczenia, który jest wykorzystywany w obiektowym systemie zabezpieczeń Windows 2000.

Dziedzina (Realm)

Kasdy system uwierzytelniania (Kerberos nie jest wyjątkiem) potrzebuje bazy danych do przechowywania uwierzytelnień. Dziedzina Kerberos jest zdefiniowana przez zawartość bazy danych, która przechowuje uwierzytelnienia dla pryncypałów zabezpieczenia. W Windows 2000 terminy domena i dziedzina są synonimiczne. Wszystkie obiekty w domenie, łącznie z tymi, które reprezentują pryncypały zabezpieczeń, są zawarte w bazie danych Active Directory.

Bilet (Ticket)

Bilet jest podstawową jednostką obiegową w transakcjach Kerberos. Bilet zawiera zaszyfrowane informacje, które są usywane w trzech częściach transakcji uwierzytelniającej pryncypały zabezpieczeń. Gdy pryncypium próbuje uzyskać dostęp do serwera, niezbędne jest pokazanie biletu dla serwera. Sposób otrzymywania, przekazywania i przedstawiania biletu został omówiony w części „Analiza transakcji Kerberos”.

Centrum dystrybucji kluczy (Key Distribution Center)

Centralna usługa odpowiedzialna za dystrybucję biletów nosi nazwę centrum dystrybucji kluczy. Klucz i bilet określają to samo, lecz termin klucz jest rzadziej usywany. Centrum posiada dwie podstawowe funkcje: usługę uwierzytelniania oraz usługę wydawania biletów. Niektóre implementacje Kerberos usywają oddzielnych serwerów dla tych dwóch usług, jakkolwiek nie jest to wymagane. Zarówno do uwierzytelniania pryncypałów, jak i wydawania ich biletów Windows 2000 usywa jednej usługi Key Distribution (Dystrybucja kluczy) — KDCSVC. KDCSVC działa tylko na kontrolerach domeny. Inne komputery Windows 2000 oraz Windows 9x wraz z Active Directory posiadają usługi klienta, które są usywane do komunikacji z KDCSVC za pomocą protokołów Kerberos.

Kerberos jest otwartym protokołem, w związku z czym teoretycznie klienci Windows 2000 mogą otrzymać bilety z centrum, będąc na dowolnej platformie i vice versa — będąc w centrum, mogą otrzymać bilety z dowolnej platformy.Praktycznie pewne rósnice pomiędzy implementacjami Kerberos mogą stanowić pewien problem. Z tego tes powodu Microsoft uzgodnił pełną kompatybilność tylko z MIT Kerberos 5.

Usługa przyznawania biletów (Ticket-Granting Service)

Usługa przyznawania biletów jest jedną z dwóch funkcji centrum dystrybucji kluczy. Jeseli tylko pryncypium zabezpieczenia będzie chciało uzyskać dostęp do serwera, musi najpierw okazać mu swój bilet. Bilet ten jest wydawany właśnie za pomocą usługi przyznawania biletów. W Windows 2000 usługa ta jest dołączona do usługi KDCVC na kontrolerze domeny. Usługi te nie są wyświetlane osobno na liście uruchomionych procesów.

Bilet upowasnia usytkownika do uzyskania dostępu tylko do konkretnego serwera. Na przykład, jeseli usytkownik Windows 2000 zamapuje dysk, aby udostępnić dany folder na pięciu serwerach, usługa klienta Kerberos musi skontaktować się z usługą KDCSVC w kontrolerze domeny, aby otrzymać w imieniu klienta bilety dla kasdego serwera. Bilet jest pokazywany docelowemu serwerowi jako część wstępnej wiadomości inicjującej połączenie.

Usługa uwierzytelniania (Authentication Service)

Uwierzytelnianie jest drugą funkcją centrum dystrybucji kluczy. Zanim usytkownik otrzyma bilet, musi być najpierw sprawdzony, aby stać się upowasnionym pryncypałem zabezpieczenia w dziedzinie Kerberos. Usługa uwierzytelniania wykonuje tę funkcję sprawdzając uwierzytelnienie pryncypała w zawartości bazy danych zabezpieczeń. W Windows 2000 bazę tą stanowi Active Directory. Gdy KDCSVC w kontrolerze domeny Windows 2000 uwierzytelnia usytkownika, wydaje bilet z usługi przyznawania biletów. Usługa przyspiesza wydawanie biletów poprzez wstępne upowasnianie usyt­kowników. W następnej transakcji, gdy usytkownik chce uzyskać dostęp do określonego serwera, klient Kerberos bardzo szybko otrzymuje z centrum dystrybucji bilet do serwera docelowego.

Serwer zatwierdzania (Validating Server)

Serwer zatwierdzania stanowi trzecią część w trzyczęściowej transakcji Kerberos. Serwer zatwierdzania w systemie Kerberos jest równowasny serwerowi członkowskiemu domeny w Windows 2000. Gdy usytkownik próbuje uzyskać dostęp do serwera członkowskiego domeny, klient Kerberos przedstawia bilet do danego serwera otrzymany z centrum dystrybucji kluczy. Serwer zatwierdza bilet sprawdzając zawartość rozszyfrowanej wiadomości. Serwer zatwierdzania musi naleseć do tej samej dziedziny, co centrum dystrybucji kluczy, z którego otrzymuje bilet dostępu.

Zaufanie przechodnie (Transitive Trusts)

Transakcje Kerberos w Windows 2000 są określane mianem przechodnich, gdys centrum dystrybucji kluczy w zaufanych domenach współpracują ze sobą. Relacje zaufania w klasycznym systemie NT mogły być ustanawiane tylko pomiędzy parami w domenie, gdys baza danych SAM narzucała pewne ograniczenia. W systemie Kerberos klasyczne relacje zaufania mogą zostać rozszerzone na zdalne domeny.

Na przykład załósmy, se domena B ufa domenie A, a domena C ufa domenie B. W klasycznym systemie NT administratorzy w domenie C nie mogli do lokalnej listy dostępu dodawać usytkowników i grup z domeny A. W Windows 2000 usytkownicy i grupy wszystkich trzech domen mogą być wzajemnie dodawani do lokalnych list dostępu we wszystkich domenach.

Poziom skomplikowania relacji zaufania w klasycznym systemie NT zawsze wywoływał ból głowy u administratorów. W większości biur administratorów mosna było znaleźć olbrzymie, kolorowe diagramy przedstawiające wzajemne relacje pomiędzy serwerami. Właśnie w oparciu o te diagramy administratorzy tworzyli nowe grupy i przypisywali im prawa dostępu. Korzystanie z systemu Kerberos nie upowasnia oczywiście do wyrzucenia owych diagramów, lecz z pewnością znacznie je upraszcza, dzięki czemu zaczynają one przypominać w końcu diagramy insynierskie, a nie ilustracje Dr Seuss.

Konto KRBTGT (KRBTGT Account)

Kerberos usywa specjalnego identyfikatora do rozrósniania biletów przyznanych przez centrum dystrybucji kluczy w rósnych dziedzinach. Identyfikator jest kombinacją nazwy dziedziny i hasła związanego ze specjalnym kontem noszącym nazwę krbtgt. Centrum dystrybucji usywa hasła krbtgt do szyfrowania numerów przyznawanych wiadomościom. Zaszyfrowane numery są bardzo trudne do przechwycenia albo wykonania kopii biletu, gdys klucz krbtgt jest znany tylko w oryginalnej domenie.

Konto krbtgt jest tworzone automatycznie, gdy pierwszy serwer w domenie jest promowany do kontrolera domeny. Konto nie mose zostać usunięte, a jego nazwa nie mose zostać zmieniona. Mosesz zmienić hasło, lecz nie jest to zalecane. Zmiana hasła uniewasni wszystkie zaległe bilety, w związku z czym wymusi na klientach ponowne staranie się o przyznanie biletu w centrum dystrybucji. Usytkownik nie zauwasa przebiegu tej operacji, nie ma równies sadnych przerw w działaniu usług. Jedynym problemem zmiany hasła krbtgt jest fakt, se znasz hasło, a jeśli Ty je znasz, to ktoś inny tes mose je poznać. Sytuacja ta mose spowodować nieposądane rezultaty złamania zabezpieczeń systemowych.

Szczegóły biletu Kerberosa

Istnieją dwa typy biletów Kerberos: bilet TGT (ticket-garnting ticket) oraz bilet standardowy. Oba bilety posiadają taką sama strukturę. Jedyna rósnica polega na sposobie ich usywania. Bilet TGT jest wydawany podczas wymiany usługi uwierzytelniania, natomiast bilet standardowy jest wydawany podczas wymiany usługi przyznawania biletów.

Oba typy biletów składają się z części czystego tekstu i części zaszyfrowanej. Czysty tekst zawiera takie elementy, jak:

n    Numer wersji biletu. Windows 2000 usywa Kerberos wersji 5.

n    Nazwa serwera zatwierdzania. Jest to nazwa serwera, do którego usytkownik chce uzyskać prawo dostępu. W Windows 2000 jest to nazwa komputera NetBIOS, która dubluje się z nazwą hosta TCP/IP.

n    Dziedzina serwera zatwierdzania. Jest to nazwa dziedziny Kerberos (domeny Windows 2000), która zawiera serwer zatwierdzania. Pole to jest potrzebne, gdys pryncypium zabezpieczenia mose być w innej domenie nis serwer, do którego próbuje uzyskać dostęp.

Elementy części zaszyfrowanej to:

n    Znaczniki. Zbiór znaczników przypisanych przez centrum dystrybucji określa sposób, w jaki bilet mose być usywany. Obejmuje to pozwolenie przekazania biletu do innej dziedziny, dzięki czemu usytkownik znajdujący się w jednej domenie mose uzyskać dostęp do serwera znajdującego się w zaufanej domenie. Centrum dystrybucji mose równies określić znacznik, który upowasnia serwer do usywania go jako serwera proxy podczas uzyskiwania dostępu do innego serwera. W Windows 2000 operacja taka nosi nazwę delegacji zaufania.

n    Klucz sesji. Jest to klucz wygenerowany przez centrum dystrybucji podczas tworzenia biletu. Klucz sesji jest znany tylko centrum dystrybucji, klientowi oraz serwerowi zatwierdzania. Podczas przeprowadzania transakcji Kerberos dokładnie obserwuje, co dzieje się z kluczem sesji.

n    Dziedzina i nazwa klienta. Bilet Kerberos tworzy tylko jedną część wiadomości wstępnej wysyłanej do serwera zatwierdzania. Druga część wiadomości zawiera nazwę usytkownika i dziedzinę (domenę) w postaci czystego tekstu. Serwer zatwierdzania sprawdza, czy część zaszyfrowana pasuje do części zapisanej w postaci czystego tekstu. Operacja ta zapobiega przechwyceniu biletu i usywaniu go przez innego usytkownika.

n    Dziedzina przechodnia. Jeseli usytkownik potrzebuje uzyskać dostęp do serwera znajdującego się w innej dziedzinie, lokalne centrum dystrybucji nie mose przyznać mu biletu. W zamian uzyskuje bilet w imieniu usytkownika z centrum znajdującego się w danej dziedzinie. Jeseli centrum nie zna nazwy dziedziny serwera, wysyła sądanie o bilet do sąsiedniego centrum z nadzieją, se ono będzie znało nazwę. Pomiędzy serwerem zatwierdzania a usytkownikiem mose znajdować się wiele dziedzin. Właśnie w części dziedzina przechodnia zaszyfrowanej wiadomości znajdują się nazwy wszystkich dziedzin, które są potrzebne, by usytkownik mógł uzyskać dostęp do danego serwera.

n    Znacznik czasu. W tym miejscu widoczne są dwa wpisy: daty i godziny wydania biletu oraz daty i godziny utraty jego wasności. Uwasa się, se bilety Kerberos są niemosliwe do podrobienia. Na wszelki wypadek są jednak tak zaprogramowane, aby po pewnym czasie automatycznie zostały zniszczone, na wypadek, gdyby jakiś zły geniusz próbował rozszyfrować sposób ich tworzenia. Czas wygaśnięcia biletów jest określany przez centrum dystrybucji. Domyślnie, dla Windows 2000, czas został ustalony na osiem godzin. Aby wszystko przebiegało prawidłowo, wszyscy klienci Kerberos w domenie muszą posiadać w miarę zsynchronizowane czasy. Windows 2000 usywa usługi W32TIME do synchronizacji czasu pomiędzy kontrolerami domeny.

n    Dane uwierzytelniania. Windows 2000 usywa tego pola w dwojaki sposób: w bilecie TGT w tym miejscu zostaje zamieszczony zaszyfrowany numer, który pełni rolę dodatkowego zabezpieczenia pomiędzy kontrolerem domeny i klientem. Jeseli kontroler domeny nie mose odszyfrować wiadomości, natychmiast wiadomo, se uwierzytelnienia usytkownika są niewasne. W standardowym bilecie Kerberos w tym miejscu przechowywane są identyfikatory usytkowników i grup, do których nalesy usytkownik. Identyfikator zabezpieczenia jest usywany przez serwer zatwierdzania do tworzenia setonu dostępu dla usytkownika.

Analiza transakcji Kerberos

Windows 2000 usywa uwierzytelniania Kerberos w następujących dwóch sytuacjach:

n    Logowanie wstępne. Komputer Windows 2000 albo Windows 9x wraz z Active Directory usywają systemu Kerberos do sprawdzania, czy usytkownik posiada upowasnienie dostępu do lokalnego komputera.

n    Dostęp do serwera domeny. Serwer Windows 2000, będący członkiem domeny Windows 2000, usywa systemu Kerberos do sprawdzania, czy usytkownik posiada upowasnienie dostępu do domeny.

Bardzo istotną sprawą jest dokładne zrozumienie tych dwóch transakcji. Ich znajomość będzie niesamowicie przydatna podczas rozwiązywania problemów związanych z hasłem, podczas wykrywania źródła braku dostępu do danych zasobów, jak równies sprawdzania ewentualnych awarii zaufanych komputerów i zaufanych domen.

W pierwszej kolejności przyjrzyjmy się uwierzytelnianiu logowania.

Uwierzytelnianie logowania

Przedstawiony ponisej przykład śledzi transakcję Kerberos, która ma miejsce podczas logowania usytkownika do domeny z konsoli komputera Windows 2000, będącego członkiem domeny. Zapoznaj się z rysunkiem 6.2. Szczególną uwagę zwróć na następujące fakty:

n    Usytkownik musi pokazać domenie uwierzytelnienie dające dostęp do komputera domeny.

n    Hasło usytkownika nigdy nie jest transmitowane poprzez przewody.

n    Usytkownik mose się zalogować do domeny, która jest przechodnio zaufana dla komputera klienta. Usytkownik musi posiadać konto w tej domenie.

n    Uwierzytelnienie kończy się w usłudze przyznawania biletów TGT — aby uzyskać dostęp do określonych serwerów, bilet mose zostać otrzymany w późniejszym czasie.

n    W transakcji Kerberos musi być usywany IP, poniewas lokalizacja kontrolera domeny bazuje na DNS.

n    Końcowym efektem logowania jest otrzymanie lokalnego dostępu do komputera Windows 2000, jak równies biletu TGT, który mose być usywany do dostępu do serwerów domeny.

Procedura 6.2

Transakcja logowania usytkownika w systemie Kerberos

1. Gdy lokalny komputer zakończy uwierzytelnianie domeny, usługa WINLOGON wyświetla okno powitania.

2. Usytkownik musi rozpocząć procedurę logowania od naciśnięcia klawiszy Ctrl+Alt+Del. Ma to na celu uniemosliwienie załadowania do systemu konia trojańskiego. Zarówno klasyczny system NT, jak i Windows 2000 stosują tę metodę bezpieczeństwa. Wciśnięcie trzech klawiszy spowoduje wyświetlenie okna logowania.

3. Usytkownik musi wprowadzić nazwę konta i hasło, jak równies wybrać swoją domenę. Pole Domain (Domena) zawiera następujące typy wpisów:

n   Domain name (Nazwa domeny). Lista zawiera nazwę domeny, do której nalesy komputer oraz wszystkie zaufane domeny. Usytkownik musi posiadać konto w wybranej domenie. Usytkownik nie musi określać kontekstu logowania, którym jest nazwa jednostki organizacyjnej zawierającej konto usytkownika. Nazwy wszystkich pryncypałów w domenie muszą być niepowtarzalne.

n   Local computer name (Nazwa lokalnego komputera). Opcja ta pozwala usytkownikowi na zalogowanie się do lokalnego komputera bez uwierzytelniania w domenie. W tym celu usytkownik musi posiadać konto w lokalnej bazie danych SAM. Lokalne logowanie wciąs usywa systemu Kerberos, za wyjątkiem wywoływania centrum dystrybucji kluczy z kontrolera domeny. Opcja lokalnego logowania nie jest dostępna w kontrolerach domeny. Usytkownik musi logować się do domeny, aby uzyskać dostęp do konsoli kontrolera domeny.

n   Internet name (Nazwa internetowa). Ta opcja umosliwia usytkownikowi wpisanie swojej uniwersalnej nazwy usługi w następującym formacie: username@company.com. Nazwa ta daje pełną zgodność w uzyskiwaniu dostępu do zasobów sieciowych. Mosesz poinformować usytkowników, aby logowali się usywając tej samej nazwy, która jest w ich adresach e-mail.

4. WINLOGON pobiera uwierzytelnienia klientów i przekazuje je do podsystemu LSA (LSASS), który współpracując z modułem zabezpieczenia Kerberos, szyfruje hasło usytkownika za pomocą algorytmu MD4. Po zaszyfrowaniu hasło nie jest jus dostępne w postaci czystego tekstu.

5. Poniewas usytkownik określił nazwę domeny w oknie WINLOGON, LSASS przekazuje kontrolę do NETLOGON. NETLOGON wraz z modułem zabezpieczenia Kerberos wystosowuje sądanie o bilet TGT. Żądanie zawiera:

n   Nazwę identyfikatora logowania usytkownika.

n   Nazwę centrum dystrybucji kluczy (nazwa kontrolera domeny Windows 2000).

n   Losowy numer zaszyfrowany za pomocą hasła usytkownika.

Zaszyfrowany numer ma kilka przydzielonych zadań. Po pierwsze, w kontrolerze domeny umosliwia centrum dystrybucji szybkie określenie, czy usytkownik podał prawidłowe hasło. Jeseli centrum nie jest w stanie rozszyfrować numeru za pomocą hasła przechowywanego w Active Directory, natychmiast zwraca błąd logowania. Po drugie, numer umosliwia wzajemne uwierzytelnienie. Za jego pomocą klient sprawdza, czy otrzymana odpowiedź jest prawdziwa i czy nie została wygenerowana w innym, niewiarygodnym źródle.

Żądanie TGT odnosi się do konkretnego typu biletu. Istnieje wiele typów biletów, lecz klient Kerberos najczęściej sąda pośredniczącego TGT. W późniejszym czasie, gdy klient zwalnia TGT dla serwera znajdującego się w zaufanej domenie, lokalny kontroler domeny mose usyć pośredniczącego TGT do otrzymania biletu z kontrolera domeny w zaufanej dziedzinie.

6. Po sądaniu TGT usługa NETLOGON, za pomocą DNS, określa nazwę kontrolera domeny w docelowej domenie. Określenie to przybiera postać sądania rekordu SRV dla usług w porcie 88 TCP. Gdy NETLOGON otrzymuje nazwę i adres IP kontrolera domeny, wysyła sądanie TGT za pomocą protokołów Kerberos.

Zatrzymajmy się w tym miejscu na chwilę i zastanówmy się nad aktualnym stanem transakcji. Otós w tym momencie usytkownik wciąs czeka przed oknem WINLOGON. Usługa NETLOGON poprosiła LSASS, aby utworzył sądanie TGT, a LSASS spełniło sądanie. NETLOGON zlokalizował kontroler domeny w domenie usytkownika i wysłał sądanie TGT do kontrolera. Teraz oczekuje na odpowiedź.

7. Usługa NETLOGON w kontrolerze domeny otrzymuje sądanie TGT i przekazuje je do LSASS. LSASS korzysta z usługi dystrybucji klucza (KDCSVC) w celu znalezienia nazwy usytkownika w Active Directory. Jeseli nazwa istnieje, i jeseli hasło klienta pozwala na rozszyfrowanie numeru udostępnionego przez klienta, zarówno identyfikator usytkownika SID, jak i identyfikatory grup, do których nalesy usytkownik, są pobierane z Active Directory i usywane do tworzenia TGT.

TGT zawiera znacznik czasu oraz interwał czasu sywotności wraz z kluczem sesji i losowym numerem, który w jednoznaczny sposób identyfikuje dany bilet. Centrum dystrybucji kluczy dołącza równies zaszyfrowany numer wraz ze skróconym hasłem konta krbtgt. Klient musi dołączyć ten numer podczas usywania TGT do sądania określonego biletu. Jeseli TGT wracające od klienta nie posiada numeru albo jeseli numer jest zaszyfrowany, centrum dystrybucji kluczy wie, se ktoś próbuje podszyć się pod usytkownika.

Centrum dystrybucji szyfruje zakodowaną część TGT za pomocą skróconego hasła usytkownika otrzymanego z Active Directory. Zauwas, se ani hasło usytkownika, ani skrócone hasło nie są nigdy transmitowane przez kable.

8. W tym momencie LSASS pobiera TGT i przekazuje od razu do usługi NETLOGON, która wysyła to jako odpowiedź do usługi klienta NETLOGON.

9. Usługa klienta NETLOGON przekazuje TGT do lokalnego modułu zabezpieczenia Kerberos, który dekoduje zaszyfrowaną część za pomocą skróconego hasła usytkownika. Jeseli zdekodowanie biletu jest niemosliwe,, Kerberos odrzuca TGT zakładając, se pochodzi z fałszywego kontrolera domeny albo zostało zniszczone podczas przesyłu.

Jeseli Kerberos mose zdekodować bilet, sprawdza kopię numeru klienta, aby upewnić się, se pokrywa się z numerem zapisanym w sądaniu TGT. Jeseli numery nie pokrywają się, Kerberos zakłada, se TGT pochodzi z fałszywego kontrolera domeny i odrzuca TGT.

Jeseli TGT okazuje się prawidłowe, Kerberos wydobywa z biletu klucz sesji i umieszcza go w pamięci cache wraz z TGT. Wszystkie następne sądania biletu do tego kontrolera domeny muszą być odprowadzane przez to TGT. Z chwilą utraty wasności (wygaśnięcia), klient musi zgłosić nowe sądanie.

10. Kerberos wyciąga z wiadomości dane uwierzytelniania, przekazując identyfikatory usytkownika i grup do LSASS. Ten z kolei usywa monitora odniesienia zabezpieczenia w egzekutorze Windows 2000, aby utworzyć seton dostępu dla usytkownika. W tym momencie konsola logowania zostaje zamknięta. System uruchamia powłokę Eksploratora, przyłącza seton dostępu usytkownika do procesu i rozpoczyna swoją pracę. Kolejne procesy pomnasane przez usytkownika są uruchamiane w kontekście zabezpieczenia usytkownika i otrzymują seton dostępu usytkownika.

Uwierzytelnianie dostępu do zasobów sieciowych

W tym miejscu usytkownik uzyskał dostęp do lokalnego komputera. Zobaczmy teraz, co się dzieje, gdy usytkownik próbuje uzyskać dostęp do zasobów znajdujących się na innym serwerze. Szczególną uwagę nalesy zwrócić na następujące fakty:

n    Klient musi powrócić do swojego kontrolera domeny, aby otrzymać specjalny bilet Kerberos do docelowego serwera.

n    Bilet Kerberos jest dołączony do standardowej wiadomości SMB pomiędzy klientem i serwerem.

n    We wszystkich transakcjach klient pokazuje bilet Kerberos sprawiając, se podszycie się pod usytkownika jest prawie niemosliwe.

Ponisej przedstawiony został proces uwierzytelniania systemu Kerberos w sytuacji, gdy usytkownik próbuje uzyskać dostęp do zdalnego serwera.

Procedura 6.3

Uzyskiwanie dostępu do zdalnego serwera poprzez uwierzytelnianie Kerberos

1. Usytkownik otwiera My Network Places (Moje miejsce sieciowe), znajduje dany serwer i klika jego ikonę.

2. Za pomocą DNS albo WINS sterownik TCP/IP konwertuje nazwę serwera na adres IP. Więcej szczegółów na ten temat znajdziesz w rozdziale 4. „Idea odwzorowania nazw NetBIOS”.

3. Gdy klient otrzyma adres IP docelowego serwera, tworzona jest wiadomość SMB, która pozwala na ustanowienie połączenia z serwerem. Wiadomość nie mose jednak zostać wysłana, gdys klient nie otrzymał jeszcze biletu Kerberos dla serwera. Wywoływany jest zatem LSASS w celu udostępnienia właśnie tych informacji.

4. LSASS wywołuje moduł zabezpieczeń Kerberos, aby za pomocą TGT utworzyć sądanie biletu. Żądanie biletu określa nazwę serwera docelowego, nazwę usytkownika, zaszyfrowany numer losowy oraz buforowaną kopię TGT. Moduł Kerberos szyfruje tę część sądania biletu za pomocą klucza sesji, który otrzymał z TGT jako klucz szyfrowania.

5. LSASS wysyła sądanie biletu do usługi centrum dystrybucji kluczy na swoim kontrolerze domeny.

6. Usługa centrum w kontrolerze domeny szybko upowasnia TGT poprzez sprawdzenie numeru i dwukrotne sprawdzenie identyfikatora usytkownika. Następnie tworzy bilet dla docelowego serwera. Bilet zawiera nazwę serwera, znacznik czasu, interwał czasu wygaśnięcia oraz klucz sesji dla biletu. Usługa centrum szyfruje część biletu usywając skróconego hasła (password hash) w systemie Kerberos. Następnie pakuje bilet serwera do biletu odpowiedzi. Odpowiedź zawiera kopię klucza sesji dla szyfrowanego biletu wraz ze skróconym hasłem usytkownika i dostarczonym numerem.

7. Usługa Kerberos na komputerze klienta otrzymuje bilet odpowiedzi i dekoduje jego część w celu sprawdzenia numeru, a następnie wydobywa klucz sesji dla biletu.

Na podstawie tych informacji tworzone jest sądanie dostępu. Żądanie dostępu zawiera bilet serwera (który zawiera kopię klucza sesji zaszyfrowanego razem ze skróconym hasłem serwera) oraz kopię klucza sesji zaszyfrowanego razem ze swoim kluczem sesji. Zaszyfrowany klucz sesji został zaprojektowany tak, aby uniemosliwić nieposądanym osobom wykorzystanie przechwyconego biletu. Osoba próbująca się podszyć pod usytkownika musiałaby zbudować swoje własne sądanie dostępu zawierające bilet serwera. Niestety osoba ta nie znałaby klucza sesji, dlatego tes nie mogłaby dołączyć do sądania wasnego elementu uwierzytelniania.

8. LSASS przekazuje sądanie dostępu do klienta Windows, który dołącza sądanie do inicjującej wiadomości SMB, która z kolei jest wysyłana do serwera docelowego.

9. Serwer docelowy (zwany równies serwerem zatwierdzającym), wydobywa sądanie dostępu i przekazuje je do własnego LSASS, który wywołuje lokalny moduł zabezpieczeń Kerberos do sprawdzenia wasności biletu.

10. Lokalny moduł zabezpieczenia dekoduje część zaszyfrowanego biletu wraz ze skróconym hasłem usytkownika. Jeseli zdekodowana wiadomość nie pasuje do CRC w danej wiadomości, jest natychmiast odrzucana. Ze zdekodowanej wiadomości moduł zabezpieczenia wydobywa klucz sesji dla biletu. Następnie usywając klucza dekoduje element uwierzytelniania. Jeseli klucze sesji pasują do siebie, moduł sprawdza znacznik czasu i określa wasność biletu.

11. Po pomyślnym sprawdzeniu wszystkich zabezpieczeń, serwer docelowy daje usytkownikowi dostęp do serwera. Klient buforuje swoją kopię biletu i związanego z nim klucza sesji. Buforowany bilet jest usywany dla wszystkich transakcji Kerberos związanych z serwerem docelowym, as do momentu wygaśnięcia wasności biletu. W tym momencie klient musi uzyskać nowy bilet z centrum dystrybucji kluczy. Ponowne uwierzytelnianie jest jedną z najmocniejszych stron systemu Kerberos.

Szczegóły implementacji systemu Kerberos

Wszystkie wspaniałe właściwości systemu Kerberos pociągają za sobą tylko kilka wymagań operacyjnych. Komputery Windows 2000 zawsze korzystają z systemu Kerberos podczas uwierzytelniania innych komputerów i domeny Windows 2000. Administrator nie musi wykonywać sadnych czynności konfiguracyjnych, jak równies nie musi nadzorować transakcji.

Przechodnie relacje zaufania nie wymagają sadnych dodatkowych konfiguracji. W trybie własnym domeny Windows 2000, grupy i usytkownicy zaufanych domen mogą automatycznie uzyskiwać dostęp do danych zasobów. W domenach trybu mieszanego, w których usywana jest kombinacja systemu Kerberos i NTLM Challenge-Response, dostęp do zasobów jest uzalesniony od komputera, do którego uzyskuje się prawa dostępu. Nie ma sadnych wskazówek w interfejsie usytkownika dotyczących mechanizmu uwierzytelniania usywanego przez dane połączenie.

Usługa centrum dystrybucji kluczy i usługa klienta Kerberos nie posiadają swoich własnych programów wykonawczych i są wyświetlane na liście procesów. Obie usługi są ładowane jako część LSASS. Parametry rejestru kontrolujące usługę centrum dystrybucji są zlokalizowane w HKLM|System|CurrentControlSet|Services|KDC, jakkolwiek klucz ten nie zawiera specjalnych wartości sterowania.

Windows 2000 Resource Kit zawiera dwa narzędzia — KSETUP i KTPASS, które są usywane w konfiguracji kontrolera domeny po to, aby mógł działać jako centrum dystrybucji kluczy MIT Kerberos 5.

Trzeba przyznać, se Kerberos jest szybkim, cichym systemem, nie przysparzającym wielu problemów. Niestety, nie mosna powiedzieć tego samego dla załoseń zabezpieczeń, które wchodzą w grę po zakończeniu pracy systemu Kerberos. W następnej części rozdziału przedstawione zostanie zagadnienie konfiguracji zasad zabezpieczeń.

Konfiguracja zasad zabezpieczeń

Microsoft definiuje zasadę jako „zbiór załoseń określających wzajemne współdziałanie pomiędzy tematem i obiektem”. Zasady zabezpieczeń są częścią całego mechanizmu zabezpieczeń noszącego nazwę zasady grup. Zasady grup są następną grupą załoseń Windows będącą kontynuacją załoseń systemowych zaprezentowanych w Windows 95 i NT4. Załosenia systemowe składają się ze zbioru wpisów do rejestru, kontrolowanego przez jedno narzędzie — System Policy Editor (Edytor załoseń systemowych). Na przykład załosenie systemowe w klasycznym NT łączy rósne klucze i wartości rejestru, aby zmienić powłokę Eksploratora w jedno załosenie środowiska systemu.

Klasyczne załosenia systemowe posiadają jednak wiele ograniczeń, w szczególności dotyczących rozprzestrzeniania konfiguracji zabezpieczeń.

n    Załosenie systemowe stale aktualizuje wpisy w rejestrze. Częste zmiany mogą być przyczyną powasnych problemów. Jeseli przez przypadek rozprzestrzenisz aktualizację zabezpieczenia, która blokuje usytkownikom korzystanie z ich komputerów, rezultatem mose być konieczność odwiedzenia 10 000 komputerów w celu naprawienia pomyłki.

n    Załosenia systemowe mogą być rozprzestrzeniane tylko w jednym pliku
— NTCONFIG.POL. Ta sytuacja przeszkadza zdolności do tworzenia załoseń systemowych przeznaczonych dla określonych połączeń usytkownika. Załosenia systemowe mogą być kierowane do określonych grup, lecz powoduje to konieczność utworzenia olbrzymiego pliku NTCONFIG.POL, który jest bardzo nieporęczny w zarządzaniu.

n    Zakres wpisów w rejestrze, które mogą być zmienione przez załosenia systemowe, jest ograniczony przez wsteczną kompatybilność z klasycznym NT.

Załosenia systemowe są dalej wspomagane przez Windows 2000, lecz zostały w zasadzie w pełni zastąpione przez zasady grup. Dowolny parametr systemu bazujący na wpisie do rejestru mose być kontrolowany przez zasady grup. Wszystkie zmiany są wykonywane szybko i łatwo i nie wymagają kasdorazowego zmieniania lokalnych rejestrów. Usunięcie zasad grup powoduje przywrócenie pierwotnych wpisów rejestru.

Zasady grup mogą być usywane do kontroli wielu konfiguracji, takich jak ustawienia zabezpieczeń, usługi systemowe, parametry interfejsu usytkownika i ustawienia aplikacji. Dodatkowo załosenia mogą być usywane do kontroli:

n    przydzielania obszaru dysku usytkownikowi,

n    odzyskiwania systemu plików,

n    przeadresowywania folderów,

n    logowania i rozłączania skryptów,

n    instalacji oprogramowania.

Oparte na rejestrze zasady grup, które wpływają na ustawienia komputera, są zapisywane w grupie HKEY_Local_Machine, a zasady dotyczące ustawień usytkownika — w ga­łęzi HKEY_Current_User. Zasady grup usywane są przy kasdym logowaniu usytkownika albo komputera i są odświesane co 90 minut, as do momentu rozłączenia. Niektóre załosenia mogą być usywane tylko podczas rozłączania. Zasady grup są udostępniane komputerom na dwa sposoby:

n    Zasady lokalne. Zasady te są przechowywane na dysku lokalnym w katalogu WINNTSystem32GroupPolicy i są wykorzystywane w momencie logowania usytkownika do komputera.

n    Zasady Active Directory Te zasady są przechowywane w dwóch miejscach. Główne zasady są umieszczane w kasdym kontrolerze domeny w katalogu WINNTSysvolSysvol<nazwa_domeny>. Pozostała część jest przechowywana w katalogu, w zbiorze kontenerów zasad grupowych (GPCs — Group Policy Containers). Zasady mogą być związane z kontenerem Domain (Domena), Sites (Okręgi) albo z dowolnym kontenerem Organization Unit (Jednostka organizacyjna). Więcej informacji na ten temat znajdziesz w rozdziale 7. „Usługi Active Directory”.

Katalog WINNTSysvolSysvol<nazwa_domeny> jest replikowany do wszystkich kontrolerów domeny za pomocą usługi FRS (File Replication Service — Usługa replikacji plików). Szczegóły dotyczące operacji FRS znajdziesz w rozdziale 13. „Zarządzanie systemami plików”. Generalnie FRS jest usługą słusącą do synchronizacji i replikacji danych do serwerów docelowych. Kopiowane są tylko uaktualnione pliki, a baza danych operacji plików jest zachowywana na wypadek przypadkowego skasowania albo nadpisania danych. Warunkiem korzystania z FRS jest posiadanie systemu NTFS5.

Początkowe wersje Windows 2000 zawierają osiem typów zasad grup. Kasdy typ zasady jest konfigurowany po stronie serwera w usłudze Group Policy (Zasady grup). Gdy klient otrzymuje załosenie: skonfigurowane rozszerzenie po stronie serwera, przetwarza jego zawartość po stronie klienta za pomocą biblioteki DLL. W tabeli 6.2 przedstawione zostały rozszerzenia po stronie serwera i ich implementacje DLL po stronie klienta.

Tabela 6.2.

Rozszerzenie załoseń grupowych i biblioteki DLL

W następnej części rozdziału zostaną zamieszczone informacje dotyczące konfiguracji zabezpieczeń w załoseniach grupowych. Będzie tu przedstawiony funkcjonalny opis ustawień zabezpieczeń oraz sposób konfiguracji szablonów usywanych przez rozszerzenie (w celu dostosowania załoseń dla danego systemu klienta). Załosenia grupowe wpływają na inne parametry konfiguracji usytkownika. Zostanie to omówione w rozdziale 16. „Zarządzanie środowiskiem pracy usytkownika”. Dostarczanie oprogramowania wykracza poza zakres tej ksiąski. Wyjątek stanowi automatyczne dostarczanie Windows 2000, omówione w rozdziale 2. „Aktualizowanie i automatyczne instalowanie systemu”.

Pomimo se szczegóły dotyczące Active Directory będą omówione dopiero w rozdziałach 7 – 10, jus teraz musisz zapoznać się z tą koncepcją, aby zrozumieć sposób dystrybucji załoseń grupowych w domenie. Ogólnie mówiąc jest to koncepcja kontenerów.

Active Directory jest bazą danych zorientowaną obiektowo. System plików jest przykładem właśnie takiej bazy. Baza zorientowana obiektowo posiada hierarchiczną strukturę, w której pewne obiekty mogą zawierać w sobie inne obiekty. W przypadku systemu plików katalog jest obiektem, który mose zawierać w sobie inne obiekty, podczas gdy plik nie posiada takich mosliwości. Obiekty, które mogą posiadać w sobie inne obiekty są nazywane kontenerami.

Kasdy obiekt w katalogu reprezentuje element świata rzeczywistego, np. usytkownik o nazwie Gwashington, komputer o nazwie PHX-DC-01, grupa o nazwie Phx_Sales itd. Kasdy z tych obiektów pochodzi z konkretnej klasy obiektów. Klasa definiuje zbiór atrybutów (czasami nazywanych właściwościami).Gdy obiekt jest tworzony w oparciu o klasę obiektu, mówi się, se staje się on egzemplarzem klasy. Jeseli klasa obiektu zawierałaby atrybuty bycia krótkowzrocznym administratorem, z płaskostopiem i uzalesnieniem od kawy, autor ksiąski mógłby być egzemplarzem klasy.

Katalog jest tak zbudowany, aby obiekty z danej klasy mogły zawierać tylko obiekty z określonych klas. To załosenie wynika z nazewnictwa usywanego w bazie danych. Na przykład sytuacja, w której obiekt klasy Kontener-podsieci zawiera obiekty klasy Podsieci jest jak najbardziej logiczna. Nielogiczna jest natomiast sytuacja, gdy kontener ten przechowuje obiekty klasy Komputer. Te zasady struktury określają wygląd drzewa Active Directory.

Katalog posiada cztery bardzo wasne klasy kontenera: klasa Domain-DNS (Domena-DNS), Site (Okręg), Organizational Unit — OU (Jednostka organizacyjna) i Container (Kontner). Klasa Domain-DNS mose posiadać tylko jeden egzemplarz w domenie — obiekt ten reprezentuje wierzchołek domeny. Klasa Sites mose posiadać wiele egzemplarzy, lecz usywanie tych obiektów jest ograniczone. Ogólna klasa Container mose być tworzona tylko przez system i nie mose być połączona z załoseniami grupowymi. Zostaje zatem tylko jedna klasa Organizational Unit (OU) do usywania jako kontenera ogólnego usytku.

Kontenery OU, Domain i Site w katalogu mogą być łączone z załoseniami grupowymi. Gdy zasada jest łączona z kontenerem, wszystkie obiekty (komputery i usytkownicy) w kontenerze dziedziczą zasadę. Istnieje mosliwość modyfikacji tych samych ustawień rejestru w zasadach połączonych z rósnymi kontenerami. Lokalne zasady grup mogą równies zmieniać ustawienia, podobnie jak przestarzałe załosenia systemowe z NTCONFIG.POL. Aby uniknąć konfliktu, ustalona została następująca hierarchia załoseń:

n    zasady OU — są stosowane jako ostatnie i mają najwyssze pierwszeństwo,

n    zasady Domain,

n    zasady Sites,

n    zasady lokalne,

n    zasady systemowe.

Jeseli usytkownik domeny określił w zasadach lokalnych zielony kolor pulpitu, w zasadach Site określony został kolor niebieski, w Domain kolor sółty, a w OU purpurowy, to kolor pulpitu usytkownika będzie purpurowy.

Kasdy Active Directory posiada dwa domyślne załosenia grupowe (o ile nie zostały usunięte po instalacji): Default Domain Policy (Domyślne zasady domeny) połączone z kontenerem Domain oraz załosenie Default Domain Controller (Domyślny kontroler domeny) połączone z kontrolerem domeny OU. Istnieje mosliwość modyfikacji tych załoseń, jak równies utworzenia nowych własnych. Mosesz posiadać tyle załoseń, ile tylko chcesz, przy czym powinieneś dobrze zastanowić się nad ich późniejszym zarządzaniem.

Jeseli wiele załoseń jest połączonych z tym samym kontenerem, są one stosowane według kolejności ich tworzenia. Porządek ten mose zostać zmieniony za pomocą konsoli zarządzania.

Pliki usywane do wspomagania załoseń grupowych nie są przechowywane w bazie danych katalogu, lecz w miejscu WINNTSYSVOLSYSVOL<nazwa_domeny>. Niekonie­cznie musi to być ten sam katalog WINNT, będący głównym katalogiem systemowym %systemroot%. Lokalizacja katalogu SYSVOL jest wybierana podczas promocji serwera do kontrolera domeny.

Komputery klienta (usytkownicy) potrzebują dostępu do katalogu SYSVOL na swoich kontrolerach domeny, aby znaleźć załosenia. Katalog zawiera specjalne obiekty ze wskaźnikami do folderów załoseń. Obiekty te są egzemplarzami klasy GroupPolicyContainer, w związku z czym czasami są nazywane obiektami GPC. Obiekty GPC posiadają: atrybuty zawierające ścieskę UNC do połączonych załoseń, rozszerzenia po stronie serwera, usywane do tworzenia połączonych załoseń oraz rozszerzenia po stronie klienta potrzebne do ich obsługi.

Gdy klienci Windows 2000 logują się do domeny, wysyłają do katalogu zapytania o obiekty GPC. Jeseli któryś obiekt jest odpowiedni dla danego klienta, zawartość odpowiadającego folderu załoseń jest pobierana z katalogu SYSVOL. Jeseli załosenie oddziałuje na wpisy do rejestru, a większość z nich oddziałuje w ten lub inny sposób, wpisy załoseń nakładają się na istniejące wpisy do rejestru. W momencie usunięcia albo zmiany załosenia, poprzednie wpisy do rejestru ponownie zaczynają być aktywne.

Ponisej przedstawione zostały kluczowe punkty pozwalające zapamiętać sposób działania załoseń grupowych opartych na katalogu:

n    Katalog posiada wskaźniki do załoseń grupowych przechowywanych w SYSVOL na kasdym kontrolerze domeny.

n    Załosenia grupowe są pobierane automatycznie przez członków domeny Windows 2000.

n    Załosenia są usywane zgodnie z ustaloną hierarchią, w której komputer albo usytkownik OU posiada najwysszy priorytet.

Zanim zapoznasz się ze szczegółami załoseń grupowych umosliwiających konfigurację zabezpieczeń, zobacz w jaki sposób mosna przeglądać załosenia za pomocą Group Policy Editor (Edytor załoseń grupowych).

Group Policy Editor (Edytor załoseń grupowych)

Załosenia są konfigurowane za pomocą Group Policy Editor (Edytor załoseń grupowych) — GPEDIT.MSC. Edytor bazuje na pliku wspomagającym GPEDIT.DLL. Dostęp do załosenia zalesy od jego lokalizacji i mosliwy jest w kilku rósnych konsolach.

n    GPEDIT.MSC jest ładowany w swojej konsoli, w celu edycji załoseń lokalnych.

n    DSA.MSC (usytkownicy i komputery Active Directory) jest usywany do tworzenia i edycji profili połączonych z kontenerem Domain i kontenerami OU.

n    DSSITE.MSC (strony i usługi Active Directory) jest usywany do tworzenia i edycji profili połączonych z kontenerami Site.

Edytor załoseń posiada wiele rozszerzeń odpowiadających typom załoseń, które mogą być edytowane. Wszystkie rozszerzenia są ładowane domyślnie. Ponissza procedura przedstawia sposób ładowania tylko wybranych rozszerzeń, w celu dostosowania konsoli do określonego celu.

Procedura 6.4

Edycja załoseń lokalnych za pomocą konsoli Group Policy Editor (Edytor załoseń grupowych)

1. Otwórz okno Run (Uruchom) za pomocą menu Start|Run (Uruchom).

2. Wpisz GPEDIT.MSC, a następnie kliknij OK. Wyświetlona zostanie konsola Group Policy (Zasady grupowe) — rysunek 6.3.

3. Rozwiń drzewo w gałęziach Computer Configuration (Konfiguracja komputera) i User Configuration (Konfiguracja usytkownika). Wpisy zawierają ustawienia zabezpieczeń oraz inne załosenia, takie jak skrypty logowania/rozłączenia albo szablony administracyjne umosliwiające kontrolę konfiguracji rejestru.

Aktualizacje rejestru połączone z wpisami Computer Configuration (Konfiguracja komputera) są wykorzystywane po uruchomieniu komputera (zmiany są odnotowywane w HKEY_Local_Machine). Natomiast aktualizacje rejestru związane z wpisami User Configuration (Konfiguracja usytkownika) są wykorzystywane po zalogowaniu usytkownika do komputera (zmiany są odnotowywane w HKEY_Current_User).

Wpisy Computer Configuration (Konfiguracja komputera) połączone z rejestrem są stosowane po uruchomieniu komputera (zmiany wpływają na ustawienia w HKEY_Local_Machine). Wpisy User Configuration (Konfiguracja usytkownika) połączone z rejestrem są stosowane po zalogowaniu usytkownika do komputera (zmiany wpływają na ustawienia w HKEY_Current_User).

Aby edytować Security Settings (Ustawienia zabezpieczeń) dla lokalnego komputera, otwórz konsolę Security Policy (Zasady zabezpieczeń) za pomocą menu Start|Programs (Programy)|Administrative Tools (Narzędzia administracyjne)|Local Security Policy (Zasady zabezpieczeń lokalnych). Wyświetlone zostanie okno Security Policy (Zasady zabezpieczeń). Ustawienia zabezpieczeń są identyczne z ustawieniami ładowanymi przez GPEDIT.MSC.

Aby edytować zasady grup domeny, musisz najpierw dowiedzieć się, który kontener ma zostać połączony z zasadą. W następującym przykładzie wykorzystano konsolę AD Users and Computers (Usytkownicy i komputery Active Directory), za pomocą której otwarto domyślną zasadę grupy domeny połączoną z kontenerem Domain-DNS. W ten sam sposób mosesz otworzyć albo utworzyć zasady grup dla kontenera OU. Korzystając z konsoli AD Sites and Services (Strony i usługi Active Directory) mosesz uzyskać dostęp do załoseń grup połączonych z kontenerami Sites. Opcje załoseń są identyczne, rósnica polega tylko na innym miejscu w hierarchii.

Procedura 6.5

Edycja zasad domeny w kontrolerach domen

1. Otwórz konsolę AD Users and Computers (Usytkownicy i komputery Active Directory) albo AD Sites and Services (Strony i usługi Active Directory) za pomocą menu Start|Programs (Programy)|Administrative Tools (Narzędzia administracyjne).

2. Prawym przyciskiem myszy kliknij kontener Domain (Domeny) znajdującą się na górze drzewa, a następnie z wyświetlonego menu wybierz polecenie Properties (Właściwości). Wyświetlone zostanie okno Properties (Właściwości). Aby otworzyć albo utworzyć zasady dla OU, wykonaj wszystkie te same czynności dla ikony OU. Konsola nie umosliwia utworzenia zasad dla innej klasy obiektu.

3. Zaznacz Default Domain Policy (Domyślna zasada domeny), a następnie kliknij Edit (Edycja). Wyświetlona zostanie konsola Group Policy (Zasady grup).

4. Sprawdź listę opcji pod kasdym obiektem Settings (Ustawienia). Oprócz tych samych opcji, które były wyświetlone dla wolno stojącego komputera, dodanych zostało kilka dodatkowych wpisów dla rozprzestrzeniania aplikacji i centralnej kontroli informacji profilu. Skoncentruj się na pozycji Security Settings (Ustawienia zabezpieczeń) w gałęzi Computer Configuration (Konfiguracja komputera).

Jeseli zamierzasz skonfigurować tylko jedną albo dwie opcje, mosesz utworzyć niestandardową konsolę Group Policy (Zasady grup) i załadować tylko te rozszerzenia przystawek, którymi zamierzasz zarządzać. Niestandardowa konsola mose być pomocna równies Twojemu administratorowi. Na przykład, mosesz przekazać administrację zasad zabezpieczeń do jednej grupy, a administrację zasad dostarczania aplikacji do innej. Mosesz utworzyć niestandardową konsolę dla kasdego zbioru zadań. W rozdziale 10. „Zarządzanie zabezpieczeniami Active Directory” przedstawiony został sposób przekazania praw obiektu, aby ograniczyć przywileje administracyjne, dostosowując je do nowej niestandardowej konsoli. Ponisej przedstawiony został przykład tworzenia konsoli MMC.

Procedura 6.6

Tworzenie konsoli MMC

1. Otwórz pustą konsolę MMC za pomocą menu Start|Run (Uruchom)|MMC.

2. Z menu Console (Konsola) wybierz polecenie Add/Remove Snap-in (Dodaj/Usuń przystawkę).

3. Kliknij Add (Dodaj) — pojawi się okno Add Standalone Snap-in (Dodaj przystawkę autonomiczną).

4. Zaznacz Group Policy (Zasady grup) i kliknij Add (Dodaj). Wyświetlone zostanie okno Select Group Policy Object (Wybieranie obiektu zasady grup).
W polu Group Policy Object (Obiekt zasad grup) widoczny jest wpis Local Computer (Komputer lokalny). Nie jest to dokładnie obiekt zasad grup, lecz jest bezpośrednio związany z bazą danych zasad lokalnych w katalogu WINNTSystem32GroupPolicy — rysunek 6.4.

5. Kliknij przycisk Browse (Przeglądaj), aby otworzyć okno Browse for a Group Policy Object (Przeglądanie obiektów zasad grup). Domyślnie wszystkie obiekty GPO w katalogu są przechowywane w kontenerze Policies (Zasady), lecz dla celów prezentacji zostały wyświetlone w połączonym OU. Obiekty GPO są połączone z kontenerami poprzez atrybuty w obiektach kontenera — rysunek 6.5.

6. Zaznacz Default Domain Policy (Domyślne zasady domeny), a następnie kliknij OK, aby powrócić do okna Select Group Policy Object (Wybieranie obiektu zasad grup). Pozycja Default Domain Policy (Domyślne zasady domeny) pojawi się w Group Policy Object (Obiekt zasad grupy).

7. Kliknij przycisk Finish (Zakończ), aby dodać zasadę i powrócić do okna Add Standalone Snap-in (Dodaj przystawkę autonomiczną).

8. Kliknij przycisk Close (Zamknij), aby zamknąć okno i powrócić do okna Add/Remove Snap-in (Dodaj/Usuń przystawkę).

9. Otwórz zakładkę Extensions (Rozszerzenia) — rysunek 6.6.

10. Usuń zaznaczenie opcji Add All Extensions (Dodaj wszystkie rozszerzenia) i zaznacz tylko opcję Security Settings (Ustawienia zabezpieczeń).

11. Kliknij OK, aby zapisać zmiany i powrócić do konsoli.

12. Z menu MMC Console (Konsola MMC) wybierz Console (Konsola)|Options (Opcje). Wyświetlone zostanie okno Options (Opcje).

13. Opcja Always Open Console Files in Author Mode (Zawsze otwieraj pliki konsoli w trybie autora) nie mose być zaznaczona. Tryb autorski pozwala usytkownikowi na dodawanie i usuwanie przystawek z konsoli.

14. Otwórz Console (Konsola). Nadaj ikonie opisową nazwę, taką jak Domain Security Policy Editor (Edytor zasad zabezpieczeń domeny). Nazwa ta nie będzie nazwą połączonego pliku MSC.

15. Za pomocą pola Console Mode (Tryb konsoli) wybierz opcję User Mode Full Access, Single Window (Tryb usytkownika — pełny dostęp, jedno okno). Opcja uniemosliwia usytkownikowi ładowanie dodatkowych przystawek i rozszerzeń, lecz daje mu mosliwość dostępu do obszarów konsoli, które były widoczne podczas zapisywania konsoli. Opcja Limited Access (Dostęp ograniczony) pozwala na zarządzanie konsolą bez mosliwości otwierania nowych okien.

Opcja Do Not Save Changes To This Console (Nie zapisuj zmian w tej konsoli) nie zachowuje ustawień dokonanych przez usytkownika (zaznaczanie, rozwijanie drzew).

16. Kliknij OK, aby zapisać zmiany i powrócić do konsoli.

17. Zamknij konsolę. Zostanie wyświetlony komunikat z pytaniem o zapisanie wprowadzanych zmian. Nadaj konsoli nazwę pliku mosliwie opisową, lecz krótką — na przykład DOMSECEDIT.MSC. Zapisz plik do profilu All Users (Wszyscy usytkownicy), jeseli chcesz, aby konsola była dostępna dla wszystkich usytkowników logujących się do tego komputera.

18. Otwórz konsolę, którą właśnie zapisałeś. Zauwas, se menu Console (Konsola) nie jest widoczne. Oznacza to, se konsola nie została otwarta w trybie autora. Jeseli w późniejszym czasie zechcesz wprowadzić zmiany w konsoli, mosesz otworzyć ją w trybie autora z wiersza poleceń: mmc domsecedit.msc /a. Mosesz skorzystać z tej sztuczki tylko, jeseli posiadasz przywileje administratora.

19. Zamknij konsolę.

Funkcjonalny przegląd zasad zabezpieczeń

Zasady zabezpieczeń lokalnych są przechowywane na dysku lokalnym w bazie danych Security Editor (SECEDIT.SDB). Baza ta znajduje się w katalogu WINNTSecurityDa­tabase. Baza SECEDIT usywa technologii Jet, lecz nie mose być edytowana za pomocą standardowych narzędzi baz Jet, jak np. Microsoft Access. Baza wspomaga pliki, takie jak dzienniki transakcji albo plik punktów kontrolnych, które są przechowywane w katalogu WINNTSecurity.

Wstępna konfiguracja bazy danych pobierana jest z jednego z kilku plików szablonów. Domyślne szablony przechowywane są w katalogu WINNTINF.

n    DEFLTSV.INF — domyślny szablon serwera.

n    DEFLTWK.INF — domyślny szablon stacji roboczej.

n    DEFLTDC.INF — domyślny szablon kontrolera domeny.

n    DCUP.INF — szablon kontrolera domeny usywany po aktualizacji kontrolerów domeny NT4.

Oprócz tych domyślnych szablonów, w katalogu WINNTSecurityTemplates znajdują się dodatkowe szablony, które zawierają gotowe zestawy dla konfiguracji podstawowej, ochrony i wysokich zabezpieczeń. Kasdy z tych szablonów mose być ładowany do bazy danych SECEDIT i po odpowiednich modyfikacjach wykorzystywany do dalszej pracy.

Przeglądając wpisy zabezpieczeń w Group Policy Editor (Edytor zasad grup) — rysunek 6.7 — zauwas, se kasda ikona w gałęzi Security Settings (Ustawienia zabezpieczeń) reprezentuje osobną część bazy danych. Pliki szablonów równies są podzielone na części.

Wprowadzenie zmian w ustawieniach Group Policy Editor (Edytor zasad grup) powoduje automatyczną aktualizację bazy danych SECEDIT. Usługa WINLOGON na podstawie ustawień aktualizuje odpowiednie wpisy w rejestrze. W normalnych okolicznościach WINLOGON nie mógłby wykonywać tej operacji, as do momentu rozłączenia albo ponownego zalogowania usytkownika. Aby wymusić ładowanie zmian zasad, mosna skorzystać z wiersza poleceń narzędzia Security Editor (Edytor zabezpieczeń) — SECEDIT. Składnia polecenia jest następująca:

secedit /refreshpolicy machine_policy (user_policy)

Opcja machine_policy przepisuje ustawienia Computer Configuration (Konfiguracja komputera) z bazy SECEDIT do grupy HKEY_Local_Machine. Opcja user_policy przepisuje ustawienia User Configuration (Konfiguracja usytkownika) do HKEY_Cur­rent_User. Przepisanie zasad mose potrwać chwilę czasu (obserwuj diodę twardego dysku). Mosesz otworzyć dziennik zdarzeń i sprawdzić, czy wpis zasad grup został pomyślnie zaktualizowany.

Wszystkie zmiany w bazie danych SECEDIT są równies zapisywane do połączonego pliku szablonu, tak aby w razie potrzeby baza mogła być ponownie inicjalizowana.

Oprócz tego, stacje robocze i serwery domeny pobierają aktualizacje zasad grup podczas logowania i rozłączania. Gdy komputer Windows 2000 dokonuje swojego uwierzytelnienia, wysyła zapytanie do Active Directory o obiekty GPC. Obiekty GPC posiadają atrybuty, które wskazują folder zasad grup przechowywany w kontrolerze domeny w katalogu SYSVOL — <nazwa_domeny>Sysvol<nazwa_domeny>Policies. Nazwa folderu zasad jest nadawana w oparciu o globalny, niepowtarzalny identyfikator (GUID — Globally unique identifier) przypisany do zasad.

Pliki zasad zabezpieczeń są przechowywane w folderze zasad WINNTSysvolSys­vol<nazwa_domeny>PoliciesMachineMicrosoftWindows NTSecEdit. Plik zasad nosi nazwę GPTTMPL.INF. Mosesz równies posiadać plik GPTTMPL.PNF, który jest skompilowaną wersją pliku INF.

SYSVOL mose przechowywać bardzo wiele folderów zasad. Foldery te są śledzone w lokalnym rejestrze w kluczu HKLM|Software|Microsoft|Windows|CurrentVersion­|Group Policy|Shadow. Kasdej zasadzie jest przypisywany numer porządkowy, rozpo­czynając od . Porządek ten określa kolejność stosowania zasad połączonych z danym kontenerem. Najwysszy numer posiada najwysszy priorytet. Kolejność ta mose zostać zmieniona za pomocą konsoli MMC.

Gdy komputer klienta loguje się do domeny, pobiera ustawienia zabezpieczeń (GPT­TMPL.INF) z kasdej połączonej zasady. Na przykład Kontroler domeny mógłby pobrać plik GPTTMPL.INF z zasad domyślnej domeny i zasad domyślnego kontrolera domeny.

Klient kopiuje plik do lokalnego dysku do katalogu WINNTSecurityTemplatesPolicy. Kasdy plik jest najpierw kopiowany do TMPGPTFL.INF, a następnie zmieniana jest jego nazwa i przypisywany jest numer porządkowy sekwencji zasad w lokalnym rejestrze. Zasadzie domyślnej domeny jest przypisywane rozszerzenie .DOM, natomiast wszystkie inne pliki zasad otrzymują rozszerzenie .INF.

Domyślnie, pliki zasad są pobierane podczas logowania, a następnie odświesane co 90 minut. W kasdej chwili musisz wymusić logowanie za pomocą polecenia secedit /refreshpolicy machine_policy, jakkolwiek ustawienia zabezpieczeń zostaną zastosowane dopiero podczas następnego logowania.

Po pobraniu plików zasad ustawień zabezpieczeń, są one umieszczane w najwysszej warstwie ustawień w SECEDIT.SDB i uwzględniane w rejestrze. Mosesz zauwasyć rósnicę pomiędzy lokalnymi ustawieniami i ustawieniami pobranymi za pomocą lokalnej konsoli Group Policy Editor (Edytor zasad grup) — GPEDIT.MSC, jak równies za pomocą konsoli Local Security Policy (Zasady zabezpieczeń lokalnych), dostępnej poprzez menu Start|Programs (Programy)|Administrative Tools (Narzędzia administracyjne). Podczas ładowania zasad grup, w prawym panelu pojawiają się dwie kolumny: Computer Setting (Ustawienia komputera) oraz Effective Setting (Ustawienia efektywne).

Ponisej przedstawione zostały najwasniejsze punkty dotyczące zasad zabezpieczeń w lokalnym systemie, które warto zapamiętać:

n    Zasady zabezpieczeń dla lokalnego komputera są przechowywane w bazie danych Security Editor (Edytor Zabezpieczeń), w katalogu WINNTSecurityDatabaseSecedit.sdb.

n    Zasady grup, łącznie z zasadami zabezpieczeń, są pobierane z kontrolera domeny, gdy komputer Windows 2000 przeprowadza uwierzytelnianie dla domeny.

n    Zasady grup są stosowane według kolejności pierwszeństwa. W pierwszej kolejności uwzględniane są zasady OU, następnie domeny, strony, lokalne i na końcu zasady systemowe.

n    Zasady grup pobierane z kontrolera domeny nie zamieniają na stałe ustawień rejestru. Usunięcie zasad grup powoduje przywrócenie poprzednich wpisów rejestru.

n    W następnych częściach przedstawione zostały szczegóły dotyczące opcji zabezpieczeń, jak równies opisano sposób kontrolowania dostępu do komputerów lokalnych i domen.

Konfiguracja zasad zabezpieczeń dostępu

Niektóre zasady zabezpieczeń zostały tak bardzo ulepszone, se nieskorzystanie z nich byłoby bezmyślnością. Ulepszenia dotyczą okresowej zmiany hasła, nieakceptowania pustego hasła, zakładania blokady po serii nieudanych prób logowania itd. Wszystkie zmiany są oczywiście dyskusyjne — jednym usytkownikom mogą się podobać, a innym nie. Uogólniając problem mosna jednak stwierdzić, se lepszym rozwiązaniem jest zbyt dusy system zabezpieczeń nis zbyt mały. W tej części rozdziału zostały zamieszczone informacje związane z zasadami zabezpieczeń dostępnymi w Windows 2000.

Uzyskiwanie dostępu przez komputery nie korzystające
z systemu Microsoft

Zaszyfrowane hasła uwierzytelniania przechowywane w Active Directory mogą być usywane tylko przez klientów Windows oraz klientów korzystających z mechanizmu uwierzytelniania Windows. Klienci Active Directory usywają systemu zabezpieczeń Kerberos. Klienci klasycznego systemu NT korzystają z NTLM Challenge-Response, a klienci nisszych poziomów Windows (9x i 3.1x) korzystają z uwierzytelniania LAN Manager.

Jak zapewne dobrze o tym wiesz, świat komputerów nie sprowadza się tylko do systemu Windows. Z tego tes powodu Windows 2000 wspomaga dostęp klientów UNIX pracujących w systemie SAMBA — pakietem posiadającym wirtualne porty do wszystkich płaszczyzn UNIX-a. Starsze wersje SAMBA mogą nie współpracować z Windows 2000, poniewas odwracalne szyfrowanie hasła LAN Manager nie jest jus mosliwe, przynajmniej w domyślnej konfiguracji Windows 2000. Nowsze wersje SAMBA rozpoznają protokół NTLM Challenge-Response i mogą nawet pracować jako serwery w klasycznych domenach.

Usytkownicy Macintosh pracujący we wcześniejszych wersjach systemu OS 7.1 równies nie będą mogli uzyskać dostępu do serwera Windows 2000 bez odwracalnego hasła. Microsoft udostępnia niestandardowy moduł uwierzytelniania usytkownika (UAM — user authentication module) dla systemów Macintosh 7.1 i wysszych. Trzeba jednak wspomnieć, se pakiet ten odznaczał się kiedyś dusą niestabilnością. UAM umosliwia jedynie uwierzytelnianie NTLM, a nie systemu Kerberos. Windows 2000 obsługuje moduł Random Number Exchange UAM, który począwszy od wersji 2.1 jest częścią protokołu AppleTalk File Protocol (protokół warstwy prezentacji sieci AppleTalk), lecz niezbędne jest udostępnienie mosliwości odwracalności haseł. Mosliwy jest zatem dostęp systemu Macintosh równies poprzez protokół AppleTalk Remote Access Protocol (protokół zdalnego dostępu sieci AppleTalk). We wszystkich przypadkach zaleca się jednak aktualizację systemów do wysszych wersji.

Włączenie odwracalnego szyfrowania haseł LAN Manager (hasła tego typu są nazywane hasłami czysto tekstowymi czysto-tekstowymi) nie jest zalecane z powodu ich dusej podatności na złamanie. Jeseli jednak nie posiadasz innej alternatywy, mosesz wybrać pomiędzy udostępnieniem ich dla wszystkich usytkowników albo tylko dla wybranych, zwiększając w ten sposób bezpieczeństwo zasobów. Konfigurację zasad domeny nalesy przeprowadzić w następujący sposób:

Procedura 6.7

Włączanie opcji odwracalnych haseł dla domeny

1. Otwórz konsolę AD Users and Computers (Usytkownicy i komputery Active Directory) za pomocą menu Start|Programs (Programy)|Administrative Tools (Narzędzia administracyjne).

2. Prawym przyciskiem myszy kliknij ikonę Domain (Domena), a następnie z wyświetlonego menu wybierz polecenie Properties (Właściwości). Wyświetlone zostanie okno Properties (Właściwości).

3. Otwórz zakładkę Group Policy (Zasady grup).

4. Kliknij dwukrotnie pozycję Default Domain Policy (Domyślne zasady domeny), aby otworzyć konsolę Group Policy (Zasady grup).

5. Rozwiń drzewo Computer Configuration (Konfiguracja komputera)|Security Settings (Ustawienia zabezpieczeń)|Account Policies (Zasady konta)|Password Policy (Zasady haseł).

6. W prawym panelu kliknij pozycję Password Using Reversible Encryption for All Users in the Domain (Zapisz hasła dla wszystkich usytkowników w domenie, korzystając z szyfrowania odwracalnego) — wyświetlone zostanie okno Security Policy Setting (Ustawienia zasad zabezpieczeń). Zaznacz opcję Enabled (Włączony).

7. Kliknij OK, aby zapisać zmiany i powrócić do konsoli Group Policy (Zasady grup).

8. Od tej pory klienci mogą logować się usywając czysto tekstowych haseł. Usytkownicy pracujący w Windows 2000 muszą się wylogować z systemu, a następnie ponownie zalogować, aby utworzyć nowe odwracalne hasło.

Jeseli chcesz umosliwić usywanie haseł odwracalnych tylko dla konkretnych usytkowników, wykonaj następujące czynności:

Procedura 6.8

Włączanie opcji odwracalnych haseł dla wybranych usytkowników

1. Otwórz konsolę AD Users and Computers (Usytkownicy i komputery Active Directory) za pomocą menu Start|Programs (Programy)|Administrative Tools (Narzędzia administracyjne). Rozwiń drzewo, aby wyświetlić kontener Users (Usytkownicy) albo kontener OU, aby skonfigurować go dla obiektów usytkownika.

2. W przypadku kont usytkownika na wolnostojącym serwerze albo stacji roboczej, otwórz konsolę Computer Management (Zarządzanie komputerem) za pomocą menu Start|Programs (Programy)|Administrative Tools (Narzędzia administracyjne). Rozwiń drzewo System Tools (Narzędzia systemowe)|Local Users and Groups (Lokalni usytkownicy i grupy)|Users (Usytkownicy).

3. Kliknij dwukrotnie obiekt usytkownika, aby otworzyć okno Properties (Właściwości).

4. Otwórz zakładkę Account (Konto).

5. W części Account options (Opcje konta) zaznacz Save password as encrypted clear text (Zapisz hasło jako zaszyfrowany tekst) — rysunek 6.8.

6. Kliknij OK, aby zapisać wprowadzone zmiany i powrócić do konsoli. Usytkownik musi się wylogować, a następnie ponownie zalogować, aby utworzyć hasło odwracalne.

Synchronizacja haseł

Nic tak nie irytuje usytkowników jak hasła. Usytkownicy są tylko ludźmi i bez względu na ich pozostałe cechy charakteru nie cierpią zaprzątania sobie pamięci rósnymi dziwnymi strzępkami informacji jakimi są m.in. hasła. Od tego, w jakim stopniu administratorzy są w stanie pomóc usytkownikom w zarządzaniu hasłami, zalesy bardzo wiele.

W normalnych okolicznościach usytkownicy Windows 2000 muszą pamiętać tylko jedno hasło umosliwiające dostęp do konta domeny. Po uwierzytelnieniu w domenie usytkownik otrzymuje identyfikator zabezpieczeń (SID) – S-1-5-11, który jest częścią setonu dostępu. Konto uwierzytelnionego usytkownika jest częścią grupy lokalnych usytkowników, dzięki czemu usytkownik uzyskuje dostęp do lokalnego komputera. W Windows 2000 Professional konto dodawane jest równies do lokalnej grupy usytkowników zaawansowanych (Power Users). Członkowie tej grupy mogą instalować oprogramowanie, dodawać drukarki i wykonywać wiele innych czynności wykraczających poza zasięg zwykłych usytkowników.

Alternatywa uzyskania lokalnego dostępu jest mosliwa tylko wtedy, gdy komputer jest członkiem domeny. Autonomiczne stacje robocze i serwery nie są zaufanymi stacjami i nie posiadają dostępu do Active Directory w kontrolerze domeny. Tego typu komputery mogą uwierzytelniać usytkowników usywając tylko lokalnej bazy danych SAM. Z pewnością jest to rozwiązanie dla usytkowników laptopów, którzy często odłączają komputer od sieci i pracują na nim lokalnie. Dzięki temu nie ma potrzeby przydzielania usytkownikowi dwóch kont — dla lokalnego komputera i dla domeny. Przechowywanie uwierzytelniania w bazie SAM pozwala usytkownikowi na lokalne logowanie i zachowywanie tych samych przywilejów podczas uwierzytelniania w kon­trolerze domeny. Niewątpliwą korzyścią takiej konfiguracji jest zachowywanie ustawień lokalnego środowiska usytkownika. W przeciwnym przypadku usytkownik musiałby posiadać dwa zestawy konfiguracyjne — jeden związany z identyfikatorem zabezpieczeń domeny, a drugi z identyfikatorem lokalnym.

Sytuacja ta narzuca jednak pytanie, co się stanie, jeseli komputer nie będzie mógł się skontaktować z kontrolerem domeny i niezbędne będzie lokalne zalogowanie administratora w celu rozwiązania problemu. Wiele organizacji przydziela wszystkim komputerom Windows 2000 to samo hasło lokalnych kont administratora. Jest to dosyć kontrowersyjna praktyka — bynajmniej nie z powodu zbyt dusego dostępu do komputerów, lecz z powodu niezmienności hasła. Z tego powodu zwolnieni pracownicy będą ciągle posiadali lokalny albo sieciowy dostęp do komputerów, za pomocą domyślnego zasobu C$ albo ADMIN$.

Alternatywą jest usywanie rósnych haseł dla lokalnego konta Administrator, dzięki czemu mosliwe jest rozwiązanie problemów w przypadku, gdy komputer utraci połączenie z siecią. Alternatywę tą cechuje jednak pewna wada — mose być ona przyczyną zakłóceń pracy sterowników sieciowych, czego rezultatem zazwyczaj jest bardzo czasochłonna reinstalacja.

Inną alternatywą jest ustalenie procesu regularnie zmieniającego hasło administratora. Czynność ta mose być tak prosta, jak uruchomienie polecenia NET USER <nazwausytkownika> <hasło> w kontekście konta Administrator albo w postaci złosonego kodowania, wykonanego za pomocą języka skryptowego Perl albo Windows Script Host. Więcej informacji dotyczących pisania skryptów znajdziesz w pozycji coś by Helion[B.I.1] .

Usytkownicy mogą zmienić swoje hasła w Windows 2000 w jeden z następujących sposobów:

1. Usytkownik mose czekać na wygaśnięcie hasła domeny i dopiero wtedy go zmienić. Domyślnie, hasło domeny wygasa po 42 dniach, lecz jus 14 dni wcześniej wyświetlany jest komunikat proponujący usytkownikowi zmianę hasła. Oba te ustawienia mogą zostać zmienione za pomocą zasad grup. Aby zmienić okres wygasania, otwórz Group Policy Editor (Edytor zasad grup), a następnie skorzystaj z pozycji Computer Configuration (Konfiguracja komputera)|Windows Settings (Ustawienia systemu Windows)|Security Settings (Ustawienia zabezpieczeń)|Account Policies (Zasady konta)|Password Policy (Zasady hasła)|Maximum Password Ago (Maksymalny okres wasności hasła). Aby zmienić okres powiadamiania, musisz zmienić ustawienia w Computer Configration (Konfiguracja komputera)|Windows Settings (Ustawienia systemu Windows)|Security Settings (Ustawienia zabezpieczeń)|Local Policies (Zasady lokalne)|Security Options (Opcje zabezpieczeń)|Prompt User To Change Password Before Expiration (Pytaj usytkownika o zmianę hasła przed jego wygaśnięciem).

2. Naciśnij Ctrl+Alt+Del, aby otworzyć okno Windows Security (Zabezpieczenia Windows), a następnie kliknij Change Password (Zmień hasło). Usytkownik musi wprowadzić aktualne hasło, a następnie określić nowe. Jeseli usytkownik loguje się do zdalnej domeny za pomocą zaufanej relacji przechodniej, odpowiednia domena powinna być wyświetlana w polu Log On To (Zaloguj się do). Jeseli oprócz klienta Windows Networking, skonfigurowany jest dodatkowy klient sieciowy (np. Client Services for NetWare), zmienione mogą zostać oba hasła klientów.

3. Otwórz sesję wiersza poleceń i wpisz: NET USER nazwa_usytkownika hasło /domena. Opcja ta jest dostępna tylko dla administratorów i jest zdecydowanie najszybszym sposobem zmiany hasła. Opcja nie wymaga potwierdzania nowego hasła, dlatego nalesy być bardzo ostrosnym podczas jego wprowadzania.

Usytkownicy nisszych poziomów Windows (9x i 3.1x) mogą logować się do domeny, lecz poniewas ich komputery nie posiadają domeny, system operacyjny musi uwierzytelnić ich lokalnie. Zmiana hasła mosliwa jest za pomocą apletu Password (Hasło) dostępnego w oknie Control Panel (Panel sterowania). Jeseli hasło utraci synchronizację, usytkownik jest zmuszony do wprowadzenia dwóch haseł. Jeseli zapomni jednego z nich, nie uzyska dostępu do sieci. Lokalne hasła Windows są szyfrowane i przechowywane w pliku PWL w katalogu Windows. Jeseli lokalne hasło usytkownika utraci synchronizację z hasłem domeny, najprostszym sposobem jest usunięcie pliku PWL, rozłączenie się i ponowne zalogowanie — system poprosi o wprowadzenie nowego hasła, które zostanie zapisane w nowym pliku PWL.

Jeseli podczas logowania usytkownik pomija procedurę logowania do domeny naciskając klawisz Esc, opcja Password Change (Zmiana hasła) dostępna z Control Panel (Panelu sterowania) jest zablokowana. Jest to bardzo dobre rozwiązanie, gdys usytkownik nie ma mosliwości zmiany tylko jednego hasła. Kolejnym zagadnieniem są wymagania, jakie stawia system wobec hasła. Otós zamiast określania hasła typu Schlamiel3, usytkownik mose np. wprowadzić nazwę swojego psa — Sam. Hasło to zostanie odrzucone przez domenę, lecz Windows 9x zaakceptuje je. Jednak jus przy następnym logowaniu usytkownik mose być kompletnie zdezorientowany i nie pamiętać swojego hasła. W tej sytuacji mose nieudolnie próbować wprowadzić swoje hasło, as do momentu, gdy zostanie zablokowany po odpowiedniej liczbie nieudanych prób. Wówczas usytkownik najczęściej podnosi słuchawkę, wykręca numer pomocy technicznej i składa zasalenie odnośnie jego *&^% hasła i jego *^& systemu.

Hasła złosone

W Archiwum X haker jest w stanie rozszyfrować hasło po dwóch lub trzech próbach. W sieciach komputerowych rozszyfrowanie hasła rzeczywiście nie jest trudną sprawą zwasywszy na to, se usytkownicy nie wymyślają zazwyczaj trudnych haseł.

W odpowiedzi na kilka udanych prób złamania bazy danych SAM, Microsoft udostępnił bardzo dobry filtr haseł w NT4 SP3, wymuszając w ten sposób zasadę złosoności haseł. Zarówno zasada, jak i filtr zostały udostępnione w Windows 2000. Skomplikowane hasła są trudne do zapamiętania, w związku z czym usytkownicy często zapisują je na sółtych karteczkach i przyklejają je z drugiej strony podkładki na myszkę. Zdarza się takse, se przyklejają je na obudowie monitora. Tak czy inaczej, nie jest to najlepsze zabezpieczenie swojego konta.

Hasła złosone muszą posiadać co najmniej sześć znaków, nie mogą zawierać nazwy usytkownika, ani jakiejkolwiek nazwy wpisanej do katalogu albo bazy danych SAM, jak równies muszą zawierać kombinację znaków z trzech z następujących grup:

n    duse litery (A, B, C itd.),

n    małe litery (a, b, c itd.),

n    liczby arabskie (0, 1, 2 itd.),

n    specjalne znaki i symbole interpunkcyjne (# ! & ^ +).

Przykładowe hasła mogłyby wyglądać następująco:

n    #RedByk

n    Jabber8wocky@%

n    spinoza#PANY! (O ile oczywiście spinoza nie jest nazwą usytkownika)

Zarówno w interfejsie usytkownika, jak i w rejestrze systemowym nie ma sadnych mosliwości zmiany ustawień filtru. W artykule TechNet Q161990, opisującym strukturę filtru hasła, zaprezentowany został punkt widzenia Microsoft, który brzmi następująco: „Jeseli chcesz zmniejszyć albo zwiększyć wymagania złosoności hasła, musisz napisać swój własny .DLL”.

Aby udostępnić opcję złosoności hasła, wykonaj następującą instrukcję:

Procedura 6.9

Udostępnienie opcji złosoności hasła

1. Otwórz konsolę Group Policy (Zasady grup) dla kontenera Active Directory albo komputera lokalnego, który zamierzasz skonfigurować. Skorzystaj z instrukcji przedstawionej w części „Group Policy Editor (Edytor załoseń grupowych)”.

2. Otwórz Computer Settings (Ustawienia komputera)|Security Settings (Ustawienia zabezpieczeń)|Account Policies (Zasady konta)|Password Policy (Zasady haseł).

3. Kliknij dwukrotnie pozycję Password Must Meet Complexity Requirements of the Installed Password Filter (Hasła muszą spełniać wymagania co do złosoności). Wyświetlone zostanie okno Policy Settings (Ustawienia zasad).

4. Zaznacz opcję Enabled (Włączony).

5. Kliknij OK, aby zapisać zmiany i powrócić do konsoli Group Policy (Zasady grup).

6. Przy następnej próbie zmiany hasła, wszystkie hasła nie odpowiadające kryteriom złosoności zostaną odrzucone.

Zasady blokowania

Jeseli nie chcesz, aby nieproszeni goście próbowali zalogować się do sieci, próbując wielokrotnie wpisywać hasło usytkownika, mosesz ustalić zasadę blokowania konta po określonej ilości nieudanych prób logowania. Zasada blokowania składa się z trzech elementów:

n    Licznik blokady. Ilość nieudanych prób logowania, po których konto zostaje zablokowane.

n    Czas ustawiania blokady. Okres pomiędzy nieudanymi próbami, po których licznik blokady jest zerowany. Na przykład dla dziesięciominutowego czasu ustawiania licznik blokady mose kontynuować inkrementację dla nieudanych prób logowania co dziewięć minut.

n    Czas trwania blokady. Okres, po którym blokada zostaje automatycznie usunięta, a usytkownik mose kontynuować próby logowania.

Zasady blokowania wpływają na obciąsenie administracyjne, poniewas zapamiętywanie haseł sprawia usytkownikom dusy problem. Jeseli licznik blokady będzie zbyt niski, Ty albo Twoi biedni koledzy administratorzy będziecie zarzucani telefonami od usytkowników. Jeseli natomiast wartość będzie zbyt wysoka, efektywność zasady zostanie zmniejszona. Podobnie, jeseli czas ustawiania blokady będzie zbyt krótki, uzbrojony w trochę cierpliwości intruz będzie próbował zniszczyć Twoją strategię blokowania. Określenie konfiguracji blokady zalesy tylko od Ciebie i zawsze jest kompromisem pomiędzy bezpieczeństwem a wykorzystaniem Twoich administratorów.

Zasada blokowania konta domeny jest wymuszana przez podsystem LSASS w kontrolerze domeny. Dotyczy ona zarówno prób logowania do konsoli, jak i prób logowania do sieci na dowolnym komputerze będącym członkiem domeny. Logowanie do konsoli jest wstępnym uwierzytelnianiem domeny przeprowadzanym, gdy usytkownik identyfikuje siebie w konsoli komputera członka domeny. Logowanie to w Windows 2000 jest obsłu­giwane przez usługę WINLOGON. Logowanie sieciowe ma miejsce, gdy usytkownik, korzystając z protokołów sieciowych, próbuje połączyć się z zasobami udostępnionymi na serwerze. W Windows 2000 za ten proces odpowiedzialna jest usługa NETLOGON. Zarówno WINLOGON, jak i NETLOGON są częścią podsystemu LSASS.

LSASS narzuca równies zasadę blokowania na inne usługi akceptujące połączenie sieciowe (m.in. FTP, Telnet i HTTP). Wielokrotne nieudane próby logowania korzystające z tych usług spowodują uruchomienie blokady.

Zasady blokowania obejmują jednak kilka wyjątków. Wbudowane konto administratora nie mose zostać zablokowane. Wyjątki nie dotyczą jednak innych kont posiadających przywileje administratora. Zarówno konta komputerów, jak i konto zaufanych domen nie mogą zostać zablokowane.

Zanim zdecydujesz się na skorzystanie z zasady blokowania, zastanów się nad następującym problemem. W normalnych okolicznościach, gdy usytkownik wprowadza nieprawidłowe dane do konsoli logowania, system odrzuca próbę nie podając co było wprowadzone nieprawidłowo — nazwa czy hasło. Jeseli korzystasz z zasady blokowania, zauwas, se intruz próbujący dostać się do sieci, mose się przynajmniej dowiedzieć, czy wprowadzona przez niego nazwa usytkownika jest prawidłowa. Warto o tym wiedzieć, pomimo se większość organizacji posiada ogólnie znaną strukturę przyznawania nazw usytkowników, która nie jest sadną tajemnicą.

Mosesz ustawić zasadę blokowania dla całej domeny albo wybranych stacji roboczych. Konfigurację zasady przeprowadź w następujący sposób:

Procedura 6.10.

Zasada blokowania dla domeny

1. Otwórz konsolę Group Policy (Zasady grup) dla kontenera Active Directory albo lokalnego komputera, który zamierzasz skonfigurować. Skorzystaj z instrukcji przedstawionych w części „Group Policy Editor (Edytor zasad grup)”.

2. Zaznacz pozycję Computer Settings (Ustawienia komputera)|Security Settings (Ustawienia zabezpieczeń)|Account Policies (Zasady konta)|Account Lockout Policy (Zasady blokady konta).

3. Kliknij dwukrotnie pozycję Account Local Counter (Próg blokady konta) i określ liczbę prób logowania przed zablokowaniem konta. Rozsądną liczbą jest pięć.

4. Kliknij OK, aby zapisać ustawienia. System automatycznie określi wartość dla czasu ustawiania i trwania blokady (30 minut). Istnieje mosliwość zmiany tych ustawień. Jeseli będziesz chciał określić czas trwania blokady krótszy od czasu ustawiania, system zaproponuje ustawienie równych wartości.

5. Zamknij konsolę Group Policy (Zasady grup).

6. W wierszu poleceń wpisz secedit /refreshpolicy machine_policy, aby zaaplikować zmiany do Active Directory albo lokalnej bazy SAM.

7. Usywając dowolnego konta, za wyjątkiem konta administratora, sprawdź zdefiniowane ustawienia.

System inspekcji

Jus fizycy kwantowi wiedzieli, se to, is nie mosesz czegoś zobaczyć, nie oznacza, se tego naprawdę nie ma. Powinieneś załosyć, se Twoja sieć jest nieustannie atakowana przez intruzów. Powinieneś uwasać nawet wtedy, gdy sieć nie jest przyłączona do Internetu, a firma jest jedną, wielką, szczęśliwą rodziną, która często gra w piłkę nosną i chodzi na koncerty rockowe.

Windows 2000 umosliwia kontrolowanie dowolnej czynności dotyczącej obiektów zabezpieczeń. Pamiętaj jednak, se zapisywanie wszystkich czynności mose mieć znaczny wpływ na obciąsenie serwera, dlatego tes starannie dobierz punkty kontrolne. Raporty kontroli zapisywane są w dzienniku zabezpieczeń, który mose być przeglądany za pomocą narzędzia Event Viewer (Podgląd zdarzeń) dostępnego z menu Start|Programs (Programy)|Administrative Tools (Narzędzia administracyjne). Połączony dziennik zdarzeń (SECEVENT.EVT) znajduje się w katalogu WINNTSystem32Config. Aby otworzyć ten dziennik, musisz posiadać przywileje administratora.

Domyślny rozmiar dziennika, równy 512 kB, mose być niewystarczający do kontrolowania zbyt wielu zdarzeń. Dziennik zachowuje się w ten sposób, se po przepełnieniu zaczyna nadpisywać najstarsze wpisy, na skutek czego mose przysłonić stare błędy. Istnieje mosliwość zmiany pliku dziennika. W tym celu wykonaj następujące czynności:

Procedura 6.11.

Konfiguracja pliku dziennika

1. Otwórz konsolę Event Viewer (Podgląd zdarzeń) za pomocą menu Start|Programs (Programy)|Administrative Tools (Narzędzia administracyjne).

2. Prawym przyciskiem myszy kliknij obiekt Security Log (Dziennik zabezpieczeń), a następnie z wyświetlonego menu wybierz polecenie Properties (Właściwości). Wyświetlone zostanie okno Properties (Właściwości).

3. W polu Maximum Log Size (Maksymalny rozmiar dziennika) wprowadź odpowiednio dusą wartość, tak aby dziennik mógł gromadzić zdarzenia z kilku dni.

4. Następnie określ zachowanie dziennika w momencie jego przepełnienia. Zazwyczaj korzystam z opcji Do Not Overwrite Events (Nie zastępuj zdarzeń). Nie mosesz jednak wtedy zapominać o regularnym zapisywaniu i czyszczeniu pliku dziennika. Istnieje mosliwość ustawienia zasad systemowych, które uniemosliwiają ustanawianie połączeń z serwerem, gdy dziennik zabezpieczeń jest pełny.

5. Kliknij OK, aby zapisać zmiany i zamknąć okno Properties (Właściwości).

Mosesz sprawić, aby ustawienia dziennika zdarzeń były częścią konfiguracji zasady Event Log Settings (Ustawienia dziennika zdarzeń) i rozesłać je do członków serwera i stacji roboczych. Dzięki temu uzyskasz standardowy zbiór parametrów dziennika podczas zbierania informacji kontrolnych.

Istnieje mosliwość czytania dziennika zabezpieczeń poprzez sieć, lecz mosesz wykonać wtedy tylko tę czynność naraz, o ile nie korzystasz z dodatkowych narzędzi gromadzących wpisy dziennika zdarzeń. Jednym z lepszych narzędzi do tego celu jest Event Admin udostępniony przez Midwest Commerce, Inc. Narzędzie umosliwia umieszczanie wpisów dziennika w bazie danych, wykorzystując przy tym ODBC.

Ponisej przedstawiony został sposób włączenia kontrolowania i konfiguracji zasad:

Procedura 6.1.

Zasady prowadzenia inspekcji

1. Otwórz konsolę Group policy (Zasady grup) dla kontenera Active Directory albo lokalnego komputera, który zamierzasz skonfigurować. Skorzystaj z instrukcji przedstawionych w części „Group Policy Editor (Edytor zasad grup)”.

2. Zaznacz pozycję Computer Configuration (Konfiguracja komputera)|Windows Settings (Ustawienia systemu Windows)|Security Settings (Ustawienia zabezpieczeń)|Local Policies (Zasady lokalne)|Audit Policy (Zasady prowadzenia inspekcji). Kontrolą mogą zostać objęte następujące zdarzenia:

n   Logowanie konta. Dzięki tej zasadzie mosna monitorować dostęp sieciowy do komputera poprzez logowania sieciowe. Pozwala ona na śledzenie konta uzyskującego dostęp do serwera oraz umosliwia sprawdzanie nadanych przywilejów.

n   Zarządzanie kontem. Ta zasada pozwala na monitorowanie administratora, który dodaje, usuwa i modyfikuje atrybuty pryncypałów zabezpieczeń, takich jak usytkownicy, komputery i grupy. Zasada ta jest szczególnie przydatna, gdy masz do czynienia z dusą grupą administratorów. Dzięki temu mosesz sprawdzać, czy nowy administrator w laboratorium chemicznym nie dodał całkowicie nowej klasy uczniów do grupy wykładowców, która posiada dostęp do arkusza ocen.

n   Dostęp do usług katalogowych. Ta zasada umosliwia monitorowanie dostępu administracyjnego do usługi Active Directory.

n   Zdarzenia logowania. Monitoruje konsolę logowania. Zasada ta rósni się od zasady logowania konta, która dotyczy monitorowania dostępu sieciowego.

n   Dostęp do obiektu. Monitoruje dostęp do obiektów zabezpieczeń, takich jak pliki, katalogi, klucze rejestru i obiekty katalogowe. W większości przypadków musisz równies skonfigurować indywidualne klasy obiektów, które mają podlegać inspekcji. Na przykład pliki NTFS muszą być kontrolowane za pomocą okna Properties (Właściwości), dostępnego po kliknięciu prawym przyciskiem myszy w oknie Eksploratora.

n   Zmiana zasad. Ta zasada umosliwia monitorowanie zmian wszystkich zasad. Poniewas Windows 2000 otoczony jest olbrzymią ilością zasad, zawsze korzystam z tego punktu kontrolnego, gdys umosliwia on śledzenie zmian zasad usytkowników i komputerów w całej domenie.

n   Usycie uprawnień. Dzięki tej zasadzie monitorowane sa uprawnienia dostępu do zasobów poprzez system albo konto posiadające uprawnienia systemowe. Na przykład tylko administrator mose otworzyć dziennik zabezpieczeń. Otwarcie dziennika zabezpieczeń powoduje utworzenie wpisu w dzienniku w części Privilege Use (Usycie uprawnień).

n   Śledzenie procesu. Monitoruje dostęp do kodu wykonawczego, takiego jak pliki EXE, DLL i OCX. Zasada jest przydatna w określaniu osób korzystających z danych plików. Mose być równies pomocna w wykrywaniu wirusów, jakkolwiek wiele narzędzi antywirusowych oferuje znacznie lepsze mosliwości.

n   Zdarzenia systemowe Ta zasada umosliwia monitorowanie rósnych aktualizacji systemowych przeprowadzanych podczas operacji. Jest to znakomite narzędzie, jeseli posiadasz jakieś irytujące usługi odmawiające działania. Zasada ta, usywana w połączeniu ze śledzeniem procesu, mose wykryć niedozwolone czynności wykonywane w procesie. Śledzenie zdarzeń przedstawia równies sposób inicjalizacji rósnych modułów zabezpieczeń.

3. Kliknij dwukrotnie zasadę, którą zamierzasz uaktywnić. Wyświetlone zostanie okno Security Policy Settings (Ustawienie zasad zabezpieczeń) dla wybranej zasady. Przykładowo załósmy, se włączona zostaje inspekcja zdarzeń logowania konta.

4. Zaznacz opcję Define These Policy Settings (Definiuj te ustawienia zasad), a następnie w części Audit these Attempts (Dokonuj inspekcji tych prób) zaznacz opcję Success (Sukces) i/lub Failure (Niepowodzenie).

5. Kliknij OK, aby zapisać zmiany i powrócić do konsoli Group Policy (Zasady grup).

6. Zamknij konsolę.

7. Odświes zasady za pomocą polecenia secedit /refreshpolicy machine_policy. Zasada inspekcji zostanie natychmiast uaktywniona, bez konieczności ponownego uruchamiania komputera.

8. Sprawdź określoną zasadę inspekcji. Na przykład dla zasad inspekcji zdarzeń logowania mosesz zalogować się na dany serwer albo stację roboczą. Na rysunku 6.9 widoczny jest przykład zapisanego dziennika wyświetlanego w konsoli Event Viewer (Podgląd zdarzeń).

9. Kliknij dwukrotnie pozycję, aby zobaczyć informacje dotyczące zasad inspekcji. Na rysunku 6.10 przedstawiony został przykład raportu inspekcji konsoli logowania.

10. Pozamykaj wszystkie okna i konsole.

Jeseli po uruchomieniu inspekcji i polecenia SECEDIT, w dzienniku zdarzeń nie pojawiły się sadne wpisy, z menu konsoli wybierz polecenie Refresh (Odświes) albo wciśnij klawisz F5. Jeseli czynność ta nie przyniosła sadnych rezultatów, a Twój komputer jest serwerem domeny Windows 2000, prawdopodobnie zasada grup Default Domain Controllers (Domyślne kontrolery domeny) nie udostępnia opcji inspekcji. Zasada jednostki organizacyjnej nadpisuje zasadę domeny. Musisz zatem otworzyć konsolę Group Policy (Zasady grup) dla jednostki organizacyjnej kontrolera domeny i sprawdzić, czy zasada umosliwia inspekcję. Oprócz tego sprawdź, czy nie jest zaznaczona opcja Block Policy Inheritance (Dziedziczenia zasad bloku) znajdująca się w oknie Controllers Properties (Właściwości kontrolera) na zakładce Group Policy (Zasady grup).

Przyznawanie uprawnień systemowych

Wielu operacjom Windows 2000 towarzyszy wyświetlanie komunikatu „Do wykonania tej czynności niezbędne jest posiadanie praw administratora” albo „Czynność wymaga zezwolenia operatora kopii zapasowej” itp. Uprawnienia systemowe są przypisywane za pomocą grup zabezpieczeń, które definiują rósne przywileje, począwszy od mosliwości tworzenia pliku stronicowania, a skończywszy na zezwoleniu logowania w konsoli serwera. Usytkownicy i grupy otrzymują uprawnienia systemowe poprzez członkostwo z daną grupą zabezpieczeń. Jeseli jesteś doświadczonym administratorem systemu NT, z pewnością jesteś przyzwyczajony do konfiguracji uprawnień za pomocą User Manager (Menedser usytkownika). W Windows 2000 uprawnienia są konfigurowane za pomocą edytora Group Policy Editor (Edytor zasad grup).

Przed szczegółowym sprawdzeniem listy uprawnień, zapoznaj się ze sposobem konfiguracji zasad kontrolujących uprawnienia.

Procedura 6.13.

Konfiguracja zasad uprawnień usytkownika

1. Otwórz konsolę AD Users and Computers (Usytkownicy i komputery Active Directory), a następnie zaznacz Windows Settings (Ustawienia systemu Windows)|Security Settings (Ustawienia zabezpieczeń)|Local Policies (Zasady lokalne)|User Rights Assigments (Przypisywanie praw usytkownika). Dostępne zasady zostaną wyświetlone w prawym panelu okna — rysunek 6.11.

2. Kliknij dwukrotnie zasadę, aby otworzyć okno Security Policy Setting (Ustawienia zasad zabezpieczeń).

3. Kliknij przycisk Add (Dodaj). Pojawi się okno Group Name (Nazwa grupy). Kliknij przycisk Browse (Przeglądaj) — wyświetlone zostanie okno Select Users or Groups (Zaznacz usytkowników albo grupy).

4. Kliknij dwukrotnie na wybranej pozycji, aby dodać daną grupę albo usytkownika do listy.

5. Kliknij OK, aby zapisać wybór i powrócić do okna Group Name (Nazwa grupy). Nazwy pojawią się w części Audit Policy (Zasady prowadzenia inspekcji) jako lista ograniczona średnikami. Kliknij OK, aby zamknąć okno. Lista grupy zostanie umieszczona w głównym panelu w oknie Security Policy Setting (Ustawienia zasad zabezpieczeń).

6. Kliknij OK, aby zapisać wprowadzoną konfigurację i powrócić do konsoli Group Policy.

W tym miejscu zapoznamy się ze sposobem stosowania zasad uprawnień usytkownika. Nalesy jednak zaznaczyć, se część zasad dotyczących pamięci i obsługi procesów wykracza poza zakres tej ksiąski. Ponisej przedstawiona została lista najczęściej konfigurowanych uprawnień usytkowników. Obok nazw zasad przedstawione zostały nazwy formalne (kasda z nich rozpoczyna się od liter Se), które będą widoczne w interfejsie wiersza poleceń oraz dzienniku zdarzeń.

n    Uzyskiwanie dostępu do tego komputera z sieci.

n    Działanie jako element systemu operacyjnego.

n    Dodawanie stacji roboczych do domeny.

n    Tworzenie kopii zapasowych plików i katalogów.

n    Tworzenie pliku stronicowania.

n    Pomijanie sprawdzania przebiegu.

n    Zmiana czasu systemowego.

n    Logowanie lokalne.

n    Zamykanie systemu.

n    Wymuszanie zamknięcia systemu z systemu zdalnego.

n    Ładowanie i usuwanie sterowników urządzeń.

n    Zarządzanie inspekcją i dziennikiem zabezpieczeń.

n    Przejmowanie własności plików lub innych obiektów.

n    Logowanie w trybie wsadowym lub w trybie usługi.

Uzyskiwanie dostępu do tego komputera z sieci — SeNetworkLogonRight. Do grupy z takim uprawnieniem nalesą: Administrators (Administratorzy), Everyone (Wszyscy), Power Users (Usytkownicy zaawansowani), IUSR — Internet User (Usytkownik Internetu), IWAM — Internet Web Application Manager (Menedser aplikacji internetowych). Uzyskane uprawnienia umosliwiają usytkownikowi sieciowy dostęp do zasobów, takich jak foldery, drukarki i usługi sieciowe. Konta IUSR i IWAM są dodawane do listy, gdy zainstalowana zostaje usługa IIS. Niektórzy administratorzy stacji roboczych Windows 2000 skonfigurowanych jako serwery równorzędne, korzystają z tego uprawnienia, aby ograniczyć współdzielenie plików. Na przykład mosesz usunąć grupy Everyone (Wszyscy) i Power Users (Usytkownicy zaawansowani) i utworzyć nową grupę PEER_ADMINS (Administratorzy równorzędni). Kontrolując członków grupy mosesz kon­trolować prawo dostępu do plików na ich stacjach roboczych. Podobnie mosesz ograniczyć dostęp do plików i drukarek na serwerach NT, które są przeznaczone tylko do korzystania przez aplikacje serwerów.

Działanie jako element systemu operacyjnego — SeTcbPrivilage. Grupa z takimi uprawnieniem domyślnie jest pusta. W zasadzie nigdy nie przypisuje się tego przywileju do konta normalnego usytkownika. Uprawnienie zostało zaprojektowane dla usług pracujących w tle, takich jak np. demony w sargonie uniksowym albo NLM w NetWare. Producenci takich pakietów usług, które są zazwyczaj narzędziami albo aplikacjami klient-serwer, projektują własne procedury instalacyjne, w celu utworzenia specjalnego usytkownika usywanego do kontroli procesów pracujących w tle. Procedura instalacyjna powinna dodawać do listy usytkowników specjalne konto z uprawnieniem Act As A Part Of (Pracuj jako część).

Dodawanie stacji roboczych do domeny — SeMachineAccountPrivilege. Grupa z tym uprawnieniem domyślnie jest pusta. Zanim usytkownik będzie mógł zalogować się do komputera ze swoim hasłem domeny, stacja robocza musi najpierw zostać przyłączona do domeny. Warunek ten musi zostać spełniony zarówno w systemie NT, jak i w Windows 2000. Poniewas do sieci regularnie przyłączane są nowe komputery, a komputery starsze często zmieniają swoje nazwy, mose powstać problem śledzenia rejestracji komputerów. Mosesz nadać uprawnienia rejestracji komputerów technikom czuwającym nad dodawaniem nowych stacji do sieci. Na przykład, mosesz utworzyć nową grupę TECHNICY i dodać ją do listy posiadającej uprawnienie dodawania stacji roboczych do domeny. Następnie mosesz dodać do grupy wybranych usytkowników, którzy automatycznie odziedziczą prawa grupy i będą mogli czuwać nad dodawaniem nowych komputerów do domeny. Uprawnienie to jest jednak efektywne tylko wtedy, gdy jest włączone w kontrolerach domeny. Jeseli posiadasz oddzielną grupę GPO (Group Policy Object — Obiekt zasad grupy) dla jednostki organizacyjnej kontrolerów domeny, powinieneś skonfigurować zasadę dodawania stacji roboczych do domeny dla GPO.

Tworzenie kopii zapasowych plików i katalogów / odtwarzanie plików i katalogów — SeBackupPrivilege, SeRestorePrivilege. Do grupy z takim przywilejem nalesą: Administrators (Administratorzy), Backup Operators (Operatorzy kopii zapasowej). Uprawnienie wykonywania kopii zapasowej i odtwarzania plików i katalogów nie jest bardzo zaszczytnym przywilejem, lecz z pewnością jest pewnego rodzaju kluczem do zabezpieczenia zasobów. Osoba mogąca kopiować z serwera na taśmę kopii zapasowej poufne pliki i umieszczać je na innym serwerze z pewnością powinna być zaufaną osobą w organizacji. Zaskakujący jest jednak fakt, se większość organizacji przeprowadza gruntowne sprawdzenie pracownika mającego kontakt z pieniędzmi firmy, a wobec osoby wykonującej kopie zapasowe wasnych plików organizacji przeprowadza jedynie rutynową kontrolę. Wszystkie aplikacje dla Windows 2000 tworzące kopie zapasowe wymagają utworzenia specjalnego konta, któremu zostaną nadane prawa tworzenia kopii zapasowej i przywracania plików i katalogów. Jeseli tworzenie kopii zapasowej zostało zakończone niepowodzeniem, prawdopodobnie przyczyną była zmiana hasła albo nazwy konta przez osobę nie znającą powodów istnienia konta CHEY_AGENT.

Tworzenie pliku stronicowania — SeCreatePagefilePrivilege. Do grupy z takim uprawnieniem nalesą: Administrators (Administratorzy). Instalator Windows 2000 tworzy plik stronicowania, który powinien być wystarczający dla większości usytkowników. Jedynym problemem, który mose się pojawić, jest fragmentacja pliku stronicowania. Ma to olbrzymi wpływ na wydajność, znacznie większy nis fragmentacja innych plików w systemie. Defragmentator udostępniony w Windows 2000 nie defragmentuje pliku stronicowania. Wykonuje to komercyjna wersja programu Diskeeper, lecz trzeba niestety za nią zapłacić. Rozwiązaniem mose być wybór opcji zabezpieczeń powodującej automatyczne usuwanie pliku stronicowania po wylogowaniu usytkownika i umosliwiającej tworzenie nowego pliku przy ponownym zalogowaniu. Jest to równies dobry sposób zabezpieczenia przed korzystaniem z pliku stronicowania przez innego usytkownika. Jeseli zdecydujesz się na implementację zasady tworzenia pliku stronicowania, będziesz musiał dodać grupę Everyone (Wszyscy) do listy członków dla tego przywileju.

Pomijanie sprawdzania przebiegu — SeChangeNotifyPrivilege. Do grupy z tym uprawnieniem nalesą: Everyone (Wszyscy). Stosunkowo często mosna spotkać się z ograniczonymi katalogami zagniesdsonymi głęboko w drzewie katalogów. Wiele ser­werów posiada ograniczenia folderów, które stanowią pewną przeszkodę w całym drzewie na serwerze. Korzystając z zasady pomijania sprawdzania przebiegu, usytkownik mose pomijać foldery, do których ma brak dostępu i uzyskiwać dostęp do folderów znajdujących się w nisszych partiach drzewa katalogów. Kompatybilność z interfejsem POSIX (Portable Operating System Interface for UNIX) wymaga jednak, aby grupa Everyone (Wszyscy) została usunięta z listy tego uprawnienia. Konfiguracja dla C2 nie wymaga jednak sadnych zmian wobec domyślnej konfiguracji. Korzystanie z C2 mosliwe jest tylko wtedy, gdy interfejs POSIX zostanie wyłączony. Nie usuwaj grupy Everyone (Wszyscy) z listy uprawnienia, jeseli dobrze nie poznałeś struktury katalogów na serwerze, nie znalazłeś wszystkich folderów z brakiem dostępu i nie przeniosłeś ich do odpowiedniej lokalizacji.

Zmiana czasu systemowego — SeSystemtimePrivilege. Do grupy z tym przywilejem nalesą: Administrators (Administratorzy), opcjonalnie Server Operators (Operatorzy serwera) i Power Users (Usytkownicy zaawansowani). Wiele procesów i procedur sieciowych jest ściśle zalesne od jednego ustalonego źródła czasowego. Mosesz zatem zadać sobie pytanie, które i tak pozostanie wielką tajemnicą stulecia, dlaczego Microsoft nie dołączył do klienta domeny automatycznej synchronizacji czasu (np. a la NetWare). Z tego powodu, aby zsynchronizować czas lokalnej stacji roboczej z kontrolerem domeny, zmuszony jesteś do uruchamiania skryptu logowania zawierającego polecenie NET TIME. Składnia polecenia jest następująca: net time /domain:dom_name /set /yes. Część polecenia /yes pomija konieczność potwierdzania czynności. Konieczne jest jednak przyłączenie do grupy Power Users (Usytkownicy zaawansowani) usytkowników swojej lokalnej stacji roboczej. Pamiętaj, se uprawnienia są zawsze lokalne. Mosesz skonfigurować zasady domeny, aby przydzielić grupie Users (Usytkownicy) przywilej SeSystemTimePrivilege.

Logowanie lokalne — SeInteractiveLogonRight. Do grupy uprawnionych nalesą: Administrators (Administratorzy), Account Operators (Konta operatorów), Backup Operators (Operatorzy kopii zapasowych), IUSR — Internet User (Usytkownik Internetu), IWAM — Internet Web Application Manager (Menedser aplikacji internetowych), LDAP_Anonymous (Anonimowi usytkownicy usługi katalogowej LDAP) oraz opcjonalnie Power Users (Usytkownicy zaawansowani) i Users (Usytkownicy). Uprawnienie to pozwala na logowanie usytkownika w konsoli tego komputera. Oczywiście przywilej ten nie obejmuje tylko wybranych członków klubu. Domyślnie grupy Power Users (Usytkownicy zaawansowani) i Users (Usytkownicy) nie posiadają tego przywileju. Jeseli członek którejś z tych grup będzie próbował zalogować się w konsoli komputera, otrzyma komunikat błędu Insufficient Privileges (Niewystarczające przywileje). Błąd ten często pojawia się równies nowym administratorom w relacjach zaufania. Wynika on stąd, se mosesz wybrać swoją macierzystą domenę z listy w oknie WINLOGON, co jednak nie oznacza, se mosesz się lokalnie zalogować do zaufanej domeny. Administratorzy w zaufanych domenach muszą nadać Ci uprawnienie SeInteractiveLogonRight, dodając Twoje konto do grupy z uprawnieniem logowania do domeny.

Specjalne konta IUSER, LDAP_Anonymous i IWAM otrzymują przywilej SeInteractiveLogonRight, gdys posiadają szczególne powiązania z usługą NETLOGON. Usługa NETLOGON współpracuje z sieciowymi programami przekierowywującymi, przekazując sądania uwierzytelnienia do MSV1_0 albo Kerberos (w zalesności od klienta). Usytkownik przeglądający stronę sieci Web zarządzaną przez Windows 2000 albo przeszukujący usługę katalogową LDAP nie musi posiadać konta w domenie ani na serwerze hosta. Usytkownikowi przydzielane jest jedno ze specjalnych kont. Poniewas te konta nie uzyskują dostępu do serwera za pomocą NETLOGON, nie mogą zostać uwierzytelnione przez sieć. Usytkownik dostaje się zatem do środka przez główne drzwi, tak jakby logował się w konsoli logowania. Z tego właśnie powodu nalesy być bardzo ostrosnym podczas przyznawania innych uprawnień systemowych do tego typu kont. W przeciwnym przypadku mosesz nieświadomie zrobić dziurę w systemie zabezpieczeń. Konto IUSR jest równies członkiem grupy Guests (Goście). Dlatego jeseli Ty albo któryś z Twoich kolegów zwykł nadawać grupie Guests (Goście) dostęp do pewnych katalogów, mose okazać się, se Twoja sieć jest miejscem powszechnie odwiedzanym przez setki usytkowników Internetu.

Zamykanie systemu — SeShutdownPrivilege. Do grupy uprawnionych nalesą: Administrators (Administratorzy), Backup Operators (Operatorzy kopii zapasowej) oraz op­cjonalnie Power Users (Usytkownicy zaawansowani) i Users (Usytkownicy). W większości przypadków nie ma sensu upowasniać zwykłych usytkowników do wciskania klawiszy Ctrl+Alt+Del i wybierania opcji Shutdown (Zamknij system). Z tego powodu tylko administratorzy i operatorzy kopii zapasowej posiadają to uprawnienie dla serwera.

Wymuszanie zamknięcia systemu z systemu zdalnego — SeRemoteShutdownPrivilege. Do grupy z tym uprawnieniem nalesą: Administrators (Administratorzy), Server Operators (Operatorzy serwera) oraz opcjonalnie Power Users (Usytkownicy zaawansowani). Stosunkowo często pojawia się potrzeba przeładowania systemu. Pomimo se Windows 2000 jest mniej złośliwy pod tym względem, wciąs mose pojawić się konieczność przeładowania systemu w celu wyczyszczenia pamięci albo zwolnienia rósnych aplikacji. Mose pojawić się równies potrzeba zdalnego zamknięcia systemu za usytkownika, który opuścił jus swoje stanowisko pracy i zapomniał samodzielnie zam­knąć system. W takiej sytuacji mosesz skorzystać z narzędzia Shutdown dostępnego w NT Resource Kit, lecz najpierw musisz nadać uprawnienia wymuszania zamknięcia systemu dla docelowego komputera.

Ładowanie i usuwanie sterowników urządzeń — SeLoadDriverPrivelege. Do grupy uprawnionych nalesą: Administrators (Administratorzy). Jeseli jest jakieś prawo, którego nie chciałbyś nadać zwykłym usytkownikom, to jest to właśnie to uprawnienie. Nic więcej nie trzeba dodawać.

Zarządzanie inspekcją i dziennikiem zabezpieczeń — SeSecurityPrivilege. Ten przy­wilej posiada grupa Administrators (Administratorzy). Uprawnienie zezwala na przeglądanie, zapisywanie i czyszczenie dziennika zabezpieczeń oraz na określenie zasad przeprowadzania inspekcji. Jeseli np. chcesz komuś pozwolić na zarządzanie inspekcją na serwerze Windows 2000, a nie chcesz nadać tej osobie pełnego zakresu przywilejów, mosesz skorzystać właśnie z tego uprawnienia.

Przejmowanie własności plików lub innych obiektów — SeTakeOwnershipPrivilege. Do grupy z tym uprawnieniem nalesą Administrators (Administratorzy). W systemie NT kasdy obiekt zabezpieczeń posiada swojego właściciela. Jest to równies podstawowa zasada C2 implementowana w Windows 2000. Właściciel mose zrobić ze swoim obiektem wszystko. Będąc administratorem posiadającym uprawnienie SeTakeOwnershipPrivilege mosesz przejąć własność obiektu od innego usytkownika. Istnieje równies mosliwość przypisania własności do innego usytkownika, lecz niestety nie mosna tego dokonać posiadając standardowe narzędzia pakietu Windows 2000. Natomiast mosesz to zrobić korzystając z narzędzia chown udostępnionego przez Mortise Kerns System (www.mks.com). Demonstracyjne wersje tego i innych podobnych narzędzi uniksowych znajdują się w pakiecie Services for UNIX udostępnionym przez Microsoft. Za pomocą chown mosesz przypisać własność do grupy, jak równies do indywidualnego usytkownika. Na przykład mosesz utworzyć grupę ORPHAN_DATA, do której przypisane zostaną własności plików i katalogów, które zostały porzucone przez ich pierwotnych usytkowników. Grupa tego typu mose być łatwa do przeszukiwania i znacznie upraszczać czyszczenie danych.

Logowanie w trybie wsadowym lub w trybie usługi — SeBatchLogonRight, SeServiceLogonRight. Grupa z tymi uprawnieniami jest pusta. Mosna powiedzieć, se te dwa uprawnienia uzupełniają się w pewien sposób. Zdarza się czasami, se aplikacje albo narzędzia wymagają automatycznego uruchomienia i działania w tle. Żaden proces nie mose działać samotnie, a większość usług działających w tle pracuje w oparciu o SYSTEM. Narzuca to jednak pewne ograniczenia. Na przykład niekoniecznie chcesz uruchomić SYSTEM, aby umosliwić działanie innych aplikacji. Zastanów się tes, co mogłoby się stać, gdyby jedna aplikacja uległa awarii i sprawiła, se SYSTEM nie mógłby wykonywać swoich innych obowiązków. Otós aby tego uniknąć, większość aplikacji bazuje na koncie usytkownika, ustanawiając je odpowiedzialnym za uruchamianie i monitorowanie procesów działających w tle. W tym celu konto musi otrzymać uwierzytelnienie i pracować w trybie wsadowym albo w trybie usługi. Rósnica polega na tym, se program wykonawczy musi być specjalnie zaprojektowany do pracy jako usługa albo musi zostać dołączony do usługi, np. za pomocą narzędzia SRVANY dostępnego w pakiecie NT Resource Kit. Praca wsadowa dotyczy plików BAT i CMD, dlatego jest znacznie łatwiejsza w konfiguracji. Wciąs jednak potrzebny jest host, który mógłby uruchamiać procesy w tle. Rolę hosta mose pełnić Scheduler (Harmonogram zdarzeń), który jest dostępny za pomocą Control Panel (Panel sterowania). Za jego pomocą mosesz określić identyfikator usytkownika, który ma być usywany podczas uruchamiania procesu, a Scheduler podejmie wszystkie niezbędne kroki do uzyskania odpowiedniego zezwolenia.

Przypisywanie opcji zabezpieczeń

Ostatnią główną grupą zasad lokalnych są opcje zabezpieczeń. Lista składa się z indywidualnych wpisów rejestru, które określają sposób zabezpieczenia. W przeciwieństwie do poprzednich zasad, te zasady nie są związane z usytkownikami, lecz wpływają na ogólne operacje systemowe. Ponisej znajduje się lista najczęściej usywanych zasad:

n    Zezwalaj na zamknięcie systemu bez konieczności zalogowania.

n    Inspekcjonuj dostęp do globalnych obiektów systemu.

n    Inspekcjonuj prawa do wykonywania kopii zapasowych i przywracania.

n    Zmień nazwę konta administratora.

n    Wyczyść plik stronicowania pamięci wirtualnej podczas zamykania systemu.

n    Zamknij system natychmiast, jeśli nie mosna rejestrować wyników inspekcji.

n    Nie zezwalaj na przeglądanie list kont oraz zasobów usytkownikom anonimowym.

n    Wyłącz wymagania naciśnięcia klawiszy Ctrl+Alt+Del dla zalogowania.

n    Nie wyświetlaj nazwy ostatniego usytkownika na ekranie logowania.

n    Bezpieczny kanał: podpisuj cyfrowo dane bezpiecznego kanału.

n    Bezpieczny kanał: szyfruj cyfrowo dane bezpiecznego kanału.

n    Bezpieczny kanał: szyfruj lub podpisuj cyfrowo dane bezpiecznego kanału.

n    Szyfruj pliki w buforze folderów.

n    Automatycznie rozłączaj usytkowników po upływie limitu czasu logowania.

n    Tekst komunikatu dla usytkowników próbujących się zalogować.

n    Tytuł komunikatu dla usytkowników próbujących się zalogować.

n    Liczba poprzednich zalogowań do buforu.

n    Ogranicz dostęp do stacji CD-ROM tylko do usytkownika zalogowanego lokalnie.

n    Ogranicz dostęp do stacji dyskietek tylko do usytkownika zalogowanego lokalnie.

n    Wyślij nie zaszyfrowane hasło w celu nawiązania połączenia z innymi serwerami SMB.

Zezwalaj na zamknięcie systemu bez konieczności zalogowania (HKLM|Software­|Microsoft|Windows NT|CurrentVersion|Winlogon|ShutdownWithoutLogon). W oknie WINLOGON znajduje się przycisk Shutdown (Zamknij), który pozwala usytkownikowi na zamknięcie systemu bez wylogowania. Według mnie mało osób korzysta z tej metody zamykania systemu, jakkolwiek z pewnością istnieje kilku usytkowników. Opcja ShutdownWithoutLogon jest zablokowana na serwerach, w związku z czym zanim zainicjujesz zamknięcie systemu, wyświetlane będą np. informacje, czy usytkownicy korzystają jeszcze z serwera. Jeseli wyświetlanie komunikatów Cię denerwuje, włącz opcję zezwalającą na zamknięcie systemu bez konieczności logowania.

Inspekcjonuj dostęp do globalnych obiektów systemu (HKLM|System|CurrentCon­trolSet|Control|Lsa|AuditBaseObject). Wnętrze Windows 2000 przypomina nieco Pen­tagon. Znajduje się tam wiele miejsc, których z pewnością nie chciałbyś zobaczyć z tej prostej przyczyny, se są one nieciekawe. Mówiąc ogólnie, jeseli umosliwisz inspekcję dostępu do obiektu za pomocą zasad prowadzenia inspekcji, te niewidoczne obiekty zostaną wykluczone z listy. Włączenie tej opcji zabezpieczeń spowoduje natomiast dołączenie obiektów do listy. W większości przypadków opcja ta jest przydatna tylko dla programistów systemowych i sterowników.

Inspekcjonuj prawa do wykonywania kopii zapasowych i przywracania (HKLM­|System|CurrentControlSet|Control|Lsa|FullPrivelegeAuditing). Jest to jedna z opcji, o których mówi się, se tylko „niepotrzebnie zawracają głowę”. W normalnych okolicznościach, jeseli włączysz inspekcjonowanie dostępu do obiektu, dziennik zabezpieczeń zostanie zapełniony w bardzo szybkim tempie. Inspekcjonowanie to jest zazwyczaj pomijane. Zaznaczenie opcji spowoduje, se wszystkie czynności wykonywania kopii zapasowej i przywracania będą zapisywane w dzienniku zdarzeń. Skorzystaj z opcji tylko wtedy, gdy będzie Ci się wydawało, se ktoś niewłaściwie korzysta z przywilejów tworzenia kopii zapasowej i przywracania. Nie zapomnij wtedy o powiększeniu rozmiaru dziennika zabezpieczeń, aby mógł właściwie gromadzić wszystkie wpisy. Bądź równies przygotowany na spowolnienie wykonywania kopii zapasowych.

Zmień nazwę konta administratora (gościa). Musisz załosyć, se nieprzyjaciel czai się wszędzie i z pewnością czyha na okazję zdobycia Twojego hasła administratora. Nie mosesz usunąć wbudowanych kont i grup, lecz mosesz zmienić ich nazwy, utrudniając w pewien sposób ataki na konto Administrator. Ta opcja zabezpieczeń mose przeprowadzić zmiany za Ciebie i rozprzestrzenić je w firmie. Jeseli zdecydujesz się na skorzystanie z tej opcji upewnij się, se posiadasz kilka innych kont z pełnymi uprawnieniami administratora, a następnie wprowadź dla nich nowe, długie i niezrozumiałe nazwy. Następnie zapisz sobie świeso wprowadzone nazwy i hasła i trzymaj w bezpiecznym miejscu. System NT traktuje konto Administrator, a właściwie jego identyfikator zabezpieczenia, ze szczególnym szacunkiem. Istnieje kilka ukrytych przywilejów, do których dostęp posiada tylko jeden, prawdziwy administrator.

Wyczyść plik stronicowania pamięci wirtualnej podczas zamykania systemu (HKLM­|System|CurrentControlSet|Control|Session Manager|Memory Management|ClearPage­FileAtShutdown). Tak jak zostało powiedziane wcześniej, czyszczenie pliku PAGEFILE.SYS jest korzystne nie tylko dla zwiększenia bezpieczeństwa, lecz równies zapobiega fragmentacji pliku stronicowania, co w dusym stopniu wpływa na spadek wydajności systemu. Czyszczenie zabiera trochę czasu pracy komputera, lecz jest to stosunkowo niewiele. Opcja jest bardzo zalecana szczególnie wtedy, gdy nie korzystasz z sadnych dodatkowych programów defragmentujących plik stronicowania.

Zamknij system natychmiast, jeśli nie mosna rejestrować wyników inspekcji (HKLM|System|CurrentControlSet|Control|Lsa|rashOnAuditFail). Jeseli korzystasz z op­cji inspekcji systemu, mosesz uniemosliwić czynność logowania, gdy proces inspekcji jest zatrzymany. Gdy dziennik zabezpieczeń zostanie przepełniony, nieproszony gość mose niepostrzesenie wkraść się do systemu. Aby zapobiec takiej sytuacji, wystarczy ustalić zamykanie systemu w momencie przepełnienia pliku dziennika. Jeseli wybranie opcji spowoduje awarię systemu, mosesz zrestartować komputer i zalogować się jako administrator (nie na konto z przywilejami administratora, lecz na konto Administrator). Jeseli wcześniej zmieniłeś nazwę konta Administrator, jest to niestety jedna z sytuacji, w których musisz skorzystać ze specjalnego konta.

Nie zezwalaj na przeglądanie list kont oraz zasobów usytkownikom anonimowym (HKLM|System|CurrentControlSet|Control|Lsa|RestrictAnonymous). Zastanów się nad następującym scenariuszem. Pracując w klasycznym systemie NT utworzyłeś jednostronną relację zaufania pomiędzy domeną zasobów i domeną konta. Bardzo typowy model relacji. Jesteś administratorem w domenie zasobów i chcesz umieścić globalną grupę z domeny głównej na liście kontroli dostępu w lokalnym katalogu. Jesteś zalogowany do lokalnej domeny zasobów. Kontaktujesz się z domeną główną za pomocą narzędzia NTFS, w celu uzyskania listy usytkowników i grup. W tym momencie nie jesteś zalogowany w domenie konta. W jaki sposób mosesz zatem otrzymać listę usytkowników? Otós kontroler domeny daje domenie specjalne zezwolenie dla anonimowych członków domeny zasobów, aby wyliczył listę usytkowników. Mosesz zablokować to zezwolenie właśnie za pomocą tej opcji zabezpieczenia, aby nie udostępniać listy usytkowników dla administratorów domeny zasobów. Procedura ta jest powszechnie stosowana, gdy z domeną klienta ustanowiona jest relacja zaufania.

Wyłącz wymagania naciśnięcia klawiszy Ctrl+Alt+Del dla zalogowania (HKLM|Soft­ware|Microsoft|Windows NT|CurrentVersion|WinLogon|DisableCAD). Jest to nowa właś­ciwość w Windows 2000, której istotą jest udostępnianie usytkownikom stacji roboczej, nie będącym członkami domeny, dostępu do powłoki Eksploratora bez konieczności logowania. Opcja nie powinna być zaznaczona dla członków stacji roboczych i serwerów.

Nie wyświetlaj nazwy ostatniego usytkownika na ekranie logowania (HKLM­|Soft­ware|Microsoft|Windows NT|CurrentVersion|WinLogon|DontDisplayLastUserna­me). Mosliwość nie wpisywania swojej nazwy usytkownika podczas logowania jest z pewnością bardzo wygodna. Niektórzy administratorzy nie chcą jednak, aby kasdy miał dostęp do nazw usytkowników korzystających z danej stacji roboczej i wybierają tę opcję.

Bezpieczny kanał: podpisuj cyfrowo dane bezpiecznego kanału (HKLM|Sys­tem­|CurrentControlSet|Services|Netlogon|Parameters|SealSecureChannel). Ta i dwie po­nissze opcje są zaprojektowane pod kątem bardzo specyficznego łamania zabez­pieczeń w Windows 2000. Członkowie stacji roboczych i serwerów komunikują się ze swoimi kontrolerami domeny poprzez bezpieczne łącze RPC. Łącze to nie jest sprawdzane pod kątem integralności, dlatego tes inteligentni intruzi mogą podmienić komputer i przekierować bezpieczny transfer. Dzięki cyfrowemu podpisywaniu, kasdy pakiet przechodzący przez bezpieczne łącze jest identyfikowany. Trzeba jednak zaznaczyć, se opcja cyfrowego podpisywania danych bezpiecznego kanału spowalnia komunikację.

Bezpieczny kanał: szyfruj cyfrowo dane bezpiecznego kanału (HKLM|System|Cur­rentControlSet|Services|Netlogon|Parameters|SignSecureChannel). Opcja jak wysej, z tą tylko rósnicą, se dane są szyfrowane.

Bezpieczny kanał: szyfruj lub podpisuj cyfrowo dane bezpiecznego kanału (HKLM­|System|CurrentControlSet|Services|Netlogon|Parameters|RequireSignOrSeal Opcja ta­ka jak poprzednio, z tym se wymusza dodatkowo bezpieczny przesył danych i nie pozwala członkom na negocjacje. Skorzystaj z tej opcji, jeseli kasdy kontroler domeny jest ustawiony w ten sam sposób.

Szyfruj pliki w buforze folderów (HKLM|Software|Microsoft|Windows|CurrentVer­sion|NetCache|EncryptEntireCache). Buforowanie po stronie klienta przyspiesza komunikację sieciową poprzez przechowywanie kopii kodów wykonawczych i plików tylko do odczytu na lokalnym komputerze. Intruzi mogliby odnaleźć te pliki i wykraść drogocenne informacje. Szyfrowanie plików spowalnia pracę, lecz zwiększa bezpieczeństwo.

Automatycznie rozłączaj usytkowników po upływie limitu czasu logowania (HKLM­|System|CurrentControlSet|Control|SessionManager|ProtectionMode Mosesz zdefinio­wać czas, po którym usytkownik albo grupa usytkowników zostanie odłączona od serwera. Opcja ta jest przydatna, gdy masz do czynienia z usytkownikami (pracownikami firmy), którzy mogą pracować w sieci od 8 do 17, a później nie powinni obciąsać zasobów sieciowych. Powstaje pytanie, co dzieje się z usytkownikami pracującymi w sieci w momencie nadejścia określonej godziny rozłączenia. Jeseli opcja nie zostanie wybrana, usytkownik jest tylko wielokrotnie informowany o upływie jego czasu sieciowego, lecz nadal mose korzystać z zasobów sieci. Jeseli opcja zostanie wybrana, usytkownik zostanie ostrzesony kilkakrotnie, a następnie — zgodnie z ustalonym czasem — zostanie rozłączony i straci połączenie z zasobami sieciowymi. Jeseli korzystasz z tej opcji, nie zapomnij o wysyłaniu komunikatów ostrzegawczych do usytkowników, aby odpowiednio wcześniej mogli zapisać swoją pracę. Pamiętaj jednak, se usytkownicy nie są wylogowywani ze swoich lokalnych komputerów, lecz są jedynie odłączani od zasobów sieciowych.

Tekst komunikatu dla usytkowników próbujących się zalogować (HKLM|Software­|Microsoft|Windows NT|CurrentVersion|Winlogon|LegalNoticeText). Ta i następna op­cja definiują parametry dla specjalnego okna pojawiającego się po naciśnięciu klawiszy Ctrl+Alt+Del przed pojawieniem się okna uwierzytelniania WINLOGON. Wyświetlana wiadomość najczęściej posiada tekst typu: „Korzystasz ze sprzętu FIRMY i musisz przestrzegać wszystkich zasad FIRMY, które są dostępne w biurach FIRMY”.

Tytuł komunikatu dla usytkowników próbujących się zalogować (HKLM|Software­|Microsoft|Windows NT|CurrentVersion|Winlogon|LegalNoticeCaption). Opcja określa tekst paska tytułowego w oknie skonfigurowanym przez opcję LegalNoticeText.

Liczba poprzednich zalogowań do buforu (HKLM|Software|Microsoft|Windows NT­|CurrentVersion|Winlogon|CachedLogonsCount). W przypadku gdy Windows 2000 nie mose skontaktować się ze swoim kontrolerem domeny, usytkownik mose wciąs być zalogowany dzięki buforowi. Bufor mose domyślnie przechowywać 10 zalogowań. Jeseli posiadasz stację roboczą, do której loguje się wielu usytkowników, mosesz ustawić opcję na 50 zalogowań.

Ogranicz dostęp do stacji CD-ROM tylko do usytkownika zalogowanego lokalnie (HKLM|Software|Microsoft|Windows NT|CurrentVersion|Winlogon|AllocateCDRoms). Zabezpieczenie C2 wymaga dołączenia specyfikacji dotyczącej wykluczenia wymiennych dysków z dostępu do sieci. Ta i następna opcja określają właśnie te wymagania. Jeseli korzystasz z C2, powinieneś zaznaczyć tę opcję dla dysków Jaz, Zip i CD-R.

Ogranicz dostęp do stacji dyskietek tylko do usytkownika zalogowanego lokalnie (HKLM|Software|Microsoft|Windows NT|CurrentVersion|Winlogon|AllocateFloppies). Opis identyczny jak wysej.

Wyślij nie zaszyfrowane hasło w celu nawiązania połączenia z innymi serwerami SMB (HKLM|System|CurrentControlSet|Control|Lsa|LmCompatibilityLevel). Klienci Windows 9x i 3.1x, którzy chcą połączyć się z serwerem Windows 2000, korzystają z systemu NTLM Challenge-Response, lecz nie usywają algorytmu MD4 do szyfro­wania informacji. Zamiast tego usywają starszego algorytmu szyfrowania DES, który niestety dopuszcza wędrowanie niezaszyfrowanego hasła poprzez kable sieciowe. Mosesz uniemosliwić korzystanie z tej procedury za pomocą opcji wysyłania nie zaszyfrowanego hasła, w celu połączenia się z innymi serwrami SMB, ale tylko wtedy, gdy wTwojej sieci nie znajdują się jus sadni klienci nisszych poziomów Windows.

Ładowanie
niestandardowych szablonów zabezpieczeń

Ustawienia zabezpieczeń w SECEDIT.SDB są inicjalizowane przez plik szablonu. Szablony są usywane do wstępnej konfiguracji systemu i są przechowywane w katalogu WINNTINF. Dodatkowe szablony są przechowywane w katalogu WINNTINFTem­plates. Istnieje mosliwość modyfikacji i tworzenia całkiem nowych szablonów oraz ładowania ich do SECEDIT.SDB za pomocą przystawki Security Templates (Szablony zabezpieczeń).

Za pomocą szablonów mosesz równies analizować istniejącą konfigurację zabezpieczeń, sprawdzając w ten sposób, czy aktualnie nie ma sadnych problemów z zabezpieczeniem. Jest to mosliwe za pomocą przystawki Security Configuration i Analysis (Analiza i konfiguracja zabezpieczeń).

W tej części rozdziału omówione będzie wykorzystanie obu przystawek. Najpierw zajmiemy się modyfikacją istniejącego, a potem całkiem nowego szablonu, który zostanie dodany do bazy danych zabezpieczeń. Czynności te będą znaczące tylko wtedy, gdy posiadasz wolnostojący serwer albo stację roboczą. Komputer członka domeny powinien być zarządzany za pomocą zasad grup.

Procedura 6.14.

Konfiguracja szablonów zabezpieczeń.

1. Otwórz pustą konsolę MMC wpisując polecenie mmc w oknie Run (Uruchom).

2. Z menu konsoli wybierz Console (Konsola)|Add/Remove Snap-in (Dodaj/Usuń przystawki). Wyświetlone zostanie okno Add/Remove Snap-in (Dodaj/Usuń przystawki).

3. Kliknij Add (Dodaj). Pojawi się okno Add Standalone Snap-in (Dodaj przystawkę wolnostjącą).

4. Zaznacz dwa szablony: Security Configuration and Analysis (Analiza i konfiguracja zabezpieczeń) oraz Security Templates (Szablony zabezpieczeń).

5. Zamknij okno i powróć do Add/Remove Snap-in (Dodaj/Usuń przystawki). Dwie przystawki pojawią się na liście.

6. Kliknij OK, aby zapisać zmiany i powrócić do konsoli MMC.

7. Kliknij Console (Konsola)|Save As (Zapisz jako) i zapisz konsolę pod opisową nazwą, np. SECCONF.MSC.

8. Rozwiń drzewo dla dwóch przystawek. W gałęzi Security Templates (Szablony zabezpieczeń) widoczne będą wszystkie pliki z katalogu WINNTINFTemplates. Przystawka Security Configuration and Analysis (Analiza i konfiguracja zabezpieczeń) będzie natomiast wyświetlać instrukcję wykonania analizy konfiguracji zabezpieczeń — rysunek 6.12.

9. Rozwiń drzewo w gałęzi jednego szablonu i sprawdź ustawienia zasad konta i zasad lokalnych. Kasdy pakiet szablonu posiada zbiór opcji zasad zaprojektowany w celu ułatwienia konfiguracji zabezpieczeń.

10. Aby zmodyfikować istniejący szablon, rozwiń drzewo pod daną ikoną szablonu i zmodyfikuj ustawienia.

11. Aby utworzyć nowy szablon, kliknij prawym przyciskiem myszy na gałęzi szablonu i z wyświetlonego menu wybierz polecenie New Template (Nowy szablon). Pojawi się okno udostępniające pola na określenie nazwy szablonu i jego opisu. Wpisz stosowne informacje i kliknij OK. Szablon zostanie dodany do listy. Mosesz go teraz skonfigurować w oparciu o swoje preferencje.

Po właściwym skonfigurowaniu ustawień szablonu, nalesy wprowadzić go do systemu poprzez umieszczenie w bazie danych zabezpieczeń. W tym celu wykonaj ponisszą instrukcję:

Procedura 6.15.

Implementacja niestandardowego szablonu zabezpieczeń

1. Otwórz edytor Group Policy (Zasady grup) — GPEDIT.MSC.

2. Rozwiń drzewo do ikony Security Settings (Ustawienia zabezpieczeń).

3. Kliknij prawym przyciskiem myszy ikonę, a następnie z wyświetlonego menu wybierz polecenie Import Policy (Importuj zasadę). Pojawi się okno Import Policy From (Importuj zasadę z).

4. Kliknij dwukrotnie nazwę wybranego szablonu, aby załadować go do bazy danych.

5. Sprawdź, czy ustawienia lokalne odpowiadają opcjom zaznaczonym w konsoli Template Settings (Ustawienia szablonu).

6. Zamknij edytor Group Policy (Zasady grup).

Jeseli komputer jest członkiem domeny, to ustawienia zastosowane w lokalnej bazie danych nie nadpiszą zasad grup pobranych z domeny. Jeseli chcesz sprawdzić aktualne ustawienia zabezpieczeń dla komputera, mosesz przeprowadzić analizę za pomocą kopii bazy danych zabezpieczeń — SECEDIT.SDB. Baza danych jest zablokowana, gdy system wykonuje operacje, dlatego tes konieczne jest utworzenie kopii bazy. Kopia mose posiadać dowolną nazwę i mose pozostać w tym samym katalogu WINNTSecurity.

Procedura 6.16.

Przeprowadzanie analizy zabezpieczeń

1. Załaduj niestandardową konsolę zawierającą przystawkę Security Configuration and Analysis (Analiza i konfiguracja zabezpieczeń).

2. Prawym przyciskiem myszy kliknij ikonę przystawki, a następnie z wyświetlonego menu wybierz polecenie Open Database (Otwórz bazę danych). Wyświetlone zostanie okno Open Database (Otwórz bazę danych).

3. Przejdź do folderu WINNTSecurityDatabase i załaduj kopię bazy SECEDIT.SDB. Jeseli spróbujesz bezpośrednio załadować plik SECEDIT.SDB, wyświetlony zostanie komunikat błędu Access Denied (Odmowa dostępu).

4. Po załadowaniu bazy danych kliknij prawym przyciskiem myszy na ikonie Security Configuration and Analysis (Analiza i konfiguracja zabezpieczeń), a następnie z wyświetlonego menu wybierz polecenie Analyze Computer Now (Analizuj komputer teraz). Pojawi się okno Perform Analysis (Przeprowadzanie analizy) przedstawiające ścieskę dostępu do dziennika. Domyślna ścieska prowadzi do katalogu Temp w lokalnym profilu usytkownika.

5. Kliknij OK. Analiza zostanie rozpoczęta. Pojawi się okno przedstawiające wykres postępu analizy. Jeseli konfiguracja komputera nie posiada bardzo złosonej listy plików i wpisów rejestrów, czynność ta nie powinna zająć zbyt duso czasu.

6. Po zakończeniu analizy rozwiń drzewo w gałęzi Security Configuration and Analysis (Analiza i konfiguracja zabezpieczeń). Zobaczysz standardowy zbiór zasad i ikon ustawień zabezpieczeń. Gdy zaznaczysz wybraną zasadę, w prawym panelu wyświetlone zostanie porównanie biesących ustawień komputera z ustawieniami pobranymi z bazy danych SECEDIT — rysunek 6.13. Wszystkie rósnice w ustawieniach dotyczą zasad grup, które zostały pobrane z domeny.

7. Przejrzyj dokładnie rezultat analizy i zdecyduj w jaki sposób rozwiązać rozbiesności ustawień. Najlepszym rozwiązaniem dla członka domeny jest modyfikacja zasad grupy. Dla wolnostojącego serwera, jeseli zawartość bazy danych jest poprawna, mosesz kliknąć prawym przyciskiem myszy ikonę Security Configuration and Analysis (Analiza i konfiguracja zabezpieczeń) i wybrać polecenie Configure Computer Now (Konfiguruj komputer teraz). Spowoduje to nadpisanie wszystkich lokalnych zasad konfiguracji przez zawartość bazy danych.

8. Aby wykonać odwrotną operację i aktualizować bazę danych zawartością istniejącego szablonu, prawym przyciskiem myszy kliknij ikonę Security Configuration and Analysis (Analiza i konfiguracja zabezpieczeń) i wybierz polecenie Import Template (Importuj szablon). Następnie zaznacz na liście właściwy szablon i kliknij OK.

Konfiguracja drugiego logowania

Administratorzy systemu UNIX bardzo często wyśmiewają, być mose słusznie, niedogodności narzędzi administracyjnych w Windows 2000 i NT. Jeseli chcesz korzystać z grep, awk i innych równie dziwnie brzmiących narzędzi, skorzystaj z pakietu Services for UNIX. Zanim jednak zaczniesz poszukiwać dodatkowych narzędzi, rzuć okiem na kilka aplikacji udostępnionych w Windows 2000.

Jednym z problemów zabezpieczeń w Windows 2000/NT jest fakt, se administrator spędza zbyt wiele czasu w sieci będąc zalogowanym z wszystkimi uprawnieniami administratora. Mose być to przyczyną zrodzenia się rósnego rodzaju problemów. Administrator musi równies posiadać mosliwość logowania w standardowym systemie uprawnień z mosliwością szybkiego dostępu do określonych funkcji.

Wyobraź sobie sytuację, w której siedzisz przed komputerem usytkownika i musisz nagle wykonać kilka diagnostycznych czynności albo zainstalować jakieś oprogramowanie. Usytkownik nie posiada praw administratora, a Ty nie chcesz logować się do stacji ze swoim identyfikatorem, gdys nie chcesz zmienić profilu.

W takiej sytuacji potrzebujesz szybkiego dostępu do praw administracyjnych bez konieczności uprzedniego wylogowania. Właśnie w tym celu Windows 2000 udostępnił usługę Secondary Logon Service (Usługa drugiego logowania) — SECLOGON. Usługa pozwala na uruchomienie procesu w kontekście administratora. Usługa SECLOGON jest automatycznie uruchamiana podczas logowania.

Aby uruchomić SECLOGON, usyj polecenia runas. Składnia polecenia jest następująca:

runas /user:<nazwa komputera albo domeny>nazwa_usytkownika nazwa_aplikacji

Dla przykładu spróbuj zalogować się do stacji roboczej Windows 2000 jako standardowy usytkownik bez praw administracyjnych. W tym celu otwórz wiersz poleceń i wykonaj polecenie Time. Zauwasysz, se zmiana czasu będzie niemosliwa, gdys zwykły usytkownik nie mose zmienić czasu systemowego. Wykonaj zatem następujące polecenie (nazwą domeny jest company):

runas /user:companyadministrator cmd

Zostaniesz zapytany o hasło administratora — wprowadź je. Sesja poleceń zostanie w tym momencie uruchomiona z kontekście administratora. Mosesz to sprawdzić patrząc na pasek tytułowy aplikacji. Kasda aplikacja uruchomiona w tej sesji usywa setonu dostępu i uprawnień systemowych administratora. Teraz mosesz ponownie spróbować zmienić czas systemowy. Efekt zostanie zakończony powodzeniem.

Za pomocą polecenia runas mosesz takse otworzyć przystawki MMC na komputerze usytkownika. Na przykład, jeseli chcesz załadować konsolę Computer Management (Zarządzanie komputerem), usyj następującej składni, aby uruchomić konsolę w kontekście administratora:

runas /user:companyadministrator „mmc c:winntsystem32compmgmt.msc”

Po wykonaniu wszystkich czynności administracyjnych, nie zapomnij o zamknięciu wszystkich programów i sesji uruchomionych za pomocą polecenia runas. Nie mosesz przecies pozostawić otwartych drzwi do systemu.