Compreender a opção permitir usuários NFS locais com LDAP Compreender o mapeamento de nomes usando LDAP nos Arquivos NetApp do Azure
Quando um usuário tenta acessar um volume de Arquivos NetApp do Azure via NFS, a solicitação vem em uma ID numérica. Por padrão, o Azure NetApp Files oferece suporte a associações de grupo estendidas para usuários NFS (para ir além do limite padrão de 16 grupos). Como resultado, os arquivos NetApp do Azure tentam pegar essa ID numérica e procurá-la no protocolo LDAP (lightweight directory access protocol) em uma tentativa de resolver as associações de grupo para o usuário em vez de passar as associações de grupo em um pacote RPC. Devido a esse comportamento, se essa ID numérica não puder ser resolvida para um usuário no LDAP, a pesquisa falhará e o acesso será negado. Essa negação ocorre mesmo se o usuário solicitante tiver permissão para acessar o volume ou a estrutura de dados.
A opção Permitir usuários NFS locais com LDAP em conexões do Ative Directory destina-se a desabilitar essas pesquisas LDAP para solicitações NFS desativando a funcionalidade de grupo estendido. Ele não fornece "criação/gerenciamento de usuário local" nos Arquivos NetApp do Azure.
Quando a opção "Permitir usuários NFS locais com LDAP" está habilitada, as IDs numéricas são passadas para os Arquivos NetApp do Azure e nenhuma pesquisa LDAP ocorre. Isso cria um comportamento variável para diferentes cenários, conforme abordado abaixo.
NFSv3 com volumes de estilo de segurança UNIX
Os IDs numéricos não precisam ser traduzidos para nomes de usuário. A opção "Permitir usuários NFS locais com LDAP" não afeta o acesso ao volume. Isso pode afetar como a propriedade do usuário/grupo (conversão de nome) é exibida no cliente NFS. Por exemplo, se um ID numérico de 1001 for user1 no LDAP, mas for user2 no arquivo passwd local do cliente NFS, o cliente exibirá "user2" como o proprietário do arquivo quando o ID numérico for 1001.
NFSv4.1 com volumes de estilo de segurança UNIX
Os IDs numéricos não precisam ser traduzidos para nomes de usuário. Por padrão, o NFSv4.1 usa cadeias de caracteres de nome (user@CONTOSO.COM) para sua autenticação. No entanto, os Arquivos NetApp do Azure dão suporte ao uso de IDs numéricas com NFSV4.1, o que significa que as solicitações NFSv4.1 chegam ao servidor NFS com uma ID numérica. Se não existir nenhuma ID numérica para conversão de nome de usuário em arquivos locais ou serviços de nome, como LDAP, para o volume Arquivos NetApp do Azure, a numérica será apresentada ao cliente. Se uma ID numérica for traduzida para um nome de usuário, a cadeia de caracteres de nome será usada. Se a cadeia de caracteres de nome não corresponder, o cliente esmagará o nome para o usuário anônimo especificado no arquivo idmapd.conf do cliente. Habilitar a opção "Permitir usuários NFS locais com LDAP" não afeta o acesso ao NFSv4.1. O Access retorna ao comportamento NFSv3 padrão, a menos que os Arquivos NetApp do Azure possam resolver uma ID numérica para um nome de usuário em seu banco de dados de usuário NFS local. Os Arquivos NetApp do Azure têm um conjunto de usuários UNIX padrão que pode ser problemático para alguns clientes e esmagar para um usuário "ninguém" se as cadeias de caracteres de ID de domínio não corresponderem.
- Os usuários locais incluem: root (0), pcuser (65534), ninguém (65535).
- Os grupos locais incluem: root (0), daemon (1), pcuser (65534), nobody (65535).
Mais comumente, root pode aparecer incorretamente em montagens de cliente NFSv4.1 quando o ID de domínio NFSv4.1 está configurado incorretamente. Para obter mais informações sobre o domínio de ID NFSv4.1, consulte Configurando o domínio de ID NFSv4.1 para arquivos NetApp do Azure.
As ACLs NFSv4.1 podem ser configuradas usando uma cadeia de caracteres de nome ou uma ID numérica. Se forem utilizados IDs numéricos, não é necessária a tradução de nomes. Se uma cadeia de caracteres de nome for usada, a tradução de nomes será necessária para a resolução adequada da ACL. Ao usar ACLs NFSv4.1, habilitar "Permitir usuários NFS locais com LDAP" pode causar comportamento incorreto da ACL NFSv4.1, dependendo da configuração da ACL.
NFS (NFSv3 e NFSv4.1) com volumes de estilo de segurança NTFS em configurações de protocolo duplo
Os volumes de estilo de segurança UNIX aproveitam as permissões de estilo UNIX (bits de modo e ACLs NFSv4.1). Para esses tipos de volumes, o NFS aproveita apenas a autenticação no estilo UNIX, aproveitando uma ID numérica ou uma cadeia de caracteres de nome, dependendo dos cenários listados acima.
No entanto, os volumes de estilo de segurança NTFS usam permissões de estilo NTFS. Essas permissões são atribuídas usando usuários e grupos do Windows. Quando um usuário NFS tenta acessar um volume com uma permissão de estilo NTFS, um mapeamento de nome UNIX para Windows deve ocorrer para garantir controles de acesso adequados. Nesse cenário, a ID numérica NFS ainda é passada para o volume NFS do Azure NetApp Files, mas há um requisito para que a ID numérica seja convertida para um nome de usuário UNIX para que ele possa ser mapeado para um nome de usuário do Windows para autenticação inicial. Por exemplo, se o ID numérico 1001 tentar acessar uma montagem NFS com permissões de estilo de segurança NTFS que permitam o acesso ao usuário do Windows "user1", então 1001 precisará ser resolvido no LDAP para o nome de usuário "user1" para obter o acesso esperado. Se nenhum usuário com a ID numérica de "1001" existir no LDAP, ou se o LDAP estiver configurado incorretamente, o mapeamento de nomes UNIX para Windows concluirá a tentativa com 1001@contoso.com. Na maioria dos casos, os usuários com esse nome não existem. Como resultado, a autenticação falha e o acesso é negado. Da mesma forma, se a ID numérica 1001 for resolvida para o nome de usuário errado (como user2), a solicitação NFS será mapeada para o usuário incorreto do Windows (neste cenário, user1 tem o acesso concedido a user2).
Ativar "Permitir usuários NFS locais com LDAP" desativa todas as traduções LDAP de IDs numéricos para nomes de usuário. Essa ação efetivamente quebra o acesso a volumes de estilo de segurança NTFS. Como tal, o uso desta opção com volumes de estilo de segurança NTFS é desencorajado.