Strong Certificate Mapping: preparare il vostro MDM/UEM all’enforcement

Il problema: l’enforcement completo di KB5014754

Microsoft sta introducendo lo Strong Certificate Mapping Enforcement per correggere alcune vulnerabilità dell’autenticazione basata su certificati di Active Directory.

A partire dagli aggiornamenti Windows di febbraio 2025, i domain controller richiederanno che ogni certificato usato per l’autenticazione client includa una mappatura sicura verso il rispettivo account utente, nello specifico incorporando il Security Identifier (SID) dell’utente. Questa modifica (descritta in KB5014754) punta a impedire che un attaccante falsifichi un’identità tramite certificato, imponendo una mappatura più rigorosa.

In precedenza i certificati venivano mappati agli utenti tramite attributi come lo UPN o il subject name, un metodo oggi considerato una mappatura «debole». Con il nuovo enforcement, per il logon Kerberos verranno accettate soltanto mappature «forti» (mappature esplicite oppure un SID corrispondente incorporato nel certificato).

Per la mobilità aziendale il tema riguarda soprattutto l’autenticazione Kerberos sui dispositivi mobili. Hypergate Authenticator (che abilita il Kerberos SSO su Android) si affida a certificati utente per ottenere i ticket Kerberos. Questi certificati vengono in genere emessi tramite un MDM (come Ivanti Neurons, MobileIron, ecc.) via SCEP o metodi simili e non includono ancora il SID di AD. L’enforcement di Microsoft significa che, per impostazione predefinita, questi login mobili basati su certificato inizieranno a fallire una volta attivo l’enforcement completo, a meno che i certificati non vengano aggiornati. In altre parole, l’autenticazione Kerberos dei client mobili (Android, iOS, ecc.) con login basato su certificato smetterà di funzionare se i certificati non vengono aggiornati.

Sono interessate le seguenti versioni di Windows Server:

• Windows Server 2025
• Windows Server 2022
• Windows Server 2019
• Windows Server 2016
• Windows Server 2012 R2
• Windows Server 2008 R2 con ESU

E tutti gli MDM/UEM come (indipendentemente dalla versione):

• Microsoft Intune
• Ivanti Neurons, ex MobileIron Core/Cloud
• Omnissa Workspace One, ex VmWare AirWatch
• BlackBerry UEM
• Soti Mobicontrol
• Samsung Knox

Microsoft ha concesso un periodo di transizione in «compatibility mode» (con warning nei log, ma senza blocco dell’autenticazione); dall’11 febbraio 2025, però, la mappatura forte diventa l’impostazione predefinita e dal 10 settembre 2025 la modalità di compatibilità verrà eliminata del tutto.

L’impatto su Hypergate Authenticator

Nelle attuali installazioni MDM, gli utenti Android che usano Hypergate Authenticator ricevono un certificato utente (distribuito via MDM) e lo utilizzano per l’autenticazione Kerberos (PKINIT). Senza mappatura forte questi logon riescono oggi solo grazie alla modalità di compatibilità e generano warning sui vostri domain controller. Quando la mappatura forte verrà applicata in modo rigoroso (al più tardi a settembre 2025), qualsiasi certificato privo del corretto legame con il SID verrà rifiutato, impedendo agli utenti mobili di autenticarsi ai servizi intranet via Kerberos.

Concretamente, un certificato utente distribuito oggi dal vostro MDM contiene in genere lo UPN dell’utente nel Subject o nel SAN, che Active Directory mappa all’account. Con l’enforcement forte il KDC pretenderà una mappatura sicura (una mappatura esplicita altSecurityIdentities in AD oppure l’estensione SID incorporata). Se il certificato non contiene il SID, il KDC rifiuterà di emettere il TGT. Di conseguenza le sessioni Kerberos SSO (via Hypergate Authenticator) inizieranno a fallire. Microsoft segnala esplicitamente che i certificati emessi tramite MDM o NDES (che usano «offline template») sono a rischio e che i fallimenti di autenticazione sono probabili se questi certificati non rispettano i nuovi standard. In breve, senza alcun intervento la vostra forza lavoro mobile potrebbe perdere all’improvviso l’accesso alle risorse autenticate via Kerberos.

Gli errori da aspettarsi quando la mappatura del certificato fallisce

Ecco alcuni esempi degli errori che potreste incontrare a causa di questo problema:

• Windows Event Viewer (domain controller, KDC): Event ID 39 (Warning o Error):

  “The Key Distribution Center (KDC) encountered a user certificate that was valid but could not be mapped to a user in a secure way (such as via explicit mapping, key trust mapping, or a SID)…”.

  Indica che il certificato presentato non aveva una mappatura forte (nessuna estensione SID né mappatura esplicita). In modalità di compatibilità l’evento viene registrato come warning e il login è comunque consentito; in modalità di enforcement completo diventa un errore e il login viene rifiutato.

• Windows Event Viewer (domain controller, KDC): Event ID 41 (Error):

  “The Key Distribution Center (KDC) encountered a user certificate that was valid but contained a different SID than the user to which it mapped. As a result, the request involving the certificate failed.”

  Significa che il certificato conteneva un SID, ma diverso da quello dell’account utente di destinazione (la verifica della mappatura sicura è fallita). L’autenticazione viene negata per motivi di sicurezza.

• Log del client Kerberos (Hypergate Authenticator): nei log Kerberos dettagliati (o nei log di debug di Hypergate) comparirà un errore come “Received error from KDC: … Certificate mismatch” al momento dell’acquisizione del TGT.

  Un tentativo di kinit, ad esempio, potrebbe restituire KDC_ERR_CERTIFICATE_MISMATCH. Corrisponde all’evento registrato sul KDC: in pratica il domain controller sta dicendo «non posso accettare questo certificato per questo utente».

Questi errori indicano che la mappatura tra certificato e account non è considerata sicura. Il requisito dell’estensione SID è la chiave per risolverli. Vediamo ora come intervenire in un ambiente MDM/UEM con Hypergate.

La soluzione: strong certificate mapping tramite il vostro MDM

Per garantire la continuità del Kerberos SSO mobile esistono due approcci: abilitare la modalità di compatibilità e aggiornare i certificati in un secondo momento, oppure aggiornare subito i certificati.

L’obiettivo finale è aggiornare i certificati al più tardi entro settembre 2025, in modo che tutti i certificati client Kerberos contengano la corretta mappatura SID.

Workaround temporaneo: abilitare la Compatibility Mode sui domain controller

Come mitigazione immediata, abilitate la Compatibility Mode per la mappatura dei certificati su tutti i domain controller. In questo modo l’autenticazione con certificati a mappatura «debole» continuerà a funzionare finché non li avrete aggiornati, evitando interruzioni prima della scadenza. Le indicazioni di Microsoft prevedono di impostare una chiave di registro su ogni DC:

• Percorso del registro: HKLM\SYSTEM\CurrentControlSet\Services\Kdc

• Nome del valore: StrongCertificateBindingEnforcement (REG_DWORD)

• Dati del valore: 1 (per la Compatibility mode, in cui i certificati senza SID sono ancora ammessi ma registrati nei log)

I valori possibili sono:

• 0: Compatibility mode: disattiva il controllo della mappatura forte dei certificati. Sconsigliato, perché disabilita tutti i miglioramenti di sicurezza. (non più possibile dopo l’11 febbraio 2025)
• 1: Compatibility mode con warning: verifica se esiste una mappatura forte del certificato. In caso affermativo, l’autenticazione è consentita. Altrimenti il KDC controlla se il certificato contiene la nuova estensione SID e la convalida. Se l’estensione non è presente, l’autenticazione è consentita solo se l’account utente è antecedente al certificato.
• 2: Strict enforcement: verifica se esiste una mappatura forte del certificato. In caso affermativo, l’autenticazione è consentita. Altrimenti il KDC controlla se il certificato contiene la nuova estensione SID e la convalida. Se l’estensione non è presente, l’autenticazione viene negata.

