Ausgangslage: technische Konten werden zu Ersatzbenutzern

In vielen Active-Directory-Umgebungen gibt es Service-Accounts, die ursprünglich für einen klaren Zweck angelegt wurden: Windows-Dienst, geplanter Task, IIS-App-Pool, Datenbankzugriff, Backup-Agent, Monitoring oder Schnittstellenkonto. Jahre später sind manche dieser Konten aber nicht mehr nur Dienstidentitäten. Sie haben bekannte Passwörter, laufen auf mehreren Servern, werden von Administratoren für Tests genutzt und können sich interaktiv anmelden.

Das ist ein unnötig breiter Risikopfad. Ein Service-Account hat oft mehr Rechte als ein normaler Benutzer, aber weniger Schutz als ein Admin-Konto: keine MFA, seltene Passwortrotation, unklare Owner, lange Laufzeit und hohe Toleranz für Ausnahmen. Wenn sich ein solches Konto per RDP, lokal an der Konsole oder über normale interaktive Windows-Sessions anmelden darf, entstehen Credential-Spuren, unklare Verantwortlichkeit und ein leichter Missbrauchspfad.

Das Ziel ist nicht, jeden technischen Account hart zu sperren und den Betrieb zu gefährden. Das Ziel ist eine klare Trennung: Service-Accounts dürfen genau die Logon-Typen nutzen, die sie für ihre Workloads brauchen. Menschliche Interaktion, RDP und lokale Anmeldung sind dafür in der Regel nicht erforderlich.

Zielbild: Dienstidentitäten ohne Mensch-Login

Ein sauberes Zielbild hat mehrere konkrete Eigenschaften:

  1. Service-Accounts sind inventarisiert und haben Owner. Niemand muss raten, welche Anwendung oder welches Team hinter einem Konto steht.
  2. Interaktive Anmeldung ist blockiert. Service-Accounts dürfen sich nicht lokal, per RDP oder als normale Benutzersession anmelden.
  3. Service- und Batch-Rechte sind gezielt vergeben. Log on as a service und Log on as a batch job gelten nur dort, wo der Workload sie braucht.
  4. Deny-Rechte sind bewusst eingesetzt. Deny log on locally und Deny log on through Remote Desktop Services werden genutzt, aber mit Testgruppen, Scope und Rollback.
  5. Privilegierte Service-Accounts werden reduziert. Wo möglich, werden klassische Benutzer-Service-Accounts durch gMSA ersetzt.
  6. Logon-Versuche werden überwacht. Ein interaktiver Logon-Versuch eines Service-Accounts ist kein normales Betriebsrauschen.

Wichtig: Deny-Rechte gewinnen gegen Allow-Rechte. Das ist sicherheitstechnisch gewollt, aber betrieblich riskant, wenn Gruppen zu breit gefüllt werden. Genau deshalb gehört die Umsetzung in Wellen.

Umsetzung: erst sichtbar machen, dann blockieren

1) Service-Accounts realistisch inventarisieren

Starte nicht mit einer GPO, sondern mit einer Liste. Es gibt selten eine perfekte Quelle. Kombiniere mehrere Signale:

  • Konten mit SPNs,
  • Konten mit PasswordNeverExpires,
  • Konten in Service-, SQL-, IIS-, Backup-, Monitoring- oder Applikationsgruppen,
  • dokumentierte Konten aus CMDB, PAM, Passworttresor und Applikationsbetrieb,
  • Konten, die in Diensten, Tasks oder App-Pools konfiguriert sind,
  • Konten mit alten Passworten oder sehr langer letzter Anmeldung.

Eine read-only AD-Abfrage für einen ersten SPN-Blick:

Import-Module ActiveDirectory

Get-ADUser -LDAPFilter '(servicePrincipalName=*)' `
  -Properties ServicePrincipalName,Enabled,PasswordNeverExpires,PasswordLastSet,LastLogonDate,Description |
  Select-Object SamAccountName,Enabled,PasswordNeverExpires,PasswordLastSet,LastLogonDate,Description,ServicePrincipalName

Das ist kein vollständiges Service-Account-Inventar. Konten für geplante Tasks, lokale Dienste oder Drittprodukte haben nicht zwingend SPNs. Die Abfrage liefert nur einen belastbaren Startpunkt.

2) Interaktive Nutzung vor dem Change suchen

Vor dem Blockieren muss klar sein, ob ein Konto heute interaktiv genutzt wird. Relevante Windows-Signale sind vor allem Security-Events auf Servern und Domain Controllern:

  • 4624 erfolgreiche Anmeldung,
  • 4625 fehlgeschlagene Anmeldung,
  • Logon Type 2 für lokal/interaktiv,
  • Logon Type 10 für RemoteInteractive/RDP,
  • Logon Type 11 für CachedInteractive,
  • 4648 für Anmeldung mit expliziten Credentials.

Wenn ein Service-Account regelmäßig Logon Type 10 erzeugt, ist das kein GPO-Problem, sondern ein Betriebsprozess: Wer nutzt das Konto, warum, von welchem System und mit welcher Alternative? Erst danach blockieren.

3) Gruppenmodell klein und eindeutig halten

Ein praktikables Muster ist eine dedizierte Sicherheitsgruppe, zum Beispiel:

  • GG-Deny-ServiceAccounts-InteractiveLogon
  • optional getrennt nach Tier oder Umgebung, etwa GG-T0-Deny-ServiceAccounts-InteractiveLogon

Diese Gruppe enthält nur klassische Benutzer-Service-Accounts, für die interaktive Anmeldung untersagt werden soll. Keine normalen Benutzer, keine Admin-Konten, keine Break-Glass-Konten, keine Gruppen ohne Owner.

Die Gruppe wird dann per GPO auf passende Server- und Workstation-OUs angewendet. Für Domain Controller braucht es eine eigene Bewertung und eine eigene, eng kontrollierte Policy. Tier-0-Systeme sollten zuerst mit wenigen, gut verstandenen Konten getestet werden.

4) User Rights Assignment per GPO setzen

Die zentralen Einstellungen liegen unter:

Computer Configuration
  Windows Settings
    Security Settings
      Local Policies
        User Rights Assignment

Für Service-Accounts sind besonders relevant:

  • Deny log on locally (SeDenyInteractiveLogonRight)
  • Deny log on through Remote Desktop Services (SeDenyRemoteInteractiveLogonRight)

Diese beiden Rechte blockieren die typischen Mensch-Login-Pfade. Sie sollten auf die Deny-Gruppe zeigen.

Nicht pauschal setzen:

  • Deny log on as a service: würde genau die Dienste brechen, für die Service-Accounts existieren.
  • Deny log on as a batch job: kann geplante Tasks oder Job-Systeme brechen.
  • Deny access to this computer from the network: kann Dateifreigaben, Applikationszugriffe und Remote-Management unbrauchbar machen.

Parallel sollte geprüft werden, wo Log on as a service und Log on as a batch job heute zu breit vergeben sind. Das ist aber ein eigener Schritt und sollte nicht mit der Deny-Einführung vermischt werden.

5) In Wellen ausrollen

Ein sauberes Vorgehen:

  1. Pilotgruppe mit wenigen bekannten Service-Accounts bilden.
  2. GPO auf eine kleine Servergruppe mit klaren Ownern verlinken.
  3. gpupdate oder normalen GPO-Refresh abwarten.
  4. Dienste, Tasks, App-Pools und Applikationsfunktionen testen.
  5. Security-Events für blockierte interaktive Logons auswerten.
  6. Rollout auf weitere OUs und Kontogruppen erweitern.

Der wichtigste Punkt: Ein blockierter interaktiver Logon ist oft ein gewollter Fund. Trotzdem braucht der Betrieb eine schnelle Antwort: Ist es ein legitimer alter Arbeitsablauf, ein Fehlgebrauch durch Admins, ein falsch dokumentierter Dienst oder ein verdächtiges Ereignis?

6) gMSA und Passwortdisziplin parallel bewerten

Das Blockieren interaktiver Anmeldung ist keine vollständige Service-Account-Strategie. Es reduziert einen konkreten Missbrauchspfad. Parallel sollten besonders kritische Konten auf gMSA-Eignung, Passwortrotation, minimale Gruppenmitgliedschaften und SPN-Ownership geprüft werden.

gMSA ist nicht für jede Drittanwendung geeignet, aber für viele Windows-nahe Workloads deutlich sauberer: kein manuell bekanntes Passwort, automatische Rotation und bessere Bindung an berechtigte Hosts. Wo gMSA nicht möglich ist, braucht das klassische Konto mindestens Owner, Zweck, erlaubte Hosts, Passwortrotation und Logon-Einschränkungen.

Vorteile

  • Weniger Credential-Spuren: Service-Account-Passwörter landen seltener in interaktiven Sessions, RDP-Profilen oder Admin-Workflows.
  • Klarere Verantwortlichkeit: Technische Konten werden wieder als Workload-Identitäten behandelt, nicht als Shared User.
  • Bessere Signale: Interaktive Logon-Versuche eines Service-Accounts werden auffällig und auswertbar.
  • Geringe technische Einstiegshürde: Die nötigen User Rights Assignments sind in Windows/GPO vorhanden.
  • Passt zu Tiering und gMSA: Die Maßnahme ergänzt bestehende AD-Hardening-Bausteine, statt sie zu ersetzen.
  • Reduziert Seiteneffekte alter Admin-Gewohnheiten: Tests und Notfallzugriffe müssen über richtige Admin- oder Break-Glass-Prozesse laufen.

Nachteile und Grenzen

  • Fehlkonfiguration kann Betrieb stören: Zu breite Deny-Gruppen oder falsch verlinkte GPOs können legitime Arbeitsabläufe blockieren.
  • Nicht jeder Logon-Typ wird gelöst: Dienste, Batch-Jobs und Netzwerkzugriffe brauchen eigene Rechte- und Host-Einschränkungen.
  • Legacy-Anwendungen brauchen Analyse: Manche Produkte nutzen technische Konten unsauber für Wartung, Konsolen oder Remote-Aktionen.
  • Deny ist hart: Wenn ein Konto in der Deny-Gruppe landet, gewinnt diese Einstellung gegen erlaubende Rechte.
  • gMSA ist nicht immer sofort möglich: Drittprodukte, Appliances oder alte Plattformen unterstützen es nicht zwingend.
  • Monitoring bleibt erforderlich: Eine GPO verhindert nicht automatisch, dass neue Service-Accounts wieder falsch angelegt werden.

Typische Stolperfallen

  • Alle Service-Accounts in eine Gruppe kippen: Ohne Owner und Test entsteht ein Blindflug.
  • Deny-Rechte auf falsche OUs verlinken: Eine gute Einstellung am falschen Scope ist ein Ausfallrisiko.
  • Batch und Service verwechseln: Interaktive Anmeldung blockieren ist nicht dasselbe wie Log on as a service entziehen.
  • Domain Controller wie normale Member Server behandeln: DCs brauchen eine separate Tier-0-Policy und vorsichtige Testabdeckung.
  • Break-Glass-Konten miterfassen: Notfallkonten gehören nicht in breite Deny-Gruppen.
  • Keine Events nach dem Rollout lesen: Dann bleiben legitime Bruchstellen und verdächtige Versuche unsichtbar.
  • Neue Konten ohne Prozess zulassen: Service-Account-Hardening scheitert schnell, wenn Provisioning und Review nicht angepasst werden.

Projekt-Checkliste

  • [ ] Service-Accounts aus AD, CMDB, PAM, Passworttresor, GPOs und Applikationsbetrieb zusammenführen.
  • [ ] Owner, Zweck, erlaubte Hosts, SPNs, Passwortalter und Gruppenmitgliedschaften dokumentieren.
  • [ ] Security-Events für Logon Types 2, 10, 11 und 4648 für Service-Accounts auswerten.
  • [ ] Pilotgruppe für Deny log on locally und Deny log on through Remote Desktop Services erstellen.
  • [ ] GPO-Scope klein starten und DCs/Tier-0 getrennt behandeln.
  • [ ] Dienste, Tasks, App-Pools und Applikationen nach GPO-Refresh testen.
  • [ ] Blockierte interaktive Logons im SIEM oder Eventlog als Signal aufnehmen.
  • [ ] gMSA-Eignung für kritische oder breit genutzte Konten prüfen.
  • [ ] Ausnahmen befristen und mit Owner, Grund und Ablaufdatum dokumentieren.
  • [ ] Provisioning-Regel für neue Service-Accounts ergänzen: kein interaktiver Login ohne genehmigte Ausnahme.