faq-o-matic.net » AD-Schema

Video: Active Directory als Datenspeicher?

Nils Kaczenski — Wed, 09 Feb 2011 06:44:00 +0000

Das Schema ist das Rückgrat des Active Directory: Es definiert die Datenfelder und Objekttypen, die das Verzeichnis kennt. Damit entscheidet es darüber, welche Daten man in AD ablegen kann. Manipulationen des Schema können sich gravierend auswirken, wenn sie falsch laufen: Es droht nicht weniger als der komplette Datenverlust. Aber wie empfindlich ist das Schema wirklich? Welche Daten können Sie in AD speichern und welche nicht? Was sollte man beachten, wenn man das Schema erweitern will? Und wie kann man hinterher die neuen Datenfelder nutzen?

Ein Video mit viel Praxis-Demo, das die wichtigsten Kenntnisse zur Datenbankstruktur des Active Directory vermittelt.

Das folgende Video wurde vor einem Jahr anlässlich des fünften Geburtstags von faq-o-matic.net aufgezeichnet. Aufgrund technisch-organisatorischer Probleme konnten wir es damals leider nicht veröffentlichen. Da sich an der Aktualität aber nichts geändert hat, holen wir das jetzt nach.

Active Directory als Datenspeicher? von Nils Kaczenski auf Vimeo.

Die Folien zu dem gleichnamigen Vortrag auf der ice:2008, der dem Video zugrundeliegt, finden sich hier:

[faq-o-matic.net » \\ice:2008: Active Directory als Datenspeicher? Die Folien]
http://www.faq-o-matic.net/2008/08/30/ice2008-active-directory-als-datenspeicher-die-folien/

AD-Schemaerweiterung: Ein paar Hinweise

Nils Kaczenski — Wed, 08 Apr 2009 19:37:17 +0000

Viele komplexe Applikationen integrieren sich in Active Directory (AD). Einige davon legen dort auch Konfigurationsdaten ab, beispielsweise Exchange oder Ciscos Call Manager. Zu diesem Zweck erweitern sie das Schema des AD, also die Definition der Datenbank: Sie legen neue Attribute (Datenfelder) und meist auch neue Objektklassen an, die den Aufbau bestimmter Objekte beschreiben. Doch auch Windows selbst ändert bisweilen das AD-Schema, vor allem bei der Aufnahme von Domänencontrollern mit neuen Betriebssystemversionen (etwa Windows Server 2003, 2008 oder die jeweiligen R2-Versionen). Selbst WIndows Vista kann eine Schemaergänzung erfordern, wenn man die Schlüssel für die Festplattenverschlüsselung BitLocker in AD ablegen möchte.

Derartige Manipulationen des Schemas haben eins gemeinsam: Sie sind von ihren Herstellern sorgfältig entworfen und entwickelt worden, und natürlich hat es intensive Tests gegeben. In solchen Fällen darf der geneigte Admin also darauf vertrauen, dass die Schemaerweiterung selbst in Ordnung ist. Anders kann es aussehen, wenn ein Anwenderunternehmen selbst Ergänzungen am AD-Schema ausführen möchte. Solche Anforderungen lassen sich sinnvoll umsetzen, wenn man sich intensiv mit der Materie beschäftigt und die passende Sorgfalt bei Entwurf und Entwicklung walten lässt. Hintergründe dazu finden sich verstreut, aber durchaus umfassend auf Microsofts Webseiten.

Im Folgenden geht es um “fertige” Schema-Änderungen, also im Regelfall solche der erstgenannten kommerziellen Art. Trotz der sorgfältigen Entwicklung sollte man einige Dinge berücksichtigen, damit das Upgrade sauber und sicher funktioniert.

Wie kritisch ist eine Schemaerweiterung?

Allenthalben ist die Warnung zu lesen: Das Schema ist das Rückgrat des Active Directory. Eine fehlerhafte Änderung kann den Verzeichnisdienst empfindlich stören. Daher wird zu größter Sorgfalt geraten. Was ist dran?

Generell gesprochen, sind die Einordnung und die Warnung richtig. Das Schema legt über Attribute und Objektklassen fest, welche Daten wie im Verzeichnis abgelegt werden. Ein beschädigtes Schema kann daher durchaus das ganze AD lahmlegen. Ein Beispiel: Ein Unternehmen erweitert das Schema, um bei allen Benutzern die Schuhgröße zu speichern. Für die meisten “User”-Objekte wird die Schuhgröße dann auch gepflegt. Später entfällt der Bedarf für diese Daten, und ein Admin entschließt sich kurzerhand, die Erweiterung “Schuhgröße” zu deaktivieren (denn: Löschen kann man Attribute und Klassen nicht). Was passiert? Fast alle “User”-Objekte enthalten nun Daten für ein Attribut, das gar nicht aktiv ist. Diese Objekte sind also fehlerhaft. Eine solche Änderung am Schema hätte man also anders durchführen müssen: Erst das Löschen aller betroffenen Attributwerte, dann das Deaktivieren des Attributs.

Ein anderes Beispiel: Ein Unternehmen beschließt, bestimmte Daten in AD abzulegen. Dazu erzeugt es einige Attribute und Klassen, übersieht aber die Notwendigkeit, dies auf eine bestimmte strukturierte Weise zu tun. Die “Object ID”, die das Unternehmen verwendet, hat es nicht vorher registriert und auch nicht geprüft. Eigentlich gehört diese ID einem anderen Unternehmen, das Software herstellt. Später entschließt das erste Unternehmen, eine Software des zweiten Unternehmens einzusetzen. Leider bricht die dafür nötige Schemaerweiterung ab: Die vorgesehene Object ID ist bereits in Benutzung – durch die eigenmächtige Erweiterung des Anwenderunternehmens.

Das sind zwei Szenarien, die sich durch Planung verhindern lassen. Es gibt aber auch technische Ausfälle – etwa dass eine Schemaerweiterung mittendrin abbricht. Ist nun das Schema unbrauchbar?

Nein, sehr wahrscheinlich ist das nicht der Fall. Active Directory arbeitet transaktional: Eine Änderung an Daten wird immer vollständig oder gar nicht ausgeführt. Fällt also der Strom aus, während AD gerade dabei ist, ein neues Attribut zu definieren, so wird beim nächsten Serverstart diese begonnene Änderung widerrufen. Aber: Das betrifft immer nur die laufende Transaktion, im Beispiel also dieses eine Attribut. Die anderen Attribute, die dieselbe Schemaerweiterung vorher bereits definiert hatte, bleiben im AD-Schema.

Was nun? AD enthält einige, aber nicht alle Erweiterungen, die für die jeweilige Applikation nötig sind. Die Applikation wird also wohl nicht laufen. Das AD selbst ist in seiner Funktion aber ziemlich sicher nicht eingeschränkt, denn es gibt nur einige Daten mehr als sonst, die aber andere Applikationen nicht stören. Günstigenfalls lässt sich die Schemaerweiterung der neuen Applikation einfach neu starten (siehe unten) und läuft dann zum Ende durch. Aber: Eine Garantie dafür gibt es nicht!

