Downloadlink

Viel Spaß beim Installieren wünscht,

Frank

Ich möchte in der folgenden Artikelserie dem Administrator eine Übersicht geben, an der man ungefähr die zu erwartende Größe der Active Directory Datenbank abschätzen kann.

Teil Eins der Artikelserie betrachtet das Anlegen von Benutzerobjekten. Um hier sehr nahe an die tatsächliche Größe eines einzelnen Benutzerobjekts zu kommen, habe ich in 100.000er Schritten durch ein Powershellskript Benutzer angelegt. Meine Testumgebung stellt sich folgendermaßen dar:

Windows 2008 R2 Domänencontroller
Domänenname: spielwiese.de

Gefüllte Attribute beim Anlegen:

samAccountName: Gefüllt von 000000 bis 999999
UPN: Gefüllt von 000000@spielwiese.de bis 999999@spielwiese.de
name: 000000
distinguishedName: cn=000000,ou=test,dc=spielwiese,dc=de

Nach dem Intervall von 100.000 Benutzerobjekten hat mein Powershellskript die Größe der AD Datenbank gemessen. Anschließend wurde eine Defragmentierung der AD Datenbank durchgeführt und die Größe der Datenbank erneut gemessen.

Wie man in der zweiten Tabelle erkennen kann, sind die Messergebnisse wesentlich linearer als bei der ersten Messung. Die Ergebnisse sind darauf zurückzuführen, daß bei der ersten Messung natürlich noch viele Transaktionen nicht in die Datenbank geschrieben waren. Bei der offline Komprimierung werden diese natürlich mit in die Datenbank geschrieben. Deshalb ist die zweite Messung maßgebend. Abschließend kann man also sagen, daß die Größe eines Benutzerobjekts in der Active Directory Datenbank ungefähr 5,74 KB beträgt.

Im nächsten Artikel werde ich die Auswirkungen von Attributen auf die Größe der AD Datenbank betrachten.

LINUX

Ich fand es cool. Leider hat meine Handykamera versagt und man sieht es nicht auf dem Foto:-(. Wenn man ganz genau hinsieht, dann kann man es eventuell erahnen…..

Ich kann dafür nur einfach Danke sagen und freue mich auf ein weiters Jahr mit den ganzen Tekkies;-). Mal sehen, was das neue MVP Jahr so alles bringt. Informationen was MVPs sind und was die so treiben findet Ihr hier:

MVP Programm

Allen anderen neu- oder wiederernannten MVPs gratuliere ich hiermit auch.

Man kann sich also nur die ersten 1000 Dateien für jeden Besitzer anzeigen lassen. Wenn man sich aber für einen einzelnen Benutzer alle Dateien anzeigen lassen will, die er momentan im Besitz hat, dann ist dieses Feature eher  nutzlos. Um trotzdem an diese Informationen zu kommen, war bis jetzt der Einsatz von Skripten oder auch Drittanbietertools notwendig.

Seit Windows Server 2008 ist es möglich, diese Beschränkungen aufzuheben. Allerdings geht das nicht über die grafische Benutzeroberfläche des “Ressourcen-Managers für Dateiserver”, sondern muss aufwendig über Skripting realisiert werden. Um die Sache etwas zu vereinfachen, habe ich das Powershell Skript “set-fsrmstoragereportlimit.ps1” erstellt. Damit können die einzelnen Beschränkungen relativ einfach angepasst werden.

##########################################
# Skript konfiguriert die Beschränkungen der FSRM Reports um.
#
# Einsetzbar ab Windows Server 2008
#
# Von Frank Röder 2010
# http://blog.iteach-online.de
#
##########################################
$values = @{"-maxfiles"=1;"-maxfilegroups"=2;"-maxowners"=3;
"-maxfilesperfilegroup"=4;"-maxfilesperowner"=5;"-maxfilesperduplgroup"=6;
"-maxduplicategroups"=7;"-maxquotas"=8;"-maxfilescreenevents"=9;
"-maxpropertyvalues"=10;"-maxfilesperpropertyvalue"=11}
 
$int64 = New-Object System.Int64
$fsrm = New-Object -comObject "fsrm.fsrmReportManager"
#prüfe ob Parameter übergeben wurden
if($Args.count%2 -eq 0 -and $Args.count -gt 0)
{
for($a=0;$a -lt $Args.Count;$a+=2)
{
if($values.containskey($Args[$a]) -and [System.Int64]::TryParse($Args[$a+1],[ref] $int64)){
"Setze neuen Wert für:" + [char]9 + $Args[$a]
"Alter Wert:" + [char]9 + $fsrm.GetReportSizeLimit($values.Item($Args[$a]))
"Neuer Wert:" + [char]9 + $Args[$a+1]
$fsrm.SetReportSizeLimit($values.Item($Args[$a]),$Args[$a+1])
}else{
parameters_alert
break
}
}
} else{
parameters_alert
}
function parameters_alert(){
 
Write-host "Falsche Anzahl an Parametern oder ungültiger Parameter! Gültige Parameter sind:" -foregroundcolor red
$values.Keys | ForEach-Object {$_ + [char]9 + "(Erlaubter Wert: 0 bis 9223372036854775807)"}
 
"Beispiel: set-fsrmstoragelimit.ps1 -maxfiles 50000"
}

Die Standardwerte für die einzelnen Werte sind:

Hinweis: Das Skript funktioniert nur unter Windows Server 2008 und kann nicht unter Windows Server 2003 R2 eingesetzt werden. Bei Windows Server 2003 R2 sind die Werte der Speicherberichte statisch hinterlegt!

Hier kann das Skript heruntergeladen werden: set-fsrmstoragereportlimit.ps1 Size: 906 bytes , 108 Hits

Zusätzliche Quellen:
MSDN

 Um die Funktion domänenweit abschalten zu können, benötigt man das MMC-Snapin “ADSIedit”. Dieses ist in den “Support Tools” für Windows Server 2003 enthalten. Achtet bitte bei den “Support Tools” darauf, dass Microsoft für jedes Service Pack eine neue Version zum Herunterladen bereit stellt.

Folgende Schritte deaktivieren “Drag and Drop”:

1. Herunterladen und Installieren von den “Support Tools” für Windows Server 2003 SP1
2. Start / Ausführen / MMC
3. In der MMC klickst du auf “Datei” / “Snap-In hinzufügen / entfernen” und im nächsten Fenster unten auf den Button “Hinzufügen”. Jetzt sollte ein Fenster erscheinen, wo du alle auf diesem Rechner verfügbaren Snap-Ins sehen kannst. Dort markierst du das Snap-In ADSI-Edit und klickst auf “Hinzufügen” und danach auf “Schließen”. Jetzt nur noch auf “OK” im Fenster “Snap-In hinzufügen / entfernen” klicken.
4. In der MMC sollte jetzt in der linken Seite unterhalb vom Konsolenstamm das Snap-In “ADSI Edit” verfügbar sein. Dort klickst du bitte mit der rechten Maustaste drauf und wählst aus dem Kontextmenü den Punkt “Connect to…” aus.
5. Jetzt sollte ein Fenster erscheinen, das den Titel “Connections Settings” trägt. Bitte wähle dort den Punkt “Select a well known Naming Context” aus und selektiere im darunter liegenden Pull-Down Menü den Punkt “Configuration” aus. Danach einfach nur noch auf “OK” klicken.
6. Unterhalb von “ADSI  Edit” ist jetzt ein Unterpunkt verfügbar, der “Configuration” heißt und dahinter sollte “[deinserver.deinedomaene.de]” stehen.
7. Diesen Punkt erweiterst du, es sollte jetzt folgender Eintrag sichtbar sein: “CN=Configuration,DC=deinedomäne,DC=de”, den du bitte auch erweiterst.
8. Unterhalb von “CN=Configuration,DC=deinedomaene,DC=de” befindet sich ein Eintrag “CN=DisplaySpecifiers”, wo du bitte mit Rechtsklick das Kontextmenü aufrufst und auf Menüpunkt “Eigenschaften” klickst.
9. Auf der Registerkarte “Attribute Editor” siehst du die einzelnen verfügbaren Attribute. Hier ist das Attribut “flags” von Interesse. Dieses Attribut sollte als “Value” momentan “<Not Set>” haben. Mit einem Doppelklick kannst du hier einen Wert setzen. Dieser Wert kann ein beliebiger Integerwert sein, also z.B. “1″.
10. Nach dem Setzen des Wertes bestätigst du das mit Klicken auf “OK” und schließt die “MMC”. Ab sofort ist “Drag and Drop” im “Active Directory Benutzer und Computer” deaktiviert.

