Windows Server Insider Preview: Active Directory jednak żyje

Ogłoszono nowości w usłudze Active Directory. Informacja, opublikowana w dokumencie na portalu Microsoft Learn na początku miesiąca, została zignorowana przez media i branżę. Wieloletnie oczekiwanie na progres w rozwoju usług domenowych znużyło administratorów.

Usługa Active Directory (AD) jest w powszechnym użyciu w wielu firmach i przez wiele lat będzie stanowić nieusuwalny element korporacyjnych sieci. Microsoft nalega, by użytkownicy przeszli na rozwiązania chmurowe, jak Entra i Sentinel, ale nie pokrywają się one funkcjonalnie z wysłużonym Active Directory. Są także niemożliwe do wdrożenia w sieciach izolowanych. Z tych względów na AD zawsze będzie zapotrzebowanie.

Mimo pokaźnego zbioru brakujących funkcji i wciąż dużego pola do potencjalnego rozwoju, Microsoft od lat nie inwestował w rozwój AD. Można ten fakt tłumaczyć silnym skupieniem na chmurze, ale nie mniej prawdopodobne jest wytłumaczenie, że Active Directory należy do zbioru produktów, które "i tak ktoś kupi", przez co nie warto ich rozwijać. Zawsze ktoś gdzieś potrzebuje AD.

Dalsza część artykułu pod materiałem wideo

Microsoft ma więcej zamrożonych w czasie programów, które wciąż sprzedaje. Programy Access, Publisher i Visio nie otrzymały znaczących nowych funkcji już od wielu lat. Ponieważ jednak istnieje masa krytyczna klientów, którzy regularnie kupują nowe wersje i nie zapowiada się, by było tych klientów więcej, obecny model amortyzuje wydatki nie wykazując zarazem zasadności głębszych inwestycji.

Podobnie sprawa ma się z AD: można dodać nowe funkcje, ale nie ma to biznesowego uzasadnienia. Duże korporacje i tak kupią nowe wersje Windows Server, liczba dużych firm jest raczej stała, a te nowe i najbardziej dynamiczne, od początku budują systemy tożsamości oparte o Entrę (Azure Active Directory) lub zestawy autorstwa Google.

Dlatego tak zaskakujące są dobre wieści z projektu Windows Insider: kompilacja 25951 systemu o roboczej nazwie "Windows Server vNEXT" wprowadza nowy poziom funkcjonalny domeny i pierwsze od siedmiu lat nowe funkcje. Zaktualizowana jest także schema Active Directory, co oznacza zmiany w wewnętrznej strukturze - niegdyś regularne, obecnie bardzo rzadkie. Poza zmianami wewnątrz bazy zmienia się dużo mechanizmów komunikacji z domeną. Mają one na celu zwiększenie bezpieczeństwa i są bardzo pożądane. W praktyce jednak przydatne byłyby bardziej radykalne reformy.

Niemniej, zmiany są niewątpliwymi usprawnieniami. Od teraz obowiązkowe jest szyfrowanie podczas operowania na poufnych atrybutach. Domyślne jest także "wiązanie kanałów LDAP" (LDAP Channel Binding), szyfrowanie łączności LDAP oraz TLS 1.3 dla łączności LDAP-over-TLS. Żądania zmiany hasła są obowiązkowo szyfrowane z użyciem AES, a tradycyjne żądania SAM RPC są zablokowane. Wzmocniony został także Kerberos (dokładniej mówiąc - jego Microsoftowa implementacja), poprzez dodanie obsługi SHA-384 i usunięcie RC4. Minimalny poziom funkcjonalny domeny to teraz Windows Server 2016. System ten jest w stanie działać z nowymi mechanizmami zabezpieczeń. Są one bowiem dostępne w Windowsach od wielu lat - ale w obawie o zgodność bardzo długo nie były włączone domyślnie.

Microsoft zwiększył prędkość usuwania starych, niemożliwych do zabezpieczenia protokołów. Ogłoszono już usunięcie WINS, a wkrótce niemożliwe będzie włączenie SMB1 - usuwana jest implementacja tego protokołu, mającego swoje początki nie w pierwszej wersji NT, a wcześniej: w systemie OS/2 LAN Manager. Nadchodzi koniec NTLM. Podobny los czeka wkrótce protokoły LLMNR i PNRP. Składnikiem na żądanie zostaje także Visual Basic Script, a od pewnego czasu możliwe jest wyłączenie HTA. Wciąż niemożliwa jest skuteczna kontrola nad skryptami PowerShell i istnieje wiele metod obejścia blokady polityki wykonawczej i nie słychać jeszcze o zmianach w tej kwestii.

Windows Server staje się jednak znacznie bezpieczniejszy. Odbędzie się to kosztem zgodności: starsze składniki domeny nie będą w stanie dogadać się z nowymi kontrolerami. Ale taka jest cena bezpieczeństwa. Klasycznych mechanizmów komunikacji w NT nie da się zabezpieczyć - nie pozwala na to ich architektura. Ufortyfikowanie Active Directory wciąż pozostaje jednak trudnym zadaniem. Jest to niezależne od bezpieczeństwa protokołów komunikacyjnych.