Napisane przez: kokocinskiandrzej | 30 listopada 2011

ACS – strojenie


ACS – strojenie

Filtrowanie zdarzeń.

Po zainstalowaniu Audit Collection i po konfiguracji forwardów kolektorów z przyjemnością  zauważyliśmy że  zaczęliśmy gromadzić wszystkie zdarzenia z dziennika zabezpieczeń. Bardzo często wile z tych zdarzeń nie jest na tyle krytyczna aby je zbierać z uwagi na małe znaczenie biznesowe lub też techniczne. Dobrym przykładem jest zdarzenie "wylogowaniu użytkownika",(z perspektywy bezpieki jest to jedno z ciekawszych zdarzeń). Dla administratora w większości przypadków o wiele bardziej interesujące jest , kto i kiedy wprowadził zmiany w systemie

Konsekwencje zbierania wszystkich zdarzeń są dość oczywiste, baza szybko puchnie. W OpsMgr2007 posiadamy możliwość filtrowania zdarzeń. Jest to filtr który może ograniczyć przyrost danych w ACS bazie danych. Mechanizm polega na stworzeniu kwerendy  i dołączenie jej  z narzędzi do zarządzania ACS – AdtAdmin (% systemroot% \ system32 \ Security \ Adtserver \).

Na przykład, nie chcemy, wyfiltrować zdarzenie " User Logoff" (EventID = 538 dla WIN 2008 EventID = 4634 ) oraz " Privileged Service Called " (EventID = 577 dla WIN 2008 EventID = 4673 ). Filtr będzie wyglądać tak:

SELECT * FROM AdtsEvent wheare (EventID = 538 OR EventID = 577)

Ponadto w dzienniku zabezpieczeń magazynowanych jest wiele zdarzeń logowania, generowanych z perspektywy kont usług (np. computer), polityki aktualizacji itp. Filtrowanie tych zdarzeń , może oprzeć na stworzeniu spójnej kultury nazewniczej (wspólne cechy kont usług odróżniających od zwykłych kont użytkowników). Na przykład, nazwy wszystkich  kont serwisowych mogą wyglądać xx_ (np. xx_exchange lub xx_sql) poprzez taką kulturę możemy filtrować dzienniku zdarzeń bazy danych (logowanie do sieci, EventID = 528 i 540 dla windows 2008 EventID = 4624) wyłączając te konta . Filtr z poprzedniego przykładu, możemy dodać:

SELECT * FROM AdtsEvent Wheare (EventID = 538 OR EventID = 577 OR ((HEADERUSER LIKE ‚% xx_%’) AND (EventID = 528 OR EventID = 540))

Dodanie na kolektorze :

% Systemroot% \ system32 \ Security \ Adtserver \ AdtAdmin.exe-SetQuery: "SELECT * FROM AdtsEvent Wheare (EventID = 538 OR EventID = 577 OR ((HEADERUSER LIKE ‚% xx_%’) AND (EventID = 528 OR EventID = 540))”

Przydatne linki :

Wydarzenia audytu bezpieczeństwa dla systemów Microsoft Windows Server 2008 i Microsoft Windows Vista

Wydarzenia audytu bezpieczeństwa dla systemów Microsoft Windows Server 2008 R2 i Microsoft Windows 7

Należ pamiętać : Filtrowanie odbywa się na kolektorze i jego obciążanie wzrasta poprzez zastosowane filtry . Zdarzenia będą nadal przychodziły do kolektora jednak są one przetwarzane, zamiast ich sortowania są odrzucane zależnie od reguł zawartych w filtrze. Filtrowanie nie zmniejsza obciążenie sieci. Sposoby, zmniejszenia obciążenie na kolektorze są zależne od ustawienia audytu.

Priorytety.

Duże obciążenie na kolektorze lub brak możliwości magazynowania w bazie danych (np. utracone połączenie z serwerem) zdarzeń, które są wysyłane do kolektora, są kolejkowane. Rozmiar kolejki domyślnie 262 144 zdarzeń. Domyślna maksymalna wielkość kolejki jest 128 MB.

Gdy rozmiar kolejki osiągnie 75% maksymalnej domyślnej wartości – połączenia z nowymi forwarderami zostanie przerwane. Istniejące połączenie nadal będą podtrzymywane. Ta wartość znajduje się w HKLM \ System \ CCS \ Services \ \ AdtServer Parameters \ BackOffTreshold.

Kiedy zajętość kolejki osiągnie 90% maksymalnej dozwolonej wartości – zacznie się proces ich zamykania. Ta wartość znajduje  w HKLM \ System \ CCS \ Services \ \ AdtServer Parameters \ DisconnectTreshold.

Należy zaznaczyć, że w tym procesie ważny jest priorytet. Priorytet jest liczbą od 1 do 99. Najwyższym priorytetem jest  99, domyślnie przydzielony jest priorytet równy jeden. Priorytet równy 99 ma pierwszeństwo przed wszystkimi innymi..

Aby utworzyć grupę forwarderów i przypisać wartość priorytetu, należy uruchomić następujące polecenie:

AdtAdmin.exe-add /group:Group:GroupName /value: 50

50 jest wartością priorytetu. Aby wyświetlić listę istniejących grup i ich priorytetów:

C: \ Windows \ System32 \ Security \ AdtServer> adtadmin-listgroups
Wartość Nazwa
1, domyślna
2, TestGroup
50, MyGroupName

Utworzenie forwardera do określonej grupy tworzymy za pomocą polecenia:

AdtAdmin.exe -updforwarder /Forwarder: MyForwarderName /group:Group:GroupName

Inne parametry AdtAdmin.exe zawarte są w Centrum pomocy (adtadmin /?).

Reklamy
Napisane przez: kokocinskiandrzej | 22 listopada 2011

SCOM 2007: Jak wykonać kopię zapasową klucza szyfrowania


SCOM 2007: Jak wykonać kopię zapasową klucza szyfrowania

Jednym z bardzo ważnych zadań a wręcz kluczowych jest odzyskanie kontroli nad SCOM po awarii RMS. Ażeby wypromować nowego RMS-a należy posiadać klucz

Do czego stosowany jest klucz

Ten klucz jest używany do przechowywania danych w SCOM. Gwarantuje nam to, że dane w bazie danych są poufne i zaszyfrowane. RMS używa tego klucza do odczytu i zapisu danych do bazy danych ..

Co się stanie jeśli nie mamy klucza- czy odzyskamy SCOM-a  produkcyjnie ?

Jeśli nie posiadamy tego klucza, nie można podłączyć się do istniejącej bazy danych RMS i stracimy wszystkie zmiany konfiguracji co oznacza w konsekwencji nową  instalacje OpsMgr .. (jest to jedno z pytań na egzaminie 70-400)

Należy pamiętać, że najlepszym rozwiązaniem jest wykonanie kopii zapasowej klucza po instalacji i po wszelkich zmianach związanych z kontem RunAs.

Zobaczmy, jak wykonać kopię zapasową klucza.

Istnieją dwie metody: interfejsu graficznego lub wiersza polecenia.

Graficzny interfejs użytkownika

Należy zalogować się na RMS-a jako admin.

Należy uruchomić wiersz polecenia jako administrator i przejść do podkatalogów gdzie została dokonana instalacji SCOM.

clip_image001

Następnie uruchomić securestoragebackup.exe

clip_image002

Uwaga: Securestoragebackup.exe będzie dostępny tylko w przypadku zainstalowanej konsoli zarządzania na RMS. W przeciwnym razie, należy skopiować z nośnika  instalacyjnego SupportTools

Następnie należy uruchomić kreatora Backup Key Encryption :

clip_image003

następnie next> i wybrać kopię zapasową klucza szyfrowania.

clip_image004

Wybieramy lokalizacji i zapisujemy plik

Dobrze jest zastanowić się gdzie będziemy przechowywać zbackupowany klucz pozostawienie klucza na serwerze RMS, w przypadku awarii tego serwera, jest oczywistym że nie będziemy mogli go odzyskać z uwagi na jego awarie.

Dobrze jest zrobić kopie klucza na MS- serwery

Tak więc, należy określić lokalizację pliku i kontynuować.

clip_image006

Wprowadzamy hasło do pliku . Oczywiście istotne jest aby pamiętać te hasło

clip_image008

Procedura składowania trwa tylko kilka sekundclip_image010

Korzystanie z wiersza poleceń:

Należy zalogować się do serwera RMS jako admin

Otwieramy wiersz polecenia jako administrator i przechodzimy do instalacji SCOM. W moim przypadku zapisany domyślnie – c: \ program files \ system operacyjny centrum Manager 2007 \

securestoragebackup.exe /? dla składni polecenia.

Składnia polecenia wygląda tak: securestoragebackup <nazwa_pliku> kopii zapasowej

clip_image012

jeszcze oczywiście hasło ..

… I END

Napisane przez: kokocinskiandrzej | 8 listopada 2011

Struktury bazy danych ACS oraz jej ustawienia


Struktury bazy danych ACS oraz jej ustawienia

ACS jest bazą danych, która każdego dnia tworzy nową sekcję, dzieje się to podczas codziennego maintenance-u bazy danych. Proces tworzy nową partycję, a następnie zamyka i reindeksuje ją.

Jest kilka tabel, które z uwagi na swoją wyjątkowość zasługują na przyjrzenie się im.

Pierwsza z nich jest to dtPartition

clip_image002

Statusy partishena są trzy:

  • 0 – otwarta, status pracy.
  • 1 – zamknięta, gotowy do indeksowania
  • 2 – jest zamknięta, indeksowana, gotowy do czyszczenia

Przy prawidłowej pracy, baza ze statusem "1" praktycznie nie występuje. Jednak zdarzały się i to dość często błędy ze statusem „1” w wersji SCOM 2007 bez sp1. Jeśli jednak pojawiłby się status "1", możemy uruchomić następujące polecenia w celu przygotowania jej do  oczyszczania:

Use OperationsManagerAC

DtPartition UPDATE

SET Status = 2

WHERE status = 1

Druga ważną tabelą jest dtConfig. Jak sama nazwa wskazuje, jest tabelą konfiguracji.

Przyjrzyjmy się jej: clip_image004

Konwersja znacznika czasu do czasu lokalnego

  • 1 = konwersja do czasu lokalnego.
  • 0 = Universal Time Coordinate (UTC)

Wykonywana  konserwacji indeksu (Index Service)

  • 1 = włączona
  • 0 = wyłączona

Wartość tego parametru określa, kiedy ACS będzie używać innej tabeli do przechowywania danych, począwszy od północy wedle czasu UTC.

82 800 = 82800/60 * 60 = 23 UTC

Średnia = 82 800 1:00 dla Warszawy. (Nawiasem mówiąc, jest to widoczne w dtPartition:))

Interwał w sekundach przełącznika tabeli =Wartości 86 400 = co 24 godziny, to znaczy że tabela zostanie włączona, co 24 godziny o 01:00.

Liczba partycji

Liczba partycji jest wartością rzeczywistą liczby dni przechowywania informacji.

Domyślnie – 15.

Pewien szczegół

W rejestrze posiadamy kilka opcji:

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ AdtServer \ Parameters

EventRetentionPeriod (w godzinach)

Widziałem kilka źródeł, które mówią, że jest to liczba godzin, dla których zdarzenia będą przechowywane w bazie danych ACS. Jednak  jest to informacja błędna. Ten parametr określa liczbę godzin, dla których dane są rejestrowane w „spedytorach” kolektora. Ta opcja nie ma wpływu na liczbę partycji oraz czasu przechowywania danych w ACS. Domyślnie jest to 336 godzin (odpowiednik 14 dni).

Napisane przez: kokocinskiandrzej | 8 listopada 2011

Active directory partycje


Active directory partycje

Wyobraźmy sobie że może być wiele odwołań w skali od kilkudziesięciu do miliona i odwołania te odnoszą się do obiektów w Active Directory. Dane te są magazynowane w logicznych partycjach w taki sposób że każdy DC nie magazynuje całego dirctory lecz dokonuje usystematyzowania logicznego w postaci partycjonowania danych kategoryzowanych zgodnie z nazwą schematu tzn. obiektów nazw grupy obiektów będących w logicznych kategoriach, tak więc każdy obiekt może być zarządzany i replikowany zależnie od odpowiedniego priorytetu. W Active Directory największy z takich logicznych kategorii jest nazywany directory partycją.

Każdy DC zawiera najmniej jeden directory partycje, tak że magazyn danych, zawiera użytkowników, grupy, OU. Ponadto każdy DC magazynuje również dwie „non-domain” partycje directory takie jak magazyn „forest-wide” czyli forestu dane, w każdym zawarty jest schemat i konfiguracja.

Kontrolery domeny przechowują kopie kontekstów nazw w swoich domenach. Za pomocą tych kopii realizowany jest szerszy dostęp tzn zostaje przyspieszone żądanie wyszukiwania w obrębie swojej domeny i domen zaufanych.

