Schema Erweiterungen – Riskant oder unkritisch?

Das Schema ist quasi die Vorlage für alle Objekte die im Active Directory vorhanden sind oder angelegt werden können, basierend auf den im Schema definierten Klassen und Attributen. Wobei mit der Installation des AD nur das Default Schema angelegt wird (siehe dazu auch Details unter https://msdn.microsoft.com/en-us/library/ms674984(VS.85).aspx sowie https://msdn.microsoft.com/en-us/library/ms675085(VS.85).aspx). Vielen Anwendungen reichen diese Standard Attribute jedoch nicht und möchten daher eigene Attribute im Schema anlegen oder bestehende Attribute umwandeln oder ergänzen. Ist dies nun kritisch?

 

Aus unserer Erfahrung heraus gibt es da zwei Kategorien:

- Einmal Anwender die vor dem Einsatz einer Schema Erweiterung prinzipiell bei uns Nachfragen und die Schema Erweiterung überprüft haben möchten

- Und zum anderen die Anwender, die in irgendeinem Internet Forum als Workaround eine Schema Erweiterung empfohlen bekommen haben, dort auch eine DLL runter laden und damit dann das Schema erweitern. Ohne weiteres Testen.

 

Beides ist vielleicht nicht der ideale Ansatz. Doch zunächst etwas Theorie. Attribute im Schema werden eindeutig gekennzeichnet, mit einer sog. OID (Object Identifier) muss nach RFC 2251 ein Directory Service Klassen und Attribute identifizieren. Diese OIDs identifizieren die Attribute in einer Baumstruktur und nützen dafür eine mit Punkten getrennte Syntax. Z.b. die OID 1.2.840.113556.1.5.9

Dies bedeutet:

Value

Meaning

Description

1

ISO

Identifies the root authority.

2

ANSI

Group designation assigned by ISO.

840

USA

Country/region designation assigned by the group.

113556

Microsoft

Organization designation assigned by the country/region.

1

Active Directory

Assigned by the organization.

5

Classes

Assigned by the organization.

9

user class

Assigned by the organization.

Soviel zur Theorie. Die OIDs sind schon einer der Hauptproblempunkte. Aus dieser Syntax (und natürlich der RFC) kann man erkennen, dass die OID bis zu einer gewissen Ebene von Öffentlichen Institutionen vorgegeben ist und ab einem Punkt dann einer Organisation „gehört“. Grundsätzlich müssen OIDs eindeutig sein, da es sonst zu Konflikten kommen würde. Zumindest das AD wehrt sich gegen eine Erweiterung mit einer bereits vergebenen OID. Es muss also eine eindeutige OID her. Doch woher? Hmm, ganz einfach (dachten viele): Microsoft bieten ein Script an um eindeutige OIDs zu generieren (https://www.microsoft.com/technet/scriptcenter/scripts/ad/domains/addmvb03.mspx?mfr=true ). Oder doch nicht? Nun, Microsoft gehört nicht zu den Organisationen (wie ANSI, IANA, oder andere ISO Name Registration Authorities) die OIDs vergeben können. Daher garantiert das Script keine eindeutige OID. Prinzipiell raten wir unbedingt dazu offiziell registrierte OIDs zu verwenden, nur so lässt sich vermeiden, das man eine Anwendung installieren möchte und diese Anwendung sich verweigert weil die OIDs schon genutzt sind. Oder vielleicht sogar der Name des Attributes? Auch hier ist die Empfehlung klar: Wir raten unbedingt dazu eigene Schema Attribute mit dem Namen der Organisation zu verknüpfen.

 

Das ist das eigentliche Problem leider nicht nur bei der „Wald-und-Wiesen-Schema-Erweiterung“ aus dem Internet Forum, sogar auch bei verschiedenen Anwendungen. Auch in unserem Hause gab es da zugegebenermaßen schon Probleme. Wenn nun also eine Schema Erweiterung implementiert wurde und später eine andere Anwendung sich nicht mehr installieren lässt weil das Attribut schon existiert (aber leider in einer falschen Definition) oder die OID schon vergeben ist. Was dann?

 

Nun, hier muss zunächst festgestellt werden wer dafür Verantwortlich ist, welches Attribut, welche OID ist falsch? Ist es die Anwendung die gerade installiert werden sollte? Dann Glück gehabt. Hier hilft nur sich beim Hersteller zu melden und diese Problematik zu erklären. Der Hersteller steht dann in der Pflicht diesen Fehler auszubügeln. Im Nachhinein geht das natürlich immer schwerer.

 

Nicht nur einmal hatte ich das Problem, das ein Kunde unsere Software installieren wollte (z.B: Windows 2003, 2008 Forestprep, Office Communication Server, SFU o.ä.) und dabei über bereits existierende Attribute mit gleichem Namen oder bereits vergebene OIDs gestolpert ist. Hier wieder raus kommen ist nicht ganz einfach. Eine Schema Erweiterung kann nicht rückgängig gemacht werden, das ist ein Fakt. Wie jedoch nun den Kunden weiterhelfen? Wenn man das Attribut nicht löschen kann, das falsche Attribut schon im Schema drin ist und daher eine wichtige Anwendung nicht eingesetzt werden kann – bleibt dann etwas anderes als eine Migration in einen neuen Forest? Meistens – ja. Doch es kann durchaus sein, das eine Migration die einzige Lösung ist. Wie kann man das also umgehen?

 

Zunächst muss man sich klar sein, welche Anwendung für einen wichtiger ist. Die, die schon installiert ist und den Fehler verursacht oder die, die neu installiert werden soll und sich aufgrund des Fehlers verweigert? In meinen Fällen hat hier immer die neue Anwendung gesiegt, die Kunden haben immer bewusst in Kauf genommen, dass die alte Anwendung nicht mehr funktionieren wird. Das ist leider ein Grundübel wenn man schon soweit ist. „Es kann nur einen geben“ – dieses Prinzip gilt auch hier.

 

Hier nun eine Script Vorlage für eine LDIF Datei mit der man bestehende Attribute „überarbeiten kann“. Selbstverständlich ist dies nur eine Vorlage und kann nicht ohne Anpassung eingesetzt werden. Wer das macht und hierbei einen Fehler macht, dem sei die Lektüre zu ADMT empfohlen: „Wie migriere ich in einen neuen Forest.“

 

Die Schritte sind im einzelnen:

- Überprüfen ob das Attribut Referenzen im „mayContain“ hat bzw. bei anderen drin steht

- Diese Referenzen entfernen

- Die LinkID entfernen

- Das Schema Attribut umbenennen

- Evtl. den alten RDN entfernen

- Dann das Attribut neu und korrekt anlegen

- Evtl. „mayContain“ Einträge wieder ergänzen

 

Dies noch ergänzt mit schemaUpdateNow an den richtigen Stellen. Wie bereits erwähnt, das Beispiel enthält alle notwendigen Schritte, muss aber noch mit Kleinigkeiten für den SchemaUpdate ergänzt werden. Da ich mich ja im Anfang über „Wald-und-Wiesen“ Schema Erweiterungen aus Internetforen mokiert habe, kann ich hier natürlich keine Anleitung liefern mit der man per Copy & Paste sein Schema unwiderruflich schädigen kann. Daher ist dies hier bitte als theoretische Abhandlung und Aufzeigen des Machbaren zu verstehen. Wer also in solch einen Fehler reinläuft, dem sei geraten bei uns eine Anfrage zu eröffnen damit wir entsprechende Hilfestellung leisten können. Es gibt im Internet durchaus Anleitungen wie man ein Attribut einfach aus dem Schema löschen soll, doch unsere Erfahrungen damit lassen definitiv von solchen Versuchen abraten.

 

Rename + Defunct + Re-create Schema object

 

# +----------------------------------------------------------------+

# I Der Forest MUSS im Forest Functional Level 2003 sein,

# I andernfalls geht das mit dem Fehler "duplicate OID" schief

# +----------------------------------------------------------------+

# +----------------------------------------------------------------+

# I Entferne hjs-MyAttribut von

# I hjs-MyOtherAttribut maycontain

# +----------------------------------------------------------------+

dn: CN= hjs-MyOtherAttribut,CN=Schema,CN=Configuration,DC=domain,DC=com

changetype: modify

delete: mayContain

mayContain: hjs-MyAttribut

-

# +----------------------------------------------------------------+

# I Entferne L I N K I D

# +----------------------------------------------------------------+

dn: CN= hjs-MyAttribut,CN=Schema,CN=Configuration, DC=domain,DC=com

changetype: Modify

replace: LinkID

LinkID: 0

-

# +----------------------------------------------------------------+

# I Umbenennen des A T T R I B U T

# +----------------------------------------------------------------+

dn: CN= hjs-MyAttribut,CN=Schema,CN=Configuration, DC=domain,DC=com

changetype: Modify

replace: lDAPDisplayName

lDAPDisplayName: hjs-MyAttribut -Defunct

-

# +----------------------------------------------------------------+

# I Note:

# I kein abschließendes "-" in der Zeile nach deleteoldrdn

# +----------------------------------------------------------------+

dn: CN= hjs-MyAttribut,CN=Schema,CN=Configuration, DC=domain,DC=com

changetype: modrdn

newrdn: CN= hjs-MyAttribut -Defunct

deleteoldrdn: 1

# +----------------------------------------------------------------+

# I D E F U N C T hjs-MyAttribut

# +----------------------------------------------------------------+

dn: CN=ms- hjs-MyAttribut -Defunct,CN=Schema,CN=Configuration, DC=domain,DC=com

changetype: modify

replace: isDefunct

isDefunct: TRUE

-

# +----------------------------------------------------------------+

# I Neu Erstellen des Attributes

# +----------------------------------------------------------------+

dn: CN= hjs-MyAttribut,CN=Schema,CN=Configuration, DC=domain,DC=com

changetype: add

adminDescription: hjs-MyAttribut

adminDisplayName: hjs-MyAttribut

description: Beispiel Attribut für Schema Erweiterungsblog.

objectclass: attributeSchema

attributeID: <hier nun die korrekten Werte aus der Schema LDIF Datei>

schemaIDGUID:: <hier nun die korrekten Werte aus der Schema LDIF Datei>

oMSyntax: <hier nun die korrekten Werte aus der Schema LDIF Datei>

attributeSyntax: <hier nun die korrekten Werte aus der Schema LDIF Datei>

linkID: <hier nun die korrekten Werte aus der Schema LDIF Datei>

usw.

# +----------------------------------------------------------------+

# I hjs-MyAttribut zuo hjs-MyOtherAttribut

# I maycontain hinzufügen

# +----------------------------------------------------------------+

dn: CN= hjs-MyOtherAttribut,CN=Schema,CN=Configuration, DC=domain,DC=com

changetype: modify

add: mayContain

mayContain: <hier nun die korrekte Attribut ID des neuen, korrekten Attributes>

-

 

Nun zurück zu der Frage:

- Was kann oder sollte ich tun um bei einer Schema Erweiterung größtmögliche Sorgfalt walten zu lassen

1.) Entweder gehört Vertrauen zum Vendor der Schema Erweiterung dazu oder man muss überprüfen (geht nur bei den ISO Name Registration Authorities) ob diese Erweiterungen alle korrekt registriert wurden.

2.) Dann gehört Testen dazu. Ideal ist es (nach der Erstellung eines aktuellen Backups) den Schema FSMO und einen direkten Replikationspartner offline zu nehmen, auf dem Schema FSMO das Schema erweitern und auch noch die Replikation beobachten. Wenn die Erweiterung erfolgreich war und auch die Replikation keine Probleme aufwirft, dann kann ich mit beiden DCs wieder online gehen und diese replizieren die Schema Erweiterung raus.

Schöne Grüße, Hans-Jürgen