Microsoft PowerPoint - 02_Wyklad

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. S

zczegół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 znaleźć 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: +1 999 222 2222
title: Developer
dn: cn=Susan Moller, o=Someorg
changetype:add
cn: Susan Moller
sn: Moller>
givename: Susan
objectclass: inetorgperson
telephonenumber: +1 999 222 2222
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

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)

Umożliwia dysponentowi kontenera dziedziczenie nadanych mu praw do obiektów w
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.

Inheritable (I)
(dziedziczenie)

Prawo do zmiany nazwy obiektu.

Rename (R)
(zmiana nazwy)

Prawo do usunięcia obiektu z drzewa eDirectory

Delete (D)
(usuwanie)

Prawo do tworzenia nowego obiektu poniżej danego obiektu w drzewie eDirectory.
Prawo to odnosi się tylko do obiektów klasy Container.

Create (C)
(tworzenie)

Prawo do przeglądania danego obiektu w drzewie eDirectory.

Browse (B)
(przeglądanie)

Przyznaje wszystkie uprawnienia dostępu. Dysponent z prawem Supervisor ma również
pełny dostęp do wszystkich praw do cech danego obiektu.

Supervisor (S)
(nadzorca)

Opis

Prawo

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)

Przyznaje dysponentowi kontenera prawo do dziedziczenia przyznanych praw do
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.

Inheritable (I)
(dziedziczenie)

Przyznaje dysponentowi obiektu prawo do dodawania lub usuwania samego
siebie jako wartości cechy. Nadanie prawa Write powoduje automatyczne
nadanie prawa Add/Remove Self.

Add/Remove Self (A)
(dodawanie/ usuwanie
siebie)

Pozwala dysponentowi obiektu na modyfikowanie, dodawanie, zmienianie lub
usuwanie wartości cechy. Prawo Write zawiera w sobie prawo Add/Remove Self.

Write (W) (zapis)

Umożliwia odczytanie wartości cechy. Zawiera w sobie prawo Compare.

Read (R) (odczyt)

Umożliwia porównanie dowolnej wartości z wartością cechy, czego wynikiem jest
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.

Compare (C)
(porównywanie)

Przyznaje wszystkie prawa do cech obiektu.

Supervisor (S)
(nadzorca)

Opis

Prawo

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 ź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

Zacząć od przypisań domyślnych.

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.

Do nadawania praw używać opcji Selected Properties.

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

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.

Pamiętać, że nadanie prawa Supervisor do obiektu jest równoznaczne z nadaniem
prawa Supervisor do wszystkich jego cech.

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ę

eDirectory na pierwszym
serwerze w nowym drzewie
eDirectory, tworzone są
automatycznie dwa obiekty:

• obiekt [Root]

• obiekt Admin.

W tym momencie tworzony jest

także dysponent [Public].

Dysponent [Public] i użytkownik

Admin mają przyznawane następujące
prawa do obiektu [Root]:

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.

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.

Porównanie scentralizowanej i rozproszonej
administracji

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