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
.
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:
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.
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.
Registrar o recurso
Register-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain
Verifique o status do registro do recurso:
Observação
O RegistrationState pode ficar no estado
Registering
por até 60 minutos antes de mudar paraRegistered
. Aguarde até que o status sejaRegistered
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
Na assinatura do Azure NetApp Files, selecione Domínio de ID NFSv4.1.
Selecione Configurar.
Para usar o domínio padrão, marque a caixa ao lado de Usar domínio
defaultv4iddomain.com
de 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.Selecione Salvar.
Configurar o domínio de ID do NFSv4.1 em clientes NFS
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 valorlocaldomain
, conforme a seguir:- Se o volume não estiver habilitado para LDAP, use o domínio padrão especificando
Domain = defaultv4iddomain.com
ou especifique o domíniodefaultv4iddomain.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, secontoso.com
for o domínio configurado na conta do NetApp, definaDomain = 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.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
- Se o volume não estiver habilitado para LDAP, use o domínio padrão especificando
Desmonte todos os volumes NFS montados no momento.
Atualize o arquivo
/etc/idmapd.conf
.Limpe o conjunto de chaves do NFS
idmapper
(nfsidmap -c
).Monte os volumes de NFS conforme necessário.
O seguinte exemplo mostra a 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 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
, Host1
testuser02
, testuser03
):
No Host2
, não existem contas de usuário correspondentes, mas o mesmo volume é montado em ambos os hosts:
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.