Durchführen einer Active Directory-Domainmigration für Dell Security Server

Summary: Durchführen einer Active Directory-Domainmigration in Dell Data Protection | Enterprise Edition.

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Instructions

Betroffene Produkte:

  • Dell Security Management Server
  • Dell Security Management Server Virtual
  • Dell Data Protection | Enterprise Edition
  • Dell Data Protection | Virtual Edition

Betroffene Versionen:

  • Version 6.0 bis 11.0

Warnung: Wir empfehlen dringend, unsere Serviceabteilung (kostenpflichtiger Service) einzubeziehen, um Sie bei der Planung des Domainmigrationsprozesses zu unterstützen.
  • Dell Security Management Server (ehemals Dell Data Protection | Enterprise Edition) ist betriebsbereit und mit der Domain verknüpft.
  • Eine vorhandene Domain wurde dem Abschnitt „Domain“ unter der WebUI-Konsole hinzugefügt.
  • Endpunkte wurden für den Server aktiviert.
  • Eine Migration der Domain ist erforderlich.
  • Auch die Migration des SID-Verlaufs der AD-Objekte ist in Planung.
  • Endpunkte verfügen über eine vollständige Verbindung zum Server und können Policys für die alte Domain abrufen, bevor der Domainmigrationsprozess gestartet wird.
  • Verschlüsselte Daten auf den Endpunkten sind vollständig zugänglich, Endpunkte sind aktiviert und es ist möglich, sie zu deaktivieren und erneut zu aktivieren. Wir können bestätigen, dass Aktivierungen mit einem schnellen WSDeactivate von Endpunkten ohne Probleme stattfinden.

Die allgemeinen Schritte sind nicht zu komplex, aber es ist wichtig zu wissen, dass, wenn der gesamte Prozess nicht ordnungsgemäß durchgeführt wird, Daten verloren gehen können oder eine Recovery von Maschinen erforderlich sein könnte. Während dieser Prozess auf jeder Version von Dell Security Management Server und Client durchgeführt werden kann, empfiehlt Dell Technologies, mindestens den Client 8.3.0 und den Server 8.5 zu installieren, da seitdem mehrere Verbesserungen vorgenommen wurden, wodurch der gesamte Migrationsprozess auf der Seite von Dell Security Management Server vereinfacht wird. Nachfolgend finden Sie eine Übersicht über die Funktionsweise des gesamten Prozesses und die wichtigsten Fragen.

Der erste Schritt besteht darin, zu verstehen, ob eine Domainmigration erforderlich ist. Es gibt Situationen, in denen ein Unternehmen beispielsweise zu Office 365 wechselt, in denen es ausreicht, einen Alias hinzuzufügen und als primären UPN für die AD-NutzerInnen festzulegen. Dies ist keine echte Domainmigration und es sind keine weiteren Maßnahmen auf Dell Data Protection | Enterprise Edition-Server notwendig als das Hinzufügen des neuen Alias zur Domainaliasliste unter Einstellungen, Domainaliasliste. Wenn eine neue Domain erstellt und AD-Objekte von der alten, außer Betrieb genommenen Domain in die neue verschoben werden müssen, muss eine Domainmigration geplant werden.

Wenn eine Domainmigration geplant ist, ist der erste Schritt, auch die Migration des SID-Verlaufs in Betracht zu ziehen. Um die Domainmigration auf der Seite Dell Security Management Server erfolgreich zu gestalten, muss der SID-Verlauf beibehalten werden. Andernfalls gelten AD-Objekte als neu für unseren Dell Security Management Server und daher auch nach der Reaktivierung, sodass wir nicht mit denselben Verschlüsselungsschlüsseln arbeiten können. Dell muss den SID-Verlauf migrieren. Wir werden nicht weiter ausführen, wie eine Domainmigration durchgeführt wird, da es sich hierbei nicht um eine Dell Data Protection | Encryption-Aufgabe handelt. Allerdings gibt es mehrere Tools wie ADMT von Microsoft, mit denen ein Unternehmen eine Domain A zu einer Domain B migrieren kann. Wie oben erwähnt, ist eine SID-Verlaufsmigration erforderlich, damit wir eine Aufrechterhaltung von Schlüsseln sicherstellen können. Die Migration des SID-Verlaufs bedeutet, dass wir das SID-Verlaufsattribut in AD der alten SID-Vormigration des Nutzers/der Nutzerin hinzufügen, um die Kontinuität in den migrierten Objekten zu gewährleisten.

In der Regel auf AD-Seite:

  • Wenn ein Objekt umbenannt wird, wird der Wert des objectSID-Attributs (die SID) nicht geändert. Wenn Sie ein Objekt von einer Domain in eine andere verschieben, muss sich die objectSID ändern, da ein Teil von ihr domainspezifisch ist, und die alte SID wird dem SIDHistory Attribut hinzugefügt (vorausgesetzt, dies wird migriert). Sie können SIDHistory mit ADSI Edit anzeigen (eine Ansicht ist in hexadezimal oder dezimal möglich). Wenn keine Werte vorhanden sind, gibt es keinen SID-Verlauf oder das Objekt wurde nie aus einer anderen Domain verschoben.
  • SIDhistory ist nur verfügbar, wenn Konten zwischen Domains oder Gesamtstruktur migriert werden.

Unten sehen Sie einen Screenshot, der zeigt, wie Sie feststellen können, ob SIDHistory mit dem Attributeditor migriert wurde:

SIDHistory

Hinweis: Sowohl das Nutzer- als auch das Maschinenobjekt verfügen über einen eigenen SID-Verlauf, der migriert werden muss.

Sobald wir bestätigt haben, dass auch die SIDHistory der migrierten NutzerInnen und Maschinen verschoben wurden, können wir mit der Dell Security Management Server-Konfiguration fortfahren. Wenn weitere Informationen zum Durchführen einer Domainmigration und zum Beibehalten des SID-Verlaufs erforderlich sind, lesen Sie die folgende Microsoft-Dokumentation:

Im Folgenden wird beschrieben, was während einer Domainmigration auf der Seite von Dell Security Management Server geschieht.

  1. Auf Seiten des Clients:
    • Wir lösen den UPN der Nutzerin/des Nutzers in die SID auf. Wir suchen nach ihrer/seiner SID in der Vault-Datei. Wir finden sie nicht.
    • Wir entscheiden, dass es sich um ein neues Nutzerkonto handelt, und wenden uns an den Security Server, indem wir den UPN und das Kennwort als typische Aktivierungsanforderung weitergeben.
  2. Auf Seiten des Servers:
    • Wir erhalten die Aktivierungsanfrage. Wir wenden uns an Active Directory und suchen den UPN. Anschließend wird die/der NutzerIn selektiert. Im Rahmen dieses Selektierungsprozesses stellen wir fest, dass die SID in der Entitätstabelle nicht mit der SID in AD übereinstimmt. Wir untersuchen den SIDHistory , um in unserer Entitätstabelle nach der SID zu suchen. Wenn wir sie nicht finden, geben wir eine Ausnahme aus und die Aktivierung schlägt fehl, da diese SCID bereits vorhanden ist. Wenn wir die SID finden, aktualisieren wir die Entitätstabelle mit der neuen SID (im UID-Teil ist der erste Teil die Domain und wir aktualisieren sie und aktualisieren den Endpunkt-Domainteil).
    • Dann leiten wir die alten Schlüssel, die Policy, die DCID usw. an den Client weiter (wie bei einer Reaktivierung).
  3. Zurück auf dem Client:
    • Der Endpunkt empfängt diese Informationen und fügt einen Eintrag in der Datei credsys.vlt hinzu, dass die/der NutzerIn aktiviert ist und die/der NutzerIn zu diesem Zeitpunkt normal angemeldet ist.

Ein wichtiger Punkt auf der Seite von Dell Security Management Server ist es, zu verstehen, ob eine neue Domain unter der WebUI hinzugefügt werden muss, damit Prozesse mit neuen und alten NutzerInnen beim Aktivieren oder Reaktivieren funktionieren.

Bei einer Domainmigration fügen wir die neue Domain nicht zur Dell Security Management Server-Konsole hinzu, WENN die übergeordnete Root-Domain der alten und neu migrierten Domain vorhanden ist. Es reicht aus, die neue Domain in Form eines Alias unter dem Abschnitt „Einstellungen“, „Domainaliasliste“ hinzuzufügen. (Und wir gehen davon aus, dass eine bidirektionale Vertrauensstellung zwischen der übergeordneten und der neuen untergeordneten Domain vorhanden ist.) Das Servicekonto für die Root-Domain sollte möglicherweise in der übergeordneten Domain eingerichtet werden. Wenn wir stattdessen die Domain A.local zu B.local migrieren und die beiden Domains nicht untergeordnete Domains derselben Root-Domain sind oder zu einer anderen Gesamtstruktur gehören, benötigen wir eine neue Domain, die unter unserer Konsole hinzugefügt wird, da wir alle vorhandenen Endpunkte an die neue Domain und ein neues Servicekonto binden müssen.

Es ist sehr wichtig, die oben genannten Punkte bei der korrekten Konfiguration von Dell Security Management Server zu verstehen, da andernfalls mehrere Probleme nach der Migration auftreten. Essenziell ist es außerdem, zu verstehen, welche Art von Vertrauen zwischen diesen Domains und ihren Root-Domains (falls vorhanden) und der Liste ihrer aktuellen Domains unter der Dell Security Management Server-Konsole vorhanden ist. Grundsätzlich gilt, wenn Sie eine Art von Vertrauensstellung zwischen der übergeordneten/untergeordneten Domain haben, genügt es, wenn unter Dell Data Protection | Enterprise Edition-Server die Root-Domain und die Aliasnamen vorhanden sind. Andernfalls müssen wir so viele untergeordnete Domains unter Dell Security Management Server wie ihre echten Subdomains hinzufügen, und diese Regel gilt auch für die Domänenmigration.

Allgemein sollten *niemals* gleichzeitig eine untergeordnete und übergeordnete Domain hinzugefügt werden, da das Vorhandensein desselben potenziell sichtbaren Nutzerkontos auf beiden Ebenen, uns Probleme verursacht. Das Entfernen von Domains ist (noch) keine vollständig unterstützte Aufgabe auf der Seite des Dell Security Management Server.

Wenn der Client Version 8.2.1 oder früher und der Server Version 8.3.1 oder höher ist, ist WSDeactivate ein erforderlicher Schritt, da wir den Teil der Endpunkt-Domain auf der Serverseite nicht automatisch umbenannt haben. Dies gilt nicht für die neuesten Builds unseres Dell Security Management Servers oder Endpunkts.

Alte Domains können nicht manuell oder über die Konsole aus der Datenbank von Dell Security Management Server entfernt werden. Dies liegt daran, dass Dell Security Management Server eine/einen NutzerIn oder eine Gruppe sucht und dann feststellt, dass es sich um eine Domainmitgliedschaft handelt. Aus diesem Grund müssen alle Objekte, die Teil dieser Domain sind, entfernt werden, wenn eine Domain entfernt wird. Zu diesem Zeitpunkt wird keine dieser Optionen unterstützt. Dell arbeitet derzeit daran, dieses Verhalten in zukünftigen Builds von Dell Security Management Server zu ändern, obwohl dies zu diesem Zeitpunkt keine unterstützte oder praktikable Aufgabe ist. Wenn wir die Domain als entfernt in der Datenbank markieren möchten (manuell), erhalten wir einen Fehler, der alle 15 Minuten für alle zugehörigen verwaisten NutzerInnen und Gruppen in die Serverprotokolle ausgegeben wird.

Sollte Shield auf einem migrierten Endpunkt deinstalliert werden, sind hier dieselben Schritte erforderlich, die erforderlich sind, um eine normale (Nicht-Domain-)Reaktivierung für dieselbe Shield-ID durchzusetzen. In allgemein verschlüsselten Dateien müssen wir dieselbe DCID in der Registrierung erzwingen, bevor der Endpunkt für den Dell Data Protection | Enterprise Edition Server oder Dell Security Management Server reaktiviert werden kann. Wenn Sie Fragen haben, wenden Sie sich an das Team des technischen Supports, um weitere Hilfe zu erhalten.

Nein, eine neue Domainlizenz ist ab Dell Data Protection | Enterprise Edition Server 8.x nicht erforderlich. Bei einer älteren Version von Dell Data Protection | Enterprise Edition Server ist eine neue Lizenz weiterhin erforderlich. Wenden Sie sich an das Team des technischen Supports, um weitere Informationen zu erhalten.


Nutzen Sie zur Kontaktaufnahme mit dem Support die internationalen Support-Telefonnummern von Dell Data Security.
Gehen Sie zu TechDirect, um online eine Anfrage an den technischen Support zu erstellen.
Zusätzliche Einblicke und Ressourcen erhalten Sie im Dell Security Community Forum.

Affected Products

Dell Encryption
Article Properties
Article Number: 000178442
Article Type: How To
Last Modified: 02 Jul 2024
Version:  13
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.