Microsoft a mis en place une nouvelle version de LAPS qui remplace l'ancien LAPS hérité. La solution n'est pas juste une mise à jour, mais un nouveau produit. En effet, elle utilise de nouveaux attributs dans l'annuaire Active Directory et offre des possibilités nouvelles dont entre autres :
Si vous utilisez les préférences dans les stratégies de groupe, il est possible d'utiliser des variables pour cibler certains éléments. Pour accéder aux variables, il suffit d'appuyer sur la touche « F3 » lorsque vous êtes dans le champ du paramètre pour ouvrir la liste des paramètres disponibles.
La stratégie de verrouillage des comptes permet de se protéger contre des tentatives de connexion abusives. La stratégie définit le nombre d'erreurs dans un intervalle de temps précis. Par exemple, 3 erreurs de mot de passe en 10 minutes provoquent le verrouillage du compte pendant 30 minutes.
Comme pour la connexion à des partages, il est possible de déployer des imprimantes via les stratégies de groupe. Si vous souhaitez déployer des imprimantes, il est nécessaire de gérer la partie installation du pilote. En effet une imprimante partagée peut être vue en 2 parties. La première est la file d'attente d'impression gérée par le serveur. La 2ème partie est le pilote d'impression qui devra s'installer sur le poste cible. Par défaut, les comptes utilisateurs du domaine ne peuvent pas installer de pilote.
Nous avons vu dans le chapitre précédent qu'il est possible d'utiliser les scripts d'ouverture de session pour connecter des lecteurs réseaux spécifiques à chaque utilisateur. Depuis Windows 2008, il existe une autre méthode permettant de gérer ce type de paramètre à l'aide des préférences dans les stratégies de groupe. Les préférences ne sont applicables en natif que sur les postes client en Windows Vista ou supérieurs.
Nous allons dans ce premier exemple modifier la stratégie de mot de passe définit par défaut dans un domaine. L'option la plus souvent utilisée est de modifier les paramètres de la stratégie de groupe « Default Domain Policy ». Si vous définissez une stratégie de mot de passe sur une unité d'organisation contenant des objets ordinateurs, la stratégie que vous avez définie remplacera la stratégie pour les comptes créés localement sur la machine (voir SAM local), mais les comptes du domaine ne sont pas impactés.
Il est possible de restreindre l'application d'une stratégie de groupe à l'aide de filtres. Dans la partie « étendue » de la stratégie de groupe, en dessous des liaisons, vous retrouvez « filtrage de sécurité ». Par défaut il est défini sur « utilisateurs authentifiés » qui est un groupe dynamique contenant tous les utilisateurs et ordinateurs authentifiés. Il est possible de supprimer ce filtrage pour le remplacer par un groupe Active Directory, dans ce cas seul les membres des groupes seront concernés :
La console de gestion des stratégies de groupes est installée par défaut avec les services Active Directory Domain Services depuis Windows 2008.
Vous pouvez y accéder par le gestionnaire de serveur dans le menu déroulant « outils » ou dans les outils d'administrations du panneau de configuration ou en saisissant la commande « gpmc.msc ».
Avant la création d'Active Directory, la gestion des utilisateurs et des ressources se faisait à l'aide d'un ou plusieurs domaines « NT » (New Technology). Une entreprise présente sur plusieurs sites disposait souvent d'un domaine pour chacun de ses sites. Dans un domaine NT, il y avait un serveur qui était accessible en écriture, le « Primary Domain Controller », les autres « Backup Domain Controller » ne sont que des copies en lecture de l'annuaire et pouvait assurer le rôle d'authentification de l'utilisateur.
Nous avons déjà vu l'importance de sécurisé les connexions LDAP.
Le blocage de l'authentification simple LDAP, l'exigence d'utiliser une signature avec l'authentification SASL, permet d'améliorer la sécurité de l'authentification, mais ne chiffre pas la connexion vers le contrôleur de domaine et les réponses aux requêtes.
Nous avons vu dans la première partie, comment activer les audits afin de rechercher les connexions LDAP non sécurisées sur le port 389(ou 3268 pour le catalogue global).
Lorsque vous avez détecté et corrigé les connexions non sécurisées, vous pouvez activer des paramètres pour les postes clients Windows et pour les contrôleurs de domaine afin d'exiger la signature. Cela supprime les authentifications simples et SASL non signé.
Il est recommandé de configurer les clients avant la mise en œuvre du paramètre sur les contrôleurs de domaine.
Il est fréquent dans nos environnements de connecter des applications tierces ou des équipements afin de récupérer les informations dans notre annuaire Active Directory.
C'est le cas par exemple de copieurs multifonctions qui dispose d'option de scan vers une adresse de messagerie électronique.
Dans ce cas, vous allez configurer le copieur vers le port 389 de votre contrôleur de domaine. Il vous faudra indiquer un compte et un mot de passe pour exécuter des recherches.
Nous avons déjà introduit l'administration par les rôles et entre autres les rôles d'administrateur et de gestionnaire de certificat.
Nous allons parler d'un rôle qui n'est pas forcément utile dans toutes les structures. L'agent d'inscriptions, souvent membre des équipes techniques est une personne pouvant créer des certificats pour d'autres utilisateurs.
Nous allons créer un groupe de domaine local, afin de gérer les autorisations. Il est recommandé d'utiliser le modèle AGDLP déjà évoqué dans les articles précédents.
L'administrateur d'une autorité de certification AD CS, peut affecter des rôles aux utilisateurs. Un utilisateur pourrait avoir plusieurs rôles au sein AD CS. Il est recommandé de séparer les rôles. Il est également possible d'activer la séparation des rôles aux niveaux de l'autorité de certification.
Avant d'activer la séparation des rôles, chaque utilisateur ne doit disposer que d'un seul rôle. Un utilisateur qui dispose de plusieurs rôles pourrait être bloqué dans ses tâches d'administrations.
Les gestionnaires de certificats ont entre autres pour missions :
Emettre, approuver ou refuser des certificats
Révoquer des certificats émis
Il est recommandé d'affecter la permission d'émettre et de gérer les certificats à un groupe Active Directory et de gérer les membres du groupe en ajoutant les comptes autorisés.
Il est recommandé d'utiliser le modèle AGDLP.
Il est possible de créer plusieurs groupes différents de gestionnaire de certificats et de limiter les modèles de certificats gérés par chaque groupe.
Ou sont stocké les informations de l'autorité de certification d'entreprise dans Active Directory ?
Dans une autorité de certification d'entreprise, intégré aux services de domaine Active Directory, il existe un certain nombre d'informations enregistré dans l'annuaire.
Parmi ses éléments, nous retrouvons entre autres :
La gestion des permissions sur un environnement AD CS est un élément crucial. L'utilisation d'un produit comme AD CS commence souvent par le besoin de répondre à une exigence applicative d'utilisation de certificat, comme un certificat pour un serveur Web.
Un certificat peut permettre l'authentification d'un client, la sécurité apportée à son utilisation a le même niveau d'importance que celle apporté à votre annuaire Active Directory et à vos protocoles d'authentification.
Dans un domaine Active Directory les comptes membres du groupe « admins du domaine » ou « administrateurs de l'entreprise » peuvent ajouter un ordinateur à un domaine.
Il est possible de déléguer l'autorisation de joindre un ordinateur au domaine à des personnes ou des groupes. Pour ce faire il faut autoriser le groupe ou l'utilisateur à créer des objets ordinateurs dans le domaine.
L'inscription automatique de certificat permet de générer des certificats utilisateurs ou ordinateurs dans le magasin personnel du demandeur sans qu'une personne n'en fasse spécifiquement une demande.
L'utilisation de l'inscription automatique n'est valable que pour une autorité de certification d'entreprise donc intégrée à Active Directory.
Pour diffuser des certificats automatiquement, il faut :
Selon votre politique d'émission de certificat, il peut être intéressant de mettre en place un processus d'approbation avant de délivrer un certificat. La demande d'approbation est une option définit au niveau du modèle de certificat. Une autorité peut donc émettre certains certificats sans approbation alors que d'autres modèles l'exigent. L'approbation doit être réalisée par une personne ayant les permissions de gestion des certificats sur AD CS.
La révocation d'un certificat consiste à ajouter le numéro de série d'un certificat dans une liste de révocation qui est publié et disponible aux différents systèmes qui ont besoin de vérifier la validité du certificat. Un certificat révoqué ne devrait donc plus être utilisable si l'application gère la consultation des listes de révocations ou si elle interroge un répondeur OCSP.
Il existe des situations dans lesquelles le certificat doit être révoqué. La liste suivante, non-exhaustive illustre des motifs devant entraîner la révocation d'un certificat :
OpenSSL est un outil pratique permettant de créer des demandes et de manipuler des certificats. Il est largement utilisé dans les environnements Linux/ Apache, mais il est également possible de l'installer sur Windows.
Dans cet exemple, nous allons extraire la clé privée et le certificat d'un fichier #PKCS12 avec une extension .pfx.
La première commande avec l'option « -nokeys » permet d'exclure la clé privée de la ligne d'export.
Pour restaurer une autorité de certification AD CS, vous pouvez utiliser la console de gestion de l'autorité de certification (%windir%\system32\certsrv.msc) .
Cliquez sur « OK » lors du message d'avertissement vous indiquant que les services AD CS doivent être arrêté pendant la restauration.