Wenn man die “Drag and Drop”-Funktionälität wieder haben möchte, kann man durch Zurücksetzen des Wertes vom Attribut “flags” auf “<not set>” das “Drag and Drop” wieder aktivieren.

Die Administratoren, die einen Windows 2003 Server einsetzen, können auf ein Tool zurückgreifen, was sich “eventtriggers” nennt. Mit diesem Tool ist der Administrator in der Lage, auf von ihm definierte Ereignisprotokolleinträge entsprechend zu reagieren. Dieses Tool ist im Lieferumfang von Windows XP Professional und Windows 2003 enthalten.

 Ein einfacher Aufruf von “eventriggers /?” liefert folgende Ausgabe:

Eventtriggers bietet hier drei mögliche Parameter. Mit “/create” kann man einen Eventtrigger anlegen, mit “/delete” kann man einen oder mehrere Eventtrigger löschen und mit “/query” alle angelegten Eventtrigger anzeigen lassen.
Mit “eventtriggers /create” kann man also einen neuen Trigger erstellen. Zusätzlich kann angegeben werden, welcher Task ausgeführt werden soll, wenn dieses Ereignis eintritt.
Stellen wir uns vor, wir möchten über jeden fehlgeschlagenen Anmeldeversuch an der Domäne informiert werden. Dafür müssen wir das Sicherheitsprotokoll nach Ereignis IDs mit der Nummer “529″ überwachen. Als auszuführenden Task, habe ich hier der Einfachheit halber nur eine Batchdatei gewählt, die per “net send” eine Nachricht an den “PC1″ sendet. Man könnte natürlich hier auch eine E-Mail über “Blat” an das Postfach des Administrators versenden.

Inhalt der alarm.bat:
net send pc1 “ALARM-ungültiger Anmeldeversuch”

Jetzt muss nur noch der Eventtrigger angelegt werden:
eventtriggers /create /l security /eid 529 /tr “Anmeldefehler” /ru domaenedienstkonto /rp passwort /tk c:alarm.bat

Erklärung der Parameter:

/l – gibt das zu überwachende Ereignisprotokoll an.
/eid – gibt die zu überwachende Ereignis ID an.
/tr – definiert für den Trigger einen “friendly Name”
/ru – gibt das Benutzerkonto an, was verwendet wird, um den definierten Task zu starten.
/rp – gibt das Kennwort für das Benutzerkonto an.
/tk – gibt die ausführbare Datei an, die bei Eintreten des Tasks gestartet werden soll.

Wenn alles richtig eingegeben wurde, sollte die Registrierung des Triggers erfolgreich sein.

Ab sofort ist der Eventtrigger aktiv und verschickt eine “net send” Meldung bei jedem fehlgeschlagenen Anmeldeversuch an der Domäne. Zu beachten ist hier, dass dieser Trigger auf jedem Domänencontroller der Domäne gesetzt werden muss.Wenn man jetzt mehrere Eventtrigger gesetzt hat, dann möchte man eventuell alle aktiven Trigger auf einem Rechner einsehen. Hierbei ist der Befehl “eventtriggers /query” hilfreich.Wer es hier etwas ausführlicher wissen möchte, der kann noch zusätzlich den Parameter “/v” für diesen Befehl nutzen.

Um diesen Eventtrigger vom System zu entfernen, nutzt man “eventtriggers /delete /TID 1″. Das “TID” steht hier für die Trigger-ID, die in der Ausgabe von “eventtriggers /query” ersichtlich ist. Wenn man alle auf dem System definierten Trigger entfernen möchte, so kann man dies über die Eingabe von “eventtriggers /delete /TID *” tun.

Microsoft bietet hier ein Tool mit dem Namen “subinacl” an , was sich kostenfrei auf der Microsoft-Webseite herunterladen lässt.

Download:
http://www.microsoft.com/downloads/details.aspx?FamilyID=E8BA3E56-D8FE-4A91-93CF-ED6985E3927B&displaylang=en
Dieses Tool ist unter Windows 2000, Windows XP und auch Windows 2003 Server einsetzbar.

