Compartilhar via

Entender o uso do LDAP com o Azure NetApp Files

  • Artigo

O protocolo LDAP é um protocolo de acesso ao diretório padrão desenvolvido por um comitê internacional chamado Internet Engineering Task Force (IETF). O LDAP destina-se a fornecer um serviço de diretório baseado em rede de uso geral que você pode usar em plataformas heterogêneas para localizar objetos de rede.

Os modelos LDAP definem como se comunicar com o repositório de diretórios LDAP, como encontrar um objeto no diretório, como descrever os objetos no repositório e a segurança usada para acessar o diretório. O LDAP permite a personalização e a extensão dos objetos descritos no repositório. Portanto, você pode usar um repositório LDAP para armazenar muitos tipos de informações diversas. Muitas das implantações iniciais do LDAP se concentraram no uso do LDAP como um repositório de diretórios para aplicativos como aplicativos Web e email e para armazenar informações de funcionários. Muitas empresas estão substituindo ou substituíram o Serviço de Informações de Rede (NIS) pelo LDAP como um repositório de diretórios de rede.

Um servidor LDAP fornece identidades de usuário e grupo UNIX para uso com volumes NAS. No Azure NetApp Files, o Active Directory é o único servidor LDAP com suporte no momento que pode ser usado. Esse suporte inclui o Active Directory Domain Services (AD DS) e o Microsoft Entra Domain Services.

As solicitações LDAP podem ser divididas em duas operações principais.

  • As associações LDAP são logons para o servidor LDAP de um cliente LDAP. A associação é usada para autenticar no servidor LDAP com acesso somente leitura para executar pesquisas LDAP. O Azure NetApp Files atua como um cliente LDAP.
  • As pesquisas LDAP são usadas para consultar o diretório em busca de informações de usuário e grupo, como nomes, IDs numéricas, caminhos de diretório inicial, caminhos de shell de logon, associações de grupo e muito mais.

O LDAP pode armazenar as seguintes informações usadas no acesso NAS de protocolo duplo:

  • Nomes de usuário
  • Nomes de grupo
  • IDs de usuário numéricas (IUDs) e IDs de grupo (GIDs)
  • Diretórios base
  • Shell de logon
  • Netgroups, nomes DNS e endereços IP
  • Associação de grupo

Atualmente, o Azure NetApp Files usa apenas o LDAP para informações de usuário e grupo – sem informações de netgroup ou host.

O LDAP oferece vários benefícios para seus usuários e grupos UNIX como uma fonte de identidade.

  • O LDAP é à prova de futuro.
    À medida que mais clientes NFS adicionam suporte para NFSv4.x, domínios de ID NFSv4.x que contêm uma lista atualizada de usuários e grupos acessíveis de clientes e armazenamento são necessários para garantir a segurança ideal e o acesso quando o acesso é definido. Ter um servidor de gerenciamento de identidade que fornece mapeamentos de nome um para um para usuários SMB e NFS simplifica muito a vida útil dos administradores de armazenamento, não apenas no presente, mas nos anos seguintes.
  • O LDAP é escalonável.
    Os servidores LDAP oferecem a capacidade de conter milhões de objetos de usuário e grupo e, com o Microsoft Active Directory, vários servidores podem ser usados para replicar em vários sites para escala de desempenho e resiliência.
  • O LDAP é seguro.
    O LDAP oferece segurança na forma de como um sistema de armazenamento pode se conectar ao servidor LDAP para fazer solicitações de informações do usuário. Os servidores LDAP oferecem os seguintes níveis de associação:
    • Anônimo (desabilitado por padrão no Microsoft Active Directory; sem suporte no Azure NetApp Files)
    • Senha simples (senhas de texto sem formatação; sem suporte no Azure NetApp Files)
    • Simple Authentication and Security Layer (SASL) – métodos de associação criptografados, incluindo TLS, SSL, Kerberos e assim por diante. O Azure NetApp Files dá suporte a LDAP por TLS, assinatura LDAP (usando Kerberos), LDAP por SSL.
  • O LDAP é robusto.
    Arquivos NIS, arquivos NIS+ e arquivos locais oferecem informações básicas, como UID, GID, senha, diretórios domésticos e assim por diante. No entanto, o LDAP oferece esses atributos e muitos mais. Os atributos adicionais usados pelo LDAP tornam o gerenciamento de protocolo duplo muito mais integrado ao LDAP em comparação ao NIS. Somente o LDAP tem suporte como um serviço de nome externo para gerenciamento de identidade com o Azure NetApp Files.
  • O Microsoft Active Directory é baseado em LDAP.
    Por padrão, o Microsoft Active Directory usa um back-end LDAP para suas entradas de usuário e grupo. No entanto, esse banco de dados LDAP não contém atributos de estilo UNIX. Esses atributos são adicionados quando o esquema LDAP é estendido por meio do Gerenciamento de Identidade para UNIX (Windows 2003R2 e posterior), Serviço para UNIX (Windows 2003 e anterior) ou ferramentas LDAP de terceiros, como o Centrify. Como a Microsoft usa o LDAP como um back-end, ele torna o LDAP a solução perfeita para ambientes que optam por aproveitar volumes de protocolo duplo no Azure NetApp Files.

    Observação

    Atualmente, o Azure NetApp Files dá suporte apenas ao Microsoft Active Directory nativo para serviços LDAP.

Noções básicas do LDAP no Azure NetApp Files

A seção a seguir discute os conceitos básicos do LDAP, pois ele pertence ao Azure NetApp Files.

  • As informações do LDAP são armazenadas em arquivos simples em um servidor LDAP e são organizadas por meio de um esquema LDAP. Você deve configurar clientes LDAP de uma maneira que coordene as solicitações e pesquisas deles com o esquema no servidor LDAP.

  • Os clientes LDAP iniciam consultas por meio de uma associação LDAP, que é essencialmente um logon para o servidor LDAP usando uma conta que tem acesso de leitura ao esquema LDAP. A configuração de associação LDAP nos clientes é configurada para usar o mecanismo de segurança definido pelo servidor LDAP. Às vezes, trata-se de trocas de nome de usuário e senha em texto sem formatação (simples). Em outros casos, as associações são protegidas por meio de métodos Simple Authentication and Security Layer (sasl) como Kerberos ou LDAP por TLS. O Azure NetApp Files usa a conta do computador SMB para associar usando a autenticação SASL para obter a melhor segurança possível.

  • As informações de usuário e grupo armazenadas no LDAP são consultadas por clientes usando solicitações de pesquisa LDAP padrão, conforme definido no RFC 2307. Além disso, mecanismos mais recentes, como RFC 2307bis, permitem pesquisas de usuários e grupos mais simplificadas. O Azure NetApp Files usa uma forma de RFC 2307bis para suas pesquisas de esquema no Windows Active Directory.

  • Os servidores LDAP podem armazenar informações de usuário e grupo e netgroup. No entanto, atualmente, o Azure NetApp Files não pode usar a funcionalidade de netgroup no LDAP no Windows Active Directory.

  • O LDAP no Azure NetApp Files opera na porta 389. Atualmente, esta porta não pode ser modificada para usar uma porta personalizada, como a porta 636 (LDAP via SSL) ou a porta 3268 (pesquisas do Catálogo Global do Active Directory).

  • Comunicações LDAP criptografadas podem ser obtidas usando LDAP via TLS (que opera pela porta 389) ou assinatura LDAP, e ambos podem ser configurados na conexão do Active Directory.

  • O Azure NetApp Files dá suporte a consultas LDAP que não levam mais de 3 segundos para serem concluídas. Se o servidor LDAP tiver muitos objetos, esse tempo limite poderá ser excedido e as solicitações de autenticação poderão falhar. Nesses casos, considere especificar um escopo de pesquisa LDAP para filtrar consultas para melhor desempenho.

  • O Azure NetApp Files também dá suporte à especificação de servidores LDAP preferenciais para ajudar a acelerar as solicitações. Use esta configuração se quiser garantir que o servidor LDAP mais próximo da região do Azure NetApp Files esteja sendo usado.

  • Se nenhum servidor LDAP preferencial estiver definido, o nome de domínio do Active Directory será consultado no DNS para registros de serviço LDAP para preencher a lista de servidores LDAP disponíveis para sua região localizada dentro desse registro SRV. Você pode consultar manualmente registros de serviço LDAP no DNS de um cliente usando os comandos nslookup ou dig.

    Por exemplo:

    C:\>nslookup
Default Server:  localhost
Address:  ::1

> set type=SRV
> _ldap._tcp.contoso.com.

Server:  localhost
Address:  ::1

_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 0
          port           = 389
          svr hostname   = oneway.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = ONEWAY.Contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = oneway.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = parisi-2019dc.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = contoso.com
oneway.contoso.com       internet address = x.x.x.x
ONEWAY.Contoso.com       internet address = x.x.x.x
oneway.contoso.com       internet address = x.x.x.x
parisi-2019dc.contoso.com        internet address = y.y.y.y
contoso.com      internet address = x.x.x.x
contoso.com      internet address = y.y.y.y

  • Os servidores LDAP também podem ser usados para executar o mapeamento de nomes personalizado para os usuários. Para obter mais informações, confira Mapeamento de nome personalizado usando LDAP.

  • Tempos limite de consulta LDAP

    Por padrão, as consultas LDAP passam do tempo limite se não puderem ser concluídas em tempo hábil. Se uma consulta LDAP falhar devido a um tempo limite, a pesquisa de usuário e/ou grupo falhará e o acesso ao volume do Azure NetApp Files poderá ser negado, dependendo das configurações de permissão do volume. Confira Criar e gerenciar conexões do Active Directory para entender as configurações de tempo limite de consulta LDAP do Azure NetApp Files.

Tipos de mapeamento de nomes

As regras de mapeamento de nomes podem ser divididas em dois tipos principais: simétrico e assimétrico.

  • O mapeamento de nome simétrico é um mapeamento de nome implícito entre usuários do UNIX e do Windows que usam o mesmo nome de usuário. Por exemplo, o usuário CONTOSO\user1 do Windows mapeia para o usuário user1 do UNIX.
  • O mapeamento de nomes assimétricos é o mapeamento de nomes entre usuários UNIX e Windows que usam nomes de usuário diferentes. Por exemplo, o usuário CONTOSO\user1 do Windows mapeia para o usuário user2 do UNIX.

Por padrão, o Azure NetApp Files usa regras de mapeamento de nomes simétricas. Se forem necessárias regras de mapeamento de nome assimétricas, considere configurar os objetos de usuário LDAP para usá-las.

Mapeamento de nome personalizado usando LDAP

O LDAP poderá ser um recurso de mapeamento de nomes, se os atributos de esquema LDAP no servidor LDAP tiverem sido preenchidos. Por exemplo, para mapear usuários do UNIX para nomes de usuário correspondentes do Windows que não correspondem de um para um (ou seja, são assimétricos), você pode especificar um valor diferente para uid no objeto de usuário em relação ao que está configurado para o nome de usuário do Windows.

No exemplo a seguir, um usuário tem um nome asymmetric do Windows e precisa ser mapeado para uma identidade UNIXuser do UNIX. Para conseguir isso no Azure NetApp Files, abra uma instância do MMC de Usuários e Computadores do Active Directory. Em seguida, localize o usuário desejado e abra a caixa de propriedades. (Fazer isso requer habilitar o Editor de Atributos). Navegue até a guia Editor de Atributos e localize o campo UID e, em seguida, preencha o campo UID com o nome de usuário UNIX desejado UNIXuser e clique em Adicionar e OK para confirmar.

Captura de tela que mostra a janela Propriedades Assimétricas e a janela Editor de Cadeia de Caracteres com vários valores.

Depois que esta ação for concluída, os arquivos gravados dos compartilhamentos SMB do Windows pelo usuário asymmetric do Windows serão de propriedade de UNIXuser do lado do NFS.

O exemplo a seguir mostra o proprietário asymmetric do SMB do Windows:

Captura de tela que mostra o proprietário do SMB do Windows chamado Assimétrico.

O exemplo a seguir mostra o proprietário UNIXuser do NFS (mapeado do usuário do Windows asymmetric usando LDAP):

root@ubuntu:~# su UNIXuser
UNIXuser@ubuntu:/root$ cd /mnt
UNIXuser@ubuntu:/mnt$ ls -la
total 8
drwxrwxrwx  2 root     root   4096 Jul  3 20:09 .
drwxr-xr-x 21 root     root   4096 Jul  3 20:12 ..
-rwxrwxrwx  1 UNIXuser group1   19 Jul  3 20:10 asymmetric-user-file.txt

Permitir usuários NFS locais com LDAP

Quando um usuário tenta acessar um volume do Azure NetApp Files via NFS, a solicitação vem em uma ID numérica. Por padrão, o Azure NetApp Files dá suporte a associações de grupo estendidas para usuários NFS (para ir além do limite padrão de grupo de 16). Como resultado, os arquivos do Azure NetApp tentarão usar essa ID numérica e pesquisá-la no LDAP na 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 este 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, mesmo que o usuário solicitante tenha permissão para acessar a estrutura de volume ou dados. A opção Permitir usuários NFS locais com LDAP em conexões do Active Directory destina-se a desabilitar essas pesquisas LDAP para solicitações NFS desabilitando a funcionalidade de grupo estendido. Ela não fornece "criação/gerenciamento de usuário local" no Azure NetApp Files.

Quando a opção "Permitir usuários locais do NFS com LDAP" está habilitada, as IDs numéricas são passadas para o Azure NetApp Files e nenhuma pesquisa LDAP é executada. Isso cria um comportamento variável em diferentes cenários, conforme abordado abaixo.

NFSv3 com volumes de estilo de segurança UNIX

IDs numéricas não precisam ser traduzidas para nomes de usuário. A opção "Permitir usuários locais do NFS com LDAP" não afetará o acesso ao volume, mas poderá afetar a forma como a propriedade do usuário/grupo (conversão de nomes) é exibida no cliente NFS. Por exemplo, se uma ID numérica de 1001 for user1 em LDAP, mas for user2 no arquivo de passagem local do cliente NFS, o cliente exibirá "user2" como o proprietário do arquivo quando a ID numérica for 1001.

