Scegliere l'account di un servizio Windows — LocalSystem, account virtuali e gMSA

«Un servizio interno che facevamo girare come LocalSystem “per ora” è stato segnalato in un audit di sicurezza come “privilegio eccessivo”. In cosa dovremmo cambiarlo?» «Il servizio non riusciva ad accedere a una cartella condivisa, quindi lo facciamo girare come utente di dominio. Quando la password scade il servizio si ferma, quindi l’abbiamo resa senza scadenza e l’abbiamo scritta in chiaro nel runbook.» — Tra le consulenze sui servizi Windows dei clienti, queste due sono classiche.

Ciò che i due siti hanno in comune è che l’account di accesso del servizio è congelato come «l’impostazione che per caso ha funzionato», non come una decisione di progetto. Un servizio Windows gira sempre nel contesto di sicurezza di qualche account, e quell’account decide tutto: cosa può fare in locale, chi è dall’altra parte della rete e chi gestisce la password. Lasciate questo al valore predefinito e una vulnerabilità di un solo servizio porta direttamente alla presa dell’intera macchina, e le password in chiaro si disperdono in runbook e script.

flowchart TB
    accTitle: Tre cose che l'account di accesso decide
    accDescr: Un servizio gira sempre nel contesto di sicurezza di un account, e quell'account decide tutto ciò che può fare in locale, chi è dall'altra parte della rete e chi gestisce la password
    acct["L'account di accesso del servizio"] --> local["Cosa può fare in locale"]
    acct --> net["Chi è dall'altra parte della rete"]
    acct --> pwd["Chi gestisce la password"]

Figura 1: Scegliere l’account di accesso è una decisione di progetto che fissa insieme privilegi locali, identità di rete e gestione della password.

Ci sono di fatto sei scelte — LocalSystem, LocalService, NetworkService, un account virtuale (NT SERVICE\), un utente di dominio e un gMSA (account di servizio gestito di gruppo). Destinato al personale IT di PMI e agli sviluppatori di app Windows, questo articolo organizza privilegi, identità di rete e gestione delle password di queste sei in una sola tabella e riassume un flusso decisionale, sulla base delle fonti primarie Microsoft Learn di agosto 2026.

Come costruire il servizio stesso (scelta tra Utilità di pianificazione e un servizio, implementazione con un .NET Worker Service) è trattato in «How to Build and Operate Windows Services». Questo articolo si concentra sull’«account di accesso», dove succedono più incidenti.

1. Prima la conclusione

• Nel dubbio, un account virtuale è il primo candidato per un servizio che si chiude dentro una sola macchina, e un gMSA è il primo candidato per un servizio che accede a una risorsa del dominio con un’identità propria del servizio. Microsoft dà anche la guida a usare un account gestito (MSA / account virtuale) ovunque possibile.¹²
• Non scegliete LocalSystem perché «funziona». Il token include SYSTEM e BUILTIN\Administrators e detiene privilegi forti come SeDebugPrivilege, quindi una presa di controllo perde quasi tutto su quella macchina. Che il valore predefinito di sc.exe create sia LocalSystem è il terreno di coltura di questo incidente.³⁴
• La differenza tra LocalService e NetworkService è l’identità di rete. I privilegi locali sono minimi per entrambi, ma verso il remoto LocalService appare anonimo e NetworkService appare come l’account computer.⁵
• **Un account virtuale (NT SERVICE\) è il default moderno che può separare l'identità per servizio senza bisogno di gestione della password.** Potete indicare «NT SERVICE\\nome-del-servizio» direttamente su un'ACL, e l'account di servizio predefinito di SQL Server è questo.[^understand-service-accounts][^sql-service-accounts]
• Quando LocalSystem, NetworkService o un account virtuale escono in rete, diventano l’account computer (DOMAIN\nome-computer$). Concedere PC$ sull’ACL di una cartella condivisa o di SQL Server spesso permette di fare a meno di un utente di dominio.³⁶
• Una configurazione che usa un utente di dominio per un servizio diventa debito sia sull’esercizio delle password sia verso il Kerberoasting. Lo SCM accede con la password memorizzata, quindi la scadenza diventa un fallimento di avvio, e il «mai scadenza + nota in chiaro» che lo evita diventa un regalo per l’attaccante.⁷⁸
• Un gMSA fa generare e ruotare la password automaticamente da Active Directory. I requisiti sono un dominio e una chiave radice KDS, e impostate il servizio su «DOMAIN\nome-account$» con il campo password vuoto. Alcune app non lo supportano, quindi serve validare in anticipo.⁹¹⁰
• Cambiare l’account cambia le ipotesi di profilo, %TEMP% e DPAPI. I dati protetti con il DPAPI del vecchio account non possono essere decifrati dal nuovo.
• Un inventario dello stato attuale si conferma dagli account di accesso dell’elenco servizi e dall’ID evento 4624 (tipo di accesso 5).¹¹

In una frase, la conclusione di questo articolo è: fate di una configurazione che «non dà a un servizio una password umana» (account integrati, account virtuale, gMSA) il default, e trattate l’utente di dominio come ultima risorsa.

2. Il quadro delle scelte — sei account di accesso in una tabella

Un gradino di ripasso prima. All’avvio del servizio, il Gestore di controllo dei servizi (SCM) accede con l’account configurato e, in caso di successo, crea un token di accesso e lo assegna al processo del servizio. Da lì, ogni accesso a una risorsa — file, pipe e simili — si decide confrontando questo token con l’ACL.⁷ Scegliere l’account di accesso è quindi un progetto che decide il contenuto del token passato al processo del servizio. Ecco le sei scelte.

flowchart TB
    accTitle: Cosa fa lo SCM all'avvio di un servizio
    accDescr: Lo SCM accede con l'account configurato, in caso di successo crea un token di accesso e lo assegna al processo del servizio, e da lì l'accesso alle risorse si decide confrontando il token con l'ACL
    scm["SCM"] --> logon["Accedere con l'account configurato"]
    logon --> token["Creare un token di accesso"]
    token --> proc["Assegnarlo al processo del servizio"]
    proc --> access["Accesso a un file o a una pipe"]
    access --> check{"L'ACL lo consente?"}
    check -->|Sì| ok["Accesso riuscito"]
    check -->|No| deny["Accesso negato"]

Figura 2: Ogni accesso alle risorse del servizio si decide confrontando il token creato dallo SCM all’avvio con l’ACL.

LocalSystem, LocalService, NetworkService e un account virtuale non hanno affatto il concetto di password. Gli unici che accedono con una password memorizzata nello SCM (= scadenza e fuga possibili) sono un utente di dominio e un utente locale.⁷³

Sotto scaviamo questa tabella una riga alla volta.

3. Cosa non va in LocalSystem

3.1. Ancora più forte di «Esegui come amministratore»

LocalSystem (nome visualizzato Local System, NT AUTHORITY\SYSTEM) è un account predefinito che lo SCM usa e detiene privilegi estesi sul computer locale. Il token include i SID di NT AUTHORITY\SYSTEM e BUILTIN\Administrators e può accedere alla maggior parte degli oggetti sul sistema. Inoltre SeDebugPrivilege, che può eseguire il debug di altri processi, e SeTcbPrivilege, che agisce come parte dell’OS, sono abilitati di default.³

Questa forza è sinonimo dell’ampiezza del danno in caso di presa di controllo. Se un servizio che gira come LocalSystem ha una vulnerabilità di esecuzione di codice arbitrario, un attaccante arriva, in un respiro, a leggere e alterare i file di ogni utente su quella macchina (SYSTEM ha Controllo completo di default su NTFS⁵), a leggere la memoria di altri processi via SeDebugPrivilege e a rubare credenziali e muoversi lateralmente da lì (un punto di partenza per Pass-the-Hash e simili). La catena di furto di credenziali e movimento laterale è trattata in «NTLM and Kerberos Explained with Diagrams» e «A Practical Guide to Windows LAPS».

flowchart TB
    accTitle: Il danno quando un servizio LocalSystem viene preso
    accDescr: Se un servizio che gira come LocalSystem ha una vulnerabilità di esecuzione di codice arbitrario, un attaccante arriva a leggere e alterare i file di ogni utente, a leggere la memoria di altri processi e a rubare credenziali e muoversi lateralmente
    vuln["Una vulnerabilità di esecuzione di codice"] --> sys["L'attaccante ottiene i privilegi SYSTEM"]
    sys --> files["Lettura e alterazione dei file"]
    sys --> mem["Lettura della memoria di altri processi"]
    sys --> cred["Furto di credenziali"]
    cred --> lateral["Movimento laterale verso un'altra macchina"]

Figura 3: Una vulnerabilità in un servizio LocalSystem lascia un attaccante arrivare, in un respiro, alla presa dell’intera macchina e a un punto di partenza per il movimento laterale.

3.2. Perché viene ancora scelto

Il motivo è semplice: è il default e un accesso negato non compare mai. Il default quando omettete obj= su sc.exe create è LocalSystem,⁴ e molti vecchi esempi e modelli di installer assumono ancora LocalSystem. Perché potete restare liberi da errori di privilegio in sviluppo, c’è la struttura che produce in massa «ha funzionato, quindi lascialo». La documentazione di Microsoft stessa afferma che la maggior parte dei servizi non ha bisogno di un livello di privilegio così alto e che se non vi serve dovreste considerare LocalService o NetworkService.³

flowchart TB
    accTitle: La struttura che fa ancora scegliere LocalSystem
    accDescr: Il default di sc.exe create è LocalSystem e i vecchi esempi e modelli assumono LocalSystem, quindi in sviluppo non compare un accesso negato e una configurazione ha funzionato quindi lascialo viene prodotta in massa
    def["Il default di sc.exe create"] --> lsys["Creato come LocalSystem"]
    old["Vecchi esempi e modelli"] --> lsys
    lsys --> noerr["Nessun accesso negato in sviluppo"]
    noerr --> asis["Ha funzionato, quindi lascialo"]
    asis --> mass["Servizi con privilegio eccessivo vengono prodotti in massa"]

Figura 4: Il default e un’esperienza di sviluppo «senza accesso negato» producono in massa servizi congelati come LocalSystem.

3.3. La differenza da TrustedInstaller — nemmeno LocalSystem è illimitato

Chiamare LocalSystem «l’account più forte di Windows» non è accurato. La Protezione risorse di Windows (WRP) da Windows Vista consente modifiche a file, cartelle e chiavi di registro importanti del sistema solo a TrustedInstaller (il servizio Programma di installazione moduli di Windows), e anche SYSTEM o un amministratore ricevono accesso negato su una riscrittura.¹² Il «È necessaria l’autorizzazione di TrustedInstaller» di Explorer è questo meccanismo. Al contrario, LocalSystem può raggiungere quasi tutto fuori dall’area protetta da WRP, e di solito non c’è motivo di dare questo a un servizio di business.

flowchart TB
    accTitle: La relazione tra l'area protetta da WRP e TrustedInstaller
    accDescr: Le modifiche a file di sistema e chiavi di registro importanti che WRP protegge sono consentite solo a TrustedInstaller, e anche SYSTEM o un amministratore ricevono accesso negato
    ti["TrustedInstaller"] -->|Può modificare| wrp["File di sistema protetti da WRP e simili"]
    sysadm["SYSTEM e amministratori"] -->|Accesso negato| wrp
    sysadm -->|Quasi tutto è consentito| other["Fuori dall'area protetta da WRP"]

Figura 5: Nemmeno LocalSystem è illimitato; le modifiche all’area protetta da WRP sono consentite solo a TrustedInstaller.

3.4. Casi in cui LocalSystem è ragionevole

Ciò che è eccezionalmente ragionevole è un servizio i cui privilegi richiesti superano già in partenza la classe amministratore — lavorare a stretto contatto con un driver di dispositivo, operare il fondamento di sicurezza dell’OS, gestire altri servizi o sessioni e simili. Si applica software come un agente di backup o un EDR. Anche allora vale confermare che esista un percorso di codice che usa davvero quel privilegio e considerare se il lavoro che ha bisogno del privilegio può essere separato (per come distinguerlo, vedi «When Do You Actually Need Administrator Privileges on Windows?»).

4. LocalService e NetworkService — account integrati a privilegio minimo

LocalService (NT AUTHORITY\LOCAL SERVICE, SID: S-1-5-19) e NetworkService (NT AUTHORITY\NETWORK SERVICE, SID: S-1-5-20) sono account integrati preparati per servizi a basso privilegio. Entrambi detengono solo privilegi minimi in locale e possono poco più di un membro del gruppo Users.⁵¹

La differenza tra i due è un punto: chi sono dall’altra parte della rete.⁵

• LocalService: si connette al remoto con credenziali anonime. Non può accedere a una risorsa che richiede autenticazione.
• NetworkService: presenta le credenziali del computer al remoto (in un ambiente di dominio, DOMAIN\nome-computer$).

Lo spacco è LocalService se «non esce in rete, o se lo fa non ha bisogno di identità», e NetworkService se «volete accedere a una risorsa del dominio con l’identità della macchina».

flowchart TB
    accTitle: La differenza tra LocalService e NetworkService
    accDescr: I privilegi locali sono minimi per entrambi, ma verso il remoto LocalService si connette con credenziali anonime e NetworkService presenta quelle del computer
    ls["LocalService"] --> anon["Si connette con credenziali anonime"]
    anon -.-> ng["Una risorsa che richiede autenticazione non è possibile"]
    ns["NetworkService"] --> comp["Presenta le credenziali del computer"]
    comp -.-> pc["In un dominio appare come PC$"]

Figura 6: I privilegi locali sono lo stesso minimo, ma l’identità visibile dall’altra parte della rete si spezza in anonimo o account computer.

Questi due però hanno una debolezza dal punto di vista moderno. Lo stesso account è condiviso da molti servizi. Se cinque servizi girano come LocalService, finché l’ACL è per account i cinque possono accedere alle risorse gli uni degli altri. SQL Server non supporta l’account Local Service per lo stesso motivo: è un account condiviso e non si può separare dagli altri servizi.¹

flowchart TB
    accTitle: Un account condiviso non si può separare
    accDescr: Se più servizi condividono lo stesso LocalService, finché l'ACL è per account possono accedere alle risorse gli uni degli altri
    sva["Servizio A"] --> acct["Lo stesso LocalService"]
    svb["Servizio B"] --> acct
    svc["Servizio C"] --> acct
    acct --> mutual["Possono accedere alle risorse gli uni degli altri"]
    mutual -.-> reason["Perché l'ACL è per account"]

Figura 7: I servizi che condividono lo stesso account non possono essere separati dalle risorse gli uni degli altri da un’ACL.

Risolvere questo «restare a basso privilegio, ma separare per servizio» è il tema successivo, l’account virtuale.

5. Account virtuali (NT SERVICE\) — il default moderno

5.1. Potete avere un’identità per servizio senza password

Un account virtuale è un «account locale gestito» disponibile da Windows Server 2008 R2 / Windows 7. Ha tre caratteristiche.⁶

• L’account è gestito automaticamente; non servono né creazione né impostazione di una password
• Il nome è NT SERVICE\<nome-del-servizio> e diventa un’identità unica di ogni servizio
• In un ambiente di dominio può accedere alla rete con le credenziali dell’account computer (DOMAIN\nome-computer$)

In altre parole, tiene il pregio «nessuna gestione della password» di LocalService/NetworkService e toglie il difetto «non si può separare perché l’account è condiviso». È anche perché l’installazione di SQL Server usa di default un account virtuale come NT SERVICE\MSSQLSERVER.¹

flowchart TB
    accTitle: Cosa un account virtuale rende compatibile
    accDescr: Un account virtuale tiene il pregio nessuna gestione della password di LocalService e NetworkService, toglie il difetto non si può separare perché condiviso e ha un'identità unica di ogni servizio
    merit["Pregio (nessuna gestione della password)"] -->|Tenere| va["Account virtuale"]
    demerit["Difetto (non si può separare perché condiviso)"] -->|Togliere| va
    va --> ident["Un'identità unica di ogni servizio"]
    va --> auto["Né creazione né password sono necessarie"]

Figura 8: Un account virtuale tiene i pregi degli account integrati e toglie solo il difetto non si può separare perché condiviso.

5.2. Potete scrivere «NT SERVICE\nome-del-servizio» direttamente su un’ACL

La comodità pratica è che potete aggiungere solo quel servizio a un’ACL per nome. «Solo questo servizio può scrivere in questa cartella dati» si realizza senza creare un gruppo né gestire una password.

# Change the service's logon account to a virtual account
# The value of obj= is "NT SERVICE\service-name". Do not specify a password
sc.exe config MyAppService obj= "NT SERVICE\MyAppService"

# Confirm the configuration (check SERVICE_START_NAME)
sc.exe qc MyAppService

# Grant modify rights on the data folder to this service only
icacls "C:\ProgramData\MyApp" /grant "NT SERVICE\MyAppService:(OI)(CI)M"

Nella GUI, in services.msc aprite le proprietà del servizio → scheda «Accedi» → inserite NT SERVICE\nome-del-servizio in «Questo account» e lasciate vuoti i campi password (per un account virtuale o un MSA, non specificare una password è la specifica dello SCM). Dopo il cambio, un riavvio del servizio lo applica.

5.3. Il vincolo — fuori dalla macchina non è «quel servizio»

L’identità di un account virtuale è locale alla macchina e non è riconosciuta dal dominio. In rete collassa all’account computer come descritto più avanti, quindi il remoto non può dire «di quale servizio si tratta», e non potete nemmeno condividere la stessa identità su più server.¹⁰

flowchart TB
    accTitle: L'identità di un account virtuale collassa fuori dalla macchina
    accDescr: Un account virtuale unico per servizio dentro la macchina collassa anche all'account computer in rete, e il remoto non può dire di quale servizio si tratta
    vaa["Account virtuale A"] --> pc["Account computer PC$"]
    vab["Account virtuale B"] --> pc
    pc --> remote["L'identità visibile al remoto"]
    remote -.-> nodist["Non si può dire di quale servizio si tratta"]

Figura 9: Anche con un’identità unica dentro la macchina, dall’altra parte della rete ogni servizio sembra lo stesso PC$.

Il momento in cui questo vincolo — bisogno di un’identità propria del servizio dall’altra parte della rete, bisogno della stessa identità su più server — diventa un problema è quello in cui viene chiamato un gMSA (capitolo 8).

6. Identità quando si esce in rete — la pratica dell’account computer (PC$)

6.1. «Un servizio non può accedere a una cartella condivisa» è un malinteso

Su una macchina aggiunta al dominio, quando un servizio che gira come LocalSystem, NetworkService o account virtuale accede a una risorsa remota, si autentica come account computer (DOMAIN\nome-computer$).³⁶ Molte delle consulenze di apertura «non riusciva ad accedere a una cartella condivisa, quindi l’abbiamo fatto utente di dominio» si risolvono in realtà così. L’ACL di destinazione semplicemente non consenteva PC$.

