Enrôlement automatique Windows

S'applique à :

DuoKey Cockpit v2Windows 10 / 11, Windows Server 2016+MS-XCEP · MS-WSTEP

Préversion

L'enrôlement automatique Windows est disponible en préversion. Déployez-le d'abord sur une unité d'organisation pilote et vérifiez l'enrôlement, le renouvellement et le journal d'événements sur chaque version de Windows utilisée avant d'étendre la stratégie de groupe à la production.

Vue d'ensemble

Windows peut enrôler des certificats auprès d'un serveur de stratégie et d'un service web d'enrôlement en HTTPS, plutôt qu'auprès d'une CA intégrée à Active Directory. DuoKey implémente ces deux services :

Service	Protocole	URL DuoKey
Certificate Enrollment Policy (CEP)	MS-XCEP `GetPolicies` (SOAP 1.2)	`https://<origin>/ms-enroll/<endpoint-id>/cep`
Certificate Enrollment Web Service (CES)	MS-WSTEP WS-Trust `RequestSecurityToken`	`https://<origin>/ms-enroll/<endpoint-id>/ces`

Le client lit la stratégie (modèles, certificat de la CA, adresse du CES), construit une demande pour chaque modèle qu'il est autorisé à enrôler automatiquement et l'envoie au CES. Aucun DCOM / RPC (MS-WCCE) n'intervient : aucun serveur de CA Windows n'est nécessaire. L'identifiant du point de terminaison dans l'URL est un identifiant de routage, pas un secret.

Ce qui est pris en charge

Stratégie : une stratégie par modèle avec l'OID et le nom du modèle, la durée de validité et la période de renouvellement, les droits d'enrôlement et d'enrôlement automatique, la longueur de clé minimale, les indicateurs de nom de sujet et d'enrôlement, et les extensions d'utilisation de clé et d'utilisation étendue. Les utilisateurs ne voient que les modèles utilisateur ; les ordinateurs ne voient que les modèles ordinateur.
Enrôlement et renouvellement : demandes PKCS#10, PKCS#7 et CMC. Les demandes sont émises ou refusées immédiatement (pas d'état en attente) ; les refus renvoient les codes d'erreur Windows standards (par exemple CERTSRV_E_TEMPLATE_DENIED, CERTSRV_E_KEY_LENGTH).
La politique d'émission appartient à la CA : seule la clé publique est reprise de la demande. Sujet, SAN, utilisations de clé, EKU, validité et extensions proviennent du modèle.
Extension de modèle de certificat : les certificats émis portent l'extension de modèle, ce qui permet à Windows de reconnaître le modèle et de ne pas réenrôler, ainsi que le point de distribution CRL et l'adresse OCSP de la CA lorsqu'elle en a.
Inventaire et audit : les certificats émis apparaissent dans l'inventaire des certificats et sont comptés pour la CA. Chaque demande de stratégie, enrôlement et renouvellement est journalisé par point de terminaison (principal, modèle, résultat, numéro de série) et affiché dans PKI > Windows.

Modèles

Chaque modèle Windows est associé à des paramètres DuoKey :

Paramètre	Signification
Nom, OID, version	Identité du modèle telle que Windows la voit (un OID est généré si vous n'en donnez pas)
Demandeur	Utilisateur ou ordinateur
Source du sujet	Construit à partir de l'identité : les utilisateurs reçoivent `CN=<compte>` et un SAN UPN (éventuellement l'adresse e-mail), les ordinateurs `CN=<nom DNS>` et un SAN DNS. Fourni dans la demande : sujet et SAN sont copiés depuis la demande
Utilisations de clé, EKU	Issues du modèle ou d'un profil de certificat DuoKey associé
Validité, période de renouvellement	La validité est plafonnée par le profil associé et à 825 jours
Taille de clé RSA minimale, clé exportable, enrôlement automatique	Annoncés au client

Modèles « fourni dans la demande »

Avec « fourni dans la demande », toute personne autorisée à utiliser le point de terminaison peut demander n'importe quel sujet. Windows n'enrôle pas automatiquement ces modèles ; réservez-les à des points de terminaison restreints et à l'enrôlement manuel.

Les renouvellements reprennent le sujet et les SAN du certificat renouvelé.

Authentification

La stratégie de groupe utilise Kerberos (authentification Windows intégrée) par défaut. Cockpit ne termine pas Kerberos lui-même ; chaque point de terminaison utilise l'un de trois modes :

Mode	Type d'authentification Windows	Identification de l'appelant
Frontal de confiance (Kerberos)	Windows intégrée	Un frontal authentifiant (IIS, ou un reverse proxy avec SPNEGO) effectue la négociation et transmet le principal dans `X-DuoKey-Enroll-Principal`, avec le secret du point de terminaison dans `X-DuoKey-Proxy-Secret`
Nom d'utilisateur / mot de passe	Nom d'utilisateur/mot de passe	`UsernameToken` WS-Security, vérifié contre les comptes d'enrôlement définis sur le point de terminaison (pas contre Active Directory). Les mots de passe comptent au moins 12 caractères
Certificat client	Certificat X.509	La signature d'une demande de renouvellement, ou un certificat client TLS vérifié par le frontal et transmis avec le secret du point de terminaison. Le certificat est revérifié par rapport à la CA

Le secret du frontal est généré par Cockpit (256 bits), affiché une seule fois et peut être renouvelé. Sans secret valide, les en-têtes d'identité sont ignorés : un client qui atteint Cockpit directement ne peut pas usurper un utilisateur en posant ces en-têtes. Le frontal doit écraser (et non compléter) ces en-têtes.

Les principaux sont acceptés sous la forme DOMAIN\name, name@REALM ou name ; un $ final désigne un compte ordinateur. Le nom DNS d'un ordinateur provient de X-DuoKey-Enroll-Dns s'il est transmis, sinon <host>.<domaine DNS AD>. X-DuoKey-Enroll-Mail peut fournir l'adresse e-mail de l'utilisateur.

Mise en place

1. Cockpit

Activer la fonctionnalité

L'enrôlement automatique Windows doit être activé dans l'édition du tenant.

Créer un point de terminaison

Dans PKI > Windows, créez un point de terminaison avec la CA émettrice (CA classique RSA ou ECDSA ; les CA post-quantiques sont refusées), le mode d'authentification, l'origine HTTPS publique que les clients atteignent (Windows exige HTTPS pour CEP et CES) et le domaine DNS Active Directory. Copiez le secret du frontal s'il est affiché.

Ajouter des modèles

Par exemple DuoKeyUser (utilisateur, construit à partir de l'identité) et DuoKeyComputer (ordinateur, construit à partir de l'identité, authentification client et serveur). Associez éventuellement chacun à un profil de certificat DuoKey.

