Come configurare l'autenticazione LDAP in ownCloud Infinite Scale

Che cosa significa l'autenticazione LDAP in Infinite Scale?

ownCloud Infinite Scale (oCIS) autentica le sessioni del browser e del client tramite OpenID Connect (OIDC). LDAP può fornire gli utenti e le credenziali della directory dietro il provider di identità integrato di oCIS, oppure può essere posizionato dietro un provider OIDC esterno come Keycloak. La configurazione corretta dipende dal fatto che si necessiti di una piccola implementazione con un flusso di accesso semplice o di una piattaforma di identità di produzione con controlli più ampi.

Questa distinzione è utile perché oCIS non è ownCloud Server Classic. I tutorial di Classic configurano LDAP tramite la pagina di amministrazione web o occ ldap:*non configurano oCIS. In oCIS, le impostazioni sono variabili d'ambiente di distribuzione o configurazione del servizio, e più servizi potrebbero necessitare di una visione coerente della stessa directory.

La documentazione del servizio IDP di ownCloud, con le relative versioni, afferma che il provider integrato può utilizzare un backend LDAP esterno. Le linee guida sulla sicurezza raccomandano un provider OIDC esterno per installazioni di grandi dimensioni o in produzione. Questa guida utilizza la documentazione di oCIS 8.2; prima di applicare le variabili, verificare la documentazione corrispondente alla versione installata, poiché le impostazioni predefinite e gli esempi di implementazione possono cambiare.

Quale sistema di autenticazione dovresti scegliere?

Se utilizzi già Keycloak o un altro provider OIDC, collegarlo alla directory è solitamente la soluzione più pulita per l'ambiente di produzione. Se si tratta di un'implementazione di piccole dimensioni e i limiti del provider integrato sono accettabili, configura il backend LDAP dell'IDP e testalo prima di consentire l'accesso agli utenti.

Quali informazioni è necessario raccogliere prima di modificare oCIS?

• La versione esatta di oCIS e il metodo di implementazione, ad esempio Docker Compose, Kubernetes o un processo binario supervisionato.
• Nome DNS del server LDAP, catena di certificati TLS e endpoint LDAPS. Preferibilmente ldaps://con convalida del certificato; non disabilitare la convalida per nascondere un problema di attendibilità.
• Un account di bind con privilegi minimi e il suo nome distinto (DN) completo. L'account deve essere in grado di cercare i rami utente e di gruppo necessari a oCIS, senza permessi di scrittura non necessari.
• Il DN di base per la ricerca degli utenti, l'ambito di ricerca, l'attributo di accesso, la classe dell'oggetto, gli attributi email e display-name e un attributo ID utente univoco e stabile. Verificare questi dati confrontandoli con le voci effettive della directory.
• Il DN di base del gruppo e l'attributo di appartenenza se i gruppi LDAP degli utenti devono essere visualizzati in oCIS.
• Un backup della configurazione oCIS corrente e un accesso amministratore testato che non dipenda dalla modifica LDAP.

La mappatura stabile delle identità richiede particolare attenzione. Il nome visualizzato o l'indirizzo email possono cambiare; tuttavia, un ID univoco deve rimanere associato alla stessa persona. Se oCIS rileva un identificativo diverso dopo la modifica, una persona esistente potrebbe apparire come un nuovo account anziché ereditare l'identità e l'accesso previsti.

Come si collega l'IDP integrato a un server LDAP esterno?

Per una distribuzione di piccole dimensioni che utilizza l'IDP integrato di oCIS, impostare le variabili LDAP con ambito IDP nella configurazione dell'ambiente o del servizio utilizzata dalla distribuzione. I valori riportati di seguito sono solo esempi. Sostituire host, DN, percorso del certificato e nomi dello schema con i valori presenti nella propria directory.

IDP_LDAP_URI=ldaps://ldap.example.net:636
IDP_LDAP_TLS_CACERT=/etc/ocis/certs/directory-ca.pem
IDP_LDAP_BIND_DN=uid=ocis-reader,ou=service,dc=example,dc=net
IDP_LDAP_BIND_PASSWORD=<load-from-your-secret-store>
IDP_LDAP_BASE_DN=ou=people,dc=example,dc=net
IDP_LDAP_SCOPE=sub
IDP_LDAP_LOGIN_ATTRIBUTE=uid
IDP_LDAP_EMAIL_ATTRIBUTE=mail
IDP_LDAP_NAME_ATTRIBUTE=displayName
IDP_LDAP_UUID_ATTRIBUTE=entryUUID
IDP_LDAP_UUID_ATTRIBUTE_TYPE=text
IDP_LDAP_OBJECTCLASS=inetOrgPerson

La documentazione di riferimento IDP descrive queste impostazioni, inclusi URI, certificato CA, DN di associazione e password, DN di base utente, ambito, attributo di accesso, attributo UUID e classe oggetto. L'esempio presuppone che la directory fornisca un valore testuale entryUUID; Active Directory e altri schemi potrebbero richiedere mappature diverse. Non copiare entryUUIDsolo perché appare qui.

Archivia la password di bind come segreto di distribuzione o nel meccanismo di sicurezza consigliato per la tua piattaforma. Evita di inserirla in un file Compose pubblico, in un repository o in un ticket. Assicurati che il certificato CA sia leggibile dal processo oCIS e conserva la verifica del certificato. L' INSECUREimpostazione dell'IDP disabilita la convalida del certificato LDAP TLS e non è esplicitamente destinata agli ambienti di produzione.

Assicurati inoltre che il comportamento di disabilitazione dell'account corrisponda alla tua directory. La documentazione dell'IDP elenca IDP_USER_ENABLED_ATTRIBUTE; il suo valore predefinito è un nome di attributo specifico di ownCloud. Se la tua directory utilizza un flag di abilitazione/disabilitazione diverso, mappa quell'attributo effettivo. Esamina USERS_LDAP_DISABLE_USER_MECHANISManche il servizio utenti. A seconda della directory, le opzioni documentate sono la gestione basata sugli attributi, la gestione basata sui gruppi o none; scegli deliberatamente in modo che un account disabilitato non venga trattato come attivo a causa di una mancata corrispondenza dello schema.

Anche le ricerche di utenti e gruppi richiedono le impostazioni LDAP?

Spesso sì. La verifica della password e l'individuazione dell'utente sono processi correlati ma distinti. L'IDP autentica l'accesso; gli utenti oCIS e i servizi Graph forniscono alla piattaforma informazioni su utenti e gruppi. Se si utilizza una directory esterna come origine dell'identità per oCIS, è necessario configurare gli utenti e i backend LDAP di Graph in modo che leggano la stessa directory e mappino gli stessi utenti in modo coerente.

Per il servizio utenti, rivedere USERS_DRIVER=ldape le relative impostazioni a livello di servizio, come USERS_LDAP_URI, USERS_LDAP_CACERT, USERS_LDAP_BIND_DN, USERS_LDAP_BIND_PASSWORD, USERS_LDAP_USER_BASE_DN, USERS_LDAP_USER_SCHEMA_ID, e USERS_LDAP_USER_SCHEMA_USERNAME. Impostare le variabili mail, display-name, scope e group quando la distribuzione lo richiede. I nomi esatti dello schema devono corrispondere alla directory anziché a un esempio generico.

Il servizio Graph ha le proprie impostazioni LDAP. Per una directory esistente che oCIS deve leggere senza gestirla, impostare GRAPH_LDAP_SERVER_WRITE_ENABLED=falsee configurare la connessione e lo schema LDAP di Graph. La documentazione di ownCloud descrive questo come il modello di sola lettura per la connessione a un server LDAP esistente. Lasciare le scritture disabilitate a meno che non si sia predisposto uno schema LDAP compatibile e si desideri che oCIS crei o modifichi gli oggetti della directory.

Utilizzate con cautela i prefissi delle variabili specifiche del servizio o le OCIS_LDAP_*variabili globali documentate. Le variabili globali possono influenzare più servizi contemporaneamente. Per una prima integrazione, le impostazioni esplicite per ciascun servizio semplificano l'individuazione del servizio non funzionante e prevengono scritture indesiderate o presupposti errati dello schema. I riferimenti ai servizi utente e ai servizi Graph elencano i nomi e i valori predefiniti specifici per ciascuna versione.

Come si applicano le impostazioni in modo sicuro?

1. Salva una copia del file di ambiente corrente, dell'unità di servizio o della configurazione di Compose. Annota la procedura per ripristinarla.
2. Aggiungi le variabili LDAP alla definizione del servizio oCIS. Non sostituire il resto di un blocco di ambiente Compose esistente con questo esempio; integra le impostazioni nella distribuzione già in esecuzione.
3. Verifica che il file del certificato esista all'interno del container o dello spazio dei nomi host in cui il servizio oCIS lo legge. Il percorso host non è automaticamente visibile all'interno di un container.
4. Prima di riavviare oCIS, convalidare l'account di bind e la base di ricerca rispetto a LDAP. Utilizzare lo stesso hostname del server, il DN di base e l'attributo di login configurati per il servizio.
5. Riavvia oCIS seguendo la normale procedura di distribuzione in modo che i servizi ricevano il nuovo ambiente. In una distribuzione multiservizio o multinodo, verifica che i servizi pertinenti su ogni istanza utilizzino la configurazione prevista.
6. Eseguire il test con un account LDAP autorizzato e un account che non deve effettuare l'accesso. Mantenere aperta una sessione amministratore esistente fino a quando il nuovo percorso di accesso non sarà stato verificato.