flowchart TB
    accTitle: Accesso remoto come account computer
    accDescr: Un servizio LocalSystem, NetworkService o account virtuale su una macchina aggiunta al dominio si autentica verso il remoto come account computer, e se l'ACL di destinazione consente PC$ può accedere
    svc["Servizio (LocalSystem, un account virtuale e simili)"] --> auth["Autenticarsi come PC$"]
    auth --> acl{"L'ACL di destinazione consente PC$?"}
    acl -->|Sì| ok["L'accesso a una cartella condivisa o a un DB riesce"]
    acl -->|No| ng["Accesso negato"]

Figura 10: In un ambiente di dominio, concedere PC$ sull’ACL di destinazione da solo stabilisce l’accesso remoto senza un utente di dominio.

La concessione lato file server è la stessa di un’operazione ACL ordinaria; indicate nome-computer$ come nome account (nella finestra di selezione oggetti della GUI includete «Computer» nei tipi di oggetto).

# On the file-server side: grant a service on APPSV01 modify rights on the shared folder
# You need to grant both share permissions and NTFS permissions
Grant-SmbShareAccess -Name "AppData" -AccountName "CORP\APPSV01$" -AccessRight Change -Force
icacls "D:\Shares\AppData" /grant "CORP\APPSV01$:(OI)(CI)M"

SQL Server è lo stesso: create l’account computer come accesso e la stringa di connessione passa con Integrated Security=true e senza password.

-- On the DB-server side: permit Windows integrated authentication from a service on APPSV01
CREATE LOGIN [CORP\APPSV01$] FROM WINDOWS;

6.2. Conoscere i limiti dell’approccio PC$

Questo approccio ha due limiti.

1. La granularità è per macchina. LocalSystem, NetworkService e ogni servizio a account virtuale sulla stessa macchina sembrano tutti lo stesso PC$ dal remoto. Non potete «autorizzare solo questo servizio» sulla destinazione e non potete nemmeno auditare quale servizio ha usato quell’account.²
2. Non si può usare in un ambiente di gruppo di lavoro. Un account computer è un oggetto Active Directory, quindi una macchina non aggiunta al dominio non ne ha uno. Serve un progetto che gestisca esplicitamente le credenziali dell’account di destinazione.

Quando volete superare il limite 1, la risposta 2026 non è l’utente di dominio del capitolo successivo… ma saltare quel problema e procedere a un gMSA.

flowchart TB
    accTitle: Due limiti dell'approccio PC$
    accDescr: L'autenticazione come PC$ ha granularità a livello di macchina quindi né autorizzazione né audit per servizio sono possibili, e in un gruppo di lavoro l'account computer stesso non esiste quindi non si può usare
    pcs["L'approccio PC$"] --> lim1["Limite 1: per macchina"]
    pcs --> lim2["Limite 2: nessun gruppo di lavoro"]
    lim1 -.-> noaudit["Né autorizzazione né audit per servizio"]
    lim2 -.-> nocred["Usare credenziali esplicite"]
    lim1 --> gmsa["Oltre: un gMSA"]

Figura 11: Quando volete superare i due limiti di granularità a livello di macchina e prerequisito di dominio, saltate l’utente di dominio e procedete a un gMSA.

7. Il problema di usare un utente di dominio per un servizio

7.1. Il problema strutturale della password

Se assegnate un utente di dominio (o un utente locale) a un servizio, lo SCM memorizza quella password e la usa per accedere a ogni avvio. Lo SCM non gestisce la scadenza, quindi quando la password scade l’accesso fallisce e il servizio non si avvia.⁷

Da lì inizia la spirale negativa che si vede spesso sul campo.

1. Avviene un incidente di arresto del servizio per scadenza
2. Come prevenzione di recidiva si imposta «password non scade mai»
3. Una procedura di cambio non viene mai stabilita e la stessa password è scritta in chiaro nei runbook, script e Utilità di pianificazione di più server
4. Anche quando qualcuno se ne va, la password non cambia (se la cambiate, non sapete cosa si fermerà)

flowchart TB
    accTitle: La spirale negativa di operare con un utente di dominio
    accDescr: La password scade e il servizio si ferma, mai-scadenza viene impostato come prevenzione di recidiva, una password in chiaro si diffonde in runbook e script, e anche quando qualcuno se ne va non si può cambiare
    expire["1. La scadenza ferma il servizio"] --> forever["2. Mai-scadenza viene impostato come prevenzione"]
    forever --> spread["3. Una password in chiaro si diffonde"]
    spread -.-> where["Runbook, script, attività"]
    spread --> stuck["4. Anche quando qualcuno se ne va, non si può cambiare"]

Figura 12: Partendo da un incidente di scadenza, mai-scadenza e la diffusione di una password in chiaro si fissano.

Microsoft sottolinea anche che una configurazione che usa un account di dominio per un servizio costa notevole sforzo operativo nella gestione manuale di password e SPN, e che la manutenzione può portare a un arresto del servizio.¹

7.2. Kerberoasting — un account di servizio è preso di mira

Un altro attacco specifico di un account di servizio utente di dominio è il Kerberoasting. Un servizio che riceve autenticazione Kerberos registra un SPN (nome dell’entità servizio) sull’account di accesso. Qualsiasi utente autenticato nel dominio può richiedere un ticket di servizio a un account che ha uno SPN registrato, quindi un attaccante ottiene il ticket e tenta un brute-force offline della password. Una password di 10-16 caratteri decisa da un umano non regge a questo attacco.

flowchart TB
    accTitle: Il flusso del Kerberoasting
    accDescr: Un ticket di servizio verso un account di servizio che ha uno SPN registrato può essere richiesto da qualsiasi utente autenticato, quindi un attaccante ottiene il ticket e tenta un brute-force offline della password
    atk["Un utente autenticato nel dominio"] --> req["Richiedere un ticket per lo SPN"]
    req --> tkt["Ottenere un ticket di servizio"]
    tkt --> brute["Brute-force offline"]
    brute --> weak["Circa 10-16 caratteri verranno spezzati"]

Figura 13: Qualsiasi utente autenticato può richiedere un ticket, e una password di una lunghezza decisa da un umano non regge a un brute-force offline.

La risposta efficace è rendere la password di una forza che un umano non può indovinare né spezzare. Microsoft elenca anche il forzare una password lunga e l’uso di un gMSA la cui password diventa un valore casuale lungo generato dalla macchina.⁸ Lo stesso documento menziona anche l’armatura Kerberos (FAST), ma FAST protegge i dati di preautenticazione e la resistenza allo spoofing del KDC; non impedisce a un utente autenticato di richiedere un ticket di servizio a uno SPN, quindi non è un sostituto della forza della password di un account di servizio. La relazione tra SPN e Kerberos e le condizioni in cui l’autenticazione cade su NTLM sono diagrammate in «NTLM and Kerberos Explained with Diagrams».

7.3. Se usate comunque un utente di dominio

Se non avete scelta se non usare un utente di dominio, per motivi come l’applicazione che non supporta un gMSA, trattate quanto segue come mitigazione minima.

• Rendete la password 25 caratteri o più generati a caso e non scrivetela da nessuna parte se non in uno strumento di gestione password (runbook, script, un Excel condiviso)
• Fatene un account dedicato al servizio e spezzatelo per servizio (non condividetelo con un account umano²)
• Negate l’accesso interattivo e Desktop remoto e consentite solo «Accedere come servizio»
• Riducete al minimo i gruppi a cui appartiene (aggiungerlo a Domain Admins è fuori discussione)
• Stabilite una procedura di rotazione periodica e mettetene i punti che un cambio colpirà in un registro

Fare tutto questo è meno sicuro e meno facile che migrare a un gMSA — è il capitolo successivo.

8. gMSA — lasciare la gestione della password ad Active Directory

8.1. Il meccanismo e l’effetto

Un gMSA (account di servizio gestito di gruppo) è un account di dominio che lascia la gestione della password al controller di dominio. La password è calcolata dal controller di dominio dalla chiave radice KDS (Key Distribution Service) e solo gli host autorizzati la ottengono.¹³

flowchart TB
    accTitle: Come un gMSA gestisce la password
    accDescr: Il controller di dominio calcola la password dalla chiave radice KDS, solo gli host autorizzati la ottengono e la usano per far girare il servizio, e la password viene ruotata automaticamente ogni 30 giorni di default
    kds["Chiave radice KDS"] --> dc["Il DC calcola la password"]
    dc --> host["Un host autorizzato la ottiene"]
    host --> svc["Usata per far girare il servizio"]
    dc -.-> rot["Rotazione automatica ogni 30 giorni di default"]

Figura 14: Il controller di dominio si assume generazione, distribuzione e aggiornamento della password, e le persone possono operare senza conoscere la password.

Gli effetti sono chiari.⁹

• Una password di 240 byte generata a caso: brute-force e attacchi a dizionario diventano irrealistici e la resistenza al Kerberoasting sale in modo sostanziale
• Rotazione automatica ogni 30 giorni di default: una persona non deve pianificare un cambio e il servizio non deve essere fermato
• La stessa identità può essere condivisa su più server: una server farm sotto bilanciamento del carico può autenticarsi a vicenda come lo stesso principale
• Gestione SPN più semplice: registrazione e gestione degli SPN possono anche essere delegate e semplificate

Le persone possono operare senza conoscere la password — se lo prendete come il meccanismo che fa per un account di servizio ciò che Windows LAPS fa per una password di amministratore locale, il posizionamento è più facile da afferrare.

8.2. Requisiti

Un gMSA ha prerequisiti.¹⁰

• Un ambiente di dominio Active Directory (non possibile in un gruppo di lavoro)
• Livelli funzionali di dominio e foresta Windows Server 2012 o superiore
• Una chiave radice KDS è già stata creata
• Il nome del gMSA è univoco nella foresta, non solo nel dominio
• L’intervallo di cambio password si può impostare solo in creazione

Creare la chiave radice KDS è un’operazione una tantum, ma fino a 10 ore dopo la creazione non potete creare un gMSA, perché aspettate la replica verso ogni controller di dominio. È un dispositivo di sicurezza per impedire l’incidente di un fallimento di recupero della password prima che la replica sia finita.¹⁴

flowchart TB
    accTitle: Dalla creazione della chiave radice KDS alla creazione di un gMSA
    accDescr: Dopo la creazione della chiave radice KDS aspettate la replica verso ogni controller di dominio, quindi fino a 10 ore non potete creare un gMSA; dopo il completamento della replica potete crearne uno
    add["Creare la chiave radice KDS"] --> wait["Fino a 10 ore di attesa della replica"]
    wait -.-> why["Un dispositivo di sicurezza per impedire un incidente di fallimento di recupero"]
    wait --> done["La replica verso ogni DC è completata"]
    done --> ok["Potete creare un gMSA"]

Figura 15: L’attesa fino a 10 ore dopo la creazione della chiave radice è tempo di attesa per impedire un fallimento di recupero finché la replica non è finita.

# Run as a domain administrator, on a domain controller (or an administrative
# workstation with the AD PowerShell module)

# Confirm whether a KDS root key exists, and create one if not (once per forest)
Get-KdsRootKey
Add-KdsRootKey -EffectiveImmediately   # Actually usable after up to 10 hours

8.3. La procedura dalla creazione alla configurazione

La procedura è in quattro fasi: «① creare un gruppo autorizzato a recuperare → ② creare il gMSA → ③ installarlo sui server → ④ impostarlo sul servizio».¹⁰

flowchart TB
    accTitle: Le quattro fasi di introduzione di un gMSA
    accDescr: Introdurlo in quattro fasi: creare un gruppo autorizzato a recuperare la password, creare il gMSA, installarlo su ogni server e impostarlo come account di accesso del servizio
    st1["① Creare un gruppo autorizzato a recuperare"] --> st2["② Creare il gMSA"]
    st1 -.-> add["Aggiungere i PC$ dei server"]
    st2 --> st3["③ Installare su ogni server"]
    st3 -.-> test["Validare il recupero con il comando Test"]
    st3 --> st4["④ Impostarlo sul servizio"]

Figura 16: Dalla creazione del gruppo all’impostazione del servizio, l’introduzione di un gMSA procede in quattro fasi.

# ① Create a security group permitted to retrieve the password,
#    and add the computer accounts of the servers that will run the service
New-ADGroup -Name "GG-SvcBatchHosts" -GroupScope Global
Add-ADGroupMember -Identity "GG-SvcBatchHosts" -Members "APPSV01$", "APPSV02$"
# Group membership is evaluated at computer logon, so
# restarting the target servers after adding is the reliable approach

# ② Create the gMSA
New-ADServiceAccount -Name "svc-batch" `
    -DNSHostName "svc-batch.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "GG-SvcBatchHosts"

# ③ On each server that will run the service, install the gMSA and validate
Install-ADServiceAccount -Identity "svc-batch"
Test-ADServiceAccount -Identity "svc-batch"   # True means retrieval is working

# ④ Set it as the service's logon account. Append $ to the name, and do not specify a password
sc.exe config MyBatchService obj= "CORP\svc-batch$"
Restart-Service MyBatchService

Anche impostando da services.msc, il nome account è come CORP\svc-batch$ — aggiungete $ alla fine e lasciate vuoti i campi password. Un account della famiglia MSA non può essere usato per un accesso interattivo.¹ Poi concedete CORP\svc-batch$ sull’ACL di una cartella condivisa o di SQL Server al posto di PC$, e l’accesso di rete con un’identità propria del servizio è completo, senza password.

8.4. Alcune app non lo supportano

Come avvertenza, non ogni software girerà come gMSA. Le cose che configurano l’identità di accesso tramite un meccanismo standard — un servizio Windows, un pool di applicazioni IIS, un’attività dell’Utilità di pianificazione — sono ampiamente supportate, ma ci sono vincoli come il clustering di failover stesso che non supporta un gMSA e un’app il cui interno esige una password che non può usarlo.¹⁰ Microsoft afferma anche chiaramente che dovreste confermare il comportamento come gMSA in un ambiente di test prima della produzione.⁹

flowchart TB
    accTitle: Distinguere se qualcosa supporta un gMSA
    accDescr: Un'app che configura l'identità di accesso tramite un meccanismo standard supporta ampiamente un gMSA, ma il clustering di failover e un'app il cui interno esige una password non possono usarlo, quindi confermate in un ambiente di test prima della produzione
    app["L'app di destinazione"] --> how{"Come si imposta l'accesso?"}
    how -->|Meccanismo standard| okapp["gMSA supportato"]
    okapp -.-> ex1["Servizio, IIS, un'attività"]
    how -->|Password richiesta| ngapp["gMSA non possibile"]
    ngapp -.-> ex2["Clustering di failover"]
    okapp --> test["Testare prima della produzione"]

Figura 17: Un’app che configura l’accesso tramite un meccanismo standard è ampiamente supportata, ma alcuni progetti non lo sono, quindi la validazione prima della produzione è indispensabile.

Ci sono anche fratelli: l’sMSA (account di servizio gestito autonomo) per un solo server e il dMSA (account di servizio gestito delegato, introdotto in Windows Server 2025, che si lega all’identità del dispositivo per contrastare il furto di credenziali). Per una nuova costruzione, prendete un gMSA come base e considerate secondo i requisiti.⁶

9. Progetto di accompagnamento — diritti di accesso, profilo, DPAPI e audit

Altre quattro cose che cambiano con l’account, da tenere.

9.1. Il diritto «Accedere come servizio» (SeServiceLogonRight)

Per avviarsi come servizio, l’account ha bisogno del diritto utente «Accedere come servizio». LocalSystem, LocalService e NetworkService lo hanno integrato, ma qualsiasi altro account (un utente di dominio, un gMSA e simili) ha bisogno di un’assegnazione esplicita.¹⁵

Se lo impostate dalla scheda «Accedi» della GUI di services.msc, lo snap-in concede questo diritto automaticamente. Invece CreateService / ChangeServiceConfig (le API che sc.exe config chiama) non verificano che l’account specificato abbia questo diritto. La causa tipica di un servizio configurato da uno script che si ferma all’avvio con «il servizio non è stato avviato a causa di un errore di accesso» è questa. Non affidatevi a un effetto collaterale di uno strumento; includete nella procedura di distribuzione, in modo esplicito, l’aggiunta a «Accedere come servizio» in Criteri di sicurezza locali (secpol.msc) o la configurazione via GPO/Intune (in un ambiente che configura questo diritto con Criteri di gruppo, una concessione locale viene sovrascritta quando il criterio si applica, quindi anche questo richiede attenzione). Al contrario, la mossa standard per un account dedicato al servizio è impostare insieme «Nega l’accesso locale».

flowchart TB
    accTitle: La differenza secondo il percorso di configurazione del diritto Accedere come servizio
    accDescr: La GUI di services.msc concede il diritto automaticamente, ma l'API che sc.exe config chiama non verifica il diritto, quindi un account senza il diritto ferma il servizio con un errore di accesso all'avvio
    gui["Impostare in services.msc"] --> auto["Il diritto viene concesso automaticamente"]
    auto --> okgui["Il servizio può avviarsi"]
    cli["Impostare con sc.exe config"] --> noval["Il diritto non viene verificato"]
    noval --> has{"Ha il diritto?"}
    has -->|Sì| okcli["Il servizio può avviarsi"]
    has -->|No| stop["Si ferma con un errore di accesso"]
    stop -.-> fix["Concedere in modo esplicito con secpol.msc o un GPO"]

Figura 18: La GUI concede il diritto automaticamente, ma una configurazione da script non lo verifica, quindi dovete includere una concessione esplicita nella procedura.

9.2. Profilo, %TEMP% e HKEY_CURRENT_USER cambiano

Lo SCM carica il profilo utente di quell’account all’avvio del servizio.⁷ Quindi i veri %TEMP%, %APPDATA% e HKEY_CURRENT_USER sono una cosa diversa per account di accesso, e quando cambiate account, impostazioni e cache salvate nel profilo del vecchio account sembrano «scomparse».

La risposta di progetto è semplice: mettete i dati del servizio non sotto il profilo ma su un percorso esplicito come C:\ProgramData\<nome-app> e concedete quell’ACL all’account di accesso. Così un cambio di account non porta una migrazione di dati.

flowchart TB
    accTitle: Dipendenza dal profilo e risposta del posizionamento dei dati
    accDescr: Il profilo reale è una cosa diversa per account di accesso, quindi cambiare account fa sembrare scomparsi i dati del vecchio profilo, ma posizionarli su un percorso esplicito e concedere l'ACL rende la migrazione inutile
    sw["Cambio dell'account di accesso"] --> newprof["Viene caricato un profilo diverso"]
    newprof --> lost["I vecchi dati sembrano scomparsi"]
    lost -.->|Risposta| fix["Posizionarli sotto ProgramData"]
    fix --> acl["Concedere l'ACL all'account di accesso"]
    acl --> nomig["Nessuna migrazione anche quando l'account cambia"]

Figura 19: Evitate il profilo e mettete i dati su un percorso esplicito, e un cambio di account non porta più una migrazione di dati.

9.3. I dati protetti con DPAPI sono legati all’account

Ancora più facile da perdere è DPAPI. I dati cifrati con DPAPI di ambito utente (CryptProtectData o ProtectedData di .NET) possono, in linea di principio, essere decifrati solo dallo stesso account che li ha protetti. Nel momento in cui cambiate l’account, una stringa di connessione o una chiave API memorizzata non si può più leggere — è DPAPI che fa correttamente il suo lavoro, ma se non è nella procedura di migrazione diventa un incidente.

flowchart TB
    accTitle: La relazione tra i dati protetti da DPAPI e un cambio di account
    accDescr: I dati protetti con DPAPI di ambito utente possono essere decifrati solo dallo stesso account che li ha protetti, quindi dopo aver cambiato l'account di accesso dovete reinserire i segreti
    protect["Proteggere con DPAPI con il vecchio account"] --> data["Una stringa di connessione protetta e simili"]
    data --> who{"Quale account sta decifrando?"}
    who -->|Lo stesso vecchio account| okdec["Può decifrare"]
    who -->|Il nuovo account| ngdec["Non può decifrare"]
    ngdec --> re["Reinserire i segreti"]

Figura 20: I dati protetti da DPAPI sono legati all’account che li ha protetti, e dopo un cambio di account dovete reinserire.

La risposta è includere nel piano di migrazione la procedura «reinserire i segreti dopo il cambio di account» (per il progetto di dove memorizzarli, vedi «Memorizzazione di segreti nelle app Windows»). Inoltre una configurazione che può chiudersi con l’autenticazione integrata Windows come gMSA o PC$ può eliminare la memorizzazione del segreto stesso. L’ordine corretto è considerare «possiamo farne a meno» prima di «dove lo memorizziamo».

E se il servizio vuole elaborare «con i privilegi dell’utente chiamante», usate l’impersonificazione invece di rendere l’account più forte. Per quello vedi «Handling Windows Impersonation Tokens Correctly».

9.4. Audit — guardate 4624 tipo di accesso 5

Un avvio di servizio viene registrato nel registro eventi di sicurezza come ID evento 4624 (Un account ha eseguito l’accesso) con tipo di accesso 5 (Servizio: lo SCM ha avviato un servizio). Il campo «Virtual Account» nell’evento indica se l’accesso era da un MSA / account virtuale, quindi si può usare anche per osservare l’uso di account gestiti.¹¹

flowchart TB
    accTitle: Il flusso di audit di un avvio di servizio
    accDescr: Lo SCM che avvia un servizio viene registrato come ID evento 4624 tipo di accesso 5, e il campo Virtual Account può identificare se l'accesso era da un account gestito
    start["Lo SCM avvia un servizio"] --> ev["Registrare l'ID evento 4624"]
    ev --> type5["Tipo di accesso 5 (Servizio)"]
    type5 --> vafield["Campo Virtual Account"]
    vafield --> watch["Osservare gli account gestiti"]

Figura 21: Un avvio di servizio viene registrato come un 4624 di tipo di accesso 5, e potete persino tracciare l’uso di account gestiti.

Per un inventario dello stato attuale, aggregare gli account di accesso dell’elenco servizi è il metodo veloce.

# Aggregate which services are running as which account
Get-CimInstance Win32_Service |
    Group-Object StartName |
    Sort-Object Count -Descending |
    Select-Object Count, Name

# Inventory non-standard services running as LocalSystem (tell in-house / third-party by the path)
Get-CimInstance Win32_Service |
    Where-Object { $_.StartName -eq 'LocalSystem' -and $_.PathName -notlike '*\Windows\*' } |
    Select-Object Name, DisplayName, PathName

Se questa uscita allinea «un servizio di business che gira come LocalSystem» e «un servizio che gira come utente di dominio», viene chiamato il flusso decisionale del capitolo successivo.

10. Flusso decisionale — decidere con quattro domande

Ecco il contenuto finora, come procedura di selezione. Rispondete a quattro domande in ordine.

flowchart TB
    accTitle: Il flusso decisionale per l'account di accesso
    accDescr: Decidere l'account di accesso rispondendo in ordine alle quattro domande di accesso di rete, adesione al dominio, se basta un'identità a livello di macchina e supporto gMSA
    q1{"Auth Windows verso un peer?"} -->|No| va["Account virtuale"]
    va -.-> sys["LocalSystem se serve"]
    q1 -->|Sì| q2{"Aggiunto al dominio?"}
    q2 -->|No| cred["Proteggere le credenziali memorizzate"]
    q2 -->|Sì| q3{"Livello macchina basta?"}
    q3 -->|Sì| pcacl["Account virtuale + PC$"]
    q3 -->|No| q4{"L'app supporta un gMSA?"}
    q4 -->|Sì| gmsa["gMSA"]
    q4 -->|No| du["Utente + mitigazioni"]

Figura 22: Rispondete alle quattro domande in ordine e quale delle sei scelte dovreste usare è deciso.

Domanda 1: Quel servizio accede a un’altra macchina in rete (una cartella condivisa, un DB, un’API e simili) con autenticazione Windows?

Se no, un account virtuale è il default. Solo se serve un privilegio locale speciale, confermate quel bisogno e poi considerate LocalSystem.

Domanda 2: (Se accede) La macchina è aggiunta al dominio?

In un gruppo di lavoro non si possono usare né PC$ né un gMSA. Usate un progetto che gestisca esplicitamente le credenziali dell’account di destinazione (protegete l’archivio con DPAPI o simili), o considerate di aggiungere al dominio.

Domanda 3: (In un dominio) Basta un’identità a livello di macchina (PC$)?

Se sì, un account virtuale (o NetworkService) + concedere PC$ sull’ACL di destinazione è completo. Se serve un’identità propria del servizio, o un’identità comune su più server, andate alla domanda 4.

Domanda 4: L’applicazione supporta un gMSA?

Se sì (le cose che configurano l’accesso tramite un meccanismo standard — SCM, un pool di app IIS, Utilità di pianificazione — in genere lo fanno), un gMSA. Non dimenticate un controllo di comportamento in un ambiente di validazione. Se non è supportato comunque, usate un utente di dominio dedicato dopo aver applicato ogni mitigazione della sezione 7.3.

In tabella è come segue.

11. Riepilogo

• L’account di accesso di un servizio è una decisione di progetto che decide insieme privilegi locali, identità di rete e gestione della password. Non lasciatelo al default (LocalSystem).
• LocalSystem detiene un token SYSTEM+Administrators e privilegi forti, e il danno in caso di presa di controllo è massimizzato. La maggior parte dei servizi di business non ha bisogno di questo privilegio.
• LocalService e NetworkService sono entrambi a basso privilegio; la differenza è l’identità di rete (anonimo, o l’account computer). Perché l’account è condiviso da più servizi, però, non si possono separare.
• Un account virtuale (NT SERVICE\) è il default moderno che può separare per servizio senza bisogno di gestione della password. Potete indicarlo direttamente su un'ACL e la configurazione è solo cambiare il nome dell'account di accesso.
• LocalSystem, NetworkService e un account virtuale escono in rete come DOMAIN\PC$ in un ambiente di dominio. Concedere PC$ sull’ACL di una cartella condivisa o di SQL Server spesso permette di fare a meno di un utente di dominio.
• Usare un utente di dominio per un servizio ha i problemi strutturali di un arresto per scadenza, della diffusione di una password in chiaro e del Kerberoasting. Se ne usate uno, servono un account dedicato + una password casuale lunga + restrizioni di accesso.
• Un gMSA è un meccanismo in cui AD genera e ruota la password automaticamente; i requisiti sono un dominio, livello funzionale 2012 o superiore e una chiave radice KDS. Impostate il servizio su «DOMAIN\nome$» con il campo password vuoto.
• Quando cambiate l’account, includete il diritto «Accedere come servizio», lo spostamento di profilo e %TEMP% e il reinserimento dei dati protetti da DPAPI nella procedura di migrazione. L’audit si conferma con l’ID evento 4624 tipo di accesso 5.

La prossima volta che installate un servizio, fermatevi un momento sulla schermata delle impostazioni di accesso e riformulate questa domanda. Come chi, e fino a dove, questo servizio dovrebbe poter accedere? La risposta dovrebbe essere qualche riga della tabella decisionale di questo articolo.

Articoli correlati

• How to Build and Operate Windows Services ── From Choosing Between Task Scheduler and Services to Turning a BackgroundService into a Windows Service
• When Do You Actually Need Administrator Privileges on Windows? - UAC, Protected Areas, and How to Tell by Design
• Handling Windows Impersonation Tokens Correctly — Borrowing Privileges per Thread and Reverting Safely
• NTLM and Kerberos Explained with Diagrams — Why Authentication Falls Back to NTLM
• A Practical Guide to Windows LAPS — Retiring the Shared Local Administrator Password Across All PCs
• Memorizzazione di segreti nelle app Windows: evitare la configurazione in testo normale con DPAPI

Aree di consulenza correlate

KomuraSoft LLC si occupa della progettazione dell’account di accesso e dell’indurimento a privilegio minimo per servizi Windows e app residenti, della migrazione a un account virtuale o a un gMSA di servizi esistenti costruiti sull’ipotesi di LocalSystem e dell’indagine di guasti causati da accesso negato, DPAPI e profilo dopo un cambio di account. Partire dallo stadio «ci hanno segnalato in un audit, ma non sappiamo da dove cominciare» va benissimo.

• Sviluppo di applicazioni Windows
• Analisi dei bug e delle cause
• Consulenza tecnica e revisione del progetto
• Contattaci

Riferimenti

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Devo cambiare subito un servizio che per ora gira come LocalSystem?

Un cambio immediato non è sempre la risposta giusta. Prima verificate se quel servizio ha davvero bisogno di privilegi locali di classe LocalSystem (privilegi forti oltre un amministratore). Se si tratta solo di lettura/scrittura di file e comunicazione di rete, il primo candidato è un account virtuale (NT SERVICE\nome-del-servizio). In migrazione confermate la concessione di accesso a cartelle e chiavi di registro necessarie, come gestire i dati che dipendono dal profilo o da DPAPI, e se è presente il diritto «Accedere come servizio». Confermate avvio e funzioni principali in un ambiente di validazione, poi passate la produzione.

Devo scegliere un account virtuale o NetworkService?

Per una scelta nuova raccomandiamo un account virtuale. In rete entrambi appaiono come l'account computer (DOMAIN\nome-computer$), e entrambi hanno privilegi locali piccoli. NetworkService però è condiviso da più servizi, quindi non potete separare con un'ACL che «autorizza solo questo servizio». Un account virtuale ha un'identità propria di ogni servizio e potete indicare NT SERVICE\nome-del-servizio direttamente su un'ACL. I prodotti Microsoft recenti come SQL Server usano di default un account virtuale.

Posso usare un gMSA in un ambiente di gruppo di lavoro (senza dominio)?

No. Un gMSA è un meccanismo in cui un controller di dominio Active Directory genera e gestisce la password; un dominio e la creazione di una chiave radice KDS sono prerequisiti. In un gruppo di lavoro la base è chiudere l'elaborazione locale con un account virtuale o LocalService/NetworkService. Se serve accedere a un'altra macchina, serve un altro progetto, ad esempio usare esplicitamente le credenziali di un account preparato sulla destinazione. L'accesso di rete come account computer (PC$) vale solo in un ambiente di dominio.

Dopo aver cambiato l'account di accesso del servizio, non riesco più a leggere impostazioni e credenziali salvate. Perché?

Perché ogni account di accesso è legato al proprio profilo utente, %TEMP%, HKEY_CURRENT_USER e chiave DPAPI. In particolare i dati protetti con DPAPI di ambito utente (CryptProtectData e simili) possono, in linea di principio, essere decifrati solo dallo stesso account che li ha protetti. I file salvati sotto il profilo (AppData e simili) sono anche un altro percorso dal nuovo account. Prima di cambiare account, pianificate la procedura per ricreare i dati protetti da DPAPI (reinserire chiavi API e simili) e migrare i file sotto il profilo.

Se voglio solo che il servizio acceda a una cartella condivisa, serve un utente di dominio?

In molti casi no. In un ambiente di dominio un servizio che gira come LocalSystem, NetworkService o account virtuale si autentica verso il remoto come account computer (DOMAIN\nome-computer$). Aggiungete quel PC$ alle autorizzazioni di condivisione e NTFS della cartella condivisa e può leggere e scrivere. Se volete un controllo di accesso con un'identità propria del servizio, o la stessa identità su più server, considerate un gMSA invece di un utente di dominio.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.