Un accesso VPN che verifica le credenziali su una directory implica due connessioni di rete separate. La connessione dell’utente al gateway è protetta dal certificato proprio della VPN e dalla configurazione del protocollo. La connessione del gateway alla directory è un’altra sessione con le proprie impostazioni TLS, il proprio archivio di fiducia e i propri modi di guasto. Nulla della prima garantisce nulla sulla seconda.

Questa asimmetria è il meccanismo dietro un accesso che sembra cifrato e che comunque invia una password di bind in chiaro.

Due connessioni, due decisioni di fiducia

La sessione esterna è ciò che vede l’utente: un certificato legato al nome host della VPN, convalidato dal client, che trasporta lo scambio di autenticazione. La sessione interna appartiene al client della directory dentro il gateway, che apre la propria connessione e negozia TLS oppure no. Ogni lato convalida l’interlocutore con cui parla, usando materiale di un diverso file di configurazione. Un tratto interno mal configurato resta invisibile dal lato dell’utente, perché il tratto esterno funziona esattamente come previsto.

Ecco perché il guasto è silenzioso e non rumoroso. Un gateway che non controlla mai il certificato della directory autentica comunque gli utenti correttamente; li autentica semplicemente su un canale che non ha verificato.

StartTLS e LDAPS, scelti deliberatamente

StartTLS si apre come LDAP semplice e viene aggiornato sul posto, convenzionalmente sulla porta 389. LDAPS avvia TLS con la connessione, convenzionalmente sulla 636. Entrambi sono legittimi e l’adattatore deve corrispondere a ciò che offre la directory. Richiedere StartTLS è diverso dal provarlo e continuare quando l’aggiornamento fallisce, ed è proprio in quella differenza che una password di bind può sfuggire. Configurate la modalità rigorosa e non consentite un ripiego non protetto per un bind con password.

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

L’opzione -ZZ è tutto il punto: la query fallisce invece di proseguire silenziosamente senza l’aggiornamento. I nomi e gli account di quella riga sono esempi. La documentazione TLS di OpenLDAP copre le impostazioni di fiducia che ne stanno alla base.

Quale archivio di fiducia legge il client LDAP?

La libreria client OpenLDAP legge la propria configurazione di fiducia, sia dal file di sistema sia da un’impostazione specifica del plugin. La direttiva CA della VPN vale per i peer VPN e non è prova che la libreria LDAP legga lo stesso file. Usate il nome host della directory che il certificato copre davvero, più la catena emittente di cui la libreria si fida. In Active Directory, distribuite un certificato di servizio directory con l’uso corretto per l’autenticazione server invece di ragionare da un nome visualizzato.

Ogni destinazione di failover deve soddisfare la stessa politica di identità. Un ambiente in cui il primario è convalidato e il secondario no è peggiore di uno senza failover, perché il percorso più debole si scopre solo durante un’interruzione.

L’account di bind resta un problema a parte

Proteggere il trasporto non riduce ciò che l’account di bind può fare. L’ambito di ricerca nella directory, l’autorizzazione per gruppi e i privilegi dell’account di servizio sono decisioni separate, e un account di bind ampio resta ampio dopo aver abilitato TLS. Usate l’account di servizio e la base di ricerca più stretti di cui l’integrazione ha bisogno, e registrate l’endpoint, la modalità TLS, il proprietario della fiducia e il processo di rinnovo insieme alla configurazione della VPN.

Quando compare una discrepanza di certificato, distribuite il certificato o la catena corretti. Disattivare la verifica trasforma una discrepanza visibile in invisibile e lascia la seconda relazione di fiducia non verificata.

Due connessioni, due proprietari, due date di rinnovo. Tenerle separate nella documentazione è ciò che mantiene onesto l’accesso.

Articoli correlati