Compartir a través de

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

  • Artículo

NFSv4 presenta el concepto de un dominio de autenticación de identificador. Azure NetApp Files usa el valor defaultv4iddomain.com de entrada 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 identificador NFSv4. Puede invalidar esta configuración mediante el archivo de configuración NFSv4 denominado idmapd.conf.

Si la configuración 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 idmapd.conf archivo (generalmente, nadie:99) y se registrará un evento en el cliente.

En este artículo se explica el comportamiento predeterminado de la asignación de usuarios o grupos y cómo configurar los clientes NFS correctos 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 los clientes de Azure NetApp Files y NFS. El proceso de instalación de una aplicación suele requerir el uso del usuario raíz. Azure NetApp Files se puede configurar para permitir el acceso a root.

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

Screenshot of file directory output.

En la lista de los archivos del directorio, file1 se muestra como asignado a nobody, cuando debe 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 central de usuarios: si ya usa una administración central de usuarios como Servicios de dominio de Active Directory (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 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 obtener más información sobre este proceso, consulte Habilitación de la autenticación LDAP de Servicios de dominio de Active Directory (AD DS) para volúmenes NFS.

  2. Configurar manualmente el cliente Linux: si no usa una administración de usuarios central 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 identificador NFSv4.1 en Azure NetApp Files

Puede especificar un dominio de identificador 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 identificador 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 esté Registered antes de continuar.

    Get-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain

También puede usar los comandos de la CLI de Azureaz 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 NFSv4.1 ID Domain (Dominio de identificador nfSv4.1).

  2. Seleccione Configurar.

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

    Screenshot with field to set NFSv4 domain.

  4. Seleccione Guardar.

Configuración del dominio de identificador 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 defaultv4iddomain.com predeterminado especificando Domain = defaultv4iddomain.como especificando el dominio de identificador NFSv4.1 tal como está 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.

    En los ejemplos siguientes se muestra la configuración inicial de antes de /etc/idmapd.conf 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

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

    [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. Borre el keyring 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:

Screenshot that shows an example of the resulting user/group change.

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

Comportamiento de otros usuarios y grupos (noroot)

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 se describe en el ejemplo siguiente.

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

Screenshot that shows that Host1 has three existing test user accounts.

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

Resulting configuration for 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