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.