Linee guida per l’abilitazione di LDAP Channel Binding e LDAP Signing

In Agosto 2019 Microsoft ha pubblicato un Security Advisory chiamato ADV190023 | Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing in cui avvisava della necessità di aumentare la sicurezza delle comunicazioni tra i client LDAP e i domain controller di Active Directory. Le configurazioni predefinite relative all’LDAP channel binding e all’LDAP signing  permettono infatti di sfruttare delle vulnerabilità e poter fare elevazione dei privilegi sui domain controller.

Per questo motivo a marzo 2020 verrà rilasciata una patch di sicurezza che impatterà sul protocollo LDAP di Windows Server con ruoli di AD DS (Domain Controller) o AD LDS (Active Directory Lightweight Directory Services) e che interesserà i seguenti sistemi operativi:

  • Windows 10, versione 1909
  • Windows 10, versione 1903
  • Windows 10, versione 1809
  • Windows Server 2019, tutte le versioni
  • Windows 10, versione 1803
  • Windows 10, versione 1709
  • Windows 10, versione 1703
  • Windows 10, versione 1607
  • Windows Server 2016
  • Windows 10
  • Windows 8.1
  • Windows Server 2012 R2
  • Windows Server 2012
  • Windows 7 Service Pack 1
  • Windows Server 2008 R2 Service Pack 1
  • Windows Server 2008 Service Pack 2

Microsoft consiglia agli amministratori di apportare le modifiche di protezione avanzata descritte nel Security Advisory ADV190023 poiché quando si utilizzano le impostazioni predefinite, si verifica una vulnerabilità relativa all’elevazione dei privilegi in Microsoft Windows che potrebbe consentire all’autore di un attacco man-in-the-middle di inoltrare una richiesta di autenticazione a un server LDAP Windows. Oltre ad aumentare il livello di sicurezza, la patch è necessaria per risolvere una vulnerabilità ( bollettino CVE-2017-8563) di privilege-escalation.

Una volta installato l’aggiornamento, il server LDAP di Windows rifiuterà tutte le richieste di connessione non crittografata (senza crittografia SSL/TLS). L’aggiornamento aggiungerà nuovi eventi di log, cambierà alcuni parametri predefiniti delle Group Policy che abiliteranno l’hardening di LDAP Channel Binding e LDAP Signing.

Aggiornamento del 4 febbraio 2020: la patch di marzo 2020 non cambierà le policy di LDAP Channel Binding e LDAP Signing oppure le chiavi di registro equivalenti sui domain controller esistenti oppure sui nuovi domain controller. Un successivo aggiornamento, previsto per la seconda metà del 2020, invece abiliterà l’hardening di default. Quindi al momento è tutto rimandato.

Aggiornamento del 28 febbraio 2020: il 10 marzo 2020 verrà rilasciato attraverso Windows Update un aggiornamento che consentirà agli amministratori di modificare la configurazione per LDAP channel bindig sui domain controllers. L’aggiornamento aggiungerà:

  1. Domain controller: LDAP server channel binding token requirements group policy.
  2. CBT signing events 3039, 3040, and 3041 with event source Microsoft-Windows-ActiveDirectory_DomainService in the Directory Service event log.

Verifica dei log sulle connessioni LDAP in Event Viewer

Per verificare se ci sono delle connessioni in ingresso LDAP non cifrate, recatevi nell’Event Viewer del vostro Domain Controller e cercate l’evento con ID 2887.

Figura 1 – Numero chiamate LDAP su Domain Controller non cifrate

Per raccogliere ulteriori dettagli sulle chiamate LDAP senza crittografia SSL, lanciate il seguente comando tramite Prompt dei comandi:

 

Attenzione: questa impostazione colleziona un numero elevato di log consultabili nell’Event Viewer.

Di seguito il comando per disabilitare la raccolta log:

 

Di seguito, troverete 2 metodi che semplificano la visualizzazione e la gestione dei log raccolti:

  • Vista filtrata in Event Viewer: scaricate il file LDAP Signing Events Custom View.xml da GitHub ed importatelo nell’Event Viewer del vostro Domain Controller (Event Viewer-> Custom views -> click destro “Import Custom View”). L’evento che contiene informazioni sulle chiamate LDAP non cifrate, ha ID 2889.

