AD Uwierzytelnianie między lasami - brak grup w PAC

Mam konfigurację usługi Active Directory składającą się z 2 lasów:

• 1 las wielodomenowy z 1 domeną główną lasu i 2 bezpośrednimi domenami podrzędnymi
• 1 las jednodomenowy do celów wydawniczych DMZ

Utworzyłem 3 wychodzące zaufanie w domenie DMZ, 1 przechodni zaufanie lasu w domenie głównej lasu i 2 zewnętrzne zaufanie nieprzechodnie (inaczej. Skróty zaufania).

Wszystkie kontrolery domeny we wszystkich czterech domenach to serwery wykazu globalnego.

Próbowałem to sobie wyobrazić poniżej:

Teraz jest problem. Kiedy udzielam dostępu do zasobu w dmzRoot.tldgrupie zabezpieczeń w childAdomenie, działa to dla użytkowników, childAktórzy są członkami grupy zabezpieczeń, ale nie dla użytkowników w childBdomenie, nawet jeśli są członkami grupy zabezpieczeń w childA.

Powiedzmy, że chcę, na przykład, dać lokalnemu administratorowi dostęp do serwera członkowskiego dmzRoot.tld. Dodaję childA.ForestRoot.tld\dmzAdministratorsdo lokalnej wbudowanej grupy Administratorzy na serwerze członkowskim.

childA.ForestRoot.tld\dmzAdministrators ma następujących członków:

• childA \ dmzAdmin
• childB \ superUser

Teraz, jeśli uwierzytelnię się jako childA\dmzAdmin, mogę zalogować się na serwerze członkowskim jako lokalny administrator, a jeśli spojrzę na dane wyjściowe whoami /groups, childA.ForestRoot.tld\dmzAdministratorsgrupa jest wyraźnie wymieniona.

Jeśli childB\superUserjednak uwierzytelnię się , otrzymam komunikat, że konto nie jest autoryzowane do zdalnego logowania. Gdybym sprawdzić whoami /groupsna childB\superUserkoncie The childA.ForestRoot.tld\dmzAdministratorsgrupa nie ma na liście.

Wygląda prawie na to, że childAidentyfikatory SID grupy nigdy nie zostaną uwzględnione w PAC podczas uwierzytelniania childBużytkowników, nawet jeśli wszystkie kontrolery domeny są GC.

Wyłączyłem sprawdzanie poprawności PAC na komputerze w dmzRoot.tld, na którym go testowałem, ale to nie pomogło.

Wszelkie sugestie dotyczące skutecznego rozwiązania tego problemu? Jak podążać śladem uwierzytelnienia, aby ustalić, gdzie się nie udaje?

Okazuje się, że problem powodował zaufanie skrótów.

Gdy uwierzytelnianie AD Kerberos przemieszcza się między domenami, dziedzina docelowa (tj. dmzRoot.tld) Identyfikuje relację zaufania, za pośrednictwem której użytkownicy pochodzący z domeny (np. childA.ForestRoot.tld) Są domeną zaufaną.

Ponieważ zarówno przechodnie zaufanie lasu do, jak ForestRoot.tldi zaufanie zewnętrzne (zaufanie skrótu) do childAtych warunków są zgodne, dziedzina docelowa musi wybrać jedno, a zaufanie skrótu ma pierwszeństwo (ponieważ jest jawne) przed niejawną relacją zaufania w zaufaniu lasu .

Ponieważ kwarantanna filtru SID jest domyślnie włączona dla wychodzących relacji zaufania, tylko identyfikatory SID z zaufanej dziedziny (w tym przypadku childAdomeny) będą honorowane po uwierzytelnieniu, a zagraniczne identyfikatory SID zostaną odfiltrowane.

Podsumowując, istnieją na to dwa rozwiązania:

• Usuń zewnętrzne relacje zaufania i polegaj na zaufaniu lasu. Ponieważ zaufanie lasu jest przechodnie, wszystkie identyfikatory SID z całego lasu pozostaną w twoim tokenie.
• Wyłącz filtr SID Kwarantanna dla wychodzącego zaufania z dmzRoot.tlddomeny

Mam nadzieję, że to miało sens