Partilhar via

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

  • Artigo

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

GID primário

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 Ative 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 Ative 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 Windows:

Screenshot that shows the Windows group member field.

O exemplo a seguir mostra LDAPsearch todos os grupos em que User1 é 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 Chamada de Procedimento Remoto (RPC) no NFS tem uma limitação específica para o número máximo de GIDs auxiliares que podem ser honrados 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 NetApp do Azure, consulte Habilitar a autenticação LDAP dos Serviços de Domínio Ative 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 forma que a manage-gids opção para outros servidores NFS. 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 é eliminado pelo protocolo. Com grupos estendidos nos Arquivos NetApp do Azure, quando uma nova solicitação NFS chega, as informações sobre a associação ao grupo do usuário são solicitadas.

Considerações para GIDs estendidos com LDAP do Ative Directory

Por padrão, nos servidores LDAP do Microsoft Ative Directory, o MaxPageSize atributo é definido como um padrão de 1.000. Essa configuração significa que grupos acima de 1.000 seriam truncados em consultas LDAP. Para habilitar o suporte total 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 How to View and set LDAP Policy in Ative Directory by Using Ntdsutil.exe e o artigo da biblioteca TechNet MaxPageSize Is set Too High.

Próximos passos