Mappatura debole dei certificati in AD CS

Cos'è la mappatura debole dei certificati?

La mappatura debole dei certificati è un rischio di autenticazione basata su certificati in Active Directory, in cui un certificato può essere associato a un account tramite dati di nome riutilizzabili invece che tramite un binding forte e non riutilizzabile all'account. In termini AD CS concreti, il problema si presenta quando il logon Kerberos con certificato o l'autenticazione con certificato client Schannel accetta mappature basate su nomi come UPN, nome DNS, indirizzo e-mail, nome soggetto, o emittente e nome soggetto combinati.

Il rischio non è che i certificati siano intrinsecamente insicuri. L'autenticazione basata su certificati è una funzionalità di identità legittima di Windows. Il rischio è che le mappature basate su nomi possano essere ambigue o riutilizzabili, specialmente quando certificati, nomi account, UPN, nomi alternativi del soggetto o mappature legacy non legano in modo univoco il certificato all'account previsto. Microsoft ha affrontato questa classe di problemi attraverso modifiche all'autenticazione basata su certificati sui domain controller Windows, inclusa l'applicazione della mappatura forte dei certificati ed eventi di audit per i certificati non compatibili con la modalità Full Enforcement.

Questo articolo si concentra sul comportamento di mappatura dei certificati documentato da Microsoft: la forza della mappatura KDC Kerberos, altSecurityIdentities, StrongCertificateBindingEnforcement, i CertificateMappingMethods di Schannel, e gli eventi operativi che rivelano mappature deboli o fallite. Non tratta ogni problema AD CS come lo stesso problema. Le configurazioni errate dei template, come la registrazione SAN arbitraria, sono correlate, ma la mappatura debole dei certificati riguarda specificamente il modo in cui il certificato viene legato a un account durante l'autenticazione.

Per la superficie di attacco AD CS più ampia, vedere Attacchi ai certificati ADCS: come ESC1-ESC8 portano a Domain Admin. Per un percorso di autenticazione basato su chiavi correlato ma distinto, vedere Shadow Credentials: abuso di msDS-KeyCredentialLink in Active Directory.

Come funziona la mappatura dei certificati

Logon Kerberos con certificato

Nell'autenticazione Kerberos basata su certificato, il Key Distribution Center (KDC) riceve una richiesta di autenticazione basata su certificato e deve determinare quale account rappresenta il certificato. La documentazione Microsoft PKCA definisce la forza della mappatura dei certificati e classifica i metodi di mappatura come deboli o forti. Le mappature deboli dipendono da dati di nome. Le mappature forti dipendono da identificatori più difficili da riutilizzare o direttamente legati all'account.

Microsoft elenca mappature KDC deboli come SAN UPNName, SAN DNSName, altSecurityIdentities emittente e soggetto, altSecurityIdentities solo soggetto, e il campo 822 di altSecurityIdentities. Microsoft elenca mappature forti come il SID, Key Trust, altSecurityIdentities emittente e numero di serie, identificatore chiave soggetto, hash SHA1 della chiave pubblica, ed emittente e SID. La differenza operativa è diretta: se il KDC mappa un certificato tramite un metodo debole, dovrebbe continuare a cercare una mappatura più forte e può far fallire la richiesta di autenticazione se non ne trova una.

Questa distinzione spiega perché il binding forte conta. Un certificato che contiene un nome riutilizzabile non è forte quanto un certificato che porta un'estensione SID o che è mappato esplicitamente tramite emittente e numero di serie, SKI, o hash SHA1 della chiave pubblica. Il compito del difensore è rimuovere le mappature deboli evitabili e assicurarsi che l'autenticazione basata su certificato riesca solo tramite mappature forti.

Mappatura del certificato client Schannel

Kerberos non è l'unico componente Windows che mappa certificati agli account. Microsoft documenta che Schannel può mappare un certificato client fornito a un'applicazione server a un account utente Windows. Il valore di registro CertificateMappingMethods controlla quali metodi di mappatura Schannel può usare. Microsoft afferma che le mappature di certificato Subject/Issuer, Issuer, e UPN sono deboli e disabilitate per impostazione predefinita nel comportamento aggiornato, mentre S4U2Self e S4U2Self esplicito sono forti.

