Comment fonctionne ADCS, la PKI Microsoft ? partie 1

LSA AD sécurité

Partie 1 : chiffrement des communications LDAP avec AD sans PKI

Rappel sur le protocole LDAPidentifaction

Par défaut, les communications LDAP entre les applications clientes et les serveurs ne sont pas cryptées. Sans chiffrement, il est possible pour un pirate de capturer le trafic entre les serveurs et les applications, à l’aide d’outils de surveillance et de reniflage de paquets et d’en examiner le contenu.

De même, au cours des communications LDAP simples, les informations sur les noms d’utilisateurs et les mots de passe sont transmises dans des paquets non chiffrés, ce qui peut conduire aux vols d’informations d’authentifications administratives.

 

Initialement le protocole LDAP sécurisé (LDAPS) était utilisé pour les clients « non-Microsoft » tel que Linux, serveur Web, Oracle… Il sert à protéger les informations d’identification car lors d’une liaison LDAP sans certificat, les noms d’utilisateurs et leurs mots de passe peuvent être exposés. Sauf dans le cas de clients non Microsoft et de certaines applications tierces qui ne possèdent pas leurs propres méthodes de communication sécurisées avec les contrôleurs de domaine, l’utilisation du protocole LDAPS n’est pas nécessaire.

La majorité des clients Microsoft ne nécessitent pas l’utilisation du LDAPS. Comme par exemple les composant logiciel enfichable ou encore console MMC, utilisent l’authentification intégrée qui est chiffré. Donc pour de nombreuses applications, le trafic LDAP est chiffré à l’aide des protocoles Kerberos ou NTLM tout simplement.

Les outils d’administration du service de domaine Active Directory utilisent le port 389, mais les communications sont protégées par l’authentification intégrée.

Il n’est pas de possible de forcer les clients à utiliser le protocole LDAPS car le type de connexion dépend de l’application en cours d’utilisation sur la machine cliente.

Il n’est pas possible de forcer tous les clients LDAP non-Microsoft à utiliser LDAPS, sauf en leur interdisant l’accès au contrôleur de domaine via le port TCP 389. Quelle que soit l’application que vous utilisez doit prendre en charge LDAPS. Bien qu’il soit possible de réaliser cette opération, le blocage du port 389 n’est pas recommandé sur les contrôleurs de domaine.

Pour information le port du protocole LDAPS est TCP 636.

PS : Les bonnes pratiques proposent de n’utiliser que du LDAPS en faveur du LDAP afin de mieux sécuriser ses communications sur le réseau.

Prérequis nécessaire au LDAPS en PKI Microsoft ( ADCS)

Le protocole LDAPS exige un certificat X.509 correctement formaté sur les contrôleurs de domaine Windows. Ce certificat permet au service LDAP d’un contrôleur de domaine DC d’écouter et d’accepter automatiquement les connexions SSL LDAP et des catalogues globaux. Le certificat du serveur est utilisé pour authentifier le DC au client lors de l’installation de LDAPS et pour créer le tunnel de communication SSL entre le client et le serveur après l’installation.

 

Pour activer le protocole LDAPS il est nécessaire d’installer un certificat qui respecte les conditions suivantes :

  • Le certificat LDAPS doit être installé dans le magasin de certificats personnel du DC
  • Une clé privée correspondant au certificat doit être présente dans le magasin de certificat et correctement associée au certificat. Cette clé privée ne doit pas avoir la sécurité renforcée de clé privée activée.
  • L’extension « Utilisation avancée de la clé » doit inclure l’identificateur d’authentification du serveur appelé OID (1.3.6.1.5.5.7.3.1)
  • Le nom de domaine complet du contrôleur de domaine doit apparaître soit dans:
  • Le Nom Commun (CN), dans le champ Subject
  • L’entrée DNS dans l’extension Autre nom de l’objet
  • Le certificat doit être délivré par une autorité de certification approuvée par le contrôleur de domaine et les clients LDAPS.

Active Directory Certificate Services – ADCS

Pour l’utilisation des certificats, il vous faut installer le rôle Microsoft Windows AD CS (Active Directory Certificates Services ).

Lors de l’installation d’ADCS, plusieurs choix sont disponibles dans la fenêtre :

  • Autorité de Certification Racine
  • Autorité de Certification Secondaire

 

Description des types des différentes CA (Certificate Autority)  : (cf. http://technet.microsoft.com/fr-fr/library/cc732368(v=ws.10).aspx)

Il n’est pas possible d’installer une CA secondaire sans avoir préalablement installé une CA racine. Après avoir sélectionné Autorité de certification racine, un nouveau choix apparaît :

 

L’infrastructure de clés publiques (dit « PKI ») de Microsoft prend en charge un modèle d’Autorités de certification hiérarchique. Cette hiérarchie de certification offre la sécurité, l’évolutivité, la facilité d’administration et la cohérence avec un nombre croissant de produits commerciaux et d’autres produits d’Autorité de certification.

Une fois la CA installé, il n’est plus possible de changer le nom ou le domaine du serveur. Pour modifier le nom du serveur, il faudra désinstaller l’autorité de certification, changer le nom du serveur, réinstallez l’autorité de certification, et relancez tous les certificats émis par l’’autorité de certification.

 

Hiérarchies d’autorité de certification

Connexion pour les Utilisateurs enregistrés
   

 

logo2 itconsult

Laisser un commentaire