Ldap

Sumário
I Sobre essa Apostila 2
II Informações Básicas 4
III LDAP 9
1 LDAP 10
2 Plano de ensino 11
2.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Público Alvo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Pré-requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6 Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7 Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8 Bibliograﬁa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Introdução 13
3.1 O que é LDAP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 História . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4 Primeiros conceitos 15
4.1 Para que podemos usar o LDAP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Que tipos de aplicativos podem utilizar LDAP? . . . . . . . . . . . . . . . . . . . . . 15
4.3 Como é o acesso ao LDAP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4 Como é o uso do LDAP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.5 Como são os dados do LDAP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.6 Quem tem acesso aos dados? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.7 Conceitos e convenções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5 Estrutura de diretórios LDAP 18
5.1 Noções gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2 * Country . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3 * Organizational Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.4 * Organizational Unit Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.5 * User Identiﬁcation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1

CDTC Centro de Difusão de Tecnologia e Conhecimento Brasil/DF
5.6 * Distinguished Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.7 * Relative Distinguished Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.8 * Domain Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.9 Exemplo gráfico de uma árvore LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6 Instalação 22
6.1 Pacotes e serviços utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2 BerkleyDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.3 SSL/TSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.4 OpenLDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.5 Um pouco sobre os arquivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7 Teoria LDAP 25
7.1 Algumas apresentações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.2 ObjectClass: funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.3 Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8 slapd.conf : Configurando - Parte 1 29
8.1 Introdução ao slapd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.2 Esquemas - parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.3 Esquemas - parte 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.4 Dois ajustes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.5 Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.6 SSL e TLS - parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.7 SSL e TLS - parte 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.8 SSL e TLS - parte 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.9 Algumas variáveis relativas à segurança . . . . . . . . . . . . . . . . . . . . . . . . . 33
9 slapd.conf : Configurando - Parte 2 35
9.1 Recorte do slapd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.2 Backends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.3 Suffix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.4 RootDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.5 Senha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.6 Diretório . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10 slapd.conf : Indexes e ACLs 39
10.1 Índices (indexes) - parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.4 ACLs (Access Control Lists) - parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2

11 LDIF 43
11.1 Introdução ao LDIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
11.2 1 - Sintaxe das atribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
11.3 2 - Listagem de atribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
11.4 3 - Comentários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
11.5 4 - Caracteres especiais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
11.6 5 - Continuação de linha com quebra de linha . . . . . . . . . . . . . . . . . . . . . . 45
11.7 6 - Atributos vazios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
11.8 7 - Linhas em branco e início de bloco . . . . . . . . . . . . . . . . . . . . . . . . . . 46
11.9 8 - Atribuição por referência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
12 Ferramentas LDAP/Slapd 47
12.1 Ferramentas de manutenção LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
12.2 1 - Ldapadd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
12.3 2 - Ldapdelete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
12.4 3 - Ldapmodify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
12.5 4 - Ldapsearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
12.6 5 - Ldapmoddn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
12.7 6 - Ldapbind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
12.8 Ferramentas ofﬂine (do slapd) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
13 Manipulando dados 52
13.1 Escrevendo um LDIF - parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
13.2 Escrevendo um LDIF - parte 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
13.3 Levantando dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
13.4 Consultando dados - parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
13.5 Consultando dados - parte 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
13.6 Removendo dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
14 Últimas notas 56
14.1 Replicação LDAP - parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
14.2 Replicação LDAP - parte 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
14.3 Diretórios LDAP distribuídos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
14.4 Interfaces de administração LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3

Conteúdo
O conteúdo dessa apostila é fruto da compilação de diversos materiais livres publicados na in-
ternet, disponíveis em diversos sites ou originalmente produzido no CDTC em http://www.cdtc.org.br.
O formato original deste material bem como sua atualização está disponível dentro da licença
GNU Free Documentation License, cujo teor integral encontra-se aqui reproduzido na seção de
mesmo nome, tendo inclusive uma versão traduzida (não oﬁcial).
A revisão e alteração vem sendo realizada pelo CDTC (suporte@cdtc.org.br) desde outubro
de 2006. Críticas e sugestões construtivas são bem-vindas a qualquer tempo.
Autores
A autoria deste é de responsabilidade de Tomas Ribeiro Cardoso (tomas@cdtc.org.br).
O texto original faz parte do projeto Centro de Difusão de Tecnologia e Conhecimento, que
vem sendo realizado pelo ITI (Instituto Nacional de Tecnologia da Informação) em conjunto com
outros parceiros institucionais, atuando em conjunto com as universidades federais brasileiras
que tem produzido e utilizado Software Livre, apoiando inclusive a comunidade Free Software
junto a outras entidades no país.
Informações adicionais podem ser obtidas através do email ouvidoria@cdtc.org.br, ou da
home page da entidade, através da URL http://www.cdtc.org.br.
Garantias
O material contido nesta apostila é isento de garantias e o seu uso é de inteira responsabi-
lidade do usuário/leitor. Os autores, bem como o ITI e seus parceiros, não se responsabilizam
direta ou indiretamente por qualquer prejuízo oriundo da utilização do material aqui contido.
Licença
Copyright ©2006, Instituto Nacional de Tecnologia da Informação (cdtc@iti.gov.br) .
Permission is granted to copy, distribute and/or modify this document under the terms
of the GNU Free Documentation License, Version 1.1 or any later version published by
the Free Software Foundation; with the Invariant Chapter being SOBRE ESSA APOS-
TILA. A copy of the license is included in the section entitled GNU Free Documentation
License.
5

Parte II
Informações Básicas
6

Sobre o CDTC
Objetivo Geral
O Projeto CDTC visa a promoção e o desenvolvimento de ações que incentivem a dissemina-
ção de soluções que utilizem padrões abertos e não proprietários de tecnologia, em proveito do
desenvolvimento social, cultural, político, tecnológico e econômico da sociedade brasileira.
Objetivo Específico
Auxiliar o Governo Federal na implantação do plano nacional de software não-proprietário e
de código fonte aberto, identificando e mobilizando grupos de formadores de opinião dentre os
servidores públicos e agentes políticos da União Federal, estimulando e incentivando o mercado
nacional a adotar novos modelos de negócio da tecnologia da informação e de novos negócios
de comunicação com base em software não-proprietário e de código fonte aberto, oferecendo
treinamento específico para técnicos, profissionais de suporte e funcionários públicos usuários,
criando grupos de funcionários públicos que irão treinar outros funcionários públicos e atuar como
incentivadores e defensores de produtos de software não proprietários e código fonte aberto, ofe-
recendo conteúdo técnico on-line para serviços de suporte, ferramentas para desenvolvimento de
produtos de software não proprietários e de seu código fonte livre, articulando redes de terceiros
(dentro e fora do governo) fornecedoras de educação, pesquisa, desenvolvimento e teste de pro-
dutos de software livre.
Guia do aluno
Neste guia, você terá reunidas uma série de informações importantes para que você comece
seu curso. São elas:
• Licenças para cópia de material disponível
• Os 10 mandamentos do aluno de Educação a Distância
• Como participar dos foruns e da wikipédia
• Primeiros passos
É muito importante que você entre em contato com TODAS estas informações, seguindo o
roteiro acima.
Licença
Copyright ©2006, Instituto Nacional de Tecnologia da Informação (cdtc@iti.gov.br).
7

É dada permissão para copiar, distribuir e/ou modiﬁcar este documento sob os termos
da Licença de Documentação Livre GNU, Versão 1.1 ou qualquer versão posterior
públicada pela Free Software Foundation; com o Capitulo Invariante SOBRE ESSA
APOSTILA. Uma cópia da licença está inclusa na seção entitulada "Licença de Docu-
mentação Livre GNU".
Os 10 mandamentos do aluno de educação online
• 1. Acesso à Internet: ter endereço eletrônico, um provedor e um equipamento adequado é
pré-requisito para a participação nos cursos a distância.
• 2. Habilidade e disposição para operar programas: ter conhecimentos básicos de Informá-
tica é necessário para poder executar as tarefas.
• 3. Vontade para aprender colaborativamente: interagir, ser participativo no ensino a distân-
cia conta muitos pontos, pois irá colaborar para o processo ensino-aprendizagem pessoal,
dos colegas e dos professores.
• 4. Comportamentos compatíveis com a etiqueta: mostrar-se interessado em conhecer seus
colegas de turma respeitando-os e fazendo ser respeitado pelo mesmo.
• 5. Organização pessoal: planejar e organizar tudo é fundamental para facilitar a sua revisão
e a sua recuperação de materiais.
• 6. Vontade para realizar as atividades no tempo correto: anotar todas as suas obrigações e
realizá-las em tempo real.
• 7. Curiosidade e abertura para inovações: aceitar novas idéias e inovar sempre.
• 8. Flexibilidade e adaptação: requisitos necessário à mudança tecnológica, aprendizagens
e descobertas.
• 9. Objetividade em sua comunicação: comunicar-se de forma clara, breve e transparente é
ponto - chave na comunicação pela Internet.
• 10. Responsabilidade: ser responsável por seu próprio aprendizado. O ambiente virtual não
controla a sua dedicação, mas reﬂete os resultados do seu esforço e da sua colaboração.
Como participar dos fóruns e Wikipédia
Você tem um problema e precisa de ajuda?
Podemos te ajudar de 2 formas:
A primeira é o uso dos fóruns de notícias e de dúvidas gerais que se distinguem pelo uso:
. O fórum de notícias tem por objetivo disponibilizar um meio de acesso rápido a informações
que sejam pertinentes ao curso (avisos, notícias). As mensagens postadas nele são enviadas a
8

todos participantes. Assim, se o monitor ou algum outro participante tiver uma informação que
interesse ao grupo, favor postá-la aqui.
Porém, se o que você deseja é resolver alguma dúvida ou discutir algum tópico específico do
curso. É recomendado que você faça uso do Forum de dúvidas gerais que lhe dá recursos mais
efetivos para esta prática.
. O fórum de dúvidas gerais tem por objetivo disponibilizar um meio fácil, rápido e interativo
para solucionar suas dúvidas e trocar experiências. As mensagens postadas nele são enviadas
a todos participantes do curso. Assim, fica muito mais fácil obter respostas, já que todos podem
ajudar.
Se você receber uma mensagem com algum tópico que saiba responder, não se preocupe com a
formalização ou a gramática. Responda! E não se esqueça de que antes de abrir um novo tópico
é recomendável ver se a sua pergunta já foi feita por outro participante.
A segunda forma se dá pelas Wikis:
. Uma wiki é uma página web que pode ser editada colaborativamente, ou seja, qualquer par-
ticipante pode inserir, editar, apagar textos. As versões antigas vão sendo arquivadas e podem
ser recuperadas a qualquer momento que um dos participantes o desejar. Assim, ela oferece um
ótimo suporte a processos de aprendizagem colaborativa. A maior wiki na web é o site "Wikipé-
dia", uma experiência grandiosa de construção de uma enciclopédia de forma colaborativa, por
pessoas de todas as partes do mundo. Acesse-a em português pelos links:
• Página principal da Wiki - http://pt.wikipedia.org/wiki/
Agradecemos antecipadamente a sua colaboração com a aprendizagem do grupo!
Primeiros Passos
Para uma melhor aprendizagem é recomendável que você siga os seguintes passos:
• Ler o Plano de Ensino e entender a que seu curso se dispõe a ensinar;
• Ler a Ambientação do Moodle para aprender a navegar neste ambiente e se utilizar das
ferramentas básicas do mesmo;
• Entrar nas lições seguindo a seqüência descrita no Plano de Ensino;
• Qualquer dúvida, reporte ao Fórum de Dúvidas Gerais.
Perfil do Tutor
Segue-se uma descrição do tutor ideal, baseada no feedback de alunos e de tutores.
O tutor ideal é um modelo de excelência: é consistente, justo e profissional nos respectivos
valores e atitudes, incentiva mas é honesto, imparcial, amável, positivo, respeitador, aceita as
idéias dos estudantes, é paciente, pessoal, tolerante, apreciativo, compreensivo e pronto a ajudar.
9

A classificação por um tutor desta natureza proporciona o melhor feedback possível, é crucial, e,
para a maior parte dos alunos, constitui o ponto central do processo de aprendizagem.’ Este tutor
ou instrutor:
• fornece explicações claras acerca do que ele espera, e do estilo de classificação que irá
utilizar;
• gosta que lhe façam perguntas adicionais;
• identifica as nossas falhas, mas corrige-as amavelmente’, diz um estudante, ’e explica por-
que motivo a classificação foi ou não foi atribuída’;
• tece comentários completos e construtivos, mas de forma agradável (em contraste com um
reparo de um estudante: ’os comentários deixam-nos com uma sensação de crítica, de
ameaça e de nervossismo’)
• dá uma ajuda complementar para encorajar um estudante em dificuldade;
• esclarece pontos que não foram entendidos, ou corretamente aprendidos anteriormente;
• ajuda o estudante a alcançar os seus objetivos;
• é flexível quando necessário;
• mostra um interesse genuíno em motivar os alunos (mesmo os principiantes e, por isso,
talvez numa fase menos interessante para o tutor);
• escreve todas as correções de forma legível e com um nível de pormenorização adequado;
• acima de tudo, devolve os trabalhos rapidamente;
10

Capítulo 1
LDAP
LDAP é um serviço totalmente desenvolvido sobre tcp/ip que funciona como um banco de
dados que armazena informações em uma estrutura hierárquica (em árvore) de diretórios. Sua
funcionalidade se adequa a um número enorme de acessos por dia e a uma quantidade pequena
de gravações/atualizações pelo mesmo tempo. O LDAP oferece a possibilidade de uma uniﬁca-
ção generalizada, dos processos de autenticação e de armazenamento de dados pessoais, entre
diferentes plataformas e backends.
12

Capítulo 2
Plano de ensino
2.1 Objetivo
Introduzir, com uma base sólida, técnicos em GNU/Linux à administração de um servidor
LDAP simples.
2.2 Público Alvo
Técnicos e administradores GNU/Linux interessados em compreender de forma cuidosa o
funcionamento básico do LDAP, mas que ainda não sejam propriamente administradores de ser-
vidores LDAP.
2.3 Pré-requisitos
Os interessados deverão, necessariamente, ter familiaridade com o sistema GNU/Linux como
um todo e saber, portanto, realizar as tarefas de usuário regular pela linha de comando. Conhe-
cimento básico de redes pode ser também interessante.
2.4 Descrição
O curso de LDAP aborda os conceitos envolvidos no entendimento e na manutenção de seu
serviço e apresenta os passos para se realizar a instalação do OpenLDAP. As ferramentas de
gerenciamento do banco são apresentadas com exemplos de forma que aqueles interessados em
continuar os estudos sobre o LDAP possam ter no curso uma base sólida para implementações
reais de um servidor LDAP. Não são mostrados, portanto, na atual versão do curso, estudos de
caso de como se procederia para integrar o LDAP aos demais serviços de uma rede típica, mas o
curso se preocupa em iniciar no assunto clara e cuidadosamente, prática e teoricamente, técnicos
que desconheçam ou até tenham medo do LDAP.
2.5 Metodologia
Todo o material está no formato de lições, sendo que cada uma dispõe de um texto explicativo
e uma ou mais perguntas para acompanhar panoramicamente a leitura dos participantes. Ao ﬁnal
13

do curso um questionário será apresentado para que se faça uma avaliação do aprendizado de
cada um. Aconselhamos a leitura de "Ambientação do Moodle"para aquelas pessoas que não
tenham nenhum familiaridade com o que seja nem o Moodle nem o que seja ensino à distância.
2.6 Cronograma
Duração Descrição do Módulo
1 semana Lição 1 - Introdução
Lição 2 - Primeiros conceitos
Lição 3 - Estrutura de diretórios LDAP
Lição 4 - Instalação
2 semana Lição 5 - Teoria LDAP
Lição 6 - slapd.conf : Configurando - Parte 1
Lição 7 - slapd.conf : Configurando - Parte 2
Lição 8 - slapd.conf : Indexes e ACLs
3 semana Lição 9 - LDIF
Lição 10 - Ferramentas LDAP/Slapd
Lição 11 - Manipulando dados
Lição 12 - Últimas notas
Avaliação de aprendizagem
Avaliação do curso
2.7 Avaliação
Toda a avaliação será feita on-line. Tanto o resultado das lições quanto o resultado do questi-
onário final serão relevantes para a média final das notas, que por sua vez nos habilita ou não a
liberar a certificação. Para a aprovação o participante deverá obter nota maior ou igual a 6,0 na
média final.
2.8 Bibliografia
Livro LDAP system administration Gerald Carter Ed. O’reilly Copy right 2003
Apresentação de Slides CNPTIA/Embrapa VI Seminário de Capacitação Interna Daniel No-
vais Martins dnovais@correionet.com.br
Páginas:
• http://www.openldap.org/
• http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm?info/rzahy/rzahyovrco.htm
• http://www.brennan.id.au/20-Shared_Address_Book_LDAP.html
• http://en.wikipedia.org/wiki/Ldap
• http://quark.humbug.org.au/publications/ldap/ldap_tut.html
• http://www.zytrax.com/books/ldap/ch3/index.html#overview
• http://yolinux.com/TUTORIALS/LinuxTutorialLDAP-DefineObjectsAndAttributes.html#OBJECT
14

Capítulo 3
Introdução
3.1 O que é LDAP?
LDAP significa Lightweight Directory Acces Protocol, o que em português é Protocolo Leve
de Acesso a Diretório. Primeiramente, temos de saber que diretórios, para o LDAP, não são
pastas de um sistema de arquivo. Diretório foi um jargão aplicado já pelo padrão X.500 sobre o
qual o LDAP se baseia, e diz respeito, mais genericamente, a alguma maneira de estruturar um
recipiente de dados.
LDAP é um protocolo que serve e acessa dados associados a ítens determinados (dados
que são, aliás, armazenados em único registro respectivo a cada ítem), como uma pessoa, um
arquivo ou qualquer outro, armazenados logicamente em diretórios hierárquicos, como em um
sistema de arquivo.
Ou seja, o LDAP, como um servidor, armazena informações sobre seus objetos (ou ítens, que
de certa forma são análogos a arquivos) organizados em uma estrutura de continentes, isto é, em
uma estrutura de diretórios (que também podemos pensar, com fins didáticos, serem análogos a
pastas de um sistema operacional). Já o LDAP cliente acessa as informações armazenadas no
servidor segundo um pedido específico que fazemos. Hoje o LDAP está em sua terceira versão,
que iremos utilizar, e é por isso chamado de LDAPv3.
O LDAP, em linhas gerais e situantes, é um banco de dados hierárquico (e não relacional),
pois armazena dados em diretórios que se estruturam em árvore. Suas funções e capacidades
são, e isto é importante, um bocado diferentes daquelas de um banco de dados relacional. Vamos
tentar entender isso em breve.
3.2 História
O protocolo LDAP foi desenvolvido originalmente por três pessoas em 1993: Steve Killi, Tim
Howes e Wengyik Yeong. O LDAP, que, como já sabemos, funciona sobre o padrão de diretórios
X.500 melhorado, foi uma tentativa bem sucedida de ser um protocolo compativel com o DAP
e mais rápido que este. DAP, que significa Directory Access Protocol, deu origem ao LDAP,
Lightweight Directory Access Protocol - em português, protocolo leve de accesso à diretórios. As
razões da melhoria de desempenho se devem ao fato do LDAP não fazer uso do protocolo OSI,
mas constituir conexões diretas do cliente com o servidor de diretórios, antes o próprio DAP, com
os protocolos TCP/IP.
Originalmente, o que veio a ser o LDAP era chamado de LDBP: Lightweight Directory Browsing
Protocol, pois seus acessos ao servidores de diretórios só permititam a leitura de dados e não
15

também a edição destes. Com seu crescimento, o LDBP não somente passou a escrever e
editar o diretórios, sendo chamado de LDAP, mas também passou a se manter autonomamente
como servidor LDAP, se tornando uma alternativa independente do DAP, que ainda era mantido
compatível e paralelamente.
16

Capítulo 4
Primeiros conceitos
4.1 Para que podemos usar o LDAP?
O LDAP, em linhas gerais, desempenha tipicamente duas funções: a de armazenar em árvore
e disponibilizar informações sobre algum objeto, normalmente pessoas, e de realizar a auten-
ticação de usuários para frontends e aplicativos de maneira uniﬁcada. Para tanto o LDAP faz
uso do PAM com o módulo pam_ldap. Como objetos ﬁnais visados por uma árvore podemos ter
outras coisas que não pessoas como, por exemplo, arquivos ou cds que uma loja queira manter
organizados.
4.2 Que tipos de aplicativos podem utilizar LDAP?
Como o LDAP foi desenvolvido sobre TCP/IP, ele é um serviço integralmente compatível com
os usos da internet. Em tese, todos aplicativos podem acessar dados de um servidor LDAP e
atualizá-los, se tiverem as devidas permissões. A maiorida dos servidores de email tem suporte
a LDAP, ainda que, por hora, vários deles somente leiam dados mas não escrevam. O LDAP
pode autenticar usuários para um número enorme de procedimentos, desde logins Linux e até
Windows (família NT), passando por Samba até serviços POP e IMAP.
4.3 Como é o acesso ao LDAP?
O LDAP funciona segundo o modelo cliente/servidor, mas enquanto o cliente é sempre um, o
servidor deste cliente pode se dividir em várias máquinas LDAP. A lógica é simples, o cliente faz
um pedido ao servidor, que por sua vez ou retorna os dados ou repassa o pedido a uma outra
máquina que faz serviço de diretórios LDAP. Naturalmente, o(s) servidor(es) LDAP pode(m) estar
tanto na própria máquina cliente, quanto em uma rede ou na internet, como acontece na maioria
esmagadora dos casos. Em todos esses casos e especialmente no último, um único servidor
LDAP, com uma única arvore de diretórios, pode autenticar o mesmo usuário para diversos ser-
viços diferentes, ou seja, um usuário pode logar em um sistema, ler seus e-mails, logar em um
portal e ser autenticado em serviços de rede com um só login e com uma só senha armazenados
em um só servidor LDAP.
17

4.4 Como é o uso do LDAP?
O LDAP, diferentemente de um banco de dados relacional, não é preparado para ser cons-
tantemente atualizado e ter seus dados remanejados e transitando. O LDAP é principamente um
serviço de consulta, o que, obviamente, requer que dados sejam escritos de vez em quando. Por-
tanto, o LDAP sim suporta escrita e leitura de dados, mas com uma finalidade diferente daquela
de um banco de dados relacional. O LDAP, pois, suporta uma quantidade absurda de acessos
para leitura ao mesmo tempo, mas não se adequa a usos que requeiram armazenamento de
dados que devam ser freqüentemente atualizados, o que explica o uso típico de armazenamento
de informações pessoais, pois se modificam pouco.
4.5 Como são os dados do LDAP?
Cada objeto visado pelo LDAP, que a partir de então chamaremos de ítem, possui um único
registro que lista os campos com seus atributos. Cada ítem, por sua vez, é uma instância de
alguma classe de ítens (objetos) escolhida que define que informações têm que estar e que
informações podem estar listadas no registro de suas instâncias. Cada item é único e pode
ser encontrado sem ambiguidades por conta da estrutura arbórea padrão dos diretórios LDAP.
Todos servidores LDAP, portanto, são estruturados segundo um mesmo princípio de continentes e
conteúdos, que será esclarecido mais tarde, que torna seus dados intercambiáveis. Haver vários
frontends que suportam LDAP e que são capazes de descrever um caminho completo a um ítem
requer um padrão de estrutura de diretórios. Podemos, enfim, referenciar um item específico e
pedir o retorno de seus dados ou parte destes passando ao servidor o caminho completo através
da árvore até o ítem visado. Podemos também, como vamos ver, fazer referência não a um
ítem, mas a um ramo inteiro de dados da árvore, cobrindo todos ítens nele contidos. Uma árvore
de diretórios LDAP é também chamada de DIT, Directory Information Tree. Um mesmo servidor
LDAP pode, inclusive, suportar mais de uma árvore.
4.6 Quem tem acesso aos dados?
A organização de diretórios do LDAP permite que sejam setadas permissões personalizadas
de acesso tanto para leitura quanto para escrita a ramos inteiros de uma árvore de dados ou a
diretórios específicos, restringindo o acesso de quaisquer usuários ou grupos destes. O LDAP,
pois, em certo sentido também autentica a si mesmo o acesso de usuários.
4.7 Conceitos e convenções
Antes de aprendermos algumas das palavras-chave do LDAP e entender sua estrutura de da-
dos, vamos expor algumas noções importantes a um sistema LDAP e ao mesmo tempo estipular
os nomes que daremos a elas. O importante é que fiquemos familiarizados com a nomenclatura
em geral e que tenhamos uma visão panorâmica de tudo aquilo sobre o que vamos falar daqui
em diante. Não é preciso que se domine todos os conceitos agora, pois vamos estudar aqueles
ainda não apresentados um a um posteriormente.
• Árvore LDAP ou de dados é a estrutura hierárquica de dados do LDAP;
18

• A raiz ou tronco é o primeiro e maior diretório de uma árvore de dados;
• Um diretório é um ramo da árvore que contém outros diretórios ou ítens;
• Um ítem é aquilo que é visado pela árvore, aquilo que os diretórios tentam organizar;
• Categorias do LDAP são os tipos de diretórios e de ítens, nomeados pelas palavras especi-
ais;
• Registro é o conjunto de atributos de um ítem;
• Atributos são as propriedades (nome e valor(es)) associadas a um determinado ítem;
• Os atributos (necessários e possíveis) de um ítem são designados por esquemas;
• Esquemas constituem classes ou tipos de ítens, que são suas instâncias.
19

Capítulo 5
Estrutura de diretórios LDAP
5.1 Noções gerais
A estrutura de diretórios do LDAP é baseada em um conjunto de tipos, que designam papéis
e posições diferenciadas para cada diretório e significam referências a um item ou a um ramo
da árvore. Ou seja, o LDAP possui algumas palavras reservadas, digamos assim, que são utili-
zadas para designar uma estrutura ou um caminho através da árvore; sem alguma coisa como
essas palavras, e vamos conhecer a solução desenvolvida, não poderíamos fazer referência a
um determinado ponto da árvore sem apontar graficamente para ela.
Sem ainda nos preocuparmos em decorar ou entender os nomes, eis uma lista das palavras
mais importantes que constituem uma estrutura típica de diretórios:
• c - Country (País)
• o - Organizational Name (Nome Organizacional)
• ou - Organizational Unit Name (Nome da Unidade Organizacional)
• dn - Distinguished Name (Nome Distinto)
• rdn - Relative Distinuished Name (Nome Distinto Relativo)
• dc - Domain Component (Componente de Domínio)
As palavras que se seguem são algumas das utilizadas em árvores que possuem pessoas,
pelo menos, como itens. Existem muitos outros nomes que constituem regularmente uma estru-
tura de diretórios LDAP, mas, tendo em vista as considerações feitas, estes são os únicos que
nos interessarão por hora:
• cn - Common Name (Nome Comum)
• uid - User Identification (Identificação de Usuário)
• oid - Object Identifier (Identificador de Objeto)
• cu - Common User (Usuário Comum)
• st - State (Estado)
20

5.2 * Country
Como o LDAP precisa de uma estrutura padrão que sirva universalmente para intercambiar
dados e links para que seja um serviço unificante, decidiu-se considerar o país como o ramo de
nível mais alto, a partir do qual saem todos outros ramos e antes do qual não há nada. São como
que o tronco da árvore de diretórios. Os códigos utilizados para designar os países são, não por
acaso, os mesmos utilizados na estrutura de domínios da internet.
No caso do Brasil, a designação de valor a ’c’ seria:
c=BR
5.3 * Organizational Name
Esta categoria diz respeito às maiores subdivisões de um país presentes na árvore. Em
outras palavras, são os primeiros galhos que saem do tronco do país. Podemos imaginar os
valores de ’o’, pois, como sendo por exemplo alguma coisa como ’governo’, ’empresas’, ou ’civil’,
’financeiro’, ’publico’, ’universidades ou até mesmo ’unb’, mas provavelmente não cdtc. Outros
’o’s, no entanto, podem e costumam seguir um primeiro ’o’, o que talvez levasse ’cdtc’ a poder ser
um valor razoável de um ’o’.
o=cdtc
5.4 * Organizational Unit Name
Esta categoria constitui as partes analisadas de um único ramo organizacional, podendo dizer
respeito a ’unb’ como uma unidade da organização ’universidades’, por exemplo. Uma ’ou’ pode
estar contida em outra ’ou’, assim como acontece com as ’o’.
ou=estagiarios
5.5 * User Identification
Este atributo faz parte de qualquer tipo de item relativo a pessoa e a identifica unicamente em
seu diretório. Igualmente, a identificação de usuário é uma palavra contingente (é um atributo)
que não estaria presente na descrição de um ítem que fosse um disco de música.
uid=tomasrc
5.6 * Distinguished Name
O nome distinto é o "nome"com que apontamos para um único ítem específico. Este nome é,
na verdade, a descrição completa do caminho da árvore que leva ao ítem referido. Por isso o DN é
composto dos componentes do caminho separados por vírgulas, sendo os primeiros diretórios e o
último um atributo que identifique o ítem em questão (que constitui um R(elative)DN), tipicamente
o CN ou o UID, quando o ítem é uma pessoa. O DN, sintaticamente, é uma lista de categorias e
de seus valores ligados pelo sinal de igualdade, sendo os componentes separados por vírgulas.
Um exemplo de DN poderia ser:
21

dn="uid=tomas, ou=estagiarios, o=iti, c=BR"
5.7 * Relative Distinguished Name
O nome distinto relativo é o primeiro componente de um DN, ou seja, em geral o identiﬁcador
do item em questão. No exemplo de DN acima, o RDN seria "uid=tomas". O RDN deve ser capaz
de apontar para um único item dentro do componente seguinte listado no DN. O RDN deve ser
algum atributo do item, mas não necessariamente um atributo cujo valor seja exclusivo do item
visado, inclusive porque não há como evitar que o mesmo atributo de itens diferentes mantenham
o mesmo valor. Nesse caso, para acabar com a ambiguidade, um RDN pode apresentar mais de
um valor separados por um sinal "+". Exemplo de DN cujo RDN ("uid=tomas+ou=suporte") possui
mais de um valor:
dn="uid=tomas+ou=suporte, ou=estagiarios, o=iti, c=BR"
5.8 * Domain Component
O Nome de Domínio diz respeito ao domínio web relativo a um ramo da árvore ou à árvore
toda. No caso, o nome do domínio onde se encontra a pessoa de uid ’tomas’ é o ’iti.br’. Esse
domínio possui dois componentes de domínio, ’iti’ e ’br’, logo:
dc=iti, dc=br
Podemos, desta forma, fazer referência a um ítem, ou seja, um DN, fazendo uso do domínio
através da listagem de seus componentes de domínio, por exemplo:
dn="uid=tomas, ou=estagiarios, dc=iti, dc=br"
Não é necessário que se domíne o uso do domínio no LDAP à primeira vista, ao longo das
lições ele se tornará mais claro.
22

5.9 Exemplo gráﬁco de uma árvore LDAP
23

Capítulo 6
Instalação
6.1 Pacotes e serviços utilizados
Para implementar o LDAPv3, utilizaremos o OpenLDAP (www.openldap.org), lançado com
uma licensa própria compatível com a GPL. No momento em que este texto foi escrito, a versão
mais recente do OpenLDAP era 2.3.25. Para baixá-la, podemos acessar "www.openldap.org/software/downloa
Além do próprio OpenLDAP, serão necessários:
1. 1. Um gerenciador de banco de dados, que no caso será o Berkeley DB. O código fonte do
Berkeley DB (bdb) pode ser baixado de "www.sleepycat.com/download.html".
2. 2. SSL/TLS funcionando para criptografar sessões que precisem ser seguras. Procurem o
código fonte mais recente em "www.openssl.org/source".
6.2 BerkleyDB
A versão utilizada aqui do bdb será a 4.4.20, com um pouco mais de 7mb, baixada em
ftp://ftp.sleepycat.com/releases/db-4.4.20.tar.gz. Para instalar os componentes necessários e
posteriormente o OpenLDAP, obtenha um terminal como root.
Para instalar o bdb em seu sistema, primeiramente extraia o código em /usr/local/src, que é
diretório escolhido para o exemplo de instalação. Para tanto, com o código em /root digite os
seguintes comandos:
$ cd /usr/local/src
$ gzip -dc /db-4.4.20.tar.gz | tar xvf - (adapte o comando para a versão baixada)
Observe que dentro do diretório criado, /usr/local/src/db-4.4.20 existe uma pasta chamada docs
com uma documentação geral sobre o Berkeley DB. Para realizar a instalação, acesse o diretório
mencionado, /usr/local/src/db-4.4.20, entre em build_unix. O comando para tanto é:
$ cd db-4.4.20/build_unix (adapte o comando para a versão baixada)
Enfim digite os seguintes comandos:
$ ../dist/configure –prefix=/usr/local
24

$ make
$ make install
6.3 SSL/TSL
O código fonte do OpenSSL mais recente no momento em que este texto foi escrito foi baixado
de http://www.openssl.org/source/openssl-0.9.8b.tar.gz. Procure em www.openssl.org/source uma
versão mais recente. Com um terminal acessado com uma conta root, leve o código fonte baixado
até a pasta /root. A partir daqui, digite os comandos:
$ cd /usr/local/src
$ gzip -dc /openssl-0.9.8b.tar.gz | tar xvf - (adapte o comando para a versão baixada)
E, para, instalar:
$ cd openssl-0.9.8b (adapte o comando para a versão baixada)
$ ./config shared –openssldir=/usr/local
$ make
$ make install
6.4 OpenLDAP
Enfim vamos instalar o que nos interessa. Para baixar o OpenLDAP e instalá-lo digitem (nada
impede que procurem um versão mais nova no diretório em que se encontra o arquivo que indico
abaixo; neste caso adeque os comandos para a versão que for usar):
$ wget ftp://ftp.matrix.com.br/pub/openldap/openldap-release/openldap-2.3.30.tgz
$ gunzip -c openldap-2.3.30.tgz | tar xvfB -
$ cd openldap-2.3.30
$ ./configure
(digite "./configure –help"para ver as opções do configure, e caso tenha problemas nesta etapa
experimente ler as indicações desta página.)
$ make depend
$ make
$ make test
$ su root -c ’make install’
25

6.5 Um pouco sobre os arquivos
Acessem o diretório /usr/local. Nele estão contidos diversos arquivos que fazem parte da
instalação do OpenLDAP. Dentro da subpasta bin existem alguns utilitários como o ldapsearch, o
ldapcompare, e ldappasswd. Eles servem respectivamente para procurar e comparar atributos de
ítens de um diretório Ldap e o último serve para altera o atributo password de ítens do Ldap. Além
deste existem na subpasta bin os três comandos ldapadd, ldapmodify e ldapdelete, que criam,
modificam e deletam ítens de um diretório Ldap, respectivamente.
Já na subpasta sbin existem os comandos slapadd, o slapcat e o slappasswd, entre outros,
que servem para alterar dados do servidor Ldap. O slappasswd, em particular, que talvez venha-
mos usar, gera hash de senhas para ser utilizado no slapd.conf. O slapd, o daemon do OpenL-
DAP, fica na subpasta libexec juntamente com o slurpd, o daemon de replicação do OpenLDAP.
Acessem agora o diretório /etc/ldap. Nele ficam os arquivos de configuração que mais nos
interessam. O ldap.conf, que pouco vamos conhecer neste curso, é prioritariamente responsável
pelas ferramentas utilizadas pelo lado do cliente, como aquelas mencionadas que residem no
diretório /usr/local/bin. O slapd.conf vai estará mais sob o nosso foco, pois as informações nele
contidas dizem respeito ao daemon slapd ele mesmo, e configurá-lo corretamente é fundamental.
A pasta schema faz parte do diretório /etc/ldap, e nele estão contidas as definições dos es-
quemas disponíveis, guardadas em arquivos .schema.
26

Capítulo 7
Teoria LDAP
7.1 Algumas apresentações
Basicamente, esquemas são um conjunto de regras que regulam que tipos de dados poderão
ser armazenados no registro de um item. Semelhantemente à declaração do tipo de uma variável
em programação com tipos, a especificação do esquema que um ítem implementa determina
que atributos ele deve e pode ter. Por exemplo, um ítem relativo a uma pessoa deve ser a
implementação de um esquema para pessoas, o que vai exigir dele que tenha um atributo de
nome e permitir que tenha, se vier ao caso, um atributo de telefone ou de endereço.
Visto a necessidade de que os ítens em um diretório LDAP sejam sempre implementados por
um esquema, temos que existe pelo menos um atributo que todos ítens têm de ter: o atributo
"objectClass"(Classe de objeto). O atributo objectClass de um dado ítem i define o esquema que
do qual o ítem i é um caso. Um atributo pode ter, entretanto, mais de um objectClass, fazendo
parte de mais de um esquema.
Todo atributo ou objectClass utilizado em uma implementação LDAP deve estar definido em
um esquema. Para que o servidor LDAP reconheça a classe, por sua vez, o slapd.conf deve estar
bem configurado.
Uma implementação do LDAP deve ter ao menos um objectClass necessariamente, caso
contrário não se poderia definir quaisquer ítens. O objectClass, em certo sentido, contém os
outros atributos.
Como já dizia, todos aqueles nomes apresentados como sendo palavras especiais do LDAP
são, na verdade, atributos pertencentes a e definidos por alguma objectClass. Cada atributo
pertence a pelo menos um objectClass, mas pode pertencer a mais. E são esses atributos
aquilo que vai guardar o que queremos, os dados. E novamente as coisas ficam um pouco mais
complicadas para depois se tornarem óbvias.
7.2 ObjectClass: funcionamento
Características Uma objectClass é como uma coleção de (nomes de) atributos. Como dizia,
todo ítem possui um "atributo"objectClass que define suas características, associando-o a uma
classes, e um ítem pode ter mais de um objectClass, associando-se a mais de uma classe.
Naturalmente, para que um ítem possa se associar a uma classe desta forma, as objectClass
têm necessariamente de ter nomes únicos. Vamos entender adiante que tipo de responsabilidade
as objectClass têm para com um ítem, dado que ela administra seus outros atributos, e como o
27

LDAP faz para genrenciar as várias e tantas possibilidades de implementações de classes, que é
através da herança.
Note que um esquema pode ser derivado de outro, como classes em orientação a objetos.
Um esquema que se deriva de outro possui todas as especificações de atributos do esquema
dos qual se deriva, mais suas prórprias especificações, que podem eventualmente sobrepor as
derivadas. Um oblectClass faz em geral, pois, parte de uma hierarquia de objectClasses, que são
modulares nesse sentido, e que apontam para uma única definição abstrata, a classe top. Por
exemplo, inetOrgPerson herda as definições de organizationalPerson que herda suas definições
de person que herda as suas de top, o todo das hierarquias de objectClass. O recurso de herança
de especificações de esquemas ajuda-nos a evitar a redundância de declarações, tornando o
trabalho com LDAP mais inteligente. Definindo variáveis e seu status As objectClass, que são
definidas dentro das classes, são responsáveis por definir o status de seus atributos para com os
seus ítens. Ou seja, é na sua definição que vai estar descrito que aributos são permitidos e que
atributos são necessários aos ítens que quiserem instanciar uma classe. Um objectClass pode
possuir as seguintes informações:
1. 1. Atributos requeridos para o ítem (MUST);
2. 2. Atributos permitidos ao ítem (MAY);
3. 3. Padrões de comparação;
4. 4. Tipos de valores (inteiros, reais, strings);
5. 5. Controle de duplicação e outros controles;
6. 6. Seu esquema pai (SUP).
Uma definição Uma objectClass é definida em arquivos terminados em ’.schema’. Esquemas
podem ser entendidos, basicamente, como conjuntos de definições de objectClasses. Talvez não
se lembrem das notas sobre a instalação, mas os arquivos de extenção ’.schema’ ficam todos no
diretório ’/etc/ldap/schema’. Bom, entremos no diretório ’schema’. Notem que nele existem al-
guns esquemas básicos disponíveis por padrão, como o ’inetorgperson.schema’ e ’core.schema’.
Note também a presença de um README. Nele estão descritos brevemente os esquemas já
contidos no diretório e a indicação de como proceder caso queiramos autenticar e disponibilizar
um esquema novo que tenhamos definido adquirindo os nossos identificadores de objetos LDAP
(OIDs).
Abra agora um esquema como o ’inetorgperson.schema’ com qualquer editor. O início dos
arquivos .schema tipicamente explica o propósito do esquema, e fornece algumas informações
importantes como dependências (no caso de haver herança de definições, o que é comum, por
ser útil e aconselhável), algumas indicações de uso e de versões e dados relativos ao autor ou
a autora e endereços da internet. Rolem o texto do arquivo até o seu final. Note suas últimas
dezoito linhas. Se quiser, digite na linha de comando ’cd /etc/ldap/schema; clear; tail -n 18 ine-
torgperson.schema’ para visualizar exatamente as linhas de que estou falando.
# inetOrgPerson
# The inetOrgPerson represents people who are associated with an
# organization in some way. It is a structural class and is derived
# from the organizationalPerson which is defined in X.521 [X521].
NAME ’inetOrgPerson’
28

DESC ’RFC2798: Internet Organizational Person’
SUP organizationalPerson
STRUCTURAL
MAY (
audio $ businessCategory $ carLicense $ departmentNumber $
displayName $ employeeNumber $ employeeType $ givenName $
homePhone $ homePostalAddress $ initials $ jpegPhoto $
labeledURI $ mail $ manager $ mobile $ o $ pager $
photo $ roomNumber $ secretary $ uid $ userCertificate $
x500uniqueIdentifier $ preferredLanguage $
userSMIMECertificate $ userPKCS12 )
7.3 Atributos
Os atributos são como variáveis que armazenam os dados propriamente ditos. Os atributos
são sempre associados a ítens, e um ou mais atributos em um mesmo nível hierárquico deve(m)
ser capaz(es) de individuar um único ítem. Ou seja, em outras palavras, dois ítens em um mesmo
nível de hierarquia na árvore não podem ter exatamente os mesmos atributos contendo os mes-
mos valores.
Como sabemos, um ítem é como uma instância de uma determinada classe de objetos, que
definirá que atributos poderão e terão de fazer parte do ítem instanciado.
Para que qualquer atributo seja reconhecido, e, logo, para que seja parte de um dado ítem/objeto,
portanto, ele deve ser descrito em uma classe de objetos, uma objectClass, que deve também
ser um atributo do mesmo ítem/objeto. Lembrando que uma objectClass é também um atributo,
ainda que bem especial. Conclui-se que se um ítem tem que ter atributos, quaisquer que sejam,
para ser individuável, ele deve ter ao menos um atributo - o objectClass.
A definição dos atributos determinam que eles tenham, assim como em algumas linguagens
programações, um tipo. Ou seja, um atributo destinado a guardar números de telefone, por
exemplo, pode esperar receber dados em forma de números, e não em letras, strings. A definição
dos atributos também pode informar como os atributos respondem às buscas, permitindo buscas
sem consideração de caso, por exemplo.
Os atributos também herdam definições, como as definições de classes.
Uma definição de atributo
Ainda com o ’inetorgperson.schema’ aberto, dêem uma olhada nas primeiras linhas desco-
mentadas do arquivo. Elas se tratam da definição do atributo ’carLicense’, um atributo destinado
a armazenar o número de identificação da licença de motorista de uma pessoa. Note que esse
atributo não estaria definido em um esquema que não servisse a objetos do tipo ’pessoa’.
# carLicense
# This multivalued field is used to record the values of the license or
# registration plate associated with an individual.
attributetype ( 2.16.840.1.113730.3.1.1
NAME ’carLicense’
DESC ’RFC2798: vehicle license or registration plate’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
29

Explicação
O que pode não ser evidente aqui é a aplicação tanto de EQUALITY quanto de SUBSTR e de
SYNTAX. NAME, DESC têm funções bastante auto-evidentes. EQUALITY, SUBSTR e SYNTAX
servem à função de especificar como o atributo deve reagir em comparações de valores quando
um cliente estiver realizando uma busca por dados no diretório LDAP.
EQUALITY e SUBSTR ambos são responsáveis por indicar as regras que devem ser aplicadas
nas comparações. A diferença entre EQUALITY e SUBSTR é que a primeira somente pode
indicar regras que não contenham wildcards (caracteres especiais de expansão como ?, ., *). A
consequência dessa simples condição é que o o tamanho das strings comparadas será o mesmo.
Para fazermos uso de regras que utilizem wildcards, devemos fazer uso da palavra SUBSTR.
Existe também a palavra ORDERING, que serve para definir uma regra que contenha os
operadores >= ou <=.
Por último, SYNTAX indica que as regras apontadas operam segundo as definições identifica-
das pelo OID (identificador de objeto) dado.
Alguns nomes de regras de comparação
• objectIdentifierMatch
• caseIgnoreMatch
• booleanMatch
• uniqueMemberMatch
• caseExactSubstringsMatch
• distinguishedNameMatch
• telephoneNumberMatch
• integerBitOrMatch
• caseIgnoreMatch
30

Capítulo 8
slapd.conf : Configurando - Parte 1
8.1 Introdução ao slapd.conf
Como já sabemos, o slapd.conf é o arquivo que configura os aplicativos do lado do servidor
do ldap, como o slapd e o slurpd, entre outros como o slapcat, por exemplo. Para poder editá-lo,
devemos conhecer ao menos suas três regras básicas de interpretação. Como sabemos, todo
arquivo de configuração possui algumas regras que permitem, por exemplo, que comentemos as
nossas linhas. Devemos pois, saber que:
• * Linhas em branco são desconsideradas;
• * Linhas inciadas com ’ # ’ são desconsideradas;
• * Linhas inicadas com um espaço em branco são consideradas continuação da linha ante-
rior.
• * Se um argumento, como o valor de uma atribuição, possuir um espaço em branco, ele
deve ser contido dentro de aspas duplas.
• * Se um argumento contiver aspas duplas, estas devem ser precedidas com o caractere de
escape padrão .
• * Se um próprio argumento possuir o caractere barra invertida , este deve ser precedido
por outra barra invertida de escape .
A maior parte do slapd.conf especifica alguns parâmetros que vão reger o comportamento
geral do servidor, já o restante, ao final, diz respeito ao banco de dados utilizado, no nosso caso
o dbd.
8.2 Esquemas - parte 1
O primeiro passo para editarmos o slapd.conf é decidirmos e setarmos os esquemas que
serão utilizados pelo nosso serviço. Essa pergunta também poderia ser feita com "que tipo de
ítens queremos armazenar em nosso diretório?"Com ’tipo de ítens’ não digo ’tipo de dados’,
o que sugeriria uma decisão sobre se queremos armazenar valores numéricos ou strings, por
exemplo. Na verdade a pergunta está mais para se queremos armazenar informações sobre
pessoas ou sobre objetos abstratos, e no caso de ser pessoa, por exemplo, em contexto nosso
31

diretório as enxergará. Elas serão pessoas como vistas do ponto de vista do Estado, ou como
vistas por um portal da web? Uma maneira de chegar a uma resposta objetiva é ter em mente,
se já soubermos, os aplicativos irão fazer uso do nosso serviço, já que conhecê-los nos permite
saber em que informações ele pode estar interessado ou mesmo que dados exatamente ele pode
solicitar.
Como já sabemos, as definições de esquemas são guardadas por padrão no subdiretório
/etc/ldap/schema. O arquivo core.schema possui as definições de classes de objetos (object-
classes) básicas que os esquemas mais elaborados herdam. Boa parte das classes de objetos
que um diretório LDAP vai querer utilizar vai estar definida no próprio core.schema, mas é claro
que podemos aproveitar esquemas já maduros para instanciar classes de objetos mais persona-
lizadas. Existem diversos esquemas já publicados que provavelmente satisfariam a maioria dos
diretórios LDAP, nos eximindo da necessidade de definirmos nossas próprias classes.
Para que decidam sobre que esquemas implementar, naveguem por cada um dos arquivos
existentes no diretório schema e notem as classes de objetos que cada um oferece tendo em
vista os objetivos do diretório LDAP que deseja levantar. Essa é também simplesmente a me-
lhor maneira que há de nos familiarizarmos com a estrutura e a sintaxe da diretivas e com os
conteúdos existentes em nas definições de um esquema.
8.3 Esquemas - parte 2
Uma implementação do LDAP reconhece os esquemas aos quais deve dar suporte procu-
rando por chamadas de ’includes’ dentro do slapd.conf. Essas linhas ficam já no início do
slapd.conf, e observe como, por padrão, o nosso arquivo de configuração já inclui alguns es-
quemas predefinidos, alguns daqueles que encontramos no diretório schema.
#######Recorte do meu slapd.conf padrão, da linha 12 à 18#######
# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
################################################################
Provavelmente esses quatro esquemas são não somente suficientes para as necessidades de
algumas implementação do serviço LDAP, mas também talvez desnecessários. Caso queira ex-
cluir um esquema ou adicionar outro, leve em consideração as dependências de cada esquema
(de outros esquemas dos quais é herdeiro) retirado ou incluido, que são indicadas no início do
arquivo de suas definições. Boa parte dos esquemas, por exemplo, depende da presença do
core.schema.
32

8.4 Dois ajustes
Notem o seguinte trecho do arquivo de configuração:
# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile /var/run/slapd/slapd.pid
# List of arguments that were passed to the server
argsfile /var/run/slapd/slapd.args
Aqui, setamos como valor ao pidfile o arquivo em caminho absoluto que indicará para o sistema
o número de identificação do processo sob o qual rodará o serviço slapd. O argumento padrão é
um valor razoável.
Para argsfile atribuímos o caminho absoluto para o arquivo que possuirá a chamada pa-
drão ao slapd, já com os argumentos de linha de comando (ou parâmetros) que desejamos
que sejam passados sempre que o slapd for iniciado normalmente. Por padrão, o conteúdo
de /var/run/slapd/slapd.args é:
/usr/sbin/slapd -g openldap -u openldap
8.5 Logs
Outro conjunto de configurações que faz parte das configurações globais do slapd.conf dizem
respeito ao que deve ser logado das notificações que o serviço pode gerar.
Quanto ao que deve ser logado, existem diversos gradações de logs, ainda que a diferença
entre um nível e outro não seja de quantidade de linhas geradas. Existe uma tabela que apre-
senta as várias opções, cada qual associada a um valor numérico. Caso queiramos combinar
as opções, simplismente somamos esses valores. Como podem ter notado, o sistema lembra a
atribuição numérica de permissões a arquivos no sistema GNU/Linux.
33

-1 Todas informações
0 Nenhuma informação
1 Chamadas de funções
2 Debug de pacotes (packet-handling)
4 Debug detalhado de chamdas
8 Gerenciamento de conexões
16 Pacotes enviados e recebidos
32 Processamento de filtros de busca
64 Processamento de configurações de arquivo
128 Processamento de Access Control Lists
256 Estatísticas de conexões, operações e resultados
512 Estatísticas de resultados enviados aos clientes
1024 Comunicação com os backends do shell
2048 Análise de entries
Como o próprio slapd.conf indica, podemos ler o manual do arquivo configuração do slapd
com o comando:
$ man slapd.conf
O manual mostra, entre todas as coisas, esta tabela, que lá possui quatro linha que omiti
aqui de valores superiores a 2048. O manual possui 1235 linhas e pode ser uma ótima fonte de
consulta em caso de problemas ou de excesso de interesse sorriso
Uma possível configuração de logs poderia ser:
# 8 + 16 + 256 = 280
loglevel 280
8.6 SSL e TLS - parte 1
Vale notar que este trecho pode ser ignorado caso não se tenha preocupação com garantir
essa segurança ao usuário em sua conexão com o servidor. Mas ainda assim esta página explica
como habilitar o suporte a SSL/TLS no slapd.
O LDAP oferece alguns controles de como ele conversará com o SSL e com o TLS, para um
a referência mais completa, consultem o manual do arquivo. Para nós, neste curso, precisamos
de pelo menos duas linhas de configuração a princípio. Uma indicará ao slapd onde encontrar
o arquivo com o certificado do servidor e outra para apontar à chave privada associada ao certi-
ficado. Mas para incluir as duas linhas devemos antes possuir um certificado, e é o que vamos
fazer agora.
Para gerá-lo vamos utilizar uma ferramenta em perl que funciona como uma ’interface’ para se
conversar de forma amigável com o OpenSSL. Procure por CA.pl, que pode estar em /usr/lib/ssl/misc/CA.pl
ou mesmo em /usr/local/misc/CA.pl, dependendo de como resolveu sua instalação. De qualquer
maneira, o procedimento é como o seguinte:
$ cd /usr/lib/ssl/misc ou $ cd /usr/local/misc/
$ ./CA.pl -newcert
34

Informe uma senha e confirme. Em seguida ele pedirá alguns dados para associá-los ao cer-
tificado a ser gerado, como seu nome, estado e país.
Um arquivo chamado newkey.pem é gerado, e este é a chave privada que devemos guardar
com muito cuidado. O certificado foi gerado com o nome de newcert.pem. Em sequência vamos
retirar a senha de dentro do arquivo da chave privada para que o slapd possa acessá-la.
$ openssl rsa -in newkey -out slapd-private-key.pem
Informe a senha que setou a pouco para a chave e um arquivo de nome slapd-private-key.pem
deve estar visível. Altere sua permissão para leitura e escrita exclusiva do administrador.
Por fim delete o arquivo da chave privada original e renomeie o arquivo do certificado. Vamos
criar uma pasta com nosso certificado e com a chave para mantê-los organizados.
$ rm newkey.pem
$ mv newcert.pem slapd-certificate.pem
$ mkdir /etc/ldap/certs
$ mv slapd-certificate.pem slapd-private-key.pem /etc/ldap/certs/
Agora vamos incluir as linhas de que falávamos no slapd.conf.
#Opções de TLS:
TLSCertificateFile /etc/ldap/certs/slapd-certificate.pem
TLSCertificateKeyFile /etc/ldap/certs/slapd-private-key.pem
Adicionemos uma outra linha que promove nossa segurança.
TLSCipherSuite HIGH
8.9 Algumas variáveis relativas à segurança
Sete no início do arquivo ou em qualquer região separada as seguintes variáveis:
security ssf
35

require none
allow bind_v2
password-hash SSHA
Essa configuração acima é básica e certamente não é a melhor seleção do ponto de vista da
segurança, caso fossemos armazenar dados de máxima importância. Neste caso recomendo
que pesquisem sobre como utilizar o LDAP juntamente com o SASL. Nesse caso algumas linhas
deveriam ser adicionadas ao nosso arquivo e poderíamos setar a variável security acima como
sasl. Ele seria usado para tornar algumas conexões privilegiadas, como a do administradores,
mais seguras do que conxões por simples binds. Para a variável require podemos também setar
outras condições de uso, como obrigar todos que quiserem se conectar ao servidor a utilizar a
versão 3 do protocolo LDAP. Podemos também forçar uma atenticação prévia ao acesso a da-
dos, evitando conexões anônimas, se elas não forem interessantes. Uma variável que não está
incluída acima é a disallow, que impede que a conexão seja estabelecida caso o cliente não satis-
faça a condição dada. Consultem o manual do slapd.conf para conhecer as opções caso queiram
montar um diretório com uma configuração minimente mais elaborada.
Uma boa consideração aqui é que todos mantenham o arquivo de configuração /etc/ldap/slapd.conf
com permissões de escrita e leitura somente para o root.
36

Capítulo 9
slapd.conf : Configurando - Parte 2
9.1 Recorte do slapd.conf
Recorte do slapd.conf
#######################################################################
# Specific Backend Directives for bdb:
# Backend specific directives apply to this backend until another
# ’backend’ directive occurs
backend bdb
checkpoint 512 30
#######################################################################
# Specific Backend Directives for ’other’:
# Backend specific directives apply to this backend until another
# ’backend’ directive occurs
#backend <other>
#######################################################################
# Specific Directives for database #1, of type bdb:
# Database specific directives apply to this databasse until another
37

# ’database’ directive occurs
database bdb
# The base of your directory in database #1
suffix "dc=example,dc=com"
# rootdn directive for specifying a superuser on the database. This is needed
# for syncrepl.
# rootdn "cn=admin,dc=example,dc=com"
# Where the database file are physically stored for database #1
directory "/var/lib/ldap"
#######################################################################
9.2 Backends
O trecho que recortei começa próximo à linha 45, e trata do backend de banco de dados.
Como podemos ver o bdb é considerado o padrão, mas outros podem ser utilizados se informados
no lugar de <other>, como é explicado no trecho acima. Caso queira utilizar outro backend de
banco exclusivamente, comente as linhas padrões do dbd. Outras possibilidades são:
bdb Berkeley DB
dnssrv DNS SRV
hdb Variante hierárquica do bdb
ldap Lightweight Directory Access Protocol (Proxy)
ldbm Lightweight DBM
meta Meta Directory
monitor Monitor backend
passwd Utiliza o arquivo /etc/password
perl Backend programável Perl
shell Programa acessado via shell
sql SQL
9.3 Suffix
A próxima linha não-comentada atribui "dc=example,dc=com"à variável suffix. Este valor, tam-
bém chamado de naming context, é tipicamente o domínio do servidor, o que é recomendado
38

oficialmente, mas poderia ser qualquer outro. Como podem recordar, DC é uma abreviatura de
Domain Component.
suffix "dc=example,dc=com"
Adeque essa linha à configuração desejada.
9.4 RootDN
Assim como muitos serviços possuem algum usuário administrador o LDAP pode, se for o
caso, reconhecer um usuário chamado rootdn. O rootdn, como o nome sugere, é o "nome
distinto"do super-usuário. Devemos nos lembrar que dn significa (Distinguished Name) "nome
distinto", que é o apelido para a coleção de diretórios/atributos que identifica exlusivamente um
usuário. Um atributo que o superusuário precisa ter é o CN (Common Name), o "nome comum".
Este nome pode ser qualquer um como "administrador", "root", "admin", "diretor", "chefe"ou qual-
quer coisa que se queira, e vai compor o DN.
Logo, se o domínio do servidor é example.com e o diretório se reconhece como sendo "dc=example,dc=com
como foi atribuído à variável sufix, então, se o superusuário tiver um CN admin, o roodn poderia
ser, como no trecho acima, "cn=admin,dc=example,dc=com".
rootdn "cn=admin,dc=example,dc=com"
Adeque essa linha à configuração desejada.
9.5 Senha
Agora podemos setar uma senha para o nosso administrador, que ficará guardada dentro do
próprio slapd.conf, mas que, é claro, ficará criptografada. A variável password-hash que já se-
tamos como SSHA definiu o tipo de algorítimo aceito. Como este é o padrão, não teremos que
saber muito para gerar a senha criptografada. Na linha de comando, digitem:
$ /usr/sbin/slappasswd
Digitem uma senha e repita-a em seguida. A senha criptografada será mostrada no final. Essa é
a sua senha. A senha "senha"que eu escolhi gerou a saída:
{SSHA}8EGXOOzdVLByzPiZdAraIkwZlPkP+RIR
Copiando-a e a inserindo adequadamente no slapd.conf eu tenho a seguinte linha, que colo-
quei logo abaixo da linha que define o rootdn:
rootpw {SSHA}8EGXOOzdVLByzPiZdAraIkwZlPkP+RIR
39

9.6 Diretório
A última linha descomentada do trecho que reproduzi a cima diz respeito a em que lugar no
sistema os dados vão propriament ficar.
directory "/var/lib/ldap"
A linha acima define a pasta /var/lib/ldap, mas outro diretório poderia ser declarado no seu lu-
gar, como "/var/lib/ldap/example.com".
Assegure-se de que o diretório existe, e caso não exista, o que provavelmente é o caso se o
diretório que definiram com a diretiva directory não é o padrão.
Crie o diretório caso não exista em seu sistema e sete sua permissão para 700, pois queremos
o root e somente ele lendo, escrevendo e acessando o diretório.
Em seguida é recomendável que se adicione a linha que define as permissões sobre os ar-
quivos que serão criados no sistema. Queremos que somente o root tenha permissões de leitura
e de escrita sobre estes arquivos (e nem ele com permissão de execução), então vamos atribuir
o valor de permissão 0600 aos arquivos criados com a diretiva mode:
mode 0600
40

Capítulo 10
slapd.conf : Indexes e ACLs
10.1 Índices (indexes) - parte 1
Para otimizar a busca por informações no banco de dados o LDAP oferece a possibilidade
de associar os atributos a quatro categorias de otimização de buscas. Cada um dos índices cor-
responde a uma "matching rule"deﬁnida na sub-pasta schema. A seguir são listados os índices,
cada qual com uma breve descrição de seu uso:
• pres : Otimiza os testes para saber se um dado atributo realmente existe no diretório;
• eq : Otimiza a busca por valores de atributos que sejam idênticos ao padrão dado;
• sub : Otimiza a busca por sub-strings de valores de atributos que correspondam ao padrão
dado;
• approx : Otimiza a busca por valores de atributo semelhantes ao padrão dado.
Para que as otimizações se apliquem precisamos associar (indexar) atributos com esses índi-
ces, o que funciona segundo a seguinte sintaxe:
# Para atribuir o índice eq ao atributo objectClass (atribuição necessária para OpenLDAP 2):
index objectClass eq
# Para atribuir os índices eq e approx aos atributos cn e objectClass na mesma linha:
index cn,objectClass eq,approx
# O mesmo poderia ser feito, no entanto, em duas (ou mais, se necessário) linhas:
index cn eq,aprox
index objectClass eq,approx
41

"Que escolhas fazer?"é uma boa pergunta para quem ainda está conhecendo e se habituando
aos usos dos atributos mais básicos. A minha sugestão é que pesquisem, se quiserem, e façam
experiências antes de levantar um slapd a servir o Brasil inteiro. Faça antes de uma maneira mais
intuitiva e experimentalista, pois dificilmente se encontrará uma fórmula para decidir por essa con-
figuração; cada tipo de diretório vai exigir mais da performance de alguns atributos específicos,
e certamente cada diretório vai esperar por otimizações diferentes. É vital saber que aplicativos
vão no final das contas conversar com o serviço, e como este tenderá a crescer, o que torna a
decisão pelo conjunto de índices uma decisão que exige maturidade. O autor deste curso não se
habilita a sugerir qualquer combinação de índices, mesmo que isso coubesse neste curso.
10.4 ACLs (Access Control Lists) - parte 1
ACLs (Access Control Lists) - parte 1 ACL significa, em português, Listas de Controle de
Acesso. Como o nome sugere, ACLs resolvem o problema do poder de acesso de cada usuário.
Para forjarmos essas regras, o LDAP possui uma sintaxe particular e bastante simples. Vejamos
seu funcionamento:
Exitem 6 níveis de permissões de acesso diferentes, aqui apresentadas em ordem de autori-
dade. O tipo de usuário a ser especificado pode:
• write : Mudar valor de atributos;
• read : Ler resultados de buscas;
• search : Buscar pela existência de atributos;
• compare : Comparar atributos;
• auth : Autenticar-se com um DN;
• none : Sem privilégios.
É importante saber que aqueles aos quais forem dados algum privilégio de acesso qualquer
terão também acesso às funções menos privilegiadas, ou seja, quem puder ler, também poderá
comparar atributos, e quem pode escrever pode também realizar todas as outras funções.
Naturalmente, uma regra de acesso precisa definir quem é que pode ou que não pode, ou
seja, a quem vamos atribuir cada privilégio de acesso. Para tanto existem quatro tipos de usuários
(fora, é claro, o próprio administrador, caso haja, que pode tudo):
• self : o próprio usuário conectado já previamente autenticado;
• users : usuários que se conectarem com autenticação;
• anonymous : usuários que se conectarem sem autenticação;
• * : todos usuários.
42

Além de podermos utilizar essas definições de usuários acima, podemos também utilizar
strings e/ou expressões regulares para nos referir a um DN específico. Bom, acredito que a
melhor forma de entender como esses e outros elementos vão se organizar nas regras é obser-
vando alguns exemplos. Como em regras de Iptables, podemos definir uma política geral, que no
fundo é também só uma regra geral:
defaultaccess search
Definindo a regra acima, todos a princípio poderão realizar no máximo buscas.
Podemos, é claro, setar permissões para atributos específicos. Uma regra típica e muitas
vezes fundamental é a seguinte:
access to attrs=userPassword
by self write
by self * auth
Acima foi definida uma única regra, e o que permite que escrevamos uma regras em mais de
uma linha é o espaço no início da linha, que indica continuação da linha anterior, como foi ex-
plicado quando falávamos da sintaxe do slapd.conf. A regra acima permite que qualquer um
modifique o próprio atributo de senha e permite que todos se autentiquem através desse atributo.
Para definir uma regra geral, que não podemos confundir com uma política, podemos usar a
sintaxe mais simple:
access to * by * read
Como disse, este formato desempenha uma função diferente daquele qua primeira diretiva, que
definia a política, desempenha, ainda que seus resultados sejam assemelhados. Enquanto a
primeira diretiva de permissões que mostrei está mais para uma política de acesso, a segunda
diretiva, por sua vez, está mais para uma regra global de acesso - os usos de diretivas de políticas
e de regras de acesso não são intercambiáveis.
Apesar desses formatos de regras nos servirem bem, normalmente vamos querer aplicar re-
gras restritas a determinados ramos de nossa árvore de diretórios. Podemos querer aplicar regras
somente para os usuários pertencentes a uma dada Unidade Organizacional (OU), por exemplo.
Neste caso, poderíamos ter uma regra do tipo:
access to dn=".*,dc=example,dc=org"
attrs=userPassword
43

by self write
by * auth
by dn=".*,ou=superusers,dc=example,dc=org"write
Aqui se definiu permissões ao atributo userPassword que são internos ao domínio example.org
de:
1. escrita para self;
2. autenticação para * (todos);
3. escrita para todos pertences à OU superuser (que seriam administradores);
Observe que na declaração do DN não há espaços entre seus componentes, ou seja, não há
espaços entre as vírgulas.
Por último, é importante sabermos que a ordem com que devemos declarar as regras é das
mais específicas para as mais gerais (ao contrário de como fazemos com regras de Iptables,
por exemplo). A única diretiva que não seja este princípio é a que define a política, a definida
com defaultaccess. Enfim, não funciona setarmos permissão de leitura de tudo a todos e em
seguida restringir o acesso ao atributo userPassword a autenticação apenas. A primeira regra vai
permanecer regente, concedendo permissão de leitura de tudo a todos. Precisamos, pois, neste
caso, primeiro informar que só se pode acessar o atributo userPassword para autenticação (e
escrita para autenticados, se for o caso, e tudo mais que seja específico) e depois sim informar
que todos podem ler tudo. Neste exemplo o LDAP lerá a última regra já com a ressalva de que
especificamente o atributo userPassword só pode ser acessado para autenticação e escrita se for
o caso (e o que mais tiver sido decidido nas primeiras regras específicas).
Outras linhas de configurações que não vimos aqui estão presentes por padrão no slapd.conf,
o que permite a quem quiser conhecer melhor o slapd simplismente lendo o arquivo de confi-
guração. O ideal, no entanto, é que se leia não somente as linhas do nosso arquivo que não
chegamos a ver aqui, mas também o manual do slapd.conf. Este curso não pode cobrir todas
diretivas de configuração do slapd, logo ler o manual pode ser o primeiro e melhor passo para
uma configuração mais personalizada do serviço.
44

Capítulo 11
LDIF
11.1 Introdução ao LDIF
O LDIF signiﬁca LDAP Data Interchange Format (Formato de traca de dados LDAP) e é um
padrão de arquivos-texto que permite a atualização do conteúdo de um diretório LDAP através do
processamento de um texto simples contendo os dados a se processar no formato adequado. O
seu propósito é ser um meio humanamente hábil para a manipulação dos dados de um diretório
LDAP.
Podemos entender o que o LDIF faz em duas funções básicas: exportar e importar diretórios,
itens e atributos. Logo o LDIF serve tanto para montar do início a sua árvore de diretórios LDAP
quanto para mantê-la atualizada posteriormente.
Como o conteúdo de um diretório LDAP se trata basicamente de atributos de itens e seus
respectivos valores, um arquivo LDIF é constituído basicamente de uma listagem de atributos de
um item representado por um DN associados a seus respectivos valores de atribuição. Além do
DN e da lista de atribuição, um arquivo LDIF pode possuir diretivas que informem ao interpretador
do LDIF como os dados deverão ser processados. Obviamente, além da própria sintaxe LDIF, um
arquivo LDIF precisa que seu conteúdo seja compatível com os esquemas adotados no diretório.
Por hora vamos apenas conhecer sua sintaxe como um conjunto de regras numeradas e mais
tarde, quando estivermos levantando os dados propriamente ditos, vamos conhecer exemplos do
que poderiam ser LDIFs reais. É importante, no entanto, saber que o LDIF, para amazenar dados
inteligíveis ao LDAP, organiza as informações sobre cada objeto (ítens e diretórios) em blocos
distintos, o que faz do LDIF um formato que sempre separa o conteúdo dos arquivos em blocos.
11.2 1 - Sintaxe das atribuições
Uma atribuição nos arquivos LDIF deve ter a forma "atributo: valor". Note que entre um atri-
buto e um valor o sinal de atribuição é o dois pontos ": "e não o sinal de igualdade, e que após
esse deve haver um espaço em branco até o entrada do valor a se atribuir. Um exemplo de atri-
buição pode ser:
uid: tomasrc
45

11.3 2 - Listagem de atribuições
Cada entrada de atributo deve estar em sua própria linha, logo não há em um arquivo LDIF
linhas que contenham mais de uma declaração de atributos. Logo, dentro de um texto LDIF en-
contraremos linhas como, por exemplo:
uid: tomasrc
cn: Tomas
objectclass: account
uidnumber: 1001
homedirectory: /mnt/home/tomas
userpassword: cryptEDgToXSJ7OeAs
11.4 3 - Comentários
Comentários em um texto LDIF são identiﬁcados linha-a-linha, sendo que para que uma linha
seja reconhecida como um comentário ela deve ser iniciada com o caractere sharp "# ", como em
scripts bash. A peculiaridade de um arquivo LDIF é que nele o caractere de comentário "# "tem
de estar necessariamente na primeira coluna da linha para ser corretamente interpretado. Por
exemplo:
#LDIF para a atualização do dn: dc=example, dc=org
dn: dc=example, dc=org
objectClass: domain
dc: example
11.5 4 - Caracteres especiais
Como de se esperar, existem caracteres reservados que são interpretados especialmente em
uma arquivo LDIF. Para que se interprete literalmente um caractere reservado devemos precedê-
lo, também como de se esperar, de uma barra invertida "". Obviamente, # é reservado e para
nos referirmos literalmente ao caractere # devemos escrever "# ". O mesmo vale para a seguinte
lista de caracteres especiais, além do próprio #:
• + (sinal de soma)
• , (vírgula)
46

• "(aspas dupla)
• (barra invertida)
• ; (ponto e vírgula)
• < (sinal de menor)
• > (sinal de maior)
• (espaço em branco) no início ou no ﬁnal de linhas;
11.6 5 - Continuação de linha com quebra de linha
No caso de haver uma atribuição ou qualquer texto a ser interpretado em uma só linha que
precise ser continuado na linha de baixo, devemos iniciar a continuação na linha de baixo com
um único espaço em seu início. Exemplo:
uid: tomasrc
cn: Tomas
objectclass: account
loginshell: /bin/bash
uidnumber: 1001
homedirectory: /mnt/home/tomas
userpassword: cryptEDgToXSJ7OeAs
descripton: Estagiário do projeto
de inclusão digital CDTC
11.7 6 - Atributos vazios
Para declarar um atributo cujo valor seja vazio, deve-se declará-lo normalmente até os dois
pontos e deixar o restante da linha em branco. Exemplo:
uidnumber: 1001
homedirectory:
userpassword: {crypt}EDgToXSJ7OeAs
47

11.8 7 - Linhas em branco e início de bloco
Linhas em branco são utilizadas para separar blocos de dados a serem importados, tipica-
mente deﬁnições de um diretório, iniciados por dn...
# Espaço de uma linha antes de um novo bloco
# Novo bloco
dn: ou=usuarios, dc=example,dc=com
ou: usuarios
description: Diretorio dos usuarios
objectclass: organizationalunit
11.9 8 - Atribuição por referência
Uma possibilidade é que se atribua um valor dado por referência a um arquivo no sistema (ou
até mesmo na rede). Neste caso utilizamos o caractere ’<’ em sequência aos dois-pontos.
cn:< ﬁle://home/usuario/nome.asc
48

Capítulo 12
Ferramentas LDAP/Slapd
12.1 Ferramentas de manutenção LDAP
Até então compreendemos de forma geral o funcionamento e os conceitos do um diretório
LDAP, instalamos o slapd como seu serviço e configuramos o arquivo de configuração deste ao
mesmo tempo que fomos aprendendo mais sobre o que está envolvido em levantar um servidor
LDAP. Ok, mas e os dados? Tudo o que fizemos até então foi um esforço para permitir que
organizássemos nossos dados da maneira como gostaríamos e não termos problemas cabais
de organização e de segurança. Como fazemos afinal para de fato colocarmos e mantermos os
dados dentro de nosso diretório? Já temos alguma noção de como o processo funciona pois já
aprendemos por alto o funcionamento e a sintaxe de um arquivo LDIF.
O LDAP possui uma lista de seis ferramentas de linha de comando que nos permite inserir,
retirar e consultar, modificar e mover dados. Podemos, através destas ferramentas, levantar e
fazer toda a manutenção de nosso servidor. Muitos vão sentir, no entanto, a tarefa de manter o
servidor através das ferramentas de linha de comando muito sacrificiosa quando uma quantidade
grande de dados está envolvida. Mais tarde vamos saber de uma ou outra interface mais amigável
para manipular os dados do diretório LDAP, mas é importante que conheçamos os utilitários
básicos de linha de comando, o que permite uma compreensão mais sólida da manutenção dos
dados no LDAP.
As ferramentas de que falo são as seguintes:
• ldapadd
• ldapdelete
• ldapmodify
• ldapsearch
• ldapmoddn
• ldapbind
Temos que saber que estas ferramentas listadas são as ferramentas de uso dito online, ou
seja, que requerem que o servidor esteja em pé, e que por sua vez permite o seu uso (via rede,
por exemplo) sem a necessidade de uma conta na máquina local (o que mesmo em um acesso
remoto costuma ser necessário). Existem também, no entanto, as ferramentas que fazem parte
do slapd, e que são utilitários offline, bem-vindos no momento em que estamos levantando os
49

primeiros do(s) nosso(s) servidor(es), já que não precisamos que ele(s) esteja(m) no ar, e já que
a transferência de dados localmente costuma ser signiﬁcativamente mais rápida. Estes utilitários
do slapd são especialmente funcionais localmente, e portanto nem sempre convenientes. É justo
lembrar que algumas das ferramentas locais foram já apresentadas en passant durante a lição
em que instalamos o slapd.
Mas vamos agora nos concentrar nas ferramentas ldap..., pois são aquelas de uso generali-
zado, tanto para manutenção quanto para consulta e levantamento, contrastando com o uso das
slap..., que servem a um administrador que tenha acesso (login) à própria máquina de produção.
12.2 1 - Ldapadd
O ldapadd é a ferramenta que utilizamos para inserir dados no nosso diretório. Passamos
para o comando pelo menos três ou quatro parâmetros: o endereço e porta do diretório ao qual
se conectar, o usuário a ser autenticado, sua senha e o arquivo LDIF contendo os dados a serem
inseridos. Finalmente o LDIF entra em jogo. Um exemplo de uso do ldapadd poderia ser:
ldapadd -h example.com -p 389 -D "cn=admin-w senha-secreta -f arquivo1.ldif
Consulte o manual com o comando man ldapadd para conhecer todas opções e parâmetros
possíveis, ou procure pelo manual na internet.
12.3 2 - Ldapdelete
O comando ldapdelete serve para remover de um diretório LDAP um determinado ítem ou um
ramo de um diretório, tipicamente um usuário. Assim como o ldapadd, o ldapdelete recebe os
parâmetros necessários para se conectar ao diretório e se autenticar como um usuário com sua
senha. Por último, ele deve receber o DN do ítem a ser removido do diretório. Naturalmente, este
usuário deverá possuir as permissões setadas por ACLs para remover o ítem dado. Tipicamente
esse usuário é um administrador (não necessariamente de todo o servidor, mas possivelmente
de toda uma OU, por exemplo).
Um exemplo de uso do ldapdelete poderia ser:
ldapdelete -h example.com -p 389 -D "cn=admin-w senha-secreta "cn=carlota,ou=gerencia,dc=exam
Consulte o manual com o comando man ldapdelete para conhecer todas opções e parâmetros
12.4 3 - Ldapmodify
O comando ldapmodify é como um comando de manutenção genérica dos dados do servidor.
Ele é capaz tanto de adicionar quanto de deletar dados, o que permite, enﬁm, que ele seja
utilizado para se adequar dados já existentes no servidor (além de poder substituir o ldapadd e o
ldapdelete). Este comando segue uma sintaxe como a do comando ldapadd, visto que se utiliza
de um arquivo LDIF para fornecer as informações a serem acrescentadas. Outros parâmetros
necessários além do caminho do arquivo LDIF são, é claro, o endereço do servidor, o usuário
com o qual se autenticar e sua senha. O ldapmodify exige que montemos nosso LDIF com uma
diretiva especial, indicando a ele o que fazer. Isso é natural visto que o LDIF deve informar aqui
50

exatamente o que fazer no diretório, já que em geral não vamos simplismente inserir dados novos
quando utilizarmos esse comando (ainda que possamos fazê-lo). A diretiva a qual me referi é a
changetype, que vai informar ao servidor que tipo de modificação deve ser realizada no diretório.
São quatro tipos de allterações possíveis:
• add : insere um bloco de dados novo;
• delete : remove um ítem;
• modify : modifica os atributos de um ítem;
• modrdn : modifica o RDN de um ítem.
Para quem não se lembra, RDN é uma sigla para Relative DN, que é simplismente um atributo
escolhido que vai servir para distinguir um ítem de outro em um mesmo ramo de diretório. Não
pode haver, portanto, dois RDNs iguais em um mesmo ramo na hierarquia. O atributo uid é um
exemplo de atributo usado como RDN.
Um exemplo de uso do ldapmodify poderia ser:
ldapmodify -h example.com -p 389 -D "cn=admin-w senha-secreta -f modifica-carlota.ldif
Consulte o manual com o comando man ldapmodify para conhecer todas opções e parâme-
tros possíveis, ou procure pelo manual na internet.
12.5 4 - Ldapsearch
O comando ldapsearch é utilizado para realizar buscas por ítens de uma árvore de dados
LDAP. Como de se esperar, o comando de busca também pode se autenticar com um usuá-
rio e uma senha, ou pode, se as regras de acesso permitirem, conectar-se anonimamente. O
parâmetro que não faria sentido faltar é, é claro, a string que designa o escopo da busca. Pode-
mos solicitar, por exemplo, que o servidor nos responda com todos os ítens pertencentes a uma
determinada organização, representada por um ramo da árvore.
Eis um exemplo de uso do ldapsearch, mostrando uma autenticação anônima com solicitação
de busca pela raíz (-b) do ramo informado pelos dois atributos dados de todos os ítens, esperando
por uma resposta simpática do servidor (-u).
ldapsearch -h example.com -p 389 -b -u "ou=funcionarios,dc=example,dc=com"sn mail
Consulte o manual com o comando man ldapsearch para conhecer todas opções e parâme-
tros possíveis, ou procure pelo manual na internet.
12.6 5 - Ldapmoddn
O comando ldapmoddn é usado tanto para mover um objeto do diretório para outro ponto da
árvore, quanto para alterar o RDN de um ítem. Naturalmente, para realizar esse tipo de tarefa
é necessário se autenticar, e provavelmente como administrador. Além dos parâmetros host,
porta, login e senha, passamos a especificação de um objeto do diretório através de seu DN
(-b) e passamos o outro parâmetro que vai indicar se queremos movê-lo pelo diretório (-N) ou se
queremos alterar o RDN que o reconhece (-R).
Um exemplo de uso do comando ldapmoddn poderia ser:
ldapmoddn -h myhost -p 389 -D "cn=admin-w senha-secreta
51

-b "cn=maria,ou=funcionarios,dc=example,dc=com"
-N "ou=administradores,dc=example,dc=com"
Consulte o manual com o comando man ldapmoddn para conhecer todas opções e parâmetros
12.7 6 - Ldapbind
O ldapbind é a ferramenta que utilizamos para nos autenticarmos em um servidor LDAP.
Já conhecemos o uso deste através dos exemplos das outras ferramentas que já conhecemos.
Precisamos informar de que servidor estamos falando (-h), sua porta de escuta (-p), o nome de
login (-D) e a senha deste (-w, para autenticação simples ou -W para autenticação com SSL). Um
exemplo de uso do ldapbind poderia ser:
ldapbind -h example.com -p 389 -D "cn=admin-w senha-secreta
Consulte o manual com o comando man ldapbind para conhecer todas opções e parâmetros
12.8 Ferramentas ofﬂine (do slapd)
Agora é interessante que listemos em uma apresentação breve as ferramentas do slapd para
(re)conhecermos suas possibilidades. Entre os utilitários slap estão:
• slapadd
• slapcat
• slapindex
• slappasswd
Como devem lembrar, utilizamos o slappasswd para gerar a senha do rootdn. Mas e os outros
utilitários? Bom, lembra das marcações que vimos poder setar para os atributos no slapd.conf?
Aquelas marcações são chamadas de index(es), que é a palavra que iniciava as diretivas das
marcações. O slapindex nos permite atualizar e associar marcações (indexes) a atributos na
medida em que os dados se multiplicarem no backend de dados.
O slapadd, como se pode imaginar, tem a função análoga a do ldapadd. O slapadd é mais
adequado para a inserção de grandes quantidades de dados, visto que uma transferência local
de dados costuma ser mais rápida que uma transferência online, e o slapadd é uma ferramenta
ofﬂine.
O slapcat tem a função de solicitar dados do servidor, analogamente ao ldapsearch, mas
retorna o conteúdo de todo um diretório e nos entrega um arquivo em LDIF. O slapadd e o slapcat
recebem os mesmos parâmetros, mas enquanto para o slapadd nós fornecemos um arquivo LDIF,
com o slapcat nós informamos onde ele deve escrever o seu.
52

Entre os parâmetros que essas duas ferramentas podem receber estão dois mais importantes,
a indicação de um arquivo de conﬁguração, para caso queiramos apontar para outro caminho que
não o padrão
−f
, e a indicação de que arquivo LDIF de input(slapadd)/output(slapcat) vai ser utilizado
−l
.
53

Capítulo 13
Manipulando dados
13.1 Escrevendo um LDIF - parte 1
Enfim, vamos colocar algum dado no ar. Como já sabemos, vamos precisar montar um ar-
quivo LDIF que contenha as informações que vão explicar ao servidor como, onde e que dados
devem ser armazenados. Como vai ser exemplificado o início da inserção de dados no servidor, é
razoável que optemos agora pelo utilitário do slapd, o slapadd (o que é mais raro do que comum).
Vamos primeiramente inserir três blocos de dados que consitituirão o princípio do diretório
LDAP do servidor escola.org, cada um especificando um objeto do árvore, que no caso serão:
1. 1. a raíz do diretório, cujo DN vai ser, por conveção, o próprio domínio do servidor (naming
context);
2. 2. a OU dos professores;
3. 3. a OU dos estudantes.
Esse tipo de modelo que utilizo regularmente como exemplo é uma aprensentação simplista
do que costuma ou do que pode ser um diretório LDAP, e serve somente para nos ajudar a conhe-
cermos a sua implementação e o funcionamento do serviço em geral, mas não para representar
uma organização de diretórios exemplar. Enfim, o exemlo acima não nos serviria como um estudo
caso, por assim dizer.
13.2 Escrevendo um LDIF - parte 2
Abram, pois, o seu editor de texto predileto. Se se lembram bem da lição sobre o LDIF, vão
esperar corretamente que devemos começar nosso script por um DN, que vai abrir o primeiro
bloco de dados. Esse DN vai indicar a posição do objeto que queremos implementar. Pois bem,
o primeiro objeto descrito tem de ser o topo do diretório, a raiz.
# Implementação da raíz da árvore:
dn: dc=escola,dc=com
dc: escola
objectClass: dcObject
objectClass: organizationalUnit
ou: Escola Web
54

Este foi o primeiro bloco do nosso arquivo. Ele instancia o objeto de classes dcObject e or-
ganizationalUnit no DN especificado, que é a raíz. Pulando uma linha, informamos que vamos
inciar um novo bloco de dados, que vai dizer respeito a outro objeto. Continuando o script LDIF,
adicionando os dois sub-diretórios à raiz:
# Implementação da raíz da árvore:
dn: dc=escola,dc=com
dc: escola
objectClass: dcObject
ou: Escola Web
# Pula-se uma linha para indicar um novo bloco de dados
# Implemtação da OU dos professores:
dn: ou=professores,dc=escola,dc=com
ou: professores
#Pula-se outra linha
# Implementação da OU dos estudantes:
dn: ou=estudantes,dc=escola,dc=com
ou: estudantes
Poderíamos, se fosse o caso, adicionar uma OU também para a diretoria da escola e outra para
os administradores do serviço, quem sabe, dependendo da política. Enfim, salve o arquivo em
um diretório como por exemplo o /etc/ldap/ldif, que ainda não existe, mas que podemos criar para
guardar nossos scripts LDIF. Um nome para esse arquivo poderia ser base-escola.ldif. Vamos
então carregar o servidor com nossos dados.
13.3 Levantando dados
Na linha de comando, em nome do usuário (que deveria ser, de preferência, o root) que tiver
permissão para escrever no caminho do sistema designado pela diretiva directory, como setada
no slapd.conf, digitem o seguinte comando:
# slapadd -l /etc/ldap/ldif/base-escola.ldif
O comando como apresentado acima deve ser adaptado às condições de cada um, visto que
assume que tenham salvo o arquivo como "base-escola.ldif"em um diretório personalizado "ldif",
que nos têm servido aqui somente como exemplos. Outros parâmetros prediletos podem ser
passados aqui, mas foi apresentado um exemplo básico para que compreendamos o que basi-
camente se passa em uma inserção de dados através do slapadd. O único parâmetro passado
e que não poderia mesmo faltar é o que especifica o caminho e nome do script LDIF cujas in-
formações gostaríamos de inserir. O caminho do arquivo LDIF é passado com o parâmetro ’ -l
’.
55

13.4 Consultando dados - parte 1
Neste momento nosso servidor já possui um esboço de uma estrutura de diretórios hierár-
quica, o que significa necessariamente que existem atributos armazenados, o que também sig-
nifica que existem dados armazenados. Em certo sentido, temos uma miniatura simplificada do
que é uma árvore de diretórios LDAP. Simplificada pois um servidor LDAP maduro é capaz de
replicar dados e muitas vezes integrado a uma rede de forma a desempenhar funções como a de
um servidor de logins (NIS), por exemplo. Ora, mas mesmo uma versão reduzida de banco de
dados qualquer nos deveria permitir que consultássemos seus dados. Claro, vamos experimentar
em breve o uso do ldapsearch, de cujo funcionamento já temos uma boa idéia.
No entanto, sabemos que as ferramentas ldap... não funcionam se o servidor não estiver no
ar. Para utilizá-las, precisamos colocar o servidor para rodar. O servidor pode estar executável
em alguns locais possíveis do sistema (visto que as instalações podem ter sido diferentes, e em
diferentes sistemas), como por exemplo em /usr/sbin/slapd ou em /usr/local/libexec/slapd, as-
sim como através do initd, tipicamente no debian, devendo ser inicializado com /etc/init.d/slapd
start. Naturalmente, variados parâmetros podem ser passados para o slapd, redefinindo o ar-
quivo de configuração utilizado, caso não se queira utilizar na chamada do serviço o arquivo
padrão slapd.conf. Existem parâmetros relativos ao processo de logging, e parâmetros para de-
terminar o usuário e o grupo em nome dos quais o processo do slapd no sistema deverá ser
executado. Estudem o manual do serviço com o comando man slapd para conhecer suas capa-
cidades.
Uma vez com o servidor no ar, podemos fazer uso do utilitários ldap... como ldapsearch.
13.5 Consultando dados - parte 2
Como vimos, os comandos ldap... requerem que nos autentiquemos (a não ser que queira-
mos, é claro, acessar o servidor como usuário anônimo). É fácil agora entender por que funcio-
nam desta forma, enquanto acabamos de utilizar o sladadd sem credencial alguma. O utilitários
como o ldapadd, ldapmodify , ldapsearch, etc., não requerem qualquer autorização do sistema
que serve o LDAP, pois seu propósito é estarem disponíveis à rede, ao contrário das ferramentas
slap...(que, aliás, também só funcionarão se executadas por um usuário local que tenha as per-
missões adequadas no sistema servidor). Analogamente, as ferrmantas online também requerem
que informemos o endereço do servidor visado, enquanto as ferramentas locais naturalmente não.
Além destes dois parâmetros, devemos, no caso do ldapsearch, delimitar nossa intenção de
busca, como com qualquer serviço de banco de dados. Basicamente podem ser feitas duas
perguntas por essa delimitação: "o quê?"e "onde?". Cada uma destas perguntas é respondida
com dois parâmetros. A primeira com o parâmetro de filtro de busca e com uma lista de atributos
que pode interessar daquilo que for filtrado. A segunda com o parâmtro -b que deve designar
através de um DN dado uma posição na árvore a partir de qual o diretório deve ser vistoriado a
dentro.
Na linha de comando, digitem:
# ldapsearch -h localhost -b "dc=escola,dc=com(objectclass=*)"
Observem que todos os ítens devem possuir o atributo objectClass, e que portanto pedir por
todas ocorrências do atributo objectClass é como solicitar também todos os ítens. Observem
também que não nos autenticamos, mas que como usuários anônimos temos acesso de leitura
ao nosso diretório, se é o caso de não o terem desabilitado com uma regra de ACL. Para nos
autencticarmos com um usuário regular, precisaríamos que houvesse algum usuário regular ca-
56

dastrado em nosso banco! Mas também nada impede que acessemos o servidor para consulta
com as credenciais do superusuário (RootDN). Neste caso, usaríamos os parâmetros -D (seguido
do DN do superusuário) e -w (seguido da senha).
13.6 Removendo dados
Obviamente, dados devem poder ser removidos, e para tanto podemos utilizar, se o servidor
estiver funcionando, o ldapdelete. O ldapdelete pode, além de deletar objetos específicos da
árvore, remover recursivamente todo um diretório. Isso pode ser interessante caso queiramos,
por exemplo, mover todo um ramo de diretórios. Caso seja nossa intenção, podemos fazê-lo
através de um dump LDIF do diretório através do slapcat. Em seguida podemos reinserí-lo em
outro ponto da árvore com o ldapadd. Essa é uma boa alternativa para quem precisa modificar
diversos dados de diretório estático que possa estar fora do ar durante alguns minutos sem se ter
que elaborar um grande LDIF a ser utilizado com o ldapmodify. Para deletar tudo o que estiver
abaixo da OU do professores com um comando podemos digitar:
# ldapdelete -D "cn=admin,dc=escola,dc=com-w senha -x -r "ou=professores,dc=escola,dc=com"
Claramente, deve-se substituir o DN do superusuário para aquele definido na diretiva rootdn
dentro do slapd.conf e a senha para aquela armazenada através da linha rootpw. Ainda não
conhecíamos, talvez, o parâmetro ’ -x ’, que permite a realização de uma autenticação simples,
sem SASL. O parâmetro ’ -r ’ tem um função bastante previsível, habilita a recursividade de que
falávamos, permitindo a remoção de tudo o que estivesse dentro do diretório abaixo (ainda que,
como no nosso caso, não haja quase nada).
57

Capítulo 14
Últimas notas
14.1 Replicação LDAP - parte 1
Outra funcionalidade do LDAP (do OpenLDAP), ainda que não tenha sido tão bem instituida, é
a de permitir que um servidor base converse com um segundo servidor (na maioria esmagadora
das vezes, também uma outra máquina) replicando seus dados para este, ou seja, o mantendo
como sua réplica. Um administrador LDAP pode ter vários bons motivos para querer implementar
a replicação de dados. Basicamente, os motivos se devem a escassez de recursos relativa ao
uso de um servidor, seja essa uma escassez de memória, de processamento ou de banda de
rede.
Outro motivo interessante que se pode ter para querer manter um servidor LDAP de réplica é
querer ter um servidor somente-leitura que esteja sempre disponível (satisfazendo uma demanda
permanete), o replicado, e um replicante que eventualmente podesse sair do ar para entrar em
manutenção. Essa estrutura pode auxiliar boas práticas de segurança além de diminuir drastica-
mente a chance de que, quando o servidor base cair, os dados não sejam mais acessíveis. Esta
razão, aliás, é quase sempre uma razão por si só, visto que muitas empresas e organizações
simplismente não podem vir a ficar fora do ar.
14.2 Replicação LDAP - parte 2
Talvez lembrem do slurpd. Este é o serviço que replica os dados de um servidor slapd para
outro. Ou seja, existe um outro serviço que deve ser inicado para que a replicação aconteça. Se
configurado para tanto, o servidor base exporta um arquivo de log que vai ser interpretado pelo
slurpd cujos dados vão ser por este atualizados no servidor replicado, através das operações
LDAP que já conhecemos. Não instalamos o slurpd. Para habilitar sua compilação durante o
processo do ./configure temos de passar o argumento –enable-slurpd.
Iluminando um pouco o caminho daqueles que possam se interessar, para implementar uma
replicação de dados LDAP não é necessário que se edite qualquer arquivo de configuração rela-
tivo ao slurpd. O procedimento passa por editar ambos slapd.conf, tanto do servidor base quanto
do replicado e pela cópia estática do conteúdo deste para o servidor a ser replicado. Com os
servidores reiniciados, o processo é natural. O segredo está, pois, em como editar cada um dos
dois arquivos (assumindo que se tem o slurpd disponível no sistema). Uma busca no google por
slurpd não deve ser omissa em how-tos e em tutoriais.
58

14.3 Diretórios LDAP distribuídos
Uma última capacidade especial do LDAP que gostaria de apresentar aqui, com o simples
objetivo de informar alguns sobre sua existência e seus propósitos. Assumimos até então que
todos diretórios LDAP que estavam sob um mesmo domínio estivessem rodando também em um
mesmo diretório.
O LDAP possui a capacidade de ser funcional tendo os ramos de seus diretórios distribuí-
dos entre diferentes servidores. Um diretório LDAP pode ser organizado logicamente de forma
que enquanto o seu topo é servido em uma determinada máquina, cada unidade organizacional
subsequente, por exemplo, fique armazenada e servida em máquinas particulares.
O uso da distribuição de diretórios LDAP pode ser interessante para desafogar os recursos de
uma máquina em particular assim como para adequar a estrutura física do diretório a uma dada
estrutura administrativa, de forma que o responsável por cada seção da árvore possa manter
seus dados em sua própria máquina, por exemplo.
A implementação da distribuição de diretório LDAP passa, para aqueles que estejam interes-
sados, pela etapa de editar o arquivo de configuração de cada servidor re-setando as diretivas
suffix, rootdn, directory e eventualmente alguma outra para cada cenário em particular.
14.4 Interfaces de administração LDAP
Existem alguns aplicativos que permitem que realizemos as operações LDAP e que mante-
nhamos o diretório através de interfaces amigáveis. Ao menos mais amigáveis do que a própria
linha de comando. Elas permitem, em geral, que visualizemos a estrutura da árvore LDAP e as
permissões setadas, os objetos e seus atributos, ao mesmo tempo que permitem, é claro, a ma-
nipulação destes valores mediante uma autenticação através da própria interface. A baixo são
listadas as interfaces mais conhecidas de gerenciamento de diretórios LDAP:
phpLDAPadmin
Talvez a melhor ferramenta. Funciona através do Apache e do php, ou seja, é uma inter-
face de navegação em browser. Permite a visualização lógica do diretório e dispõe de todas as
ferramentas para o gerenciamento e a manutenção do diretório.
LDAP Browser/Editor
Este aplicativo serve perfeitamente às necessidades de administração LDAP, além de permitir
uma navegação completa pelos diretórios existentes, servindo também para consulta e tarefas
não administrativas.
Directory Administrator
Este aplicativo é feito para Gnome e visa o uso do LDAP integrado ao sistema de usuários
em UNIX. O site oficial nota, no entanto, que "Directory Administrator does not currently work
with OpenLDAP 2.2 or newer, unless schema checking is disabled. Set "schemacheck off"in the
slapd.conf and restart OpenLDAP."
59

Ldap

Mais conteúdo relacionado

Destaque

Semelhante a Ldap

Mais de Tiago

Último

Ldap