faq-o-matic.net » AD: Daten bearbeiten

dsmove und sein beständiger Fehler

Nils Kaczenski — Thu, 18 Mar 2010 09:29:51 +0000

Mit dem Kommando “dsmove” kann man seit Windows Server 2003 AD-Objekte per Kommandozeile verschieben. Anders als die anderen ds*-Tools kommt dsmove leider nicht mit dem Piping klar: Zwar kann man etwa die Ausgabe eines “dsquery”-Befehls per Pipe an dsmove weiterleiten und so nacheinander mehrere Objekte an den Befehl verfüttern – doch dsmove wird nur das erste übergebene Objekt verschieben und danach einen Fehler ausgeben. Leider gilt das auch noch in Windows Server 2008 R2.

Möchte man eine Massenverschiebung ausführen, so muss man sich mit folgendem Trick behelfen. Das Kommando verschiebt alle Objekte, deren Anmeldename mit “A” beginnt, in eine andere OU. Achtung, die “for”-Zeile bis zur zweiten öffnenden Klammer ist eine einzige Zeile.

for /f "delims=" %%a in ('dsquery user "OU=AlteOU,DC=dom,DC=faq-o-matic,DC=net" -samid a* -limit 0') do (
dsmove %%a -newparent "OU=NeueOU,OU=DC=dom,DC=faq-o-matic,DC=net"
)

Diese Syntax gilt bei Ausführung per Batch – direkt auf der Kommandozeile muss man “%%a” in “%a” ändern. Möchte man das zunächst gefahrlos testen, so fügt man vor dem “dsmove” noch das Kommando “ECHO” ein und leitet die Ausgabe in eine Datei um. Dann wird dsmove nicht aktiv, sondern das Kommando erzeugt nur die Kommandos.

Achtung: Auch mit Umlauten kommt diese Technik nur unter bestimmten Umständen klar, nämlich dann, wenn die Codepage des CMD-Fensters auf 850 steht. Das ist zwar normalerweise der Fall, aber um sicherzugehen, sollte man in einem Batch zu Beginn das Kommando “chcp 850” einfügen. Die Schalter “uc/uci/uco” der ds*-Tools helfen nicht, weil sie keine gültigen Daten weitergeben.

(Hier noch der Verweis auf meine Fundstelle – wie immer bei ExpertsExchange ganz nach unten scrollen:
http://www.experts-exchange.com/Programming/Languages/Scripting/Shell/Batch/Q_22997808.html)

dsacls in Extremsituation

Nils Kaczenski — Thu, 11 Mar 2010 16:33:04 +0000

dsacls.exe ist das Kommandozeilenwerkzeug, mit dem man Berechtigungen auf Objekte in Active Directory manipulieren kann. Heute hatte ich Gelegenheit, es in einer Extremsituation zu nutzen.

In einem Testszenario sollten für 16.308 Benutzerkonten die AD-Zugriffsberechtigungen geändert werden. Für jedes einzelne Objekt gab es sieben Änderungen: Zwei vorhandene Berechtigungen wurden entfernt und fünf neue hinzugefügt. Das Ganze wurde über eine große Batchdatei gesteuert, die für jedes der Objekte die sieben dsacls-Kommandos ausführte. Das passierte auf einem Domänencontroller unter Windows Server 2008 R2, der in einer nicht optimierten VM lief (nur 512 MB RAM und eine einzige virtuelle Festplatte).

Der Vorgang dauerte etwas weniger als zwei Stunden. Erst war ich überrascht über die lange Bearbeitungszeit, aber dann habe ich mal nachgerechnet:

16.308 Objekte mit jeweils sieben ACL-Änderungen ergibt 114.156 einzelne ACL-Änderungen.
Die Ausführung dauerte etwas weniger als zwei Stunden, was etwa 1000 ACL-Änderungen pro Minute ergibt.
Das wiederum bedeutet, dass etwas mehr als 15 Änderungen pro Sekunde erfolgten.
Hierbei muss man – neben dem geringen Arbeitsspeicher des Servers – berücksichtigen, dass jede Änderung im Ereignisprotokoll mitgeschrieben wurde und dass dsacls bei jeder Ausführung die Berechtigungen des Objekts als Text ausgibt, hier umgeleitet in eine Datei.
Die Datenbank-Dateigröße des AD änderte sich durch diesen Vorgang übrigens nicht, was wahrscheinlich auf die pro Objekt geringe Anzahl geänderter ACLs zurückzuführen ist.

„Benutzer kann Passwort nicht ändern“-Option auf Abwegen

Florian Frommherz — Wed, 25 Mar 2009 10:35:30 +0000

Neulich rief ein Kollege bei mir an und berichtete mir, dass einige Benutzer ihre Domänenpasswörter nicht mehr ändern konnten. Sie erhielten folgende Fehlermeldung:

Da es in den Benutzerkontenoptionen eine Checkbox namens „Benutzer kann Passwort nicht ändern“ gibt, die ein Verändern des Benutzerpasswords durch den Benutzer selbst verhindert, schloss ich darauf, dass das Problem dort liegen könnte. Doch die Checkbox war nicht aktiviert, wie mir mein Kollege versicherte.

Obwohl wir beide etwas ratlos waren, fand mein Kollege zumindest einen Workaround für das Problem: er aktivierte die Checkbox „Benutzer kann Passwort nicht ändern“, übernahm die Änderung am Benutzerkonto, löschte die Checkbox wieder und übernahm die Änderung erneut. Das half ihm sicherzustellen, dass die Benutzer ihre Passworte wieder ändern konnten.

Da das sicherlich kein Dauerzustand sein konnte und wir den wahren Grund für das Problem herausfinden wollten, haben wir uns weiterhin bemüht, die Ursache des Problems zu finden. Wir sprachen über mögliche Faktoren, die das Problem hätten hervorrufen können und nahmen uns einige Skripte zur Brust, die zur Verwaltung und Provisionierung von Benutzern verwandt wurden. In der Tat wurden wir fündig: der Kunde setzte ein Skript ein, das Benutzerkonten für Kurzzeitmitarbeiter anlegte. Hierbei wurde ein festes Passwort vergeben, das nach dem maximalen Kennwortalter, das in der Passwortrichtlinie vorgegeben ist, abläuft. Die Benutzer müssen dann zu ihrem Manager und das Passwort entweder verlängern lassen oder die Firma verlassen Zugegeben, diese Methode ist nicht gerade die Beste, zumal es ja die „Konto läuft ab:“-Option in den Konteneinstellungen gibt und extra hierfür entwickelt wurde.

Das eigentliche Problem war folgendes: das Skript machte keine gute Arbeit beim Verbieten der Kennwortänderung durch den Benutzer, denn es löschte einfach zwei Standardberechtigungen aus der Berechtigungsliste des Benutzerobjektes:

Das scheint erst mal kein Problem zu sein, denn schließlich tut das Skript das, für was es bezahlt wird. Schlecht nur, dass „Active Directory Benutzer und Computer“ diese Methode nicht kennt und dementsprechend auch die Checkbox zu „Benutzer kann Kennwort nicht ändern“ anzeigt. Was „Active Directory Benutzer und Computer“ erwartet – und was es selbst auch verändert, wenn die Checkbox aktiviert wird – ist, dass das Recht „Change Password“ für die „Jeder“ (Everyone) und „Selbst“ (Self)-Autoritäten verweigert wird. Diese beiden Einträge werden zur Berechtigungsliste hinzugefügt und – sollte die Checkbox wieder gelöscht werden, entfernt. Zusätzlich zum Entfernen der „verweigern“-Berechtigungen werden die im Bild markierten Berechtigungen „Change Password“ für „Jeder“ und „Selbst“ zur Liste hinzugefügt. Das ist auch der Grund, warum der Workaround meines Kollegen funktioniert hat.

Und die Moral von der Geschicht? Wenn du wilde Skripte schreiben möchtest, schau doch mal nach, ob’s die Funktionalität nicht schon fertig gibt. Falls es sie schon fertig gibt, schau doch auch gleich noch nach, wie die Fertiglösung „hinter den Kulissen“ funktioniert – das erspart Ärger mit der Checkbox.

Umbenennen einer AD-Domäne

Mark Heitbrink — Tue, 02 Sep 2008 06:30:05 +0000

rendom.exe: Umbenennen einer Domäne – Schritt für Schritt. Dieses PDF-Dokument beschreibt den Idealfall einer Domänen-Umbenennung in Active Directory. Verwandte Beiträge: Kann ich eine Domäne oder einen DC umbenennen? Das Umbenennen einer Domäne oder eines Domänencontrollers wurde zwischen Windows... Wie kann man einen Domänencontroller unter Windows Server 2003 umbenennen? Wenn man einen Domänencontroller umbenennen muss, so kann [...]

AD-Adressen im Sekretariat bearbeiten lassen

Nils Kaczenski — Mon, 23 Jun 2008 09:14:56 +0000

Active Directory ist in vielen Unternehmen die zentrale Adressdatenbank für alle Mitarbeiterinnen und Mitarbeiter – vor allem, wenn Exchange eingesetzt wird. Dadurch tritt aber schnell ein Rollenkonflikt auf: Änderungsrechte im AD hat meist nur die IT-Abteilung. Die Pflege der internen Adressdaten ist aber in den meisten Firmen eigentlich eine Aufgabe der Personalabteilung oder des Sekretariats.

Kein Problem – schließlich kennt Active Directory ein sehr umfassendes Berechtigungskonzept. Schnell den zuständigen Mitarbeitern die nötigen Rechte gegeben, und schon ist der Admin die lästige Adresspflege los.

Kein Problem? Doch. Denn ganz so einfach ist es meist nicht. Zunächst einmal müssen die nötigen Berechtigungen überhaupt identifiziert werden. Dann muss man sie zuweisen. Und schließlich benötigt die Personalabteilung, das Sekretariat oder wer eben zuständig sein soll, eine passende Eingabemöglichkeit zur Pflege der Daten. Gut, also frisch ans Werk!

Schritt 1: Datenfelder identifizieren

Die eigentliche Identifikation, welche Daten denn bearbeitet werden sollen, kann nur innerhalb der jeweiligen Firma vorgenommen werden, idealerweise von den Personen selbst, die die Daten pflegen müssen (bzw. die die Verantwortung dafür tragen). Die Zuordnung, welche Felder bzw. Attribute in Active Directory dahinter stehen, geschieht dann wiederum durch die IT-Abteilung. Es gibt eine ganze Reihe von Übersichten, welche Einträge in den Verwaltungsprogrammen oder in Outlook von Active Directory mit welchen Namen angesprochen werden. Hier eine Auswahl:

[faq-o-matic.net » Active Directory: LDAP-Feldnamen]
http://www.faq-o-matic.net/2002/09/21/active-directory-ldap-feldnamen/

[MSXFAQ.DE - AD LDAPFelder]
http://www.msxfaq.de/code/adfelder.htm

[SelfADSI : Attribute für ADS User]
http://www.selfadsi.de/attadus.htm

Schritt 2: Berechtigungen setzen

Berechtigungen sollten in Active Directory möglichst sparsam gesetzt werden: Jeder Berechtigungseintrag wird in der AD-Datenbank gespeichert und mit ihr repliziert. Unnötige Einträge verursachen also unnötige Last. Umgekehrt sollten Berechtigungen natürlich möglichst gezielt erteilt werden nach dem Prinzip "Least Privilege" – also nur das erlauben, was wirklich benötigt wird.

In Produktionsumgebungen hat es sich bewährt, AD-Berechtigungen mit dem Kommandozeilenwerkzeug dsacls.exe zu setzen. Dies kann per Skript geschehen – was den unschätzbaren Vorteil birgt, dass das Skript gleichzeitig eine hervorragende Dokumentation ist. Zudem kann so ein Skript zunächst in einem Testlabor entwickelt und geprüft werden, bevor man dann die fertige Fassung auf das Produktionsnetzwerk loslässt – das geht mit grafischen Tools natürlich nicht.

dsacls.exe ist in Windows Server 2008 enthalten. In älteren Windows-Versionen kann es mit den Support Tools nachgerüstet werden. Ein Ausschnitt aus einem dsacls-Skript, das gezielt Berechtigungen auf der Attributebene erteilt, folgt hier:

@echo off
set OURoot="OU=Vertrieb,OU=Benutzer,DC=ad2008,DC=faq-o-matic,DC=net"
set GROUP=AD2008\Adressbearbeitung
set PERM=RPWP 

dsacls %OURoot% /I:S /G %GROUP%:%PERM%;displayName;user
dsacls %OURoot% /I:S /G %GROUP%:%PERM%;givenName;user
dsacls %OURoot% /I:S /G %GROUP%:%PERM%;sn;user
dsacls %OURoot% /I:S /G %GROUP%:%PERM%;telephoneNumber;user

Zunächst definiert das Skript drei Variablen, damit der folgende Aufbau möglichst flexibel bleibt. Die erste ist die Basis-OU: Meist sollen Berechtigungen für alle Objekte unterhalb eines bestimmten AD-Astes erteilt werden – hier ist das die OU "Benutzer/Vertrieb" in der eigenen Domäne. Als zweites wird die Gruppe definiert, die die Berechtigungen erhalten soll (hier: Adressbearbeitung). Als drittes folgt dann ein Kürzel für die Berechtigung, die erteilt werden soll: RPWP steht für "Read Property, Write Property", also Lese- und Schreibrechte für ein einzelnes Attribut. Durch diese Vordefinition lässt sich das Skript später leicht anpassen.

Die eigentlichen dsacls-Kommandos erfolgen dann einzeln für jedes Attribut und nutzen die vorher definierten Variablen. Als erstes erwartet dsacls die Angabe des Objekts, das zu bearbeiten ist (hier in der Variablen %OURoot% abgelegt, also konkret die OU "Benutzer/Vertrieb"). Danach steht mit dem Parameter /I die Angabe der Vererbung; "S" steht für "Subobjects", die Berechtigungen werden also nur auf untergeordnete Objekte vergeben, nicht aber auf die OU selbst. Mit /G gibt man dann die zu erteilende (G für "grant") Berechtigung als vierteiligen String an: Zuerst die zu berechtigende Gruppe (Variable %GROUP%), nach einem Doppelpunkt folgt dann in drei Teilen die Berechtigung. Das erste Element ist der Berechtigungscode, der hier über die zuvor definierte Variable %PERM% definiert ist. Nach einem Semikolon steht das Objekt oder Attribut, für das die Berechtigung gilt – hier also der LDAP-Name des jeweiligen Attributs. Nach dem letzten Semikolon steht noch, für welche Objektklasse dies anzuwenden ist: uns geht es nur um Benutzerobjekte. Diese letzte Angabe ist optional.

Die dsacls-Syntax ist sehr umfassend und stark gewöhnungsbedürftig. Daher sollte man seine Skripts in einer separaten Laborumgebung gut testen. Praktischerweise kennt dsacls auch einen Schalter, mit dem man alle Berechtigungen für einen AD-Zweig wieder auf den Installationsstandard zurücksetzen kann:

dsacls "OU=Vertrieb,OU=Benutzer,DC=ad2008,DC=faq-o-matic,DC=net" /S

Schritt 3: Adressen bearbeiten

Bleibt die Frage: Wie kann die Personalchefin oder der Praktikant im Sekretariat denn die Adressen nun bearbeiten? Dafür gibt es mehrere Möglichkeiten. Eine davon ist das AD-Verwaltungsprogramm: Man könnte dem Benutzer eine angepasste MMC-Konsole geben, die das Snap-in "Active Directory-Benutzer und -Computer" enthält und auf die gewünschte OU-Ebene fokussiert ist. Das Snap-in lässt tatsächlich nur die Bearbeitung der Felder zu, für die der angemeldete Benutzer Berechtigungen hat. Andere Felder sind (größtenteils) ausgegraut. Nachteil: Es sind eben nicht alle Felder inaktiv, die der Benutzer nicht bearbeiten darf – bei manchen kann er zunächst einen Eintrag machen und bekommt erst nach dem "OK"-Klick die Fehlermeldung, dass der Zugriff verweigert wurde. Außerdem lassen sich die Registerkarten der MMC nicht sinnvoll anpassen – die Datenfelder sind also auf mehrere Karten verteilt, und ganz nebenbei kann der Bearbeiter auch Dinge sehen, die ihn eigentlich nichts angehen (z.B. Gruppenmitgliedschaften oder Konto-Optionen).

Eine sinnvolle Lösung besteht in einem angepassten Skript, das dem Bearbeiter nur die Felder und Inhalte zeigt, die in seiner Situation von Interesse sind. Einen Prototyp eines solchen Skripts stellen wir hier zur Verfügung. Es gewährt Zugriff auf einige wichtige Adressfelder und ist leicht erweiterbar oder auch um zusätzliche Logik und Funktionen zu ergänzen – beispielsweise eine Logging-Funktion, die alle Änderungen aufzeichnet, um Fehler leichter beheben zu können.

Bedienung

Nach dem Aufruf der Datei "faq-o-matic.net-Adressbearbeitung.hta" öffnet sich ein Fenster mit einem Eingabefeld. Hier kann man einen gesuchten Namen eingeben (bzw. einen Teil davon) und dann auf "Benutzer finden" klicken (Tastaturkürzel: Alt-F; bitte nicht Return drücken). Das Skript präsentiert dann die gefundenen Objekte; das passende wählt man mit dem Button "Benutzer auswählen" aus.

Nun zeigt das Skript die Adressdaten des gewählten Benutzers an und lässt die Bearbeitung zu; alle geänderten Felder werden gelb hinterlegt. Ein Klick auf "Änderungen speichern" schreibt die bearbeiteten Daten zurück ins Active Directory (natürlich nur, wenn der ausführende Benutzer dies darf).

Erweiterung

Das Skript ist bewusst nur als Prototyp aufgebaut. Es ist aber recht leicht zu erweitern:

Zusätzliche Felder (Attribute) zum Anzeigen und Bearbeiten kann man im Skriptcode einfach hinterlegen. Dazu öffnet man die HTA-Datei mit einem Texteditor. Alle anzuzeigenden Felder sind als Array mit zwei Dimensionen angegeben. Beispiel:
arrFeld(6, 0) = "streetAddress"
arrFeld(6, 1) = "Straße"
Die erste Angabe (0 in der zweiten Array-Dimension) ist der LDAP-Feldname des Attributs. Die zweite Angabe (1 in der zweiten Array-Dimension) ist der Text, der in der Benutzermaske angezeigt werden soll.
Auf diese Weise kann man zusätzliche Felder recht simpel hinzufügen – einfach erst den LDAP-Feldnamen, dann die Bezeichnung. Zweierlei ist zu beachten:
1. Die erste Array-Dimension gibt die Reihenfolge in der Maske vor (im Original von 0 (Anzeigename) bis 11 (Fax)); für eine andere Reihenfolge kann man die Nummerierung einfach ändern.
2. Wenn man zusätzliche Felder hinzufügt, muss die Gesamtzahl im Skript geändert werden. Dazu folgende Zeile bearbeiten:
Dim arrFeld(11,1)
Hier die erste Zahl ändern, sodass sie 1 geringer ist als die Zahl der Felder (bei 23 Feldern also "Dim arrFeld(22,1)").
Weitere Funktionen zu ergänzen, setzt natürlich etwas Scripting-Erfahrung und Beschäftigung mit dem Code voraus. Denkbar ist z.B. eine Protokollierung aller Änderungen (dürfte z.B. in der Prozedur "speichereDaten()" leicht einzubauen sein) oder auch eine Plausibilitätsprüfung für einzelne Felder.

Hier ist der Download des Skripts:

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.

Excel: Admins unbekannter Liebling

Nils Kaczenski — Sat, 19 Jan 2008 10:38:47 +0000

Excel ist ein beliebtes Werkzeug für vielerlei Aufgaben. Am meisten lieben es – einem gängigen Klischee folgend – Buchhalterinnen und Controller. Viele Administratoren nutzen es nur, um einfache Listen zu verwalten. Dabei kann Excel viel mehr für den Admin tun!

Die Tabellenkalkulation eignet sich nämlich hervorragend als Skriptgenerator und Programmierhilfe. Dazu kann man sich gut der Funktionen bedienen, die Zeichenketten verarbeiten. In Zusammenarbeit mit der Importfunktion lässt sich damit so manche Aufgabe in wenigen Minuten lösen, für die man manuell Stunden benötigen würde. Und das alles ohne Programmierkenntnisse und langes Debugging komplexer Skripts.

Das Geheimnis liegt darin, dass viele Massenoperationen im Prinzip mit (relativ) einfachen Kommandozeilenbefehlen auf eine vorhandene Liste von Objekten angewendet werden können. Eine typische Frage in den Newsgroups ist etwa: „Ich habe eine Liste von neuen Mitarbeitern, die ich alle in Active Directory als Benutzer anlegen muss. Wie kann ich diese Liste in die Domäne importieren?" Oft wird als Antwort auf diverse Import-Programme oder auf komplexe VBS- oder PowerShell-Skripts verwiesen. Mit Excel kann aber auch ein Nichtprogrammierer schnell zum Erfolg kommen.

Mehrere Benutzer schnell anlegen

Hier zunächst eine einfache Variante: Ein einzelnes Benutzerkonto lässt sich mit dem Kommandozeilenbefehl „net user" in der Domäne anlegen. Für Ellen Bogen könnte dies mit ein paar Zusatzinformationen so lauten (Kommando in einer einzigen Zeile):

net user EllenB GeheimesKennwort /add
   /FullName:"Ellen Bogen" /ScriptPath:vertrieb.bat /domain

Angenommen, in einer Excel-Liste sind bereits der Name (Spalte A), der Anmeldename (Spalte B), das Startkennwort (Spalte C) und die Abteilung (Spalte D) für mehrere neue Benutzer vorgegeben – dann eignet sich folgende Formel in Spalte E, jedes Benutzerkonto zu erzeugen:

="net user " & B2 & " " & C2 & " /add /Fullname:""" & A2 & """ /Scriptpath:" &D2 & ".bat /domain"

Das sieht auf den ersten Blick etwas komplex aus, ist aber gar nicht so schlimm. Der Reihe nach:

Das Gleichheitszeichen leitet eine Formel ein. Danach kommen Anführungsstriche, um einen festen Text anzugeben – hier das Kommando „net user".
Nach „net user" muss der Benutzername folgen, der in Zelle B2 steht. Also Anführungsstriche schließen, mit & der Zeichenkette einen neuen Teil hinzufügen und auf Zelle B2 verweisen.
Als nächstes kommt das Kennwort, durch ein Leerzeichen getrennt. Also wieder ein &, um die nächste Zeichenkette anzufügen, hier ein einzelnes Leerzeichen, das auch wieder in Anführungsstriche eingefasst wird. Das Kennwort steht in Zelle C2, auf die wieder mit & verwiesen wird.
Als nächstes kommt wieder ein fester Text, nämlich die Optionsschalter „/add" und „FullName". Letzterer erwartet nach einem Leerzeichen den Anzeigenamen des Benutzers. Da dieser Name ein Leerzeichen enthält, muss er auf der Kommandozeile in Anführungsstriche gesetzt werden. Nun wird es etwas wild: Die Anführungsstriche nutzt Excel ja bereits selbst für die Formel. Um Excel mitzuteilen, dass es nun die Anführungsstriche im Formelergebnis ausgeben soll, muss das Zeichen mehrfach angegeben werden (diese Notation benutzt Microsoft an vielen Stellen). Doppelt wird das Zeichen angegeben, wenn dahinter wieder fester Text steht. In diesem Fall folgt danach aber ein weiterer Teil der Formel, nämlich eben der Anzeigename. Also werden die Anführungsstriche gleich dreimal hintereinander angegeben: Zweimal, um die Ausgabe zu erzeugen, und ein drittes Mal, um die Zeichenkette abzuschließen und die Formel fortzusetzen.
Wiederum mit drei Anführungsstrichen wird der letzte Schalter „/ScriptPath" eingeleitet, der auf Zelle D2 verweist. Zum Schluss schließlich noch die Dateinamenerweiterung und die Option „/domain".

Diese Formel wird mit der Maus in alle Zellen kopiert, für die ein Kommando erzeugt werden soll. Excel passt die Zellenbezüge automatisch an. Im Effekt stehen nun in der Spalte E Kommandos dieser Art:

net user EllenB abc123! /add
   /Fullname:"Ellen Bogen" /Scriptpath:Vertrieb.bat /domain

net user KarlK bcd234! /add
   /Fullname:"Karl Koop" /Scriptpath:Einkauf.bat /domain

net user UteD cde345! /add
   /Fullname:"Ute Digute" /Scriptpath:Buchhaltung.bat /domain

Diese Kommandospalte kann man nun markieren und mit Strg-C in die Zwischenablage kopieren. Von dort in Notepad einfügen und als „users.bat" abspeichern und ausführen – voilà!

Das Kommando „net user" hat aber einen entscheidenden Nachteil: Es erzeugt neue Objekte nur im Standardcontainer der Domäne. Normalerweise ist das der Ordner „Users". Zwar kann man diesen vorher mit „redirusr.exe" auf einem Windows Server 2003 umlenken, aber das ist für unsere Zwecke nicht besonders praktikabel.

Flexibler mit ds-Tools

Sinnvoller ist es, mit leistungsfähigeren Kommandos zu arbeiten. Windows Server 2003 selbst bringt dafür die „ds-Tools" mit, einen Satz von Kommandozeilenbefehlen, die mit „ds" (für „Directory Service") beginnen. Dies sind die Befehle „dsadd" (Hinzufügen von Objekten), „dsmod" (Ändern), „dsquery" (im AD suchen), „dsget" (Details zu einem Einzelobjekt) und „dsrm" (Löschen). Nähere Informationen dazu finden sich in der Server-Onlinehilfe. Ein Kommando, mit dem Günter Melzer in der OU „Marketing" angelegt wird, wäre etwa dieses (wiederum eine einzige Zeile):

dsadd user "CN=Günter Melzer,OU=Marketing,DC=faq-o-matic,DC=net"
   -samid GMelzer -pwd abc123!

Das lässt sich natürlich noch mit zahlreichen Optionen verfeinern, die in dsadd bereits vordefiniert sind. Die passende Excel-Formel für eine massenweise Listenverarbeitung lässt sich nach obigem Beispiel sicher leicht aufbauen.

Noch flexibler mit AdMod

Mehr Flexibilität als mit den ds-Tools hat man allerdings mit AdMod von Joe Richards:

[faq-o-matic.net » Active-Directory-Massenoperationen mit AdMod und AdFind]

http://www.faq-o-matic.net/2006/11/29/active-directory-massenoperationen-mit-admod-und-adfind/

AdMod erlaubt fast beliebige Änderungen an AD-Objekten. Recht effizient kann man etwa arbeiten, wenn mehrere Änderungen an einer Menge von Objekten ausgeführt werden sollen. Für jede Änderung kann man mit der Excel-Technik eine eigene Spalte mit der passenden Befehlsformel erzeugen.

Ein Beispiel: Alle Benutzerkonten einer Domäne sollen umbenannt werden. Der neue Anmeldename und der alte Name (hier: Die Personalnummer) stehen in einer Excel-Tabelle. Mit der Umbenennung gehen einige weitere Änderungen einher, etwa das Umbenennen von Profil- und Home-Ordnern.

Zunächst benötigt AdMod (genau wie die ds-Tools) den distinguishedName (DN) des zu ändernden Objekts. Machen wir es uns einfach und tun so, als lägen alle Objekte in derselben OU. Dann könnte folgende Formel in Spalte C helfen:

="CN=pers-" &B2&",OU=Personal,DC=contoso,DC=com"

So ist der DN dann als Ergebnis in Spalte C zu finden. Eine Formel zum Ändern des Anmeldenamens auf den Wert, der jeweils in Spalte A steht, wäre diese hier (einzutragen in Spalte D):

="ADMod -b """&$C2&""" ""sAMAccountName::"&$A2&""""

Das daraus resultierende AdMod-Kommando ist (auch hier eine einzige Zeile):

ADMod -b "CN=pers-33268,OU=Personal,DC=contoso,DC=com"
   "sAMAccountName::AlbrechtH"

Ebenso kann über eine vergleichbare Formel in Spalte E der Profilordner in Active Directory umbenannt werden:

="ADMod -b """&$C2&""" ""profilePath::\\file03\profiles$\"&$A2&""""

Doch Achtung, in diesem Fall muss natürlich auch der Ordner auf dem Server umbenannt werden. Das gelingt mit dieser Formel in Spalte F:

="ren ""E:\Profiles\pers-"&B2&""" " & $A2

Entsprechend können in den Spalten G, H und I die analogen Formeln eingetragen werden, um den Home-Ordner sowohl in AD als auch auf dem Server zu ändern (hier noch eine dritte Formel, um den Laufwerksbuchstaben für das Mapping mitzugeben):

="ADMod -b """&$C2&""" ""homeDirectory::\\file03\home$\"&$A2&""""

="ADMod -b """&$C2&""" ""homeDrive::O:"""

="ren ""E:\Home\pers-"&B2&""" " & $A2

Nachdem diese Formeln auf alle Zeilen der Tabelle angewendet wurden, kann man die einzelnen Spalten markieren, mit Strg-C kopieren und in eine Batchdatei einfügen. Da diese für jede Änderung eine einzelne Zeile enthält, kann man sie meist leichter kontrollieren als eine Programmierschleife. Zudem kann man einzelne Zeilen zu Testzwecken isolieren, um die grundlegende Funktion zu prüfen.

Kopieren auf mehrere Server

Ein letzter Anwendungsfall: Eine bestimmte Datei soll in einen bestimmten Ordner auf allen Servern kopiert werden. Auch dies lässt sich mit Excel gut automatisieren. Zunächst benötigen wir aber eine Liste der Server. Vorausgesetzt, alle Server befinden sich in einer oder wenigen OUs im AD, ist dies einfach: In Active Directory-Benutzer und -Computer die richtige OU heraussuchen, Rechtsklick darauf. Mit dem Befehl „Liste exportieren" aus dem Kontextmenü werden die Servernamen (und etwas Beiwerk) in eine Textdatei geschrieben. Diese kann man nun in Excel öffnen und alle unnötigen Daten entfernen.

Stehen nun die Servernamen in Spalte A, lassen sich die Kopierkommandos mit dieser Formel in Spalte B erzeugen:

="copy C:\temp\datei.txt \\" & A2 & "\c$\daten\"

Und wieder: Das Ergebnis in eine Textdatei kopieren, als Batchdatei abspeichern und ausführen.

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.

Kostenstelle in AD integrieren

Norbert Fehlauer — Tue, 27 Feb 2007 15:00:00 +0000

Basierend auf dem Artikel "Eigene Funktionen in die AD-Tools integrieren" von Nils habe ich das dort vefügbare Beispiel erweitert. Zweck dieser Erweiterung ist es, das extensionAttribute3 modifzieren zu können. Im konkreten Fall wird dieses Attribut genutzt, um eine Kostenstellenzuordnung für eine Cisco-VOIP-Telefonanlage zu schaffen.

Ziel ist es, diese Kostenstelle mittels Kontextmenü direkt über das Nutzerobjekt in Active Directory modifizieren zu können. Hierzu zählt auch die Möglichkeit, einen einmal gesetzten Wert auch komplett löschen zu können.

Das folgende Skript speichert man als extension3.hta z. B. unter c:\windows\system32 ab.

Die Löschroutine löscht den gesetzten Wert ohne nochmalige Sicherheitsabfrage. Also bitte aufpassen.

——– Extension3.hta —————-

"oHTA">
NAME="author" CONTENT="Nils Kaczenski und Norbert Fehlauer">
"start();">
"head">
Benutzer:
"anzeige">

[K]ostenstelle "Kosten" accesskey="k">
"all">

——– Extension3.hta —————-
Mit folgendem Script wird die extension3.hta im Rechtsklickmenü verfügbar. Hierzu adminmenu.vbs ausführen. Der Wert "strValue", der angibt, wie der Menüpunkt heißen soll, muss entsprechend angepasst werden.
——— Adminmenu.vbs ———————

Set root= GetObject("LDAP://rootDSE")
strConfig = root.Get("configurationNamingContext")
strPath = "LDAP://cn=user-Display,cn=407,cn=DisplaySpecifiers," & strConfig
Set obj= GetObject(strPath)
strValue = "5,Kostenstelle modifizieren,Extension3.hta"
arrValue = Array(strValue)
obj.PutEx 3, "adminContextMenu", arrValue
obj.SetInfo
msgBox "Kontextmenüeintrag hinzugefügt: " & strValue

Active-Directory-Massenoperationen mit AdMod und AdFind

Nils Kaczenski — Wed, 29 Nov 2006 14:39:00 +0000

Windows Server 2003 enthält die so genannten "ds*-Tools": Eine Sammlung von Kommandozeilenprogrammen, die Massenoperationen an Active Directory zulassen. Zu diesen Tools zählen dsquery (Abfragen des AD), dsget (Zugriff auf bestimmte Objekte erhalten), dsadd (Objekte erzeugen), dsmove (Objekte verschieben), dsmod (Objekte manipulieren) und andere. Das Interessante ist, dass diese Tools das Piping unterstützen, d.h. man kann etwa die Ausgabe einer dsquery-Abfrage direkt an dsmod verfüttern, um alle gefundenen Objekte zu bearbeiten.

Doch die ds*-Tools sind nicht immer das Nonplusultra. Viele Operationen erfordern, dass die Domäne oder der Forest im WIndows-2003-Modus arbeiten, was nicht immer gegeben ist. Ältere Umgebungen ohne Windows Server 2003 können gar nicht davon profitieren. Und schließlich gibt es auch einige Begrenzungen innerhalb der Tools. Hier kommt joeware.net ins Spiel.

Joe Richards, amerikanischer MVP für Active Directory, hat zwei Werkzeuge entwickelt, die in einigen Situationen bessere Dienste leisten als die ds-Pendants: AdFind (zum Durchsuchen des Active Directory) und AdMod (zum Bearbeiten von Objekten). Die Nutzung ist recht einfach und wird auf Joes Webseite www.joeware.net gut erläutert. Hier die Links:

AdFind: http://www.joeware.net/win/free/tools/adfind.htm
AdMod: http://www.joeware.net/win/free/tools/admod.htm
Noch mehr Joeware: http://www.joeware.net/win/free/all.htm

Benutzer:	"anzeige">
[K]ostenstelle	"Kosten" accesskey="k">

faq-o-matic.net » AD: Daten bearbeiten

dsmove und sein beständiger Fehler

Verwandte Beiträge:

dsacls in Extremsituation

Verwandte Beiträge:

„Benutzer kann Passwort nicht ändern“-Option auf Abwegen

Verwandte Beiträge:

Umbenennen einer AD-Domäne

Verwandte Beiträge:

AD-Adressen im Sekretariat bearbeiten lassen

Schritt 1: Datenfelder identifizieren

Schritt 2: Berechtigungen setzen

Schritt 3: Adressen bearbeiten

Bedienung

Erweiterung

Verwandte Beiträge:

Adam und Eva

Verwandte Beiträge:

Excel: Admins unbekannter Liebling

Verwandte Beiträge:

Maulkorb für den OU-Admin

Verwandte Beiträge:

Kostenstelle in AD integrieren

"head">

Verwandte Beiträge:

Active-Directory-Massenoperationen mit AdMod und AdFind

Verwandte Beiträge: