Mehr Sicherheit für Domänencontroller

5 Schritte zur sicheren Active Directory-Umgebung

| Autor / Redakteur: Thomas Joos / Peter Schmitz

Domänencontroller, privilegierte Accounts und Admin-Konten sind das Lieblingsziel von Hackern und Cyberkriminellen. Es gilt also diese Systeme und Konten im Active Directory besonders sorgfältig abzusichern.
Domänencontroller, privilegierte Accounts und Admin-Konten sind das Lieblingsziel von Hackern und Cyberkriminellen. Es gilt also diese Systeme und Konten im Active Directory besonders sorgfältig abzusichern. (© REDPIXEL - stock.adobe.com)

Das Active Directory wird in vielen Unternehmen als zentrales Element zur Authentifizierung genutzt. Daher stehen die Domänencontroller auch im Fokus von Angreifern. Werden diese Systeme kompromittiert, dann ist oft das gesamte Netzwerk in Gefahr. Mit Bordmitteln lässt sich die Sicherheit aber deutlich erhöhen.

Vor allem Konten mit erhöhten Rechten und Administratorkonten sind häufig im Fokus der Angreifer. Um Active Directory optimal abzusichern, sollten sich auch kleine und mittelständische Unternehmen an Enterprise-Umgebungen orientieren, die in den meisten Fällen für deutlich mehr Sicherheit in der Active Directory-Umgebung suchen.

Wenn Angreifer in ein Netzwerk eindringen, geschieht das normalerweise über einen einzelnen Endpunkt. Sobald dieser Endpunkt, zum Beispiel ein unsicherer PC, Server, Router oder ein anderes Netzwerkgerät übernommen wurde, gilt es Informationen über das Netzwerk zu sammeln. Denn nur mit ausreichend Informationen kann ein Angreifer auch den Rest des Netzwerks effizient ausspähen oder weitere Angriffe durchführen. Dieses Ausspähen auch Reconnaissance, kurz „recon“ genannt, späht das Netzwerk aus. Pass-the-Hash-Angriffe zielen direkt auf Benutzerkonten im Active Directory. Hier sind natürlich vor allem Benutzerkonten mit privilegierten Rechten interessant. Dabei kann es sich um Administrator-Konten handeln, aber auch um Benutzerkonten, die zum Beispiel das Recht erhalten haben Benutzerkennwörter zu ändern. Denn mit Benutzeränderungen kommen Angreifer, neben PtH noch zu anderen Zugängen. PtH-Angriffe setzen nicht nur auf die Kennwörter der Benutzer, sondern auf die Hashes, die einem Benutzerkonto nach der Authentifizierung zugewiesen werden. Einfach ausgedrückt handelt es sich dabei um Eintrittskarten in Active Directory.

Schritt 1: Administratorkonto umsichtig einsetzen und Rechte aufteilen

Administratorkonten sollten in Active Directory-Umgebungen sehr umsichtig eingesetzt werden. Zunächst sollten für die verschiedenen Serveranwendungen im Unternehmen auch jeweils verschiedene Administratorkonten verwendet werden. Administratorkonten für SQL-Server, sollten nicht auch noch für Exchange verwendet werden, oder zur Verwaltung von Active Directory. Wird ein solches Konto kompromittiert, dann sind auch alle anderen Serverdienste in Gefahr. Windows-Server bieten dazu verschiedene Benutzergruppen an, die standardmäßig verfügbar sind, und auch genutzt werden sollten. Vor allem in Gesamtstrukturen sind diese Standardgruppen in der Rootdomäne besonders wichtig.

Schritt 2: Keine unnötigen Anmeldungen mit Administratorkonten

In sicheren AD-Umgebungen ist es sinnvoll, möglichst wenig mit Konten mit erhöhten Rechten zu arbeiten. Die Anmeldung sollte immer nur mit dem Administrator-Konto erfolgen, dass für den jeweiligen Serverdienst eingerichtet ist.

Besteht für eine Arbeitsstation der Verdacht, dass diese kompromittiert oder unsicher ist, dann sollten sich Administratoren keinesfalls mit dem Administrator-Konto am System anmelden. Generell ist es durchaus sinnvoll eine Anmeldung an Rechnern zu vermeiden, die eine Verbindung mit dem Internet hat. Daher sollten die Arbeitsstationen der Administratoren, mit denen die Verwaltung der Umgebung erfolgt, keine Anbindung an das Internet erhalten.

Schritt 3: Multifaktor-Anmeldung nutzen und Administrator-auf-Zeit-Konten einsetzen

Grundsätzlich kann es für Administrator-Konten notwendig sein die Multifaktor-Authentifizierung (MFA) einzusetzen. Darüber hinaus sollten Sie auch auf Administrator-Konten auf Zeit zu setzen. In einer solchen Infrastruktur erhalten Administrator-Konten nur eine bestimmte Zeit das Recht eine bestimmte Verwaltungsaufgabe durchzuführen. Ist die Aufgabe abgeschlossen, oder die Zeit abgelaufen, werden die Rechte wieder entfernt.

Änderungen in Microsoft-Netzwerken nachverfolgen

Video-Tipp: Berechtigungen überwachen

Änderungen in Microsoft-Netzwerken nachverfolgen

14.03.17 - Administratoren haben häufig das Problem, dass sich Änderungen an Berechtigungen für verschiedene Objekte im Netzwerk kaum nachverfolgen lassen. Allerdings sind solche Überwachungen sinnvoll, und in vielen Fällen auch gesetzlich vorgeschrieben. Wie man eine solche Änderungsüberwachung realisiert, zeigen wir in diesem Video-Tipp-Artikel. lesen

Schritt 4: An unsicheren Standorten schreibgeschützte Domänencontroller verwenden

An Standorten an denen die Domänencontroller nicht in geschützten Serverräumen positioniert sind, sollten schreibgeschützte Domänencontroller eingesetzt werden. Eine Möglichkeit Domänencontroller in Niederlassungen abzusichern sind die schreibgeschützten Domänencontroller (Read-only Domain Controller, RODC). Diese Domänencontroller erhalten die replizierten Informationen von den normalen Domänencontrollern und nehmen selbst keine Änderungen von Administratoren entgegen.

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. 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. Wird 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.

Schritt 5: Verwaltete Dienstkonten nutzen - Managed Service Accounts

Die verwalteten Dienstkonten sind eine Neuerung seit Windows Server 2008 R2 und wurden in Windows Server 2012 R2 deutlich verbessert. In Windows Server 2016 funktionieren die verwalteten Dienstkonten noch in etwa so, wie in Windows Server 2012 R2. Administratoren können ein verwaltetes Dienstkonto für mehrere Server nutzen. Dazu hat Microsoft zu den bereits verwalteten Dienstkonten (Managed Service Accounts, MSA) noch die gruppierten verwalteten Dienstkonten (Grouped Managed Service Accounts, gMSA) entwickelt. Verwalten können Administratoren die verwalteten Dienstkonten in der PowerShell. Mit der Freeware Managed Service Accounts GUI werden wesentlich einfacher verwaltete Dienstkonten in Windows Server 2016 angelegt.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44815215 / Betriebssystem)