Partilhar via

Compreender o uso do LDAP com os Arquivos NetApp do Azure

  • Artigo

Lightweight directory access protocol (LDAP) é um protocolo padrão de acesso a diretórios que foi 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 armazenamento de diretório LDAP, como encontrar um objeto no diretório, como descrever os objetos no armazenamento e a segurança usada para acessar o diretório. O LDAP permite a personalização e extensão dos objetos descritos na loja. Portanto, você pode usar um armazenamento LDAP para armazenar muitos tipos de informações diversas. Muitas das implantações LDAP iniciais se concentraram no uso do LDAP como um armazenamento de diretório para aplicativos como e-mail e aplicativos da Web e para armazenar informações de funcionários. Muitas empresas estão substituindo ou substituíram o Network Information Service (NIS) pelo LDAP como um armazenamento de diretório de rede.

Um servidor LDAP fornece identidades de usuário e grupo UNIX para uso com volumes NAS. Nos Arquivos NetApp do Azure, o Ative Directory é o único servidor LDAP atualmente suportado que pode ser usado. Este suporte inclui os Serviços de Domínio Ative Directory (AD DS) e os Serviços de Domínio Microsoft Entra.

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

  • As ligações LDAP são logins no servidor LDAP a partir de um cliente LDAP. A associação é usada para autenticar no servidor LDAP com acesso somente leitura para executar pesquisas LDAP. Os Arquivos NetApp do Azure atuam como um cliente LDAP.
  • As pesquisas LDAP são usadas para consultar o diretório em busca de informações de usuários e grupos, como nomes, IDs numéricos, caminhos de diretório base, caminhos de shell de login, associações de grupo e muito mais.

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

  • Nomes de utilizador
  • Nomes de grupos
  • IDs de usuário numéricos (UIDs) e IDs de grupo (GIDs)
  • Diretórios base
  • Shell de login
  • Netgroups, nomes DNS e endereços IP
  • Associação a um grupo

Atualmente, os Arquivos NetApp do Azure usam apenas LDAP para informações de usuário e grupo – sem informações de grupo de rede ou host.

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

  • O LDAP está preparado para o futuro.
    À medida que mais clientes NFS adicionam suporte para NFSv4.x, os domínios de ID NFSv4.x que contêm uma lista atualizada de usuários e grupos acessíveis a partir de clientes e armazenamento são necessários para garantir segurança ideal e acesso garantido quando o acesso é definido. Ter um servidor de gerenciamento de identidades que fornece mapeamentos de nomes um-para-um para usuários SMB e NFS simplifica muito a vida dos administradores de armazenamento, não apenas no presente, mas nos próximos anos.
  • O LDAP é escalável.
    Os servidores LDAP oferecem a capacidade de conter milhões de objetos de usuário e grupo e, com o Microsoft Ative Directory, vários servidores podem ser usados para replicar em vários locais para 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 ligação:
    • Anónimo (desativado por predefinição no Microsoft Ative Directory; não suportado nos Ficheiros NetApp do Azure)
    • Palavra-passe simples (palavras-passe de texto simples; não suportadas nos Ficheiros NetApp do Azure)
    • SASL (Simple Authentication and Security Layer) – Métodos de associação criptografados, incluindo TLS, SSL, Kerberos e assim por diante. Os Arquivos NetApp do Azure dão suporte a LDAP sobre TLS, assinatura LDAP (usando Kerberos), LDAP sobre SSL.
  • O LDAP é robusto.
    NIS, NIS+ e arquivos locais oferecem informações básicas, como UID, GID, senha, diretórios home e assim por diante. No entanto, o LDAP oferece esses atributos e muito mais. Os atributos adicionais que o LDAP usa tornam o gerenciamento de protocolo duplo muito mais integrado com o LDAP versus o NIS. Somente LDAP é suportado como um serviço de nome externo para gerenciamento de identidades com Arquivos NetApp do Azure.
  • O Microsoft Ative Directory baseia-se no LDAP.
    Por padrão, o Microsoft Ative 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 Identity Management for UNIX (Windows 2003R2 e posterior), Service for UNIX (Windows 2003 e anteriores) ou ferramentas LDAP de terceiros, como o Centrify. Como a Microsoft usa LDAP como back-end, ela torna o LDAP a solução perfeita para ambientes que optam por aproveitar volumes de protocolo duplo nos Arquivos NetApp do Azure.

    Nota

    Atualmente, os Arquivos NetApp do Azure só dão suporte ao Microsoft Ative Directory nativo para serviços LDAP.

Noções básicas de LDAP nos Arquivos NetApp do Azure

A seção a seguir discute os conceitos básicos do LDAP no que diz respeito aos Arquivos NetApp do Azure.

  • As informações 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 forma que coordene suas solicitações e pesquisas com o esquema no servidor LDAP.

  • Os clientes LDAP iniciam consultas por meio de uma ligação LDAP, que é essencialmente um login no 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, eles são trocas de nome de usuário e senha em texto simples (simples). Em outros casos, as ligações são protegidas por meio de métodos de Camada de Segurança e Autenticação Simples (sasl), como Kerberos ou LDAP sobre TLS. Os Arquivos NetApp do Azure usam a conta de máquina SMB para vincular usando a autenticação SASL para a melhor segurança possível.

  • As informações de usuários e grupos armazenadas no LDAP são consultadas pelos clientes usando solicitações de pesquisa LDAP padrão, conforme definido na RFC 2307. Além disso, mecanismos mais recentes, como o RFC 2307bis, permitem pesquisas mais simplificadas de usuários e grupos. Os Arquivos NetApp do Azure usam uma forma de RFC 2307bis para suas pesquisas de esquema no Windows Ative Directory.

  • Os servidores LDAP podem armazenar informações de usuários e grupos e netgroup. No entanto, os Arquivos NetApp do Azure atualmente não podem usar a funcionalidade netgroup no LDAP no Windows Ative Directory.

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

  • As comunicações LDAP criptografadas podem ser obtidas usando LDAP sobre TLS (que opera pela porta 389) ou assinatura LDAP, que podem ser configuradas na conexão do Ative Directory.

  • Os Arquivos NetApp do Azure dão 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 obter melhor desempenho.

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

  • Se nenhum servidor LDAP preferencial estiver definido, o nome de domínio do Ative 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 nesse registro SRV. Você pode consultar manualmente os registros de serviço LDAP no DNS a partir de um cliente usando nslookup comandos or 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, consulte Mapeamento de nome personalizado usando LDAP.

  • Tempos limite de consulta LDAP

    Por padrão, as consultas LDAP atingem o 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 Arquivos NetApp do Azure poderá ser negado, dependendo das configurações de permissão do volume. Consulte Criar e gerenciar conexões do Ative Directory para entender as configurações de tempo limite de consulta LDAP dos Arquivos NetApp do Azure.

Tipos de mapeamento de nomes

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

  • O mapeamento simétrico de nomes é o mapeamento de nomes 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 user1UNIX .
  • O mapeamento assimétrico de nomes é 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 user2UNIX .

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

Mapeamento de nome personalizado usando LDAP

O LDAP pode ser um recurso de mapeamento de nomes, se os atributos do 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 um-para-um (ou seja, assimétricos), você pode especificar um valor diferente para uid no objeto de usuário do que o configurado para o nome de usuário do Windows.

No exemplo a seguir, um usuário tem um nome Windows de asymmetric e precisa mapear para uma identidade UNIX de UNIXuser. Para conseguir isso nos Arquivos NetApp do Azure, abra uma instância do MMC Usuários e Computadores do Ative Directory. Em seguida, localize o usuário desejado e abra a caixa de propriedades. (Para isso, é necessário ativar o Editor de Atributos). Navegue até a guia Editor de atributos e localize o campo UID, preencha o campo UID com o nome UNIXuser de usuário UNIX desejado 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 essa ação for executada, os arquivos gravados a partir de compartilhamentos SMB do Windows pelo usuário asymmetric do Windows serão de propriedade UNIXuser do lado NFS.

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

Captura de tela que mostra o proprietário do Windows SMB chamado Asymmetric.

O exemplo a seguir mostra o proprietário UNIXuser do NFS (mapeado do usuário asymmetric do Windows 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 utilizadores locais de NFS com LDAP

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 tentarão pegar essa ID numérica e procurá-la no LDAP 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 – mesmo que o usuário solicitante tenha 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 é executada. 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 afetará o acesso ao volume, mas poderá afetar a forma 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éricos com NFSV4.1, o que significa que as solicitações NFSv4.1 chegarão 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 um ID numérico for traduzido 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 afetará o acesso ao NFSv4.1, pois ele voltará ao comportamento padrão do NFSv3, 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 (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 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 nome UNIX para Windows tentado 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 o ID numérico 1001 resolver 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".

Ativar "Permitir usuários NFS locais com LDAP" desativará todas as traduções LDAP de IDs numéricos para nomes de usuário, o que efetivamente interromperá o acesso aos volumes de estilo de segurança NTFS. Como tal, o uso desta 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 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 o aninhamento 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.

Próximos passos