Figura 2 – Event ID 2889 LDAP bind clear text

  • Script PowerShell Query-InsecureLDAPBinds.ps1: scaricate lo script Powershell Query-InsecureLDAPBinds.ps1 da GitHub ed una volta eseguito sul Domain Controller, genererà un file .CSV con i dettagli (IP,Porta, Username e tipologia di bind) dei servizi che utilizzano connessioni in chiaro.

Figura 3 – Utilizzo dello script Query-InsecureLDAPBinds.ps1 e generazione automatica csv

Per ulteriori dettagli vi rimando all’articolo ufficiale https://docs.microsoft.com/en-us/archive/blogs/russellt/identifying-clear-text-ldap-binds-to-your-dcs

Attivazione del protocollo LDAPS usufruendo di una CA di tipo Enterprise o una PKI Two-Tier

Uno dei metodi per attivare il protocollo LDAPS all’interno di un dominio Active Directory è l’implementazione di una CA (Certification Authority).

Quando si implementa una CA di tipo Enterprise su un Domain Controller (pratica non consigliata), il protocollo LDAPS è abilitato automaticamente.

Per la configurazione di una Enterprise CA vi rimando all’articolo ufficiale https://docs.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/install-the-certification-authority.

Discorso diverso invece per una PKI (Public Key Infrastructure) Two-Tier, dove è necessario effettuare alcuni passaggi per l’enrollment sui Domain Controller interessati di un certificato contenente l’OID 1.3.6.1.5.5.7.3.1 8 (Server Authentication).

Sul nostro sito è disponibile la guida per la configurazione di una PKI a due livelli alla pagina https://www.ictpower.it/sistemi-operativi/deploy-pki-in-windows-server-2016-parte-1-architettura-di-una-pki-two-tier.htm

Pubblicazione del certificato tramite Certification Autority

Dal server con il ruolo di Certification Authority lanciate il comando certsrv.msc per aprire la console di gestione.

Per gestire i template dei certificati, fate click col tasto destro su Certificate Templates e selezionate Manage.

Figura 4 – Gestione template certificati su Certification Authority

Per la creazione del certificato con lo scopo di Server Authentication è possibile duplicare il template esistente di Kerberos Authentication.

NB: è fondamentale disporre di un solo certificato sui Domain Controller a scopo di Server Authentication per evitare che si verifichino problemi di selezione certificati.

Cliccate con il tasto destro su Kerberos Authentication e selezionate Duplicate Template.

Figura 5 – Duplicazione template Kerberos Authentication

Nel tab General, modificate il nome del template ed eventualmente il periodo di validità come da seguente immagine:

Figura 6 – Modifica nome template del certificato e periodo di validità

Nel caso in cui vogliate importare il certificato nello store AD DS, recatevi nel tab Request Handling e spuntate Allow private key to be exported.

Figura 7 – Spunta da abilitare per export chiave privata

Successivamente assicuratevi che nel tab Subject Name siano selezionati DNS name e Service principal name.

Figura 8 – Selezione DNS name e Service principal name in tab Subject Name

Terminate le modifiche cliccate su Apply e chiudete la finestra del template.

Ritornate nella finestra principale della console e procedete all’emissione del template creato in precedenza.

Cliccate con il tasto destro su Certificate Templates e scegliete New -> Certificate Template to Issue.

Figura 9 – Emissione template certificate

Selezionate il template interessato e cliccate OK.

Figura 10 – Selezione template

A questo punto potete collegarvi al Domain Controller per richiedere il certificato e abilitare il protocollo LDAPS.

Per accedere allo store dei certificati Personal del Computer Account: Start -> Run -> digitare mmc -> File -> Add/Remove Snap-in -> Certificates -> Add -> Computer Account -> Finish -> Ok oppure potete digitare certlm.msc sui sistemi operativi più recenti.

Una volta aperto lo snap-ip, è possibile procedere con la richiesta del certificato come dalle seguenti immagini:

Figura 11 – Richiesta certificato nello store Personal del computer account

Figura 12 – Certificate Enrollment

Figura 13 – Active Directory Enrollment Policy

Selezionate come certificato il nome del template creato in precedenza e cliccate Enroll.

Figura 14 – Enrollment del certificato per LDAPS

Test di verifica dell’abilitazione del protocollo LDAPS

Al seguente link https://gallery.technet.microsoft.com/Domain-Controller-TLS-6a50a3d2 è disponibile un tool per verificare se il protocollo LDAPS è abilitato sul Domain Controller e le informazioni riguardo al certificato utilizzato.

Figura 15 – Tool per verifica LDAPS su DC

Per forzare l’utilizzo del protocollo LDAPS sui Domain Controller, disabilitando la possibilità di connessioni in chiaro, è disponibile la seguente GPO:

Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options

Domain Controller: LDAP server signing requirements: Require signing.

Figura 16 – Domain Controller: LDAP server signing requirements: Require signing.

Attivazione del protocollo LDAPS tramite certificato Self-Signed

Le organizzazioni che non hanno una Certification Authority all’interno della propria infrastruttura, possono attivare il protocollo LDAPS utilizzando un certificato self-signed.

Per erogare il certificato, collegatevi sul Domain Controller (Windows server 2012 e successivi) e lanciate il seguente comando in powershell (con diritti di administrator):

 

Di default la validità di un certificato è di 1 anno, ma nel caso vogliate estenderne la validità(ad esempio 2 anni), basterà lanciare i seguenti comandi powershell (validi per Windows Server 2016/Windows10):

 

Figura 17 – Erogazione del certificato self-signed

Il prossimo step è quello di esportare la chiave pubblica del certificato self-signed ed importarlo nello store del client che effettuerà chiamate LDAPS.

Click destro sul certificato -> All Tasks -> Export…

Figura 18 – Export certificate 1

Figura 19 – Export certificato 2

Figura 20 – Export certificato 3

Figura 21 – Export certificato 4

Figura 22 – Export certificato 5

Nel caso di un client con OS Windows, importate il certificato nello store Trusted Root Certification Authorities.

Copiate il file .cer generato sul client e con un doppio click si attiverà automaticamente il wizard di installazione.

Figura 23 – Import certificato self-signed 1

Figura 24 – Import certificato self-signed 2

Figura 25 – Import certificato self-signed 3

Figura 26 – Import certificato self-signed 4

Test di autenticazione LDAPS tramite tool LDAPAdmin

Per testare l’autenticazione, abbiamo utilizzato un client Windows 10 con LDAPAdmin, un tool gratuito che potete scaricare al link http://www.ldapadmin.org/download/ldapadmin.html , un Domain Controller configurato con il protocollo LDAPS e con auditing degli eventi LDAP attivo .

Collegamento LDAP al Domain Controller in chiaro

Figura 27 – Configurazione connessione LDAP in chiaro in LDAPAdmin

Figura 28 – Errore connessione LDAP in chiaro

Figura 29 – Evento connessione LDAP in chiaro

Collegamento LDAPS al Domain Controller

Poiché la connessione è avvenuta da un client joinato in Active Directory, il client è già in possesso del certificato della Root/Sub CA di dominio, che gli è stato distribuito automaticamente grazie alla Certification Authority integrata in Active Directory.

ATTENZIONE: Nel caso in cui abbiate la necessità di fare delle chiamate da un client non aggiunto allo stesso dominio, da un client in workgroup oppure da una macchina linux è necessario installare la Root/SubCA di riferimento nello store certificati delle Trusted Root Certification Authorities.

Figura 30 – Configurazione connessione LDAPS in LDAPAdmin

Figura 31 – Connessione LDAPS effettuata con successo

Conclusioni

In tanti questi giorni ci state scrivendo per avere notizie a proposito della patch che verrà rilasciata a marzo 2020 relativa a Microsoft LDAP Channel Binding & Signing (ADV190023). Anche se la forzatura dell’utilizzo di LDAP over SSL sembra che verrà rimandata alla seconda metà del 2020, abbiamo pensato che avrebbe fatto comodo sapere fin da ora come aumentare il livello di sicurezza delle comunicazioni delle applicazioni che si autenticano utilizzando Active Directory. Questo tipo di patch non impatterà i client Windows, che si autenticano in Active Directory utilizzando il protocollo Kerberos, ma impatterà i software che si connettono ad Active Directory utilizzando il protocollo LDAP senza usare il TLS/LDAPS.

Ci sono davvero tantissimi software che usano LDAP per l’autenticazione; ci vengono in mente VMware vSphere o vCenter, diversi modelli di firewall, diversi modelli di server RADIUS e potremmo andare avanti per giorni. Risolvere il problema è molto semplice, grazie all’utilizzo dei certificati e all’implementazione di una Certification Authority interna.