Zu diesem Fall gibt es aber natürlich auch Ausnahmen: Man kann das Schema nämlich nicht nur um neue Einträge erweitern, sondern auch vorhandene Einträge modifizieren. Hängt eine solche Modifikation von anderen Einträgen ab, die aufgrund eines Abbruchs gar nicht vorhanden sind, wird es vermutlich Probleme geben. In solch einem Fall ist der Support des Herstellers einzuschalten.

Die Grenzen

Es gibt zwei faktisch unverrückbare Grenzen, die man bei der Manipulation des AD-Schema kennen sollte:

Eine Erweiterung lässt sich nicht rückgängig machen. Vorhandene Attribute und Klassen kann man nicht löschen.
Zwar kann man Klassen oder Attribute deaktivieren, sodass sie künftig nicht nutzbar sind. Entfernen kann man sie aber nicht.
Es gibt kein Rollback und kein “Authoritative Restore” des Schema.
Die Methoden, mit denen man “normale” AD-Einträge aus einem Backup wiederherstellen kann, greifen beim Schema nicht.

Bedarf klären

Auch beim Einsatz einer kommerziellen Applikation sollten die Zuständigen genau prüfen, ob sie das Programm und seine Schema-Manipulation wirklich benötigen. Stellt sich nach dem Update heraus, dass man die Applikation doch nicht nutzen will, hat man unnötige “Altlasten” im System. Diese sind zwar normalerweise nicht kritisch, können sich aber in Einzelfällen als Problem auswirken (siehe obige Diskussion).

Eine Warnung in diesem Zusammenhang vor Beta-Software: Entwicklungsversionen einer Software haben in einem produktiven Netzwerk nichts zu suchen. Eine Schemaerweiterung lässt sich nicht rückgängig machen. Neben dem “Altlast”-Problem können auch handfeste Schwierigkeiten entstehen, wenn man etwa eine überholte Fassung des Schemas betreibt, die vielleicht mit der Endversion inkompatibel ist.

Eingangsuntersuchung

Für Anwendungen mit eingeschränktem Support – also etwa Individualsoftware oder Eigenentwicklungen – gilt, dass man die Änderungen am Schema zunächst im Quelltext überprüfen sollte, sofern das möglich ist. Eine Empfehlung für solche Änderungen ist, dass sie im LDIF-Format (LDAP Interchange Format) vorliegen und über das Windows-eigene Werkzeug ldifde.exe importiert werden sollten. Hat sich der Entwickler daran gehalten, so liegen die nötigen Definitionen also als Textdateien vor, die man einer Inspektion unterziehen kann (bei Exchange etwa ist das der Fall).

Nun benötigt man für eine solche Analyse sehr tiefgehende Kenntnisse von der Materie und meist auch von der neuen Applikation. Nur selten werden Admins darüber verfügen. Was man aber bei der Durchsicht tun kann:

Prüfen, ob die Dateien vollständig sind. Fehlen etwa Dateien bei fortlaufender Nummerierung der Dateinamen? Sind Dateien korrupt und unvollständig? In solchen Fällen ist natürlich Ersatz anzufordern.
Notieren einiger Änderungen und Ergänzungen. Meist definieren Applikationen neue Attribute und Objekte. Hier kann man stichprobenartig einige Definitionen herauskopieren, damit man nach dem Update vergleichen kann, ob alles da ist. Oft gibt es aber auch Änderungen an bestehenden Definitionen (erkennbar im LDIF-Text an dem Schlüsselwort “modify”). Auch hier lohnen Ist-Soll-Vergleiche.
Nachprüfen, ob die Erweiterungen evtl. schon vorhanden sind. Gerade bei “älteren” AD-Umgebungen, in denen vielleicht die Admins gewechselt haben, besteht oft keine Klarheit darüber, in welchem Zustand sich das Schema befindet. Die folgenden Artikel können bei der Identifikation helfen:

[faq-o-matic.net » José Active-Directory-Dokumentation: Version 2.0 ist fertig]
http://www.faq-o-matic.net/2008/10/29/jos-active-directory-dokumentation-version-20-ist-fertig/

[faq-o-matic.net » Schema-Versionen vergleichen]
http://www.faq-o-matic.net/2007/10/21/schema-versionen-vergleichen/

Test

Ein Schema-Upgrade sollte man immer erst testen, bevor man es in der Produktionsumgebung ausführt. Hierzu eignen sich virtuelle Umgebungen. Meist reicht eine einzelne VM aus, nämlich ein Domänencontroller (DC), dessen Schema auf demselben Stand ist wie in der realen Welt – vor dem Upgrade natürlich.

In speziellen Fällen kann es sinnvoll sein, wichtige Applikationen mit in die Testwelt zu holen, um deren Reaktion auf die Änderung zu prüfen. Da allerdings eine Schemaerweiterung als solche die AD-Definition nur erweitert, ist sie Applikationen in der Regel egal, denn sie ignorieren die Objekte und Attribute einfach, die sie nicht interessieren. Anders sieht es aber bei Änderungen (modify) bestehender Attribute oder Klassen aus. Hier können durchaus Abhängigkeiten bestehen. Normalerweise sollte der Applikationshersteller darüber aber Auskunft geben können.

Der Test selbst erfolgt im Wesentlichen nach demselben Verfahren wie die “echte” Änderung – siehe also unten. Der Testvorgang bezieht sich hauptsächlich auf den Upgradeprozess: Welches Tool nutzt man und wie arbeitet es? Läuft es klaglos durch? Ein erweiterter Test könnte darin bestehen, den Upgradevorgang mutwillig zu unterbrechen. Dann ist die spannende Frage: Kann man das Upgrade durch erneute Ausführung fortsetzen? Die meisten Upgrade-Tools können das, einzelne aber nicht (das ADModify von Windows Server 2003/R2/2008/R2 etwa sollte man auf keinen Fall unterbrechen). Vielleicht lässt sich der Vorgang aber durch ein anderes Werkzeug wie ldifde.exe fortsetzen. Das ist dann gegeben, wenn die Änderungen selbst durch .ldf-Dateien ausgeführt werden. Mit dem Schalter –k weist man ldifde.exe an, seinen Import im Falle bereits bestehender Objekte fortzusetzen.

Um solche Teste mehrfach ausführen zu können, empfiehlt sich die Snapshot-Funktion der virtuellen Umgebung.

Vorbereitung

Waren Analyse und Test erfolgreich, geht es an die tatsächliche Durchführung in der Produktionsumgebung. Vorbereitend sollte man einige Dinge vollziehen:

