Condividi tramite

Gestire gli account del servizio gestito del gruppo

Questo articolo illustra come abilitare e usare gli account del servizio gestito del gruppo in Windows Server.

I protocolli di autenticazione che supportano l'autenticazione reciproca, come Kerberos, non possono essere usati a meno che tutte le istanze dei servizi non usino la stessa entità. Ad esempio, quando un computer client si connette a un servizio che usa il bilanciamento del carico o un altro metodo in base al quale tutti i server sembrano essere lo stesso servizio per il client. Il che vuol dire che ogni servizio deve usare le stesse password o chiavi per dimostrare la propria identità. Gli account del servizio gestito di gruppo sono un tipo di account utilizzabile con più server. Un gMSA è un account di dominio che può essere usato per eseguire servizi in più server senza dover gestire la password. Il gMSA fornisce la gestione automatica delle password e la gestione semplificata del nome dell'entità servizio (service principal name, SPN) tra cui la delega della gestione ad altri amministratori.

Annotazioni

I cluster di failover non supportano gli account del servizio gestiti di gruppo. Tuttavia, i servizi eseguiti sul servizio Cluster possono utilizzare un gMSA o un sMSA se sono un servizio Windows, un pool di app, un'attività pianificata o supportano nativamente gMSA o sMSA.

I servizi possono scegliere l'entità da usare. Ogni tipo di entità supporta servizi diversi e presenta limitazioni diverse.

Dirigenti Servizi supportati Gestione delle password
Account computer del sistema Windows Limitato a un server aggiunto al dominio Gestite dal computer
Account computer senza sistema Windows Qualsiasi server aggiunto al dominio Nessuno
Account virtuale Limitato a un server Gestite dal computer
Account del servizio gestito autonomo di Windows Limitato a un server aggiunto al dominio Gestite dal computer
Account utente Qualsiasi server aggiunto al dominio Nessuno
Account di Servizio Gestito di Gruppo Qualsiasi server Windows Server aggiunto al dominio Gestite dal controller di dominio e recuperate dall'host

Non è possibile condividere tra più sistemi un account computer Windows, un account del servizio gestito autonomo (standalone Managed Service Account, sMSA) Windows o account virtuali. Quando si usano account virtuali, l'identità è anche locale per il computer e non riconosciuta dal dominio. Se si configura un account per i servizi da condividere in server farm, è necessario scegliere un account utente o un account computer diverso da quello del sistema Windows. In entrambi i casi, questi account sono privi della funzionalità di gestione delle password come singolo punto di controllo. Senza la gestione delle password, ogni organizzazione deve aggiornare le chiavi per il servizio in Active Directory (AD) e distribuire queste chiavi a tutte le istanze di tali servizi.

Quando si usano i gMSA, Windows Server evita ai servizi o agli amministratori dei servizi di gestire la sincronizzazione delle password tra istanze dei servizi. Crei l'Account del Servizio Gestito di Gruppo (gMSA) in AD e quindi configuri il servizio che supporta gli account del servizio gestito. L'uso del gMSA è destinato a qualsiasi computer in grado di utilizzare il Lightweight Directory Access Protocol (LDAP) per recuperare le credenziali del gMSA. È possibile creare un gMSA usando i New-ADServiceAccount cmdlet che fanno parte del modulo AD. I seguenti servizi supportano la configurazione dell'identità del servizio nell'host.

  • Le stesse API del sMSA, in modo tale che i prodotti che supportano il sMSA supportino anche il gMSA

  • Servizi che usano Service Control Manager per configurare l'identità di accesso

  • Servizi che usano il gestore di Internet Information Services (IIS) per configurare l'identità nei pool di applicazioni

  • Attività che usano Utilità di pianificazione.

Prerequisiti

Per gestire i gMSAs (Group Managed Service Accounts), il tuo dispositivo deve soddisfare i seguenti requisiti:

Suggerimento

Per controllare quali host o servizi possono usare un gMSA, aggiungere gli account computer a un gruppo di sicurezza designato (nuovo o esistente) e assegnare le autorizzazioni necessarie a questo gruppo. Analogamente, usare un gruppo di sicurezza per gestire l'accesso per i servizi in esecuzione con gMSA, assicurando che il gruppo disponga di tutte le autorizzazioni necessarie per il funzionamento del servizio e l'accesso alle risorse.

