Wo speichere ich vertrauliche Daten in Active Directory?

Ich speichere im Wesentlichen einen privaten Schlüssel (Hash) in einem der OctetString-Attribute in Active Directory.

Meine Frage ist, welches Attribut standardmäßig sicher ist und es sinnvoll ist, private Daten dort zu speichern. Dieser Wert sollte als ähnlich wie ein Kennwort angesehen werden, bei dem auch Administratoren (wenn möglich) keinen Zugriff haben sollten, genau wie das aktuelle AD-Kennwort.

Hier ist der Anfang einer Liste von Attributen, die standardmäßig in einer Windows 2008R2 + Exchange 2010-Domäne aktiviert sind.

Aktualisieren:

Kennt jemand ein Octet String-Attribut, das nicht standardmäßig allen Benutzern in der Domäne Leseberechtigungen zur Verfügung stellt? Ich möchte meinen Hash nicht öffentlich speichern und jemandem erlauben, einen Regenbogentisch basierend auf den Hashes zu erstellen.

Das Problem, mit dem die meisten Menschen beim Speichern von Daten in AD konfrontiert sind, ist

• Erweiterung des Schemas (was häufig unternehmenspolitische Auswirkungen hat)

• Verwenden eines vorhandenen Attributs und Bearbeiten der Berechtigungen (was zu einem Aufblähen von AD / ACL führt, das Ihre DIT und die nachfolgende Replikationsgröße erhöht)

Es gibt eine Alternative ... Ich denke, die beste Wahl ist, diese weniger bekannte Funktion von AD zu verwenden, um ein vorhandenes Attribut zu übernehmen und es als vertraulich zu kennzeichnen.

Hier finden Sie Details zum Prozess

Die Standardberechtigungen in Active Directory sind so, dass authentifizierte Benutzer pauschalen Lesezugriff auf alle Attribute haben. Dies macht es schwierig, ein neues Attribut einzuführen, das vor dem Lesen durch alle geschützt werden sollte.

Um dies zu vermeiden, bietet Windows 2003 SP1 eine Möglichkeit, ein Attribut als VERTRAULICH zu markieren. Diese Funktion wird durch Ändern des searchFlags-Werts für das Attribut im Schema erreicht. SearchFlags enthält mehrere Bits, die verschiedene Eigenschaften eines Attributs darstellen. ZB Bit 1 bedeutet, dass das Attribut indiziert ist. Das neue Bit 128 (7. Bit) bezeichnet das Attribut als vertraulich.

Hinweis: Sie können dieses Flag nicht für Basisschemaattribute setzen (solche, die von "top" abgeleitet sind, z. B. "Common-Name"). Sie können feststellen, ob ein Objekt ein Basisschemaobjekt ist, indem Sie das Objekt mithilfe von LDP anzeigen und das systemFlags-Attribut des Objekts überprüfen. Wenn das 10. Bit gesetzt ist, handelt es sich um ein Basisschemaobjekt.

Wenn der Verzeichnisdienst eine Lesezugriffsprüfung durchführt, sucht er nach vertraulichen Attributen. Wenn dies der Fall ist, benötigt der Verzeichnisdienst zusätzlich zum Zugriff auf READ_PROPERTY auch den Zugriff auf das Attribut oder seinen Eigenschaftssatz CONTROL_ACCESS.

Standardmäßig haben nur Administratoren CONTROL_ACCESS-Zugriff auf alle Objekte. Daher können nur Administratoren vertrauliche Attribute lesen. Es steht den Benutzern frei, dieses Recht an eine bestimmte Gruppe zu delegieren, die sie möchten. Dies kann mit dem DSACL-Tool, Scripting oder der R2 ADAM-Version von LDP erfolgen. Zum jetzigen Zeitpunkt ist es nicht möglich, den ACL UI Editor zum Zuweisen dieser Berechtigungen zu verwenden.

Das Markieren eines Attributs als vertraulich und das Hinzufügen der Benutzer, die das Attribut anzeigen müssen, umfasst drei Schritte

1. Bestimmen, welches Attribut als vertraulich markiert werden soll, oder Hinzufügen eines Attributs zum Markieren von vertraulich.

2. Vertraulich markieren

3. Gewähren Sie den richtigen Benutzern das Control_Access-Recht, damit sie das Attribut anzeigen können.

Weitere Einzelheiten und schrittweise Anleitungen finden Sie im folgenden Artikel:

922836 So markieren Sie ein Attribut in Windows Server 2003 Service Pack 1 als vertraulich

http://support.microsoft.com/default.aspx?scid=kb;EN-US;922836

Zu diesem Zweck können Sie das Active Directory jederzeit um ein neues Feld erweitern.

Hier ist ein Dokument , das Anweisungen zum Hinzufügen eines neuen Attributs und zum Einschränken der Berechtigungen für das Attribut enthält.

Dieser Wert sollte als ähnlich wie ein Kennwort angesehen werden, bei dem auch Administratoren (wenn möglich) keinen Zugriff haben sollten, genau wie das aktuelle AD-Kennwort.

Das ist nicht richtig, es ist nicht einmal falsch. Das Passwort wird nicht gespeichert. Der Hash wird gespeichert, und Domänenadministratoren können darauf zugreifen. Sie können AD sogar so konfigurieren, dass das Kennwort in einer reversiblen Verschlüsselung gespeichert wird, wenn Sie dies möchten.

In AD gibt es nichts, von dem Sie Domain-Administratoren fernhalten können. Wenn Sie Rechte entfernen oder sogar verweigern, kann ein Domain-Administrator das Eigentum übernehmen und sich wieder hinzufügen. Dies steht im Gegensatz zu Novells NDS, bei dem ein Administrator einer Organisationseinheit Administratoren höherer Ebenen unwiderruflich aussperren könnte.

Das Beste, was Sie tun können, ist, ein vorhandenes oder neues Attribut zu verwenden und den Zugriff einzuschränken. Sie können Administratoren davon abhalten und die Überwachung des Attributs aktivieren, damit alle Zugriffs- oder Berechtigungsänderungen protokolliert werden.