Zarządzanie zabezpieczeniami
eDirectory
mgr inż. Agata Skowrońska, CNA, NAI
Tematyka wykładu
1. Zarządzanie obiektami typu User
2. Obiekt Admin
3. Zarządzanie zabezpieczeniami eDirectory
4. kontrolowanie dostępu do obiektów eDirectory;
5. określanie praw przyznanych do obiektów eDirectory;
6. blokowanie uprawnień dziedziczonych;
7. określanie praw efektywnych;
8. usuwanie problemów związanych z zabezpieczeniami
eDirectory.
Funkcje obiektu typu User
Obiekty typu User reprezentują osoby
korzystające z sieci  są podstawowymi
obiektami usług eDirectory.
Obiekt typu User zawiera informacje
o użytkowniku i jego otoczeniu
sieciowym. Wyznacza zakres dostępu do
sieci i jej usług. Każdy użytkownik sieci
powinien mieć przypisany unikatowy
obiekt typu User.
Na przykład, aby użytkownik mógł się
zalogować, musi mieć przypisany w
drzewie eDirectory odpowiedni obiekt
typu User. Aby użytkownik mógł
korzystać z aplikacji, musi być dodany do
cech tej aplikacji. Aby użytkownik mógł
drukować, musi być powiązany
z drukarką.
Funkcje obiektu typu User
Obiekty typu User mogą być tworzone i zarządzane za pomocą
następujących, dostępnych w systemie NetWare, programów
narzędziowych:
" ConsoleOne
" NetWare Administrator
" iManager
" import/conversion export (ICE)  import lub eksport plików LDIF
Narzędzia administracyjne pozwalają przenosić i kasować obiekty
użytkowników. Dla większej przejrzystości wyświetlana jest nazwa
obiektu, a nie jego numer SID (security identifier). Skasowanie obiektu
jest równoznaczne z usunięciem nadanego mu numeru SID, dla którego
są przyznawane uprawnienia. Jeśli usuniemy, a następnie stworzymy
konto użytkownika o takiej samej nazwie, to nie uzyska on praw
swojego poprzednika, gdyż nowo utworzone konto będzie miało inny
identyfikator.
Aby móc dokonywać zmian w drzewie eDirectory, trzeba mieć
uprawnienia do modyfikowania systemu zabezpieczeń.
Tworzenie i modyfikowanie kont użytkowników
Obiekty typu User należą do najbardziej złożonych obiektów
eDirectory. Szczegółowe dane wraz z wymaganymi cechami tworzą
konto użytkownika.
Tworząc obiekt typu User trzeba podać wartości cech Name (Login
Name) i Surname (Last Name). Wartość cechy Name zostanie użyta
jako nazwa obiektu typu User i będzie używana w procesie logowania.
Katalog własny użytkownika jest osobistym katalogiem w
sieciowym systemie plików. Zwykle wszystkie katalogi własne
użytkowników są zgrupowane w jednym katalogu nadrzędnym (np. w
katalogu USERS).
Nazwa katalogu własnego jest zwykle identyczna z identyfikatorem
użytkownika. Katalog ten można ustanowić podczas tworzenia obiektu
typu User.
Obiekt typu Template
Tworząc użytkowników o podobnych charakterystykach
można skorzystać z obiektu typu Template. Zawiera on
informacje domyślne, które mogą być stosowane dla
tworzonych obiektów typu User.
Obiekt Template utrzymuje łącze z z utworzonym za
jego pomocą obiektem typu User. Cechy obiektów typu
User utworzonych na podstawie obiektu Template można
modyfikować (w obiekcie Template) za pomocą polecenia
Properties of Multiple Users.
W ten sposób można wprowadzić w jednym miejscu
globalne zmiany i przekazywać je do wszystkich obiektów
typu User.
Format LDIF
Aby automatycznie utworzyć wielu użytkowników,
można również skorzystać z programu narzędziowego
import/conversion export (ICE), umieszczonego w
ConsoleOne. ICE korzysta z formatu plików LDIF (LDAP
Data Interchange Format).
Dane w formacie LDIF można wysyłać z większości
systemów katalogowych i poczty elektronicznej.
Więcej informacji o formatach plików LDIF można znalez
ć pod adresem
http://developer.novell.com/research/appnotes/1999/march/a1frame.htm
LDIF
Wprowadzanie informacji
Version: 1
dn: cn=Patrick Milliken, o=Someorg
changetype:add
cn: Patrick Milliken, o=Someorg
sn: Milliken
givename: Patrick
objectclass: inetorgperson
telephonenumber: [phone]
title: Developer
dn: cn=Susan Moller, o=Someorg
changetype:add
cn: Susan Moller
sn: Moller>
givename: Susan
objectclass: inetorgperson
telephonenumber: [phone]
title: Director
LDIF
Modyfikacja i usuwanie informacji informacji
Kolejny przykład przedstawia plik służący do modyfikowania
informacji. Niezbędne są wiersze zaczynające się od kreski poziomej:
dn: cn=Patrick Milliken, o=Someorg
changetype:modify
add:postaladdress
postaladdress: 999 W 555 E $ Sometown, UT $ USA
-
delete:description
-
delete:telephonenumber
telephonenumber: 1-999-999-9999
-
Poniżej przedstawiono przykład pliku służącego do usuwania
informacji. Uzyskuje się to przez wprowadzenie wyróżniających nazw,
które mają zostać usunięte, bez początkowego kwalifikatora:
dn: cn=Patrick Milliken, o=Someorg
changetype:delete
dn: cn=Susan Moller, o=Someorg
changetype:delete
Obiekt Admin
Obiekt Admin jest jedynym istniejącym domyślnie kontem
użytkownika. Jest ono tworzone automatycznie podczas pierwszej
instalacji usług eDirectory. Jego właściciel ma uprawnienia do
zarządzania wszystkimi elementami sieci.
Liczba obiektów o uprawnieniach administratora może być
większa.
Obiekt Admin jest obiektem typu User  może być usunięty lub
zmodyfikowany, można też odebrać niektóre z powiązanych z nim
uprawnień. Usuwając takie konto, należy postępować rozważnie i
wcześniej upewnić się, czy istnieje inny obiekt użytkownika
posiadający prawa administratora.
Modyfikowanie kont użytkowników
Konta użytkowników można modyfikować na dwa sposoby:
" indywidualnie  każdy obiekt User może być modyfikowany
oddzielnie za pomocą polecenia Properties z menu Object. Niektóre
cechy takie jak identyfikator użytkownika, nazwisko i hasło, mogą być
zmieniane wyłącznie indywidualnie.
" grupami  zmieniamy cechy wspólne dla wielu kont użytkowników,
korzystając z polecenia Properties of Multiple Users (z menu Object).
To polecenie może być używane do modyfikowania obiektów typu User
powiązanych z innymi obiektami. Np. po wybraniu obiektu
Organizational Unit można zmieniać wszystkie zawarte w nim obiekty
User. (podobnie jest dla obiektów Group i Template)
Rodzaje zabezpieczeń sieciowych systemu NetWare
W systemie NetWare jest
dostępnych wiele zabezpieczeń
pozwalających chronić sieć i jej
zasoby.
Nie ma jednego systemu
zapewniającego pełne
zabezpieczenie sieci. Jest ono
efektem działania wielu systemów
funkcjonujących po to, aby chronić i
nadzorować poszczególne elementy
sieci.
Zabezpieczenia eDirectory
Zabezpieczenia dostępne w systemie NetWare:
" Zabezpieczenia procedury logowania  nadzorują, kto może zalogować się do
sieci. Dodatkowo można nałożyć ograniczenia na sposób, czas i miejsce
logowania.
" Zabezpieczenia systemu plików  regulują dostęp do aplikacji i plików danych.
" Zabezpieczenia serwera
" Zabezpieczenia drukowania w sieci  regulują kto może korzystać ze
środowiska drukowania i zarządzać nim.
" Zabezpieczenia eDirectory  nadzorują kto może korzystać z Katalogu i nim
zarządzać.
Zabezpieczenia eDirectory
Zabezpieczenia eDirectory pozwalają
użytkownikom na uzyskiwanie dostępu do
zasobów eDirectory, a jednocześnie chronią
Katalog przed niepożądanym dostępem.
Zabezpieczenia eDirectory służą do zarządzania
dostępem do znajdujących się w Katalogu
obiektów eDirectory i ich cech. Zabezpieczenia
te określają, kto może mieć dostęp do informacji
zawartych w Katalogu i w jaki sposób może
przeglądać i modyfikować te informacje.
Na przykład użytkownik potrzebuje uprawnień
do przeglądania innych obiektów w drzewie
Katalogu. Potrzebuje również uprawnień do
logowania się do sieci z użyciem skryptu logowania
zapisanego w odpowiadającym mu obiekcie typu
User. Inny użytkownik może potrzebować dostępu
do informacji o adresie poczty elektronicznej
określonej osoby w celu wysłania do niej
wiadomości.
Podobieństwa i różnice między zabezpieczeniami systemu
plików i zabezpieczeniami eDirectory
Zabezpieczenia eDirectory i zabezpieczenia systemu plików są
niezależne od siebie.
Z tego powodu administrowanie systemem plików i administrowanie
eDirectory może być wykonywane przez jednego administratora sieci
lub rozdzielone pomiędzy różnych administratorów. Umożliwia to tak
zwane kontenerowe administrowanie siecią.
Kontrolowanie dostępu do obiektów eDirectory
Ochrona usług i zasobów sieciowych polega na sprawdzeniu, którzy
użytkownicy mają do nich dostęp. Aby móc kontrolować dostęp
użytkowników do obiektów eDirectory reprezentujących usługi i
zasoby sieciowe, należy zaznajomić się z następującymi pojęciami:
" dysponenci obiektów;
" prawa do obiektów (Entry Rights);
" prawa do cech (Attribute Rights);
" prawa do cech nadane za pomocą opcji All Properties (wszystkie
cechy), a prawa do cech nadane za pomocą opcji Selected Properties
(wybrane cechy);
" domyślne przypisane prawa eDirectory.
Dysponenci obiektów
Każdy obiekt eDirectory ma swoją
listę kontroli dostępu (ACL -Access
Control List). Lista ACL określa, kto
ma prawa do tego obiektu. Lista ta
jest też nazywana listą dysponentów.
Dysponent jest obiektem, który
został umieszczony na liście ACL
cechy Object Trustees (dysponenci
obiektu) innego obiektu.
Obiekty te (dysponenci) mogą mieć
także dostęp do informacji
przechowywanych w cechach obiektu
oraz prawo do dokonywania zmian
tych informacji.
Dysponenci obiektów
Na cechę Object Trustees (ACL) składają się nazwy
eDirectory dysponentów obiektu oraz prawa, jakie mają oni
do tego obiektu.
Dysponenci obiektów
Każdy z podanych obiektów eDirectory może zostać mianowany
dysponentem obiektu. Mianowanie któregokolwiek z tych obiektów, poza
obiektem typu User, dysponentem innego obiektu pozwala na nadanie
praw wielu użytkownikom jednocześnie:
" obiekt typu User;
" obiekt typu Group;
" obiektu typu Organizational Role;
" kontenery i kontenery nadrzędne;
" obiekt [Root];
" dysponent [Public].
Obiekt typu User może otrzymać prawa także przez przyznanie mu
równoważności zabezpieczeń z innym obiektem typu User.
Dysponent Tree [Root]
W trakcie instalowania systemu NetWare na
najwyższym poziomie drzewa Katalogu jest
tworzony obiekt Tree [Root]. Wszyscy
użytkownicy, którzy zalogują się w systemie,
mają domyślnie przyznawaną równoważność
zabezpieczeń z obiektem [Root]. Zatem
mianowanie obiektu [Root] dysponentem
innych obiektów powoduje nadanie wszystkim
użytkownikom tych samych praw, które ma
obiekt [Root].
Niezbędne jest jednak uwiarygodnienie
użytkownika, aby mógł on otrzymać prawa za
pośrednictwem obiektu [Root].
W większości sytuacji nie jest potrzebne, aby
obiekty drzewa Katalogu były ogólnie dostępne
dla użytkowników. Aby zapewnić ochronę
zasobom i usługom eDirectory, należy unikać
używania obiektu [Root] do nadawania praw
dostępu do innych obiektów drzewa Katalogu.
Dysponent [Public]
Obiekt [Public] jest specjalnym obiektem drzewa
Katalogu traktowanym jako obiekt typu Group
obejmujący cały Katalog eDirectory. W trakcie
instalowania systemu NetWare obiekt [Public] jest
mianowany dysponentem obiektu [Root] i są mu
nadawane prawa do przeglądania wszystkich
obiektów w Katalogu.
Wszystkie obiekty drzewa eDirectory mają
przyznaną równoważność zabezpieczeń z
dysponentem [Public]. To przypisanie pozwala
wszystkim użytkownikom z drzewa Katalogu na
przeglądanie wszystkich innych obiektów z
drzewa jeszcze przed zalogowaniem się.
Ponieważ do otrzymania praw za pośrednictwem
dysponenta [Public] nie jest konieczne
uwiarygodnienie użytkownika, nie należy zmieniać
praw dysponenta [Public]. Przyznanie szerszych
praw dysponentowi [Public] daje wszystkim
obiektom drzewa Katalogu większy dostęp do
pozostałych obiektów w tym drzewie.
Prawa do obiektów (Entry rights)
Prawa do obiektów są
prawami nadawanymi
dysponentowi obiektu. Ich
zadaniem jest:
" określanie, jakie operacje
(przeglądanie, zmiana nazwy lub
usunięcie obiektu) dysponent
może wykonywać na danym
obiekcie;
" decydowanie o dostępie do
obiektu, ale nie o dostępie do
wartości cech tego obiektu.
Prawa do obiektów (Entry rights)
Prawo Opis
Supervisor (S) Przyznaje wszystkie uprawnienia dostępu. Dysponent z prawem Supervisor ma również
(nadzorca) pełny dostęp do wszystkich praw do cech danego obiektu.
Browse (B) Prawo do przeglądania danego obiektu w drzewie eDirectory.
(przeglądanie)
Create (C) Prawo do tworzenia nowego obiektu poniżej danego obiektu w drzewie eDirectory.
(tworzenie) Prawo to odnosi się tylko do obiektów klasy Container.
Delete (D) Prawo do usunięcia obiektu z drzewa eDirectory
(usuwanie)
Rename (R) Prawo do zmiany nazwy obiektu.
(zmiana nazwy)
Inheritable (I) Umożliwia dysponentowi kontenera dziedziczenie nadanych mu praw do obiektów w
(dziedziczenie) odniesieniu do obiektów i podkontenerów znajdujących się w tym kontenerze.
Prawo to jest nadawane w sposób domyślny w celu umożliwienia dziedziczenia
uprawnień na obiekty kontenera i jego podkontenery.
Cofnięcie tego prawa ogranicza prawa dysponentów do praw przyznanych do danego
kontenera. Prawa te nie są dziedziczone w odniesieniu do obiektów wewnątrz tego
kontenera i jego podkontenerów. Prawo to odnosi się tylko do obiektów klasy
Container.
Prawa do cech (Attribute rights)
Prawa do cech decydują o uzyskiwaniu
dostępu do informacji przechowywanych w
cechach obiektu:
" decydują o uzyskiwaniu dostępu do wartości
przechowywanych w cechach obiektów
eDirectory, pozwalając użytkownikom na
przeglądanie, przeszukiwanie lub zmienianie
tych wartości;
" określają możliwości użytkownika dotyczące
korzystania z zasobu sieciowego
reprezentowanego przez dany obiekt
eDirectory. Na przykład użytkownik potrzebuje
prawa Read (do cech) do cechy Path (ścieżka)
obiektu typu Directory Map (mapowanie na
katalog), aby móc użyć tego obiektu.
Dysponent obiektu może mieć prawa do cech
obiektu eDirectory nadane z opcją All Properties
(wszystkie cechy) lub Selected Properties
(wybrane cechy).
Prawa do cech (Attribute rights)
Prawo Opis
Supervisor (S) Przyznaje wszystkie prawa do cech obiektu.
(nadzorca)
Compare (C) Umożliwia porównanie dowolnej wartości z wartością cechy, czego wynikiem jest
(porównywanie) wartość Prawda lub Fałsz. Użytkownik nie może odczytać wartości cechy, lecz
tylko wynik porównania (równe, nie równe) z określoną wartością. Nadanie
prawa Read powoduje automatyczne nadanie prawa Compare.
Read (R) (odczyt) Umożliwia odczytanie wartości cechy. Zawiera w sobie prawo Compare.
Write (W) (zapis) Pozwala dysponentowi obiektu na modyfikowanie, dodawanie, zmienianie lub
usuwanie wartości cechy. Prawo Write zawiera w sobie prawo Add/Remove Self.
Add/Remove Self (A) Przyznaje dysponentowi obiektu prawo do dodawania lub usuwania samego
(dodawanie/ usuwanie siebie jako wartości cechy. Nadanie prawa Write powoduje automatyczne
siebie) nadanie prawa Add/Remove Self.
Inheritable (I) Przyznaje dysponentowi kontenera prawo do dziedziczenia przyznanych praw do
(dziedziczenie) cech na obiekty znajdujące się w kontenerze.
Bez tego prawa, prawa dysponenta do cech odnoszą się tylko do cech
kontenera, ale nie do cech obiektów umieszczonych w tym kontenerze.
Prawo to jest nadawane w sposób domyślny po zaznaczeniu opcji All Properties
i domyślnie odbierane po zaznaczeniu opcji Selected Properties.
Prawo to odnosi się tylko do kontenerów.
Opcja All Properties
Ta opcja reprezentuje poziom praw do cech, które
dysponent obiektu ma nadane do wszystkich cech obiektu.
Pozwala na jednoczesne nadanie tych samych praw do
wszystkich cech.
Prawa do cech przyznane za pomocą opcji All Properties
dotyczą każdej cechy danego obiektu. Po przyznaniu
użytkownikowi prawa do cech Read za pomocą opcji All
Properties, może on odczytywać wartości wszystkich cech
tego obiektu.
Selected Properties
Ta opcja pozwala na nadawanie praw osobno dla każdej cechy. Jest ona przydatna
wówczas, gdy jest potrzebny dostęp tylko do kilku cech danego obiektu.
Opcja Selected Properties jest używana zazwyczaj wtedy, gdy użytkownik musi
dokonywać częstych zmian w cechach innych obiektów. Jest tak na przykład w
wypadku pomocnika administratora zajmującego się adresami i numerami
telefonicznymi użytkowników. Po mianowaniu pomocnika administratora
dysponentem wszystkich obiektów typu User, administrator sieci daje mu niezbędne
prawa [ R W ] (Read, Write) do cech Street (ulica) i Telephone (numer telefoniczny).
Dysponentom kontenerów można nadać prawo Inheritable do cechy. Prawo do
cech Inheritable zostaje domyślnie nadane dysponentowi obiektu, gdy do
przyznawania uprawnień używa się opcji All Properties.
Jeśli jednak prawa do cech kontenera są przyznawane za pomocą
opcji Selected Properties, to prawo Inheritable musi zostać nadane ręcznie.
Wyznaczanie praw nadanych do obiektów
eDirectory
Ponieważ eDirectory ma strukturę
hierarchiczną, prawa przechodzą w dół
z kontenerów na podkontenery.
Prawo C nie przepływa w dół do DA1,
ponieważ prawo Create (tworzenie)
dotyczy tylko kontenerów, a DA1 jest
obiektem klasy Leaf.
Dziedziczeniu podlegają zarówno
prawa do obiektów, jak i prawa do
cech. Jednak w wypadku praw do cech
nadanych za pomocą opcji Selected
Properties prawo Inheritable
(dziedziczenie) musi zostać jawnie
nadane.
Blokowanie uprawnień dziedziczonych
Aby uniemożliwić przyznawanie obiektom niektórych
lub wszystkich uprawnień eDirectory, można użyć
następujących metod do zablokowania dziedziczenia praw:
" nowe przypisanie dysponenta na niższym poziomie
drzewa Katalogu i przyznanie mu nowych praw;
" zablokowanie praw za pomocą filtru IRF.
Nowe przypisanie dysponenta
Prawa do obiektów przyznane na
wyższym poziomie w drzewie
Katalogu mogą zostać zastąpione
prawami do obiektów przyznanymi
przez nowe przypisanie dysponenta
na niższym poziomie drzewa.
Prawa dysponenta ulegają
zmianie od poziomu, na którym
odbyło się nowe przypisanie, w dół
drzewa.
Blokowanie praw za pomocą filtru uprawnień
dziedziczonych (IRF)
Filtr IRF może zostać użyty do zablokowania
dziedziczenia praw do obiektów lub praw do cech.
W poprzednich wersjach systemu NetWare prawa
nadane za pomocą opcji Selected Properties nie mogły być
dziedziczone. W NetWare 5.x prawa te są dziedziczone,
jeśli zostało nadane prawo Inheritable (do cech).
Jeśli dysponentowi nie nadano prawa Inheritable (do
cech) do wybranej cechy, to prawo to nie będzie
dziedziczone na inne obiekty w drzewie Katalogu,
niezależnie od umieszczenia filtrów IRF w obiektach
położonych na niższym poziomie drzewa.
Blokowanie praw za pomocą filtru uprawnień
dziedziczonych (IRF)
Filtr IRF dla obiektu eDirectory nie
blokuje uprawnień nadanych dysponentowi
tego obiektu.
Aby zablokować dziedziczenie praw dla
danego użytkownika, należy mianować tego
użytkownika dysponentem obiektu
umieszczonego w drzewie Katalogu w
miejscu, gdzie mają obowiązywać nowe
przypisania praw.
Aby zablokować dziedziczenie praw dla
wszystkich użytkowników, należy umieścić
filtr IRF w obiekcie w miejscu, gdzie prawa
mają zostać ograniczone.
Prawo Supervisor do obiektów może
zostać zablokowane przez filtr IRF w
drzewie Katalogu; nie można go
zablokować filtrem IRF w systemie plików.
Wyznaczanie praw efektywnych
Prawa efektywne użytkownika są sumą praw otrzymanych z
następujących z
ródeł, z wyłączeniem praw zablokowanych za pomocą
filtrów IRF:
" prawa nadane bezpośrednio obiektowi typu User;
" prawa nadane obiektom typu Group i Organizational Role;
" prawa uzyskane w wyniku ustanowienia równoważności zabezpieczeń;
" prawa nadane kontenerom, w których znajduje się dany użytkownik
(obiekt typu User ma ustanowioną równoważność zabezpieczeń z
kontenerami, w których się znajduje);
" obiekt [Root];
" dysponent [Public];
" prawa dziedziczone z wyższych obszarów drzewa.
Przewodnik po zastosowaniach zabezpieczeń
eDirectory
1. Zacząć od przypisań domyślnych.
2. Unikać nadawania praw za pomocą opcji All Properties.
Główną przyczyną, dla której nie należy nadawać dodatkowych uprawnień za pomocą
opcji All Properties, jest to, że są wówczas nadawane prawa do cechy Object Trustees
(ACL).
Dostęp do cechy Object Trustees (ACL) ma bardzo ważne znaczenie dla
bezpieczeństwa systemu. Jest to cecha decydująca o przyznawaniu dodatkowych
praw do obiektu.
3. Do nadawania praw używać opcji Selected Properties.
4. Zachować ostrożność przy nadawaniu prawa Write (zapis) do cechy Object Trustees
(ACL) (dysponenci obiektu) jakiegokolwiek obiektu.
To prawo daje dysponentowi możliwość do nadania każdemu, włącznie z samym sobą,
wszystkich praw, w tym prawa Supervisor.
Dostęp do cechy Object Trustees (ACL), szczególnie z prawem Write (do cech), może
stanowić naruszenie bezpieczeństwa eDirectory. Każdy użytkownik z nadanym prawem
Write (do cech) do tej cechy może nadać każdemu użytkownikowi prawo Supervisor do
tego obiektu.
Przewodnik po zastosowaniach
zabezpieczeń eDirectory
5. Zachować ostrożność przy przyznawaniu prawa Supervisor do obiektu typu Server.
Jest to równoznaczne z nadaniem prawa Supervisor do systemu plików do wszystkich
woluminów na tym serwerze.
Jednym ze sposobów na uniknięcie nadania prawa Supervisor do obiektów jest nadanie
wszystkich praw do obiektów z wyjątkiem prawa Supervisor i nieprzyznawanie prawa
Write (do cech) do cechy Object Trustees (ACL) (dysponenci obiektów).
Ponadto nadanie prawa Write (do cech) do cechy Object Trustees (ACL) obiektu typu
Server da również prawo Supervisor do systemu plików na wszystkich woluminach tego
serwera.
Nadanie prawa Supervisor do obiektu typu Server jest jedyną sytuacją, gdy w
systemie plików są dziedziczone prawa do eDirectory.
6. Pamiętać, że nadanie prawa Supervisor do obiektu jest równoznaczne z nadaniem
prawa Supervisor do wszystkich jego cech.
7. Zachować ostrożność przy blokowaniu prawa Supervisor za pomocą filtru IRF.
Przykład: administrator kontenera używa filtru IRF w celu zablokowania praw
administratora całej sieci do określonej gałęzi drzewa Katalogu.
Jeśli administrator sieci (mający prawo Supervisor do obiektu typu User administratora
kontenera) usunie obiekt typu User administratora kontenera, to tą gałęzią drzewa
Katalogu nigdy już nie będzie można administrować.
Rozwiązywanie problemów z zabezpieczeniami eDirectory
W większości wypadków
rozwiązywanie problemów z
zabezpieczeniami eDirectory
dotyczy:
" wyszukiwania użytkowników
mających nieautoryzowany
dostęp do obiektów i ich cech;
" stwierdzania, dlaczego
użytkownicy nie mają dostępu do
określonych zasobów sieciowych.
Użytkownicy mający nieautoryzowany
dostęp
Jeśli jakiś użytkownik ma większy dostęp do
określonego zasobu niż powinien, to należy określić, skąd
pochodzą prawa do tego zasobu.
Najlepszą metodą na odnajdywanie niepotrzebnych
praw jest:
" określenie praw efektywnych;
" stwierdzenie, skąd te prawa pochodzą.
Określanie, skąd pochodzą prawa
Może okazać się konieczne przeszukanie drzewa Katalogu w celu
odnalezienia praw efektywnych konkretnego użytkownika i stwierdzenia, skąd
te prawa pochodzą. Po określeniu, gdzie prawa mają swój początek,
stwierdzić w podany sposób, jak użytkownik otrzymał te prawa.
1. Sprawdzić przypisania dysponentów danego kontenera.
2. Sprawdzić jawne przypisania dysponentów w wypadku następujących
elementów:
" obiekt typu User;
" grupy, których członkiem jest dany użytkownik;
" funkcje (Organizational Role), które użytkownik pełni;
" równoważności zabezpieczeń, które może mieć użytkownik;
" kontenery w górę drzewa Katalogu, w których znajduje się użytkownik, aż
do obiektu [Root];
" prawa nadane dysponentowi [Public];
" prawa nadane obiektowi [Root].
3. Sprawdzić prawa dziedziczone dla elementów wymienionych w punkcie 2.
Użytkownicy nie mający dostępu do zasobu
" Group/Organizational Role. Czy użytkownik jest członkiem grupy lub pełni
funkcję?
" Równoważność zabezpieczeń. Czy użytkownik miał nadaną równoważność
zabezpieczeń?
" Container. Czy przyznano prawo kontenerowi?
Czy na pewno każdy użytkownik znajdujący się w kontenerze powinien otrzymać te
same uprawnienia? Jeśli tak, to należy się upewnić, czy przyznanie praw odbyło się
na poziomie kontenera. Jeśli nie, to należy utworzyć grupę i przyznać tej grupie
odpowiednie prawa, a następnie umieścić w niej użytkowników potrzebujących
tych uprawnień.
" User. Czy przyznano prawa użytkownikowi?
" Filtr IRF. Czy w kontenerze jest umieszczony filtr IRF?
" Jeśli tak, to dokonać jawnego przypisania dysponenta tego kontenera.
" Jeśli nie, to sprawdzić, czy filtry IRF są umieszczone w kontenerach
nadrzędnych, a następnie dokonać jawnych przypisań.
Domyślne prawa eDirectory
Domyślne prawa eDirectory są tymi prawami,
nadawanymi kiedy inicjujemy następujące zdarzenia:
" tworzenie pierwszego obiektu drzewa ([Root])
" tworzenie kontenera (container)
" instalowanie serwera
" tworzenie konta użytkownika
Domyślne prawa eDirectory umożliwiają dostęp i
pozwalają administrować nowymi obiektami,
reprezentującymi zasoby sieciowe. Administrator może
rozszerzać domyślne prawa według potrzeb.
Domyślne prawa eDirectory przyznawane
przy tworzeniu pierwszego obiektu drzewa
Kiedy instalujemy bazę W tym momencie tworzony jest
eDirectory na pierwszym także dysponent [Public].
serwerze w nowym drzewie
Dysponent [Public] i użytkownik
eDirectory, tworzone są
Admin mają przyznawane następujące
automatycznie dwa obiekty:
prawa do obiektu [Root]:
" obiekt [Root]
" obiekt Admin.
Domyślne prawa eDirectory przyznawane przy
tworzeniu kontenera
Każdy kontener, który
tworzymy, otrzymuje
domyślne prawa dla samego
siebie. To przypisanie tworzy
równoważność zabezpieczeń
kontenera z obiektami typu
User, znajdującymi się w
kontenerze.
Domyślne prawa eDirectory przyznawane przy
instalowaniu serwera
Przy instalacji serwera, domyślne
prawa przyznawane są
użytkownikowi, który tworzy obiekt
typu serwer, oraz obiektowi [Root] i
dysponentowi [Public].
Użytkownikiem, który tworzy
obiekt typu serwer w drzewie
eDirectory, jest zazwyczaj
użytkownik Admin.
Domyślne prawa eDirectory przyznawane przy
tworzeniu obiektu typu User
Po utworzeniu nowego
obiektu typu User,
domyślne prawa, pozwalają
użytkownikowi w pewnym
stopniu na dostęp do
zasobów sieciowych.
Użytkownik otrzymuje
wystarczające prawa do
modyfikacji własnego
skryptu logowania i
konfiguracji zadań wydruku.
Domyślne prawa eDirectory przyznawane przy
tworzeniu obiektu typu User
Porównanie scentralizowanej i rozproszonej
administracji
NetWare pozwala na dwa sposoby
administrowania siecią:
scentralizowaną i rozproszoną
administrację.
Drzewo może mieć jednego
administratora całego drzewa lub
kilku administratorów dla
poszczególnych gałęzi, albo funkcje
te mogą być rozdzielone na jednego
administratora do całego drzewa i
kilku do gałęzi.
Administracja scentralizowana
W administracji scentralizowanej, jeden lub kilku użytkowników ma dostęp
do całego drzewa eDirectory. Taki sposób administrowania drzewem jest w
systemie NeWare domyślny.
Użytkownik Admin jest tworzony podczas instalacji i ma wszystkie prawa
do zarządzania drzewem eDirectory  prawa te ma zapewnione przez jawne
przypisanie praw [SI] do obiektu [Root].
Użytkownik Admin w rezultacie dziedziczy prawa do reszty drzewa, o ile na
niższym poziomie drzewa nie jest stosowany filtr IRF (blokujacy prawa
Adminowi).
Administracja scentralizowana jest odpowiednia dla organizacji z małym
drzewem eDirectory. Również niektóre zadania w systemie NetWare wymagają
centralnego zarządzania:
" zmiana drzewa eDirectory
" tworzenie pierwszego poziomu w drzewie eDirectory
" zarządzanie partycjami i replikami
" zarządzanie synchronizacją czasu
" tworzenie użytkowników z uprawnieniami admina
Administracja rozproszona
W administracji rozproszonej, wyznaczeni użytkownicy zarządzają
wydzielonymi gałęziami drzewa eDirectory. Użytkownik, który jest
wyznaczony do wykonywania zadań administracyjnych na poziomie kontenera,
należy do grupy Container Administrator.
Administracja rozproszona jest stosowana w dużych sieciach, gdzie
kontrolą zajmuje się kilka osób.
Następujące zadania mogą być zarządzane w sposób rozproszony:
" tworzenie kont użytkowników
" zarządzanie hasłami użytkowników
" tworzenie i konfigurowanie usług wydruku
" Back up i odzysk danych
" zarządzania systemem plików
" instalacja dodatkowych serwerów
" tworzenie grup roboczych