• Guide, Sicurezza, Sistemi Operativi
• 17 Ottobre 2025

Microsoft continua a evolvere la gestione delle identità di servizio in ambienti Windows Server introducendo, con Windows Server 2025, una nuova tipologia di account gestito: i Delegated Managed Service Accounts (dMSA).

Questa novità rappresenta un passo importante verso un modello di sicurezza moderno e allineato ai principi di Zero Trust e Credential Guard, offrendo un meccanismo più sicuro, flessibile e decentralizzato per l’esecuzione dei servizi di sistema.

In questa guida vedremo cosa sono i dMSA, come si differenziano dai tradizionali Managed Service Accounts (sMSA) e Group Managed Service Accounts (gMSA) e come configurarli in un ambiente Windows Server 2025.

Introduzione

Gli account di servizio sono utilizzati da applicazioni, servizi di sistema e componenti infrastrutturali per autenticarsi su risorse di rete o controller di dominio.

Fino a oggi si è fatto affidamento su:

• Account utente di dominio tradizionali, con password statiche e gestione manuale.
• Managed Service Accounts (sMSA) introdotti in Windows Server 2008 R2, per automatizzare la gestione delle credenziali su un singolo host.
• Group Managed Service Accounts (gMSA) in Windows Server 2012, estesi per più server e applicazioni distribuite. Ne abbiamo parlato abbondantemente in questa guida Active Directory Managed Service Accounts – sMSA, gMSA e dMSA – ICT Power che vi invito a leggere.

Con Windows Server 2025 arriva una nuova generazione: i Delegated Managed Service Accounts, progettati per semplificare la gestione delle credenziali in scenari moderni, ridurre la dipendenza dai privilegi di dominio e migliorare la sicurezza complessiva.

Cos’è un Delegated Managed Service Account (dMSA)

Un Delegated Managed Service Account è un account di servizio che combina i vantaggi dei Managed Service Accounts tradizionali con un nuovo modello di delega e isolamento a livello di dispositivo.

Le caratteristiche principali sono:

• Creato in Active Directory, ma con autenticazione vincolata al dispositivo che lo usa.
• Le credenziali vengono derivate dal computer account e gestite automaticamente dal controller di dominio (non salvate in chiaro o replicate).
• Credential Guard e Virtualization-Based Security (VBS) proteggono il segreto dell’account.
• L’uso è consentito solo ai computer presenti nell’attributo PrincipalsAllowedToRetrieveManagedPassword.
• Può essere creato e gestito anche da account non Domain Admin, grazie a un modello di delega più granulare.
• Ideale per applicazioni e servizi locali che richiedono elevata sicurezza ma non necessitano di accesso multi-server.
• Ideale per ambienti isolati o con connettività intermittente ai domain controller.
• Ideale per server collocati in zone a bassa fiducia o segmentate (es. DMZ).
• Ideale per architetture zero trust o hybrid-cloud, dove si vuole limitare l’esposizione delle credenziali.

Figura 1: Principio di funzionamento dei Delegated Managed Service Account

Differenze tra sMSA, gMSA e dMSA

Per comprendere il valore dei dMSA, è utile confrontarli con le due tipologie precedenti.

I dMSA non sostituiscono i gMSA ma li affiancano: i primi sono ottimali per carichi di lavoro su singolo server, i secondi per applicazioni distribuite.

NOTA: È importante sapere che non è possibile migrare da un gMSA o MSA a un dMSA: la migrazione è ammessa solo da account di servizio standard (legacy) verso dMSA.

Architettura e funzionamento

Un dMSA sfrutta un meccanismo di autenticazione basato su identità del dispositivo (Device Identity Binding).

Quando viene creato, il sistema genera una chiave crittografica univoca, custodita nel Trusted Platform Module (TPM) o protetta da Virtualization-Based Security (VBS) tramite Credential Guard. Vi invito ad approfondire questo argomento leggendo la mia guida Credential Guard, Virtualization-based security (VBS) e Windows Defender Application Control (WDAC) – ICT Power

Durante il logon o l’avvio del servizio:

• Il sistema genera un segreto univoco basato sulle credenziali del computer;
• Il controller di dominio protegge il segreto e crittografa i ticket Kerberos con esso;
• L’host autorizzato recupera la password in modo sicuro e la usa per autenticarsi.

Il binding garantisce che:

• Il segreto non possa essere esportato o utilizzato da altri host;
• I ticket vengano rilasciati solo per i computer autorizzati;
• Le credenziali restino protette anche se il server è compromesso.

Prerequisiti

Prima di procedere con la creazione o migrazione a dMSA, verificate che:

1. Tutti i dispositivi coinvolti (es. server che eseguiranno il servizio) supportino dMSA (al momento, solo Windows Server 2025 o Windows 11 24H2).
2. Esista almeno un controller di dominio Windows Server 2025 in modalità scrittura (RW DC) che possa aggiornare e replicare i metadati necessari.
3. Sia presente una KDS root key (usata per generare i segreti): è necessario verificarla con Get-KdsRootKey e, se mancante, crearla con Add-KdsRootKey con un tempo efficace retroattivo.
4. I computer client o server devono avere il flag di registro per abilitare il supporto al dMSA: si può utilizzare una GPO, anche locale, che abiliti Computer Configuration\Administrative Templates\System\Kerberos\Enable Delegated Managed Service Account logons.
5. Il servizio o account legacy che volete migrare non abbia vincoli che ne impediscano la sostituzione (es. permessi speciali o deleghe non compatibili).
6. Garantita la replica AD, affinché i cambiamenti relativi a membership e attributi si propaghino correttamente, soprattutto se ci sono siti con latenza.

Creazione di un Delegated Managed Service Account “standalone”

Vediamo ora la procedura passo-passo per creare e utilizzare un dMSA in Windows Server 2025.

1. Creazione dell’account
   

Aprite una finestra di PowerShell con privilegi elevati ed eseguite l’installazione degli strumenti di amministrazione remota (RSAT) per Active Directory, se non sono presenti, con il comando seguente:

Se è la prima volta che utilizzate un Managed Service Account, è possibile che nel dominio non esista ancora una KDS root key (Key Distribution Service). I controller di dominio hanno bisogno di questa chiave radice per poter generare le password dei Managed Service Account. Per verificarne la presenza, utilizzate il comando:

Se il comando non restituisce alcun risultato, dovrete crearne una nuova con:

Tenete presente che una nuova KDS root key impiega fino a 10 ore per diventare attiva, tempo necessario per consentirne la replica in ambienti di grandi dimensioni. Se invece state operando in un laboratorio di test e desiderate che la chiave diventi subito operativa, potete anticiparne l’efficacia con questo comando:

Una volta verificata o creata la chiave, potete procedere con la creazione di un Delegated Managed Service Account (dMSA) eseguendo:

Questo comando genera un nuovo account di servizio gestito delegato, associandolo al nome host indicato e configurandolo per l’utilizzo della crittografia Kerberos AES256, oggi considerata la più sicura e consigliata.

2. Verifica dello stato dell’account
   

Per visualizzare i dettagli e lo stato operativo dell’account appena creato:

Il risultato mostrerà informazioni sul binding al dispositivo, la data di creazione e la scadenza della password.

Figura 2: Creazione del Delegated Managed Service Account completata

Come si può vedere dalla figura sopra, l’account non può essere utilizzato fino a quando non concedete alla macchina il permesso di recuperare la password gestita da dMSA:

3. Assegnazione dell’account a un servizio
   

Una volta creato il dMSA, è possibile associarlo a un servizio Windows come IIS, SQL Server o un’applicazione personalizzata:

Il sistema riconoscerà automaticamente l’account come gestito e si occuperà di utilizzare le credenziali sicure memorizzate nel local store.

Migrazione da account legacy a dMSA

Uno degli scenari più comuni di adozione dei Delegated Managed Service Accounts (dMSA) riguarda la sostituzione di vecchi account di servizio tradizionali, spesso caratterizzati da password statiche e gestione manuale.

