L’autenticazione LDAP di OpenVPN funziona ma il controllo di gruppo fallisce: dove guardare

L’autenticazione può passare mentre il controllo di gruppo rifiuta tutti. Esaminate in ordine il blocco Authorization, l’attributo di appartenenza e l’endpoint della directory.

Le credenziali passano, il tunnel inizia a salire e poi la sessione fallisce con un messaggio sul gruppo anziché sulla password. Questa combinazione colloca il guasto nella seconda metà del lavoro del plugin LDAP: il bind e la verifica della password sono riusciti, la decisione di appartenenza che segue no. Le due metà leggono dalla stessa strofa di configurazione, per questo una correzione in un punto può lasciare l’altra intatta. Cominciate dalla riga di log che nomina il passo, non dall’account con cui state provando per caso.

Trattate il rifiuto come una risposta di autorizzazione

Il plugin esegue un bind di servizio, cerca l’account, verifica la password fornita e poi chiede se quell’account appartiene a un gruppo consentito. Sono quattro operazioni distinte, e solo l’ultima riguarda i gruppi. Un rifiuto che arriva dopo un bind riuscito non dice quindi nulla sulla password, anche quando il client mostra un errore di autenticazione generico. Alzare il livello di log del plugin prima di modificare la configurazione è ciò che separa le quattro nell’output.

Cercate la valutazione del gruppo stessa. Quando non compare alcuna query di gruppo, il blocco di autorizzazione non viene raggiunto, il che di solito significa che una direttiva sta fuori dalla strofa che la possiede o che manca un’opzione obbligatoria. Quando la query compare e non restituisce nulla, l’endpoint o il filtro rispondono a una domanda diversa da quella che intendevate.

Decidete se l’appartenenza vive nel filtro o in un blocco di gruppo

Ci sono due forme supportate, e mescolarle è il modo in cui una configurazione funzionante smette di funzionare. La prima spinge l’appartenenza nella ricerca dell’utente chiedendo un attributo sull’oggetto utente; la seconda lascia stare la ricerca dell’utente e fa cercare l’oggetto gruppo in seguito al plugin. Sceglietene una per distribuzione e annotate quale avete scelto.

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(&(sAMAccountName=%u)(memberOf=CN=VPN Access,OU=Groups,DC=example,DC=org))"
    RequireGroup false
</Authorization>

Con quella forma il filtro decide tutto, quindi RequireGroup deve essere false, altrimenti il plugin va a cercare un oggetto gruppo che il filtro non ha mai menzionato. L’attributo nel filtro deve esistere sull’oggetto utente ed essere compilato, cosa non garantita quando i gruppi sono annidati.

L’altra forma mantiene la ricerca semplice e aggiunge una ricerca di gruppo dopo. L’oggetto gruppo è nominato esplicitamente, e il plugin confronta l’utente con i membri che la directory restituisce per esso. Nulla cambia nel filtro utente, il che rende questa forma più facile da verificare quando un altro team gestisce il gruppo.

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(sAMAccountName=%u)"
    RequireGroup true
    Group        "CN=VPN Access,OU=Groups,DC=example,DC=org"
</Authorization>

Il punto cieco è condiviso: un semplice confronto di appartenenza non espande i gruppi annidati, quindi un account il cui accesso arriva tramite un gruppo padre fallisce mentre la console mostra ancora l’appartenenza. Active Directory espone member sul gruppo, altri schemi usano uniqueMember, e puntare all’attributo sbagliato restituisce un risultato vuoto invece di un errore.

Scegliete un endpoint che contenga l’oggetto gruppo

L’URL decide quale directory interroga il plugin, e un controller di dominio sulla porta 389 risponde solo per il proprio contesto di nomi. Un catalogo globale sulla porta 3268 risponde per tutta la foresta, in sola lettura e con un set di attributi parziale. Quando gli account sono in un dominio e il gruppo VPN in un altro, una query su un solo dominio può trovare l’utente e mancare comunque l’appartenenza. È il caso in cui spostare l’URL sulla porta del catalogo risolve il rifiuto, ed è anche il caso in cui le persone generalizzano troppo.

Il set di attributi parziale è il limite: un attributo che il catalogo non contiene non può essere usato come filtro, quindi la stessa modifica può far funzionare una distribuzione e far restituire vuoto a un’altra. Confermate ciò che l’endpoint restituisce davvero per l’utente e il gruppo reali prima di riscrivere la strofa. I referral e TLS sono di nuovo questioni separate, dato che un referral va seguito e un endpoint che richiede TLS ha bisogno dei file di fiducia corrispondenti.

Tenete lo stato dell’account e l’ambito di ricerca nei propri campi

Il flag di disattivazione appartiene al filtro, non al controllo di gruppo. In Active Directory è il secondo bit di userAccountControl, e senza quella condizione un account disattivato con una password valida si autentica e poi fallisce al passo del gruppo, cosa che sembra un bug di autorizzazione. L’ambito di ricerca appartiene al DN di base, perché partire dalla radice del dominio è più lento e può corrispondere a oggetti fuori dall’unità organizzativa che volevate coprire.

Tenete stretti anche i diritti dell’account di bind. Diritti di directory ampi trasformano un filtro mal configurato in una query riuscita e nascondono il bug finché qualcuno non controlla l’account. Cambiate l’appartenenza nella directory stessa, mai in un elenco locale di eccezioni, così che disattivare l’account basti a togliere l’accesso. Se un altro team gestisce il gruppo, concordate l’attributo che popolano prima di scrivere un filtro su di esso.

Dimostrate il risultato con tre account

Eseguite la configurazione contro tre identità: un membro consentito, un account valido fuori dal gruppo e un account che è stato disattivato. Se tutti e tre sono rifiutati, il bind o la query di gruppo sono rotti; se tutti e tre sono accettati, non viene applicata alcuna condizione di gruppo. Un risultato misto è l’unico che dimostra che la configurazione distingue i casi che vi interessano.

Leggete le stesse tre risposte direttamente dalla directory prima di dare la colpa al plugin. La prima query mostra l’attributo di gruppo da cui dipende il filtro, e la seconda mostra il valore di controllo dell’account. Sostituite con il vostro DN di base, account ed endpoint:

ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=alice)" memberOf
ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=bob)" userAccountControl

Un utente il cui memberOf torna vuoto è un fatto della directory, non un bug del plugin, e un account che si autentica ancora dopo essere stato disattivato significa che al filtro manca la condizione di controllo dell’account. Correggete prima quella prova, poi rieseguite il test a tre account. Tenete la riga di log che ha nominato il passo fallito accanto alla modifica di configurazione, così la persona successiva può separare l’autorizzazione dall’autenticazione senza ripetere la ricerca.

Articoli correlati