Descripción de los esquemas de LDAP en Azure NetApp Files
Los esquemas de protocolo ligero de acceso a directorios (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.
Cuando los volúmenes de Azure NetApp Files necesitan realizar búsquedas LDAP para identidades de usuario NFS, una serie de atributos definidos por un esquema LDAP basado en RFC-2307bis. En la tabla siguiente se muestran los atributos que las búsquedas LDAP usan, que son los valores predeterminados definidos en Microsoft Active Directory cuando se usan atributos UNIX. Para una funcionalidad adecuada, asegúrese de que estos atributos se rellenen correctamente en las cuentas de usuario y grupo en LDAP.
| Atributo UNIX | Valor del esquema LDAP |
|---|---|
| Nombre de usuario de UNIX | uid* |
| Identificador numérico de usuario de UNIX | uidNumber* |
| Nombre del grupo UNIX | cn* |
| Identificador numérico del grupo UNIX | gidNumber* |
| Pertenencia al grupo UNIX | miembro** |
| Clase de objeto de usuario de UNIX | Usuario** |
| Directorio de inicio de UNIX | unixHomeDirectory |
| Nombre para mostrar de UNIX | gecos |
| Contraseña de usuario de UNIX | unixUserPassword |
| Shell de inicio de sesión de UNIX | LoginShell |
| Cuenta de Windows usada para la asignación de nombres | sAMAccountName** |
| Clase de objeto del grupo de UNIX | Grupo** |
| UID de miembro de UNIX | memberUid*** |
| Grupo UNIX de la clase de objeto de nombres únicos | Grupo** |
* Atributo necesario para la funcionalidad LDAP adecuada
** Rellenado en Active Directory de forma predeterminada
*** No es necesario
Descripción de la indexación de atributos LDAP
El LDAP de Active Directory proporciona un método de indexación para atributos que ayuda a acelerar las solicitudes de búsqueda. Esto es especialmente útil en entornos de directorios grandes, donde una búsqueda LDAP puede superar potencialmente el valor de tiempo de espera de 10 segundos para búsquedas en Azure NetApp Files. Si una búsqueda supera su valor de tiempo de espera, se produce un error en la búsqueda LDAP y el acceso no funcionará correctamente porque el servicio no puede comprobar el acceso de usuario o grupo que solicita acceso.
De forma predeterminada, LDAP de Microsoft Active Directory indexará los siguientes atributos UNIX que usa Azure NetApp Files para búsquedas LDAP:
El atributo uid no está indexado de forma predeterminada. Como resultado, las consultas LDAP para el UID tardan más tiempo que las consultas de atributos indexados.
Por ejemplo, en la siguiente prueba de una consulta en un entorno de Active Directory con más de 20 000 usuarios y grupos, una búsqueda de un usuario con el atributo indexado CN tardó aproximadamente 0,015 segundos, mientras que una búsqueda para el mismo usuario con el atributo UID (que no está indexado de forma predeterminada) tardó más cerca de 0,6 segundos (40 veces más lento).
En entornos más pequeños, esto no causa problemas. Pero en entornos más grandes (o entornos en los que el entorno de Active Directory está en el entorno local o tiene una latencia de red alta), la diferencia puede ser lo suficientemente drástica como para provocar problemas de acceso para los usuarios que acceden a volúmenes de Azure NetApp Files. Como resultado, se recomienda configurar el atributo UID en LDAP para que Active Directory lo indexe.
Configuración del atributo UID que va a indexar Active Directory
Los atributos se indexan a través del valor searchFlags para el objeto de atributo, que se puede configurar a través de ADSI Edit en el contexto de nomenclatura de esquemas. El acceso a ADSI Edit debe abordarse con precaución y requiere como mínimo privilegios de administrador de esquemas.
De forma predeterminada, el searchFlags del objeto de atributo UID se establece en 0x8 (PRESERVE_ON_DELETE). Esta configuración predeterminada garantiza que aunque se elimine el objeto de Active Directory, el valor del atributo permanece almacenado en el directorio como registro histórico del atributo del usuario.
En comparación, un atributo indexado en Active Directory para búsquedas LDAP tendría el valor de 0x1 (o alguna combinación que incluya ese valor), como uidNumber:
Debido a esto, las consultas para uidNumber se devuelven más rápido que las consultas de uid. Para lograr coherencia y rendimiento, puede ajustar el valor de searchFlags para UID a 9 agregando 0x1 junto con el valor existente de 0x8, que es (INDEX | PRESERVE_ON_DELETE). Esta adición mantiene el comportamiento predeterminado al agregar la indexación de atributos al directorio.
Con la indexación, las búsquedas de atributos de usuario con uid son tan rápidas como las búsquedas de otros atributos indexados.