Udostępnij za pośrednictwem

Jak działają relacje zaufania dla lasów w usłudze Active Directory (wersja zapoznawcza)

  • Artykuł

Usługi Active Directory Domain Services (AD DS) zapewniają bezpieczeństwo w wielu domenach lub lasach poprzez relacje zaufania między domenami i lasami. Przed przeprowadzeniem uwierzytelniania między relacjami zaufania system Windows musi najpierw sprawdzić, czy domena żądana przez użytkownika, komputer lub usługę ma relację zaufania z domeną żądanego konta.

Aby sprawdzić tę relację zaufania, system zabezpieczeń systemu Windows oblicza ścieżkę zaufania między kontrolerem domeny (DC) serwera, który odbiera żądanie i kontroler domeny w domenie żądanego konta.

Mechanizmy kontroli dostępu udostępniane przez usługi AD DS i rozproszony model zabezpieczeń systemu Windows zapewniają środowisko do działania zaufania między domenami i lasami. Aby te relacje zaufania działały prawidłowo, każdy zasób lub komputer musi mieć bezpośrednią ścieżkę zaufania do kontrolera domeny (DC) w domenie, w której jest zlokalizowany.

Usługa Net Logon implementuje ścieżkę zaufania przy użyciu uwierzytelnionego połączenia zdalnego wywołania procedury (RPC) z zaufanym urzędem domeny. Zabezpieczony kanał obejmuje również inne domeny AD DS przez relacje zaufania międzydomenowe. Ten zabezpieczony kanał służy do uzyskiwania i weryfikowania informacji zabezpieczających, w tym identyfikatorów zabezpieczeń (SID) dla użytkowników i grup.

Notatka

Usługi domenowe obsługują wiele kierunków zaufania lasu, w tym wersję testową zaufania dwukierunkowego i zaufania jednokierunkowego, które mogą być przychodzące lub wychodzące.

Aby zapoznać się z omówieniem sposobu stosowania relacji zaufania do usług Domain Services, zobacz pojęcia i funkcje lasu .

Aby rozpocząć korzystanie z relacji zaufania w usługach Domain Services, utworzyć domenę zarządzaną, która używa relacji zaufania lasu.

Przepływy relacji zaufania

Przepływ zabezpieczonej komunikacji przez sieci zaufania określa elastyczność tych sieci. Sposób tworzenia lub konfigurowania zaufania określa, jak daleko komunikacja rozciąga się w obrębie lasów lub między lasami.

Kierunek zaufania określa przepływ komunikacji w ramach zaufania. Relacje zaufania mogą być jednokierunkowe lub dwukierunkowe i mogą być przechodnie lub nie przechodnie.

Na poniższym diagramie przedstawiono, że wszystkie domeny w Drzewie 1 i Drzewie 2 mają domyślnie relacje zaufania przechodniego. W związku z tym użytkownicy w Tree 1 mogą uzyskiwać dostęp do zasobów w domenach w Tree 2 i użytkowników w Tree 2 mogą uzyskiwać dostęp do zasobów w drzewie 1, gdy odpowiednie uprawnienia są przypisane do zasobu.

Diagram relacji zaufania między dwoma lasami domen

Relacje zaufania jednokierunkowe i dwukierunkowe

Relacje zaufania umożliwiają dostęp do zasobów i mogą być jednokierunkowe lub dwukierunkowe.

Jednokierunkowa relacja zaufania to jednokierunkowa ścieżka uwierzytelniania utworzona między dwiema domenami. W jednokierunkowym zaufaniu między domeną A a domeną B użytkownicy w domenie A mogą uzyskiwać dostęp do zasobów w domenie B . Jednak użytkownicy w domenie B nie mogą uzyskiwać dostępu do zasobów w domenie A .

Niektóre zaufania jednokierunkowe mogą być nieprzechodnie lub przechodnie w zależności od typu tworzonego zaufania.

W dwukierunkowej relacji zaufania domena A ufa domenie B, a domena B ufa domenie A. Ta konfiguracja oznacza, że żądania uwierzytelniania mogą być przekazywane między obydwoma domenami w obu kierunkach. Niektóre relacje dwukierunkowe mogą być nieprzechodnie lub przechodnie w zależności od typu tworzonego zaufania.

Wszystkie relacje zaufania domeny w lokalnym lesie AD DS są dwukierunkowymi, przechodnimi relacjami zaufania. Po utworzeniu nowej domeny podrzędnej dwukierunkowa relacja zaufania przechodniego jest tworzona automatycznie między nową domeną podrzędną a domeną nadrzędną.

Przechodnie i nieprzechodnie relacje zaufania

Przechodniość określa, czy relacja zaufania może zostać rozszerzona poza dwiema domenami, z którymi została utworzona.

  • Przechodnie zaufanie może służyć do rozszerzania relacji zaufania z innymi domenami.
  • Relacja zaufania nieskojarzona może służyć do odrzucenia stosunków zaufania z innymi domenami.

Za każdym razem, gdy tworzysz nową domenę w lesie, dwukierunkowa relacja zaufania jest tworzona automatycznie między nową domeną a domeną nadrzędną. Jeśli domeny podrzędne są dodawane do nowej domeny, ścieżka zaufania przepływa w górę przez hierarchię domeny rozszerzającą początkową ścieżkę zaufania utworzoną między nową domeną a domeną nadrzędną. Przechodnie relacje zaufania przepływają w górę przez drzewo domeny podczas jego tworzenia, tworząc przechodnie relacje zaufania między wszystkimi domenami w drzewie domeny.

Żądania uwierzytelniania są zgodne z tymi ścieżkami zaufania, więc konta z dowolnej domeny w lesie mogą być uwierzytelniane przez dowolną inną domenę w lesie. W przypadku jednokrotnego logowania konta z odpowiednimi uprawnieniami mogą uzyskiwać dostęp do zasobów w dowolnej domenie w lesie domenowym.

Fundusze powiernicze leśne

Zaufanie leśne pomaga zarządzać segmentowaną infrastrukturą usług katalogowych AD DS oraz obsługiwać dostęp do zasobów i innych obiektów między lasami. Fundusze powiernicze są przydatne dla dostawców usług, firm przechodzących fuzje lub przejęcia, biznesowych ekstranetów do współpracy oraz firm poszukujących rozwiązania dla autonomii administracyjnej.

Korzystając z zaufania lasów, można połączyć dwa różne lasy, aby utworzyć jednokierunkową lub dwukierunkową transaktywną relację zaufania. Zaufanie leśne umożliwia administratorom połączenie dwóch lasów usług AD DS przy użyciu jednej relacji zaufania w celu zapewnienia bezproblemowego uwierzytelniania i autoryzacji między lasami.

Relację zaufania lasu można utworzyć wyłącznie między domeną główną lasu w jednym lesie a domeną główną lasu w innym lesie. Relacje zaufania lasów mogą być tworzone tylko między dwoma lasami i nie mogą być niejawnie rozszerzane na trzeci las. To zachowanie oznacza, że jeśli relacja zaufania lasu jest tworzona między lasem Lasem 1a lasem 2lasem 2, a innym zaufaniem lasu Forest 2 i Forest 3, Forest 1 nie ma niejawnego zaufania z lasem Forest 3.

Na poniższym diagramie przedstawiono dwie oddzielne relacje zaufania między trzema obszarami usług AD DS w jednej organizacji.

Diagram relacji zaufania lasu w ramach jednej organizacji

Ta przykładowa konfiguracja zapewnia następujący dostęp:

  • Użytkownicy w lesie Forest 2 mogą uzyskiwać dostęp do zasobów w dowolnej domenie w lesie las 1 lub las 3
  • Użytkownicy w Forest 3 mogą uzyskiwać dostęp do zasobów w dowolnej domenie w Forest 2
  • Użytkownicy w lesie Forest 1 mogą uzyskiwać dostęp do zasobów w dowolnej domenie w Forest 2

Ta konfiguracja nie zezwala użytkownikom w Forest 1 na dostęp do zasobów w Forest 3 lub odwrotnie. Aby umożliwić użytkownikom zarówno lasu 1, jak i Las 3 współużytkowania zasobów, należy utworzyć dwukierunkową relację zaufania między dwoma lasami.

Jeśli między dwoma lasami zostanie utworzone jednokierunkowe zaufanie lasu, członkowie zaufanego lasu mogą korzystać z zasobów znajdujących się w lesie zaufania. Zaufanie działa jednak tylko w jednym kierunku.

Na przykład, gdy tworzone jest jednokierunkowe zaufanie lasu między Las 1 (zaufanym lasem) a Lasem 2 (lasem, który obdarza zaufaniem):

  • Członkowie Forest 1 mają dostęp do zasobów znajdujących się w Forest 2.
  • Członkowie Forest 2 nie mogą uzyskiwać dostępu do zasobów znajdujących się w Forest 1 przy użyciu tego samego zaufania.

Ważny

Usługa Microsoft Entra Domain Services obsługuje wielokierunkowe zaufania leśne.

Wymagania dotyczące zaufania Forest

Przed utworzeniem zaufania lasu należy sprawdzić poprawną infrastrukturę systemu nazw domen (DNS). Relacje zaufania leśnego można utworzyć tylko wtedy, gdy jest dostępna jedna z następujących konfiguracji DNS:

  • Jeden bazowy serwer DNS jest bazowym serwerem DNS dla obu przestrzeni nazw DNS lasu — strefa bazowa zawiera delegacje dla każdej przestrzeni nazw DNS, a root-hinty wszystkich serwerów DNS obejmują bazowy serwer DNS.

  • Jeśli nie ma współdzielonego głównego serwera DNS, a główne serwery DNS w każdym lesie przestrzeni nazw DNS używają warunkowych serwerów nazwowych DNS do kierowania zapytań o nazwy w innej przestrzeni nazw, to...

    Ważny

    Każdy las usług Microsoft Entra Domain Services z zaufaniem musi używać tej konfiguracji DNS. Hostowanie przestrzeni nazw DNS innej niż przestrzeń nazw DNS lasu nie jest funkcją usług Microsoft Entra Domain Services. Warunkowe usługi przesyłania dalej to właściwa konfiguracja.

  • Jeśli nie ma współużytkowanego głównego serwera DNS, a główne serwery DNS w każdej przestrzeni nazw DNS używają stref pomocniczych DNS, są one konfigurowane w każdej przestrzeni nazw DNS do kierowania zapytań dotyczących nazw w innej przestrzeni nazw.

Aby utworzyć zaufanie lasu w usługach AD DS, musisz być członkiem grupy Administratorzy domeny (w domenie głównej lasu) lub grupy Administratorzy przedsiębiorstwa w usłudze Active Directory. Każdemu zaufaniu przypisano hasło, które powinni znać administratorzy w obu lasach. Członkowie administratorów przedsiębiorstwa w obu lasach mogą jednocześnie tworzyć relacje zaufania w obu lasach, a w tym scenariuszu hasło kryptograficznie losowe jest generowane automatycznie i zapisywane dla obu lasów.

Zarządzany las domenowy obsługuje do pięciu jednokierunkowych zaufanych relacji lasowych wychodzących do lokalnych lasów. Zaufanie międzylasowe wychodzące dla usług Microsoft Entra Domain Services jest tworzone w centrum administracyjnym Microsoft Entra. Użytkownik z uprawnieniami wymienionymi wcześniej w lokalnej usłudze Active Directory musi skonfigurować zaufanie do nadchodzącego lasu.

Procesy zaufania i interakcje

Wiele transakcji międzydomenowych i międzylasowych zależy od relacji zaufania domeny lub lasu, aby wykonać różne zadania. W tej sekcji opisano procesy i interakcje, które występują w miarę uzyskiwania dostępu do zasobów w relacjach zaufania i oceniania odwołań uwierzytelniania.

Omówienie przetwarzania odwołań uwierzytelniania

Gdy żądanie uwierzytelnienia jest kierowane do domeny, kontroler domeny w tej domenie musi określić, czy istnieje relacja zaufania z domeną, z której pochodzi żądanie. Kierunek zaufania i to, czy relacja zaufania jest przechodnia, czy nieprzechodnia, musi być również określony przed uwierzytelnieniem użytkownika w celu uzyskania dostępu do zasobów w domenie. Proces uwierzytelniania, który występuje między zaufanymi domenami, różni się w zależności od używanego protokołu uwierzytelniania. Protokoły Kerberos V5 i NTLM przetwarzają odnośniki dotyczące uwierzytelniania w domenie inaczej.

Przetwarzanie odwołań protokołu Kerberos V5

Protokół uwierzytelniania Kerberos V5 jest zależny od usługi Net Logon na kontrolerach domeny na potrzeby uwierzytelniania i autoryzacji klienta. Protokół Kerberos łączy się z internetowym centrum dystrybucji kluczy (KDC) i magazynem kont usługi Active Directory w celu uzyskania biletów sesyjnych.

Protokół Kerberos używa również relacji zaufania dla usług przyznawania biletów między obszarami (TGS) i do weryfikowania certyfikatów atrybutów uprawnień (PACs) w zabezpieczonym kanale. Protokół Kerberos wykonuje uwierzytelnianie między domenami tylko z obszarami Kerberos systemów operacyjnych innych niż Windows, takimi jak obszar Kerberos MIT, i nie musi wchodzić w interakcję z usługą Net Logon.

Jeśli klient używa protokołu Kerberos V5 do uwierzytelniania, żąda biletu do serwera w domenie docelowej od kontrolera domeny w domenie jego konta. Centrum dystrybucji kluczy Protokołu Kerberos działa jako zaufany pośrednik między klientem a serwerem i udostępnia klucz sesji, który umożliwia obu podmiotom uwierzytelnianie się nawzajem. Jeśli domena docelowa różni się od bieżącej domeny, KDC stosuje logiczny proces, aby określić, czy żądanie uwierzytelniania może zostać przekazane.

  1. Czy bieżąca domena jest zaufana bezpośrednio przez domenę serwera, którego dotyczy żądanie?

    • Jeśli tak, wyślij klientowi odwołanie do żądanej domeny.
    • Jeśli nie, przejdź do następnego kroku.

  2. Czy relacja zaufania przechodniego istnieje między bieżącą domeną a następną domeną na ścieżce zaufania?

    • Jeśli tak, wyślij klientowi odwołanie do następnej domeny w ścieżce zaufania.
    • Jeśli nie, wyślij klientowi komunikat o odmowie logowania.

Przetwarzanie odwołań NTLM

Protokół uwierzytelniania NTLM jest zależny od usługi Net Logon na kontrolerach domeny na potrzeby uwierzytelniania i autoryzacji klienta. Ten protokół uwierzytelnia klientów, którzy nie korzystają z uwierzytelniania Kerberos. Protokół NTLM używa zaufania do przekazywania żądań uwierzytelniania między domenami.

Jeśli klient używa protokołu NTLM do uwierzytelniania, początkowe żądanie uwierzytelniania przechodzi bezpośrednio z klienta do serwera zasobów w domenie docelowej. Ten serwer tworzy wyzwanie, na które odpowiada klient. Następnie serwer wysyła odpowiedź użytkownika do kontrolera domeny w domenie konta komputera. Ten kontroler domeny sprawdza konto użytkownika względem bazy danych kont zabezpieczeń.

Jeśli konto nie istnieje w bazie danych, kontroler domeny określa, czy przeprowadzić uwierzytelnianie przekazywane, przekazać żądanie lub odmówić żądania przy użyciu następującej logiki:

  1. Czy bieżąca domena ma bezpośrednią relację zaufania z domeną użytkownika?

    • Jeśli tak, kontroler domeny wysyła poświadczenia klienta do kontrolera domeny w domenie użytkownika na potrzeby uwierzytelniania przekazywanego.
    • Jeśli nie, przejdź do następnego kroku.

  2. Czy bieżąca domena ma przechodnią relację zaufania z domeną użytkownika?

    • Jeśli tak, przekaż żądanie uwierzytelniania do następnej domeny w ścieżce zaufania. Ten kontroler domeny powtarza proces, sprawdzając poświadczenia użytkownika względem własnej bazy danych kont zabezpieczeń.
    • Jeśli nie, wyślij klientowi komunikat o odmowie logowania.

Przetwarzanie żądań uwierzytelniania przez zaufania lasów z użyciem protokołu Kerberos

Gdy dwa lasy są połączone zaufaniem leśnym, żądania uwierzytelniania wysyłane przy użyciu protokołów Kerberos V5 lub NTLM mogą być kierowane między lasami, aby zapewnić dostęp do zasobów w obu lasach.

Gdy po raz pierwszy ustanawia się zaufanie między lasami, każdy z lasów gromadzi wszystkie zaufane przestrzenie nazw w lesie partnerskim i przechowuje te informacje w zaufanym obiekcie domeny. Zaufane przestrzenie nazw obejmują nazwy drzew domen, sufiksy głównej nazwy użytkownika (UPN), sufiksy głównej nazwy usługi (SPN) i przestrzenie nazw identyfikatora zabezpieczeń (SID) używane w innym lesie. Obiekty TDO są replikowane do wykazu globalnego.

Notatka

Alternatywne sufiksy nazw UPN dla relacji zaufania nie są obsługiwane. Jeśli domena lokalna używa tego samego sufiksu UPN co Usługi domenowe, do logowania należy użyć sAMAccountName.

Zanim protokoły uwierzytelniania będą mogły podążać za ścieżką zaufania lasu, główna nazwa usługi (SPN) komputera zasobu musi być zamieniona na lokalizację w innym lesie. Nazwa SPN może być jedną z następujących nazw:

  • Nazwa DNS hosta.
  • Nazwa DNS domeny.
  • Nazwa wyróżniająca obiektu punktu połączenia usługi.

Gdy stacja robocza w jednym lesie próbuje uzyskać dostęp do danych na komputerze zasobów w innym lesie, proces uwierzytelniania Kerberos kontaktuje się z kontrolerem domeny o bilet serwisowy do SPN komputera zasobów. Gdy kontroler domeny wysyła zapytanie do wykazu globalnego i określa, że nazwa SPN nie znajduje się w tym samym lesie co kontroler domeny, kontroler domeny wysyła odwołanie do domeny nadrzędnej z powrotem do stacji roboczej. W tym momencie stacja robocza wysyła zapytanie do domeny nadrzędnej dla biletu usługi i kontynuuje działanie łańcucha odwołań do momentu dotarcia do domeny, w której znajduje się zasób.

Poniższy diagram i kroki zawierają szczegółowy opis procesu uwierzytelniania Kerberos używanego podczas próby uzyskania dostępu do zasobów z komputera znajdującego się w innym lesie na komputerach z systemem Windows.

diagram procesu Kerberos na zaufania lasu

  1. użytkownik User1 loguje się do Workstation1 przy użyciu poświadczeń z domeny europe.tailspintoys.com. Następnie użytkownik próbuje uzyskać dostęp do zasobu udostępnionego w FileServer1 znajdującym się w lesie usa.wingtiptoys.com.

  2. Workstation1 kontaktuje się z centrum dystrybucji kluczy Kerberos na kontrolerze jego domeny, ChildDC1, i żąda biletu serwisowego dla FileServer1 SPN.

  3. ChildDC1 nie znajduje SPN w bazie danych domeny i wysyła zapytanie do wykazu globalnego, aby sprawdzić, czy w lesie tailspintoys.com znajdują się jakiekolwiek domeny zawierające ten SPN. Ponieważ wykaz globalny jest ograniczony do własnego lasu, nie można odnaleźć nazwy głównej usługi (SPN).

    Następnie katalog globalny przeszukuje swoją bazę danych pod kątem wszelkich powiązań zaufania leśnego ustanowionych z jego lasem. Jeśli zostanie znaleziona, porównuje sufiksy nazw wymienione w obiekcie zaufanej domeny zaufania lasu (TDO) do sufiksu docelowej nazwy SPN w celu znalezienia dopasowania. Po znalezieniu dopasowania wykaz globalny udostępnia wskazówkę routingu z powrotem do ChildDC1.

    Wskazówki dotyczące routingu ułatwiają kierowanie żądań uwierzytelniania do lasu docelowego. Wskazówki są używane tylko wtedy, gdy wszystkie tradycyjne kanały uwierzytelniania, takie jak lokalny kontroler domeny, a następnie wykaz globalny, nie mogą zlokalizować nazwy SPN.

  4. ChildDC1 wysyła przekierowanie do domeny macierzystej do Workstation1.

  5. Workstation1 kontaktuje się z kontrolerem domeny w ForestRootDC1 (jej domenie nadrzędnej) w celu uzyskania odwołania do kontrolera domeny (ForestRootDC2) w domenie głównej lasu wingtiptoys.com.

  6. Workstation1 kontaktuje się z ForestRootDC2 w lesie wingtiptoys.com o bilet serwisowy do żądanej usługi.

  7. ForestRootDC2 kontaktuje się z wykazem globalnym, aby znaleźć nazwę SPN, a wykaz globalny znajduje dopasowanie nazwy SPN i wysyła go z powrotem do ForestRootDC2.

  8. ForestRootDC2 następnie wysyła odwołanie do usa.wingtiptoys.com z powrotem do Workstation1.

  9. Workstation1 kontaktuje się z KDC na ChildDC2 i negocjuje bilet dla User1, aby uzyskać dostęp do FileServer1.

  10. Gdy Workstation1 ma zgłoszenie serwisowe, wysyła je do FileServer1, który odczytuje dane uwierzytelniające użytkownika User1i odpowiednio tworzy token dostępu.

Zaufany obiekt domeny

Zaufany obiekt domeny (TDO) przechowywany w kontenerze System w ramach swojej domeny reprezentuje każdą domenę lub relację zaufania lasu w organizacji.

Zawartość TDO

Informacje zawarte w obiekcie TDO różnią się w zależności od tego, czy TDO zostało utworzone przez zaufanie domenowe, czy przez zaufanie leśne.

Po utworzeniu zaufania domeny atrybuty, takie jak nazwa domeny DNS, identyfikator SID domeny, typ zaufania, przechodniość zaufania i nazwa wzajemnie zaufanej domeny są reprezentowane w TDO. Obiekty TDO zaufania lasu przechowują dodatkowe atrybuty, aby zidentyfikować wszystkie zaufane przestrzenie nazw w lesie partnera. Te atrybuty obejmują nazwy drzew domen, sufiksy głównej nazwy użytkownika (UPN), sufiksy głównej nazwy usługi (SPN) i przestrzenie nazw identyfikatora zabezpieczeń (SID).

Ponieważ relacje zaufania są przechowywane w usłudze Active Directory jako obiekty TDO, wszystkie domeny w lesie znają relacje zaufania obowiązujące w całym lesie. Podobnie, gdy co najmniej dwa lasy są połączone za pośrednictwem zaufania między lasami, domeny główne w lasach są świadome relacji zaufania, które istnieją we wszystkich domenach w zaufanych lasach.

Zmiany hasła TDO

Obie domeny w relacji zaufania dzielą się hasłem, które jest przechowywane w obiekcie TDO w usłudze Active Directory. W ramach procesu konserwacji konta co 30 dni zaufany kontroler domeny zmienia hasło przechowywane w TDO. Ponieważ wszystkie dwukierunkowe relacje zaufania to w rzeczywistości dwie relacje zaufania jednokierunkowe idące w przeciwnych kierunkach, proces ten zachodzi dwukrotnie w przypadku relacji zaufania dwukierunkowych.

Zaufanie ma stronę ufającą i stronę obdarzoną zaufaniem. Po stronie zaufanej każdy zapisywalny kontroler domeny może służyć do tego procesu. Po stronie zaufanej, emulator kontrolera PDC wykonuje zmianę hasła.

Aby zmienić hasło, kontrolery domeny zakończą następujący proces:

  1. Emulator podstawowego kontrolera domeny (PDC) w domenie zaufania tworzy nowe hasło. Kontroler domeny w zaufanej domenie nigdy nie inicjuje zmiany hasła. Zawsze jest inicjowane przez zaufany emulator kontrolera domeny PDC.

  2. Emulator kontrolera PDC w domenie zaufania ustawia pole OldPassword obiektu TDO na bieżące pole NewPassword.

  3. Emulator kontrolera PDC w domenie zaufania ustawia pole NewPassword obiektu TDO na nowe hasło. Przechowywanie kopii poprzedniego hasła umożliwia przywrócenie starego hasła, jeśli kontroler domeny w zaufanej domenie nie otrzyma zmiany lub jeśli zmiana nie zostanie zreplikowana przed wysłaniem żądania używającego nowego hasła zaufania.

  4. Emulator kontrolera PDC w domenie zaufania wykonuje zdalne wywołanie kontrolera domeny w zaufanej domenie z prośbą o ustawienie hasła na koncie zaufania na nowe hasło.

  5. Kontroler domeny w zaufanej domenie zmienia hasło zaufania na nowe hasło.

  6. W każdej ze stron zaufania, aktualizacje są replikowane na inne kontrolery w tej samej domenie. W domenie zaufania zmiana wyzwala pilną replikację zaufanego obiektu domeny.

Hasło jest teraz zmieniane na obu kontrolerach domeny. Replikacja normalna dystrybuuje obiekty TDO do innych kontrolerów domeny w domenie. Jednak kontroler domeny w domenie zaufanej może zmienić hasło bez pomyślnego zaktualizowania kontrolera domeny w zaufanej domenie. Ten scenariusz może wystąpić, ponieważ nie udało się ustanowić zabezpieczonego kanału, który jest wymagany do przetworzenia zmiany hasła. Istnieje również możliwość, że kontroler domeny w zaufanej domenie może być niedostępny w pewnym momencie procesu i może nie otrzymać zaktualizowanego hasła.

Aby poradzić sobie z sytuacjami, w których zmiana hasła nie została pomyślnie przekazana, kontroler domeny w domenie zaufanej nigdy nie zmienia nowego hasła, chyba że pomyślnie uwierzytelni się (ustawi zabezpieczony kanał) przy użyciu nowego hasła. Z tego powodu zarówno stare, jak i nowe hasła są przechowywane w obiekcie TDO zaufanej domeny.

Zmiana hasła nie zostanie sfinalizowana do momentu pomyślnego uwierzytelnienia przy użyciu hasła. Stare, przechowywane hasło można używać za pośrednictwem zabezpieczonego kanału, dopóki kontroler domeny w zaufanej domenie nie otrzyma nowego hasła, co umożliwi nieprzerwaną usługę.

Jeśli uwierzytelnianie przy użyciu nowego hasła nie powiedzie się, ponieważ hasło jest nieprawidłowe, zaufany kontroler domeny próbuje uwierzytelnić się przy użyciu starego hasła. Jeśli pomyślnie uwierzytelnia się przy użyciu starego hasła, proces zmiany hasła zostanie wznowiony w ciągu 15 minut.

Aktualizacje haseł zaufania muszą być replikowane do kontrolerów domeny obu stron zaufania w ciągu 30 dni. Jeśli hasło zaufania zostanie zmienione po 30 dniach, a kontroler domeny posiada jedynie hasło N-2, nie może skorzystać z zaufania po stronie ufającej i nie może utworzyć bezpiecznego kanału po stronie zaufanej.

Porty sieciowe używane przez relacje zaufania

Ponieważ relacje zaufania muszą być wdrażane w różnych granicach sieci, mogą one obejmować co najmniej jedną zaporę. W takim przypadku można tunelować ruch zaufania przez zaporę lub otwierać określone porty w zaporze, aby zezwolić na przekazywanie ruchu.

Ważny

Usługi Active Directory Domain Services nie obsługują ograniczania ruchu RPC usługi Active Directory do określonych portów.

Przeczytaj sekcję Windows Server 2008 i nowsze wersje artykułu pomocy technicznej firmy Microsoft Jak skonfigurować zaporę dla domen i zaufania w usłudze Active Directory, aby dowiedzieć się o portach wymaganych do zaufania lasu.

Obsługa usług i narzędzi

Aby obsługiwać relacje zaufania i uwierzytelnianie, używane są niektóre dodatkowe funkcje i narzędzia do zarządzania.

Logowanie netto

Usługa Net Logon utrzymuje zabezpieczony kanał komunikacyjny z komputera z systemem operacyjnym Windows do kontrolera domeny. Jest on również używany w następujących procesach związanych z zaufaniem:

  • Konfiguracja zaufania i zarządzanie — Net Logon pomaga zachować hasła zaufania, zbiera informacje o zaufaniu i weryfikuje je poprzez interakcję z procesem LSA i obiektem TDO.

    W przypadku lasów zaufania, informacje o zaufaniu obejmują rekord Informacji o Zaufaniu Lasu (FTInfo), który zawiera zestaw przestrzeni nazw, którymi zarządza zaufany las, z adnotacją wskazującą, czy każde z roszczeń jest uznawane za zaufane przez las udzielający zaufania.

  • Uwierzytelnianie — dostarcza poświadczenia użytkownika za pośrednictwem zabezpieczonego kanału do kontrolera domeny i zwraca identyfikatory SID domeny i prawa użytkownika dla użytkownika.

  • Lokalizacja kontrolera domeny — ułatwia znajdowanie lub lokalizowanie kontrolerów domeny w domenie lub w różnych domenach.

  • Weryfikacja z przekazywaniem — poświadczenia użytkowników z innych domen są przetwarzane przez Net Logon. Gdy domena ufająca musi zweryfikować tożsamość użytkownika, przekazuje poświadczenia użytkownika za pośrednictwem usługi Net Logon do domeny zaufanej w celu weryfikacji.

  • Weryfikacja certyfikatu atrybutu uprawnień (PAC) — gdy serwer używający protokołu Kerberos do uwierzytelniania musi zweryfikować certyfikat PAC w bilecie usługi, wysyła certyfikat PAC przez bezpieczny kanał do kontrolera domeny w celu weryfikacji.

Urząd zabezpieczeń lokalnych

Urząd zabezpieczeń lokalnych (LSA) to podsystem chroniony, który przechowuje informacje o wszystkich aspektach zabezpieczeń lokalnych w systemie. Nazywane zbiorczo lokalnymi politykami zabezpieczeń, LSA udostępnia różne usługi tłumaczenia między nazwami a identyfikatorami.

Podsystem zabezpieczeń LSA zapewnia usługi zarówno w trybie jądra, jak i w trybie użytkownika na potrzeby weryfikowania dostępu do obiektów, sprawdzania uprawnień użytkownika i generowania komunikatów inspekcji. LSA jest odpowiedzialny za sprawdzenie ważności wszystkich biletów sesyjnych przedstawianych przez usługi w zaufanych lub niezaufanych domenach.

Narzędzia do zarządzania

Administratorzy mogą używać domen i zaufania usługi Active Directory, Netdom i Nltest uwidaczniać, tworzyć, usuwać lub modyfikować relacje zaufania.

  • Domeny i zaufania usługi Active Directory to konsola zarządzania firmy Microsoft (MMC), która służy do administrowania zaufaniami domen, poziomami funkcjonalności domen i lasów oraz sufiksami nazwy głównej użytkownika.
  • Narzędzia Netdom i Nltest mogą służyć do znajdowania, wyświetlania, tworzenia zaufania i zarządzania nimi. Te narzędzia komunikują się bezpośrednio z urzędem LSA na kontrolerze domeny.

Następne kroki

Aby rozpocząć tworzenie zarządzanej domeny z zaufaniem lasu, zobacz Tworzenie i konfigurowanie domeny zarządzanej za pomocą usług Domain Services. Następnie można Utworzyć relację zaufania lasu wychodzącego z domeną lokalną.