Dienstkonten fallen häufig erst auf, wenn eine Anwendung nach einem Kennwortwechsel ausfällt. Dabei sind sie dauerhaft Teil der Sicherheitsarchitektur. Ein Konto kann auf mehreren Servern laufen, auf Dateifreigaben zugreifen und Aufgaben ausführen, ohne dass täglich jemand seine Verwendung betrachtet.
Aha-Moment
Ein automatisch verwaltetes Kennwort verbessert den Betrieb eines Dienstkontos. Es beantwortet aber nicht, ob dieses Konto zu viele Rechte besitzt.
Mit einem brauchbaren Inventar beginnen
Die erste Frage lautet nicht, welches Kontomodell am modernsten klingt. Zuerst muss feststehen, welche Anwendung welches Konto tatsächlich benutzt. Erfassen Sie Windows-Dienste, geplante Aufgaben, Anwendungspools und andere relevante Ausführungsorte. Ergänzen Sie den fachlich Verantwortlichen und einen technischen Ansprechpartner.
| Inventarfeld | Warum es benötigt wird |
|---|---|
| Anwendung und Zweck | Verhindert eine spätere Zuordnung nach Vermutung |
| Ausführende Hosts | Zeigt die tatsächliche Reichweite |
| Zielressourcen | Begründet Datei-, Datenbank- oder Verzeichnisrechte |
| Kontotyp und Kennwortverfahren | Macht Wartungsabhängigkeiten sichtbar |
| Verantwortlicher und Prüftermin | Verhindert herrenlose Dauerzugänge |
Eine Kontoliste ohne Verwendung ist unvollständig. Umgekehrt reicht eine Diensteliste nicht aus, wenn dieselbe Identität noch auf weiteren Systemen eingesetzt wird.
Rechte aus der Aufgabe ableiten
Beginnen Sie mit dem benötigten Zugriff: Muss die Anwendung eine Datei lesen, einen bestimmten Datensatz schreiben oder tatsächlich Systeme administrieren? Die Antwort sollte sich in den vergebenen Rechten wiederfinden. Microsoft empfiehlt für lokale AD-Dienstkonten unter anderem die Vermeidung unnötig privilegierter Gruppenmitgliedschaften. Microsoft: Einführung in AD-Dienstkonten.
Eine breit berechtigte Gruppe ist bequem, erschwert aber die spätere Bewertung. Wenn ein Produkt zunächst erhöhte Installationsrechte benötigt, ist zusätzlich zu prüfen, ob diese Rechte auch für den Dauerbetrieb erforderlich sind. Installation und Betrieb sind unterschiedliche Aufgaben.
Wo ein gMSA helfen kann
Ein group Managed Service Account erlaubt Windows die Verwaltung des Kontokennworts und kann von mehreren dafür vorgesehenen Hosts verwendet werden. Das reduziert manuelle Kennwortpflege, setzt jedoch eine geeignete AD-Umgebung und Unterstützung durch den konkreten Dienst voraus. Microsoft: gMSA-Übersicht.
Prüfen Sie vor der Auswahl die Produktdokumentation und den tatsächlichen Betriebsfall. Nicht jede Anwendung akzeptiert jeden Kontotyp. Auch ein gMSA benötigt eine bewusst begrenzte Berechtigung für seine Ressourcen. Die Frage, welche Hosts das Konto verwenden beziehungsweise sein Kennwort beziehen dürfen, gehört ausdrücklich zur Prüfung.
Eine Migration nicht mit dem Kontowechsel beenden
Bereiten Sie zunächst einen Pilot vor. Dokumentieren Sie die bisherige Dienstidentität, die benötigten Zugriffe und einen Rückweg. Prüfen Sie anschließend den Start, die normale Verarbeitung und die Verbindung zu nachgelagerten Systemen. Ein Fehler kann erst beim nächsten geplanten Lauf sichtbar werden.
Definieren Sie deshalb einen Zeitraum, in dem der Dienst beobachtet wird. Halten Sie fest, welche Verarbeitung tatsächlich durchgeführt wurde. „Dienst läuft“ ist weniger aussagekräftig als ein erfolgreich abgeschlossener fachlicher Vorgang mit dem neuen Konto.
Tier-Grenzen und Lebenszyklus erhalten
Ein einziges universelles Dienstkonto sollte nicht zur unbeabsichtigten Verbindung zwischen unterschiedlichen Schutzbereichen werden. Bewerten Sie jede weitere Verwendung als Änderung des bestehenden Umfangs. Wenn eine neue Anwendung hinzukommt, müssen Rechte, Hosts und Verantwortlichkeiten erneut betrachtet werden.
Bei Stilllegung einer Anwendung wird zunächst geprüft, ob das Konto noch anderweitig benötigt wird. Danach folgt eine kontrollierte Deaktivierung mit dokumentierter Beobachtung. Unbekannte Abhängigkeiten werden nicht durch eine spontane Löschaktion behoben.
Was die regelmäßige Kontrolle liefern sollte
Eine Wiederholungsprüfung vergleicht Inventar und tatsächliche Nutzung. Neue Hosts, zusätzliche Gruppen oder eine fehlende Zuständigkeit werden als Änderung sichtbar. Ausnahmen erhalten eine Begründung und einen nächsten Prüftermin. Dadurch bleibt die Arbeit auch nach einem Dienstleisterwechsel nachvollziehbar.
Weiterführend: Technischer IT-Audit und Sollzustand und Konfigurationsabweichungen nachweisen.
Dienstkontenprüfung mit Hamburger IT-Service planen. Fachliche Quellenprüfung: 25. September 2026.
Credential Guard konfigurieren und prüfen: Was geschützt wird und was nicht
Phishingresistente Anmeldung planen: Warum ein neues Verfahren allein nicht genügt
Standortübergreifende Administration absichern: Windows-Zugriffe in Geesthacht und Schleswig-Holstein
Windows 10 Support-Ende: Fristen, Versionen, ESU und Folgen
Windows-Systemhärtung vor Ort: Prüfablauf für Hamburg und bundesweite Projekte
