• Guide, Sicurezza, Sistemi Operativi
• 27 Maggio 2026

Per anni abbiamo raccontato i certificati come una garanzia quasi assoluta. Se il certificato è valido, se la chain è corretta, se la CA è attendibile, allora siamo a posto. Più o meno.

In Active Directory, soprattutto quando entra in gioco l’autenticazione Kerberos basata su certificato, la domanda non è soltanto: “Questo certificato è valido?”.

La domanda vera è un’altra:

“Questo certificato appartiene davvero a questo utente o a questo computer?”

Ed è qui che entra in gioco lo Strong Certificate Mapping.

Il tema sembra piccolo, quasi da addetti ai lavori. In realtà può avere un impatto enorme su ambienti che usano smart card logon, Windows Hello for Business certificate trust, Intune SCEP/PKCS, NPS, EAP-TLS, Wi-Fi enterprise, VPN, certificati utente, certificati dispositivo e integrazioni ibride con Active Directory.

Il problema non è emettere certificati. Il problema è dimostrare al KDC che quel certificato è legato in modo forte all’identità corretta.

Perché Microsoft ha cambiato il comportamento

Nel 2022 Microsoft ha introdotto modifiche importanti all’autenticazione basata su certificato sui Domain Controller Windows, in risposta a vulnerabilità legate allo spoofing dei certificati e all’emulazione di identità.

Il punto centrale è questo: alcuni metodi storici di mapping tra certificato e account Active Directory erano troppo deboli. Se il KDC usa campi come UPN, Subject o indirizzo email per capire a quale account associare un certificato, si affida a informazioni che possono essere ambigue, riutilizzabili, duplicate o manipolabili in alcuni scenari. Questi valori sono comodi. Ma la sicurezza non sempre ama ciò che è comodo.

Microsoft ha quindi rafforzato il comportamento del KDC richiedendo un mapping più affidabile tra certificato e oggetto Active Directory. Oggi, negli ambienti aggiornati, se il certificato non può essere mappato in modo forte all’utente o al computer, l’autenticazione può fallire anche se il certificato è formalmente valido.

Questo è il cambio culturale da capire: non basta più avere un certificato buono, serve un certificato valido e associato in modo robusto all’identità giusta.

Che cos’è lo Strong Certificate Mapping

Strong Certificate Mapping significa associare un certificato a un account Active Directory usando un identificatore considerato non facilmente riutilizzabile o ambiguo. In pratica, il KDC deve poter dire:

“Questo certificato non assomiglia soltanto all’utente. Questo certificato è legato a quell’utente.”

I mapping deboli si basano tipicamente su nomi, subject, UPN o indirizzi email. I mapping forti si basano invece su identificatori più specifici, come il SID dell’account, il seriale del certificato, il Subject Key Identifier o l’hash della public key.

Figura 1 – Domain Controller non configurato

Per abilitare la configurazione è possibile utilizzare il seguente script:

Figura 2 – Configurazione Strong Certificate Mapping

E verificare con il seguente script

Figura 3 – Verifica configurazione

Mapping deboli e mapping forti

Il motivo è semplice: nomi, UPN ed email sono attributi descrittivi. Possono cambiare, essere duplicati, essere riutilizzati o non rappresentare in modo sufficientemente robusto l’identità.

Il SID, invece, identifica l’oggetto Active Directory. Quando il certificato contiene un’informazione legata al SID dell’account, il KDC può validare che il certificato presentato corrisponda davvero all’utente o al computer che sta tentando di autenticarsi.

Dove entra in gioco il SID nel certificato

Il modello più importante, oggi, è quello basato sulla SID extension. Dopo gli aggiornamenti introdotti da Microsoft, le Enterprise CA Microsoft aggiornate possono aggiungere ai certificati emessi tramite template online una nuova estensione non critica con OID:

1.3.6.1.4.1.311.25.2

Questa estensione contiene il SID dell’oggetto Active Directory per cui il certificato è stato emesso.

