Comprenda el uso de LDAP con Azure NetApp Files

Article
06/17/2024

El protocolo ligero de acceso a directorios (LDAP) es un protocolo estándar de acceso a directorios desarrollado por un comité internacional denominado Grupo de trabajo de ingeniería de Internet (IETF). LDAP está diseñado para proporcionar un servicio de directorio basado en red y de uso general que se puede utilizar en plataformas heterogéneas para localizar objetos de red.

Los modelos LDAP definen cómo comunicarse con el almacén de directorios LDAP, cómo encontrar un objeto en el directorio, cómo describir los objetos del almacén y la seguridad que se utiliza para acceder al directorio. LDAP permite la personalización y extensión de los objetos que se describen en el almacén. Por lo tanto, puede utilizar un almacén LDAP para almacenar muchos tipos de información diversa. Muchas de las implementaciones iniciales de LDAP se centraron en el uso de LDAP como almacén de directorios para aplicaciones como el correo electrónico y las aplicaciones web y para almacenar información de los empleados. Muchas empresas reemplazan o han reemplazado Servicio de información de la red (NIS) por LDAP como almacén de directorios de red.

Un servidor LDAP proporciona identidades de usuarios y grupos UNIX para su uso con volúmenes NAS. En Azure NetApp Files, Active Directory es el único servidor LDAP admitido actualmente que se puede usar. Esta compatibilidad incluye Active Directory Domain Services (AD DS) y Microsoft Entra Domain Services.

Las solicitudes LDAP se pueden dividir en dos operaciones principales.

Los enlaces LDAP son inicios de sesión en el servidor LDAP desde un cliente LDAP. El enlace se usa para autenticarse en el servidor LDAP con acceso de solo lectura para realizar búsquedas LDAP. Azure NetApp Files actúa como un cliente LDAP.
Las búsquedas LDAP se usan para consultar el directorio de información de usuarios y grupos, como nombres, id. numéricos, rutas de directorios personales, rutas de shell de inicio de sesión, pertenencia a grupos, etc.

LDAP puede almacenar la siguiente información que se usa en el acceso NAS de protocolo dual:

Nombres de usuario
Nombres de grupo
Id. numérico de usuario (UID) e id. de grupo (GID)
Directorios principales
Shell de inicio de sesión
Netgroups, nombres DNS y direcciones IP
Pertenencia a grupos

Actualmente, Azure NetApp Files solo usa LDAP para la información de usuarios y grupos, pero no para la información de netgroup o hosts.

LDAP ofrece varias ventajas para sus usuarios y grupos UNIX como fuente de identidad.

LDAP es a prueba de futuro.
A medida que más clientes NFS agregan compatibilidad con NFSv4.x, se necesitan dominios de id. NFSv4.x que contengan una lista actualizada de usuarios y grupos accesibles desde los clientes y el almacenamiento para garantizar una seguridad óptima y un acceso garantizado cuando se defina el acceso. Tener un servidor de administración de identidades que proporcione asignaciones de nombres uno a uno para los usuarios de SMB y NFS por igual simplifica considerablemente la vida útil para los administradores de almacenamiento, no solo en el presente, sino por años.
LDAP es escalable.
Los servidores LDAP ofrecen la posibilidad de contener millones de objetos de usuario y grupo, y con Microsoft Active Directory, se pueden utilizar varios servidores para replicarse en varios sitios, tanto a escala de rendimiento como de resistencia.
LDAP es seguro.
LDAP ofrece seguridad en forma de cómo un sistema de almacenamiento puede conectarse al servidor LDAP para realizar solicitudes de información del usuario. Los servidores LDAP ofrecen los siguientes niveles de enlace:
- Anónimo (deshabilitado de forma predeterminada en Microsoft Active Directory; no se admite en Azure NetApp Files)
- Contraseña simple (contraseñas de texto sin formato; no se admite en Azure NetApp Files)
- Nivel de seguridad y autenticación simples (SASL): métodos de enlace cifrados, como TLS, SSL, Kerberos, etc. Azure NetApp Files admite LDAP a través de TLS, firma LDAP (mediante Kerberos), LDAP a través de SSL.
LDAP es sólido.
Los archivos NIS, NIS+ y locales ofrecen información básica como UID, GID, contraseña, directorios principales, etc. Sin embargo, LDAP ofrece esos atributos y muchos más. Los atributos adicionales que usa LDAP hacen que la administración de protocolos duales sea mucho más integrada con LDAP frente a NIS. Solo se admite LDAP como un servicio de nombres externo para la administración de identidades con Azure NetApp Files.
Microsoft Active Directory se basa en LDAP.
De manera predeterminada, Microsoft Active Directory utiliza un backend LDAP para sus entradas de usuarios y grupos. Sin embargo, esta base de datos LDAP no contiene atributos de estilo UNIX. Estos atributos se agregan cuando el esquema LDAP se extiende a través de Identity Management para UNIX (Windows 2003R2 y versiones posteriores), Servicio para UNIX (Windows 2003 y versiones anteriores) o herramientas LDAP de terceros como Centrify. Dado que Microsoft utiliza LDAP como backend, lo convierte en la solución perfecta para los entornos que deciden aprovechar los volúmenes de doble protocolo en Azure NetApp Files.

Nota:

Actualmente, Azure NetApp Files solo admite Microsoft Active Directory nativo para los servicios LDAP.

Conceptos básicos de LDAP en Azure NetApp Files

En la sección siguiente se describen los conceptos básicos de LDAP en lo que respecta a Azure NetApp Files.

La información LDAP se almacena en archivos planos en un servidor LDAP y se organiza mediante un esquema LDAP. Debe configurar clientes LDAP de una manera que coordine sus solicitudes y búsquedas con el esquema en el servidor LDAP.
Los clientes LDAP inician consultas mediante un enlace LDAP, que es básicamente un inicio de sesión en el servidor LDAP mediante una cuenta que tiene acceso de lectura al esquema LDAP. La configuración de enlace LDAP en los clientes está configurada para usar el mecanismo de seguridad definido por el servidor LDAP. A veces, son intercambios de nombre de usuario y contraseña en texto sin formato (simple). En otros casos, los enlaces se protegen mediante métodos de nivel de seguridad y autenticación simples (sasl), como Kerberos o LDAP a través de TLS. Azure NetApp Files usa la cuenta del equipo SMB para enlazar mediante la autenticación SASL para obtener la mejor seguridad posible.
Los clientes consultan la información de usuario y grupo almacenada en LDAP mediante solicitudes de búsqueda LDAP estándar, tal como se define en RFC 2307. Además, los mecanismos más recientes, como RFC 2307bis, permiten búsquedas de usuarios y grupos más simplificadas. Azure NetApp Files usa una forma de RFC 2307bis para sus búsquedas de esquema en Windows Active Directory.
Los servidores LDAP pueden almacenar información sobre usuarios y grupos y netgroup. Sin embargo, Azure NetApp Files actualmente no puede usar la funcionalidad netgroup en LDAP en Windows Active Directory.
LDAP en Azure NetApp Files funciona en el puerto 389. Actualmente, este puerto no se puede modificar para usar un puerto personalizado, como el puerto 636 (LDAP a través de SSL) o el puerto 3268 (búsquedas en el catálogo global de Active Directory).
Las comunicaciones LDAP cifradas se pueden lograr mediante LDAP a través de TLS (que funciona a través del puerto 389) o la firma LDAP, ambas que se pueden configurar en la conexión de Active Directory.
Azure NetApp Files admite consultas LDAP que no tardan más de 3 segundos en completarse. Si el servidor LDAP tiene muchos objetos, ese tiempo de espera puede superarse y se pueden producir errores en las solicitudes de autenticación. En esos casos, considere la posibilidad de especificar un ámbito de búsqueda LDAP para filtrar las consultas y obtener un mejor rendimiento.
Azure NetApp Files también admite la especificación de servidores LDAP preferidos para ayudar a acelerar las solicitudes. Use esta configuración si desea asegurarse de que se usa el servidor LDAP más cercano a su región de Azure NetApp Files.

Si no se establece ningún servidor LDAP preferido, el nombre de dominio de Active Directory se consulta en DNS para los registros del servicio LDAP para rellenar la lista de servidores LDAP disponibles para la región que se encuentra dentro de ese registro SRV. Puede consultar manualmente los registros del servicio LDAP en DNS desde un cliente utilizando los comandos nslookup o dig.

Por ejemplo:

C:\>nslookup
Default Server:  localhost
Address:  ::1

> set type=SRV
> _ldap._tcp.contoso.com.

Server:  localhost
Address:  ::1

_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 0
          port           = 389
          svr hostname   = oneway.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = ONEWAY.Contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = oneway.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = parisi-2019dc.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = contoso.com
oneway.contoso.com       internet address = x.x.x.x
ONEWAY.Contoso.com       internet address = x.x.x.x
oneway.contoso.com       internet address = x.x.x.x
parisi-2019dc.contoso.com        internet address = y.y.y.y
contoso.com      internet address = x.x.x.x
contoso.com      internet address = y.y.y.y

Los servidores LDAP también pueden utilizarse para realizar asignaciones de nombres personalizadas para los usuarios. Para obtener más información, consulte Asignación de nombres personalizada mediante LDAP.
Tiempos de espera de consulta LDAP

De manera predeterminada, las consultas LDAP agotan el tiempo de espera si no se pueden completar de forma oportuna. Si se produce un error en una consulta LDAP debido a un tiempo de espera, se producirá un error en la búsqueda de usuarios o grupos y se puede denegar el acceso al volumen de Azure NetApp Files en función de la configuración de permisos del volumen. Consulte Creación y administración de conexiones de Active Directory para comprender la configuración del tiempo de espera de consulta LDAP de Azure NetApp Files.

Tipos de asignación de nombres

Las reglas de asignación de nombres se pueden dividir en dos tipos principales: simétricos y asimétricos.

La asignación simétrica de nombres es la asignación implícita de nombres entre usuarios UNIX y Windows que utilizan el mismo nombre de usuario. Por ejemplo, el usuario de Windows CONTOSO\user1 se asigna al usuario UNIX user1.
La asignación asimétrica de nombres es la asignación de nombres entre usuarios de UNIX y Windows que utilizan nombres de usuario diferentes. Por ejemplo, el usuario de Windows CONTOSO\user1 se asigna al usuario UNIX user2.

De manera predeterminada, Azure NetApp Files usa reglas de asignación de nombres simétricas. Si se requieren reglas de asignación de nombres asimétricas, considere la posibilidad de configurar los objetos de usuario LDAP para usarlos.

Asignación de nombres personalizada mediante LDAP

LDAP puede ser un recurso de asignación de nombres, si se han rellenado los atributos del esquema LDAP en el servidor LDAP. Por ejemplo, para asignar usuarios UNIX a los nombres de usuario de Windows correspondientes que no coinciden con uno a uno (es decir, asimétrico), puede especificar un valor diferente para uid en el objeto de usuario que el configurado para el nombre de usuario de Windows.

En el siguiente ejemplo, un usuario tiene un nombre Windows de asymmetric y necesita asignarse a una identidad UNIX de UNIXuser. Para conseguirlo en Azure NetApp Files, abra una instancia de Usuarios y equipos de Active Directory de MMC. A continuación, busque el usuario deseado y abra el cuadro de propiedades. (Para ello, es necesario habilitar el Editor de atributos). Vaya a la pestaña Editor de atributos y busque el campo UID, rellene el campo UID con el nombre de usuario UNIX UNIXuser deseado y haga clic en Agregar y Aceptar para confirmar.

Una vez realizada esta acción, los archivos escritos desde recursos compartidos SMB de Windows por el usuario asymmetric de Windows serán propiedad de UNIXuser desde el lado NFS.

El siguiente ejemplo muestra el propietario asymmetric de Windows SMB:

El siguiente ejemplo muestra el propietario NFS UNIXuser ( asignado desde el usuario Windows asymmetric usando LDAP):

root@ubuntu:~# su UNIXuser
UNIXuser@ubuntu:/root$ cd /mnt
UNIXuser@ubuntu:/mnt$ ls -la
total 8
drwxrwxrwx  2 root     root   4096 Jul  3 20:09 .
drwxr-xr-x 21 root     root   4096 Jul  3 20:12 ..
-rwxrwxrwx  1 UNIXuser group1   19 Jul  3 20:10 asymmetric-user-file.txt

Permitir usuarios de NFS locales con LDAP

Cuando un usuario intenta acceder a un volumen de Azure NetApp Files a través de NFS, la solicitud se incluye en un id. numérico. De manera predeterminada, Azure NetApp Files admite pertenencias extendidas a grupos para usuarios NFS (para ir más allá del límite estándar de 16 grupos). Como resultado, los archivos de Azure NetApp intentarán tomar ese id. numérico y buscarlo en LDAP en un intento de resolver las pertenencias a grupos para el usuario en lugar de pasar las pertenencias a grupos en un paquete RPC. Debido a este comportamiento, si ese id. numérico no se puede resolver en un usuario de LDAP, se producirá un error en la búsqueda y se denegará el acceso, incluso si el usuario solicitante tiene permiso para acceder al volumen o la estructura de datos. La opción Permitir usuarios NFS locales con LDAP en conexiones de Active Directory está pensada para deshabilitar esas búsquedas LDAP para las solicitudes NFS deshabilitando la funcionalidad de grupo extendido. No ofrece "creación o administración de usuarios locales" dentro de Azure NetApp Files.

Cuando la opción "Permitir usuarios NFS locales con LDAP" está habilitada, los id. numéricos se pasan a Azure NetApp Files y no se realiza ninguna búsqueda LDAP. Esto crea un comportamiento variable para distintos escenarios, como se describe a continuación.

NFSv3 con volúmenes de estilo de seguridad de UNIX

No es necesario traducir los id. numéricos a los nombres de usuario. La opción "Permitir usuarios NFS locales con LDAP" no afectará al acceso al volumen, pero puede afectar a cómo se muestra la propiedad del usuario/grupo (traducción de nombres) en el cliente NFS. Por ejemplo, si un id. numérico de 1001 es usuario1 en LDAP, pero es usuario2 en el archivo passwd local del cliente NFS, el cliente mostrará "usuario2" como propietario del archivo cuando el id. numérico sea 1001.

NFSv4.1 con volúmenes de estilo de seguridad de UNIX

No es necesario traducir los id. numéricos a los nombres de usuario. De manera predeterminada, NFSv4.1 usa cadenas de nombre (user@CONTOSO.COM) para su autenticación. Sin embargo, Azure NetApp Files admite el uso de id. numéricos con NFSV4.1, lo que significa que las solicitudes NFSv4.1 llegarán al servidor NFS con un id. numérico. Si no existe una traducción de id. numérico a nombre de usuario en los archivos locales o en los servicios de nombres como LDAP para el volumen Azure NetApp Files, se presenta el numérico al cliente. Si un id. numérico se traduce en un nombre de usuario, se usará la cadena de nombre. Si la cadena de nombre no coincide, el cliente aplastará el nombre al usuario anónimo especificado en el archivo idmapd.conf del cliente. Habilitar la opción "Permitir usuarios NFS locales con LDAP" no afectará al acceso NFSv4.1, ya que volverá al comportamiento NFSv3 estándar a menos que Azure NetApp Files pueda resolver un id. numérico con un nombre de usuario en su base de datos de usuarios NFS local. Azure NetApp Files cuenta con un conjunto de usuarios UNIX predeterminados que puede resultar problemático para algunos clientes y que se aplasta a un usuario "nadie" si las cadenas de id. de dominio no coinciden.

Los usuarios locales incluyen: raíz (0), pcuser (65534), nadie (65535).
Los grupos locales incluyen: raíz (0), demonio (1), pcuser (65534), nadie (65535).

Normalmente, la raíz puede mostrarse incorrectamente en los montajes de cliente NFSv4.1 cuando el id. de dominio NFSv4.1 está mal configurado. Para obtener más información sobre el dominio de id. NFSv4.1, consulte Configuración del dominio de id. NFSv4.1 para Azure NetApp Files.

Las ACL NFSv4.1 se pueden configurar mediante una cadena de nombre o un id. numérico. Si se usan id. numéricos, no se requiere ninguna traducción de nombres. Si se usa una cadena de nombre, la traducción de nombres sería necesaria para la resolución de ACL adecuada. Al usar ACL NFSv4.1, habilitar "Permitir usuarios NFS locales con LDAP" puede provocar un comportamiento incorrecto de ACL nfSv4.1 en función de la configuración de ACL.

NFS (v3 y v4.1) con volúmenes de estilo de seguridad NTFS en configuraciones de protocolo dual

Los volúmenes de estilo de seguridad de UNIX aprovechan los permisos de estilo UNIX (bits de modo y ACL NFSv4.1). Para esos tipos de volúmenes, NFS solo aprovecha la autenticación al estilo UNIX mediante un id. numérico o una cadena de nombre, dependiendo de los escenarios mencionados anteriormente. Sin embargo, los volúmenes de estilo de seguridad NTFS usan permisos de estilo NTFS. Estos permisos se asignan mediante usuarios y grupos de Windows. Cuando un usuario NFS intenta acceder a un volumen con un permiso de estilo NTFS, debe producirse una asignación de nombres UNIX a Windows para garantizar los controles de acceso adecuados. En este escenario, el id. numérico NFS se sigue pasando al volumen NFS de Azure NetApp Files, pero es necesario que el id. numérico se traduzca a un nombre de usuario UNIX para que, a continuación, se pueda asignar a un nombre de usuario Windows para la autenticación inicial. Por ejemplo, si el id. numérico 1001 intenta acceder a un montaje NFS con permisos de estilo de seguridad NTFS que permiten el acceso al usuario de Windows "user1", entonces 1001 necesitaría resolverse en LDAP al nombre de usuario "user1" para obtener el acceso esperado. Si no existe ningún usuario con el id. numérico "1001" en LDAP, o si LDAP está mal configurado, la asignación de nombre de UNIX a Windows que se intente será 1001@contoso.com. En la mayoría de los casos, los usuarios con ese nombre no existen, por lo que se produce un error en la autenticación y se deniega el acceso. Del mismo modo, si el id. numérico 1001 se resuelve en el nombre de usuario incorrecto (por ejemplo, user2), la solicitud NFS se asignará a un usuario inesperado de Windows y los permisos para el usuario usarán los controles de acceso "user2".

Al habilitar "Permitir usuarios NFS locales con LDAP", se deshabilitarán todas las traducciones LDAP de id. numéricos a nombres de usuario, lo que interrumpirá eficazmente el acceso a volúmenes de estilo de seguridad NTFS. Por lo tanto, no se recomienda el uso de esta opción con volúmenes de estilo de seguridad NTFS.

Esquemas LDAP

Los esquemas LDAP son la forma en que los servidores LDAP organizan y recopilan información. Los esquemas de servidor LDAP suelen seguir los mismos estándares, pero es posible que distintos proveedores de servidores LDAP tengan variaciones en cómo se presentan los esquemas.

Cuando Azure NetApp Files consulta LDAP, los esquemas se utilizan para ayudar a acelerar las búsquedas de nombres, ya que permiten el uso de atributos específicos para encontrar información sobre un usuario, como el UID. Los atributos del esquema deben existir en el servidor LDAP para que Azure NetApp Files pueda encontrar la entrada. De lo contrario, las consultas LDAP podrían no devolver ningún dato y las solicitudes de autenticación podrían fallar.

Por ejemplo, si Azure NetApp Files debe consultar un número UID (como root=0), se utiliza el atributo de esquema RFC 2307 uidNumber Attribute. Si no existe ningún UID número 0 en LDAP en el campo uidNumber, se produce un error en la solicitud de búsqueda.

El tipo de esquema usado actualmente por Azure NetApp Files es una forma de esquema basado en RFC 2307bis y no se puede modificar.

RFC 2307bis es una extensión de RFC 2307 y agrega soporte para posixGroup, que permite búsquedas dinámicas para grupos auxiliares usando el atributo uniqueMember, en lugar de usar el atributo memberUid en el esquema LDAP. En lugar de usar solo el nombre del usuario, este atributo contiene el nombre distintivo completo (DN) de otro objeto de la base de datos LDAP. Por lo tanto, los grupos pueden tener otros grupos como miembros, lo que permite anidar grupos. El soporte con RFC 2307bis también agrega compatibilidad con la clase de objeto groupOfUniqueNames.

Esta extensión RFC se adapta perfectamente a la forma en que Microsoft Active Directory administra usuarios y grupos a través de las herramientas de administración habituales. Esto se debe a que cuando se agrega un usuario de Windows a un grupo (y si ese grupo tiene un GID numérico válido) utilizando los métodos de administración estándar de Windows, las búsquedas LDAP extraerán la información suplementaria necesaria del grupo del atributo habitual de Windows y encontrarán los GID numéricos automáticamente.

Comparteix a través de