La désactivation par Microsoft du LDAP non signé menace les connexions non chiffrées à Active Directory

2020-02-07T16:05:31+01:00février 5th, 2020|Blog|0 Comments

Quels impacts pour mon système d’information ?

Avant de rentrer dans les détails techniques de cette future mise à jour Microsoft, il convient d’en indiquer les conséquences si rien n’est fait : 

Les applications ayant une adhérence avec AD ou Active Directory Lightweight Directory Services (ADLDS) via le protocole LDAP ne fonctionneront plus. 

Des examples d’utilisation du LDAP dans les entreprises ? En voici :

  • applications métiers (ERP, CRM)
  • fournisseurs d’identités (IdP) pour l’accès à vos applications cloud ou internes
  • application d’infrastructure, de supervision, de ticketing
  • toute application, code, script, macro Excel utilisant LDAP

Note : les applications utilisant de l’authentification non LDAP tels que Kerberos, NTLM, WIA, OpenIDConnect, SAML, Radius ou les applications full Cloud sans adhérence avec AD/ADLDS ne sont pas impactées. Les CMDlets PowserShell tel que Get-ADUser ne sont pas non plus impactées.

Microsoft sécurise le protocole LDAP courant 2020

Microsoft a annoncé du changement dans le LDAP signing et LDAP channel binding pour les services de domaine Active Directory (ADDS) et Active Directory Lightweight Directory Services (ADLDS). Par défaut ces services autorisent la communication en mode non signé.

En accord avec le bulletin de sécurité ADV190023, une vulnérabilité rendant possible une élévation de privilège existe dans Microsoft Windows. Cette vulnérabilité pourrait permettre une attaque man-in-the-middle de transmettre une requête authentification à un serveur Windows LDAP (ADDS/ADLDS) qui ne requiert pas la signature sur les connexions entrantes.

Le LDAP signing fait référence à l’obligation de signer les communications LDAP, donc de garantir l’intégrité des données échangées, c’est à dire non modifiées entre le client et le serveur. Cette intégrité des données est mise en place au moyen du LDAP sécurisé (LDAPS ou LDAP avec STARTTLS) reposant sur un certificat et les notions de clé privée/clé publique.

Bien que cela ne soit pas forcément mis en avant par Microsoft, le LDAPS permet le chiffrement des données échangées permettant de garantir leur confidentialité en complément de l’intégrité.

Le LDAP Channel binding renforce la sécurité d’une connexion LDAPS pour empêcher une attaque man-in-the-middle l’homme du milieu (CVE-2017-8563) en ajoutant la prise en charge de la protection d’authentification étendue SSPI (EAP).

Fonctionnement d’une authentification LDAP non sécurisée

L’authentification auprès d’un annuaire LDAP s’exécute au travers d’un LDAP binding. C’est un ensemble d’opérations pour authentifier et autoriser les clients sur un serveur LDAP (en l’occurrence un contrôleur de domaine). Dans le contexte présent, un client peut-être une application, un serveur ou l’utilisateur souhaitant se connecter au serveur LDAP.

Avec les informations d’authentification, les clients envoient la configuration ou les paramètres de connexion LDAP (tels que la signature requise) à utiliser dans les messages au sein de cette même connexion.

Il existe deux types de liaison LDAP :

  • Simple Bind : le client s’authentifie sur le serveur LDAP en soumettant le login et le mot de passe sous forme de texte en clair
  • Simple Authentication and Security Layer (SASL) : SASL permet différentes options d’authentification qui ne nécessitent pas de transmission de mot de passe en texte clair. comme NTLM ou Kerberos. Les produits Microsoft utilisent uniquement le type de liaison SASL

Signature LDAP obligatoire à partir de mi 2020

Par défaut, les deux types de liaisons présentés, Simple Bind et SASL, utilisent LDAP en non signé et ne garantissent pas l’intégrité des échanges LDAP (ni la confidentialité pour le Simple Bind).

Microsoft souhaite donc imposer la signature. Dans un premier temps, en mars 2020, Microsoft déclenchera une mise à jour, non impactante dans l’immédiat:

Windows Updates in March 2020 add new audit events, additional logging, and a remapping of Group Policy values that will enable hardening LDAP Channel Binding and LDAP Signing. The March 2020 updates do not make changes to LDAP signing or channel binding policies or their registry equivalent on new or existing domain controllers.

Cependant, en mi 2020 (auparavant indiquée comme mars 2020 mais désormais repoussé à ‘seconde moitié de l’année 2020’), Microsoft publiera une mise à jour de sécurité pour garantir l’intégrité de ces échanges. Cela impliquera de rejeter toutes les connexions entrantes sur les contrôleurs de domaine utilisant LDAP non signé. Concrètement, l’impact est principalement relative à la clé HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\ldapserverintegrity présente sur les contrôleurs de domaine :

ValeurComportement actuelComportement après la mise à jour
non définisignature non requisesignature requise
0signature non requisesignature non requise
1signature non requisesignature requise
2signature requisesignature requise

Pour résumé, après la mise à jour courant 2020, la signature via LDAP devient un prérequis si vous avez un contrôleur de domaine.

Auditer vos applications

Par défaut, l’AD journalise seulement un résumé -par tranche de 24 heures – des authentifications LDAP non signés. Cela est présent dans l’événement 2887 sur les contrôleurs de domaine (Applications and Services > Directory Service).

Logs dans Directory Service

 

Détails du log 2887

Pour exécuter une recherche sur tous vos contrôleurs de domaine, l’usage de PowerShell est recommandée :

Cependant, l’analyse de l’événement 2887 seul n’est pas suffisant car:

  • cela ne donne pas d’informations sur la machine / utilisateur qui s’est connecté
  • en fonction de votre configuration de logs, les logs peuvent avoir été écrasés par des logs plus récents (par défaut, la taille de ce journal est de 1Mo, ce qui est très faible).

Pour cela, il est nécessaire :

  • d’activer les logs avancées
  • augmenter la taille du journal Directory Service

Pour faciliter cette tâche, vous pouvez utiliser le script PowerShell ci-dessous sur un contrôleur de domaine. Cela créé la GPO « Enable LDAP logs to level basic » pour activer les logs LDAP et augmenter les logs Directory Service à 1 Go. La GPO est appliqué sur l’OU Domain Controllers.

Les contrôleurs de domaine vont appliquer la GPO dans les 5 minutes après la création (temps de refresh des GPO sur les DC).

Si vous ne souhaitez pas utiliser ce script, vous pouvez exécuter ces commandes sur chaque contrôleur de domaine :

Il faut ensuite analyser les événements 2888 sur les contrôleurs de domaine (Applications and Services > Directory Service) pour avoir le détail de cette connexion (IP source, utilisateur).

Et après ?

Une fois les serveurs/applications/utilisateurs identifiés, il faut :

  • mettre en place le LDAPS sur vos contrôleurs de domaine
  • configurer l’application pour utiliser le LDAPS ou LDAP/STARTTLS
  • configurer les contrôleurs de domaine et les membres du domaine pour imposer la signature (chose qui sera faite par la mise à jour courant 2020)

Besoin d’aide ?

Aduneo vous assiste pour être conforme à cette nouveauté, contactez nous à contact [at] aduneo.com.

Auteur : Bastien