Questo conta perché l'autenticazione basata su certificato può presentarsi in più di un punto: logon con smart card, PKINIT, autenticazione TLS client, applicazioni web legacy, portali VPN, flussi NPS/RADIUS, e servizi amministrativi interni. Un dominio può avere un KDC irrobustito mentre un percorso applicativo dipende ancora da una mappatura Schannel debole. Trattate Kerberos e Schannel come superfici di controllo correlate ma distinte.

Il ruolo dei template AD CS

I template di certificato AD CS influenzano quali certificati possono essere emessi e quali dati di identità contengono. La documentazione Microsoft Defender for Identity descrive template di certificato rischiosi in cui gli utenti possono richiedere certificati validi per utenti arbitrari in base alle impostazioni del template. Indica specificamente l'opzione Supply in the request, gli EKU di autenticazione come Client Authentication o Smartcard Logon, permessi di iscrizione troppo permissivi, mancanza di approvazione del manager, e template pubblicati da una CA.

L'abuso dei template e la mappatura debole non sono identici. Un problema di template controlla se un utente può ottenere un certificato con affermazioni di identità pericolose. Un problema di mappatura controlla se il dominio o l'applicazione accetta quel certificato come un account specifico. Negli ambienti reali, i due problemi spesso si combinano: un template consente a un utente non privilegiato di richiedere un certificato con dati di identità controllati dall'attaccante, e una mappatura debole fa sì che quei dati si risolvano in un account privilegiato.

Perché la mappatura debole conta ancora dopo le modifiche di applicazione di Microsoft

Il KB5014754 di Microsoft documenta le modifiche all'autenticazione basata su certificati per i domain controller Windows. Le modifiche affrontano vulnerabilità di elevazione dei privilegi che possono verificarsi quando il KDC Kerberos serve richieste di autenticazione basate su certificato. Microsoft spiega che, prima dell'aggiornamento di sicurezza del 10 maggio 2022, l'autenticazione basata su certificato non teneva conto di un simbolo di dollaro alla fine di un nome macchina, e che conflitti tra UPN e sAMAccountName introducevano vulnerabilità di spoofing.

Le date operative importanti sono già passate. Microsoft ha documentato che i domain controller sono passati alla modalità Full Enforcement con l'aggiornamento di sicurezza Windows di febbraio 2025, a meno che gli amministratori non avessero già configurato la chiave di registro StrongCertificateBindingEnforcement. Microsoft ha anche documentato che, dopo l'aggiornamento di sicurezza Windows del 9 settembre 2025, quella chiave di registro non sarebbe più stata supportata. In modalità Full Enforcement, se un certificato non può essere mappato fortemente, l'autenticazione viene negata.

Questo non rende il tema obsoleto. Cambia ciò che i difensori devono controllare. In un ambiente aggiornato, le dipendenze da mappatura debole diventano interruzioni operative, debito di sicurezza, o un segnale che qualcuno ha mantenuto impostazioni di compatibilità che dovrebbero essere rimosse. In ambienti meno omogenei, livelli di patch misti dei domain controller, uso legacy di certificati client, applicazioni basate su Schannel, distribuzioni CA non Microsoft, e mappature manuali di altSecurityIdentities possono ancora creare un'esposizione reale.

Un audit maturo dovrebbe rispondere a tre domande:

Tutti i domain controller e i server AD CS sono aggiornati con gli aggiornamenti di sicurezza Microsoft pertinenti?
I logon con certificato riescono tramite mappature forti anziché mappature deboli basate sui nomi?
Applicazioni o domain controller dipendono ancora da comportamenti di compatibilità, metodi Schannel deboli, o mappature manuali legacy?

La catena di attacco

Un modello difensivo sicuro di catena di attacco è il seguente:

