Los protocolos de uso compartido de archivos, como SMB (CIFS), NFSv3 con grupos extendidos y NFSv4, que usan principios de seguridad, dependen de servicios de directorio externos para proporcionar información de identidad del usuario. NetApp Volumes se basa en Microsoft Active Directory para los servicios de directorio. Active Directory proporciona servicios como servidores LDAP para buscar objetos, como usuarios, grupos y cuentas de máquinas, servidores DNS para resolver nombres de host y servidores Kerberos para la autenticación.
Para obtener más información, consulta Prácticas recomendadas para ejecutar Active Directory en Google Cloud.
Los volúmenes de NetApp no son compatibles con Microsoft Active Directory administrado de Google Cloud.
Casos de uso
NetApp Volumes usa Active Directory para los casos que se describen en las siguientes secciones.
Servicio de dominio SMB
Active Directory es el servicio de dominio central para las pymes. El SMB se usa para la autenticación y la búsqueda de identidades de usuarios y grupos. NetApp Volumes se une al dominio como miembro y no admite SMB en modo de grupo de trabajo.
Compatibilidad con grupos extendidos de NFSv3
Para NFSv3 con compatibilidad con grupos extendidos, Active Directory proporciona el servidor LDAP necesario para buscar objetos, como usuarios, grupos o cuentas de máquinas. Específicamente, se requiere un servidor LDAP que cumpla con el RFC2307bis para las búsquedas de IDs de usuario y de grupo. La compatibilidad con LDAP se habilita en los grupos de almacenamiento durante su creación.
La compatibilidad con grupos extendidos ignora todos los IDs de grupo que envía el cliente de NFS en una llamada de NFS. En su lugar, toma el ID de usuario de la solicitud y busca todos los IDs de grupo para el ID de usuario determinado en el servidor LDAP para realizar verificaciones de permisos de archivos.
Para obtener más información, consulta Administra atributos POSIX de LDAP RFC2307bis.
Mapeo de principal de seguridad de NFSv4.x a ID de usuario y ID de grupo
En NFSv4.x, se usa Active Directory para asignar principales de seguridad a IDs de usuario y de grupo. NFSv4 usa un modelo de autenticación basado en el principal. En la autenticación basada en principales, los usuarios se identifican con entidades de seguridad que tienen el formato user@dns_domain (consulta https://www.rfc-editor.org/rfc/rfc7530.html#section-19) en lugar de hacerlo con IDs de usuario y de grupo. Para asignar principales de seguridad a los IDs de usuario y de grupo cuando se accede al volumen con un protocolo NFSv4.x, los volúmenes de NetApp requieren un servidor LDAP que cumpla con RFC2307bis. El único servidor LDAP compatible es Active Directory. La compatibilidad con LDAP se habilita en los grupos de almacenamiento durante su creación.
Para usar los principales de seguridad, el cliente y el servidor de NFS deben conectarse a la misma fuente de LDAP, y el archivo idmapd.conf se debe configurar en el cliente. Para obtener más información sobre la configuración del archivo idmapd.conf, consulta la página de manual de Ubuntu: idmapd.conf: archivo de configuración de libnfsidmap.
El nombre de dominio de Active Directory se usa para dns_domain. user es el nombre de los usuarios de Active Directory. Usa estos valores cuando establezcas tus atributos POSIX de LDAP.
Para usar NFSv4.1 sin configurar la asignación de IDs y solo usar IDs de usuario y de grupo similares a NFSv3, puedes usar IDs numéricos para ignorar los principales de seguridad. NetApp Volumes admite IDs numéricos, y los clientes de NFS actuales usan IDs numéricos de forma predeterminada si no se configura la asignación de IDs.
NFSv4.x con Kerberos
Si usas Kerberos, es obligatorio usar Active Directory como el servidor LDAP para las búsquedas de principales de seguridad. Los principales de Kerberos se usan como identificadores de seguridad. Active Directory también se usa como centro de distribución de claves (KDC) de Kerberos. Para que esto funcione, debes adjuntar una política de Active Directory que contenga la configuración de Kerberos al grupo y habilitar la compatibilidad con LDAP en un grupo de almacenamiento durante su creación.
Para obtener más información, consulta Cómo crear un grupo de almacenamiento.
Acceso a LDAP de Active Directory
En los casos de uso de NFS, Active Directory se usa como servidor LDAP. NetApp Volumes espera datos de identidad con un esquema RFC2307bis. Active Directory ya proporciona este esquema, pero debes asegurarte de propagar los atributos necesarios para tus usuarios y grupos.
Los volúmenes de NetApp usan las credenciales proporcionadas de la política de Active Directory para vincularse con LDAP mediante la firma de LDAP.
Si no se puede encontrar el usuario o el grupo, se denegará el acceso.
Almacenamiento en caché de atributos
NetApp Volumes almacena en caché los resultados de las consultas de LDAP. En la siguiente tabla, se describe la configuración del tiempo de actividad (TTL) para la caché de LDAP. Si la caché contiene datos no válidos debido a parámetros de configuración incorrectos que intentas corregir, debes esperar a que se actualice la caché antes de que se detecten los cambios en Active Directory. De lo contrario, el servidor NFS seguirá usando los datos anteriores para verificar el acceso, lo que probablemente genere mensajes de permiso denegado en el cliente. Después del período de TTL, las entradas se vuelven obsoletas para que no permanezcan. Las solicitudes de búsqueda que no se encuentran se retienen durante un TTL de un minuto para ayudar a evitar problemas de rendimiento.
| Caché | Tiempo de espera predeterminado |
|---|---|
| Lista de membresías de grupos | TTL de 24 horas |
| Grupos de Unix (GID) | TTL de 24 horas, TTL negativo de 1 minuto |
| Usuarios de Unix (UID) | TTL de 24 horas, TTL negativo de 1 minuto |
Topologías de controladores de dominio de Active Directory
Una vez que te conectes correctamente a los controladores de dominio de Active Directory, puedes usar los siguientes protocolos de uso compartido de archivos:
- SMB
- NFSv3 con grupos extendidos
- NFSv4
En las siguientes secciones, se ilustran varias topologías posibles. Los diagramas solo muestran el controlador de dominio que usan NetApp Volumes. Los demás controladores de dominio para el mismo dominio solo se muestran cuando es necesario.
Microsoft recomienda implementar al menos dos controladores de dominio (DC) para la redundancia y la disponibilidad.
Controlador de dominio de Active Directory en la misma región que los volúmenes de NetApp Volumes
En el siguiente diagrama, se muestra el modo de implementación más simple, un controlador de dominio en la misma región que los volúmenes de NetApp Volumes.
Controladores de dominio de Active Directory en varias regiones que usan sitios de AD
Si usas volúmenes de NetApp Volumes en varias regiones, te recomendamos que coloques al menos un controlador de dominio en cada región. Mientras el servicio intenta elegir el mejor DC para usar automáticamente, se recomienda administrar la selección de DC con los sitios de AD.
Controlador de dominio de Active Directory en una red local
Se admite el uso de un controlador de dominio local a través de VPN, pero es posible que afecte negativamente la autenticación del usuario final y el rendimiento del acceso a los archivos. Asegúrate de no agregar saltos de intercambio de tráfico de VPC adicionales en la ruta de red.
Consideraciones para los DCs locales
Las conexiones a los DCs locales usan TCP e IP. Estas conexiones suelen fallar debido a las siguientes limitaciones:
Intercambio de tráfico entre redes de VPC: Los volúmenes de NetApp solo pueden llegar a los DCs que están en la VPC del grupo de almacenamiento o conectados a ella a través de VPN. Los volúmenes de NetApp no pueden llegar a los DCs en ninguna otra VPC, incluidas aquellas que están en intercambio de tráfico con la VPC que se conecta al almacenamiento del grupo.
Firewalls: Debes permitir que NetApp Volumes se comunique con tus DCs. Consulta las reglas de firewall para el acceso a Active Directory.
Controlador de dominio de Active Directory en una red de VPC diferente
No puedes colocar el controlador de dominio en una VPC diferente porque el intercambio de tráfico entre VPC de Google Cloud no permite el enrutamiento de transición. Como alternativa, puedes conectar los volúmenes de NetApp a una red de VPC compartida que aloje los controladores de dominio de Active Directory. Si conectas volúmenes de NetApp a una red de VPC compartida, desde el punto de vista arquitectónico, esta situación se convierte en una de las situaciones de las secciones anteriores.
Administra las selecciones de DC mediante los sitios de AD
Para representar las ubicaciones, las oficinas y la topología de red reales del centro de datos lo más cerca posible, coloca los controladores de dominio en la misma región que tus volúmenes y define un sitio de Active Directory para esa región.
Cuando NetApp Volumes está conectado a tu dominio, el servicio usa el descubrimiento basado en DNS para encontrar los controladores de dominio correctos con los que comunicarse. Con los resultados del descubrimiento, el servicio mantiene una lista de DCs válidas para conectarse y usa la que tiene la latencia más baja.
Cuando especificas un sitio en la configuración de Active Directory de los volúmenes de NetApp, puedes limitar la lista de DCs a los que se especifican en el sitio de AD.
Si la selección automática de DC falla, usar sitios de AD puede ayudar a solucionar el problema:
Implementa al menos un controlador de dominio en la región de NetApp Volumes y conéctalo a tu Active Directory existente.
Crea un sitio de Active Directory para tu región de Google Cloud y coloca los controladores de dominio adecuados en ese sitio.
Usa el sitio de Active Directory cuando configures conexiones de Active Directory.
Para verificar manualmente la lista de posibles DCs que puede usar el servicio, consulta Cómo identificar los controladores de dominio de Active Directory que usan los volúmenes de NetApp.
Para obtener más información, consulta Active Directory: Consideraciones de diseño y prácticas recomendadas.