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

Mise à jour janvier 2021

Microsoft a fait marche arrière, le LDAP signé ne sera pas imposé. Cependant, Microsoft recommande fortement de sécuriser les connexions LDAP.

Cet article est donc toujours d’actualité pour vous aider à identifier et sécuriser vos connexions LDAP.

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 :

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.

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).

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

Import-Module ActiveDirectory $filterHashtable = @{ LogName=’Directory Service’ ID=2887 } Get-ADDomainController -Filter * | ForEach-Object { Write-Host -ForegroundColor green « `nGet LDAP unsigned summary logs on $_ » Get-WinEvent -ComputerName $_ -FilterHashtable $filterHashtable }

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).

#requires -modules GroupPolicy
#requires -modules ActiveDirectory

Import-Module ActiveDirectory
Import-Module GroupPolicy

function Create-LDAPLogsGPO{
Param(
[string]$GpoName = ‘Enable LDAP logs to level basic’,
[int]$DirectoryServiceLogMaxSize = ‘1048576000’ # 524288000‬ = 512MB; 1048576000 = 1GB;2097152000‬ = 2GB
)

$DC = (Get-ADDomainController -Discover -Service ADWS).Name

if($DirectoryServiceLogMaxSize -lt 64000) {
Write-Warning « DirectoryServiceLogMaxSize parameter must be greater than or equal to 64Kb »
return
}

if($DirectoryServiceLogMaxSize%64000 -ne 0) {
Write-Warning « DirectoryServiceLogMaxSize parameter must be a multiple of 64Kb »
return
}

Write-Host -ForegroundColor Green $GpoName ‘- Create GPO’
try {
$myGPO = New-GPO -Name $GpoName -Comment ‘GPO to enable LDAP logs (level basic)’ -Server $DC -ErrorAction Stop

$dcOU = Get-ADOrganizationalUnit -Filter {Name -eq’Domain Controllers’}

Write-Host -ForegroundColor Green « $GpoName – Link GPO to $($dcOU.DistinguishedName) »
New-GPLink -Guid $myGPO.Id -Target $dcOU -LinkEnabled Yes -Server $DC -ErrorAction Stop | Out-Null
}
catch {
Write-Warning $_.Exception.Message
break
}

try {
Write-Host -ForegroundColor Green « $GpoName – Enable LDAP Logs »
Set-GPPrefRegistryValue -Name $GpoName -Context ‘Computer’ -Key ‘HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics’ -ValueName ’16 LDAP Interface Events’ -Value 2 -Type DWord -Action Update -Server $DC -ErrorAction Stop | Out-Null

# convert to hexa
$maxSize = ‘{0:x4}’ -f $DirectoryServiceLogMaxSize
Write-Host -ForegroundColor Green « $GpoName – Increase DirectoryService Log to $DirectoryServiceLogMaxSize »
Set-GPPrefRegistryValue -Name $GpoName -Context ‘Computer’ -Key ‘HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Directory Service’ -ValueName ‘MaxSize’ -Value $maxSize -Type DWord -Action Update -Server $DC -ErrorAction Stop | Out-Null
}
catch {
Write-Warning $_.Exception.Message
}
}

Create-LDAPLogsGPO

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

reg add « HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics » /v « 16 LDAP Interface Events » /t REG_DWORD /d 2

reg add « hKLM\SYSTEM\CurrentControlSet\Services\EventLog\Directory Service » /v « MaxSize » /t REG_DWORD /d 3Ex800000

Il faut ensuite analyser les événements 2889 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