Share via


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

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

Se as configurações de domínio de autenticação no cliente NFS e nos Arquivos do Azure NetApp não corresponderem, o acesso ao arquivo poderá ser negado, pois o mapeamento de usuário e grupo do NFSv4 poderá falhar. Quando isso acontece, os usuários e grupos que não correspondem corretamente esmagarão o usuário e o grupo configurados idmapd.conf no arquivo (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 corretamente 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 Arquivos NetApp do Azure e os clientes NFS. O processo de instalação de um aplicativo geralmente requer o uso do usuário root. Os Arquivos NetApp do Azure podem ser configurados para permitir o acesso ao 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 padrão para o domínio de autenticação de ID, que é diferente da configuração localdomain padrão do Azure NetApp Files do defaultv4iddomain.com.

Screenshot of file directory output.

Na listagem dos arquivos no diretório, mostra como sendo mapeado para nobody, file1 quando ele deve ser de propriedade do usuário root.

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

  1. Gerenciamento central de usuários: se você já estiver usando um gerenciamento de usuários central, como os Serviços de Domínio Active Directory (AD DS), poderá configurar seus clientes Linux para usar 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 Arquivos NetApp do Azure 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, consulte Habilitar a autenticação LDAP dos Serviços de Domínio Active Directory (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 dos Arquivos NetApp do Azure para volumes habilitados para LDAP não.

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 nos Arquivos do Azure NetApp

Você pode especificar um domínio de ID 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 NetApp na mesma assinatura e região. Ele não afeta volumes habilitados para LDAP na mesma assinatura e região da NetApp.

Registrar o recurso

Os Arquivos NetApp do Azure dão 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. No momento, este recurso está em versão prévia. 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 Azureaz 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 NFSv4.1.

  2. Selecione Configurar.

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

    Screenshot with field to set NFSv4 domain.

  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 padrão especificando Domain = defaultv4iddomain.comou especifique o domínio defaultv4iddomain.com de ID NFSv4.1 conforme configurado nos Arquivos NetApp do Azure.
    • 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 antes das /etc/idmapd.conf 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 NFSv4.1 não LDAP para o domínio defaultv4iddomain.compadrã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. Limpe o conjunto de chaves 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:

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

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

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

Os Arquivos NetApp do Azure dão 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 o mapeamento de 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 existir com IDs de usuário e grupo diferentes) e, portanto, não serão mapeados corretamente, conforme descrito no exemplo abaixo.

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

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

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

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