plik

Ochrona kont
użytkownika w systemie
Windows NT

Konta użytkownika
Własności kont użytkownika. Rola
kont w procesie udostępniania zasobów
systemu.

Weryfikacja użytkownika

Problemy ochrony na poziomie użyt-

kownika. Podstawowe wiadomości
o weryfikacji

Konta użytkowników są mechanizmem, który
umożliwia weryfikację osób rejestrujących się
w systemie oraz przyznawanie lub odbieranie
uprawnień dostępu do zasobów, takich jak wy-
dzielone do wspólnego użytku katalogi plików
lub drukarki.

Rozdział, który zaczynamy, omawia konta
użytkowników i związane z nimi parametry,
w szczególności identyfikatory SID. Zoba-
czymy, jak jest weryfikowana tożsamość
użytkownika oraz przyznane mu uprawnie-
nia. Przeanalizujemy najczęstsze problemy
związane z kontami oraz dowiemy się, jak je
rozwiązywać.

Na początek dokonamy przeglądu
podstawowych własności kont oraz
omówimy, w

jaki sposób Windows NT

umożliwia dostęp do systemu oraz
dostępnych w sieci zasobów.

użytkownika w

chwili rejestracji

w systemie.

Rejestracja w systemie jako proces
sprawdzania tożsamości i weryfikacji
uprawnień.
Szczegóły procesu rejestracji
w

systemie. Sprawdzanie tożsamości

użytkownika. Weryfikacja uprawnień.

Dostęp do zasobów

Procesy zachodzące w

systemie

podczas odległej rejestracji

w systemie.

Problemy związane z kontami

Przegląd najczęściej spotykanych

problemów związanych z kontami oraz
rejestracją w systemie.

Część II Implementacja systemu ochrony Microsoft Windows NT

162

Konta użytkownika w systemie operacyjnym Windows NT

Windows NT wykorzystuje konta użytkowników do identyfikacji osób
żądających dostępu do zasobów sieciowych. Zanim ktokolwiek zostanie
dopuszczony przez system do korzystania z sieci, musi przejść weryfika-
cję uprawnień dostępu do systemu lub domeny. Za tę sferę pracy syste-
mu odpowiada proces weryfikacji konta i związanego z nim hasła. Win-
dows NT traktuje nazwę konta i skojarzone z nim hasło jako tajne infor-
macje o podstawowym znaczeniu dla bezpieczeństwa. Przechowuje je
w specjalnej bazie chronionych kont (SAM - Security Account Database).
Identyfikacja polega na porównaniu danych wprowadzonych przez
użytkownika z odpowiednimi elementami bazy SAM. W zależności od
wyniku procesu, użytkownik otrzymuje prawo korzystania z sieci lub
nie. Jeśli dostęp jest zabroniony, to na serwerze lub stacji roboczej NT
w ogóle nie pojawi się graficzny interfejs systemu. Na stacjach roboczych
pracujących pod kontrolą WfW lub Windows 3.1x interfejs użytkownika
będzie w pełni operatywny, ale użytkownik nie będzie miał dostępu do
żadnych zasobów sieciowych w domenach, będących pod kontrolą sys-
temu ochrony Windows NT.

Informacje, dotyczące kont użytkowników, grup oraz komputerów, są
regularnie aktualizowane poprzez kopiowanie z głównego kontrolera
domeny na kontrolery zapasowe. Dzięki temu, rejestracja w sieci może
odbywać się zarówno za pośrednictwem głównego, jak i dowolnego spo-
śród zapasowych kontrolerów domeny. Pomyślny przebieg procesu we-
ryfikacji daje użytkownikowi dostęp do zasobów sieci, zgodnie
z przynależnymi jego kontu prawami i uprawnieniami dostępu.

Ochrona na poziomie kont a zabezpieczenia na poziomie zasobów
współdzielonych

Omówiony wyżej sposób ochrony zasobów nosi nazwę zabezpieczenia
na poziomie użytkownika (user level security) i opiera się na jednorazowej
rejestracji w systemie (oczywiście pod warunkiem poprawnego wprowa-
dzenia danych).

Innym możliwym rozwiązaniem są zabezpieczenia na poziomie zasobów
współdzielonych (share level security), które polegają na przyporządko-
waniu każdemu zbiorowi wspólnemu odrębnego hasła. Ten poziom za-
bezpieczeń wymaga pamiętania wielu haseł. Jest często stosowany
w

sieciach peer-to-peer (każdy z

każdym), na przykład opartych

o Windows 95 lub WfW 3.1x. Umożliwia wydzielenie zasobów wspól-
nych i udostępnienie ich innym użytkownikom, z hasłami uprawniają-

Ochrona kont użytkownika w systemie Windows NT

163

cymi do pełnego dostępu (full-access) lub w trybie tylko do odczytu (read
only). Każdy wydzielony zbiór wymaga odrębnych haseł, co czyni system
niewygodnym, ze względu na konieczność ich zapamiętania. Zaletą
ochrony na poziomie zasobów jest prostota konfiguracji. Wadami zaś:
niski poziom ochrony, związany z używaniem tego samego hasła przez
kilka osób i ograniczona liczba wariantów ochrony. Zazwyczaj systemy,
implementujące zabezpieczenia na poziomie zasobów, nie są wyposażo-
ne w możliwość monitorowania dostępu.

Windows NT wykorzystuje system ochrony na poziomie użytkownika,
który jest subtelniejszym sposobem sterowania dostępem do zasobów.
Umożliwia administratorowi kontrolę korzystania przez użytkowników
ze wszystkich usług dostępnych w sieci. Użytkownik musi pamiętać tyl-
ko nazwę swojego konta oraz hasło. Aby uzyskać dostęp do wszystkich
przysługujących mu usług, wprowadza swoje dane tylko jeden raz.

Ochrona na poziomie użytkownika opiera się na kontroli zgodności na-
zwy konta z odpowiadającym mu hasłem. Obie potrzebne systemowi
informacje przechowywane są w specjalnej bazie danych SAM. W tej
samej bazie składowane są jeszcze nazwy wszystkich grup, do których
należy użytkownik, dodatkowe informacje wykorzystywane w procesie
rejestracji, takie jak katalog prywatny i adres do skryptu rejestracyjnego,
oraz lista ograniczeń nałożonych na konto.

Rodzaje kont użytkownika

Konta użytkownika mogą zostać zdefiniowane jako globalne (domyślne
ustawienie systemu) lub jako lokalne. Konto globalne umożliwiają użyt-
kownikowi interaktywną rejestracje w systemie i podejmowanie wszyst-
kich uprawnionych działań. Konta lokalne nie może być wykorzystywa-
ne do rejestracji interaktywnej. Zamiast tego umożliwia, kontom użyt-
kowników z domen, które nie są upoważnione, dostęp do zasobów do-
meny lokalnej. Równocześnie ogranicza ono użytkownikowi możliwość
rejestrowania się interaktywnie w domenie lokalnej. Po za tym konto
lokalne nie może być wykorzystywane, w przeciwieństwie do konta glo-
balnego, w relacjach upoważnienia.

Predefiniowane konta użytkowników

Podczas instalacji Windows NT Server lub Workstation tworzone są au-
tomatycznie dwa konta użytkowników. Pierwsze to konto administratora
(Administrator), drugie - gościa (Guest). Jeśli instalujemy główny kontroler
domeny, utworzone konta są kontami domeny, składowanymi w bazie
danych domeny (SAM). Podczas instalacji serwera samodzielnego lub

Część II Implementacja systemu ochrony Microsoft Windows NT

164

stacji roboczej, utworzone konta stają się elementami lokalnej bazy da-
nych SAM.

Konto administratora

Konto służy do zarządzania systemem po zainstalowaniu. Jest jedynym
kontem, które umożliwia jego właścicielowi natychmiastową rejestrację
w systemie i podejmowanie wszystkich czynności związanych z zarzą-
dzaniem głównym kontrolerem domeny, samodzielnym serwerem lub
stacją robocza (z wyjątkiem stacji roboczych podłączanych w czasie reje-
stracji do istniejącej domeny) Konto administratora jest automatycznie
elementem lokalnej grupy administratorów. Nie może być usunięte, mo-
dyfikowane, wyłączone ani przeniesione z lokalnej grupy administrato-
rów. Po zarejestrowaniu się na koncie administratora możemy tworzyć
inne konta i umieszczać je w lokalnej grupie administratorów, ale nie
możemy utworzyć innego konta administratora. Pozostali członkowie
grupy będą mieli wszystkie uprawnienia konta administratora i będą
zdolni wykonywać każde związane z tym zadanie. Jedyna różnica polega
na możliwości usunięcia z grupy wszystkich kont, z wyjątkiem admini-
stratora.

Wskazówka

Dla podniesienia bezpieczeństwa można zmienić nazwę konta administratora,
ukrywając w ten sposób jego znaczenie w systemie.

Konto administratora jest automatycznie wyposażone we wszystkie
uprawnienia, pozwalające wykonywać zadania administracyjne na
wszystkich kontrolerach domeny, stacjach roboczych i samodzielnych
serwerach należących do domeny lub domen upoważniających. Podczas
instalacji głównego kontrolera domeny, samodzielnego serwera lub stacji
roboczej, program instalacyjny Windows NT żąda wprowadzenia hasła,
aby zainicjować konto administratora. Hasło należy wykorzystać do
pierwszej rejestracji w systemie. Hasło może być zmieniane w dowolnym
momencie.

Wskazówka

Należy utworzyć przynajmniej jeszcze jedno konto, które będzie elementem
lokalnej grupy administratorów. Do wykonywania codziennych obowiązków
związanych z zarządzaniem systemem, należy korzystać właśnie z tego konta.
Oryginalne konto administratora powinno służyć do rejestracji w systemie
w sytuacjach awaryjnych. Monitorowanie aktywności administratorów jest
łatwiejsze, jeśli każdy wykonuje swoje zadania z własnego konta.

Ochrona kont użytkownika w systemie Windows NT

165

Podczas instalowania zapasowego kontrolera domeny zostaniemy we-
zwani do wprowadzenia hasła administratora. W odpowiedzi możemy
wpisać nazwę konta i hasło dowolnego członka lokalnej grupy admini-
stratorów.

Konto gościa

Konto gościa zostało zaprojektowane, aby umożliwić dostęp do zasobów,
nie wymagających ochrony, osobom, które nie mają własnego konta
w systemie. Mogą z niego również korzystać użytkownicy, którym wyłą-
czono ich własne konto w systemie. Należy jednak pamiętać, że jeśli kon-
to gościa jest aktywne (domyślnie konto jest wyłączone), to można z nim
robić wszystko to, co z normalnymi kontami. Można mu udzielać wszel-
kich uprawnień dostępu i dokładać je do dowolnych grup, nawet do lo-
kalnej grupy administratorów. Ponieważ konto gościa nie wymaga hasła,
to decydując się na jego wykorzystanie trzeba zachować ostrożność. Kon-
to jest elementem globalnej grupy Domain Guests, która z kolei jest ele-
mentem lokalnej grupy Guest.

Aby zarejestrować się w systemie na koncie gościa, można wykorzystać
dwa sposoby. Pierwszy polega na rejestracji lokalnej (local guest logon),
stosowanej przez osoby włączające się do systemu za pośrednictwem
okna dialogowego Logon Information Windows NT Workstation lub
Server. Pozwala to gościowi pracować interaktywnie na stacji roboczej
lub samodzielnym serwerze. Kontu gościa nie przysługuje prawo reje-
stracji lokalnej na kontrolerach domeny, co zabezpiecza je przed interak-
tywnym dostępem dla użytkowników rzadko korzystających z systemu.

Drugi sposób polega na sieciowej rejestracji z konta gościa (network guest
logon). Działając interaktywnie na koncie domeny lub koncie lokalnego
komputera można wykorzystać konto gościa (jeśli jest dostępne) do połą-
czenia z innym komputerem, wykorzystującym konto gościa. Aby sesja
mogła dojść do skutku, konto gościa docelowego komputera musi być
aktywne i pozostawać bez ochrony hasłem. W taki sposób można zareje-
strować się na każdym z następujących komputerów:

Kontroler domeny Windows NT Server

Windows NT Server będący elementem domeny

Windows NT Workstation (bez względu czy jest elementem domeny,
czy grupy roboczej)

Komputer LAN Manager version 2.x client

Jeśli połączenie zostanie zrealizowane, użytkownik zarejestrowany jako
gość, będzie miał wszystkie przywileje wynikające z praw, uprawnień
dostępu oraz przynależności grupowej, przyznanych kontu gościa doce-
lowego komputera. Zapamiętajmy ten punkt, aby ponownie go przemy-

Część II Implementacja systemu ochrony Microsoft Windows NT

166

śleć przy analizie algorytmów dostępu przedstawionych w dalszej części
rozdziału.

Przy użyciu programu User Manager for Domains można wyłączyć moż-
liwość rejestracji z wykorzystaniem jednego lub obu wyżej przedstawio-
nych sposobów. Jeśli na przykład postanowimy pozostawić użytkowni-
kom okazjonalnym prawo do lokalnej rejestracji na stacji roboczej (lub
samodzielnym serwerze), bez możliwości rejestracji poprzez sieć, może-
my postąpić według następującego algorytmu:

1. Otworzyć User Manager for Domains i dwukrotnie kliknąć na pozycji

konta gościa, co spowoduje otwarcie się okna User Properties (własno-
ści konta użytkownika)

2. Sprawdzić, czy jest zaznaczone pole wyboru opisane Account Disabled

(konto nieaktywne). Jeśli tak, to kliknąć na polu, by je oczyścić. Wci-
snąć przycisk OK, aby powrócić do głównego okna programu.

3. Wybrać z listy rozwijalnej Policies pozycję User Rights, aby otworzyć

okno dialogowe User Right Policy (reguły określające prawa użytkow-
nika). Wyświetlaną domyślnie pozycją w oknie listy rozwijalnej Right
powinna być Access this computer from the network (komputer jest do-
stępny poprzez sieć. Jeśli nie, należy wybrać tę pozycję z listy.

Jak łatwo zauważyć, patrząc na okno Grant To, prawo „komputer jest
dostępny poprzez sieć” przyznane jest kontu administratora oraz grupie
Everyone. Warto odnotować, że grupa Everyone nie widnieje na liście
grup, wyświetlanej na stronie Groups programu User Manager for Doma-
ins, gdyż jest ukrytą, predefiniowaną grupą stworzoną dla potrzeb sys-
temu i nie może być modyfikowana. Przy domyślnych ustawieniach gru-
pa Everyone zawiera wszystkie konta użytkowników, z kontem gościa
włącznie. Aby uniemożliwić zdalną rejestrację na komputerze poprzez
konto gościa, musimy pozbawić je prawa Access this computer from the
network. Konto dziedziczy uprawnienie dzięki przynależności do grupy
Everyone. Aby osiągnąć założony cel, należy najpierw zabrać uprawnie-
nie grupie Everyone, a następnie, aby pozostawić użytkownikom możli-
wość zdalnej rejestracji na komputerze, przyznać je lokalnej grupie Users
Group. Oto spis niezbędnych działań:

4. Zaznaczyć pozycję Everyone na liście znajdującej się w oknie Grant To

i kliknąć na przycisku Remove.

5. Wcisnąć przycisk Add, aby otworzyć okno Add Users and Groups (do-

dawanie użytkowników i grup). Upewnić się, że w polu listy wyboru
List Name From

znajduje się nazwa domeny lokalnej. Jeśli nie, wybrać

nazwę właściwej domeny.

Ochrona kont użytkownika w systemie Windows NT

167

6. Przewinąć zawartość okna Name i zaznaczyć pozycję lokalnej grupy

Users

opisanej jako Ordinary users. Wcisnąć przycisk Add. Nazwa lo-

kalnej grupy użytkowników: nazwa_domeny\Users powinna pojawić
się w oknie dialogowym na liście Add Names.

7. Wcisnąć przycisk OK, aby powrócić do okna User Rights Policy.

W oknie Grant To powinna widnieć pozycja Users. Wcisnąć przycisk
OK

, by powrócić do głównego okna programu.

Od tego momentu, każdy użytkownik korzystający z konta gościa,
próbujący zarejestrować się zdalnie na komputerze, zobaczy komunikat
przedstawiony na rysunku 6.1.

Rysunek 6.1

Zdalny dostęp do komputera
jest zabroniony dla konta
gościa.

Przeanalizujemy teraz przykład odwrotny. Poniższe czynności ustana-
wiają konfigurację, w której użytkownik, korzystający z konta gościa,
może rejestrować się na komputerze wyłącznie poprzez sieć:

1. Otworzyć User Manager for Domains i dwukrotnie kliknąć na pozycji

konta gościa, co spowoduje otwarcie się okna User Properties (własno-
ści konta użytkownika)

2. Sprawdzić, czy jest zaznaczone pole wyboru opisane Account Disabled

(konto nieaktywne). Jeśli tak, to kliknąć na polu, by je oczyścić. Wci-
snąć przycisk OK aby powrócić do głównego okna programu.

3. Wybrać z listy rozwijalnej Policies pozycję User Rights, aby otworzyć

okno dialogowe User Right Policy (reguły określające prawa użytkow-
nika).

4. W oknie listy rozwijalnej Right powinna być wyświetlana domyślnie

pozycja: Access this computer from the network (komputer jest dostępny
poprzez sieć). Jeśli nie, należy wybrać pozycję z listy. W oknie Grant
To powinna znajdować się przynajmniej jedna spośród następujących
pozycji: Everyone, lokalna grupa Guest, golabna grupa Guest lub konto
Guest

Jeśli wymaganych pozycji nie ma na liście, należy dodać grupę Everyone
lub lokalną grupę Guest. W tym celu wcisnąć przycisk Add i wybrać na-
zwę odpowiedniej grupy w oknie Add Users and Groups. Wybór grupy
Everyone umożliwia wszystkim użytkownikom zdalny dostęp do kom-

Część II Implementacja systemu ochrony Microsoft Windows NT

168

putera. Jeśli dostęp komputera poprzez sieć chcemy ograniczyć do wy-
branych grup, to pozycja Everyone powinna pozostać pozbawiona tego
prawa.

5. Wybrać pozycję Log on locally z listy rozwijalnej Right. W oknie Grant

nie powinna znajdować się nazwa żadnego konta z następującej li-

sty: lokalne konto Guest, konto lokalnej grupy Guest, konto globalnej
grupy Guest. Jeśli nazwa dowolnego z wymienionych kont widnieje
w oknie, to należy ją usunąć przy użyciu przycisku Remove.

6. Wcisnąć przycisk OK, aby powrócić do głównego okna User Manager

for Domains

Przy domyślnej konfiguracji systemu Windows NT Server, prawo do
lokalnej rejestracji mają wyłącznie konta administratorów, a grupa
Everyone wyposażona jest w uprawnienie dostępu poprzez sieć. Aby
umożliwić kontu gościa zdalną rejestrację, wystarczy uaktywnić konto
gościa, które domyślnie jest wyłączone. (Z punktu widzenia bezpieczeń-
stwa systemu najlepiej pozostawić konto gościa nieaktywnym).

Po przeglądzie podstawowych wiadomości związanych z kontami, przy-
szła pora na procesy identyfikacji użytkownika i weryfikacji uprawnień
dostępu. Zaczniemy od struktury identyfikatora systemu bezpieczeństwa
(SID), który jest wykorzystywany jako dowód osobisty konta.

Budowa identyfikatorów systemu bezpieczeństwa (SID)

Z każdym kontem czy to indywidualnym, czy komputerów lub grup
skojarzony jest unikatowy numer identyfikacyjny systemu ochrony (SID-
Security IDentificaton number). SID jest generowany podczas tworzenia
konta i jednoznacznie je identyfikuje przez cały czas istnienia. System
wykorzystuje ten statystycznie unikatowy numer przy sterowaniu dostę-
pem użytkowników do wszystkich zasobów, do których mają uprawnie-
nia. Teoretycznie ten sam numer nie powinien być nigdy przyznany in-
nemu kontu. Powstaje jako wynik działania algorytmu przemieszczania
(hashing algoritm), opartego o drzewo liczb 32 bitowych pochodzących z:

Nazwy komputera.

Aktualnego czasu systemowego na komputerze.

Czasu wykonywania bieżącego wątku trybu użytkownika (wykorzy-
stywanego do tworzenia SID).

Format numeru SID można podejrzeć przy pomocy edytora rejestrów
Windows NT. Podczas rejestrowania się użytkownika w sysyemie Win-
dows NT Workstation lub Server tworzony jest profil użytkownika zwią-
zany z kontem. Profil zawiera informacje o obszarze roboczym użytkow-

Ochrona kont użytkownika w systemie Windows NT

169

nika i indywidualnych ustawieniach. System przechowuje informacje
o profilu w zbiorach typu hive. Pliki położone są w rejestrach i oznaczone
numerami indywidualnych kont. Aby zobaczyć listę numerów SID opisu-
jących profile użytkownika, należy otworzyć następującą pozycję reje-
stru:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\

CurrentVer-

sion\ProfileList

Rysunek 6.2 ilustruje profile utworzone na kontrolerze domeny SHARES
o nazwie BEPPO, wykorzystywanym w poprzednich przykładach.

Rysunek 6.2

Pliki zawierające profile
użytkownika opisane są
unikatowymi numerami SID.

Dwa numery SID, które można zobaczyć na rysunku są bardzo podobne.
Trzeci składa się z zupełnie odmiennych fragmentów. Przyczyną różnicy
jest pochodzenie konta. Odmienny numer SID jest przyporządkowany
kontu z upoważnionej domeny ADMIN. Ponieważ konto zostało założo-
ne na innej domenie, fragment numeru opisuje przynależność konta do
tej domeny.

Rysunek 6.3 ilustruje pozycję:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\hiveList

Pozycja przechowuje systemowe pliki hive, które są również opisane
numerem SID. Rysunek ilustruje numer SID wraz z opisem struktury
danych.

Część II Implementacja systemu ochrony Microsoft Windows NT

170

Rysunek 6.3

Komponenty
numeru SID.

Identyfikatory kont indywidualnych oraz grup są zapisane w specjalnej
strukturze danych o nazwie Security Descriptor (SD). Deskryptory są
wykorzystywane do zapisywania kont, którym przyznano uprawnienie
dostępu do obiektu. Uprawnienia dostępu przyznane użytkownikowi są
przyporządkowane jego numerowi SID.

Odtworzenie usuniętego konta z tą samą nazwą i hasłem nie odtwarza
automatycznie uprawnień dostępu. Podczas ponownego zakładania kon-
ta powstaje nowy numer SID. Żaden z deskryptorów przechowujących
poprzedni SID nie będzie zawierał nowego numeru identyfikacyjnego.
Z tego powodu strukturę uprawnień raz usuniętego konta trzeba odtwa-
rzać od nowa.

Przebieg procesu weryfikacji

Zanim użytkownik zobaczy interfejs graficzny Windows NT Workstation
lub Server musi przejść procedurę rejestracyjną, która polega na wpro-
wadzeniu nazwy konta oraz związanego z nią hasła. Dane wpisane przez
użytkownika są weryfikowane przez system. Jeśli sprawdzenie skończy
się pozytywnie, na komputerze pojawi się znajomy pulpit Windows
i będzie można korzystać ze wszystkich usług komputera i sieci, przyna-
leżnych użytkownikowi. Wybór bazy danych, stosowanej przez system
do weryfikacji użytkownika, zależy od kilku czynników.

Na przykład, jeśli użytkownik podejmuje próbę rejestracji w systemie
Windows NT Server , to nazwa konta i hasło podane przez użytkownika
będą porównywane z bazą danych domeny. Jeśli serwer jest elementem
domeny upoważniającej, to użytkownik otrzymuje opcjonalną możliwość
dodatkowej weryfikacji z bazą danych domeny upoważnionej.

Użytkownik, rejestrujący się na komputerze w systemie Windows NT
Workstation, nie będącym elementem domeny, weryfikowany jest przy
użyciu lokalnej bazy danych. Jeśli natomiast komputer jest elementem

Ochrona kont użytkownika w systemie Windows NT

171

domeny, to użytkownik ma do wyboru opcje rejestracji poprzez lokalną
bazę danych, bazę danych domeny, do której należy komputer, lub po-
przez bazę dowolnej domeny upoważnionej przez domenę macierzystą.

Dokładniej, użytkownik pracujący na stacji w systemie Windows NT
Workstation, będącej elementem domeny, może się zarejestrować, wyko-
rzystując tę samą nazwę konta i to samo hasło zarówno w lokalnej bazie
danych SAM, jak i w bazie kont domeny. Podczas rejestracji w lokalnej
bazie kont, system potwierdzania uprawnień porównuje dane wprowa-
dzone przez użytkownika z informacjami o kontach lokalnej maszyny.
Podczas rejestracji w domenie, system ochrony przesyła żądanie rejestra-
cji do weryfikacji przez kontroler domeny.

Należy pamiętać, że dwa konta o tej samej nazwie i tym samym haśle
wcale nie są tym samym kontem, gdyż różnią się numerem SID. Prowa-
dzi to czasem do nieporozumień. Użytkownik, który pomyślnie prze-
szedł proces weryfikacji, może być zarejestrowany na innym koncie niż
zamierzał. Uprawnienia dostępu przyznane kontu

ADMIN

\JoeF mogą

być istotnie inne od uprawnień konta

WORKSTATION

\JoeF. Dlatego jeśli

JoeF jest zarejestrowany na stacji lokalnej zamiast w domenie, nie musi
mieć dostępu do niektórych zasobów.

Proces weryfikacji

Windows NT wykorzystuje do weryfikacji tożsamości użytkowników
pakiet weryfikacyjny MSV1_0 zwany LsaLogonUser API. Jest to domyśl-
ny pakiet weryfikacyjny dostarczany razem z Windows NT, który wyko-
rzystuje bazę danych SAM jako składnicę wszystkich informacji związa-
nych z ochroną kont. Układ MSV1_0 wspiera również weryfikację po-
średnią (pass-through authentication) z użyciem usługi

NETLOGON

Service.

Weryfikacja pośrednia oznacza, że Netlogon Service przesyła informacje
rejestracyjne do innego komputera, celem weryfikacji przez jego pakiet
MSV1_0. Następnie układ weryfikacyjny komputera odległego porównu-
je otrzymane informacje z danymi własnej bazy danych SAM.

Pakiet weryfikacyjny MSV1_0 składa się obecnie z dwóch części,
spełniających różne funkcje w procesie potwierdzania uprawnień kont.
Oznaczmy, dla uproszczenia, pierwszą część pakietu literą A, drugą zaś
B. Część A przyjmuje informacje rejestracyjne i jest zawsze uruchamiana
na komputerze, na którym użytkownik podejmuje próbę rejestracji. Część
B jest odpowiedzialna za porównanie danych od użytkownika
z informacjami z bazy danych SAM. Obie części pakietu nie muszą być
uruchamiane na tych samych maszynach.

Część II Implementacja systemu ochrony Microsoft Windows NT

172

Jeśli użytkownik rejestruje się na stacji roboczej, która nie jest elementem
domeny, cała operacja odbywa się na tym samym komputerze. Inaczej
przebiega scenariusz rejestracji odległej. Jeśli użytkownik rejestruje się na
stacji roboczej, która jest elementem domeny, to może wybrać opcję reje-
stracji w domenie. W takiej sytuacji część A pakietu stacji lokalnej odbiera
dane użytkownika i przesyła je do weryfikacji przez część B pakietu kon-
trolera domeny.

Hasła

Każde konto użytkownika posiada dwa hasła, które są składowane ra-
zem z pozostałymi informacjami dotyczącymi konta w bazie danych
SAM. Pierwsze hasło jest kompatybilne z systemem LAN Manager, dru-
gie jest hasłem Windows NT; oba są podwójnie kodowane. Wynik pierw-
szego kodowania realizowanego przy pomocy metody nazywanej jedno-
drogową funkcją (OWF - one-way function) jest wersją hasła pisanego otwar-
tym tekstem i nie nadaje się do odszyfrowania. Wynik drugiego kodowa-
nia nadaje się do odszyfrowania (co wprawia w podniecenie wszystkich
hakerów). Odszyfrowanie tej wersji hasła wymaga znajomości podwójnie
zakodowanego hasła, względnego identyfikatora użytkownika (Relativ
ID) oraz właściwego algorytmu.

Można się zapytać, jaka jest przyczyna stosowania dwóch haseł? Odpo-
wiedź jest prosta. Pierwsze umożliwia wsteczną kompatybilność ze starą
konwencją, używaną przez LAN Manager 2.x. Konwencja określała, że
w haśle nie rozróżnia się małych i wielkich liter, długość hasła nie może
przekraczać 14 znaków (14 bajtów), a wszystkie znaki muszą być elemen-
tami zbioru OEM (Original Equipment Manufacturer). Przed kodowaniem
wszystkie znaki są zamieniane na wielkie litery, co czyni zadość opisy-
wanej normie.

Hasło dedykowane dla LAN Manager w wersji OWF lub ESTD jest wy-
prowadzane przez kodowanie algorytmem DES (Data Encryption
Standard) przyjętym przez Narodowy Instytut Standaryzacji i Technologii
USA (NITS - National Institute of Standards and Technology). Hasło ma 16
bitów długości i jest wyprowadzane z 14 bitowego, niezaszyfrowanego
tekstu. Pierwsze osiem bitów zaszyfrowanego hasła powstaje
z zakodowania pierwszych siedmiu bitów otwartego tekstu, a ostatnie
osiem z zakodowania drugiej połówki.

Drugie hasło przechowywane w bazie SAM jest określane jako hasło
Windows NT lub Windows NT OWF. W otwartej postaci wykorzystuje
znaki ze zbioru Unicode. W haśle rozróżniane są małe i wielkie litery,
a długość hasła nie może przekraczać 128 znaków. Zakodowana wersja
hasła powstaje przez zastosowanie znanego i popularnego algorytmu,

Ochrona kont użytkownika w systemie Windows NT

173

wykorzystującego klucz publiczny, znanego jako RSA Public - Key
Cipher. Metoda została opracowana w latach siedemdziesiątych, a nazwa
RSA powstała z pierwszych liter nazwisk jej twórców (Ron Rivest, Adi
Shamir i Leonard Adleman). Algorytm służy do kodowania i rozszyfro-
wania danych i jest wykorzystywany między innymi do generowania
i weryfikacji podpisów binarnych. Windows NT stosuje wersję algorytmu
oznaczaną jako RSA MD-4.

Trzy typy procesu rejestracji: interaktywny, usług i sieciowy

Pakiet weryfikacyjny MSV1_0 odbiera informacje rejestracyjne od proce-
dury API LsaLogonUser. Procedura obsługuje wszystkie trzy typy reje-
stracji, przesyłając do pakietu weryfikacyjnego następujące informacje:

Nazwę domeny, z której pochodzi konto.

Nazwę konta użytkownika.

Wartość określoną pewną funkcją hasła użytkownika.

Postać, w jakiej jest reprezentowane hasło, zależy od typu rejestracji.

Rejestracje interaktywne oraz rejestracje usług zachodzą na tej samej ma-
szynie, która uruchamia część A pakietu weryfikacyjnego. Pakiet otrzy-
muje hasło w otwartej postaci i przetwarza je na wersje dedykowane dla
LAN Manager i Windows NT OWF. W tej postaci hasło (a właściwie pa-
ra) jest przesyłane dalej. Możliwe są dwie sytuacje. Jeśli nazwa domeny
różni się od nazwy domeny serwera, to hasło przejmuje usługa Netlogon
Service. Jeśli nazwy obu domen są zgodne, hasło jest przesyłane bezpo-
średnio do części B pakietu weryfikacyjnego. Następnie porównywane są
wersje hasła OWF otrzymane z części A z wersjami OWF przechowywa-
nymi w bazie SAM.

Podczas rejestracji sieciowej do klienta wysyła się 16 bajtowe wezwanie
nazywane tymczasowym (nonce). Odpowiedzi na wezwanie zależą od
o systemu:

LAN Manager: Klient LAN Manager oblicza 24 bajtową odpowiedź na
wezwanie kodując kombinację 16 bajtowego wezwania tymczasowego
z 16 bajtowym hasłem LAN Manager OWF. Odpowiedź na wezwanie
- „LAN Manager Challenge Response” jest przesyłana do serwera
Windows NT.

Windows NT. Klient Windows NT oblicza taką samą odpowiedź jak
klient LAN Manager. Oprócz tego oblicza własną 24 bajtową odpo-
wiedź - „Windows NT Chalange Response” , kodując kombinację 16
bajtowego wezwania tymczasowego i 16 bajtowego hasła Windows
NT OWF. Obie odpowiedzi są wysyłane do serwera Windows NT.

Część II Implementacja systemu ochrony Microsoft Windows NT

174

Program usługowy Netlogon Service przesyła odpowiedzi na wezwanie
do procedury API LsaLogonUser serwera Windows NT, razem
z następującymi informacjami:

Nazwa domeny.

Nazwa użytkownika.

Oryginalne wezwanie.

Wszystkie wymienione informacje są przesyłane do części A pakietu
weryfikacyjnego serwera Windows NT, po czym w nie zmienionej posta-
ci, do części B. Tutaj porównuje się przesłane hasło OWF z hasłem znaj-
dującym się w bazie danych SAM. Odpowiednie odpowiedzi na wezwa-
nie są ponownie obliczane i porównywane z nadesłanymi.

Działanie programu usługowego Netlogon Service

Netlogon Service umożliwia rejestrację pośrednią (pass-through) klien-
tów na serwerach Windows NT, wykonując trzy podstawowe zadania:

Wybiera domenę, do której ma zostać wysłane żądanie weryfikacji.

Wybiera kontroler domeny, któremu ma być dostarczone żądanie
weryfikacji.

Pełni funkcję mechanizmu przenoszącego żądanie rejestracji do wy-
branego serwera.

Usługa jest realizowana w trzech etapach:

1. Wyszukiwania kontrolera domeny docelowej, który zrealizuje zadanie

weryfikacji.

2. Ustanowienia bezpiecznego kanału łączności między komputerem

wysyłającym żądanie, a wybranym kontrolerem domeny. Należy bo-
wiem zapewnić, że oba końce połączenia są tymi komputerami, za
które się podają.

3. Przesłania informacji rejestracyjnych do serwera prowadzącego wery-

fikację.

Proces wyszukiwania

Procesu wyszukiwania docelowej domeny i kontrolera mającego prze-
prowadzić weryfikację jest wywoływany z różnych powodów:

Po pierwsze, kiedy użytkownik dokonuje próby rejestracji na kompute-
rze, nie będącym kontrolerem domeny. Mimo oczywistości tego faktu,
zanim jakiś kontroler zweryfikuje uprawnienia użytkownika, najpierw

Ochrona kont użytkownika w systemie Windows NT

175

musi być odnaleziony. Informacje o zlokalizowanym serwerze zostają
złożone w buforze i są wykorzystywane do kolejnych wywołań kompu-
tera (z bazą danych SAM).

Inną przyczyną uruchomienia procesu wyszukiwania jest próba rejestra-
cji na komputerze, będącym elementem domeny. Wysyła on żądanie
odnalezienia kontrolera domeny, który dokończy weryfikację. Następnie
kontrolery odpowiadają na żądanie, a informacje o odpowiadających
serwerach są buforowane w lokalnym systemie, celem wykorzystania do
niezbędnych wywołań bazy danych SAM. Dane przechowywane
w buforze pozwalają usłudze Netlogon wysyłać bezpośrednie żądania
weryfikacji do właściwego kontrolera domeny.

Ostatnim omawianym powodem uruchomienia procesu wyszukiwania,
może być próba rejestracji inicjowana na kontrolerze domeny, celem zna-
lezienia właściwej domeny upoważnionej oraz nazw jej kontrolerów.
Kontroler posiada informacje o wszystkich pozostałych kontrolerach
własnej domeny, dzięki informacjom przechowywanym w bazie danych
SAM. Nie przechowuje jednak danych o kontrolerach dostępnych na
innych domenach dzięki relacjom upoważnienia. Po wysłaniu zapytania
do domeny upoważnionej, wszystkie dostępne na niej kontrolery odsyła-
ją odpowiedź. Tak jak poprzednio odesłane informacje są buforowane,
aby umożliwić dalszą komunikację z odpowiednią bazą danych SAM.

Rysunek 6.4 ilustruje przykład procesu wyszukiwania.

Przykład wykorzystuje kontroler sieci (Network Monitor) do przechwy-
cenia ruchu wywołanego żądaniem rejestracji użytkownika na kontrole-
rze BEPPO, upoważniającej domeny SHARES. Rejestracja została zwery-
fikowana przez główny kontroler domeny ADMIN o nazwie ZIPPO.
Pierwsza z przechwyconych ramek ilustruje żądanie wysłane przez
BEPPO. Druga ramka przedstawia odpowiedź kontrolera ZIPPO. Ostat-
nie trzy ramki opisują przebieg rejestracji konta między domenami (In-
terdomain trust account).

por. „Połączenia komunikacyjne ustanawiające relacje upoważnienia

Część II Implementacja systemu ochrony Microsoft Windows NT

176

Rysunek 6.4

Proces wyszukiwania obserwowany na kontrolerze domeny upoważniającej

Jeśli kontroler domeny upoważniającej nie otrzyma odpowiedzi na we-
zwanie, ponawia kolejne serie wywołań co 15 minut, aż do pomyślnego
zlokalizowania właściwego kontrolera. Jeśli żądanie weryfikacji upraw-
nień do zasobów ma problemy z dotarciem do odpowiedniego kontrolera
domeny, to kontroler domeny upoważniającej wysyła natychmiast na-
stępne żądanie.

Zestawianie bezpiecznego połączenia komunikacyjnego

Proces lokalizacji odpowiedniego adresata zakończył się pomyślnie. Te-
raz potrzebny jest bezpieczny kanał komunikacji między usługami Ne-
tlogon na stacji roboczej i kontrolerze domeny upoważnionej. Połączenie
będzie wykorzystane do przesłania żądania weryfikacji pakietowi identy-
fikacyjnemu, działającemu na kontrolerze domeny upoważnionej. Celem
zestawienia połączenia, wykorzystuje się standardowe procedury zabez-
pieczeń na poziomie użytkownika, z zastosowaniem pewnych specjal-
nych kont. Pierwsze z nich - konto między domenami (Interdomain trust
account) było omawiane w rozdziale 5. Służy komputerowi Windows NT
Server do identyfikacji pośredniej (pass-through) kontrolera domeny upo-
ważnionej. Oto pozostałe konta specjalne:

Ochrona kont użytkownika w systemie Windows NT

177

Workstation Trust Account - konto działa analogicznie do konta mię-
dzydomenowego, z tym że umożliwia przesłanie żądania identyfikacji
do kontrolera domeny, której elementem jest stacja robocza.

Server Trust Account - konto umożliwia serwerowi odbieranie kopii
baz danych z głównego kontrolera domeny.

Proces zestawiania bezpiecznego kanału łączności można podejrzeć na
rysunku 6.4. Podobnie jak w przypadku procesu wyszukiwania, jeśli
połączenie nie może być ustanowione natychmiast, to próby zestawienia
ponawiane są co 15 minut, aż do pomyślnego końca. Windows NT Server
oraz Workstation buforuje upoważnienia ostatnich dziesięciu użytkow-
ników, na wypadek gdyby nie można było zestawić bezpiecznego połą-
czenia z kontrolerem domeny. Rozwiązanie to umożliwia rejestracje
użytkowników, których dane znajdują się w buforze, w przypadku roz-
łączenia komputera z wszystkimi kontrolerami domeny.

Weryfikacja pośrednia (Pass Through Authentication)

Weryfikacja pośrednia znajduje zastosowanie w sytuacjach, kiedy konto
użytkownika nie może zostać zweryfikowane na maszynie lokalnej.
Przykładem może być próba interaktywnej rejestracji na stacji roboczej
lub serwerze, nie będącym kontrolerem domeny, które są elementami
domeny. Innym przykładem jest zdalna rejestracja użytkownika (remote
logon), który będąc zarejestrowany w jednej domenie, żąda dostępu do
innej.

W środowisku Windows NT można być zarejestrowanym na kilka róż-
nych sposobów. Przebieg wydarzeń związanych z rejestracją różni się
w zależności od miejsca (komputera), z którego podejmuje się próbę reje-
stracji. Oto trzy różne scenariusze:

Rejestracja na stacji roboczej Windows NT, która nie jest elementem domeny.
Informacje wprowadzone przez użytkownika w

oknie Logon

Information

są porównywane z danymi bazy kont lokalnych stacji ro-

boczej. Lista From box z okna Logon Information zawiera jedynie nazwę
stacji lokalnej.

Rejestracja na stacji roboczej Windows NT, będącej elementem domeny. Lista
From box

zawiera nazwy stacji lokalnej oraz domeny, której jest ele-

mentem. Jeśli użytkownik wybierze stację lokalną, weryfikacja prze-
biega analogicznie jak w punkcie poprzednim. Jeżeli użytkownik za-
znaczy nazwę domeny, program usługowy Net Logon prześle we-
zwanie do kontrolera domeny, a ten przeprowadzi proces weryfikacji.

Rejestracja na domenie upoważnionej ze stacji roboczej lub samodzielnego
serwera. Netlogon Service przenosi żądanie rejestracji do kontrolera

Część II Implementacja systemu ochrony Microsoft Windows NT

178

domeny upoważnionej, który weryfikuje upoważnienia konta użyt-
kownika. Jeśli konto użytkownika nie może być pozytywnie zweryfi-
kowane, a domena umożliwia korzystanie z konta gościa, użytkownik
zostaje zarejestrowany w domenie jako gość.

Różnice między rejestracją interaktywną a rejestracją zdalną

Rejestracją interaktywną nazywamy proces rejestracyjny realizowany
drogą bezpośredniej sesji na komputerze. Rejestracja zdalna jest odwrot-
nością interaktywnej. Mamy z nią do czynienia, kiedy użytkownik jest już
zarejestrowany na jakiejś maszynie i chce skorzystać z zasobów znajdują-
cych na innym komputerze lub w innej domenie. Przykładem rejestracji
odległej jest sytuacja, gdy użytkownik jest już zarejestrowany na stacji
roboczej i chcąc uzyskać dostęp do zasobów innej domeny, wydaje pole-
cenie „net use x: //nazwa_serwera/nazwa_zasobu”.

Przebieg rejestracji interaktywnej

Jeśli pomyślnie zarejestrowaliśmy się na stacji roboczej lub serwerze, to
odbyliśmy interaktywną sesje rejestracji. Rejestracja interaktywna zaczy-
na się w

chwili wciśnięcia na komputerze kombinacji klawiszy

CTRL+ALT+DEL

i wprowadzenia nazwy konta oraz odpowiedniego

hasła. Po pomyślnym zweryfikowaniu naszych danych, system udostęp-
nia swój graficzny interfejs użytkownika. Jeśli ktoś rejestruje się na stacji
roboczej lub serwerze, który nie jest kontrolerem domeny, to może wy-
brać opcję rejestracji lokalnej lub rejestracji w domenie. W zależności od
dokonanego wyboru, dane użytkownika są odpowiednio weryfikowane
na stacji roboczej lub kontrolerze domeny,

Jeśli stacja robocza nie jest elementem domeny, to opcja wyboru domeny
w oknie dialogowym Login Information nie jest dostępna. Jedyne co może
zrobić użytkownik na takiej maszynie, to przejść weryfikację poprzez
lokalną bazę danych SAM.

Jeśli rejestracja przebiega na komputerze pełniącym funkcję kontrolera
domeny, to wyłączona jest z kolei opcja rejestracji lokalnej. Użytkownik
może się jedynie zarejestrować w domenie, której kontrolerem jest jego
komputer. Jeśli jednak domenę łączą relacje upoważnienia z innymi, to
w oknie dialogowym Logon Information dostępne są możliwości wyboru
nazwy dowolnej domeny upoważnionej. Wybierając taką opcję,
uruchomimy proces rejestracji, wykorzystujący usługę Netlogon Service.
Program przeniesie niezbędne do weryfikacji informacje do kontrolera
wybranej przez nas domeny.

Ochrona kont użytkownika w systemie Windows NT

179

Uzyskiwanie dostępu do zasobów drogą zdalnej rejestracji

Proces zdalnej rejestracji ma miejsce, kiedy użytkownik, który jest już
zarejestrowany w systemie interaktywnie, żąda dostępu potrzebnych mu
zasobów innego komputera. Przykładem może być wykorzystanie
Eksploratora lub Menedżera plików do przyporządkowania literze
napędu wydzielonych zasobów wspólnych serwera sieciowego.

Przebieg procesu zdalnej rejestracji zależy od sposobu aktualnego zareje-
strowania w sieci oraz od wyboru miejsca nowej rejestracji. Schematy
blokowe przedstawione na rysunkach od 6.5 do 6.10 ilustrują proces
zdalnej rejestracji, wywołany prostym poleceniem net use:... wyprowa-
dzonym z linii komend Windows NT Server.

Przedstawione schematy blokowe ilustrują różne drogi, jakimi użytkow-
nik może otrzymać dostęp do odległych zasobów. Odnotujmy, jak często
występuje w diagramach konto gościa. Jeśli konto gościa pozostaje ak-
tywne, to brak odpowiedniego nadzoru nad należnymi mu uprawnie-
niami stanowi istotne zagrożenie bezpieczeństwa.

Schematy odwołują się często do bloku komunikatów serwera (SMB -
Server-Message-Block). SMB jest strukturą pakietu sieciowego, wykorzy-
stywaną jako narzędzie obsługujące wywołania klienta dotyczące prze-
adresowywania (redirector) oraz odpowiednich odpowiedzi serwera.
SMB składa się z następujących części (por. rysunek 6.11):

Nagłówek: zawiera pola parametrów i środowiska.

Komenda (komendy): określa żądania, które redyrektor (redirector)
powinien zrealizować na odległej stacji.

Opcjonalna przestrzeń danych: może zawierać do 64kB danych skie-
rowanych do odległej stacji.

Część II Implementacja systemu ochrony Microsoft Windows NT

186

Rysunek 6.11

Składniki bloku SMB.

Poniższa lista ilustruje kolejne procesy, związane z tworzeniem prze-
pustki dostępu oraz identyfikatora (UID), dla użytkownika korzystające-
go z dostępu do odległych zasobów:

1. Przepustka dostępu systemu bezpieczeństwa (token1) jest tworzona

podczas inicjacji interaktywnej sesji rejestracyjnej. Przepustka jest sko-
jarzona ze wstępnym procesem użytkownika.

2. Przy pomocy omawianej instrukcji

net use:...,

użytkownik po-

dejmuje próbę zdalnego dostępu do innego serwera (serwer B).

3. Serwer B weryfikuje uprawnienia konta użytkownika i tworzy inną

przepustkę użytkownika (token2).

4. Serwer B zachowuje przepustkę token2 w tablicy lokalnej.

5. Serwer B tworzy identyfikator użytkownika UID i odwzorowuje UID

do przepustki token2, w swojej tablicy lokalnej.

6. UID jest odsyłane z powrotem do redyrektora klienta.

7. Redirektor Klienta wstawia identyfikator UID do wszystkich pakie-

tów SMB, które kolejno wysyła do serwera B.

Ochrona kont użytkownika w systemie Windows NT

187

Wszystkie inne żądania dostępu do zasobów serwera B będą zawierały
identyfikator UID, który został utworzony we wstępnym procesie udo-
stępniania zasobów.

por. „Proces rejestracji”
Jako podsumowanie rozdziału, przedstawimy najczęściej spotykane pro-
blemy, zachodzące podczas rejestracji użytkownika w systemie siecio-
wym domen Windows NT.

Najczęstsze problemy związane z kontami użytkownika

Większość problemów, występujących podczas podejmowania prób reje-
stracji, polega na braku dostępu spowodowanym dublowaniem się kont
o tej samej nazwie i różnych hasłach. Na przykład: John ma w domenie
A założone konto o

nazwie „John” i

haśle „start”. Jednocześnie

w domenie B ma założone konto o nazwie „John” i haśle „stop”. Jeśli
John jest zarejestrowany w domenie A i podejmuje próbę dostępu do
zasobów domeny B, to napotyka komunikat o braku dostępu.

Rozwiązanie przedstawionej sytuacji jest bardzo proste. Albo należy
ujednolicić hasła na obu domenach, albo wprowadzić relacje upoważnie-
nia między domenami A i B. Konsekwentne stosowanie zasady „jedno
konto dla jednego użytkownika”, połączone z właściwą strukturą relacji
upoważnienia między domenami, eliminuje większość tego typu pro-
blemów.

Innego rodzaju kłopoty z rejestracją użytkownika w systemie mogą być
skutkiem braku właściwej synchronizacji między kontrolerami domeny.
Na przykład; John zmienił hasło w swojej domenie. Zmiana została odno-
towana na głównym kontrolerze domeny. Zanim zmiana została skopio-
wana na zapasowe kontrolery domeny, John podjął próbę zarejestrowa-
nia się z nowym hasłem. Pierwszym kontrolerem domeny, który odpo-
wiedział na wezwanie o weryfikację, był zapasowy kontroler domeny, na
którym nie zostały zaktualizowane kopie baz danych z PDC. John nie
uzyskał dostępu do domeny.

Problem można rozwiązać przez wymuszenie pełnej synchronizacji kon-
trolerów domeny przy pomocy programu Server Manager.

Synchronizację kontrolerów domeny można konfigurować przy pomocy
User Manager for Domains lub Server Manager. Oto lista różnych zmia-
ny mogących zachodzić w bazach kont użytkowników, wymagających
pełnej synchronizacji kontrolerów domeny:

Tworzenie nowych kont użytkowników i grup.

Zmiana hasła użytkownika.

Część II Implementacja systemu ochrony Microsoft Windows NT

188

Zmiana w strategii użytkowników domeny (reguł dotyczących kont).

Zmiana przynależności do grupy.

Zmiana skryptu rejestracyjnego lub katalogu prywatnego.

Zmiana czasu dostępności konta.

Zmiana typu lub daty wygaśnięcia konta.

Zmiana w wykazie komputerów, na których użytkownik może się
rejestrować.

Podłączenie do domeny nowego serwera lub stacji roboczej.

Zazwyczaj proces synchronizacji, obsługiwany przez usługę Netlogon
Service, realizowany jest, zanim wystąpią jakiekolwiek problemy
z rejestracją. Tym niemniej, jeśli wynikną problemy spowodowane złą
synchronizacją, rozwiązaniem jest pełna synchronizacja domeny za po-
mocą programu Server Manager.

W innych rozdziałach...

W tym rozdziale wyłożone zostały własności kont w Windows NT oraz
procesy związane z rejestracją i weryfikacją upoważnień użytkowników.
Treść kolejnych rozdziałów skupia się wokół poniższych zagadnień:

Rozdział 7 - Zabezpieczenia możliwe dzięki systemowi plików
NTFS, analizuje dodatkową warstwę systemu ochrony, umożliwiającą
stosowanie zabezpieczeń bezpośrednio na poziomie plików i katalo-
gów założonych na partycjach NTFS.

Rozdział 8 - Wykorzystanie systemu ochrony Windows NT do zabezpiecza-
nia zasobów domen - ilustruje zastosowanie dostępnych w systemie na-
rzędzi administracyjnych do zarządzania ochroną domeny Windows
NT. Nauczymy się, jak korzystać z programów narzędziowych, aby
zapewnić właściwy poziom bezpieczeństwa sieci.

Rozdział 9 - Ochrona Windows NT - analizuje problemy związane
z udziałem stacji roboczych Windows NT w środowisku domen.