Les administrateurs informatiques travaillent avec Active Directory depuis l’introduction de cette technologie dans Windows 2000 Server. Windows 2000 Server a été lancé le 17 février 2000, mais de nombreux administrateurs ont commencé à travailler avec Active Directory fin 1999, à sa sortie en version RTM, le 15 décembre 1999.
Sécurité d’Active Directory
La sécurité est un thème majeur, car elle recouvre un nombre impressionnant de domaines. Même pour une technologie aussi spécifique que la base de données AD, la sécurité demeure un vaste sujet. Dans cet article, nous allons nous concentrer sur trois domaines précis de la sécurité dans AD DS :
- Sécurisation du trafic LDAP avec SSL/TLS
- Modification de la liste de contrôle d’accès des comptes administratifs
- Mise en place d’une authentification de domaine forte
Sécurisation du trafic LDAP
Pour sécuriser le trafic LDAP avec SSL/TLS, la première étape consiste à installer AD CS. Il est recommandé d’installer ce rôle sur un serveur membre. Avant de mettre en œuvre une ICP, passez du temps à recueillir des informations, à concevoir cette ICP et à planifier. Une fois que vous disposez d’une ICP opérationnelle, vous pouvez fournir un certificat à chaque contrôleur de domaine. Vous pouvez également faire appel à une autorité de certification tierce pour sécuriser les communications LDAP. La clé privée du certificat ne doit pas être assortie d’une forte protection.
De plus, le nom de domaine complet du contrôleur de domaine doit apparaître soit dans le champ Nom commun du champ Objet, soit comme entrée DNS dans l’extension Autre nom de l’objet.
L’utilisation améliorée de la clé doit également inclure l’authentification serveur en option, identificateur d’objet 1.3.6.1.5.5.7.3.1. En activant LDAP sur SSL, la communication LDAP peut se faire sur les ports 389 (LDAP) et 636 (LDAP/SSL). Les requêtes au catalogue global sont effectuées via le port SSL 3269.
La commande certreq.exe permet de créer une nouvelle requête de certificat. Pour créer une requête, exécutez la commande suivante :
- certreq -new request.inf request.req
Le fichier request.inf doit contenir le nom de domaine complet du contrôleur de domaine, ainsi que des informations sur la longueur de la clé et l’heure de la requête. Pour voir un exemple complet du fichier request.inf : http://support.microsoft.com/kb/321051. Le fichier request.req est alors créé et doit être soumis à l’autorité de certification. Après avoir reçu le certificat, traitez la requête avec la commande certreq.exe.
- certreq -accept certnew.cer
Pour vérifier que SSL a bien été activé, l’outil d’administration d’Active Directory ldp.exe vous permet de vous connecter manuellement à l’environnement AD DS. Lancez l’outil ldp.exe et effectuez une nouvelle connexion. Dans le champ Port, spécifiez 636. Si les informations RootDSE s’affichent, LDAP sur SSL a été configuré avec succès.
Modification de la liste de contrôle d’accès
Une autre façon de sécuriser AD DS consiste à modifier la liste de contrôle d’accès des comptes d’utilisateur dotés de privilèges d’administration.
Les listes de contrôle d’accès des comptes d’utilisateur des groupes administratifs sont remplacées toutes les heures par un processus de l’émulateur de contrôleur de domaine principal. Ce processus compare les listes de contrôle d’accès de chaque compte des groupes administratifs et les groupes eux-mêmes à l’objet AdminSDHolder. Dans un domaine appelé contoso.com, l’objet se trouve à l’emplacement suivant : CN=AdminSDHolder,CN=System,DC=Contoso,DC=Com. Toute différence entre le compte et l’objet AdminSDHolder est alors remplacée sur le compte.
Les groupes suivants et les membres de ces groupes sont contrôlés par le processus AdminSDHolder :
- Administrateurs
- Opérateurs de compte
- Éditeurs de certificats
- Opérateurs de sauvegarde
- Administrateurs du domaine
- Administrateurs de l’entreprise
- Opérateurs d’impression
- Administrateurs du schéma
- Opérateurs de serveur
De plus, les comptes d’administrateur et d’utilisateur krbtgt sont également contrôlés indépendamment de leur appartenance à un groupe.
Les comptes protégés par le processus AdminSDHolder peuvent être identifiés par l’attribut de compte adminCount.
Si le compte est protégé, cet attribut prend la valeur 1.
Pour modifier la liste de contrôle d’accès d’un compte protégé par le processus AdminSDHolder, trois étapes doivent être accomplies pour vérifier que la liste n’est pas remplacée.
- Supprimez l’objet de compte de tous les groupes protégés.
- Fixez l’attribut adminCount à 0.
- Activez l’héritage de l’objet de compte.
Remarquez que le fait de mettre adminCount à 0 sans supprimer l’objet des groupes protégés n’empêche pas le processus de remplacer les listes de contrôle d’accès. Le fait de supprimer l’objet des groupes sans modifier l’attribut adminCount ne résout pas la situation.
Une autre solution consiste à modifier l’objet AdminSDHolder de manière à inclure les listes de contrôle d’accès que vous souhaitez appliquer aux comptes d’utilisateur. Si vous incluez les entrées de contrôle d’accès supplémentaires dans l’objet AdminSDHolder, celles-ci seront également incluses lorsque les listes de contrôle d’accès de chaque objet de compte seront comparées. Ceci est utile pour modifier les autorisations de tous les objets des comptes utilisateur d’administration.
Authentification de domaine forte
Un autre aspect de la sécurité d’AD DS consiste à instaurer une authentification de domaine forte dans votre environnement.
Ainsi, les utilisateurs pourront s’authentifier auprès d’Active Directory en utilisant uniquement des protocoles d’authentification solides. Par défaut, Windows Server 2012 accepte les requêtes d’authentification basées sur NTLM et NTLMv2, mais ne répond qu’avec NTLMv2.
Ce paramètre peut être restreint en modifiant le paramètre « Network Security: LAM Manager Authentication Level » (Sécurité réseau : niveau d’authentification Gestionnaire de compte LDAP) dans la stratégie de groupe. Ce paramètre s’applique aux contrôleurs de domaine et peut être réglé sur « Send NTLMv2 response only. Refuse LM and NTLM » (Envoyer une réponse NTLMv2 uniquement. Refuser LM et NTLM). En configurant ainsi ce paramètre, les contrôleurs de domaine ne répondront pas, à moins de recevoir une requête NTLMv2.
Vous trouverez plus d’informations élémentaires sur Active Directory dans notre didacticiel AD pour débutants.
