Ausgangslage: RDP auf DCs ist bequem und riskant

Domain Controller sind keine normalen Windows-Server. Sie verwalten Kerberos, NTLM, LDAP, Gruppenrichtlinien, DNS-Integration und die zentralen Identitaetsdaten der Domaene. Trotzdem werden sie in vielen Umgebungen wie normale Member Server administriert: RDP ist aktiviert, mehrere Admin-Gruppen koennen sich anmelden, Firewall-Regeln sind breit, und der Unterschied zwischen Serveradministration und Tier-0-Administration ist im Alltag unscharf.

Das ist ein vermeidbarer Risikopfad. Eine RDP-Sitzung auf einem Domain Controller erzeugt interaktive Logon-Spuren, Profile, potenzielle Credential-Artefakte und einen direkten Bedienpfad auf das kritischste System der Windows-Umgebung. Wenn Helpdesk-, Serveradmin-, Backup- oder Applikationsadmin-Konten dort anmelden duerfen, ist die Grenze zwischen normalen Betriebsrollen und Domain-Kontrolle praktisch aufgeweicht.

RDP auf DCs ist nicht automatisch falsch. Fuer bestimmte Wartungs-, Recovery- oder Break-Fix-Szenarien kann eine interaktive Sitzung noetig sein. Der Punkt ist die Normalisierung: Wenn DC-RDP der taegliche Admin-Weg ist, wird jedes kompromittierte Admin-Konto wertvoller, und jedes schlecht gehartete Admin-Endgeraet wird zum Tier-0-Risiko.

Das Ziel ist deshalb nicht pauschal "RDP immer aus". Das Ziel ist ein kontrollierter Betriebszustand: Domain Controller werden bevorzugt ueber sichere Remote-Administration und dedizierte Admin-Workstations verwaltet. RDP bleibt nur fuer klar definierte Tier-0-Szenarien offen, ist technisch begrenzt und wird ueberwacht.

Zielbild: DC-RDP ist Ausnahme mit klarer Spur

Ein belastbares Zielbild hat konkrete Eigenschaften:

  1. Nur Tier-0-Admins haben das RDP-Anmelderecht. Helpdesk, normale Serveradmins, Operator-Gruppen und Service-Accounts sind ausgeschlossen.
  2. RDP ist kein Ersatz fuer saubere Remote-Administration. RSAT, PowerShell Remoting, Event Forwarding und zentrale Management-Systeme laufen ueber kontrollierte Admin-Pfade.
  3. Netzzugriff ist eng begrenzt. TCP 3389 auf DCs ist nur aus PAW-, Jump-Host- oder Management-Subnetzen erreichbar.
  4. NLA bleibt verpflichtend. Remote Desktop wird nicht fuer alte Clients oder Bequemlichkeit abgeschwaecht.
  5. Deny-Rechte sind gezielt, nicht breit. Keine Deny-Gruppe darf versehentlich Domain Admins oder Break-Glass-Konten enthalten.
  6. Jede DC-RDP-Sitzung ist sichtbar. Erfolgreiche und fehlgeschlagene RemoteInteractive-Logons werden gesammelt und bewertet.
  7. Notfallzugriff ist dokumentiert. Wenn RDP fuer Recovery gebraucht wird, gibt es definierte Konten, Orte, Freigaben und Nachbereitung.

Der praktische Zielzustand: Eine normale Admin-Rolle kann einen DC nicht per RDP bedienen. Ein eng begrenzter Tier-0-Admin kann es aus einem kontrollierten Netz, mit nachvollziehbarer Anmeldung und nur fuer einen erklaerten Zweck.

Umsetzung: Rechte, Netz und Nachweis zusammenziehen

1) Aktuellen RDP-Zustand erfassen

Starte lesend. Auf Domain Controllern sollten diese Fragen beantwortet werden:

  • Ist RDP auf DCs aktiviert oder per GPO erzwungen?
  • Welche GPO setzt Allow log on through Remote Desktop Services?
  • Welche Gruppen stehen im erlaubenden Recht?
  • Gibt es Deny log on through Remote Desktop Services und welche Gruppen sind enthalten?
  • Aus welchen Netzen ist TCP 3389 auf DCs erreichbar?
  • Welche Konten haben in den letzten 30 bis 90 Tagen Logon Type 10 auf DCs erzeugt?

Ein einfacher Event-Startpunkt auf einem DC:

$start = (Get-Date).AddDays(-30)

Get-WinEvent -FilterHashtable @{
  LogName   = 'Security'
  Id        = 4624
  StartTime = $start
} | Where-Object {
  $_.Properties[8].Value -eq 10
} | Select-Object TimeCreated,
  @{Name='TargetUser';Expression={$_.Properties[5].Value}},
  @{Name='SourceAddress';Expression={$_.Properties[18].Value}},
  @{Name='LogonProcess';Expression={$_.Properties[9].Value}}

Die Property-Indizes sind je nach Eventversion nicht die schoenste Schnittstelle. Fuer ein Projekt reicht das als schneller Start. Fuer dauerhafte Auswertung gehoert die Logik in SIEM, Windows Event Forwarding oder eine robuste XML-basierte Event-Abfrage.

Ergaenze fehlgeschlagene Anmeldungen (4625), Session-Reconnects (4778), Disconnects (4779) und TerminalServices-Logs. Wichtig ist nicht nur "wer kam rein", sondern auch "wer versucht es regelmaessig".

2) DC-RDP nicht mit normalen Servern vermischen

Domain Controller brauchen eine eigene GPO oder mindestens einen klar getrennten GPO-Abschnitt. RDP-Regeln fuer Member Server sollten nicht unbesehen auf die Domain Controllers OU wirken.

Die relevanten Rechte liegen hier:

Computer Configuration
  Windows Settings
    Security Settings
      Local Policies
        User Rights Assignment

Besonders wichtig:

  • Allow log on through Remote Desktop Services
  • Deny log on through Remote Desktop Services
  • Allow log on locally
  • Deny log on locally

Fuer Domain Controller sollte das erlaubende RDP-Recht nur sehr eng vergeben werden. Ein konservativer Start ist Administrators, wenn diese Gruppe in der Umgebung sauber Tier-0-kontrolliert ist. Reifer ist eine dedizierte Tier-0-Gruppe fuer DC-Interaktivzugriff, aber nur wenn der Betrieb, Break-Glass und GPO-Wirkung sauber getestet sind.

Nicht sinnvoll ist eine breite Liste aus Helpdesk, Server Operators, Account Operators, Backup Operators, Applikationsadmins oder normalen Betriebsgruppen. Genau diese Vermischung ist der Risikotreiber.

3) Deny-Rechte vorsichtig einsetzen

Deny log on through Remote Desktop Services ist ein scharfes Werkzeug. Deny gewinnt gegen Allow. Das ist gut, wenn bekannte Nicht-Tier-0-Gruppen sicher ausgeschlossen werden sollen. Es ist schlecht, wenn eine breite Gruppe indirekt auch Domain Admins, Break-Glass-Konten oder privilegierte Servicekonten enthaelt.

Sinnvolle Kandidaten fuer Deny sind klar abgegrenzte Gruppen wie:

  • Helpdesk-Admin-Gruppen,
  • normale Serveradmin-Gruppen,
  • Service-Account-Deny-Gruppen,
  • Applikationsadmin-Gruppen ohne Tier-0-Aufgabe,
  • historische Operator-Gruppen, sofern sie nicht mehr fuer DC-Betrieb benoetigt werden.

Riskante Kandidaten sind:

  • Domain Users,
  • Authenticated Users,
  • sehr breite Mitarbeitergruppen,
  • Gruppen, deren Verschachtelung niemand geprueft hat,
  • Break-Glass- oder PAM-Gruppen.

Vor jedem Deny-Rollout gehoert eine Gruppenauflosung dazu. In der Praxis ist ein kleines Test-Set besser als eine grosse "alles blockieren"-Geste.

4) RDP technisch erreichbar nur aus Management-Netzen

User Rights reichen nicht. Wenn TCP 3389 aus breiten Client-, Server- oder VPN-Netzen erreichbar ist, wird jeder Fehlversuch zum staendigen Hintergrundrauschen und jede Fehlkonfiguration sofort relevant.

Begrenze RDP auf DCs mit zwei Ebenen:

  1. Windows Defender Firewall per GPO: Eingehende Remote-Desktop-Regeln nur fuer definierte Remote-IP-Bereiche erlauben.
  2. Netzwerk-Firewall oder ACL: Zugriff auf DC-RDP nur aus PAW-, Jump-Host- oder Management-Segmenten.

Der zweite Punkt ist wichtig. Host-Firewall-Regeln sind gut, aber DCs verdienen zusaetzliche Netzgrenzen. Wenn ein normaler Client oder ein beliebiger VPN-Endpunkt einen RDP-Handshake zum DC aufbauen kann, ist das Zielbild nicht erreicht.

5) NLA und RDP-Policy fest setzen

Pruefe die Einstellungen unter:

Computer Configuration
  Administrative Templates
    Windows Components
      Remote Desktop Services
        Remote Desktop Session Host
          Connections
          Security

Fuer DCs sind besonders relevant:

  • Allow users to connect remotely by using Remote Desktop Services
  • Require user authentication for remote connections by using Network Level Authentication
  • Set client connection encryption level

Wenn RDP auf DCs nicht benoetigt wird, kann die erste Einstellung fuer DCs deaktiviert werden. Wenn RDP als Notfallpfad bewusst erhalten bleibt, sollte NLA erzwungen und die Verbindung nicht fuer Altclients geschwaecht werden. Alte Thin Clients oder Fremdprodukte sind kein guter Grund, DC-RDP abzusenken.

6) Admin-Pfad ersetzen, nicht nur blockieren

Viele RDP-Ausnahmen entstehen, weil es keinen sauberen Ersatz gibt. Ein DC-Hardening-Projekt muss deshalb den normalen Admin-Pfad klaeren:

  • RSAT und AD-Verwaltung von PAWs oder geharteten Admin-Systemen,
  • PowerShell Remoting mit eingeschraenkten Admin-Konten und Logging,
  • zentrale Event- und Health-Abfragen statt manueller DC-Logins,
  • dokumentierte Wartungsablaeufe fuer DNS, GPO, Replikation und Zertifikate,
  • Break-Glass-Prozess fuer echte Notfaelle.

Wenn der Alltag weiter "auf den DC per RDP und dort klicken" lautet, wird jede technische Einschraenkung umgangen oder als Stoerung wahrgenommen. Der Betriebsprozess muss mitziehen.

7) Rollout in kleinen Wellen

Ein belastbarer Ablauf:

  1. Bestehende RDP-Logons und erlaubende Rechte auf allen DCs erfassen.
  2. Owner fuer legitime DC-RDP-Nutzung identifizieren.
  3. Zielgruppe fuer Tier-0-DC-RDP definieren.
  4. GPO auf eine Test-DC-Gruppe oder ein Wartungsfenster begrenzen.
  5. Netzwerk- und Host-Firewall-Regeln in derselben Welle pruefen.
  6. RDP mit berechtigtem Tier-0-Konto testen.
  7. RDP mit Helpdesk-, Serveradmin- und Service-Account-Testkonten negativ testen.
  8. Events und SIEM-Signale auswerten.
  9. Danach auf alle DCs ausrollen.

Negativtests sind wichtig. Ein erfolgreicher Admin-Login beweist nur, dass der Notfallpfad funktioniert. Er beweist nicht, dass unerwuenschte Rollen wirklich blockiert sind.

Vorteile

  • Klarere Tier-0-Grenze: Normale Betriebsrollen koennen DCs nicht mehr wie Member Server behandeln.
  • Weniger Credential-Risiko: Interaktive Sessions auf DCs werden seltener und besser nachvollziehbar.
  • Bessere Erkennung: Jeder DC-RDP-Versuch wird ein relevantes Signal statt normales Grundrauschen.
  • Stabilere Admin-Prozesse: RSAT, PowerShell, PAW und zentrale Verwaltung werden zum Standardpfad.
  • Reduzierter Angriffsweg nach Admin-Kompromittierung: Ein kompromittiertes Serveradmin- oder Helpdesk-Konto fuehrt nicht automatisch zur DC-Konsole.
  • Gute Auditierbarkeit: Rechte, Netzpfade und Eventlage lassen sich pruefbar dokumentieren.

