Compartilhar via

Entenda as associações de grupo NFS e grupos suplementares

  • Artigo

Você pode usar o LDAP para controlar a associação ao grupo e retornar grupos suplementares para usuários NFS. Esse comportamento é controlado por meio de atributos de esquema no servidor LDAP.

DTGI primária

Para que os Arquivos NetApp do Azure possam autenticar um usuário corretamente, os usuários LDAP sempre devem ter um GID primário definido. O GID primário do usuário é definido pelo esquema gidNumber no servidor LDAP.

GIDs secundários, suplementares e auxiliares

Grupos secundários, suplementares e auxiliares são grupos dos quais um usuário é membro fora de seu GID primário. Nos Arquivos NetApp do Azure, o LDAP é implementado usando o Microsoft Active Directory e os grupos suplementares são controlados usando a lógica padrão de associação de grupo do Windows.

Quando um usuário é adicionado a um grupo do Windows, o atributo Member de esquema LDAP é preenchido no grupo com o nome distinto (DN) do usuário que é membro desse grupo. Quando a associação de grupo de um usuário é consultada pelos Arquivos NetApp do Azure, uma pesquisa LDAP é feita para o DN do usuário no atributo de Member todos os grupos. Todos os grupos com um UNIX gidNumber e o DN do usuário são retornados na pesquisa e preenchidos como associações de grupo suplementares do usuário.

O exemplo a seguir mostra a saída do Active Directory com o DN de um usuário preenchido Member no campo de um grupo e uma pesquisa LDAP subsequente feita usando ldp.exe.

O exemplo a seguir mostra o campo de membro do grupo do Windows:

Screenshot that shows the Windows group member field.

O exemplo a seguir mostra LDAPsearch todos os grupos em que User1 é um membro:

Screenshot that shows the search of a user named `User1`.

Você também pode consultar associações de grupo para um usuário nos Arquivos NetApp do Azure selecionando o link Lista de ID de Grupo LDAP em Suporte + solução de problemas no menu de volume.

Screenshot that shows the query of group memberships by using the **LDAP Group ID List** link.

Limites de grupo no NFS

A RPC (Chamada de Procedimento Remoto) no NFS tem uma limitação específica para o número máximo de GIDs auxiliares que podem ser atendidos em uma única solicitação NFS. O máximo para é 16, e para AUTH_SYS/AUTH_UNIX AUTH_GSS (Kerberos), é 32. Essa limitação de protocolo afeta todos os servidores NFS - não apenas os Arquivos NetApp do Azure. No entanto, muitos servidores e clientes NFS modernos incluem maneiras de contornar essas limitações.

Para contornar essa limitação de NFS nos Arquivos do Azure NetApp, consulte Habilitar a autenticação LDAP dos Serviços de Domínio Active Directory (AD DS) para volumes NFS.

Como funciona a extensão da limitação de grupo

As opções para estender a limitação de grupo funcionam da mesma maneira que a manage-gids opção para outros servidores NFS funciona. Basicamente, em vez de despejar toda a lista de GIDs auxiliares aos quais um usuário pertence, a opção executa uma pesquisa para o GID no arquivo ou pasta e retorna esse valor.

O exemplo a seguir mostra o pacote RPC com 16 GIDs.

Screenshot that shows RPC packet with 16 GIDs.

Qualquer GID além do limite de 16 é descartado pelo protocolo. Com grupos estendidos nos Arquivos do Azure NetApp, quando uma nova solicitação NFS chega, informações sobre a associação de grupo do usuário são solicitadas.

Considerações sobre GIDs estendidos com LDAP do Active Directory

Por padrão, nos servidores LDAP do Microsoft Active Directory, o MaxPageSize atributo é definido como padrão de 1.000. Essa configuração significa que grupos além de 1.000 seriam truncados em consultas LDAP. Para habilitar o suporte completo com o valor 1.024 para grupos estendidos, o atributo deve ser modificado para refletir o MaxPageSize valor 1.024. Para obter informações sobre como alterar esse valor, consulte o artigo do Microsoft TechNet Como exibir e definir a diretiva LDAP no Active Directory usando Ntdsutil.exe e o artigo da biblioteca do TechNet MaxPageSize is Set Too High.

Próximas etapas