Anforderungen für Active Directory-Vertrauensstellungen

Warum und wann dieser Vorgang ausgeführt wird

Ihr Windows-Administrator muss mithilfe des Snap-ins "Active Directory-Domänen und -Vertrauensstellungen" Gesamtstrukturvertrauensstellungen zwischen den Domänen einrichten. Externe Vertrauensstellungen unterstützen die Kerberos-Authentifizierung nicht und können daher nicht verwendet werden. Schlagen Sie in der Microsoft™-Dokumentation nach, wenn Sie weitere Informationen für das Einrichten von Vertrauensstellungen benötigen.

Beachten Sie, dass eine übergeordnete Domäne eine untergeordnete Domäne automatisch als vertrauenswürdig anerkennt, sodass zwischen derartigen Domänen keine Vertrauensstellungen konfiguriert werden müssen. Eine untergeordnete Domäne ist eine Domäne, die in der DNS-Hierarchie eine Ebene unterhalb einer anderen Domäne liegt. Zum Beispiel ist sales.east.renovations.com der Domäne east.renovations.com untergeordnet.

Folgende Arten von Gesamtstrukturvertrauensstellungen werden unterstützt:

• Bidirektionale Windows-Gesamtstrukturvertrauensstellungen. Falls beispielsweise zwischen Gesamtstrukturen A und B eine bidirektionaler Vertrauensstellung besteht, können die Benutzer der Gesamtstrukturen A und B auf die Server in beiden Gesamtstrukturen zugreifen.
• Unidirektionale, eingehende Vertrauensstellung für eine andere Gesamtstruktur. Falls beispielsweise in Gesamtstruktur A eine unidirektionale Vertrauensstellung für Gesamtstruktur B besteht, können die Benutzer der Gesamtstruktur A auf die Server in Gesamtstruktur B zugreifen. Benutzer in Gesamtstruktur B können nicht auf Gesamtstruktur A zugreifen, solange in Gesamtstruktur B nicht ebenfalls eine eingehende Vertrauensstellung für Gesamtstruktur A besteht.
• Unidirektionale ausgehende Vertrauensstellung für eine andere Gesamtstruktur. Falls beispielsweise in Gesamtstruktur A eine ausgehende Vertrauensstellung für Gesamtstruktur B besteht, können die Benutzer der Gesamtstruktur B auf Server in Gesamtstruktur A zugreifen. Benutzer in Gesamtstruktur A können nicht auf Gesamtstruktur B zugreifen, solange in Gesamtstruktur B nicht ebenfalls eine ausgehende Vertrauensstellung für Gesamtstruktur A besteht.
• Transitive Vertrauensstellung. Wenn Benutzer in Gesamtstruktur A aufgrund einer Vertrauensstellung auf Server in Gesamtstruktur B zugreifen können, können auch Benutzer einer der Gesamtstruktur A untergeordneten Domäne auf Server in Gesamtstruktur B zugreifen, falls die Vertrauensstellung zwischen den Gesamtstrukturen A und B als transitive Vertrauensstellung konfiguriert ist.

Prozedur

1. Öffnen Sie das Dienstprogramm "Active Directory-Domänen und -Vertrauensstellungen" im Menü "Verwaltung".

2. Klicken Sie mit der rechten Maustaste auf Ihre Domäne und klicken Sie auf "Eigenschaften".

3. Klicken Sie auf das Register "Vertrauensstellung", um eine Liste der vertrauenswürdigen Domänen anzuzeigen.

Synchronisierung von Computeruhren

Warum und wann dieser Vorgang ausgeführt wird

Serveruhren müssen innerhalb von Domänen und domänenübergreifend so genau wie möglich synchronisiert sein, da Kerberos (der der einmaligen Anmeldung von Windows für Web-Clients zugrunde liegende Sicherheitsmechanismus) empfindlich auf Zeitabweichungen reagiert. Sie sollten Zeitabweichungen, falls möglich, immer beheben. Gegebenenfalls kann der Windows-Administrator folgende Schritte durchführen, um die Toleranz gegenüber Zeitabweichungen zu erhöhen:

Prozedur

1. Starten Sie die Gruppenrichtlinien-Verwaltungskonsole. (Klicken Sie beispielsweise unter Windows Server 2008 auf "Start > Ausführen", geben Sie "gpmc.msc" ein und klicken Sie auf OK.)

2. Suchen Sie in der Konsolenstruktur nach Ihrer Domäne und erweitern Sie die Struktur.

3. Erweitern Sie die Gruppenrichtlinienobjekte.

4. Klicken Sie unterhalb der Gruppenrichtlinienobjekte auf "Standarddomänenrichtlinie" (wird dann angezeigt). Klicken Sie im Register mit den Einstellungen der Standarddomänenrichtlinie auf "Sicherheitseinstellungen" und anschließend auf "Kontorichtlinien/Kerberos-Richtlinie".

5. Doppelklicken Sie auf "Maximale Toleranz für die Synchronisierung des Computertakts", um diese Einstellung zu bearbeiten.

DNS-Anforderungen

Falls jede Domäne über eine eigene Namenshierarchie verfügt (beispielsweise east.renovations.com und west.renovations.com), muss Ihr Netzwerkadministrator Forward- und Reverse-Lookupzonen erstellen, die es Computern ermöglichen, Namen aus anderen Domänen aufzulösen.

Browser-Anforderungen

Browser müssen so konfiguriert werden, dass sie die einmalige Anmeldung von Windows bei jeder Zieldomäne von Active Directory zulassen.

Anforderungen für die Domino-Namenssuche

Jeder Domino-Server muss in der Lage sein, Benutzer, die sich in Active Directory-Domänen befinden, über Kerberos-Namen zu suchen. Sind die Kerberos-Namen von Benutzern in mehreren Domino-Verzeichnissen gespeichert, muss der Domino-Administrator jeden Domino-Server so konfigurieren, dass bei der Suche nach den Benutzernamen in sekundären Domino-Verzeichnissen ein Verzeichniskatalog oder die Verzeichnisverwaltung verwendet wird. Werden die Kerberos-Namen der Benutzer jedoch mithilfe der Verzeichnisverwaltung in Active Directory aufgelöst, kann jeder Domino-Server die Verzeichnisverwaltung verwenden, um in jedem Active Directory nach Namen zu suchen, in dem sich die Benutzernamen befinden.

Konfigurationsempfehlungen für die einmalige Anmeldung

Warum und wann dieser Vorgang ausgeführt wird

Nachdem für einen Benutzer die einmalige Anmeldung (SSO) von Windows eingerichtet wurde, gibt der Domino-Server ein LTPA-Token für den Benutzer zurück. Sie sollten den SSO-Einsatz sorgfältig planen und dabei berücksichtigen, ob Domino-Server dieselbe SSO-Konfiguration verwenden.

Falls Sie beispielsweise die SSO-Konfiguration der Server in der Domäne "east.renovations.com" so einrichten, dass sie dieselben SSO-Schlüssel wie die Server der Domäne "west.renovations.com" verwenden, kann ein East-Server ein LTPA-Token annehmen, dass von einem West-Server erstellt wurde. In diesem Fall könnten die Konfigurationsdokumente eine allgemeine DNS-Domäne verwenden, zum Beispiel "renovations.com".

Setzen Sie jedoch eine allgemeine DNS-Domäne wie "renovations.com" ein, ohne dass die Server der beiden Domänen dieselben SSO-Schlüssel verwenden, ist ein SSO nicht wirksam. Stattdessen sollten Sie Ihre SSO-Domäne auf die Windows-DNS-Domäne zuschneiden, in der sie betrieben wird.

Beispiel: Wirkungslose SSO-Konfiguration

Das folgende Beispiel verdeutlicht, dass die Verwendung einer allgemeinen SSO-Domäne (renovations.com) wirkungslos ist, wenn die Server in west.renovations.com und east.renovations.com nicht dieselben SSO-Schlüssel verwenden.

Prozedur

1. Benutzer authentifizieren sich bei den Servern in east.renovations.com mittels Windows-SSO. Der East-Server erstellt unter Verwendung seines SSO-Schlüssels das LTPA-Token für den Benutzer. Der Browser des Benutzers beschafft sich das LTPA-Token, das für DNS-Domänen in renovations.com verwendet wird.

2. Der Benutzer greift auf einen Server in west.renovations.com zu. Der Browser sendet das LTPA-Token, das für alle Server in renovations.com gilt. Der Server in west.renovations.com verbringt Zeit mit dem Versuch, das Token zu validieren. Dieser Vorgang schlägt fehl, da die West-Server nicht dieselben SSO-Schlüssel wie die East-Server verwenden.

3. Der West-Server kann das vorhandene LTPA-Token nicht validieren und muss daher den Benutzer über Windows-SSO authentifizieren. Der West-Server erstellt unter Verwendung seines SSO-Schlüssels das LTPA-Token für den Benutzer. Der Browser des Benutzers beschafft sich ein neues LTPA-Token, das für DNS-Domänen in renovations.com verwendet wird. Der Browser verfügt jetzt nur über das von dem West-Server erstellte LTPA-Token, das das vorherige ersetzt.

4. Der Benutzer greift auf einen Server in east.renovations.com zu. Der Browser sendet das LTPA-Token, das für alle Server in renovations.com gilt. Der East-Server verbringt Zeit mit dem Versuch, das Token zu validieren. Dieser Vorgang schlägt fehl, da das Token vom West-Server unter Verwendung anderer SSO-Schlüssel erstellt wurde. Der Benutzer muss erneut bei dem East-Server mittels Windows-SSO authentifiziert werden. Wieder überschreibt der East-Server das vorhandene LTPA-Token.

Ergebnisse

Die ständig wiederkehrenden Windows-SSOs, bei denen jedes Mal die LTPA-Token überschrieben werden, sind ausgesprochen ineffizient.

Beispiel: Funktionierende SSO-Konfiguration

Das folgende Beispiel verdeutlicht, dass es wirkungsvoller ist, SSO-Domänen einzusetzen, die auf die Windows-Domäne zugeschnitten sind, falls die Server in west.renovations.com und east.renovations.com nicht dieselben SSO-Schlüssel verwenden.

Prozedur

1. Der Benutzer authentifiziert sich bei einem Server in east.renovations.com und erhält das LTPA-Token für die Verwendung der DNS-Domänen in east.renovations.com.

2. Der Benutzer greift auf einen Server in west.renovations.com zu. Der Browser sendet nicht das für die East-Server bestimmte LTPA-Token.

3. Der West-Server muss den Benutzer über Windows-SSO authentifizieren. Der Benutzer erhält ein zweites LTPA-Token, das für DNS-Domänen in west.renovations.com verwendet wird.

4. Der Benutzer greift auf einen Server in east.renovations.com zu. Der Browser sendet das erste LTPA-Token, das für alle East-Server gilt. Der East-Server verwendet das LTPA-Token, um den Benutzer zu identifizieren.

5. Der Benutzer greift auf einen Server in west.renovations.com zu. Der Browser sendet das zweite LTPA-Token, das für alle West-Server gilt. Der West-Server verwendet das LTPA-Token, um den Benutzer zu identifizieren.

Zugehörige Tasks
Serverübergreifende sitzungsbasierte Authentifizierung (einmalige Anmeldung)
Einmalige Anmeldung von Windows für Web-Clients einrichten

Zugehörige Informationen
Fehlersuche bei der einmaligen Anmeldung von Windows für Web-Clients (SPNEGO)

Feedback zur Hilfe oder Benutzerfreundlichkeit des Produkts?

Hilfe zur Hilfe

Gesamter Inhalt der Hilfe

Feedback zur Hilfe oder Benutzerfreundlichkeit?

Hilfe zur Hilfe