Fase	Cosa succede	Cosa devono verificare i difensori
1. Opportunità di emissione del certificato	Un template, un'impostazione CA, o un percorso di iscrizione consente a un utente di ottenere un certificato con dati di identità che possono influenzare l'autenticazione.	Rivedere gli EKU di autenticazione, `Supply in the request`, i permessi di iscrizione, l'approvazione del manager, le firme autorizzate, e se il template è pubblicato.
2. Mappatura debole dell'account	Il certificato viene mappato a un account tramite dati di nome riutilizzabili o una mappatura legacy `altSecurityIdentities` invece di un binding forte all'account.	Inventariare i metodi di mappatura debole, le mappature manuali, le impostazioni Schannel, e gli eventi di audit del KDC.
3. Autenticazione basata su certificato	Il certificato viene presentato per PKINIT Kerberos, logon con smart card, o un percorso di autenticazione client Schannel.	Correlare gli eventi KDC, il comportamento Schannel, l'emissione della CA, e la sensibilità dell'account target.
4. Impatto sui privilegi	L'account mappato è privilegiato, ha diritti di movimento laterale, o può raggiungere servizi sensibili.	Rivedere gli account privilegiati, l'accesso ai servizi, e l'uso a valle dopo l'autenticazione con certificato.
5. Rischio di persistenza o replay	Il certificato rimane valido fino alla scadenza o alla revoca, anche in caso di reset della password.	Revocare i certificati dove appropriato, rimuovere le mappature deboli, e verificare il binding forte dopo la pulizia.

L'articolo evita intenzionalmente la sintassi degli strumenti offensivi. Il fallimento tecnico è chiaro senza un percorso di exploitation pronto da copiare e incollare: un certificato viene emesso o accettato con dati di identità che non dovrebbero bastare a rappresentare l'account target.

Questo percorso si colloca accanto ad altri percorsi di escalation di Active Directory. Per i percorsi basati sui permessi degli oggetti, vedere Abuso di ACL e DCSync: i percorsi silenziosi verso Domain Admin. Per la persistenza Kerberos che non dipende dai certificati, confrontare Attacco Golden Ticket: le chiavi del vostro regno e Attacco Silver Ticket: ticket di servizio Kerberos falsificati in Active Directory.

Rilevamento

Il rilevamento della mappatura debole dei certificati è un problema di correlazione. Un singolo evento può mostrare una mappatura di certificato debole o fallita, ma da solo non spiega come è stato emesso il certificato, se l'account è privilegiato, o se un percorso applicativo legacy dipende ancora da un comportamento debole.

Segnale	Fonte	Cosa cercare	Limitazione
Eventi di mappatura debole o fallita del KDC	Registro di sistema del domain controller dopo gli aggiornamenti pertinenti	Eventi documentati da KB5014754 per certificati privi di mappatura forte o che non soddisfano i criteri Full Enforcement.	Richiede domain controller aggiornati e tentativi di autenticazione con certificato pertinenti.
Emissione di certificati a identità sensibili	Log di sicurezza della CA AD CS	Certificati emessi con EKU di autenticazione, identità del richiedente, nome del template, dati SAN o soggetto se registrati.	La registrazione della CA deve essere abilitata e conservata; l'emissione da sola non prova un'autenticazione riuscita.
Valori deboli di `altSecurityIdentities`	Inventario di Active Directory	Mappature manuali basate su nomi come emittente/soggetto, solo soggetto, o mappature tipo RFC822/e-mail.	La mappatura manuale può essere logica di business legacy; validare prima della rimozione.
Configurazione di mappatura debole Schannel	Registro del domain controller e comportamento dell'applicazione	Valori `CertificateMappingMethods` che riattivano metodi di mappatura deboli.	I fallimenti Schannel possono interessare le applicazioni; testare prima di modificare le impostazioni di produzione.
Rischio del template	Revisione del template AD CS o valutazione Defender for Identity	`Supply in the request`, EKU di autenticazione, permessi di iscrizione ampi, mancanza di approvazione, template pubblicati.	Il rischio del template e il rischio di mappatura sono correlati ma non identici.

Eventi KDC e segnali Full Enforcement

Il KB5014754 di Microsoft ha aggiunto eventi di audit per identificare i certificati non compatibili con la modalità Full Enforcement. Documenta anche che, in modalità Full Enforcement, l'autenticazione viene negata se un certificato non può essere mappato fortemente. I domain controller che registrano questi eventi vi stanno dicendo che un tentativo di autenticazione con certificato è incompatibile con il binding forte, oppure che esiste ancora una mappatura di certificato legacy in un percorso che dovete comprendere.

Non trattate questi eventi come rumore. Un avviso di mappatura debole può essere un problema di compatibilità aziendale, un'attività di migrazione, o un'indagine di sicurezza. Date priorità agli eventi che coinvolgono utenti privilegiati, account di servizio, domain controller, workstation amministrative, servizi VPN/NPS, e certificati emessi da template che consentono l'autenticazione.

Telemetria di emissione e template AD CS

La telemetria di emissione AD CS risponde a una domanda diversa: da dove proviene il certificato? Rivedete i log della CA per certificati emessi, richieste negate, nomi dei template, account richiedenti, e proprietà del certificato. Quando l'audit dei servizi di certificazione è abilitato, eventi come 4886, 4887, 4888, 4870, 4871, 4872, 4891, 4892, e 4898 forniscono telemetria concreta su richiesta, emissione, negazione, revoca, pubblicazione CRL, modifica di configurazione, e caricamento del template. Abbinate questo alla configurazione del template: EKU di autenticazione, soggetto o SAN fornito dal richiedente, permessi di iscrizione, requisiti di approvazione, firme autorizzate, e se il template è pubblicato su una CA.

Le valutazioni della postura di sicurezza di Microsoft Defender for Identity possono aiutare a identificare template che consentono agli utenti di richiedere certificati validi per utenti arbitrari, e template esposti tramite le condizioni CVE-2024-49019. Defender for Identity raccomanda specificamente di rimuovere i permessi di iscrizione non privilegiati, disabilitare Supply in the request, applicare le patch pertinenti per i server AD CS vulnerabili, e usare mitigazioni come l'approvazione del manager o i requisiti di firma dove appropriato.

Inventario delle mappature manuali

Inventariate altSecurityIdentities su utenti, account privilegiati, e account di servizio. Microsoft documenta diversi valori supportati e classifica le mappature in base alla loro forza. Quelle deboli sono basate sui nomi. Quelle forti usano emittente e numero di serie, SKI, hash SHA1 della chiave pubblica, mappatura correlata al SID, o Key Trust.

Fate attenzione durante la pulizia. Una mappatura debole su un utente legacy a basso rischio può essere una dipendenza operativa, mentre una mappatura debole su un account privilegiato è un riscontro a rischio molto più alto. Il piano di remediation dovrebbe sostituire le mappature deboli con mappature forti, non semplicemente eliminare i percorsi di autenticazione di produzione senza migrazione.

Per una copertura dei log più ampia sull'attività del domain controller e degli oggetti AD, abbinate questo articolo a Monitoraggio Active Directory: gli ID evento di sicurezza che contano.

Remediation

La remediation deve affrontare sia l'emissione dei certificati che la mappatura dei certificati. Correggere solo un lato lascia delle lacune. Un piano sicuro rimuove le mappature deboli non necessarie, aggiorna le pratiche di emissione dei certificati, valida l'applicazione a livello di domain controller, e testa i percorsi applicativi che dipendono dai certificati client.

Applicare il binding forte dei certificati

Iniziate dai domain controller. Assicuratevi che tutti i domain controller che servono l'autenticazione con certificato siano aggiornati con gli aggiornamenti Microsoft pertinenti. Negli ambienti moderni aggiornati, Full Enforcement è lo stato atteso. Se un domain controller ha ancora una configurazione di compatibilità o un percorso di eccezione, documentate perché esiste, quali certificati ne dipendono, e il piano esatto di ritiro.

