W latach 90. Novell był w Polsce bardzo popularny, ale na komputerach użytkowników coraz częściej pojawiał się Windows. Microsoft miał już własny mechanizm domen w Windows NT, jednak jego możliwości były ograniczone. Domeny pozwalały na centralne przechowywanie kont i uwierzytelnianie użytkowników, lecz wraz ze wzrostem organizacji administracja stawała się coraz trudniejsza. Brakowało hierarchicznego katalogu, wygodnego delegowania uprawnień oraz spójnego sposobu zarządzania użytkownikami, komputerami i konfiguracją systemów. Odpowiedzią Microsoftu było Active Directory.

Autor: 7 min czytania

Co było przed Active Directory?

W domenach Windows NT informacje o użytkownikach i grupach znajdowały się w bazie Security Accounts Manager, czyli SAM. Jeden kontroler pełnił rolę Primary Domain Controller, a pozostałe działały jako Backup Domain Controllers. Model był stosunkowo prosty, ale miał ograniczenia. Zmiany w bazie domeny wykonywano na głównym kontrolerze, a następnie replikowano je do kontrolerów zapasowych. W większych organizacjach tworzono wiele domen i zestawiano między nimi relacje zaufania. W efekcie infrastruktura potrafiła szybko zamienić się w skomplikowaną sieć domen, kont i trustów. Zarządzanie takim środowiskiem wymagało nie tylko wiedzy technicznej, lecz także dobrej dokumentacji – najlepiej aktualnej.

Microsoft potrzebował rozwiązania, które połączy katalog użytkowników z systemem operacyjnym, komputerami, uwierzytelnianiem i politykami bezpieczeństwa.

Kiedy pojawiło się Active Directory?

Active Directory zadebiutowało razem z Windows 2000 Server, którego światowa premiera odbyła się 17 lutego 2000 roku. Była to jedna z najważniejszych zmian w historii serwerowych systemów Microsoftu. Firma przedstawiała Active Directory jako centralny element zarządzania nową generacją środowisk Windows (Microsoft Source). Nowy katalog korzystał ze standardów znanych już z wcześniejszych usług katalogowych. LDAP służył do wyszukiwania i modyfikowania obiektów, DNS pomagał w odnajdywaniu usług domenowych, a Kerberos stał się podstawowym protokołem uwierzytelniania. Active Directory nie wymyśliło więc katalogu od nowa. Microsoft połączył istniejące standardy z systemem Windows i narzędziami administracyjnymi w jeden spójny mechanizm.

Dlaczego DNS stał się taki ważny?

W czasach Windows NT wielu administratorów kojarzyło DNS przede wszystkim z Internetem. W Active Directory stał się on jednym z fundamentów działania domeny. Komputer musi wiedzieć, gdzie znajduje się kontroler domeny, serwer katalogowy albo usługa Kerberos. Active Directory publikuje te informacje za pomocą rekordów DNS. Bez prawidłowo działającego DNS użytkownik może nie zalogować się do domeny, komputer może nie odnaleźć kontrolera, a zasady grupy mogą nie zostać zastosowane.

To dlatego próba wpisania publicznego serwera DNS bezpośrednio na karcie sieciowej komputera domenowego potrafiła kończyć się trudnymi do wyjaśnienia problemami.

Microsoft podkreśla, że Active Directory Domain Services wykorzystuje otwarte standardy internetowe, w tym LDAP i DNS, do lokalizowania oraz udostępniania informacji o obiektach i usługach (Microsoft Learn).

Co zmienił Kerberos?

LDAP odpowiadał za dostęp do katalogu, ale potrzebny był jeszcze mechanizm potwierdzający tożsamość użytkownika. W domenach Windows 2000 tę rolę przejął Kerberos. Po zalogowaniu użytkownik otrzymuje bilet, który może być później wykorzystany celem uzyskania dostępu do kolejnych usług. Hasło nie musi być ponownie przesyłane do każdego serwera plików, aplikacji czy bazy danych. Możliwe staje się Single Sign-On w obrębie domeny. Kerberos umożliwia również wzajemne uwierzytelnienie. Nie tylko usługa sprawdza użytkownika – użytkownik także może upewnić się, czy łączy się z właściwą usługą. Podstawy współczesnej wersji protokołu opisuje RFC 4120. Dla użytkownika efekt był prosty: jedno logowanie do komputera otwierało drogę do wielu zasobów firmowych.

Dlaczego Group Policy było tak dużą zmianą?

Active Directory nie ograniczało się do przechowywania kont. Komputery również stały się obiektami katalogu, a administratorzy otrzymali możliwość centralnego zarządzania ich konfiguracją. Group Policy pozwoliło na określanie ustawień systemu, zabezpieczeń,  skryptów logowania, mapowania zasobów czy sposobu działania aplikacji. Zasady można było przypisywać do lokalizacji, domen i jednostek organizacyjnych. W praktyce oznaczało to, że konfiguracja setek lub tysięcy komputerów nie musiała być wykonywana ręcznie. Nowy komputer dołączony do domeny mógł automatycznie otrzymać ustawienia obowiązujące w danej części organizacji. To właśnie połączenie katalogu, uwierzytelniania i centralnej konfiguracji odróżniało Active Directory od samego LDAP.

Dlaczego Active Directory wygrało?

Przewagą Active Directory nie był pojedynczy mechanizm. Liczyła się integracja.

Użytkownik logował się do Windows. Komputer należał do domeny. Kerberos zapewniał uwierzytelnianie. LDAP udostępniał informacje z katalogu. DNS pozwalał na odnajdywanie kontrolerów i usług, a Group Policy zarządzało konfiguracją stacji roboczych oraz serwerów. Do tego dochodziły grupy zabezpieczeń, delegowanie administracji, relacje zaufania, hierarchia domen i lasów oraz integracja z aplikacjami. Microsoft opisuje dziś AD DS jako usługę zapewniającą nie tylko katalog LDAP, lecz także uwierzytelnianie, zarządzanie obiektami komputerów, zasady grupy i trusty (Microsoft Learn). Dla organizacji korzystających z Windows wybór Active Directory był więc naturalny. Nie trzeba było budować osobno katalogu, systemu logowania i narzędzi do zarządzania komputerami.

Dlaczego ten model nie wystarczył chmurze?

Active Directory powstało dla środowiska, w którym użytkownik, komputer i aplikacja znajdowali się najczęściej w tej samej sieci organizacji. Dostęp był oparty na domenie, kontrolerach domeny i protokołach projektowanych z myślą o firmowej infrastrukturze.

Chmura zmieniła te założenia. Użytkownicy zaczęli pracować z dowolnego miejsca, na różnych urządzeniach i poza siecią firmową. Aplikacje przestały działać wyłącznie na serwerach należących do organizacji. Coraz częściej były usługami SaaS, dostępnymi przez przeglądarkę i utrzymywanymi przez zewnętrznego dostawcę. Dołączenie każdej aplikacji do domeny nie było możliwe. Tradycyjne protokoły, takie jak Kerberos i LDAP, nadal były potrzebne lokalnie, ale świat usług internetowych wymagał federacji oraz tokenów przenoszonych przez HTTP.

Active Directory zdominowało środowiska lokalne, jednak rozwój chmury wymusił zupełnie nowe podejście do uwierzytelniania. W kolejnym artykule z tej serii opowiemy, dlaczego w świecie SaaS bilet Kerberos musiał ustąpić miejsca federacji i tokenom.