Nachteile und Grenzen

  • Betriebsgewohnheiten muessen geaendert werden: Teams brauchen Ersatzprozesse fuer typische DC-Aufgaben.
  • Fehlkonfiguration kann aussperren: Zu harte Deny-Rechte oder falsche Gruppenverschachtelung koennen auch berechtigte Admins treffen.
  • RDP ist nur ein Pfad: LDAP, SMB, WinRM, RPC, ADUC, DNS-Konsole und GPO-Verwaltung muessen separat betrachtet werden.
  • NLA ersetzt keine starke Admin-Hygiene: Ein gueltiges, kompromittiertes Admin-Konto bleibt ein Problem.
  • Netzwerkgrenzen brauchen Pflege: Neue VPN-, PAW- oder Jump-Host-Segmente muessen bewusst nachgezogen werden.
  • Legacy-Notfaelle bleiben moeglich: In Recovery-Szenarien kann ein interaktiver DC-Zugriff weiter noetig sein.

Typische Stolperfallen

  • Domain Controllers OU mit Member-Server-GPOs behandeln: Dadurch landen normale Serveradmin-Regeln auf DCs.
  • Zu breite Deny-Gruppen verwenden: Domain Users kann indirekt auch Admin-Konten treffen, weil Deny gewinnt.
  • Nur User Rights setzen: Ohne Firewall-Begrenzung bleibt RDP netzweit sichtbar.
  • NLA fuer alte Clients abschwaechen: DCs sind kein Kompatibilitaetsziel fuer schwache RDP-Clients.
  • Break-Glass vergessen: Wenn der Notfallpfad fehlt, wird das Hardening beim ersten Problem zurueckgebaut.
  • Keine negativen Tests durchfuehren: Dann bleibt unklar, ob Helpdesk- oder Serveradmin-Konten wirklich blockiert sind.
  • Service-Accounts uebersehen: Technische Konten sollten keine interaktive DC-RDP-Option haben.
  • Events nicht zentralisieren: Lokale Eventlogs reichen nicht, wenn ein DC-Problem erst Wochen spaeter untersucht wird.

Projekt-Checkliste

  • [ ] Alle DCs, ihre RDP-Aktivierung und wirksamen GPOs inventarisieren.
  • [ ] Allow log on through Remote Desktop Services und Deny log on through Remote Desktop Services auf DCs pruefen.
  • [ ] RDP-Logons der letzten 30 bis 90 Tage aus Security- und TerminalServices-Logs auswerten.
  • [ ] Legitime DC-RDP-Nutzer auf dedizierte Tier-0-Gruppe oder eng kontrollierten Admin-Kreis reduzieren.
  • [ ] Helpdesk-, Serveradmin-, Service-Account- und Operator-Gruppen explizit bewerten.
  • [ ] Keine breiten Deny-Gruppen ohne vollstaendige Gruppenauflosung verwenden.
  • [ ] Windows Defender Firewall fuer DC-RDP auf PAW-, Jump-Host- oder Management-Subnetze begrenzen.
  • [ ] Netzwerk-Firewall oder ACLs fuer TCP 3389 auf DCs ergaenzen.
  • [ ] NLA erzwingen und RDP nicht fuer Altclients abschwaechen.
  • [ ] Normalen Admin-Pfad ueber PAW, RSAT, PowerShell und zentrale Logs dokumentieren.
  • [ ] Positivtests mit Tier-0-Admin und Negativtests mit normalen Adminrollen durchfuehren.
  • [ ] DC-RDP-Erfolge und -Fehlversuche in Monitoring und Review aufnehmen.
  • [ ] Break-Glass-Prozess mit Konten, Ort, Freigabe, Protokollierung und Nachbereitung dokumentieren.