J'avais déjà écrit quelques articles sur le service de certificats Active Directory, comme une installation simple d'une autorité racine d'entreprise. Ce scénario peut sembler suffisant pour apprendre le produit et réaliser quelques petites opérations. Dans un environnement plus complexe et si l'on souhaite rester un peu plus dans les bonnes pratiques, il est préférable d'avoir une autorité racine autonome qui fournit un certificat à l'autorité secondaire d'entreprise.
Nous allons revenir sur la session sur le serveur « CA-ADCSSub », hébergeant l'autorité secondaire d'entreprise. Nous ouvrons la console de l'autorité de certification « certsrv.msc ». Faites un clic droit sur le nom de l'autorité, puis « toutes les tâches » et « installer un certificat d'autorité de certification ».
Sélectionner le certificat de l'autorité secondaire que vous avez créé puis cliquez sur « ouvrir ».
Dans l'étape précédente, nous avons utilisé l'assistant de configuration des services AD CS, afin de configurer une autorité secondaire d'entreprise. Lors de la configuration, nous avons généré, un fichier de requête à soumettre à l'autorité racine afin de générer le certificat de l'autorité secondaire.
Le fichier en question se trouve sur la racine du disque « c : » de notre serveur « CA-ADCSSub ».
Par défaut, AD CS utilise des fichiers avec une extension « .req ».
Après avoir installé le rôle AD CS, il faudra exécuter l'assistant de configuration des services de certificats Active Directory, proposé dans les tâches post déploiement sur le gestionnaire de serveur.
Sur la page « Informations d'identification », conserver le compte de la session qui dispose des droits d'administrations. Par défaut, il s'agit du compte « administrateur » sur la version française. Cliquez sur « suivant ».
Nous allons configurer un serveur en tant qu'autorité de certification secondaire d'entreprise. Cette autorité sera en mesure de créer différents types de certificats, comme des certificats pour des services Web.
Le serveur qui détiendra le rôle est « CA-ADCSSub ». Il sera membre du domaine Active Directory et dispose d'une adresse IP fixe.
Dans ce chapitre, nous allons installer une autorité de certification secondaire d'entreprise. Le certificat de l'autorité secondaire sera délivré par notre autorité racine autonome AD CS. L'utilisation d'un produit tierce en tant qu'autorité racine est tout à fait possible. Ce type de configuration ne sera pas détaillé dans ces articles.
Nous avons vu dans les étapes précédentes, la mise en œuvre d'une autorité de certification racine autonome avec AD CS. Lors de l'installation, nous avons généré le certificat de l'autorité. Pour que les postes de travails et les serveurs de votre domaine Active Directory acceptent de faire confiance à cette autorité, il est nécessaire d'ajouter le certificat de l'autorité racine dans le magasin des autorités racine de confiance des différents postes.
Dans les étapes précédentes, nous avions installé une autorité de certification racine autonome. Cette autorité n'est pas accessible directement sur le réseau. Il nous faut maintenant configurer un site IIS sur un autre serveur afin de rendre disponible le certificat de l'autorité racine ainsi que la liste de révocation. Nous avions vu dans une étape précédente comment récupérer ces deux fichiers.
Pour modifier la durée de vie des certificats dans une autorité de certification Microsoft, il faut modifier une clé de registre. Avec une autorité de certification d'entreprise intégrée dans un domaine Active Directory, la durée de vie d'un certificat dépend du modèle de certificat sans pouvoir excéder la durée de vie du certificat de l'autorité ni de la durée de la clé de registre suivante.
Dans une autorité autonome, vous n'avez pas de modèle de certificats et vous ne pouvez donc pas définir de durée de certificat depuis un modèle.
Vous pouvez générer une nouvelle liste de révocation, même si la précédente n'a pas encore expiré. Il est même préférable de la renouveler et de la rendre disponible avant l'expiration.
Pour générer la liste de révocation, ouvrez la console « autorité de certificat », faites un clic droit sur « certificats révoqués », puis « toutes les tâches » et « publier ».
Parmi les éléments importants dans la configuration d'une autorité de certification, il y a les extensions. Ces extensions sont généralement présentes sur les certificats que l'autorité émet et permettent de définir un lien vers le certificat de l'autorité racine ainsi qu'un lien vers la liste des certificats révoqués. Le principe de configuration est le même pour une autorité racine autonome ou pour une autorité d'entreprise. Néanmoins certains éléments, comme la publication de la liste de révocation dans Active Directory n'est exploitable que dans une autorité d'entreprise.
Après avoir installé le rôle AD CS, nous allons configurer l'autorité et générer le certificat de l'autorité racine. Dans le gestionnaire de serveur, l'étape « installation de fonctionnalité » devrait être terminé et une étape de configuration post-déploiement vous est proposé. Cliquez sur « Configurer les services de certificats Active Directory ».
Dans ce chapitre, nous allons voir les étapes de l'installation d'une autorité racine autonome. Une autorité de certification autonome se gère différemment d'une autorité d'entreprise. Dans le cas d'une autorité d'entreprise, vous avez la possibilité de gérer des modèles de certificats. Les modèles dans les autorités d'entreprise sont stockés dans l'annuaire Active Directory. Dans le cas d'une autorité autonome, vous ne disposez pas de ses possibilités. Vous verrez également que certains paramètres doivent être modifiés directement dans le registre.
Dans notre exemple et pour les articles à venir, nous disposons de deux contrôleurs de domaine lab2016dc1 et lab2019dc2. Le nom de domaine du lab est « htrab.lan ».
Nous allons créer une autorité racine « CA-Root » autonome et déconnectée du réseau. Nous choisissons une durée de vie du certificat de l'autorité racine de 30 ans et la durée de vie des CRL de 3 mois. L'autorité racine n'aura d'autre but que de générer des certificats pour l'autorité secondaire d'entreprise AD CS.
Avant de débuter, il faudra répondre à quelques questions. Le premier élément est d'identifier les types de certificats et l'utilisation qui en sera faites.
Il faudra définir si vous devez publier en format web, la liste de révocation et les informations de l'autorité (AIA), ou si la publication dans l'AD, existant par défaut est suffisante pour votre usage.
Dans cet article, nous allons voir le suivi du verrouillage de compte par suite d'une succession de tentatives de connexion avec un mot de passe erroné.
L'environnement de test est composé de deux contrôleurs de domaine : LAB2016dc1 et LAB2019DC2 et d'un poste client Windows 10 LABCL1. Tous les rôles FSMO sont gérés par LAB2016DC1.
La stratégie de verrouillage a été définie dans la GPO « Default Domain Policy ». Nous avons défini un verrouillage de 10 minutes si pendant une durée de 10 minutes, 3 mauvais mot de passe sont saisie.
Vous trouverez dans ce post quelques informations sur l'installation des DC sous Windows server 2022.
Avant de promouvoir un nouveau contrôleur de domaine, il faut généralement mettre à jour le schéma Active Directory.
Depuis 2012 et la fin de « dcpromo.exe », l'assistant de configuration des services Active Directory effectue la mise à jour automatiquement lors de la promotion.
La commande suivante permet de connaître la version du schéma :
Microsoft a annoncé la disponibilité générale de la nouvelle version de Windows Server 2022.
Si les nouveautés dans les services Active Directory ne sont pas très visibles, la sécurité a été renforcée dans cette nouvelle version.
Une innovation sur la partie stockage permet d'utiliser des disques SSD en tant que cache de stockage pour les serveurs autonomes (HyperV par exemple). Vous trouverez un article sur le sujet dans les liens suivant :
Suite à la vulnérabilité CVE-2021-34527, il est recommandé de désactiver le service spooler sur les serveurs Windows qui n’en n’ont pas l’utilité et en particulier sur les contrôleurs de domaines.
Vous trouverez plus d’information dans les articles suivants :
Cette option introduite dans les services DNS sur Windows Server 2016, réduit les risques d'attaques par amplification DNS. Ce type d'attaque en déni de service, vise à envoyer un nombre important de requêtes DNS en modifiant l'IP réseau de la source. Le réseau victime peut recevoir une quantité importante d
Nous avons vu dans un article précédent, comment activer DNSSEC sur les zones DNS de votre domaine Active Directory. Nous avons également vu le rôle joué par les ancres de confiance pour la signature des enregistrements DNS.
Dans cette article nous allons voir comment mettre à jour les ancres de confiance publié par l'IANA concernant la racine d'internet. Le lien suivant https://data.iana.org/root-anchors/root-anchors.xml permet de retrouver les ancres de confiances.
Dans l'article précédent, nous avons vu, comment activer DNSSEC sur vos zones DNS internes intégrées à Active Directory. Nous avons vu également, comment configurer les clients DNS du domaine afin d'exiger la vérification des signatures DNS.
Lors de la signature de la zone, nous avons défini un de nos contrôleurs de domaine en tant que maître des clés.
DNSSec est un mécanisme de sécurité permettant de signer les enregistrements DNS d'une zone afin de protéger votre environnement. La signature permet de réduire le risque de d'empoisonnement du cache du client DNS et d'éviter certaines attaques de type Man In The Middle.
DNSSEC est comparable à une autorité de certification qui utiliserait des certificats pour faire de la signature.
