DirectAccess : un jeu de lego – (Partie 4/7 : NLS)
|
.jpg)
.jpg){kind=logo}
Vous trouverez ci-dessous le début de l’article, n’hésitez pas à télécharger la suite directement en format pdf
Sommaire de l'article
- Configuration du serveur APP1
- Configuration initiale du système d’exploitation
- Installation du rôle WebServer
- Publication de la CRL
- Fichier de demande du certificat NLS
- Soumission de la demande de certificat NLS
- Installation du certificat NLS
>> Télécharger gratuitement l'intégralité de cet article <<
Configuration du serveur APP1
Etant donné que ce serveur n’aura finalement que peu d’utilisation sinon d’héberger un simple site web en HTTPS pour le Network Location Server de DirectAccess, on va installer ce serveur avec « Windows Server 2008 R2 Standard » mais en Core. Pour le coup, c’est « complex by design ». La configuration comprendra les étapes suivantes :
- La configuration initiale du système d’exploitation
- L’installation du rôle WebServer
- La publication de la CRL
- La mise en œuvre du NLS
.jpg)
Configuration initiale du système d’exploitation
A ce stade, rien de bien difficile, sinon l’utilisation de SCONFIG.EXE pour réaliser les opérations suivantes :
- Nommer le serveur en APP1
- Configurer l’interface réseau
- Configurer le client DNS
- Effectuer la jointure au domaine
- Activer l’administration à distance avec les consoles d’administration
- Activer la prise en charge de PowerShell en mode sécurité (remotesigned)
- Autoriser l’utilisation de la console Server Manager pour une administration distante
- Configurer la stratégie pour Windows Update
- Installer les mises à jour disponibles depuis Windows Update
- Activer le Remote Desktop mais uniquement pour les clients capables de s’authentifier en Network Local Authentication
Bref, c’est fou ce qu’on arrive à faire avec SCONFIG.EXE. Sous Windows 2008, le nombre de commandes à exécuter pouvait rebuter n’importe qui.
.jpg)
Pour rappel, la documentation relative à SCONFIG.EXE est disponible à cette adresse https://technet.microsoft.com/en-us/library/ee441254(WS.10).aspx. Les nostalgiques de Windows 2008 Core pourront se consoler avec la documentation relative aux commandes NETSH.EXE pour arriver au même résultat https://technet.microsoft.com/en-us/library/ee441257(WS.10).aspx.
.gif){kind=icon}
| Haut de page
Installation du rôle WebServer
Maintenant que les bases du serveur sont posées, continuons avec le composant principal, à savoir le serveur web, toujours dans sa version Core. On va commencer par installer le rôle WebServer, avec DSIM.EXE.
.jpg)
Histoire de se faciliter la vie, on va activer l’administration du site à distance au travers de la console d’administration de IIS et dépendances associées.
.jpg)
Attention DISM.EXE est chatouilleux sur la case des noms des rôles et fonctionnalités !
.jpg)
Il ne reste plus qu’à activer l’administration à distance en mettant à jour une clé de registre.
.jpg)
La configuration du service d’administration à distance pour un démarrage automatique puis de le démarrage de celui-ci va terminer la phase d’installation. Attention au SC CONFIG, il faut bien un espace après le caractère =
.jpg)
| Haut de page
Publication de la CRL
Nous avions laissé notre autorité de certification en pleine configuration. Plus précisément au niveau de la publication des listes de révocations. Pour rappel, l’autorité de certification a été configurée pour :
- Publier la CRL dans le partage CRLDIST$
- Publier la CRL Delta dans le partage CRLDIST$
- Référencer l’emplacement de stockage de la CRL à http://crl.corp.contoso.com
Il ne reste donc plus qu’à mettre en place toute la structure pour accueillir les listes de révocations. Ces opérations seront donc réalisées sur le serveur APP1.CORP.CONTOSO.COM. On va commencer par créer le répertoire qui va héberger nos listes de révocations. Les permissions NTFS seront donc héritées de la racine, donc minimalistes, parfait !
.jpg)
Ce répertoire doit être partagé sous le nom référencé dans l’extension préalablement déclaré dans l’autorité de certification. On va même s’assurer que le partage ne soit accessible en écriture que pour le serveur hébergeant l’autorité de certification.
.jpg)
Passons maintenant à la publication. Il nous faut un répertoire virtuel nommé CRLD à la racine du site web et pointant sur le répertoire CRLD. Attention APPCMD.EXE n’est pas dans un répertoire référencé dans la variable d’environnement Path.
.jpg)
IIS est tellement sécurisé par défaut qu’il interdit le parcours de répertoire. C’est bloquant pour les clients qui viendront télécharger les listes de révocation, donc on rétablit le parcours de répertoire sur le répertoire virtuel.
.jpg)
Subtilité d’IIS, par défaut, il n’autorise pas l’utilisation du Double Escaping dans les noms de fichiers. Dommage, le caractère + tombe dans cette catégorie. Il faut donc désactiver la fonctionnalité.
https://support.microsoft.com/kb/942076/en-us
.jpg)
A ce stade, notre serveur APP1.CORP.CONTOSO.COM est opérationnel pour la publication des listes de révocation. Encore faut-il s’assurer que tout est bien opérationnel. Tant qu’il n’y a pas de certificats révoqués, il n’y a pas encore de liste de révocation. On va donc forcer la publication pour s’assurer du bon fonctionnement. Certes, il est possible d’utiliser la console d’administration mais étant donné qu’on va passer du temps dans CERTUTIL.EXE, autant commencer tout de suite avec la publication de la CRL depuis le serveur DC1.CORP.CONTOSO.COM.
.jpg)
Pour s’en assurer, on peut aller voir le contenu du répertoire sur le serveur APP1.CORP.CONTOSO.COM pour constater la présence des deux listes de révocation.
.jpg)
On peut aussi utiliser notre navigateur Internet pour aller consulter la liste des fichiers mis à disposition mais la meilleure validation reste celle de CERUTIL.EXE.
.jpg)
>> Télécharger gratuitement l'intégralité de cet article <<
| Haut de page