Jak działają relacje zaufania dla lasów w usłudze Active Directory
domena usługi Active Directory Services (AD DS) zapewnia zabezpieczenia w wielu domenach lub lasach za pośrednictwem relacji zaufania domeny i lasu. 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 model zabezpieczeń rozproszonych systemu Windows zapewniają środowisko do działania relacji zaufania domeny i lasu. 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 w domenie, w której się znajduje.
Ścieżka zaufania jest implementowana przez usługę Net Logon przy użyciu uwierzytelnionego połączenia zdalnego wywołania procedury (RPC) z zaufanym urzędem domeny. Zabezpieczony kanał obejmuje również inne domeny usług AD DS za pośrednictwem relacji zaufania międzydomenowych. 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.
Uwaga
Usługi Domain Services obsługują wiele wskazówek zaufania lasu, w tym dwukierunkowe relacje zaufania i relacje zaufania jednokierunkowe, 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, utwórz domenę zarządzaną korzystającą z relacji zaufania lasu.
Przepływy relacji zaufania
Przepływ zabezpieczonej komunikacji za pośrednictwem relacji zaufania określa elastyczność zaufania. Sposób tworzenia lub konfigurowania zaufania określa, jak daleko komunikacja rozciąga się w obrębie lasów lub między lasami.
Przepływ komunikacji z relacjami zaufania jest określany przez kierunek zaufania. Relacje zaufania mogą być jednokierunkowe lub dwukierunkowe i mogą być przechodnie lub nie przechodnie.
Na poniższym diagramie pokazano, że wszystkie domeny w drzewie 1 i drzewie 2 domyślnie mają relacje zaufania przechodniego. W związku z tym użytkownicy w drzewie 1 mogą uzyskiwać dostęp do zasobów w domenach w drzewie 2, a użytkownicy w drzewie 2 mogą uzyskiwać dostęp do zasobów w drzewie 1, gdy odpowiednie uprawnienia zostaną przypisane do zasobu.
Relacje zaufania jednokierunkowe i dwukierunkowe
Relacje zaufania umożliwiają dostęp do zasobów może być jednokierunkowy lub dwukierunkowy.
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ą uzyskać dostępu do zasobów w domenie A.
Niektóre relacje zaufania jednokierunkowego mogą być przechodnie lub przechodnie w zależności od typu tworzonego zaufania.
W dwukierunkowym zaufaniu domena A ufa domenie B i domenie B ufa domenie A. Ta konfiguracja oznacza, że żądania uwierzytelniania mogą być przekazywane między dwiema domenami w obu kierunkach. Niektóre relacje dwukierunkowe mogą nie być przechodnie lub przechodnie w zależności od typu tworzonego zaufania.
Wszystkie relacje zaufania domeny w lokalnym lesie usług AD DS są dwukierunkowymi relacjami zaufania przechodnimi. 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 nieumiejętne 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 nieumiejętnego może służyć do odmowy relacji 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 procesu logowania jednokrotnego konta z odpowiednimi uprawnieniami mogą uzyskiwać dostęp do zasobów w dowolnej domenie w lesie.
Relacje zaufania lasów
Relacje zaufania lasu pomagają zarządzać segmentowaną infrastrukturą usług AD DS i obsługiwać dostęp do zasobów i innych obiektów w wielu lasach. Zaufanie lasu jest przydatne dla dostawców usług, firm przechodzących fuzje lub przejęcia, współpracy ekstranetów biznesowych i firm poszukujących rozwiązania dla autonomii administracyjnej.
Korzystając z relacji zaufania lasu, można połączyć dwa różne lasy, aby utworzyć jednokierunkową lub dwukierunkową relację zaufania. Zaufanie lasu umożliwia administratorom łączenie dwóch lasów usług AD DS z jedną relacją zaufania w celu zapewnienia bezproblemowego uwierzytelniania i autoryzacji w lasach.
Relację zaufania lasu można utworzyć tylko między domeną główną lasu w jednym lesie a domeną główną lasu w innym lesie. Relacje zaufania lasu można tworzyć tylko między dwoma lasami i nie można niejawnie rozszerzyć do trzeciego lasu. To zachowanie oznacza, że jeśli relacja zaufania lasu zostanie utworzona między lasem 1 i lasem 2, a między lasem 2 a lasem 3 zostanie utworzone inne zaufanie, las Forest 1 nie ma niejawnego zaufania z lasem Forest 3.
Na poniższym diagramie przedstawiono dwie oddzielne relacje zaufania lasu między trzema lasami usług AD DS w jednej organizacji.
Ta przykładowa konfiguracja zapewnia następujący dostęp:
- Użytkownicy lasu 2 mogą uzyskiwać dostęp do zasobów w dowolnej domenie w lesie Forest 1 lub Forest 3
- Użytkownicy lasu 3 mogą uzyskiwać dostęp do zasobów w dowolnej domenie w lesie Forest 2
- Użytkownicy lasu 1 mogą uzyskiwać dostęp do zasobów w dowolnej domenie w lesie Forest 2
Ta konfiguracja nie zezwala użytkownikom w lesie Forest 1 na dostęp do zasobów w lesie Forest 3 lub odwrotnie. Aby umożliwić użytkownikom zarówno lasu 1 , jak i lasu 3 współużytkowanie zasobów, należy utworzyć dwukierunkowe zaufanie przechodnie 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 po jednokierunkowym utworzeniu relacji zaufania lasu między lasem 1 (zaufanym lasem) i lasem 2 (lasem zaufania):
- Członkowie lasu Forest 1 mogą uzyskiwać dostęp do zasobów znajdujących się w lesie Forest 2.
- Członkowie lasu 2 nie mogą uzyskać dostępu do zasobów znajdujących się w lesie Forest 1 przy użyciu tego samego zaufania.
Ważne
Usługa Microsoft Entra Domain Services obsługuje wiele wskazówek dotyczących zaufania lasu.
Wymagania dotyczące zaufania lasu
Przed utworzeniem zaufania lasu należy sprawdzić poprawną infrastrukturę systemu nazw domen (DNS). Relacje zaufania lasu można utworzyć tylko wtedy, gdy jest dostępna jedna z następujących konfiguracji DNS:
Jeden główny serwer DNS jest głównym serwerem DNS dla obu przestrzeni nazw DNS lasu — strefa główna zawiera delegowania dla każdej przestrzeni nazw DNS i wskazówek głównych wszystkich serwerów DNS obejmują główny serwer DNS.
Jeśli nie ma współużytkowanego głównego serwera DNS i głównych serwerów DNS w każdym lesie przestrzeni nazw DNS użyj warunkowych usług przesyłania dalej DNS dla każdej przestrzeni nazw DNS do kierowania zapytań dotyczących nazw w innego przestrzeni nazw.
Ważne
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żdym lesie przestrzeni nazw DNS są używane strefy pomocnicze DNS są konfigurowane w każdej przestrzeni nazw DNS do kierowania zapytań dotyczących nazw w innego przestrzeni nazw.
Aby utworzyć zaufanie lasu w usługach AD DS, musisz być członkiem grupy Administracja domen (w domenie głównej lasu) lub grupy Administracja przedsiębiorstwa w usłudze Active Directory. Każde zaufanie ma przypisane hasło, które muszą wiedzieć administratorzy w obu lasach. Członkowie Administracja przedsiębiorstwa w obu lasach mogą jednocześnie tworzyć relacje zaufania w obu lasach, a w tym scenariuszu hasło, które jest kryptograficznie losowe, jest generowane automatycznie i zapisywane dla obu lasów.
Las domeny zarządzanej obsługuje do pięciu jednokierunkowych relacji zaufania lasu wychodzącego do lasów lokalnych. Zaufanie lasu wychodzącego dla usług Microsoft Entra Domain Services jest tworzone w centrum administracyjnym firmy Microsoft Entra. Relacja zaufania lasu przychodzącego musi być skonfigurowana przez użytkownika z uprawnieniami zanotowanymi wcześniej w lokalna usługa Active Directory.
Procesy zaufania i interakcje
Wiele transakcji międzydomenowych i między lasami zależy od relacji zaufania domeny lub lasu w celu wykonania różnych zadań. 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 nieprzejeżdżająca, musi być również określona przed uwierzytelnienie 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ą odwołania do 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 centrum dystrybucji kluczy online (KDC) i magazynem kont usługi Active Directory dla biletów sesji.
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 obszarami tylko w przypadku obszaru operacyjnego kerberos innych niż Windows, takich jak obszar PROTOKOŁU KERberos MIT i nie musi wchodzić w interakcje z usługą Net Logon.
Jeśli klient używa protokołu Kerberos V5 do uwierzytelniania, żąda biletu do serwera w domenie docelowej z kontrolera domeny w domenie 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, centrum dystrybucji kluczy jest zgodne z procesem logicznym w celu określenia, czy można odwoływać się do żądania uwierzytelniania:
Czy bieżąca domena jest zaufana bezpośrednio przez domenę żądanego serwera?
- Jeśli tak, wyślij klientowi odwołanie do żądanej domeny.
- Jeśli nie, przejdź do następnego kroku.
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 relacji 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:
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.
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 za pośrednictwem zaufania lasu opartego na protokole Kerberos
Gdy dwa lasy są połączone relacją zaufania lasu, żądania uwierzytelniania wysyłane przy użyciu protokołów Kerberos V5 lub NTLM mogą być kierowane między lasami w celu zapewnienia dostępu do zasobów w obu lasach.
Po pierwszym ustanowieniu zaufania lasu każdy las zbiera wszystkie zaufane przestrzenie nazw w lesie partnerskim i przechowuje 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.
Uwaga
Alternatywne sufiksy nazw UPN dla relacji zaufania nie są obsługiwane. Jeśli domena lokalna używa tego samego sufiksu nazwy UPN co usługi Domain Services, logowanie musi używać nazwy sAMAccountName.
Aby protokoły uwierzytelniania mogły podążać za ścieżką zaufania lasu, główna nazwa usługi (SPN) komputera zasobu musi być rozpoznawana jako lokalizacja 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 dla biletu usługi do nazwy 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.
Użytkownik User1 loguje się do stacji roboczej1 przy użyciu poświadczeń z domeny europe.tailspintoys.com. Następnie użytkownik próbuje uzyskać dostęp do udostępnionego zasobu na serwerze FileServer1 znajdującym się w lesie usa.wingtiptoys.com .
Stacja robocza1 kontaktuje się z centrum dystrybucji kluczy Kerberos na kontrolerze domeny w swojej domenie, ChildDC1 i żąda biletu usługi dla nazwy SPN FileServer1 .
ChildDC1 nie znajduje nazwy SPN w bazie danych domeny i wysyła zapytanie do wykazu globalnego, aby sprawdzić, czy jakiekolwiek domeny w lesie tailspintoys.com zawierają tę nazwę SPN. Ponieważ wykaz globalny jest ograniczony do własnego lasu, nie można odnaleźć nazwy SPN.
Następnie wykaz globalny sprawdza swoją bazę danych pod kątem wszelkich relacji zaufania lasu, które są ustanawiane 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.
ChildDC1 wysyła odwołanie do domeny nadrzędnej z powrotem do stacji roboczej1.
Stacja robocza1 kontaktuje się z kontrolerem domeny w ForestRootDC1 (jego domena nadrzędna) dla odwołania do kontrolera domeny (ForestRootDC2) w domenie głównej lasu wingtiptoys.com .
Stacja robocza1 kontaktuje się z lasem ForestRootDC2 w lesie wingtiptoys.com dla biletu usługi do żądanej usługi.
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.
Następnie ForestRootDC2 wysyła odwołanie do usa.wingtiptoys.com z powrotem do stacji roboczej1.
Stacja robocza1 kontaktuje się z centrum dystrybucji kluczy w usłudze ChildDC2 i negocjuje bilet dla użytkownika User1 w celu uzyskania dostępu do serwera FileServer1.
Gdy stacja robocza1 ma bilet usługi, wysyła bilet usługi do serwera FileServer1, który odczytuje poświadczenia zabezpieczeń użytkownika User1 i tworzy odpowiednio token dostępu.
Zaufany obiekt domeny
Każda domena lub zaufanie lasu w organizacji jest reprezentowane przez zaufany obiekt domeny (TDO) przechowywany w kontenerze systemowym w swojej domenie.
Zawartość TDO
Informacje zawarte w obiekcie TDO różnią się w zależności od tego, czy element TDO został utworzony przez zaufanie domeny, czy przez zaufanie lasu.
Po utworzeniu zaufania domeny atrybuty, takie jak nazwa domeny DNS, identyfikator SID domeny, typ zaufania, przechodniość zaufania i nazwa domeny wzajemnej są reprezentowane w TDO. Obiekty TDO zaufania lasu przechowują dodatkowe atrybuty, aby zidentyfikować wszystkie zaufane przestrzenie nazw z lasu 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 TDOS, wszystkie domeny w lesie mają wiedzę na temat relacji zaufania, które są przechowywane w całym lesie. Podobnie, gdy co najmniej dwa lasy są połączone za pośrednictwem relacji zaufania lasu, domeny główne lasu w każdym lesie mają wiedzę na temat relacji zaufania, które znajdują się we wszystkich domenach w zaufanych lasach.
Zmiany hasła TDO
Obie domeny w relacji zaufania współużytkuje hasło, 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 są rzeczywiście dwoma relacjami zaufania jednokierunkowymi, odbywa się dwukrotnie w przypadku relacji zaufania dwukierunkowych.
Zaufanie ma zaufanie i zaufaną stronę. Po stronie zaufanej każdy zapisywalny kontroler domeny może służyć do tego procesu. Po stronie zaufania emulator kontrolera PDC wykonuje zmianę hasła.
Aby zmienić hasło, kontrolery domeny zakończą następujący proces:
Emulator podstawowego kontrolera domeny (PDC) w domenie zaufania tworzy nowe hasło. Kontroler domeny w zaufanej domenie nigdy nie inicjuje zmiany hasła. Jest on zawsze inicjowany przez zaufany emulator kontrolera PDC domeny.
Emulator kontrolera PDC w domenie zaufania ustawia pole OldPassword obiektu TDO na bieżące pole NewPassword .
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.
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.
Kontroler domeny w zaufanej domenie zmienia hasło zaufania na nowe hasło.
Po każdej stronie zaufania aktualizacje są replikowane do innych kontrolerów domeny w 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 można 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 zaufania nigdy nie zmienia nowego hasła, chyba że pomyślnie uwierzytelniony (skonfiguruj zabezpieczony kanał) przy użyciu nowego hasła. Dlatego zarówno stare, jak i nowe hasła są przechowywane w obiekcie TDO domeny zaufania.
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 upływie 30 dni, a kontroler domeny ma tylko hasło N-2, nie może użyć zaufania po stronie zaufania i nie może utworzyć bezpiecznego kanału po zaufanej stronie.
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żne
domena usługi Active Directory Services nie obsługuje ograniczania ruchu RPC usługi Active Directory do określonych portów.
Przeczytaj sekcję systemu Windows Server 2008 i nowszych wersji artykułu pomoc techniczna firmy Microsoft How to configure a firewall for Active Directory domains and trusts (Jak skonfigurować zaporę dla domen i relacji zaufania usługi Active Directory), aby dowiedzieć się więcej 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.
Netlogon
Usługa Net Logon utrzymuje zabezpieczony kanał z komputera z systemem Windows do kontrolera domeny. Jest on również używany w następujących procesach związanych z zaufaniem:
Konfiguracja zaufania i zarządzanie — logowanie net pomaga zachować hasła zaufania, zbiera informacje o zaufaniu i weryfikuje relacje zaufania przez interakcję z procesem LSA i TDO.
W przypadku relacji zaufania lasu informacje o zaufaniu zawierają rekord Informacji o zaufaniu lasu (FTInfo), który zawiera zestaw przestrzeni nazw, którymi zarządza zaufany las, z adnotacjami z polem wskazującym, czy każde oświadczenie jest zaufane przez las 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 w innych domenach są przetwarzane przez logowanie netto. Jeśli domena zaufania musi zweryfikować tożsamość użytkownika, przekazuje poświadczenia użytkownika za pośrednictwem logowania net do zaufanej domeny 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 zasadami zabezpieczeń LSA udostępnia różne usługi tłumaczenia nazw i identyfikatorów.
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 sesji prezentowanych przez usługi w zaufanych lub niezaufanych domenach.
Narzędzia do zarządzania
Administracja istratorzy mogą używać domena usługi Active Directory i zaufania, Netdom i Nltest do uwidaczniać, tworzyć, usuwać lub modyfikować relacje zaufania.
- domena usługi Active Directory s and Trusts to microsoft Management Console (MMC), która służy do administrowania relacjami zaufania domeny, poziomami funkcjonalności domeny i lasu oraz sufiksami głównej nazwy użytkownika.
- Narzędzia wiersza polecenia 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 domeny zarządzanej z zaufaniem lasu, zobacz Tworzenie i konfigurowanie domeny zarządzanej usług Domain Services. Następnie można utworzyć relację zaufania lasu wychodzącego z domeną lokalną.