Compreender esquemas LDAP em arquivos NetApp do Azure

Os esquemas LDAP (Lightweight Directory Access Protocol) são como os servidores LDAP organizam e coletam informações. Os esquemas de servidor LDAP geralmente seguem os mesmos padrões, mas diferentes provedores de servidor LDAP podem ter variações sobre como os esquemas são apresentados.

Quando os Arquivos NetApp do Azure consultam LDAP, os esquemas são usados para ajudar a acelerar as pesquisas de nomes, pois permitem o uso de atributos específicos para localizar informações sobre um usuário, como o UID. Os atributos de esquema devem existir no servidor LDAP para que os Arquivos NetApp do Azure possam localizar a entrada. Caso contrário, as consultas LDAP podem não retornar dados e as solicitações de autenticação podem falhar.

Por exemplo, se um número UID (como root=0) deve ser consultado pelos Arquivos NetApp do Azure, o atributo de esquema RFC 2307 uidNumber Attribute é usado. Se não existir nenhum número 0 UID no LDAP no uidNumber campo, a solicitação de pesquisa falhará.

O tipo de esquema usado atualmente pelos Arquivos NetApp do Azure é uma forma de esquema baseada no RFC 2307bis e não pode ser modificado.

RFC 2307bis é uma extensão do RFC 2307 e adiciona suporte para posixGroup, que permite pesquisas dinâmicas para grupos auxiliares usando o uniqueMember atributo em vez de usar o memberUid atributo no esquema LDAP. Em vez de usar apenas o nome do usuário, esse atributo contém o nome distinto completo (DN) de outro objeto no banco de dados LDAP. Portanto, os grupos podem ter outros grupos como membros, o que permite a configuração de grupos dentro de grupos. Suporte para RFC 2307bis também adiciona suporte para a classe groupOfUniqueNamesde objeto .

Esta extensão RFC se encaixa bem em como o Microsoft Ative Directory gerencia usuários e grupos através das ferramentas de gerenciamento usuais. Isso ocorre porque quando você adiciona um usuário do Windows a um grupo (e se esse grupo tiver um GID numérico válido) usando os métodos de gerenciamento padrão do Windows, as pesquisas LDAP extrairão as informações suplementares necessárias do grupo do atributo usual do Windows e localizarão os GIDs numéricos automaticamente.

Quando os volumes de Arquivos NetApp do Azure precisam executar pesquisas LDAP para identidades de usuário NFS, é utilizada uma série de atributos que são definidos por um esquema LDAP baseado no RFC-2307bis. A tabela a seguir mostra os atributos usados pelas pesquisas LDAP, que são os padrões definidos no Microsoft Ative Directory quando os atributos UNIX são usados. Para obter a funcionalidade adequada, verifique se esses atributos estão preenchidos corretamente nas contas de usuário e grupo no LDAP.

* Atributo necessário para a funcionalidade LDAP adequada

** Preenchido no Ative Directory por padrão

Não obrigatório

Compreender a indexação de atributos LDAP

O LDAP do Ative Directory fornece um método de indexação para atributos que ajuda a acelerar as solicitações de pesquisa. Isso é particularmente útil em ambientes de diretório grandes, onde uma pesquisa LDAP pode potencialmente exceder o valor de tempo limite de 10 segundos para pesquisas nos Arquivos NetApp do Azure. Se uma pesquisa exceder seu valor de tempo limite, a pesquisa LDAP falhará e o acesso não funcionará corretamente porque o serviço não poderá verificar a identidade do usuário ou grupo que solicita acesso.

Por padrão, o LDAP do Microsoft Ative Directory indexará os seguintes atributos UNIX usados pelos Arquivos NetApp do Azure para pesquisas LDAP:

• Denominação comum (NC)
• uidNumber
• gidNumber

O atributo uid não é indexado por padrão. Como resultado, as consultas LDAP para o UID levam mais tempo do que as consultas para atributos indexados.

Por exemplo, no teste a seguir de uma consulta em um ambiente do Ative Directory com mais de 20.000 usuários e grupos, uma pesquisa por um usuário com o atributo indexado CN levou aproximadamente 0,015 segundos, enquanto uma pesquisa pelo mesmo usuário com o atributo UID (que não é indexado por padrão) levou cerca de 0,6 segundos — 40 vezes mais lenta.

Em ambientes menores, isso não causa problemas. Mas em ambientes maiores (ou ambientes em que o ambiente do Ative Directory está no local ou tem alta latência de rede), a diferença pode ser drástica o suficiente para causar problemas de acesso para os usuários que acessam os volumes do Azure NetApp Files. Como resultado, é uma prática recomendada configurar o atributo UID no LDAP para ser indexado pelo Ative Directory.

Configurando o atributo UID a ser indexado pelo Ative Directory

Os atributos são indexados através do valor do objeto de atributo, que é configurável através do ADSI Edit no contexto de nomenclatura do esquema. O acesso ao ADSI Edit deve ser abordado com cautela e requer privilégios mínimos de administrador de esquema.

Por padrão, o atributo uid do objeto searchFlags é definido como 0x8 (PRESERVE_ON_DELETE). Essa configuração padrão garante que, mesmo que o objeto no Ative Directory seja excluído, o valor do atributo permaneça armazenado no diretório como um registro histórico do atributo do usuário.

Em comparação, um atributo indexado no Ative Directory para pesquisas LDAP teria o valor de 0x1 (ou alguma combinação incluindo esse valor), como uidNumber:

Por isso, as consultas para uidNumber retornam mais rápido do que as consultas para uid. Para consistência e desempenho, pode ajustar o valor searchFlags de uid para 9 ao adicionar 0x1 ao valor existente de 0x8, que é (INDEX | PRESERVE_ON_DELETE). Essa adição mantém o comportamento padrão ao adicionar indexação de atributos ao diretório.

Com a indexação, as pesquisas por atributos de usuário com uid são tão rápidas quanto as pesquisas por outros atributos indexados.

Próximos passos

• Compreender as noções básicas de LDAP
• Compreender o mapeamento de nomes usando LDAP
• Compreender a permissão para usuários locais de NFS com a opção LDAP