Per un controllo diretto della directory, ldapsearchè possibile testare il filtro di associazione e utente senza inserire la password nella riga di comando:

ldapsearch -H ldaps://ldap.example.net:636 \
  -D 'uid=ocis-reader,ou=service,dc=example,dc=net' -W \
  -b 'ou=people,dc=example,dc=net' '(uid=alice)' dn uid entryUUID mail

Utilizza l'attributo di login e il DN di base che intendi configurare. Una query riuscita conferma il comportamento di rete, TLS, bind e ricerca per quella query; non dimostra che ogni servizio oCIS utilizzi la stessa mappatura.

Come fai a sapere se la configurazione funziona?

Valuta il risultato non solo in base alla visualizzazione della pagina di accesso. Accedi tramite il normale flusso Web di oCIS con un utente di directory di prova, apri un file e verifica il nome utente e i dettagli del profilo previsti. Se i gruppi gestiscono l'accesso alle condivisioni o agli spazi, verifica anche l'appartenenza a un gruppo noto. Quindi, prova con una password errata e con un account LDAP disabilitato o non incluso nell'elenco degli utenti consentiti. Questi account non dovrebbero ottenere l'accesso.

Esamina i log del servizio oCIS per individuare errori di connessione LDAP, TLS, autenticazione e ricerca utente. Un'autenticazione LDAP valida seguita da un accesso oCIS non riuscito spesso indica un problema con il filtro di ricerca, il DN di base, l'identificativo utente o la mappatura OIDC-utente. In un ambiente di test in produzione, verifica i file, le condivisioni e l'accesso basato su gruppi di un utente esistente prima di migrare un gruppo più ampio. Un controllo di autenticazione riuscito da solo non garantisce che l'identità e l'autorizzazione dell'account esistente siano state preservate.

Cosa bisogna modificare se l'accesso continua a non funzionare?

• Errori TLS o di connessione: verificare che l'host oCIS si risolva e raggiunga il server LDAP, che la porta e lo schema corrispondano e che il file CA contenga la catena di certificati emittenti. Mantenere la verifica abilitata.
• L'autenticazione ha esito positivo, ma non è stato trovato alcun utente: verificare l'esatto DN della base utente, l'ambito, la classe oggetto, l'attributo di login e il filtro. Un DN di autenticazione corretto non implica che la ricerca venga effettuata nel ramo corretto.
• LDAP accetta la password, ma oCIS non riesce a risolvere l'account: confronta l'identificativo di accesso IDP con il nome utente del servizio utenti o la mappatura dell'ID stabile. Mantieni un identificativo stabile e non passare casualmente dal nome utente all'indirizzo email.
• L'accesso funziona, ma l'accesso basato sui gruppi non è corretto: verificare gli utenti e il DN di base del gruppo Graph, la classe dell'oggetto gruppo, l'attributo membro e se il backend Graph è configurato in sola lettura o con permessi di scrittura, come previsto.
• Se hai bisogno di autenticazione a più fattori (MFA), sessioni centralizzate o controlli di identità più ampi, sposta l'autenticazione LDAP su un provider OIDC esterno e configura oCIS in modo che si fidi di tale emittente. Il provider di identità integrato è intenzionalmente limitato; ownCloud consiglia un provider esterno per installazioni di grandi dimensioni e sottolinea che il provider integrato non offre tutte le funzionalità di un servizio di identità esterno.

Non abilitare questa PROXY_ENABLE_BASIC_AUTHopzione come scorciatoia per l'accesso al browser in ambiente di produzione. La documentazione del proxy elenca l'autenticazione di base come schema di richiesta supportato, ma raccomanda di utilizzarla solo in fase di sviluppo e non in produzione. Per l'accesso oCIS standard, utilizzare il provider OIDC integrato solo laddove le sue limitazioni lo consentano, oppure connettere un provider di identità OIDC esterno basato su LDAP.

Cosa c'è al di fuori di questo contesto?

L'autenticazione LDAP non rende automaticamente disponibili tutte le funzioni amministrative LDAP in oCIS. Il provisioning di utenti e gruppi, la sincronizzazione dei gruppi, l'accesso in scrittura, le modifiche delle password, le regole per gli account disabilitati e la mappatura degli utenti esistenti richiedono impostazioni di servizio e schemi LDAP compatibili specifici. Per il provisioning automatico OIDC esterno, ownCloud richiede anche un claim utente stabile e un backend Graph con accesso in scrittura quando il flusso scelto crea gli account. Consultare la documentazione del proxy prima di abilitare tale comportamento.

Apporta una modifica alla volta, esegui dei test con un piccolo set di account e verifica sia l'autenticazione che la mappatura delle identità prima di un'implementazione su larga scala. Se la versione di oCIS, lo schema LDAP o il provider di identità differiscono dalle ipotesi dell'esempio, segui la configurazione specifica di quella versione anziché riutilizzare l'esempio senza modifiche.