Maulkorb für den OU-Admin

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.