Rotazione password con smart card in Active Directory

Rotazione password con smart card in Active Directory

La rotazione password con smart card in Active Directory è importante perché questi account conservano un segreto di password di rete. Senza rinnovo automatico della password, il segreto casuale impostato da Windows può persistere finché non viene modificato esplicitamente. L’affermazione secondo cui «non cambia mai per impostazione predefinita» richiede una precisazione immediata: Microsoft documenta il rinnovo come abilitato per i nuovi domini, mentre i domini esistenti richiedono una configurazione. Consideratelo un rischio nei domini in cui il rinnovo è assente o disabilitato, anziché una proprietà universale del moderno Active Directory. La documentazione Microsoft sulle funzionalità di Windows Server 2016 chiarisce questa distinzione.

L’opzione dell’account e l’impostazione di rotazione del dominio rispondono a domande diverse. La prima determina se l’utente deve usare una smart card per l’accesso interattivo iniziale, incluso Desktop remoto. La seconda controlla la manutenzione del segreto basato su password che rimane rilevante per l’autenticazione di rete. Una verifica che si ferma alla casella dell’account lascia senza risposta la seconda domanda. La documentazione Microsoft sugli account descrive sia la restrizione interattiva sia l’hash NT che rimane.

Per gli amministratori, l’obiettivo utile va quindi oltre il semplice «rendere verde la casella». Stabilite quali identità richiedono la carta, se il loro dominio supporta e abilita il rinnovo e come dimostrare un ripristino riuscito su un account rappresentativo. Questa guida segue tale sequenza: esaminare account e dominio, interpretare i riscontri, quindi sperimentare la correzione con un progetto pilota. I comandi seguenti sono esempi basati sulla documentazione; nessuno è stato eseguito su un dominio per questo articolo.

Il bit è un requisito di autenticazione

L’opzione corrisponde al flag cumulativo di userAccountControl denominato SMARTCARD_REQUIRED, con valore esadecimale 0x40000 e decimale 262144. Altri flag possono coesistere. Leggere l’intero attributo come se dovesse essere uguale a 0x40000 farebbe perdere gli account che hanno opzioni aggiuntive. Il riferimento Microsoft su UserAccountControl elenca il flag e spiega i valori cumulativi.

Windows rende casuale il segreto dell’account quando il requisito viene abilitato. Le indicazioni amministrative di Microsoft descrivono una password casuale inizialmente sconosciuta e avvertono che chi dispone dei diritti di ripristino della password può successivamente impostare un valore noto e usare determinati percorsi di accesso alla rete. Richiedere la carta non elimina l’importanza di queste autorizzazioni di ripristino. Le indicazioni Microsoft sul privilegio minimo esplicitano questa capacità amministrativa residua.

Come funzionano il segreto residuo e il rinnovo

Casuale non significa sostituito regolarmente

Il riferimento Microsoft sugli account indica che, senza il comportamento aggiuntivo di rinnovo, il valore generato rimane fino all’impostazione di una nuova password o alla disabilitazione e successiva riabilitazione del requisito della smart card. Un valore iniziale ad alta entropia contrasta i tentativi di indovinare la password; mantenere lo stesso valore dopo un furto è un problema diverso. Questa distinzione motiva la verifica, senza affermare che ogni account con smart card abbia la password più vecchia del proprio dominio. Il comportamento documentato degli account conferma la persistenza e il meccanismo di sostituzione manuale.

L’autenticazione Windows deve anche supportare l’accesso successivo alle risorse di rete. La documentazione Microsoft sui processi delle credenziali descrive la conservazione dell’hash NT corrispondente nel proprio modello di credenziali dopo l’accesso tramite smart card. Questo spiega perché il segreto è rilevante. Non dimostra che un attaccante possa estrarre un hash da qualsiasi endpoint indipendentemente dalle sue protezioni o dalla sessione effettiva. Tenete separate le domande investigative sull’esistenza di una credenziale, sulla sua esposizione e sul suo furto.

