Wi-Fi d’entreprise EAP-TLS : PKI, NDES, NPS et Intune

Le probleme qu’on resout

Un SSID d’entreprise protege par une cle pre-partagee (WPA2-PSK) ou par un identifiant/mot de passe (PEAP-MSCHAPv2) presente deux faiblesses majeures. La cle partagee se diffuse de poste en poste et ne peut etre revoquee sans tout reconfigurer. L’authentification par mot de passe, elle, expose l’organisation au vol d’identifiants, au phishing et aux attaques par relais si la validation du certificat serveur est mal configuree cote client.

Pour une flotte mixte (postes geres, mobiles d’entreprise, appareils personnels enrôles), la cible est une authentification sans secret partage, par appareil, revocable a la demande. C’est exactement ce que fournit EAP-TLS : chaque appareil presente un certificat client signe par votre PKI, et le serveur RADIUS n’accorde l’acces qu’apres validation de la chaine et correspondance avec un compte annuaire.

La difficulte n’est pas conceptuelle mais operationnelle : distribuer des certificats sur des mobiles non joints au domaine, publier l’inscription SCEP de maniere securisee vers Internet, et surtout composer avec le durcissement Kerberos de KB5014754 qui casse silencieusement les certificats mobiles classiques.

Comment ca marche

Le flux se decompose en deux phases independantes.

Phase 1 : obtention du certificat (inscription)

L’appareil enrôle dans Intune recoit un profil SCEP. Il genere localement sa paire de cles, puis soumet une demande au point d’inscription SCEP (NDES). Cette URL est publiee vers l’exterieur via un proxy d’application d’entreprise, de sorte que seul un relais HTTPS est expose, pas le serveur NDES lui-meme. NDES relaie la demande a l’autorite de certification (ADCS), qui emet un certificat client porteur de l’UPN de l’utilisateur dans le champ SAN.

Phase 2 : connexion Wi-Fi (authentification)

Quand l’appareil se connecte au SSID, le point d’acces agit en client RADIUS et transfere la session EAP-TLS au serveur NPS. Le NPS valide la chaine du certificat client (racine + intermediaire deja presentes dans son magasin), identifie le compte annuaire via l’UPN, applique une strategie reseau (conditions sur le SSID et l’appartenance a un groupe), puis renvoie une autorisation accompagnee d’attributs RADIUS placant l’appareil dans le bon VLAN.

Le point sensible est le liage certificat/compte. Depuis KB5014754, le KDC exige un liage fort : soit le certificat contient l’extension de securite SID (szOID_NTDS_CA_SECURITY_EXT), soit l’attribut altSecurityIdentities du compte porte un mappage explicite et fort. Les certificats emis par auto-inscription embarquent nativement cette extension ; ceux emis via SCEP/NDES, non — d’ou la necessite d’une action dediee.

Prerequis

• Une autorite de certification d’entreprise (ADCS) operationnelle avec un modele de certificat utilisateur SCEP (EKU Authentification du client, le sujet etant fourni par le demandeur).
• Un serveur NDES avec le connecteur de certificats Intune installe et sain.
• Un serveur NPS/RADIUS declare comme serveur d’authentification du controleur Wi-Fi.
• Un proxy d’application d’entreprise publiant l’URL SCEP interne.
• Intune avec droits d’administration des profils de configuration et des groupes.
• Droits annuaire pour modifier altSecurityIdentities (delegation ciblee, pas d’admin de domaine permanent).
• Acces administrateur local aux serveurs NPS et NDES pour verification et redemarrage de service.

Procedure