Impostando 1 i DC restano nello stato di compatibilità (registra e consenti). (Il valore 2 corrisponde al Full Enforcement: registra e rifiuta i certificati senza SID, e diventerà l’impostazione predefinita dopo gli aggiornamenti, mentre 0 disattiverebbe del tutto i nuovi controlli, opzione che Microsoft ha già rimosso negli aggiornamenti precedenti. Non è richiesto alcun riavvio perché la modifica abbia effetto.

Con ogni probabilità dovrete considerare anche la chiave di registro CertificateBackdatingCompensation. Questa chiave gestisce il caso specifico in cui la data di emissione del certificato è anteriore alla data di creazione dell’account utente (situazione che il KDC considera sospetta). In modalità di compatibilità, per impostazione predefinita il KDC tollera solo una differenza di 10 minuti:

• Percorso del registro: HKLM\SYSTEM\CurrentControlSet\Services\Kdc

• Nome del valore: CertificateBackdatingCompensation (REG_DWORD)

• Dati del valore: 5E0C89C0 (esadecimale: omettete 0x per inserire il valore corretto tramite regedit)

I valori possibili sono (scegliete un valore appena superiore alla durata dei vostri certificati):

• 0x5E0C89C0: 50 anni
• 0x2EFE0780: 25 anni
• 0x12CC0300: 10 anni
• 0x9660180: 5 anni
• 0x5A39A80: 3 anni
• 0x1E13380: 1 anno

Abilitando questa chiave, i certificati più datati possono autenticarsi come mappatura debole entro quell’intervallo di tempo. Usatela solo se davvero necessario: funziona unicamente in modalità di compatibilità e resta comunque un workaround temporaneo.

Con la modalità di compatibilità attiva, i login Hypergate dei vostri utenti continueranno a funzionare durante la transizione (anche se i DC registreranno dei warning). Avrete così il tempo di implementare la soluzione definitiva senza interrompere il servizio.

Soluzione definitiva: aggiornare i certificati con la mappatura SID

La soluzione a lungo termine consiste nell’incorporare il SID dell’utente nel certificato client usato da Hypergate (e da altri servizi), così che il certificato possa essere mappato in modo sicuro all’account. In genere questo significa aggiornare i template dei certificati e la configurazione dei profili SCEP o PKCS del vostro MDM/UEM. Lo mostriamo qui in un ambiente Ivanti Neurons:

1. Andate su Configurations, filtrate per Identity Certificate e selezionate la vostra configurazione certificato attuale:
   
2. Aggiungete il seguente Subject Alternate Name Type aggiuntivo di tipo Uniform Resource Identifier: tag:microsoft.com,2022-09-14:sid:${user.sid}. La data è statica: non modificatela, deve essere esattamente 2022-09-14.
   Gli identificatori corretti sono:

   Microsoft Intune: {{OnPremisesSecurityIdentifier}}
   Ivanti EPMM / MobileIron Core: tag:microsoft.com,2022-09-14:sid:$USER_SID$
   Ivanti Neuron / MobileIron Cloud: tag:microsoft.com,2022-09-14:sid:{user.sid}
   BlackBerry UEM: tag:microsoft.com,2022-09-14:sid:%UserSID%
   Soti Mobicontrol: tag:microsoft.com,2022-09-14:sid:$USER_SID$
   Samsung Knox: tag:microsoft.com,2022-09-14:sid:<UserSID>

3. 
5. La configurazione del certificato dovrebbe presentarsi così:
   

6. Il risultato sarà un certificato contenente i seguenti Subject Alternative Names:

   
   

7. Verificate la nuova mappatura del certificato: dopo che un dispositivo ha ricevuto il nuovo certificato, provate un’autenticazione Kerberos (PKINIT) tramite Hypergate Authenticator. Dovrebbe riuscire come prima. Controllate di nuovo i log del domain controller: per il logon di quell’utente non dovreste più vedere warning con Event 39. Se il SID è presente e corretto, il KDC considererà la mappatura forte e non registrerà alcun errore.

8. Una volta verificata con successo la mappatura del certificato, siamo pronti a imporla. Questo passaggio serve solo se volete applicare lo strong certificate binding prima di settembre 2025. Dopo quella data la chiave di registro diventa irrilevante e il binding verrà comunque applicato. Per abilitarlo già oggi occorre impostare una chiave di registro su ogni DC:

   • Percorso del registro: HKLM\SYSTEM\CurrentControlSet\Services\Kdc

   • Nome del valore: StrongCertificateBindingEnforcement (REG_DWORD)

   • Dati del valore: 2 (per la Strict mode)

Con questi passaggi avete messo in atto una soluzione che soddisfa i nuovi requisiti di Microsoft e mantiene operativo senza interruzioni l’SSO mobile della vostra azienda. Con lo Strong Certificate Mapping Enforcement pienamente in vigore, i vostri utenti Android possono continuare a usare Hypergate per l’autenticazione Kerberos in tutta sicurezza e i vostri domain controller accetteranno le mappature forti basate su SID presenti in ogni certificato.