# Certificats de contrôleur de domaine

{% hint style="info" %}
Cette fonctionnalité nécessite la version **1.6** ou supérieure.
{% endhint %}

{% hint style="warning" %}
Édition SCEPman Enterprise uniquement
{% endhint %}

Vous pouvez utiliser SCEPman pour délivrer des certificats d’authentification Kerberos à vos contrôleurs de domaine. Cela permet à vos appareils joints à l’AAD ou en mode hybride de s’authentifier de manière transparente lors de l’accès aux ressources sur site. Cela peut être utilisé pour implémenter le **Hybrid Key trust pour Windows Hello for Business**. SCEPman remplacera l’exigence d’une **infrastructure à clé publique**. Les détails se trouvent [ici](https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs)

## Root CA sans extension Enhanced Key Usage (EKU)

**Cette fonctionnalité impose de nouvelles exigences à la Root CA.**\
Si vous mettez à jour à partir d’une version antérieure comme **1.6** vous devez générer une **nouvelle** Root CA.\
Pour prendre en charge les certificats d’authentification Kerberos, le certificat de l’AC doit ne contenir aucune extension Enchanced Key Usage (EKU), ou bien inclure Kerberos Authentication et Smart Card Logon.

Si vous commencez avec SCEPman **1.6** et générez la Root CA avec notre SCEPman, vous pouvez ignorer les étapes suivantes.\
Sinon, veuillez suivre ce guide pour générer une nouvelle Root CA.

{% hint style="warning" %}
Si vous générez un nouveau certificat d’AC, vous devez mettre à jour vos stratégies Intune et déployer la nouvelle Root CA ainsi que les nouveaux certificats utilisateur et appareil !
{% endhint %}

1. Accédez à votre **Key Vault**
2. Vérifiez si votre compte utilisateur est ajouté aux **stratégies d’accès** avec toutes les autorisations de certificat
3. Allez à **Certificates**, sélectionnez votre certificat d’AC et cliquez sur **Delete**
4. Après avoir supprimé avec succès le certificat d’AC, vous devez cliquer sur **Manage deleted certificates**
5. Sélectionnez votre certificat d’AC que vous avez supprimé à l’étape 3 et cliquez sur **Purge** (Gardez à l’esprit qu’après avoir purgé le certificat, vous ne pouvez pas le restaurer !)
6. Redémarrez maintenant vos App Services SCEPman
7. Une fois vos App Services redémarrés, ouvrez le tableau de bord SCEPman en accédant à l’URL de votre SCEPman
8. Vous pouvez voir la section **Config issues**, veuillez suivre les étapes de cette section.
9. Après avoir généré le nouveau certificat d’AC, vous pouvez vérifier l’adéquation de l’AC dans le tableau de bord SCEPman.

Adéquation de l’AC sur le tableau de bord SCEPman :

![](https://129332256-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-4998f1e56f64d240e4e8d23a9aa886cc8b49724b%2F2022-05-27%2011_09_46-Window.png?alt=media)

## Modifications de configuration du service SCEPman

Pour activer cette fonctionnalité, vous devez ajouter deux paramètres d’application dans votre service SCEPman. Dans l’implémentation actuelle, nous utilisons une clé pré-partagée (mot de passe) pour les demandes des DC.\
**Veuillez générer une nouvelle clé/mot de passe et la conserver en lieu sûr.** (vous en aurez besoin dans les étapes suivantes et plus tard, sur les contrôleurs de domaine)

1. Accédez à **App Services**
2. Choisissez ensuite votre application SCEPman
3. Ensuite sous **Settings** cliquez **Environment variables**
4. Sélectionnez Add
5. Type **AppConfig:DCValidation:Enabled** comme Name (utilisez \_\_ au lieu de : pour SCEPman basé sur Linux)
6. Type **true** comme Value
7. Confirmez avec **OK**
8. Sélectionnez **Ajouter** à nouveau
9. Type **AppConfig:DCValidation:RequestPassword** comme Name (utilisez \_\_ au lieu de : pour SCEPman basé sur Linux)
10. Saisissez votre **clé/mot de passe**, que vous avez généré précédemment, comme Value
11. Confirmez avec **OK**
12. Enregistrez les paramètres d’application

## Faire confiance au certificat de l’AC dans le domaine pour l’authentification Kerberos

Les certificats utilisés pour l’authentification Kerberos doivent être approuvés dans le domaine AD en tant que certificats d’AC d’authentification. Veuillez télécharger le certificat d’AC depuis le tableau de bord SCEPman. Si vous avez enregistré le fichier sous `scepman-root.cer`, vous pouvez publier le certificat d’AC SCEPman (qu’il s’agisse d’une Root CA ou d’une Intermediate CA) avec la commande suivante en utilisant un compte disposant des droits d’Enterprise Administrator :

```
certutil -f -dsPublish scepman-root.cer NTAuthCA
```

De manière analogue, exécutez la commande suivante pour déployer le certificat Root CA (c.-à-d. le certificat d’AC SCEPman ou, si SCEPman est une Intermediate CA, la Root CA de la chaîne de certificats de l’AC SCEPman) dans le magasin de certificats Trusted Root pour toutes les machines du forêt AD :

```
certutil -f -dsPublish scepman-root.cer RootCA
```

Ensuite, le certificat d’AC est généralement approuvé dans AD et, en particulier, approuvé pour l’authentification Kerberos. Cependant, cela prend un certain temps (dans la configuration par défaut, jusqu’à 8 heures) avant que tous les appareils reçoivent cette configuration. Vous pouvez accélérer ce processus sur n’importe quelle machine en exécutant `gpupdate /force`, par exemple sur les contrôleurs de domaine.

Cela garantit que les certificats DC sont approuvés dans le domaine. Ils sont également approuvés sur tous les appareils gérés par Intune dans le périmètre d’un profil de certificat approuvé distribuant le certificat Root CA. Il peut être nécessaire de distribuer manuellement la Root CA à d’autres services comme des appliances ou des services cloud afin de rendre les certificats DC approuvés pour tous les systèmes.

## Installation sur le client

Vous devez ensuite télécharger notre logiciel client SCEP Open Source [SCEPClient](https://github.com/scepman/scepclient/releases). Les versions avec le suffixe *-framework* utilisent .NET Framework 4.6.2, qui est préinstallé sur Windows Server 2016 et compatible avec les versions plus récentes. Les autres versions nécessitent que le runtime .NET Core soit installé sur les systèmes cibles.

Exécutez la commande suivante dans une invite de commandes élevée sur un contrôleur de domaine pour recevoir un certificat de contrôleur de domaine de SCEPman :

```
ScepClient.exe newdccert https://your-scepman-domain/dc RequestPassword
```

Vous devez ajouter l’URL SCEPman dans la commande précédente mais conserver le chemin `/dc`. Remplacez `RequestPassword` par la clé/le mot de passe sécurisé que vous avez généré précédemment.

Le mot de passe de requête est chiffré avec le certificat d’AC de SCEPman, donc seul SCEPman peut le lire. Les certificats de contrôleur de domaine ne sont délivrés qu’avec le mot de passe de requête correct.

### Renouvellement automatisé des certificats

{% hint style="warning" %}
La commande ci-dessus demande un nouveau certificat DC, qu’il existe déjà ou non un certificat valide. Consultez la section suivante pour apprendre à renouveler les certificats uniquement si le certificat existant est sur le point d’expirer.
{% endhint %}

Pour un renouvellement entièrement automatisé des certificats, vous devriez distribuer ScepClient à **tous** vos contrôleurs de domaine, ainsi que le script PowerShell [enroll-dc-certificate.ps1](https://github.com/scepman/scepclient/blob/Core31/enroll-dc-certificate.ps1). Ajoutez une tâche planifiée qui exécute la commande suivante dans un contexte SYSTEM (adaptez l’URL et le mot de passe de requête) :

```
powershell -ExecutionPolicy RemoteSigned -File c:\scepman\enroll-dc-certificate.ps1 -SCEPURL https://your-scepman-domain/dc -SCEPChallenge RequestPassword -LogToFile
```

Veuillez vous assurer que le script PowerShell se trouve dans le même répertoire que SCEPClient.exe et ses dépendances supplémentaires.

![Configuration de l’action d’exécution dans la tâche planifiée](https://129332256-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-732f9e212c1622579da03c12e497e2b1b632aaab%2Fimage%20\(17\).png?alt=media)

Cela vérifie l’existence de certificats DC dans le magasin de certificats de la machine. Ce n’est que s’il n’y a aucun certificat approprié avec au moins 30 jours de validité qu’il utilise ScepClient.exe pour demander un nouveau certificat DC à SCEPman. Si vous souhaitez modifier le seuil de 30 jours, utilisez le paramètre -ValidityThresholdDays du script PowerShell.

Le script écrit un fichier journal continu dans le répertoire où il est stocké. Si vous ne souhaitez pas ce fichier journal, omettez le `-LogToFile` paramètre. Vous pouvez à la place rediriger les flux Information, Error et/ou Debug vers des fichiers (par ex. `6>logfile.txt 2>&1`).

Pour WHfB, tous les DC exécutant la version 2016 ou plus récente ont besoin d’un certificat d’authentification Kerberos. Les anciens DC redirigent les requêtes d’authentification vers les DC plus récents ; ils n’ont donc pas nécessairement besoin d’un certificat d’authentification Kerberos. Toutefois, il est recommandé de leur fournir également des certificats.

### Retrait progressif d’une PKI interne existante

Veuillez vous assurer que les PKI internes n’inscrivent pas de certificats DC (modèles de certificat "Domain Controller", "Domain Controller Authentication" et "Kerberos Authentication") en parallèle avec SCEPman. Sinon, les DC pourraient utiliser le certificat DC de la PKI interne, lequel est considéré comme non approuvé si, par exemple, le CDP est inaccessible. Le certificat DC SCEPman peut être utilisé pour tous les usages pour lesquels les certificats des modèles mentionnés ci-dessus peuvent être utilisés, par exemple l’authentification Kerberos et LDAPS.

La manière la plus simple d’y parvenir est d’arrêter les AC internes d’émettre des certificats pour les modèles "Domain Controller", "Domain Controller Authentication" et "Kerberos Authentication". Dans le composant logiciel enfichable MMC Certification Authority, supprimez ces modèles de la liste des modèles émis de chaque AC interne. Ensuite, supprimez les certificats déjà émis par l’AC interne des magasins "MY" de vos contrôleurs de domaine (`certlm.msc` et accédez à Personal). Même après un `gpupdate /force`, aucun nouveau certificat DC de la PKI interne ne devrait apparaître dans le magasin Personal du DC.