Dane magazynu zawierają dane dla pojedynczego forestu. Chociaż pojedynczy directory, posiada kilka danych directory to dane są rozproszone w całej domenie, dopóki inne dane są rozproszone w całym foreście to nie mają odniesienia dla granicy domeny. W windows serwer 2003 i 2008 dane mogą być również dystrybuowane na DC zgodnie z potrzebami aplikacji. Może zaistnieć taka sytuacja,gdzie będzie potrzeba stworzenia pewnego rodzaju zakresu który, będzie określany przez zapotrzebowanie aplikacji. Występują trzy typy danych, które są magazynowane w Active Directory:

Dla całej domeny: Specyficzne dane są magazynowane w domain directory partycji. Pełna do zapisu replika domain directory partycji, która jest replikowana do każdego DC w domenie.

Dla całego forestu: Dla całego forest dane są w dwóch directory partycji: konfiguracji directory i schemat directory. Konfiguracji kontener jest najwyższym obiektem w konfiguracji directory partycji natomiast schemat kontener jest najwyższym obiektem schemat directory partition.

FULL Pełna do zapisu replika w konfiguracji directory partycji jest replikowana do każdego DC w forescie

A „read-only” replika dla schematu directory partycji jest replikowana do każdego DC w forescie. Schemat do zapisu znajduje się tylko na DC zawierający schema master role .

Oprócz pełnej do zapisu repliki obejmującej domenę, możemy znaleźć specjalną funkcjonalność będącą na DC jako rola global catalog . GC również przechowuje część, read-only repliki dla każdego innego domain directory partycji w foreście.

Application data: Aplikacje mogą używać nowego typu directory partycji, nazywanych aplikacyjnym directory partycja. Magazynowane dane aplikacyjne są wyspecyfikowane mogą znajdować się w zakresie zdefiniowanych mniejszym niż cały forest lub domena. Takie dane mogą być charakterystyczne dla innych często zmieniających (dynamicznych) lub posiadające krótki czas użytkowania. Dla przykładu DNS może używać aplikacji directory partycji do przechowywania dynamicznych update DNS zone danych na tylko tych DC które są DNS server.

Napisane przez: kokocinskiandrzej | 8 listopada 2011

Schemat usługi Active Directory


Schemat usługi Active Directory

Schemat Active Directory jest zbiorem definicji wszystkich typów obiektów katalogu i ich atrybutów. System określa sposób przechowywania i konfiguracji AD dla wszystkich użytkowników, komputerów i innych obiektów, całej struktury Active Directory. Układ jest chroniony przez listy kontroli dostępu, (poufnej listy kontroli dostępu – DACL), kontroluje możliwe atrybuty każdego obiektu w Active Directory. W istocie, jest podstawową definicją samego katalogu oraz funkcjonalnością domeny środowiska. Delegowanie zarządzania systemem powinno być starannie weryfikowane i zmieniane w schemacie AD

Obiekty schematu
Obiekty struktury Active Directory – User (użytkownika), Printer (drukarka), komputer (PC) i strony (witryny) – w rozumieniu obiektów schematu. Każdy obiekt ma wykaz cech, które go definiują i mogą być używane w tym obiektcie. Na przykład obiekt użytkownik dla pracownika nazwie Ala Kowalski będzie miała atrybut Imię Ala atrybut Nazwisko Kowalski. Oprócz tak zwanych podstawowych , można przypisać inne atrybuty: nazwa jednostki, adres e-mail i wiele innych. Użytkownicy, wyszukują informacje w usłudze Active Directory, na podstawie informacji zwartych w atrybutach danych klas obiektów , na przykład, wyszukanie wszystkich użytkowników, w dziale sprzedaży.

Rozszerzanie schematu
Jedną z głównych zalet struktury Active Directory jest możliwość bezpośredniego modyfikowania i rozszerzania schematu, aby obejmowały niestandardowe atrybuty. Zwykle rozszerzenie atrybutów odbywa się w trakcie instalowania najnowszej wersji programu np. Microsoft Exchange, jednak oczywistym jest to, że biznes może potrzebować dodatkowych pól w związku z dostępem do aplikacji lub też określeniem przynależności strukturalnej danego obiektu

Zmiany dokonywane na obiektach
ADSI (Active Directory Service Interfaces )jest podstawowym narzędziem przeznaczonym do modyfikacji obiektów (ale nie tylko) w Active Directory. Umożliwia również przejrzenie zawartości z katalogu LDAP. Narzędzie ADSI, można przeglądać, usuwać i modyfikować atrybuty programu. Z modyfikacją systemu powinniśmy być szczególnie ostrożni, ponieważ problemy, które mogą pojawiać się po naszej ingerencji , mogą być bardzo trudne do naprawienia.

Napisane przez: kokocinskiandrzej | 7 listopada 2011

Active directory partycje


Active directory partycje

Partycja = kontekst Nazw

Forest vs. Domain partycje
Domena- Specyficzne dane domeny
pełna kopia na każdym DC dla danej domeny
Forest – storowany na dwóch partycjach – schemat i konfiguracja
pełna kopia na każdym DC w foresiecie
schemat jest tylko read-only z wyjątkiem roli schemat master FSMO
Global Catalog

Wyobraźmy sobie że może być wiele odwołań w skali od kilkudziesięciu do miliona i odwołania te odnoszą się do obiektów w Active Directory. Dane te są magazynowane w logicznych partycjach w taki sposób że każdy DC nie magazynuje całego dirctory lecz dokonuje usystematyzowania logicznego w postaci partycjonowania danych kategoryzowanych zgodnie z nazwą schematu tzn. obiektów nazw grupy obiektów będących w logicznych kategoriach, tak więc każdy obiekt może być zarządzany i replikowany zależnie od odpowiedniego priorytetu. W Active Directory największy z takich logicznych kategorii jest nazywany directory partycją.

Każdy DC zawiera najmniej jeden directory partycje, tak że magazyn danych, zawiera użytkowników, grupy, OU. Ponadto każdy DC magazynuje również dwie „non-domain” partycje directory takie jak magazyn „forest-wide” czyli forestu dane, w każdym zawarty jest schemat i konfiguracja.

Kontrolery domeny przechowują kopie kontekstów nazw w swoich domenach. Za pomocą tych kopii realizowany jest szerszy dostęp tzn zostaje przyspieszone żądanie wyszukiwania w obrębie swojej domeny i domen zaufanych.

Dane magazynu zawierają dane dla pojedynczego forestu. Chociaż pojedynczy directory, posiada kilka danych directory to dane są rozproszone w całej domenie, dopóki inne dane są rozproszone w całym foreście to nie mają odniesienia dla granicy domeny. W windows serwer 2003 i 2008 dane mogą być również dystrybuowane na DC zgodnie z potrzebami aplikacji. Może zaistnieć taka sytuacja, gdzie będzie potrzeba stworzenia pewnego rodzaju zakresu który, będzie określany przez zapotrzebowanie aplikacji. Występują trzy typy danych, które są magazynowane w Active Directory:

Dla całej domeny: Specyficzne dane są magazynowane w domain directory partycji. Pełna do zapisu replika domain directory partycji, która jest replikowana do każdego DC w domenie.

Dla całego forestu: Dla całego forest dane są w dwóch directory partycji: konfiguracji directory i schemat directory. Konfiguracji kontener jest najwyższym obiektem w konfiguracji directory partycji natomiast schemat kontener jest najwyższym obiektem schemat directory partition.

FULL Pełna do zapisu replika w konfiguracji directory partycji jest replikowana do każdego DC w forescie

A „read-only” replika dla schematu directory partycji jest replikowana do każdego DC w forescie. Schemat do zapisu znajduje się tylko na DC zawierający schema master role .

Oprócz pełnej do zapisu repliki obejmującej domenę, możemy znaleźć specjalną funkcjonalność będącą na DC jako rola global catalog . GC również przechowuje część, read-only repliki dla każdego innego domain directory partycji w foreście.

Application data: Aplikacje mogą używać nowego typu directory partycji, nazywanych aplikacyjnym directory partycja. Magazynowane dane aplikacyjne są wyspecyfikowane mogą znajdować się w zakresie zdefiniowanych mniejszym niż cały forest lub domena. Takie dane mogą być charakterystyczne dla innych często zmieniających (dynamicznych) lub posiadające krótki czas użytkowania. Dla przykładu DNS może używać aplikacji directory partycji do przechowywania dynamicznych update DNS zone danych na tylko tych DC które są DNS server.

Napisane przez: kokocinskiandrzej | 7 listopada 2011

LDAP cz.3


Schemat

Schemat katalogu ma następujące właściwości:

  1. Jest zbiorem zasad, które opisują przechowywane dane.
  2. Wspierają spójność i jakość.
  3. Zmniejszają dublowanie danych.
  4. Zapewniają, że ​​aplikacje mają spójny interfejs do danych.
  5. Określają klasy obiektów oraz zasady systemu, które powinien spełniać rekord.
  6. Zawierają następujące informacje:
    • niezbędne atrybuty;
    • dopuszczalne atrybuty;
    • metody porównawcze atrybutów;
    • ograniczenie przechowywania atrybutów,
    • ograniczenie nośników, takich jak zakaz duplikatów, itp.

Schemat katalogu jest zestawem definicji i ograniczeń na strukturę DIT, jak również możliwe sposoby rekordy nazw. Schemat określa informacje, które mogą być przechowywane w rejestrze, atrybuty używane do reprezentowania tych informacji i jej organizację w hierarchii, umożliwia ich wyszukiwanie. Definiuje zasady zgodności wartości atrybutu i wartość wyrażenia.

Formalnie, schemat katalogu składa się z zestawu:

  1. Nazw formatu – charakteryzują stosunki między konwencjami nazewnictwa dla klas strukturalnych obiektu.
  2. Zasad określających konstrukcję DIT- nadają nazwy, pod którymi mogą być zapisane
  3. Definicji zasad zachowania DIT, które specyfikują możliwe atrybuty, rekordy należące do strukturalnych klasa obiektu.
  4. Definicji klas obiektów, które opisują podstawowy zestaw obowiązkowych i opcjonalnych atrybutów, które mogą i powinny być obecne w tej klasie
  5. Definicji typów atrybutów, które określają identyfikator obiektu dla atrybutu, jego składniki, związane z nim reguły dopasowania.
  6. Składni definicji LDAP.
Klasy obiektów

Klasa Object jest identyfikowana przez rodziny obiektów, które mają wspólne cechy.

Podstawowe właściwości klasy obiektów:

  1. Klasy są używane do informacji o grupie.
  2. Klasy zapewniają następujące cechy:
    • określają niezbędne atrybuty;
    • określają dopuszczalne atrybuty;
    • stanowią prosty sposób grupowania informacji.
  3. Wpisy mogą mieć wiele klas obiektów ,wymaganych cech i ważnych w tym przypadku powiązań atrybutów z daną klasą.
  4. Mają również na celu kontrolę funkcjonowania katalogu.

Klasy Object (podklasy) można uzyskać z innej klasy obiektów (nadrzędnych).

Każda klasa obiektu określa zbiór atrybutów, obecnych w pozycji należącej do klasy, oraz zbiorów atrybutów, które mogą być obecne w tych rejestrach.

Każda klasa obiektu definiowana jest jako jedna z trzech klas obiektów: abstract, strukturalna, lub pomocnicza.

Każda klasa obiektu jest identyfikowana przez identyfikator obiektu (OID), i (opcjonalnie) przez jedną lub więcej krótkich nazw (opisów).

n Abstrakcyjne — Abstract. Klasy istnieją tylko po to, aby mogły z nich dziedziczyć inne klasy. W Active Directory istnieje 14 klas abstrakcyjnych, takich jak Top (Wierzchołek), Leaf (Liść), Connection-Point (Punkt połączenia), Device (Urządzenie), Person (Osoba) i Security Object (Obiekt zabezpieczeń).

n Pomocnicze — Auxiliary. Używane do rozszerzania definicji klasy abstrakcyjnej. W Active Directory istnieją cztery tego typu klasy: Mail-Recipient (odbiorca poczty), Sam-Domain (przykład domeny), Sam-Domain-Base (przykład bazy domeny) i Security-Principle (pryncypia zabezpieczeń).

n Strukturalne — Structural. Klasy, które posiadają obiekty w katalogu. Przykładami mogą być klasy User (użytkownik), Group (grupa), Computer (komputer), czy Server (serwer).

Dziedziczenie klas obiektów

—————————

Dziedziczenie klas obiektów ma następujące właściwości:

  • Klasy obiektów mogą być uzyskane z innych klas obiektów.
  • W przypadku dziedziczenia może nastąpić rozszerzenie właściwości innych klas obiektów.
  • Dla klas strukturalnych i abstrakcyjnych nie ma wielokrotnego dziedziczenia.
  • Na klasy obiektów mogą się nakładać zasady.
  • Istnieje specjalna klasa. W tej klasie jest tylko konieczny atrybut objectClass. Gwarantuje to, że wszystkie wpisy mają atrybut objectClass.
Administracyjne i funkcjonalne katalogi informacji

Weźmy pod uwagę niektóre aspekty administracyjne i operacyjne modelu informacyjnego LDAP. Niektóre implementacje mogą wspierać LDAP, i inne aspekty modelu.

Atrybut ObjectClass

rekord obiektu, jest (wraz z innymi informacjami) używany w połączeniu z systemem użytkownika. Wartości tego atrybutu mogą być modyfikowane przez klientów, atrybutu objectClass nie można usunąć.

Funkcjonalne

