Best Practices Active-Directory-Security (2)

Lesezeit
3 Minuten
Bis jetzt gelesen

Best Practices Active-Directory-Security (2)

09.11.2020 - 00:00
Veröffentlicht in:
Active-Directory-Umgebungen stehen häufig im Fokus von Angreifern und Hackern. Sobald auf einem PC in der Domäne eine Malware Anmeldedaten abgreifen kann, besteht die Gefahr, dass die ganze Active-Directory-Umgebung übernommen wird. Im zweiten Teil beleuchten wir das Konzept schreibgeschützter Domänencontroller und erläutern, wie Sie DNS richtig absichern.
Schreibgeschützte Domänencontroller
Eine Möglichkeit, Domänencontroller in Niederlassungen abzusichern, sind die schreibgeschützten Domänencontroller (Read-only Domain Controller, RODC). Diese erhalten replizierte Informationen von regulären Domänencontrollern und nehmen selbst keine Änderungen von Administratoren entgegen.

Ein RODC erhält also immer nur Informationen und kann selbst keinerlei Informationen in das Active Directory schreiben. Durch dieses Feature können Sie auch DCs in kleineren Niederlassungen betreiben, ohne dass das Sicherheitskonzept eines Unternehmens dahingehend beeinträchtigt ist, wenn die DCs in den Niederlassungen nicht hinreichend geschützt sind.

Ein RODC schützt das Active Directory so etwa davor, dass Kennwörter ausspioniert werden können. Er kennt zwar alle Objekte im Active Directory, speichert aber nur die Kennwörter der Benutzer, die Sie explizit festlegen. Wird ein solcher Domänencontroller gestohlen und versucht ein Angreifer, die Kennwörter aus der Datenbank des Controllers auszulesen, sind die Konten der restlichen Domäne geschützt. Ein RODC nimmt keine Änderungen in der Datenbank des Active Directory an, nur ein lesender Zugriff ist erlaubt. Schreibende Domänencontroller richten zudem keine Replikationsverbindung zu RODCs ein, da eine Replikation nur von normalen DCs zu RODCs erfolgen kann. RODCs richten vielmehr Replikationsverbindungen zu den schreibenden Domänencontrollern ein, die Sie bei der Heraufstufung angeben.

Klicken Sie im Snap-In "Active Directory-Benutzer und -Computer" mit der rechten Maustaste auf die OU "Domain Controllers", können Sie im zugehörigen Kontextmenü den Eintrag "Konto für schreibgeschützten Domänencontroller vorbereiten" auswählen. In diesem Fall führen Sie in der Zentrale den Assistenten zum Erstellen eines neuen Domänencontrollers aus und weisen diesem ein Computerkonto zu. In der Niederlassung kann anschließend ein Administrator diesen Server installieren. Der Server bekommt automatisch die Funktion des RODCs zugewiesen.


Bild 2: Mit schreibgeschützten Domänencontrollern lassen sich Niederlassungen sicherer anbinden.

Ein RODC bietet ein vollständiges Active Directory, allerdings ohne gespeicherte Kennwörter. Dieser Ordner auf dem RODC ist schreibgeschützt (read only), also nur lesbar, verfügbar. Zwar kann auch ein RODC Kennwörter speichern, aber nur genau diejenigen, die ein Administrator angibt. Bei der Verwendung von RODCs werden folgende Abläufe beim Anmelden eines Benutzers abgewickelt:
  1. Ein Anwender meldet sich am Standort des RODC an.
  2. Der RODC überprüft, ob das Kennwort des Anwenders auf den Server repliziert wurde. Falls ja, wird der Anwender angemeldet.
  3. Ist das Kennwort nicht auf dem RODC verfügbar, wird die Anmeldeanfrage an einen vollwertigen DC weitergeleitet.
  4. Ist die Anmeldung erfolgreich durchgeführt, wird dem RODC ein Kerberos-Ticket zugewiesen.
  5. Der RODC stellt dem Anwender jetzt noch ein eigenes Kerberos-Ticket aus, mit dem dieser Anwender arbeitet. Gruppenmitgliedschaften und Gruppenrichtlinien werden übrigens nicht über die WAN-Leitung gesendet. Diese Informationen werden auf dem RODC gespeichert.
  6. Als Nächstes versucht der RODC, das Kennwort dieses Anwenders in seine Datenbank von einem vollwertigen DC zu replizieren. Ob das gelingt oder nicht, hängt von der jeweiligen Gruppenmitgliedschaft ab.
  7. Bei der nächsten Anmeldung dieses Anwenders beginnt der beschriebene Prozess von vorne.
