AD Gesamtstrukturübergreifende Authentifizierung - Gruppen fehlen im PAC

Ich habe ein Active Directory-Setup, das aus 2 Gesamtstrukturen besteht:

• 1 Gesamtstruktur mit mehreren Domänen mit 1 Gesamtstruktur-Stammdomäne und 2 direkten untergeordneten Domänen
• 1 Single-Domain-Gesamtstruktur für DMZ-Veröffentlichungszwecke

Ich habe 3 ausgehende Vertrauensstellungen in der DMZ-Domäne erstellt, 1 transitive Gesamtstrukturvertrauensstellung für die Gesamtstrukturstammdomäne und 2 externe nicht transitive Vertrauensstellungen (auch bekannt als Shortcut-Vertrauensstellungen).

Alle Domänencontroller in allen vier Domänen sind globale Katalogserver.

Ich habe versucht, es unten zu visualisieren:

Hier ist das Problem. Wenn ich dmzRoot.tldeiner Sicherheitsgruppe in der childADomäne Zugriff auf eine Ressource erteile, funktioniert dies für Benutzer childA, die Mitglied der Sicherheitsgruppe sind, jedoch nicht für Benutzer in der childBDomäne, obwohl sie Mitglieder der Sicherheitsgruppe in sind childA.

Angenommen, ich möchte dem lokalen Administrator beispielsweise Zugriff auf einen Mitgliedsserver gewähren dmzRoot.tld. Ich füge childA.ForestRoot.tld\dmzAdministratorsder lokalen integrierten Administratorgruppe auf dem Mitgliedsserver hinzu.

childA.ForestRoot.tld\dmzAdministrators hat folgende Mitglieder:

• childA \ dmzAdmin
• childB \ superUser

Wenn ich childA\dmzAdminmich jetzt als authentifiziere , kann ich mich als lokaler Administrator beim Mitgliedsserver anmelden. Wenn ich mir die Ausgabe von anschaue whoami /groups, wird die childA.ForestRoot.tld\dmzAdministratorsGruppe klar aufgelistet.

Wenn ich mich childB\superUserjedoch als authentifiziere , erhalte ich die Meldung, dass das Konto nicht für die Remote-Anmeldung autorisiert ist. Wenn ich whoami /groupsnach dem childB\superUserKonto suche, wird die childA.ForestRoot.tld\dmzAdministratorsGruppe NICHT aufgelistet.

Es scheint fast so, als würden die childAGruppen-SIDs bei der Authentifizierung von childBBenutzern niemals in das PAC aufgenommen , obwohl alle DCs GCs sind.

Ich habe die PAC-Validierung auf dem Computer in dmzRoot.tld deaktiviert, auf dem ich sie getestet habe, aber dies hat nicht geholfen.

Irgendwelche Vorschläge, wie ich dies effektiv beheben kann? Wie verfolge ich die Spur der Authentifizierung, um festzustellen, wo sie fehlschlägt?

Es stellt sich heraus, dass die Shortcut-Vertrauensstellungen das Problem verursacht haben.

Wenn die AD Kerberos-Authentifizierung domänenübergreifend ausgeführt wird, dmzRoot.tldidentifiziert der Zielbereich (dh ) eine Vertrauensstellung, über die der Benutzerbereich (z. B. childA.ForestRoot.tld) eine vertrauenswürdige Domäne ist.

Da sowohl die transitive Gesamtstrukturvertrauensstellung gegenüber ForestRoot.tldals auch die externe Vertrauensstellung (Verknüpfungsvertrauensstellung) gegenüber childAdieser Bedingung übereinstimmen, muss der Zielbereich eine auswählen, und die Verknüpfungsvertrauensstellung hat Vorrang (weil sie explizit ist) vor der impliziten Vertrauensstellung in der Gesamtstrukturvertrauensstellung .

Da die Quarantäne für SID-Filter standardmäßig für ausgehende Vertrauensstellungen aktiviert ist, childAwerden bei der Authentifizierung nur SIDs aus dem vertrauenswürdigen Bereich (in diesem Fall die Domäne) berücksichtigt und fremde SIDs herausgefiltert.

Zusammenfassend gibt es zwei Lösungen dafür:

• Entfernen Sie die externen Vertrauensstellungen und verlassen Sie sich auf die Gesamtstrukturvertrauensstellung. Da die Gesamtstrukturvertrauensstellung transitiv ist, verbleiben alle SIDs aus der gesamten Gesamtstruktur in Ihrem Token.
• Deaktivieren Sie die SID-Filter-Quarantäne für die ausgehende Vertrauensstellung aus der dmzRoot.tldDomäne

Hoffe das machte Sinn