Los protocolos de uso compartido de archivos, como SMB (CIFS), NFSv3 con grupos ampliados y NFSv4, que usan entidades de seguridad, dependen de servicios de directorio externos para proporcionar información de identidad de usuario. NetApp Volumes usa Microsoft Active Directory para los servicios de directorio. Active Directory proporciona servicios como servidores LDAP para buscar objetos (por ejemplo, usuarios, grupos o 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 las prácticas recomendadas para ejecutar Active Directory en Google Cloud.
NetApp Volumes no admite Managed Microsoft Active Directory de Google Cloud.
Casos prácticos
NetApp Volumes usa Active Directory en los casos que se describen en las siguientes secciones.
Servicio de dominio SMB
Active Directory es el servicio de dominio central para pymes. SMB se usa para la autenticación y las búsquedas de identidades de usuarios y grupos. NetApp Volumes se une al dominio como miembro y no admite SMB en el modo de grupo de trabajo.
Compatibilidad con grupos extendida de NFSv3
En el caso de NFSv3 con compatibilidad con grupos extendidos, Active Directory proporciona el servidor LDAP necesario para buscar objetos, como usuarios, grupos o cuentas de máquinas. En concreto, se necesita un servidor LDAP compatible con RFC2307bis para búsquedas de ID de usuario e ID de grupo. La compatibilidad con LDAP se habilita en los grupos de almacenamiento durante la creación de grupos.
La compatibilidad con grupos ampliada ignora todos los IDs de grupo enviados por el cliente NFS en una llamada NFS. En su lugar, toma el ID de usuario de la solicitud y busca todos los IDs de grupo del ID de usuario en el servidor LDAP para comprobar los permisos de archivo.
Para obtener más información, consulta el artículo Gestionar atributos POSIX de LDAP RFC2307bis.
Asignación de principal de seguridad de NFSv4.x a ID de usuario e ID de grupo
En el caso de NFSv4.x, Active Directory se usa para asignar los principales de seguridad a los IDs de usuario y de grupo. NFSv4 usa un modelo de autenticación basado en principales. En la autenticación basada en entidades principales, los usuarios se identifican mediante entidades principales de seguridad que tienen el formato user@dns_domain (consulta https://www.rfc-editor.org/rfc/rfc7530.html#section-19) en lugar de identificarse mediante IDs de usuario y de grupo. Para asignar principales de seguridad a IDs de usuario y de grupo al acceder al volumen mediante un protocolo NFSv4.x, NetApp Volumes requiere un servidor LDAP compatible con RFC2307bis. El único servidor LDAP compatible es Active Directory. La compatibilidad con LDAP se habilita en los grupos de almacenamiento durante la creación del grupo.
Para usar los principales de seguridad, el cliente y el servidor NFS deben conectarse a la misma fuente LDAP y el archivo idmapd.conf debe configurarse en el cliente. Para obtener más información sobre cómo configurar el archivo idmapd.conf, consulta la página del manual de Ubuntu sobre idmapd.conf: archivo de configuración de libnfsidmap.
El nombre de dominio de Active Directory se usa para dns_domain. El usuario es el nombre de los usuarios de Active Directory. Utilice estos valores cuando configure sus atributos POSIX de LDAP.
Para usar NFSv4.1 sin configurar la asignación de ID y usar solo los IDs de usuario y los IDs de grupo de forma similar a NFSv3, puedes usar IDs numéricos para ignorar las entidades de seguridad. NetApp Volumes admite IDs numéricos y los clientes de NFS actuales usan IDs numéricos de forma predeterminada si no se ha configurado la asignación de IDs.
NFSv4.x con Kerberos
Si usas Kerberos, es obligatorio usar Active Directory como servidor LDAP para las búsquedas de entidades 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 pool y habilitar la compatibilidad con LDAP en un pool de almacenamiento durante la creación del pool.
Para obtener más información, consulta el artículo Crear un pool de almacenamiento.
Acceso LDAP de Active Directory
En los casos prácticos de NFS, Active Directory se utiliza como servidor LDAP. NetApp Volumes espera datos de identidad con un esquema RFC2307bis. Active Directory ya proporciona este esquema, pero debes asegurarte de rellenar los atributos obligatorios de tus usuarios y grupos.
NetApp Volumes usa las credenciales proporcionadas por la política de Active Directory para enlazarse con LDAP mediante la firma LDAP.
Si no se encuentra el usuario o el grupo, se deniega el acceso.
Almacenamiento en caché de atributos
NetApp Volumes almacena en caché los resultados de las consultas LDAP. En la siguiente tabla se describen los ajustes de tiempo de vida (TTL) de la caché de LDAP. Si la caché contiene datos no válidos debido a errores de configuración que estás intentando corregir, debes esperar a que se actualice la caché para que se detecten los cambios en Active Directory. De lo contrario, el servidor NFS seguirá usando los datos antiguos para verificar el acceso, lo que probablemente provocará que se muestren mensajes de permiso denegado en el cliente. Una vez transcurrido el periodo de TTL, las entradas caducan para que no se queden obsoletas. Las solicitudes de búsqueda que no se encuentran se conservan durante un TTL de un minuto para evitar problemas de rendimiento.
| Caché | Tiempo de espera predeterminado |
|---|---|
| Lista de miembros del grupo | TTL de 24 horas |
| Grupos de Unix (GID) | TTL de 24 horas y TTL negativo de 1 minuto |
| Usuarios de Unix (UID) | TTL de 24 horas y TTL negativo de 1 minuto |
Topologías de controladores de dominio de Active Directory
Una vez que te hayas conectado correctamente a los controladores de dominio de Active Directory, podrás usar los siguientes protocolos para compartir archivos:
- Pymes
- NFSv3 con grupos ampliados
- NFSv4
En las siguientes secciones se ilustran varias topologías posibles. Los diagramas solo muestran el controlador de dominio que usan los volúmenes de NetApp. Los demás controladores de dominio del mismo dominio solo se muestran cuando es necesario.
Microsoft recomienda implementar al menos dos controladores de dominio para garantizar 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 sencillo, 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 mediante 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. Aunque el servicio intenta elegir automáticamente el mejor centro de datos, se recomienda gestionar la selección de centros de datos mediante 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 una VPN, pero puede afectar negativamente al rendimiento de la autenticación de los usuarios finales y al acceso a los archivos. Asegúrate de no añadir saltos de emparejamiento de VPC adicionales en la ruta de tu red.
Consideraciones sobre los DCs locales
Las conexiones a los DCs on-premise usan TCP e IP. Estas conexiones suelen fallar debido a las siguientes limitaciones:
Emparejamiento de VPC: los volúmenes de NetApp solo pueden acceder a los centros de datos que se encuentren en la VPC del pool de almacenamiento o que estén conectados a ella mediante una VPN. Los volúmenes de NetApp no pueden acceder a los controladores de dominio de ninguna otra VPC, incluidas las que están emparejadas con la VPC que se conecta al grupo de almacenamiento.
Cortafuegos: debes permitir que NetApp Volumes se ponga en contacto con tus controladores de dominio. Consulta las reglas de cortafuegos 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 emparejamiento de VPC de Google Cloud no permite el enrutamiento transitivo. También puedes asociar volúmenes de NetApp a una red de VPC compartida que aloje los controladores de dominio de Active Directory. Si asocias volúmenes de NetApp a una red de VPC compartida, este escenario se convierte en uno de los escenarios de las secciones anteriores.
Gestionar las selecciones de DC mediante sitios de AD
Para representar las ubicaciones de los centros de datos, las oficinas y la topología de red reales de la forma más precisa 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 se conecta a tu dominio, el servicio usa la detección basada en DNS para encontrar los controladores de dominio adecuados con los que comunicarse. A partir de los resultados del descubrimiento, el servicio mantiene una lista de DCs válidos a los que conectarse y usa el que tiene la latencia más baja.
Cuando especifica un sitio en la configuración de Active Directory de NetApp Volumes, puede limitar la lista de controladores de dominio a los que se especifican en el sitio de AD.
Si la selección automática de controladores de dominio falla, puede usar los sitios de AD para solucionar el problema:
Implementa al menos un controlador de dominio en la región de volúmenes de NetApp y conéctalo a tu instancia de Active Directory.
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 al configurar las conexiones de Active Directory.
Para verificar manualmente la lista de posibles controladores de dominio 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.