Kto pamięta czasy Novell NetWare 3.12? W latach 90. był to w Polsce jeden z najpopularniejszych sieciowych systemów operacyjnych. Można go było spotkać w firmach, urzędach, szkołach, na uczelniach i w ośrodkach szkoleniowych. Były dyskietki instalacyjne, protokół IPX/SPX, sterowniki ODI, mapowane dyski i charakterystyczna konsola serwera. Użytkownik logował się do sieci, otrzymywał dostęp do plików i drukarek, a administrator zarządzał kontami oraz uprawnieniami. Jak na tamte czasy był to ogromny krok naprzód.

Autor: 6 min czytania

Dzisiaj świat zarządzania tożsamością wygląda zupełnie inaczej. Mówimy o Entra ID, Identity Governance, automatycznym provisioningu, recertyfikacji i dostępie warunkowym. Mimo to u podstaw wielu współczesnych systemów nadal znajduje się LDAP – protokół opracowany ponad trzy dekady temu.

Jak zarządzano użytkownikami przed usługami katalogowymi?

NetWare 3.x korzystał z mechanizmu nazywanego bindery. Informacje o użytkownikach, grupach i zasobach były przechowywane lokalnie na konkretnym serwerze. W niewielkiej sieci działało to całkiem dobrze. Problem pojawiał się wtedy, gdy serwerów przybywało. Konta trzeba było zakładać i utrzymywać w kilku miejscach, a użytkownik często miał różne hasła oraz uprawnienia na poszczególnych serwerach.

Novell odpowiedział na ten problem w NetWare 4, wprowadzając w 1993 roku Novell Directory Services, czyli NDS. Zamiast osobnych baz pojawił się hierarchiczny katalog obejmujący całe środowisko. Później NDS rozwinął się w wieloplatformowy produkt znany jako eDirectory. Jego historia została opisana w dokumentacji Novella (novell.com).

Po co powstały usługi katalogowe?

Problem rozproszonych kont nie dotyczył wyłącznie Novella. Wraz z rozwojem sieci rosła liczba użytkowników, komputerów, serwerów, drukarek i aplikacji. Informacje o nich znajdowały się w wielu oddzielnych bazach. Potrzebny był wspólny katalog, pozwalający na przechowywanie informacji o obiektach, porządkowanie ich w hierarchii i szybkie wyszukiwanie.

Taką rolę miał pełnić standard X.500, rozwijany przez ITU-T i ISO. Zakładał stworzenie rozproszonej usługi katalogowej, w której obiekty otrzymywały jednoznaczne nazwy i miejsce w strukturze organizacji. Problemem był sposób dostępu do katalogu. Protokół DAP korzystał z rozbudowanego stosu OSI i wymagał znacznych zasobów. Dla komputerów i aplikacji z początku lat 90. był po prostu zbyt ciężki.

Dlaczego LDAP miał być lekki?

Odpowiedzią był Lightweight Directory Access Protocol. Pierwsza specyfikacja LDAP została opublikowana w 1993 roku jako RFC 1487, a rok później zastąpił ją RFC 1777.

Celem było zapewnienie dostępu do katalogu X.500 bez konieczności korzystania z pełnego i skomplikowanego DAP. Zamiast stosu OSI LDAP wykorzystywał TCP/IP.

Aplikacja mogła połączyć się z serwerem katalogowym, wyszukać użytkownika, odczytać jego atrybuty albo zmodyfikować wpis. LDAP nie był przy tym osobnym katalogiem, lecz protokołem komunikacji z usługą katalogową. Współczesną podstawą standardu pozostaje RFC 4511, opublikowany w 2006 roku.

Jak wyglądają dane w LDAP?

Informacje są przechowywane w postaci drzewa. Każdy wpis reprezentuje obiekt, na przykład użytkownika, grupę, komputer albo jednostkę organizacyjną. Obiekt ma zestaw atrybutów, takich jak imię, nazwisko, adres e-mail, identyfikator logowania czy numer telefonu. Jego miejsce w katalogu określa Distinguished Name, czyli DN:

cn=Jan Kowalski,ou=Warszawa,dc=firma,dc=pl

Schemat katalogu definiuje, jakie klasy obiektów mogą istnieć oraz jakie atrybuty są dla nich wymagane. Model ten opisano szczegółowo w RFC 4512.

Dzisiaj takie podejście wydaje się naturalne. W latach 90. możliwość przechowywania użytkowników i zasobów w jednym hierarchicznym katalogu była jednak poważną zmianą.

Dlaczego LDAP przetrwał ponad 30 lat?

LDAP rozwiązuje konkretny problem i jest wspierany przez wielu producentów. To otwarty standard, który nie należy do jednej firmy ani platformy. Korzystają z niego między innymi OpenLDAP, eDirectory i Active Directory. Nadal spotyka się go również w aplikacjach biznesowych, systemach linuksowych, urządzeniach sieciowych, VPN-ach, narzędziach deweloperskich i starszych systemach ERP.

Microsoft opisuje Active Directory Domain Services jako hierarchiczny magazyn informacji o użytkownikach, komputerach, drukarkach i usługach, umożliwiający ich wyszukiwanie oraz wykorzystanie w sieci (learn.microsoft.com). LDAP bywa najprostszym wspólnym językiem między aplikacją a katalogiem firmowym. Nie oznacza to jednak, że każda implementacja jest bezpieczna. Proste uwierzytelnianie bez szyfrowania może narazić dane logowania. Mechanizmy TLS i SASL opisano między innymi w RFC 4513, ale wymagają one poprawnej konfiguracji.

Czego LDAP nie potrafił rozwiązać?

LDAP uporządkował sposób przechowywania i wyszukiwania informacji o użytkownikach. Nie rozwiązał jednak całego problemu zarządzania tożsamością.

Nie określał:

  • kto ma utworzyć konto nowego pracownika,
  • kiedy dostęp powinien zostać odebrany,
  • jakie uprawnienia wynikają ze stanowiska,
  • kto powinien zaakceptować dodatkowy dostęp
  • czy jak zarządzać komputerami i politykami bezpieczeństwa.

Katalog potrafił przechowywać obiekty. Potrzebny był jeszcze system, który połączy katalog, uwierzytelnianie, administrację komputerami, polityki bezpieczeństwa i zarządzanie dostępem. LDAP uporządkował informacje o użytkownikach, ale nie rozwiązał problemu zarządzania nimi. W kolejnym artykule opowiemy, jak zrobiło to Active Directory.