L’impostazione del dominio abilita la scadenza secondo i criteri

L’attributo booleano del dominio msDS-ExpirePasswordsOnSmartCardOnlyAccounts controlla la scadenza delle password degli account che usano solo smart card secondo i criteri delle password. Non è il bit della smart card del singolo utente. La definizione dell’attributo in MS-ADA2 ne specifica lo scopo.

La funzionalità richiede un livello di funzionalità del dominio Windows Server 2016 o superiore. La sola versione del sistema operativo di un controller di dominio non dimostra questo prerequisito, e qui il requisito riguarda il livello del dominio, non un prerequisito inventato a livello di foresta. La pagina Microsoft sulle funzionalità documenta anche l’opzione del Centro di amministrazione di Active Directory per i domini esistenti. La descrizione della funzionalità di rinnovo è il riferimento per questi requisiti di distribuzione.

Il ripristino fa parte dell’elaborazione di un accesso idoneo

Durante l’elaborazione AS-REQ di PKINIT, il KDC richiede il ripristino della password dell’account che usa solo smart card nelle condizioni definite dalla procedura di ripristino MS-PKCA. Il completamento riuscito provoca il riavvio dell’elaborazione della richiesta originale.

Il servizio che risponde applica le regole di scadenza e convalida della specifica normativa di ripristino MS-SAMS. Una password non scaduta restituisce un esito positivo senza sostituzione. Qui, scadenza significa la condizione calcolata dal protocollo, che considera anche le regole sulla durata dei ticket; non è semplicemente la soglia di età del dominio usata dal collettore. Per una password scaduta, la convalida include l’attributo del dominio abilitato, un livello di funzionalità del dominio sufficiente, il bit della smart card e l’assenza di DONT_EXPIRE_PASSWD. Un ripristino riuscito genera nuovi segreti e aggiorna pwdLastSet all’ora corrente.

Si tratta dell’elaborazione di un accesso soggetta a condizioni dei criteri e del protocollo. Non è un timer in background, una sostituzione garantita a ogni accesso o una pianificazione universale a intervalli fissi di giorni. Come inferenza operativa, un account che esegue raramente un accesso idoneo può mantenere una data vecchia anche quando il rinnovo è abilitato. Esaminate i criteri e l’uso effettivo dell’account prima di attribuire una causa alla data.

Misurare separatamente account e dominio

Usate un controller di dominio identificato per nome per ottenere letture confrontabili e sostituite corp.example, dc01.corp.example, il nome distinto del dominio e admin-pilot con i valori reali. Conservate l’identità, l’ora di raccolta e i risultati grezzi nel registro della modifica. Gli esempi sono costruiti a partire da parametri documentati dei cmdlet; non vengono presentati come comandi esatti copiati letteralmente da Learn o come risultati di un audit di un cliente.

Passaggio 1 — Inventariare gli account che hanno il requisito

Get-ADUser documenta -Filter, -Properties e -Server. Il modello a oggetti di Active Directory documenta SmartcardLogonRequired e la proprietà PasswordLastSet derivata da pwdLastSet.

Get-ADUser -Filter {SmartcardLogonRequired -eq $true} -Properties pwdLastSet,PasswordLastSet,PasswordNeverExpires,Enabled,adminCount -Server dc01.corp.example

Leggete lo stato di abilitazione e l’eccezione alla scadenza insieme alle date. Conservate gli account disabilitati nell’inventario se utile, ma distingueteli dalla popolazione abilitata valutata dal rilevatore della rotazione. Una data è una prova sulla manutenzione della password; non data autonomamente il momento in cui è stato abilitato il bit della smart card.

Per ogni account, registrate il proprietario, il flusso di accesso previsto, i criteri applicabili e le eccezioni alla scadenza. Raccogliete separatamente i dettagli del flusso e della titolarità; Get-ADUser non li determina.

Passaggio 2 — Identificare il dominio e il livello di funzionalità

Get-ADDomain accetta un’identità di dominio e un server e restituisce informazioni sul dominio, incluse DomainMode e DistinguishedName.

Get-ADDomain -Identity corp.example -Server dc01.corp.example

Usate l’identità del dominio restituita per confermare che le letture successive riguardino il contesto di denominazione previsto. Registrate il livello di funzionalità separatamente dall’inventario dei sistemi operativi dei controller di dominio. Se il risultato non è ottenibile o identifica il dominio sbagliato, risolvete questo problema di misurazione prima di trarre conclusioni sulla disponibilità della funzionalità.

Passaggio 3 — Leggere l’attributo del dominio e i criteri di età della password

Get-ADObject documenta la lettura di un oggetto per identità con proprietà LDAP aggiuntive. Leggete l’oggetto radice del dominio, anziché un’OU o un singolo utente:

Get-ADObject -Identity 'DC=corp,DC=example' -Properties msDS-ExpirePasswordsOnSmartCardOnlyAccounts,maxPwdAge -Server dc01.corp.example

Conservate il valore grezzo di maxPwdAge insieme all’impostazione del dominio. Il confronto di età del collettore descritto di seguito usa un valore in giorni derivato da quei criteri. Non sostituitelo con un obiettivo arbitrario di età per poi descriverlo come un requisito Microsoft del rinnovo.

Trattate un attributo assente, un valore false e una lettura non riuscita come situazioni investigative distinte. Confermate il controller, l’identità del dominio, le autorizzazioni e la completezza della risposta. Una vista vuota nella console non è una prova sufficiente che una raccolta riuscita abbia restituito false.

Rilevamento: stabilire a quale domanda rispondono le prove

Partite da due popolazioni: gli account abilitati che richiedono la carta e le identità amministrative che non la richiedono. Nella prima, determinate se il rinnovo è abilitato prima di valutare l’età. Nella seconda, confermate le responsabilità amministrative reali prima di decidere dove applicare il requisito. Sono passaggi di verifica derivati dai criteri dei rilevatori, non prove di un’intrusione.

La tabella riassume smartcard-rotation.go:48 e admin-no-smartcard.go:24, esaminati integralmente per questo articolo. La loro implementazione è descritta in «Come EtcSec rileva questa situazione».

Un registro di prove utile separa l’osservazione di configurazione, l’osservazione dell’età dell’account e la causa confermata. Per esempio, una data vecchia con il rinnovo abilitato è un motivo per indagare; non è una prova che l’attributo del dominio debba essere segretamente disabilitato. Evitate di descrivere il nome del rilevatore come la diagnosi di ogni account che restituisce.

Perché la conseguenza dell’attacco rimane condizionale

Se viene effettivamente rubato un segreto NT ancora valido, il suo utilizzo dipende dai protocolli di autenticazione e dai diritti disponibili lungo il percorso verso l’obiettivo. La nostra guida Pass-the-Hash spiega questo riutilizzo condizionale tramite NTLM. Distingue inoltre Overpass-the-Hash, che ottiene materiale di autenticazione Kerberos nelle condizioni pertinenti, da Pass-the-Ticket, che riutilizza un ticket. Non deducete che possedere l’hash NT di un utente fornisca ogni ticket in un dominio basato su AES.

Mantenete preciso l’obiettivo del rafforzamento: ridurre la persistenza di un segreto di password riutilizzabile. Non descrivete un ripristino riuscito della password come una revoca universale dei ticket già emessi, delle sessioni di rete esistenti o dei certificati. Questi richiedono decisioni proprie di risposta agli incidenti.

Correzione: abilitare il rinnovo con un progetto pilota controllato (Remediation)

Passaggio 1 — Stabilire prerequisiti e responsabilità

Prima di modificare il dominio, nominate l’amministratore responsabile, selezionate un account pilota rappresentativo e confermate il livello di funzionalità del dominio. Esaminate i criteri reali delle password del pilota e le sue eccezioni alla scadenza. Organizzate un modo per provare l’accesso con smart card e gli accessi di rete necessari, con una procedura di recupero concordata.