Ajouter des comptes (mode nom d'utilisateur / mot de passe uniquement)

Créez les comptes d'enrôlement avec leur type (utilisateur ou ordinateur) et leur UPN ou nom DNS.

2. Frontal Kerberos

IIS (Application Request Routing + URL Rewrite) sur un serveur joint au domaine :

Site et authentification Windows

Créez un site lié en HTTPS avec un certificat au nom de l'origine publique. Activez l'authentification Windows (Negotiate ; mode noyau désactivé, ou un SPN HTTP/<host> enregistré pour l'identité du pool d'applications) et désactivez l'authentification anonyme.

Autoriser les variables serveur

Dans URL Rewrite, autorisez HTTP_X_DUOKEY_ENROLL_PRINCIPAL et HTTP_X_DUOKEY_PROXY_SECRET.

Règle de reverse proxy

Règle ^ms-enroll/(.*) vers https://<cockpit>/ms-enroll/{R:1}, avec HTTP_X_DUOKEY_ENROLL_PRINCIPAL = {LOGON_USER} et HTTP_X_DUOKEY_PROXY_SECRET = le secret du point de terminaison (règle lisible par les seuls administrateurs).

Restreindre l'accès au backend

N'autorisez que le serveur IIS à atteindre /ms-enroll/ sur Cockpit. Le secret protège déjà le point de terminaison ; la restriction réseau est une défense en profondeur.

Reverse proxy Linux (nginx avec un module SPNEGO, ou Apache mod_auth_gssapi) : authentifiez avec un keytab pour HTTP/<host>, positionnez X-DuoKey-Enroll-Principal depuis l'utilisateur authentifié et X-DuoKey-Proxy-Secret depuis un fichier inclus protégé. Positionnez toujours ces en-têtes pour remplacer toute valeur fournie par le client.

3. Stratégie de groupe

Pour les ordinateurs : Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies de clé publique. Pour les utilisateurs : le même chemin sous Configuration utilisateur.

Stratégie d'inscription de certificats

Client de services de certificats - Stratégie d'inscription de certificats : réglez le modèle de configuration sur Activé, ajoutez un serveur de stratégie avec l'URL CEP https://<origin>/ms-enroll/<endpoint-id>/cep et le type d'authentification du point de terminaison (Windows intégrée, Nom d'utilisateur/mot de passe ou Certificat X.509), cliquez sur Valider le serveur, cochez Activer pour l'inscription et le renouvellement automatiques, puis définissez-le par défaut. Supprimez la stratégie d'inscription Active Directory si DuoKey doit être la seule source.

Inscription automatique

Client des services de certificats - Inscription automatique : Activé, avec Renouveler les certificats expirés, mettre à jour les certificats en attente et supprimer les certificats révoqués et Mettre à jour les certificats qui utilisent les modèles de certificats.

Confiance

Distribuez la CA racine DuoKey dans les Autorités de certification racines de confiance (et les intermédiaires dans les Autorités de certification intermédiaires), et vérifiez que les clients font confiance au certificat TLS de l'origine publique.

Mode nom d'utilisateur / mot de passe

L'identifiant doit être enregistré sur chaque client pour que l'enrôlement automatique fonctionne sans intervention : saisissez-le lorsque le client contacte le serveur de stratégie pour la première fois (console Certificats, Demander un nouveau certificat, propriétés de la stratégie d'inscription, mémoriser l'identifiant), dans le contexte utilisateur ou machine. certutil -credstore liste les identifiants enregistrés.

Tester sur un client

gpupdate /force, puis certutil -pulse (machine) ou certutil -user -pulse (utilisateur). certutil -policyserver * -template liste les modèles renvoyés par la stratégie ; le journal Application (source CertificateServicesClient-AutoEnrollment) indique le résultat.

Enrôlement manuel avec la même stratégie :

Enrôlement manuelPOWERSHELL

certreq -enroll -q -policyserver "https://<origin>/ms-enroll/<endpoint-id>/cep" DuoKeyComputer

Renouvellement

Windows renouvelle les certificats pendant la période de renouvellement du modèle. Une demande de renouvellement signée avec le certificat actuel est acceptée si ce certificat est rattaché à la CA du point de terminaison, est dans sa période de validité, a été émis par Cockpit, n'est pas révoqué et provient du même modèle. Avec le renouvellement par la clé activé sur le point de terminaison (par défaut), ces renouvellements ne nécessitent aucun autre identifiant : les certificats se renouvellent sans mot de passe enregistré. La stratégie annonce alors aussi une adresse CES réservée au renouvellement, authentifiée par certificat.

Révoquer un certificat dans Cockpit arrête son renouvellement.

Limites

Pas de recherche dans l'annuaire. Les sujets sont construits à partir du principal et des en-têtes DNS / e-mail transmis (ou des champs du compte). Les attributs d'annuaire tels que le service, le DN complet de l'annuaire ou l'extension d'identifiant de sécurité (SID) ne sont pas ajoutés. Les certificats utilisés pour l'ouverture de session par carte à puce ou Windows Hello sur des contrôleurs de domaine qui appliquent le mappage fort des certificats nécessitent donc un mappage explicite, ou sont hors périmètre.
Pas de demandes en attente / d'approbation par un responsable, d'archivage de clé, d'enrôlement pour le compte d'un tiers ni de remplacement de modèles. Les listes d'algorithmes et de fournisseurs (attributs CNG de schéma 3/4) sont laissées au client.
Kerberos nécessite le frontal décrit ci-dessus.
Les CA post-quantiques ne peuvent pas être utilisées.
Les points de terminaison partagent la limite de débit de l'API de 300 requêtes par minute et par adresse client. Les clients arrivent généralement par une seule adresse de frontal : si un parc important renouvelle en même temps, répartissez la charge côté frontal.

Sécurité

Les documents XML contenant des DTD ou des déclarations d'entités sont refusés ; la taille des demandes est plafonnée.
Aucun secret ne transite dans une URL. Les mots de passe des comptes sont stockés en hachage Argon2id et le secret du frontal sous forme de vérificateur ; aucun n'est journalisé ni renvoyé après sa création.
Les erreurs de protocole ne renvoient jamais de détails internes.
Le point de terminaison est soumis à la politique d'accès et aux règles d'émission à haute valeur de la CA.

API

Méthode et chemin	Rôle
`GET` / `POST /api/pki/ms-enrollment/endpoints`	Lister / créer des points de terminaison
`GET` / `PUT` / `DELETE /api/pki/ms-enrollment/endpoints/{id}`	Lire / modifier / supprimer un point de terminaison
`POST /api/pki/ms-enrollment/endpoints/{id}/proxy-secret`	Renouveler le secret du frontal
`/api/pki/ms-enrollment/endpoints/{id}/templates`, `/api/pki/ms-enrollment/templates/{id}`	Modèles
`/api/pki/ms-enrollment/endpoints/{id}/accounts`, `/api/pki/ms-enrollment/accounts/{id}`	Comptes d'enrôlement
`GET /api/pki/ms-enrollment/endpoints/{id}/requests`	Journal des demandes

Permissions : Operations.Pki.MsEnrollment.Read, .Create, .Update, .Delete.

Vue d'ensemble​

Ce qui est pris en charge​

Modèles​

Authentification​

Mise en place​

1. Cockpit​