Compartir a través de

Comprender Kerberos en Azure NetApp Files

  • Artículo

Kerberos es un protocolo de autenticación que utiliza una clave secreta para validar la identidad de los mandantes. Las claves secretas se generan tomando la contraseña de una entidad de seguridad y convirtiéndola en un formato de clave criptográfica hash utilizando un método de cifrado acordado por el cliente y el servidor (como AES). Consulte la sección de terminología de Kerberos para conocer los términos utilizados en este documento.

Los centros de distribución de claves (KDC), como Windows Active Directory, mantienen una base de datos de entidades de seguridad Kerberos y sus contraseñas cifradas. En Kerberos, la clave secreta es la prueba de una identidad única. Por lo tanto, se puede confiar en el KDC para autenticar cualquier entidad de seguridad a cualquier otra entidad de seguridad, como autenticar un Nombre de entidad de seguridad de servicio (SPN) de cliente NFS a un SPN de servidor NFS en el montaje. También se puede confiar en él para autenticar una entidad de seguridad de usuario en un SPN de servidor NFS para el acceso de usuario a un punto de montaje NAS. Como medida de seguridad adicional, Kerberos no envía contraseñas en texto claro para la autenticación a través de la red.

Azure NetApp Files admite el uso de Kerberos para proporcionar seguridad en vuelo para los protocolos SMB y NFS.

Tipos de cifrado admitidos

Azure NetApp Files admite NFS Kerberos con tipos de cifrado específicos, en función del modo operativo y la versión que utilice.

Para asegurarse de que un cliente utiliza el tipo de cifrado adecuado, puede limitar los tipos de cifrado válidos en el objeto principal ubicado en el KDC (por ejemplo, la cuenta de la máquina) o en el archivo keytab creado manualmente por el cliente en lugar de globalmente en el archivo /etc/krb5.conf, si es posible, ya que la administración de numerosos archivos krb5.conf de cliente puede ser un dolor de cabeza para la administración. Administrar Kerberos de forma centralizada desde el KDC es más escalable en entornos de grandes empresas, es más fácil de automatizar y obliga al cliente a utilizar tipos de cifrado más potentes cuando son compatibles.

Nota:

Se recomienda establecer la opción allow_weak_crypto en falso en el archivo krb5.conf de los clientes. Esta configuración evita las comunicaciones menos seguras enctypes para Kerberos (como DES o 3DES).

La siguiente tabla muestra los tipos de cifrado admitidos para Kerberos (tanto SMB como NFS) para Azure NetApp Files.

Protocolo Tipos de cifrado admitidos
SMB
  • RC4-HMAC
  • AES-128
  • AES-256
NFS AES-256

Modos de seguridad NFS Kerberos compatibles

Además del concepto de tipos de cifrado, también existen niveles de seguridad y comprobación de integridad en Kerberos. Dependiendo del modo de seguridad que se utilice, estos modos de seguridad ayudan a evitar los ataques de intermediario ofreciendo cifrado de extremo a extremo para el tráfico NFS.

En Azure NetApp Files, estos modos de seguridad se especifican en las reglas de la directiva de exportación establecidas para el volumen para NFS y se definen durante el montaje NFS inicial mediante la segunda opción de montaje.

Por ejemplo: # mount -o sec=krb5p

Nota:

En el caso de SMB Kerberos, los modos de seguridad para Kerberos se controlan mediante la configuración de cifrado SMB en el recurso compartido, el refuerzo de UNC y las directivas de firma o sellado SMB en los controladores de dominio.

Azure NetApp Files admite los siguientes modos de seguridad para su uso con NFS Kerberos:

Modo de seguridad Descripción
krb5 Solo cifrado de autenticación.

Utiliza cadenas de nombres Kerberos V5 y nombres de usuario principal en lugar de identificadores de usuario (UID) e identificadores de grupo (GID) UNIX locales para autenticar a los usuarios.
krb5i Cifrado de autenticación y comprobación de integridad cifrada.

Utiliza Kerberos V5 para la autenticación de usuarios y también realiza comprobaciones de integridad de las operaciones NFS mediante sumas de comprobación seguras para evitar la manipulación de datos y los ataques de intermediario.
krb5p Toda la conversación NFS encriptada.

Utiliza Kerberos V5 para la autenticación de usuarios y la comprobación de la integridad, y también cifra todo el tráfico NFS para evitar el rastreo de paquetes. Esta configuración es la más segura, pero también la que genera más sobrecarga de rendimiento.

Terminología de Kerberos

Esta sección define la terminología clave que se utiliza al describir los procesos de Kerberos. Esta sección pretende ayudar a aclarar términos que pueden resultar desconocidos para los administradores de almacenamiento.

Término Definición
Centro de distribución de claves (KDC) El KDC es el servidor de autenticación que incluye el servicio de concesión de vales (TGS) y el servicio de autenticación (AS). Los términos KDC, AS y TGS se utilizan indistintamente. En entornos Microsoft, un controlador de dominio Active Directory es un KDC.
Dominio (o dominio Kerberos) Un dominio (o dominio Kerberos) puede utilizar cualquier cadena ASCII. La norma es utilizar el nombre de dominio en mayúsculas; por ejemplo, contoso.com se convierte en el dominio CONTOSO.COM. Los dominios Kerberos suelen configurarse en archivos krb5.conf en clientes y servidores.

Administrativamente, cada principal@REALM debe ser único. Para evitar un único punto de fallo, cada dominio puede tener varios KDC que compartan la misma base de datos (principales y sus contraseñas) y tengan las mismas claves maestras de KDC. Microsoft Windows Active Directory lo hace de forma nativa mediante la replicación de Active Directory, que tiene lugar cada 15 minutos por defecto.
Principal El término entidad de seguridad se refiere a cada entidad dentro de una base de datos Kerberos. A los usuarios, ordenadores y servicios se les asignan entidades de seguridad para la autenticación Kerberos. Cada entidad de seguridad debe ser única dentro de la base de datos Kerberos y se define por su nombre distinguido. Una entidad de seguridad puede ser un nombre de entidad de seguridad de usuario (UPN) o un nombre de entidad de seguridad de servicio (SPN).

Un nombre principal tiene tres partes:
  • Principal: La parte principal puede ser un usuario o un servicio como el servicio NFS. También puede ser el servicio especial "host", que significa que este servicio principal está configurado para proporcionar varios servicios de red diferentes.
  • Instancia: Esta parte es opcional en el caso de un usuario. Un usuario puede tener más de una entidad de seguridad, pero cada entidad de seguridad debe ser única en el KDC. Por ejemplo, Fred puede tener una entidad de seguridad de uso diario (fred@contoso.com) y otra que permita un uso privilegiado, como una cuenta de administrador del sistema (admin-fred@contoso.com). La instancia es necesaria para los principales de servicio y designa el nombre de dominio completo (FQDN) del host que proporciona el servicio.
  • Dominio: Un dominio Kerberos es el conjunto de entidades de seguridad Kerberos registradas en un servidor Kerberos. Por convención, el nombre del dominio suele ser el mismo que el nombre DNS, pero se convierte a mayúsculas. Las mayúsculas no son obligatorias, pero la convención permite distinguir fácilmente entre el nombre DNS y el nombre del dominio.
Entradas Un vale es un conjunto temporal de credenciales que verifica la identidad de una entidad de seguridad para un servicio y contiene la clave de sesión. Un vale puede ser un servicio, un vale de aplicación o un vale de concesión de vale (TGT). Los vales se intercambian entre el cliente, el servidor y el KDC para la autenticación Kerberos.
Clave secreta Kerberos utiliza un sistema de clave simétrica en el que la clave secreta se utiliza tanto para cifrar como para descifrar. La clave secreta se genera a partir de la contraseña Kerberos de la entidad de seguridad con una función hash unidireccional. El KDC almacena la contraseña de cada entidad de seguridad y puede así generar la clave secreta de la entidad de seguridad. Para los usuarios que solicitan un servicio Kerberos, la clave secreta suele derivarse de una contraseña presentada al programa kinit. Las entidades de seguridad de servicios y demonios no suelen utilizar contraseña, sino que el resultado de la función hash unidireccional se almacena en un keytab.
Keytab Un keytab contiene una lista de principales y sus claves secretas. Las claves secretas de un keytab suelen crearse utilizando una contraseña aleatoria y se utilizan sobre todo para los principales de servicio o demonio.

Información del puerto de red

En la siguiente tabla se indican los puertos de red que se utilizan para las comunicaciones Kerberos. Si existe un firewall de red, estos puertos deben abrirse para permitir el correcto funcionamiento de Kerberos. Puede encontrar más información sobre estos puertos en el Registro IANA de nombres de servicio y números de puerto de protocolo de transporte.

Servicio Port
Kerberos 88 (TCP/UDP)
kpasswd 464 (TCP/UDP)
Protocolo ligero de acceso a directorios (LDAP) (para la asignación de nombres) 389 (TCP/UDP)
Admin server 749 (TCP/UDP)
Catálogo global (búsquedas de usuarios de Windows) 3268 (TCP/UDP)

Valores de antigüedad de caché en Azure NetApp Files

La siguiente tabla muestra el tiempo de vida de una entrada de caché en un volumen Azure NetApp Files.

Cache Antigüedad de la memoria caché
Conexiones de servidor de nombres inactivas 60 segundos
Tiempo de espera de la consulta LDAP 10 segundos
Entrada de host DNS local para KDC TTL 24 horas
Antigüedad del vale Kerberos Especificado por el KDC* y/o el cliente

* De forma predeterminada, 10 horas para los KDC de Active Directory de Windows
Credenciales de usuario 24 horas
Distorsión temporal de Kerberos 5 minutos

Requisitos para el correcto funcionamiento de entornos Kerberos en Azure NetApp Files

La autenticación Kerberos depende en gran medida de servicios externos para funcionar correctamente. En Microsoft Active Directory, la mayoría de estos servicios se combinan en un único servidor en muchos casos. Por ejemplo, un controlador de dominio de Active Directory puede dar servicio a las siguientes dependencias de Kerberos:

  • Servicios de sincronización horaria
  • DNS
  • Distribución de claves Kerberos
  • Servicios de contraseña/inicio de sesión único
  • Servicios de identidad (como LDAP)

Cuando se utiliza Microsoft Active Directory nativo (el único tipo de KDC que Azure NetApp Files admite actualmente), la mayoría de las dependencias externas de Kerberos en Azure NetApp Files están cubiertas, como DNS, KDC y servicios de contraseñas. En algunos casos, los servicios necesarios pueden estar alojados fuera del dominio de Active Directory (como DNS). En esos casos, es importante asegurarse de que los servicios necesarios están configurados correctamente.

Azure NetApp Files tiene dependencias específicas para el correcto funcionamiento de NFS Kerberos. Siga leyendo para obtener más información.

Servicios de sincronización horaria

Los servicios de sincronización horaria son obligatorios cuando se utiliza Kerberos para la autenticación, ya que los mecanismos de tickets de Kerberos dependen de que las desviaciones horarias entre el cliente y el servidor estén dentro de un intervalo predeterminado de 5 minutos. Si la configuración horaria del cliente o del servidor supera ese intervalo de cinco minutos, la autenticación Kerberos falla con un error de desviación horaria (KRB_AP_ERR_SKEW) y se deniega el acceso al recurso compartido del NAS. Este tiempo de espera es una característica de seguridad que ayuda a prevenir los "ataques de repetición", en los que un atacante puede interceptar mensajes entre el KDC y el cliente y luego reproducir esos mensajes en un momento posterior para hacerse pasar por un usuario autenticado. Los límites de desviación temporal ayudan a minimizar el riesgo de ese tipo de ataques.

Consideraciones clave para los problemas de sincronización horaria:

Para obtener más información, consulte Tolerancia máxima para la sincronización del reloj del ordenador

Sistemas de nombres de dominio (DNS)

Los sistemas de nombres de dominio (DNS) son obligatorios para Kerberos como característica de seguridad. La resolución de nombres de host se utiliza para formular los principales de servicio Kerberos utilizados para la autenticación. En este proceso, las búsquedas de nombres de host (registros A/AAAA) se utilizan para conectarse a recursos compartidos que aprovechan la autenticación Kerberos. Esta búsqueda se utiliza para formular el nombre principal de servicio (SPN) utilizado en la solicitud de autenticación Kerberos. Si no se puede encontrar un SPN existente en el KDC, falla la autenticación Kerberos.

En entornos Windows SMB, se puede probar un método de autenticación de respaldo (como NTLM). Sin embargo, en muchos casos, NTLM está deshabilitado por razones de seguridad, lo que provocaría un error de acceso al recurso compartido cuando falla la autenticación Kerberos. El visor de eventos de Windows a menudo registra la causa raíz de los errores (como SPN duplicados/faltantes, errores de búsqueda DNS, errores NTLM, etc.).

Además de la resolución de SPN, el DNS se utiliza en gran medida para resolver nombres de host y direcciones IP para servicios de dominio, como LDAP, KDC Kerberos, etc. a través de registros SRV. Para obtener información más detallada sobre DNS en Azure NetApp Files (incluidos los registros SRV necesarios), consulte Acerca de DNS en Azure NetApp Files.

Nota:

Si se utiliza una dirección IP para el acceso Kerberos, el comportamiento depende del protocolo NAS (NFS o SMB) en uso. Para más información, consulte Direcciones IP para el acceso con Kerberos.

LDAP

El Protocolo ligero de acceso a directorios (LDAP) aprovecha las bases de datos de identidad para proporcionar una fuente unificada de servicios de nombres para clientes y servidores NAS, de modo que todos los dispositivos participantes coincidan en la autenticidad de los usuarios, la pertenencia a grupos y los identificadores numéricos, que luego se utilizan para los permisos de archivos.

Para Kerberos, los usuarios y servicios principales se almacenan con las entradas en las bases de datos LDAP como atributos en las cuentas principales. Windows Active Directory lo admite por defecto. En algunos casos (como cuando se crean alias o entidades de seguridad de servicio), los usuarios y los ordenadores requieren que se agreguen o modifiquen los nombres de las entidades de seguridad de servicio. Puede cumplir este requisito mediante los Usuarios y equipos de Active Directory y Microsoft Management Console (MMC) o con PowerShell. Para obtener más información sobre cómo administrar nombres de entidades de seguridad, consulte Administración de nombres de entidades de seguridad.

Además de los nombres de entidad de seguridad de servicio y los id. numéricos para la autenticación Kerberos, LDAP también se puede utilizar para identidades de usuario y grupo UNIX, que se utilizan para la asignación de nombres de identidades en Azure NetApp Files, así como para la autenticación inicial para montajes NFS Kerberos a través de una asignación SPN:> nombre de usuario UNIX. Para obtener más información, consulte Funcionamiento de NFS Kerberos en Azure NetApp Files y Función de LDAP con Kerberos en Azure NetApp Files.

Funcionamiento de SMB Kerberos en Azure NetApp Files

SMB Kerberos funciona de forma separada de los servicios NFS Kerberos, ya que las cuentas de máquina creadas para cada protocolo no pueden compartir keytabs debido a la posibilidad de que los cambios en el número de versión de clave (kvno) de un keytab afecten al otro servicio. Como resultado de esto, así como de las diferencias naturales en los protocolos NAS, los flujos de trabajo de los servicios SMB para Kerberos y NFS para Kerberos difieren en funcionalidad en algunas áreas.

Configuración inicial de los servicios SMB

Los servicios SMB en Azure NetApp Files se configuran inicialmente mediante la creación de una conexión de Active Directory, que define varias piezas críticas para la interacción con los servicios de dominio, incluyendo:

  • Servidor DNS principal (obligatorio)
  • DNS secundario
  • Nombre DNS de Active Directory*
  • Nombre del sitio de Active Directory (para la detección de DC) (obligatorio)
  • Nombre del prefijo del servidor SMB
  • Unidad organizativa (donde deben almacenarse las cuentas de máquina en el dominio Azure AD)
  • Habilitar o deshabilitar el cifrado AES
  • Habilitar o deshabilitar la firma LDAP
  • Configuración de LDAP
  • Cifrado SMB a DC
  • Usuarios con privilegios
  • Nombre de usuario y contraseña del usuario con permisos OU

Nota:

Solo se permite una conexión Azure Active Directory (AD) por cuenta. Una vez creada la conexión Azure AD, cualquier nuevo volumen SMB de Azure NetApp Files utiliza la configuración de la conexión Azure AD.

Cuenta de máquina SMB Kerberos

Una cuenta de máquina en Active Directory contiene información relevante para su uso en solicitudes de autenticación, incluido el nombre principal de servicio (SPN). Cuando se crea un volumen SMB en Azure NetApp Files, se utiliza la configuración de conexiones de Active Directory para interactuar en la creación de una cuenta de máquina que proporcione acceso seguro a un recurso compartido SMB mediante autenticación Kerberos (o NTLM, si está habilitada).

Las nuevas cuentas de máquina se crean cuando se aprovisiona un volumen SMB de Azure NetApp Files en un recurso backend específico del servicio. A continuación se muestran diferentes escenarios en los que se puede crear o reutilizar una cuenta de máquina SMB en configuraciones de volumen de Azure NetApp Files.

Escenario Resultado
Primer volumen SMB nuevo Nueva cuenta de máquina SMB/Nombre DNS
Volúmenes SMB posteriores creados en breve sucesión a partir del primer volumen SMB Reutilización de la cuenta de máquina SMB/nombre DNS (en la mayoría de los casos).
Volúmenes SMB posteriores creados mucho más tarde que el primer volumen SMB El servicio determina si se necesita una nueva cuenta de máquina. Es posible que se creen múltiples cuentas de máquina, lo que crea múltiples puntos de conexión de direcciones IP.
Primer volumen de doble protocolo Nueva cuenta de máquina SMB/Nombre DNS
Volúmenes de doble protocolo posteriores creados en breve sucesión a partir del primer volumen de doble protocolo Reutilización de la cuenta de máquina SMB/nombre DNS (en la mayoría de los casos)
Los volúmenes posteriores de doble protocolo se crearon mucho después que el primer volumen de doble protocolo El servicio determina si se necesita una nueva cuenta de máquina. Es posible que se creen varias cuentas de máquina, lo que crea varios puntos de conexión de direcciones IP
Primer volumen SMB creado tras un volumen de doble protocolo Nueva cuenta de máquina SMB/Nombre DNS
Primer volumen de protocolo dual creado después del volumen SMB Nueva cuenta de máquina SMB/Nombre DNS

La cuenta de equipo SMB creada para el volumen SMB (o protocolo dual) de Azure NetApp Files utiliza una convención de nomenclatura que respeta el máximo de 15 caracteres impuesto por Active Directory. El nombre utiliza la estructura de [prefijo del servidor SMB especificado en la configuración de la conexión a Azure AD]-[identificador numérico único].

Por ejemplo, si ha configurado sus conexiones Azure AD para utilizar el prefijo de servidor SMB "AZURE", la cuenta de máquina SMB que crea Azure NetApp Files se parece a "AZURE-7806". Ese mismo nombre se utiliza en la ruta UNC para el recurso compartido SMB (por ejemplo, \AZURE-7806) y es el nombre que utilizan los servicios DNS dinámicos para crear el registro A/AAAA.

Nota:

Dado que un nombre como "AZURE-7806" puede ser difícil de recordar, resulta beneficioso crear un registro CNAME como alias DNS para los volúmenes Azure NetApp Files. Para obtener más información, consulte Creación de alias de servidor SMB.

Diagrama de varias cuentas de máquina y entradas DNS en Azure NetApp Files.

En algunos casos, al crear múltiples volúmenes SMB y/o de protocolo dual, la configuración puede acabar con múltiples cuentas de máquina SMB y nombres DNS dispares.

Si se desea un único espacio de nombres para el acceso del usuario a través de los volúmenes, esto puede presentar un desafío en la configuración, ya que un único alias CNAME solo puede apuntar a un único registro de host A/AAAA, mientras que el uso de múltiples alias de registro A/AAAA idénticos puede resultar en la imprevisibilidad del acceso a los datos en el acceso a los volúmenes a través de diferentes cuentas de máquinas SMB, ya que no hay garantía de que el punto de conexión que el cliente selecciona en la búsqueda de DNS contenga el volumen esperado debido a la naturaleza round-robin de la selección de registros DNS en esas configuraciones.

Para solucionar esta limitación, los volúmenes Azure NetApp Files pueden participar como destinos en una configuración Sistema de archivos distribuido de Microsoft (DFS), lo que puede proporcionar una forma de asociar varios volúmenes SMB con un único punto de entrada de espacio de nombres.

Diagrama de un sistema de archivos distribuido en Azure NetApp Files.

Flujo de trabajo de creación de SPN SMB Kerberos

El siguiente diagrama ilustra cómo se crea un SPN Kerberos SMB cuando se crea un volumen SMB o de protocolo dual de Azure NetApp Files. Los SPN SMB están asociados a objetos de cuenta de máquina SMB en el dominio. El SPN puede verse y administrarse a través de las propiedades de la cuenta de máquina utilizando el editor de atributos de la vista Avanzada.

Captura de pantalla de las propiedades de Azure-SMB.

También puede ver y administrar las propiedades con el setspn comando .

Captura de pantalla del comando

Este proceso sigue los mismos pasos que cuando un cliente normal de Windows se une a un dominio (DNS, LDAP, Kerberos, consultas RPC sobre tuberías con nombre).

Diagrama de cuenta de máquina Kerberos.

En la mayoría de los casos, conocer los pasos detallados en profundidad no es necesario para las tareas de administración cotidianas, pero resulta útil para solucionar cualquier error al intentar crear un volumen SMB en Azure NetApp Files.

Pasos detallados

Para obtener información detallada sobre cómo se crea una cuenta de equipo SMB en Azure NetApp Files, amplíe la lista.

  • La búsqueda DNS se realiza utilizando la configuración DNS para el registro SRV de un KDC Kerberos. Azure NetApp Files utiliza los siguientes registros SRV en sus solicitudes.

    • _kerberos._tcp.dc._msdcs.CONTOSO.COM
    • _kerberos._tcp.CONTOSO.COM (si la consulta anterior no da resultados)

  • La búsqueda DNS se realiza utilizando los nombres de host que se devuelven en la consulta SRV para los registros A/AAAA de los KDC.

    • Se realiza un ping LDAP (LDAP enlace y consulta RootDSE) para buscar servidores NetLogon heredados disponibles utilizando la consulta (&(DnsDomain=CONTOSO.COM)(NtVer=0x00000016)) con un filtro de atributo para NetLogon. Las versiones más recientes del controlador de dominio de Windows (superiores a 2008) no tienen el NtVervalor presente.

  • Azure NetApp Files realiza una consulta de DNS para encontrar los servidores LDAP en el dominio mediante los siguientes registros SRV:

    • _ldap._tcp.CONTOSO.COM
    • _kerberos._tcp.CONTOSO.COM

    Nota:

    Estas consultas se producen varias veces en la misma llamada en diferentes partes del proceso. Los problemas de DNS pueden provocar lentitud en estas llamadas o, con tiempos de espera, fallos completos. - Si las consultas no encuentran ninguna entrada o si no se puede contactar con las entradas encontradas, la creación del volumen SMB falla. - Si las consultas de DNS tienen éxito, se procesan los siguientes pasos.

  • Se envía ICMP (ping) para comprobar que las direcciones IP devueltas por DNS son accesibles.

  • Si el ping está bloqueado en la red por directivas de firewall, la petición ICMP falla. En su lugar, se utilizan pings LDAP.

  • Se realiza otro ping LDAP para buscar servidores NetLogon heredados disponibles utilizando la consulta (&(&(DnsDomain=CONTOSO.COM)(Host=KDChostname.contoso.com))(NtVer=0x00000006)) con el filtro de atributo NetLogon. Las versiones más recientes del controlador de dominio de Windows (superiores a 2008) no tienen el valor NtVer presente.

  • Se envía una autenticación AS-REQ desde el servicio Azure NetApp Files utilizando el nombre de usuario configurado con la conexión de Active Directory.

  • El DC responde con KRB5KDC_ERR_PREAUTH_REQUIRED, que está pidiendo al servicio que envíe la contraseña para el usuario de forma segura.

  • Se envía una segunda AS-REQ con los datos de pre autenticación necesarios para autenticarse con el KDC de acceso para proceder a la creación de la cuenta de máquina. Si tiene éxito, se envía un vale de concesión de vales (TGT) al servicio.

  • Si tiene éxito, el servicio envía un TGS-REQ para solicitar el vale de servicio CIFS (cifs/kdc.contoso.com) al KDC utilizando el TGT recibido en el AS-REP.

  • Se realiza un nuevo enlace LDAP utilizando el ticket de servicio CIFS. Las consultas se envían desde Azure NetApp Files:

    • Base de búsqueda RootDSE del DN ConfigurationNamingContext del dominio
    • Búsqueda OneLevel de CN=partitions en el DN recuperado para el ConfigurationNamingContext utilizando el filtro (&(&(objectClass=crossRef)(nETBIOSName=*))(dnsRoot=CONTOSO.COM)) para el atributo NETBIOSname.
    • Se realiza una búsqueda base utilizando el filtro (|(objectClass=organizationalUnit)(objectClass=container)) en la OU especificada en la configuración de conexiones de Active Directory. Si no se especifica, se utiliza el valor por defecto OU=Computers. Esto verifica que el contenedor existe.
    • Se realiza una búsqueda de subárbol en el DN base del dominio utilizando el filtro (sAMAccountName=ANF-XXXX$) para comprobar si la cuenta ya existe.
      • Si la cuenta existe, se vuelve a utilizar.
    • Si la cuenta no existe, se crea, siempre que el usuario tenga permisos para crear y modificar objetos en el contenedor mediante un comando LDAP addRequest. Se establecen los siguientes atributos LDAP en la cuenta:
    Attribute Valor
    CN ANF-XXXX
    sAMAccountName ANF-XXXX$
    objectClass
    • Superior
    • Person
    • OrganizationalPerson
    • Usuario
    • Computer
    servicePrincipalName
    • HOST/ANF-XXXX
    • HOST/anf-xxxx.contoso.com
    • CIFS/anf-xxxx.contoso.com
    userAccountControl 4096
    operatingSystem Versión de NetApp
    dnsHostName ANF-XXXX.CONTOSO.COM
    • Si hay un error en el addRequest, ocurrirá un error en la creación del volumen. Un addRequest puede fallar debido a permisos incorrectos en el objeto contenedor.
    • Si addRequest se realiza con éxito, se realiza una búsqueda LDAP utilizando el filtro (sAMAccountName=ANF-XXXX$) para recuperar el atributo objectSid.
    • Se realiza una conversación SMB2 "Negociar protocolo" para recuperar el Kerberos mechTypes admitido del KDC.
    • Se realiza una "Configuración de sesión" SMB2 utilizando el SPN CIFS y el más alto admitido mechType y una "Conexión de árbol" a IPC$.
    • Se crea un archivo lsarpc SMB2 en el recurso compartido IPC$.
    • Se realiza un enlace a DCERPC. El archivo lsarpc se escribe para luego ser leído.
    • A continuación, se realizan las siguientes solicitudes de LSA:

  • Se realiza una TGS-REQ utilizando el TGT para recuperar el vale del kadmin/changepw SPN asociado a la cuenta krbtgt.

  • Se realiza una solicitud KPASSWD desde el servicio al KDC para cambiar la contraseña de la cuenta del equipo.

  • Se realiza una consulta LDAP con el filtro (sAMAccountName=ANF-XXXX) para los atributos distinguishedName y isCriticalSystemObject.

  • Si el valor isCriticalSystemObject de la cuenta es falso (el valor predeterminado), el DN recuperado se utiliza para formular un modifyRequest al atributo msDs-SupportedEncryptionTypes. Este valor se establece en 30, que equivale a DES_CBC_MD5 (2) + RC4 (4) + AES 128 (8) + AES 256 (16).

  • Se realiza una segunda ""Negociar protocolo"/Intercambio de vales Kerberos/"Configuración de sesión"/"Conexión de árbol" a IPC$. La cuenta de máquina del servidor SMB (ANF-XXXX$) sirve como entidad de seguridad Kerberos.

  • Se han completado las comunicaciones NetLogon, NetrServer ReqChallenge/Authenticate2.

  • Se realiza un tercer "Negociar protocolo"/Intercambio de vales Kerberos/"Configuración de sesión"/"Conexión de árbol" a IPC$; la cuenta de máquina del servidor SMB (ANF-XXXX$) se utiliza como entidad de seguridad Kerberos.

  • Las conexiones lsarpc y NetLogon se realizan como comprobación final de la cuenta.

Flujo de trabajo de conexión a recursos compartidos SMB (Kerberos)

Cuando un volumen de Azure NetApp Files se monta mediante Kerberos, se utiliza un intercambio de tickets Kerberos durante las solicitudes de configuración de varias sesiones para proporcionar un acceso seguro al recurso compartido. En la mayoría de los casos, conocer en profundidad los pasos detallados no es necesario para las tareas cotidianas de administración. Este conocimiento es útil para solucionar errores al intentar acceder a un volumen SMB en Azure NetApp Files.

