DsAddSidHistory verwenden

Die Funktion DsAddSidHistory ruft die primäre Kontosicherheitskennung (SID) eines Sicherheitsprinzipals aus einer Domäne (der Quelldomäne) ab und fügt sie dem Attribut sIDHistory eines Sicherheitsprinzipals in einer anderen (Ziel-)Domäne in einer anderen Gesamtstruktur hinzu. Wenn sich die Quelldomäne im nativen Modus von 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 zu einem Sicherheitsprinzipal sIDHistory ist ein sicherheitsrelevanter Vorgang, der dem Zielprinzipal Zugriff auf alle Ressourcen gewährt, auf die der Quellprinzipal zugreifen kann, vorausgesetzt, dass Vertrauensstellungen von den anwendbaren Ressourcendomänen zur Zieldomäne bestehen.

In einer Windows 2000-Domäne im nativen Modus wird bei der Anmeldung eines Benutzers ein Zugriffstoken erstellt, das die SID des primären Benutzerkontos und die SIDs der Gruppen sowie die sIDHistory und die sIDHistory der Gruppen, in denen der Benutzer Mitglied ist, enthält. Wenn diese früheren SIDs (sIDHistory-Werte) im Token des Benutzers vorhanden sind, erhält der Benutzer Zugriff auf Ressourcen, die durch Zugriffskontrolllisten (ACLs) geschützt sind, die die früheren SIDs enthalten.

Dieser Vorgang erleichtert bestimmte Einsatzszenarien von Windows 2000. Insbesondere unterstützt es ein Szenario, 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 existieren. Indem die SID des Windows NT 4.0-Kontos in das Windows 2000-Konto sIDHistory eingefügt wird, bleibt der Zugriff auf Netzwerkressourcen für den Benutzer, der sich bei seinem neuen Windows 2000-Konto anmeldet, erhalten.

DsAddSidHistory unterstützt auch die Migration von Windows NT 4.0 Backup-Domänencontroller (BDCs) Ressourcenservern (oder DCs und Mitgliedsservern in einer Windows 2000-Domäne im nativen Modus) in eine Windows 2000-Domäne als Mitgliedsserver. Für diese Migration müssen in der Windows 2000-Zieldomäne lokale Domänengruppen erstellt werden, die in ihrer sIDHistory die primären SIDs der auf dem BDC definierten lokalen Gruppen (oder der in ACLs auf den Windows 2000-Servern referenzierten lokalen Domänengruppen) in der Quelldomäne enthalten. Durch die Erstellung einer lokalen Zielgruppe, die die sIDHistory und alle Mitglieder der lokalen Quellgruppe enthält, wird der Zugriff auf die migrierten Serverressourcen, die durch ACLs geschützt sind, die auf die lokale Quellgruppe verweisen, für alle Mitglieder beibehalten.

Hinweis

Die Verwendung von DsAddSidHistory erfordert ein Verständnis der weitergehenden administrativen und sicherheitsrelevanten Auswirkungen in diesen und anderen Szenarien. Weitere Informationen finden Sie in dem White Paper „Planning Migration from Windows NT to Microsoft Windows 2000“, das als Dommig.doc in den Windows 2000 Support Tools zur Verfügung steht. Diese Dokumentation befindet sich auch auf der Produkt-CD unter \Support\Tools.

Anforderungen an die Autorisierung

DsAddSidHistory erfordert Administratorrechte in den Quell- und Zieldomänen. Insbesondere muss der Aufrufer dieser API ein Mitglied der Gruppe Domänenadministratoren in der Zieldomäne sein. Es wird eine fest kodierte Prüfung auf diese Mitgliedschaft durchgeführt. Außerdem muss das im Parameter SrcDomainCreds angegebene Konto Mitglied der Gruppe „Administrators“ oder „Domain Administrators“ in der Quelldomäne sein. Wenn NULL in SrcDomainCreds übergeben wird, muss der Aufrufer der API entweder Mitglied der Gruppe Administrators oder Domain Administrators in der Quelldomäne sein.

Domänen- und Vertrauensanforderungen

DsAddSidHistory erfordert, dass sich die Zieldomäne im nativen Modus von Windows 2000 oder höher befindet, da nur dieser Domänentyp das Attribut sIDHistory unterstützt. Die Quelldomäne kann entweder Windows NT 4.0 oder Windows 2000, gemischter oder nativer Modus sein. Die Quell- und die Zieldomäne dürfen sich nicht im selben Forest befinden. Windows NT 4.0-Domänen befinden sich per Definition nicht in einer Gesamtstruktur. Diese waldübergreifende Einschränkung stellt sicher, dass doppelte SIDs, egal ob sie als primäre SIDs oder als sIDHistory-Werte erscheinen, nicht im selben Wald erstellt werden.

DsAddSidHistory erfordert in den in der folgenden Tabelle aufgeführten Fällen einen externen Trust von der Quelldomäne zur Zieldomäne.

Fall	Beschreibung
Die Quelldomäne ist Windows 2000.	Das Attribut sIDHistory, das nur in Windows 2000-Quelldomänen verfügbar ist, kann nur über LDAP gelesen werden, das dieses Vertrauen für den Integritätsschutz benötigt.
Die Quelldomäne ist Windows NT 4.0 und SrcDomainCreds ist NULL.	Die Impersonation, die erforderlich ist, um Operationen in der Quelldomäne unter Verwendung der Anmeldeinformationen des Anrufers zu unterstützen, hängt von diesem Vertrauen ab. Für die Impersonation ist es außerdem erforderlich, dass auf dem Ziel-Domänencontroller standardmäßig „Trusted for Delegation“ aktiviert ist.

Es ist jedoch kein Vertrauen zwischen der Quell- und Zieldomäne erforderlich, wenn die Quelldomäne Windows NT 4.0 ist und SrcDomainCreds nicht NULL ist.

Anforderungen an den Quell-Domänencontroller

DsAddSidHistory erfordert, dass der Domänencontroller, der als Ziel für Operationen in der Quelldomäne ausgewählt wurde, der PDC in Windows NT 4.0-Domänen oder der PDC-Emulator in Windows 2000-Domänen ist. Quelldomänenüberprüfungen werden durch Schreibvorgänge erzeugt, daher ist der PDC in Windows NT 4.0-Quelldomänen erforderlich, und die Beschränkung auf den PDC stellt sicher, dass DsAddSidHistory Überprüfungen auf einem einzigen Computer erzeugt werden. Dies reduziert die Notwendigkeit, die Audit-Protokolle aller DCs zu überprüfen, um die Verwendung dieser Operation 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) oder höher ausgeführt werden, um eine ordnungsgemäße Unterstützung der Überprüfung zu gewährleisten.

Der folgende Registrierungswert muss als REG_DWORD-Wert erstellt und auf dem Quell-Domänencontroller sowohl für Windows NT 4.0- als auch für Windows 2000-Quell-DCs auf 1 gesetzt werden.

HKEY_LOCAL_MACHINE
   System
      CurrentControlSet
         Control
            Lsa
               TcpipClientSupport

Die Einstellung dieses Wertes ermöglicht RPC-Aufrufe über den TCP-Transport. Dies ist erforderlich, da SAMRPC-Schnittstellen standardmäßig nur über benannte Leitungen entfernt werden können. Die Verwendung von Named Pipes führt zu einem System zur Verwaltung von Anmeldeinformationen, das sich für interaktiv angemeldete Benutzer eignet, die Netzwerkaufrufe tätigen, aber nicht flexibel ist für einen Systemprozess, der Netzwerkaufrufe mit vom Benutzer bereitgestellten Anmeldeinformationen tätigt. RPC über TCP ist für diesen Zweck besser geeignet. Die Einstellung dieses Wertes beeinträchtigt die Systemsicherheit nicht. Wenn dieser Wert erstellt oder geändert wird, muss der Quelldomänencontroller neu gestartet werden, damit diese Einstellung wirksam wird.

Eine neue lokale Gruppe, „<SrcDomainName>$$$“, muss in der Quelldomäne zu Überprüfungszwecken erstellt werden.

Überwachung

DsAddSidHistory Vorgänge werden überprüft, um sicherzustellen, dass sowohl Quell- als auch Zieldomänenadministratoren in der Lage sind, zu erkennen, wann diese Funktion ausgeführt worden ist. Auditing ist sowohl in der Quell- als auch in der Zieldomäne obligatorisch. DsAddSidHistory prüft, ob der Prüfungsmodus in jeder Domäne aktiviert ist und ob die Kontoverwaltungsprüfung von Erfolgs-/Fehlerereignissen eingeschaltet ist. In der Zieldomäne wird für jeden erfolgreichen oder fehlgeschlagenen DsAddSidHistory-Vorgang ein eindeutiges Audit-Ereignis „Add Sid History“ erzeugt.

Einzigartige „Add Sid History“-Audit-Ereignisse sind auf Windows NT 4.0-Systemen nicht verfügbar. Um Audit-Ereignisse zu erzeugen, die eindeutig die Verwendung von DsAddSidHistory gegen die Quelldomäne widerspiegeln, werden Operationen mit einer speziellen Gruppe durchgeführt, deren Name der eindeutige Bezeichner im Audit-Protokoll ist. Eine lokale Gruppe „<SrcDomainName>$$$“, deren Name sich aus dem NetBIOS-Namen der Quelldomäne mit drei angehängten Dollarzeichen ($) zusammensetzt (ASCII-Code = 0x24 und Unicode = U+0024), muss auf dem Quelldomänencontroller erstellt werden, bevor DsAddSidHistory aufgerufen wird. Jeder Quellbenutzer und jede globale Gruppe, die Ziel dieses Vorgangs ist, wird zu dieser Gruppe hinzugefügt und dann wieder entfernt. Dadurch werden in der Quelldomäne Audit-Ereignisse zum Hinzufügen von Mitgliedern und zum Löschen von Mitgliedern erzeugt, die durch die Suche nach Ereignissen, die auf den Gruppennamen verweisen, überwacht werden können.

Hinweis

DsAddSidHistory-Vorgänge auf lokalen Gruppen in einer Windows NT 4.0- oder Windows 2000-Quelldomäne mit gemischtem Modus können nicht geprüft werden, da lokale Gruppen nicht zu Mitgliedern einer anderen lokalen Gruppe gemacht werden können und daher nicht zu der speziellen lokalen Gruppe „<SrcDomainName>$$$“ hinzugefügt werden können. Diese fehlende Prüfung stellt kein Sicherheitsproblem für die Quelldomäne dar, da der Zugriff auf die Ressourcen der Quelldomäne durch diesen Vorgang nicht beeinträchtigt wird. Das Hinzufügen der SID einer lokalen Quellgruppe zu einer lokalen Zielgruppe gewährt keinen zusätzlichen Benutzern Zugriff auf Quellressourcen, die durch diese lokale Gruppe geschützt sind. Das Hinzufügen von Mitgliedern zur lokalen Gruppe des Ziels gewährt ihnen keinen Zugriff auf Quellressourcen. Hinzugefügte Mitglieder erhalten nur Zugriff auf Server in der Zieldomäne, die aus der Quelldomäne migriert wurden und deren Ressourcen möglicherweise durch die SID der lokalen Quellgruppe geschützt sind.

Sicherheit der Datenübertragung

DsAddSidHistory ergreift die folgenden Sicherheitsmaßnahmen:

• Bei einem Aufruf von einer Windows 2000-Arbeitsstation aus werden die Anmeldeinformationen des Aufrufers verwendet, um den RPC-Aufruf an den Zieldomänencontroller zu authentifizieren und die Privatsphäre zu schützen. Wenn SrcDomainCreds nicht NULL ist, müssen sowohl die Arbeitsstation als auch der Ziel-DC eine 128-Bit-Verschlüsselung unterstützen, um die Privatsphäre der Anmeldeinformationen zu schützen. Wenn keine 128-Bit-Verschlüsselung verfügbar ist und SrcDomainCreds bereitgestellt wird, muss der Anruf auf dem Ziel-DC erfolgen.
• Der Ziel-Domänencontroller kommuniziert mit dem Quell-Domänencontroller, indem er entweder SrcDomainCreds oder die Anmeldeinformationen des Aufrufers verwendet, um das Lesen der SID des Quellkontos gegenseitig zu authentifizieren und die Integrität zu schützen (unter Verwendung eines SAM-Lookups) und sIDHistory (unter Verwendung eines LDAP-Lesevorgangs).

Bedrohungsmodelle

In der folgenden Tabelle sind die potenziellen Bedrohungen aufgeführt, die mit dem Aufruf DsAddSidHistory verbunden sind, und es wird auf die Sicherheitsmaßnahmen eingegangen, die für die jeweilige Bedrohung relevant sind.

Potenzielle Bedrohung	Sicherheitsmaßnahme
Man-in-the-Middle-Angriff Ein unbefugter Benutzer fängt den lookup SID des Rückrufs des Quellobjekts ab und ersetzt die SID des Quellobjekts durch eine beliebige SID zum Einfügen in ein Zielobjekt SIDhistory.	Die lookup SID des Quellobjekts ist ein authentifizierter RPC, der die Administrator-Anmeldeinformationen des Aufrufers verwendet, mit Schutz der Paketintegritätsnachrichten. Dadurch wird sichergestellt, dass der Rückruf nicht unbemerkt verändert werden kann. Der Zieldomänencontroller erstellt ein eindeutiges Audit-Ereignis „Add SID History“, das die dem Zielkonto hinzugefügte SID widerspiegelt sIDHistory.
Trojan-Quelldomäne Ein unbefugter Benutzer erstellt eine „Trojan Horse“-Quelldomäne in einem privaten Netzwerk, die die gleiche Domänen-SID und einige der gleichen Konto-SIDs wie die legitime Quelldomäne hat. Der unbefugte Benutzer versucht dann, DsAddSidHistory in einer Zieldomäne auszuführen, um die SID eines Quellkontos zu erhalten. Dies geschieht, ohne dass die Anmeldedaten des Domänenadministrators der echten Quelle benötigt werden und ohne dass ein Prüfpfad in der echten Quelldomäne hinterlassen wird. Der unbefugte Benutzer könnte eine der folgenden Methoden zur Erstellung der Quelldomäne des Trojan Horse verwenden: Beschaffen Sie sich eine Kopie (BDC-Backup) der SAM-Quelldomäne. Erstellen Sie eine neue Domäne, indem Sie die Domänen-SID auf der Festplatte so ändern, dass sie mit der legitimen Quelldomänen-SID übereinstimmt, und erstellen Sie dann genügend Benutzer, um ein Konto mit der gewünschten SID zu instanziieren. Erstellen Sie eine BDC-Replik. Dazu sind die Anmeldedaten des Quelldomänenadministrators erforderlich. Dann nimmt der unbefugte Benutzer den Nachbau mit in ein privates Netzwerk, um den Angriff durchzuführen.	Obwohl es viele Möglichkeiten für einen nicht autorisierten Benutzer gibt, eine gewünschte Quellobjekt-SID abzurufen oder zu erstellen, kann der nicht autorisierte Benutzer sie nicht verwenden, um die sIDHistory eines Kontos zu aktualisieren, ohne Mitglied der Zieldomänenadministratorgruppe zu sein. Da die Überprüfung der Domänenadministrator-Mitgliedschaft auf dem Zieldomänencontroller fest kodiert ist, gibt es keine Möglichkeit, die Zugriffssteuerungsdaten zum Schutz dieser Funktion durch eine Festplattenänderung zu ändern. Der Versuch, ein Trojan-Horse-Quellkonto zu klonen, wird in der Zieldomäne überprüft. Dieser Angriff wird abgeschwächt, indem die Mitgliedschaft in der Gruppe der Domänenadministratoren nur besonders vertrauenswürdigen Personen vorbehalten ist.
Änderung des SID-Verlaufs auf der Festplatte Ein raffinierter, nicht autorisierter Benutzer mit Domänenadministrator-Anmeldeinformationen und physischem Zugriff auf einen DC in der Zieldomäne könnte den Wert eines Kontos sIDHistory auf der Festplatte ändern.	Dieser Versuch wird durch die Verwendung von DsAddSidHistory nicht ermöglicht. Dieser Angriff wird dadurch abgeschwächt, dass der physische Zugang zu den Domänencontrollern für alle außer hochgradig vertrauenswürdigen Administratoren verhindert wird.
Rogue Code zum Entfernen von Schutzmaßnahmen Ein unbefugter Benutzer oder ein bösartiger Administrator mit physischem Zugriff auf den Verzeichnisdienstcode könnte einen bösartigen Code erstellen, der: Entfernt die Prüfung auf Mitgliedschaft in der Gruppe „Domänenadministratoren“ im Code. Ändert die Aufrufe auf dem Quelldomänencontroller, die die SID auf einen LookupSidFromName verweisen, der nicht geprüft wird. Entfernt Audit-Log-Aufrufe.	Jemand, der physischen Zugriff auf den DS-Code hat und über das nötige Wissen verfügt, um Rogue-Code zu erstellen, kann das Attribut sIDHistory eines Kontos willkürlich ändern. Die API DsAddSidHistory erhöht dieses Sicherheitsrisiko nicht.
Durch gestohlene SIDs gefährdete Ressourcen Wenn es einem unbefugten Benutzer gelungen ist, mit einer der hier beschriebenen Methoden ein Konto sIDHistory zu ändern, und wenn die interessierenden Ressourcendomänen der Kontodomäne des unbefugten Benutzers vertrauen, dann kann der unbefugte Benutzer unbefugten Zugriff auf die Ressourcen der gestohlenen SID erhalten, möglicherweise ohne eine Prüfspur in der Kontodomäne zu hinterlassen, aus der die SID gestohlen wurde.	Ressourcendomänenadministratoren schützen ihre Ressourcen, indem sie nur solche Vertrauensbeziehungen einrichten, die unter Sicherheitsaspekten sinnvoll sind. Die Verwendung von DsAddSidHistory ist in der vertrauenswürdigen Zieldomäne auf Mitglieder der Gruppe Domänenadministratoren beschränkt, die im Rahmen ihrer Zuständigkeiten bereits über weitreichende Berechtigungen verfügen.
Rogue Target Domain 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 Administrator-Anmeldeinformationen für die Quelldomäne, um DsAddSidHistory verwenden zu können, und hinterlässt einen Prüfpfad auf dem Quelldomänencontroller. Die Rogue-Zieldomäne erhält nur in anderen Domänen, die der Rogue-Domäne vertrauen, unbefugten Zugriff, was Administratorrechte in diesen Ressourcendomänen erfordert.

Operative Einschränkungen

In diesem Abschnitt werden die operativen Einschränkungen bei der Verwendung der Funktion DsAddSidHistory beschrieben.

Die SID von SrcPrincipal darf in der Ziel-Gesamtstruktur nicht bereits existieren, weder als primäre Konto-SID noch in der sIDHistory eines Kontos. Die Ausnahme ist, dass DsAddSidHistory keinen Fehler erzeugt, wenn versucht wird, eine SID zu einer sIDHistory hinzuzufügen, die eine identische SID enthält. Durch dieses Verhalten kann DsAddSidHistory mehrfach mit identischen Eingaben ausgeführt werden, was zum Erfolg und zu einem konsistenten Endzustand führt und die Verwendung des Tools für Entwickler erleichtert.

Hinweis

Die Latenzzeit für die Replikation des globalen Katalogs kann ein Zeitfenster bieten, in dem doppelte SIDs erstellt werden können. Doppelte SIDs können jedoch von einem Administrator leicht gelöscht werden.

SrcPrincipal und DstPrincipal müssen einer der folgenden Typen sein:

• Benutzer

• Sicherheitsaktivierte Gruppe, einschließlich:

  Lokale Gruppe Globale Gruppe Domänenlokale Gruppe (nur Windows 2000 nativer Modus) Universelle Gruppe (nur Windows 2000 nativer Modus)

Die Objekttypen von SrcPrincipal und DstPrincipal müssen übereinstimmen.

• Wenn SrcPrincipal ein Benutzer ist, muss DstPrincipal ein Benutzer sein.
• Wenn SrcPrincipal eine lokale oder domänenlokale Gruppe ist, muss DstPrincipal eine domänenlokale Gruppe sein.
• Wenn SrcPrincipal eine Global- oder Universalgruppe ist, muss DstPrincipal eine Global- oder Universalgruppe sein.

SrcPrincipal und DstPrincipal können nicht einer der folgenden Typen sein: (DsAddSidHistory schlägt in diesen Fällen mit einem Fehler fehl)

• Computer (Arbeitsplatzrechner oder Domänencontroller)

• Inter-Domain-Vertrauen

• Vorübergehend dupliziertes Konto (praktisch ungenutzte Funktion, ein Erbe von LANman)

• Konten mit wohlbekannten SIDs. Bekannte SIDs sind in jeder Domäne identisch; daher würde das Hinzufügen von SIDs zu sIDHistory die Anforderung der Eindeutigkeit von SIDs in einer Windows 2000-Gesamtstruktur verletzen. Zu den Konten mit „Well Known SIDs“ gehören die folgenden lokalen Gruppen:

  Kontobetreiber Administratoren Backup-Betreiber Gäste Druck-Betreiber Replikator Server-Betreiber Benutzer

Wenn SrcPrincipal einen bekannten relativen Bezeichner (RID) und ein domänenspezifisches Präfix hat, d. h. Domänenadministratoren, Domänenbenutzer und Domänencomputer, dann muss DstPrincipal denselben bekannten RID besitzen, damit DsAddSidHistory erfolgreich sein kann. Zu den Konten mit bekannten RIDs gehören die folgenden Benutzer und globalen Gruppen:

• Administrator
• Gast
• Domänenadministratoren
• Bereich Gäste
• Domänenbenutzer

Einstellen des Registrierungswerts

Das folgende Verfahren zeigt, wie Sie den Registrierungswert TcpipClientSupport festlegen.

So legen Sie den Registrierungswert TcpipClientSupport fest

1. Erstellen Sie den folgenden Registrierungswert als REG_DWORD-Wert auf dem Quelldomänencontroller und setzen Sie seinen Wert auf 1.

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\TcpipClientSupport

2. Starten Sie dann den Quell-Domänencontroller neu. Dieser Registrierungswert veranlasst den SAM, auf TCP/IP zu hören. DsAddSidHistory schlägt fehl, wenn dieser Wert auf dem Quelldomänencontroller nicht gesetzt ist.

Aktivieren des Auditing 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

1. Wählen Sie im MMC-Snap-In Active Directory-Benutzer und -Computer den Container Domänencontroller der Zieldomäne aus.
2. Klicken Sie mit der rechten Maustaste auf Domain Controllers und wählen Sie Eigenschaften.
3. Klicken Sie auf die Registerkarte Gruppenrichtlinie .
4. Wählen Sie die Richtlinie Standarddomänencontroller und klicken Sie auf Bearbeiten.
5. Doppelklicken Sie unter Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Audit-Richtlinie auf Audit Account Management.
6. Wählen Sie im Fenster Audit Account Management sowohl Success als auch Failure Auditing. Richtlinienaktualisierungen werden nach einem Neustart oder nach einer Aktualisierung wirksam.
7. Überprüfen Sie, ob die Überwachung aktiviert ist, indem Sie die effektive Überwachungsrichtlinie im Gruppenrichtlinien-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

1. Klicken Sie in User Manager for Domains auf das Menü Policies und wählen Sie Audit.
2. Wählen Sie Audit These Events.
3. Für Benutzer- und Gruppenverwaltung, siehe Erfolg und Misserfolg.

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

1. Klicken Sie im User Manager für Domänen auf das Menü Benutzer und wählen Sie Neue lokale Gruppe.
2. Geben Sie einen Gruppennamen ein, der aus dem NetBIOS-Namen der Quelldomäne und drei Dollarzeichen ($) besteht, z. B. FABRIKAM$$$$. Im Beschreibungsfeld sollte angegeben werden, dass diese Gruppe zur Prüfung der Verwendung von DsAddSidHistory oder Klonvorgängen verwendet wird. Vergewissern Sie sich, dass es keine Mitglieder in der Gruppe gibt. Klicken Sie auf OK.

Der Vorgang DsAddSidHistory schlägt fehl, wenn die Quell- und Zielüberprüfung nicht wie hier beschrieben aktiviert ist.

Trust einrichten, falls erforderlich

Wenn einer der folgenden Punkte zutrifft, muss eine Vertrauensstellung von der Quelldomäne zur Zieldomäne hergestellt werden (dies muss in einer anderen Gesamtstruktur geschehen):

• Die Quelldomäne ist Windows Server 2003.
• Die Quelldomäne ist Windows NT 4.0 und SrcDomainCreds ist NULL.