Verwenden von DsAddSidHistory
Die DsAddSidHistory-Funktion ruft die Primäre Kontosicherheits-ID (SID) eines Sicherheitsprinzipals aus einer Domäne (quelldomäne) ab und fügt sie dem sIDHistory-Attribut eines Sicherheitsprinzipals in einer anderen (Zieldomäne) in einer anderen Gesamtstruktur hinzu. Wenn sich die Quelldomäne im nativ Windows 2000 befindet, ruft diese Funktion auch die sIDHistory-Werte des Quellprinzipals ab und fügt sie der sIDHistory des Zielprinzipals hinzu.
Das Hinzufügen von SIDs zurIDHistory eines Sicherheitsprinzipals ist ein sicherheitssensibler Vorgang, der dem Zielprinzipal effektiv Zugriff auf alle Ressourcen gewährt, auf die der Quellprinzipal zugreifen kann, vorausgesetzt, dass Vertrauensstellungen von den anwendbaren Ressourcendomänen zur Zieldomäne vorhanden sind.
In einer Domäne im nativ Windows 2000-Modus erstellt eine Benutzeranmeldung ein Zugriffstoken, das die SID des primären Benutzerkontos und die Gruppen-SIDs sowie die Benutzer-sIDHistory und die sIDHistory der Gruppen enthält, deren Mitglied der Benutzer ist. Diese früheren SIDs (sIDHistory-Werte) im Token des Benutzers gewähren dem Benutzer Zugriff auf Ressourcen, die durch Zugriffssteuerungslisten (Access Control Lists, ACLs) geschützt sind, die die früheren SIDs enthalten.
Dieser Vorgang erleichtert bestimmte Windows 2000-Bereitstellungsszenarien. Insbesondere wird ein Szenario unterstützt, in dem Konten in einer neuen Windows 2000-Gesamtstruktur für Benutzer und Gruppen erstellt werden, die bereits in einer Windows NT 4.0-Produktionsumgebung vorhanden sind. Durch das Platzieren der Windows NT 4.0-Konto-SID im Windows 2000-Konto sIDHistory wird der Zugriff auf Netzwerkressourcen für den Benutzer beibehalten, der sich bei seinem neuen Windows 2000-Konto anmelden kann.
DsAddSidHistory unterstützt auch die Migration von Windows NT 4.0-Sicherungsdomänencontrollern (BDCs) Windows zu einer Windows 2000-Domäne als Mitgliedsserver. Diese Migration erfordert die Erstellung von lokalen Domänengruppen in der Zieldomäne Windows 2000, die in ihrer sIDHistory die primären SIDs der lokalen Gruppen enthalten, die auf dem BDC (oder lokalen Domänengruppen, auf die in ACLs auf den Windows 2000-Servern verwiesen wird) in der Quelldomäne definiert sind. Durch das Erstellen einer lokalen Zielgruppe, die sIDHistory und alle Mitglieder der lokalen Quellgruppe enthält, wird der Zugriff auf die migrierten Serverressourcen, geschützt durch ACLs, die auf die lokale Quellgruppe verweisen, für alle Mitglieder verwaltet.
Hinweis
Die Verwendung von DsAddSidHistory erfordert ein Verständnis der umfassenderen administrativen und Sicherheitsauswirkungen in diesen und anderen Szenarien. Weitere Informationen finden Sie im Whitepaper "Planning Migration from Windows NT to Microsoft Windows 2000" (Planen der Migration von Windows NT zu Microsoft Windows 2000), das als Dommig.doc in den Windows 2000-Supporttools bereitgestellt wird. Diese Dokumentation finden Sie auch auf der Produkt-CD unter \ \ Supporttools.
Autorisierungsanforderungen
DsAddSidHistory erfordert Administratorrechte in den Quell- und Zieldomänen. Insbesondere muss der Aufrufer dieser API Mitglied der Gruppe Domänenadministratoren in der Zieldomäne sein. Für diese Mitgliedschaft wird eine hart codierte Überprüfung durchgeführt. Außerdem muss der Aufrufer oder das im SrcDomainCreds-Parameter bereitgestellte Konto, wenn nicht NULL, Mitglied der Gruppe Administratoren oder Domänenadministratoren in der Quelldomäne sein.
Domänen- und Vertrauensstellungsanforderungen
DsAddSidHistory erfordert, dass sich die Zieldomäne im nativ Windows 2000 oder höher befindet, da nur dieser Domänentyp das sIDHistory-Attribut unterstützt. Die Quelldomäne kann entweder nt Windows 4.0 oder Windows 2000 im gemischten oder nativen Modus sein. Die Quell- und Zieldomänen dürfen sich nicht in derselben Gesamtstruktur befinden. Windows NT 4.0-Domänen befinden sich definitionsgemäß nicht in einer Gesamtstruktur. Diese Einschränkung zwischen Gesamtstruktur stellt sicher, dass doppelte SIDs , unabhängig davon, ob sie als primäre SIDs oder sIDHistory-Werte angezeigt werden, nicht in derselben Gesamtstruktur erstellt werden.
DsAddSidHistory erfordert eine externe Vertrauensstellung von der Quelldomäne zur Zieldomäne in den in der folgenden Tabelle aufgeführten Fällen.
| Fall | BESCHREIBUNG |
|---|---|
| Die Quelldomäne ist Windows 2000. |
Das sIDHistory-Quellattribut, das nur in Windows 2000-Quelldomänen verfügbar ist, kann nur über LDAP gelesen werden, was diese Vertrauensstellung für den Integritätsschutz erfordert. |
| Die Quelldomäne ist Windows NT 4.0 und SrcDomainCreds ist NULL. |
Der Identitätswechsel, der erforderlich ist, um Quelldomänenvorgänge mithilfe der Anmeldeinformationen des Aufrufers zu unterstützen, hängt von dieser Vertrauensstellung ab. Der Identitätswechsel erfordert auch, dass für den Zieldomänencontroller standardmäßig "Vertrauenswürdig für Delegierung" auf Domänencontrollern aktiviert ist. |
Zwischen den Quell- und Zieldomänen ist jedoch keine Vertrauensstellung erforderlich, wenn die Quelldomäne Windows NT 4.0 ist und SrcDomainCreds nicht NULL ist.
Anforderungen an den Quelldomänencontroller
DsAddSidHistory erfordert, dass der Domänencontroller, der als Ziel für Vorgänge in der Quelldomäne ausgewählt wurde, das PDC in Windows NT 4.0-Domänen oder das PDC Emulator in Windows 2000-Domänen ist. Die Überwachung der Quelldomäne wird über Schreibvorgänge generiert. Daher ist das PDC in Windows NT 4.0-Quelldomänen erforderlich, und die Einschränkung nur für PDC stellt sicher, dass DsAddSidHistory-Überwachungen auf einem einzelnen Computer generiert werden. Dies reduziert die Notwendigkeit, die Überwachungsprotokolle aller Dcs zu überprüfen, um die Verwendung dieses Vorgangs zu überwachen.
Hinweis
In Windows NT 4.0-Quelldomänen muss auf dem PDC (Ziel von Vorgängen in der Quelldomäne) Service Pack 4 (SP4) und höher ausgeführt werden, um eine ordnungsgemäße Überwachung sicherzustellen.
Der folgende Registrierungswert muss als REG DWORD-Wert erstellt und auf dem Quelldomänencontroller für Windows _ NT 4.0- und Windows 2000-Quelldomänencontroller auf 1 festgelegt werden.
HKEY_LOCAL_MACHINE
System
CurrentControlSet
Control
Lsa
TcpipClientSupport
Durch Festlegen dieses Werts werden RPC-Aufrufe über den TCP-Transport aktiviert. Dies ist erforderlich, da SAMRPC-Schnittstellen standardmäßig nur auf Named Pipes remotable sind. Die Verwendung von Named Pipes führt zu einem Anmeldeinformationsverwaltungssystem, das für interaktiv angemeldete Benutzer geeignet ist, die Netzwerkaufrufe tätigen, ist aber nicht flexibel für einen Systemprozess, der Netzwerkaufrufe mit vom Benutzer bereitgestellten Anmeldeinformationen vorn bringt. RPC über TCP ist für diesen Zweck besser geeignet. Wenn Sie diesen Wert festlegen, wird die Systemsicherheit nicht beeinträchtigt. Wenn dieser Wert erstellt oder geändert wird, muss der Quelldomänencontroller neu gestartet werden, damit diese Einstellung wirksam wird.
Die neue lokale Gruppe "$$$" muss zu Überwachungszwecken in der Quelldomäne erstellt werden.
Überwachung
DsAddSidHistory-Vorgänge werden überwacht, um sicherzustellen, dass sowohl Quell- als auch Zieldomänenadministratoren erkennen können, wann diese Funktion ausgeführt wurde. Die Überwachung ist sowohl in der Quell- als auch in der Zieldomäne obligatorisch. DsAddSidHistory überprüft, ob der Überwachungsmodus in jeder Domäne aktiviert ist und dass die Kontoverwaltungsüberwachung von Erfolgs-/Fehlerereignissen aktiviert ist. In der Zieldomäne wird für jeden erfolgreichen oder fehlgeschlagenen DsAddSidHistory-Vorgang ein eindeutiges Überwachungsereignis "Sidverlauf hinzufügen" generiert.
Eindeutige Überwachungsereignisse vom Typ "Sidverlauf hinzufügen" sind auf nt Windows 4.0-Systemen nicht verfügbar. Um Überwachungsereignisse zu generieren, die eindeutig die Verwendung von DsAddSidHistory für die Quelldomäne widerspiegeln, werden Vorgänge für eine spezielle Gruppe durchgeführt, deren Name der eindeutige Bezeichner im Überwachungsprotokoll ist. Eine lokale Gruppe namens "$$$", deren Name aus dem NetBIOS-Quelldomänennamen besteht, der mit drei Dollarzeichen ($) (ASCII-Code = 0x24 und Unicode = U+0024) angefügt ist, muss vor dem Aufruf von DsAddSidHistory auf dem Quelldomänencontroller erstellt werden. Jeder Quellbenutzer und jede globale Gruppe, die ziel dieses Vorgangs ist, wird hinzugefügt und dann aus der Mitgliedschaft dieser Gruppe entfernt. Dadurch werden Überwachungsereignisse "Mitglied hinzufügen" und "Mitglied löschen" in der Quelldomäne generiert, die durch Suchen nach Ereignissen überwacht werden können, die auf den Gruppennamen verweisen.
Hinweis
DsAddSidHistory-Vorgänge für lokale Gruppen in einer Windows NT 4.0- oder Windows 2000-Quelldomäne im gemischten Modus können nicht überwacht werden, da lokale Gruppen nicht zu Mitgliedern einer anderen lokalen Gruppe werden können und daher nicht der speziellen lokalen Gruppe "$$$ " hinzugefügt werden können. Diese fehlende Überwachung stellt kein Sicherheitsproblem für die Quelldomäne vor, da der Zugriff auf Quelldomänenressourcen von diesem Vorgang nicht betroffen ist. Durch das Hinzufügen der SID einer lokalen Quellgruppe zu einer lokalen Zielgruppe wird zusätzlichen Benutzern kein Zugriff auf Quellressourcen gewährt, die von dieser lokalen Gruppe geschützt werden. Das Hinzufügen von Mitgliedern zur lokalen Zielgruppe gewährt ihnen keinen Zugriff auf Quellressourcen. Hinzugefügten Mitgliedern wird nur Zugriff auf Server in der Zieldomäne gewährt, die aus der Quelldomäne migriert wurden. Diese verfügen möglicherweise über Ressourcen, die durch die SID der lokalen Quellgruppe geschützt sind.
Sicherheit der Datenübertragung
DsAddSidHistory erzwingt die folgenden Sicherheitsmaßnahmen:
- Wird von Windows 2000-Arbeitsstation aufgerufen, werden die Anmeldeinformationen des Aufrufers verwendet, um den RPC-Aufruf an den Zieldomänencontroller zu authentifizieren und den Datenschutz zu schützen. Wenn SrcDomainCreds nicht NULL ist, müssen sowohl die Arbeitsstation als auch der Ziel-DC die 128-Bit-Verschlüsselung unterstützen, um die Anmeldeinformationen zum Schutz des Datenschutzes zu schützen. Wenn keine 128-Bit-Verschlüsselung verfügbar ist und SrcDomainCreds bereitgestellt wird, muss der Aufruf auf dem Zieldomänencontroller vorgenommen werden.
- Der Zieldomänencontroller kommuniziert mit dem Quelldomänencontroller, indem entweder SrcDomainCreds oder die Anmeldeinformationen des Aufrufers verwendet werden, um sich gegenseitig zu authentifizieren und den Leseschutz der Quellkonto-SID (mithilfe einer SAM-Suche) und sIDHistory (mithilfe eines LDAP-Leses) zu gewährleisten.
Bedrohungsmodelle
In der folgenden Tabelle sind die potenziellen Bedrohungen aufgeführt, die dem DsAddSidHistory-Aufruf zugeordnet sind, und die Sicherheitsmaßnahmen, die für die bestimmte Bedrohung relevant sind.
| Potenzielle Bedrohung | Sicherheitsmaßnahme |
|---|---|
| Man-in-the-Middle-Angriff Ein nicht autorisierter Benutzer fängt die Such-SID des Quellobjekt-Rückgabeaufrufs ab und ersetzt die Quellobjekt-SID durch eine beliebige SID zum Einfügen in ein Zielobjekt SIDhistory. |
Die Such-SID des Quellobjekts ist ein authentifizierter RPC, der die Administratoranmeldeinformationen des Aufrufers mit Paketintegritätsmeldungsschutz verwendet. Dadurch wird sichergestellt, dass der Rückgabeaufruf nicht ohne Erkennung geändert werden kann. Der Zieldomänencontroller erstellt ein eindeutiges Überwachungsereignis "SID-Verlauf hinzufügen", das die SID widerspiegelt, die dem Zielkonto sIDHistory hinzugefügt wurde. |
| Source-Domäne von Trojanern Ein nicht autorisierter Benutzer erstellt eine Quelldomäne "TrojanEr" in einem privaten Netzwerk, das über die gleiche Domänen-SID und einige der gleichen Konto-SIDs wie die legitime Quelldomäne verfügt. Der nicht autorisierte Benutzer versucht dann, DsAddSidHistory in einer Zieldomäne ausführen, um die SID eines Quellkontos zu erhalten. Dies erfolgt, ohne dass die Anmeldeinformationen des Echten Quelldomänenadministrators erforderlich sind und kein Überwachungspfad in der tatsächlichen Quelldomäne hinterlassen wird. Die Methode des nicht autorisierten Benutzers zum Erstellen der Source-Domäne "Trojaner" kann eine der folgenden sein:
|
Es gibt zwar viele Möglichkeiten für einen nicht autorisierten Benutzer, eine gewünschte Quellobjekt-SID abzurufen oder zu erstellen, aber der nicht autorisierte Benutzer kann sie nicht verwenden, um die IDHistory eines Kontos zu aktualisieren, ohne Mitglied der Gruppe der Zieldomänenadministratoren zu sein. Da die Überprüfung der Domänenadministratormitgliedschaft auf dem Zieldomänencontroller hart codiert ist, gibt es auf dem Zieldomänencontroller keine Methode zum Ändern der Zugriffssteuerungsdaten, die diese Funktion schützen. In der Zieldomäne wird ein Versuch überwacht, ein Source-Konto eines "Trojaner" zu klonen. Dieser Angriff wird durch die Reservierung der Mitgliedschaft in der Gruppe Domänenadministratoren nur für stark vertrauenswürdige Personen gemindert. |
| Änderung des SID-Verlaufs auf dem Datenträger Ein anspruchsvoller nicht autorisierter Benutzer mit Anmeldeinformationen des Domänenadministrators und physischem Zugriff auf einen Domänencontroller in der Zieldomäne könnte den sIDHistory-Wert eines Kontos auf dem Datenträger ändern. |
Dieser Versuch wird nicht mit DsAddSidHistory aktiviert. Dieser Angriff wird entschärft, indem der physische Zugriff auf Domänencontroller für alle Außer-vertrauenswürdigen Administratoren verhindert wird. |
| Nicht autorisierter Code zum Entfernen von Schutzmaßnahmen Ein nicht autorisierter Benutzer oder nicht autorisierter Administrator mit physischem Zugriff auf den Verzeichnisdienstcode könnte nicht autorisierten Code erstellen, der:
|
Ein Benutzer mit physischem Zugriff auf den DS-Code und ausreichend Kenntnisse zum Erstellen von nicht autorisiertem Code hat die Möglichkeit, das sIDHistory-Attribut eines Kontos willkürlich zu ändern. Die DsAddSidHistory-API erhöht dieses Sicherheitsrisiko nicht. |
| Ressourcen, die für gestohlene SIDs anfällig sind Wenn ein nicht autorisierter Benutzer erfolgreich eine der hier beschriebenen Methoden zum Ändern eines Kontos sIDHistoryverwendet hat und die ressourcendomänen von Interesse der Domäne des nicht autorisierten Benutzerkontos vertrauen, kann der nicht autorisierte Benutzer nicht autorisierten Zugriff auf die Ressourcen der gestohlenen SID erhalten, möglicherweise ohne einen Überwachungspfad in der Kontodomäne zu verlassen, aus der die SID gestohlen wurde. |
Ressourcendomänenadministratoren schützen ihre Ressourcen, indem sie nur die Vertrauensstellungen einrichten, die aus Sicherheitssicht sinnvoll sind. Die Verwendung von DsAddSidHistory ist in der vertrauenswürdigen Zieldomäne auf Mitglieder der Gruppe Domänenadministratoren beschränkt, die bereits über umfassende Berechtigungen im Rahmen ihrer Zuständigkeiten verfügen. |
| Nicht autorisierte Zieldomäne Ein nicht autorisierter Benutzer erstellt eine Windows 2000-Domäne mit einem Konto, dessen sIDHistory eine SID enthält, die aus einer Quelldomäne gestohlen wurde. Der nicht autorisierte Benutzer verwendet dieses Konto für den nicht autorisierten Zugriff auf Ressourcen. |
Der nicht autorisierte Benutzer benötigt Administratoranmeldeinformationen für die Quelldomäne, um DsAddSidHistoryverwenden zu können, und hinterlässt einen Überwachungspfad auf dem Quelldomänencontroller. Die nicht autorisierte Zieldomäne erhält nur in anderen Domänen, die der nicht autorisierten Domäne vertrauen, nicht autorisierten Zugriff, was Administratorrechte in diesen Ressourcendomänen erfordert. |
Betriebseinschränkungen
In diesem Abschnitt werden die betrieblichen Einschränkungen der Verwendung der DsAddSidHistory-Funktion beschrieben.
Die SID von SrcPrincipal darf nicht bereits in der Zielgestruktur vorhanden sein, weder als primäre Konto-SID noch in der sIDHistory eines Kontos. Die Ausnahme ist, dass DsAddSidHistory beim Versuch, einer sIDHistory, die eine identische SID enthält, eine SID hinzuzufügen, keinen Fehler generiert. Dieses Verhalten ermöglicht die mehrfache Ausführung von DsAddSidHistory mit identischer Eingabe, was zu Erfolg und einem konsistenten Endzustand führt, um die Benutzerfreundlichkeit für Toolentwickler zu erleichtern.
Hinweis
Die Latenz der globalen Katalogreplikation kann ein Fenster bereitstellen, in dem doppelte SIDs erstellt werden können. Doppelte SIDs können jedoch problemlos von einem Administrator gelöscht werden.
SrcPrincipal und DstPrincipal müssen einen der folgenden Typen haben:
Benutzer
Sicherheitsfähige Gruppe, einschließlich:
- Lokale Gruppe
Globale Gruppe
Lokale Domänengruppe (nur Windows 2000-Modus)
Universelle Gruppe (nur Windows 2000-Modus)
Die Objekttypen von SrcPrincipal und DstPrincipal müssen übereinstimmen.
- Wenn SrcPrincipal ein Benutzer ist, muss DstPrincipal ein Benutzer sein.
- Wenn SrcPrincipal eine lokale gruppe oder eine lokale Domänengruppe ist, muss DstPrincipal eine lokale Domänengruppe sein.
- Wenn SrcPrincipal eine globale oder universelle Gruppe ist, muss DstPrincipal eine globale oder universelle Gruppe sein.
SrcPrincipal und DstPrincipal dürfen keinen der folgenden Typen haben: (DsAddSidHistory schlägt in diesen Fällen mit einem Fehler fehl)
Computer (Arbeitsstation oder Domänencontroller)
Domänenübergreifende Vertrauensstellung
Temporäres doppeltes Konto (praktisch nicht genutztes Feature, ein Legacy von LANman)
Konten mit bekannten SIDs. Bekannte SIDs sind in jeder Domäne identisch. Daher würde das Hinzufügen zu einer sIDHistory die SID-Eindeutigkeitsanforderung einer Windows 2000-Gesamtstruktur verletzen. Konten mit bekannten SIDs umfassen die folgenden lokalen Gruppen:
- Kontooperatoren
Administrators
Sicherungsoperatoren
Gäste
Druckoperatoren
Replicator
Serveroperatoren
Benutzer
Wenn SrcPrincipal über einen bekannten relativen Bezeichner (RID) und ein domänenspezifisches Präfix (d. h. Domänenadministratoren, Domänenbenutzer und Domänencomputer) verfügt, muss DstPrincipal dieselbe bekannte RID besitzen, damit DsAddSidHistory erfolgreich ist. Konten mit bekannten RIDs umfassen die folgenden Benutzer und globalen Gruppen:
- Administrator
- Gast
- Domänenadministratoren
- Domänen gäste
- Domänenbenutzer
Festlegen des Registrierungswerts
Das folgende Verfahren zeigt, wie Der TcpipClientSupport-Registrierungswert festgelegt wird.
So legen Sie den TcpipClientSupport-Registrierungswert fest
Erstellen Sie den folgenden Registrierungswert als REG DWORD-Wert auf dem Quelldomänencontroller, und legen Sie _ dessen Wert auf 1 fest.
HKEY _ LOCAL MACHINE SYSTEM _ \ \ CurrentControlSet-Steuerelement \ \ Lsa \ TcpipClientSupport
Starten Sie dann den Quelldomänencontroller neu. Dieser Registrierungswert bewirkt, dass SAM TCP/IP abhört. DsAddSidHistory kann nicht verwendet werden, wenn dieser Wert nicht auf dem Quelldomänencontroller festgelegt ist.
Aktivieren der Überwachung von Benutzer-/Gruppenverwaltungsereignissen
Das folgende Verfahren zeigt, wie Sie die Überwachung von Benutzer-/Gruppenverwaltungsereignissen in einer Windows 2000- oder Windows Server 2003-Quell- oder -Zieldomäne aktivieren.
So aktivieren Sie die Überwachung von Benutzer-/Gruppenverwaltungsereignissen in einer Windows 2000- oder Windows Server 2003-Quell- oder -Zieldomäne
- Wählen Sie Active Directory-Benutzer und -Computer MMC-Snap-In den Zieldomänencontrollercontainer aus.
- Klicken Sie mit der rechten Maustaste auf Domänencontroller, und wählen Sie Eigenschaften aus.
- Klicken Sie auf Gruppenrichtlinie Registerkarte .
- Wählen Sie die Standarddomänencontrollerrichtlinie aus, und klicken Sie auf Bearbeiten.
- Doppelklicken Sie unter \ \ Computerkonfiguration Windows Einstellungen \ \ Einstellungen Überwachungsrichtlinie für lokale Richtlinien auf Kontoverwaltung überwachen.
- Wählen Sie im Fenster Kontoverwaltung überwachen die Option Überwachung erfolgreich und Fehler aus. Richtlinienupdates werden nach einem Neustart oder nach einer Aktualisierung wirksam.
- Überprüfen Sie, ob die Überwachung aktiviert ist, indem Sie die effektive Überwachungsrichtlinie im Gruppenrichtlinie MMC-Snap-In anzeigen.
Das folgende Verfahren zeigt, wie Sie die Überwachung von Benutzer-/Gruppenverwaltungsereignissen in einer Windows NT 4.0-Domäne aktivieren.
So aktivieren Sie die Überwachung von Benutzer-/Gruppenverwaltungsereignissen in einer Windows NT 4.0-Domäne
- Klicken Sie im Benutzer-Manager für Domänen auf das Menü Richtlinien, und wählen Sie Überwachen aus.
- Wählen Sie Audit These Events (Diese Ereignisse überwachen) aus.
- Aktivieren Sie für Benutzer- und Gruppenverwaltung die Kontrollkästchen Erfolg und Fehler.
Das folgende Verfahren zeigt, wie Sie die Überwachung von Benutzer-/Gruppenverwaltungsereignissen in einer Windows NT 4.0-, Windows 2000- oder Windows Server 2003-Quelldomäne aktivieren.
So aktivieren Sie die Überwachung von Benutzer-/Gruppenverwaltungsereignissen in einer Windows NT 4.0-, Windows 2000- oder Windows Server 2003-Quelldomäne
- Klicken Sie im Benutzer-Manager für Domänen auf das Menü Benutzer, und wählen Sie Neue lokale Gruppe aus.
- Geben Sie einen Gruppennamen ein, der aus dem NetBIOS-Namen der Quelldomäne besteht, der mit drei Dollarzeichen ($) angefügt ist, z. B. FABRIKAM$$$. Das Beschreibungsfeld sollte angeben, dass diese Gruppe verwendet wird, um die Verwendung von DsAddSidHistory oder Klonvorgängen zu überwachen. Stellen Sie sicher, dass keine Mitglieder in der Gruppe sind. Klicken Sie auf OK.
Der DsAddSidHistory-Vorgang schlägt fehl, wenn die Quell- und Zielüberwachung nicht wie hier beschrieben aktiviert ist.
Einrichten der Vertrauensstellung bei Bedarf
Wenn eine der folgenden Bedingungen zutrifft, muss eine Vertrauensstellung von der Quelldomäne zur Zieldomäne eingerichtet werden (dies muss in einer anderen Gesamtstruktur erfolgen):
- Die Quelldomäne ist Windows Server 2003.
- Die Quelldomäne ist Windows NT 4.0 und SrcDomainCreds ist NULL.