Diagrama del flujo de trabajo de conexión de recursos compartidos SMB.

Para ver los pasos que detallan cómo se accede al recurso compartido SMB en Azure NetApp Files, amplíe la lista.
  • El cliente intenta acceder a un recurso compartido SMB utilizando la ruta UNC mostrada en Azure NetApp Files. Por defecto, la ruta UNC incluiría el nombre del servidor SMB (como ANF-XXXX)
  • Se consulta el DNS para asignar el nombre de host a una dirección IP
  • Se produce una conversación inicial SMB2 "Negociar protocolo"
    • Se envía una solicitud desde el cliente para descubrir qué dialectos SMB admite el servidor e incluye lo que admite el cliente solicitante
    • El servidor responde con lo que admite, incluyendo:
      • Modo de seguridad (con o sin firma)
      • Versión de SMB
      • GUID del servidor
      • Funciones compatibles (DFS, arrendamiento, MTU grande, multicanal, controladores persistentes, arrendamiento de directorios, cifrado)
      • Tamaño máximo de la transacción
      • Tamaño máximo de lectura y escritura
      • Blob de seguridad (Kerberos o NTLM)
  • Una segunda conversación SMB2 "Negociar protocolo" tiene lugar como "autorización previa"/login
    • La solicitud del cliente incluye:
      • Hash de autorización previa
      • Modos de seguridad admitidos (con o sin firma)
      • Funciones compatibles (DFS, arrendamiento, MTU grande, multicanal, controladores persistentes, arrendamiento de directorios, cifrado)
      • GUID de cliente
      • Dialectos SMB admitidos
    • Si se acepta el hash de autorización previa, el servidor responde con:
      • Modo de seguridad (con o sin firma)
      • Funciones compatibles (DFS, arrendamiento, MTU grande, multicanal, controladores persistentes, arrendamiento de directorios, cifrado)
      • Tamaño máximo de la transacción
      • Tamaño máximo de lectura y escritura
      • Blob de seguridad (Kerberos o NTLM)
      • Funciones de integridad y cifrado de autorización previa SMB
  • Si la negociación del protocolo tiene éxito, se realiza una solicitud de "Configuración de sesión".
    • La configuración utiliza el hash de autorización previa de la negociación del protocolo.
    • La configuración informa al servidor SMB de lo que admite el cliente solicitante, entre otras cosas:
      • StructureSize
      • Marca de vinculación de sesión
      • Modo de seguridad (firma habilitada y requerida)
      • Funcionalidades
      • Tipos de cifrado Kerberos admitidos
  • Se envía una respuesta "Configuración de sesión".
    • Se conceden créditos SMB.
    • Se establece el id. de sesión.
    • Se establecen las marcas de sesión (invitado, null, cifrar).
    • Se define el tipo de cifrado Kerberos.
  • El cliente envía una solicitud de conexión de árbol para conectarse al recurso compartido SMB.
    • Las marcas y capacidades de compartición se envían desde el servidor, junto con los permisos de compartición.
  • El ioctl comando FSCTL_QUERY_NETWORK_INTERFACE_INFO se envía para obtener la dirección IP del servidor SMB.
  • El servidor SMB de Azure NetApp Files devuelve la información de red, que incluye: * Dirección IP * Capacidad de la interfaz (RSS activado o desactivado) * Recuento de colas RSS * Velocidad del vínculo
  • El cliente envía una solicitud de conexión de árbol para conectarse al recurso compartido administrativo IPC$.
    • El recurso compartido IPC$ es un recurso que comparte las canalizaciones con nombre que son esenciales para la comunicación entre programas. El recurso compartido IPC$ se utiliza durante la administración remota de un ordenador y cuando se visualizan los recursos compartidos de un ordenador. No puede cambiar la configuración del recurso compartido, las propiedades del recurso compartido ni las ACL del recurso compartido IPC$. Tampoco puede cambiar el nombre ni eliminar el recurso compartido IPC$.
  • Se realiza un enlace DCERPC al archivo srvsvc para establecer una conexión segura.
    • Se escribe en el fichero con la información recuperada anteriormente.
  • El cliente Windows emite una Kerberos TGS-REQ al KDC para obtener un vale de servicio (ST) para el servicio SMB.
  • Un NetShareGetInfo comando es ejecutado por el cliente SMB al servidor y envía una respuesta.
  • El vale de servicio SMB se recupera del KDC.
  • Azure NetApp Files intenta asignar el usuario de Windows que solicita acceso al recurso compartido a un usuario UNIX válido.
    • Una solicitud TGS de Kerberos se realiza utilizando las credenciales Kerberos del servidor SMB almacenadas con el keytab del servidor SMB desde la creación inicial del servidor SMB para utilizarlas en un enlace de servidor LDAP.
    • Se busca en LDAP un usuario UNIX que esté asignado al usuario SMB que solicita acceso al recurso compartido. Si no existe ningún usuario UNIX en LDAP, Azure NetApp Files utilizará el usuario UNIX pcuser predeterminado para la asignación de nombres (los archivos/carpetas escritos en volúmenes de protocolo dual utilizan el usuario UNIX asignado como propietario UNIX).
  • Se realiza otra negociación de protocolo/solicitud de sesión/conexión de árbol, esta vez utilizando el SPN Kerberos del servidor SMB al recurso compartido IPC$ del DC de Active Directory.
    • Se establece una canalización con nombre al recurso compartido a través del archivo srvsvc.
    • Se establece una sesión NETLOGON en el recurso compartido y se autentica el usuario de Windows.
  • Si los permisos lo permiten para el usuario, el recurso compartido enumera los archivos y carpetas contenidos en el volumen.

Nota:

Azure NetApp Files agrega entradas a la caché de contexto Kerberos para el cliente. Estas entradas residen en la caché durante la duración del vale Kerberos (establecida por el KDC y controlada por la directiva Kerberos.

Creación de alias de servidor SMB

Cuando Azure NetApp Files crea un servidor SMB utilizando una convención de nomenclatura de [prefijo de servidor SMB especificado en la configuración de conexión de Azure AD]-[identificador numérico único]. (Para obtener más información sobre el identificador numérico único, consulte Cuenta de máquina SMB Kerberos). Este formato significa que los nombres de los servidores SMB no están creados de forma fácil de usar. Por ejemplo, un nombre como "SMB-7806" es más difícil de recordar que algo similar a "AZURE-FILESHARE"

Debido a este comportamiento, es posible que los administradores deseen crear nombres de alias fáciles de usar para los volúmenes de Azure NetApp Files. Para ello es necesario apuntar un nombre canónico DNS (CNAME) al registro DNS A/AAAA existente en el servidor.

Cuando se crea un CNAME y se utiliza en solicitudes de ruta UNC (por ejemplo, \\AZURE-FILESHARE en lugar de \\SMB-7806), DNS redirige la solicitud CNAME (AZURE-FILESHARE.contoso.com) al registro A/AAAA adecuado (SMB-7806.contoso.com), que se utiliza en la recuperación de SPN de Kerberos (cifs/SMB-7806). Esto permite el acceso de Kerberos al recurso compartido SMB mientras se utiliza el nombre con alias.

Si se crea un registro DNS A/AAAA (por ejemplo, AZURE-FILESHARE.contoso.com) y se intenta utilizar como alias, se produce un error en las solicitudes Kerberos. El error se debe a que el SPN construido utilizado para autenticarse en el recurso compartido (cifs/AZURE-FILESHARE) no coincide con el SPN de Kerberos para el servidor SMB (cifs/SMB-7806). El error se puede mitigar si se crea otro SPN y se anexa a la cuenta de la máquina del servidor SMB (como cifs/AZURE-FILESHARE).

Funciones de servidor SMB compatibles en Azure NetApp Files

Cuando se realiza la solicitud de "protocolo de negociación" SMB, se solicita al servidor SMB de Azure NetApp Files que admita funciones específicas. La siguiente tabla muestra las funcionalidades consultadas y la respuesta devuelta desde un volumen SMB de Azure NetApp Files cuando se realiza una conexión de configuración de sesión/árbol.

Funcionalidad SMB ¿Es compatible con Azure NetApp Files?
Objetivo DFS Sí
Arrendamiento Sí
MTU grande Sí
SMB multicanal Sí
Controladores persistentes SMB Sí
Alquiler de directorios No
Cifrado de SMB Sí (si está habilitado)

Funciones y propiedades de recursos compartidos SMB compatibles en Azure NetApp Files

Durante el acceso a recursos compartidos SMB, se realiza una solicitud de "conexión de árbol" y el cliente consulta las funcionalidades y propiedades de los recursos compartidos SMB compatibles al servidor Azure NetApp Files. La siguiente tabla muestra las funcionalidades de recurso compartido consultadas y la respuesta devuelta desde un volumen SMB de Azure NetApp Files, tal y como se ve en una captura de paquetes.

Funcionalidad de uso compartido de SMB ¿Es compatible con Azure NetApp Files?
Continuamente disponible (CA) Sí, para cargas de trabajo específicas* (si está habilitado)
Escalado No
Clúster No
Asimétrica No
Redirigir al propietario No

* Consulte Habilitar la disponibilidad continua en volúmenes SMB existentes para cargas de trabajo compatibles.

La siguiente tabla muestra las propiedades de recurso compartido consultadas y la respuesta devuelta de un volumen SMB de Azure NetApp Files.

Funcionalidad de uso compartido de SMB ¿Es compatible con Azure NetApp Files?
Objetivo DFS Sí
Raíz DFS No
Restringir aperturas exclusivas No
Eliminación compartida forzada No
Permitir el almacenamiento en caché de espacios de nombres No
Enumeración basada en el acceso Sí (si está habilitado)
Bloqueo de fuerza nivel II No
Hash V1 habilitado No
Hash V2 habilitado No
Cifrado necesario Sí (si está habilitado)
Identidad remota No
E/S comprimida No
Transporte aislado No

Funcionamiento de NFS Kerberos en Azure NetApp Files

NFS Kerberos funciona de forma independiente a los servicios SMB, ya que las cuentas de máquina creadas para cada protocolo no pueden compartir keytabs debido a la posibilidad de que los cambios en el número de versión de clave (kvno) de un keytab afecten al otro servicio. Como resultado, los flujos de trabajo de los servicios SMB para Kerberos y NFS para Kerberos difieren en funcionalidad en algunas áreas.

Configuración inicial del dominio Kerberos

El dominio Kerberos de NFS se configura cuando se rellena la información del dominio Kerberos en el Portal Azure NetApp Files, en la página de conexiones de Active Directory.

Captura de pantalla de la configuración del dominio Kerberos.

El nombre del servidor de Azure AD y la IP del KDC se utilizan para conectarse a los servicios del KDC de Azure AD en la creación inicial de la cuenta de equipo. El servicio Azure NetApp Files aprovecha la información de dominio existente para completar el resto de la configuración del dominio. Por ejemplo:

Kerberos Realm: CONTOSO.COM
KDC Vendor: Microsoft
KDC IP Address: x.x.x.x 
KDC Port: 88
Clock Skew: 5
Active Directory Server Name: dc1.contoso.com
Active Directory Server IP Address: x.x.x.x
Comment: -
Admin Server IP Address: x.x.x.x
Admin Server Port: 749
Password Server IP Address: x.x.x.x
Password Server Port: 464
Permitted Encryption Types: aes-256
-    Configured by Azure NetApp Files administrator in the portal
-    Automatically configured by the service using Active Directory connection information/system defaults

Cuando se configura el dominio NFS Kerberos, se agrega una entrada de hosts locales en el servicio con el KDC especificado en la configuración. Cuando se modifica el dominio, también se modifica la entrada de hosts locales en el servicio.

Diagrama de configuración del dominio Kerberos.

Esta entrada de host local actúa como "último recurso" si se produce una interrupción en el KDC especificado en la configuración del dominio y no se puede consultar a los KDC redundantes a través de DNS.

Nota:

Si el centro de distribución de claves (KDC) del dominio de Kerberos debe desconectarse para realizar tareas de mantenimiento (por ejemplo, para actualizar o desmantelar un servidor), se recomienda configurar el dominio para que utilice un KDC que no esté en mantenimiento para evitar interrupciones.

Creación inicial de una cuenta de máquina/SPN

Cuando Kerberos está habilitado en un volumen de Azure NetApp Files, se crea una cuenta/principal de máquina denominada NFS-{SMB-server-name} en el dominio en la OU especificada en las conexiones de Active Directory (unidad organizativa). Los nombres de cuenta de las máquinas se truncan después de 15 caracteres.

Nota:

Al agregar clientes Linux con nombres de host de más de 15 caracteres a un dominio de Active Directory, sus SPN de cuenta de máquina Kerberos se truncan. Por ejemplo, un cliente Linux con un nombre de MORE-THAN-FIFTEEN tiene un nombre de cuenta de máquina de MORE-THAN-FIFT$, que se convierte en un SPN de MORE-THAN-FIFT$@CONTOSO.COM. Cuando DNS busca el nombre de host de un cliente, encuentra el nombre más largo e intenta utilizar ese nombre en una solicitud de SPN (MORE-THAN-FIFTEEN@CONTOSO.COM). Dado que ese SPN no existe, el cliente intenta utilizar el siguiente SPN del keytab en la solicitud (normalmente host/nombre de host). Solo los SPN de nombre de cuenta de máquina funcionan de forma nativa con Azure NetApp Files NFS Kerberos. En consecuencia, asegúrese de que los nombres de host de cliente Linux utilizados para NFS Kerberos con Azure NetApp Files no superen los 15 caracteres. De forma alternativa, si desea utilizar el SPN host o nombre de host, configure un usuario UNIX en LDAP con el nombre de usuario "host". Esta configuración proporciona un mapeo de nombre krb-unix para el SPN.

En Azure NetApp Files, los bloques de claves Kerberos (o entradas de keytab) se agregan al servicio con el SPN del servicio NFS (nfs/nfs-server-name.contoso.com@CONTOSO.COM). Se crean varias entradas: una para cada tipo de cifrado admitido. En Azure NetApp Files, solo se admite el tipo de cifrado AES-256 para NFS Kerberos.

En la mayoría de los casos, conocer estos pasos en profundidad no será necesario para las tareas de administración diarias, pero son útiles para solucionar cualquier error al intentar crear un volumen NFS Kerberos en Azure NetApp Files.

Flujo de trabajo de creación de NFS Kerberos SPN

El siguiente diagrama muestra cómo se crea un SPN NFS cuando se crea un volumen NFS o de protocolo dual de Azure NetApp Files con Kerberos habilitado. En la mayoría de los casos, conocer los pasos detallados en profundidad no será necesario para las tareas de administración cotidianas, pero son útiles para solucionar cualquier fallo al intentar crear un volumen SMB en Azure NetApp Files.

Diagrama del flujo de trabajo de creación de NFS Kerberos SPN.

Para obtener información detallada sobre cómo se crea un SPN Kerberos NFS con Azure NetApp Files, amplíe la lista.
  • Las credenciales de administrador se pasan al KDC especificado en la configuración del dominio utilizando el nombre de usuario proporcionado para su uso en la conexión de Active Directory, el usuario debe tener permiso para ver/crear objetos en la OU especificada.
  • Azure NetApp Files consulta los servidores DNS especificados en la configuración de conexión de Active Directory de Azure NetApp Files para obtener los registros de servicio Kerberos (SRV) en los siguientes formatos:
    • Consulta URI para _kerberos.CONTOSO.COM
    • Consulta SRV para _kerberos-master._udp. CONTOSO.COM
    • Consulta SRV para _kerberos master._tcp. CONTOSO.COM

Nota:

Estas consultas se producen varias veces en la misma llamada en diferentes partes del proceso. Los problemas de DNS pueden provocar lentitud en estas llamadas o errores completos. Estos registros no parecen existir por defecto en las implementaciones de Active Directory y deben crearse manualmente.

  • Si las consultas no encuentran una entrada o si las entradas encontradas no pueden ser contactadas o utilizadas como el KDC principal, entonces se utiliza como último recurso una consulta de registro A utilizando el nombre de dominio encontrado en la configuración del dominio NFS Kerberos para conectarse al KDC a través del puerto 88.
  • Durante la configuración de NFS Kerberos, se agrega una entrada de host estática para el KDC especificado al archivo de hosts local como copia de seguridad si fallan las búsquedas de DNS.
  • Si existe una entrada DNS en caché para el dominio, se utiliza. Si no existe, se utiliza la entrada del archivo local. Las entradas DNS almacenadas en caché viven mientras el Período de vida (TTL) esté configurado para el registro DNS. La entrada del archivo local está configurada con un TTL de 86 400 segundos (24 horas). La configuración ns-switch para las búsquedas de host en Azure NetApp Files utiliza primero los archivos y después DNS. Cuando se encuentra la entrada local, no se realizan más consultas.
  • La cuenta de máquina SMB creada cuando se crea la conexión de Active Directory se utiliza como credenciales para un enlace LDAP de Active Directory utilizando SASL/GSS sobre el puerto 389 para buscar cualquier entrada existente del SPN o nombre de cuenta de máquina deseado. Si el SPN o el nombre de cuenta de máquina ya existe, se envía un error. Si el SPN no existe en la consulta LDAP, la creación de la cuenta de máquina se realiza en la OU designada con entradas para los siguientes atributos establecidos por Azure NetApp Files:
    • cn (NFS-MACHINE)
    • sAMAccountName (NFS-MACHINE$)
    • objectClass (top, person, organizationalPerson, user, computer)
    • servicePrincipalName (host/NFS-MACHINE, host/NFS-MACHINE.CONTOSO.COM, nfs/NFS-MACHINE, nfs/NFS-MACHINE.CONTOSO.COM)
    • userAccountControl (4096)
    • msDs-SupportedEncryptionTypes (AES-256_CTS_HMAC_SHA1_96)
    • dnsHostName (NFS-MACHINE.CONTOSO.COM)
  • La contraseña de la cuenta de máquina NFS kerberos se establece para la cuenta NFS-MACHINE a través del puerto 464.
  • Los bloques de claves Kerberos (keytabs) para el SPN NFS se guardan en el servicio Azure NetApp Files.
  • Se crea una regla de asignación de nombres estática en el servicio Azure NetApp Files para garantizar que el usuario raíz de cada cliente NFS Kerberos se asigna a raíz cuando se utiliza Kerberos.
  • Se agrega un archivo krb5.conf a los sistemas internos del servicio con la información del dominio NFS.

Montajes NFS Kerberos

Cuando se monta un volumen de Azure NetApp Files utilizando tipos de seguridad Kerberos sobre NFS, se realiza el siguiente flujo de trabajo. Para obtener información más detallada sobre Kerberos, consulte la Sinopsis del Servicio de autenticación de red Kerberos (V5).

Diagrama del flujo de trabajo de montaje NFS Kerberos.

Para obtener información detallada sobre cómo se monta un volumen NFS Kerberos con Azure NetApp Files, amplíe la lista.
  • El cliente intenta un montaje en una ruta de exportación NFS en Azure NetApp Files y especifica el tipo de seguridad -okrb5 (o krb5i o krb5p).
  • DNS se utiliza para formular una solicitud de un principal de servicio NFS a Azure NetApp Files mediante un registro A/AAAA o PTR (en función de cómo se haya emitido el comando de montaje).
  • El cliente recupera un TGT del KDC mediante una llamada AS-REQ utilizando el nombre de la entidad de seguridad CLIENT que se encuentra en el keytab del cliente.
  • Se comprueba que la ruta de exportación existe en el sistema de archivos.
  • La regla de la directiva de exportación se comprueba para garantizar que se permite el acceso de Kerberos a la ruta de exportación.<
  • El cliente solicita el ticket de servicio NFS al KDC mediante una llamada AP-REQ. Azure NetApp Files comprueba el keytab en busca de una entrada válida con un tipo de cifrado válido mediante el TGT del cliente adquirido del KDC.
  • Si el TGT es válido, se emite un vale de servicio.
  • El SPN del cliente (por ejemplo, CLIENT$@CONTOSO.COM) se asigna al usuario raíz mediante la regla de asignación de nombres en Azure NetApp Files.
  • El usuario raíz es consultado en las bases de datos de los servicios de nombres (archivos y LDAP) para conocer su existencia y pertenencia a grupos.
  • Se realiza un enlace LDAP utilizando la cuenta de máquina del servidor SMB para permitir una búsqueda LDAP del usuario raíz.
  • Dado que la raíz siempre existe en Azure NetApp Files, esto no debería causar ningún problema, pero las consultas LDAP para la raíz podrían fallar. Estos errores pueden ser omitidos.
  • El vale de servicio NFS se devuelve al cliente y el montaje se realiza correctamente. El usuario raíz tiene acceso raíz al montaje Kerberos a través de la cuenta principal de la máquina del cliente (visible con el comando klist -e desde el cliente).
  • Azure NetApp Files agrega entradas a la caché de contexto Kerberos para el cliente. Estas entradas residirán en la caché durante el tiempo de vida del vale Kerberos establecido por el KDC y controlado por la directiva Kerberos.
  • NFSv4.1 envía periódicamente (cada 20 segundos) actualizaciones de actualización de vales Kerberos como "keepalives"

Acceso de montaje NFS Kerberos con usuarios principales

Cuando un usuario (que no sea el usuario raíz, que utiliza el SPN de la cuenta del equipo) accede a un montaje NFS Kerberos de Azure NetApp Files, se realiza el siguiente flujo de trabajo.

Diagrama de acceso de montaje NFS Kerberos con usuarios principales.

Para conocer los pasos detallados sobre cómo se accede a un volumen NFS Kerberos con un usuario no raíz con Azure NetApp Files, amplíe la lista.
  • El usuario inicia sesión en el KDC mediante un intercambio de nombre de usuario y contraseña o a través de un archivo keytab para obtener un TGT mediante una llamada AS-REQ que se utilizará para recopilar un vale de servicio del volumen Azure NetApp Files.
  • La regla de la directiva de exportación se comprueba para garantizar que se permite el acceso de Kerberos a la ruta de exportación del equipo cliente
  • Azure NetApp Files busca un vale de servicio NFS en caché. Si no existe ninguno, se solicita el vale de servicio NFS mediante una llamada AP-REQ y el servicio comprueba el keytab en busca de una entrada válida con un tipo de cifrado válido utilizando el TGT del cliente adquirido del KDC
  • Si el TGT es válido, se emite un vale de servicio
  • El nombre de usuario principal (UPN) del usuario se asigna mediante una asignación implícita. Por ejemplo, si el UPN es user1@CONTOSO.COM, el servicio busca un usuario UNIX llamado user1. Dado que ese usuario UNIX no existe en la base de datos de archivos local de Azure NetApp Files, se utiliza LDAP.
  • Se intenta un enlace LDAP utilizando la cuenta de máquina del servidor SMB para permitir una búsqueda LDAP del usuario asignado. Se realiza una consulta DNS SRV para los registros DNS de Kerberos (_kerberos y _kerberos-master). Si no se pueden utilizar registros válidos, la configuración vuelve a la configuración del dominio. Estas consultas KDC DNS SRV no tienen ámbito de sitio.
  • Se consultan los registros SRV de LDAP en busca de servidores LDAP válidos. Estos son de ámbito local.
  • Si el usuario no existe en LDAP o no se puede consultar LDAP (el servidor no funciona, falla la búsqueda DNS, falla el enlace, se agota el tiempo de búsqueda LDAP, el usuario no existe), la asignación falla y se deniega el acceso.
  • Si el usuario existe, se recopilan las pertenencias a grupos.
  • La asignación tiene éxito y se emite un vale de servicio NFS para el cliente (visto en klist -e comandos). El acceso se permite en función de los permisos de archivo de la ruta de exportación.

Función de LDAP con Kerberos en Azure NetApp Files

Azure NetApp Files se basa en LDAP para NFS Kerberos. NFS Kerberos en Azure NetApp Files requiere Kerberos para asignaciones de nombres UNIX para SPN de usuario entrantes. Dado que Azure NetApp Files no admite la creación de usuarios UNIX locales, se necesita LDAP para realizar búsquedas de usuarios UNIX cuando se solicita una asignación de nombres.

  • Cuando se crea una conexión Azure AD, el nombre de dominio de Active Directory se utiliza para especificar el proceso de búsqueda de servidores LDAP.
  • Cuando se necesita un servidor LDAP, _ldap.domain.com se utiliza para la búsqueda SRV de servidores LDAP.
  • Una vez descubierta una lista de servidores, se utiliza el mejor servidor disponible (basado en el tiempo de respuesta del ping) como servidor LDAP para la conexión a través del puerto 389.
  • Se intenta un enlace LDAP utilizando la cuenta de máquina SMB a través de GSS/Kerberos.
  • Si no hay conexión en caché ni credenciales Kerberos, se emite una nueva solicitud de vale Kerberos. Las conexiones almacenadas en caché para servidores de nombres en Azure NetApp Files están activas durante 60 segundos. Si está inactiva durante más de 60 segundos, se borra la caché de conexión.
  • DNS se utiliza para encontrar los KDC de Kerberos adecuados mediante registros SRV.
  • Si no se puede encontrar ningún KDC mediante una consulta de DNS, se utiliza el KDC especificado en el archivo krb5.conf para los servicios SMB.
    • Si el KDC no es accesible o no puede procesar la solicitud Kerberos, se produce un error en el enlace LDAP. También se produce un error en la búsqueda de nombres. Se niega el acceso al montaje ya que no se produjo una autenticación válida.
    • Si la vinculación tiene éxito, se realiza una consulta LDAP para el usuario y sus credenciales. Si el tiempo de búsqueda supera los 10 segundos, la búsqueda falla.
  • Si la búsqueda encuentra al usuario, la asignación se ha realizado con éxito y se concede el acceso a través de Kerberos (siempre que el vale sea válido o no haya caducado).

Direcciones IP para el acceso con Kerberos

Por defecto, la autenticación Kerberos aprovecha la resolución de nombre de host a dirección IP para formular el nombre principal de servicio (SPN) utilizado para recuperar el vale Kerberos. Por ejemplo, cuando se accede a un recurso compartido SMB con una ruta de Convención de nomenclatura universal (UNC) como \SMBVOLUME.CONTOSO.COM, se emite una solicitud DNS para el nombre de dominio completo SMBVOLUME.CONTOSO.COM y se recupera la dirección IP del volumen Azure NetApp Files. Si no existe ninguna entrada DNS (o la entrada actual es diferente de lo que se solicita, por ejemplo, con alias o CNAME), no se puede recuperar un SPN adecuado y se produce un error en la solicitud de Kerberos. Como resultado, se podría denegar el acceso al volumen si el método de autenticación de reserva (como New Technology LAN Manager) está deshabilitado.

Las entradas DNS en Azure NetApp Files se crean automáticamente mediante DNS dinámico y se formulan utilizando el nombre del servidor SMB. Para cualquier variación o alias del nombre definido, debe crearse un registro DNS CNAME manual que apunte a la entrada DNS dinámica. Para obtener más información, consulte Descripción de DNS en Azure NetApp Files.

NFSv4.1 Kerberos funciona de forma similar para la recuperación de SPN, donde las búsquedas DNS son integrales para el proceso de autenticación y también se pueden usar para la detección de dominios de Kerberos.

Si se utiliza una dirección IP (en lugar de un nombre de host) en una solicitud de acceso a un volumen Azure NetApp Files, la solicitud Kerberos funcionará de forma diferente en función del protocolo utilizado.

Comportamiento de SMB Kerberos con direcciones IP y nombres DNS

Cuando se utiliza SMB, una solicitud de una ruta UNC utilizando una dirección IP (por ejemplo, \\x.x.x.x) por defecto intenta utilizar NTLM para la autenticación. En entornos en los que NTLM no está permitido por motivos de seguridad, una solicitud SMB que utilice una dirección IP no podrá utilizar Kerberos o NTLM para la autenticación de forma predeterminada. Como resultado, se deniega el acceso al volumen de Azure NetApp Files. En versiones posteriores de Windows (a partir de Windows 10 versión 1507 y Windows Server 2016), los clientes Kerberos pueden configurarse para admitir nombres de host IPv4 e IPv6 en SPN para la comunicación SMB con el fin de solucionar este problema.

Comportamiento de NFSv4.1 Kerberos con direcciones IP y nombres DNS

Cuando se utiliza NFSv4.1, una solicitud de montaje a una dirección IP utilizando una de las sec=[krb5/krb5i/krb5p] opciones utiliza búsquedas DNS inversas a través de PTR para resolver una dirección IP a un nombre de host. Ese nombre de host se utiliza entonces para formular el SPN para la recuperación de tickets Kerberos. Si usa NFSv4.1 con Kerberos, debe tener un registro D/DDDD y PTR para el volumen de Azure NetApp Files para cubrir el acceso de nombre de host y dirección IP a los montajes. Azure NetApp Files crea un registro DNS A/AAAA dinámico. Si existe una zona DNS inversa para esa subred, también se crea automáticamente un registro PTR. Para desviaciones de las convenciones de nombres de host estándar de Azure NetApp Files, utilice registros CNAME para alias DNS.

Para obtener más información, consulte Comprender DNS en Azure NetApp Files