⚠️

⚠️ Attenzione: le linee guida Microsoft sono chiare: la modalità Full Enforcement nega l'autenticazione quando un certificato non soddisfa i criteri di mappatura forte. Microsoft afferma anche che i metodi Schannel deboli sono disabilitati per impostazione predefinita nel comportamento aggiornato, e che riportare CertificateMappingMethods al valore ampio precedente riattiva metodi di mappatura di certificati deboli. Trattate questa modifica del registro come un'eccezione di compatibilità, non come uno stato di irrobustimento normale.

Sostituire le mappature deboli

Per le mappature manuali in altSecurityIdentities, sostituite le mappature deboli con mappature forti quando l'attività ha ancora bisogno di una mappatura esplicita. Microsoft raccomanda mappature forti come emittente e numero di serie quando i certificati non possono essere riemessi con la nuova estensione SID. Altre opzioni di mappatura forte includono SKI e l'hash SHA1 della chiave pubblica secondo la documentazione Microsoft sulla forza della mappatura.

Non lasciate account privilegiati mappati tramite nomi riutilizzabili. Amministratori di dominio, amministratori di certificati, agenti di iscrizione, account di servizio, identità di emergenza (break-glass), e utenti di workstation amministrative non dovrebbero dipendere da un binding di identità debole. Se esiste un flusso di certificati privilegiato, dovrebbe usare una mappatura forte, un'emissione documentata, durate di vita del certificato brevi dove appropriato, e un monitoraggio esplicito.

Correggere i template dei certificati e le impostazioni CA

Rivedete i template che possono emettere certificati capaci di autenticazione. Le raccomandazioni di Microsoft Defender for Identity evidenziano diverse mitigazioni concrete per i template che consentono richieste di certificato per utenti arbitrari: disabilitare Supply in the request, rimuovere gli EKU che consentono l'autenticazione utente quando non necessaria, rimuovere permessi di iscrizione troppo permissivi, richiedere l'approvazione del manager, richiedere firme autorizzate, o de-pubblicare i template dalle CA se non necessari.

Rivedete anche le impostazioni a livello CA come EDITF_ATTRIBUTESUBJECTALTNAME2. Microsoft Defender for Identity indica che, se questo flag è abilitato e un template è valido per l'autenticazione, un attaccante può iscrivere un certificato in grado di impersonare account arbitrari. Questo non è lo stesso di una mappatura debole, ma influisce direttamente sul fatto che affermazioni di identità pericolose possano apparire nei certificati emessi.

Testare le dipendenze Schannel e applicative

Prima di modificare le impostazioni di mappatura Schannel, identificate le applicazioni che usano l'autenticazione con certificato client: applicazioni IIS, VPN, NPS/RADIUS, portali di amministrazione interni, flussi di autenticazione dei dispositivi, e middleware legacy. Testatele con percorsi di mappatura forte. Se un servizio si interrompe solo quando la mappatura debole viene disabilitata, la correzione non è preservare indefinitamente la mappatura debole. La correzione è aggiornare l'emissione dei certificati e la mappatura degli account in modo che il servizio si autentichi tramite un binding forte.

Revocare e riemettere dove necessario

Se sono stati emessi o mappati debolmente certificati sospetti, revocate i certificati interessati, pubblicate CRL aggiornate dove appropriato, e validate che i sistemi dipendenti verifichino la revoca. Riemettete certificati con supporto per la mappatura forte o con mappatura manuale forte esplicita. Se l'account è stato usato dopo l'autenticazione con certificato, trattate l'indagine come una compromissione dell'identità: rivedete le modifiche ai gruppi, l'accesso ai servizi, il movimento laterale, e le azioni amministrative a valle.

Validazione dopo l'irrobustimento

La validazione deve dimostrare che l'autenticazione continua a funzionare per gli utenti legittimi e fallisce per i certificati con binding debole.