1. Preparer le groupe de deploiement. Creez un groupe (Entra ID synchronise vers l’AD on-prem) qui portera les utilisateurs pilotes. Son SID servira de condition dans la strategie NPS.
2. Exporter la chaine de confiance. Depuis le serveur NPS, exportez le certificat racine et le certificat intermediaire au format DER pour les importer dans Intune.
3. Creer le profil « certificat racine de confiance » (iOS/iPadOS, modele Certificat de confiance) et le profil intermediaire.
4. Creer le profil SCEP. Type Utilisateur, sujet CN={{UserPrincipalName}}, SAN de type UPN valant {{UserPrincipalName}}, cle 2048 bits, SHA-2, EKU Authentification du client, URL SCEP du proxy, et nom du modele de certificat saisi manuellement (il doit correspondre exactement au nom du modele ADCS).
5. Creer le profil Wi-Fi. Type Entreprise, EAP-TLS, nom du SSID, nom du certificat serveur de confiance (FQDN du NPS), selection des deux racines de validation, et selection du profil SCEP comme certificat client via le menu deroulant de l’interface graphique.
6. Assigner les quatre profils au groupe pilote et synchroniser un appareil de test.
7. Appliquer le contournement KB5014754 (voir script) : ajouter un mappage fort <I><SR> sur le compte le temps que l’injection du SID soit en place.
8. Redemarrer le service NPS et tester la connexion.

Le script

Export de la chaine de confiance depuis le NPS, puis ajout du mappage fort temporaire. Adaptez les valeurs generiques a votre environnement.

# === Partie 1 : export racine + intermediaire (a executer sur le serveur NPS) ===
# Prerequis : console admin locale sur le NPS, dossier C:\Temp existant

$sortie = 'C:\Temp'
New-Item -ItemType Directory -Path $sortie -Force | Out-Null

# Racine : adaptez le sujet a votre CA racine
$racine = Get-ChildItem 'Cert:\LocalMachine\Root' |
  Where-Object { $_.Subject -eq 'CN=ExempleRootCA' }
$octets = $racine.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Cert)
[IO.File]::WriteAllBytes("$sortie\root-ca.cer", $octets)

# Intermediaire : adaptez au nom de votre CA emettrice
$inter = Get-ChildItem 'Cert:\LocalMachine\CA' |
  Where-Object { $_.Subject -match 'EXEMPLE-ISSUING-CA' }
$octets = $inter.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Cert)
[IO.File]::WriteAllBytes("$sortie\issuing-ca.cer", $octets)

Write-Host "Certificats exportes dans $sortie — a importer dans Intune."

# === Partie 2 : mappage fort KB5014754 (contournement temporaire) ===
# A executer depuis un poste d'administration avec le module Active Directory.
# Le numero de serie du certificat emis se lit dans l'evenement CAPI2 90 sur le NPS,
# dans les journaux NDES, ou via le portail Intune.

# Nom distingue du compte cible (exemple generique)
$compte  = 'CN=Prenom Nom,OU=Utilisateurs,DC=exemple,DC=test'

# Nom distingue de l'emetteur (ordre inverse de lecture, format )
$issuer  = 'DC=test,DC=exemple,CN=EXEMPLE-ISSUING-CA'

# Numero de serie TEL QUE LU (sera inverse par paires d'octets)
$serial  = '120000016E75793B27313E66C400000000016E'

# Inversion octet par octet (byte-pair reversal) exigee par le format 
$paires  = ($serial -split '(..)' | Where-Object { $_ })
[array]::Reverse($paires)
$serialRev = ($paires -join '')

# Construction de la valeur de mappage fort
$altSecId = "X509:$issuer$serialRev"

Set-ADUser -Identity $compte -Add @{ 'altSecurityIdentities' = $altSecId }
Write-Host "Mappage fort ajoute : $altSecId"

Redemarrage du service RADIUS a distance :

# A executer depuis un poste d'administration autorise
Invoke-Command -ComputerName 'NPS01' -ScriptBlock { Restart-Service IAS -Force }

Solution perenne : faire injecter l’extension SID par le connecteur de certificats, sur le serveur NDES.

# A executer en administrateur sur le serveur NDES.
# Verifiez au prealable que votre version du connecteur supporte cette cle
# (consultez les notes de version Microsoft du connecteur).
$cle = 'HKLM:\SOFTWARE\Microsoft\MicrosoftIntune\Connectors\CertificateConnector\Configuration'
Set-ItemProperty -Path $cle -Name 'IncludeSidExtension' -Value 1 -Type DWord
Restart-Service PFXCertificateConnectorSvc
# Forcez ensuite un renouvellement SCEP (desassigner/reassigner le profil)
# puis retirez le mappage fort temporaire une fois le nouveau certificat valide.

Validation

Verifiez chaque maillon, dans l’ordre d’inscription puis d’authentification.