Niektóre atrybuty, zwane funkcjonalnymi, używane są lub utrzymywane przez serwery w celach administracyjnych i funkcjonalnych.

Atrybuty funkcjonalne są zazwyczaj niewidoczne. Będą zwracane jako wyniki wyszukiwania.

Wpisy mogą obejmować, między innymi, następujące funkcjonalne atrybuty.

  • creatorsName: DN użytkownika, który dodał wpis w katalogu.
  • createTimestamp: czas, kiedy rekord został dodany do katalogu.
  • modifiersName: DN użytkownika, który ostatnio zmodyfikował ten wpis.
  • modifiersTimestamp: czas, kiedy rekord został ostatnio zmieniony.

Serwery muszą obsługiwać creatorsName, createTimestamp, modifiersTimestamp modifiersName oraz wszystkie rekordy w DIT.

Każdy atrybut jest przechowywany w katalogu LDAP, ma specyficzną składnię (np. typ danych), która nakłada ograniczenia na strukturę i format jego wartości. Porównanie wartości nie jest częścią definicji składni i oddziela zasady zgodności. Zasady dopasowania określa oświadczenie wartości argumentu, który również ma pewne składniki. Weźmy pod uwagę podstawowy zestaw składni i dopasowania zasady korzystania z niektórych atrybutów w katalogach LDAP.

Definiujemy składnie wymaganą do działania z katalogu i ogólnego przeznaczenia. Jednak definicja dodatkowych arbitralnych składni\ nie zawsze jest pożądana, ponieważ zmniejsza interoperacyjności.

Przypisywanie wartości atrybutu

Typ atrybut zawiera opis AttrubuteValueAssertion oraz odpowiednie reguły do przypisywania typu wartości.

 AttributeValueAssertion:: = SEQUENCE { 
       attributeDesc
         AttributeDescription, 
       assertionValue
         AssertionValue 
 } 
 AssertionValue:: = OCTET STRING 

Składnia AssertionValue zależy od kontekstu operacji wykonywanych LDAP. Na przykład, RÓWNOŚĆ składni, pasująca do reguły dla atrybutu, który jest używany podczas wykonywania Porównaj.

Zasady zgodności

Zasady dopasowania używane są do porównywania implementacji wartości atrybutów katalogu wartości podczas wykonywania wyszukaj i porównaj. Są one również wykorzystywane do porównywania nieznanych i unikatowych nazw z nazwą rekordu. Podczas modyfikacji zasada porównywania jest używana do identyfikacji wartości, która powinna zostać usunięta, tak aby zapobiec, posiadanie dwóch równorzędnych wartości atrybutu.

DIT Content Rules

Rekord DIT określa, które klasy pomocnicze obiektu są dozwolone, oraz jakie są dodatkowo dla atrybutu (wg rodzaju) wymagane, dozwolone lub niedozwolone w rekordzie.

Lista nieprawidłowych atrybutów nie może zawierać żadnych atrybutów wymienionych jako obowiązkowe w regule strukturalnych klas obiektów, lub zależnej od klas obiektów.

Każda reguła jest określona przez zawartość OID, jak również krótkie nazwy (deskryptory) strukturalne klasy obiektów, do których są stosowane.

Wpis powinien zawierać wszystkie atrybuty potrzebne klasie obiektu, do której rekord należy, jak również wszystkie cechy wymagane przez zasady zarządzania treścią.

Rekord może zawierać nie zabronione atrybuty, które są ważne dla klasy obiektów, do których zapis należy, jak również wszystkie cechy które są ważne do zarządzania treścią zasady.

LDIF

LDIF jest formatem wymiany danych i posiada następujące właściwości:

  • Reprezentuje LDAP jako tekst.
  • Posiada czytelny format.
  • Umożliwia w łatwy sposób modyfikowanie danych.
  • Służy do zmiany dużych ilości danych w następujący sposób: – dump bazy danych, uruchomienie skryptu do importu
  • umożliwia archiwizację danych do innych systemów.

LDIF przykład:

 dn: uid = Ania, ou = pracownik,
 dc = pl, dc = msu
 uid: Ania
Projektowanie topologii

Drzewo katalogów może składać się z wielu serwerów fizycznych.

W celu określenia topologii należy wziąć pod uwagę:

  • Zwiększenie wydajności.
  • Zwiększenie dostępności.
  • Lepsze zarządzanie katalogiem.
  • Możliwość przechowywania więcej rekordów niż na jednym serwerze.
Skierowania

Serwer LDAP może zawierać odnośniki (skierowania) do innych serwerów LDAP. Umożliwiają one w operacjach wyszukiwania, klientom możliwość otrzymywania informacji z wielu serwerów.

  • Klient wysyła żądania do serwera ldap.
  • Serwer zwraca skierowanie do serwera 2.
  • Klient ponownie wysyła żądanie do serwera 2.
  • Server 2 zwraca informacje do klienta.
Nazewnictwa głównego kontekstu i danych serwera

Nazewnictwo głównego kontekstu jest rekordem dla serwerów na najwyższym poziomie. Niektóre serwery mogą mieć wiele korzeni kontekstów nazewnictwa.

Serwer LDAP musi dostarczyć informacje o sobie, jak również informacje specyficzne dla każdego serwera. Jest to przedstawone jako grupa atrybutów umieszczonych w DSE root (DSA-konkretny wpis), która jest wymieniony w LDAPDN o zerowej długości. Atrybuty te są one powtarzalne, podlegają kontroli dostępu, jeśli klient będzie szukał obiekt bazowego dla katalogu głównego filtra (objectClass =*), zwracać będzie atrybuty powrotu

Zidentyfikowane są następujące atrybuty DSE root.

  • altServer: atrybut list adresów URL, wskazuje na alternatywne serwery, które mogą być połączone, gdy serwer jest niedostępny. Jeśli serwer nie zna żadnych innych serwerów, które można wykorzystać ten atrybut jest nieobecny.
  • namingContexts: atrybut zawiera listę prefiksów kontekście serwera. Jeśli serwer jest klasy serwer, musi określić pusty ciąg (root DIT). Atrybut ten pozwala klientowi wybrać odpowiednie obiekty bazy do przeszukiwania, gdy łączy się z serwerem.
  • supportedControl: identyfikatory listy atrybutu obiektu, które określają, jak zarządzać żądaniami , obsługiwanymi przez serwer. Jeśli serwer nie obsługuje kontroli zapytania tzn że atrybutu tego nie ma.
  • supportedExtension: identyfikatory listy atrybutu obiektu, które definiują operacje rozszerzone obsługiwane przez serwer.
  • supportedLDAPVersion: atrybut zawiera listę wersji LDAP, które obsługuje serwer.
  • supportedSASLMechanisms: atrybut listy mechanizmów SASL, który identyfikuje serwer. Zawartość tego atrybutu może zależeć od aktualnego stanu sesji. Jeśli serwer nie obsługuje mechanizmu SASL, atrybut ten nie musi być obecny.

DSE korzeni może również obejmować subschemaSubentry atrybutu. Jeśli tak, to wskazuje na subcircuit, który zarządza atrybutami DSE root.

Replikacja

Replikacja jest to metoda do przechowywania kopii danych katalogowych na wielu serwerach.

Podczas korzystania z replikacji zwiększa się:

  • Niezawodność – wile kopi na różnych serwerach
  • Dostępność – łatwiej jest znaleźć dostępny serwer.
  • Performance – mogą korzystać najbliższego serwera.
  • Speed ​​–zapytania wysyłane do wielu ldap szybsze odpowiedzi.
Napisane przez: kokocinskiandrzej | 7 listopada 2011

LDAP cz 2


Model informacyjny

DIB zawiera dwa rodzaje informacji:

  1. Informacje o użytkowniku – informacje dostarczone przez użytkownika – mogą być zmienione.
  2. Administracyjne i funkcjonalne – informacje, które są używane do udostępniania funkcjonalności katalogu.

Klasa Object jest identyfikowana przez rodzinę obiektów, które mają wspólne cechy. Każdy obiekt należy do co najmniej jednej klasy. Klasa obiektu może być podklasą innej klasy obiektów

Rekord Katalogu – jest nazwą zbieranej informacji. Jest to podstawowa jednostka informacji przechowywanych w katalogu. Istnieje kilka rodzajów wpisów katalogowych.

Obiekt rekordu reprezentuje rzeczywistą wartość obiektu. Wejścia Alias ​​zapewniają alternatywną nazwę tego samego obiektu.

Drzewa katalogów informacji

DIB jest połączeniem wielu rekordów, zorganizowanym hierarchicznie w postaci drzewa, zwanego drzewem informacji katalogowej (directory information tree– DIT). Wierzchołkami drzewa są rekordy.

clip_image001
Przykład drzewa katalogów

Model nazewnictwa

LDAP definiuje hierarchiczną strukturę danych, o nazwie DIT. Drzewo katalogów jest czymś w rodzaju systemu plików. Odróżnienie od systemu plików jest następujące:

  1. Każdy wpis w LDAP może zawierać zarówno dane jak i służyć jako kontener, tj. zawiera poddrzewa. W systemie plików, każdy wpis jest plikiem lub katalogiem, ale nie jednym i drugim jednocześnie.
  2. Unikatowe nazwy są odczytywane w LDAP odwrotnie niż w systemie plików – od korzenia do wybranego punktu.

Względna nazwa wyróżniona (RDN — Relative Distinguished Name).

Nazwa względna pełni taką samą funkcję w katalogu, jak częściowa ścieżka dostępu w systemie plików (jest skrótem ułatwiającym dostęp do danego elementu).

Względna nazwa wyróżniająca (RDN) jest złożona z nieuporządkowanego zestawu jednego lub więcej wyrażeń wartości atrybutów.

Oto kilka przykładów RDNs:

 UID = 12 345
 OU = sprzedawca
 CN = Arek Kowalski + L = Białepisaki

Ostatnia opcja jest przykładem RDN wielowartościowego. Oznacza to, że RDN składa się z wielu AVAS.

Zasady nazewnicze:

  • Wszystkie zgłoszone muszą posiadać nazwy.
  • Nazwy nie powinny powodować konfliktów, tj. wszystkie nazwy potomne od jednego z rodziców muszą mieć unikalne nazwy
Liczba unikalnych nazw

Pełna nazwa rekordu, znana jako nazwa wyróżniająca (DN), jest połączeniem RDN i DN jego rodzica. DN jednoznacznie identyfikuje rekord w drzewo.

Oto przykłady DN:

 UID = nikt@przykład.com,
     DC = przykład, DC = com
 cn = NIK, ou = sprzdawca,
     dc = domena, dc = com, dc = pl
LDAP wpis

Kluczowe funkcje :

  • Wpisy składają się z atrybutów.
  • Atrybut składa się z typu i jednej lub więcej wartości.
  • Wartość ma znaczenie informacji w formacie tekstowym.
  • Atrybuty składni, zależy od typu rekordu.

Zapis zawiera zbiór atrybutów, które przechowują informacje o obiekcie. Niektóre atrybuty są przechowują informacje o użytkowniku i nazywane są atrybutami użytkownika. Inne atrybuty przechowują zapisy są funkcjonalne i / lub informacje administracyjne, i nazywane są funkcjonalnymi.

Atrybut składa się z atrybutów opisu (typu atrybutu i zero lub więcej opcji) i jednej lub więcej wartości związanej. Atrybut często identyfikowany jest z opisem. Na przykład, atrybut givenName atrybut składa się z givenName atrybutu opisu oraz jednej lub więcej wartości powiązanych.

Dwie wartości są uznawane za równoważne, jeżeli równoważność jest wykonywana zgodnie z zasadami równoważności atrybutu type. Jeśli atrybut typ jest zidentyfikowany bez równoważności reguł to dwie wartości są równoważne wtedy i tylko wtedy, gdy są one identyczne.

Na przykład, givenName atrybut może mieć więcej niż jedną wartość, wartości te muszą być Strings Directory. Dlatego atrybut givenName nie może jednocześnie mieć wartości John i John, ponieważ zgodnie z zasadą równoważności atrybutu type są to równoważne wartościami.

Atrybuty

Atrybut składa się z opisu jednej lub więcej wartości atrybutów.

 Atrybut:: = SEQUENCE { 
   AttributeDescription typu, 
   vals ZESTAW AttributeValue 
 } 

Każda wartość atrybutu musi być unikalna, tzn. powielanie jest niedozwolone. Przypisywanie wartości atrybutów nie prowadzi do uporządkowania tych wartości.

Wartość atrybutu

Wartości atrybutów odpowiadają składni zdefiniowanej dla atrybutu.

Jeśli atrybut jest używany do nazywania wpisów, i ma tylko jedną wartość wybranego atrybutu jest obecny w RDN. Ta wartość jest zdefiniowana jako wyjątkowa.

Pole typu AttributeValue jest OCTET STRING, zawierającym typ danych wartości atrybutu. Wartość jest zgodna z definicją reprezentacji w LDAP.

 AttributeValue:: = OCTET STRING 

.

Tak więc atrybuty powinny zawierać:

  1. Imię i nazwisko – unikalny identyfikator wrażliwy.
  2. Obiekt identyfikator (OID) – ciąg liczb oddzielonych kropkami.

3. Składnię atrybutu, która określa:

    • typ danych przechowywanych w atrybucie: liczby całkowite, łańcuchy, itp.;
    • jak wykonać porównanie.
  1. Może mieć wiele wartości atrybutów, lub tylko jedną wartość.

Przykłady nazw atrybutów:

uid – id użytkownika

cn – nazwa pospolita

sn – nazwisko

l – lokalizacja

ou – jednostka organizacyjna

o – organizacja

dc – komponent domain

st – personel

c – kraj

Aliasy

Aliasy wpisy mają następujące funkcje:

  1. Stosowane do łączenia jednego rekordu z drugim.
  2. Pozwalają mieć strukturę, która nie jest hierarchiczna.
  3. Nie wszystkie serwery LDAP wspierają aliasy.
Napisane przez: kokocinskiandrzej | 7 listopada 2011

LDAP cz.1


LDAP – Lightweight Directory Access Protocol

Wprowadzenie do LDAP

Historia LDAP

CCITT (Międzynarodowy Komitet Konsultacyjny dla telegrafii i telefonii) opracował szereg zaleceń dotyczących tworzenia tzw. katalogu usług lub katalogu. Katalog jest serwerem lub rozproszonym zbiorem serwerów obsługujących rozproszone bazy danych zawierający informacje takie jak użytkownicy, urządzenia itp. Ta rozproszona baza danych o nazwie Information Base Directory (Information Base Directory – DIB) zawiera informacje zawierające min nazwę podmiotu, jak również różne cechy, które charakteryzują ten podmiot.

LDAP daje wiele możliwości implementacji protokołu X.500 i ma zdecydowanie niższe koszty wdrożenia niż wspomniany protokół X.500. LDAP, w przeciwieństwie do X.500 używa stosu TCP, a nie OSI.

Pierwsza implementacja LDAP została opracowana przez University of Michigan ( większość wczesnych implementacji LDAP jest na niej oparta).

Co to jest LDAP

LDAP (Lightweight Directory Access Protocol) – protokół używany do dostępu do informacji przechowywanych poprzez rozproszoną sieć serwerów.

Informacje te są danymi przechowywanymi w atrybutach. Zakłada się, że takie dane są częściej odczytywane niż modyfikowane. LDAP jest oparta na architekturze klient-serwer modelu interakcji.

Ogólny model tego protokołu jest, taki że klient wykonuje operacje protokołu na serwerach. Klient wysyła żądanie w postaci operacji wykonywanych na serwerze. Serwer wykonuje i przetwarza w katalogu a po dokonaniu operacji, zwraca odpowiedź do klienta zawierającą wyniki lub też błędy.

Należy zauważyć, że jeśli chcemy aby serwer zwracał odpowiedź, jaka jest zdefiniowana w protokole, to nie ma wymogu pracy synchronicznej w zachowania klientów lub serwerów. Zapytania i odpowiedzi dla wielu operacji mogą być przesyłane pomiędzy klientem i serwerem w dowolnej kolejności, ale klienci powinni otrzymać odpowiedź na każde jego żądanie.

Informacje o serwer LDAP są zbiorem rekordów, które zawierają zbiór atrybutów i są pogrupowane w hierarchii drzewa.

Rekord jest identyfikowany przez unikalną w skali nazwę (Distinguished Name – DN) – tak jak struktury nazwa domeny w DNS.

Katalog jest wyspecjalizowaną bazą danych, która można wykorzystać w życiu codziennym – w książce telefonicznej, przewodnikach po programach, itp. Klasycznym i najbardziej obrazowym przykładem są dla takiej usługi specjalistyczne bazy danych DNS.

Korzyści z LDAP

Główne przyczyny popularności LDAP są związane z faktem, że:

  • LDAP przechowuje wzorzec w przeciwieństwie do relacyjnych baz danych, gdzie w każdym przypadku jest określony przez system pamięci masowej w postaci tabel i kolumn. Dlatego LDAP nie jest specyficzny dla każdego katalogu i dla każdej aplikacji zarządzania – ". Problemu N +1 Katalog".
  • LDAP pozwala szybko znaleźć potrzebne dane, skupia się bardziej na odczycie i wyszukiwaniu informacji, niż na procesie zapisu zmian.
  • LDAP nie musi być ograniczony do określonego serwera, możliwe jest zbudowanie sieci rozproszonych systemów z wielu serwerów. W LDAP możliwe jest tworzenie powiązań między różnymi serwerami LDAP, które zapewnia możliwość wyszukiwania na wielu serwerach, LDAP.
  • Jako protokół LDAP, stanowi strukturę katalogów zorganizowaną zgodnie z określonymi normami, nie ma wpływu na realizacje zależną od różnych producentów.
  • Inny ważny cel LDAP – przechowuje wszystkie informacje związane z PKI, a mianowicie, certyfikaty, CRL, itp.

LDAP vs bazy danych

Porównujemy dwa najbardziej popularne sposoby przechowywania informacji – relacyjne bazy danych i serwery LDAP, które charakteryzują się następującymi cechami:

  • Stosunek do odczytu i zapisu – LDAP, w przeciwieństwie do relacyjnej bazy danych zoptymalizowany jest do odczytu
  • Rozszerzalność – schemat LDAP jest łatwy w modyfikacji w odróżnieniu do schematu baz danych.
  • Dystrybucja – LDAP dane mogą znajdować się na wielu serwerach, na których zapytanie można wykonać za pomocą jednego polecenia. W rezultacie, można utworzyć optymalną konfigurację serwera LDAP, w zależności od tego, jakie są potrzeby dla usług aplikacji, zapewniając jednocześnie możliwość wyszukiwania informacji przechowywanych na wszystkich serwerach w LDAP. Osiągamy w ten sposób wyższy stopień rozkładu w porównaniu z relacyjnymi bazami danych.
  • Replikacja – LDAP dane mogą być przechowywane na wielu serwerach, z możliwością stosowania różnych sposobów na synchronizowanie informacji.
  • Dane aplikacji – LDAP ma na celu umożliwienie wykorzystania danych przez aplikacje, bazy danych są tworzone dla jednej aplikacji.
  • Złożoność relacji pomiędzy obiektami – obiekty bazy danych są bardziej złożone niż rekordy LDAP.
  • Transakcje – Transakcje w LDAP łatwiej, modyfikowalne niż w bazach danych.
  • Rodzaj przechowywanych informacji – LDAP przechowuje informacje w atrybutach.
  • Nazewnictwo – LDAP posiada strukturę hierarchiczną. Nazwa obiektu jest określona przez lokalizacje w drzewie hierarchii,.
  • System – w przypadku relacyjnych baz danych są one całkowicie ustalone przez dewelopera określonej bazy danych, LDAP ma ustaloną strukturę. Zapewnia to większą interoperacyjność, w porównaniu do bazy danych.
  • Standardy – standardy dla protokół LDAP wymuszają na producentach LDAP zachowanie z góry określonej struktury
  • Wycofanie z nieudanych transakcji – relacyjne bazy danych są bardziej elastyczne w przypadku wycofania zmian , tak więc bardziej są nastawione na obsługę dużej ilości modyfikacji niż modyfikacje danych na LDAP.