Questi account, utilizzati per eseguire servizi o applicazioni di sistema, rappresentano da sempre un punto debole in termini di sicurezza: le credenziali rimangono memorizzate localmente, non vengono ruotate in modo automatico e possono essere esposte in caso di compromissione del server.

Con l’introduzione dei dMSA in Windows Server 2025, è ora possibile migrare questi account a un modello più sicuro e moderno, in cui la gestione delle credenziali è automatizzata e protetta da Credential Guard, eliminando del tutto la necessità di aggiornamenti manuali delle password.

Nel nostro esempio pratico, effettueremo la migrazione dell’account di dominio legacy [email protected], attualmente configurato per eseguire il servizio SNMP Trap, verso un Delegated Managed Service Account (dMSA).

In questo modo, il servizio continuerà a funzionare con le stesse autorizzazioni, ma sfrutterà un meccanismo di autenticazione più robusto, basato su device binding e segreti crittografati gestiti automaticamente dal sistema.

Come potete vedere nella figura sotto, il servizio SNMP Trap utilizza al momento l’account [email protected] per eseguire il processo. L’obiettivo della migrazione è sostituire questo account con un nuovo dMSA denominato, ad esempio, [email protected], mantenendo inalterata la configurazione del servizio e garantendo la continuità operativa.

Figura 3: Il servizio SNMP Trap in esecuzione con l’account legacy [email protected]

Una volta verificato che il nuovo Delegated Managed Service Account (dMSA) sia stato creato correttamente in Active Directory, possiamo procedere con la migrazione dell’account legacy utilizzato dal servizio.

L’operazione di migrazione viene eseguita tramite il cmdlet Start-ADServiceAccountMigration, che collega l’account di servizio esistente al nuovo dMSA, mantenendo intatte le autorizzazioni e aggiornando la gestione delle credenziali.

Aprite quindi una console PowerShell con privilegi elevati e lanciate il comando seguente:

Con questo comando, Active Directory avvia il processo di transizione dell’account svcSNMP verso il nuovo dMSA-NSP1, conservando la relazione con il servizio associato e abilitando la gestione automatica della password.

Figura 4: Avvio della migrazione dell’account legacy svcSNMP verso il nuovo dMSA dMSA-NSP1

Potete esplorare gli attributi del dMSA utilizzando lo strumento ldp.exe. Dal menu di navigazione, espandete il contenitore Managed Service Accounts e selezionate il dMSA che avete appena creato.

Nel riquadro di destra noterete che il valore dell’attributo msDS-DelegatedMSAState è ora impostato su 1, a indicare che la migrazione dell’account è stata avviata correttamente.

Inoltre, l’attributo msDS-ManagedAccountPrecededByLink punta all’account di servizio originale, confermando che la relazione tra l’account legacy (svcSNMP) e il nuovo Delegated Managed Service Account è stata stabilita.

Figura 5: Attributi LDAP del dMSA aggiornati: lo stato di migrazione (msDS-DelegatedMSAState = 1) e il collegamento all’account di origine (msDS-ManagedAccountPrecededByLink)

Prima di completare la migrazione e consentire al server di utilizzare correttamente il nuovo Delegated Managed Service Account (dMSA), è importante verificare che sia attiva la relativa impostazione di criteri di gruppo (GPO) necessaria per abilitare l’autenticazione dei dMSA.

Potete utilizzare una GPO per abilitare la funzionalità, configurando Computer Configuration\Administrative Templates\System\Kerberos\Enable Delegated Managed Service Account logons. Questa impostazione consente al client Kerberos del sistema di riconoscere e supportare i logon dei Delegated Managed Service Accounts, garantendo che i servizi configurati con un dMSA possano autenticarsi correttamente presso il controller di dominio.

Se il criterio non è abilitato, le autenticazioni basate su dMSA non saranno permesse.

Figura 6: Abilitazione del criterio “Enable Delegated Managed Service Account logons” nelle impostazioni Kerberos

A questo punto è necessario riavviare il servizio di destinazione, in modo che l’attributo PrincipalsAllowedToRetrieveManagedPassword possa acquisire automaticamente l’identità della macchina su cui il servizio è in esecuzione.

Durante il riavvio, Windows Server utilizza il nuovo Delegated Managed Service Account (dMSA) per eseguire il servizio e stabilire il binding con l’identità del server.

Figura 7: Riavvio del servizio SNMP Trap per aggiornare le informazioni sull’identità del dispositivo

Dopo l’avvio, l’account macchina del server viene aggiunto automaticamente all’attributo PrincipalsAllowedToRetrieveManagedPassword dell’oggetto dMSA in Active Directory, consentendogli di recuperare la password gestita in modo sicuro.

Questo passaggio è fondamentale: solo il computer presente in tale attributo può ottenere le credenziali del dMSA, garantendo così che l’account non venga mai utilizzato da sistemi non autorizzati.

Per verificare che la migrazione e il binding del dMSA al server siano avvenuti correttamente, potete utilizzare la cmdlet Get-ADServiceAccount in PowerShell.

Nel risultato visualizzerete alcune informazioni chiave:

• L’attributo msDS-DelegatedMSAState con valore 1 conferma che la migrazione dell’account è in corso o attiva.
• L’attributo PrincipalsAllowedToRetrieveManagedPassword elenca ora il nome del computer al quale è permesso accedere al dMSA (in questo esempio, CN=NSP1,CN=Computers,DC=demo,DC=lab).

Figura 8: Verifica del binding del dMSA con il server tramite gli attributi di Active Directory

Se durante la migrazione avete commesso un errore e, ad esempio, avete indicato un nome di account errato o un oggetto di servizio non corretto, potete annullare la migrazione utilizzando il comando seguente:

Questa cmdlet interrompe il collegamento tra il nuovo Delegated Managed Service Account (dMSA) e l’account di servizio legacy, riportando la configurazione allo stato precedente.

Se invece desiderate ripristinare l’account di servizio in uno stato non collegato, ovvero rimuovere completamente la relazione tra i due account mantenendo però il dMSA creato, potete eseguire:

NOTA: è consigliabile attendere il periodo consigliato (≥ 14 giorni, fino a 28 giorni) per garantire propagazione e rinnovi di ticket prima di completare o annullare definitivamente la migrazione.

 

Completamento della migrazione

Per completare la migrazione dell’account di servizio, eseguite il comando seguente in PowerShell:

Questo comando conclude il processo di transizione, aggiornando gli attributi del Delegated Managed Service Account e disabilitando automaticamente l’account di servizio tradizionale (svcSNMP) in Active Directory.

Dopo il completamento, potete verificare lo stato della migrazione con:

Il valore dell’attributo msDS-DelegatedMSAState passerà a 2, come mostrato nella figura sotto, indicando che la migrazione è terminata con successo e che il dMSA è pienamente operativo.

Figura 9: Completamento della migrazione del servizio SNMP verso il dMSA e stato aggiornato a msDS-DelegatedMSAState = 2

Da questo momento in poi, il servizio continuerà a funzionare senza interruzioni, ma utilizzando l’account dMSA-NSP1. Non è necessario modificare la configurazione del servizio: la sostituzione dell’account e la gestione delle credenziali avvengono in modo completamente trasparente, garantendo continuità operativa e maggiore sicurezza.

A questo punto potete riavviare il servizio per completare la transizione e verificare che tutto funzioni correttamente.

Figura 10: Riavvio del servizio SNMP Trap dopo il completamento della migrazione

Dopo il riavvio, il servizio continuerà a funzionare regolarmente e a comunicare con le stesse autorizzazioni, ma in background l’autenticazione verrà gestita tramite il nuovo Delegated Managed Service Account (dMSA).

Nel pannello “Log On As” potrete ancora vedere il nome dell’account legacy ([email protected]), ma in realtà le credenziali sono ormai controllate e fornite automaticamente dal dMSA, che ha assunto il ruolo operativo.

Questo comportamento è previsto: l’interfaccia di gestione dei servizi mostra ancora il riferimento all’account precedente, ma il servizio utilizza internamente la password gestita dal nuovo dMSA.

 

