Windows-Verwaltung

Erweitern des Active Directory-Schemas

Vikas Malhotra

Kurz zusammengefasst:

• Grundlagen des standardmäßigen Active Directory-Schemas
• Hinzufügen von classSchema- oder attributeSchema-Objekten
• Abrufen und Verwenden von Objektbezeichnern
• Erweitern des Schemas mithilfe von .ldif-Dateien

Laden Sie den Code für diesen Artikel herunter: Schema2008_05.exe (151KB)

Seit der Einführung von Active Directory mit der Veröffentlichung von Windows 2000 hat Microsoft für Kunden die Basisschemadefinition zum Implementieren von Active Directory bereitgestellt.

Der Einsatz von Active Directory® hat auch eine Änderung bei der Entwicklung und Implementierung zahlreicher Anwendungen unter Windows® bewirkt. Bis zu diesem Zeitpunkt verfügten Anwendungen wie Microsoft® Exchange 5.5 über ihre eigene Verzeichnisstruktur. Mit der Einführung von Active Directory nutzten zahlreiche Anwendungen (sowohl von Microsoft als auch von anderen Unternehmen) die Vorteile der zugrunde liegenden Struktur von Active Directory, statt ein eigenes Schema neu zu entwickeln.

Diese Anwendungen nutzten die grundlegende Architektur von Active Directory und erweiterten sie nach Bedarf. Microsoft Exchange 2000 verwendet Active Directory z. B. zur Implementierung von Messaging, was zur Definition der zukünftigen Messagingarchitektur von Microsoft geführt hat.

Heute sind zahlreiche Anwendungen, die für die Verwendung in einer Active Directory-Umgebung entwickelt wurden, für ihr Funktionieren vom zugrunde liegenden Schema abhängig und definieren die eigenen Änderungen basierend auf dem Schema. Dies setzt natürlich ein erweiterbares Schema voraus, wie ich in diesem Artikel erläutern werde. Darüber hinaus ist die kontinuierliche Stabilität des Hauptschemas unerlässlich, da zahlreiche Anwendungen von den grundlegenden Definitionen in Active Directory abhängen. Da viele Anwendungen nebeneinander im gleichen Active Directory ausgeführt werden, muss es möglich sein, Änderungen für eine Anwendung vorzunehmen, die sich nicht auf andere Anwendungen auswirken.

Was ist ein Schema?

Für viele ist das Active Directory-Schema ein Buch mit sieben Siegeln, und viele würden sich nicht trauen, eine eigene Änderung des Schemas vorzunehmen. Eine Erweiterung des Active Directory-Schemas muss natürlich nicht jeden Tag vorgenommen werden, bestimmte Anwendungen oder Geschäftsanforderungen können dies jedoch erforderlich machen. Es ist daher wichtig zu wissen, was genau ein Schema ist und welche Komponenten in einem Schema enthalten sind, da es sich bei Active Directory um eine wichtige Ressource in vielen Organisationen handelt. Eine fehlerhafte Funktion von Active Directory aufgrund einer nicht korrekten Aktualisierung kann daher schwerwiegende Auswirkungen haben.

Viele Organisationen erwägen als Strategie den Einsatz von Active Directory Lightweight Directory Service (ADLDS) in Windows Server® 2008 (oder Active Directory Application Mode, ADAM, unter Windows Server 2003) als Alternative zum Testen oder zur direkten Implementierung der angepassten Schemadefinitionen statt der Erweiterung des Active Directory-Schemas.

Bei einem Schema handelt es sich um die zugrunde liegende Struktur, die das Format für einen Verzeichnisdienst bereitstellt. Das Active Directory-Schema definiert die Objektklassen und Attribute, die in Active Directory Domain Services (ADDS) verwendet werden. Das Hauptschema bietet Definitionen für viele bekannte Klassen (z. B. user, computer und organizationalUnit) und Attribute (z. B. telephoneNumber und objectSID). Die Objekte in der Hauptschemadefinition werden als Objekte der Kategorie 1 und Objekte, die hinzugefügt werden, als Objekte der Kategorie 2 bezeichnet.

Ein Active Directory-Schema befindet sich im Container, der unter dem Pfad „cn=Schema,cn=Configuration,dc=X“ definiert ist, wobei es sich bei X um den Namespace der Active Directory-Struktur handelt. Beachten Sie, dass eine Active Directory-Struktur lediglich ein Schema enthält. Änderungen der Schemadefinition in einer Struktur wirken sich auf alle Domänen in der Struktur aus. Abbildung 1 zeigt die Anzahl an Klassen und Attributen, die dem Active Directory-Schema in verschiedenen Versionen von Windows Server hinzugefügt sind.

Figure 1 Anzahl an Klassen und Attributen

Die Aktualisierung des Schemas für verschiedene Versionen von Windows Server wird über ein Dienstprogramm namens „Adprep“ durchgeführt. Über die Updates für Windows Server 2003 R2 wird die Schemaversion auf 31 und über Windows Server 2008 auf 44 aktualisiert.

Dies kann überprüft werden, indem der Wert des Attributs „objectVersion“ in cn=Schema,cn=Configuration,dc=X in Ihrem Active Directory mithilfe eines Tools wie ADSIEdit geprüft wird. Beachten Sie, dass einige Anwendungen wie z. B. Exchange Server, System Management Server (SMS) oder andere Anwendungen, die auf Active Directory basieren, das Schema entsprechend der Anwendungsanforderungen ändern können.

Fakten

Active Directory verfügt über zwei Objekttypen: ClassSchema (kurz Klasse) und attributeSchema (kurz Attribut). Eine Erweiterung des Active Directory-Schemas wird in der Regel in Betracht gezogen, wenn eine Organisation Daten in bestimmten Attributen speichern möchte, die nicht im vorhandenen Schema verfügbar sind. Attribute in einem Active Directory-Schema werden erstellt, indem zuerst ein attributeSchema-Objekt im Schemacontainer festgelegt und dann die erforderlichen Eigenschaften für das neue Objekt definiert werden.

Eine Liste der Eigenschaften für das attributeSchema-Objekt sowie weitere relevante Informationen finden Sie unter go.microsoft.com/fwlink/?LinkId=110445. Es gibt zahlreiche Eigenschaften, die für attributeSchema-Objekte definiert werden können. Einige dieser Eigenschaften sind obligatorisch.

Neben den allgemeinen Attributen in einem Schema gibt es auch besondere Attribute, die als verknüpfte Attribute bezeichnet und in Paaren implementiert werden, indem diese einen Forwardlink und einen Backwardlink bereitstellen. Ein Beispiel hierfür ist die Gruppenmitgliedschaft in Active Directory. Bei dem Mitgliedsattribut einer beliebigen Gruppe (z. B. eine Gruppe namens „ContosoEmployees“ mit einem Mitglied namens John Doe) handelt es sich um den Forwardlink und bei dem entsprechenden memberOf-Attribut des Mitgliedobjekts um den Backlink (das heißt, wenn das memberOf-Attribut für John Doe abgefragt wird, wird der Distinguished Name (oder DN) der Gruppe „ContosoEmployees“ berechnet).

Der Forwardlink verhält sich wie andere Attribute. Das Attribut kann einen oder mehrere Werte enthalten (wie das Mitgliedattribut, das mehrere Objekte als Mitglieder einer Gruppe enthalten kann), und die Werte werden zusammen mit dem übergeordneten Objekt im Verzeichnis gespeichert.

Backlinks hingegen werden vom System verwaltet, um die referentielle Integrität sicherzustellen. Wenn Sie den Wert für ein Backlink-Attribut abfragen, werden die Ergebnisse aus allen relevanten Forwardlink-Werten berechnet. Backlinks verfügen immer über mehrere Werte.

Jede Objektklasse in ADDS ist über ein classSchema-Objekt im Schemacontainer definiert. Eine Liste mit Attributen, die für eine erfolgreiche Definition des classSchema-Objekts erforderlich sind, finden Sie unter go.microsoft.com/fwlink/?LinkId=110445.

Es gibt drei Klassentypen, die angegeben werden können: Strukturklassen, abstrakte Klassen und Erweiterungsklassen. Diese werden über den Wert des objectClassCategory-Attributs definiert. (Eine vierte Kategorie, die auch als 88 bekannt ist, enthält Klassen, die vor X.500-1993-Standards definiert wurden. Dieser Klassentyp wird über den Wert 0 im objectClassCategory-Attribut angegeben. Der Klassentyp sollte nicht mehr definiert werden.)

Abrufen und Verwenden von Objektbezeichnern

Die Identitäten der einzelnen classSchema- und attributeSchema-Objekte im Verzeichnis werden über einen obligatorischen Objektbezeichner (OID) definiert, der wiederum über governsID für classSchema-Objekte und attributeID für attributeSchema-Objekte definiert ist. Hierbei handelt es sich um eindeutige numerische Werte, die von bestimmten Ausgabestellen zur Identifikation von Objekten bereitgestellt werden. Die Nummerierung wird über die Definition des LDAP-Protokolls (RFC 2251) gesteuert. Einige OIDs im Active Directory-Schema werden von der International Organization for Standardization (ISO) und einige von Microsoft veröffentlicht. Ein OID muss für ein Objekt innerhalb des Verzeichnisses eindeutig sein.

Beim OID handelt es sich um eine Zeichenfolge, z. B. 1.2.840.113556.1.y.z (siehe Abbildung 2). Der OID für ein classSchema-Benutzerobjekt lautet z. B. 1.2.840.113556.1.5.9.

Figure 2 Bezeichner für das Benutzerobjekt

Wenn eine Organisation beabsichtigt, das Schema zu erweitern, wird sichergestellt, dass der OID eindeutig ist, indem die Organisation eine eigene OID-Stammnummer erhält. Die Stammnummer stellt dann eindeutige IDs für die neuen Objektklassen und Attribute bereit, die von der Organisation erstellt werden. Der OID-Stamm kann direkt über eine ISO-NRA (National Registration Authority) erlangt werden. (In den USA handelt es sich hierbei um das American National Standards Institute, ANSI.)

Informationen zum Verfahren und zu Gebühren für den Erhalt eines Stamm-OID finden Sie unter ansi.org. Wenden Sie sich in anderen Ländern an die entsprechende ISO-Organisation. Eine Liste der Organisationen finden Sie unter iso.org/iso/about/iso_members.htm.

Früher konnten Organisationen einen OID von Microsoft per e-Mail unter schemreg@microsoft.com anfordern. Dies führt jetzt jedoch zu einer automatisierten Antwort, die den anfordernden Benutzer auffordert, das VBScript unter go.microsoft.com/fwlink/?LinkId=110453 herunterzuladen und auszuführen.

Für OIDs, die von Microsoft ausgegeben werden, wird die Zahl innerhalb des Zahlenbereichs für Microsoft-OIDs zugewiesen: 1.2.840.113556.1.8000.x, wobei es sich bei x um eine eindeutige Zahl handelt, die der Organisation zugewiesen wird. Die Organisation kann die OIDs teilen, um die Objekte zu spezifizieren. Eine Organisation kann daher 1.2.840.113556.1.8000.x.1.y für neue classSchema-Objekte und 1.2.840.113556.1.8000.x.2.z für attributeSchema-Objekte verwenden (wobei es sich bei x um die eindeutige Zahl der Organisation und bei y und z um die Zahlen handelt, die bestimmten classSchema- und attributeSchema-Objekten zugewiesen sind). Es wird auch empfohlen, ein organisationsspezifisches Präfix für die Namen der Objekte zu verwenden, um diese zu unterscheiden.

Definieren verknüpfter Attribute

Es ist wichtig, dass der attributeSyntax-Wert eines Forwardlinks 2.5.5.1, 2.5.5.7 oder 2.5.5.14 ist. Diese Werte entsprechen der Syntax, die einen Distinguished Name enthält, wie z. B. die Object-Syntax (DS-DN).

Der attributeSyntax-Wert eines Backlinks muss 2.5.5.1 lauten, wobei es sich um die Object-Syntax (DS-DN) handelt. Entsprechend der Konvention werden Backlink-Attribute dem mayContain-Wert der obersten abstrakten Klasse hinzugefügt. Hiermit kann das Backlink-Attribut von Objekten beliebiger Klassen gelesen werden, da Backlink-Attribute nicht zusammen mit dem Objekt gespeichert werden. Stattdessen werden die Attribute basierend auf den Forwardlink-Attributen berechnet.

In Windows Server 2003 wurde ein Feature eingeführt, das Organisationen verwenden können, um zwei Objekte in einem Schema zu verknüpfen: Automatische Generierung von linkIDs. Mit diesem Feature generiert das System automatisch eine linkID für ein neues verknüpftes Attribut, wenn das linkID-Attribut des Attributs auf 1.2.840.113556.1.2.50 gesetzt ist. Ein entsprechender Backlink wird erstellt, indem die linkID auf die attributeId oder den ldapDisplayName des Forwardlinks abgestimmt wird. Der Schemacache muss nach dem Erstellen des Forwardlinks und vor dem Erstellen des Backlinks neu geladen werden. Ist dies nicht der Fall, wird die attributeId oder der ldapDisplayName des Forwardlinks nicht gefunden, wenn der Backlink erstellt wird. Das Neuladen des Schemacache erfolgt nach Bedarf, einige Minuten, nachdem Änderungen am Schema vorgenommen wurden oder wenn der Domänencontroller neu gestartet wird.

Wenn Ihr Active Directory unter Windows 2000 läuft, müssen linkIDs von Microsoft durch Senden einer E-Mail an schemreg@microsoft.com angefordert werden. In der automatisierten Antwort wird eine Zeile ähnlich der folgenden angezeigt: „E-Mails, die an schemreg@microsoft.com gesendet werden, werden nur bearbeitet, wenn es sich um linkID-Registrierungen für Legacyumgebungen handelt.“ Fügen Sie hierfür folgende Informationen in die E-Mail ein: Firmenname, Kontaktperson, E-Mail-Adresse, Telefonnummer, registriertes Präfix (sofern zutreffend), registrierter OID (sofern zutreffend).

Bereit zur Erweiterung des Schemas

Gehen wir davon aus, dass Sie entschieden haben, Ihr Active Directory-Schema zu erweitern. Im Rahmen der Analyse wurde die Verwendung eines alternativen Verzeichnisses über ADLDS (oder ADAM in Windows Server 2003) verworfen, nachdem festgestellt wurde, dass die Anforderungen damit nicht erfüllt wurden. Im nächsten Schritt haben Sie die neuen attributeSchema-Objekte identifiziert, die Sie dem Schema hinzufügen möchten. In diesem Rahmen haben Sie alle erforderlichen Werte (wie cn, ldapDisplayName usw.) definiert, mit denen die neuen Objekte angegeben werden. Beim Definieren der Attributwerte für das Objekt haben Sie den OID von Microsoft oder von einer anderen Quelle erhalten. Sie haben alle oben genannten Informationen als Geschäftsanforderungen und technische Daten dokumentiert. Sie haben außerdem eine Testumgebung implementiert, die Ihr Active Directory repräsentiert und zum Testen bereit ist.

Viele Organisationen richten besondere Gremien ein, die solche Änderungen genehmigen oder ablehnen und den Prozess für die Implementierung festlegen. Diese Prüfungen und gegenseitige Kontrollen sind erforderlich, da Active Directory in zahlreichen Organisationen als autorisierende Informationsquelle verwendet wird, und es ist besonders wichtig, dass Active Directory auch nach vorgenommenen Änderungen sofort funktionsfähig ist.

Wenn sich die Organisation entschieden hat, Änderungen vorzunehmen, müssen Test- und Implementierungspläne für das Projekt definiert werden. Das Schema kann entweder durch Hinzufügen neuer Objekte mithilfe des Active Directory-Schema-Snap-Ins der Microsoft Management Console (MMC) oder über die Verwendung programmgesteuerter oder halb programmgesteuerter Methoden (z. B. die Verwendung von LDIFDE zum Importieren von .ldif-Format-Dateien, CSVDE zum Importieren von .csv-Format-Dateien oder mit Active Directory Service Interfaces-Skripting) erweitert werden.

Für alle Methoden gilt, dass die Funktion auf einem Server ausgeführt werden muss, der entweder mit der FSMO-Rolle (Flexible Single Master Operations) des Schemamasters in der Active Directory-Struktur verbunden ist oder über diese Rolle verfügt. Das Konto, das für die Schemaaktualisierung verwendet wird, muss über die erforderlichen Berechtigungen zum Ausführen der Aktualisierung verfügen. Das Konto sollte daher ein Mitglied der Gruppe „Schemaadministratoren“ sein. Abschließend müssen Schemaaktualisierungen für die Struktur aktiviert werden (diese Option ist standardmäßig deaktiviert).

Wenn es sich nicht um eine sehr einfache Änderung handelt, sollte die Aktualisierung automatisiert werden, um die Standardisierung zwischen Test- und Produktionsimplementierungsphasen zu gewährleisten und um Fehler zu vermeiden, die bei einer manuellen Ausführung auftreten können. Gehen wir davon aus, dass Sie LDIFDE zur Implementierung der Änderungen verwenden. Um Aktualisierungen beim Erweitern des Schemas anzuwenden, fügen Sie die neuen Attribute und Klassen hinzu, fügen dann die neuen Attribute Klassen hinzu und veranlassen dann ein erneutes Laden des Cache. Im Folgenden werden einige Szenarios aufgeführt.

Hinzufügen von Attributen

Gehen wir davon aus, dass eine Organisation namens „Contoso“ ein Attribut in Active Directory hinzufügen möchte, über das die Schuhgröße der einzelnen Mitarbeiter identifiziert wird. Die Active Directory-Struktur verfügt über zwei Domänen: contoso.com und employees.contoso.com. Es ist erforderlich, dass alle Objekte, die über die Benutzerklassendefinition erstellt werden, auch über das neue Attribut verfügen.

Denken Sie daran, dass die Schemaänderung für beide Domänen ausgeführt wird, da sich diese in der gleichen Struktur befinden. Gehen wir davon aus, dass Sie den OID 1.2.840.113556.8000.9999 von Microsoft erhalten und diesen für Contoso in 1.2.840.113556.8000.9999.1 für classSchema- und 1.2.840.113556.8000.9999.2 für attributeSchema-Objekte unterteilt haben. Jetzt werden alle Attributwerte für dieses neue Objekt entsprechend Abbildung 3 definiert.

Figure 3 Definieren des contosoEmpShoe-Attributs

Obwohl das Attribut „contosoEmpShoe“ für alle Objekte verfügbar sein muss, die als Benutzerklassenobjekte erstellt wurden, wird nicht empfohlen, die Standarddefinition der Benutzerklassen zu ändern. Stattdessen sollten Sie eine Erweiterungsklasse namens „contosoUser“ definieren, für die der Wert von mayContain als „contosoEmpShoe“ angegeben ist (siehe Abbildung 4). Fügen Sie dann der Benutzerklasse die Attribute zu, die für die Erweiterungsklasse „contosoUser“ definiert sind.

Figure 4 Definieren der contosoUser-Klasse

Nachdem die Analyse durchgeführt und die Werte definiert wurden, wird die ldif-Datei erstellt, die dem Code in Abbildung 5 entspricht. Sie können den Inhalt von Abbildung 5 in Editor kopieren und die Datei als „contosoUser.ldif“ speichern (eine Kopie ist auch im Codedownload unter technetmagazine.com verfügbar).

Figure 5 .ldif-Datei zum Erweitern Ihres Schemas

#Attribute definition for contosoEmpShoe

dn: CN=contosoEmpShoe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: contosoEmpShoe
attributeID: 1.2.840.113556.1.8000.9999.2.1
attributeSyntax: 2.5.5.12
isSingleValued: TRUE
adminDisplayName: contosoEmpShoe
adminDescription: contosoEmpShoe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: contosoEmpShoe
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

# Classes

dn: CN=contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: classSchema
cn: contosoUser
governsID: 1.2.840.113556.1.8000.9999.1.1
mayContain: contosoEmpShoe
rDNAttID: cn
adminDisplayName: contosoUser
adminDescription: contosoUser
objectClassCategory: 3
lDAPDisplayName: contosoUser
name: contosoUser
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

dn: CN=User,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: auxiliaryClass
auxiliaryClass: contosoUser
-

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

Nach dem Generieren der .ldif-Datei sollte die Implementierung gründlich in einer Testumgebung getestet, die End-to-End-Replikation Ihrer Domäne und Struktur überprüft und die Aktualisierung des Schemas in der Struktur aktiviert werden. Sie sollten sich nun mit einem Konto anmelden, das über die Schemaadministratorberechtigungen verfügt. Möglicherweise sollte die ausgehende Replikation auf dem Schemamaster (auf dem die Änderung durchgeführt wird) deaktiviert und folgender Befehl zum Importieren der .ldif-Datei ausgeführt werden:

ldifde –i –f <Path>\contosoUser.ldif –b
<username> <domain> <password> -k –j. –c
"CN=schema,CN=Configuration,DC=X"
#schemaNamingContext

Nachdem die Änderung durchgeführt wurde, aktivieren Sie die ausgehende Replikation auf dem Schemamaster, und stellen Sie sicher, dass die Replikation für alle Domänencontroller durchgeführt wurde.

Jetzt können Sie sich entspannen, die Aktualisierung ist abgeschlossen! Sie haben ein neues Attribut im Schema definiert, das den Objekten zugeordnet wird, die über die Benutzerklasse (d. h. Benutzerkonten) erstellt wurden.

Öffnen Sie zum Überprüfen der Änderung „Active Directory-Benutzer und -Computer“, stellen Sie eine Verbindung zur Domäne „employees.contoso.com“ her, suchen Sie die Organisationseinheit „Benutzer“ (organizational unit, OU), und erstellen Sie ein neues Benutzerkonto namens „ContosoTestUser“. Öffnen Sie die Konsole „adsiedit.msc“, und stellen Sie eine Verbindung zur Domänenpartition „dc=employees,dc=contoso,dc=com“ her, erweitern Sie die Organisationseinheit „Benutzer“, klicken Sie mit der rechten Maustaste auf „ContosoTestUser“, und öffnen Sie die Seite „Eigenschaften“. Suchen Sie das Attribut „contosoEmpShoe“. Sie können das Attribut bearbeiten, um einen Wert einzugeben. Sie können auch das Dienstprogramm „Ldp.exe“ verwenden, um die Attribute zu überprüfen und zu ändern.

Im Folgenden finden Sie ein Beispiel, in dem zwei Attribute verknüpft werden. Gehen wir davon aus, dass die Schuhgröße von Mitarbeitern bei Contoso besonders wichtig ist und Contoso die jährliche Leistung von Mitarbeitern, die Schuhgrößen im Unternehmen erfassen, nachverfolgen möchte. Gehen wir weiterhin davon aus, dass Contoso nicht nur nachverfolgen möchte, wer für die Messung der Schuhgrößen von Mitarbeitern verantwortlich war, sondern auch, wessen Schuhgrößen gemessen wurden und wie viele. Dies alles soll über eine Attributabfrage erfolgen. (Solche Daten sind möglicherweise besser in Datenbanktabellen aufgehoben, hier wird jedoch lediglich versucht, die Funktionsweise von Forward- und Backwardlinks zu verdeutlichen.)

Auch in diesem Fall wird zunächst die bereits erwähnte Analyse durchgeführt. In diesem Fall fahren wir jedoch mit der Generierung der .ldif-Dateien „linkids1.ldif“ und „linkids2.ldif“ entsprechend Abbildung 6 fort. Führen Sie dann folgenden Befehl aus, um die .ldif-Dateien zu importieren:

Figure 6 .ldif-Dateien für den Forward- und Backwardlink

 
#linkids1.ldif
#Attribute definition for Forward Link Attribute

dn: CN=ContosoShoeSizeTaker,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizeTaker
attributeID: 1.2.840.113556.1.8000.9999.2.2
LinkID: 1.2.840.113556.1.2.50
attributeSyntax: 2.5.5.1
isSingleValued: TRUE
adminDisplayName: ContosoShoeSizeTaker
adminDescription: ContosoShoeSizeTaker
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizeTaker
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Reload schema

#linkids2.ldif

#Attribute definition for Backward Link Attribute

dn: CN=ContosoShoeSizesTakenByMe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizesTakenByMe
attributeID: 1.2.840.113556.1.8000.9999.2.3
LinkID: 1.2.840.113556.8000.9999.2.2
attributeSyntax: 2.5.5.1
isSingleValued: FALSE
adminDisplayName: ContosoShoeSizesTakenByMe
adminDescription: ContosoShoeSizesTakenByMe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizesTakenByMe
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Add ContosoShoeSizeTaker and ContosoShoeSizesTakenByMe Attribute as MayContain in 
#contosoUser class

dn: CN= contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizeTaker
mayContain: ContosoShoeSizesTakenByMe

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Add Backward Link Attribute as MayContain in Top

dn: CN=Top,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizesTakenByMe

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

ldifde –i –f <Path>\linkedids<>.ldif –b
<username> <domain> <password> -k –j. –c
"CN=schema,CN=Configuration,DC=X"
#schemaNamingContext

Wenn ein Benutzerobjekt erstellt wird, verfügt dieses nun auch über die Attribute „ContosoShoeSizeTaker“ und „ContosoShoeSizesTakenByMe“. Beim Erstellen eines Benutzerobjekts für John erhält das Attribut „ContosoShoeSizeTaker“ den DN der Person, die die Schuhgröße gemessen hat, in diesem Fall der Mitarbeiter namens Frank. Wenn Sie nun die Benutzerobjekteigenschaften für Frank aufrufen und das Attribut „ContosoShoeSizesTakenByMe“ abfragen, verfügt das Ergebnis über Johns DN und alle anderen DNs für Personen, deren Schuhgröße von Frank gemessen wurde. Das Management könnte Frank nun z. B. basierend auf der Anzahl an DNs im Attribut „ContosoShoeSizesTakenByMe“ seines Benutzerkontos belohnen.

Systemprüfungen und gegenseitige Kontrollen

Eine kritische Aktualisierung wie eine Schemaänderung darf nicht ohne Prüfung der Anforderungen an die Architektur durchgeführt werden. Diese Konsistenz- und Sicherheitsprüfungen werden von Active Directory dazu verwendet sicherzustellen, dass die Änderungen keine Inkonsistenzen oder anderen Probleme verursachen, wenn Änderungen am Active Directory-Schema vorgenommen werden.

Zunächst müssen die governsID-Werte für jede Klasse innerhalb des Schemas eindeutig sein. Beim Definieren eines schemaClass-Objekts, müssen alle Attribute, die in den Listen „systemMayContain“, „mayContain“, „systemMustContain“ und „mustContain“ definiert sind, bereits vorhanden sein. Ebenso müssen alle Klassen, die in den Listen „subClassOf“, „systemAuxiliaryClass“, „auxiliaryClass“, „systemPossSuperiors“ und „possSuperiors“ definiert sind, bereits vorhanden sein.

Bei der objectClassCategory aller Klassen in den Listen „systemAuxiliaryClass“ und „auxiliaryClass“ muss es sich entweder um die Klasse „88“ oder die Erweiterungsklasse handeln. Ebenso muss die objectClassCategory aller Klassen in den Listen „systemPossSuperiors“ und „possSuperiors“ entweder als Klasse „88“ oder als Strukturklasse angegeben sein.

Während der Definition verschiedener Klassen können abstrakte Klassen nur von anderen abstrakten Klassen erben, Erweiterungsklassen können nicht von Strukturklassen erben und Strukturklassen können nicht von Erweiterungsklassen erben. Das Attribut im Attribut „rDNAttID“ muss als Syntax über eine Unicode-Zeichenfolge und nur über einen Wert verfügen.

Hierbei handelt es sich um einige der Regeln für die classSchema-Objekte. Gilt dies auch für attributeSchema-Objekte? Ebenso wie bei governsID-Werten für Klassen muss der Wert von attributeID eindeutig sein. Der Wert von mAPIID (sofern zutreffend) muss ebenfalls eindeutig sein. Wenn rangeLower und rangeUpper angegeben werden, muss der Wert für rangeLower kleiner als der Wert für rangeUpper sein. Die Werte für attributeSyntax und oMSyntax müssen übereinstimmen. Wenn das Attribut über eine Objektsyntax (oMSyntax = 127) verfügt, muss es die korrekte oMObjectClass besitzen. Die linkID (sofern vorhanden) muss eindeutig sein. Außerdem muss ein Backlink immer über einen entsprechenden Forwardlink verfügen.

Was passiert, wenn Sie einen Fehler machen?

Wenn das Schema um neue Objekte (Klassen und Attribute) erweitert wurde, können diese nicht wieder gelöscht werden. Klassen und Attribute können jedoch deaktiviert werden, indem das Attribut „isDefunct“ im Schemaobjekt auf TRUE gesetzt wird. Schemaobjekte, die Teil des Standardschemas sind, das mit Active Directory (Objekte der Kategorie 1) geliefert wird, können nicht deaktiviert werden. Sie können nur Objekte deaktivieren, die dem Standardschema hinzugefügt wurden. Das heißt, es können lediglich Objekte der Kategorie 2 deaktiviert werden, und diese auch nur dann, wenn Active Directory sichergestellt hat, dass die Klasse nicht in den Listen „subClassOf“, „auxiliaryClass“ oder „possSuperiors“ einer vorhandenen nicht außer Kraft gesetzten Klasse verwendet wird.

Bei einem Versuch, ein Attribut zu deaktivieren, stellt Active Directory sicher, dass das Attribut nicht in mustContain oder mayContain einer vorhandenen nicht außer Kraft gesetzten Klasse verwendet wird. Die deaktivierten Objekte können wieder aktiviert werden, indem das Attribut „isDefunct“ auf FALSE gesetzt wird. Wenn Ihr Active Directory unter Windows Server 2003 ausgeführt wird, können Sie die ldapDisplayName-, schemaIdGuid-, OID- und mapiID-Werte des deaktivierten Objekts wiederverwenden.

Schlussbemerkung

Das Hinzufügen oder Ändern von Klassen- oder Attributdefinitionen im Schema beinhaltet das Hinzufügen oder Ändern der entsprechenden classSchema- oder attributeSchema-Objekte. Dieser Prozess ähnelt dem Hinzufügen oder Ändern eines beliebigen Objekts in Active Directory. Hinzu kommt das Durchführen weiterer Prüfungen, um sicherzustellen, dass die Änderungen nicht zu Inkonsistenzen oder Problemen bei der weiteren Verwendung des Schemas führen.

Obwohl das Ändern des Active Directory-Schemas relativ einfach ist, sollten der Aufbau des Schemas sowie die Funktionsweise des Schemas bei der Implementierung der Änderungen verstanden werden. Änderungen des Active Directory-Schemas in einer Produktionsumgebung erfordern ausführliche Planung und Umsicht bei der Durchführung. Es ist wichtig, die Geschäftsanforderungen und technischen Spezifikationen für neue Objekte zu definieren und zahlreiche Tests in einer Testumgebung durchzuführen. Da Änderungen enorme Auswirkungen haben können, wird empfohlen, das Active Directory-Schema nur zur erweitern, wenn es unbedingt notwendig ist.

Vikas Malhotra ist bei Microsoft Consulting Services in New York tätig. Während seiner 12-jährigen Tätigkeit hat er mit zahlreichen IT-Organisationen in großen und mittleren Unternehmen zusammengearbeitet, um Anforderungen an die Infrastrukturarchitektur zu erfüllen, z. B. in Bezug auf Verzeichnis, Messaging, Sicherheit und Datennetzwerk. Er verfügt über einen Bachelor of Engineering in Electronics and Telecommunications und einen Master of Science in Telecom (Tech) Management. Sie erreichen ihn unter: vikasmal@microsoft.com.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.