Passo di validazione	Criterio di successo
Revisione delle patch dei domain controller	Tutti i domain controller che servono l'autenticazione con certificato sono aggiornati e operano nello stato di applicazione atteso.
Revisione degli eventi KDC	Non rimangono avvisi ricorrenti di mappatura debole per i flussi di autenticazione legittimi dopo la migrazione.
Test di mappatura forte	I logon con certificato utente e macchina riescono tramite estensione SID, Key Trust, o mappature forti esplicite.
Test di mappatura debole	I certificati che si mappano solo tramite metodi deboli basati sui nomi falliscono nelle condizioni di applicazione.
Revisione dei template	I template capaci di autenticazione non consentono affermazioni di identità arbitrarie senza controlli compensativi.
Revisione Schannel	Le applicazioni che usano certificati client non dipendono da metodi di mappatura deboli Subject/Issuer, Issuer, o UPN.
Validazione degli incidenti	I certificati revocati o sostituiti non si autenticano più, e l'attività dell'account a valle è stata rivista.

Eseguite la validazione a fasi. Iniziate con una OU di test o un gruppo di servizio rappresentativo, poi estendete a utenti privilegiati, workstation amministrative, VPN/NPS, utenti di smart card, account di servizio, e scenari di certificato macchina. Non presumete che il superamento di un test con smart card validi ogni percorso di autenticazione con certificato nel dominio.

Come EtcSec rileva questa esposizione

EtcSec dovrebbe trattare la mappatura debole dei certificati come un'esposizione di binding dell'identità del certificato, non solo come un problema di template AD CS. I segnali correlati includono mappature altSecurityIdentities deboli o legacy, template di certificato che emettono certificati capaci di autenticazione con controllo pericoloso del soggetto, permessi di iscrizione troppo ampi, impostazioni CA che consentono SAN forniti dalla richiesta, e impostazioni di compatibilità del domain controller che preservano un comportamento di mappatura debole.

La piattaforma può anche collegare questa esposizione a percorsi di attacco adiacenti: template AD CS che consentono identità arbitrarie, principal che possono modificare le ACL dei template di certificato, utenti privilegiati che dipendono da mappature di certificato deboli, e monitoraggio mancante del domain controller per gli eventi di autenticazione con certificato. Questa è la vista operativa utile. Una mappatura debole è pericolosa perché si trova tra l'emissione del certificato e l'autenticazione dell'account.

Controlli correlati

Controllo	Perché conta
Full Enforcement per l'autenticazione con certificato	Nega l'autenticazione quando il certificato non può essere mappato fortemente.
Percorsi di binding forte dei certificati	Sostituisce le mappature basate su nomi riutilizzabili con mappature manuali forti `altSecurityIdentities` come emittente/numero di serie, SKI, o hash SHA1 della chiave pubblica, o con altri percorsi forti come estensione SID, Key Trust, o emittente/SID.
Irrobustimento dei template AD CS	Impedisce agli utenti non fidati di ottenere certificati capaci di autenticazione per identità arbitrarie.
Revisione della mappatura Schannel	Trova i percorsi applicativi che dipendono ancora da una mappatura di certificato debole.
Monitoraggio dell'emissione della CA	Mostra quali certificati sono stati emessi, a chi, da quale template, e con quali dati di identità.
Revisione dei certificati degli account privilegiati	Assicura che amministratori e account di servizio sensibili non dipendano da un binding di identità debole.
Validazione della revoca	Conferma che i certificati sospetti o sostituiti non si autenticano più.

La mappatura debole dei certificati non è una casella isolata da spuntare. Fa parte della sicurezza AD CS, dell'autenticazione Kerberos, del ciclo di vita degli account, e dell'autenticazione applicativa. Se state costruendo una revisione completa, abbinate questo articolo a Come auditare la sicurezza di Active Directory: checklist pratica per i team interni e Attacchi di delega Kerberos: dalla delega non vincolata all'abuso RBCD per comprendere percorsi di identità adiacenti.

Mappatura debole dei certificati in AD CS: perché conta il binding forte