Schützen benutzerbasierter Dienstkonten in Active Directory

Artikel
10/25/2023

Lokale Benutzerkonten waren der traditionelle Ansatz, um Dienste zu sichern, die unter Windows ausgeführt werden. Verwenden Sie diese Konten heute, wenn von Gruppen verwaltete Dienstkonten (group Managed Service Accounts, gMSAs) oder eigenständigen verwalteten Dienstkonten (standalone Managed Service Accounts, sMSAs) von Ihrem Dienst nicht unterstützt werden. Weiter Informationen über den zu verwendenden Kontotyp finden Sie unter Sichern lokaler Dienstkonten.

Sie können die Verschiebung Ihres Diensts in ein Azure-Dienstkonto überprüfen, z. B. in eine verwaltete Identität oder einen Dienstprinzipal.

Weitere Informationen:

Sie können lokale Benutzerkonten erstellen, um Sicherheit für Dienste und Berechtigungen bereitzustellen, welche die Konten für den Zugriff auf lokale und Netzwerkressourcen benötigen. Lokale Benutzerkonten erfordern wie andere AD-Benutzerkonten (Active Directory) eine manuelle Kennwortverwaltung. Zum Sichern von Konten müssen Dienst- und Domänenadministratoren starke Kennwortverwaltungsprozesse einhalten.

Wenn Sie ein Benutzerkonto als Dienstkonto erstellen, verwenden Sie es nur für einen Dienst. Verwenden Sie eine Namenskonvention, aus der hervorgeht, dass es sich um ein Dienstkonto handelt und mit welchem Dienst es verbunden ist.

Vorteile und Einschränkungen

Lokale Benutzerkonten sind ein vielseitiger Kontotyp. Benutzerkonten, die als Dienstkonten verwendet werden, werden über Richtlinien für Benutzerkonten gesteuert. Verwenden Sie diese, wenn Sie kein MSA verwenden können. Überprüfen Sie, ob ein Computerkonto nicht die bessere Option ist.

Die Herausforderungen lokaler Benutzerkonten sind in der folgenden Tabelle zusammengefasst:

Herausforderung	Minderung
Die Kennwortverwaltung erfolgt manuell, was die Sicherheit schwächt und Downtimes des Diensts zur Folge hat	– Sicherstellen der regelmäßigen Komplexität von Kennwörtern und sicherstellen, dass Änderungen durch einen Prozess gesteuert werden, der sichere Kennwörter beibehält – Koordinieren von Kennwortänderungen mit einem Dienstkennwort, was dazu beiträgt, dass die Downtime des Diensts reduziert wird
Die Identifizierung von lokalen Benutzerkonten, die Dienstkonten sind, kann schwierig sein	– Dokumentieren von in Ihrer Umgebung bereitgestellten Dienstkonten – Nachverfolgen des Kontonamens und der Ressourcen, auf die sie zugreifen können – Erwägen des Hinzufügens des Präfixes „svc“ zu Benutzerkonten, die als Dienstkonten verwendet werden

Suchen von als Dienstkonten verwendeten lokalen Benutzerkonten

Lokale Benutzerkonten sind wie andere AD-Benutzerkonten. Es kann schwierig sein, die Konten zu finden, da sie durch kein Benutzerkontoattribut als Dienstkonto identifiziert werden. Es wird empfohlen, eine Namenskonvention für Benutzerkonten zu erstellen, die als Dienstkonten verwendet werden. Fügen Sie beispielsweise einem Dienstnamen das Präfix „svc“ hinzu: svc-HRDataConnector.

Verwenden Sie einige der folgenden Kriterien bei der Suche nach Dienstkonten. Es ist jedoch möglich, dass dieser Ansatz keine Konten findet:

Gilt für die Delegierung
Mit Dienstprinzipalnamen
Mit Kennwörtern, die nie ablaufen

Um die für die Dienste verwendeten lokalen Benutzerkonten zu finden, führen Sie die folgenden PowerShell-Befehle aus:

Um Konten mit Vertrauensstellung für die Delegierung zu finden:


Get-ADObject -Filter {(msDS-AllowedToDelegateTo -like '*') -or (UserAccountControl -band 0x0080000) -or (UserAccountControl -band 0x1000000)} -prop samAccountName,msDS-AllowedToDelegateTo,servicePrincipalName,userAccountControl | select DistinguishedName,ObjectClass,samAccountName,servicePrincipalName, @{name='DelegationStatus';expression={if($_.UserAccountControl -band 0x80000){'AllServices'}else{'SpecificServices'}}}, @{name='AllowedProtocols';expression={if($_.UserAccountControl -band 0x1000000){'Any'}else{'Kerberos'}}}, @{name='DestinationServices';expression={$_.'msDS-AllowedToDelegateTo'}}

Um Konten mit Dienstprinzipalnamen zu finden:


Get-ADUser -Filter * -Properties servicePrincipalName | where {$_.servicePrincipalName -ne $null}

Um Konten mit nie ablaufenden Kennwörtern zu finden:


Get-ADUser -Filter * -Properties PasswordNeverExpires | where {$_.PasswordNeverExpires -eq $true}

Sie können den Zugriff auf vertrauliche Ressourcen überwachen und Überwachungsprotokolle in einem SIEM-System (Security Information & Event Management) archivieren. Mit Azure Log Analytics oder Microsoft Sentinel können Sie nach Dienstkonten suchen und sie analysieren.

Bewerten der Sicherheit des lokalen Benutzerkontos

Verwenden Sie die folgenden Kriterien, um die Sicherheit lokaler Benutzerkonten zu bewerten, die als Dienstkonten verwendet werden:

Kennwortverwaltungsrichtlinie
Konten mit Mitgliedschaft in privilegierten Gruppen
Lese-/Schreibberechtigungen für wichtige Ressourcen

Beheben potenzieller Sicherheitsprobleme

In der folgenden Tabelle finden Sie Informationen zu potenziellen Sicherheitsproblemen für lokale Benutzerkonten und mögliche Abhilfemaßnahmen:

Sicherheitsproblem	Minderung
Kennwortverwaltung	– Sicherstellen, dass die Komplexität von Kennwörtern und Kennwortänderungen durch regelmäßige Updates und strenge Kennwortanforderungen gesteuert sind – Koordinieren von Kennwortänderungen mit einem Kennwortupdate, um die Ausfallzeit des Diensts zu minimieren
Das Konto ist Mitglied von privilegierten Gruppen	– Überprüfen der Gruppenmitgliedschaft – Entfernen des Kontos aus privilegierten Gruppen – Erteilen von Rechten und Berechtigungen für das Konto zum Ausführen des Diensts (wenden Sie sich an den Dienstanbieter) – Beispiel: die lokale oder die interaktive Anmeldung verweigern
Das Konto verfügt über Lese-/Schreibberechtigungen für vertrauliche Ressourcen	– Überwachen des Zugriffs auf vertrauliche Ressourcen – Archivieren von Überwachungsprotokollen in einem SIEM: Azure Log Analytics oder Microsoft Sentinel – Beheben von Ressourcenberechtigungen, wenn Sie unerwünschte Zugriffsebenen erkennen

Sichere Kontotypen

Microsoft rät von der Verwendung lokaler Benutzerkonten als Dienstkonten ab. Bei Diensten, die diesen Kontotyp verwenden, ist zu prüfen, ob sie für die Verwendung eines gMSA oder eines sMSA konfiguriert werden können. Prüfen Sie außerdem, ob Sie den Dienst zu Azure verschieben können, um die Verwendung sichererer Kontotypen zu ermöglichen.

Nächste Schritte

Weitere Informationen zum Schützen von Dienstkonten: