Nous avons récemment mis en œuvre la version 4.0 de notre système de gestion des certificats (CMS) pour un client et nous avons rencontré un problème étrange avec la mise en œuvre de SCEP par Microsoft - le service de rôle d'autorité de certification Microsoft Network Device Enrollment Service (NDES) sous le rôle Active Directory Certificate Services (AD CS) - sur Windows Server 2012 R2, problème que nous n'avions jamais rencontré auparavant. J'ai pensé vous en parler afin que, si vous rencontrez ce problème, vous n'ayez pas à vous frapper la tête contre le mur aussi longtemps que nous l'avons fait avant de trouver une solution.
Le NDES de Microsoft est utilisé en conjonction avec le CMS pour prendre en charge l'enregistrement de certificats à partir d'appareils iOS. Dans la mise en œuvre de ce client particulier, le CMS était installé sur le même serveur que le rôle NDES de Microsoft. Il s'agit d'une conception de mise en œuvre courante. Le CMS et le NDES fonctionnent tous deux sous IIS, mais le CMS nécessite plus de services de rôle IIS que le NDES. Il nécessite également ASP.NET 4.5, qui est à la fois une fonctionnalité et un service de rôle sous IIS Application Development sur Windows Server 2012 R2.
Parce que NDES peut être un peu difficile à faire fonctionner, nous l'installons généralement en premier et nous nous assurons qu'il émet avec succès des défis SCEP avant d'installer CMS, et c'est ce que nous avons fait dans ce cas. Mais, malgré tous nos efforts, nous n'avons pas réussi à faire en sorte que le service NDES émette des défis SCEP. Nous avions correctement configuré NDES selon la documentation Microsoft en utilisant l'authentification Kerberos et avions accordé à notre utilisateur les droits d'inscription pour les certificats en utilisant le modèle configuré pour être utilisé par NDES. Mais à chaque fois que nous avons demandé un challenge SCEP, nous avons reçu un message indiquant que nous ne disposions pas des autorisations suffisantes pour demander un challenge SCEP. Le message exact dans le journal des événements pour chaque échec était le suivant :
Le service d'inscription des équipements réseau ne peut pas fournir son mot de passe car l'utilisateur ne dispose pas d'autorisations d'inscription sur le modèle de certificat configuré, ou l'autorité de certification n'est pas autorisée à émettre des certificats basés sur le modèle de certificat configuré.
Le message reçu par l'utilisateur final était le suivant :
Vous ne disposez pas d'autorisations suffisantes pour vous inscrire auprès de SCEP. Veuillez contacter votre administrateur système.
Alors que nous continuions à nous frapper la tête contre le mur, nous avons remarqué des comportements très curieux :
- Si nous avons accordé à notre utilisateur des droits d'administration locaux sur le serveur NDES, cet utilisateur a pu obtenir un challenge SCEP à distance (en visitant l'URL /certsrv/mscep_admin servie par le serveur NDES à partir d'un autre ordinateur) mais n'a pas pu obtenir un challenge SCEP localement. Pour que le CMS fonctionne correctement, il faut que cela fonctionne localement. De plus, c'est un risque pour la sécurité que d'accorder à l'utilisateur (pour la fonctionnalité du CMS, il s'agirait du compte de service sous lequel le CMS fonctionne) des droits d'administration locaux sur le serveur, et cela ne devrait pas être nécessaire.
- L'utilisateur administratif du domaine "Administrator" (le compte intégré) pouvait obtenir un challenge SCEP localement, mais aucun autre compte administrateur de domaine ou d'entreprise ne pouvait obtenir un challenge SCEP localement. Notez que ce comportement n'est apparu que dans les environnements où NDES était configuré pour effectuer l'authentification Kerberos. Lorsqu'il fonctionne correctement, NDES fonctionnera avec succès au sein d'un domaine unique en utilisant l'authentification NTLM.
- Le message de refus de permission lors de la tentative d'obtention d'un challenge SCEP s'est produit même si nous avons accordé au groupe magique "Everyone" les permissions d'enrôlement sur le modèle d'AC configuré pour NDES.
Il est clair que le message d'autorisation refusée était un faux message et que quelque chose d'autre ne fonctionnait pas, mais quoi ? Prêt pour la grande révélation ? Voici ce qu'il en est.
Lorsque nous avons installé les rôles NDES sur le serveur (à la fois le Network Device Enrollment Service et les rôles Certificate Authority Web Enrollment), nous avons installé les rôles supplémentaires nécessaires pour CMS en même temps - Basic Authentication for IIS et ASP.NET 4.5 (à la fois la fonctionnalité et le service de rôle IIS). NDES sur Windows Server 2012 R2 ne joue pas bien avec cela. Microsoft nous a expliqué que le fichier web.config utilisé par NDES est piétiné (c'est-à-dire corrompu) par l'un de ces autres rôles, ce qui conduit à une situation dans laquelle il n'y a aucun espoir de voir NDES fonctionner.
La solution à ce problème ? Désinstaller NDES (tous les rôles CA) et tous les rôles IIS. Réinstallez ensuite uniquement les rôles NDES et les services IIS qu'il souhaite installer. Ne sélectionnez aucun rôle ou fonctionnalité supplémentaire lors de cette première installation. Une fois que les défis SCEP fonctionnent à la fois à distance et localement (sans demande de mot de passe), vous pouvez revenir en arrière et installer les rôles et fonctionnalités supplémentaires requis pour le CMS et poursuivre l'implémentation du CMS.
AVERTISSEMENT: Ne désinstallez pas .NET Framework 4.5 de Windows Server 2012 R2. Cela désinstalle l'interface graphique de l'ordinateur et vous laisse avec quelque chose qui ressemble à une installation de Windows Server Core. Il est possible de désinstaller ASP.NET 4.5, mais ce n'est pas nécessaire pour résoudre le problème.
Lors du dépannage de ce problème NDES, nous avons rencontré un autre problème NDES étrange qui produisait le même message d'erreur bidon que ci-dessus, mais avec une cause différente. Dans cet autre cas, le problème résultait d'un bogue de mappage du gestionnaire IIS. Ce bogue est spécifique à Windows Server 2012 R2 et NDES et semble être lié à l'installation du rôle ASP.NET 4.5 en plus des rôles NDES et web enrollment sur le serveur NDES, bien que nous attendions toujours des informations de la part de Microsoft quant à la cause exacte de ce problème. Si vous rencontrez ce problème et que la méthode de réinstallation ci-dessus ne résout pas le problème, essayez cette résolution :
- Lancez le Gestionnaire IIS en utilisant l'option "Exécuter en tant qu'administrateur".
- Recherchez le répertoire virtuel mscep_admin sous certsrv pour le site Web par défaut.
- Double-cliquez sur "Handler Mappings".
- Cliquez sur "Voir la liste ordonnée..." dans le volet de droite.
- Localisez et sélectionnez "ExtensionlessURLHandler-ISAPI-4.0_64bit".
- Sous "Actions" dans le volet de droite, cliquez sur "Descendre" jusqu'à ce que "ExtensionlessURLHandler-ISAPI-4.0_64bit" se trouve tout en bas de la liste.
- Redémarrez IIS dans IIS Manager ou à une invite administrative command avec "iisreset".
- Réessayer la récupération du challenge SCEP en tant que compte de service NDES à la fois localement et à distance.
