Beheerde serviceaccounts voor beveiligde groepen

Door groepen beheerde serviceaccounts (gMSA's) zijn domeinaccounts om services te beveiligen. gMSA's kunnen worden uitgevoerd op één server of in een serverfarm, zoals systemen achter een netwerktaakverdeling of IIS-server (Internet Information Services). Nadat u uw services hebt geconfigureerd voor het gebruik van een gMSA-principal, wordt accountwachtwoordbeheer afgehandeld door het Windows-besturingssysteem (OS).

Voordelen van gMSA's

gMSA's zijn een identiteitsoplossing met meer beveiliging waarmee administratieve overhead wordt verminderd:

  • Stel sterke wachtwoorden in - 240 byte, willekeurig gegenereerde wachtwoorden: de complexiteit en lengte van gMSA-wachtwoorden minimaliseert de kans op inbreuk door beveiligingsaanvallen of woordenlijstaanvallen
  • Cyclus wachtwoorden regelmatig : wachtwoordbeheer gaat naar het Windows-besturingssysteem, waardoor het wachtwoord elke 30 dagen wordt gewijzigd. Service- en domeinbeheerders hoeven geen wachtwoordwijzigingen te plannen of servicestoringen te beheren.
  • Ondersteuning voor implementatie naar serverfarms - gMSA's implementeren op meerdere servers ter ondersteuning van oplossingen met gelijke taakverdeling waarbij meerdere hosts dezelfde service uitvoeren
  • Ondersteuning voor vereenvoudigd SPN-beheer (Service Principal Name): stel een SPN in met PowerShell wanneer u een account maakt.
    • Daarnaast kunnen services die automatische SPN-registraties ondersteunen, dit doen op basis van de gMSA, als de gMSA-machtigingen juist zijn ingesteld.

GMSA's gebruiken

Gebruik gMSA's als het accounttype voor on-premises services, tenzij een service, zoals failoverclustering, dit niet ondersteunt.

Belangrijk

Test uw service met gMSA's voordat deze naar productie gaat. Stel een testomgeving in om ervoor te zorgen dat de toepassing gebruikmaakt van de gMSA en vervolgens toegang krijgt tot resources. Raadpleeg Ondersteuning voor door groepen beheerde serviceaccounts voor meer informatie.

Als een service geen ondersteuning biedt voor gMSA's, kunt u een zelfstandig beheerd serviceaccount (sMSA) gebruiken. Een sMSA heeft dezelfde functionaliteit, maar is bedoeld voor implementatie op één server.

Als u geen gMSA of sMSA kunt gebruiken die door uw service wordt ondersteund, configureert u de service zodanig dat deze wordt uitgevoerd als een standaardgebruikersaccount. Service- en domeinbeheerders moeten sterke processen voor wachtwoordbeheer observeren om het account veilig te houden.

GMSA-beveiligingspostuur beoordelen

gMSA's zijn veiliger dan standaardgebruikersaccounts, waarvoor doorlopend wachtwoordbeheer is vereist. Overweeg echter gMSA-toegangsbereik in relatie tot de beveiligingspostuur. Mogelijke beveiligingsproblemen en oplossingen voor het gebruik van gMSA's worden weergegeven in de volgende tabel:

Beveiligingsprobleem Correctie
gMSA is lid van bevoorrechte groepen - Controleer uw groepslidmaatschappen. Maak een PowerShell-script om groepslidmaatschappen op te sommen. Filter het resulterende CSV-bestand op gMSA-bestandsnamen
- Verwijder de gMSA uit bevoorrechte groepen
- Verken de gMSA-rechten en machtigingen die nodig zijn om de service uit te voeren. Zie de leverancier van uw service.
gMSA heeft lees-/schrijftoegang tot gevoelige resources - Toegang tot gevoelige resources
controleren - Auditlogboeken archiveren naar een SIEM, zoals Azure Log Analytics of Microsoft Sentinel
- Overbodige resourcemachtigingen verwijderen als er een onnodig toegangsniveau is

GMSA's zoeken

Uw organisatie heeft mogelijk gMSA's. Voer de volgende PowerShell-cmdlets uit om deze accounts op te halen:

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

Container beheerde serviceaccounts

Om effectief te kunnen werken, moeten gMSA's zich in de container Managed Service Accounts bevinden.

Screenshot of a gMSA in the Managed Service Accounts container.

Voer de volgende opdrachten uit om service-MSA's te vinden die niet in de lijst voorkomt:


Get-ADServiceAccount -Filter *

# This PowerShell cmdlet returns managed service accounts (gMSAs and sMSAs). Differentiate by examining the ObjectClass attribute on returned accounts.

# For gMSA accounts, ObjectClass = msDS-GroupManagedServiceAccount

# For sMSA accounts, ObjectClass = msDS-ManagedServiceAccount

# To filter results to only gMSAs:

Get-ADServiceAccount –Filter * | where-object {$_.ObjectClass -eq "msDS-GroupManagedServiceAccount"}

GMSA's beheren

Gebruik de volgende Active Directory PowerShell-cmdlets om gMSA's te beheren:

Get-ADServiceAccount

Install-ADServiceAccount

New-ADServiceAccount

Remove-ADServiceAccount

Set-ADServiceAccount

Test-ADServiceAccount

Uninstall-ADServiceAccount

Notitie

In Windows Server 2012 en latere versies werken de *-ADServiceAccount-cmdlets met gMSA's. Meer informatie: Aan de slag met door groepen beheerde serviceaccounts.

Verplaatsen naar een gMSA

gMSA's zijn een beveiligd serviceaccounttype voor on-premises. Het is raadzaam om gMSA's te gebruiken, indien mogelijk. Overweeg bovendien om uw services naar Azure en uw serviceaccounts te verplaatsen naar Microsoft Entra-id.

Notitie

Zie Aan de slag met door groepen beheerde serviceaccounts voordat u uw service configureert voor het gebruik van de gMSA.

Ga als volgende te werk om naar een gMSA te gaan:

  1. Zorg ervoor dat de KDS-hoofdsleutel (Key Distribution Service) is geïmplementeerd in het forest. Dit is een eenmalige bewerking. Zie de KDS-hoofdsleutel voor sleuteldistributieservices maken.
  2. Een nieuw gMSA maken. Zie Aan de slag met door groepen beheerde serviceaccounts.
  3. Installeer de nieuwe gMSA op hosts waarop de service wordt uitgevoerd.
  4. Wijzig uw service-identiteit in gMSA.
  5. Geef een leeg wachtwoord op.
  6. Controleer of uw service werkt onder de nieuwe gMSA-identiteit.
  7. Verwijder de oude serviceaccount-id.

Volgende stappen

Zie de volgende artikelen voor meer informatie over serviceaccounts: