Nowości Active Directory – Protected Users

17 marca 2015 at 07:36

W części drugiej mini-cyklu o nowościach w Active Directory na poziomie funkcjonalności Windows Server 2012 R2 przedstawiam funkcjonalność użytkowników chronionych (Protected Users).

Zacznijmy od wymagań aby móc skorzystać z tego dobrodziejstwa. Konieczne do spełnienia są następujące warunki:

  • Rozszerzony schemat Active Directory do poziomu Windows Server 2012 R2 (wersja schematu – 69)
  • Kontroler domeny pełniący rolę PDC pod kontrolą Windows’a Server 2012 R2

Plus dwa warunki dodatkowe:

  • Poziom funkcjonalności domeny na poziomie Windows Server 2012 R2 – aby zapewnić pełną ochronę kontrolerów domeny
  • Konieczność logowania na Windows 8.1* lub Windows Server 2012 R2 z uwierzytelnieniem na kontrolerze domeny pracującym pod kontrolą Windows Server 2012 R2 – aby móc w pełni wykorzystać oferowane rozwiązanie po stronie klienta oraz kontrolerów domeny.

To tyle z wymagań formalnych – trochę dużo… ale można oczywiście nieco pokombinować i zrobić to w sposób wymagający mniejszego zachodu niż upgrade całego lasu Active Directory.

Jako minimum – Rozszerzenie schematu AD, upgrade PDC do Windows 2012 R2 (lub wypromowanie na chwilę nowego kontrolera domeny na Windows 2012R2), transfer PDC na ten kontroler – replikacja danych na pozostałe kontrolery domeny i już mamy funkcjonalność Protected Users. Teraz można powrócić z PDC na wcześniejszy kontroler domeny i mieć nową funkcjonalność (co prawda nie pełną… ale zawsze) na starym sprzęcie – jeśli ktoś tak chce :)

Wracając jednak do sedna…

Protected Users – o co tyle szumu? Przecież jest już sporo sposobów ochrony bardziej wrażliwych na ataki kont takich jak obiekty PSO wymuszającymi inne zasady haseł, chronione grupy, AdminSDHolder, uprawnienia do logowania w wybranych godzinach, na wybranych stacjach, wyłączenie uprawnień logowania sieciowego czy w trybie usługi itd. Co zyskamy wdrażając ten nowy mechanizm? Czy jest on w ogóle przydatny i potrzebny?

Okazuje się, że tak. Żaden inny dostępny dotąd mechanizm nie pozwalał na modyfikację czasu życia kerberosowych biletów TGT (ang. Ticket Granting Tickets), czy na swobodne wyłączenie mniej bezpiecznych protokołów uwierzytelniania (np. NTLM), czy sposobów szyfrowania (np. DES) per wybrany użytkownik, bez modyfikacji globalnych.

Jak jednak w rzeczywistości działa mechanizm chronienia użytkowników? Zasadniczo składa się z dwóch poziomów zabezpieczeń:

  1. Ochrony po stronie klienta – w przypadku gdy użytkownik będący objęty ochroną loguje się na stacji z Windowsem 8.1 lub na serwerze z Windows Server 2012 R2
  2. Ochrony po stronie kontrolera domeny – wymagania jak w przypadku ochrony po stronie klienta + dodatkowo konto użytkownika w domenie o poziomie funkcjonalności Windows Server 2012 R2.

W przypadku gdy użytkownik loguje się na starszych systemach operacyjnych funkcjonalność nie działa, niezależnie od poziomu funkcjonalności domeny.

Zobaczmy natomiast szczegółowo jakie mechanizmy ochrony zyskujemy. Które z nich działają po stronie klienta, a które po stronie kontrolera domeny – oraz jakie ograniczenia narzuca członkostwo w grupie „Protected Users”:

Funkcjonalność Ochrona po stronie klienta Ochrona po stronie kontrolera domeny
Możliwość uwierzytelnienia z wykorzystaniem NTLM X
Możliwość uwierzytelnienia z wykorzystaniem Digest Authentication X
Możliwość uwierzytelnienia z wykorzystaniem Digest CredSSP X
Hasła w postaci czystego tekstu (digest) nie mogą być bufrowane lokalnie X
Hasła NTLM – NTOWF nie mogą być buforowane lokalnie X
Brak logowania buforowanego (cached logon) X
Brak szyfrowania żądań kerberosa z wykorzystaniem DES X
Brak szyfrowania żądań kerberosa z wykorzystaniem RC4 X
Brak możliwości ograniczonej kerberosowej delegacji konta X
Brak możliwości nieograniczonej kerberosowej delegacji konta X
Maksymalny czas życia kerberosowego biletu użytkownika – 240 minut X X
Maksymalny czas odnowienia kerberosowego biletu użytkownika – 240 minut X X

 

Jak widać w powyższej tabelce mechanizmów tych jest całkiem sporo. Zapewniają one wyższy poziom ochrony niż dotychczas i co najważniejsze nakładane są w prosty sposób – przez dodanie do grupy, bez konieczności wygrzebywania poszczególnych ustawień z poziomu GPO.

Ale kolejna uwaga – testujemy, testujemy, testujemy w swoim środowisku zanim dodamy wszystkie konta do grupy Protected Users, ponieważ narzucone ograniczenia nie mają obejścia. Oznacza to, że jeśli dodamy tu wszystkie konta administratorów domeny i nie będziemy się mogli żadnym zalogować czeka nas zapewne przywracania Active Directory z backupu…

Dobra rada – przed dodaniem jakiegoś konta do grupy Protected Users ustawcie mu nowe hasło, żeby mieć pewność, że hasło nie było ustawiane jeszcze w czasach Windows 2008. Unikniecie dzięki temu problemów z późniejszym uwierzytelnianiem.

 

*Po instalacji poprawki KB2871997 funkcjonalność Protected users może być wykorzystywana również w starszych systemach operacyjnych.