Der Wartungsjob läuft mit einem Kennwort aus der Datei

Ein Managementserver prüft nachts Dienste auf mehreren Mitgliedsservern. Das Skript importiert eine vor Jahren exportierte Credential-Datei. Welches Team das Konto verantwortet, welche weiteren Jobs es verwenden und weshalb es Administratorrechte auf allen Zielen besitzt, ist unklar. Nach einem Serverumzug funktioniert die Entschlüsselung nicht mehr. Als schnelle Reparatur entsteht die nächste Datei.

Solche Abhängigkeiten bleiben auch bestehen, wenn WinRM Basic Authentication bereits abgeschaltet ist. Transport, Authentifizierungsverfahren und Speicherung von Geheimnissen sind unterschiedliche Kontrollen. Der bestehende Beitrag zum Abschalten von Basic Auth behandelt die Protokoll-Baseline; hier geht es um Identitäten, Kennwortlebenszyklus und die Ablösung vorhandener Credential-Kopien.

Der Scope umfasst administrative Arbeitsplätze, Automatisierungsserver, geplante Aufgaben und deren konkrete Zielsysteme. Tier-0-Verwaltung wird getrennt betrachtet. Ein allgemeiner Jobserver bekommt durch die Bereinigung keinen neuen Zugang zu Domain Controllern.

Jede Verbindung erhält eine nachvollziehbare Identität

Für interaktive Domänenadministration ist die angemeldete, passend berechtigte Identität auf einem geschützten Verwaltungsrechner der Ausgangspunkt. Automatisierung erhält eine eigene Dienstidentität mit genau den benötigten Rechten. Ein unvermeidbares Kennwort wird zentral verwaltet und nur bei Bedarf bereitgestellt. Es gehört weder in das Repository noch als dauerhaftes Administratorkonto in ein Profilverzeichnis.

Die Abnahme verlangt mehr als einen erfolgreichen Job: Ausführungskonto, erlaubte Ziele, benötigte Operationen, nachgelagerte Ressourcen und verantwortliches Team sind dokumentiert. Es existiert ein getesteter Wiederanlauf ohne persönliche Credential-Datei. Ein entzogenes Recht führt zu einem sichtbaren Fehler, nicht zu einem automatischen Wechsel auf ein mächtigeres Ersatzkonto.

Verschlüsselte Credential-Dateien bleiben nutzbare Geheimnisse

Unter Windows schützt Export-Clixml exportierte Credentials mit DPAPI und bindet ihre Entschlüsselung an Benutzer und Rechner. Unter Linux und macOS bietet dieser Export keinen entsprechenden Verschlüsselungsschutz. Die Windows-Bindung schützt die Datei bei bestimmten Zugriffsszenarien, macht sie aber nicht zu einer sicheren Grenze gegenüber Prozessen im berechtigten Benutzerkontext.

Für den Betrieb bleibt entscheidend: Das Skript muss das Geheimnis wieder verwenden können. Ein vorhandenes SecureString oder eine XML-Datei ersetzt daher keine begrenzten Berechtigungen, Rotation und Kontrolle des Ausführungssystems. Auch ein separat abgelegter Entschlüsselungsschlüssel löst das Problem nicht, wenn derselbe Job beide Dateien lesen darf.

Zuerst Abhängigkeiten erfassen, keine Kennwörter einsammeln

Die Inventur beginnt bei freigegebenen Skriptverzeichnissen, Jobdefinitionen, Runbooks und Konfigurationen. Gesucht werden Verwendungen von Import-Clixml, expliziten Credentials, Credential-Manager-Einträgen und festen RunAs-Konten. Dokumentiert werden Fundstelle und Zweck; Geheimnisse werden weder entschlüsselt noch in Tickets oder zentrale Suchergebnisse kopiert.

Pro Ablauf reichen zunächst sechs Angaben: Startsystem, Ausführungskonto, Zielsystem, benötigte Rechte, weitere Ressourcen und Eigentümer. Monatsläufe, Wiederherstellungsjobs und manuell gestartete Wartung zählen ausdrücklich dazu. Ein fehlender Kennwortparameter im Skript beweist nicht, dass die Ausführungsplattform kein Kennwort speichert.

Anschließend wird jeder Fund einem Ersatzmuster zugeordnet. Erst wenn die Abhängigkeiten bekannt sind, beginnt die Umstellung. Pauschales Löschen aller Credential-Manager-Einträge oder Zurücksetzen gemeinsam genutzter Konten wäre keine kontrollierte Bereinigung. Die Inventur muss so konkret sein, dass andere Betreiber die gemeinte Abhängigkeit ohne Zugriff auf ein Geheimnis erkennen können.

Kerberos für den direkten Remoting-Pfad prüfen

Bei einem direkten Zugriff vom Verwaltungsrechner auf einen Domänenserver kann Kerberos die aktuelle Identität nutzen, ohne ein separat gespeichertes Kennwort an das Skript zu übergeben. DNS, Zeitabgleich, Vertrauensstellung und Dienstidentität müssen zum gewählten Zielnamen passen. Negotiate ist kein Nachweis, dass tatsächlich Kerberos verwendet wurde.

Der folgende lesende Test erzwingt Kerberos. Den Beispielnamen durch einen freigegebenen FQDN ersetzen und im vorgesehenen Ausführungskontext starten:

$remoteCheck = @{
    ComputerName = 'srv01.ad.example.com'
    Authentication = 'Kerberos'
    ErrorAction = 'Stop'
    ScriptBlock = {
        [pscustomobject]@{
            Computer = $env:COMPUTERNAME
            Identity = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
        }
    }
}
Invoke-Command @remoteCheck

Dieser Test prüft Anmeldung und effektive Identität im Standardendpunkt. Er belegt keine fachlichen Berechtigungen und keinen Zugriff auf weitere Server. Ein geplanter Job muss zusätzlich unter seinem tatsächlichen Konto laufen; der erfolgreiche Aufruf aus einer Administrator-Sitzung reicht nicht. Fehler führen zur Prüfung von Namen, SPNs und Berechtigungen, nicht zum Aktivieren von Basic oder breiten TrustedHosts.

Für Automation gMSA und begrenzte Endpunkte wählen

Unterstützt die Ausführungsplattform ein Group Managed Service Account, übernimmt Windows dessen Kennwortverwaltung. Ein gMSA ist weiterhin eine privilegierbare Identität, kein kennwortloser Sicherheitszauber. Nur die vorgesehenen Hosts dürfen es verwenden; das Konto erhält ausschließlich benötigte Zielrechte. Unterstützung durch Scheduler oder Produkt vor der Migration nachweisen.

Für wiederkehrende, klar begrenzte Verwaltungsaufgaben ist Just Enough Administration geeignet. Die zugelassenen Befehle und Parameter werden an der Aufgabe ausgerichtet. Virtuelle Konten vermeiden ein gepflegtes RunAs-Kennwort für lokale Tätigkeiten; für benötigte Netzwerkzugriffe kann ein gMSA die Ausführungsidentität bilden. Dabei müssen Sitzungsprotokolle die gemeinsame Dienstidentität wieder dem aufrufenden Benutzer zuordnen.

Bei JEA auf Domain Controllern sind die Standardrechte virtueller Konten besonders kritisch: Ohne angepasste Gruppenzuweisung erhalten sie Domain-Admins-Mitgliedschaft. Zulässige Befehle deshalb eng begrenzen und Ausführungsrechte bewusst reduzieren. Bestehende Volladministratorrechte verschwinden durch einen zusätzlichen JEA-Endpunkt nicht.

Falls eine Anwendung zwingend ein Kennwort benötigt, kommt ein betriebener Vault mit begrenzter Zugriffsidentität, Rotation und protokolliertem Abruf infrage. Auch dessen Anmeldung benötigt ein tragfähiges Konzept. SecretManagement kann eine Schnittstelle liefern, ist jedoch selbst keine Garantie für sichere Speicherung oder automatische Rotation. Ein Vault-Token neben dem Skript wäre lediglich ein neues dauerhaftes Geheimnis.

Den zweiten Hop als eigenen Zugriff entwerfen

Verbindet sich Rechner A per Remoting mit B und benötigt B eine Ressource auf C, ist das ein zusätzlicher Authentifizierungspfad. Direkter Kerberos-Erfolg auf B erlaubt nicht automatisch den Zugriff auf C. CredSSP kann Credentials auf B verfügbar machen und erhöht damit dessen Vertrauensanforderungen; es ist kein Standardersatz für eine entfernte Kennwortdatei.

Zuerst prüfen, ob der Orchestrator A beide Ziele direkt erreichen und Ergebnisse zusammenführen kann. Andernfalls benötigt B eine bewusst gewählte, begrenzte Ausführungsidentität. Kerberos Constrained Delegation und Resource-based Constrained Delegation unterstützen keinen zweiten Hop über WinRM. Für andere nachgelagerte Dienste muss deren Protokoll separat geprüft werden.

Umstellen, beobachten und alte Geheimnisse entwerten

Ein Pilot umfasst einen häufigen Job, einen seltenen Wartungsablauf und einen Ablauf mit zusätzlicher Netzwerkressource. Zunächst Identität und Rechte bereitstellen, dann den Job umstellen und Ergebnis sowie Protokollierung prüfen. Fehlversuche müssen ein Ziel und einen Betriebsfehler erkennen lassen, ohne Geheimnisse auszugeben.

Nach erfolgreicher Abnahme werden alte Verweise und aktive Credential-Kopien gezielt entfernt. Nicht mehr benötigte Konten werden stillgelegt; weiter benötigte statische Kennwörter nach Abstimmung aller Verbraucher rotiert. Backups und Repository-Historie können ältere Kopien enthalten. Dateien zu löschen entwertet solche Kopien nicht. Bereits ausgestellte Tickets und laufende Sitzungen müssen bei der Stilllegung gesondert berücksichtigt werden.

Der Rückfallplan besteht aus einem kontrollierten Wiederanlauf, einem Verantwortlichen und einer zeitlich begrenzten Ausnahme. Er darf keine vergessene Kopie des alten Domain-Admin-Kennworts voraussetzen. Dokumentiert werden der Wiederanlauftest und der Ablageort des Runbooks für das zuständige Betriebsteam.

Vorteile: weniger Kopien und klare Zuständigkeiten

  • Wiederverwendbare Admin-Geheimnisse verschwinden aus alltäglichen Skript- und Profilverzeichnissen.
  • Getrennte Dienstidentitäten begrenzen die Auswirkungen eines einzelnen fehlerhaften Jobs.
  • Rechte, Zielsysteme und Eigentümer lassen sich je Ablauf prüfen.
  • Wiederanlauf und Kontowechsel werden planbar statt von persönlichen Exportdateien abhängig.

Nachteile und Grenzen: der Ausführungshost bleibt kritisch

  • Rollenmodell, Migration und Tests verursachen Aufwand; ältere Produkte unterstützen nicht jedes Identitätsmuster.
  • Ein kompromittierter berechtigter Host kann weiterhin seine erlaubten Zugriffe ausführen.
  • gMSA und Vault reduzieren manuelle Kennwortpflege, ersetzen aber keine sichere Hostverwaltung.
  • Gemeinsam verwendete Ausführungsidentitäten erschweren die Zuordnung ohne ausreichende Sitzungsdaten.
  • Vault-Ausfall, Rechteänderungen und seltene Jobs brauchen einen erprobten Betriebsprozess.

Projekt-Checkliste für die Abnahme

  • Credential-Verwendungen und seltene Abläufe ohne Sammlung von Geheimnissen erfasst.
  • Ausführungskonto, Ziele, Rechte und Eigentümer je Job festgelegt.
  • Tier-0-Zugriffe von allgemeiner Serverautomation getrennt.
  • Direkter Kerberos-Pfad im echten Ausführungskontext erfolgreich geprüft.
  • gMSA-Unterstützung beziehungsweise Vault-Anmeldung praktisch nachgewiesen.
  • JEA-Befehle, Parameter und effektive Ausführungsrechte kontrolliert.
  • Jeder zweite Hop mit Zielprotokoll und eigener Identitätsentscheidung dokumentiert.
  • Positive Funktionstests und negative Berechtigungstests bestanden.
  • Protokolle liefern Zuordnung und Fehler, jedoch keine Kennwörter oder Tokens.
  • Alte Kopien entfernt, betroffene Geheimnisse entwertet und Sitzungen berücksichtigt.
  • Wiederanlauf, Ausnahmenablauf und regelmäßige Rechteprüfung einem Team zugewiesen.