Compartilhar via

Configurar o domínio de ID do NFSv4.1 para o Azure NetApp Files

  • Artigo

O NFSv4 apresenta o conceito de domínio de autenticação de ID. O Azure NetApp Files usa o valor de entrada defaultv4iddomain.com como o domínio de autenticação e os clientes NFS usam sua própria configuração para autenticar usuários que queiram acessar arquivos nesses volumes. Por padrão, os clientes NFS usarão o nome de domínio DNS como o domínio de ID do NFSv4. Você pode substituir essa configuração usando o arquivo de configuração NFSv4 chamado idmapd.conf.

Se as configurações de domínio de autenticação no cliente NFS e no Azure NetApp Files não corresponderem, o acesso ao arquivo poderá ser negado, pois o mapeamento de usuário e grupo do NFSv4 poderá falhar. Quando isso acontecer, os usuários e grupos que não corresponderem corretamente esmagarão o usuário e o grupo configurados no arquivo idmapd.conf (geralmente, nobody:99) e um evento será registrado no cliente.

Este artigo explica o comportamento padrão do mapeamento de usuário/grupo e como configurar os clientes NFS corretos para autenticar corretamente e permitir o acesso. 

Comportamento padrão do mapeamento de usuário/grupo

O mapeamento de usuário raiz pode ilustrar o que acontece se houver uma incompatibilidade entre os clientes do Azure NetApp Files e do NFS. O processo de instalação de um aplicativo geralmente requer o uso do usuário raiz. O Azure NetApp Files pode ser configurado para permitir o acesso a root.

No exemplo de listagem de diretório a seguir, o usuário root monta um volume em um cliente Linux que usa sua configuração localdomain padrão para o domínio de autenticação de ID, que é diferente da configuração padrão de defaultv4iddomain.com do Azure NetApp Files.

Captura de tela da saída do diretório de arquivos.

Na listagem dos arquivos no diretório, file1 mostra como sendo mapeado para nobody, quando deveria ser propriedade do usuário raiz.

Há duas maneiras de ajustar o domínio de autenticação em ambos os lados: Azure NetApp Files como servidor NFS e Linux como clientes NFS:

  1. Gerenciamento de usuário central: se você já estiver usando um gerenciamento de usuário central, como o Active Directory Domain Services (AD DS), poderá configurar seus clientes Linux para usar o LDAP e definir o domínio configurado no AD DS como domínio de autenticação. No lado do servidor, você deve habilitar o serviço de domínio do AD para o Azure NetApp Files e criar volumes habilitados para LDAP. Os volumes habilitados para LDAP usam automaticamente o domínio configurado no AD DS como seu domínio de autenticação.

    Para obter mais informações sobre esse processo, confira Habilitar a autenticação LDAP do Active Directory Domain Services (AD DS) para volumes NFS.

  2. Configurar manualmente o cliente Linux: se você não estiver usando um gerenciamento de usuário central para seus clientes Linux, poderá configurar manualmente os clientes Linux para corresponder ao domínio de autenticação padrão do Azure NetApp Files para volumes não habilitados para LDAP.

Nesta seção, nos concentraremos em como configurar o cliente Linux e como alterar o domínio de autenticação do Azure NetApp Files para todos os volumes não habilitados para LDAP.

Configurar o domínio de ID do NFSv4.1 no Azure NetApp Files

Você pode especificar um domínio de ID do NFSv4.1 desejado para todos os volumes não LDAP usando o portal do Azure. Essa configuração se aplica a todos os volumes não LDAP em todas as contas do NetApp na mesma assinatura e região. Ele não afeta volumes habilitados para LDAP na mesma assinatura e região do NetApp.

Registrar o recurso

O Azure NetApp Files dá suporte à capacidade de definir o domínio de ID do NFSv4.1 para todos os volumes não LDAP em uma assinatura usando o portal do Azure. Esse recurso está atualmente na visualização. Você precisa registrar o recurso para usá-lo pela primeira vez. Após o registro, o recurso é habilitado e funciona em segundo plano.

  1. Registrar o recurso

    Register-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain

  2. Verifique o status do registro do recurso:

    Observação

    O RegistrationState pode ficar no estado Registering por até 60 minutos antes de mudar para Registered. Aguarde até que o status seja Registered antes de continuar.

    Get-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain

Você também pode usar os comandos da CLI do Azure az feature register e az feature show para registrar o recurso e exibir o status do registro.

Etapas

  1. Na assinatura do Azure NetApp Files, selecione Domínio de ID do NFSv4.1.

  2. Selecione Configurar.

  3. Para usar o domínio defaultv4iddomain.com padrão, selecione a caixa ao lado de Usar o Domínio de ID do NFSv4 padrão. Para usar outro domínio, desmarque a caixa de texto e forneça o nome do domínio de ID do NFSv4.1.

    Captura de tela com o campo para definir o domínio do NFSv4.

  4. Selecione Salvar.

Configurar o domínio de ID do NFSv4.1 em clientes NFS

  1. Edite o arquivo /etc/idmapd.conf no cliente NFS.
    Remova a marca de comentário da linha #Domain (ou seja, remova a # da linha) e altere o valor localdomain, conforme a seguir:

    • Se o volume não estiver habilitado para LDAP, use o domínio defaultv4iddomain.com padrão especificando Domain = defaultv4iddomain.com ou especifique o domínio de ID do NFSv4.1 conforme configurado no Azure NetApp Files.
    • Se o volume estiver habilitado para LDAP, definir Domain para o domínio que é configurado na Conexão do Active Directory em sua conta do NetApp. Por exemplo, se contoso.com for o domínio configurado na conta do NetApp, defina Domain = contoso.com.

    Os exemplos a seguir mostram a configuração inicial de /etc/idmapd.conf antes das alterações:

    [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

    O exemplo a seguir mostra a configuração atualizada de volumes do NFSv4.1 não LDAP para o domínio defaultv4iddomain.com padrão:

    [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

    O exemplo a seguir mostra a configuração atualizada de volumes do NFSv4.1 habilitado para LDAP: Neste exemplo, contoso.com é o domínio configurado na conta do 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 todos os volumes NFS montados no momento.

  3. Atualize o arquivo /etc/idmapd.conf.

  4. Desmarque o keyring do NFS idmapper (nfsidmap -c).

  5. Monte os volumes de NFS conforme necessário.

    Confira Montar um volume para VMs do Windows ou Linux.

O seguinte exemplo mostra a alteração de usuário/grupo resultante:

Captura de tela que mostra um exemplo da alteração de usuário/grupo resultante.

Como mostra o exemplo, o usuário/grupo agora mudou de nobody para root.

Comportamento de outros usuários e grupos (não raiz)

O Azure NetApp Files dá suporte a usuários e grupos locais (criados localmente no cliente NFS e representados por IDs de usuário e grupo) e à propriedade e permissões correspondentes associadas a arquivos ou pastas em volumes NFSv4.1. No entanto, o serviço não resolve automaticamente para mapear usuários e grupos locais entre clientes NFS. Usuários e grupos criados em um host podem ou não existir em outro cliente NFS (ou existem com diferentes IDs de usuário e grupo) e, portanto, não serão mapeados corretamente conforme descrito no exemplo abaixo.

No exemplo a seguir, Host1 tem três contas de usuário (testuser01, testuser02, testuser03):

Captura de tela que mostra que o Host1 tem três contas de usuário de teste.

Em Host2, não existem contas de usuário correspondentes, mas o mesmo volume está montado em ambos os hosts:

Configuração resultante para NFSv4.1

Para resolver esse problema, crie as contas ausentes no cliente NFS ou configure seus clientes NFS para usar o servidor LDAP que o Azure NetApp Files está usando para identidades UNIX gerenciadas centralmente.

Próximas etapas