Per consentire l'uso dell'autenticazione Kerberos con i servizi che utilizzano account del servizio gestito di gruppo (gMSA), sono necessari i seguenti elementi:

  • Assicurarsi che gli SPN siano registrati correttamente per ogni servizio usando un gMSA. Ciò consente a Kerberos di identificare e autenticare il servizio.

  • Assicurarsi che i record DNS siano configurati correttamente per la risoluzione dei nomi, su cui Kerberos si basa per l'individuazione dei servizi di dominio.

  • Assicurarsi che i firewall e i criteri di rete consentano il traffico Kerberos e le comunicazioni del servizio necessarie.

  • Per le impostazioni di durata dei ticket Kerberos, configurare i criteri di scadenza e rinnovo del ticket in linea con i requisiti di sicurezza e operativi.

  • Tutti i sistemi coinvolti nel processo di autenticazione devono avere orologi sincronizzati. Kerberos è sensibile alla configurazione temporale e le discrepanze possono causare errori di autenticazione.

Se si gestisce Active Directory da un computer che non è un controller di dominio, installare Strumenti di amministrazione remota del server per accedere alle funzionalità di gestione necessarie. RSAT fornisce il modulo AD per PowerShell. Dopo aver installato Strumenti di amministrazione remota del server (RSAT), aprire PowerShell come amministratore ed eseguire Import-Module ActiveDirectory per abilitare i cmdlet di gestione di Active Directory. In questo modo gli amministratori possono gestire Active Directory in modalità remota e sicura, riducendo al minimo il carico sui controller di dominio.

Creare un gMSA

Per creare un gMSA (account del servizio gestito del gruppo) con PowerShell, seguire questi passaggi in una finestra di PowerShell con privilegi elevati:

Importante

I nomi degli account gMSA devono essere univoci all'interno di un livello di foresta e non solo di dominio. Il tentativo di creare un account gMSA con un nome duplicato fallisce, anche in domini diversi.

  1. Creare la chiave radice KDS, se non esiste, seguendo le indicazioni riportate in Creare la chiave radice KDS dei servizi di distribuzione chiavi. Se esiste già una chiave, ignorare questo passaggio.

  2. Per creare un gMSA, eseguire il comando seguente. Sostituire <gMSAName> con il nome gMSA desiderato e <domain> con il nome del dominio. Sostituire <SecurityGroup> con il nome del gruppo di sicurezza o degli account computer che devono avere accesso per recuperare la password del gMSA.

    New-ADServiceAccount -Name <gMSAName> -DNSHostName <gMSAName>.<domain> -PrincipalsAllowedToRetrieveManagedPassword <SecurityGroup>

    Per creare un gMSA esclusivamente per l'autenticazione in uscita, eseguire il comando seguente. Sostituire <Days> con un valore numerico. Se non viene specificato un valore, per impostazione predefinita viene impostato su 30 giorni.

    New-ADServiceAccount -Name <gMSAName> -DNSHostName <gMSAName>.<domain> -RestrictToOutboundAuthenticationOnly -ManagedPasswordIntervalInDays <Days> -PrincipalsAllowedToRetrieveManagedPassword <SecurityGroup>

    Importante

    È possibile impostare l'intervallo di modifica della password solo in fase di creazione. Per modificare l'intervallo, è necessario creare un nuovo account del servizio gestito del gruppo e impostarlo al momento della creazione.

  3. Su ogni computer che utilizza il gMSA, eseguire il comando seguente per installare il gMSA sul dispositivo di destinazione. Sostituire <gMSAName> con il nome del gMSA, l'account del servizio gestito del gruppo che hai creato.

    Install-ADServiceAccount -Identity <gMSAName>

  4. Eseguire il comando seguente per verificare che l'installazione del gMSA sia stata eseguita sul dispositivo di destinazione.

    Test-ADServiceAccount -Identity <gMSAName>

Per completare questa procedura, è necessaria l'appartenenza al gruppo di sicurezza appropriato o disporre delle autorizzazioni delegate necessarie per creare msDS-GroupManagedServiceAccount oggetti. Anche se i membri degli Operatori Account possono gestire determinati oggetti utente e gruppo in Active Directory, non dispongono dei diritti predefiniti per la creazione di gMSAs (account del servizio gestito di gruppo), a meno che tali autorizzazioni non vengano delegate. Per informazioni dettagliate sull'uso degli account e delle appartenenze ai gruppi appropriati, vedere Gruppi di sicurezza di Active Directory.

È anche possibile aggiornare le proprietà del gMSA usando il cmdlet Set-ADServiceAccount. Ad esempio, per aggiornare il nome visualizzato dei computer, eseguire il comando seguente sostituendo <gMSAName> e <NewDisplayName> con i valori:

Set-ADServiceAccount -Identity "<gMSAName>" -DisplayName "<NewDisplayName>"

Per informazioni dettagliate su come impostare altre proprietà per l'account del servizio gestito di gruppo (gMSA), vedere Set-ADServiceAccount.

Verificare le modifiche apportate a un account gMSA

Dopo aver apportato modifiche a un gMSA, è possibile verificare se l'aggiornamento è stato effettuato correttamente. Queste modifiche includono l'aggiunta, la rimozione e la disinstallazione di un gMSA. È anche possibile eseguire questo passaggio in qualsiasi momento in cui vengono eseguiti aggiornamenti alle proprietà del gMSA.

Eseguire il comando seguente sostituendo <gMSAName> con il nome del gMSA che hai creato.

Get-ADServiceAccount -Identity "<gMSAName>" | Select-Object *

Aggiungere host membro a un gruppo di sicurezza

Annotazioni

  • Gestione incentrata sui gruppi (Add-ADGroupMember / Remove-ADGroupMember): usare questi cmdlet quando si vuole gestire l'appartenenza a un gruppo specifico. Sono più adatti per aggiungere o rimuovere più utenti, computer o altri oggetti da o verso un singolo gruppo in modo efficiente.

  • Gestione incentrata sugli utenti (Add-ADPrincipalGroupMembership / Remove-ADPrincipalGroupMembership): scegliere questi cmdlet quando l'obiettivo è di gestire in più gruppi l'appartenenza di un utente o di un computer specifico. Consentono di aggiungere o rimuovere un'entità da diversi gruppi in un'unica operazione, semplificando l'aggiornamento delle affiliazioni di gruppo per i singoli account.

Se si utilizzano gruppi di sicurezza per gestire i membri host, aggiungere l'account per computer del nuovo host membro al gruppo di sicurezza che include gli host membri del gMSA. A questo scopo, è possibile usando uno dei metodi seguenti:

Per utilizzare lo snap-in Utenti e Computer di Active Directory (ADUC), vedi Aggiungere un account computer a un gruppo e Gestire gli account utente in Utenti e Computer di Active Directory.

Se si usano account computer, trovare gli account esistenti e aggiungere il nuovo account computer.

Rimuovere gli host membro da un gruppo di sicurezza

Per usare lo snap-in ADUC, vedere Eliminare un account computer e Rimuovere un account utente.

Disinstallare un gMSA dal sistema

Anche se non è possibile disinstallare i gMSA in ADUC, è possibile eliminare manualmente un gMSA individuandolo nel contenitore Account del Servizio Gestito ed eliminandolo come qualsiasi altro oggetto AD. Tenere tuttavia presente che questa operazione non esegue le stesse operazioni di pulizia che Uninstall-ADServiceAccount verrebbero eseguite in PowerShell.

Per disinstallare un gMSA (Group Managed Service Account), aprire una finestra di PowerShell con privilegi elevati e seguire questa procedura.

  1. Per rimuovere un singolo gMSA dall'ambiente, eseguire il comando seguente sostituendo <gMSAName> con il proprio valore:

    Uninstall-ADServiceAccount -Identity <gMSAName>

  2. Per rimuovere più gMSA dal tuo ambiente, esegui il comando seguente sostituendo <gMSA#$> con i tuoi valori:

    $gMSANames = @("gMSA1$", "gMSA2$", "gMSA3$")

foreach ($gMSAs in $gMSANames) {
  Uninstall-ADServiceAccount -Identity $gMSAs
}

Per altre informazioni sul Uninstall-ADServiceAccount cmdlet, vedere Uninstall-ADServiceAccount.

Vedere anche