Condividi tramite


Panoramica degli account del servizio gestito del gruppo

Importante

Le build di Windows Server Insider sono in ANTEPRIMA. Queste informazioni sono relative alla release non definitiva del prodotto, che potrebbe subire modifiche significative prima della release definitiva. Microsoft non fornisce alcuna garanzia, esplicita o implicita, in relazione alle informazioni contenute in questo documento.

Un nuovo tipo di account noto come account del servizio gestito delegato (dMSA) viene introdotto in Windows Server Insiders Preview che consente la migrazione da un account di servizio tradizionale a un account computer con chiavi gestite e completamente casuali, disabilitando al tempo stesso le password originali dell'account del servizio. L'autenticazione per dMSA è collegata all'identità del dispositivo, il che significa che solo le identità del computer specificate mappate in AD possono accedere all'account. L'uso di dMSA consente di impedire la raccolta delle credenziali usando un account compromesso (kerberoasting), che è un problema comune con gli account di servizio tradizionali.

Confronto tra dMSA e gMSA

Gli account del servizio gestito del servizio gestito e dell'account del servizio gestito sono due tipi di account di servizio gestiti usati per eseguire servizi e applicazioni in Windows Server. Un account dMSA viene gestito da un amministratore e viene usato per eseguire un servizio o un'applicazione in un server specifico. Un gMSA viene gestito da AD e viene usato per eseguire un servizio o un'applicazione in più server. Entrambi offrono una maggiore sicurezza e una gestione semplificata delle password. dMSA è diverso da:

  • Utilizzo dei concetti relativi all'account del servizio gestito del gruppo per limitare l'ambito di utilizzo tramite Credential Guard (CG) per associare l'autenticazione del computer.
  • CG può essere usato per migliorare la sicurezza in dMSA ruotando automaticamente le password e associando tutti i ticket dell'account di servizio. Gli account legacy vengono quindi disabilitati per migliorare ulteriormente la sicurezza.
  • Anche se i gMSA sono protetti da password generate e autorotate del computer, le password non sono ancora associate al computer e possono essere rubate.

Funzionalità di dMSA

dMSA consente agli utenti di crearli come account autonomo o di sostituire un account di servizio standard esistente. Quando un amministratore del servizio gestito sostituisce un account esistente, l'autenticazione a tale account esistente tramite la password verrà bloccata. La richiesta viene reindirizzata all'autorità di sicurezza locale (LSA) per l'autenticazione tramite dMSA, che ha accesso a tutto ciò che l'account precedente può accedere in AD.

Durante la migrazione, dMSA apprende automaticamente i dispositivi in cui usare l'account del servizio, che viene quindi usato per passare da tutti gli account di servizio esistenti.

dMSA usa un segreto casuale (derivato dalle credenziali dell'account computer) che viene mantenuto dal controller di dominio per crittografare i ticket. Il segreto può essere ulteriormente protetto abilitando CG. Anche se i segreti usati da dMSA vengono aggiornati periodicamente in un periodo come un account del servizio gestito del gruppo, la differenza principale è che il segreto di dMSA non può essere recuperato o trovato in qualsiasi punto diverso dal controller di dominio.

Flusso di migrazione per dMSA

Un rapido concetto del processo di flusso di migrazione per un dMSA prevede i passaggi seguenti:

  1. I criteri CG possono essere configurati per proteggere l'identità dei computer.
  2. Un amministratore avvia e completa la migrazione dell'account del servizio.
  3. L'account del servizio aggiorna il server TGT (Ticket Granting Server).
  4. L'account del servizio aggiunge l'identità del computer per consentire i principi.
  5. L'account del servizio originale diventa disabilitato.

Quando si esegue la migrazione di dMSA, tenere presente quanto segue:

  • Non è possibile eseguire la migrazione da un account del servizio gestito o da un gMSA a un dMSA.
  • Attendere almeno due durate dei ticket (equivalenti a 14 giorni) dopo aver modificato il descrittore di sicurezza (SD) prima di completare la migrazione dMSA. È consigliabile mantenere un servizio nello stato di avvio per quattro durate dei ticket (28 giorni). Ritardare la migrazione se i controller di dominio sono partizionati o la replica viene interrotta durante l'onboarding.
  • Prestare attenzione ai siti in cui i ritardi di replica sono più lunghi del tempo di rinnovo del ticket predefinito di 10 ore. L'attributo groupMSAMembership viene controllato e aggiornato a ogni rinnovo del ticket e ogni volta che l'account del servizio originale accede durante lo stato di "avvio della migrazione", che aggiunge l'account del computer al gruppoMSAMembership dell'account del servizio gestito di database.
    • Ad esempio, due siti usano lo stesso account del servizio e ogni ciclo di replica richiede più di 10 ore per durata del ticket. In questo scenario, l'appartenenza a un gruppo viene persa durante i cicli di replica iniziali.
  • La migrazione richiede l'accesso a un controller di dominio di lettura/scrittura (RWDC) per eseguire query e modificare sd.
  • La delega non vincolata smette di funzionare al termine della migrazione se l'account del servizio precedente lo usava. Se si usa un dMSA protetto da CG, la delega senza vincoli smette di funzionare. Per maggiori informazioni, consultare la sezione Considerazioni e problemi noti quando si usa Credential Guard.

Avviso

Se si intende eseguire la migrazione a un dMSA, tutti i computer che usano l'account del servizio devono essere aggiornati per supportare dMSA. In caso contrario, i computer che non supportano dMSA avranno esito negativo con l'account del servizio esistente dopo che l'account diventa disabilitato durante la migrazione.

Attributi dell'account per dMSA

Questa sezione descrive il modo in cui gli attributi per dMSA cambiano nello schema di AD. Questi attributi possono essere visualizzati usando lo snap-in Utenti e computer di Active Directory o l'esecuzione ADSI Edit nel controller di dominio.

Nota

Gli attributi numerici impostati per l'account indicano che:

  • 1 - La migrazione dell'account è iniziata.
  • 2 - La migrazione dell'account è stata completata.

L'esecuzione Start-ADServiceAccountMigration esegue le modifiche seguenti:

  • All'account del servizio viene concessa la lettura generica a tutte le proprietà nell'account del servizio gestito di database
  • All'account del servizio viene concessa la proprietà Write a msDS-groupMSAMembership
  • msDS-DelegatedMSAState viene modificato in 1
  • msDS-ManagedAccountPrecededByLink è impostato sull'account del servizio
  • msDS-SupersededAccountState viene modificato in 1
  • msDS-SupersededManagedServiceAccountLink è impostato su dMSA

L'esecuzione Complete-ADServiceAccountMigration esegue le modifiche seguenti:

  • L'account del servizio viene rimosso dalla lettura generica a tutte le proprietà nell'account del servizio gestito di database
  • L'account del servizio viene rimosso dalla proprietà Write nell'attributo msDS-GroupMSAMembership
  • msDS-DelegatedMSAState è impostato su 2
  • I nomi dell'entità servizio (SPN) vengono copiati dall'account del servizio all'account dMSA
  • msDS-AllowedToDelegateTo viene copiato se applicabile
  • msDS-AllowedToActOnBehalfOfOtherIdentity il descrittore di sicurezza viene copiato su, se applicabile
  • I criteri AuthN assegnati, msDS-AssignedAuthnPolicy, dell'account del servizio vengono copiati
  • dMSA viene aggiunto a tutti i silo dei criteri di autenticazione di cui l'account del servizio è membro
  • Il bit di controllo dell'account utente (UAC) attendibile "Auth for Delegation" viene copiato se è stato impostato nell'account del servizio
  • msDS-SupersededServiceAccountState è impostato su 2
  • L'account del servizio è disabilitato tramite il bit di disabilitazione UAC
  • Il nome SPN viene rimosso dall'account

Vedi anche

Configurazione di account del servizio gestito delegati