ldap

LDAP18 de abril de 2007

Sumário

I Sobre essa Apostila 2

II Informações Básicas 4

III LDAP 9

1 LDAP 10

2 Plano de ensino 112.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Público Alvo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3 Pré-requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.6 Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.7 Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.8 Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Introdução 133.1 O que é LDAP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 História . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Primeiros conceitos 154.1 Para que podemos usar o LDAP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2 Que tipos de aplicativos podem utilizar LDAP? . . . . . . . . . . . . . . . . . . . . . 154.3 Como é o acesso ao LDAP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.4 Como é o uso do LDAP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.5 Como são os dados do LDAP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.6 Quem tem acesso aos dados? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.7 Conceitos e convenções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5 Estrutura de diretórios LDAP 185.1 Noções gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.2 * Country . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.3 * Organizational Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.4 * Organizational Unit Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.5 * User Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1

CDTC Centro de Difusão de Tecnologia e Conhecimento Brasil/DF

5.6 * Distinguished Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.7 * Relative Distinguished Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.8 * Domain Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.9 Exemplo gráfico de uma árvore LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6 Instalação 226.1 Pacotes e serviços utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226.2 BerkleyDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226.3 SSL/TSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236.4 OpenLDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236.5 Um pouco sobre os arquivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

7 Teoria LDAP 257.1 Algumas apresentações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257.2 ObjectClass: funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257.3 Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

8 slapd.conf : Configurando - Parte 1 298.1 Introdução ao slapd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298.2 Esquemas - parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298.3 Esquemas - parte 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308.4 Dois ajustes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318.5 Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318.6 SSL e TLS - parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328.7 SSL e TLS - parte 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328.8 SSL e TLS - parte 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338.9 Algumas variáveis relativas à segurança . . . . . . . . . . . . . . . . . . . . . . . . . 33

9 slapd.conf : Configurando - Parte 2 359.1 Recorte do slapd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359.2 Backends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369.3 Suffix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369.4 RootDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379.5 Senha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379.6 Diretório . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

10 slapd.conf : Indexes e ACLs 3910.1 Índices (indexes) - parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3910.2 Índices (indexes) - parte 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3910.3 Índices (indexes) - parte 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4010.4 ACLs (Access Control Lists) - parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 4010.5 ACLs (Access Control Lists) - parte 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 4010.6 ACLs (Access Control Lists) - parte 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 4110.7 ACLs (Access Control Lists) - parte 4 . . . . . . . . . . . . . . . . . . . . . . . . . . 4110.8 ACLs (Access Control Lists) - parte 5 . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2


11 LDIF 4311.1 Introdução ao LDIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4311.2 1 - Sintaxe das atribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4311.3 2 - Listagem de atribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4411.4 3 - Comentários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4411.5 4 - Caracteres especiais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4411.6 5 - Continuação de linha com quebra de linha . . . . . . . . . . . . . . . . . . . . . . 4511.7 6 - Atributos vazios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4511.8 7 - Linhas em branco e início de bloco . . . . . . . . . . . . . . . . . . . . . . . . . . 4611.9 8 - Atribuição por referência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

12 Ferramentas LDAP/Slapd 4712.1 Ferramentas de manutenção LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4712.2 1 - Ldapadd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4812.3 2 - Ldapdelete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4812.4 3 - Ldapmodify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4812.5 4 - Ldapsearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4912.6 5 - Ldapmoddn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4912.7 6 - Ldapbind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5012.8 Ferramentas offline (do slapd) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

13 Manipulando dados 5213.1 Escrevendo um LDIF - parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5213.2 Escrevendo um LDIF - parte 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5213.3 Levantando dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5313.4 Consultando dados - parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5413.5 Consultando dados - parte 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5413.6 Removendo dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

14 Últimas notas 5614.1 Replicação LDAP - parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5614.2 Replicação LDAP - parte 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5614.3 Diretórios LDAP distribuídos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5714.4 Interfaces de administração LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3

Parte I

Sobre essa Apostila

4


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çaGNU Free Documentation License, cujo teor integral encontra-se aqui reproduzido na seção demesmo nome, tendo inclusive uma versão traduzida (não oficial).

A revisão e alteração vem sendo realizada pelo CDTC ([email protected]) desde outubrode 2006. Críticas e sugestões construtivas são bem-vindas a qualquer tempo.

Autores

A autoria deste é de responsabilidade de Tomas Ribeiro Cardoso ([email protected]).

O texto original faz parte do projeto Centro de Difusão de Tecnologia e Conhecimento, quevem sendo realizado pelo ITI (Instituto Nacional de Tecnologia da Informação) em conjunto comoutros parceiros institucionais, atuando em conjunto com as universidades federais brasileirasque tem produzido e utilizado Software Livre, apoiando inclusive a comunidade Free Softwarejunto a outras entidades no país.

Informações adicionais podem ser obtidas através do email [email protected], ou dahome 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 responsabilizamdireta 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 ([email protected]) .

Permission is granted to copy, distribute and/or modify this document under the termsof the GNU Free Documentation License, Version 1.1 or any later version published bythe 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 DocumentationLicense.

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 dodesenvolvimento 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 ede código fonte aberto, identificando e mobilizando grupos de formadores de opinião dentre osservidores públicos e agentes políticos da União Federal, estimulando e incentivando o mercadonacional a adotar novos modelos de negócio da tecnologia da informação e de novos negóciosde comunicação com base em software não-proprietário e de código fonte aberto, oferecendotreinamento 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 comoincentivadores 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 deprodutos 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ê comeceseu 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 oroteiro acima.

Licença

Copyright ©2006, Instituto Nacional de Tecnologia da Informação ([email protected]).

7


É dada permissão para copiar, distribuir e/ou modificar este documento sob os termosda Licença de Documentação Livre GNU, Versão 1.1 ou qualquer versão posteriorpúblicada pela Free Software Foundation; com o Capitulo Invariante SOBRE ESSAAPOSTILA. 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 seuscolegas de turma respeitando-os e fazendo ser respeitado pelo mesmo.

• 5. Organização pessoal: planejar e organizar tudo é fundamental para facilitar a sua revisãoe a sua recuperação de materiais.

• 6. Vontade para realizar as atividades no tempo correto: anotar todas as suas obrigações erealizá-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, aprendizagense 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ãocontrola a sua dedicação, mas reflete 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çõesque 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 queinteresse ao grupo, favor postá-la aqui.Porém, se o que você deseja é resolver alguma dúvida ou discutir algum tópico específico docurso. É recomendado que você faça uso do Forum de dúvidas gerais que lhe dá recursos maisefetivos para esta prática.

. O fórum de dúvidas gerais tem por objetivo disponibilizar um meio fácil, rápido e interativopara solucionar suas dúvidas e trocar experiências. As mensagens postadas nele são enviadasa todos participantes do curso. Assim, fica muito mais fácil obter respostas, já que todos podemajudar.Se você receber uma mensagem com algum tópico que saiba responder, não se preocupe com aformalizaçã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 podemser 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, porpessoas 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 dasferramentas 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 respectivosvalores e atitudes, incentiva mas é honesto, imparcial, amável, positivo, respeitador, aceita asidé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 tutorou 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 umreparo de um estudante: ’os comentários deixam-nos com uma sensação de crítica, deameaç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

Parte III

LDAP

11

Capítulo 1

LDAP

LDAP é um serviço totalmente desenvolvido sobre tcp/ip que funciona como um banco dedados que armazena informações em uma estrutura hierárquica (em árvore) de diretórios. Suafuncionalidade se adequa a um número enorme de acessos por dia e a uma quantidade pequenade gravações/atualizações pelo mesmo tempo. O LDAP oferece a possibilidade de uma unifica-ção generalizada, dos processos de autenticação e de armazenamento de dados pessoais, entrediferentes 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 servidorLDAP simples.

2.2 Público Alvo

Técnicos e administradores GNU/Linux interessados em compreender de forma cuidosa ofuncionamento 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 comoum 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 seuserviço e apresenta os passos para se realizar a instalação do OpenLDAP. As ferramentas degerenciamento do banco são apresentadas com exemplos de forma que aqueles interessados emcontinuar os estudos sobre o LDAP possam ter no curso uma base sólida para implementaçõesreais de um servidor LDAP. Não são mostrados, portanto, na atual versão do curso, estudos decaso de como se procederia para integrar o LDAP aos demais serviços de uma rede típica, mas ocurso se preocupa em iniciar no assunto clara e cuidadosamente, prática e teoricamente, técnicosque 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 explicativoe uma ou mais perguntas para acompanhar panoramicamente a leitura dos participantes. Ao final

13


do curso um questionário será apresentado para que se faça uma avaliação do aprendizado decada um. Aconselhamos a leitura de "Ambientação do Moodle"para aquelas pessoas que nãotenham 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ódulo1 semana Lição 1 - Introdução

Lição 2 - Primeiros conceitosLição 3 - Estrutura de diretórios LDAPLição 4 - Instalação

2 semana Lição 5 - Teoria LDAPLição 6 - slapd.conf : Configurando - Parte 1Lição 7 - slapd.conf : Configurando - Parte 2Lição 8 - slapd.conf : Indexes e ACLs

3 semana Lição 9 - LDIFLição 10 - Ferramentas LDAP/SlapdLição 11 - Manipulando dadosLição 12 - Últimas notasAvaliação de aprendizagemAvaliaçã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 aliberar a certificação. Para a aprovação o participante deverá obter nota maior ou igual a 6,0 namédia final.

2.8 Bibliografia

Livro LDAP system administration Gerald Carter Ed. O’reilly Copy right 2003Apresentação de Slides CNPTIA/Embrapa VI Seminário de Capacitação Interna Daniel No-

vais Martins [email protected]á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 Levede Acesso a Diretório. Primeiramente, temos de saber que diretórios, para o LDAP, não sãopastas de um sistema de arquivo. Diretório foi um jargão aplicado já pelo padrão X.500 sobre oqual o LDAP se baseia, e diz respeito, mais genericamente, a alguma maneira de estruturar umrecipiente de dados.

LDAP é um protocolo que serve e acessa dados associados a ítens determinados (dadosque são, aliás, armazenados em único registro respectivo a cada ítem), como uma pessoa, umarquivo ou qualquer outro, armazenados logicamente em diretórios hierárquicos, como em umsistema de arquivo.

Ou seja, o LDAP, como um servidor, armazena informações sobre seus objetos (ou ítens, quede certa forma são análogos a arquivos) organizados em uma estrutura de continentes, isto é, emuma estrutura de diretórios (que também podemos pensar, com fins didáticos, serem análogos apastas de um sistema operacional). Já o LDAP cliente acessa as informações armazenadas noservidor 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 capacidadessão, e isto é importante, um bocado diferentes daquelas de um banco de dados relacional. Vamostentar entender isso em breve.

3.2 História

O protocolo LDAP foi desenvolvido originalmente por três pessoas em 1993: Steve Killi, TimHowes e Wengyik Yeong. O LDAP, que, como já sabemos, funciona sobre o padrão de diretóriosX.500 melhorado, foi uma tentativa bem sucedida de ser um protocolo compativel com o DAPe 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. Asrazõ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, comos protocolos TCP/IP.

Originalmente, o que veio a ser o LDAP era chamado de LDBP: Lightweight Directory BrowsingProtocol, 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 eeditar o diretórios, sendo chamado de LDAP, mas também passou a se manter autonomamentecomo servidor LDAP, se tornando uma alternativa independente do DAP, que ainda era mantidocompatí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 árvoree disponibilizar informações sobre algum objeto, normalmente pessoas, e de realizar a auten-ticação de usuários para frontends e aplicativos de maneira unificada. Para tanto o LDAP fazuso do PAM com o módulo pam_ldap. Como objetos finais visados por uma árvore podemos teroutras coisas que não pessoas como, por exemplo, arquivos ou cds que uma loja queira manterorganizados.

4.2 Que tipos de aplicativos podem utilizar LDAP?

Como o LDAP foi desenvolvido sobre TCP/IP, ele é um serviço integralmente compatível comos usos da internet. Em tese, todos aplicativos podem acessar dados de um servidor LDAP eatualizá-los, se tiverem as devidas permissões. A maiorida dos servidores de email tem suportea LDAP, ainda que, por hora, vários deles somente leiam dados mas não escrevam. O LDAPpode 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, oservidor deste cliente pode se dividir em várias máquinas LDAP. A lógica é simples, o cliente fazum pedido ao servidor, que por sua vez ou retorna os dados ou repassa o pedido a uma outramáquina que faz serviço de diretórios LDAP. Naturalmente, o(s) servidor(es) LDAP pode(m) estartanto na própria máquina cliente, quanto em uma rede ou na internet, como acontece na maioriaesmagadora dos casos. Em todos esses casos e especialmente no último, um único servidorLDAP, 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 umportal e ser autenticado em serviços de rede com um só login e com uma só senha armazenadosem 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 umserviç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 daquelade um banco de dados relacional. O LDAP, pois, suporta uma quantidade absurda de acessospara leitura ao mesmo tempo, mas não se adequa a usos que requeiram armazenamento dedados que devam ser freqüentemente atualizados, o que explica o uso típico de armazenamentode 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 únicoregistro que lista os campos com seus atributos. Cada ítem, por sua vez, é uma instância dealguma classe de ítens (objetos) escolhida que define que informações têm que estar e queinformações podem estar listadas no registro de suas instâncias. Cada item é único e podeser 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 econteúdos, que será esclarecido mais tarde, que torna seus dados intercambiáveis. Haver váriosfrontends que suportam LDAP e que são capazes de descrever um caminho completo a um ítemrequer um padrão de estrutura de diretórios. Podemos, enfim, referenciar um item específico epedir o retorno de seus dados ou parte destes passando ao servidor o caminho completo atravésda á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 árvorede diretórios LDAP é também chamada de DIT, Directory Information Tree. Um mesmo servidorLDAP 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 personalizadasde acesso tanto para leitura quanto para escrita a ramos inteiros de uma árvore de dados ou adiretó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 estipularos nomes que daremos a elas. O importante é que fiquemos familiarizados com a nomenclaturaem geral e que tenhamos uma visão panorâmica de tudo aquilo sobre o que vamos falar daquiem diante. Não é preciso que se domine todos os conceitos agora, pois vamos estudar aquelesainda 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éise posições diferenciadas para cada diretório e significam referências a um item ou a um ramoda á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 comoessas palavras, e vamos conhecer a solução desenvolvida, não poderíamos fazer referência aum determinado ponto da árvore sem apontar graficamente para ela.

Sem ainda nos preocuparmos em decorar ou entender os nomes, eis uma lista das palavrasmais 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 quenos 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 intercambiardados e links para que seja um serviço unificante, decidiu-se considerar o país como o ramo denível mais alto, a partir do qual saem todos outros ramos e antes do qual não há nada. São comoque o tronco da árvore de diretórios. Os códigos utilizados para designar os países são, não poracaso, 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. Emoutras palavras, são os primeiros galhos que saem do tronco do país. Podemos imaginar osvalores 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 serum 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 dizerrespeito a ’unb’ como uma unidade da organização ’universidades’, por exemplo. Uma ’ou’ podeestar 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 emseu 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), tipicamenteo CN ou o UID, quando o ítem é uma pessoa. O DN, sintaticamente, é uma lista de categorias ede 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 identificadordo item em questão. No exemplo de DN acima, o RDN seria "uid=tomas". O RDN deve ser capazde apontar para um único item dentro do componente seguinte listado no DN. O RDN deve seralgum atributo do item, mas não necessariamente um atributo cujo valor seja exclusivo do itemvisado, inclusive porque não há como evitar que o mesmo atributo de itens diferentes mantenhamo mesmo valor. Nesse caso, para acabar com a ambiguidade, um RDN pode apresentar mais deum valor separados por um sinal "+". Exemplo de DN cujo RDN ("uid=tomas+ou=suporte") possuimais 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 à árvoretoda. No caso, o nome do domínio onde se encontra a pessoa de uid ’tomas’ é o ’iti.br’. Essedomí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ínioatravé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 daslições ele se tornará mais claro.

22


5.9 Exemplo gráfico 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 comuma licensa própria compatível com a GPL. No momento em que este texto foi escrito, a versãomais recente do OpenLDAP era 2.3.25. Para baixá-la, podemos acessar "www.openldap.org/software/download".

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 doBerkeley 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 ocó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 emftp://ftp.sleepycat.com/releases/db-4.4.20.tar.gz. Para instalar os componentes necessários eposteriormente 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 osseguintes 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 docscom uma documentação geral sobre o Berkeley DB. Para realizar a instalação, acesse o diretóriomencionado, /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 baixadode http://www.openssl.org/source/openssl-0.9.8b.tar.gz. Procure em www.openssl.org/source umaversão mais recente. Com um terminal acessado com uma conta root, leve o código fonte baixadoaté 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 (nadaimpede que procurem um versão mais nova no diretório em que se encontra o arquivo que indicoabaixo; 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 etapaexperimente 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 dainstalação do OpenLDAP. Dentro da subpasta bin existem alguns utilitários como o ldapsearch, oldapcompare, 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émdeste 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 nosinteressam. O ldap.conf, que pouco vamos conhecer neste curso, é prioritariamente responsávelpelas ferramentas utilizadas pelo lado do cliente, como aquelas mencionadas que residem nodiretório /usr/local/bin. O slapd.conf vai estará mais sob o nosso foco, pois as informações nelecontidas 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ãoser armazenados no registro de um item. Semelhantemente à declaração do tipo de uma variávelem programação com tipos, a especificação do esquema que um ítem implementa determinaque atributos ele deve e pode ter. Por exemplo, um ítem relativo a uma pessoa deve ser aimplementação de um esquema para pessoas, o que vai exigir dele que tenha um atributo denome 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 porum 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 quedo qual o ítem i é um caso. Um atributo pode ter, entretanto, mais de um objectClass, fazendoparte de mais de um esquema.

Todo atributo ou objectClass utilizado em uma implementação LDAP deve estar definido emum esquema. Para que o servidor LDAP reconheça a classe, por sua vez, o slapd.conf deve estarbem configurado.

Uma implementação do LDAP deve ter ao menos um objectClass necessariamente, casocontrário não se poderia definir quaisquer ítens. O objectClass, em certo sentido, contém osoutros atributos.

Como já dizia, todos aqueles nomes apresentados como sendo palavras especiais do LDAPsão, na verdade, atributos pertencentes a e definidos por alguma objectClass. Cada atributopertence a pelo menos um objectClass, mas pode pertencer a mais. E são esses atributosaquilo que vai guardar o que queremos, os dados. E novamente as coisas ficam um pouco maiscomplicadas 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 umaclasses, 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 objectClasstêm necessariamente de ter nomes únicos. Vamos entender adiante que tipo de responsabilidadeas 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 esquemados qual se deriva, mais suas prórprias especificações, que podem eventualmente sobrepor asderivadas. Um oblectClass faz em geral, pois, parte de uma hierarquia de objectClasses, que sãomodulares nesse sentido, e que apontam para uma única definição abstrata, a classe top. Porexemplo, inetOrgPerson herda as definições de organizationalPerson que herda suas definiçõesde person que herda as suas de top, o todo das hierarquias de objectClass. O recurso de herançade especificações de esquemas ajuda-nos a evitar a redundância de declarações, tornando otrabalho com LDAP mais inteligente. Definindo variáveis e seu status As objectClass, que sãodefinidas dentro das classes, são responsáveis por definir o status de seus atributos para com osseus ítens. Ou seja, é na sua definição que vai estar descrito que aributos são permitidos e queatributos são necessários aos ítens que quiserem instanciar uma classe. Um objectClass podepossuir 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’. Esquemaspodem ser entendidos, basicamente, como conjuntos de definições de objectClasses. Talvez nãose lembrem das notas sobre a instalação, mas os arquivos de extenção ’.schema’ ficam todos nodiretó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 disponibilizarum 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 dosarquivos .schema tipicamente explica o propósito do esquema, e fornece algumas informaçõesimportantes como dependências (no caso de haver herança de definições, o que é comum, porser útil e aconselhável), algumas indicações de uso e de versões e dados relativos ao autor oua autora e endereços da internet. Rolem o texto do arquivo até o seu final. Note suas últimasdezoito 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 organizationalPersonSTRUCTURALMAY (

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 atributossã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 mesmoní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, quedefinirá 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émser 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 linguagensprogramações, um tipo. Ou seja, um atributo destinado a guardar números de telefone, porexemplo, pode esperar receber dados em forma de números, e não em letras, strings. A definiçãodos atributos também pode informar como os atributos respondem às buscas, permitindo buscassem consideração de caso, por exemplo.

Os atributos também herdam definições, como as definições de classes.Uma definição de atributoAinda 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 destinadoa armazenar o número de identificação da licença de motorista de uma pessoa. Note que esseatributo 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 caseIgnoreMatchSUBSTR caseIgnoreSubstringsMatchSYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

29


ExplicaçãoO 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 SYNTAXservem à função de especificar como o atributo deve reagir em comparações de valores quandoum 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 aplicadasnas comparações. A diferença entre EQUALITY e SUBSTR é que a primeira somente podeindicar regras que não contenham wildcards (caracteres especiais de expansão como ?, ., *). Aconsequê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 osoperadores >= 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 servidordo 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, todoarquivo de configuração possui algumas regras que permitem, por exemplo, que comentemos asnossas 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, eledeve ser contido dentro de aspas duplas.

• * Se um argumento contiver aspas duplas, estas devem ser precedidas com o caractere deescape padrão \.

• * Se um próprio argumento possuir o caractere barra invertida \, este deve ser precedidopor outra barra invertida de escape \.

A maior parte do slapd.conf especifica alguns parâmetros que vão reger o comportamentogeral do servidor, já o restante, ao final, diz respeito ao banco de dados utilizado, no nosso casoo dbd.

8.2 Esquemas - parte 1

O primeiro passo para editarmos o slapd.conf é decidirmos e setarmos os esquemas queserã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, porexemplo. Na verdade a pergunta está mais para se queremos armazenar informações sobrepessoas 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 comovistas 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 permitesaber em que informações ele pode estar interessado ou mesmo que dados exatamente ele podesolicitar.

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 objetosque um diretório LDAP vai querer utilizar vai estar definida no próprio core.schema, mas é claroque podemos aproveitar esquemas já maduros para instanciar classes de objetos mais persona-lizadas. Existem diversos esquemas já publicados que provavelmente satisfariam a maioria dosdiretórios LDAP, nos eximindo da necessidade de definirmos nossas próprias classes.

Para que decidam sobre que esquemas implementar, naveguem por cada um dos arquivosexistentes no diretório schema e notem as classes de objetos que cada um oferece tendo emvista 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 osconteú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 doslapd.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 dealgumas 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 doarquivo de suas definições. Boa parte dos esquemas, por exemplo, depende da presença docore.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 sistemao 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 desejamosque sejam passados sempre que o slapd for iniciado normalmente. Por padrão, o conteúdode /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 dizemrespeito 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çaentre 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 combinaras opções, simplismente somamos esses valores. Como podem ter notado, o sistema lembra aatribuição numérica de permissões a arquivos no sistema GNU/Linux.

33


-1 Todas informações0 Nenhuma informação1 Chamadas de funções2 Debug de pacotes (packet-handling)4 Debug detalhado de chamdas8 Gerenciamento de conexões16 Pacotes enviados e recebidos32 Processamento de filtros de busca64 Processamento de configurações de arquivo128 Processamento de Access Control Lists256 Estatísticas de conexões, operações e resultados512 Estatísticas de resultados enviados aos clientes1024 Comunicação com os backends do shell2048 Análise de entries

Como o próprio slapd.conf indica, podemos ler o manual do arquivo configuração do slapdcom o comando:

$ man slapd.confO 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 deconsulta 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 garantiressa segurança ao usuário em sua conexão com o servidor. Mas ainda assim esta página explicacomo 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 uma referência mais completa, consultem o manual do arquivo. Para nós, neste curso, precisamosde pelo menos duas linhas de configuração a princípio. Uma indicará ao slapd onde encontraro 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 vamosfazer agora.


Para gerá-lo vamos utilizar uma ferramenta em perl que funciona como uma ’interface’ para seconversar de forma amigável com o OpenSSL. Procure por CA.pl, que pode estar em /usr/lib/ssl/misc/CA.plou mesmo em /usr/local/misc/CA.pl, dependendo de como resolveu sua instalação. De qualquermaneira, 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 guardarcom muito cuidado. O certificado foi gerado com o nome de newcert.pem. Em sequência vamosretirar 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.pemdeve 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. Vamoscriar 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 dasegurança, caso fossemos armazenar dados de máxima importância. Neste caso recomendoque pesquisem sobre como utilizar o LDAP juntamente com o SASL. Nesse caso algumas linhasdeveriam ser adicionadas ao nosso arquivo e poderíamos setar a variável security acima comosasl. 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 setaroutras condições de uso, como obrigar todos que quiserem se conectar ao servidor a utilizar aversã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 queirammontar 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.confcom 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 informadosno lugar de <other>, como é explicado no trecho acima. Caso queira utilizar outro backend debanco exclusivamente, comente as linhas padrões do dbd. Outras possibilidades são:

bdb Berkeley DBdnssrv DNS SRVhdb Variante hierárquica do bdbldap Lightweight Directory Access Protocol (Proxy)ldbm Lightweight DBMmeta Meta Directorymonitor Monitor backendpasswd Utiliza o arquivo /etc/passwordperl Backend programável Perlshell Programa acessado via shellsql 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 deDomain 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 ocaso, reconhecer um usuário chamado rootdn. O rootdn, como o nome sugere, é o "nomedistinto"do super-usuário. Devemos nos lembrar que dn significa (Distinguished Name) "nomedistinto", que é o apelido para a coleção de diretórios/atributos que identifica exlusivamente umusuá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 poderiaser, 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 dopró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 quesaber 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 nosistema 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 odiretó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 queremoso 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 leiturae de escrita sobre estes arquivos (e nem ele com permissão de execução), então vamos atribuiro 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 possibilidadede associar os atributos a quatro categorias de otimização de buscas. Cada um dos índices cor-responde a uma "matching rule"definida 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ãodado;

• 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 habituandoaos usos dos atributos mais básicos. A minha sugestão é que pesquisem, se quiserem, e façamexperiências antes de levantar um slapd a servir o Brasil inteiro. Faça antes de uma maneira maisintuitiva 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 aplicativosvão no final das contas conversar com o serviço, e como este tenderá a crescer, o que torna adecisão pelo conjunto de índices uma decisão que exige maturidade. O autor deste curso não sehabilita 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 deAcesso. 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. Vejamosseu 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 qualquerterã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, ouseja, 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 utilizarstrings e/ou expressões regulares para nos referir a um DN específico. Bom, acredito que amelhor 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 nofundo é 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 muitasvezes 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 deuma 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 ummodifique 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 asintaxe mais simple:

access to * by * read

Como disse, este formato desempenha uma função diferente daquele qua primeira diretiva, quedefinia a política, desempenha, ainda que seus resultados sejam assemelhados. Enquanto aprimeira diretiva de permissões que mostrei está mais para uma política de acesso, a segundadiretiva, por sua vez, está mais para uma regra global de acesso - os usos de diretivas de políticase 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 regrassomente 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.orgde:

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 é dasmais 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 definidacom defaultaccess. Enfim, não funciona setarmos permissão de leitura de tudo a todos e emseguida restringir o acesso ao atributo userPassword a autenticação apenas. A primeira regra vaipermanecer regente, concedendo permissão de leitura de tudo a todos. Precisamos, pois, nestecaso, primeiro informar que só se pode acessar o atributo userPassword para autenticação (eescrita para autenticados, se for o caso, e tudo mais que seja específico) e depois sim informarque todos podem ler tudo. Neste exemplo o LDAP lerá a última regra já com a ressalva de queespecificamente o atributo userPassword só pode ser acessado para autenticação e escrita se foro 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ãochegamos a ver aqui, mas também o manual do slapd.conf. Este curso não pode cobrir todasdiretivas de configuração do slapd, logo ler o manual pode ser o primeiro e melhor passo parauma configuração mais personalizada do serviço.

44

Capítulo 11

LDIF

11.1 Introdução ao LDIF

O LDIF significa LDAP Data Interchange Format (Formato de traca de dados LDAP) e é umpadrão de arquivos-texto que permite a atualização do conteúdo de um diretório LDAP através doprocessamento de um texto simples contendo os dados a se processar no formato adequado. Oseu propósito é ser um meio humanamente hábil para a manipulação dos dados de um diretórioLDAP.

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 LDAPquanto para mantê-la atualizada posteriormente.

Como o conteúdo de um diretório LDAP se trata basicamente de atributos de itens e seusrespectivos valores, um arquivo LDIF é constituído basicamente de uma listagem de atributos deum item representado por um DN associados a seus respectivos valores de atribuição. Além doDN e da lista de atribuição, um arquivo LDIF pode possuir diretivas que informem ao interpretadordo LDIF como os dados deverão ser processados. Obviamente, além da própria sintaxe LDIF, umarquivo 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 maistarde, quando estivermos levantando os dados propriamente ditos, vamos conhecer exemplos doque poderiam ser LDIFs reais. É importante, no entanto, saber que o LDIF, para amazenar dadosinteligíveis ao LDAP, organiza as informações sobre cada objeto (ítens e diretórios) em blocosdistintos, 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ósesse 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 LDIFlinhas 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 identificados linha-a-linha, sendo que para que uma linhaseja reconhecida como um comentário ela deve ser iniciada com o caractere sharp "# ", como emscripts bash. A peculiaridade de um arquivo LDIF é que nele o caractere de comentário "# "temde estar necessariamente na primeira coluna da linha para ser corretamente interpretado. Porexemplo:

#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 emuma 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 paranos referirmos literalmente ao caractere # devemos escrever "# ". O mesmo vale para a seguintelista 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 final 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 queprecise ser continuado na linha de baixo, devemos iniciar a continuação na linha de baixo comum ú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 doispontos 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 definiçõ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 (ouaté mesmo na rede). Neste caso utilizamos o caractere ’<’ em sequência aos dois-pontos.

cn:< file://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órioLDAP, instalamos o slapd como seu serviço e configuramos o arquivo de configuração deste aomesmo tempo que fomos aprendendo mais sobre o que está envolvido em levantar um servidorLDAP. Ok, mas e os dados? Tudo o que fizemos até então foi um esforço para permitir queorganizássemos nossos dados da maneira como gostaríamos e não termos problemas cabaisde organização e de segurança. Como fazemos afinal para de fato colocarmos e mantermos osdados 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 efazer toda a manutenção de nosso servidor. Muitos vão sentir, no entanto, a tarefa de manter oservidor através das ferramentas de linha de comando muito sacrificiosa quando uma quantidadegrande de dados está envolvida. Mais tarde vamos saber de uma ou outra interface mais amigávelpara manipular os dados do diretório LDAP, mas é importante que conheçamos os utilitáriosbásicos de linha de comando, o que permite uma compreensão mais sólida da manutenção dosdados 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, ouseja, 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 acessoremoto costuma ser necessário). Existem também, no entanto, as ferramentas que fazem partedo 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á quea transferência de dados localmente costuma ser significativamente mais rápida. Estes utilitáriosdo slapd são especialmente funcionais localmente, e portanto nem sempre convenientes. É justolembrar que algumas das ferramentas locais foram já apresentadas en passant durante a liçãoem 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 dasslap..., 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. Passamospara o comando pelo menos três ou quatro parâmetros: o endereço e porta do diretório ao qualse conectar, o usuário a ser autenticado, sua senha e o arquivo LDIF contendo os dados a sereminseridos. 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âmetrospossí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 umramo de um diretório, tipicamente um usuário. Assim como o ldapadd, o ldapdelete recebe osparâmetros necessários para se conectar ao diretório e se autenticar como um usuário com suasenha. Por último, ele deve receber o DN do ítem a ser removido do diretório. Naturalmente, esteusuário deverá possuir as permissões setadas por ACLs para remover o ítem dado. Tipicamenteesse usuário é um administrador (não necessariamente de todo o servidor, mas possivelmentede 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=example,dc=com"Consulte o manual com o comando man ldapdelete para conhecer todas opções e parâmetros

possíveis, ou procure pelo manual na internet.

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, enfim, que ele sejautilizado para se adequar dados já existentes no servidor (além de poder substituir o ldapadd e oldapdelete). Este comando segue uma sintaxe como a do comando ldapadd, visto que se utilizade um arquivo LDIF para fornecer as informações a serem acrescentadas. Outros parâmetrosnecessários além do caminho do arquivo LDIF são, é claro, o endereço do servidor, o usuáriocom o qual se autenticar e sua senha. O ldapmodify exige que montemos nosso LDIF com umadiretiva 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 novosquando utilizarmos esse comando (ainda que possamos fazê-lo). A diretiva a qual me referi é achangetype, 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 atributoescolhido que vai servir para distinguir um ítem de outro em um mesmo ramo de diretório. Nãopode haver, portanto, dois RDNs iguais em um mesmo ramo na hierarquia. O atributo uid é umexemplo 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.ldifConsulte 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 dadosLDAP. 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. Oparâ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 umadeterminada organização, representada por um ramo da árvore.

Eis um exemplo de uso do ldapsearch, mostrando uma autenticação anônima com solicitaçãode busca pela raíz (-b) do ramo informado pelos dois atributos dados de todos os ítens, esperandopor uma resposta simpática do servidor (-u).

ldapsearch -h example.com -p 389 -b -u "ou=funcionarios,dc=example,dc=com"sn mailConsulte 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 sequeremos 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âmetrospossíveis, ou procure pelo manual na internet.

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 delogin (-D) e a senha deste (-w, para autenticação simples ou -W para autenticação com SSL). Umexemplo de uso do ldapbind poderia ser:

ldapbind -h example.com -p 389 -D "cn=admin-w senha-secretaConsulte o manual com o comando man ldapbind para conhecer todas opções e parâmetros

possíveis, ou procure pelo manual na internet.

12.8 Ferramentas offline (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 outrosutilitá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 dasmarcações. O slapindex nos permite atualizar e associar marcações (indexes) a atributos namedida 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 é maisadequado para a inserção de grandes quantidades de dados, visto que uma transferência localde dados costuma ser mais rápida que uma transferência online, e o slapadd é uma ferramentaoffline.

O slapcat tem a função de solicitar dados do servidor, analogamente ao ldapsearch, masretorna o conteúdo de todo um diretório e nos entrega um arquivo em LDIF. O slapadd e o slapcatrecebem 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 configuração, para caso queiramos apontar para outro caminho quenã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 dadosdevem 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órioLDAP 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 (namingcontext);

2. 2. a OU dos professores;

3. 3. a OU dos estudantes.

Esse tipo de modelo que utilizo regularmente como exemplo é uma aprensentação simplistado 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 representaruma organização de diretórios exemplar. Enfim, o exemlo acima não nos serviria como um estudocaso, 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ãoesperar corretamente que devemos começar nosso script por um DN, que vai abrir o primeirobloco 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=comdc: escolaobjectClass: dcObjectobjectClass: organizationalUnitou: 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 vamosinciar 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=comdc: escolaobjectClass: dcObjectobjectClass: organizationalUnitou: 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=comou: professoresobjectClass: organizationalUnit

#Pula-se outra linha# Implementação da OU dos estudantes:dn: ou=estudantes,dc=escola,dc=comou: estudantesobjectClass: organizationalUnit

Poderíamos, se fosse o caso, adicionar uma OU também para a diretoria da escola e outra paraos administradores do serviço, quem sabe, dependendo da política. Enfim, salve o arquivo emum diretório como por exemplo o /etc/ldap/ldif, que ainda não existe, mas que podemos criar paraguardar nossos scripts LDIF. Um nome para esse arquivo poderia ser base-escola.ldif. Vamosentã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 tiverpermissão para escrever no caminho do sistema designado pela diretiva directory, como setadano slapd.conf, digitem o seguinte comando:

# slapadd -l /etc/ldap/ldif/base-escola.ldifO 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 serpassados 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 passadoe 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 doque é uma árvore de diretórios LDAP. Simplificada pois um servidor LDAP maduro é capaz dereplicar dados e muitas vezes integrado a uma rede de forma a desempenhar funções como a deum servidor de logins (NIS), por exemplo. Ora, mas mesmo uma versão reduzida de banco dedados qualquer nos deveria permitir que consultássemos seus dados. Claro, vamos experimentarem 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 noar. Para utilizá-las, precisamos colocar o servidor para rodar. O servidor pode estar executávelem alguns locais possíveis do sistema (visto que as instalações podem ter sido diferentes, e emdiferentes 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/slapdstart. 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 arquivopadrã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á serexecutado. 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árioscomo o ldapadd, ldapmodify , ldapsearch, etc., não requerem qualquer autorização do sistemaque serve o LDAP, pois seu propósito é estarem disponíveis à rede, ao contrário das ferramentasslap...(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 requeremque 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 debusca, como com qualquer serviço de banco de dados. Basicamente podem ser feitas duasperguntas por essa delimitação: "o quê?"e "onde?". Cada uma destas perguntas é respondidacom dois parâmetros. A primeira com o parâmetro de filtro de busca e com uma lista de atributosque pode interessar daquilo que for filtrado. A segunda com o parâmtro -b que deve designaratravés de um DN dado uma posição na árvore a partir de qual o diretório deve ser vistoriado adentro.

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. Observemtambém que não nos autenticamos, mas que como usuários anônimos temos acesso de leituraao nosso diretório, se é o caso de não o terem desabilitado com uma regra de ACL. Para nosautencticarmos 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 consultacom as credenciais do superusuário (RootDN). Neste caso, usaríamos os parâmetros -D (seguidodo 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 servidorestiver 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ê-loatravés de um dump LDIF do diretório através do slapcat. Em seguida podemos reinserí-lo emoutro ponto da árvore com o ldapadd. Essa é uma boa alternativa para quem precisa modificardiversos dados de diretório estático que possa estar fora do ar durante alguns minutos sem se terque elaborar um grande LDIF a ser utilizado com o ldapmodify. Para deletar tudo o que estiverabaixo 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ãoconhecí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 quefalá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 esmagadoradas vezes, também uma outra máquina) replicando seus dados para este, ou seja, o mantendocomo sua réplica. Um administrador LDAP pode ter vários bons motivos para querer implementara replicação de dados. Basicamente, os motivos se devem a escassez de recursos relativa aouso de um servidor, seja essa uma escassez de memória, de processamento ou de banda derede.

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 demandapermanete), o replicado, e um replicante que eventualmente podesse sair do ar para entrar emmanutençã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. Estarazão, aliás, é quase sempre uma razão por si só, visto que muitas empresas e organizaçõessimplismente 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 paraoutro. Ou seja, existe um outro serviço que deve ser inicado para que a replicação aconteça. Seconfigurado para tanto, o servidor base exporta um arquivo de log que vai ser interpretado peloslurpd cujos dados vão ser por este atualizados no servidor replicado, através das operaçõesLDAP que já conhecemos. Não instalamos o slurpd. Para habilitar sua compilação durante oprocesso do ./configure temos de passar o argumento –enable-slurpd.

Iluminando um pouco o caminho daqueles que possam se interessar, para implementar umareplicaçã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 quantodo replicado e pela cópia estática do conteúdo deste para o servidor a ser replicado. Com osservidores reiniciados, o processo é natural. O segredo está, pois, em como editar cada um dosdois arquivos (assumindo que se tem o slurpd disponível no sistema). Uma busca no google porslurpd 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 simplesobjetivo de informar alguns sobre sua existência e seus propósitos. Assumimos até então quetodos diretórios LDAP que estavam sob um mesmo domínio estivessem rodando também em ummesmo 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 formaque enquanto o seu topo é servido em uma determinada máquina, cada unidade organizacionalsubsequente, 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 deuma máquina em particular assim como para adequar a estrutura física do diretório a uma dadaestrutura administrativa, de forma que o responsável por cada seção da árvore possa manterseus 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 diretivassuffix, 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óprialinha de comando. Elas permitem, em geral, que visualizemos a estrutura da árvore LDAP e aspermissõ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ãolistadas as interfaces mais conhecidas de gerenciamento de diretórios LDAP:

phpLDAPadminTalvez 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 asferramentas para o gerenciamento e a manutenção do diretório.

LDAP Browser/EditorEste 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 tarefasnão administrativas.

Directory AdministratorEste 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 workwith OpenLDAP 2.2 or newer, unless schema checking is disabled. Set "schemacheck off"in theslapd.conf and restart OpenLDAP."

59

ldap

Documents