Lokalne sieci komputerowe 1 – laboratorium

Ć

wiczenie 8 : Administracja systemem Novell Netware 6.0

Cel ćwiczenia

Celem ćwiczenia jest opanowanie podstaw projektowania i implementacji hierarchicznej bazy
danych X.500 w środowisku Novell Netware 6.0.

1. Wprowadzenie

Podstawową funkcją serwera jest przechowywanie i udostępnianie plików i/lub usług
uprawnionym użytkownikom. Aby zapewnić kontrolę dostępu do zasobów, system serwera musi
dysponować odpowiednią bazą danych, zawierającą informacje o:

•

zasobach

•

użytkownikach

•

prawach użytkowników do korzystania z zasobów.

W systemach NetWare taka baza nosiła kolejno nazwy: Bindery w NetWare 3 i starszych;
NetWare Directory Services (NDS) w NetWare 4 i 5; oraz eDirectory w Netware 6.0 i
nowszych (ponieważ z terminologii jak i programów NetWare nie do końca wyrugowano termin
‘drzewo NDS’, powinien on być utożsamiany z eDirectory i tak też będzie w dalszej części tej
instrukcji). eDirectory ma strukturę hierarchiczną i jest bazą obiektową, tzn. każdy ‘element’
sieci jest reprezentowany jako obiekt o określonych właściwościach. Zasadniczą funkcją
eDirectory jest zorganizowanie dostępu do informacji o wszelkich obiektach w sieci globalnej i
kontrolowanie wzajemnych zależności tych obiektów. Budowa bazy obiektowej, którą zarządza
eDirectory, jest zgodna ze standardem ISO X.500 i reprezentuje zunifikowaną strukturę dla
każdej sieci.

Charakterystyka eDirectory

Zgodność bazy obiektowej NDS ze standardem X.500 narzuca pewne wstępne wymagania na jej
strukturę i funkcjonalność:
1.

Wszystkie zasoby sieci definiowane są jako obiekty, które zarządzane są przez eDirectory w
sposób hierarchiczny, a drzewiasta struktura bazy tych obiektów na ogół odzwierciedla
schemat organizacyjny przedsiębiorstwa. Jest przez to bardziej przyjazna użytkownikowi,
który nie musi znać fizycznej struktury sieci w przedsiębiorstwie, ale powinien raczej znać
organizację samej firmy.

2.

Każdy obiekt, a może nim być użytkownik, jednostka organizacyjna, komputer czy
drukarka, posiadają zespół cech, którym przypisane są odpowiednie wartości, np. numery
seryjne dla komputera, a adres dla użytkownika.

3.

Użytkownik sieci może odwoływać się do obiektów za pomocą prostych nazw, kojarzonych
z typem i cechami obiektów, natomiast eDirectory przeprowadza ich jednoznaczną
identyfikację na podstawie unikalnego systemu nazewnictwa.

4.

Użytkownik nie rejestruje się na serwerze, lecz w bazie eDirectory (w drzewie NDS), dzięki
czemu uzyskuje dostęp do wszystkich serwerów w całym drzewie. Nie ma to oczywiście
znaczenia przy systemach jednoserwerowych.

5.

Użytkownik może korzystać z funkcji skorowidza typu yellow pages, czyli wyszukiwania
obiektów w bazie na podstawie określonych przez siebie kryteriów.

6.

Baza eDirectory może być podzielona na logiczne fragmenty, zwane partycjami,
niekoniecznie mającymi związek z fizyczną lokalizacją obiektów. Partycje te mogą być

replikowane na wielu serwerach, co zabezpiecza bazę przed utratą integralności w
przypadku zniszczenia danych pierwotnej kopii partycji.

7.

Baza eDirectory jest automatycznie synchronizowana, a globalny system synchronizacji
czasowej kontroluje spójność danych w przypadku modyfikacji bazy z wielu odległych
miejsc równocześnie.

Typy obiektów eDirectory

Jak już wspomniano, struktura bazy jest hierarchiczna. W związku z tym można ją zobrazować
za pomocą drzewa obiektów, podobnie jak hierarchiczną strukturę plikową w systemach DOS
lub UNIX. Od razu jednak zaznaczmy, iż struktura plików w systemie NetWare, mimo iż
podobna, nie ma związku z budową bazy obiektowej eDirectory . Każdy wolumin dyskowy
zainstalowany w sieci jest reprezentowany przez obiekt w eDirectory, natomiast sama struktura
woluminu (system plików) nie jest znana ani przechowywana w bazie.

Drzewo tworzone jest z trzech typów obiektów, charakteryzujących miejsce obiektu w
hierarchii. Są to:

•

korzeń (Root)

•

kontener (Container)

•

liść (Leaf).

Obiekt typu korzeń tworzony jest automatycznie w trakcie instalacji systemu NetWare na
szczycie drzewa i jest jedynym tego typu obiektem w całej strukturze. Rozgałęzienia struktury
zawierają kontenery i liście, przy czym kontenery mogą zawierać inne obiekty typu kontener.
Obiekty typu liść tworzą zakończenia gałęzi drzewa i nie mogą już zawierać innych obiektów.
Istnieją trzy rodzaje obiektów typu kontener:

•

kraj (Country) oznaczany literą C,

•

organizacja (Organization) oznaczana przez O,

•

jednostka organizacyjna (Organizational Unit) oznaczana symbolem OU.

W każdej strukturze drzewa obiektów musi znajdować się co najmniej jeden obiekt typu
organizacja. Jednostki organizacyjne mogą ułatwiać organizowanie bazy obiektowej, ale ich
występowanie w drzewie nie jest obowiązkowe. Przy definiowaniu obiektów typu organizacja i
jednostka organizacyjna należy dbać o to, aby ich nazwy były nazwami docelowymi, ponieważ
ich zmiana nie jest operacją prostą.
Obiekt kraj winien być stosowany jedynie w wyjątkowych przypadkach np. tworzenia bazy dla
globalnego przedsiębiorstwa), gdyż jego obecność w drzewie obiektów komplikuje
wykonywanie operacji na elementach bazy. Wykorzystanie tego obiektu umożliwia m. in.
zdefiniowanie różnych stref czasowych.
Liście to fizyczne lub logiczne obiekty sieci nie zawierające innych obiektów, np. użytkownicy,
grupy użytkowników (które wbrew intuicji nie są obiektami typu kontenerowego), serwery,
woluminy, drukarki, kolejki drukowania itd. Posiadają one zazwyczaj ogólne nazwy (Common
Name) oznaczane symbolem CN.
Obiekty umieszczane w danej jednostce organizacyjnej (OU) powinny być zgrupowane zgodnie
z przynależnością do grupy roboczej, czyli zatrudnionych pracowników i współużywanych przez
nich zasobów: drukarek, programów, plików z danymi.

Pojęcie kontekstu

Jak już wspomniano, rozmaite obiekty mogą być umiejscowione w różnych kontenerach, które z
kolei mogą się zawierać w innych kontenerach itd. Może się, rzecz jasna, zdarzyć sytuacja, w
której istnieć będą dwa obiekty zupełnie od siebie niezależne ale posiadające tę samą nazwę. Na
przykład dwóch użytkowników, pracujących w dwóch różnych działach firmy posiada
identyfikator TOMASZ. Ponieważ pracują gdzie indziej, administrator umieścił ich w różnych
kontenerach, reprezentujących działy (jednostki organizacyjne) firmy: SERWIS i BIURO. Obaj
użytkownicy, mimo iż tak samo nazwani, mają określone inne prawa dostępu do plików
zawartych w woluminach. Mają też inne prawa do wszystkich pozostałych obiektów eDirectory,
w tym do siebie nawzajem (przykładowo TOMASZ z BIURA może nie wiedzieć o istnieniu
drugiego TOMASZA ani nawet kontenera, w którym tamten jest zawarty).
W sytuacji takiej jak w opisanym przykładzie, mamy do czynienia z faktem, że każdy z
opisywanych użytkowników znajduje się w innym kontekście. Kontekst to inaczej pozycja
obiektu w strukturze hierarchicznej eDirectory, przy czym dotyczy to nie tylko użytkowników
ale także wszystkich pozostałych obiektów. Pojęcie kontekstu jest więc podobne do pojęcia
ś

cieżki w hierarchicznej strukturze katalogów systemu DOS. Tak jak ścieżka w DOS-ie

jednoznacznie określa, o który katalog lub plik chodzi, tak kontekst precyzuje, w którym miejscu
struktury eDirectory dany obiekt się znajduje. Odwołanie do obiektu jest poprawne, jeżeli polega
na wyspecyfikowaniu jego pełnego kontekstu (tj. ścieżki zawierającej listę wszystkich
kontenerów dzielących dany obiekt od [Root]).
Kontekstem bieżącym jest aktualna pozycja w eDirectory (na tej samej zasadzie jak bieżący
katalog w systemie plików). Z pozycji tej dostępne są bezpośrednio inne obiekty eDirectory
(pod warunkiem posiadania prawa dostępu do nich) zawarte w tym samym kontenerze i aby się
do nich odwołać nie trzeba podawać pełnej ścieżki; wystarczy podanie nazwy obiektu (czyli
adresu względnego).

Konwencje syntaktyczne w eDirectory

Wszelkie obiekty istniejące w strukturze eDirectory muszą mieć swoją nazwę, albo inaczej
mówiąc własność Name. Musi być ona obowiązkowo wypełniona wartością już przy tworzeniu
obiektu. Zasady nazywania obiektów są dosyć proste. Ich nazwy nie mogą być dłuższe niż 64
znaki (oprócz dwuznakowych nazw kontenera typu Country, które są międzynarodowym
skrótem nazwy kraju), w jednym kontenerze nie może wystąpić więcej niż jeden obiekt o tej
samej nazwie, a do tworzenia nazwy można użyć dowolnego znaku specjalnego. Małe i duże
litery nie są rozróżniane, a znak spacji jest utożsamiany ze znakiem podkreślenia. Dopuszczalne
(ale nie zalecane) jest także używanie znaków narodowych.
Nieco bardziej skomplikowana jest zasada odwoływania się do obiektu przez podanie ścieżki do
niego. Tutaj analogie z systemem DOS przestają obowiązywać. O ile bowiem w systemie DOS
pełna ścieżka zaczyna się od podania "korzenia" czyli szczytu struktury hierarchicznej i dalej
katalogów "w dół" tej struktury, tak w eDirectory specyfikacja kontekstu zaczyna się od nazwy
obiektu i dalej wymieniane są kolejne nazwy kontenerów w kierunku szczytu struktury (obiektu
[Root] jako ostatniego zazwyczaj nie wymienia się). Dodatkowo przyjęto założenia, że każdy
obiekt może być poprzedzony kwalifikatorem typu właściwego dla niego (czyli C, O, OU albo
CN) ze znakiem '=', a kolejne nazwy odpowiadające kolejnym poziomom oddziela się znakiem
kropki. Jeżeli specyfikacja kontekstu jest pełna, czyli zawiera całą ścieżkę w NDS, to całą
specyfikację poprzedza znak kropki. Kropka wiodąca ma zatem znaczenie specjalne i informuje,
ż

e ciąg znaków następujący po niej to pełna nazwa. Brak kropki wiodącej niesie zaś ważną

informację, że ciąg znaków w nazwie to nie pełna nazwa, lecz odwołanie względne w stosunku
do bieżącego kontekstu (jest to tzw. nazwa częściowa lub adres względny). Wtedy system
dokleja podaną nazwę względną do nazwy specyfikującej kontekst bieżący do jego lewej strony i
całą powstałą w ten sposób nazwę traktuje jako pełną nazwę obiektu.

Specyfikacje:
.CN=TOMASZ.OU=SERWIS.O=FIRMA oraz .CN=TOMASZ.OU=BIURO.O=FIRMA
są pełnymi nazwami dlatego, że zaczynają się od znaku kropki. Obie te nazwy w sposób
jednoznaczny określają, o jakie obiekty chodzi. Obie są poprawne dlatego, że zawierają
wszystkie elementy struktury eDirectory od obiektu wskazywanego TOMASZ do obiektu
FIRMA włącznie, a tak właśnie powinno być, gdyż obie specyfikacje zaczynają się od kropki.
Nazwa pełna może być podana niezależnie od bieżącego kontekstu i zawsze jednoznacznie
określa jeden i ten sam obiekt. Z inną sytuacją mamy do czynienia, gdy nazwa nie jest pełna.
Załóżmy, że kontekstem bieżącym jest .OU=SERWIS.O=FIRMA. Wtedy podanie nazwy w
postaci: CN=TOMASZ jest poprawne, gdyż jest to nazwa częściowa - odwołanie względne -
które będzie przez system doklejone do nazwy specyfikującej kontekst bieżący od strony lewej i
to co powstanie będzie traktowane jako nazwa pełna: .CN=TOMASZ.OU=SERWIS.O=FIRMA.
Pozostał do omówienia jeszcze jeden element konwencji nazewniczych - możliwość pomijania
kwalifikatora typu obiektów w jego nazwie. Jest to dosyć wygodny mechanizm, pozwala
bowiem na uniknięcie wypisywania dodatkowych znaków w odwołaniu do obiektu:
.TOMASZ.SERWIS.FIRMA
Niestety, w wielu przypadkach stosowanie tej techniki prowadzi do niejednoznaczności i
pomyłek, bowiem system sam próbuje uzupełnić nazwę bez typów o kwalifikatory typów.

2. System plików

Jedną z najważniejszych cech każdego systemu operacyjnego jest stosowany w nim system
plików. System NetWare zajmuje się wyłącznie dyskami sieciowymi - znajdującymi się w
serwerach. Zasoby lokalne - zarówno napędy dyskietek, jak i dysków twardych - nie są
zarządzane przez system sieciowy i ich obsługa zależy od systemu operacyjnego stacji roboczej.
Pliki i katalogi dysku sieciowego są w systemie NetWare udostępniane tak, żeby program
uruchomiony na stanowisku roboczym mógł korzystać z nich, jak z zasobów dysku lokalnego.
Mimo to, dane przechowywane na dysku sieciowym mają specyficzne cechy, nadane im w
systemie NetWare. Wynika to z wielodostępu i konieczności ochrony zasobów. Dane sieciowe
są zorganizowane hierarchicznie. Jednostkami nadrzędnymi w tej hierarchii są serwery plików -
komputery, do których dostęp chroniony hasłami mają tylko zarejestrowani użytkownicy.
Serwery są identyfikowane przez nazwę (co najmniej dwa znaki).
Na każdym serwerze dane są przechowywane w woluminach. Wolumin to przestrzeń dyskowa o
ustalonej wielkości, w której przechowuje się jedno drzewo katalogów. Wolumin jest logicznym
odpowiednikiem dysku DOS-owego (jedynie odpowiednikiem, ponieważ wolumin sieciowy
może składać się nawet z 32 fizycznych obszarów pamięci dyskowej). Obszary te mogą
znajdować się na różnych dyskach fizycznych przyłączonych do serwera plików. Ciekawą cechą
woluminu Novellowego jest możliwość powiększenia go bez konieczności ponownej instalacji
systemu. Każdy serwer posiada na swoich dyskach co najmniej jeden wolumin (a maks.64).
Każdy wolumin posiada swoją nazwę, unikalną w ramach danego serwera. Nazwa każdego
woluminu kończy się dwukropkiem. Jeden wolumin musi nazywać się SYS:, pozostałe zaś mogą
się nazywać dowolnie (nazwy te nadaje osoba instalująca serwer). Różne serwery NetWare
mogą mieć woluminy o tych samych nazwach (np. każdy serwer musi mieć wolumin SYS: ).
Nazwa woluminu może zawierać od dwóch do piętnastu znaków spośród znaków alfabetu,
znaków cyfr i następujących znaków specjalnych: ~, !, #, $, %, ^, &, (, ), -, _, {, }.
Pełne odwołanie do woluminu fizycznego powinno być poprzedzone nazwą serwera, na którym
został on zainstalowany, a separatorem dzielącym nazwę serwera od nazwy woluminu jest znak
'/' lub '\'. Tak więc poprawne odwołanie do fizycznego woluminu VOL1: ma postać:
SERWER_N/VOL1:
Tak podawane nazwy woluminów w serwerach NetWare są często określane jako tzw. nazwy
fizyczne woluminów, gdyż określają one gdzie fizycznie, tj. na dyskach którego serwera te
woluminy się znajdują i jak się nazywają. Takie nazewnictwo było zupełnie wystarczające w
starszych wersjach systemu NetWare (poniżej 4.0), gdzie dostęp do woluminów był zawsze

możliwy tylko poprzez dostęp do konkretnego fizycznego serwera, który zawierał dane
woluminy. Jednak koncepcja sieci bazującej na NetWare w wersji 4.0 i wyższych jest zupełnie
inna - mianowicie dostęp do systemu uzyskuje się przez dostęp do całej sieci (drzewa), a nie do
poszczególnych serwerów. Idąc dalej za tym rozumowaniem, dla przeprowadzanie operacji na
danych wcale nie jest potrzebny dostęp do serwera, który ma na swoich dyskach zainstalowany
dany wolumin, lecz tylko dostęp do woluminu jako takiego. Stąd też wyodrębniono w systemie
NetWare dwa obiekty logiczne. Jeden to serwer wraz z jego własnościami, a drugi to wolumin,
który oprócz własności opisujących go, posiada interesujący nas system plikowy. W tej sytuacji
dla dostępu do woluminu w eDirectory nie należy posługiwać się nazwami fizycznymi (bo te
wiążą serwer z woluminem) lecz nazwami logicznymi (które określają tylko wolumin). Zasada
budowania nazw logicznych jest nieskomplikowana - nazwę woluminu pozbawia się dwukropka
i dla jednoznaczności nazw poprzedza nazwą serwera ze znakiem podkreślenia. Jest to domyślny
sposób nazywania woluminów, aczkolwiek mogą być nazwane zupełnie inaczej.
Jak wspomniano, w trakcie instalacji serwera wraz z woluminami, zawsze jeden z nich musi
nazywać się SYS:. Nie jest to przypadek, gdyż w tym właśnie woluminie zakładane są specjalne
katalogi z plikami obsługującymi system. Zanim zostanie omówiona rola poszczególnych
katalogów, trzeba wyjaśnić dwie istotne sprawy. Po pierwsze pełna ścieżka w sensie struktury
katalogów,

określająca

przykładowy

podkatalog

o

nazwie

'DOS'

brzmi:

.CN=SSERWER_SYS.OU=SERWIS.O=FIRMA:

\PUBLIC\DOS

Po drugie, struktura eDirectory kończy się na obiekcie SSERWER_SYS (kolor czerwony
oznacza adres w eDirectory), a dalej w głąb struktury mamy do czynienia z systemem plikowym
(kolor zielony oznacza ścieżkę w systemie plików), również uporządkowanym hierarchicznie.
Ten wszakże system plikowy nie jest częścią struktury eDirectory, jakby to mogło się mylnie
wydawać. A zatem specyfikacja pliku lub katalogu w sieci składa się z dwóch części. Pierwsza
część, tzw. obiektowa, zawiera poprawną według konwencji przyjętych w eDirectory
specyfikację obiektu, jakim jest wolumin. Druga część, związana ze strukturą plikową zawiera
poprawną według konwencji przyjętych w systemie DOS specyfikację pliku lub katalogu
zawartego w woluminie, przyjmując umownie za szczyt struktury plikowej właśnie ten wolumin.
Obie części specyfikacji oddziela się znakiem dwukropka. Jak widać jednak na przytoczonym
przykładzie, specyfikacja katalogu może być bardzo długa i skomplikowana. Dlatego sposób
odwoływania się do plików i katalogów przez podanie ścieżki do nich jest mało praktyczne i z
tego powodu twórcy systemu wprowadzili kilka mechanizmów upraszczających takie
odwołania. Mechanizmy te bazują na tym, że użytkownik w czasie sesji pracy w sieci na ogół
korzysta z kilku, najwyżej kilkunastu katalogów na różnych woluminach. Proponowane
rozwiązanie (zresztą bardzo skuteczne) polega na tymczasowym nazwaniu tych katalogów
literami alfabetu i odwoływanie się do nich poprzez te symbole, zamiast podawania całej
specyfikacji. Technika ta zwana jest mapowaniem dysków lub przypisywaniem napędów.

Mapowanie dysków
Mapowanie polega na przypisaniu litery dysku katalogowi znajdującemu się na woluminie
serwera, co umożliwia odwoływanie się do tego katalogu w taki sposób, jak do dysków
lokalnych. Wykorzystuje się do tego systemowe polecenie MAP. Wydane bez parametru
wypisuje na ekranie stacji listę aktualnie obowiązujących oznaczeń literowych przypisanych
katalogom, w tym oznaczeń katalogów, które są przeszukiwane (tzw. ścieżki przeszukiwania)
dla znalezienia plików typu .COM, EXE i .BAT - jeżeli nie znajdują się one w katalogu
bieżącym. Polecenie MAP służyć może także do przypisania nowego oznaczenia literowego do
katalogu, do którego użytkownik posiada uprawnienia, w dowolnym momencie jego pracy. Np.

MAP K:=SYS:\PUBLIC\DOS

spowoduje przypisanie katalogowi \PUBLIC\DOS w woluminie SYS: oznaczenia literowego K:.

W systemie Windows dyski można mapować wykorzystując polecenie paska narzędzi ‘Mapuj
dysk sieciowy’.

Atrybuty plików i katalogów

Nazwa atrybutu

Znaczenie atrybutu

A – Archive
Needed

Wymagana archiwizacja. Oznacza, że od czasu sporządzenia kopii
zapasowych zmieniła się zawartość pliku. Podczas tworzenia kopii
zapasowej pliku atrybut ten jest automatycznie kasowany. Przy
zmianie zawartości pliku lub podczas tworzenia jest ustawiany.
Odpowiada atrybutowi A z DOS-a.

Ci – Copy Inhibit

Zakaz kopiowania. Atrybut używany do realizacji zakazu
kopiowania na stanowiskach typu Apple Macintosh.

Di – Delete Inhibit

Zakaz usuwania. Gdy nadano go katalogowi nie blokuje możliwości
kasowania samej zawartości katalogu.

Dc - Don't
Compress

Nie kompresuj. Atrybut zabrania systemowi dokonania kompresji
pliku lub katalogu (wraz z jego zawartością).

Dm - Don't Migrate

Nie dokonuj migracji. Zabrania systemowi wykonania migracji pliku
lub katalogu

M - Migrated

Nadanie tego atrybutu jest możliwe tylko przez system i oznacza, że
plik został poddany migracji.

Ic - Immediate
Compress

Natychmiastowa kompresja. Atrybut można nadać tylko plikowi.
Nakazuje on natychmiastowe wykonanie kompresji.

Cc - Can't
Compress

Niemożność kompresji. Może być nałożony tylko przez system i
oznacza, że plik nie będzie poddany kompresji, gdyż ta byłaby
nieopłacalna.

Co - Compressed

Skompresowany. Atrybut jest nakładany przez system i oznacza, że
plik został poddany kompresji.

X – Execute Only

Tylko do wykonania, plik nie może być przeczytany jako dane. Raz
nadany nie może być usunięty, nawet przez administratora.

H – Hidden

Ukryty. Oznacza, że nazwa pliku/katalogu nie będzie widoczna dla
użytkowników używających klasycznych narzędzi do przeglądania
katalogów, np. komendy DIR, oraz nie będzie mógł być skasowany
takimi narzędziami jak ERASE czy DEL.

P – Purge

Wyczyszczenie. Oznacza, że po usunięciu pliku/katalogu nie można
go już odzyskać. W odniesieniu do katalogu oznacza kompletne
kasowanie wszystkich plików w tym katalogu, nawet jeżeli nie
posiadają one atrybutu P.

Ro – Read Only

Plik tylko do odczytu pliku, zabrania zapisu do pliku.

Rw – Read/Write

Umożliwia zarówno odczyt jak i zapis.

Ri – Rename Inhibit Zakaz zmiany nazwy.

Sh – Shareable

Dzielony. Pozwala na jednoczesne korzystanie z pliku wielu
użytkownikom. Dotyczy tylko plików.

Sy – System

Systemowy. Działa podobnie jak H, a ponadto nie pozwala na
zmianę nazwy lub skasowanie. Odnosi się także do katalogów.

N – Normal

Zwykły - oznacza, że żaden atrybut nie został ustawiony. Plik nie
może być współużytkowany oraz można do niego zapisywać dane.

T – Transactional

Transakcyjny. Plik jest automatycznie chroniony systemem
ś

ledzenia transakcji (TTS).

W systemie DOS/Windows plikom można nadawać 4 atrybuty: ukryty, tylko do odczytu,
systemowy, archiwalny. W niektórych narzędziach NetWare te 4 atrybuty oznaczane są jako
DOS Attributes.

Zmiana atrybutów plików i katalogów

Zestaw atrybutów można zmieniać za pomocą:

−

właściwości pliku/katalogu, z menu kontekstowego w Windows (atrybuty ‘DOS-owe’ w
zakładce ‘Ogólne’, atrybuty NetWare w zakładce ‘Informacje NetWare’) – rys. 3.

−

programów NetWare Administrator (NwAdmn32 – rys. 4.), ConsoleOne – w Windows

Usuwanie plików

W NetWare funkcjonuje system odzyskiwania plików skasowanych. Pliki bez ustawionego
atrybutu P można odzyskać po skasowaniu, ustawienie atrybutu P powoduje, że skasowanie
pliku będzie nieodwracalne. Do zarządzania skasowanymi plikami służą opcje ‘Odzyskaj’ oraz
‘Czyszczenie’ dostępne w grupie ‘Programy narzędziowe firmy Novell’ w pasku narzędzi
Novell (

N

). Przed odzyskaniem/czyszczeniem należy wskazać katalog, w którym mają być

przeprowadzone te operacje.

3. Prawa w systemie plików

Ważniejsze pojęcia

Property (własność) – cecha obiektu/pliku/katalogu. Własnościami są np. nazwa, data

utworzenia (pliku), hasło (użytkownika). Obiekty NDS mogą mieć po
kilkadziesiąt własności.

File/Directory Attribute (atrybut pliku/katalogu) – własność obiektu lub pliku precyzująca

sposób traktowania go przez system i sterująca trybem korzystania z
niego przez użytkowników, np. restrykcje co do czynności możliwych
do wykonania z tym plikiem lub katalogiem, niezależnie od tego jaki
użytkownik chce te czynności wykonać.

File/Directory Rights (prawa do pliku/katalogu) – określają uprawnienia konkretnego obiektu

NDS (np. użytkownika) do dysponowania plikiem/katalogiem.

ACL (Access Control List – Lista kontroli dostępu) – jest to jedna z własności każdego pliku,

katalogu oraz obiektu NDS. Lista zawiera nazwy wszystkich obiektów
posiadających jakiekolwiek prawa do dysponowania plikiem,
katalogiem lub obiektem, którego jest własnością. Np. lista ACL pliku
test.txt może zawierać obiekt Kazio.dzial.firma i przypisane mu prawa
do odczytu i zapisu. Oznacza to, że użytkownik Kazio ma w/w prawa
do tego pliku.

Trustee (dysponent) – dysponentem pliku, katalogu czy obiektu NDS jest obiekt NDS (np.

użytkownik) który, posiada prawa (czyli jest wpisany do ACL) do tego
pliku/katalogu/obiektu.

Inherited Rights (prawa dziedziczone) – prawa nadane nie w sposób bezpośredni (jawny), lecz

uzyskane w wyniku dziedziczenia. W NetWare istnieją 2 mechanizmy
dziedziczenie, omówione w dalszej części instrukcji.

Inherited Rights Filter (filtr praw dziedziczonych) – filtr umożliwiający ograniczenie

dziedziczenia uprawnień. Filtr jest jedną z własności plików, katalogów
oraz obiektów NDS.

Effective Rights (prawa efektywne) – rzeczywiste prawa obiektu do pliku (lub katalogu lub

innego obiektu). Są sumą praw jawnie nadanych, praw odziedziczonych
i praw grupowych.

Zestaw praw dysponenckich do plików i katalogów

Jako, że głównymi czynnościami, które mogą być wykonywane na plikach, jest ich tworzenie,
kasowanie, otwieranie, czytanie oraz zapis, to zestaw praw dysponenckich odzwierciedla
potrzeby użytkowników w tym zakresie i wygląda następująco:

Uprawnienie

Znaczenie uprawnienia

Read

Możliwość otwarcia pliku i odczytania jego zawartości.

Write

Możliwość zapisywania do pliku nowych danych, jak i zmieniania
istniejącej zawartości.

File Scan

Możliwość zobaczenia nazwy tego pliku w katalogu, w którym istnieje.
Prawo to nie ma zastosowania w odniesieniu do katalogów.

Create

Dotyczy tylko katalogów i oznacza, że dysponent z tym prawem może
w tych katalogach zakładać nowe podkatalogi i pliki.

Erase

Oznacza, że dysponent z tym prawem może katalog lub plik skasować.

Modify

Możliwość zmiany atrybutów lub nazwy katalogu lub pliku.

Access Control

Pozwala nadawać lub zabierać dowolnym obiektom wszystkie, poza
Supervisory, uprawnienia dysponenckie do tego katalogu lub pliku.

Supervisory

Prawo to ma znaczenie specjalne. Jest faktycznie nie pojedynczym
prawem, lecz zestawem praw. Oto istotne cechy: Posiadanie prawa
Supervisory oznacza automatycznie posiadanie wszystkich pozostałych
praw do katalogu lub pliku. Prawo Supervisory nadane do jakiegoś
katalogu nie może być odfiltrowane filtrem IRF, inaczej mówiąc
zawsze się je dziedziczy. Nie może być także zabrane jawnym
nadaniem dysponenckim w stosunku do żadnego pliku lub podkatalogu
znajdującego się w głębi struktury katalogu.

Dziedziczenie uprawnień

W NetWare istnieją dwa rodzaje dziedziczenia: dziedziczenie uprawnień od przodków
(Ancestory Inheritance) i dziedziczenie polegające na spływaniu praw dysponenckich (Rights
Flow).
Dziedziczenie od swoich przodków polega na tym, że jakiś kontener (przodek) zostaje
dysponentem dowolnego pliku/katalogu. Wtedy uprawnienia tego kontenera przechodzą na
zawarte w nim obiekty, które w ten sposób też stają się dysponentami pliku/katalogu, którego
dysponentem jest ich kontener-przodek (rys. 1.).

2) Użytkownik jest potomkiem kontenera, dziedziczy od

kontenera prawa [RWFC] do katalogu, ale nie
znajduje się na liście ACL katalogu

1) Kontener

ma

jawnie

nadane

prawa

[RWFC] do katalogu (znajduje się na liście
ACL katalogu)

Rys. 1. Dziedziczenie po przodkach (Ancestory Inheritance)

Drugi przypadek to spływanie praw. Jeżeli obiekt jest dysponentem jakiegoś katalogu, np. ma w
stosunku do niego prawo Create, to takie samo prawo ma również do wszystkich
plików/katalogów zawartych w tym katalogu (rys. 2.).

2) Prawa użytkownika do

katalogu

nadrzędnego

spływają

na

pliki

i

podkatalogi – użytkownik
ma prawa [RW] do pliku
i podkatalogu, ale nie
znajduje się na liście ACL
pliku ani podkatalogu

1) Użytkownik ma jawnie nadane prawa

[RW] do katalogu nadrzędnego (znajduje
się na liście ACL katalogu)

Rys. 2. Spływanie praw (Rights Flow)

Prawa dysponenta do pliku/katalogu odziedziczone z katalogów nadrzędnych (spływające) mogą
zostać anulowane poprzez ponowne jawne nadanie dysponenckie do tego obiektu/własności.
Takie nadanie jest silniejsze od dziedziczenia praw i powoduje, że od tego katalogu począwszy,
w głąb struktury spływają tylko te prawa, które pojawiły się w wyniku tego nadania (przykład 1).

Filtrowanie praw dysponenckich

Ponieważ prawa dysponenckie spływają w głąb struktury plików, można na dowolny
plik/katalog w nałożyć specjalny filtr, zwany Inherited Rights Filter, w skrócie IRF. Filtr IRF
jest formalnie częścią własności ACL pliku/katalogu, czyli dotyczy wszystkich jego
dysponentów. Blokuje on "spływanie" praw w dół systemu plików według określonych reguł.
Zawiera określony zestaw uprawnień, które mają być dziedziczone - zabrania dziedziczenia tych
praw, które nie są w nim wymienione (filtrowaniu nie podlega uprawnienie Supervisory).
Domyślnie filtr IRF zawiera wszystkie możliwe uprawnienia i rolą operatora systemu (bądź
właściciela katalogu) jest wykluczyć z niego prawa zbędne, czyli te które nie powinny być
dziedziczone.
W przypadku, gdy do jakiegokolwiek dysponowanego pliku/katalogu odnoszą się uprawnienia
dysponenta przypisane jawnie, to te prawa obowiązują ów plik/katalog niezależnie od tego, jaki
filtr IRF posiada i jakie prawa spływają z katalogów nadrzędnych. Zatem jawne nadanie anuluje
prawa spływające, zatem filtr IRF działa tylko w przypadku, w którym dysponent dziedziczy
prawa, a nie uzyskuje ich przez jawne nadanie dysponenckie.

Prawa efektywne

Aby odpowiedzieć na pytanie "co naprawdę obiekt X może zrobić z plikiem Y ?" trzeba
"obliczyć" jego prawa efektywne. W tym celu należy:

−

zsumować wszystkie prawa dysponenckie obiektu X (nadane jawnie lub odziedziczone po

przodku), prawa grup, do których ten obiekt należy i prawa wszystkich jego równoważników
(Security equals)

−

wziąć część wspólną praw z IRF obiektu Y i praw spływających, jeżeli nie ma praw nadanych

jawnie.

Większość narzędzi NetWare wyposażona jest w ‘kalkulatory’ praw efektywnych.

Przykład 1.

Rozpatrzmy następującą strukturę katalogów:

LANG
|
C++

1)

Nadajemy użytkownikowi prawa [RWFCA] do katalogu LANG. Prawa te spływają na
katalogi podrzędne, w efekcie użytkownik posiada prawa efektywne [RWFCA] do
katalogu C++.

2)

Nadajemy użytkownikowi prawa [RW] do katalogu C++. Ponieważ nadanie jawne
unieważnia prawa spływające, to użytkownik posiada prawa efektywne [RW] do
katalogu C++.

3)

Usuwamy użytkownika z ACL katalogu C++ (czyli usuwamy nadane mu prawa [RW]).
Jego prawa efektywne do katalogu C++ zmieniają się na [RWFCA].

Nadawanie praw do plików/katalogów

Prawa do plików/katalogów oraz filtry dziedziczenia można zmieniać za pomocą:
–

właściwości pliku/katalogu, z menu kontekstowego w Windows (zakładka ‘Prawa NetWare’)
- rys. 3.

–

programów NetWare Administrator (rys. 4.), ConsoleOne – w Windows

Lista dysponentów
(ACL) – możliwość
zmiany uprawnień

Usunięcie zaznaczonego
dysponenta z listy ACL

Drzewo NDS – tu
wybieramy obiekt do
dodania do ACL

Dodanie zaznaczonego
dysponenta (dowolnego
obiektu NDS) do listy
ACL

Filtr IRF oraz lista
obiektów, posiadających
prawa odziedziczone

Moje prawa efektywne

Rys. 3. Zarządzanie listą ACL plików/katalogów (własności pliku - Windows)

Lista dysponentów (ACL)

‘Kalkulator’ praw efektywnych (umożliwia
wyświetlenie praw efektywnych dla dowolnego
obiektu (niekoniecznie z listy ACL)

Zakładka
Atrybuty

Dodanie
dysponenta

Filtr IRF

Prawa zaznaczonego
obiektu (nadane jawnie)

Usunięcie
dysponenta

Rys. 4. Zarządzanie listą ACL plików/katalogów (NetWare Administrator)

Uwagi

−

administrator systemu ma prawo S do katalogu głównego każdego z woluminów. Ponieważ
prawa S nie można usunąć z filtru IRF, to administrator ma prawo S do każdego pliku i
katalogu na każdym woluminie,

−

użytkownik, który utworzy nowy katalog/plik, staje się jego właścicielem (ang.: Owner) i ma
wszystkie prawa do tego pliku/katalogu,

−

opisane prawa i atrybuty mają zastosowanie wyłącznie do plików i katalogów NetWare
(znajdujących się na woluminach serwera),

−

niektóre polecenia linii komend nie działają, gdy dyskiem bieżącym jest dysk lokalny,

proszę uważać, aby podczas ćwiczeń nie odebrać sobie praw do swoich katalogów (w
szczególności katalogu domowego). Odebranie sobie prawa A i S wiąże się z utratą
możliwości zarządzania plikiem.

4. Obiekty i prawa eDirectory

Typy obiektów

AFP Serwer (serwer typu AFP) - serwer stosowany w sieciach firmy Apple, używający

protokołu AFP (AppleTalk Filing Protocol). Może być instalowany również w sieciach
NetWare.

Alias (nazwa zastępcza) - odsyłacz do innego istniejącego obiektu w strukturze NDS (coś w

rodzaju windowsowego skrótu, ale odnoszący się do obiektów NDS).

Computer (komputer) - reprezentuje fizyczny komputer, np. stację roboczą, jest to obiekt czysto

informacyjny, może przechowywać informacje takie jak numery seryjne, adresy sieciowe,
lokalizacja etc.

Directory Map (mapowanie katalogów) - obiekt stworzony w celu ułatwienia mapowania.

Directory Map wskazuje na katalog i może być wykorzystany w poleceniu MAP, np.:

map k:=Directory_map_1

Group (grupa użytkowników) – zbiór użytkowników. Pozwala na zbiorowe nadawanie praw

wszystkim członkom grupy.

NetWare Server (serwer NetWare) - reprezentuje istniejący w systemie fizyczny komputer na

którym zainstalowano system operacyjny NetWare. Podobnie jak Computer, jest obiektem
informacyjnym, przechowuje m.in. rodzaj procesora, ilość pamięci operacyjnej, pojemność
dysków, listę woluminów itp.

Organizational Role (rola organizacyjna) - obiekt tego typu ma za zadanie ułatwiać

administrowanie systemem. W dowolnym kontenerze NDS tworzy się obiekt Organizational
Role, po czym nadaje mu się prawa do zarządzania innymi obiektami. Następnie dowolnego
użytkownika można uczynić obiektem Organizational Role, przez wpisanie do własności
Occupant nazwy użytkownika. Otrzymuje on tym samym przywileje określone w prawach
obiektu Organizational Role. Jak łatwo zauważyć, funkcje tego obiektu może spełniać obiekt
typu Group, Novell zaleca, aby Group używać do nadawania uprawnień w systemie plików, a
Organizational Role do praw w NDS.

Print Server (serwer drukowania) - moduł programowy, stworzony do obsługiwania kolejek

drukarskich, drukowanie oparte na kolejkach było standardem w NetWare 4.0, w wersjach od
5.0 wzwyż mechanizm ten jest rzadko wykorzystywany.

Printer (drukarka) - obiekt reprezentuje fizyczne urządzenie. Oprócz funkcji informowania

użytkowników NDS o istnieniu drukarki dostępny jest jej opis, a w nim elementy takie jak jej
typ, parametry techniczne itp.

Print Queue (kolejka zadań drukarskich) - magazyn zadań, które są już przygotowane do

bezpośredniego wydruku. W NetWare 6 rzadko wykorzystywany (podobnie jak Print Server).

Profile (profil) - obiekt typu profil istnieje po to, by przechowywać dodatkowy program

zgłoszenia (login script), który może być przypisany użytkownikowi i wykonany podczas
rejestrowania się do sieci. Więcej informacji o skryptach logowania w dalszej części tej
instrukcji.

User (użytkownik) - reprezentuje użytkownika, który ma prawo do pracy w systemie, zawiera

jego dokładny opis, m. in. dane umożliwiające identyfikację, uprawnienia i restrykcje w NDS.

Volume (wolumin) – reprezentuje logiczny dysk na serwerze. Należy pamiętać, że system

plików na woluminie nie jest częścią NDS. Obiekt ten pełni również funkcje informacyjną.

Obiekty Bindery (Bindery Object, Bindery Queue) – były wykorzystywane w wersjach poniżej

4.0. Mogą się znaleźć w bazie NDS w celu obsługi klientów pracujących w starszych
wersjach systemu.

Template lub User_Template (wzorzec użytkownika) – służy do tworzenia użytkowników

(User) o ustalonych własnościach

Unknown (nieznany obiekt) - obiekt, który na skutek jakichś anormalnych wydarzeń w sieci

(np. awaria) przestaje być rozpoznawalny jako obiekt dowolnego z wymienionych wyżej
typów. Taki typ obiektów reprezentuje również niektóre serwisy systemowe (można je
znaleźć w obiekcie Organization). Oczywiście obiekty tego typu nie mogą być tworzone.

Obiekty, oprócz swojej funkcjonalności, różnią się własnościami. Niektóre własności występują
we wszystkich typach obiektów (np. nazwa, lista ACL), inne tylko w niektórych typach, np.
Nazwisko (Last Name) użytkownika, lista członków (Members) grupy, wskazywany katalog
obiektu Directory Map, itp. Niektóre typy obiektów mogą mieć nawet ponad 100 własności.

Zabezpieczenia na poziomie struktury bazy NDS

Zabezpieczenia na poziomie bazy NDS regulują zasady dostępu jednego obiektu do innych
obiektów oraz ich własności.
Wyróżniamy dwa rodzaje praw dotyczących obiektów NDS: prawa do obiektów (object rights)
oraz prawa do własności (property rights). Pierwsze z nich odnoszą się do obiektów jako całości,
pozwalają np. tworzyć nowe i kasować istniejące obiekty w danym kontenerze. Prawa te mogą
się odnosić zarówno do całych kontenerów jak i poszczególnych obiektów typu CN.
Uprawnienia do działania na własnościach obiektów, pozwalają na odczyt lub zmianę własności
obiektów (np. listy członków grupy, hasła użytkownika, itp.).
Dysponentem obiektu NDS może być jakikolwiek inny obiekt, chociaż najczęściej jest nim
użytkownik, grupa użytkowników albo jakiś kontener (zawierający obiekty typu użytkownik).
Obiektem dysponowanym może być każdy obiekt w NDS.

Poniżej wyszczególniono wszystkie prawa do obiektów i prawa do własności obiektów
występujące w NDS.

Prawa do obiektów (object rights)

Uprawnienie

Znaczenie uprawnienia

Browse

Jeżeli obiekt posiada prawo Browse do drugiego obiektu w strukturze
NDS, to może go w tej strukturze zobaczyć, czyli stwierdzić, że istnieje i
w jakim kontenerze. Nie gwarantuje jednak możliwości odczytu
jakiejkolwiek własności tego obiektu.

Create

Oznacza możliwość zakładania innych obiektów w strukturze obiektu
dysponowanego, którym może być tylko kontener. Prawo to
automatycznie dodaje prawo Browse.

Delete

Oznacza możliwość kasowania obiektów dysponowanych.

Rename

Daje możliwość zmiany nazwy obiektu. Jest to równoznaczne z prawem
zmiany bardzo ważnej własności obiektu, jaką jest jego nazwa.

Supervisory

Oznacza, że dysponent posiada automatycznie wszystkie pozostałe
prawa obiektowe do obiektu dysp., a ponadto posiada prawo z kategorii
praw do własności obiektów (property right) o nazwie Supervisory.

Prawa do własności obiektów (property rights)

Uprawnienie

Znaczenie uprawnienia

Compare

Pozwala porównać wartość własności z jakąś inną wartością. W
praktyce oznacza to, że można np. sprawdzić czy nazwisko (własność
Surname) użytkownika brzmi Kowalski.

Read

Pozwala odczytać wartość własności. Jednocześnie prawo Read
pociąga za sobą posiadanie prawa Compare do danej własności.

Write

Pozwala zmieniać dowolnie własność obiektu, tj. wpisać do niej nową
wartość, zmienić wartość już istniejącą bądź ją skasować. Prawo
Write pociąga za sobą prawo Add or Delete Self.

Add or Delete Self

Prawo to ma sens tylko w stosunku do takich własności, które mają
charakter jakiejś listy (np. nazw). Oznacza, że można do listy, którą
stanowi własność dopisać lub skasować samego siebie. Ma to
praktyczne znaczenie np. w stosunku do własności obiektu 'grupa
użytkowników', jaką jest lista jej członków. Posiadanie tego prawa nie
daje jednak możliwości sprawdzenia, z jakich elementów składa się
dana lista.

Supervisory

Posiadanie prawa Supervisory do własności jakiegoś obiektu pociąga
za sobą posiadanie wszystkich innych praw do tych własności.

Reguły dotyczące praw dysponenckich w NDS

1.

Każdy bez wyjątku obiekt, podobnie jak pliki i katalogi, posiada własność o nazwie ACL
(Access Control List). Własność ta zawiera filtr IRF (Inherited Rights Filters) oraz listę
wszystkich

dysponentów

tego

obiektu

i

dysponentów

jego

własności

z

wyszczególnieniem praw posiadanych przez tych dysponentów.

Dodatkowo istnieje możliwość zbiorczego potraktowania wszystkich własności, która
polega na tym, że dowolne prawo z kategorii praw do własności może być nadane nie
jakiejś pojedynczej własności, ale wszystkim własnościom naraz. Praktycznie oznacza to
możliwość udostępnienia, np. użytkownikowi, prawa do odczytu wszystkich swoich
własności. Takie nadawanie praw wszystkim własnościom od razu nosi nazwę angielską
All Property Rights i jest często wykorzystywane. Ostatecznie więc, na liście ACL mogą
się również pojawić prawa zwane All Property Rights do wszystkich własności obiektu.

Jako że ACL to jedna z własności obiektu, to warto zapamiętać, że posiadanie do niej
prawa Write umożliwia nadawanie temu obiektowi lub jego własnościom nowych
dysponentów. Zatem posiadanie tego prawa do ACL jakiegoś obiektu to duży przywilej,
bo pozwala decydować, kto i co może z danym obiektem w sieci zrobić.

Fakt, że obiekt X literalnie figuruje w wykazie, jakim jest ACL obiektu Y oznacza, że X
ma określone prawa do obiektu Y, lub jego własności. Mówimy wówczas, że obiekt X
otrzymał jawne nadanie dysponenckie do obiektu Y (lub jego własności). Prawa
dysponenckie można uzyskać nie tylko w wyniku umieszczenia na Acces Control List
danego obiektu, ale i w innych okolicznościach (dziedziczenie, prawa grupowe - w
odróżnieniu od jawnego nadania są to prawa otrzymane niejawnie).

2.

Jeżeli obiekt typu 'Grupa użytkowników' jest dysponentem obiektu/własności, to każdy

użytkownik należący do tej grupy jest dysponentem tego obiektu/własności z
identycznym zestawem uprawnień, jakie ma obiekt typu grupa, do której należy. Tak
więc, sens stworzenia grupy użytkowników jest taki, że zamiast nadawać wielu
użytkownikom takie same prawa do jakichś obiektów, wystarczy stworzyć grupę,
wspomnianych użytkowników uczynić jej członkami, a grupie jako obiektowi tylko raz
nadać takie prawa, jakie nadawane byłyby każdemu użytkownikowi z osobna.

3.

Istnieje specjalny obiekt umowny o nazwie [Public]. Formalnie nie jest on umieszczony
w żadnym miejscu struktury NDS, ale za to ma specjalną cechę polegającą na tym, że
każdy obiekt w NDS ma takie same przypisania dysponenckie do katalogów, plików,
innych obiektów i ich własności jak on. Nawet nie trzeba się do sieci zarejestrować
(zalogować) by mieć takie prawa jak [Public]. Domyślnie, jeżeli administrator tego nie
zmieni, [Public] jest dysponentem obiektu [Root] z prawem Browse, dzięki czemu każdy
użytkownik w sieci może oglądać całą strukturę NDS.

4.

Każdy użytkownik posiada własność o nazwie Security Equals, co oznacza "ma takie

prawa jak". Jest to lista obiektów w strukturze NDS, których prawa dysponenckie
posiada dany użytkownik. Automatycznie trafiają na tą listę wszystkie grupy, do których
ten użytkownik należy. Na liście tej mogą się znaleźć inni użytkownicy, których
uprawnienia w ten sposób dany użytkownik przejmuje.

5.

Prawa dysponenckie podlegają dziedziczeniu, podobnie jak ma to miejsce w systemie

plików. Są dwa rodzaje dziedziczenia: dziedziczenie uprawnień od przodków (Ancestory
Inheritance) i dziedziczenie polegające na spływaniu praw dysponenckich (Rights Flow).
Prawa spływające podlegają z kolei filtrowaniu.

Dziedziczenie uprawnień

Dziedziczenie od swoich przodków polega na tym, że jakiś kontener (przodek) zostaje
dysponentem dowolnego obiektu. Wtedy uprawnienia tego kontenera przechodzą na zawarte w
nim obiekty, które w ten sposób też stają się dysponentami obiektu, którego dysponentem jest
ich kontener-przodek.
Drugi przypadek to spływanie praw. Jeżeli obiekt jest dysponentem jakiegoś kontenera, np. ma
w stosunku do niego prawo Browse, to takie samo prawo ma również do wszystkich obiektów
zawartych w kontenerze.
Ciekawa rzecz pojawia się przy dziedziczeniu praw do własności obiektów. Otóż nie mogą one
dla pojedynczych własności "spływać" w dół struktury, ponieważ nie wiadomo czy w obiekcie
położonym niżej w strukturze istnieje taka sama własność. Natomiast mogą spływać prawa do
wszystkich własności (All Property). Prawa typu obiektowego spływają zawsze w głąb struktury.
Prawa spływające mogą zostać anulowane poprzez ponowne jawne nadanie dysponenckie do
tego obiektu/własności. Takie nadanie jest silniejsze od dziedziczenia praw i powoduje, że od
tego obiektu począwszy, w głąb struktury (o ile był to kontener) spływają tylko te prawa, które
pojawiły się w wyniku tego nadania. Prawa spływające podlegają także filtrowaniu.

Filtrowanie praw dysponenckich

Ponieważ prawa dysponenckie obiektowe i prawa do wszystkich własności obiektu spływają w
głąb struktury, można na dowolny obiekt w NDS (lub na jego wszystkie własności) nałożyć
specjalny filtr, zwany Inherited Rights Filter, w skrócie IRF. Filtr IRF jest częścią własności
ACL obiektu. Blokuje on "spływanie" praw w dół struktury NDS według określonych reguł.
Zawiera on określony zestaw uprawnień, które mogą spływać na dany obiekt. Filtr może być
nakładany na dowolny obiekt dysponowany (albo wszystkie jego własności - All Property
Rights), a nie na dysponenta obiektu. Filtr zabrania dziedziczenia tych praw, które nie są w nim
wymienione (dotyczy to również uprawnienia Supervisory). Domyślnie filtr IRF zawiera
wszystkie możliwe uprawnienia i rolą operatora systemu jest wykluczyć z niego prawa zbędne
(tj. te, które nie powinny być dziedziczone).
W przypadku gdy do jakiegokolwiek obiektu dysponowanego (lub jego wszystkich własności)
odnoszą się uprawnienia dysponenta przypisane jawnie, to te prawa obowiązują ów obiekt
niezależnie od tego, jaki filtr IRF posiada. Zatem jawne nadanie jest silniejsze od filtrowania,
albo - inaczej mówiąc - filtr IRF działa na dany obiekt tylko w przypadku, w którym dysponent
dziedziczy prawa z wyższych kontenerów, a nie uzyskuje ich przez jawne nadanie dysponenckie.

Prawo Supervisory

W przeciwieństwie do systemu plików, w NDS prawo Supervisory może zostać usunięte z filtra
IRF. System pilnuje jednak, aby nie doszło do takiej sytuacji, gdy nikt nie ma prawa Supervisory
do danego obiektu. W efekcie niemożliwe jest np.:
-

usunięcie prawa S z filtra IRF obiektu, gdy nikt nie ma tego prawa nadanego jawnie

-

jeżeli tylko jeden obiekt posiada prawo S do danego obiektu, to prawo nie może być mu
odebrane.

Prawa efektywne

Jak więc widać system zabezpieczeń na poziomie NDS jest dość skomplikowany. Aby
odpowiedzieć na pytanie "co naprawdę obiekt X może zrobić z obiektem Y lub jego
własnościami?" trzeba "obliczyć" jego prawa efektywne. W tym celu należy:

1.

zsumować wszystkie prawa dysponenckie obiektu X (nadane jawnie lub odziedziczone
po przodku), prawa grup, do których ten obiekt należy i prawa wszystkich jego
równoważników (Security equals)

2.

jeżeli obiekt X nie ma praw nadanych jawnie, wziąć część wspólną praw z IRF obiektu Y
i praw spływających, jeżeli Y opatrzony jest filtrem IRF.

5. Praca w Novell Netware

Rejestrowanie się w systemie - logowanie

Każdy użytkownik na początku pracy w sieci musi zostać rozpoznany i zaakceptowany przez
system. Użytkowanie sieci polega na realizacji jednej lub wielu sesji pracy z siecią.
Identyfikacja użytkownika odbywa się przez podanie nazwy systemowej użytkownika oraz
(ewentualnie) hasła. Jeżeli system odnajdzie dane dotyczące rejestrującego się użytkownika (w
swoim rejestrze użytkowników), to udostępni mu swoje zasoby w stopniu określonym uprzednio
przez administratora sieci. W ten sposób rozpocznie się sesja pracy w sieci NetWare.
Proces rejestrowania się do sieci jest też zwany logowaniem (od ang. login). Zarejestrować się
do sieci można na kilka sposobów:

•

Z poziomu systemu DOS należy użyć polecenia LOGIN. Jego składnia jest następująca:
LOGIN <'nazwa_użytkownika'>
przy czym nazwa użytkownika musi zostać poprzedzona specyfikacją kontekstu w
eDirectory o ile kontekst bieżący nie jest tym, w którym umieszczono obiekt reprezentujący
użytkownika, np:

LOGIN .TOMASZ.SERWIS.FIRMA.

Logowanie z poziomu DOS jest obecnie wykorzystywane jedynie w wyjątkowych
sytuacjach, lecz znajomość pełnej nazwy użytkownika jest niezbędna np. do korzystania z
programów obsługi poczty.

•

W celu zarejestrowania się do sieci pod Windows należy użyć programu NetWare Login (lub
Novell Login – w zależności od wersji klienta Novell). W oknie dialogowym należy podać
nazwę rejestrowanego użytkownika (pole Username) i jego hasło (pole Password), jak
również nazwę drzewa NDS (nie wszędzie ‘stara’ nazwa NDS została zastąpiona przez
eDirectory), serwera i kontekstu rejestrowanego użytkownika.

Podczas logowania wykonywany jest skrypt logowania (Login Script), którego zadaniem jest
przygotowanie środowiska pracy. Raport z wykonania skryptu można prześledzić w oknie
skryptu (należy wyłączyć opcję automatycznego zamykania okna skryptu -> okno logowania ->
zaawansowane -> zakładka Skrypt Logowania -> automatyczne zamykanie okna)

Programy zgłoszeniowe - login scripty
Każdorazowe logowanie w systemie pociąga za sobą wykonanie programu zgłoszenia (login
script). Każdy użytkownik ma swój własny, prywatny program zgłoszenia (jest to jedna z

własności obiektu User). Brak prywatnego programu zgłoszenia spowoduje wykonanie
specjalnego, domyślnego programu zgłoszenia, który oprócz powitania usiłuje przypisać między
innymi ścieżkę przeszukiwań do katalogu \PUBLIC i do domniemanego katalogu zawierającego
zewnętrzne polecenia systemu DOS. Posiadanie przypisania takich napędów poszukiwawczych
jest konieczne dla wykonania jakichkolwiek poleceń administracyjnych i użytkowych w sieci.
Język programów zgłoszenia składa się z pewnej liczby instrukcji, posiada także swoje zmienne.
Podczas ćwiczenia wykorzystywane będzie jedynie polecenia MAP, opisane w rozdz. 2.

MAP

Definiuje oznaczenia literowe oraz ścieżki przeszukiwań:
MAP K:=PRV:DANE\PDF
W programach zgłoszenia steruje też trybem wykonywania poleceń MAP.
Włączenie lub wyłączenie wypisywania komunikatów o błędach w przypisaniach
napędów:
MAP ERRORS [OFF | ON]
Wyłączenie lub włączenie wyświetlania informacji o przypisanych napędach w
programie zgłoszenia:
MAP DISPLAY [OFF | ON]
Np.:

MAP DISPLAY OFF

Kończenie pracy

Poprawne zakończenie sesji pracy z siecią NetWare polega na wydaniu polecenia LOGOUT
(DOS), lub wybraniu opcji odłączenia od drzewa (Windows).

Praca w Windows - ikona paska zadań NetWare

W okienkowych systemach graficznych (np. Windows) wraz z podstawowymi plikami klienta
NetWare instalowanych jest wiele narzędzi ułatwiających pracę w sieci Novell. ‘Centrum
dowodzenia’ jest tu ikona paska zadań Novell NetWare (Rys. 5).

Rys. 5. Pasek zadań Novell

Kolejne pozycje umożliwiają:

•

Logowanie NetWare – zalogowanie do NetWare

•

Połączenia NetWare – wyświetlenie aktualnych połączeń oraz wylogowanie z systemu

•

Novell – Mapuj dysk sieciowy – przypisanie litery napędu do wybranego katalogu w
systemie plików NetWare, przez co katalog na serwerze jest widziany jako lokalny napęd.
Najważniejsze katalogi (głownie systemowe) są mapowane podczas logowania.

•

Odłącz dysk sieciowy – odłączenie zamapowanego napędu. Przechwycenie i zakończenie
przechwytywania portu drukarki

•

Programy usługowe NetWare – kopiowanie plików, wysyłanie wiadomości do innych
użytkowników, zarządzanie prawami do obiektów, zarządzanie skasowanymi plikami
(odpowiednikiem windowsowego kosza )

•

Zarządzanie użytkownikami dla DRZEWO – edycję własności użytkowników (np. adresu,
haseł)

•

Przeglądanie sieci, zmianę konfiguracji klienta Novell i inne

Zarządzanie bazą eDirectory – program NetWare Administrator
Program NetWare Administrator jest jednym z narzędzi do zarządzania bazą eDirectory (i NDS
w NetWare 4 i 5). Umożliwia tworzenie obiektów, zmianę ich własności, uprawnień, itp. W
ć

wiczeniu posłuży do zapoznania się ze strukturą eDirectory.

6. Ćwiczenia

Przed rozpoczęciem wykonywania ćwiczeń proszę zgłosić się do Prowadzącego po nazwę
konta (login) i hasło.

1.

Zapoznać się podstawowymi funkcjami klienta Novell (Pomoc klienta Novell)

2.

Przećwiczyć mapowanie i odłączanie woluminów

3.

Zapoznać się z własnościami obiektu użytkownik (Zarządzanie użytkownikami dla
KSSK_s03)

4.

Uruchomić NetWare Administratora (SYS:/Public/win32/nwadmn32.exe), zapoznać się z
budową bazy eDirectory (hierarchią kontenerów)

5.

W kontenerze (Organizational Unit) o nazwie odpowiadającej terminowi zajęć (np. SR09,
PT13) założyć kontener o nazwie <numer indeksu>. W kontenerze tym założyć konto
użytkownika ‘Admin<numer indeksu>’ nie korzystając z żadnych wzorców. Będzie on
administratorem utworzonego kontenera. Ustalić ograniczenia i prawa dla tego
użytkownika:

a.

Termin ważności konta – 1 września 2012r.,

b.

Obligatoryjne hasło, obowiązkowo zmieniane co miesiąc, unikalne, o minimalnej
długości 10 znaków,

c.

Użytkownik nie może się logować w niedzielę,

d.

Nadać użytkownikowi ‘Admin<numer indeksu>’ nieograniczone prawa do
administracji utworzonym kontenerem (użytkownikami, grupami, profilami, itd.).

e.

Katalog domowy utworzyć w katalogu PRV:/LSK1/.

6.

Zalogować się jako ‘Admin<numer indeksu>’, kolejne punkty wykonywać z tego konta.

7.

Utworzyć w swoim katalogu domowym katalogi ‘SHARE’ i ‘HOME’.

8.

W kontenerze <numer indeksu> utworzyć kontener CORP a w nim kontenerowy wzorzec
użytkownika (template) o nazwie ‘user<numer indeksu>’,

9.

W kontenerze CORPORATION utworzyć kontenery: PROD, HR, ACCOUNTING,
MANAGEMENT

10.

Utworzyć w kontenerze CORPORATION grupę, nazwać ją group<M*100+D>

*

, nadać jej

prawa do zapisu i odczytu plików w utworzonym katalogu ‘SHARE’.

11.

Zdefiniować następujące własności w stworzonym wzorcu użytkowników:

a.

Termin ważności konta – 1 lipca 2012r.,

b.

Obowiązkowe hasło, minimalna długość hasła – 8 znaków ,

c.

Wprowadzić ograniczenia czasu logowania – użytkownicy mogą się logować od
poniedziałku do piątku w godzinach od 8 do 16,

d.

Przypisać użytkownika do stworzonej w kontenerze CORPORATION grupy,

*

M = bieżący miesiąc, D = bieżący dzień (przykładowa grupa z 23 lutego to grupa223)

e.

Ustalić wolumen i katalog, w którym będą tworzone katalogi domowe
użytkowników (utworzony katalog ‘HOME’),

f.

W skrypcie logowania zamapować najważniejsze katalogi systemowe
(SYS:LOGIN, SYS:PUBLIC, PRV:)

12.

Korzystając z wzorca (template) utworzyć po kilku (2-3) użytkowników w każdym z
kontenerów utworzonych w pkt. 9 i katalogi domowe dla nich. Każdemu użytkownikowi
nadać początkowe hasło.

13.

W katalogu SHARE utworzyć następującą strukturę podkatalogów:

Administration

Accounting

Marketing

HR

Production

Service

Management
Security

14.

Zaimplementować następujący zestaw praw dostępu użytkowników do katalogów:

a.

Użytkownicy z kontenera PROD mają wszystkie uprawnienia (poza S) do
katalogu Production, ale tylko prawo odczytu w katalogu Service

b.

Użytkownicy z kontenerów ACCOUNTING i HR mają uprawnienia RWCM w
odpowiadających im katalogach, ale nie mają żadnych uprawnień do katalogu
Marketing (nie mogą go nawet 'widzieć').

c.

Użytkownicy z kontenerów HR, ACCOUNTING, MANAGEMENT nie widzą
katalogu Security ani Production.

d.

Jeden z użytkowników z kontenera MANAGEMENT ma wszystkie prawa do
katalogu Management.

e.

Dwóch użytkowników z kontenera HR oraz jeden z kontenera ACCOUNTING
mają możliwość przeglądania zawartości katalogów i plików umieszczonych w
katalogach domowych wszystkich użytkowników.

15.

Zalogować się na utworzone konta, sprawdzić poprawność ich funkcjonowania (poprawność
mapowania, prawa do katalogów, ograniczenia hasła i czasu logowania).