È un piano di modifica consigliato, non un risultato di laboratorio. Serve a far emergere le dipendenze prima di estendere la modifica. Non usate un’operazione di scrittura riuscita come unico criterio di accettazione. Decidete in anticipo quali letture e prove di autenticazione conserverà come evidenza il responsabile della modifica.

Le identità selezionate devono inoltre corrispondere all’uso previsto. Il riferimento Microsoft sugli account indica che gli account con obbligo di smart card non possono essere usati per avviare servizi o eseguire attività pianificate. Esaminate queste dipendenze prima di modificare il requisito di un account. Le indicazioni Microsoft sugli account definiscono questo limite.

Passaggio 2 — Abilitare il rinnovo del dominio

Dopo aver convalidato il livello di funzionalità e pianificato il progetto pilota, adattate l’esempio 6 di Set-ADDomain:

Set-ADDomain -Identity corp.example -PublicKeyRequiredPasswordRolling $true -Server dc01.corp.example

Il parametro documentato imposta msDS-ExpirePasswordsOnSmartCardOnlyAccounts a true. È una modifica del dominio, anche se la convalida inizia con un singolo account. Inventariate le identità coinvolte e i relativi proprietari prima di applicarla.

Ripetete immediatamente la lettura precedente dell’oggetto dominio sul controller scelto. Organizzate quindi un accesso idoneo del pilota e ripetete la lettura dell’utente. Registrate ciò che è realmente accaduto anziché inserire un output atteso nel registro della modifica. Se la data non cambia, esaminate l’idoneità e i criteri prima di ripetere modifiche alla cieca. Questo esempio non promette alcun ritardo di replica né alcun risultato del ripristino.

Passaggio 3 — Usare la sostituzione manuale solo come procedura controllata

Dove il rinnovo automatico non può ancora essere usato, il riferimento Microsoft sugli account documenta la sostituzione disabilitando e riabilitando il requisito. Set-ADUser documenta il parametro booleano -SmartcardLogonRequired. Quelle che seguono sono due azioni separate su un account pilota.

Rimuovete prima il requisito:

Set-ADUser -Identity admin-pilot -SmartcardLogonRequired $false -Server dc01.corp.example

Poi ripristinatelo:

Set-ADUser -Identity admin-pilot -SmartcardLogonRequired $true -Server dc01.corp.example

Leggete di nuovo l’account, verificate che il requisito sia ripristinato, provate il flusso previsto di accesso e rete e confermate lo stato replicato pertinente. Non affermate che questa procedura manuale aggiorni sempre pwdLastSet in modo identico al ripristino automatico normativo. Misurate il risultato.

Se un livello di funzionalità inferiore impedisce il rinnovo automatico, documentate la procedura manuale, le responsabilità e la pianificazione organizzativa. Scegliete tale pianificazione attraverso il vostro processo di gestione del rischio e operativo; non presentate l’intervallo scelto come un requisito Microsoft per questa funzionalità.

Passaggio 4 — Esaminare il reale perimetro amministrativo

Usate la selezione del rilevatore complementare come elenco iniziale. La sintassi seguente usa parametri documentati di Get-ADUser; i criteri di selezione provengono da admin-no-smartcard.go:24.

Get-ADUser -Filter {Enabled -eq $true -and adminCount -eq 1 -and SmartcardLogonRequired -eq $false} -Properties adminCount,userAccountControl -Server dc01.corp.example

Riconciliate questo elenco con le appartenenze attuali ai gruppi, l’amministrazione delegata, le autorità sulle applicazioni e le identità di recupero. Il rilevatore legge un marcatore amministrativo; non calcola ogni forma di privilegio effettivo. Le indicazioni Microsoft sul privilegio minimo discutono i privilegi nei gruppi della directory, nei sistemi membri e nelle applicazioni: per questo la verifica deve estendersi oltre la popolazione della query. Esaminate i privilegi amministrativi e i diritti di ripristino delle password prima di applicare restrizioni agli account.

Convalidare la modifica senza sovrastimare il risultato

Costruite il registro di convalida intorno a osservazioni riproducibili da un revisore: il dominio e il controller interrogati, il livello di funzionalità, l’attributo grezzo del rinnovo, il requisito dell’account, i criteri esaminati e l’esito dell’autenticazione del pilota. Includete le date e le ore e conservate eventuali errori. È un formato di prove consigliato, non l’affermazione che un singolo comando fornisca ogni elemento.

Distinguete «l’impostazione è abilitata» da «il ripristino di un account idoneo è stato completato». Se il pilota non deve ancora scadere, una data invariata può essere coerente con il flusso documentato. Se il ripristino riesce, confrontate la nuova osservazione dell’utente con l’acquisizione precedente. Per gli account usati raramente, decidete come organizzare la convalida futura anziché presumere che una modifica del dominio rinnovi immediatamente ogni segreto.

Infine, eseguite nuovamente la valutazione della configurazione ed esaminate ancora entrambe le popolazioni. Un riscontro residuo merita indagine; un conteggio zero richiede il contesto della raccolta. Mantenete disponibile il piano di recupero amministrativo mentre la modifica viene estesa. La chiusura deve descrivere esattamente cosa è stato verificato e cosa dipende ancora da accessi futuri o da controlli separati.

Come EtcSec rileva questa situazione

SMARTCARD_PASSWORD_ROTATION_DISABLED

L’implementazione in ad/advanced/other/smartcard-rotation.go:48 gestisce prima l’assenza di informazioni sul dominio restituendo un riscontro con Count: 0. Quindi seleziona gli utenti abilitati il cui userAccountControl contiene 0x40000.

Ha due rami effettivi:

• Impostazione del dominio false: viene selezionato ogni utente di quella popolazione abilitata con obbligo di smart card, indipendentemente da PasswordLastSet. Una modifica recente della password non elimina il riscontro di configurazione.
• Impostazione del dominio true: l’età viene valutata solo quando MaxPasswordAge > 0. L’account viene selezionato se PasswordLastSet è zero o strettamente precedente a Now.AddDate(0, 0, -MaxPasswordAge). L’uguaglianza non viene selezionata. Con un’età massima pari a zero, questo ramo non deduce alcun riscontro sull’età.

Questi rami si trovano in smartcard-rotation.go:79–87; la soglia dei criteri è in 62–66. Il controllo non usa una soglia a giorni fissi e non dimostra che un ripristino sia avvenuto durante un accesso specifico.

ADMIN_NO_SMARTCARD

L’implementazione complementare in ad/accounts/advanced/admin-no-smartcard.go:24 seleziona utenti abilitati con AdminCount=true e senza il bit della smart card, mediante le condizioni in 29–41. Non esamina l’età della password né l’attributo del rinnovo del dominio.

I due controlli valutano popolazioni di account diverse. Uno verifica la manutenzione del segreto dietro una smart card obbligatoria; l’altro identifica gli account della propria selezione amministrativa senza quel requisito. Nessuno dei due va presentato come capace di eliminare tutti gli attacchi basati su password.

Cosa non misurano questi riscontri

Nessuno dei due Detect() convalida il livello di funzionalità del dominio, calcola i criteri granulari delle password effettivi di ogni utente, controlla DONT_EXPIRE_PASSWD, dimostra un accesso o un ripristino riuscito o inventaria gli amministratori al di fuori di adminCount. La raccolta LDAP converte un attributo del rinnovo true in un booleano e converte assente o false in false; deriva l’età massima della password da maxPwdAge (providers/ldap/client.go:636,662–669). Questo limite della raccolta è rilevante quando si interpreta il primo ramo.

Un conteggio zero può quindi significare nessun utente selezionato, un confronto di età senza soglia positiva o informazioni sul dominio non disponibili. Non è una prova autonoma di raccolta completa o di rotazione funzionante. Usate i riscontri per orientare le misurazioni di account e dominio sopra descritte e conservate le prove del pilota che dimostrano il comportamento effettivamente verificato.