Kennzeichnen eines Attributs als vertraulich in Windows Server 2003 Service Pack 1

In diesem Artikel wird beschrieben, wie Sie ein Attribut in Windows Server 2003 Service Pack 1 als vertraulich markieren.

Gilt für: Windows Server 2003
Ursprüngliche KB-Nummer: 922836

Zusammenfassung

Im Active Directory-Verzeichnisdienst für Microsoft Windows Server 2000 und Microsoft Windows Server 2003 ist es schwierig, zu verhindern, dass ein authentifizierter Benutzer ein Attribut liest. Wenn der Benutzer READ_PROPERTY Berechtigungen für ein Attribut oder dessen Eigenschaftensatz anfordert, wird im Allgemeinen Lesezugriff gewährt. Die Standardsicherheit in Active Directory ist so festgelegt, dass authentifizierte Benutzer Lesezugriff auf alle Attribute haben. In diesem Artikel wird erläutert, wie Sie den Lesezugriff für ein Attribut in Windows Server 2003 Service Pack 1 (SP1) verhindern.

Weitere Informationen

Windows Server 2003 SP1 führt eine Möglichkeit ein, ein Attribut als vertraulich zu kennzeichnen. Dazu ändern Sie den Wert des attributs searchFlags im Schema. Der searchFlags-Attributwert enthält mehrere Bits, die verschiedene Eigenschaften eines Attributs darstellen. Wenn beispielsweise Bit 1 festgelegt ist, wird das Attribut indiziert. Bit 7 (128) bezeichnet das Attribut als vertraulich.

Anforderungen und Einschränkungen

Nur Domänencontroller mit Windows Server 2003 SP1 oder einer höheren Version erzwingen die Lesezugriffsprüfung für vertrauliche Attribute. Das Feature für vertrauliche Attribute ist an die Installation von Windows Server 2003 SP1 oder einer höheren Version gebunden. Dieses Feature hängt nicht davon ab, ob eine Domäne oder eine Gesamtstrukturfunktionsebene aktiviert ist.

Verwenden Sie das Feature für vertrauliche Attribute nur, wenn die folgenden Bedingungen erfüllt sind:

• Auf allen Windows Server 2003-basierten Domänencontrollern ist Windows Server 2003 SP1 oder eine höhere Version installiert.

• Alle Windows 2000-basierten Domänencontroller wurden aktualisiert oder entfernt. Wenn eine Domäne eine Mischung aus Domänencontrollern enthält, auf denen Windows 2000 Server, die ursprüngliche Version von Windows Server 2003 und Windows Server 2003 SP1 ausgeführt wird, kann das folgende Szenario auftreten:

• Wenn ein nicht autorisierter Client die Windows 2000 Server- und Windows Server 2003-basierten Domänencontroller nach vertraulichen Attributdaten fragt, kann der Client die Daten lesen.

• Wenn ein nicht autorisierter Client den Windows Server 2003 SP1-basierten Domänencontroller nach vertraulichen Attributdaten fragt, kann der Client die Daten nicht lesen. Sie können ein Basisschema-Attribut nicht als vertraulich markieren. Eine Mitarbeiter-ID ist ein Beispiel für ein Basisschema-Attribut. Dieses Attribut kann nicht als vertraulich markiert werden, da sein systemFlags-Attributwert auf 0x10 (Basisschema) festgelegt ist. Weitere Informationen finden Sie im Abschnitt "Bestimmen, ob ein Attribut ein Basisschema-Attribut ist" und im Abschnitt "Bestimmen des searchFlags-Attributwerts bei Verwendung eines vorhandenen Attributs".

Testen

Da Sie änderungen an Active Directory und jeder Schemaerweiterung testen würden, empfehlen wir Ihnen, Attributänderungen in einem Lab, das Ihre Produktionsgesamtstruktur widerspiegelt, gründlich zu testen. Tests tragen dazu bei, dass das Verfahren reibungslos funktioniert und Probleme erkannt werden.

Zugriffssteuerungsprüfungen

Nachdem Windows Server 2003 SP1 installiert wurde und Active Directory eine Lesezugriffsprüfung durchgeführt hat, sucht Active Directory nach vertraulichen Attributen. Wenn vertrauliche Attribute vorhanden sind und READ_PROPERTY Berechtigungen für diese Attribute festgelegt sind, benötigt Active Directory auch CONTROL_ACCESS Berechtigungen für die Attribute oder deren Eigenschaftensätze.

Active Directory führt in den folgenden Fällen eine Lesezugriffsprüfung für ein Objekt durch:

• Wenn Sie auswerten, ob das Objekt mit dem Suchfilter übereinstimmt.
• Wenn Sie Attribute eines Objekts zurückgeben, die dem Suchfilter entsprechen. Standardmäßig verfügen nur Administratoren über CONTROL_ACCESS Berechtigungen für alle Objekte. Daher können nur Administratoren vertrauliche Attribute lesen. Administratoren können diese Berechtigungen an jeden Benutzer oder eine beliebige Gruppe delegieren.

Generische und objektspezifische Zugriffssteuerungseinträge

Jedem Objekt in Active Directory sind Zugriffssteuerungsinformationen zugeordnet. Diese Informationen werden als Sicherheitsbeschreibung bezeichnet. Der Sicherheitsdeskriptor steuert die Art des Zugriffs, der Benutzern und Gruppen zur Verfügung steht. Der Sicherheitsdeskriptor wird automatisch erstellt, wenn das Objekt erstellt wird.

Der Satz von Berechtigungseinträgen in einem Sicherheitsdeskriptor wird als DACL (Discretionary Access Control List) bezeichnet. Jeder Berechtigungseintrag in der DACL wird als Zugriffssteuerungseintrag (Access Control Entry, ACE) bezeichnet.

Sie können berechtigungen für das Objekt oder CONTROL_ACCESS Berechtigungen für vertrauliche Attribute erteilen, indem Sie einen generischen oder objektspezifischen Zugriffssteuerungseintrag für das Objekt verwenden. Sie können Berechtigungen erteilen, indem Sie sie explizit für das Objekt stempeln oder vererbung verwenden. Vererbung bedeutet, dass Sie einen vererbbaren Zugriffssteuerungseintrag für einen Container festlegen, der in der Containerhierarchie höher ist.

Generische und objektspezifische Zugriffssteuerungseinträge sind im Grunde identisch. Was sie unterscheidet, ist der Grad der Kontrolle, den die Zugriffssteuerungseinträge für die Vererbung und den Zugriff auf Objekte bieten. Generische Zugriffssteuerungseinträge gelten für das gesamte Objekt. Objektspezifische Zugriffssteuerungseinträge bieten mehr Kontrolle darüber, welche Objekte den Zugriffssteuerungseintrag erben. Wenn Sie einen objektspezifischen Zugriffssteuerungseintrag verwenden, können Sie das Attribut oder den Eigenschaftensatz des Objekts angeben, das den Zugriffssteuerungseintrag erbt.

Wenn Sie das Feature "Vertrauliche Attribute" verwenden, wird CONTROL_ACCESS Berechtigung erteilt, indem einem Benutzer ein generischer Zugriffssteuerungseintrag zugewiesen wird. Wenn CONTROL_ACCESS Berechtigung durch Zuweisen eines objektspezifischen Zugriffssteuerungseintrags erteilt wird, verfügt der Benutzer nur über CONTROL_ACCESS Berechtigung für das confidential-Attribut.

Die folgenden Berechtigungen werden gewährt, wenn Sie einen generischen Zugriffssteuerungseintrag verwenden:

• Alle erweiterten Rechte
• Zulässig zur Authentifizierung
• Kennwort ändern
• Empfangen als
• Kennwort zurücksetzen
• Senden als

Berechtigungen, die gewährt werden, wenn Sie einen generischen Zugriffssteuerungseintrag verwenden, bieten möglicherweise mehr Zugriff als gewünscht für das gesamte Objekt. Wenn dies ein Problem ist, können Sie einen objektspezifischen Zugriffssteuerungseintrag für das Objekt festlegen, sodass der Zugriffssteuerungseintrag nur für das vertrauliche Attribut gilt. Wenn Sie objektspezifische Zugriffssteuerungseinträge verwenden, können Sie die Eigenschaft oder den Eigenschaftensatz steuern, für die der Zugriffssteuerungseintrag gilt.

Die Benutzeroberfläche in Windows Server 2003 macht keine Control_Access Berechtigungen verfügbar. Sie können das tool Dsacls.exe verwenden, um Control_Access Berechtigungen festzulegen, indem Sie einen generischen Zugriffssteuerungseintrag zuweisen. Sie können dieses Tool jedoch nicht verwenden, um einen objektspezifischen Zugriffssteuerungseintrag zuzuweisen. Das einzige Tool, das Control_Access Berechtigungen durch Zuweisen eines objektspezifischen Zugriffssteuerungseintrags festlegen kann, ist das Ldp.exe-Tool.

Verwenden der Vererbung

In einer großen Domäne ist es nicht praktisch, einem Benutzer oder einer Gruppe manuell steuerungszugriff für jedes Objekt zuzuweisen, das über ein vertrauliches Attribut verfügt. Die Lösung besteht darin, die Vererbung zu verwenden, um einen vererbbaren Zugriffssteuerungseintrag festzulegen, der in der Containerhierarchie höher ist. Dieser Zugriffssteuerungseintrag gilt für alle untergeordneten Objekte dieses Containers.

Standardmäßig ist die Vererbung für alle Organisationseinheiten (OE) und für alle Benutzerkonten mit Ausnahme des integrierten Administratorkontos aktiviert. Wenn Sie Benutzerkonten erstellen, für die die Vererbung deaktiviert ist, oder wenn Sie Administratorkonten durch Kopieren des integrierten Administratorkontos erstellen, müssen Sie die Vererbung für diese Konten aktivieren. Andernfalls gilt das Vererbungsmodell nicht für diese Konten.

Erstellen eines vertraulichen Attributs

1. Bestimmen Sie, welches Attribut als vertraulich gekennzeichnet werden soll, oder fügen Sie ein Attribut hinzu, das Sie vertraulich machen möchten.
2. Erteilen Sie den entsprechenden Benutzern Control_Access Berechtigungen, damit die Benutzer die Attributdaten anzeigen können.

Tools wie das Ldp.exe-Tool und das Tool Adsiedit.msc können verwendet werden, um ein vertrauliches Attribut zu erstellen. LDF-Dateien werden in der Regel verwendet, um das Schema zu erweitern. Diese Dateien können auch verwendet werden, um ein Attribut als vertraulich zu kennzeichnen. Die Dateien, die Sie für eine Implementierung erstellen, sollten während der Testphase optimiert werden, damit Sie genau wissen, was Sie dem Schema beim Rollout in der Produktion hinzufügen. LDF-Dateien verhindern Fehler.

Die folgenden LDF-Beispieldateien können für folgende Aktionen verwendet werden:

• Hinzufügen eines Attributs zum Schema
• Kennzeichnen des Attributs als vertraulich
• Hinzufügen des Attributs zur Benutzerklasse

LDF-Beispieldateien

Der folgende Code fügt dem Schema ein Attribut hinzu und markiert das Attribut dann als vertraulich.

dn: CN=ConfidentialAttribute-LDF,CN=Schema,Cn=Configuration,DC=domain,DC=com
changetype: add
objectClass: attributeSchema
lDAPDisplayName: ConfidentialAttribute
adminDescription: Dieses Attribut speichert die vertraulichen Daten des Benutzers.
attributeID: 1.2.840.113556.1.xxxx.xxxx.1.x
attributeSyntax: 2.5.5.12
oMSyntax: 64
isSingleValued: TRUE
showInAdvancedViewOnly: TRUE
searchFlags: 128

Dn:
changeType: modify
add: schemaupdatenow
schemaupdatenow: 1
-

Der folgende Code fügt der Benutzerklasse das neue Attribut hinzu.

dn: CN=User,CN=Schema,CN=Configuration,DC=domain,DC=com
changetype: modify
add: mayContain
mayContain: ConfidentialAttribute
-

Dn:
changeType: modify
add: schemaupdatenow
schemaupdatenow: 1
-

So können Benutzer, die keine Administratoren sind, die Attributdaten anzeigen

Manuelles Festlegen von Control_Access Berechtigungen für ein Benutzerkonto

1. Öffnen Sie das Ldp.exe-Tool, das in Windows Server 2003 R2 ADAM enthalten ist.
2. Stellen Sie eine Verbindung her, und binden Sie es an das Verzeichnis.
3. Wählen Sie ein Benutzerkonto aus, klicken Sie mit der rechten Maustaste auf das Konto, klicken Sie auf Erweitert, klicken Sie auf Sicherheitsbeschreibung, und klicken Sie dann auf OK.
4. Klicken Sie im Feld DACL auf ACE hinzufügen.
5. Geben Sie im Feld Treuhänder den Gruppennamen oder den Benutzernamen ein, dem Sie Berechtigungen erteilen möchten.
6. Überprüfen Sie im Feld Zugriff steuern die Änderungen, die Sie in Schritt 5 vorgenommen haben.

Verwenden der Vererbung zum Zuweisen von Control_Access Berechtigungen

