Schützen von eigenständigen verwalteten Dienstkonten

Eigenständige verwaltete Dienstkonten (Standalone Managed Service Accounts, sMSAs) sind verwaltete Domänenkonten zum Schutz von Diensten, die auf einem Server ausgeführt werden. Sie können nicht auf mehreren Servern wiederverwendet werden. sMSAs bieten eine automatische Kennwortverwaltung, eine einfachere Verwaltung des Dienstprinzipalnamens (SPN) und die Möglichkeit, die Verwaltung an andere Administrator*innen zu delegieren.

In Active Directory (AD) sind sMSAs an einen bestimmten Server gebunden, auf dem ein Dienst ausgeführt wird. Sie finden diese Konten in der Microsoft Management Console im Snap-In „Active Directory-Benutzer und -Computer“.

Hinweis

Verwaltete Dienstkonten wurden mit dem Active Directory-Schema für Windows Server 2008 R2 eingeführt und erfordern mindestens Windows Server 2008 R2.

Vorteile von sMSA

sMSAs bieten gegenüber der Verwendung von Benutzerkonten als Dienstkonten mehr Sicherheit. Sie tragen dazu bei, den Verwaltungsaufwand zu reduzieren:

  • Sichere Kennwörter: Von sMSAs werden komplexe, nach dem Zufallsprinzip generierte Kennwörter mit 240 Byte verwendet.
    • Die Komplexität minimiert die Wahrscheinlichkeit einer Kompromittierung durch Brute-Force- oder Wörterbuchangriffe.
  • Regelmäßige Änderung von Kennwörtern: Das sMSA-Kennwort wird von Windows alle 30 Tage geändert.
    • Dienst- und Domänenadministrator*innen müssen keine Kennwortänderungen planen oder damit verbundene Ausfallzeiten verwalten.
  • Vereinfachte SPN-Verwaltung: Dienstprinzipalnamen werden aktualisiert, wenn Windows Server 2008 R2 die Domänenfunktionsebene ist. Der SPN wird aktualisiert, wenn Sie:
    • das Hostcomputerkonto umbenennen.
    • den DNS-Namen (Domain Name Server) des Hostcomputers ändern.
    • mithilfe von PowerShell andere „sam-accountname“- oder „dns-hostname“-Parameter hinzufügen oder entfernen.
    • Weitere Informationen finden Sie unter Set-ADServiceAccount.

Verwenden von sMSAs

Mit sMSAs können Sie Verwaltungs- und Sicherheitsaufgaben vereinfachen. sMSAs sind hilfreich, wenn Dienste auf einem Server bereitgestellt wurden und Sie kein gruppenverwaltetes Dienstkonto (Group Managed Service Account, gMSA) verwenden können.

Hinweis

Sie können sMSAs für mehrere Dienste verwenden, es wird jedoch zu Überwachungszwecken empfohlen, dass jeder Dienst über eine eigene Identität verfügt.

Wenn die Ersteller*innen der Software Ihnen nicht sagen können, ob die Anwendung ein MSA verwendet, testen Sie die Anwendung. Erstellen Sie eine Testumgebung, und stellen Sie sicher, dass sie auf die erforderlichen Ressourcen zugreift.

Weitere Informationen finden Sie unter Verwaltete Dienstkonten: Grundlegendes, Implementierung, bewährte Methoden und Problembehandlung.

Bewerten des sMSA-Sicherheitsstatus

Betrachten Sie den sMSA-Zugriffsbereich als Teil des Sicherheitsstatus. Informationen zur Behebung potenzieller Sicherheitsprobleme finden Sie in der folgenden Tabelle:

Sicherheitsproblem Minderung
Das sMSA ist Mitglied von privilegierten Gruppen - Entfernen Sie das sMSA aus Gruppen mit erhöhten Rechten (z. B. Domänenadministrator*innen).
- Verwenden Sie das Modell mit den geringsten Berechtigungen.
- Erteilen Sie dem sMSA nur die Rechte und Berechtigungen, die zum Ausführen der Dienste erforderlich sind.
- Wenn Sie nicht sicher sind, welche Berechtigungen erforderlich sind, wenden Sie sich an die Ersteller*innen der Dienste.
sMSAs verfügen über Lese-/Schreibzugriff auf vertrauliche Ressourcen. - Überwachen Sie den Zugriff auf vertrauliche Ressourcen.
- Archivieren Sie Überwachungsprotokolle zur Analyse in einem SIEM-Programm (Security Information & Event Management) wie Azure Log Analytics oder Microsoft Sentinel.
- Korrigieren Sie Ressourcenberechtigungen, wenn unerwünschte Zugriffe erkannt werden.
Standardmäßig beträgt das Kennwortrolloverintervall von sMSAs 30 Tage. Mit einer Gruppenrichtlinie können Sie die Dauer entsprechend den Sicherheitsanforderungen des Unternehmens optimieren. Um die Kennwortablaufdauer festzulegen, navigieren Sie zu:
Computerkonfiguration>Richtlinien>Windows-Einstellungen>Sicherheitseinstellungen>Sicherheitsoptionen. Verwenden Sie für Domänenmitglieder Maximalalter von Computerkontenkennwörtern.

Herausforderungen bei sMSAs

In der folgenden Tabelle finden Sie Risikominderungen zu bestimmten Herausforderungen.

Herausforderung Minderung
sMSAs gelten auf einem einzelnen Server. Verwenden Sie ein gMSA, wenn Sie das Konto serverübergreifend verwenden.
sMSAs können nicht domänenübergreifend verwendet werden. Verwenden Sie ein gMSA, wenn Sie das Konto domänenübergreifend verwenden.
Nicht alle Anwendungen unterstützen sMSAs. Verwenden Sie nach Möglichkeit ein gMSA. Andernfalls verwenden Sie ein Standardbenutzerkonto oder ein Computerkonto, wie von den Anwendungsersteller*innen empfohlen.

Suchen nach sMSAs

Führen Sie auf jedem Domänencontroller „DSA.msc“ aus, und erweitern Sie dann den Container „Verwaltete Dienstkonten“, um alle sMSAs anzuzeigen.

Führen Sie den folgenden PowerShell-Befehl aus, um alle sMSAs und gMSAs in der Active Directory-Domäne zurückzugeben:

Get-ADServiceAccount -Filter *

Führen Sie den folgenden Befehl aus, um die sMSAs in der Active Directory-Domäne zurückzugeben:

Get-ADServiceAccount -Filter * | where { $_.objectClass -eq "msDS-ManagedServiceAccount" }

Verwalten von sMSAs

Für die Verwaltung Ihrer sMSAs können Sie die folgenden AD-PowerShell-Cmdlets verwenden:

Get-ADServiceAccount Install-ADServiceAccount New-ADServiceAccount Remove-ADServiceAccount Set-ADServiceAccount Test-ADServiceAccount Uninstall-ADServiceAccount

Wechseln zu sMSAs

Wenn ein Anwendungsdienst sMSAs, aber keine gMSAs unterstützt und Sie ein Benutzer- oder ein Computerkonto für den Sicherheitskontext verwenden, finden Sie unter
Verwaltete Dienstkonten: Grundlegendes, Implementierung, bewährte Methoden und Problembehandlung weitere Informationen.

Verschieben Sie nach Möglichkeit Ressourcen zu Azure, und verwenden Sie verwaltete Azure-Identitäten oder Dienstprinzipale.

Nächste Schritte

Weitere Informationen zum Schützen von Dienstkonten finden Sie unter: