Integração de Rede com Diretórios LDAP

Conheça o protocolo que pode ajudar sua empresa a centralizar o acesso à informação

O que é um diretório LDAP

O protocolo LDAP (Lightweight Directory Access Protocol) é uma das tecnologias mais difundidas e menos compreendidas da Internet atual. Navegadores web, clientes de e-mail, servidores IMAP, bancos de dados, linguagens de programação e uma série de outros aplicativos têm em seus feature lists suporte a LDAP.

O LDAP é um protocolo de acesso às informações contidas em um diretório, definido como uma espécie de “livro de endereços” da empresa. Você pode fazer uma analogia com o SQL, que é uma linguagem de consulta a bancos de dados relacionais, mas o LDAP define não só a linguagem de consulta como também o protocolo de rede que transporta as requisições e respostas do cliente para o servidor. Ao contrário de um banco relacional, que necessita de uma biblioteca específica para implementar o seu protocolo de rede, qualquer cliente LDAP pode obter informações em qualquer servidor de diretório LDAP, já que o protocolo foi padronizado pelo IETF.

Grandes empresas do setor apresentaram o diretório ao mercado como a “solução de todos os problemas” de administração, gerenciamento, segurança e integração de redes, quando lançaram novas versões dos seus NOS (Network Operating Systems) incluindo serviços de diretório. Por outro lado, a maioria dos usuários deve ter ouvido falar de diretórios LDAP associados a livros de endereços de e-mail do Outlook ou do Yahoo. Isto gerou uma certa confusão quanto ao propósito e utilidade dos diretórios em geral e do LDAP especificamente. Na verdade, o LDAP complementa a infra-estrutura de redes, fornecendo novos recursos e especialmente maior integração, em vez de ser, como alguns pensam, uma nova alternativa para as funções realizadas por outros protocolos e linguagens estabelecidos como SNMP, HTTP, SMTP, IMAP ou SQL.

Um diretório é um banco de objetos hierárquico, otimizado para consultas, onde são armazenadas informações relativamente estáticas, como logins e senhas da rede, nomes de computadores, endereços IP, endereços de e-mail, e outras informações de configuração, identificação e localização de recursos da rede. Podemos dizer que os arquivos /etc do Unix, o NIS, o Bindery do Netware ou o SAM do Windows são formas primitivas de diretório, que apresentam duas limitações: primeiro, não são extensíveis para armazenar informações sobre novos dispositivos e serviços que venham a ser implantados na rede; segundo, não são escaláveis para redes com milhares ou milhões de nós, usuários e serviços.

LDAP e Serviços de Rede

Se armazenamos as informações de autenticação e de configuração da rede no diretório, significa que as aplicações responsáveis por fornecer serviços de rede têm que ser programadas para buscar estas informações no diretório em vez de nos seus próprios arquivos-texto. A maioria das aplicações de rede populares, como Apache, Sendmail, Qmail, Cyrrus IMAP, Samba e PostgreSQL já é capaz de utilizar diretórios LDAP desta forma.

Muitos destes programas suportam o uso de bancos de dados relacionais para autenticação de usuários, mas não para outras configurações, e a falta de padronização destas soluções acaba levando a dois problemas: a profusão de bancos de dados de usuários, um para cada serviço de rede, aumentando a complexidade da administração da rede, ou a queda de performance no banco de dados central de usuários, o que leva a soluções de replicação (sincronização) e, novamente, mais complexidade.

O diretório LDAP foi desenhado para ser escalável a milhões de objetos, utilizando mecanismos de replicação e de distribuição das informações. Sua rede pode ter vários servidores LDAP, cada qual responsável por uma parte da árvore do diretório, e cada um desses servidores pode ter vários servidores de backup, garantindo a performance e a tolerância à falhas do sistema como um todo. Um mesmo servidor LDAP pode ser o “master” para algumas partições da árvore e “slave” para outras partições, permitindo a distribuição e o acesso eficiente das informações em uma WAN.

O problema da padronização é resolvido pela definição de uma série de schemas padronizados por RFCs, que dizem quais classes de objetos (objectclasses) podem existir no diretório, que atributos cada um pode conter, e que tipo de informação pode ser armazenada em cada atributo. Você pode criar novas classes e atributos para a sua aplicação, e a existência desses padrões garante que todos os serviços e aplicações da rede sejam capazes de identificar atributos comuns como nome do usuário, chave pública e nome de host.

Um dado objeto no diretório pode pertencer simultaneamente a várias classes de objetos, e as classes e atributos podem ser modificados dinamicamente em objetos já existentes. Assim você pode, por exemplo, definir um objeto da classe “posixAccount” que define um usuário Unix, e posteriormente estender este mesmo objeto com a classe inetOrgPerson que define atributos para troca de e-mail. Mais adiante, quando conseguir aprovação da diretoria para migrar todos os servidores de arquivos para Linux, você pode acrescentar a classe sambaAccount, de modo que este mesmo usuário possa ser autenticado por estações e servidores Windows.

O LDAP também prevê segurança, que é o grande problema das soluções anteriores como o NIS. A comunicação com um servidor LDAP pode ser criptografada por SSL, tanto o cliente quanto o servidor podem ser autenticados por certificados digitais, e ainda podemos utilizar o Kerberos como mecanismo de autenticação distribuída.

Além disso, o diretório permite a delegação de autoridade administrativa. Em vez de apenas um usuário “root” todo-poderoso (ou similares em outros sistemas), podemos dar autoridade a um administrador local (digamos, responsável pela filial de Belo Horizonte da empresa) para criar e modificar objetos apenas no ramo correspondente da árvore. Podemos até mesmo limitar a leitura e alteração de atributos específicos como, por exemplo, o certificado digital do usuário.

LDAP e Aplicações

Entretanto, a grande utilidade de um diretório LDAP vai além da integração para serviços de rede. A maioria dos sistemas de informação da sua empresa tem necessidades próprias de configuração e de autenticação, contribuindo para o caos do gerenciamento da rede. Porque não utilizar o LDAP também nas suas aplicações?

Os fornecedores comerciais de NOS vendem esta idéia há tempos, fornecendo SDKs e componentes específicos. A força da Internet fez com que esses fornecedores compatibilizassem os seus produtos com o LDAP, de modo que seu aplicativo desenvolvido com ferramentas RAD proprietárias pode utilizar informações no seu diretório LDAP naturalmente. Que tal ter a sua aplicação de recursos humanos criando automaticamente o login na rede para o novo funcionário, ou bloqueando a conta de um usuário que está sendo demitido?

As ferramentas de desenvolvimento livres não ficam devendo nada. Temos várias opções de APIs para acesso a LDAP, a maioria delas construídas como classes de objetos, sendo que o PHP já traz este suporte no pacote básico. Fãs do Perl podem escolher entre o PerLDAP do Mozilla.org ou o Net::LDAP do CPAN, e desenvolvedores Java podem acessar LDAP via o padrão JNDI utilizando provedores fornecidos pela IBM e Novell sob licenças de software livre. Além, é claro, das APIs de cliente para C e C++ que vêm como parte integrante da maioria das distribuições do GNU/Linux.

Implementando o OpenLDAP em sua rede

Não vamos fornecer aqui um how-to detalhado de como integrar a sua rede utilizando o protocolo LDAP, mas apenas uma orientação geral dos passos necessários para orientar o administrador de redes interessado.

O conjunto mínimo de software que você vai utilizar envolve o servidor OpenLDAP e os módulos pam_ldap e nss_ldap, que são fornecidos na maioria das distribuições em várias versões. O OpenLDAP é formado por dois daemons, slapd e slurpd, o primeiro, responsável pelo próprio diretório e o segundo, pela replicação do diretório entre hosts independentes.

Você terá que configurar o OpenLDAP para a sua árvore de diretório em particular (veja o “Quick Start Guide” no FAQ do OpenLDAP em www.openldap.org) e definir um conjunto mínimo de objetos representando a raiz da sua árvore e o usuário administrador do diretório, que seria equivalente ao root.

Você pode então criar seus objetos manualmente, utilizando os utilitários ldapadd, ldapmodify e ldapsearch fornecidos com o OpenLDAP, ou então buscar um utilitário gráfico como o GQ (biot.com/gq/). Mas será mais fácil migrar os dados nos seus arquivos /etc/passwd, /etc/group e outros utilizando os scripts de migração desenvolvidos pela PADL Software (www.padl.com/tools.html). Estes scripts estão disponíveis em várias distribuições como parte do pacote OpenLAP em /usr/libexec/openldap/migration.

A parte desagradável vem na manutenção dos usuários. Utilitários fáceis, como o useradd, o Kusers ou o Linuxconf, foram feitos para editar os arquivos no diretório /etc, e não para interagir com um servidor LDAP. Isto me levou a criar um módulo para o Webmin para a administração de usuários Unix em um diretório LDAP, (veja em ldap-users.sourceforge.net). Este módulo não atende ainda a todos os desejos dos administradores de rede, mas já está sendo utilizado com sucesso por algumas empresas, e como todo bom programa, pode ser aperfeiçoado GPL por qualquer um para atender às suas necessidades.

Cada estação ou servidor vinculado ao diretório LDAP (incluindo aqueles que rodarem o slapd) deverá ter os módulos pam_ldap e nss_ldap instalados e configurados. O primeiro módulo, que deve ser configurado para cada serviço disponível em /etc/pam.d, permite que a validação e a mudança de senha dos usuários seja feita no diretório. O segundo, pela edição de /etc/nsswitch.conf, faz com que todas as buscas por informações, como o nome do usuário (dado o seu uid), o diretório home e o shell padrão, sejam obtidos no diretório. Desta forma, você se preocupa apenas com o conteúdo no diretório, e não em manter o diretório em sincronia com os arquivos /etc/passwd, /etc/shadow e /etc/group.

Os aplicativos do sistema irão utilizar o diretório transparentemente, desde que eles tenham sido escrito chamando as funções getpw* da libc, o que todo bom programa Unix faz. Aplicativos que mantêm seus próprios cadastros de usuários e senhas (como o PostgreSQL) ou que necessitam de informações extras (como aliases de e-mail ou as senhas do Samba) deverão ser configurados caso a caso para buscar estas informações no diretório.

Outros Diretórios para o Linux

O OpenLDAP tem sido a opção preferencial para a implantação de diretórios LDAP para redes Linux, mas o mercado fornece várias outras opções, a maioria delas proprietárias:

• O NDS da Novell, também vendido com o nome eDirectory, inclui um servidor LDAP onde não existe necessariamente a relação master/slave, ou seja, vários servidores podem conter uma cópia atualizável de parte da árvore do diretório. Ele inclui ainda módulos nss e pam para a autenticação dos usuários e aplicativos gráficos para a administração do diretório
• O antigo Netscape Enterprise Directoty, hoje vendido pela Sun como parte da linha iPlanet de servidores, é um servidor confiável e fornece uma interface web para a administração.
• O Active Directory da Microsoft também é um servidor LDAP, mas não fornece no pacote padrão nenhum suporte para as classes de objetos necessários para manter usuários Unix. Não seria difícil configurar o AD para reconhecer as classes necessárias e construir um aplicativo para administração (na verdade, uma vez que o diretório do AD ou qualquer outro esteja configurado, qualquer front-end de gerenciamento poderia ser utilizado, da mesma maneira que sobre o OpenLDAP ou qualquer outro servidor de diretório).

Fernando Lozano - fernando@lozano.eti.br