Datensicherung des AD: Um auf einen zwar unwahrscheinlichen, aber möglichen Katastrophenfall reagieren zu können, führt man für alle Domänen des AD-Forest eine Datensicherung aus. Dabei ist auf jeden Fall der bordeigene “System State” zu nutzen, weil dies den gemeinsamen Nenner bei einem eventuellen Einsatz des Microsoft-Supports darstellt. Wer andere Werkzeuge zur AD-Datensicherung einsetzt, nutzt diese ergänzend.
Aufbau eines Plans zum Forest Recovery: Auch dies gehört zur Kategorie “unwahrscheinlich, aber unverzichtbar”. Geht die Sache wirklich schief, kann man gezwungen sein, aus den Datensicherungen den ganzen AD-Forest wieder aufzubauen. Das Konzept ist netzwerkspezifisch, eine allgemeine Anleitung kann man also kaum geben. Gute Orientierung bietet das Microsoft-Whitepaper:

[Download details: Forest Recovery]
http://www.microsoft.com/downloads/details.aspx?familyid=afe436fa-8e8a-443a-9027-c522dee35d85&displaylang=en

Identifizieren des Schema-Masters und der berechtigten Konten: Das Schema-Upgrade kann nur über den DC erfolgen, der die Schema-Master-Rolle hält. Zudem muss das ausführende Benutzerkonto Mitglied der Gruppe “Schema-Admins” sein.
Sicherstellen, dass die Replikation des AD ordnungsgemäß funktioniert. Einen ersten Anhalt geben die Ereignisprotokolle der DCs. Weiteren Aufschluss geben der Replication Monitor (aus den Support Tools) sowie repadmin.exe (ebenfalls Support Tools).
Auswahl des Zeitpunkts: Zwar kann das Schema-Upgrade im laufenden Betrieb geschehen. Es ist aber meist sinnvoll, zumindest eine lastärmere Zeit dafür auszuwählen. Vorsicht aber: Freitagabend ist meist keine gute Wahl, weil man dann bei einer Katastrophe am Wochenende wohl kaum schnell auf externen Support zurückgreifen kann.
Replikation: Wer eine Windows-2000-Domäne aktualisiert, muss wissen, dass eine Schemaänderung zu einer Komplettreplikation des ganzen AD über alle Domänencontroller führt. Hier sollte man also laststarke Zeiten vermeiden. Ab Windows Server 2003 passiert dies aber nicht mehr, sondern es wird nur repliziert, was sich wirklich geändert hat.

Jetzt wird’s ernst!

Sind alle Vorbereitungen getroffen, kann es losgehen. Wichtig: Es ist zwar technisch möglich, das Schema-Upgrade remote auszuführen, also von einem DC aus, der selbst gar nicht Schema-Master ist, oder gar von einem Client aus. Um aber zu verhindern, dass ein Netzwerkproblem zum Abbruch führt, sollte man das Upgrade nur direkt auf dem Schema-Master ausführen.

Isolation des Schema-Masters – auf eigene Gefahr!

Achtung, das folgende Verfahren wird von Microsoft ausdrücklich nicht empfohlen! Es befindet sich allerdings nicht im Status "unsupported". Trotzdem weisen wir auf diesen Umstand hin. Näheres findet sich hier, und zwar in der dritten Frage:

[Friday Mail Sack – I live again edition - Ask the Directory Services Team - Site Home - TechNet Blogs]
http://blogs.technet.com/b/askds/archive/2010/04/16/friday-mail-sack-i-live-again-edition.aspx

Es ist technisch möglich, den Schema-Master während des Upgrade-Vorgangs von der Replikation zu isolieren. Siehe dazu aber den Hinweis direkt über diesem Absatz! Die Isolation ermöglicht ein schnelles und einfaches Fallback, falls der Upgradeprozess selbst scheitern sollte. In den meisten Fällen ist es allerdings unproblematisch, das Upgrade an der laufenden Umgebung auszuführen – insbesondere, wenn der vorherige Test ergeben hat, dass man ein abgebrochenes Upgrade neu starten und zu Ende führen kann.

Sofern der DC, der die Schema-Master-Rolle hält, noch weitere Dienste ausführt, ist es sinnvoll, übergangsweise einen zusätzlichen DC für den Vorgang zu installieren. Im Fall des Falles muss man diesen DC nämlich opfern – und es wäre kaum sinnvoll, dies mit einer Maschine zu tun, die anderweitig benötigt wird.
Den Schema-DC isoliert man nun von der AD-Replikation. Zwar ist es grundsätzlich möglich, ihn einfach vom Netzwerk zu trennen, doch führt dies bisweilen zu unerwünschten Effekten. Besser ist es also, die Replikation abzuschalten ("server.dom.tld" steht im Folgenden für den DNS-Namen des DCs):
repadmin /options server.dom.tld +DISABLE_OUTBOUND_REPL
Ausführen der Schema-Erweiterung.
Nun gibt es im Wesentlichen zwei Möglichkeiten:
- Die erwünschte, wahrscheinliche und einfache: Alles ist gutgegangen. In diesem Fall schaltet man die Replikation des Schema-Masters wieder an mit:
  repadmin /options server.dom.tld -DISABLE_OUTBOUND_REPL
  Dann ist der Prozess beendet.
  Besonders wichtig: Auf keinen Fall nach dem Abschluss des Vorgangs diesen Schritt vergessen!
- Die unerwünschte, weniger wahrscheinliche und leider nicht so einfache: Beim Schema-Update ist etwas schiefgegangen. Je nachdem, was passiert ist, gibt es mehrere mögliche Reaktionen.
  - Ist der Update-Prozess abgebrochen, kann man – insbesondere wenn man das vorher positiv getestet hat – versuchen, ihn einfach erneut auszuführen.
  - Gab es beim ADPrep Probleme, kann evtl. dieser Artikel helfen:
  - Gab es andere Probleme, ist eine Web-Recherche auf jeden Fall eine gute Idee.
  - Sollten diese Methoden nicht helfen, kann man den Schema-Master aus dem AD entfernen und neu installieren. Grundsätzlich könnte man dafür zwar dcpromo ausführen, doch wenn der Server tatsächlich nur Domänencontroller ist, ist es vermutlich einfacher, ihn komplett neu aufzusetzen. Bevor man ihn dann wieder ans Netz bringt, entfernt man die zugehörigen Objekte aus dem AD, z.B. nach folgender Anleitung:
  - In diesem Fall muss man dann den Schema-Master auf einen anderen DC verlagern.

\\ice:2008: Active Directory als Datenspeicher? Die Folien

Nils Kaczenski — Sat, 30 Aug 2008 12:28:40 +0000

Wie eben gerade im Vortrag versprochen – hier sind die Folien meines Vortrags "Active Directory als Datenspeicher? Was Sie beim Schema tun und lassen sollten" auf der \\ice:2008 in Lingen.

Eine kleine Korrektur, auf die mich Frank Röder aufmerksam gemacht hat: Seit der MMC 3.0 kann man Erweiterungen der Admin-Oberfläche nicht nur in C++, sondern auch mit .NET entwickeln (Folie 16).

Note: There is a file embedded within this post, please visit this post to download the file.

Adam und Eva

Frank Röder — Sat, 26 Jan 2008 12:43:14 +0000

Immer mehr netzwerkfähige Geräte, wie zum Beispiel Scanner oder auch Telefonanlagen, unterstützen das Einlesen der Benutzer per LDAP. Leider kranken diese Geräte oft an der fehlenden Fähigkeit, sich an einem LDAP Server zu authentifizieren oder anderen Dingen. Manchmal steht der Administrator auch vor der Aufgabe, dass beispielsweise eine Telefonanlage von mehreren Firmen genutzt wird und diese per LDAP angebunden werden soll. Welcher Administrator möchte es, dass seine Domänencontroller von einer Telefonanlage dieser Art abgefragt werden? Dadurch hätten ja unter Umständen auch andere Firmen lesenden Zugriff auf das Active Directory Verzeichnis. Genau für diese Art von Einsatzzweck hat Microsoft das Produkt ADAM entwickelt.

ADAM (Active Directory Application Mode) ist eine Art abgespecktes Active Directory, mit dem man genau diese Dinge realisieren kann, ohne dabei sein Netzwerk in Gefahr zu bringen. Microsoft liefert für ADAM auch entsprechende Werkzeuge, damit man auch ohne Programmierkenntnisse zwischen Active Directory und der ADAM Instanz eine Synchronisation durchführen kann. Wie funktioniert aber jetzt das Ganze und was wird als Voraussetzung benötigt? Im einfachsten Fall reicht hier der Einsatz von Windows XP Professional als ADAM Server. Wer möchte, kann auch einen Windows 2003 Server einsetzen. Für diesen Artikel habe ich auf der Active Directory Seite und auf der ADAM Seite einen Windows Server 2003 R2 eingesetzt. Glücklicherweise kann man unter Windows Server 2003 R2 den ADAM Dienst direkt als Windows Komponente installieren.
OK, was muss man tun, um ADAM zu konfigurieren. Als Erstes muss man die Installation über die Windows Komponenten vornehmen.

Nachdem die Installation abgeschlossen ist, findet man unter „Start -> Programme" den neuen Ordner „ADAM". Unterhalb des Ordners findet man eine Option „ADAM-Instanz erstellen". Mit dieser Option wird ADAM letztendlich lauffähig gemacht.

Da in meinem Demonetzwerk noch keine Instanz besteht, muss hier die Option „Eine eindeutige Instanz installieren" ausgewählt werden. Im nächsten Schritt wird jetzt der Instanzenname abgefragt. Da ich in diesem Artikel als Beispiel ein Telefonbuch installieren will, nenne ich meine Instanz kreativerweise „Telefonbuch FAQ-O-MATIC".

Im nächsten Schritt fragt der Assistent nach den Portnummern, auf denen die Instanz arbeiten soll. Wenn es sich bei dem Server, auf dem ADAM installiert wird, um einen Domänencontroller handelt, dann schlägt der Assistent automatisch Ports vor, die nicht von Active Directory belegt werden. Mein Demosystem ist ein einfacher Mitgliedsserver, auf dem kein Active Directory installiert ist. Deshalb werden vom Assistenten die Standardports für LDAP (389) und LDAP/SSL (636) vorgeschlagen.

Nachdem die Ports festgelegt wurden, möchte der Assistent eine Anwendungspartition erstellen. Die Anwendungspartition wird zukünftig die Benutzerobjekte aufnehmen, die die Telefonanlage dann über eine LDAP Suche abfragen kann. Ich übergehe diesen Schritt, um später demonstrieren zu können, wie man eine Partition auf der Kommandozeile anlegt.

Bei der nächsten Frage möchte der Assistent wissen, wo er die ADAM Datenbank ablegen soll. Hier sollte man prüfen, ob der Speicherplatz auf dem Systemlaufwerk noch ausreichend ist. In den seltensten Fällen macht sich ein Verschieben der Datenbanken auf eine andere Partition bzw. ein anderes Laufwerk erforderlich.

Im nächsten Schritt möchte der Assistent wissen, unter welchem Benutzerkonto der Dienst laufen soll. Auch hier kann man den Standardvorschlag bestehen lassen. Das Benutzerkonto „Netzwerkdienst" ist ein eingeschränkter Security Principal, der für diese Aufgabe geeignet ist.

Jetzt muss ein Benutzerkonto angegeben werden, was administrative Rechte über diese Instanz erhält. Der Einfachheit halber lasse ich hier den Domänen-Administrator stehen. Hier könnte man natürlich auch einen anderen „normalen" Benutzer auswählen.

Damit in einer ADAM Instanz überhaupt Objekte erstellt werden können, benötigt man ein Schema, was diese Objekte beschreibt. Auf der nächsten Seite des Assistenten hat man die Möglichkeit, bestimmte LDF Dateien für die Erweiterung des Schemas zu importieren. Wir benötigen diese Dateien nicht, da wir die Erweiterung später vornehmen.

Nachdem der Assistent noch kurz eine Zusammenfassung der Setup Parameter anzeigt, beginnt er anschließend mit der Installation.
Damit Objekte aus der bestehenden Active Directory Umgebung in die ADAM Instanz repliziert werden können, muss als nächstes das Schema erweitert werden. Im Installationsverzeichnis von ADAM befinden sich dafür zwei LDF-Dateien. Zum Einen ist das die Datei „MS-AdamSchemaW2K3.LDF" für das Schema eines Windows 2003 Active Directory und zum Anderen die Datei „MS-AdamSyncMetadata.LDF", die für den Objektabgleich benötigt wird.

Der Import der LDF Dateien wird über das aus Active Directory bekannte Kommandozeilenprogramm „ldifde" realisiert.
ldifde -i -f MS-AdamSyncMetadata.LDF -s localhost -c "cn=configuration,dc=x" #configurationNamingContext

ldifde -i -f MS-AdamSchemaW2K3.LDF -s localhost -t -c "cn=configuration,dc=x" #configurationNamingContext

Somit ist die ADAM Instanz vorbereitet. Was jetzt noch fehlt, ist die Anwendungspartition, die die Userobjekte anschließend aufnehmen soll. Für diese Aufgabe steht das Programm „dsmgmt.exe" zur Verfügung. Das Gleiche geht aber auch mit „ntdsutil".

Jetzt ist ADAM für die erste Synchronisation bereit. Für den Abgleich zwischen Active Directory und ADAM stellt Microsoft das Programm „adamsync" zur Verfügung. Adamsync benötigt eine XML-Konfigurationsdatei, in der alle wichtigen Parameter festgehalten sind. Im Installationsverzeichnis existiert bereits eine Beispieldatei. Diese muss nur noch auf die eigenen Bedürfnisse angepasst werden.

"1.0"?>

 
  FAQ-O-MATIC
  object
  faq-o-matic.net
  dc=faq-o-matic,dc=net
  
  
  dc=faqomatic
  
   <base-dn>dc=faq-o-matic,dc=netbase-dn>
   <object-filter>(&(objectclass=user)(telephoneNumber=*))object-filter>
   
    givenname
    sn
    telephoneNumber
    
   
  
  
   
    2
    600
   
   
  
 
 
  
  
  
  
  
  
  
  string>string>
  
  
  object-update>object-update>

Gehen wir die wichtigsten Elemente der XML Datei einmal durch. Im Element „" wird nur eine Beschreibung festgelegt. Mit Hilfe dieser Beschreibung kann man durch „adamsync /list localhost" die installierten Konfigurationen besser identifizieren. Die Elemente „source-ad-name" und „source-ad-partition" identifizieren die Quelldomäne. Mit „source-ad-name" wird der FQDN der Quelldomäne festgelegt und mit „source-ad-partition" die Active Directory Partition, in der die zu synchronisierenden Objekte gesucht werden. Das Element „" gibt die Zielpartition an, in der die synchronisierten Objekte erstellt werden sollen. Adamsync ermittelt die zu synchronisierenden Objekte über eine LDAP Suche. Für diese Suche werden zwei Dinge benötigt. Als Erstes muss ein „" festgelegt werden. Dieser distinguished Name beschreibt den Ausgangspunkt der LDAP Suche. Danach wird der eigentliche Suchfilter festgelegt. Da wir die ADAM Instanz als Telefonbuch nutzen wollen, werden nur Benutzer synchronisiert, die auch eine Telefonnummer besitzen. Dadurch ergibt sich folgender LDAP Filter:

„(&(objectclass=user)(telephoneNumber=*))"

Das kaufmännische „Und" kann aber nicht in der XML Datei interpretiert werden. Deshalb muss dieses Sonderzeichen in der XML Datei kodiert werden.

„(&(objectclass=user)(telephoneNumber=*))"

Als nächstes kommen wir zu den Attributen, die für unsere Objekte mit repliziert werden sollen. Für ein Telefonbuch muss ja ein Userobjekt nicht mit allen Attributen repliziert werden. Für diesen Anwendungsfall sollte die Angabe von Vorname, Nachname und Telefonnummer ausreichen. Welche Attribute repliziert werden, kann man über das Element „" steuern. Da für den Anwendungsfall „Telefonbuch" nur drei Attribute repliziert werden müssen, habe ich mich dafür entschieden, diese Attribute über „" anzugeben. Wenn die Zahl der zu synchronisierenden Attribute überwiegen sollte und man nur einige wenige von der Synchronisation ausschließen will, dann kann man diese über „" ausschließen. Ein weiterer wichtiger Punkt ist das „". Darüber kann gesteuert werden, was passieren soll, wenn ein Objekt in der Quelle gelöscht wird. Dazu aber an späterer Stelle mehr.

Nachdem alle Einstellungen in der XML Datei vorgenommen wurden, kann diese jetzt installiert werden. Dafür bietet das Tool „adamsync" den Schalter „/install" an.

adamsync /i localhost NAMEDERXMLDATEI.XMLJetzt ist ADAM für die erste Synchronisation bereit.

adamsync /sync localhost dc=faqomatic

Ein Wort zur Performance. In der Active Directory Domäne, die hier als Quelle genutzt wurde, existieren 20.000 Benutzerobjekte. Der erste Synchronisationsvorgang, zwischen Active Directory und ADAM, nahm ca. 2 Minuten und 30 Sekunden in Anspruch. Dabei wurden ca. 68,1 MB an Daten übertragen. Jede weitere Synchronisation wurde innerhalb von 5 Sekunden beendet und es wurden dabei ca. 69 KB übertragen.

Nachdem also die erste Replikation erfolgreich abgelaufen ist, kann man die oben stehende Kommandozeile als geplanten Task einrichten. Dadurch kann ein periodischer Abgleich zwischen Active Directory und ADAM sichergestellt werden. Was passiert aber mit den gelöschten Objekten? Diese bleiben bei der momentanen Konfiguration bestehen. Hier kommt jetzt das Element „" der XML Konfigurationsdatei ins Spiel. Über das Unterelement „" kann bestimmt werden, aller wie viel Sychronisationszyklen eine Überprüfung auf gelöschte Objekte vorgenommen wird. Das Unterelement „" gibt an, wie viele Objekte auf einmal untersucht werden sollen. Wenn wir in unserem Beispiel für „" den Wert „2" setzen und für „" den Wert 500, dann bedeutet dies, dass „adamsync" im schlimmsten Fall 80 Replikationszyklen benötigt, um alle Objekte auf einen eventuellen Löschvorgang zu prüfen. Findet adamsync ein im Active Directory gelöschtes Objekt, dann wird es auch in der Adaminstanz entfernt. Um die Performance hier einmal zu testen, habe ich mit drei verschiedenen Werten in „" gearbeitet.

Wert in	Dauer	Ges. und Empf. Daten
5.000	33 Sekunden	Empfangen: ca. 2MB Gesendet: ca. 1,5MB
10.000	1 Minute 20 Sekunden	Empfangen: ca. 4MB Gesendet: ca. 3MB
20.000	2 Minuten 15 Sekunden	Empfangen: ca. 8MB Gesendet: ca. 6MB

Leider gibt es bei der Synchronisation einen unschönen Nebeneffekt. Adamsync scheint bei der Synchronisation der gelöschten Objekte den LDAP Filter „(&(objectclass=user)(telephoneNumber=*))" zu nutzen. Da bei einem Löschvorgang aber das Attribut „telephoneNumber" vom Objekt entfernt wird, kann adamsync ein gelöschtes Objekt nicht korrekt erkennen. Das kann dazu führen, dass adamsync alle synchronisierten Objekte verwirft und in den Container „LostAndFound" der ADAM Partition verschiebt. Dieser Tatsache kann man aber mit einem kleinen Hack entgegenwirken. Dazu muss man im Active Directory Schema der Quelle eine kleine Anpassung im Attribut „telephoneNumber" vornehmen. Durch das Verändern der Eigenschaft „searchflags" im Attribut „telephoneNumber" kann man verhindern, dass dieses Attribut von einem Objekt entfernt wird. Dazu muss die Eigenschaft „searchflags" des Attributs „telephoneNumber" auf den dezimalen Wert 8 gesetzt werden. Dieser Wert entspricht binär dem vierten Bit.

Dadurch bleibt beim Löschen eines Objekts dieses Attribut am gelöschten Objekt erhalten und adamsync kann eine erfolgreiche Synchronisation durchführen.

Kommen wir jetzt zum letzten Punkt dieses Artikels. Jetzt muss nur noch sichergestellt werden, dass auch mit einer anonymen Anmeldung auf die Informationen im ADAM lesend zugegriffen werden kann. Um das zu ermöglichen, müssen zwei Schritte durchgeführt werden. Als erstes muss der anonymen Anmeldung erlaubt werden, sich ohne Authentifizierung mit der Telefonbuch Partition zu verbinden. Standardmäßig ist das nicht erlaubt. Um es zu ermöglichen, muss das „dsHeuristics" Attribut in den Eigenschaften des Directory Services Objekts der Konfigurationspartition auf den Wert „0000002001000" angepasst werden.

Jetzt kann zumindest schon ein LDAP Bind auf alle Partitionen der ADAM Instanz durchgeführt werden. Dadurch kann aber eine anonyme Anmeldung noch keine Objekte der einzelnen Partitionen lesen. Damit die einzelnen Partitionen auch durchsucht werden können, fügt man im einfachsten Fall das Konto „Anonymous-Anmeldung" in die ADAM Rolle „Readers" der entsprechenden Partition hinzu.

Jetzt können die Userobjekte in der ADAM Partition auch ohne Authentifizierung gelesen werden. Damit wäre es jetzt möglich, diese ADAM Instanz für das Erstellen eines Telefonbuchs zu nutzen.

Maulkorb für den OU-Admin

Frank Röder — Sun, 13 Jan 2008 19:41:20 +0000

In vielen Active-Directory-Umgebungen wird die Möglichkeit genutzt, bestimmten Mitarbeitern Berechtigungen auf das Active Directory zu geben. So könnte man zum Beispiel dem Azubi der IT-Abteilung das Recht einräumen, neue Benutzer in Active Directory anzulegen. Dadurch kann der Azubi also keinen Schaden anrichten. Er kann ja nur neue Benutzer anlegen …

Leider bringt man dadurch sein Active Directory auch in Gefahr. Durch dieses Recht könnte eine Person, die entsprechende Berechtigungen besitzt, eine unbegrenzte Anzahl von Objekten anlegen. Das heißt also, sie kann die Datenbank durch unbedarfte Experimente oder mit bösen Absichten bis zum Platzen füllen. Dadurch würde dann ein erhöhtes Replikationsaufkommen zwischen den Domänencontrollern auftreten. Die Folge wären dann erhöhte Replikationslatenzen. Durch diese Latenzen könnte es passieren, dass wichtige Informationen verspätet auf andere Domänencontroller repliziert werden. Ein weiteres mögliches Szenario wäre das Überlaufen der Festplattenpartition, auf der sich die Active Directory Datenbank befindet. Wie einfach so ein Angriff zu realisieren ist, demonstriert folgendes Skript:



set objRootDSE = GetObject("LDAP://rootDSE")

set objOU = GetObject("LDAP://ou=OU-Delegiert," & objRootDSE.Get("defaultNamingContext"))

For i=1 To 1000000

  set objUser = objOU.Create("User","cn=BenutzerNr" & i)

  objUser.Put "sAmAccountName", "BenutzerNr" & i

  objUser.Put  "givenName","Testbenutzer"

  objUser.Put "mail","hallo@hallo.de"

  objUser.Put "telePhoneNumber", "++49 (351) 123454678"

  objUser.Put "sn", "Test"

  objUser.Put "wwwHomePage","www.faq-o-matic.net"

objUser.SetInfo

objUser.AccountDisabled = False

objUser.SetPassword "Geheim$$2008"

objUser.Setinfo

next

Durch dieses Skript werden so ganz nebenbei 1.000.000 Benutzerobjekte angelegt. Diese belasten natürlich unnötigerweise die Active-Directory-Datenbank. Was kann man aber dagegen tun, um solche DoS-Attacken auf das AD zu verhindern?

Seit Windows 2003 gibt es die Möglichkeit, Kontingente auf das Active Directory zu vergeben. Dadurch kann ein Administrator bestimmen, wie viele Objekte ein Benutzer oder auch eine Sicherheitsgruppe im AD anlegen kann.

Wie funktioniert das Ganze aber? Microsoft stellt für die Verwaltung bzw. Einrichtung von Kontingenten leider kein grafisches Verwaltungsprogramm zur Verfügung. Um Kontingente auf eine Verzeichnispartition zu vergeben, muss der Administrator die Kommandozeile bemühen. Wie sieht das nun in der Praxis aus?

Nehmen wir einmal an, dass in der AD-Domäne „faq-o-matic.net“ die OU „OU-Delegiert“ existiert. Auf diese OU hat der Benutzer „Paul Schmidt“ das Recht bekommen, neue Benutzer anzulegen.

Mit dem Kommandozeilenprogramm „dsadd quota“ kann der Administrator dem Benutzer jetzt ein Kontingent einrichten.

dsadd quota -part dc=faq-o-matic,dc=net –acct faq-o-matic\p.schmidt -qlimit 500

Durch dieses Kontingent ist jetzt der Benutzer Paul Schmidt auf das Anlegen von 500 Benutzern beschränkt.
Wie kann man jetzt aber die bereits angelegten Kontingente einsehen? Für diese Aufgabe kann man zum einen das Snapin „Active Directory Benutzer und Computer“ benutzen oder auch die Kommandozeile bemühen.

Um alle Kontingente einzusehen, reicht ein:

dsquery quota

Wer es etwas genauer wissen will, kann die Kommandozeile noch erweitern.

dsquery quota | dsget quota -dn -acct -qlimit

Wenn man jetzt noch einsehen will, wieviel ein Benutzer bereits von seinem Kontingent verbraucht hat, kann man das Kommandozeilenprogramm „dsget“ einsetzen.

dsget partition „dc=faq-o-matic,dc=net“ -topobjowner

Durch dieses Kommando kann man einsehen, wie viele Objekte ein Benutzer oder eine Gruppe in der angegebenen Partition besitzt. Standardmäßig gibt „dsget“ die ersten top zehn Benutzer aus. Man kann hier hinter den Parameter „-topjobowner“ eine Zahl angeben, die beeinflusst, wie viele Benutzer oder Gruppen angezeigt werden. Durch die Angabe von „0“ werden alle Benutzer angezeigt.
Vorsicht! Bei der Angabe von „0“ kann der Domänencontroller stark ausgelastet werden und die Abfrage kann sehr viel Zeit in Anspruch nehmen.

Was ist aber, wenn Paul vorhandene Objekte gelöscht hat? Werden diese Objekte auch in das Kontingent mit einbezogen? Die Antwort für diese Frage lautet „jein“. Wenn der Benutzer Objekte löscht, dann werden diese zu 100% für die Dauer der Tombstone Lifetime auf sein Kontingent angerechnet. In einer einheitlichen Umgebung unter Windows 2003 SP1, die nicht durch ein Update von Windows 2000 bzw. Windows 2003 installiert wurde, beträgt die Tombstone Lifetime 180 Tage. Unser Benutzer muss also für 180 Tage auch mit den gelöschten Objekten leben.
Windows wäre aber nicht Windows, wenn es dort nicht noch eine Möglichkeit gäbe, dieses Problem zu umgehen. Man kann für jede Partition eine globale Einstellung vornehmen, zu wie viel Prozent ein gelöschtes Objekt in die Kontingentberechnung eingeht. Diese Festlegung kann über die Kommandozeile getroffen werden:

dsmod partition "dc=faq-o-matic,dc=net" -qtmbstnwt 10

ACHTUNG! Der Parameter „-qtmbstnwt“ ist in der Hilfe von „dsmod partition“ falsch dargestellt. Dort steht als erforderlicher Parameter „-qtmbstawt“. Dieser Eintrag ist falsch!

Was heißt das nun in der Praxis:

In der obigen Kommandozeile haben wir also den Prozentsatz für die gelöschten Objekte in der Domänenpartition auf 10 Prozent festgelegt. Wenn unser Nutzer Paul ein Kontingent von 350 Objekten hat, dann kann er 3500 gelöschte Objekte besitzen, bevor sein Kontingent erschöpft ist.

Jetzt kommt natürlich der Test, ob unser oben angelegtes Kontingent auch Wirkung zeigt. Paul wird jetzt das Skript auf unser AD loslassen und damit den Versuch starten, unser AD lahm zu legen. Kurz nachdem Paul das Skript ausgeführt hat, schmettert ihm das Active Directory eine Fehlermeldung entgegen.

Pauls Kontingent wurde erschöpft und er kann keine weiteren Objekte im Active Directory anlegen. Dadurch wurde Pauls Angriff auf das AD verhindert.

Schema-Versionen vergleichen

Nils Kaczenski — Sun, 21 Oct 2007 14:53:00 +0000

In dem kürzlich hier erschienenen Artikel "Schema-Erweiterungen auffinden" habe ich einen manuellen Weg beschrieben, mit dem sich Erweiterungen im Schema des Active Directory über einen Vergleich von zwei CSV-Exportdateien ausfindig machen lassen. Mit dem Skript "CompareSchemaCSV.vbs" lässt sich dies nun automatisieren. Das Skript gibt es hier zum Download:

Note: There is a file embedded within this post, please visit this post to download the file.

Update 7. 12. 2011: Wie ich gerade erfahre, gibt es im Lieferumfang aktueller Windows-Server ein Werkzeug, das sehr ähnlich vorgeht. Hier ein Blog-Artikel dazu vom AD-Team bei Microsoft:

[Determine Applied Schema Extensions with AD DS/LDS Schema Analyzer - Ask the Directory Services Team - Site Home - TechNet Blogs]
http://blogs.technet.com/b/askds/archive/2009/01/20/determine-applied-schema-extensions-with-ad-ds-lds-schema-analyzer.aspx

Vorbereitung

Genau wie bei der manuellen Methode müssen auch hier zwei CSV-Exportdateien des AD-Schema vorhanden sein. Die erste Datei stellt die Vergleichsgrundlage dar ("Baseline") und enthält in der Regel das Schema in einer Version, die bekannt ist (z.B. Windows Server 2003 R2 mit Exchange Server 2003). Die zweite Datei enthält einen aktuellen Export der zu untersuchenden Schema-Version. Ein Kommando, mit dem sich diese Exportdatei erzeugen lässt, ist das Folgende:

csvde -f "C:\data\schema-baseline.txt"
-d "CN=Schema,CN=Configuration,DC=faq-o-matic,DC=net"
-r "(|(objectClass=attributeSchema)(objectClass=classSchema))"
-l "name,whenCreated,whenChanged,description,mayContain,mustContain,
objectClass,objectCategory,attributeID,governsID,subClassOf,
isSingleValued,lDAPDisplayName"

Dieses Kommando muss in einer einzigen zusammenhängenden Zeile auf einem Windows-Server in einem CMD-Fenster ausgeführt werden. Der Dateipfad und der Domänenname (beide hier kursiv) müssen natürlich angepasst werden. Eine passende Baseline-Datei (für Windows Server 2003 R2, R2 mit Exchange 2003 sowie für Windows Server 2008) kann man bei uns auch herunterladen:

Note: There is a file embedded within this post, please visit this post to download the file.Nun müssen die Speicherpfade beider Dateien in den Skriptcode eingetragen werden. Dazu öffnet man die Datei in einem Editor und passt die Zeilen 27 und 30 entsprechend an.

Ausführung

Das Skript wird in einem CMD-Fenster ausgeführt. Da es natürlich viel Text ausgibt, muss es mit "cscript.exe" ausgeführt werden, ähnlich dem folgenden Kommando:

cscript C:\Pfad\CompareSchemaCSV.exe

Achtung: Das Skript nicht per Doppelklick oder ohne cscript ausführen, sonst gehen sehr viele Dialogboxen auf.

Nun vergleicht das Skript beide Exportdateien und gibt alle Zeilen auf der Kommandozeile aus, die in der zweiten Datei enthalten sind, aber in der ersten Datei fehlen. Als letztes wird die Zahl der gefundenen Unterschiede angezeigt.

Schema-Erweiterungen auffinden

Nils Kaczenski — Mon, 21 May 2007 15:01:00 +0000

Wer eine fremde Active-Directory-Umgebung übernimmt oder bearbeitet, steht vor der Frage, in welchem Zustand sich diese befindet. Neben der Konfiguration der Umgebung kann es auch relevant sein, ob das AD-Schema erweitert wurde. Leider ist es nicht ganz einfach, Schema-Erweiterungen nachträglich ausfindig zu machen, wenn sie nicht ordentlich dokumentiert worden sind. Mit ein wenig manuellem Aufwand lassen sich die Informationen aber relativ schnell herausfinden.

Die Vergleichs-Methode

Der Weg geht über den Vergleich der Produktionsumgebung mit einer Referenzumgebung. Im ersten Schritt installiert man also ein Active Directory in eine virtuelle Umgebung, das denselben Service-Pack- und Patchlevel hat wie die Produktionsumgebung. Falls Applikationen eingesetzt werden, von denen bekannt ist, dass sie das AD-Schema erweitern (z. B. Exchange), sollten auch die Schema-Erweiterungen dieser Applikationen installiert werden.

Der zweite Schritt besteht im Export des Schemas beider Umgebungen. Dazu führt man auf einem Domänencontroller der Produktionsumgebung folgendes Kommando in der Eingabeaufforderung durch (das ganze Kommando bildet eine zusammenhängende Zeile):

csvde -f D:\temp\schema.txt
-d "CN=Schema,CN=Configuration,DC=DOMAIN,DC=TLD"
- r "(|(objectClass=attributeSchema)(objectClass=classSchema))"
-l "name,whenCreated,whenChanged,mayContain,
mustContain,objectClass,objectCategory,governsID,
subClassOf,attributeID,isSingleValued,lDAPDisplayName"

Der Dateipfad "D:\temp\schema.txt" kann natürlich an die realen Pfade angepasst werden. Ebenso muss statt "DC=DOMAIN,DC=TLD" der LDAP-Pfad der echten Domäne angegeben werden.

Dasselbe Kommando wird nun in der Referenzumgebung ausgeführt.

Im dritten Schritt werden beide Textdateien in Excel als CSV-Dateien geöffnet (Trennzeichen: Komma). Für beide Dateien wird in Excel dieselbe Sortierung eingestellt (z. B. zuerst nach "objectClass", dann nach "name"), und dann werden beide nebeneinander angezeigt. So lassen sich die Unterschiede der Schemata (Klassen und Attribute) schnell ausfindig machen. Dazu eignen sich die Funktionen Anordnen und Nebeneinander vergleichen aus dem Fenster-Menü von Excel (unter Excel 2007 woanders zu finden) sehr gut.

Um den Vorgang zu vereinfachen, habe ich einige Schema-Exportdateien im CSV-Format vorbereitet, die als Referenz dienen können. Vor derm Vergleich sollte evtl. der Domänenname (lautet auf "DC=faq-o-matic,DC=net") geändert werden, um automatisierte Vergleiche zu vereinfachen. Die Dateien finden sich hier:

Note: There is a file embedded within this post, please visit this post to download the file.

Update 21. 10. 2007: Um das Ganze noch einfacher zu machen, habe ich ein Skript gepostet, das den Vergleich beider Exportdateien automatisiert. Der manuelle Vergleich mit Excel kann so entfallen. Mehr dazu: Schema-Versionen vergleichen

Die dsquery-Methode

Dean Wells hat ein Skript geschrieben, das mit Hilfe von repadmin.exe aus den Support Tools und dsquery.exe von Windows Server 2003 einen Vergleich des aktuellen Schemas mit dem Installationszustand erzeugt. Damit lassen sich auch Modifikationen an Standardobjekten identifizieren. Vorsicht: Das Skript erzeugt viele Daten, insbesondere wenn Exchange oder andere große Schema-Erweiterungen installiert wurden. Der Download findet sich hier: http://www.activedir.org/Downloads/Files/SchemaDiff.zip

(Danke für den Hinweis an Norbert Fehlauer)

Wie kann ich beeinflussen, welche Attribute beim Kopieren eines Benutzers kopiert werden?

Frank Röder — Sun, 18 Jun 2006 15:06:00 +0000

Wenn man in Active Directory ein vorhandenes Benutzerobjekt kopiert, dann wird eine Untermenge der verfügbaren Attribute in das neue Objekt übernommen. Wie kann man aber steuern, welche Attribute mit kopiert werden und welche nicht?

Die Antwort ist: Über das Schema. Im AD-Schema ist definiert, welche Attribute beim Kopieren von Objekten über die GUI-Tools mitopiert werden sollen. Ob sich ein Tool, das zur Administration eingesetzt wird, allerdings daran hält, ist Sache des Toolprogrammierers. Der Kopiervorgang wird hier nicht über Active Directory ausgeführt, sondern durch das Administrationsprogramm.

Wer die zu kopierenden Attribute also selbst beeinflussen will, muss das AD-Schema bearbeiten. Achtung: Dies ist ein hochsensibler Vorgang – man sollte wissen, was man tut, und vorher für eine ordentliche Datensicherung sorgen!

Manipulieren der zu kopierenden Attribute

Als Erstes muss man hierfür das Snapin für das "Active Directory Schema" registrieren. Dies kann man durch die Eingabe von "regsvr32 schmmgmt.dll" unter "Start" > "Ausführen" erreichen. Danach kann man das "Active Directory Schema Snapin" in einer MMC nutzen:

Flashfilm: regsvr32

Ich möchte anhand des Attributes "logonHours" demonstrieren, wie das Kopieren eines Attributes verhindert werden kann. Dazu habe ich einen Testbenutzer angelegt, der sich nur zu bestimmten Uhrzeiten anmelden darf. Dieses Attribut wird standardmässig beim Kopiervorgang in das neue Benutzerobjekt übernommen. Durch eine Veränderung der Eigenschaften des Attributs kann man ein Kopieren verhindern.

Flashfilm: Kopieren abschalten

TechNet-Webcast zum AD-Schema

Nils Kaczenski — Sat, 20 May 2006 14:40:00 +0000

Am 28. April 2006 habe ich für Microsoft TechNet einen einstündigen Webcast über die Arbeit mit dem Schema des Active Directory gehalten. Es geht dabei neben einigen theoretischen Grundlagen zum Schema vor allem um praktische Aspekte bei der Erweiterung des Schema. Mit vielen Praxisdemos beleuchte ich, was ihr berücksichtigen solltet, wenn ihr mit dem AD-Schema arbeiten wollt, wann ihr lieber die Finger vom Schema lasst und wir ihr sicherstellt, dass eure Schema-Erweiterung auch auf technisch sauber verläuft. Abschließend demonstriere ich, wie ihr eure Schema-Erweiterung dann auch ohne riesige Programmierkenntnisse nutzen könnt.

Der Download des Webcast ist möglich über: http://www.microsoft.com/germany/technet/webcasts/eventdetail.aspx?EventID=1032297149

Wo finde ich eine Dokumentation des AD-Schemas?

Nils Kaczenski — Fri, 17 Oct 2003 14:28:00 +0000

Folgende sind die einfachsten Möglichkeiten:

Untersuche das Schema mit dem MMC-Snap-in "Active Directory-Schema" (bei installiertem Adminpak das Snap-in zunächst registrieren mit regsvr32 schmmgmt.dll, dann das Snap-in zu einer MMC hinzufügen)
Die Schema-Doku im MSDN (msdn.microsoft.com)
Exportiere das Schema in eine Textdatei, die du mit Excel o. ä. ansehen kannst. Das geht z. B. mit csvde.exe:
csvde -d "cn=schema,cn=configuration,dc=deinedomain,dc=local" -u -n -f schema.txt

faq-o-matic.net » AD-Schema

Video: Active Directory als Datenspeicher?

Verwandte Beiträge:

AD-Schemaerweiterung: Ein paar Hinweise

Wie kritisch ist eine Schemaerweiterung?

Die Grenzen

Bedarf klären

Eingangsuntersuchung

Test

Vorbereitung

Jetzt wird’s ernst!

Isolation des Schema-Masters – auf eigene Gefahr!

Weitere Artikel

Verwandte Beiträge:

\\ice:2008: Active Directory als Datenspeicher? Die Folien

Verwandte Beiträge:

Adam und Eva

Verwandte Beiträge:

Maulkorb für den OU-Admin

Verwandte Beiträge:

Schema-Versionen vergleichen

Verwandte Beiträge:

Schema-Erweiterungen auffinden

Verwandte Beiträge:

Wie kann ich beeinflussen, welche Attribute beim Kopieren eines Benutzers kopiert werden?

Manipulieren der zu kopierenden Attribute

Verwandte Beiträge:

TechNet-Webcast zum AD-Schema

Verwandte Beiträge:

Wo finde ich eine Dokumentation des AD-Schemas?

Verwandte Beiträge: