Por David "Del" Elson
última atualização em 9 de Julho de 2001
Esta É a segunda parte de uma série de duas partes devotada a discutir a autenticação LDAP no Linux. O primeiro artigo ofereceu um primeiro contato com o LDAP, incluindo: instalação e configuração do OpenLDAP, migrando para o OpenLDAP, e a configuração de consultas LDAP. Este artigo irá ver a configuração do PAM e NSS para o LDAP, a proteção da conta root, algumas ferrametnas LDAP, a proteção do OpenLDAP, o OpenLDAP e o SSL, e alguns cuidados a tomar sobre o OpenLDAP. Note que, apesar desta série estar focada no Red Hat 7.1, a maioria dos mesmos princípios aplicam-se ao Debian e outras distribuições.
Primeiro, um aviso: este roteiro só funciona com o authconfig do Red Hat versões 7.0 ou posteriores. Se você está usando o Red Hat 6.2 ou anterior, você precisará ler as páginas man sobre os arquivos de configuração e ediar os mesmos à mão. Note que não há um arquivo /etc/pam.d/system-auth no Red Hat 6.2.
a configuração do PAM e NSS para usar o LDAP exige que seja editado um arquivo de configuração em /etc/pam.d (/etc/pam.d/system-auth), a modificação do arquivo de configuração NSS, que é /etc/nsswitch.conf, e a edição dos arquivos de configuração pam_nss e pam_ldap, que é /etc/ldap.conf. Felizmente, o Red Hat fornece um utilitário chamado authconfig que faz isto automaticamente para você. Para usar o mesmo, execute authconfig na linha de comando. Dentro do authconfig, isto é um exercício direto. Marque o quadro 'Use LDAP'. Nos próximos quadros, entre um valor para o servidor (o mesmo endereço IP que você usaou em /etc/openldap/ldap.conf), e um Base DN (o mesmo Base DN especificado em /etc/openldap/slapd.conf).
Uma vez finalizado, tudo deve estar configurado. Eu descobri que a melhor forma de descobrir isto é como segue:
O arquivo slapd.conf que foi configurado anteriormente contém uma entrada para o DN root bem como uma senha. Esta senha é usada como uma senha de recuperação para o root DN caso a entrada não seja encontrada no diretório. Obviamente, quando você configura o LDAP a primeira vez, com um banco de dados vazio, esta entrada era exigida. Agora não é mais, portanto você deve comentar a mesma, como segue:
rootdn "uid=root,ou=People,o=Mycompany,c=AU" # rootpw secret
Sua senha root deve ter sido obtida do arquivo /etc/passwd ou /etc/shadow e inserida no LDAP. Para testar isto, repita a pesquisa acima usando a opção -D no ldapsearch para tentar um logon em seu diretório LDAP, como segue:
ldapsearch -x -D 'uid=root,ou=People,o=MyCompany,c=AU' -W 'uid=root'
O ldapsearch irá pedir uma senha - entre sua senha de superusuário aqui e, se tudo correr de acordo com o planejado, deve funcionar corretamente.
O OpenLDAP vem com um leque de ferramentas de linha de comando Unix para administração do diretório LDAP. Estas ferramentas são úteis como referência, e como ferramentas similares são fornecidas com muitos outros sistemas LDAP comerciais, é uma boa idéia aprender estas. As ferramentas vêm com páginas man compreensivas, entretanto, pode ser melhor ler alguma informação LDAP na Internet e/ou um guia de administração LDAP para aprender a terminologia.
As ferramentas são:
Etas ferramentas admitem um conjunto de parâmetros de linha de comando comuns, que incluem opções como:
Existe uma variedade enorme de ferramentas LDAP disponíveis gratuita ou comercialmente na internet. Uma rápida pesquisa no freshmeat por LDAP vai revelar várias. Aqui estão algumas que eu gosto bastante.
O GQ é uma ferrametna poderosa que permite que você veja dentro do diretório LDAP e administre parte do mesmo. O GQ permite controle completo sobre o servidor LDAP, incluindo:
O GQ também permite que você entre dentro do diretório LDAP e veja as funções internas do LDAP. O GQ está disponível na forma de código fonte do site web, e o código fonte inclui um arquivo .spec, de forma que você pode criar um arquivo RPM se quiser.
O Directory Administrator é uma aplicação para administrar entradas de usuário e grupos em servidores de diretório LDAP. Ela fornece uma interface amigável para administrar os detalhes pessoais dos usuários, informações de livro de endereço, e roteamento de email (para versões do sendmail que suportam informações de roteamento de email armazenadas em LDAP). Eu achei a interface do Directory Administrator simples e intuitiva, apesar de não ser tão poderoso quanto o GQ e não ir além da administração simples de usuários e grupos.
O autor do Directory Administrator tem prometido uma nova versão por algum tempo, e eu tenho alguns poucos itens na minha lista de pedidos para ele, o principal problema é que sua janela principal fornece uma visualização não ordenada e não estruturada de todos os usuários na árvore do diretório. Se existe um número muito grande de usuários no diretório, isto é insatisfatório (eu tenho cerca de 1500 em uma árvore LDAP que administro, e não será incomum organizações que tem dezenas de milhares). Como uma ferramenta básica de administração de usuários em uma rede Linux pequena com um diretório LDAP, entretanto, o Directory Administrator é uma excelente ferramenta.
Ocasionalmente eu monto sistemas usando a ferramenta Kickstart da Red hat. A última versão do sistema de instalação do Red Hat inclui algumas opções Kickstart que podem ser usadas para conectar um sistema a uma rede baseada no LDAP durante a instalação do sistema. As opções são descritas em detalhe no Red Hat Linux Customization Guide, mas a opção principal que você precisa é o parâmetro "auth" que deve ser:
auth --enableldap --enableldapauth --ldapserver= --basedn=
O Red Hat também inclui alguma informação sobre o OpenLDAP no seu Red Hat Linux Reference Guide, especialmente o capítulo 4. Se você vai usar a autenticação Kerberos com o OpenLDAP, então você precisa ler também o capítulo 9.
A maneira principal em que você pode melhorar a segurança do OpenLDAP é incluir o modo secure sockets layer (SSL - camada segura de soquetes), e o modo transport layer security (TLS - segurança de camada de transporte) na sua conexão cliente/servidor. Isto criptografa todo o tráfego LDAP usando o protocolo SSL. O OpenLDAP versão 2.0 e posterior possui a capacidade de rodar nos modos SSL e TLS usando as bibliotecas OpenSSL, mas você deve estar usando uma versão posterior à 2.0.7 para que funcione corretamente.
Os passos principais que você deve serguir para conseguir que o OpenLDAP funcione com o SSL são:
Note que existe duas formas diferentes de operar o OpenLDAP com o SSL. São elas:
O modo TLS é mais flexível que o modo SSL (uma vez que clientes ou servidores que não entendem o SSL podem continuar a comunicação ignorando o comando Start TLS), mas infelizmente muitos servidores e clientes LDAP antigos não implementaram este modo e só usam o modo SSL. Assim é preferível, na minha opinião, para fezer os seus servidores e clientes LDAP funcionando tanto no modo TLS quanto SSL.
Felizmente, esta é a parte mais fácil do trabalho. Se você está usando uma versão do OpenLDAP empacotada com, por exemplo, o Red Hat ou Debian Linux, você descobrirá que este trabalho já foi feito para você. Novamente, certifique-se que você tem uma versão recente do OpenLDAP (no Red Hat, qualquer versão que é 2.0.7-3 ou posterior serve).
Se você está compilando o OpenLDAP do código fonte, você só precisa informar a seguinte flag adicional quando estiver rodando o script de configuração do OpenLDAP:
--with-tls
Você também precisa certificar-se que as bibliotecas OpenSSL estão presentes em seu sistema.
Para usar o OpenLDAP no modo TLS ou SSL voc~e precisa gerar uma chave SSL em formato PEM. Assumindo que você tem o OpenSSL instalado (caso contrário você não estaria fazendo isto), você irá encontrar um arquivo Makefile no diretório /usr/share/ssl/certs que contém os comandos apropriados para criar esta chave. Você pode executar o seguinte comando:
cd /usr/share/ssl/certs make slapd.pem
Durante o processo de criação da chave, o programa irá pedir vários detalhes sobre seu servidor. Estes incluem o código do país, estado, nome da organização, endereço email, nome do servidor, etc. Responda estas questões da forma mais completa possível - elas serão codificadas no arquivo PEM. Se você não tem o arquivo Makefile do OpenSSL, ou não pode executar o comando "make" por alguma razão, então terá de criar o arquivo PEM manualmente. Segue um roteiro aproximado dos comandos necessários:
/usr/bin/openssl req -newkey rsa:1024 -keyout tempfile1 -nodes -x509 -days 365 -out tempfile2 cat tempfile1 > ldap.pem echo "" >> ldap.pem cat tempfile2 >> ldap.pem rm -f tempfile1 tempfile2
Note que este comando irá criar uma chave RSA e irá auto-assinar a mesma chave. Chaves auto-assinadas não são usuais em (por exemplo) comunicações HTTPS, pois as chaves são geralmente assinadas por uma terceira empresa conhecida como Certification Authority. Neste caso, entretanto, uma chave auto-assinada é aceitável, já que a maioria dos clientes LDAP não checa a assinatura da chave. Obviamente, para usuários mais avançados, é possível gerar uma chave e ter a mesma assinada por uma Certification Authority externa. Fica a seu critério o que fazer.
Nota importante: uma vez que você tenha gerado as chaves, é importante que elas sejam tornadas 'read only' pelo usuário que está rodando o servidor LDAP. Para o Red Hat Linux, o servidor OpenLDAP (slapd) é executado como um usuário não privilegiado, chamado 'ldap', em um grupo chamado 'ldap'. Para tornar este usuário e grupo os proprietários da chave recém criada, execute o seguinte comando:
chown ldap.ldap slapd.pem
Para configurar o OpenLDAP para usar as chaves SSL que você recém criou, é preciso modificar o arquivo /etc/openldap/slapd.conf. As seguintes linhas devem ser acrescidas ao arquivo (elas podem estar em qualquer parte do arquivo, mas eu sugiro colocar as mesmas perto do início, após todas as declarações 'include'):
TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCertificateFile /usr/share/ssl/certs/slapd.pem TLSCertificateKeyFile /usr/share/ssl/certs/slapd.pem
Note que existem diferentes valores válidos para a linha TLSCipherSuite, mas a linha acima é o que eu recomendo.
Você pode também ter que modificar seu script de inicialização do LDAP. Se você está usando o Red Hat Linux versão 7.0 ou posterior, não será necessário. Caso contrário, você deve localizar a linha no seu script de inicialização (provavelmente /etc/rc.d/init.d/ldap ou /etc/init.d/ldap) que contém a linha que incia o slapd, e modificar a mesma para ficar assim:
slapd -h '"ldap:/// ldaps:///"'
É a opção após o "-h" que nos interessa neste ponto. Você deve notar que estmos informando ao servidor LDAP para funcionar tanto nos modos ldap quanto ldaps (seguro). Teoricamente, uma vez que isto seja feito, você pode desligar o modo ldap e usar somente o modo seguro, mas isto não é recomendado, já que muitos clientes LDAP não suportam o modo seguro. Note que podem haver mais opções na linha que roda o slapd em seu script de incialização: deixe as mesmas intactas.
É preciso reiniciar o servidor LDAP para que o mesmo re-leia o arquivo slapd.conf:
/etc/rc.d/init.d/ldap stop /etc/rc.d/init.d/ldap start
O primeiro passo para testar se o servidor LDAP está funcionando no modo SSL é executar o seguinte comando:
netstat -a | grep LISTEN
Examinando a saída do comando, você pode ver se o seu servidor slapd está ouvindo a porta 389 (ldap) bem como a porta 636 (ldaps). Se o modo SSL não estiver funcionando, então ele estará ouvindo apenas a porta 389 (ldap).
Felizmente, o OpenSSL vem não só com um útil gerador de chaves, mas também com um testador de linha SSL. Ele funciona com o seguinte comando:
openssl s_client -connect localhost:636 -showcerts
Note que eu escolhi usar a conexão direta ao LDAP no modo SSL em vez de ir através do TLS - o último é possível, mas um pouco complicado.
Se tudo correr bem, você deve ver alguma saída do servidor LDAP na janela de comando, mostrando informações sobre o certificado, bem como o certificado, IDs da sessão, e chaves mestre, que estão em uso pelo servidor.
Se você puder encontrar um cliente LDAP que suporta SSL ou TSL, como o GQ, ative a opção no cliente que habilita o modo TLS, e veja se ele funciona. Voila, você tem agora um servidor LDAP seguro!
Por mais que eu goste de software livre, eu tenho encontrado alguns problemas durante o tempo que eu tenho usado o OpenLDAP. Por exemplo, em comparação com alguns servidores LDAP como o iPlanet DS e o NDS da Novell, ele é um pouco lento. Isto pode ser percebido quando operações tanto de leitura quanto escrita estão sendo executadas ao mesmo tempo.
Eu também descobri alguns bugs no servidor OpenLDAP e bibliotecas. Estes causam vários problemas, incluindo coisas como falhas em pesquisas NSS sob carga, transações SSL terminando inesperadamente, e problemas de recuperação de diretório depois de um system crash. Para o seu crédito, o time do OpenLDAP mantém um sistema de controle de bugs acessível ao público, onde o status de problemas como estes podem ser monitorados. Em algumas ocasiões eu consegui reparar certos bugs ao reverter para versões anteriores das bibliotecas NSS LDAP.
Como alternativas ao OpenLDAP, tanto o servidor de diretórios Novell quanto o iPlanet (não-gratuitos, não open source) possuem servidores disponíveis ao Linux. Ambos funcionam bem com as bibliotecas padrão LDAP NSS e PAM, apesar da Novell fornecer seu próprio PAM e bibliotecas NSS (por um preço). Infelizmente, uma discussão mais profunda sobre os servidores de diretório da Novell e iPlanet terá de esperar outra oportunidade, pois está fora do escopo deste artigo.