Documentazione di Oracle Cloud Infrastructure

Uso di LDAP per l'autorizzazione

Scopri come utilizzare LDAP per l'autorizzazione con lo storage di file.

È possibile utilizzare LDAP (Lightweight Directory Access Protocol) come servizio di informazioni di rete per fornire le informazioni di autorizzazione al servizio di storage di file. L'uso di LDAP per fornire informazioni di autorizzazione fornisce i vantaggi riportati di seguito.

  • Gestione centralizzata di utenti e gruppi UNIX.
  • Supporto per un massimo di 256 gruppi UNIX. Se si abilita LDAP per i gruppi UNIX secondari anziché utilizzare l'elenco di gruppi fornito all'interno dell'intestazione RPC di una richiesta NFS, non si è soggetti alla limitazione AUTH_SYS di 16 gruppi.
  • L'infrastruttura LDAP è un requisito per l'autenticazione per utente quando si utilizza Kerberos. LDAP non è necessario per tutti gli scenari Kerberos, ad esempio quando l'esportazione sta schiacciando tutti.

Ricerca gruppo secondario

I file system di storage di file autorizzano l'accesso utilizzando l'UID/GID dell'operazione NFS e la lista dei gruppi UNIX secondari. Per impostazione predefinita, AUTH_SYS utilizza l'elenco di gruppi fornito nell'intestazione RPC della richiesta NFS.

Quando l'autorizzazione LDAP è abilitata, lo storage di file utilizza l'UID UNIX dall'intestazione RPC della richiesta NFS per recuperare la lista dei gruppi UNIX secondari dal server LDAP per l'accesso a AUTH_SYS. Il GIDLIST esistente nell'intestazione RPC viene sovrascritto con il GIDLIST del server LDAP. Il recupero dei gruppi UNIX secondari da un server LDAP consente alla richiesta di autorizzazione di utilizzare fino a 256 gruppi.

Se la ricerca del gruppo secondario che utilizza il mapping degli ID è abilitata, ma non configurata, configurata in modo errato o il servizio LDAP non è disponibile, lo storage di file non può aggiornare la lista di gruppi secondaria utilizzata nella richiesta. Ciò può causare errori di autorizzazione.

Scenari di richiesta NFS per AUTH_SYS
LDAP per la lista di gruppi abilitato? Risposta LDAP Esportazione squash abilitata? Richiesta NFS
Qualsiasi Qualsiasi Sì (tutti)

Se si schiaccia tutto, procede con l'impostazione di UID squash e GID squash nelle opzioni di esportazione.

Nessuna lista di gruppi secondari.
Qualsiasi Qualsiasi Sì (radice)

Se si esegue lo squash del file system root, nelle opzioni di esportazione vengono impostati UID squash e GID squash solo se l'UID è 0.

Nessuna lista di gruppi secondari.
No Non applicabile No Prosegue con UID/GID dall'intestazione RPC.
Sì Corrispondenza UID No Utilizza la lista di gruppi secondari recuperata dal server LDAP.
Sì Nessuna corrispondenza UID o qualsiasi errore LDAP No Prosegue con UID/GID dall'intestazione RPC. Nessuna lista di gruppi secondari.
Importante

Per utilizzare LDAP per l'autorizzazione, è necessario Abilita LDAP per la destinazione di accesso e all'esportazione.

Se si utilizza l'autenticazione Kerberos insieme a LDAP, il comportamento è leggermente diverso. Per ulteriori dettagli, vedere Ricerche LDAP e accesso anonimo.

Inserimento nella cache

Lo storage di file utilizza un modello di inserimento nella cache on-demand solo in memoria per memorizzare le informazioni di autorizzazione per aumentare le prestazioni e ridurre il carico sul server LDAP.

Quando viene effettuata una richiesta NFS, lo storage di file contatta il server LDAP per informazioni sull'autorizzazione. Lo storage di file memorizza nella cache le informazioni di autorizzazione, positive o negative, da utilizzare nelle operazioni NFS successive.

È possibile configurare per quanto tempo lo storage di file inserisce queste informazioni nella cache quando si configura una destinazione di accesso per LDAP utilizzando le opzioni riportate di seguito.

  • Intervallo di aggiornamento cache in secondi: il periodo di tempo durante il quale la destinazione di accesso deve consentire a una voce di persistere nella cache prima di tentare di aggiornare la voce. Scegliere un valore che bilanci le implicazioni sulla sicurezza e un carico accettabile sul server LDAP.
  • Durata della cache in secondi: la quantità massima di tempo durante la quale la destinazione di accesso può utilizzare una voce inserita nella cache. Se le voci della cache non possono essere aggiornate in modo tempestivo a causa del carico o di errori nell'infrastruttura del cliente, è utile utilizzare le voci precedenti fino al ripristino della connettività. Impostare il valore sul periodo di tempo più lungo per il quale si è disposti a disporre di una voce non più valida nella cache LDAP, inclusi i casi di indisponibilità del server LDAP per qualsiasi motivo.
  • Durata cache negativa in secondi: il periodo di tempo durante il quale una destinazione di accesso conserva le informazioni che un utente non viene trovato nella configurazione del mapping degli ID. Se un utente non viene trovato nel database LDAP, la destinazione di accesso inserisce una voce nella cache notando che l'utente non esiste. Scegliere un valore che bilanci le implicazioni sulla sicurezza e un carico accettabile sul server LDAP.

Prerequisiti

Requisiti:

  • Infrastruttura LDAP gestita dal cliente, incluso un server LDAP che supporta uno schema posix RFC2307. I server LDAP possono essere basati su OpenLDAP o Microsoft Active Directory. Potrebbe essere necessaria una configurazione personalizzata per il supporto dello storage di file della directory LDAP.

  • Un account di login al server LDAP che una destinazione di accesso allo storage di file può utilizzare per cercare informazioni su utenti e gruppi conformi a RFC2307.

    • Il server LDAP deve avere i seguenti attributi utente:
      • ObjectClass: posixAccount: questa classe oggetto fornisce i seguenti attributi per l'utente.
      • uidNumber: ID utente UNIX.
      • gidNumber: l'ID gruppo UNIX del gruppo primario dell'utente.
      • uid - Il nome dell'utente
    • Il server LDAP deve avere i seguenti attributi di gruppo:
      • ObjectClass: posixGroup: questa classe oggetto fornisce i seguenti attributi per il gruppo.
      • gidNumber: ID gruppo UNIX per il gruppo
      • memberUid: l'attributo uid degli utenti che sono membri di questo gruppo. Questo attributo può essere aggiunto più volte per avere più utenti nel gruppo.
    Suggerimento

    È possibile testare il supporto dello schema LDAP.
  • Server DNS per consentire alla destinazione di accesso di cercare i nomi host, incluso il server LDAP.
Questa immagine mostra l'infrastruttura gestita dal cliente e da OCI necessaria per l'autorizzazione LDAP.
  1. Comunicazione con il servizio DNS tramite la porta 53 TCP/UDP.
  2. Comunicazione con il servizio LDAP gestito dal cliente sulla porta TCP configurata nel connettore in uscita. Il valore predefinito è la porta TCP 636.
  3. Dati cifrati in archivio nello storage di file.

Infrastruttura LDAP

Lo storage di file richiede un connettore in uscita in modo che le destinazioni di accesso possano comunicare con un server LDAP sulla porta LDAPS. Il connettore in uscita richiede di fornire il nome dominio completamente qualificato (FQDN) del server LDAP, un nome utente e una password di autenticazione al server LDAP e la base di ricerca per utenti e gruppi.

Per consentire allo storage di file di raggiungere il server LDAP, accertarsi di quanto indicato di seguito.

  • Il firewall del server LDAP deve consentire il traffico in entrata dalla destinazione di accesso dello storage di file utilizzando TCP 636 (impostazione predefinita).
  • Qualsiasi lista di sicurezza e gruppo NSG in uso deve consentire la destinazione di accesso e il traffico del server LDAP.
  • Il DNS è configurato per la destinazione di accesso e i client per risolvere il nome host. Di seguito sono riportate alcune opzioni di configurazione DNS.
    • Uso del DNS OCI con risoluzione predefinita e nomi host nella VCN: questa opzione non offre la flessibilità dei nomi DNS personalizzati. I nomi host terminano con oraclevcn.com con i domini secondari per la VCN e la subnet. Per ulteriori informazioni, vedi DNS nella tua rete cloud virtuale.
    • Utilizzo di DNS privato OCI con zone private: le zone DNS per un dominio personalizzato sono ospitate in DNS OCI. Con questa opzione, non è necessario gestire il proprio server DNS, perché OCI gestisce completamente il DNS. È necessario gestire le zone e i record. Per ulteriori informazioni, consulta DNS privato.
    • Uso di un server DNS gestito dal cliente: quando si crea una VCN, non selezionare Usa nomi host DNS in questa VCN. In alternativa, configurare la VCN in modo che utilizzi il proprio server DNS utilizzando uno dei metodi riportati di seguito.
      1. Configurare le opzioni DHCP nella subnet per utilizzare un server DNS gestito dal cliente.
      2. Utilizzare il resolver VCN con un endpoint di inoltro e una regola di inoltro in modo che le query DNS nella VCN vengano inoltrate a un server DNS gestito dal cliente.

Lo storage di file non supporta SSLv2, SSLv3, TLSv1 o TLSv1.1 per l'autorizzazione LDAPS. Lo storage di file supporta le seguenti suite di cifratura OpenSSL per l'autorizzazione LDAPS:

  • DHE-DSS-AES128-GCM-SHA256
  • DHE-DSS-AES256-GCM-SHA384
  • DHE-RSA-AES128-GCM-SHA256
  • DHE-RSA-AES256-GCM-SHA384
  • ECDHE-ECDSA-AES128-GCM-SHA256
  • ECDHE-ECDSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES256-GCM-SHA384
  • TLS_AES_128_CCM_SHA256
  • TLS_AES_128_GCM_SHA256
  • TLS_AES_256_GCM_SHA384

Test del supporto dello schema LDAP

È possibile utilizzare le query di esempio riportate di seguito per assicurarsi che lo storage di file possa cercare informazioni su utenti e gruppi conformi a RFC2307 da un server LDAP con una configurazione supportata.

ldapsearch -b <user_searchbase> -H ldaps://<ldaps_server_fqdn>:<ldaps_port> -D <bind_DN> -W -s sub '(&(objectClass=posixAccount)(uid=<username>))' uidNumber gidNumber
Output query di esempio
$ ldapsearch -b 'ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com' -H 'ldaps://example.com:636' -D 'cn=admin,dc=fss_test,dc=com' -W -s sub '(&(objectClass=posixAccount)(uid=root))' uidNumber gidNumber
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com> with scope subtree
# filter: (&(objectClass=posixAccount)(uid=root))
# requesting: uidNumber gidNumber
#

# root, Users, nfs_kerberos.fss_test.com
dn: uid=root,ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com
gidNumber: 0
uidNumber: 0

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
ldapsearch -b <user_searchbase> -H ldaps://<ldaps_server_fqdn>:<ldaps_port> -D <bind_DN> -W -s sub '(&(objectClass=posixAccount)(uidNumber=<user_uid>))' uid gidNumber
Output query di esempio
$ ldapsearch -b 'ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com' -H 'ldaps://example.com:636' -D 'cn=admin,dc=fss_test,dc=com' -W -s sub '(&(objectClass=posixAccount)(uidNumber=0))' uid gidNumber
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com> with scope subtree
# filter: (&(objectClass=posixAccount)(uidNumber=0))
# requesting: uid gidNumber
#
# root, Users, nfs_kerberos.fss_test.com
dn: uid=root,ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com
gidNumber: 0
uid: root
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
ldapsearch -b <group_searchbase> -H ldaps://<ldaps_server_fqdn>:<ldaps_port> -D <bind_DN> -W -s sub '(&(objectClass=posixGroup)(memberuid=<username>))' gidNumber
Output query di esempio
$ ldapsearch -b 'ou=Groups,dc=nfs_kerberos,dc=fss_test,dc=com' -H 'ldaps://example.com:636' -D 'cn=admin,dc=fss_test,dc=com' -W -s sub '(&(objectClass=posixGroup)(memberuid=root))' gidNumber
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=Groups,dc=nfs_kerberos,dc=fss_test,dc=com> with scope subtree
# filter: (&(objectClass=posixGroup)(memberuid=root))
# requesting: gidNumber
#
# root, Groups, nfs_kerberos.fss_test.com
dn: cn=root,ou=Groups,dc=nfs_kerberos,dc=fss_test,dc=com
gidNumber: 0
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Suggerimento

È possibile creare allarmi basati sulle metriche del file system che consentono di individuare e diagnosticare rapidamente i problemi di connettività LDAP.

Monitoraggio e allarmi

Essere consapevoli di un problema rapidamente è importante quando si utilizza LDAP. Se l'infrastruttura LDAP non funziona correttamente, i client NFS potrebbero perdere l'accesso ai file system di storage di file resi disponibili tramite le esportazioni. Per individuare tali problemi, si consiglia di impostare gli allarmi sulle metriche della destinazione di accesso. Gli allarmi possono avvisarti dei problemi dell'infrastruttura in pochi minuti.

Gli allarmi generati dagli errori di connessione LDAP e dagli errori di richiesta LDAP rilevano i problemi di connettività tra le destinazioni di accesso, i connettori in uscita e l'infrastruttura LDAP gestita dal cliente.

Per creare un allarme per la connettività LDAP è possibile utilizzare la seguente query di esempio:

LdapConnectionErrors[1m]{resourceType = "outboundconnector", mtResourceName = "<mount_target_name>", errorType != "success"}.max() >= 1

Per ulteriori informazioni sulle metriche di monitoraggio e sull'uso degli allarmi, vedere Panoramica del monitoraggio. Per informazioni sulle notifiche per gli allarmi, vedere Panoramica delle notifiche.

Criteri IAM necessari

Lo storage di file deve accedere ai segreti di vault della password del server LDAP. L'utente che configura la destinazione di accesso e la destinazione di accesso devono disporre dell'accesso in lettura.

Importante

Per poter configurare le destinazioni di accesso in modo che utilizzino LDAP per l'autorizzazione, è necessario creare questi criteri.

Criterio per gestire i segreti vault

Concedere all'utente o al gruppo che crea le autorizzazioni del segreto vault. Per ulteriori informazioni, vedere Gestione dei segreti vault.

Criterio per abilitare la configurazione della destinazione di accesso

Concedere all'utente o al gruppo che configura LDAP in una destinazione di accesso le autorizzazioni utilizzando un criterio come il seguente:

allow <user|group> to read secret-family in compartment <Compartment_ID> where any { target.secret.id = <LDAP_Password_Secret_ID> }

Ciò consente all'utente di eseguire comandi di storage di file che leggono i segreti del vault e visualizzano parti del segreto per la convalida durante la configurazione.

Criterio che consente a una destinazione di accesso di recuperare i segreti

Il servizio di storage di file richiede la possibilità di leggere i segreti. Lo storage di file utilizza i principal delle risorse per concedere a un set specifico di destinazioni di accesso l'accesso al segreto del vault. Si tratta di un processo in due fasi, in primo luogo le destinazioni di accesso che richiedono l'accesso devono essere inserite in un gruppo dinamico, quindi al gruppo dinamico viene concesso l'accesso per leggere i segreti.

  1. Creare un gruppo dinamico per le destinazioni di accesso con un criterio, ad esempio:

    ALL { resource.type='mounttarget', resource.compartment.id = '<mount_target_compartment_id>' }
    Nota

    Se nel gruppo dinamico sono presenti più regole, assicurarsi di utilizzare l'opzione Match any rules defined below.

  2. Creare un criterio IAM che fornisca al gruppo dinamico di destinazioni di accesso l'accesso in lettura ai segreti del vault:

     allow dynamic-group <dynamic_group_name> to read secret-family in compartment <secret_compartment_name>