Compartir vía

Configuración del dominio de id. NFSv4.1, para Azure NetApp Files

  • Artículo

NFSv4 introduce el concepto de dominio de autenticación de id. Azure NetApp Files usa el valor de entrada defaultv4iddomain.com como dominio de autenticación y los clientes NFS usan su propia configuración para autenticar a los usuarios que quieran acceder a los archivos de esos volúmenes. De forma predeterminada, los clientes NFS usarán el nombre de dominio DNS como dominio de id. NFSv4. Puede invalidar esta configuración mediante el archivo de configuración NFSv4 denominado idmapd.conf.

Si las configuraciones del dominio de autenticación en el cliente NFS y Azure NetApp Files no coinciden, es posible que se deniegue el acceso a archivos, ya que se puede producir un error en la asignación de grupos y usuarios NFSv4. Cuando esto sucede, los usuarios y grupos que no coinciden correctamente aplastarán el usuario y el grupo configurados en el archivo idmapd.conf (por lo general, nobody:99) y se registrará un evento en el cliente.

Este artículo explica el comportamiento predeterminado de la asignación de usuarios o grupos y cómo configurar los clientes NFS para autenticarse correctamente y permitir el acceso. 

Comportamiento predeterminado de asignación de usuarios o grupos

La asignación de usuarios raíz puede ilustrar lo que sucede si hay una discrepancia entre Azure NetApp Files y los clientes NFS. El proceso de instalación de una aplicación suele requerir el uso del usuario raíz. Azure NetApp Files se configurarse para permitir el acceso a root.

En el ejemplo de lista de directorios siguiente, el usuario root monta un volumen en un cliente Linux que usa su configuración predeterminada localdomain para el dominio de autenticación de identificador, que es diferente de la configuración predeterminada de Azure NetApp Files de defaultv4iddomain.com.

Recorte de pantalla de la salida del directorio de archivos.

En la lista de los archivos del directorio, file1 se muestra como asignado a nobody, cuando debería ser propiedad del usuario raíz.

Hay dos maneras de ajustar el dominio de autenticación en ambos lados: Azure NetApp Files como servidor NFS y Linux como clientes NFS:

  1. Administración de usuarios central: si ya usa una administración de usuarios central como Active Directory Domain Services (AD DS), puede configurar sus clientes Linux para que usen LDAP y establecer el dominio configurado en AD DS como dominio de autenticación. En el lado del servidor, debe habilitar el servicio de dominio de AD para Azure NetApp Files y crear volúmenes habilitados para LDAP. Los volúmenes habilitados para LDAP usan automáticamente el dominio configurado en AD DS como dominio de autenticación.

    Para saber más sobre este proceso, consulte Habilitación de la autenticación LDAP de Active Directory Domain Services (AD DS) para volúmenes NFS.

  2. Configurar manualmente el cliente Linux: si no usa una administración central de usuarios para los clientes Linux, puede configurar manualmente los clientes de Linux para que coincidan con el dominio de autenticación predeterminado de Azure NetApp Files para volúmenes no habilitados para LDAP.

En esta sección nos centraremos en cómo configurar el cliente Linux y cómo cambiar el dominio de autenticación de Azure NetApp Files para todos los volúmenes no habilitados para LDAP.

Configuración del dominio de id. NFSv4.1 en Azure NetApp Files

Puede especificar un dominio de id. NFSv4.1 deseado para todos los volúmenes que no son LDAP mediante Azure Portal. Esta configuración se aplica a todos los volúmenes que no son LDAP en todas las cuentas de NetApp de la misma suscripción y región. No afecta a los volúmenes habilitados para LDAP en la misma suscripción y región de NetApp.

Registrar la característica

Azure NetApp Files admite la capacidad de establecer el dominio de id. NFSv4.1 para todos los volúmenes que no son LDAP de una suscripción mediante Azure Portal. Esta funcionalidad actualmente está en su versión preliminar. Antes de usar esta característica por primera vez, debe registrarla. Después del registro, la característica está habilitada y funciona en segundo plano.

  1. Registrar la característica

    Register-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain

  2. Compruebe el estado del registro de la característica:

    Nota:

    RegistrationState puede estar en el estado Registering hasta 60 minutos antes de cambiar a Registered. Espere hasta que el estado sea Registered antes de continuar.

    Get-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain

También puede usar los comandos de la CLI de Azure az feature register y az feature show para registrar la característica y mostrar el estado del registro.

Pasos

  1. En la suscripción de Azure NetApp Files, seleccione Dominio de id. NFSv4.1.

  2. Seleccione Configurar.

  3. Para usar el dominio predeterminado defaultv4iddomain.com, seleccione el cuadro situado junto a Usar dominio de id. NFSv4 predeterminado. Para usar otro dominio, desactive el cuadro de texto y proporcione el nombre del dominio de id. NFSv4.1.

    Recorte de pantalla con el campo para establecer el dominio NFSv4.

  4. Seleccione Guardar.

Configuración del dominio de id. NFSv4.1 en clientes NFS

  1. Edite el archivo /etc/idmapd.conf en el cliente NFS.
    Quite la marca de comentario de la línea #Domain (es decir, quite # de la línea) y cambie el valor localdomain tal como se indica a continuación:

    • Si el volumen no está habilitado para LDAP, use el dominio predeterminado defaultv4iddomain.com especificando Domain = defaultv4iddomain.com o especifique el dominio de id. NFSv4.1 como configurado en Azure NetApp Files.
    • Si el volumen está habilitado para LDAP, establezca Domain en el dominio que está configurado en la conexión de Active Directory de la cuenta de NetApp. Por ejemplo, si contoso.com es el dominio configurado en la cuenta de NetApp, establezca Domain = contoso.com.

    Los ejemplos siguientes muestran la configuración inicial de /etc/idmapd.conf antes de los cambios:

    [General]
Verbosity = O 
Pipefs—Directory = /run/rpc_pipefs 
# set your own domain here, if it differs from FQDN minus hostname 
# Domain = localdomain 

[Mapping] 
Nobody-User = nobody 
Nobody-Group = nogroup

    El ejemplo siguiente muestra la configuración actualizada de volúmenes que no son LDAP NFSv4.1 para el dominio predeterminado defaultv4iddomain.com:

    [General]
Verbosity = O 
Pipefs—Directory = /run/rpc_pipefs 
# set your own domain here, if it differs from FQDN minus hostname 
Domain = defaultv4iddomain.com 

[Mapping] 
Nobody-User = nobody 
Nobody-Group = nogroup

    El siguiente ejemplo muestra la configuración actualizada de volúmenes que tienen LDAP habilitado para NFSv4.1. En este ejemplo, contoso.com es el dominio configurado en la cuenta de NetApp:

    [General]
Verbosity = O 
Pipefs—Directory = /run/rpc_pipefs 
# set your own domain here, if it differs from FQDN minus hostname 
Domain = contoso.com

[Mapping] 
Nobody-User = nobody 
Nobody-Group = nogroup

  2. Desmonte los volúmenes NFS montados actualmente.

  3. Actualice el archivo /etc/idmapd.conf.

  4. Borrar el conjunto de claves del NFS idmapper (nfsidmap -c).

  5. Monte los volúmenes NFS según sea necesario.

    Consulte Montaje de un volumen para máquinas virtuales Windows o Linux.

El siguiente ejemplo muestra el cambio de usuario o grupo resultante:

Captura de pantalla que muestra un ejemplo del cambio de usuario o grupo resultante.

Como se muestra en el ejemplo, el usuario o grupo ahora ha cambiado de nobody a root.

Comportamiento de otros usuarios (no raíz) y grupos

Azure NetApp Files admite usuarios y grupos locales (creados localmente en el cliente NFS y representados por identificadores de usuario y grupo) y los permisos y propiedad correspondientes asociados a archivos o carpetas en volúmenes NFSv4.1. Sin embargo, el servicio no resuelve automáticamente la asignación de usuarios y grupos locales entre clientes NFS. Los usuarios y grupos creados en un host pueden existir o no en otro cliente NFS (o existen con identificadores de usuario y grupo diferentes) y, por tanto, no se asignarán correctamente como, puede verse en el ejemplo siguiente.

En el ejemplo siguiente, Host1 tiene tres cuentas de usuario (testuser01, testuser02, testuser03):

Captura de pantalla que muestra que Host1 tiene tres cuentas de usuario de prueba existentes.

En Host2, no existen cuentas de usuario correspondientes, pero el mismo volumen se monta en ambos hosts:

Configuración resultante para NFSv4.1

Para resolver este problema, cree las cuentas que faltan en el cliente NFS o configure los clientes NFS para usar el servidor LDAP que Azure NetApp Files usa para identidades UNIX administradas centralmente.

Pasos siguientes