Quando l’utente o il computer usa quel certificato per autenticarsi contro Active Directory, il KDC controlla che il SID presente nel certificato corrisponda al SID dell’oggetto AD. Se corrisponde, il mapping è forte. Se non corrisponde, l’autenticazione viene bloccata. Se l’estensione non c’è e non esiste un mapping forte alternativo, il certificato può essere rifiutato.

Questa è la parte che crea problemi operativi: molte infrastrutture hanno certificati emessi anni fa, template personalizzati, NDES, SCEP, PKCS, CA di terze parti, appliance NAC, sistemi VPN, Wi-Fi enterprise e configurazioni NPS costruite nel tempo. Tutto funziona, finché qualcuno non chiede al certificato di dimostrare davvero chi rappresenta.

Il ruolo del KDC

Nella certificate-based authentication verso Active Directory, il componente decisivo è il KDC, cioè il Key Distribution Center sui Domain Controller. Quando arriva una richiesta Kerberos basata su certificato, il KDC deve mappare il certificato ad un principal Active Directory. Prima degli enforcement più recenti, molti ambienti potevano continuare a funzionare anche usando mapping deboli. Con Full Enforcement, il comportamento cambia: se il certificato non soddisfa i criteri di mapping forte, l’autenticazione viene negata.

Il punto importante è che l’errore non è necessariamente nella CA, nel client o nel certificato inteso come oggetto crittografico. Il certificato può essere valido. La chain può essere corretta. La CA può essere trusted. La CRL può essere raggiungibile. Eppure, l’autenticazione può fallire. Perché Active Directory non riesce a legare quel certificato all’identità in modo forte.

Questa è la trappola: quando succede, si inizia a cercare il problema nel posto sbagliato. Si controlla la scadenza, la root CA, la CRL, il template, l’EKU, il client Wi-Fi, il profilo VPN. Tutto giusto. Ma se non si guarda il mapping, si rischia di passare la giornata a litigare con il certificato sbagliato.

Le scadenze: non è più un tema futuro

Questo tema non è teorico e non è più “una cosa che arriverà”. Microsoft ha introdotto gli eventi di audit con gli aggiornamenti del 10 maggio 2022, ha progressivamente cambiato il comportamento dei Domain Controller e ha portato gli ambienti verso il Full Enforcement. Dall’11 febbraio 2025 i Domain Controller aggiornati sono passati al Full Enforcement se non configurati diversamente. La possibilità di tornare temporaneamente in Compatibility Mode tramite registry key è stata mantenuta fino agli aggiornamenti del 9 settembre 2025.

Oggi, in un ambiente aggiornato, bisogna ragionare come se il Full Enforcement fosse la normalità.

Quali scenari possono essere impattati

Lo Strong Certificate Mapping può impattare tutti gli scenari in cui un certificato viene usato per autenticarsi contro Active Directory/KDC. Gli esempi più comuni sono:

• smart card logon
• Windows Hello for Business in modalità certificate trust
• certificati utente distribuiti tramite autoenrollment
• certificati dispositivo
• Intune SCEP
• Intune PKCS
• NDES
• NPS con EAP-TLS
• Wi-Fi enterprise 802.1X
• VPN con autenticazione a certificato
• soluzioni NAC
• IIS con client certificate mapping
• integrazioni con CA di terze parti

La parte più delicata è che spesso questi scenari sono distribuiti tra team diversi. Il team identity gestisce Active Directory. Il team endpoint gestisce Intune. Il team network gestisce Wi-Fi, VPN e NPS. Il team security gestisce PKI, hardening e vulnerability management.

Intune SCEP e PKCS: perché meritano attenzione

Gli ambienti moderni usano spesso Microsoft Intune per distribuire certificati SCEP o PKCS a dispositivi e utenti. Qui lo Strong Certificate Mapping diventa particolarmente importante.

SCEP

Per i certificati SCEP distribuiti da Intune, Microsoft richiede di aggiungere la variabile:

Questa variabile deve essere inserita nel Subject Alternative Name come URI.

Intune genera poi un valore nel formato:

In questo modo il certificato contiene l’informazione necessaria per soddisfare i requisiti di strong mapping.

PKCS

Per i certificati PKCS distribuiti da Intune, serve verificare il Microsoft Intune Certificate Connector. Le versioni aggiornate del connector permettono di aggiungere al certificato l’attributo OID contenente il SID dell’utente o del dispositivo.

Sul server del connector, Microsoft prevede anche l’abilitazione della chiave:

Dopo la modifica è necessario riavviare i servizi del certificate connector.

Queste modifiche si applicano ai nuovi certificati e ai certificati rinnovati. Non bisogna quindi confondere “ho modificato il profilo” con “tutti i certificati già distribuiti sono automaticamente a posto”. La PKI non dimentica.

Come riconoscere il problema nei log

Gli eventi più importanti si trovano nel registro System dei Domain Controller, con sorgente Kdcsvc. Gli eventi da cercare sono:

Comando PowerShell utile:

Se l’ambiente ha più Domain Controller, conviene eseguire la verifica su tutti:

Un errore di mapping non va letto come “il certificato è scaduto”. Va letto come “il KDC non riesce a fidarsi dell’associazione tra certificato e account”. Sono due problemi diversi.

Verificare lo stato del KDC

Per controllare la configurazione relativa allo Strong Certificate Binding Enforcement sui Domain Controller:

Valori rilevanti:

Valore	Significato
0	Disabilita il controllo. Non raccomandato e non più strada sostenibile
1	Compatibility mode
2	Full Enforcement

Attenzione: questa registry key è stata una misura transitoria. Negli ambienti aggiornati dopo settembre 2025 non va considerata una strategia di lungo periodo. La remediation corretta non è “abbassiamo il controllo”. La remediation corretta è “emettiamo o mappiamo i certificati in modo forte”.

Verificare se un certificato contiene la SID extension

Per analizzare un certificato esportato:

Oppure filtrando l’OID:

Se il certificato è stato emesso da una Enterprise CA Microsoft aggiornata, usando template online e senza esclusioni specifiche, ci si aspetta la presenza della SID extension nei certificati idonei.

Se il certificato arriva da una CA non Microsoft, da flussi SCEP/PKCS particolari o da template personalizzati, serve verificare caso per caso.

Attenzione ai template AD CS

Le Enterprise CA Microsoft aggiornate aggiungono di default la SID extension ai certificati emessi tramite template online. È però possibile escludere questa estensione agendo sul flag del template.

Microsoft documenta il bit 0x00080000 sull’attributo msPKI-Enrollment-Flag

Esempio:

Questo comando esclude la nuova estensione dal template indicato. Non è una cosa da fare con leggerezza. In uno scenario moderno, rimuovere la SID extension significa togliere una protezione che serve proprio a rendere affidabile il mapping tra certificato e identità. Può avere senso solo se quel certificato non viene usato per PKINIT/autenticazione Kerberos verso il KDC, oppure se esiste un altro mapping forte configurato.

Verificare altSecurityIdentities

In alcuni casi il mapping forte viene realizzato manualmente tramite l’attributo altSecurityIdentities dell’account Active Directory. Per individuare gli account che usano questo attributo:

Per includere anche i computer:

Da qui bisogna distinguere mapping deboli e forti. Esempi deboli:

X509:<I>IssuerName<S>SubjectName

X509:<S>SubjectName

X509:<RFC822>[email protected]

Esempi forti:

X509:<I>IssuerName<SR>SerialNumber

X509:<SKI>SubjectKeyIdentifier

X509:<SHA1-PUKEY>PublicKeyHash

Nel caso Issuer + Serial Number bisogna fare attenzione al formato del seriale: Microsoft richiede l’inversione del byte order quando si inserisce il valore in altSecurityIdentities. È un dettaglio piccolo, ma abbastanza fastidioso da ricordarci che le PKI sono state progettate anche per selezionare naturalmente le persone più pazienti.