Die Kennwörter von Administratorkonten im Active Directory landen in keinem Fall auf einem schreibgeschützten Domänencontroller. Diese Zugangsdaten sind aufgrund ihrer Wichtigkeit von der möglichen Replikation zum schreibgeschützten Domänencontroller ausgeschlossen. Geht die WAN-Verbindung in der Niederlassung mit dem RODC zu einem normalen DC verloren, findet keine Anmeldung mehr an der Domäne statt. Der RODC verhält sich dann wie ein normaler Mitgliedsserver und es ist nur die lokale Anmeldung am Server möglich.

Wird ein RODC gestohlen, enthält dieser ausschließlich nur die Daten der Benutzerkonten, die zur Replikation auf den Server explizit ausgewählt sind. Alle anderen Daten des Active Directory sind auf dem Server nicht verfügbar und können daher auch nicht ausgelesen werden. Entfernt ein Administrator das Computerkonto des gestohlenen RODCs, wird ihm ein Auswahlfenster angezeigt, über das die Kennwörter der Benutzer und Computer, die auf den RODC repliziert sind, zurückgesetzt werden können. Selbst wenn es einem Dieb gelingen sollte, die Daten vom RODC auszulesen, sind diese wertlos, weil sie zurückgesetzt wurden. Bei diesem Vorgang löscht das Active Directory nicht die Benutzer- und Computerkonten selbst, sondern ausschließlich die Kennwörter. Diese Daten lassen sich außerdem nicht nur zurücksetzen, sondern über den Assistenten besteht zusätzlich eine Exportmöglichkeit der Konten.

DNS absichern
Installieren Sie auf einem RODC den DNS-Dienst, wird dieser Server zum schreibgeschützten DNS-Server. Hier gelten die gleichen Einschränkungen für einen RODC. Ein schreibgeschützter DNS-Server nimmt nur Änderungen von normalen DNS-Servern entgegen und akzeptiert selbst keine Änderungen. Ein schreibgeschützter DNS-Server steht für Benutzer als normaler DNS-Server für Abfragen zur Verfügung, unterstützt aber keine dynamische DNS-Registrierung. Versucht sich ein Client zu registrieren, erhält er vom DNS-Server eine Rückmeldung, dass keine Aktualisierung akzeptiert wird. Im Hintergrund kann der Client versuchen, sich an einem normalen DNS-Server zu registrieren, der die Änderungen dann wieder zum schreibgeschützten DNS-Server repliziert.

Bereits mit Windows Server 2008 R2 hat Microsoft DNSSEC eingeführt, um Zonen und Einträge besser abzusichern. In Windows Server 2016 und 2019 lassen sich Zonen online digital signieren. DNSS EC lässt sich komplett im Active Directory integrieren. Das umfasst auch die Möglichkeit, dynamische Updates für geschützte Zonen zu aktivieren. Windows Server 2016/2019 unterstützt Standards wie NSEC3 und RSA/SHA-2. Ebenfalls interessant ist auch die Unterstützung von DNSSEC auf schreibgeschützten Domänencontrollern.

Findet ein RODC mit Windows Server 2016/2019 eine signierte DNS-Zone, legt er automatisch eine sekundäre Kopie der Zone an und überträgt die Daten der DNSEC-geschützten Zone. Dies hat den Vorteil, dass auch Niederlassungen mit RODCs gesicherte Daten auflösen können, aber die Signatur und Daten der Zone nicht in Gefahr sind. DNSSEC lässt sich über das Kontextmenü von Zonen erstellen. Das Signieren der Zone erfolgt über einen Assistenten. Der erlaubt das manuelle Signieren, eine Aktualisierung der Signierung und ein Signieren auf Basis automatischer Einstellungen. Mit Windows Server 2016 und 2019 lassen sich signierte Zonen auch auf andere DNS-Server im Netzwerk replizieren.

Im ersten Teil der Workshopserie erklärten wir die Hintergründe zu Active-Directory-Angriffen und haben gezeigt, wie Sie Administratorkonten umsichtig einsetzen. Im dritten Teil geht es darum, wie Sie Objekte schützen und verwalten und mit verwalteten Dienstkonten arbeiten.


dr/ln/Thomas Joos

Ähnliche Beiträge

Im Test: SQL Sentry von SolarWinds

"SQL Sentry" von SolarWinds ist ein Überwachungswerkzeug für Datenbanken auf Basis von Microsoft SQL Server. Das Tool liefert den Administratoren Leistungsdaten des Servers und der überwachten Datenbankinstanzen in einem einzigen Dashboard. Abgesehen davon bringt es auch noch einige weitere nützliche Funktionen mit. Wir haben uns im Testlabor angesehen, wie sich die Lösung in Betrieb nehmen lässt und wie die tägliche Arbeit mit ihr abläuft.