Ausgangslage: technische Konten werden zu Ersatzbenutzern

In vielen Active-Directory-Umgebungen gibt es Service-Accounts, die urspruenglich fuer einen klaren Zweck angelegt wurden: Windows-Dienst, geplanter Task, IIS-App-Pool, Datenbankzugriff, Backup-Agent, Monitoring oder Schnittstellenkonto. Jahre spaeter sind manche dieser Konten aber nicht mehr nur Dienstidentitaeten. Sie haben bekannte Passwoerter, laufen auf mehreren Servern, werden von Administratoren fuer Tests genutzt und koennen 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 fuer Ausnahmen. Wenn sich ein solches Konto per RDP, lokal an der Konsole oder ueber 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 gefaehrden. Das Ziel ist eine klare Trennung: Service-Accounts duerfen genau die Logon-Typen nutzen, die sie fuer ihre Workloads brauchen. Menschliche Interaktion, RDP und lokale Anmeldung sind dafuer in der Regel nicht erforderlich.

Zielbild: Dienstidentitaeten 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 duerfen 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 moeglich, werden klassische Benutzer-Service-Accounts durch gMSA ersetzt.
  6. Logon-Versuche werden ueberwacht. 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 gefuellt werden. Genau deshalb gehoert 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 fuer 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 vollstaendiges Service-Account-Inventar. Konten fuer 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 fuer lokal/interaktiv,
  • Logon Type 10 fuer RemoteInteractive/RDP,
  • Logon Type 11 fuer CachedInteractive,
  • 4648 fuer Anmeldung mit expliziten Credentials.

Wenn ein Service-Account regelmaessig 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 enthaelt nur klassische Benutzer-Service-Accounts, fuer 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. Fuer 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

Fuer 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: wuerde genau die Dienste brechen, fuer 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 geprueft 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-Einfuehrung 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 fuer 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 vollstaendige Service-Account-Strategie. Es reduziert einen konkreten Missbrauchspfad. Parallel sollten besonders kritische Konten auf gMSA-Eignung, Passwortrotation, minimale Gruppenmitgliedschaften und SPN-Ownership geprueft werden.

gMSA ist nicht fuer jede Drittanwendung geeignet, aber fuer viele Windows-nahe Workloads deutlich sauberer: kein manuell bekanntes Passwort, automatische Rotation und bessere Bindung an berechtigte Hosts. Wo gMSA nicht moeglich ist, braucht das klassische Konto mindestens Owner, Zweck, erlaubte Hosts, Passwortrotation und Logon-Einschraenkungen.

Vorteile

  • Weniger Credential-Spuren: Service-Account-Passwoerter landen seltener in interaktiven Sessions, RDP-Profilen oder Admin-Workflows.
  • Klarere Verantwortlichkeit: Technische Konten werden wieder als Workload-Identitaeten behandelt, nicht als Shared User.
  • Bessere Signale: Interaktive Logon-Versuche eines Service-Accounts werden auffaellig und auswertbar.
  • Geringe technische Einstiegshuerde: Die noetigen User Rights Assignments sind in Windows/GPO vorhanden.
  • Passt zu Tiering und gMSA: Die Massnahme ergaenzt bestehende AD-Hardening-Bausteine, statt sie zu ersetzen.
  • Reduziert Seiteneffekte alter Admin-Gewohnheiten: Tests und Notfallzugriffe muessen ueber richtige Admin- oder Break-Glass-Prozesse laufen.

Nachteile und Grenzen

  • Fehlkonfiguration kann Betrieb stoeren: Zu breite Deny-Gruppen oder falsch verlinkte GPOs koennen legitime Arbeitsablaeufe blockieren.
  • Nicht jeder Logon-Typ wird geloest: Dienste, Batch-Jobs und Netzwerkzugriffe brauchen eigene Rechte- und Host-Einschraenkungen.
  • Legacy-Anwendungen brauchen Analyse: Manche Produkte nutzen technische Konten unsauber fuer 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 moeglich: Drittprodukte, Appliances oder alte Plattformen unterstuetzen 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 gehoeren 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 zusammenfuehren.
  • [ ] Owner, Zweck, erlaubte Hosts, SPNs, Passwortalter und Gruppenmitgliedschaften dokumentieren.
  • [ ] Security-Events fuer Logon Types 2, 10, 11 und 4648 fuer Service-Accounts auswerten.
  • [ ] Pilotgruppe fuer 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 fuer kritische oder breit genutzte Konten pruefen.
  • [ ] Ausnahmen befristen und mit Owner, Grund und Ablaufdatum dokumentieren.
  • [ ] Provisioning-Regel fuer neue Service-Accounts ergaenzen: kein interaktiver Login ohne genehmigte Ausnahme.