Um die Vererbung zu verwenden, erstellen Sie einen Zugriffssteuerungseintrag, der den gewünschten Benutzern oder Gruppen Control_Access Berechtigungen gewährt, die in der Containerhierarchie höher sind als die Objekte mit vertraulichen Attributen. Sie können diesen Zugriffssteuerungseintrag auf Domänenebene oder an einer beliebigen Stelle in der Containerhierarchie festlegen, die für ein Unternehmen gut geeignet ist. Für die untergeordneten Objekte mit vertraulichen Attributen muss die Vererbung aktiviert sein.

Führen Sie die folgenden Schritte aus, um Control_Access Berechtigungen zuzuweisen:

1. Öffnen Sie die Ldp.exe Datei, die in Windows Server 2003 R2 ADAM enthalten ist.

2. Stellen Sie eine Verbindung her, und binden Sie es an ein Verzeichnis.

3. Wählen Sie eine Organisationseinheit oder einen Container aus, die höher in der Containerhierarchie als die Objekte mit vertraulichen Attributen ist, klicken Sie mit der rechten Maustaste auf die Organisationseinheit oder den Container, klicken Sie auf Erweitert, klicken Sie auf Sicherheitsbeschreibung, und klicken Sie dann auf OK.

4. Klicken Sie im Feld DACL auf ACE hinzufügen.

5. Geben Sie im Feld Treuhänder den Gruppennamen oder den Benutzernamen ein, dem Sie Berechtigungen erteilen möchten.

6. Überprüfen Sie im Feld Zugriff steuern die Änderungen, die Sie in Schritt 5 vorgenommen haben.

7. Klicken Sie im Feld Objekttyp auf das vertrauliche Attribut, das Sie hinzugefügt haben.

8. Stellen Sie sicher, dass die Vererbung für die Zielobjekte aktiviert ist.

Ermitteln des systemFlags-Attributwerts bei Verwendung eines vorhandenen Attributs

Wenn Sie ein vorhandenes -Objekt verwenden, müssen Sie den aktuellen searchFlags-Attributwert überprüfen. Wenn Sie ein Objekt hinzufügen, können Sie den Wert definieren, wenn Sie das Objekt hinzufügen. Es gibt viele Möglichkeiten, den SearchFlags-Attributwert abzurufen. Verwenden Sie die Methode, die für Sie am besten geeignet ist.

Führen Sie die folgenden Schritte aus, um das tool Ldp.exe zum Abrufen des searchFlags-Attributwerts zu verwenden:

1. Klicken Sie auf Start, klicken Sie auf Ausführen, geben Sie LDP ein, und klicken Sie dann auf OK.

2. Klicken Sie auf Verbindung und dann auf Binden.

3. Binden Sie als Administrator der Stammdomäne oder binden Sie als Konto, das ein Unternehmensadministrator ist.

4. Klicken Sie auf Ansicht und dann auf Struktur.

5. Klicken Sie auf CN=schema,cn=configuration,dc=rootdomain, und klicken Sie dann auf OK.

6. Erweitern Sie im linken Bereich CN=schema,cn=configuration,dc=rootdomain.

7. Suchen Sie den Domänennamen des Attributs, das Sie als vertraulich markieren möchten, und erweitern Sie ihn dann.

8. Suchen Sie in der Liste der Attribute, die für das Objekt aufgefüllt werden, nach searchFlags , um den aktuellen searchFlags-Attributwert für dieses Objekt zu bestimmen.

Bestimmen, ob ein Attribut ein Basisschema-Attribut ist

Um zu bestimmen, ob ein Attribut ein Basisschema-Attribut ist, verwenden Sie das Ldp.exe Tool, um den SystemFlags-Attributwert zu untersuchen.

LDP-Ausgabe von Employee-ID - systemFlags: 0x10 = (FLAG_SCHEMA_BASE_OBJECT)

Im folgenden Beispiel Ldp.exe Ausgabe identifiziert Ldp.exe den SystemFlags-Attributwert als 0x10 und als Basisschema-Attribut. Daher können Sie dieses Attribut nicht als vertraulich markieren.

>> Dn: CN=Employee-ID,CN=Schema,CN=Configuration,DC=domain,DC=com
2> objectClass: top; attributeSchema;
1> cn: Mitarbeiter-ID;
1> distinguishedName: CN=Employee-ID,CN=Schema,CN=Configuration,DC=domain,DC=com;
1> instanceType: 0x4 = ( IT_WRITE);
1> whenCreated: <DateTime>;
1> whenChanged: <DateTime>;
1> uSNCreated: 220;
1> attributID: 1.2.840.113556.1.4.35;
1> attributSyntax: 2.5.5.12 = ( SYNTAX_UNICODE_TYPE );
1> isSingleValued: TRUE;
1> rangeLower: 0;
1> RangeUpper: 16;
1> uSNChanged: 220;
1> showInAdvancedViewOnly: TRUE;
1> adminDisplayName: Mitarbeiter-ID;
1> adminDescription: Employee-ID;
1> oMSyntax: 64 = ( OM_S_UNICODE_STRING );
1> searchFlags: 0x0 = ( );
1> lDAPDisplayName: employeeID;
1> Name: Mitarbeiter-ID;
1> objectGUID: 64fb3ed1-338f-466e-a879-595bd3940ab7;
1> schemaIDGUID: bf967962-0de6-11d0-a285-00aa003049e2;
1> SystemOnly: FALSE;
1> systemFlags: 0x10 = ( FLAG_SCHEMA_BASE_OBJECT);
1> objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=domain,DC=com;

LDP-Ausgabe von Employee-Number systemFlags: 0x0 = ( )

Im folgenden Beispiel Ldp.exe Ausgabe identifiziert Ldp.exe den SystemFlags-Attributwert als 0. Dieses Attribut kann als vertraulich markiert werden.

>> Dn: CN=Employee-Number,CN=Schema,CN=Configuration,DC=warrenw,DC=com
2> objectClass: top; attributeSchema;
1> cn: Mitarbeiternummer;
1> distinguishedName: CN=Employee-Number,CN=Schema,CN=Configuration,DC=warrenw,DC=com;
1> instanceType: 0x4 = ( IT_WRITE);
1> whenCreated: <DateTime>;
1> whenChanged: <DateTime>;
1> uSNCreated: 221;
1> attributID: 1.2.840.113556.1.2.610;
1> attributSyntax: 2.5.5.12 = ( SYNTAX_UNICODE_TYPE );
1> isSingleValued: TRUE;
1> rangeLower: 1;
1> RangeUpper: 512;
1> mAPIID: 35943;
1> uSNChanged: 221;
1> showInAdvancedViewOnly: TRUE;
1> adminDisplayName: Mitarbeiternummer;
1> adminDescription: Employee-Number;
1> oMSyntax: 64 = ( OM_S_UNICODE_STRING );
1> searchFlags: 0x0 = ( );
1> lDAPDisplayName: employeeNumber;
1> Name: Mitarbeiternummer;
1> objectGUID: 2446d04d-b8b6-46c7-abbf-4d8e7e1bb6ec;
1> schemaIDGUID: a8df73ef-c5ea-11d1-bbcb-0080c76670c0;
1> SystemOnly: FALSE;
1> SystemFlags: 0x0 = ( );
1> objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=warrenw,DC=com;

Objektbezeichner

Wenn Sie dem Schema ein Attribut oder ein Klassenobjekt hinzufügen, ist eines der erforderlichen Attribute der Objektbezeichner (auch als OID bezeichnet). Objektbezeichner werden verwendet, um Objektklassen und Attribute eindeutig zu definieren. Stellen Sie sicher, dass Ihr Unternehmen einen eindeutigen Objektbezeichner erhält, um sein Attribut zu identifizieren. Tools, die Objektbezeichner generieren, z. B. das Oidgen.exe-Tool, werden nicht unterstützt. Besuchen Sie die folgende Microsoft-Website, um einen Objektbezeichner von Microsoft abzurufen:
Abrufen eines Objektbezeichners von Microsoft

Attributsyntax

Das attributSyntax ist auch erforderlich, um dem Schema neue Objekte hinzuzufügen. Dieses Attribut definiert die Speicherdarstellung, Bytereihenfolge und Abgleichsregeln für Vergleiche von Eigenschaftstypen. Die Syntax definiert, ob der Attributwert eine Zeichenfolge, eine Zahl oder eine Zeiteinheit sein muss. Jedes Attribut jedes Objekts ist genau einer Syntax zugeordnet. Stellen Sie sicher, dass Sie die richtige Attributsyntax für das neue Attribut auswählen. Dies ist besonders wichtig, wenn Sie ein LDAP-Verzeichnis (Lightweight Directory Access Protocol) mit einem anderen LDAP-Verzeichnis synchronisieren. Nachdem das Attribut dem Schema hinzugefügt wurde, kann seine Attributsyntax nicht mehr geändert werden.

Weitere Informationen zum attributSyntax-Attribut finden Sie unter Attribut-Syntax-Attribut.

Weitere Informationen finden Sie im Search-Flags-Attribut .