Od Novella do Active Directory: jak ewoluowało zarządzanie tożsamością w sieciach

Od tablicy na ścianie do pierwszego serwera katalogowego

Scenka otwierająca – „Hasła w zeszycie”

Małe biuro na przełomie lat 80. i 90. Na ścianie korkowa tablica, a na niej kartka: „Serwer magazyn – hasło: MAG202”. Ktoś przekreślił, dopisał długopisem „MAG203?”. Jedna osoba odchodzi z firmy, nikt nie pamięta, gdzie jeszcze znała hasła – do serwera, do aplikacji, do modemu. W końcu ktoś kasuje konto na jednym komputerze, a na trzech innych zostaje po nim „duch” – ten sam login i stare hasło działają dalej.

Tak wyglądały początki „zarządzania tożsamością w sieci” w wielu firmach: bez katalogów, bez centralizacji, za to z zeszytem haseł i plikami konfiguracyjnymi, które każdy admin łatał po swojemu. Problem nie polegał na tym, że ludzie nie rozumieli bezpieczeństwa. Problemem był brak narzędzia, które spinałoby wszystkie konta użytkowników i zasoby w jedną całość.

Cel był prosty: jedna tożsamość użytkownika w sieci i przewidywalne zasady dostępu. Zanim jednak pojawiły się Novell NetWare, domeny Windows NT i w końcu Active Directory, admini radzili sobie ręcznie – a ta „ręczna era” bardzo mocno ukształtowała to, jak później projektowano systemy katalogowe.

Ręczne zarządzanie kontami: od plików passwd do zeszytów z loginami

Na systemach uniksowych centralnym miejscem przechowywania kont był plik /etc/passwd, a później /etc/shadow. Każdy serwer miał własną listę użytkowników. Jeśli ktoś awansował albo zmienił dział, administrator logował się na kilka maszyn i ręcznie poprawiał wpisy. W środowiskach DOS/Windows występował podobny chaos – każde stanowisko z własnymi lokalnymi kontami.

Typowy scenariusz w małej firmie wyglądał tak:

• nowy pracownik dostawał konto na jednym serwerze plików,
• po tygodniu ktoś przypominał sobie o programie księgowym na innym serwerze – zakładano mu drugie konto, inną nazwę użytkownika, czasem inne hasło,
• po miesiącu dział IT odkrywał, że ta sama osoba ma trzy różne loginy i cztery różne hasła, a w razie odejścia trzeba pamiętać o wyłączeniu ich wszystkich.

Trudno mówić o spójnej tożsamości użytkownika w takim środowisku. To raczej zbiór lokalnych wpisów w różnych bazach i plikach, które czasem do siebie pasują, a czasem nie. Bez centralizacji trudno też było zapanować nad prostymi zasadami bezpieczeństwa: wymuszeniem zmiany hasła, blokadą nieużywanych kont czy raportowaniem dostępu.

Pierwsze próby „ogarnięcia tego bałaganu” szły w kierunku prostych centralnych serwerów uwierzytelniania. W świecie Uniksa pojawiały się rozwiązania NIS i NIS+, a w świecie PC – pierwsze serwery plików Novella, proste domeny Microsoftu czy systemy logowania do mainframe’ów. Każdy z nich rozwiązywał fragment problemu, ale dopiero koncepcja katalogu jako centralnego repozytorium informacji o zasobach i użytkownikach zaczęła porządkować tożsamość w sieciach na poważnie.

Poród koncepcji katalogu w sieci lokalnej

Katalog sieciowy nie powstał „znikąd”. Wynikał z kilku bardzo konkretnych potrzeb:

• jedna lista użytkowników dla wszystkich serwerów danego producenta,
• możliwość przechowywania nie tylko loginów i haseł, ale też informacji o grupach, drukarkach, serwerach, aplikacjach,
• centralne nadawanie uprawnień: kto widzi jaki zasób, kiedy i w jakim trybie,
• replikacja danych katalogowych między wieloma serwerami tak, aby praca nie zależała od pojedynczej maszyny.

W praktyce oznaczało to przejście od myślenia „konto na serwerze X” do myślenia „tożsamość użytkownika w organizacji”. Serwer stawał się jedynie klientem pytającym katalog: „kim jest ten użytkownik, jakie ma prawa, do czego mogę go wpuścić?”. Ten zwrot w myśleniu był kluczowy, bo później powielono go w Active Directory i współczesnych systemach IAM.

Wniosek z tej „przedkatalogowej” epoki jest prosty: problemy, które rozwiązują dzisiejsze systemy tożsamości, istniały od początku sieci lokalnych. Brakowało jednak spójnej, skalowalnej technologii, która pozwalałaby jednocześnie centralizować dane o użytkownikach i nie dławić się przy rosnącej liczbie serwerów i oddziałów.

Novell NetWare – złota era katalogów w latach 90.

NetWare bindery – zanim pojawił się NDS

W pierwszej połowie lat 90. w wielu firmach słowo „sieć” było praktycznie synonimem „Novell NetWare”. Systemy NetWare 3.x dominowały jako serwery plików i drukarek. Działały szybko, stabilnie i dobrze radziły sobie w środowiskach, gdzie kilkadziesiąt, a czasem kilkaset stacji roboczych Windows czy DOS potrzebowało dostępu do wspólnych zasobów.

W NetWare 3.x tożsamość użytkownika była oparta na mechanizmie bindery. Bindery to w uproszczeniu lokalna baza informacji o użytkownikach i grupach, powiązana z konkretnym serwerem NetWare. Każdy serwer miał swój „kawałek świata” – swoją listę użytkowników i uprawnień. Możliwe było pewne współdzielenie informacji, ale z perspektywy dużej organizacji nadal przypominało to „wyspy” z lokalnymi kontami.

Z punktu widzenia administratora wyglądało to następująco:

• tworzył konta użytkowników na głównym serwerze plików,
• jeśli pojawiał się nowy serwer aplikacyjny NetWare, trzeba było zadbać o odpowiednie odwzorowanie kont,
• mapowanie dysków i drukarek dla stacji roboczych opierało się na lokalnych definicjach i skryptach logowania.

Przy małej liczbie serwerów mechanizm bindery był do przełknięcia. Problemy pojawiały się, gdy firma rosła, otwierała nowe oddziały lub segmentowała infrastrukturę. Zaczynał się dobrze znany schemat: pracownik miał konto „u siebie”, ale w innym oddziale musiał używać innego loginu, bo tam serwer działający w innej domenie NetWare posiadał inną bazę bindery.

Modele uprawnień i zarządzanie drukarkami też nie były w pełni centralne. W administracji pojawiało się mnóstwo „lokalnych reguł” konfigurowanych ręcznie. Był to krok naprzód względem „zeszytu haseł”, ale jeszcze daleko do pełnoprawnego katalogu organizacji.

NDS – Novell Directory Services jako przełom

Odpowiedzią Novella na te ograniczenia stało się Novell Directory Services (NDS), wprowadzone z NetWare 4.x. NDS można uznać za jedno z pierwszych masowo wdrożonych, dojrzałych rozwiązań katalogowych w sieciach firmowych. Zamiast wielu lokalnych baz bindery pojawiło się jedno, logiczne drzewo katalogowe dla całej organizacji.

Struktura NDS była hierarchiczna i przypominała dzisiejsze katalogi LDAP:

• drzewo katalogowe (ang. tree) odzwierciedlające strukturę organizacyjną lub geograficzną,
• kontenery (organizational units, domeny logiczne), w których przechowywano obiekty,
• obiekty reprezentujące użytkowników, grupy, serwery, drukarki, aplikacje i inne zasoby.

Z punktu widzenia użytkownika największą zmianą był jeden login i jedno hasło dla całej sieci Novella. Logując się do klienta NetWare, użytkownik był uwierzytelniany przez NDS, a serwery plików, drukarki i aplikacje pytały katalog o jego tożsamość i prawa. Znikał problem wielokrotnych kont na różnych serwerach. Dla admina pojawiało się jedno miejsce, w którym mógł:

• tworzyć i usuwać konta użytkowników,
• przypisywać ich do grup i jednostek organizacyjnych,
• konfigurować uprawnienia do zasobów w oparciu o strukturę katalogu.

NDS imponował także rozwiązaniami technicznymi. Replikacja katalogu była rozproszona – nie było jednego „świętego” serwera, od którego wszystko zależało. Dane katalogowe były kopiowane między wieloma serwerami NetWare, dzięki czemu awaria jednego węzła nie paraliżowała całego środowiska. Było to podejście zdecydowanie dojrzalsze niż model Primary/Backup Domain Controller w późniejszym Windows NT.

Co ważne, NDS nie ograniczał się tylko do plików i drukarek. Novell konsekwentnie promował koncepcję katalogu jako centralnego źródła tożsamości również dla innych aplikacji. Wiele systemów biznesowych mogło integrować się z NDS, a informacja o użytkowniku – jego login, przynależność do działu, rola w organizacji – była używana jako wspólny punkt odniesienia.

NDS a współczesne IAM – więcej podobieństw niż się wydaje

Patrząc z dzisiejszej perspektywy, NDS był zaskakująco zbliżony do koncepcji znanych z nowoczesnych systemów Identity and Access Management (IAM). Kluczowe cechy, które dziś uznaje się za standard, w NDS pojawiły się bardzo wcześnie:

• centralny katalog użytkowników i zasobów,
• hierarchiczny model odwzorowujący strukturę firmy,
• replikacja danych katalogowych i rozproszone zarządzanie,
• możliwość integracji z aplikacjami jako zewnętrzne źródło tożsamości,
• jeden zestaw poświadczeń do wielu usług w obrębie sieci.

W praktyce wiele organizacji, które zainwestowały w NDS, miało już w latach 90. zalążek tego, co dziś oferują platformy typu Azure AD, Okta czy inne systemy IAM: użytkownik jako obiekt w katalogu, przypisany do grup i ról, z uprawnieniami rozciągającymi się na całą infrastrukturę.

Mini-wniosek z epoki NDS jest taki: koncepcja nowoczesnego katalogu tożsamości nie jest wymysłem ery chmury. Została opracowana i przetestowana kilkadziesiąt lat temu. Dzisiejsze rozwiązania rozwijają tę ideę, przenosząc ją do świata chmury, federacji i autoryzacji webowej, ale fundamenty – centralny katalog, hierarchia, replikacja, integracja – są w dużej mierze takie same.

Świat Microsoftu – od grup roboczych do domen NT

Grupy robocze i „chaos SMB”

Podczas gdy Novell oferował zaawansowane serwery plików z NDS, większość użytkowników końcowych pracowała na desktopach z DOS-em i kolejnymi wersjami Windows. W tych środowiskach przez długi czas dominował model grup roboczych i prostych udostępnień SMB (Server Message Block).

W grupie roboczej:

• każdy komputer był w zasadzie równorzędny (peer-to-peer),
• kontrola dostępu opierała się na lokalnych kontach i hasłach na danej maszynie,
• nie istniało centralne miejsce, gdzie definiowano użytkowników i zasoby.

Przykładowy scenariusz z tamtych czasów: dział handlowy korzysta z 10 komputerów w grupie roboczej „SPRZEDAZ”. Na komputerze „FILESERVER” utworzono kilka folderów udostępnionych, zabezpieczonych kontami lokalnymi. Aby każdy handlowiec miał dostęp, na FILESERVER tworzono lokalne konto o nazwie zgodnej z loginem na jego własnym komputerze. Hasła często były takie same – bo inaczej użytkownicy gubiliby się, gdzie wpisują które.

Przy kilku stanowiskach dało się jeszcze nad tym zapanować. Gdy jednak firma rosła, a komputerów przybywało, taki model stawał się koszmarem. Admin musiał:

• powielać te same konta na wielu komputerach,
• dbać o spójność haseł, jeśli stosowano mechanizmy „logowania zdalnego”,
• ręcznie kontrolować dostęp do udziałów sieciowych przez ustawienia lokalne.

Efekt? Brak prawdziwej tożsamości sieciowej. Użytkownik był „zlepkiem” lokalnych kont, czasem z tym samym loginem i hasłem, czasem nie. Każdy nowy serwer wprowadzał dodatkową porcję chaosu. Ten etap funkcjonowania sieci PC dobrze pokazał, że potrzebny jest krok w stronę centralizacji – dokładnie taki, jaki zrobiły domeny Windows NT.

Domeny Windows NT – pierwszy krok do centralizacji

Microsoft zareagował wprowadzając mechanizm domen Windows NT wraz z Windows NT Server. Domeny NT umożliwiały centralne zarządzanie kontami w obrębie domeny, w której istniał Primary Domain Controller (PDC) oraz jeden lub więcej Backup Domain Controller (BDC).

Kluczowe elementy modelu domen NT:

• PDC – jedyny serwer, na którym można było dokonywać zmian w bazie użytkowników (SAM – Security Accounts Manager),
• BDC – repliki bazy SAM w trybie tylko do odczytu, przejmujące uwierzytelnianie, gdy PDC był niedostępny,
• zaufania między domenami (trusts) – mechanizm, który pozwalał użytkownikom z jednej domeny korzystać z zasobów w innej.

Ograniczenia domen NT – ślepa uliczka skalowania

W większych firmach bardzo szybko wychodziło na jaw, że domeny NT są dobre „na start”, ale kiepsko znoszą wzrost. Admin z działu IT w średniej korporacji miał na biurku listę kilku, kilkunastu domen: „KRAKÓW”, „WROCŁAW”, „ODDZIAL1”, „ODDZIAL2”. Każda z nich ze swoim PDC, BDC i lokalnym zbiorem kont. Kiedy nowy pracownik miał pracować w dwóch działach, często kończyło się to dwiema tożsamościami, dwoma profilami, dwoma kompletami uprawnień.

Architektura domen NT wynikała z czasów, w których powstała. Z dzisiejszej perspektywy widać kilka poważnych barier:

• Brak hierarchii domenowej – domeny NT nie tworzyły logicznego drzewa. Istniały obok siebie, a relacje między nimi opierały się na stosunkowo prostym systemie zaufania.
• Trusty jednostronne i niesymetryczne – konfiguracja zaufania była skomplikowana, a w dużych środowiskach tworzyły się „pajęczyny” trustów, które trudno było zrozumieć i utrzymać.
• PDC jako pojedynczy punkt zapisu – istnienie jednego kontrolera domeny z prawem zapisu bazy SAM oznaczało wąskie gardło administracji. Każda zmiana przepływała z tego jednego punktu do BDC.
• Brak prawdziwego katalogu – baza SAM przechowywała głównie konta i grupy. Informacje o organizacji, stanowiskach czy strukturze firmy trzeba było trzymać gdzie indziej.

Próby obejścia tych ograniczeń wyglądały dość topornie. Administratorzy tworzyli skrypty do masowego zakładania kont w wielu domenach, ustalali „globalne zasady nazewnictwa” i ręcznie pilnowali, by użytkownik „J.Kowalski” wszędzie miał ten sam identyfikator. W praktyce nie dało się uniknąć bałaganu: część kont miała inne hasła, część inne uprawnienia, a gdy pracownik przechodził między działami, trzeba było dotykać wielu domen naraz.

Mini-wniosek z ery domen NT: udało się wprowadzić centralizację na poziomie pojedynczej domeny, lecz nie na poziomie całej organizacji. Model techniczny zwyczajnie nie nadążał za rosnącymi sieciami rozproszonymi po wielu lokalizacjach.

Most między światami: od SAM do katalogu LDAP

W pewnym momencie coraz częściej spotykało się firmy, które miały równolegle: serwery NetWare z NDS, domeny NT do logowania do Windows, do tego osobny katalog LDAP dla jakiejś aplikacji portalowej. Każdy zespół IT pilotował własny „świat”, a użytkownicy balansowali między trzema czy czterema kompletami haseł.

Na tym etapie zaczęły pojawiać się pierwsze rozwiązania integracyjne. Dotyczyły dwóch obszarów:

• Synchronizacja kont – narzędzia, które kopiowały konta z jednego systemu do drugiego: np. z NDS do SAM domeny NT, z bazy HR do katalogu LDAP. Zazwyczaj działało to wsadowo, raz na dobę.
• Uwierzytelnianie pośrednie – aplikacje, które pytały katalog NDS lub serwer Windows NT o poprawność hasła, zamiast mieć własną bazę użytkowników. Wymagało to dodatkowej logiki po stronie aplikacji.

To nie było jeszcze single sign-on w dzisiejszym sensie. Raczej zbiór sprytnych obejść, które ograniczały liczbę miejsc, gdzie trzeba było ręcznie tworzyć konta. Jednak już wtedy krystalizowała się jedna, prosta idea: najważniejsze jest jedno źródło prawdy o użytkownikach, niezależnie od tego, czy zapisane w formacie SAM, NDS czy LDIF.

LDAP, Kerberos i inne klocki, z których zbudowano nowoczesne katalogi

LDAP – katalog, który miał być lekki, a stał się fundamentem

Scenka sprzed lat: zespół wdraża aplikację webową dla całej firmy. Producent pyta: „macie LDAP?”. Dla dostawcy nie jest ważne, czy to będzie NDS, Sun Directory czy Microsoft AD – byle mówiło „po LDAP-ie”. W ten sposób protokół, który w nazwie ma „lightweight”, stał się ciężkim standardem rynku.

LDAP (Lightweight Directory Access Protocol) zaprojektowano jako prostszą alternatywę dla rozbudowanych, mało poręcznych standardów katalogowych X.500. Kluczowe założenia były dość pragmatyczne:

• klient łączy się z serwerem katalogowym przez prosty protokół na TCP/IP,
• obiekty katalogu są zorganizowane hierarchicznie w drzewo (DN – distinguished name),
• każdy obiekt ma zestaw atrybutów opisanych przez schemat,
• zapytania są zbliżone do wyszukiwania – zamiast złożonych transakcji mamy operacje bind/search/modify.

LDAP nie narzucał, do czego katalog ma służyć. Mógł przechowywać zarówno konta użytkowników, jak i informacje o serwerach, drukarkach czy nawet konfiguracji aplikacji. Dzięki temu stał się wygodnym „magazynem tożsamości” – wystarczyło ustalić wspólny schemat obiektów.

Producenci szybko podchwycili temat. Pojawiły się różne implementacje:

• Novell wypuścił eDirectory (następcę NDS) z interfejsem LDAP,
• Sun, IBM i inni tworzyli własne serwery LDAP dla środowisk UNIX,
• Microsoft zaadaptował LDAP jako główny protokół dostępu do danych katalogowych w Active Directory.

W codziennej pracy IT LDAP oznaczał jedną konkretną przewagę: aplikacje nie musiały znać „magii” konkretnego systemu katalogowego. Wystarczył im adres serwera, DN bazowy i kilka atrybutów, które trzeba odczytać (np. uid, mail, memberOf). Taka unifikacja ułatwiła integracje i sprawiła, że rozmowa o katalogu przestała się sprowadzać do pytania: „czy to Windows, czy NetWare?”, a zaczęła: „czy jest endpoint LDAP?”.

Mini-wniosek: LDAP nie był rewolucją koncepcyjną, tylko językiem, którym różne katalogi zaczęły mówić w podobny sposób. To umożliwiło zbudowanie nad nimi bardziej złożonych systemów IAM.

Kerberos – bilet do zaufanego świata

Administratorzy starszych środowisk pamiętają logowanie w stylu „podaj login i hasło” przy każdym zasobie: serwerze plików, systemie pocztowym, aplikacji telnetowej. Gdy wdrożono Kerberosa, nagle okazało się, że po jednym logowaniu użytkownik porusza się po sieci niemal bez przerw na kolejne okienka autoryzacji.

Kerberos to protokół uwierzytelniania opracowany w MIT, bazujący na kryptografii symetrycznej i idei „biletów”:

• użytkownik loguje się do centralnego serwera uwierzytelniającego (KDC – Key Distribution Center),
• po pomyślnym uwierzytelnieniu otrzymuje ticket-granting ticket (TGT),
• gdy chce skorzystać z konkretnej usługi (np. serwera plików), wymienia TGT u KDC na ticket do tej usługi,
• serwer usługi weryfikuje bilet i przyznaje dostęp – bez ponownego pytania o hasło.

W efekcie powstaje coś na kształt single sign-on na poziomie sieci. Użytkownik uzyskuje bilet wejścia do świata usług, a dalsza komunikacja odbywa się w oparciu o bilety, nie o ciągłe przesyłanie haseł po sieci. To istotne także z punktu widzenia bezpieczeństwa – hasło użytkownika nie „podróżuje” z każdą prośbą o dostęp.

Kerberos przyjął się najpierw w środowiskach akademickich i UNIX-owych. Z czasem został zaadaptowany komercyjnie, a jego rola urosła szczególnie tam, gdzie chciano uniknąć wpisywania poświadczeń w każdym systemie z osobna. Kiedy Microsoft postanowił oprzeć Active Directory na Kerberosie, ten protokół stał się de facto standardem uwierzytelniania w sieciach firmowych opartych o Windows.

Praktyczny obraz: użytkownik loguje się do komputera w domenie, a potem po prostu otwiera zasoby – udziały SMB, aplikacje webowe korzystające z Integrated Windows Authentication, usługi bazodanowe. Brak dodatkowych promptów nie jest „magią Windowsa”, tylko efektem biletów, którymi wymieniają się klient, KDC i serwery usług.

DNS – cichy bohater katalogów

Gdy ktoś pierwszy raz konfiguruje domenę AD, często skupia się na użytkownikach, OU czy politykach GPO. Dopiero gdy zaczynają się problemy z logowaniem, dostaje wskazówkę: „sprawdź DNS”. To dobry sygnał, jak bardzo usługi katalogowe są splecione z systemem nazw.

DNS w epoce nowoczesnych katalogów pełni inną rolę niż w czasach prostych sieci lokalnych. Chodzi nie tylko o tłumaczenie nazwy serwera na adres IP, lecz także o odnajdywanie usług katalogowych. Mechanizm SRV records pozwala klientowi zapytać: „gdzie w tej domenie znajdę kontroler katalogu?” – i dostać odpowiedź bez ręcznego wpisywania adresów.

To sprzężenie katalogu z DNS-em rozwiązuje wiele problemów znanych z ery domen NT czy NDS, gdzie użytkownicy „przyklejali się” do konkretnych serwerów. W dobrze skonfigurowanym środowisku klient sam wybiera najbliższy kontroler, na podstawie rekordów DNS i topologii sajtów. Migracje, dołączanie nowych serwerów, zmiana lokalizacji – wszystko staje się łatwiejsze, bo adresuje się usługę logiczną, a nie fizyczny serwer o stałej nazwie.

Mini-wniosek: choć rzadko się o tym mówi, współczesne zarządzanie tożsamością w sieci bez sprawnego DNS jest jak autostrada bez znaków – niby asfalt jest, ale trudno dotrzeć tam, gdzie trzeba.

Gdy klocki się spotykają: od protokołów do pełnoprawnego IAM

W pewnej firmie wdrożono katalog LDAP jako centralne źródło użytkowników, Kerberosa do uwierzytelniania w systemach UNIX i Active Directory dla stacji roboczych Windows. Każdy element działał poprawnie, ale dopiero po domknięciu integracji – spięciu atrybutów w katalogu, zaufaniach między domenami, centralnej polityce haseł – pracownicy odczuli różnicę: z czterech loginów zrobił się jeden, a przy zmianie działu ktoś w HR-owym systemie aktualizował tylko jedno pole.

Nowoczesne systemy IAM wyrastają właśnie z takiego łączenia klocków:

• LDAP daje strukturę i sposób odczytu informacji o użytkownikach, grupach i zasobach,
• Kerberos zapewnia silne, scentralizowane uwierzytelnianie z mechanizmem biletów,
• DNS pozwala automatycznie odnajdywać usługi katalogowe i uwierzytelniające,
• protokoły wyższego poziomu (SAML, później OAuth2/OIDC) korzystają z katalogu jako źródła tożsamości dla aplikacji webowych i chmurowych.

Z punktu widzenia użytkownika całość wygląda prosto: loguje się raz, widzi dostępne aplikacje, jego uprawnienia „podążają” za nim między działami, lokalizacjami, a dzisiaj – także między chmurą a on-premise. Z perspektywy administratora to efekt konsekwentnego wykorzystania kilku technologii, które pojawiły się na długo przed tym, zanim modne stały się hasła typu „Zero Trust” czy „Identity is the new perimeter”.

Na tym tle ewolucja od Novella do Active Directory nie jest tylko zmianą produktu, ale przejściem od lokalnego spojrzenia na konta do myślenia o tożsamości jako wspólnym zasobie całej organizacji, obsługiwanym przez dojrzałe, standaryzowane klocki protokołów i usług.

Active Directory jako punkt zwrotny w myśleniu o tożsamości

W pewnym biurze helpdesk dostawał codziennie te same zgłoszenia: „nie działa drukarka w pokoju 312”, „nie mogę się zalogować do aplikacji finansowej”, „wyskakuje błąd dostępu do udziału sieciowego”. Dla użytkownika wszystko było „jednym systemem”, dla administratorów – zbiorem niespójnych wysp. Gdy wdrożono Active Directory i zaczęto porządkować uprawnienia według ról i jednostek organizacyjnych, liczba takich zgłoszeń spadła, a dział IT pierwszy raz poczuł, że tożsamość zaczyna być zarządzana, a nie „łatania na bieżąco”.

Od domen NT do lasów i lasów zaufania

Domeny NT działały, dopóki firma była mała i miała kilka serwerów. Problem zaczynał się, gdy rosła struktura organizacyjna, pojawiały się nowe lokalizacje i potrzeba segmentacji uprawnień. Domena NT oferowała dość prymitywny model: płaską listę kont i ograniczone relacje zaufania, które w praktyce często kończyły się plątaniną „trustów” między serwerami.

Active Directory odwróciło ten model, wprowadzając kilka kluczowych pojęć:

• domena – granica administracyjna i polityki bezpieczeństwa, ale jednocześnie węzeł większej całości,
• las (forest) – zbiór domen, które dzielą wspólny schemat, katalog globalny i relacje zaufania,
• drzewo (tree) – hierarchia domen powiązanych w przestrzeni nazw.

Dzięki takiemu podejściu duża organizacja mogła tworzyć osobne domeny dla spółek-córek, regionów albo środowisk (produkcyjne, testowe), a jednocześnie utrzymywać wspólne zasady i współdzielony katalog użytkowników. Relacje zaufania w obrębie lasu były automatyczne i dwukierunkowe, co znacząco upraszczało projektowanie uprawnień między jednostkami.

Mini-wniosek: przejście z domen NT do AD nie było tylko „upgrade’em serwera”, lecz zmianą skali – z pojedynczych wysp kontroli dostępu do spójnej, wielowymiarowej przestrzeni tożsamości.

OU, GPO i grupy – jak AD zamieniło chaos w politykę

Typowy scenariusz z lat 90.: nowy pracownik w dziale sprzedaży dostaje komputer, a administrator „ręcznie” klika mu uprawnienia – do udziału z ofertami, do drukarki działowej, do aplikacji CRM. Po roku nikt już nie pamięta, co było nadawane, a co zdjęte, a migracja użytkownika do innego działu kończy się kilkoma dniami „dogrywania” dostępów.

Active Directory przyniosło trzy mechanizmy, które pozwoliły nad tym zapanować:

• OU (Organizational Units) – logiczne kontenery, w których można umieszczać użytkowników, komputery i grupy, odzwierciedlające strukturę organizacji lub funkcje (np. „Sprzedaż-EU”, „Serwery-Aplikacyjne”),
• GPO (Group Policy Objects) – zbiory ustawień konfiguracyjnych (bezpieczeństwo, pulpit, oprogramowanie) przypisywane do OU i dziedziczone przez obiekty,
• grupy bezpieczeństwa – abstrakcja „rolowa”, którą można przypisywać do zasobów zamiast konkretnych kont.

W dojrzałym środowisku schemat staje się przewidywalny: użytkownik w OU „PLUżytkownicySprzedaż” automatycznie dostaje odpowiednie polityki GPO, a jego grupa „Sprzedaż_Users” ma dostęp do udziałów, drukarek i aplikacji. Zmiana działu to przeniesienie konta do innego OU i podpięcie innych grup, zamiast ręcznego „przeklikiwania” po kilkunastu serwerach.

Skutkiem ubocznym tych mechanizmów było przejście od myślenia „użytkownik – zasób” do modelu „rola – zasób”. To z kolei otworzyło drogę do koncepcji RBAC (Role-Based Access Control), dużo łatwiejszej w utrzymaniu niż przypisywanie pojedynczych uprawnień.

Replikacja i katalog globalny – tożsamość, która jest wszędzie

W rozproszonej firmie dawniej wyglądało to tak: użytkownik w oddziale w Gdańsku nie mógł się zalogować, bo „padł” kontroler w Warszawie. Każde logowanie, każde sprawdzenie hasła, zależało od jednego centralnego serwera. Im większa odległość i większe opóźnienia, tym częściej użytkownicy narzekali na wolne logowanie czy błędy.

Architektura Active Directory została zaprojektowana z myślą o replikacji i lokalnej dostępności danych katalogowych. Kluczowe elementy to:

• wiele kontrolerów domeny w obrębie tej samej domeny, utrzymujących kopię bazy katalogowej,
• topologia replikacji oparta na sajtach (sites) i linkach, odzwierciedlających fizyczną sieć i przepustowości,
• katalog globalny (Global Catalog – GC), który przechowuje podzbiór atrybutów wszystkich obiektów z całego lasu, umożliwiając szybkie wyszukiwanie i logowanie międzydomenowe.

Dzięki GC użytkownik w filii loguje się do lokalnego kontrolera, który ma wystarczająco dużo informacji, by go uwierzytelnić i wskazać jego grupy, nawet jeśli „macierzysta” domena jest w innej części świata. Gdy replikacja jest dobrze zaprojektowana, awaria pojedynczego serwera nie paraliżuje logowań, a zmiany (np. nadanie nowych uprawnień) są rozpowszechniane w przewidywalnym czasie.

Mini-wniosek: AD wprowadziło tożsamość rozproszoną, ale spójną – użytkownik jest „ten sam” w każdym oddziale, bo jego profil i grupy są replikowane jako część jednej logiki katalogowej.

Integracja AD z innymi światem: UNIX, aplikacje, chmura

W wielu organizacjach Active Directory musiało współżyć z serwerami Linux/UNIX, urządzeniami sieciowymi i aplikacjami, które nigdy nie słyszały o GPO, ale znały LDAP czy Kerberosa. Typowy dylemat brzmiał: „czy trzymamy konta osobno, czy próbujemy to jakoś spiąć?”.

Rozwiązania wyewoluowały w kilku kierunkach:

• winbind / sssd / realmd – mechanizmy w systemach Linux pozwalające „dołączyć” host do domeny AD, używać Kerberosa i mapować użytkowników z katalogu na konta w systemie,
• RADIUS/TACACS+ z backendem na AD – uwierzytelnianie administratorów urządzeń sieciowych (routery, firewalle) przy użyciu kont domenowych,
• aplikacje webowe – integracja poprzez LDAP (pobieranie grup i atrybutów) oraz Kerberos/NTLM (Single Sign-On w sieci wewnętrznej).

W praktyce coraz częściej AD stawało się „źródłem prawdy” o użytkownikach, a reszta systemów uczyła się pytać: „kim jest ten użytkownik w katalogu?” zamiast trzymać własne, lokalne bazy kont. Na tym fundamencie pojawiły się kolejne usługi: serwery federacji (ADFS), proxy tożsamości, rozwiązania SSO dla aplikacji SaaS.

Gdy do gry weszła chmura, Microsoft dodał kolejny klockek – synchronizację katalogu do Azure AD (dziś Entra ID). W wielu firmach scenariusz wygląda obecnie tak: konta użytkowników są tworzone w AD on-premises, synchronizowane do chmury, a następnie używane do logowania do M365, aplikacji SaaS czy VPN-ów zintegrowanych z IdP w chmurze.

Od katalogu do federacji – gdy tożsamość przekracza granice firmy

W pewnej korporacji każdy partner biznesowy dostawał „gościnne” konto w wewnętrznej domenie AD. Po kilku latach okazało się, że w katalogu znajduje się kilkaset nieużywanych kont zewnętrznych, często z szerokimi uprawnieniami. Zmienność współpracy, rotacja pracowników po stronie partnerów i brak nadzoru sprawiały, że katalog zamieniał się w skansen dawnych dostępów. Dopiero przejście na federację tożsamości zmieniło reguły gry.

SAML, OAuth2, OIDC – protokoły, które oderwały logowanie od sieci lokalnej

Tradycyjne mechanizmy, takie jak Kerberos, świetnie działają w obrębie jednego, zaufanego środowiska – domeny czy lasu. Gdy jednak pojawiła się potrzeba logowania do aplikacji w Internecie, do systemów partnerów, czy usług chmurowych, zaczęły obowiązywać inne ograniczenia: brak wspólnej domeny, brak zaufania sieciowego, inne przestrzenie adresowe.

Na tym tle zaczęły dominować trzy protokoły „tożsamości webowej”:

• SAML (Security Assertion Markup Language) – oparty na XML-u standard, w którym system tożsamości (IdP) wystawia „asercję” o użytkowniku dla aplikacji (SP),
• OAuth2 – protokół autoryzacji, w którym klient otrzymuje tokeny dostępu do zasobów w imieniu użytkownika,
• OpenID Connect (OIDC) – warstwa tożsamości nad OAuth2, dodająca ID Token opisujący użytkownika.

Kluczowa zmiana była architektoniczna: aplikacja przestała trzymać hasła użytkowników czy bezpośrednio pytać katalog LDAP. Zamiast tego przekierowuje przeglądarkę użytkownika do zaufanego IdP, który go uwierzytelnia (często z użyciem AD w tle), a następnie wydaje podpisany token. Aplikacja weryfikuje podpis i na tej podstawie nadaje dostęp.

Taki model pozwolił budować zaufanie między organizacjami bez kopiowania kont. Firma A może być IdP dla swoich pracowników, a aplikacja hostedowana u partnera B ufa asercjom wystawianym przez A. Kontrola pozostaje przy macierzystej organizacji, a katalog nie musi „puchnąć” od gościnnych kont.

AD jako magazyn a IdP jako brama

W dojrzałych środowiskach Active Directory przestało być „miejscem logowania do wszystkiego”, a stało się backendem dla wyspecjalizowanych usług tożsamości. Serwer katalogowy przechowuje użytkowników, grupy i atrybuty, ale to IdP (Identity Provider) decyduje, jak i kiedy użytkownik się loguje, jakie czynniki są wymagane (MFA), jakie polityki warunkowe obowiązują.

Schemat działania przypomina trójkąt:

• AD – źródło danych o użytkowniku (grupy, dział, uprawnienia bazowe),
• IdP – warstwa uwierzytelnienia i wydawania tokenów (SAML/OIDC),
• aplikacje – konsumenci tokenów, którzy nie muszą znać szczegółów katalogu.

To rozdzielenie ról ma praktyczne konsekwencje. Wymiana IdP (np. z on-prem ADFS na usługę chmurową) nie wymaga przenoszenia katalogu. Z drugiej strony zmiana struktury OU, dodanie atrybutów czy refaktoryzacja grup może odbywać się bez angażowania zespołów developerskich – aplikacje wciąż widzą tylko to, co IdP im wystawia w tokenie.

Mini-wniosek: katalog stał się „silnikiem danych”, a nie interfejsem logowania. Warstwa interakcji z użytkownikiem przesunęła się wyżej, do IdP i protokołów webowych.

Nowe wyzwania: od „jeden login” do zarządzania całym cyklem życia tożsamości

Starszy administrator pamiętał czasy, gdy „zarządzanie tożsamością” oznaczało głównie: założyć konto, dodać do dwóch grup i raz na jakiś czas zresetować hasło. Dziś to samo środowisko musi obsłużyć pracownika etatowego, konsultanta na trzy miesiące, dostawcę systemu zdalnego, a do tego zestaw robotów RPA wykonujących operacje w systemach finansowych. Prosty model konta domenowego przestał wystarczać.

Lifecycle użytkownika: od HR do katalogu i z powrotem

W wielu firmach zmiany zaczęły się od prostego spostrzeżenia: najsłabszym ogniwem w bezpieczeństwie nie są hasła, tylko proces. Przykład: pracownik odchodzi z firmy w piątek, dział HR informuje IT w poniedziałek, a w międzyczasie były pracownik nadal może logować się z prywatnego laptopa do VPN-u.

Rozwiązaniem stało się powiązanie świata HR z katalogiem i systemami IAM. Typowy łańcuch wygląda tak:

• HR tworzy rekord nowego pracownika z przypisaną jednostką organizacyjną, stanowiskiem i lokalizacją,
• system IAM/IGA (Identity Governance & Administration) na podstawie tych danych automatycznie tworzy konto w AD, nadaje grupy, zakłada skrzynkę pocztową i przydziela dostęp do podstawowych aplikacji,
• zmiana działu w systemie HR uruchamia proces przeglądu uprawnień, przeniesienie konta do innego OU i aktualizację grup,
• zakończenie zatrudnienia skutkuje dezaktywacją konta, cofnięciem uprawnień i ewentualnym zarchiwizowaniem skrzynki.

Takie „zszycie” procesów biznesowych z katalogiem sprowadza rolę administratora z „klikania kont” do nadzoru nad regułami i wyjątkami. To także zmniejsza ryzyko pozostawionych, martwych kont, które w klasycznym modelu były ulubionym celem pentesterów i atakujących.

Role, atrybuty i polityki – logika dostępu ponad strukturą AD

Życie pokazało, że same grupy AD i OU mają granice. Pracownik może być programistą w dziale IT, ale jednocześnie członkiem komitetu bezpieczeństwa i uczestnikiem konkretnego projektu. Próba odwzorowania tego wszystkiego wyłącznie w grupach katalogowych kończy się potężnym gąszczem: „Projekt_X_Read”, „Projekt_X_Write”, „Komitet_Bezpieczeństwa”, „IT_Dev_Admin” i tak dalej.