Zasady wdrażania serwerów LDAP

Po wdrożeniu serwera LDAP musi wykonać następujące zadania:

  • zdecydować, jakie powinny być przechowywane dane w katalogu. Należy dokładnie zrozumieć, jakie aplikacje i usługi będą korzystały z LDAP.
  • określić struktury danych w katalogu i ustawień ich zależności.
  • ustalić plan katalogu z wymaganiami aplikacji.
  • zdefiniować przestrzeń nazw.
  • określić topologię serwerów wdrożenia.
  • określić wymaganą replikację, zapewniającą, dostęp danych wszędzie tam, gdzie są one potrzebne.
  • określić optymalny poziomu bezpieczeństwa do spełnienia szczególnych wymagań bezpieczeństwa.
Modele LDAP

Główne modele LDAP, które określają cechy usługi to:

  • Information Model – definiuje typy danych przechowywanych w katalogu ich związek i dostęp do nich.
  • Funkcjonalny model – definiuje działanie protokołu LDAP.
  • Model bezpieczeństwa – określa sposoby i metody ochrony informacji przechowywanych w katalogu.
  • Distributed zestawu serwerów LDAP – określa sposób współpracy serwerów LDAP do wyszukiwania informacji na wielu serwerach, LDAP.
Napisane przez: kokocinskiandrzej | 7 listopada 2011

Wprowadzenie do Active Directory


Wprowadzenie do Active Directory

Na podstawie własnych obserwacji i własnego doświadczenia jako specjalisty IT mogę podpowiedzieć jak unikać potencjalnych konfliktów, na które możemy się natknąć administrując AD. Pragnę zaprezentować cykl tematyczny poświęcony właśnie AD.

Tak więc zaczynajmy!!!

Na początku wyjaśnię kilka pojęć podstawowych i przedstawię krótki zarys historyczny Active Directory.

Katalog (Directories) – publiczny lub prywatny zbiór list zawierający nazwy lokalizacji i innych zidentyfikowanych informacji przydatnych z perspektywy istnienia podmiotu. Typowy taki katalog (najczęściej) jest zbiorem danych na temat zatrudnionych pracowników np. miejsce zatrudnienia, miejsce organizacji, departament, numer telefonu – czyli wszelkie treści użyteczne z perspektywy funkcjonowania firm, organizacji. W niedalekiej przeszłości tego rodzaju dane gromadzone były w stosach dokumentacji kadrowej.

Jak zastąpić problematyczne w tych okolicznościach kolekcjonowanie danych? Taką drogę zrewolucjonizował komputer poprzez składowanie danych w pamięciach elektronicznych. Jak grzyby po deszczu zaczęły powstawać aplikacje, które realizowały koncepcje katalogu (directories) oferujące rozmaite schematy interfejsy – słabością tych aplikacji było to, że ich standard ginął w nowej wersji aplikacji lub w nowych wymogach funkcjonalnych. Często też aplikacje te żyły w kompletnej izolacji tworząc ciekawe rozwiązania- jednak w wyniku swojego odizolowania nie udostępniały danych do innych systemów będąc na bakier z interoperacyjnością. Ta różnorodność zainicjowała narodzenie standardu i próby stworzenia jednolitej formy. Do jednych z ciekawszych standardów należy X.500

Directory Foundation: X.500

Standard X.500 narodził się 1988 dzięki Interational Organization for Standard (ISO) i Interational Telecommunications Union (ITO). X.500 definiował protokół usług katalogowych ,dzięki czemu bazujące aplikacje posiadały model hierarchiczny z nazwą informacyjną obiektów. Specyficzny charakter danych w directory tzn powodował, że można było poszukiwać lub przeglądać użytkowników lub inne elementy directory. X.500 definiował jedno lub więcej Directory System Agents (DSAs)- directory servers- każdy z nich zawierał partycje Directory Information Base (DIB). DIB zawiera nazwę informacyjną obiektu przypisaną do struktury drzewa – w Directory Information Tree (DIT) – każdy zawiera atrybuty. Każdy atrybut zawiera pre-definiowane typy i wartości. Wszystkie te parametry zawarte są w schemacie directory.

LDAP Potrzeba dla prostszej alternatywy

Potrzebę usprawnienia standardu directory zainicjowało powstanie implementacji lżejszych alternatyw dla połączeń x.500. Lightweight Directory Access Protocol (LDAP) jest katalogowym protokołem serwisowym, który działa bezpośrednio ponad TCP/IP stos. Model transportowy LDAP jest podobny do X.500 modelu OSI ,ale jest stosunkowo mniej wymagający jeżeli chodzi o zasoby , co powoduje że są szybsze odpowiedzi do zapytań wysłanych do LDAP.

LDAP model można opisać jako strukturę informacyjną w katalogu i organizacji obiektów będących w hierarchicznym drzewie strukturalnym. Implementacja modelu zawiera schemat ,w którym obiekty są definiowane w strukturze, każdy obiekt może być stworzony w directory service.

Klasy i atrybuty

Klasy i atrybuty są zdefiniowane w schemacie classSchema (object calsses) i attributeSchema (object attributes):

object calsses typ klasa, kategoria obiektów, które mogą być kreowane w directory. Na przykład users, computers i printers są klasami w objektach. Każdy objekt w directory jest stworzony w instancji kliku klass zgodnych z definicją zawartą w classSchema object dla odpowiednich klas

object attributes są charakterystykami dla obiektu. Każdy atrybut może przetrzymywać wartość lub wartość reprezentującą właściwości obiektu. Na przykład given name, surname, e-mail adress są atrybutami dla klasy user i wartości te mogą przyjmować typ text ( string). Schemat specyfikuje atrybuty oraz definiuje wartości. W Active Directory tylko atrybuty mogą posiadać wartości związane z aktualnie używanymi zasobami w bazie AD.

Każdy atrybut posiada syntax, który wyspecyfikowany jest w schemacie- determinuje zatem jakie wartości są dozwolone dla wybranego atrybuty, np. syntaxes : unicode string integer itd.

Nowy Object klasy i atrybut może być dodany do schematu, ponadto występujące obiekty mogą być modyfikowane i dodawane classSchema and attributesSchema object.

« Newer Posts - Older Posts »

Kategorie