Che fine ha fatto l’account “legacy”?

Una volta completata la migrazione e verificato il corretto funzionamento del servizio, possiamo osservare che l’account di servizio originale è stato automaticamente disabilitato.

Anche questo comportamento è previsto: durante la fase finale della migrazione, Active Directory disattiva l’account legacy per impedirne un utilizzo non autorizzato, mantenendo al contempo tutti gli attributi e le informazioni per eventuali controlli o rollback futuri.

Nell’immagine seguente potete vedere, sia da Active Directory Users and Computers che da PowerShell, che l’account svcSNMP risulta disabilitato (Enabled : False), mentre il servizio continua a funzionare regolarmente utilizzando il nuovo Delegated Managed Service Account (dMSA).

Figura 11: L’account legacy svcSNMP viene automaticamente disabilitato al termine della migrazione, ma resta disponibile in Active Directory come riferimento di sicurezza

Attenzione a possibili rischi e vulnerabilità

Nel 2025 è stata scoperta una vulnerabilità denominata BadSuccessor, documentata da Akamai Security Research, che sfrutta il processo di migrazione dei Delegated Managed Service Accounts (dMSA) per ottenere escalation di privilegi all’interno di Active Directory.

L’attacco si basa su un abuso delle relazioni di migrazione tra account legacy e dMSA:
in ambienti in cui le unità organizzative (OU) concedono permessi eccessivi a utenti o gruppi non amministrativi (ad esempio Create/Delete Child o Write Property sugli oggetti di tipo serviceAccount), un utente non privilegiato può:

• Creare un nuovo dMSA o avviare una migrazione fittizia tramite il cmdlet Start-ADServiceAccountMigration;
• Collegarlo a un account di servizio esistente e ottenere l’accesso ai suoi diritti o SPN;
• Sfruttare questa relazione per ottenere ticket Kerberos con privilegi superiori o manipolare l’autenticazione di servizi sensibili.

Raccomandazioni di sicurezza

• Applicare rigorosamente il principio del minimo privilegio (Least Privilege): concedere i permessi di creazione, migrazione o gestione dei dMSA solo agli amministratori fidati di dominio.
• Limitare le deleghe sulle OU che contengono account di servizio: evitare permessi diretti come Write Property, Write Member, o Reset Password a utenti non amministrativi.
• Abilitare auditing e monitoraggio per tutte le operazioni che coinvolgono i cmdlet:
  • Start-ADServiceAccountMigration
  • Complete-ADServiceAccountMigration
  • Undo-ADServiceAccountMigration
  • Reset-ADServiceAccountMigration
• Controllare i log di sicurezza e PowerShell (Event ID 4104, 4662, 4738) per individuare attività sospette relative a modifiche degli attributi:
  • msDS-DelegatedMSAState
  • msDS-ManagedAccountPrecededByLink
  • msDS-SupersededManagedAccountLink
• Verificare regolarmente che gli account legacy disabilitati non vengano riattivati e che i dMSA non presentino collegamenti anomali.
• Integrare questi controlli con le linee guida di hardening illustrate in “Active Directory Hardening: Best practices “from the field” – ICT Power“, che coprono protezione OU, auditing e sicurezza delle identità di servizio.

Conclusioni

Con Windows Server 2025 Microsoft introduce un nuovo paradigma nella gestione degli account di servizio.

I Delegated Managed Service Accounts permettono di coniugare autonomia amministrativa, maggiore sicurezza e riduzione dei privilegi globali, semplificando la vita dei sistemisti e migliorando la postura di sicurezza complessiva degli ambienti Windows.

Grazie all’integrazione con Credential Guard e alla possibilità di gestire le credenziali in modo completamente locale, i dMSA rappresentano la risposta moderna alle esigenze di sicurezza dei data center e delle infrastrutture ibride.

I dMSA segnano un’evoluzione importante del modello di autenticazione di Windows Server, portando il principio “least privilege by design” al livello successivo, in uno scenario dove la protezione delle identità è sempre più centrale