Dans ce second module, on va continuer notre découverte de l'Active Directory en rentrant un peu plus dans le cœur du sujet, notamment regarde ce qui le constitue et les protocoles qu'ils utilisent pour fonctionner.
Dans ce module, on parlera LDAP, DNS, Kerberos, mais aussi on regardera de près les objets que l'on peut créer dans un annuaire et les attributs qu'ils peuvent posséder.
Si le premier module est bien compris, alors n'hésitez pas, continuez avec ce second module.
Les protocoles LDAP, DNS et Kerberos
Après s’être intéressé à la vue d’ensemble d’une infrastructure Active Directory, avec les notions de domaine, d’arbres et de forêts, on va creuser un peu plus dans le fonctionnement de l’Active Directory en s’intéressant à trois protocoles indispensables à son fonctionnement.
Ces trois protocoles sont le LDAP, le DNS et le Kerberos. Pour chacun d’entre eux, nous verrons à quoi ils servent et pourquoi sont-ils si vitaux au bon fonctionnement de l’Active Directory.
Le protocole LDAP (Lightweight Directory Access Protocol) est un protocole qui permet de gérer des annuaires, notamment grâce à des requêtes d’interrogations et de modification de la base d’informations. En fait, l’Active Directory est un annuaire LDAP.
Les communications LDAP s’effectuent sur le port 389, en TCP, du contrôleur de domaine cible.
Il existe une déclinaison du protocole LDAP appelée LDAPS (LDAP over SSL) est qui apporte une couche de sécurité supplémentaire avec du chiffrement.
L’annuaire LDAP correspond directement à l’Active Directory, il contient donc un ensemble d’unités d’organisation qui forment l’arborescence générale. Ensuite, on trouve tous les différents types d’objets classiques : utilisateurs, ordinateurs, groupes, contrôleurs de domaine, voir même serveurs et imprimantes.
Pour chaque classe d’objets, il stocke les attributs correspondants et les différentes valeurs de ces attributs pour chaque instance d’un objet. Par exemple, il va stocker toutes les informations relatives à un utilisateur (nom, prénom, description, mot de passe, adresse e-mail, etc.).
Un annuaire est un ensemble d’entrées, ces entrées étant elles-mêmes constituées de plusieurs attributs. De son côté, un attribut est bien spécifique et dispose d’un nom qui lui est propre, d’un type et d’une ou plusieurs valeurs.
Chaque entrée dispose d’un identifiant unique qui permet de l’identifier rapidement, de la même manière que l’on utilise les identifiants dans les bases de données pour identifier rapidement une ligne.
L’identifiant unique d’un objet est appelé GUID qui est « l’identificateur unique global ». Par ailleurs, un nom unique (DN – Distinguished Name) est attribué à chaque objet, et il se compose du nom de domaine auquel appartient l’objet ainsi que du chemin complet pour accéder à cet objet dans l’annuaire (le chemin à suivre dans l’arborescence d’unités d’organisation pour arriver jusqu’à cet objet).
Par exemple, le chemin d’accès suivant, correspondant à un objet « utilisateur » nommé « Florian », du domaine « it-connect.local » et étant stocké dans une unité d’organisation (OU) nommée « informatique » contenant elle-même une OU nommée « system » :
Se traduira en chemin LDAP par :
Ainsi, la chaîne ci-dessus correspondra au Distinguished Name (unique) de l’objet.
Dans un chemin LDAP vers un objet, on trouve toujours la présence du domaine sous la forme « dc=it-connect,dc=local », correspondant à « it-connect.local » dans cet exemple.
Exemple de DistinguishedName
L’importance du protocole DNS n’est plus à prouver, nous l’utilisons chaque jour des centaines de fois, notamment pour la navigation internet et à chaque fois que l’on communique avec un serveur, pour ne citer que ces deux cas de figure.
Il en est de même pour l’Active Directory qui adore s’appuyer sur le DNS… D’ailleurs, sans le DNS l’Active Directory ne fonctionnera pas. C’est d’ailleurs pour ça que lors de la mise en place d’un domaine, l’installation du serveur DNS est proposée.
Le protocole DNS est utilisé pour la résolution des noms, ce qui permet aux postes clients de localiser les contrôleurs de domaine au sein de votre système d’information. De la même manière, lorsque l’on souhaite joindre un client au domaine, on utilise un nom comme « it-connect.local », ce qui implique une requête DNS pour savoir quelle est l’adresse IP correspondante à ce nom, vous serez alors redirigé vers votre contrôleur de domaine qui traitera la requête.
Le serveur DNS crée une zone correspondante à votre domaine et enregistre de nombreux enregistrements. Il y a bien sûr un enregistrement (de type A) pour chaque contrôleur de domaine, mais il existe une multitude d’enregistrements annexes, indispensable au bon fonctionnement de l’Active Directory :
Ne vous inquiétez pas, concernant les notions abordées ci-dessus et qui vous sont inconnues, nous les aborderons plus loin dans ce cours.
Il est même possible que l’ensemble des ordinateurs joint au domaine soit enregistré au sein du DNS, si vous le permettez. Ainsi, un ordinateur de l’entreprise pourra être joint via : pc-01.it-connect.local s’il se nomme « pc-01 ».
Le serveur DNS peut être sur le contrôleur de domaine ou sur un autre serveur DNS du système d’information. Ce serveur DNS peut être sous Windows mais aussi sous Linux en utilisant le paquet « Bind 9 » qui requiert alors une configuration particulière.
Les contrôleurs de domaine doivent être capables d’écrire dans la zone DNS qui leur correspond, ceci dans le but de gérer les enregistrements dynamiquement. Lors de la création d’un domaine, tous les enregistrements nécessaires au bon fonctionnement du système seront créés automatiquement (je suis sûr que ça vous rassure).
Le protocole Kerberos est l’acteur principal de l’authentification au sein d’un domaine, il n’intervient ni dans l’annuaire ni dans la résolution de noms.
Le protocole Kerberos est un protocole mature, qui est aujourd’hui en version 5. Il assure l’authentification de manière sécurisée avec un mécanisme de distribution de clés.
Chaque contrôleur de domaine dispose d’un service de distribution de clés de sécurité, appelé « Centre de distribution de clés (KDC) » et qui réalise deux services :
Ce service distribue des tickets aux clients pour la connexion de la machine du domaine. En fait, quand un client veut accéder à un ordinateur, il contacte le service d’émission de tickets correspondant au domaine auquel appartient l’ordinateur, il présente un TGT, et effectue sa demande pour obtenir un ticket d’accès sur cet ordinateur. On parlera alors de l’obtention d’un ticket TGS.
Les deux services décrits précédemment ont chacun des tâches et un processus précis. Ce mécanisme d’authentification est inévitable pour accéder aux ressources d’un domaine. Sans Kerberos, il n’y aura plus d’authentification, ce qui déclenchera des problèmes d’authentifications et d’accès.
Si le centre de distribution de clés (KDC) est indisponible depuis le réseau, l’Active Directory sera ensuite indisponible également, et le contrôleur de domaine ne contrôlera plus longtemps le domaine.
Le ticket Kerberos distribué contient de nombreuses informations qui permettent d’identifier l’élément auquel est attribué ce ticket. Par exemple, pour un utilisateur, il sera possible de savoir son nom, son mot de passe, l’identité du poste initial ainsi que la durée de validité du ticket et sa date d’expiration.
Par ailleurs, les tickets TGS et TGT contiennent une clé de session qui permet de chiffrer les communications suivantes afin de sécuriser les échanges.
En résumé, vous devez garder en tête que ces trois protocoles sont indispensables au bon fonctionnement de l’Active Directory. Ils assurent des fonctions critiques :