NPS, Wi-Fi e VPN: dove il problema diventa visibile agli utenti

Uno degli scenari più delicati è NPS con EAP-TLS. Dal punto di vista dell’utente, il problema si manifesta in modo molto semplice:

• il Wi-Fi non si connette
• la VPN rifiuta l’accesso
• l’autenticazione a certificato fallisce
• il dispositivo “ha il certificato”, ma non entra

Dal punto di vista tecnico, però, il fallimento può non essere nel certificato del server NPS, ma nel certificato client usato per autenticarsi e nel modo in cui quel certificato viene mappato all’account AD. Per questo, durante il troubleshooting, bisogna controllare almeno tre livelli:

1. certificato server NPS usato dal metodo EAP
2. certificato client presentato dall’utente o dal dispositivo
3. eventi KDC sui Domain Controller coinvolti nell’autenticazione

Per esportare la configurazione NPS e verificare quale certificato è legato a una policy:

Questo aiuta a non confondere due problemi diversi:

• il certificato server NPS scaduto o non corretto
• il certificato client non mappabile in modo forte all’identità AD

Entrambi rompono l’autenticazione. Ma sono due rotture diverse. E come sempre, Windows è molto bravo a farle sembrare parenti strette.

Metodo operativo per assessment

Per trasformare il tema in un controllo concreto, propongo questa checklist operativa.

1. Identificare tutti gli scenari certificate-based

Mappare dove vengono usati certificati per autenticazione:

• smart card
• WHfB certificate trust
• Wi-Fi 802.1X
• VPN
• NPS
• NAC
• Intune SCEP
• Intune PKCS
• certificati utente via autoenrollment
• certificati computer via autoenrollment
• IIS client certificate authentication
• applicazioni legacy

2. Verificare Domain Controller e CA

Controllare che:

• tutti i Domain Controller siano aggiornati
• le CA Enterprise siano aggiornate
• non esistano DC legacy usati in percorsi di autenticazione critici
• il Full Enforcement sia considerato comportamento normale
• i log KDC siano monitorati

3. Cercare eventi KDC

Eseguire ricerca eventi 39, 40 e 41 su tutti i Domain Controller.

4. Analizzare i certificati distribuiti

Per ogni scenario critico, esportare un certificato reale e verificare:

• issuer
• subject
• SAN
• EKU Client Authentication
• validità temporale
• presenza SID extension
• corrispondenza tra SID certificato e SID account

5. Controllare i template AD CS

Verificare quali template emettono certificati usati per autenticazione al KDC.

Per ogni template chiedersi:

• è un template online?
• viene usato per utenti o computer?
• include Client Authentication?
• viene usato da autoenrollment, Intune, NDES o connector?
• è stata esclusa la SID extension?
• il certificato emesso viene usato per PKINIT/Kerberos?

6. Controllare Intune

Per SCEP:

• verificare che il profilo contenga URI SAN
• aggiungere {{OnPremisesSecurityIdentifier}}
• testare con gruppo pilota
• forzare rinnovo o nuova emissione dove necessario

Per PKCS:

• aggiornare il Certificate Connector
• impostare EnableSidSecurityExtension = 1
• riavviare i servizi del connector
• testare nuove emissioni e rinnovi

7. Controllare altSecurityIdentities

Individuare mapping manuali esistenti e classificare weak/strong. I mapping weak non devono essere considerati una base sostenibile per l’autenticazione moderna.

8. Pianificare la remediation

Le azioni possibili sono:

• riemettere i certificati con SID extension
• correggere profili Intune SCEP/PKCS
• aggiornare connector e NDES dove necessario
• configurare mapping espliciti forti nei casi particolari
• eliminare mapping deboli legacy
• validare NPS, Wi-Fi, VPN e applicazioni con test controllati

Esempio di flusso di lavoro

Per un test è possibile utilizzare un duplicato del template “User”. Nel mio caso ICTPower-User-StrongMapping:

Figura 4 – Nuovo Template

Figura 5 – Configurazione nuovo template

Figura 6 – Configurazione nuovo template

Figura 7 – Configurazione nuovo template

Figura 8 – Configurazione nuovo template

Figura 9 – Configurazione nuovo template

Figura 10 – Verifica template

Figura 11 – Verifica assenza flag msPKI

Nel caso di template con flag presente

Figura 12 – Verifica presenza flag msPKI

Microsoft documenta alla pagina KB5014754: Certificate-based authentication changes on Windows domain controllers – Microsoft Support che impostare 0x00080000 su msPKI-Enrollment-Flag impedisce l’aggiunta dell’estensione SID, rimuovendo quindi la protezione associata a quella estensione.

Emettiamo un certificato per verificare il corretto funzionamento.

Figura 13 – Richiesta nuovo certificato

Figura 14 – Selezione Template

Figura 15 – Enroll andato a buon fine

Figura 16 – Verifica presenza SID

Oppure, con questo script, esportiamo e controlliamo il certificato:

Figura 17 – Verifica presenza SID

Errori comuni

Confondere validità del certificato e validità del mapping: Un certificato valido non è automaticamente un certificato accettabile per l’autenticazione Kerberos.

Pensare che il problema sia solo AD CS: Il problema attraversa AD CS, KDC, Intune, NPS, Wi-Fi, VPN e identità ibride.

Aggiornare il profilo ma non riemettere i certificati: Le modifiche valgono per nuovi certificati o rinnovi. I certificati già distribuiti vanno gestiti.

Guardare solo il client: Il client vede un fallimento. Il motivo spesso è scritto sul Domain Controller.

Usare Compatibility Mode come strategia: Compatibility Mode è stato un ponte, non una casa. E le case costruite sui workaround prima o poi chiedono il mutuo tecnico.

Checklist finale

Prima di considerare chiuso il tema Strong Certificate Mapping, bisognerebbe rispondere a queste domande:

• Dove usiamo certificati per autenticarci contro Active Directory?
• I Domain Controller sono tutti aggiornati?
• Le CA Enterprise sono aggiornate?
• I certificati usati per PKINIT contengono la SID extension?
• I profili Intune SCEP includono {{OnPremisesSecurityIdentifier}} nel SAN URI?
• Il Certificate Connector per PKCS è aggiornato e configurato per aggiungere il SID?
• Esistono mapping manuali in altSecurityIdentities?
• Quei mapping sono weak o strong?
• Abbiamo eventi KDC 39, 40 o 41?
• Gli scenari Wi-Fi, VPN e NPS sono stati testati dopo la riemissione dei certificati?
• Le CA di terze parti supportano un mapping forte compatibile?
• Abbiamo un piano di rinnovo e comunicazione per gli utenti impattati?

Conclusioni

Lo Strong Certificate Mapping non è una modifica cosmetica. È un cambio di postura, ancora una volta. Per anni molte infrastrutture hanno trattato il certificato come prova sufficiente dell’identità. Microsoft ha reso più esplicita una cosa che in sicurezza dovremmo sapere bene: non basta fidarsi del documento, bisogna fidarsi del legame tra documento e persona.

In Active Directory questo legame passa dal KDC, dal SID, dai template AD CS, da Intune, da NPS e da tutte quelle integrazioni che spesso funzionano talmente bene da diventare invisibili. Finché si rompono. E quando si rompono, non lo fanno in modo poetico: lo fanno impedendo a utenti e dispositivi di autenticarsi a Wi-Fi, VPN, applicazioni e risorse interne.

La vera lezione è semplice: la PKI non è solo emissione di certificati. È continuità operativa dell’identità. E lo Strong Certificate Mapping ci ricorda che in un dominio Active Directory moderno non basta chiedere: “Il certificato è valido?”. Bisogna chiedere: “Active Directory sa davvero a chi appartiene?”

Stay tuned!