Strona Kreatora instalacji usług domenowych w usłudze Active Directory Określanie zasad replikacji haseł jest wyświetlana podczas tworzenia konta kontrolera domeny tylko do odczytu (RODC), ale tylko wtedy, gdy zostało zaznaczone pole wyboru Użyj instalacji w trybie zaawansowanym na stronie kreatora Kreator instalacji usług domenowych w usłudze Active Directory - Zapraszamy!

Opis działania zasad replikacji haseł

Zasady replikacji haseł (PRP, Password Replication Policy) określają sposób buforowania poświadczeń przez kontroler RODC. Buforowanie poświadczeń polega na przechowywaniu poświadczeń użytkownika lub komputera.

Jeśli użytkownicy lub komputery w lokacji obsługiwanej przez kontroler RODC próbują uwierzytelnić się w domenie, domyślnie kontroler nie może sprawdzić ich poświadczeń. Kontroler RODC przekazuje żądanie uwierzytelnienia do zapisywalnego kontrolera domeny. Może jednak istnieć zestaw podmiotów zabezpieczeń, które potrzebują możliwości uwierzytelnienia w lokacji obsługiwanej przez kontroler RODC nawet wtedy, gdy nie ma łączności z zapisywalnymi kontrolerami.

Na przykład może istnieć zestaw użytkowników i komputerów w oddziale, który chcesz uwierzytelniać nawet wtedy, gdy nie ma łączności między oddziałem a lokacjami zawierającymi zapisywalne kontrolery domeny. Aby rozwiązać ten problem, można skonfigurować zasady replikacji haseł dla tego kontrolera RODC, aby zezwolić na buforowanie haseł tych użytkowników na tym kontrolerze. Jeśli hasła kont są buforowane na kontrolerze RODC, można uwierzytelniać te konta przy braku łączności z zapisywalnymi kontrolerami domeny.

Zasady replikacji haseł działają jak lista kontroli dostępu (ACL). Określają, czy kontroler RODC może buforować poświadczenia konta. Po otrzymaniu żądania zalogowania od użytkownika lub komputera kontroler RODC próbuje zreplikować poświadczenia dla tego konta z zapisywalnego kontrolera domeny z systemem Windows Server 2008 lub Windows Server 2008 R2. Zapisywalny kontroler domeny sprawdza zasady replikacji haseł, aby ustalić, czy poświadczenia konta powinny być buforowane. Jeśli zasady replikacji haseł na to zezwalają, zapisywalny kontroler domeny replikuje poświadczenia konta na kontroler RODC, który je buforuje. Podczas kolejnych logowań na to konto kontroler RODC może uwierzytelniać konto przy użyciu buforowanych poświadczeń. Kontroler RODC nie musi kontaktować się z zapisywalnym kontrolerem domeny.

Zasady replikacji haseł w praktyce

Zasady replikacji haseł są definiowane przez dwa wielowartościowe atrybuty usługi Active Directory, które zawierają podmioty zabezpieczeń (użytkowników, komputery i grupy). Każde konto komputera kontrolera RODC ma dwa atrybuty:

  • msDS-Reveal-OnDemandGroup, znany także jako lista dozwolonych.

  • msDS-NeverRevealGroup, znany także jako lista odrzuconych.

Aby ułatwić zarządzanie zasadami replikacji haseł, dla każdego kontrolera RODC są utrzymywane dwa inne atrybuty związane z replikacją:

  • msDS-RevealedList, znany także jako lista ujawnionych.

  • msDS-AuthenticatedToAccountList, znany także jako lista uwierzytelnionych.

Atrybut msDS-Reveal-OnDemandGroup określa, dla których podmiotów zabezpieczeń można buforować hasła na kontrolerze RODC. Domyślnie ten atrybut ma jedną wartość: Grupa, dla której jest dozwolona replikacja haseł na kontrolerach RODC. Ponieważ ta grupa lokalna domeny domyślnie nie ma żadnych członków, na kontrolerze RODC nie można buforować żadnych haseł.

W tej sekcji wyjaśniono sposób korzystania z atrybutów list dozwolonych, odrzuconych, ujawnionych i uwierzytelnionych.

Gdy kontroler RODC zgłasza żądanie replikacji hasła użytkownika, zapisywalny kontroler domeny z systemem Windows Server 2008, z którym kontaktuje się kontroler RODC, zezwala lub odrzuca to żądanie. Aby zezwolić lub odrzucić żądanie, zapisywalny kontroler domeny sprawdza wartości z listy dozwolonych i odrzuconych dla kontrolera RODC, który przedstawia to żądanie.

Jeśli kontroler RODC wysłał żądanie o hasło do konta, które znajduje się na liście dozwolonych (a nie na liście odrzuconych) dla tego kontrolera RODC, żądanie zostanie dozwolone.

Na poniższej ilustracji przedstawiono przebieg tej operacji.

Proces stosowania zasad replikacji hasła

Lista odrzuconych ma pierwszeństwo przed listą dozwolonych.

Załóżmy na przykład, że w organizacji istnieje grupa zabezpieczeń dla administratorów o nazwie Admini. W organizacji istnieje jedna lokacja o nazwie S1 i grupa zabezpieczeń o nazwie Emp_S1, w której umieszczono pracowników tej lokacji. W organizacji istnieje też inna lokacja o nazwie S2 i grupa zabezpieczeń o nazwie Emp_S2, w której umieszczono pracowników tej lokacji.

Lokację S2 wyposażono tylko w kontroler RODC. Tomasz jest administratorem, który pracuje w lokacji S2. Dlatego należy on do obu grup, czyli do grupy Emp_S2 i do grupy Admini. Po zainstalowaniu kontrolera RODC w lokacji S2, grupy zabezpieczeń podane w poniższej tabeli zostaną dodane do zasad replikacji haseł.

Grupa zabezpieczeń Ustawienie zasad replikacji haseł

Admini

Zabronione

Emp_S2

Dozwolone

Zgodnie z określonymi zasadami poświadczenia, które można buforować na kontrolerze RODC w lokacji S2, to poświadczenia członków grupy Emp_S2 nienależących do grupy Admini. Poświadczenia członków grupy Emp_S1 i grupy Admini nie będą nigdy buforowane na kontrolerze RODC. Członkowie grupy Emp_S2 mogą buforować swoje poświadczenia na kontrolerze RODC. Poświadczenia Tomasza nie będą nigdy buforowane na kontrolerze RODC.

Domyślne ustawienia zasad replikacji haseł

Każdy kontroler RODC wyposażono w zasady replikacji haseł określające, dla których kont można replikować hasła na kontrolerze RODC, a dla których kont nie można jawnie replikować haseł na kontrolerze RODC. Zasady domyślne określają grupy i ustawienia podane w poniższej tabeli.

Nazwa grupy Ustawienie zasad replikacji haseł

Administratorzy

Odmawiaj

Operatorzy serwerów

Odmawiaj

Operatorzy kopii zapasowych

Odmawiaj

Operatorzy kont

Odmawiaj

Grupa, dla której nie jest dozwolona replikacja haseł na kontrolerach RODC

Odmawiaj

Grupa, dla której jest dozwolona replikacja haseł na kontrolerach RODC

Zezwalaj

Grupa, dla której nie jest dozwolona replikacja haseł na kontrolerach RODC, domyślnie zawiera następujących członków konta domeny:

  • Wydawcy certyfikatów

  • Administratorzy domeny

  • Administratorzy przedsiębiorstwa

  • Kontrolery domeny przedsiębiorstwa

  • Kontrolery domeny tylko do odczytu na poziomie organizacji

  • Twórcy-właściciele zasad grupy

  • Konto krbtgt

  • Administratorzy schematu

Grupa, dla której jest dozwolona replikacja haseł na kontrolerach RODC, domyślnie nie ma żadnych członków.

Domyślne zasady replikacji haseł podnoszą poziom zabezpieczeń instalacji kontrolera RODC, zapewniając, że żadne hasła konta nie są domyślnie przechowywane, a zapisywanie na kontrolerze RODC haseł kont istotnych dla zabezpieczeń (takich jak konta członków grupy Administratorzy domeny) jest jawnie zablokowane.

Modyfikowanie domyślnych zasad replikacji haseł

Domyślne zasady replikacji haseł można modyfikować podczas tworzenia konta dla kontrolera RODC lub po utworzeniu konta kontrolera RODC. Aby zmodyfikować domyślne zasady replikacji haseł po utworzeniu konta kontrolera RODC, kliknij prawym przyciskiem myszy konto kontrolera RODC w jednostce organizacyjnej Kontrolery domeny w przystawce Użytkownicy i komputery usługi Active Directory, kliknij polecenie Właściwości, a następnie kliknij kartę Zasady replikacji haseł. (Aby otworzyć przystawkę Użytkownicy i komputery usługi Active Directory, kliknij przycisk Start, wskaż polecenie Narzędzia administracyjne, a następnie kliknij polecenie Użytkownicy i komputery usługi Active Directory).

Aby dodać konta do domyślnych zasad replikacji haseł podczas tworzenia konta kontrolera RODC, kliknij przycisk Dodaj na stronie kreatora Określanie zasad replikacji haseł, a następnie określ, czy chcesz zezwolić na przechowywanie haseł dla danego konta na kontrolerze RODC czy zabronić go. Następnie w oknie dialogowym Wybieranie użytkowników, komputerów lub grup wybierz konta, które mają zostać dodane.

Aby zezwolić kontrolerowi RODC na lokalne spełnianie żądań uwierzytelniania i biletów usług, w zasadach replikacji haseł należy umieścić odpowiednie konta użytkowników, komputerów i usług. Jeśli na liście dozwolonych nie zostaną uwzględnione konta komputerów, które będą używane przez użytkowników w oddziale firmy do logowania do sieci, kontroler RODC nie będzie mógł spełniać lokalnie żądań dotyczących biletów usług i w zakresie spełniania tych żądań będzie zależny od dostępu do zapisywalnego kontrolera domeny. Jeśli sieć rozległa (WAN) jest wyłączona, może to spowodować awarię usług.

Ustawienie Odmawiaj ma pierwszeństwo przed ustawieniem Zezwalaj. Jeśli zostaną określone oba ustawienia dla danego użytkownika - bezpośrednio lub pośrednio w przypadku, gdy użytkownik jest członkiem określonej grupy zabezpieczeń (lub jest zagnieżdżony w określonej grupie zabezpieczeń) - hasło tego użytkownika nie może być przechowywane na kontrolerze RODC. Należy jednak podkreślić, że użytkownik, którego hasło nie może być przechowywane na kontrolerze RODC, może nadal używać kontrolera RODC do logowania, jeśli jest dostępne połączenie sieci WAN z zapisywalnym kontrolerem domeny. Hasło dla tego użytkownika nie jest replikowane na kontrolerze RODC, ale można uwierzytelniać logowanie za pomocą zapisywalnego kontrolera domeny przez sieć WAN.

W poniższej tabeli opisano zalety i wady trzech przykładowych konfiguracji zasad replikacji haseł.

Przykład Zalety Wady

Bez buforowania kont (ustawienie domyślne)

Najwyższy poziom bezpieczeństwa. Użytkownicy są uwierzytelniani przez zapisywalny kontroler domeny, ale otrzymują zasady grupy z kontrolera RODC w celu szybkiego przetwarzania zasad.

Bez dostępu offline - do logowania jest potrzebna sieć WAN.

Buforowanie większości kont

Łatwość zarządzania hasłami - to jest rozwiązanie dla organizacji, które najbardziej interesuje usprawnienie zarządzania kontrolerami RODC, a nie zabezpieczenia.

Więcej haseł potencjalnie dostępnych dla kontrolera RODC.

Buforowanie niewielu kont

Umożliwia dostęp offline dla tych użytkowników, którzy tego potrzebują, ale zapewnia wyższy poziom bezpieczeństwa niż buforowanie większości kont.

Ta metoda wymaga administracji na wyższym poziomie szczegółowości. Może się okazać, że trzeba zamapować użytkowników i komputery na każdy oddział z kontrolerem RODC. Można też korzystać z narzędzi, takich jak repadmin /prp, w celu przenoszenia kont uwierzytelnionych przez kontroler RODC do grupy znajdującej się na liście elementów dozwolonych. Może być konieczne używanie Menedżera cyklu trwania tożsamości (ILM, Identity Lifecycle Manager) w celu zautomatyzowania tego procesu.

Każdy z przykładów opisano szczegółowo w kolejnych sekcjach.

Bez buforowania kont

Ten przykład stanowi najbezpieczniejsze rozwiązanie. Hasła nie są replikowane do kontrolera RODC z wyjątkiem konta komputera z kontrolerem RODC i jego specjalnego konta krbtgt. Jednakże uwierzytelnianie użytkownika i komputera jest uzależnione od dostępności sieci WAN. Przewaga tego przykładu polega na tym, że nie wymaga żadnych bądź prawie żadnych zmian w domyślnych ustawieniach konfiguracji administracyjnej.

Grupy użytkowników wymagające wysokiego poziomu zabezpieczeń można dodać do listy odrzuconych. Chociaż domyślnie żadne konta nie podlegają buforowaniu, dodanie tych grup do listy odrzuconych umożliwia ich ochronę przed przypadkowym włączeniem do listy dozwolonych i następstwem tego w postaci buforowania ich haseł na kontrolerze RODC.

Należy pamiętać, że konto z delegowanymi uprawnieniami administratora kontrolera RODC nie jest automatycznie dodawane do listy dozwolonych. Najlepiej dodać to konto do listy dozwolonych, aby upewnić się, że użytkownik z delegowanymi uprawnieniami administratora może zawsze zalogować się do kontrolera RODC, niezależnie od tego, czy jest dostępne połączenie sieci WAN z zapisywalnym kontrolerem domeny.

Buforowanie większości kont

Ten przykład to najprostszy tryb administracyjny, umożliwiający wyeliminowanie zależności uwierzytelniania użytkowników i komputerów od dostępności sieci WAN. Lista elementów dozwolonych dla wszystkich kontrolerów RODC zawiera grupy skupiające znaczną część zbiorowości użytkowników. Lista odrzuconych uniemożliwia buforowanie haseł dla grup użytkowników wymagających wysokiego poziomu zabezpieczeń, takich jak Administratorzy domeny. Jednak większość innych użytkowników może buforować swoje hasła na żądanie. Grupy użytkowników wymagające wysokiego poziomu zabezpieczeń można dodać do listy odrzuconych.

Ta konfiguracja jest najbardziej odpowiednia w środowiskach, gdzie fizyczne bezpieczeństwo kontrolera RODC nie jest zagrożone. Na przykład można skonfigurować w ten sposób zasady replikacji haseł dla kontrolera RODC wdrożonego w bezpiecznej lokalizacji głównie w celu skorzystania z mniejszych wymagań w zakresie replikacji i administrowania.

Ważne

Trzeba też dodać konta komputerów użytkowników do listy dozwolonych, aby umożliwić użytkownikom logowanie w oddziale, gdy łącze sieci WAN jest niedostępne.

Buforowanie niewielu kont

W tym przykładzie liczba kont, które mogą być buforowane, jest ograniczona. Zazwyczaj określa się to osobno dla każdego kontrolera RODC - każdy kontroler RODC ma inny zestaw kont użytkowników i komputerów, które może buforować. Przeważnie odpowiada on zespołowi użytkowników pracujących w konkretnym fizycznym miejscu.

Zaletą tego przykładu jest to, że grupa użytkowników będzie mieć możliwość zalogowania w sieci i uwierzytelnienia na kontrolerze RODC w oddziale firmy nawet w przypadku niedostępności sieci WAN. Jednocześnie stopień niebezpieczeństwa ujawnienia haseł jest ograniczony dzięki zmniejszonej liczbie użytkowników, których hasła można buforować.

W tym przykładzie wypełnienie zawartością listy dozwolonych oraz listy odrzuconych wymaga nakładu pracy administracyjnej. Nie ma domyślnej zautomatyzowanej techniki odczytywania kont ze znanej listy podmiotów zabezpieczeń, które uwierzytelniły się wobec danego kontrolera RODC. Nie ma również domyślnej metody umieszczania tych kont na liście dozwolonych. Można użyć polecenia repadmin /prp move, aby przenieść te konta do grupy znajdującej się na liście dozwolonych, lub skorzystać ze skryptów bądź aplikacji, takich jak program ILM, aby zbudować proces.

Chociaż można dodawać konta użytkowników i komputerów bezpośrednio do listy dozwolonych, należy zamiast tego utworzyć dla każdego kontrolera RODC grupę zabezpieczeń, dodać ją do listy dozwolonych, a następnie dodać konta użytkowników i komputerów do tej grupy. Umożliwia to określanie, dla których kont jest dozwolone buforowanie poświadczeń na kontrolerze RODC, przy użyciu standardowych narzędzi do zarządzania grupami, takich jak przystawka Użytkownicy i komputery usługi Active Directory czy programy wiersza polecenia Dsadd i Dsmod.

Polecenie repadmin /prp move wymaga określenia grupy zabezpieczeń. Jeśli określona grupa zabezpieczeń nie istnieje, zostanie utworzona i dodana do listy dozwolonych.

Podobnie jak w przypadku poprzedniego przykładu należy dodać odpowiednie konta komputerów do listy dozwolonych.


Spis treści