8_Administracja_Novell

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.

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.

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.

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.

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.

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.

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

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  (

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

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ą

pliki

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

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

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

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

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

dysponentów

jego

własności

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

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.

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.

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.

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:

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)

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)

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

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

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

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:

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

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

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

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

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

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

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

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

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:

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

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

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

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)

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

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

Production

Service

Management
Security

14.

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

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

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ć').

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

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

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