LDAP::LDAP, Servidores e Clientes – Parte 5

UPDATE: eu percebi hoje que eu escrevi esse mesmo tópico duas vezes, em dois posts diferentes., Este deve ser considerado o esforço combinado, mas pode ler um pouco como um blog Frankenstein. Original do outro permanece aqui:

este post é parte 5 da nova série LDAP que eu comecei a ajudar as pessoas a se tornarem mais conscientes do que é LDAP e como ele funciona.

Part one was posted here:

What the heck is an LDAP anyway?

Este post irá focar em servidores LDAP e clientes.,

servidores vs clientes

no reino animal, você vai ver muitas vezes relações simbólicas, como a alegada relação entre crocodilos e o pássaro plover, que come coisas mortas a partir dos dentes do crocodilo.

a relação cliente LDAP / servidor também é simbiótica. O servidor precisa que o cliente lhe faça perguntas e o cliente precisa que o servidor lhe dê informações.,

Se a natureza não é a sua coisa, há sempre a relação simbiótica homem-aranha/veneno:

no caso do LDAP, um cliente estará pedindo coisas como usernames, localizações de diretórios domésticos, membros de grupo, etc. O servidor seria responsável por entregar essa informação.

LDAP não é diferente de outros protocolos, como HTTP, NFS, etc. Há uma relação cliente e servidor. E tal como qualquer relação de sucesso, tem de haver alguém a falar e alguém a ouvir.tenho um filho de dois anos. Ele fala, mas a maior parte é apenas treino para ele., Ele vai dizer coisas como ” papá, camião dos pássaros.”E eu digo” pássaro? Camião? Fixe!”É principalmente uma conversa unilateral onde eu essencialmente ACK sua SYNs. (Eu preciso sair mais)

às vezes, é ” dada read book.”E eu obedeço.

LDAP as conversas entre cliente / servidor não são muito diferentes. O cliente tem dois anos. O servidor LDAP sou eu.

“LDAP, find user information”

“User information? Fixe! Aqui tens!”

em sua própria base, conversas LDAP não são nada mais do que SYNs TCP e ACKs. Assim, ao configurar ou solucionar problemas, eles devem ser tratados como tal.,

Onde as coisas ficam confusas é quando você começa a considerar o que é preciso para que uma relação cliente / servidor seja bem sucedida. Não é uma boa ideia deixar os canais de comunicação abertos para todos no mundo verem, por isso há algumas regras que temos de seguir quando os clientes querem falar com os servidores.

configuração Cliente/Servidor

LDAP clientes podem ser qualquer coisa em execução de software que pode consultar LDAP através de padrões RFC-2307. Windows, Linux, Sistemas de armazenamento OSes, etc podem Todos agir como clientes., Alguns sistemas operacionais contêm funcionalidade LDAP incorporada (como o Windows) que não requer que você instale nada de especial. Alguns sistemas de armazenamento, como o ONTAP de dados agrupados do NetApp, suportam totalmente o LDAP que adere ao padrão RFC-2307. Para mais informações, veja TR-4073: autenticação unificada segura.informação básica da rede.

lembre-se, na sua base, é uma simples conversa TCP.

• LDAP nomes de servidores, URI ou endereços IP (o servidor está em DNS? Há registos SRV para LDAP?,)
• LDAP port (os portos predefinidos são 389 para LDAP, 636 para LDAP sobre SSL, 3268 para o catálogo Global; você mudou o porto do servidor?)
• O cliente pode falar com o servidor (roteamento?)

antes que um cliente possa iniciar uma conversa com um servidor, ele tem que ser configurado com informações sobre esse servidor. A configuração seguirá o básico do modelo OSI, começando nas primeiras camadas da pilha para iniciar uma conversa TCP com o servidor.

clientes LDAP comuns

clientes LDAP também tendem a aderir aos mesmos padrões que os servidores. Por quê?, Porque faz sentido. Os clientes podem ficar sozinhos a partir de um sistema operacional, mas alguns SOS integram LDAP em sua configuração por padrão. O Windows é um exemplo disso por causa de como o LDAP integral é para o Diretório Ativo.

outros clientes incluem (mas certamente não se limitam a):

• SSSD
• OpenLDAP

Esperemos que a informação neste post tenha ajudado a esclarecer qualquer confusão nos clientes e servidores LDAP.

alguns servidores LDAP até lhe permitirão fazer modificações no porto em que ouve a comunicação LDAP., Isto é para ajudar a proteger os servidores LDAP, não alavancando portas bem conhecidas. Com servidores LDAP comuns, como o Active Directory, no entanto, é difícil usar portas diferentes das comuns. Ao configurar os clientes, a configuração do servidor LDAP precisa sempre de ser revista.

Depois de passarmos pela conexão TCP, passamos o nosso tempo na camada de aplicação do modelo OSI.

informação de ligação / autenticação.

primeiro temos que nos preocupar em autenticar o servidor LDAP. Isto também é conhecido como ligante., O nível de autenticação dependerá do que o servidor foi configurado para permitir. O nível de autenticação mais baixo possível é “anônimo”, mas nenhum servidor LDAP moderno permite o Anonymous binds por padrão. Geralmente, uma conta só de leitura no servidor LDAP é necessária para autenticar a um servidor para emitir consultas LDAP.

a informação de ligação necessária está incluída na configuração do cliente. Para a configuração mais segura, o uso de um sistema de autenticação baseado em ticket ou chave é preferido ao uso de senhas.,

informação de pesquisa LDAP

Depois de uma ligação ocorrer, as consultas são realizadas. A natureza das consultas dependerá da configuração do cliente. Que esquema estamos a usar? De que informação precisamos? Temos configurado o cliente para se certificar de tentar LDAP para informações em todos os momentos (via nsswitch.configuração conf)? Dissemos ao cliente onde começar a procurar informações sobre o servidor LDAP fornecendo o DN base?

Isto diz ao cliente onde começar a procurar informações no servidor LDAP.,O formato desta informação é o nome distinto (DNS), que eu encaixo na parte 4. Você pode definir um DN base e, em seguida, DNS específicos para usuários, grupos, grupos netgroups, etc. Você pode até especificar vários locais para procurar. A idéia aqui é filtrar nossas pesquisas para acelerar as coisas para os clientes.

facto Engraçado: A Apple corrige automaticamente DNs para DNS. Nada fixe, Apple. Nada fixe.

Uma vez que o cliente LDAP tenha a informação necessária, ele deve desindir – nós não queremos ficar logados indefinidamente. Isso é um problema de recursos.

LDAP schema information

I cover schemas in detail on part 3., Muitos clientes sabem sobre o esquema padrão que o LDAP usa, como RFC-2307, RFC-2307bis, etc. Na maioria dos casos, os esquemas no servidor não se desviarão disso. Mas em alguns casos, como por meio de intervenção manual ou ferramentas de terceiros como Dell Vintela (também conhecido como Centrify, Quest, etc), pode haver necessidade de fazer ajustes. Isto pode ser feito no cliente. Isso permite que o cliente peça a informação certa do servidor, que então permite que o servidor encontre a informação e responda ao cliente.,

opções específicas do cliente

muitos clientes oferecem opções específicas como caching de usuários / grupos, credenciais, configuração de Kerberos, etc. Estes são geralmente opcionais, mas devem ser analisados em uma base por cliente vendedor.

Exemplo de configuração do cliente

A seguir está um exemplo do que um cluster do Data ONTAP cliente LDAP como seria:

Este é o meu cliente de configuração executando o SSSD parece:

Servidores

Se você quer um lugar para os clientes de pedir informações, você precisa de um servidor., O servidor precisa ter um esquema RFC-2307 válido para conter os objetos LDAP necessários. Se estiver a fazer LDAP baseado no UNIX e quiser usar o directório activo da Microsoft para servir a autenticação baseada no UNIX, então terá de garantir que o servidor tem atributos UNIX no esquema. Enquanto o diretório ativo da Microsoft é executado em uma infra-estrutura LDAP, não é verdadeiro servidor LDAP baseado no UNIX até que você Extenda o esquema. Eu falo um pouco sobre isso em meu post no blog IDMU.

Como mencionado na secção cliente, você precisa de um monte de informações para configurar os clientes. O servidor é de onde esta informação vem., Aqui está o material que precisa de verificar no servidor para garantir que configura correctamente os seus clientes:

• Informação da rede do Servidor (endereço IP, Nome da máquina, itens DNS, registos SRV, portos do servidor LDAP, etc.)
• suportada bind level (use the strongest available, if possible)
• válido bind user or SPN
• DN information
• Schema type/attributes

LDAP servers can host tons of information. Codificadores UNIX, codificadores Windows, netgroups, endereços IP, SPNs, regras de mapeamento de nomes … Depende apenas do apoio dos clientes que determina o que você pode usar.,

servidores LDAP comuns

servidores LDAP todos tendem a aderir a um conjunto comum de normas, conforme definido pela IETF. Isto é para garantir uma ampla gama de apoio para os clientes., Algumas das mais comuns a servidores LDAP incluem (mas não estão limitados a):

• Active Directory
• OpenLDAP
• Servidor de Diretório RedHat/389 Directory Server
• Apple Open Directory
• o Oracle Internet Directory
• ApacheDS

Referências de LDAP

Se você estiver usando vários servidores LDAP e um cliente não é capaz de localizar um objecto no servidor LDAP específico do domínio, ele pode tentar usar uma referência de LDAP para procurar em outros servidores., Essencialmente, ele pega informações no servidor LDAP sobre outros servidores que conhecemos e tenta se conectar a eles através do URI LDAP até que a) encontre o objeto ou b) fique sem servidores para tentar. Isto pode acontecer tanto em servidores LDAP do Windows e não-Windows. Alguns clientes LDAP não suportam “perseguição de referência”, por isso é importante saber se isto está a acontecer no seu ambiente e se o seu cliente é capaz de perseguir referências.,

pesquisas globais de catálogos

em Active Directory, é possível armazenar uma cópia de atributos de vários domínios em uma floresta em controladores de domínio local atuando como servidores globais de catálogos. Por padrão, os atributos UNIX não são replicados no catálogo Global, mas você pode mudar esse comportamento conforme necessário. Eu cubro como fazer isto em TR-4073. Se você precisar consultar vários domínios na mesma floresta e quiser evitar referências LDAP, você pode simplesmente replicar os atributos necessários e mudar a porta LDAP para 3268 para que os servidores saibam usar o catálogo Global em vez disso!,

o meu ambiente

no meu ambiente, uso o LDAP Directório activo com gestão de identidade. Mas sou conhecido por usar os Serviços de Directórios OpenLDAP e RedHat. Ambos são perfeitamente válidos para usar. No entanto, se você está com a intenção de fazer multiprotocol NAS (CIFS/SMB e NFS), eu sugiro fortemente usar o Microsoft Active Directory para autenticação para usuários do UNIX e Windows. Torna a vida infinitamente mais fácil.

Se você já está usando LDAP baseado em Linux, tudo bem. Se possível, tente assegurar que os nomes dos utilizadores do UNIX (atributo uid LDAP) correspondem aos nomes dos utilizadores do Windows (atributo sAMAccount)., Dessa forma, se você estiver usando multiprotocol NAS, você não tem que se preocupar com o mapeamento de nomes.

Se você quiser ver algo adicionado a este post sobre servidores e clientes LDAP, sinta-se à vontade para comentar ou seguir-me no Twitter @NFSDudeAbides!

Wrap-up

Para informações mais detalhadas sobre a configuração LDAP (particularmente com dados agrupados do NetApp ONTAP), ver TR-4073: Secure Unified Authentication.

também, fique sintonizado para mais na série de conceitos básicos LDAP neste blog!,

Links para outras seções podem ser encontrados no primeiro post desta série:

O Que diabos é um LDAP de qualquer maneira?