Vai al contenuto

LDAP e Active Directory

Drovio Server può autenticare gli utenti presso una directory LDAP o un Active Directory Microsoft. Gli account sono creati automaticamente alla prima connessione, non c'è quindi nulla da provvedere a mano. Il dettaglio dei campi è descritto nel riferimento di configurazione.

LDAP può convivere con gli account locali e con l'SSO. Riguarda solo l'applicazione Drovio, dato che il client web non richiede alcun account.

Svolgimento di una connessione

Ogni connessione segue la sequenza classica connessione, ricerca, connessione:

  1. Drovio Server si connette alla directory con l'account di servizio.
  2. Cerca l'utente sotto base, con l'aiuto di search_filter, dove {0} è sostituito dall'indirizzo e-mail inserito nel modulo.
  3. Si connette una seconda volta con il nome distintivo dell'utente e la password fornita. È questa seconda connessione ad autenticare.

Tre conseguenze da tenere a mente scrivendo il vostro filtro

  • La ricerca riguarda tutto il sottoalbero situato sotto base.
  • Il filtro deve risolvere verso una voce e una sola. Se ne trova più di una, la connessione è rifiutata piuttosto che autenticarsi su una corrispondenza arbitraria.
  • Gli utenti si connettono con un indirizzo e-mail. Il valore è ripulito dagli spazi e portato in minuscolo, e deve essere sintatticamente valido: un semplice sAMAccountName è rifiutato prima ancora che la directory sia contattata.

Dalla directory viene riletto solo il nome distintivo. Nessun attributo è recuperato, e il meccanismo di connessione è semplice, cosicché Kerberos e gli altri meccanismi SASL non sono disponibili.

Configurare la connessione

Le impostazioni si trovano sotto Users nel pannello di amministrazione, nella sezione LDAP / Active Directory.

Campo del pannello Chiave di configurazione Esempio
Status enabled true
URL url ldaps://ldap.example.com:636
Service Account DN service_account_dn cn=drovio,ou=services,dc=example,dc=com
Service Account Password service_account_password
Base base ou=users,dc=example,dc=com
Search Filter search_filter vedere qui sotto
CA Certificate ca_certificate_path /etc/drovio-server/ldap-ca.pem

L'account di servizio ha bisogno solo del diritto di cercare nel sottoalbero situato sotto base, nulla di più.

(&(objectClass=inetOrgPerson)(mail={0}))

(&(objectClass=user)(mail={0}))

(&(objectClass=user)(userPrincipalName={0}))

Il valore fornito per impostazione predefinita è (&(objectClass=*)(mail={0})). Funziona, ma restringere la classe di oggetto rende la ricerca meno costosa e il vincolo di unicità più facile da soddisfare.

Le modifiche prendono effetto alla connessione successiva. Nessun riavvio è necessario.

Non c'è alcun pulsante di test

Il pannello non sa convalidare la configurazione da solo. Salvatela, fate tentare una connessione a un utente, poi leggete il log del server. Ogni fallimento vi è registrato con la fase difettosa, che la tabella di Risoluzione dei problemi riconduce al campo da verificare.

Connettersi in LDAPS

Usate ldaps:// sulla porta 636. Il semplice ldap:// fa circolare le credenziali in chiaro, e il server ne avverte una volta nel log.

StartTLS non è supportato. I due modi sono il chiaro su ldap:// e il TLS implicito su ldaps://.

ca_certificate_path designa il certificato da considerare affidabile. Accetta sia PEM sia DER, nonché un insieme PEM contenente un'intera catena. Potete indicarvi un'autorità di certificazione oppure direttamente il certificato della directory, il che permette di far funzionare un certificato autofirmato.

Il file sostituisce il magazzino di sistema, non lo completa

Quando ca_certificate_path è valorizzato, la connessione LDAP si fida solo di ciò che quel file contiene. Un certificato di directory emesso da un'autorità pubblica riconosciuta cessa di essere convalidato se la sua catena non vi figura ugualmente. Lasciate l'impostazione vuota per usare il magazzino di fiducia di Java.

Il certificato deve inoltre corrispondere all'host indicato in url, e l'impostazione è letta solo per gli URL in ldaps://. Valorizzarla accanto a un URL in ldap:// resta senza effetto.

Creazione automatica degli account

Alla prima connessione riuscita, Drovio Server crea l'account:

Campo dell'account Valore
E-mail L'indirizzo inserito nel modulo
Nome utente La parte locale di quell'indirizzo, jane.doe@example.com dà jane.doe

Nessun attributo della directory viene ripreso, contrariamente a SAML e OIDC che dispongono delle proprie impostazioni email_attribute e username_attribute. Gli utenti possono cambiare in seguito il proprio nome utente, e le connessioni successive lasciano quella modifica intatta.

Nessuna password è mai memorizzata per un account LDAP, e nessuna e-mail di verifica viene inviata. I cambi di password, le reinizializzazioni e la politica delle password restano interamente di competenza della vostra directory: il pannello di amministrazione non offre alcuna modifica delle credenziali per questi account.

Verificate il vostro pool di licenze prima di aprire LDAP a una directory ampia

La creazione dell'account segue users.license_allocation come qualsiasi altro account. Se nessun posto è libero, l'account viene creato comunque, semplicemente senza licenza. L'utente ne è avvertito nell'applicazione Drovio e il log del server registra:

Could not automatically allocate a license: no more free license left...

Restringere l'accesso a un gruppo o a un'unità organizzativa

Non esiste alcuna impostazione dedicata, e non ne serve. I due campi esistenti bastano:

  • Per sottoalbero. Fate puntare base sul ramo che contiene gli utenti autorizzati, per esempio OU=Drovio Users,DC=example,DC=com. Tutto ciò che è al di fuori diventa invisibile alla ricerca.

  • Per appartenenza a un gruppo. Aggiungete una clausola al filtro:

    (&(objectClass=user)(mail={0})(memberOf=CN=Drovio,OU=Groups,DC=example,DC=com))

    Su Active Directory, usate la regola di corrispondenza memberOf:1.2.840.113556.1.4.1941:= piuttosto che memberOf per includere i gruppi annidati.

Il controllo ha luogo a ogni connessione. Rimuovere qualcuno dal gruppo lo blocca quindi immediatamente. Tenete presente che il filtro deve sempre corrispondere a una voce e una sola.

Combinare con gli altri metodi di connessione

Combinazione Comportamento
LDAP e account locali La directory è interrogata per prima. Se rifiuta le credenziali, le stesse e-mail e password sono poi provate sull'account locale
LDAP e SAML Supportati, seguono percorsi distinti
LDAP e OIDC Supportati, seguono percorsi distinti

Per imporre l'autenticazione tramite la sola directory, disattivate users.auth.local.

Revocare un accesso

Eliminare o disattivare l'account nella directory blocca la connessione fin dal tentativo successivo. Ciò che non fa è eliminare alcunché lato Drovio: non esiste alcuna attività di riconciliazione. La scheda dell'utente e il suo posto di licenza sussistono entrambi, se users.license_allocation è disattivato o impostato in modalità new_user.

Per liberare il posto, eliminate l'utente dalla scheda Users del pannello di amministrazione, oppure attivate users.remove_inactive affinché gli account inutilizzati siano ripuliti periodicamente.

Limiti di esercizio

Alcuni comportamenti sono fissati e meritano di essere conosciuti al momento di dimensionare la distribuzione o di aprire il firewall:

Comportamento Valore
Connessioni per autenticazione Due, una per l'account di servizio e una per l'utente. Non sono condivise
Timeout di connessione 30 secondi
Timeout di lettura 60 secondi
Rinvii Ignorati

I rinvii ignorati contano in una foresta Active Directory multi-dominio: gli utenti il cui account risiede in un dominio diverso da quello indicato in url non vengono trovati. Fate piuttosto puntare Drovio Server verso un catalogo globale, in ldaps:// sulla porta 3269, oppure distribuite un server per dominio. Il catalogo globale espone solo una parte degli attributi, il che qui basta dato che è usato solo il nome distintivo.