Documentación de Oracle Cloud Infrastructure

Uso de LDAP para autorización

Obtener información sobre cómo utilizar LDAP para la autorización con File Storage.

Puede utilizar el protocolo ligero de acceso a directorios (LDAP) como servicio de información de red para proporcionar información de autorización al servicio de almacenamiento de archivos. El uso de LDAP para proporcionar información de autorización proporciona las siguientes ventajas:

  • Gestión centralizada de usuarios y grupos UNIX.
  • Compatibilidad con hasta 256 grupos UNIX. Si activa LDAP para grupos UNIX secundarios en lugar de utilizar la lista de grupos proporcionada en la cabecera RPC de una solicitud NFS, no está sujeto a la limitación AUTH_SYS de 16 grupos.
  • La infraestructura LDAP es un requisito para por autenticación de usuario cuando se utiliza Kerberos. LDAP no es necesario para todos los escenarios de Kerberos, por ejemplo, cuando la exportación está aplastando todo.

Consulta de grupo secundario

Los sistemas de archivos de almacenamiento de archivos autorizan el acceso mediante el UID/GID de la operación NFS y la lista de grupos UNIX secundarios. Por defecto, AUTH_SYS utiliza la lista de grupos proporcionada dentro de la cabecera RPC de la solicitud NFS.

Cuando la autorización LDAP está activada, File Storage utiliza el UID de UNIX de la cabecera RPC de la solicitud NFS para recuperar la lista de grupos UNIX secundarios del servidor LDAP para el acceso AUTH_SYS. El GIDLIST existente en el encabezado de RPC se sobrescribe con el GIDLIST del servidor LDAP. La recuperación de grupos UNIX secundarios de un servidor LDAP permite que la solicitud de autorización utilice hasta 256 grupos.

Si la consulta de grupos secundarios mediante asignación de ID está activada, pero no está configurada, configurada incorrectamente o el servicio LDAP no está disponible, File Storage no puede actualizar la lista de grupos secundarios utilizada en la solicitud. Esto puede generar errores de permisos.

Escenarios de solicitud de NFS para AUTH_SYS
¿Se activó LDAP para listas de grupos? Respuesta LDAP ¿Exportar Squash activado? Solicitud NFS
Todos Todos Sí (todo)

Si se aplaza todo, continúa con Squash UID y Squash GID definidos en las opciones de la exportación.

Ninguna lista de grupos secundaria.
Todos Todos Sí (raíz)

Si se aplaza la raíz, continúa con Squash UID y Squash GID definidos en las opciones de la exportación solo si el UID es 0.

Ninguna lista de grupos secundaria.
No No aplicable No Continúa con UID/GID de la cabecera de RPC.
Si Coincidencia de UID No Utiliza la lista de grupos secundaria recuperada del servidor LDAP.
Si No hay ninguna coincidencia de UID o error de LDAP No Continúa con UID/GID de la cabecera de RPC. Ninguna lista de grupos secundaria.
Importante

Para utilizar LDAP para la autorización, debe Activar LDAP para el destino de montaje y en la exportación.

Si utiliza la autenticación Kerberos junto con LDAP, el comportamiento es ligeramente diferente. Para obtener más información, consulte Búsquedas de LDAP y Acceso Anónimo.

Caché

El almacenamiento de archivos utiliza un modelo de almacenamiento en caché a demanda solo en memoria para almacenar información de autorización con el fin de aumentar el rendimiento y reducir la carga en el servidor LDAP.

Cuando se realiza una solicitud NFS, File Storage se pone en contacto con el servidor LDAP para obtener información sobre la autorización. El almacenamiento de archivos almacena en caché la información de autorización, ya sea positiva o negativa, para utilizarla en operaciones NFS posteriores.

Puede configurar el tiempo que File Storage almacena en caché esta información al configurar un destino de montaje para LDAP mediante las siguientes opciones:

  • Intervalo de Refrescamiento de Caché en Segundos: Cantidad de tiempo que el destino de montaje debe permitir que una entrada se mantenga en su caché antes de intentar refrescar la entrada. Elija un valor que equilibre las implicaciones de seguridad y una carga aceptable en el servidor LDAP.
  • Duración de caché en segundos: cantidad máxima de tiempo que el destino de montaje puede utilizar una entrada almacenada en caché. Si las entradas de caché no se pueden refrescar a tiempo debido a la carga o fallos en la infraestructura del cliente, es útil utilizar entradas antiguas hasta que se restaure la conectividad. Defina el valor en el período de tiempo más largo que desee para tener una entrada obsoleta en la caché LDAP, incluidos los casos de no disponibilidad del servidor LDAP por cualquier motivo.
  • Vida útil de caché negativa en segundos: cantidad de tiempo que un destino de montaje mantiene la información de que no se encuentra un usuario en la configuración de asignación de ID. Si no se encuentra un usuario en la base de datos LDAP, el destino de montaje coloca una entrada en la caché indicando que el usuario no existe. Elija un valor que equilibre las implicaciones de seguridad y una carga aceptable en el servidor LDAP.

Requisitos previos

Requisitos:

  • Infraestructura LDAP gestionada por el cliente, incluido un servidor LDAP que admite un esquema posix RFC2307. Los servidores LDAP se pueden basar en OpenLDAP o Microsoft Active Directory. Es posible que se necesite una configuración personalizada para el soporte de File Storage del directorio LDAP.

  • Una cuenta de inicio de sesión en el servidor LDAP que un destino de montaje de File Storage puede utilizar para buscar información de usuarios y grupos compatible con RFC2307.

    • El servidor LDAP debe tener los siguientes atributos de usuario:
      • ObjectClass: posixAccount: esta clase de objeto proporciona los siguientes atributos para el usuario.
      • uidNumber: ID de usuario de UNIX.
      • gidNumber: ID de grupo de UNIX del grupo principal del usuario.
      • uid: nombre de usuario del usuario
    • El servidor LDAP debe tener los siguientes atributos de grupo:
      • ObjectClass: posixGroup: esta clase de objeto proporciona los siguientes atributos para el grupo.
      • gidNumber: ID de grupo de UNIX para el grupo
      • memberUid: atributo uid de los usuarios que son miembros de este grupo. Este atributo se puede agregar varias veces para tener varios usuarios en el grupo.
    Consejo

    Puede probar el soporte del esquema LDAP.
  • Un servidor DNS para permitir que el destino de montaje busque nombres de host, incluido el servidor LDAP.
En esta imagen se muestra la infraestructura gestionada por el cliente y gestionada por OCI necesaria para la autorización de LDAP.
  1. Comunicación con el servicio DNS mediante el puerto TCP/UDP 53.
  2. Comunicación con el servicio LDAP gestionado por el cliente a través del puerto TCP configurado en el conector de salida. El valor por defecto es el puerto TCP 636.
  3. Datos cifrados estáticos en File Storage.

Infraestructura de LDAP

El almacenamiento de archivos requiere un conector saliente para que los destinos de montaje puedan comunicarse con un servidor LDAP en su puerto LDAPS. El conector de salida requiere que proporcione el nombre de dominio completo (FQDN) del servidor LDAP, un nombre de usuario y una contraseña de enlace al servidor LDAP y la base de búsqueda de usuarios y grupos.

Para permitir que File Storage acceda al servidor LDAP, asegúrese de lo siguiente:

  • El firewall del servidor LDAP debe permitir el tráfico entrante desde el destino de montaje de File Storage mediante TCP 636 (valor predeterminado).
  • Cualquier lista de seguridad y NSG en uso debe permitir el tráfico del servidor LDAP y el destino de montaje.
  • El DNS está configurado para que el destino de montaje y los clientes resuelvan el nombre de host. Las opciones de configuración de DNS incluyen:
    • Uso de OCI DNS con resolución por defecto y nombres de host en la VCN: esta opción no ofrece la flexibilidad de los nombres de DNS personalizados. Los nombres de host terminan con oraclevcn.com con subdominios para VCN y subred. Consulte DNS en su red virtual en la nube para obtener más información.
    • Uso de DNS privado de OCI con zonas privadas: las zonas de DNS para un dominio personalizado se alojan en DNS de OCI. Con esta opción, no es necesario gestionar su propio servidor DNS, porque OCI gestiona completamente el DNS. Debe gestionar las zonas y los registros. Consulte DNS privado para obtener más información.
    • Uso de un servidor DNS gestionado por el cliente: al crear una VCN, no seleccione Usar nombres de host DNS en esta VCN. En su lugar, configure la VCN para que utilice su propio servidor DNS mediante uno de los siguientes métodos:
      1. Configure las opciones de DHCP en la subred para utilizar un servidor DNS gestionado por el cliente.
      2. Utilice el solucionador de VCN con un punto final de reenvío y una regla de reenvío para que las consultas de DNS de la VCN se reenvíen a un servidor DNS gestionado por el cliente.

El almacenamiento de archivos no soporta SSLv2, SSLv3, TLSv1 ni TLSv1.1 para la autorización de LDAPS. File Storage soporta los siguientes conjuntos de cifrado OpenSSL para la autorización de 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

Prueba de Soporte de Esquema LDAP

Puede utilizar las siguientes consultas de ejemplo para asegurarse de que File Storage puede buscar información de usuarios y grupos compatible con RFC2307 desde un servidor LDAP con una configuración soportada.

ldapsearch -b <user_searchbase> -H ldaps://<ldaps_server_fqdn>:<ldaps_port> -D <bind_DN> -W -s sub '(&(objectClass=posixAccount)(uid=<username>))' uidNumber gidNumber
Salida de la Consulta de Ejemplo
$ 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
Salida de la Consulta de Ejemplo
$ 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
Salida de la Consulta de Ejemplo
$ 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
Consejo

Puede crear alarmas basadas en Métricas del sistema de archivos que le ayuden a detectar y diagnosticar rápidamente problemas de conectividad de LDAP.

Supervisión y alarmas

Conocer rápidamente un problema es importante cuando se utiliza LDAP. Si la infraestructura LDAP no funciona correctamente, los clientes NFS podrían perder el acceso a los sistemas de archivos de almacenamiento de archivos disponibles mediante sus exportaciones. Para detectar estos problemas, recomendamos configurar alarmas en las métricas del destino de montaje. Las alarmas pueden avisarle de problemas de infraestructura en cuestión de minutos.

Las alarmas creadas a partir de errores de conexión de LDAP y errores de solicitud de LDAP detectan problemas de conectividad entre destinos de montaje, conectores salientes e infraestructura LDAP gestionada por el cliente.

La siguiente consulta de ejemplo se puede utilizar para crear una alarma para la conectividad LDAP:

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

Para obtener más información sobre la supervisión de métricas y el uso de alarmas, consulte Visión general de Monitoring. Para obtener más información sobre las notificaciones de alarmas, consulte Visión general de Notifications.

Política de IAM necesaria

El almacenamiento de archivos necesita acceder a los secretos del almacén de contraseñas del servidor LDAP. Tanto el usuario que configura el destino de montaje como el propio destino de montaje necesitan acceso de lectura.

Importante

Estas políticas se deben crear antes de poder configurar destinos de montaje para utilizar LDAP para la autorización.

Política para gestionar secretos de almacén

Otorgue al usuario o grupo que crea los permisos del secreto de almacén. Para obtener más información, consulte Gestión de secretos de almacén.

Política para activar la configuración de destino de montaje

Otorgue al usuario o grupo que configura LDAP en los permisos de un destino de montaje mediante una política como la siguiente:

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

Esto permite al usuario emitir comandos de File Storage que leen los secretos de Vault y muestran partes del secreto para su validación durante la configuración.

Política para permitir que un destino de montaje recupere secretos

El servicio de almacenamiento de archivos requiere la capacidad de leer los secretos. File Storage utiliza principales de recursos para otorgar acceso a un juego específico de destinos de montaje al secreto de Vault. Se trata de un proceso de dos pasos, en primer lugar, los destinos de montaje que necesitan acceso se deben colocar en un grupo dinámico y, a continuación, se otorga acceso al grupo dinámico para leer los secretos.

  1. Cree un grupo dinámico para los destinos de montaje con una política como la siguiente:

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

    Si tiene más de una regla en el grupo dinámico, asegúrese de utilizar la opción Match any rules defined below.

  2. Cree una política de IAM que proporcione al grupo dinámico de destinos de montaje acceso de lectura a los secretos de Vault:

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