Dlatego nad AD zaczęto budować dodatkowe warstwy logiki:

• role biznesowe – definiowane w systemach IGA, przypisujące zestawy dostępów na podstawie funkcji w organizacji,

Najczęściej zadawane pytania (FAQ)

Na czym polegało ręczne zarządzanie kontami użytkowników przed katalogami takimi jak NDS czy Active Directory?

Administrator logował się po kolei na każdy serwer i każdą stację roboczą, żeby założyć, zmienić lub skasować konto. Nowy pracownik dostawał osobne loginy i hasła do serwera plików, programu księgowego czy modemu, a po kilku miesiącach nikt już nie pamiętał, gdzie ma które uprawnienia.

W praktyce „tożsamość” pracownika była zlepkiem lokalnych wpisów: plików /etc/passwd na Unixach, kont lokalnych w DOS/Windows czy własnych baz aplikacji. Przy odejściu z firmy trzeba było gasić konta w wielu miejscach z osobna, co sprzyjało zostawianiu „duchów” – działających nadal loginów na zapomnianych serwerach.

Czym różniło się zarządzanie kontami w Uniksie (plik /etc/passwd) od podejścia Novell NetWare 3.x?

Na klasycznym Uniksie każda maszyna miała własny plik /etc/passwd (i później /etc/shadow) z listą użytkowników. Ten sam człowiek mógł mieć inne loginy i hasła na różnych serwerach, a admin musiał ręcznie synchronizować zmiany między nimi, co przy kilku czy kilkunastu hostach szybko zamieniało się w chaos.

W NetWare 3.x pojawił się mechanizm bindery – lokalna baza użytkowników i grup związana z konkretnym serwerem Novella. Ułatwiało to zarządzanie w obrębie jednego serwera plików czy drukarek, ale wciąż tworzyło „wyspy” – każdy większy serwer miał swoje konta, a użytkownicy i administratorzy zmagali się z duplikacją loginów i niespójnymi uprawnieniami między oddziałami.

Co to jest Novell Directory Services (NDS) i dlaczego było przełomem w latach 90.?

Wyobraź sobie firmę, w której ktoś wreszcie wprowadza jedno konto do wszystkiego – logujesz się raz i masz dostęp do swoich udziałów sieciowych, drukarek i aplikacji. Tym właśnie było NDS: centralnym katalogiem, który przechowywał informacje o użytkownikach, grupach, serwerach, drukarkach i innych zasobach w jednym logicznym drzewie.

NDS zastąpiło rozproszone bindery jednym, hierarchicznym katalogiem z replikacją między serwerami NetWare. Administratorzy dostali jedno miejsce do zarządzania kontami i uprawnieniami, a serwery zaczęły traktować katalog jako źródło prawdy: pytały „kim jest ten użytkownik i co może?”, zamiast przechowywać lokalne listy kont.

Na czym polegała różnica między binderami w NetWare 3.x a drzewem katalogowym NDS w NetWare 4.x?

Bindery w NetWare 3.x działały jak osobne notesy z użytkownikami – każdy serwer miał własną bazę, a integracja między nimi była ograniczona. Dla małej sieci z jednym głównym serwerem to działało, ale przy rozbudowie infrastruktury prowadziło do dublowania kont i trudnego w utrzymaniu bałaganu uprawnień.

NDS w NetWare 4.x wprowadził jedno logiczne drzewo katalogowe dla całej organizacji. Zamiast wielu lokalnych baz pojawiły się kontenery (np. jednostki organizacyjne) i obiekty (użytkownicy, grupy, serwery, drukarki), a uprawnienia nadawano względem tej struktury. Dzięki replikacji katalogu między serwerami całość była odporna na awarie pojedynczych maszyn i skalowała się znacznie lepiej.

Jak ewolucja od Novell NetWare do Active Directory zmieniła zarządzanie tożsamością w firmach?

Na początku tożsamość w sieci oznaczała „konto na konkretnym serwerze” – osobne loginy do plików, aplikacji, drukarek. Novell NetWare z NDS przesunął ciężar na „konto w katalogu organizacji”, a serwery zaczęły pełnić rolę klientów pytających katalog o użytkownika i jego prawa.

Active Directory przejęło tę ideę, łącząc katalog z innymi usługami Windows (domeny, polityki grup, DNS). Firmy mogły dzięki temu wdrożyć jednokrotne logowanie w środowiskach Windows, centralne polityki bezpieczeństwa i spójny model zarządzania tożsamością, który zastąpił zeszyty z hasłami i ręczne poprawianie kont na dziesiątkach maszyn.

Dlaczego centralny katalog użytkowników stał się konieczny wraz ze wzrostem sieci lokalnych?

W małej firmie z jednym serwerem plików jeszcze da się spamiętać, kto ma jakie konto. Gdy jednak dochodzą kolejne serwery, aplikacje, oddziały i działy firmy, ręczne pilnowanie loginów i haseł zaczyna generować błędy, luki bezpieczeństwa i straty czasu – szczególnie przy rotacji pracowników.

Centralny katalog rozwiązuje ten problem, bo:

• przechowuje jedną tożsamość użytkownika dla całej organizacji,
• pozwala nadawać i odbierać uprawnienia w jednym miejscu,
• ułatwia egzekwowanie polityk bezpieczeństwa (np. wymuszanie zmiany hasła, blokowanie nieaktywnych kont),
• dzięki replikacji między serwerami skaluje się wraz z rozwojem sieci, bez uzależnienia od pojedynczej maszyny.