Partilhar via

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

  • Artigo

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 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 NFSv4 chamado idmapd.conf.

Se as configurações de domínio de autenticação no cliente NFS e nos Arquivos NetApp do Azure não corresponderem, o acesso ao arquivo poderá ser negado, pois o mapeamento de usuário e grupo 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, ninguém:99) e um evento será registrado no cliente.

Este artigo explica o comportamento padrão do mapeamento de usuário/grupo e como configurar clientes NFS corretos para autenticar corretamente e permitir 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 localdomain padrão para o domínio de autenticação de ID, que é diferente da configuração padrão do Arquivo NetApp do defaultv4iddomain.comAzure de .

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 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ário central, como os Serviços de Domínio Ative 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 Ative 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.

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 habilitados para LDAP.

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

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 os volumes habilitados para LDAP na mesma assinatura e região da NetApp.

Registar a funcionalidade

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

  1. Registar a funcionalidade

    Register-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain

  2. Verifique o status do registro do recurso:

    Nota

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

    Get-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain

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

Passos

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

  2. Selecione Configurar.

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

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

  4. Selecione Guardar.

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

  1. Edite o /etc/idmapd.conf arquivo no cliente NFS.
    Descomente a linha #Domain (ou seja, remova a # da linha) e altere o valor localdomain da seguinte maneira:

    • Se o volume não estiver habilitado para LDAP, use o domínio defaultv4iddomain.com padrão especificando Domain = defaultv4iddomain.comou especifique o domínio de ID NFSv4.1 conforme configurado em Arquivos NetApp do Azure.
    • Se o volume estiver habilitado para LDAP, defina Domain como o domínio configurado na Conexão do Ative Directory em sua conta NetApp. Por exemplo, se contoso.com for o domínio configurado na conta 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 NFSv4.1 habilitados para LDAP. Neste exemplo, contoso.com é o domínio configurado na conta 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 atualmente.

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

  4. Limpe o porta-chaves do NFS idmapper (nfsidmap -c).

  5. Monte os volumes NFS conforme necessário.

    Consulte Montar um volume para VMs Windows ou Linux.

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

Captura de ecrã que mostra um exemplo da alteração resultante do utilizador/grupo.

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 em 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, 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 existentes.

No Host2, não existem contas de usuário correspondentes, mas o mesmo volume é 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óximos passos