• Cote appareil : dans les reglages de gestion, les quatre profils apparaissent avec le statut « Reussite », et un certificat emis par votre CA emettrice figure dans les certificats installes.
• Cote PKI : dans la console ADCS, une demande recente a bien ete emise pour l’UPN attendu.
• Cote NPS : apres connexion, recherchez l’evenement d’autorisation accordee.

# Verification de l'octroi d'acces sur le NPS (evenement 6272)
Get-WinEvent -FilterHashtable @{
  LogName='Security'; ID=6272; StartTime=(Get-Date).AddMinutes(-5)
} -ComputerName 'NPS01' | Format-List TimeCreated, Message

Une fois l’injection SID active, confirmez la presence de l’extension dans le nouveau certificat via l’evenement CAPI2 90 (recherchez l’OID 1.3.6.1.4.1.311.25.2). Le test final reste la connexion effective au SSID avec placement dans le VLAN attendu.

Plan de retour (rollback)

Comme la demarche reutilise une infrastructure existante (CA, NDES, NPS), le rollback se limite a trois gestes, sans toucher aux serveurs d’infrastructure :

1. Desassigner les quatre profils Intune en remplacant leurs affectations par une liste vide, puis forcer une synchronisation de l’appareil.
2. Retirer le mappage fort ajoute sur le compte.
3. Verifier que l’appareil retombe sur sa methode de connexion anterieure.

# Retrait du mappage fort temporaire
$compte = 'CN=Prenom Nom,OU=Utilisateurs,DC=exemple,DC=test'
$valeur = 'X509:DC=test,DC=exemple,CN=EXEMPLE-ISSUING-CA6E0100000000C4663E31273B79756E01000012'
Set-ADUser -Identity $compte -Remove @{ 'altSecurityIdentities' = $valeur }

Aucune modification des strategies NPS, du connecteur ou de la CA n’est a annuler tant que vous n’avez pas active l’injection SID. Si celle-ci a ete activee, remettez la cle IncludeSidExtension a 0 et redemarrez le service du connecteur.

Depannage

Securite, changement et bonnes pratiques

Secrets et moindre privilege. Ne stockez jamais de mots de passe en clair dans les scripts : utilisez un coffre-fort ou une invite securisee. La modification de altSecurityIdentities doit passer par une delegation ciblee sur l’OU concernee, pas par un compte d’administrateur de domaine permanent. Exposez uniquement le relais SCEP via le proxy d’application, jamais le NDES directement.

Validation en lecture seule d’abord. Toutes les verifications (export de chaine, lecture d’evenements, inspection des extensions) sont non intrusives et doivent precéder toute modification. Testez systematiquement sur un unique appareil pilote avant tout elargissement.

Cadrage ITIL. La mise en place initiale est un changement normal a soumettre au CAB : elle touche la PKI, le RADIUS et la connectivite reseau de production. Planifiez une fenetre de maintenance et prevoyez le plan de retour ci-dessus. Le passage de l’injection SID en production (modification du connecteur et reemission des certificats) constitue un changement a part entiere, egalement cadre, car il impacte le liage Kerberos. L’ajout d’utilisateurs a un groupe deja outille releve ensuite d’une demande de service standard. Documentez chaque emission et chaque mappage comme des enregistrements de configuration, et remontez en gestion des problemes tout rejet recurrent au NPS pour analyse de cause racine.

Perennite. Visez l’injection SID native pour supprimer les mappages manuels, qui ne passent pas a l’echelle. Surveillez les journaux RADIUS pendant au moins une semaine apres chaque elargissement, et conservez un modele de certificat dedie aux mobiles distinct de celui des postes pour maitriser les durees de vie et les revocations.

A retenir

EAP-TLS transforme votre Wi-Fi d’entreprise en un reseau a authentification forte, par appareil, sans secret partage. La chaine PKI → SCEP/NDES → NPS → Intune est entierement reproductible a partir de composants Microsoft standards, et la plupart des echecs se concentrent sur deux points connus : la creation du profil Wi-Fi via l’interface graphique et le liage fort impose par KB5014754. Validez chaque maillon en lecture seule, pilotez sur un appareil avant d’elargir, et planifiez l’injection SID pour une solution durable. Commencez par un pilote a un utilisateur, mesurez, puis industrialisez via vos groupes et vos processus de changement.