NFSv4.1 com volumes de estilo de segurança UNIX

IDs numéricas não precisam ser traduzidas para nomes de usuário. Por padrão, o NFSv4.1 usa cadeias de caracteres de nome (user@CONTOSO.COM) para autenticação. No entanto, o Azure NetApp Files dá suporte ao uso de IDs numéricas com NFSV4.1, o que significa que as solicitações NFSv4.1 chegarão ao servidor NFS com uma ID numérica. Se nenhuma tradução de ID numérica para nome de usuário existir nos arquivos locais ou serviços de nome como LDAP para o volume do Azure NetApp Files, a ID numérica será apresentada ao cliente. Se uma ID numérica tiver tradução 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 executará squash do nome para o usuário anônimo especificado no arquivo idmapd.conf do cliente. Habilitar a opção "Permitir usuários locais do NFS com LDAP" não afetará o acesso NFSv4.1, pois ele retornará ao comportamento NFSv3 padrão, a menos que o Azure NetApp Files possa resolver uma ID numérica para um nome de usuário em seu banco de dados de usuário NFS local. O Azure NetApp Files tem um conjunto de usuários UNIX padrão que podem ser problemáticos para alguns clientes e executar squash para um usuário "nobody" se as cadeias de caracteres de ID de domínio não corresponderem.

  • Os usuários locais incluem: root (0), pcuser (65534), nobody (65535).
  • Os grupos locais incluem: root (0), daemon (1), pcuser (65534), nobody (65535).

Mais comumente, a raiz pode ser mostrada incorretamente em montagens de cliente NFSv4.1 quando a ID de domínio NFSv4.1 está configurada incorretamente. Para obter mais informações sobre o domínio de ID NFSv4.1, confira Configuração do domínio de ID NFSv4.1 para o Azure NetApp Files.

As ACLs NFSv4.1 podem ser configuradas usando uma cadeia de caracteres de nome ou uma ID numérica. Se as IDs numéricas forem usadas, nenhuma tradução de nome será necessária. Se uma cadeia de caracteres de nome for usada, a conversão de nomes será necessária para a resolução de ACL adequada. Ao usar ACLs NFSv4.1, habilitar "Permitir usuários locais do NFS com LDAP" pode causar um comportamento de ACL NFSv4.1 incorreto, dependendo da configuração da ACL.

NFS (v3 e v4.1) com volumes de estilo de segurança NTFS em configurações de protocolo duplo

Os volumes de estilo de segurança UNIX aproveitam 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 do 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 do 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. Neste cenário, a ID numérica do NFS ainda é passada para o volume NFS do Azure NetApp Files, mas há um requisito para que a ID numérica seja traduzida para um nome de usuário UNIX para que possa ser mapeada para um nome de usuário do Windows para autenticação inicial. Por exemplo, se a ID numérica 1001 tentar acessar uma montagem NFS com permissões de estilo de segurança NTFS que permitem o acesso ao usuário do Windows "user1", o 1001 precisará ser resolvido em 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 nome do UNIX para o Windows da tentativa será 1001@contoso.com. Na maioria dos casos, os usuários com esse nome não existem; portanto, 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 um usuário inesperado do Windows e as permissões para o usuário usarão os controles de acesso "user2".

Habilitar "Permitir usuários locais do NFS com LDAP" desabilitará todas as traduções LDAP de IDs numéricas para nomes de usuário, o que efetivamente interromperá o acesso a volumes de estilo de segurança do NTFS. Dessa forma, o uso dessa opção com volumes de estilo de segurança NTFS é altamente desencorajado.

Esquemas LDAP

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

Quando o Azure NetApp Files consulta o LDAP, os esquemas são usados para ajudar a acelerar pesquisas de nomes porque permitem o uso de atributos específicos para encontrar informações sobre um usuário, como a UID. Os atributos de esquema devem existir no servidor LDAP para que o Azure NetApp Files possa 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) precisar ser consultado pelo Azure NetApp Files, o atributo de esquema RFC 2307 uidNumber Attribute será usado. Se nenhum número UID 0 existir no LDAP no campo uidNumber, a solicitação de pesquisa falhará.

O tipo de esquema atualmente usado pelo Azure NetApp Files é uma forma de esquema com base no RFC 2307bis e não pode ser modificado.

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

Esta extensão RFC se encaixa perfeitamente em como o Microsoft Active Directory gerencia usuários e grupos por meio 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 de grupo suplementar necessárias do atributo habitual do Windows e encontrarão os GIDs numéricos automaticamente.

Próximas etapas