Progetto pilota di primo deployment gMSA: verificare KDS

Un oggetto gMSA non è un servizio migrato

Un progetto pilota di primo deployment gMSA deve concludersi con un servizio funzionante sotto la nuova identità, una decisione di ripristino approvata e prove raccolte dagli host che lo eseguono effettivamente. Creare un account di servizio gestito di gruppo in Active Directory crea un account. Non dimostra che un carico di lavoro di produzione utilizzi tale account, che ogni host necessario possa recuperarne le credenziali o che il carico di lavoro mantenga gli accessi corretti dopo il passaggio.

Questa distinzione conta quando un audit segnala che i gMSA non sono in uso. Considerate il risultato come un invito a esaminare l'inventario della directory e l'insieme dei servizi. Un nuovo oggetto può far scomparire un segnale di inventario mentre tutti i servizi continuano a funzionare con l'identità precedente. Viceversa, una raccolta incompleta può non rilevare un oggetto esistente. Nessuno dei due risultati risponde alla domanda operativa: quale servizio è stato migrato con successo?

Tenete separati tre registri: oggetti della directory, preparazione degli host e adozione da parte dei servizi. Il primo identifica gli account; il secondo registra se un determinato host può utilizzare l'account selezionato; il terzo documenta un carico di lavoro verificato che lo utilizza. Questo articolo propone un controllo preliminare alla prima adozione, con un solo servizio e un piano di ripristino esplicito. Non presume che tutti gli utenti con SPN rappresentino servizi compatibili e attivi.

Come funziona un progetto pilota di primo deployment gMSA

Partite da un responsabile del servizio e da un inventario del carico di lavoro, anziché da una richiesta di creazione di account. Registrate il nome del servizio, l'identità attuale, l'elenco degli host, la versione dell'applicazione, la configurazione di avvio, i client e le risorse utilizzate a valle. Chiedete al responsabile quali funzioni devono restare disponibili e quali prove dimostrerebbero che la modifica ha funzionato. Un processo che si avvia ma non riesce a scrivere il proprio output pianificato ha fallito il progetto pilota.

Microsoft documenta il supporto gMSA per i servizi configurati tramite Service Control Manager, i pool di applicazioni IIS, l'Utilità di pianificazione e i prodotti che supportano le API degli account gestiti. Il servizio Cluster stesso non supporta i gMSA; i servizi compatibili eseguiti al di sopra possono utilizzarli. Confermate il prodotto esatto e la topologia di deployment con il relativo responsabile prima di scegliere il progetto pilota. Microsoft Learn — Gestire gli account di servizio gestiti di gruppo.

Organizzate il registro della modifica intorno a questi controlli indipendenti:

Sono controlli proposti per il progetto pilota, non risultati già misurati nel vostro ambiente. Assegnate un responsabile a ogni controllo. Il responsabile AD gestisce la dipendenza della foresta; il responsabile del servizio accetta il comportamento del carico di lavoro; chi approva la modifica autorizza il passaggio e il ripristino. Registrate chi può interrompere il progetto pilota quando queste valutazioni divergono.

Rilevamento: esaminare gli oggetti, la preparazione KDS e ogni host

Riconciliare un inventario della directory basato sulla classe

Utilizzate una ricerca indipendente per classe per verificare il significato dell'inventario del collector. L'esempio seguente è di sola lettura e combina i parametri documentati di Get-ADServiceAccount. Sostituite il DC e il DN di dominio illustrativi con l'ambito approvato; ripetete per ogni dominio incluso nel progetto pilota. Non è stato eseguito sulla vostra directory.

Get-ADServiceAccount -LDAPFilter '(objectClass=msDS-GroupManagedServiceAccount)' -SearchBase 'DC=example,DC=com' -SearchScope Subtree -Server 'dc01.example.com' -ResultSetSize $null

-LDAPFilter seleziona la classe strutturale indipendentemente dall'euristica del collector basata sull'attributo di appartenenza. -SearchBase, -SearchScope e -Server rendono esplicito il confine previsto; -ResultSetSize $null evita di imporre un limite al numero totale di risultati. Nell'uso più generale, il cmdlet restituisce sia account gestiti autonomi sia account gestiti di gruppo, quindi conservate la restrizione di classe per questo inventario. Microsoft Learn — Get-ADServiceAccount.

Registrate le identità restituite e il relativo stato di abilitazione, insieme all'ambito e all'esito della query. Se la ricerca trova un gMSA che il collector non ha riconosciuto, esaminate le autorizzazioni, gli attributi richiesti, i confini della ricerca e i limiti dei risultati. Non risolvete la discrepanza creando un altro account. Se la ricerca fallisce, conservate l'errore come un problema di raccolta; una query riuscita senza risultati e una query non riuscita costituiscono prove diverse.

Associate poi ogni oggetto pertinente alle configurazioni reali dei servizi. Stabilite se è inutilizzato, in preparazione, dismesso o utilizzato da un carico di lavoro verificato. Mantenete come non associato un oggetto privo di corrispondenza. Il solo nome di un account della directory non permette di identificare un responsabile del servizio né di dimostrare che un host lo utilizzi.

Esaminare le chiavi KDS esistenti prima di richiederne una nuova

Da un contesto amministrativo autorizzato con il modulo KDS, utilizzate il comando di lettura documentato:

Get-KdsRootKey

Recupera l'elenco delle chiavi radice esistenti, inclusi i loro valori. Esaminatelo nell'ambiente amministrativo e conservate nel registro della modifica solo gli identificativi necessari e la decisione sulla preparazione; non incollate materiale grezzo delle chiavi in un ticket generico. Questo comando è un passaggio di inventario, non un test di replica. Microsoft Learn — Get-KdsRootKey.

Microsoft descrive un'attesa fino a dieci ore dopo la creazione della chiave radice, affinché la replica dei DC possa convergere prima dell'uso del gMSA. Pianificazioni di replica limitate o problemi di replica possono comunque causare errori di recupero. Chiedete al responsabile AD di verificare la disponibilità della chiave e lo stato della replica per i DC che servono gli host del progetto pilota; il solo tempo trascorso non costituisce tale prova. Microsoft Learn — Creare una chiave radice KDS.

Se esiste già una chiave adatta, la procedura di gestione indica di saltarne la creazione. Se non esiste, rendete il processo documentato del responsabile AD per la creazione della chiave e la replica un prerequisito, con tempi e autorizzazioni propri. Non incorporate una dipendenza della foresta in una modifica dell'account di servizio non esaminata.

Verificare la preparazione sugli host effettivamente autorizzati

Esaminate le entità approvate per recuperare la password e confermate che corrispondano all'insieme di host previsto. Le indicazioni di gestione Microsoft richiedono inoltre SPN appropriati, DNS, accesso alla rete, sincronizzazione degli orologi e tipi di crittografia Kerberos supportati. Considerateli prerequisiti da esaminare, senza presumere che una ricerca riuscita nella directory li verifichi.

Eseguite localmente il test dell'account documentato su ogni host previsto, sostituendo il nome dell'account illustrativo:

Test-ADServiceAccount -Identity 'svc-pilot'

Microsoft definisce un test riuscito come la preparazione ad autenticarsi e ad accedere al dominio con le credenziali attuali dell'account. Registrate host, ora, account e risultato effettivo. Il test non esercita le query del database dell'applicazione, le scritture di file, l'autenticazione dei client o il comportamento al riavvio. Microsoft Learn — Test-ADServiceAccount.

Un errore sospende il passaggio. Esaminate con i responsabili competenti l'autorizzazione prevista dell'host, l'accesso alla directory e la dipendenza KDS/replica. Estendere l'accesso al recupero a un gruppo ampio non è una scorciatoia accettabile. La revisione delle autorizzazioni per il recupero delle password gMSA spiega perché l'insieme dei lettori è un confine di sicurezza da esaminare separatamente.

Correzione: provare un servizio con un ripristino utilizzabile (Remediation)

1. Concordare i test di accettazione e il percorso di ripristino

Scegliete un carico di lavoro compatibile il cui responsabile possa osservare sia il normale funzionamento sia gli errori. Prima di cambiarne l'identità, conservate la configurazione approvata, le autorizzazioni esistenti, il comportamento all'avvio e i risultati di riferimento del carico di lavoro. Annotate la finestra di manutenzione, la persona che approva la modifica, quella che esegue il ripristino e le condizioni che lo attivano.

Definite condizioni specifiche per il servizio: un client necessario non riesce ad autenticarsi, un'operazione pianificata fallisce, una risorsa attesa non è accessibile o un riavvio non ripristina il servizio. Definite il periodo di osservazione con il responsabile anziché inventare una durata universale. Per un carico di lavoro che viene eseguito solo a un orario pianificato, la decisione di accettazione deve coprire quell'esecuzione.

2. Preparare l'host autorizzato e le autorizzazioni dell'account

Esaminate i diritti di servizio locali del candidato e le autorizzazioni a valle prima della modifica. Richiedete le autorizzazioni necessarie alle operazioni previste del carico di lavoro; conservate le dipendenze dell'identità precedente durante la finestra di ripristino. Tenete separata l'autorizzazione a recuperare la password da quella ad accedere ai dati dell'applicazione. Superare il test dell'account non dimostra né la completezza delle autorizzazioni dell'applicazione né la correttezza della sua configurazione.

Dopo il superamento dei controlli sulla directory e sulle autorizzazioni, la procedura Microsoft installa l'account su ogni host dove viene eseguito il servizio. Eseguite localmente in una sessione PowerShell con privilegi elevati, nell'ambito della modifica approvata:

Install-ADServiceAccount -Identity 'svc-pilot'

Il cmdlet prepara l'account gestito esistente sul computer locale. Non cambia l'identità configurata dell'applicazione. Il relativo riferimento richiede che l'autorizzazione al recupero sia impostata per un gMSA. Microsoft Learn — Install-ADServiceAccount.

Ripetete il test di preparazione dell'account su quell'host e conservate l'esito. Se l'installazione o il test fallisce, fermatevi a questo controllo ed esaminate la causa. Non registrate il completamento di un comando amministrativo come una migrazione del servizio riuscita.

3. Effettuare il passaggio tramite la configurazione supportata dal servizio

Utilizzate la procedura di configurazione dell'identità supportata dal prodotto per migrare il servizio selezionato. Un comando generico non può descrivere in modo sicuro ogni servizio Windows, pool di applicazioni, attività e applicazione. Conservate tale procedura specifica del prodotto e i passaggi inversi nel registro della modifica approvato.

Verificate l'identità configurata, quindi avviate o riavviate il carico di lavoro come concordato. Fate eseguire al responsabile operazioni rappresentative dei client e letture o scritture a valle. Confrontate i risultati con quelli di riferimento ed esaminate gli errori effettivi dell'applicazione. Quando l'autenticazione è rilevante, confermate il comportamento atteso dell'autenticazione dei client e delle risorse attraverso gli strumenti diagnostici consolidati dell'organizzazione. Un singolo risultato di avvio non sostituisce questi test.

Se i criteri di accettazione non sono soddisfatti, seguite quei passaggi e documentate sia l'errore che ha attivato il ripristino sia il comportamento del servizio ripristinato. Conservate le prove per l'indagine. Lasciare un oggetto account in AD durante il ripristino del carico di lavoro non significa che il progetto pilota sia riuscito.

4. Chiudere il progetto pilota e seguire il resto dell'ambiente

Dopo l'accettazione, registrate servizio, host, nuova identità, test, timestamp, approvatore e limitazioni irrisolte. Esaminate tutti gli utilizzatori rimanenti dell'identità precedente prima di dismetterla. Rimuovete tale identità solo dopo la convalida e il periodo di ripristino approvato; la scomparsa del suo nome da una configurazione di servizio non dimostra che nessun altro carico di lavoro ne dipenda.

La correzione degli account di servizio che raccomanda la migrazione a gMSA stabilisce una ragione per migrare. Questo progetto pilota fornisce le prove operative a sostegno di tale raccomandazione. Seguite separatamente i candidati successivi: l'accettazione di un primo servizio è un progresso, mentre l'adozione nell'intero ambiente richiede ancora un inventario e una decisione servizio per servizio.

Come EtcSec rileva questa situazione

Il controllo EtcSec pertinente è GMSA_NOT_IN_USE. Nell'implementazione di etc-collector esaminata, conta gli utenti riconosciuti come gMSA e gli utenti abilitati con almeno un SPN. Restituisce un rilievo di gravità Low con Count = 1 solo quando il numero di gMSA riconosciuti è zero e il numero di utenti abilitati con SPN è positivo. Altrimenti restituisce Count = 0.

Il riconoscimento è più ristretto di un inventario basato sulla classe strutturale: User.IsGMSA viene impostato quando l'attributo binario msDS-GroupMSAMembership non è vuoto. Il filtro utenti LDAP include msDS-GroupManagedServiceAccount, ma il parser non usa quella classe per impostare questo indicatore dell'utente. Un attributo di appartenenza mancante o illeggibile può quindi influire sul riconoscimento; un confine LDAP incompleto o il limite MaxUsers possono influire sull'inventario. Un errore di GetUsers arresta il motore anziché produrre un inventario vuoto riuscito.

Ogni gMSA riconosciuto contribuisce al conteggio, inclusi gli oggetti disabilitati. Basta un oggetto riconosciuto per portare questo segnale a zero, anche se nessun servizio è stato migrato. Il risultato è zero anche quando non sono stati raccolti utenti abilitati con SPN. Questo controllo non esamina le chiavi KDS, la preparazione della replica, l'installazione sugli host, la configurazione dei servizi, la compatibilità delle applicazioni o gli accessi effettivi dei servizi. Non misura né la percentuale di servizi che utilizzano gMSA né il successo del progetto pilota.