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.
La configuration du ldap sur le port 389 est quelque chose de relativement obscure, vu qu'il existe plusieurs méthodes d'authentification dans LDAP et que si l'établissement de la connexion est en mode non sécurisé, le client peut demander à basculer en mode sécurisé avec StartTls. Il est donc possible de mettre en place des connexions sécurisés ou non sur le port 389 (ou 3268 pour le catalogue global).
Si vous utilisez des connexions LDAPS sur le port 636 ou 3269(catalogue global), la sécurité est assurée par l'utilisation de SSL (ou plutôt de TLS son successeur) dès la connexion.
L'authentification vers les services LDAP peut être faite en mode simple ou avec SASL qui permet la négociation. L'authentification en mode simple correspond à l'envoi du compte et du mot de passe en texte clair sur le réseau. L'authentification SASL améliore cela, il faut activer également la signature pour éviter des attaques de type Man In The Middle.
Le sujet n'est pas réellement une nouveauté, des annonces sur le renforcement de la sécurité avaient été faites concernant les mises à jour de mars 2020 : https://support.microsoft.com/en-us/topic/2020-ldap-channel-binding-and-ldap-signing-requirements-for-windows-kb4520412-ef185fb8-00f7-167d-744c-f299a66fc00a . Si au départ la mise à jour devait appliquer le paramètre obligatoire de la signature pour l'authentification LDAP, sa mise en application a été finalement laissé aux choix de chaque client.
Néanmoins, si des recommandations existent, la mise en œuvre appartient aux administrateurs système de l'entreprise. Selon la taille et les solutions hétérogènes en place, il peut être délicat de mettre en œuvre sans impacter l'existant.
Avant d'appliquer les stratégies afin de renforcer les connexions LDAP, il est recommandé de réaliser un audit des connexions non sécurisées. Cela vous permettra d'avoir une vision des connexions non sécurisées vers votre annuaire LDAP.
Ce type d'information n'est pas collecté par défaut, il faut activer un niveau de collecte plus verbeux sur l'annuaire AD, en modifiant le registre.
La commande suivante permet d'activer la journalisation des événements :
Reg Ajouter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 événements d'interface LDAP" /t REG_DWORD /d 2
Il n'est pas utile de redémarrer les contrôleurs de domaine pour la prise en charge des événements.
Nous allons utiliser l'outil LDAP (ldp.exe) afin d'ouvrir une connexion sur le port 389 de notre contrôleur de domaine :
.
Après l'ouverture de la connexion, nous allons nous authentifier :
En effectuant un filtre sur les événements « 2889 » sur le journal « Directory Service », nous pouvons constater, l'événement concernant le compte utilisé pour le test ainsi que l'adresse IP du client LDAP.
Le type de liaison est 0, pour une authentiquassions sans signature SASL. Le type de liaison 1 désigne une authentification avec un compte et un mot de passe en texte clair sur le réseau.
En utilisant un outil comme WireShark, le problème ne fait pas de doute :
Il est donc recommandé d'activer ses événements et d'analyser les résultats régulièrement. Les équipements réseaux tels que les copieurs ou autres peuvent faire des appels non sécurisés vers votre annuaire.
Le script PowerShell « Query-InsecureLDAPBinds.ps1 » peut vous aider à identifier ces connexions.