Nehmen wir also an, dass ich einen Fileserver habe, der eine Freigabe “Daten” hat, in der verschiedene weitere Ordner existieren. In diesen Ordnern wurden über die Jahre die ACLs modifiziert und eventuell auch Benutzer und Gruppen im Active Directory gelöscht. Dadurch existieren die oben genannten verwaisten ACL-Einträge.

(Verwaister ACL-Eintrag)

Jetzt kommt “subinacl” ins Spiel. Dieses Tool stellt einen Schalter zur Verfügung, der sich “cleandeletedsidsfrom” nennt. Damit ist es möglich, nicht in Benutzernamen auflösbare SIDs aus den ACLs zu entfernen. Dieser Schalter muss als Parameter den Namen der Domäne bekommen (/cleandeletedsidsfrom=Name der Domäne).
Für mein Szenario ergibt sich daraus folgende Kommandozeile:

subinacl /subdirectories c:\daten\*.* /cleandeletedsidsfrom=domaene

(Achtung! Wenn es sich hier um eine größere Struktur von Ordnern und Dateien handelt, dann sollte man dieses Tool in Zeiten einsetzen, wo nicht gearbeitet wird. Das Tool “Subinacl” bremst natürlich die Geschwindigkeit des Datenträgers und belastet auch sehr den DC, der zum Abfragen bzw. Auflösen der SIDs genutzt wird. Subinacl speichert die bereits aufgelösten SIDs zwischen, so dass diese nicht erneut vom DC abgefragt werden müssen.)

Wenn “Subinacl” seine Arbeit getan hat, dann sollte man folgende Ausgabe in der CMD sehen:

(Ausgabe von “subinacl”)

Zum Schluss ein prüfender Blick in die Sicherheitseinstellungen des Ordners “Buchhaltung”.

(Verwaister ACE wurde von “subinacl” entfernt)

Subinacl kann natürlich wesentlich mehr und ich empfehle jedem, mal einen Blick auf die Hilfe dieses Tool zu werfen.

• Windows 2000 Professional Service Pack 4
• Windows 2000 Server Service Pack 4
• Windows XP Professional Service Pack 1 und höher
• Windows Server 2003 •Mindestens ein Windows 2003 DC
• Ein Server, der IIS 6.0 mit ASP.NET Unterstützung ausführt wird

Ich habe für diesen Test einen Domänencontroller unter Windows 2003 Server SP1 (GER) und zwei Windows XP Professional Workstations in VMWare installiert. Laut der Installationsanleitung von Limitlogin soll als erstes die Setupdatei für den IIS ausgeführt werden. Den Ablauf habe ich mit einem Flashfilm dokumentiert.

Die Installation verlief reibungslos, und ich konnte das nächste MSI-Paket ausführen. Wie sollte es auch anders sein, hier gab’s die erste Fehlermeldung. Das Setupprogramm erklärte mir, es hätte die Schemaerweiterung nicht korrekt durchführen können. Als typischer Windows-Admin klickt man natürlich hier, ohne mit der Wimper zu zucken, auf “OK”. Im letzten Dialogfeld berichtet mir das Setupprogramm “LimitLoginADSetup has been successfully installed”. Was denn, nun doch erfolgreich? Flashfilm
Da man ja anscheinend dem Setupprogramm von LimitLogin nicht trauen kann, ist ein prüfender Blick in die Logdatei der Schemaerweiterung eine gute Idee. Flashfilm

Nachdem ich mich von der korrekten Ausführung der Schemaerweiterung überzeugt hatte, habe ich mich an einer erneuten Ausführung der MSI-Datei versucht. Siehe da, das Setup erkennt, dass das Schema erweitert wurde, und bietet mir diese Option gar nicht mehr an. Die zweite Option im Setupprogramm bereitet das Active Directory für die Nutzung von LimitLogin vor. Der wichtigste Vorgang hier ist die Erzeugung der Anwendungspartition im Active Directory. Auch dabei bekomme ich, wie nicht anders zu erwarten, prompt eine Fehlermeldung. Beim Zugriff auf den Webservice wird dies mit einem HTTP 401 Fehler vom IIS zurückgewiesen. Flashfilm

Also musste irgendwo eine Zugriffsverweigerung vorliegen. Nach dem Durchkämmen der IIS-Logfiles und dem Aufruf des Webservice im Internetexplorer konnte ich die Ursache lokalisieren. Übeltäter war ein fehlendes Schreibrecht auf einen temporären Ordner für das Benutzerkonto “Netzwerkdienst”. Flashfilm

Sichtlich genervt und etwas desillusioniert führte ich das Setup nun zum dritten Mal durch, und siehe da, es wurde ohne Fehler abgeschlossen. Am Ende des Setups kommt eine Hinweismeldung, welche Anpassungen an der Gruppenrichtlinie vorgenommen werden müssen, damit die Benutzer das entsprechende Anmelde- und Abmeldeskript ausführen. Im Programmverzeichnis von Limitlogin liegen dafür drei Dateien, die in eine Netzwerkfreigabe kopiert werden müssen. Nachdem ich eine Gruppenrichtlinie entsprechend konfiguriert hatte, machte ich mich frohen Mutes sofort an die Installation der MMC-Erweiterung, damit ich endlich meine Nutzer limitieren kann. Meine Zuversicht sollte sehr schnell durch das “ausgeklügelte” Setup gebremst werden. Auch nach mehrmaligem Ausführen des Setupprogramms konnte ich keine Erweiterungen im Kontextmenü eines Benutzerkontos finden. Flashfilm

Clientseitig benötigt Limitlogin auch eine Komponente, die installiert werden muss. Ich habe dieses Setup manuell auf den beiden Clients ausgeführt. Als Alternative kann man das natürlich auch per Gruppenrichtlinie erledigen. Flashfilm

 Jetzt ist das Einzige, was noch fehlt, ein geeigneter Benutzer. Zu diesem Zweck habe ich einen Testbenutzer angelegt und diesen auf eine einzige Anmeldung an der Domäne limitiert. Flashfilm

Jetzt muss Limitlogin beweisen was es kann. Leider konnte sich der Testbenutzer trotz Limitierung mehrmals an der Domäne anmelden. Auch hier waren wieder mangelnde Schreibrechte des Benutzerkontos “Netzwerkdienst” auf den Ordner “%systemroot%Temp” schuld. Flashfilm

Nach dem die Berechtigungsprobleme beseitigt waren, funktionierte Limitlogin problemlos, und der zweite Anmeldeversuch des Testkontos wurde mit sofortiger Abmeldung belohnt. Leider bekommt der Benutzer, der versucht, sich mehrfach an der Domäne anzumelden, keine Fehlermeldung präsentiert sondern wird sofort automatisch abgemeldet. Dieser Vorgang wird sicherlich die Benutzer verwirren und zum Telefon greifen lassen. Wen werden die User denn dann anrufen? Sicherlich den armen Admin, der ja sein ganzes Wochenende der Installation von Limitlogin gewidmet hat. Flashfilm

Ich möchte mich jetzt nicht über das Preis-Leistungs-Verhältnis von Limitlogin auslassen. Dies hat ein Anderer schon sehr treffend im Allgemeinen ausformuliert: Preis-Leistungs-Verhältnis (Blog Daniel Melanchthon)

Wie kann man sich davor schützen?

Es gibt dafür drei Möglichkeiten. Die erste Methode wäre das Nutzen des Tools “cipher”. Das Tool “cipher” bietet einen Schalter “/w”, mit dem man solche Sektoren überschreiben kann, und damit würden diese Fragmente auf der Festplatte entfernt. Leider hat diese Methode einen Nachteil: Sie ist sehr zeitaufwendig. Die wesentlich bessere Methode wäre hier, einen verschlüsselten Ordner anzulegen. Wenn man einen Ordner verschlüsselt und in diesem dann neue Dateien erzeugt, dann tritt der Effekt mit den Klartextdateien nicht auf, und man kann sicher sein, dass keine unverschlüsselten Dateien auf der Festplatte vorhanden sind. Eventuell könnte aber hier noch z.B. die Auslagerungsdatei (pagefile.sys) ein Sicherheitsrisiko darstellen. Als dritte Möglichkeit kommt noch das Warten auf Windows Vista in Betracht, denn das soll “Full Volume Encryption” bieten und somit die gesamte Festplatte verschlüsseln können.