Sunteți pe pagina 1din 150

André Luiz Félix Pacheco

Eduardo Luiz da Silva


Luiz Gustavo Queiroga Pena
Márcio Flávio da Silva
Tiago Alves de Assis

Gerenciamento de Usuários em Ambiente Corporativo, Utilizando


LDAP - Lightweight Directory Access Protocol

Ciência da Computação
FIPLAC – 2005.

André Luiz Félix Pacheco


Eduardo Luiz da Silva
Luiz Gustavo Queiroga Pena
Márcio Flávio da Silva
Tiago Alves de Assis

Gerenciamento de Usuários em Ambiente Corporativo, Utilizando


LDAP - Lightweight Directory Access Protocol

Monografia apresentada como exigência para


obtenção do grau de Bacharel em Ciência da
Computação, sob a orientação do Professor
Gerson.

2
Ciência da Computação
FIPLAC – 2005.

DEDICATÓRIA

Dedicamos ao Professor Gerson Gimenes, nosso orientador, pelos esclareci-


mentos e o acompanhamento de nossas pesquisas. Dedicamos também aos professores do cur-
so de Ciência da Computação, por nos terem dado a oportunidade de adquirir os conhecimen-
tos necessários para um bom aproveitamento ao longo do curso e também por nos fazer mu-
dar a forma de pensar, quebrando paradigmas, questionando, fazendo análises críticas e tra-
zendo novas soluções para que nossas idéias fossem condizentes ao ambiente universitário em
que fomos inseridos.
Gostaríamos também de agradecer a todo o apoio e compreensão de nossos
familiares durante todo o curso e principalmente nesse último semestre em que estivemos
empenhados em desenvolver nosso projeto final. Agradecimentos especiais à: Andressa
Dantas, Renata e Lucca Ramos Silva, Dalva Pacheco Alves, Angélica dos Santos
Vasconcellos, Francisco de Paulo Pacheco, Maria Sebastiana Pacheco, Sandra Aparecida
Alves de Assis, João Divino de Assis, Cristiane de Freitas Matos, Olga Alves Pena de
Queiroga, Agostinho Joaquim de Queiroga, Paula Rejane Queiroga Pena, Hégonn William
Queiroga Pena e Mara Juliana Soares Marques.

3
TERMO DE APROVAÇÃO

Monografia apresentada e aprovada em __/__/__, pela banca examinadora


constituída pelos professores:

Prof ...

Prof ...

Prof ...

FIPLAC , __ de ____________ de 2005.

4
SUMÁRIO

Dedicatória................................................................................................................................................................3
Lista de figuras..........................................................................................................................................................8
Abstract.....................................................................................................................................................................9
Resumo....................................................................................................................................................................10
Capítulo I – Introdução...........................................................................................................................................11
1.1. Introdução....................................................................................................................................................11
1.2. Motivação.....................................................................................................................................................12
1.3. Objetivo Geral..............................................................................................................................................12
1.4. Objetivos Específicos...................................................................................................................................12
1.5. Metodologia.................................................................................................................................................13
Capítulo II – Diretórios...........................................................................................................................................14
2.1 - O que é um diretório...................................................................................................................................14
2.2 - Vantagens de usar um diretório..................................................................................................................15
2.3 - Diretórios distribuídos................................................................................................................................16
2.4 - Diretório Cliente E Servidor.......................................................................................................................17
Capítulo III – LDAP................................................................................................................................................19
3.1. Histórico do LDAP.......................................................................................................................................19
3.1.1. Precursores do LDAP................................................................................................................................19
3.1.2. Versões e características............................................................................................................................20
3.1.3. RFC’s que padronizam o LDAP...............................................................................................................21
3.1.4. O LDAP atualmente..................................................................................................................................23
3.2. LDAP Lightweight Directory Access Protocol............................................................................................23
3.3. LDAP: Protocolo ou diretório......................................................................................................................24
3.4. Arquitetura...................................................................................................................................................25
3.5. Modelos LDAP...........................................................................................................................................25
3.5.1. Modelo da informação..............................................................................................................................26
3.5.2. Modelo de nomes......................................................................................................................................26
3.5.3. Modelo Funcional.....................................................................................................................................27
3.5.4. Modelo de segurança.................................................................................................................................27
3.6. LDIF............................................................................................................................................................27
3.7. Classes de Objetos, Atributos e Esquemas...................................................................................................28
3.8. Segurança.....................................................................................................................................................31
3.8.1. Segurança no LDAP.................................................................................................................................32
3.8.2. Sem Autenticação.....................................................................................................................................33
3.8.3. Autenticação Básica.................................................................................................................................33
3.8.4. Autenticação simples e camada segura (SASL - Simple Authentication and Security Layer)................33
3.8.5. SSL e TLS................................................................................................................................................35
Cliente.....................................................................................................................................................................36
Servidor...................................................................................................................................................................36
3.8.6. Outros mecanismos de autenticação SASL..............................................................................................37
3.9. ACL.................................................................................................................................................................37
3.9.1. Autorização..............................................................................................................................................37
3.9.2. Políticas de Segurança..............................................................................................................................38
3.9.3. Definindo Listas de Controle de Acesso..................................................................................................38
3.9.4. Aspectos Gerais do modelo ACL para LDAP.........................................................................................39
3.9.5. Semântica / Política..................................................................................................................................39
Usabilidade..........................................................................................................................................................40
3.10. Replicação.................................................................................................................................................40
3.10.1. Replicação no LDAP..............................................................................................................................42
3.10.2. Daemon “SLURPD”.............................................................................................................................42
3.10.2.1. Log de replicação e aquivos auxiliares...............................................................................................43
3.10.2.2. Modos de operação..............................................................................................................................44
3.10.2.3. Funcionamento....................................................................................................................................44
5
3.10.3. Ocorrência de falhas no SLAPD e no SLURPD durante a replicação....................................................45
3.10.4. Concluindo replicação............................................................................................................................45
3.11. Banco de Dados x LDAP...........................................................................................................................46
3.11.1. Banco de dados relacional.......................................................................................................................46
3.11.2. Banco de dados hierárquico....................................................................................................................46
3.12. X.500 x LDAP...............................................................................................................................................47
3.12.1. Protocolo DAP.......................................................................................................................................47
3.12.2. Protocolo LDAP......................................................................................................................................48
3.12.3. Vantagens do LDAP...............................................................................................................................49
Desempenho........................................................................................................................................................49
3.12.5. Comparações DAP x LDAP...................................................................................................................50
Capítulo IV – Principais Ferramentas LDAP..........................................................................................................53
4.1. Introdução.....................................................................................................................................................53
4.1.1 Freeware.....................................................................................................................................................53
4.1.2 Open Source...............................................................................................................................................54
4.1.3 Ferramentas LDAP.....................................................................................................................................54
4.2. PHP LDAP ADMIN.....................................................................................................................................54
4.2.1 Características............................................................................................................................................55
4.2.2 Criando entradas de LDAP........................................................................................................................56
4.2.3 Editando entradas.......................................................................................................................................57
4.2.4 Manutenção de dados.................................................................................................................................58
4.2.5 Buscas de LDAP........................................................................................................................................58
4.2.6 Sustentação comercial de servidor LDAP..................................................................................................59
4.2.7 Novell.........................................................................................................................................................59
4.2.8 Sun ONE Directory Server.........................................................................................................................60
4.2.9 Microsoft ActiveDirectory.........................................................................................................................61
4.2.10 Sustentação internacional da língua.........................................................................................................61
4.3. YALA ..........................................................................................................................................................62
4.3.1 Características............................................................................................................................................62
4.4 LDAP Browser/Editor ..................................................................................................................................70
4.4.1 Características: ..........................................................................................................................................70
4.5. SMBLDAP...................................................................................................................................................71
Capítulo V – O LDAP e o Gerenciamento de Usuários..........................................................................................72
5.1. Usuários........................................................................................................................................................73
5.2. Gerenciamento.............................................................................................................................................73
5.3. Gerenciamento de Usuários.........................................................................................................................73
5.4. LDAP no Gerenciamento de Usuários.........................................................................................................74
Conclusão................................................................................................................................................................76
Anexo I – Documentação acerca da Implementação do Protocolo LDAP para Gerenciamento de Usuários........77
1. Objetivo geral..................................................................................................................................................77
2. Descrição e abrangência..................................................................................................................................78
3. Recursos de hardware e software....................................................................................................................78
3.1. GNU/Linux – Kurumin................................................................................................................................79
3.2 OpenLDAP....................................................................................................................................................79
3.2.1. SLAPD......................................................................................................................................................79
3.2.2 Backend de Banco de Dados – BerkeleyDB..............................................................................................80
3.3. APACHE, PHP e PHPLDAPADMIN.........................................................................................................81
3.4. Microsoft Windows XP®.............................................................................................................................81
3.5 Outlook Express®.........................................................................................................................................82
4. Configurações..................................................................................................................................................82
4.1 Servidor ........................................................................................................................................................82
4.1.1 BerkleyDB..................................................................................................................................................82
4.1.1.1 Instalação e configuração.......................................................................................................................82
4.1.2 OpenLDAP.................................................................................................................................................84
4.1.2.1 Instalação e configuração........................................................................................................................84
4.1.2.2 Migração.................................................................................................................................................91
4.1.3 Sistema de Autenticação............................................................................................................................93
4.1.3.1 PAM e NSS............................................................................................................................................93
4.1.3.2 Instalação e Configuração do NSS e PAM............................................................................................93
4.1.4 Samba.........................................................................................................................................................98
4.1.4.1 Instalação e Configuração.......................................................................................................................98
6
4.1.5 Smbldap-tools...........................................................................................................................................101
4.1.5.1 Instalação e configuração......................................................................................................................102
4.1.6 Apache......................................................................................................................................................106
4.1.6.1 Instalação e Configuração.....................................................................................................................107
4.1.7 PHP...........................................................................................................................................................112
4.1.8 PHPLDAPADMIN...................................................................................................................................113
5.1 Estação de trabalho......................................................................................................................................118
5.1.1 Autenticação.............................................................................................................................................118
Configuração.....................................................................................................................................................118
Cliente de E-mail...............................................................................................................................................120
5.1.2.1 Outlook Express...............................................................................................................................120
5.1.2.2 Pesquisa de Informações ......................................................................................................................122
6. Esquema de Funcionamento..........................................................................................................................123
7. Simulação do ambiente.................................................................................................................................124
7.1 Usuários e Grupos.......................................................................................................................................125
Criação de Grupos e Usuários...........................................................................................................................125
7.1.1.1 Autenticação..........................................................................................................................................126
Anexo II – RFC’s..................................................................................................................................................131
RFC 1777..........................................................................................................................................................131
RFC 1779..........................................................................................................................................................131
RFC 1798 .........................................................................................................................................................131
RFC 1823..........................................................................................................................................................132
RFC 1959..........................................................................................................................................................132
RFC 2044..........................................................................................................................................................132
RFC 2251..........................................................................................................................................................132
RFC 2252..........................................................................................................................................................133
RFC 2253..........................................................................................................................................................133
RFC 2254..........................................................................................................................................................133
RFC 2255..........................................................................................................................................................134
RFC 2256 ........................................................................................................................................................134
RFC 1487..........................................................................................................................................................134
RFC 1558..........................................................................................................................................................135
RFC 1778..........................................................................................................................................................135
RFC 1960..........................................................................................................................................................135
RFC 2079..........................................................................................................................................................135
RFC 2116..........................................................................................................................................................136
RFC 2164..........................................................................................................................................................136
RFC 2247..........................................................................................................................................................136
RFC 2307 .........................................................................................................................................................137
RFC 2377..........................................................................................................................................................137
RFC 2559..........................................................................................................................................................137
RFC 2596..........................................................................................................................................................137
RFC 2649..........................................................................................................................................................138
RFC 2696..........................................................................................................................................................138
RFC 2587..........................................................................................................................................................138
RFC 2589..........................................................................................................................................................139
RFC 2657..........................................................................................................................................................139
RFC 2713..........................................................................................................................................................139
RFC 2739..........................................................................................................................................................140
RFC 2798..........................................................................................................................................................140
RFC 2820..........................................................................................................................................................140
RFC 2829..........................................................................................................................................................141
RFC 2830..........................................................................................................................................................141
RFC 2849..........................................................................................................................................................141
RFC 2891..........................................................................................................................................................141
RFC 2926..........................................................................................................................................................142
RFC 2927..........................................................................................................................................................142
RFC 3045..........................................................................................................................................................142
RFC 3062..........................................................................................................................................................143
RFC 3088..........................................................................................................................................................143
RFC 3112..........................................................................................................................................................143
7
RFC 3296..........................................................................................................................................................143
RFC 3352..........................................................................................................................................................144
RFC 3377..........................................................................................................................................................144
RFC 3383..........................................................................................................................................................144
RFC 3384..........................................................................................................................................................145
RFC 3494..........................................................................................................................................................145
RFC 3663..........................................................................................................................................................145
RFC 3671..........................................................................................................................................................145
RFC 3672..........................................................................................................................................................146
RFC 3673..........................................................................................................................................................146
RFC 3674..........................................................................................................................................................146
RFC 3687..........................................................................................................................................................146
RFC 3698..........................................................................................................................................................147
RFC 3703..........................................................................................................................................................147
RFC 3712..........................................................................................................................................................147
RFC 3727..........................................................................................................................................................147
RFC 3771..........................................................................................................................................................148
RFC 3829..........................................................................................................................................................148
Bibliografia............................................................................................................................................................149

LISTA DE FIGURAS

Figura 1 - Representação, requisições feitas de clientes de LDAP a um servidor LDAP......................................18


Figura 2 - Árvore de diretório.................................................................................................................................26
Figura 3 - Mecanismo SASL...................................................................................................................................35
Figura 4 - SSL/TLS no relacionamento com outros protocolos..............................................................................35
Figura 5 - Acordo SSL/TLS....................................................................................................................................36
Figura 6 - Sistema com uma única base..................................................................................................................41
Figura 7 - Sistema com a base distribuída...............................................................................................................41
Figura 8 - Replicação do servidor mestre para os sevidores escravos..................................................................42
Figura 9 - Serviço de replicação..............................................................................................................................43
Figura 10 - Funcionamento X500 x LDAP.............................................................................................................48
Figura 11 - Página Inicial do phpLDAPadmin........................................................................................................56
Figura 12 – Criação de entradas..............................................................................................................................57
Figura 13 – Opções de manuseio phpLDAPadmin.................................................................................................57
Figura 14 – Formulário de buscas...........................................................................................................................58
Figura 15 - Entrada de certificado LDAP Novell...................................................................................................59
Figura 16 - Grupo de administradores do diretório SUN ONE...............................................................................60
Figura 17 - Entrada Microsoft ActiveDirectory......................................................................................................61
Figura 18 - Tela do início de uma sessão do YALA...............................................................................................63
Figura 19 – Árvore e índices de entrada específica................................................................................................63
Figura 20 – Sendo executado no Internet Explorer................................................................................................64
Figura 21 - Árvore de buscas no frame direito........................................................................................................68
Figura 22 – Criação de uma nova entrada...............................................................................................................68
Figura 23 – Browser text-mode...............................................................................................................................69
8
Figura 24 – LDAP Browser editor..........................................................................................................................71
Figura 25 – Tela de login do SMLDAP..................................................................................................................72
Figura 26 – apt-get listando os pacotes e suas dependências..................................................................................85
Figura 27 - apt listando os pacotes slapd e suas dependências...............................................................................86
Figura 28 – Debconf iniciado, para iniciar os primeiros parâmetros do servidor LDAP.......................................88
Figura 29 - Debconf pergunta sobre compatibilidade para o LDAPv2...................................................................88
Figura 30 – Debconf na configuração do slapd, solicitando a senha do administrador..........................................89
Figura 31 - Debconf inicia os parâmetros de configuração do nss-ldap.................................................................94
Figura 32 - Debconf solicita a base DN do LDAP..................................................................................................95
Figura 33 – Debconf pergunta qual versão LDAP foi instalada.............................................................................95
Figura 34 – Debconf solicita o usuário administrador da Base DN........................................................................96
Figura 35 – Arquivo de configuração do cliente LDAP.........................................................................................97
Figura 36 – Arquivo de configuração do nsswitch.................................................................................................97
Figura 37 – smbldap-populate inserindo entradas na base dc=ldap, dc=df..........................................................106
Figura 38 - apt lista os pacotes do apache e suas dependências............................................................................107
Figura 39 - apt obtendo os pacotes de mirrors como ftp.br.debian.org.................................................................112
Figura 40 - apt iniciando a instalação do php-ldap e php4-pear...........................................................................113
Figura 41 - apt instalando o pacote phpldapadmin e o obtendo............................................................................113
Figura 42 - Debconf iniciando as primeiras configurações do phpldapadmin......................................................114
Figura 43 - Debconf solicitando qual o servidor está instalado no sistema..........................................................115
Figura 44 - Tela inicial do phpldapadmin.............................................................................................................116
Figura 45 – Tela do Outlook express, configuração de contas.............................................................................121
Figura 46 – configuração do serviço LDAP no Outlook express.........................................................................121
Figura 47 – Configurações avançadas do serviço LDAP no outlook...................................................................122
Figura 48 – representa uma busca pelo nome através da Base LDAP..................................................................123
Figura 49 – Esquema de funcionamento do Protótipo..........................................................................................124
Figura 50 – Konqueror acessando o serviço samba, ainda sem usuário definido.................................................126
Figura 51 – Acessando a pasta dados como usuário do grupo material................................................................127
Figura 52 – Acesso Negado a pasta Dados como usuário usermaterial................................................................128
Figura 53 – Acesso a pasta dados como usuário do grupo dados.........................................................................128
Figura 54 – Navegação na pasta dados como usuário userdados..........................................................................129
Figura 55 – Mostra o PDC já mapeado como unidade H:....................................................................................130

ABSTRACT

The present work, has for objective to demonstrate the use of the LDAP in the
management of users. The functionalities will be demonstrated that are making of this a
market standard such as: high availability, integration, security, response, etc. It will be dealt
with directories and as they can be available. The description of the LDAP will approach
since its origin, when he was used as interface for the server of directory X.500 until its
standardization (Protocol). An internal vision of the LDAP, where they find its main
characteristics as Lists of Control of Access, projects of functioning and storage of

9
information. Finally, a practical demonstration, based in free platform, of as the LDAP is
useful in the management of users.

RESUMO

O presente trabalho, tem por objetivo demonstrar a utilização do LDAP no


gerenciamento de usuários. Serão demonstradas as funcionalidades que estão fazendo deste
um padrão de mercado tais como: alta disponibilidade, integração, segurança, replicação, etc.
Será tratado de diretórios e como eles podem estar disponíveis. O histórico do LDAP
abordará desde sua origem, quando era utilizado como interface para o servidor de diretório
X.500 até a sua padronização (Protocolo). Uma visão interna do LDAP, onde se encontram
suas principais características como listas de controle de acesso, esquemas de funcionamento
e de armazenamento de informações. Por fim, uma demonstração prática, baseada em
plataforma livre, de como o LDAP é útil no gerenciamento de usuários.

10
CAPÍTULO I – INTRODUÇÃO

1.1. INTRODUÇÃO

Com a tecnologia tornando-se indispensável nas grandes corporações e essas,


na sua grande maioria, descentralizadas, surge a necessidade de controlar as informações,
desde equipamentos até usuários da rede. Com isso, nascem ilhas de informações que podem
vir a ficar obsoletas pela dificuldade de atualização e também pela descentralização.
O gerenciamento de usuários é um instrumento importante para as grandes
organizações e o principal meio pelo qual ele pode ser feito é através de um serviço de
diretórios. Este serviço de diretório trás facilidade de organização das informações afins,
reduzindo assim, boa parte dos problemas da organização.
Nesse documento será abordado uma das soluções mais versáteis do mercado
atual, utilizada por grandes empresas que geralmente possuem filiais espalhadas por vários
pontos do mundo, esse serviço de diretório é chamado de LDAP (Lightweight Directory
Acces Protocol) ou Protocolo Leve de Acesso a Diretórios, que já existe há alguns anos, mas
há pouco tempo começou a se popularizar, decorrente principalmente do desenvolvimento da
ferramenta OpenLDAP.
O protocolo LDAP é uma ferramenta que utiliza uma árvore de diretórios para
sua organização, podendo ser feito um organograma da empresa e das suas filiais em um só
sistema utilizando vários servidores LDAP integrados, unificando toda a base de informação
em um só sistema integrado.

11
Uma das grandes capacidades do LDAP é a sua interação com softwares
variados, tais como: servidores de e-mail, cliente de e-mail, browsers, sistemas operacionais e
protocolos de rede.
Este estudo será dividido em cinco capítulos: o primeiro fala sobre os
principais conceitos de diretórios. O segundo trata dos serviços de diretórios sobre protocolos
LDAP, características e estrutura sobre arquivos gerados, modelos e conceitos referentes às
classes de objetos. O terceiro diz respeito ao histórico do protocolo LDAP, surgimento e
transformações até os dias atuais e perspectivas. O quarto fala da padronização do LDAP,
RFC’s envolvidas e principais ferramentas utilizadas. O quinto mostra as vantagens da
utilização do LDAP e os comparativos de desempenho. Finalmente o sexto, mostra a
implementação de um protótipo, ferramentas, estruturas utilizadas e resultados.

1.2. MOTIVAÇÃO

O LDAP por se tratar de um protocolo com uma grande área de atuação e


amplamente utilizado por corporações e vem se tornando um padrão de mercado, pois
implementa com extrema facilidade a otimização de informações reunidas numa base de
informações.
É visto como uma realidade nas grandes empresas, sendo tratado pelos
especialistas como uma solução eficaz para os problemas de gerenciamento de usuários,
autenticação, hierarquia organizacional, criptografia entre outros.
A importância do estudo do LDAP vem da necessidade de se reunir uma gama
de informações de forma rápida e segura utilizando serviços de diretórios.

1.3. OBJETIVO GERAL

Apresentar um estudo sobre o protocolo LDAP e suas aplicações, focando


principalmente o gerenciamento de usuários em ambiente corporativo . Também demonstrar
na prática sua arquitetura funcional.

1.4. OBJETIVOS ESPECÍFICOS

Este estudo tem como objetivos específicos:


• Apresentar conceitos básicos sobre diretórios;
12
• Conceituar e descrever os aspectos do protocolo LDAP;
• Apresentar arquivos gerados pelo padrão LDAP (LDIF);
• Citar as principais ferramentas opensource de mercado para as
aplicações LDAP;
• Discorrer sobre o LDAP na gerência de usuários;
• Demonstrar o ambiente de funcionamento LDAP.

1.5. METODOLOGIA

A metodologia utilizada para o desenvolvimento deste estudo será a pesquisa


bibliográfica em fontes escritas como; livros, artigos e manuais, bem como:
• Pesquisas na Internet;
• Orientação e supervisão semanal do Prof. Orientador;
• Reuniões Semanais do grupo para prover um bom desenvolvimento do
trabalho proposto;
• Correio eletrônico (e-mail)
• Visitas a empresas e consultas a profissionais especializados no
assunto.

13
CAPÍTULO II – DIRETÓRIOS

2.1 - O QUE É UM DIRETÓRIO

O termo diretório significa lista de informações sobre um arranjo de objetos


com detalhes ordenados. Partindo desse princípio objetos podem ser arquivos de um sistema,
serviço de rede, lista de endereços, sistema de domínio de nomes - DNS1, sistema de
informações de redes - NIS 2, listas telefônicas e etc. [JOHNER,1998]
A todo instante se vê exemplo de lista de objetos, um deles é a lista telefônica
que, como um diretório, tem objetos e neste caso, são pessoas e os nomes desses objetos estão
ordenados alfabeticamente. Cada uma dessas pessoas tem alguns dados detalhados tais como:
o endereço e o número de telefone. Um outro exemplo cabível seria um catálogo de livros de
uma livraria, onde os livros estariam ordenados por autor, por título, ISBN ou qualquer outra
informação de publicação.
Em termos técnicos, um diretório é uma base de dados especializada, também
chamada de repositório de dados, que armazena e organiza informações sobre objetos. Um
determinado diretório pode ter informações sobre: impressoras distribuídas na rede, no qual
deve listar informações sobre impressoras (objeto), velocidade de impressão por minuto
(numérico), fluxo de impressão suportada (PostScript 3 ou ASCII4) e assim por diante.
1
Domain Name System – Sistema de Nome de Domínio. Amplamante utilizado na internet.
2
Name information system - Serviço de Informação de Rede.
3
Linguagem projetada para fazer uma coisa apenas; descreve de forma extremamente apurada tudo o que
contém uma página.
4
Código de caracteres de texto

14
Os diretórios corporativos normalmente contêm informações de um vasto
número de objetos em sua rede, que vão desde informações de equipamentos a detalhe de um
funcionário de uma dada filial. Com essas informações, esses diretórios permitem aos
usuários utilizá-los para a busca de, por exemplo, um endereço de e-mail ou para encontrar
algum equipamento específico ou até mesmo para buscar informações sobre o faturamento de
um cliente.
Nos diretórios em geral, quando é conhecido algum atributo que sirva como
parâmetro de busca é possível conhecer os demais atributos ou características desse objeto.
Isso é similar a procurar um nome em uma lista telefônica. Entretanto, diretórios em
informática são muito mais flexíveis do que uma lista telefônica, pois podem ser procurados
por um critério específico, não por algumas categorias pré-definidas.

2.2 - VANTAGENS DE USAR UM DIRETÓRIO

Um diretório de aplicação específica5 armazena somente a informação


necessária por uma aplicação particular e não é acessível por outras aplicações, pois um
serviço de diretório com todas as funcionalidades é complexo para se construir e os diretórios
de aplicação específica são tipicamente muito limitados, provavelmente armazenam somente
um tipo específico de informação, não têm potencialidades de busca, não suportam a
replicação e a divisão e provavelmente não têm um pacote completo de ferramentas para
administração.
Em tal ambiente, cada aplicação cria e controla seu próprio diretório, que se
transforma rapidamente num pesadelo administrativo. O mesmo endereço de e-mail
armazenado pela aplicação do calendário pode também ser armazenado por uma aplicação do
correio e também por uma aplicação que notificasse operadores de sistema a respeito de
problemas do equipamento. Manter cópias múltiplas da informação é difícil, especialmente
quando as relações de servidor são diferentes e até mesmo os administradores de sistema
envolvidos são diferentes.
O que é necessário é um diretório comum, independente da aplicação. Sendo
assim os desenvolvedores de aplicação poderiam ser certificados da existência de um serviço
do diretório, então os diretórios de aplicação específica não seriam necessários. Entretanto,
esses diretórios devem ser baseados em um padrão aberto que seja suportado por muitos

5
Diretório onde contém informações úteis a aplicações específicas
15
distribuidores e em muitas plataformas. Deve ser acessível com um API 6 padrão. Deve ser
extensível de modo que possa prender os tipos de dados necessários às aplicações arbitrárias e
deve fornecer uma funcionalidade completa sem requerer recursos excessivos em sistemas
menores. Assim, como mais usuários e aplicações acessarão e dependerão do diretório
comum, outras características importantes seriam: a robustez e a segurança com grande
escalabilidade.
Com tal infra-estrutura de diretório, os desenvolvedores de aplicação podem
alocar seu tempo para desenvolver novas aplicações em vez de desenvolver diretórios de
aplicação específica. Da mesma maneira que os desenvolvedores confiam na infra-estrutura
das comunicações de TCP/IP7 e de Chamada de Procedimento Remoto (RPC)8 [RFC 1831]
para os livrar do fluxo da comunicação de baixo nível, poderão confiar em poderosos serviços
de diretório completo.
Armazenar dados em um diretório e os compartilhar entre aplicações, reduz
gasto de tempo e dinheiro mantendo a manutenção com um baixo custo.

2.3 - DIRETÓRIOS DISTRIBUÍDOS

Os termos locais, globais, centralizados, e distribuídos são usados


freqüentemente para descrever um diretório. Estes termos significam coisas diferentes em
contextos diferentes. O termo local significa algo que está fisicamente próximo. Global
significa que é algo que engloba um universo de interesses. O universo de interesse pode ser
uma companhia ou um país. Centralizado significa que algo é, como o próprio nome diz,
centralizado em um lugar e distribuído significa que algo está espalhado fisicamente no
universo de interesses.
As informações armazenadas em um servidor de diretório podem ser locais ou
globais, dependendo do escopo e de sua utilização. Um diretório que tenha informações sobre
um departamento, tem um contexto local. Essas mesmas informações, num contexto maior,
como informações de uma corporação, teriam uma visão global.
Os clientes que por ventura acessem a informação no diretório podem ser
locais ou remotos. Os clientes locais são todos situados no mesmo edifício ou na mesma LAN

6
Application Programming Interface, um conjunto de funções e sub-rotinas usadas pelos programas que
informam ao sistema operacional como executar determinada tarefa.
7
Transmission Control Protocol / Internet Protocol.
8
É um protocolo que os programas usam para requisitar serviços de outros programas rodando em servidores
num ambiente de rede
16
9
Rede local. Os clientes remotos estão geograficamente dispersos através do continente ou do
planeta.
O próprio diretório pode ser centralizado ou distribuído. Se um diretório for
centralizado ele pode ser um servidor de diretório em um local ou um servidor do diretório em
um sistema distribuído. Se o diretório for distribuído, há múltiplos servidores espalhados no
universo de interesse que fornecem o acesso ao diretório.
Quando um diretório é distribuído, a informação armazenada no diretório pode
ser dividida ou replicada. Quando a informação é dividida, cada servidor de diretório
armazena um subconjunto original sem sobrepor informação. Isto é, cada entrada de diretório
é armazenada por um, e somente um, servidor. Quando a informação é replicada, a mesma
entrada de diretório está armazenada por mais de um servidor.
As três dimensões de um diretório (espaço da informação, posição dos clientes,
e distribuição dos servidores) são independentes entre si. Como exemplo, os clientes dispersos
através do globo podem acessar um diretório que contém somente informação sobre um único
departamento, e esse diretório pode ser replicado em muitos servidores de diretório. Os
clientes em uma única posição podem acessar um diretório que contenha informação sobre
toda a empresa, que é armazenado por um único servidor do diretório.
O espaço da informação a ser armazenada em um diretório é dado
freqüentemente como uma exigência da aplicação. A distribuição dos servidores de diretório e
a maneira em que os dados são divididos ou replicados são controlados para não afetar o
desempenho e aumentar a disponibilidade do diretório.

2.4 - DIRETÓRIO CLIENTE E SERVIDOR

Os diretórios são acessados geralmente usando o modelo cliente/servidor de


comunicação. Uma aplicação que faz uso de um diretório e que queira realizar uma consulta
ou até mesmo fazer alguma atualização, não conseguirá acessar esse diretório diretamente.
Em vez disso, é chamada uma função podendo ser da API(Application Programming
Interface) da linguagem do cliente, originando uma mensagem a ser emitida a um outro
processo. Esse segundo processo acessa a informação no diretório de interesse de uma
requisição via TCP/IP. As portas padrões TCP/IP são 636 para comunicações seguras
(criptografadas) e 389 para comunicações sem criptografia. Os resultados das ações de leitura
e escrita são retornados a requisições da aplicação, como mostrado na figura 1.

9
Local Area Network ou Rede Local.
17
Figura 1 - Representação, requisições feitas de clientes de LDAP a um servidor LDAP.

A requisição é executada pelo cliente do diretório, e será respondida por um


processo chamado de servidor de diretório. Em geral, os servidores fornecem um serviço
específico aos clientes. Às vezes, um servidor pode torna-se cliente de outros servidores a fim
de recolher a informação necessária para processar uma requisição.
Os processos do cliente e do servidor podem ou não estar na mesma máquina.
Um servidor é capaz de servir a muitos clientes. Alguns servidores podem processar
requisições do cliente em paralelo. Se o servidor estiver ocupado respondendo a requisições
de um cliente, as novas requisições deveram entrar em uma fila de espera aguardando sua vez.

18
CAPÍTULO III – LDAP

3.1. HISTÓRICO DO LDAP

Nos anos 70, a integração de comunicações e tecnologias de computação levou


ao desenvolvimento de novas tecnologias de comunicação. Muitos dos sistemas servidores
que foram desenvolvidos eram incompatíveis com outros sistemas, tornou-se evidente a
necessidade de padrões que permitissem que equipamentos e sistemas diferentes tivessem
operacionalização compatível. Diante disso, as duas principais e independentes
padronizações, o CCITT10, que mais tarde tornou-se ITU11 e a ISO12 trabalharam juntamente
na definição de um padrão de serviço de diretório que permitisse tratar melhor aspectos de
denominação e de endereçamento.

3.1.1. PRECURSORES DO LDAP

O CCITT criou o X.500 básico em 1988, que se tornou o ISO 9594, Data
Communications Network Directory - (Diretório de Comunicação de Rede de Dados),
recomendações X.500 - X.521 em 1990, embora ainda seja comumente tratado como X 500.
A série de recomendações X.500 define regras para dar nome a objetos, uma
base de informações de diretório lógica para guardar informações sobre esses objetos e as
entidades de protocolo que cooperam para prover o serviço de diretórios.

10
CCITT- Consultatif et Comite Telephonique Internacional et Telegraphique, (Comitê Consultivo Internacional
em Telefonia e Telegrafia)
11
ITU International Telecommunications Union: (União Internacional de Telecomunicações - Setor de
Padronização de Telecomunicação)
12
ISO International Organization for Standardization (Organização Internacional de Padrões)
19
Por causa da sua eficiência, o X.500 é freqüentemente usado junto com
módulos agregadores para a interoperação entre serviços de diretórios incompatíveis.
O X.500 especifica a comunicação entre cliente e servidor no uso do diretório
de protocolo de acesso DAP13, no entanto, como um protocolo da camada de aplicação, o
DAP exige a pilha inteira de protocolo OSI14 para operar. Suportar a pilha de protocolo OSI
exige uma grande quantidade de recursos, portanto, foi desenvolvida uma interface para um
servidor de diretório X.500 utilizando um protocolo mais leve tanto para o acesso como para
os recursos computacionais.

3.1.2. VERSÕES E CARACTERÍSTICAS

Em 1992 o grupo de trabalho OSI-DS15 da IETF16 partiu das especificações do


DIXIE17 e definiu um protocolo de acesso que funcionava com todas as versões do X.500,
resultando no LDAP (Lightweight Directory Access Protocol) ou Protocolo Leve de Acesso a
Diretório, que em 1993 foi apresentado como proposta de padrão Internet e em l995 se
transformou em um esboço padrão.
O LDAP, como o nome sugere, foi originalmente desenvolvido como um
produto de menor custo computacional que o DAP do X.500. Seu antecessor foi o protocolo
DIXIE que já rodava sobre TCP/IP e não sobre pilha OSI. Através do DIXIE, os clientes se
comunicavam com um servidor gateway18 via TCP/IP, que traduzia as solicitações recebidas
para as correspondentes operações X.500 e as enviava para um DSA19, via protocolo DAP
sobre pilha OSI.
O LDAP promove o refinamento das idéias do protocolo DIXIE, é de
implementação mais básica e reduz a complexidade, facilitando aos clientes, a instalação das
aplicações de diretórios capacitados.
O LDAP foi concebido efetuando as seguintes simplificações na especificação
X.500:

13
DAP Directory Access Protocol (Protocolo de acesso a diretório)
14
OSI Open System Interconnection (Sistemas abertos de interconexão)
15
OSI-DS OSI Directory Service (OSI serviço de diretório)
16
IETF Internet Engineering Task Force
17
O protocolo DIXIE foi projetado para ser usado em equipamentos pequenos (exemplo, PCs e Macintoshes) e
sem potência computacional ou software necessário para implementar a pilha completa de protocolos OSI.
18
O gateway pode ser um PC com duas (ou mais) placas de rede, ou um dispositivo dedicado, utilizado para
unir duas redes. Existem vários usos possíveis, desde interligar duas redes que utilizam protocolos diferentes,
até compartilhar aconexão com a Internet entre várias estações.
19
DSA Directory Assistence Service (Serviço de assistencia a diretório)
20
• Transporte: O LDAP executa diretamente sobre TCP, evitando
a sobrecarga das camadas superiores de pilhas de protocolos OSI.
• Representação de Dados: No LDAP a maioria dos elementos
de dados são representados como cadeias de caracteres, processadas bem
mais facilmente que dados na representação estruturada ASN.l20 usada pelo
X.500.
• Codificação de Dados: O LDAP codifica dados para transporte
em redes usando uma versão simplificada das mesmas regras de
codificação usadas pelo X.500.
• Funcionalidade: O LDAP elimina características pouco usadas
e operações redundantes do X.500.
A falta de suporte para o X.500 e para a pilha de protocolos OSI levou os
pesquisadores e desenvolvedores da Universidade de Michigan a criarem um servidor LDAP
standalone, o slapd. Esse grupo disponibilizou os fontes do slapd na Internet e criou listas de
usuários para divulgar e aperfeiçoar o novo serviço. O desenvolvimento foi acompanhado por
usuários e desenvolvedores do mundo inteiro.
Com a popularização do slapd, o LDAP deixou de ser uma mera alternativa ao
DAP do X.500 e se tornou um serviço de diretório completo, passando a competir com X.500.
Em dezembro de l997, a IETF aprovou a versão 3 do LDAP como proposta de padrão Internet
para serviços de diretório. Parte dessa nova versão foi realizada na Universidade de Michigan,
à qual estavam vinculados vários membros do grupo OSI-DS. A universidade também
fornece implementações de referência de LDAP e possui páginas na web que tratam sobre o
assunto.

3.1.3. RFC’S QUE PADRONIZAM O LDAP

A primeira versão do LDAP foi definida em X.500 como DAP (Protocolo de


Acesso Leve), [RFC 1487], que foi substituído por LDAP (Protocolo Leve de Acesso a
Diretório), [RFC 1777].
A [RFC 1777] define por si mesmo o protocolo de LDAP:
• Representação de strings de atributos de sintaxes básicos,
[RFC 1778];
• Representação de strings de nomes distintos, [RFC 1779];

20
Abstract Syntax Notation One
21
• Formato de URL de LDAP [RFC 1959];
• Representação de strings de filtros de pesquisa LDAP [RFC
1960].
A Versão LDAP 2 alcançou o estado de padrão de esboço, no processo de
padronização do IETF. Todos os atuais diretórios de implementação de servidor são baseados
na especificação LDAPv3.
A Versão LDAP 3 é definida por Protocolo Leve de Acesso a Diretório (v3)
[RFC 2251].
As novas RFCs da versão LDAP 3 são:
• Protocolo Leve de Acesso a Diretório (v3): Definições de
sintaxe de atributo [RFC 2252];
• Protocolo Leve de Acesso a Diretório (v3): Representação de
strings de nomes distintos [RFC 2253];
• Representação de strings de filtros de pesquisa LDAP [RFC
2254];
• Formato URL LDAP [RFC 2255];
• Resumo do X.500(96) esquema de operador para uso com
LDAP v3 [RFC 2256];
• Métodos de autenticação para LDAP [RFC 2829];
• LDAPv3: Extensão para segurança da camada de transporte
[RFC 2830];
• Protocolo Leve de Acesso a Diretório (v3): Especificação
técnica [RFC 3377].
A [RFC 2251] é um padrão proposto, uma forma de padrão de esboço.
O LDAPv3 estendeu o LDAPv2 nas seguintes áreas:
• Referências: um servidor que não armazena os dados solicitados
pode referir o cliente a outro servidor.
• Segurança: autenticação extensa usando os mecanismos de
autenticação simples e camada de segurança (SASL)21.
• Internacionalização: UTF-822 apoio para caracteres
internacionais.

21
SASL (Simple Authentication And Security Layer)
22
Unicode Transformation Formats
22
• Extensão: novos tipos de objeto e operações podem ser
dinamicamente definidos e o esquema publicado numa maneira básica.

3.1.4. O LDAP ATUALMENTE

Várias tecnologias de diretório de integração, emergiram em anos recentes


utilizando o LDAP e a concepção de diretório para centralizar e/ou sincronizar diretórios
diferentes.
Atualmente várias empresas oferecem produtos LDAP, incluindo Microsoft®,
Netscape® e Novell®. A Open LDAP Foundation, mantém e disponibiliza uma implementação
open source de serviços de diretório LDAP, baseada na Universidade de Michigan, que inclui
os seguintes módulos:
• Slapd - servidor LDAP standalone;
• Slurpd - servidor de replicação LDAP standalone;
• Bibliotecas que implementam o protocolo LDAP;
• Utilitários e ferramentas clientes LDAP.
O desenvolvimento do Open LDAP prossegue acompanhando a evolução dos
padrões do IETF e importantes empresas em todo o mundo o vem utilizando, como: IG ®,
Yahoo®, Pop®, Ret Hat®, Conectiva®, HP®, APLLE®, IBM®, etc.
No Brasil, utilizam LDAP: metrô de São Paulo, Prodesp, Sangari®, Bombril®,
etc.

3.2. LDAP LIGHTWEIGHT DIRECTORY ACCESS PROTOCOL

O LDAP, como o nome sugere, é um protocolo leve de acesso a diretório que


roda em cima da pilha do protocolo TCP/IP e outras conexões de transferência de serviços.
Inicialmente foi utilizado como uma interface para o X.500, mas também pode ser usado com
outros tipos de servidores de diretório. Atualmente vem se tornando um padrão e diversos
programas já têm suporte ao LDAP. Listas de endereços, autenticação, armazenamento de
certificados digitais e chaves públicas, são alguns dos exemplos onde o LDAP já é
amplamente utilizado.

23
O DAP é um protocolo de difícil manuseio e implementação, e protocolos mais
simples foram desenvolvidos com a maior parte de suas funcionalidades de forma menos
complexa.
O LDAP é uma definição de protocolo para acesso a bancos de dados
especializados chamados diretórios, é similar ao SQL23 no sentido de que é uma linguagem
que interage com bancos de dados.
[KAINES, 2001]

3.3. LDAP: PROTOCOLO OU DIRETÓRIO

O LDAP é definido como um protocolo de mensagens usadas por clientes do


diretório. Um ou mais pedidos podem ser emitidos do cliente para um servidor LDAP em uma
conexão. Uma ou mais buscas podem ser feitas para procurar uma entrada específica no
diretório.
Dentro de um ambiente de desenvolvimento Microsoft, é possível alcançar
diretórios LDAP através de sua relação ativa do serviço de diretório (AD25). No geral, com o
LDAP, o cliente não é dependente de uma execução particular do servidor e o próprio
servidor pode executar o diretório que o cliente escolher.
É um padrão aberto de mercado que define um método para acessar e atualizar
a informação em um diretório. Obteve grande aceitação como método de acesso a diretórios
da Internet e, conseqüentemente, vem se tornando estratégico dentro das intranets. Cada vez
mais tem suporte a um maior número de softwares envolvidos nos projetos, incorporando
assim, um grande crescimento das aplicações.
É um protocolo de comunicação, isto é, o transporte e o formato das
mensagens são usadas por um cliente para que ele possa acessar os dados em um diretório
X.500, sendo que isso, não define um serviço próprio do diretório. Quando se fala sobre um
diretório LDAP, se fala sobre a informação que é armazenada e pode ser recuperada pelo
protocolo LDAP.
Todos os usuários de LDAP compartilham muitas características básicas,
baseadas em RFCs (Request For Comments). Devido às diferenças de execução, não são
todos completamente compatíveis quando não há um padrão definido. [JOHNER,1998]

23
Structured Query Language
25
Active Directory
24
3.4. ARQUITETURA

O serviço de diretório LDAP é baseado em um modelo cliente-servidor. Um ou


mais servidores LDAP contêm os dados para criar uma árvore de diretório. Um cliente LDAP
conecta-se a um servidor e faz uma requisição. O servidor responde a requisição ou exibe um
ponteiro para onde o cliente pode conseguir a informação (outro servidor LDAP). Pode ser
comparado com o DNS, a diferença é que o servidor LDAP não faz buscas recursivas, ou
seja, em nome do cliente. O cliente é encarregado de procurar pelo servidor até encontrar a
informação desejada.
Define a troca de mensagens entre um cliente e um servidor LDAP, essas
mensagens especificam as operações pedidas pelo cliente (busca, modificação, etc), além das
respostas do servidor e o formato dos dados carregados para dentro das mensagens.
Para um administrador de diretório LDAP, o importante é o modelo lógico que
é definido pelas mensagens, os tipos de dados, a organização de diretórios, as operações
possíveis, a proteção de informações, etc.
A iteração entre um cliente de um servidor LDAP acontece assim: 1. O cliente
estabelece uma sessão com um servidor e especifica sua identificação ou o endereço IP e o
número da porta do TCP/IP onde o usuário está escutando. 2. O cliente fornece o nome do
servidor e uma senha para autenticação. Cliente e servidor podem estabelecer uma sessão que
use métodos de segurança como a encriptação de dados. 3. O cliente executa as operações nos
dados do diretório, permitindo assim, que a informação seja controlada sempre que
requisitada.
O diretório armazena e organiza as estruturas dos dados tidos como entradas.
Uma entrada de diretório descreve, geralmente, um objeto, tal como: uma pessoa, um
dispositivo, uma posição e assim por diante sendo que cada entrada tem um nome distinto
(DN26), que o identifique [JOHNER,1998]

3.5. MODELOS LDAP

Os modelos LDAP representam os serviços fornecidos por um servidor. Os


modelos abstratos descrevem as várias faces de um diretório LDAP. Quatro modelos são
definidos:

26
Distinct Name – utilizado para definir uma base LDAP
25
3.5.1. MODELO DA INFORMAÇÃO

Fornece a estrutura e o tipo de dado necessário para a construção de uma


árvore do diretório LDAP. A unidade básica da informação armazenada no diretório é
chamada de entrada. As entradas representam objetos de interesse no mundo real tal como:
pessoas, usuários, organizações e assim por diante. São compostas por uma coleção de
atributos que contêm informações sobre os objetos. Cada atributo possui um tipo e pode ter
um ou mais valores. O tipo do atributo é associado a sintaxe. Nela é especificado que tipo de
valores podem ser armazenados. Cada entrada pode ter um atributo. A sintaxe associada a
esse tipo de atributo, especificaria que os valores representados, descrevem as características
de sua definição.

3.5.2. MODELO DE NOMES

Define como as entradas são identificadas e organizadas. As entradas são


organizadas como uma árvore estrutura, chamada de árvore da informação do diretório
(DIT27). As entradas são arranjadas dentro do DIT, que é baseado em seu nome distinto (DN).
Um DN é um nome original que identifica uma única entrada. É composto por uma seqüência
de nomes distintos (RDN). Cada RDN em um DN corresponde a uma filial no DIT que
conduz a raiz do DIT à entrada de um diretório. Cada RDN é derivado dos atributos da
entrada de um diretório.
uid = tiago, ou = pessoas, dc = ldap, dc = df

dc = ldap, dc = df

ou = pessoas ou = grupos ou = computador

uid = tiago

Figura 2 - Árvore de diretório.

27
Directory Information Tree – Árvore de Informação do Diretório
26
3.5.3. MODELO FUNCIONAL

Fornece meios para alcançar os dados na árvore do diretório. É compreendido


por algumas categorias de operações que podem ser executadas de encontro a um serviço do
diretório LDAP: A autenticação, é usada para conectar e desconectar um servidor de LDAP e
o estabelecimento de acesso e proteção das informações.

3.5.4. MODELO DE SEGURANÇA

É baseado na operação de ligamento (Bind operation). Existem diversas


operações de ligamento, e assim, o mecanismo da segurança aplicado, também é diferente.
Um exemplo disso acontece, quando um cliente pede acesso e fornece um DN que o identifica
junto a uma senha. Se nenhum DN e senha forem declarados, uma sessão anônima é suposta
pelo servidor LDAP. O uso de senhas sem criptografia é pouco utilizada, quando o serviço de
transporte não pode garantir a confiabilidade, o que pode resultar na divulgação da senha a
outros partidos não autorizados .
Junto com o LDAP, existe um comando de ligação (Bind operation) que tem
suporte ao mecanismo da camada de autenticação e segurança (SASL). Esta é uma estrutura
genuína, onde diversos métodos diferentes estão disponíveis para autenticar o cliente ao
servidor. Uma extensão relacionada à segurança é a Segurança da Camada de Transporte
(TLS) do LDAP. Isso permite ao TLS, o uso das operações, cifrando e protegendo uma sessão
do LDAP. O TLS tem um mecanismo que o permite se comunicar com um servidor do SSL
que seja compatível. Os princípios básicos do SSL e do TLS são os mesmos. [JOHNER,1998]

3.6. LDIF

O LDIF é um formato texto de intercâmbio de informações para o LDAP. Foi


definido com o objetivo de mostrar as entradas do diretório quando de sua geração ou de sua
exportação para um arquivo texto.
Quando um diretório LDAP carrega pela a primeira vez ou quando muitas
entradas têm que ser mudadas de uma só vez, não é muito conveniente mudar essas entradas
para uma outra base, uma a uma. Para esta finalidade, o LDAP suporta o formato do
intercâmbio dos dados, ou seja, o LDIF, que pode ser visto como um conveniente e necessário

27
mecanismo de gerência de dados que permite a manipulação fácil de quantidades maciças de
dados.
O formato do intercâmbio do LDAP, LDIF, é um formato padrão da ferramenta
de texto que armazena os índices das informações dos diretórios e das configurações do
LDAP. Em seu formato mais básico, um arquivo de LDIF possui uma coleção das entradas
separadas por linhas em branco, nomes dos atributos referentes os valores e uma coleção das
diretrizes orientadoras que instruem como processar a informação. [JOHNER,1998]
Exemplo básico de uma entrada de LDIF:

dn: <distinguished name>


<attrtype> : <attrvalue>
<attrtype> : <attrvalue>...

dn: uid=tiago,ou = pessoas, dc=ldap, dc=df


objectclass: person
uid: tiago

3.7. CLASSES DE OBJETOS, ATRIBUTOS E ESQUEMAS

As classes de objetos são conjuntos de atributos referentes a uma entrada. São


termos do LDAP que denotam o tipo de objeto que está sendo representado por uma entrada
ou por um registro de diretório. Os objetos podem ser: pessoas, organizações, unidade
organizacional, grupo de nomes, entre outros. Existem também as classes de objetos que
definem o relacionamento entre um objeto e outro, tais como: a classe em que o objeto possui
objetos subordinados sob ele em uma estrutura de árvore hierárquica.
As classes podem ser declaradas como: abstrata, estrutural ou auxiliar. Uma
classe abstrata do objeto é usada quando se tem um molde para a criação de outro objeto.
Uma entrada de diretório não pode ser imediata a uma classe abstrata do objeto. As entradas
de um diretório são imediatas quando se trata das classes estruturais do objeto. Já uma classe
auxiliar do objeto não pode ser imediata, por ter unida a si, às entradas dos diretório que são
imediatas as classes estruturais do objeto. As classes auxiliares do objeto fornecem um
método que estende as classes estruturais, sem ter que mudar, a definição do esquema de uma
classe estrutural.
Também definem um arranjo de atributos padrões, listados como obrigação
(atributos imperativos) e que ainda podem conter atributos opcionais. As diferentes classes de
um objeto podem prescrever alguns atributos que sobrepõem ou são redundantes a outras
classes do objeto. É comum em diretórios LDAP, usar classes múltiplas do objeto, para
28
definir uma única entrada de um diretório. A maioria das classes de objeto, são definidas em
uma ordem hierárquica, onde uma classe de objeto "herda" de outra classe superior.
[JOHNER,1998]
Não se pode simplesmente criar classes de objetos e acrescentar as mesmas a
um objeto, o servidor deve ter cada classe de objeto definida, no que é chamado de schema
(esquema). Não é possível acrescentar um registro com uma classe de objeto indefinida, isso
implicará numa tentativa de violação do esquema, e a operação irá falhar.
Algumas classes de objetos usados no LDAP:

Tabela 1 Algumas classes de objetos


account applicationEntity
adminPerson applicationProcess
alias certificationAuthority

certificationAuthority-V2 country

cRLDistributionPoint dcObject
device dmd
dNSDomain document
documentSeries domain
domainRelatedObject dSA
dynamicObject eduPerson
extensibleObject friendlyCountry
groupOfNames groupOfUniqueNames
inetOrgPerson labeledURIObject
LDAPsubEntry locality
mailAlias OpenLDAProotDSE
organization organizationalPerson
organizationalRole organizationalUnit
person pilotDSA
pilotOrganization qualityLabelledData
referral reserved
residentialPerson RFC822localPart
room simpleSecurityObject
strongAuthenticationUser subschema
top uflEduOrganization
uflEduPerson uflEduRelationship
uidObject userSecurityInformation

Como dito anteriormente para que o LDAP possa validar um objeto este deverá
estar explicitamente em um determinado esquema, que é um conjunto de regras que contém
os objetos e os atributos que o mesmo pode adquirir. Existem vários esquemas, para cada
aplicação bem definida como por exemplo o samba3x.schema que é utilizado para normatizar
29
os objetos e atributos que são utilizados no SAMBA e que possam ser migrado para para o
LDAP, segue abaixo exemplos de schemas existentes.

Tabela 2 Alguns esquemas.

corba.schema core.schema

cosine.schema inetorgperson.schema

java.schema nis.schema

openldap.schema qmail.schema

samba3x.schema authldap.schema

Para cada objeto existente no LDAP, existe também a sua identificação, o sua
classe de objeto e o esquema a que ele pertence, segue uma tabela para se exemplificar essa
definição.

Tabela 3 Relação entre atributo, classe de objeto e esquema.


Abreviação Nome Objeto Classe Esquema
c countryName country core.schema
cn commonName person core.schema
organizationalPerson
organizationalRole
groupOfNames
applicationProcess
applicationEntity
posixAccount
device
dc domainComponent dcObject core.schema
- facsimileTelephoneNumber residentialPerson core.schema
organizationalRole
organizationalPerson
co friendlyCountryName friendlyCountry cosine.schema
gn givenName inetOrgPerson core.schema
homePhone homeTelephoneNumber inetOrgPerson cosine.schema
- jpegPhoto inetOrgPerson inetorgperson.schema
l localityName locality core.schema
organizationalPerson
mail rfc822Mailbox inetOrgPerson core.schema
mobile mobileTelephoneNumber inetOrgPerson cosine.schema
o organizationName organization core.schema
ou organisationalUnitName organizationUnit core.schema
- owner groupOfNames core.schema
device
30
groupOfUniqueNames
pager pagerTelephoneNumber inetOrgPerson cosine.schema
- postalAddress organizationalPerson core.schema
postalCode postalCode organizationalPerson core.schema
sn surname person core.schema
st stateOrProvinceName organizationalPerson core.schema
street streetAddress organizationalPerson core.schema
- telephoneNumber organizationalPerson core.schema
userPassword - organization core.schema
organizationalUnit
person
dmd
simpleSecurityObject
domain
posixAccount
uid userid account core.schema
inetOrgPerson
posixAccount

Organização do LDAP em esquema, classe de objeto e atributos

3.8. SEGURANÇA

Um dos principais requisitos para um sistema é a segurança, a possibilidade de


se manter informações e dados confidenciais íntegros e livre de possíveis ataques, protegendo
o acesso.
Não existe sistema completamente seguro, o que pode ser feito é aumentar a
segurança, de forma a dificultar o máximo qualquer tipo de invasão e obtenção de dados, por
usuários estranhos ao sistema. Para aumentar a segurança em sistema é preciso observar dois
aspectos importantíssimos: a política de segurança estabelecido pela organização, definindo o
nível em que deseja que suas informações sejam protegidas; e a utilização de ferramentas e
recursos que possam proporcionar esse nível de segurança.

31
Existem diversos métodos de implementar níveis de segurança, entre eles
podemos destacar os métodos de autenticação, autorização, acesso e criptografia que hoje em
dia se tornaram requisitos essenciais dentro da política de segurança de uma organização e
não mais uma opção.
O LDAP promovendo um serviço de diretórios, em dados compartilhados e
distribuídos, não dispensa de forma alguma os métodos de segurança. Ele possui mecanismos
nativos e grande facilidade de integração com outras ferramentas para a implementação de um
ambiente seguro.
O LDAP possui um completo esquema para implementação de segurança,
como o processo de autenticação comum baseado no par login/senha até a possibilidade de
integração com certificados digitais e armazenamento de chaves públicas. [KAINES, 2001]

3.8.1. SEGURANÇA NO LDAP

O aspecto segurança é de grande importância em uma rede mundial de


computadores, e com o LDAP não é diferente. Quando são enviados dados em uma rede
interna ou externa, precisa-se que esses dados sejam protegidos de ataques e violações por
parte de pessoas mal intencionadas, durante o transporte. Essa proteção é especialmente
importante nas operações de atualização em um diretório. O Termo segurança nesse contexto
atua sobre quatro aspectos:
• Autenticação: Garante que a parte oposta (máquina ou pessoa) realmente é
quem ela afirma ser;
• Integridade: Garante que a informação que chegou é realmente a mesma que
foi enviada;
• Confidencialidade: Protege as informações divulgadas, por meio de
criptografia, para que pessoas que não sejam autorizadas, entendam essas
informações;
• Autorização: Garante que é realmente permitido a uma pessoa fazer o que está
pedindo. Isso é normalmente conferido após a autenticação do usuário.
A autorização do LDAP, não faz parte da especificação do protocolo e é
portanto implementação específica. Isso é basicamente arquivado por algum controle de
acesso, como leitura, escrita, ou exclusão, por identidades de usuários ou nomes comuns.
Quem é responsável por proporcionar os controles de acesso são as ACLs, Listas de controle

32
de acesso que são amplamente suportadas pelo LDAP. No item 3.9 serão abordados mais
detalhadamente os aspectos da autorização e das ACLs.
Autenticação, Integridade e confidencialidade serão pontos abordados nesse
item. Os métodos mais importantes para cada um destes serão apresentados. São eles:
[JOHNER,1998]
• Sem autenticação;
• Autenticação básica;
• Simple Authentication and Security Layer (SASL).

3.8.2. SEM AUTENTICAÇÃO

Esse método deve ser usado apenas quando não se faz questão da segurança dos dados
e quando nenhuma permissão de acesso especial está envolvida. Isso é definido quando os
campos da senha e do DN estão vazios na vinculação chamada pelas APIs .
O servidor LDAP então, assume automaticamente uma seção como usuário anônimo e com o
apropriado controle de acesso definido.

3.8.3. AUTENTICAÇÃO BÁSICA

O mecanismo seguro no LDAP é negociado quando a conexão entre cliente e


servidor é estabelecida. O mecanismo mais simples de segurança no LDAP é chamado de
autenticação básica, que é também usado em vários outros protocolos Web.
Quando usamos a autenticação básica com o LDAP, o cliente identifica-se para
o servidor por meio de um DN e uma senha, que são enviados em claro pela rede. O servidor
considera o cliente autenticado se o nome de domínio e a senha enviada pelo cliente
combinam com a senha do DN armazenado no diretório.

3.8.4. AUTENTICAÇÃO SIMPLES E CAMADA SEGURA (SASL - SIMPLE AUTHENTICATION AND

SECURITY LAYER).

SASL é um framework para adicionar mecanismos de autenticação para


protocolos orientados a conexão. Isso foi adicionado na versão 3 do LDAP para sobrepor a
autenticação deficiente da versão 2.

33
Foi originalmente desenvolvido para incluir uma autenticação robusta para o
protocolo IMAP e foi iniciado como um sistema geral para mediar entre protocolos e sistemas
de autenticação.
Essa é uma proposta de padrão para Internet definido na [RFC 2222].
No SASL, protocolos de conexão do tipo LDAP, IMAP e assim por diante, são
representados por perfis, cada perfil é considerado uma extensão do protocolo para permitir
que trabalhe junto com SASL.
Todo protocolo que tiver intenção de utilizar SASL necessita ser estendido
através de um comando para identificar o mecanismo de autenticação e trazer a sua
substituição.
A camada segura para encriptação de dados pode ser negociada após a
autenticação e garanti a confidencialidade. LDAP inclui esse comando (LDAP_sasl_bind( )).
Os parâmetros chave que influenciam o método de segurança usado são:

• DN: Esse é o nome distinto para a entrada que se deseja vincular.


• Mecanismo : Esse é o nome do método de segurança que deve ser usado.
No LDAP o mecanismo mais utilizado é o SSL ou TLS, que é
provido por um mecanismo externo.
• Credenciais: Contém os dados arbitrários que identificam o DN. O formato e
o conteúdo dos parâmetros dependem do mecanismo escolhido.
Se, por exemplo, o mecanismo anônimo, for escolhido, pode ser
uma cadeia de caracteres arbitrários ou um endereço de e-mail
que identifiquem o usuário.
O funcionamento do mecanismo SASL acontece da seguinte forma: a aplicação
cliente do LDAP chama o driver do protocolo SASL no servidor, que retorna as conexões do
sistema de autenticação, nomeados no mecanismo SASL, para devolver a informação de
autenticação requerida pelo usuário. SASL pode ser visto como um mediador entre o sistema
de autenticação e o protocolo LDAP.

34
Chamadas do
Mecanismos SASL (Cliente LDAP)

Driver SASL no Servidor LDAP

Sistema de Autenticação

Figura 3 - Mecanismo SASL.

3.8.5. SSL E TLS


O protocolo de conexão segura (SSL), foi desenvolvido para promover
autenticação e segurança nos dados. Ele é encapsulado sobre a camada TCP/IP nos protocolos
de rede.

Aplicações
(WWW, POP, SMTP, E-MAIL)

HTTP SMTP LDAP

Protocolos de Aplicação

Security Layer (SSL/TLS)


Protocolos de Rede
TCP/IP layer

O SSL foi desenvolvido pela Netscape. TLS é um padrão aberto.

Figura 4 - SSL/TLS no relacionamento com outros protocolos.

35
O TLS atualmente vem sendo trabalhado pela IETF. Ele é baseado no SSL 3.0
com pequenas diferenças e possui compatibilidade.
SSL/TLS suportam autenticação servidor (o cliente autentica no servidor) e
autenticação cliente (o servidor autentica no cliente) ou autenticação mútua. Também é
fornecido para privacidade a encriptação dos dados enviados na rede.
SSL/TLS usam um método de chave pública para a segurança da comunicação
e também para autenticar a contraparte na seção. Isso é arquivado como um par de chaves
pública/privada. Eles operam em função reversa uma para outra, os dados podem ser
encriptados com a chave privada e desencriptados com a chave pública e vice-versa.
A hipótese para essa consideração é que o servidor possui esses pares de chave
já gerados, isso é normalmente definido nas configurações do servidor LDAP.
O intercâmbio simplificado entre um cliente e um servidor, negociando uma
conexão SSL/TLS é explicada adiante e ilustrada na figura.

Requisição, Opções SSL/TLS

Certificado, Opções SSL/TLS

Confirmação
CLIENTE SERVIDOR
Mensagem, Digest

Chave Simétrica (encriptada)

Mensagem aleatória (encriptada)

Figura 5 - Acordo SSL/TLS.

1. No primeiro passo, o cliente questiona o servidor por uma seção SSL/TLS. O cliente
também inclui as opções SSL/TLS suportadas na requisição.
2. O servidor envia de volta as opções SSL/TLS e um certificado que inclui entre outras
coisas, a chave pública do servidor, a identidade para quem o certificado foi enviado, o
nome da certificadora e o tempo de validade.
3. O cliente então requisita que o servidor prove sua identidade. Isso para saber se o
certificado não foi enviado por outra pessoa qualquer ou foi interceptado.

36
4. O servidor retorna uma mensagem que inclui uma message digest, mensagem condensada,
que é encriptada com a sua chave privada. Uma message digest que é computada de uma
mensagem satisfatória usando uma função distribuída (hash) tem duas características: são
extremamente difíceis de serem revertidas e é praticamente impossível encontrar duas
mensagens que produzam o mesmo message digest.
5. Servidor e cliente precisam combinar sobre uma chave secreta a ser usada para
encriptação dos dados. A encriptação dos dados é definida por um algoritmo de chave
simétrica pois é mais eficiente. O cliente, depois de gerada uma chave simétrica, encripta
com a chave pública do servidor e a envia. Apenas o servidor com a chave privada pode
desencriptar a chave secreta.
6. O servidor desencripta a chave secreta e envia de volta uma mensagem de teste,
encriptada com a chave secreta para provar que a mesma chegou seguramente. Eles
podem então iniciar a comunicação usando a chave simétrica para encriptar os dados.

3.8.6. OUTROS MECANISMOS DE AUTENTICAÇÃO SASL

Embora a concepção do SASL suporte múltiplos mecanismos, produtos de


vendedores particulares podem não ser suportados, forçando com que os vendedores de
produtos apenas suportem um número reduzido de mecanismos semelhante ao SSL ou TLS.
[JOHNER,1998]

3.9. ACL

Para se falar de ACL, primeiramente é preciso compreender alguns conceitos


básicos sobre: autorização que é o alvo da implementação das ACLs; e sobre políticas de
segurança que servem como base para a implementação das ACLs.

3.9.1. AUTORIZAÇÃO

A autorização que é definida no contexto de segurança de um sistema, é aquela


que concede acesso de uso à determinados serviços, recursos, arquivos ou qualquer outro
dispositivo que esteja disponível para os usuários de uma organização seja ela local ou
distribuída. Exemplo: Quando é concedido pelos administradores do sistema, à um usuário A,

37
escrever em um arquivo de texto. Pode-se dizer que o usuário , tem autorização de escrita
para aquele arquivo específico.

3.9.2. POLÍTICAS DE SEGURANÇA

As políticas de segurança, é um termo geral que define como, quando, quem e


o que, deve ser um objeto seguro dentro do contexto de atuação de um organização, desde a
visão completa até uma visão mais interna e específica possível . Ela deve ser definida quando
da criação do sistema, para que sejam aplicadas em tempo hábil. As políticas de segurança en-
globam na sua definição os aspectos das políticas de controle de acesso e política de autoriza-
ção.
Exemplo: é definido que os usuários de nível de operação de setor de
treinamento, não podem ter acesso aos arquivos de setor de recursos humanos da empresa X.

3.9.3. DEFININDO LISTAS DE CONTROLE DE ACESSO

As Listas de Controle de Acesso são listas que contém atributos específicos


que associados a um objeto de segurança, tem como objetivo definir as regras de acesso e
autorização para um determinado usuário ou para um grupo deles. Elas são aplicadas baseadas
nas definições da política de segurança de cada organização.
Abaixo uma definição sucinta de ACL contida na [RFC 2820]:
“Lista de Controle de Acesso - (Access Control List): É um arranjo de
atributos do controle. É uma lista, associada com um objeto de segurança ou
um grupo de objetos de segurança. A lista contém os nomes de assuntos de
segurança o tipo de acesso que pode ser concedido. [RFC 2820]”
As ACLs vem com a necessidade de se obter acesso seguro às imformações
disponobilizadas por um sistema, e ao mesmo tempo assegurá-las, para que não sejam
indevidamente alteradas, por pessoas que não possuem autoridade para o fazer. Ela serve para
garantir que a operação que se deseja realizar em um determinado objeto e garantida à quem a
requisitou. Ou seja, assim promover confidencialidade, e integridade das informações.
Como citado no item anterior o LDAP ainda não possui na sua definição um
controle de acesso padronizado, contudo existe a necessidade de se proteger os diretórios
promovendo acesso seguro e consistente, e com a crescente aceitação do protocolo como

38
padrão vem crescendo também a perspectiva para que seja definido futuramente um padrão de
controle de acesso.
Apesar disso existem várias implementações proprietárias e de comunidades da
internet para o controle de acesso entre elas pode ser citado o modelo de ACL da IBM® e da
Netscape®, cada qual com suas próprias características.
Devido a grande demanda pelo uso desse serviço o IETF criou através da [RFC
2820] algumas exigências fundamentais para um modelo de listas de controle de acesso. A
criação dessa RFC pretende que se torne um repositório necessário para fornecer autorização
de acesso e interoperabilidade entre diretórios. Essas exigências parametrizam o modelo de
forma a observar aspectos importantes para a criação do modelo como semântica/política e
usabilidade além de aspectos gerais.

3.9.4. ASPECTOS GERAIS DO MODELO ACL PARA LDAP

O modelo de controle se acesso para LDAP deve ser um modelo geral,


extensível para que suporte novas características, e o mais seguro possível. Além de promover
a administração de forma que faça parte do protocolo e ainda as informações de controle
sejam atributos do LDAP.

3.9.5. SEMÂNTICA / POLÍTICA

• As regras mais específicas devem sobrepor as menos


específicas;
• As políticas múltiplas de mesmo nível devem ser facilmente
compreendida, quando não tiver uma política de segurança específica deve
haver uma interpretação de negado ou concedido o ideal é negar o acesso às
entradas de mesma especificação em que não poder ser determinada que a
concessão do acesso;
• A gerência dos direitos acesso não devem surtir efeitos
colaterais, conceder direito de acesso o um usuário em um determinado objeto
não deve implicitamente conceder a ele ou a qualquer outro usuário, direitos de
acesso diferentes ao mesmo objeto;
• A política de segurança deve ser única para entradas múltiplas,
mesmo que elas estejam em sub-árvores diferentes.
39
USABILIDADE

• O sistema deve ser o mais simples possível;


• O modelo de ACL deve ser de fácil compreensão;
• Ao administrador não deve ser dado a autorização para travar
todos os usuários;
• Deve suportar controle de acesso específico à cada entrada;
• Administrador deverá agregar usuários em grupos e/ou papéis
para facilitar a administração, poderá delegar a administração da política de
sub-arvores específicas a outros usuários;
• Deve ser possível autorizar ao usuário, que possam acessar toda
estrutura da árvore de diretórios mesmo que não tenham direito de alterar ou
examinar algumas entradas e também deve ser possível negar que façam isso;
• As informações da política de acesso herdadas, devem ser
facilmente identificadas pelos administradores, sabendo definir de quem e de
onde as ACLs são derivadas.
Esses são alguns pontos que norteiam a criação de ACLs, para que sejam
utilizados da forma mais otimizada possível e também buscando organizar as
idéias para que não divirjam muito umas das outras, apesar de serem
implementações individuais.
Abaixo, será mostrado um exemplo da configuração ACL no servidor LDAP, o
slapd:

Acess to attrs = userPassword


By dn= ”cn=admin, dc=LDAP, dc=df” write
By anonymous auth
By self write
By x nome

Access to dn.base=”” by * read

Access to *
By dn=”cn=admin,dc=LDAP,dc=df”
write by*read.

3.10. REPLICAÇÃO

40
Os sistemas distribuídos são muito utilizados atualmente, com a modernização
na área das comunicações, está cada vez mais fácil e necessário que os sistemas trabalhem
dessa forma. Com o objetivo de tornarem as informações mais acessíveis, de fácil localização
e com nível de disponibilidade satisfatório.to

Figura 6 - Sistema com uma única base.

Figura 7 - Sistema com a base distribuída.

Porém nem sempre os sistemas mantêm as informações dessa forma, criando


grande dificuldade para o usuário do sistema, devido á vários fatores, largura de banda,
excesso de usuários utilizando o sistema simultaneamente, tamanho dos arquivos transferidos,
falha nos servidores, queda na conexão indisponibilizando o serviço.
Para tentar resolver esse tipo de problema em relação aos sistemas distribuídos
é que surge conceito de replicação, onde dados de um servidor mestre são replicados
(copiados) para outros servidores, os escravos, fazendo com que os usuários tenham mais
facilidade nos acessos as informações que podem ser setorizadas, e também na confiabilidade
da disponibilidade do serviço. Colocando os servidores do sistema numa condição de

41
tolerância a falhas, ou seja, se um dos servidores perder a conexão por qualquer motivo a sua
base de dados que foi replicada para outros servidores, continuará a responder as requisições
dos usuários até que o servidor mestre seja restabelecido. [NAGUEL2]

Figura 8 - Replicação do servidor mestre para os sevidores escravos.

3.10.1. REPLICAÇÃO NO LDAP

O conjunto do serviço de diretórios do LDAP oferece possibilidade de


replicação de dados, fazendo com que o serviço seja altamente disponível e tolerante a falhas.
A base de dados do servidor mestre é replicada, criando uma base de dados atualizada igual
em um servidor escravo. No OpenLDAP quem gerencia essas funções de replicação é o
slurpd.

3.10.2. DAEMON “SLURPD”

Como citado acima, o slurpd oferece a um servidor slapd mestre a


possibilidade de replicar as modificações feitas na base de dados do diretório para a base de
dados de um servidor slapd escravo.
O serviço de replicações funciona da seguinte forma:

42
Figura 9 - Serviço de replicação.

O slurpd deve sempre trabalhar na mesma máquina do servidor slapd para que
funcione corretamente, pois ele irá detectar no servidor mestre as alterações e modifica-las
nos servidores escravo.
Para a sua operação o slurpd precisa de algumas informações de configurações
as quais ele utiliza o arquivo de configuração do servidor LDAP o slapd.conf. Durante suas
operações o slurpd utiliza dois artifícios importantes; o log de replicação e o arquivo auxiliar.

3.10.2.1. LOG DE REPLICAÇÃO E AQUIVOS AUXILIARES

Os logs de replicação são arquivos que são modificados a cada alteração


realizada no servidor mestre, são incluídas nesses arquivos as entradas que foram
modificadas. Esse arquivo serve como base de referencias para as operações de slurpd, pois o
informam as novas alterações a serem replicadas. O slurpd lê esse arquivo de log, e localiza
as novas entradas adicionadas e efetua as operações e logo em seguida o arquivo e esvaziado
para poder dar lugar às novas entradas.
Os arquivos auxiliares recebem as informações das modificações realizadas,
logo depois do processo citado acima, servindo como uma base de referencia, para se ter um
histórico das operações realizadas, a cada processo de atualização das modificações, o
conteúdo da log de replicação é copiado para o arquivo auxiliar onde lá permanece.
[NAGUEL2]

43
3.10.2.2. MODOS DE OPERAÇÃO

Existem dois modos de operação de replicação, oferecidas pelo slurpd. A


primeira é a forma mais utilizada e mais segura, ele permanece ativo, e periodicamente
verifica o arquivo de log em busca de novas entradas adicionadas e então executá-las. A
Segunda forma de operação o slurpd processa o log de replicação e finaliza imediatamente
fazendo com que o arquivo de log não seja apagado e não adicionará uma cópia das
atualizações efetuadas no arquivo auxiliar (modo “one-shot”). [NAGUEL2]

3.10.2.3. FUNCIONAMENTO

Para colocar o slurpd em funcionamento, algumas configurações básicas no


servidor mestre e no servidor escravo, são necessárias são elas; Servidor mestre: um servidor
slapd pode ser mestre de várias replicações, basta que seja especificado cada uma delas
através da diretiva “replica”. [NAGUEL]

Exemplo:
Erro: Origem da referência não encontrada

Na linha 1, é definida a diretiva “replica”, para o servidor que se deseja replicar


com o nome “slave.example.com” e a porta de comunicação padrão do LDAP “389”.
Na linha 2, a diretiva “binddn” define com qual “dn” que o mestre irá logar no
escravo, no caso essa diretiva deve existir no diretório do escravo com permissão para escrita
e deve ser a mesma do “updatedn”.
Linha 3, define na diretiva “bindmethod” o método com o mestre irá autenticar
no escravo, “simple” significa que será utilizada a senha que aparece na linha 4, em
“credentials”, a senha definida é “secret”.

44
Para evitar que a senha seja transmitida do servidor mestre para o servidor
escravo em texto claro, é definida a diretiva “TLS” na linha 5, como “critical” para que seja
utilizado uma conexão TLS com o servidor escravo.
O Servidor slapd escravo deve possuir as seguintes configurações: o "dn"
definido em “udatedn” deve ser o mesmo definido no “binddn”, o usuário que tentar fazer
alguma alteração no escravo e que o "dn" não seja o mesmo do “updatedn” será impedido de
realizar qualquer alteração. Será retornado, uma referencia indicando-o para o servidor
mestre, onde deverá fazer as alterações. Se a alteração não for realizada através do slurpd
mesmo que o “dn” seja o mesmo do “updatedn”, será recebida por ele uma mensagem de erro.
É importante observar que os direitos de acesso do escravo sobrepõe aquelas
definidas no servidor mestre, portanto é preciso tem muito cuidado no gerenciamento desses
direitos, para evitar que um usuário tenha direito de escrito na base do escravo, e acabe
criando inconsistências.
Estando slapd mestre e escravo configurados corretamente, basta colocar o
slurpd em funcionamento. Para isso deve-se; interromper a execução do servidor, e criar uma
cópia de sua base de dados. Copiar a base de dados para um arquivo LDIF, podemos utilizar o
“slapcat” para isso. Copiar a base do mestre para o escravo utilizando “slapdadd” no arquivo
LDIF gerado. Reinicializar o funcionamento do slapd mestre e escravo. Por fim inicializar o
slurpd na mesma máquina do servidor mestre.

3.10.3. OCORRÊNCIA DE FALHAS NO SLAPD E NO SLURPD DURANTE A REPLICAÇÃO

Quando o servidor slapd escravo para de funcionar durante uma replicação, o


arquivo de log é apagado e é registrada a alteração no arquivo auxiliar. Quando o servidor
voltar, as modificações são feitas normalmente.
Quando o servidor slapd mestre é interrompido, o servidor escravo continua a
responder as requisições, e a retornar a referência para o servidor mestre no caso de
alterações.
No caso do slurpd, quando seu funcionamento é interrompido, as alterações
permanecem registradas no arquivo de log, assim que voltar a operar, ele irá ler o arquivo e
executar as modificações.

3.10.4. CONCLUINDO REPLICAÇÃO

45
Como podemos observar nos esclarecimentos acima, a replicação é
fundamental para a melhor disponibilidade dos sistemas distribuídos, e o
serviço de diretórios LDAP, que trabalha fundamentalmente dessa forma não
poderia deixar de implementar essa solução. Utilizando-se de uma ferramenta
poderosa e ao mesmo tempo simples, traz a solução para a gerência de
replicação, implementada pelo daemon “slurpd”. Com configurações simples
e rápidas é possível criar um sistema de replicação e colocar em
funcionamento o “slurpd”, resultando em alta disponibilidade e integridade dos
dados tanto para os usuários quanto para os administradores do sistema.

3.11. BANCO DE DADOS X LDAP

No serviço de diretórios LDAP, o principal insumo para a realização de seus


serviços são dados. Dados esses que precisam ser armazenados em algum lugar para poderem
ser usados posteriormente quando requisitados. O local de armazenamento dos dados e
convencionalmente chamado de “banco de dados”.
Existem dois modelos de banco de dados que são mais utilizados atualmente,
são eles:
• Banco de dados relacional
• Banco de Dados Hierárquico

3.11.1. BANCO DE DADOS RELACIONAL

Um dos tipos de banco de dados existentes é o relacional. Nesse modelo de


banco os dados são armazenados de forma que haja uma referência entre esses dados. De
forma que fiquem amarrados as sua identificações e possam retornar para uma requisição essa
referência. Esse banco trabalha com o intuito de responder a um grande número de transações
o que não é adequado ao LDAP.

3.11.2. BANCO DE DADOS HIERÁRQUICO

Outro tipo de banco de dados é o hierárquico, um banco que armazena seus


dados em forma de uma árvore, onde existem os nós raiz e seus nós filho. Nesse banco não

46
são feitas transações, e suas operações são baseadas principalmente em consultas e com
poucas inserções e modificações.
O serviço de diretórios LDAP precisa de um “banco de dados” para funcionar,
o tipo de banco utilizado por ele é o modelo hierárquico, que como observamos acima é o
modelo mais adequado para o tipo de estrutura do LDAP. As requisições do LDAP são muito
simples, não precisam retornar referências, não suportam transação, elas apenas retornam o
dado ou um erro.
O LDAP utiliza o modelo hierárquico, porque são poucas inserções e
modificações e muitas consultas, o que de forma geral garante um ganho de desempenho ao
contrário de um banco de dados relacional qualquer.
Se utilizarmos um banco de dados relacional, por exemplo, para executar a
função do LDAP, teremos alguns problemas, além do trabalho penoso de inserir todos os
dados dos diretórios, seria preciso definir todos os padrões e regras de armazenamento, o que
é nativo no LDAP, além disso, a aplicação ficaria com a responsabilidade de colocar o
contexto, analisando cada dado e lavá-los em conta para cada operação. Esses fatores tornam
a vida dos implementadores, tanto da aplicação quanto do banco de dados, mais difícil em
contraposição das facilidades apresentadas pelo LDAP.

3.12. X.500 X LDAP

X.500 é um serviço de diretórios completo padrão OSI28, que inclui um modelo


de informação, espaço de nomes, modelo funcional e um framework29 de autenticação. O
X.500 também define o Protocolo de Acesso a Diretórios o DAP usado por clientes para
acesso a diretórios. [HOWES,1995] [ISQUIERDO,2001]

3.12.1. PROTOCOLO DAP

Como foi definido acima no item 3.1.1 o DAP é significativamente mais


complicado do que a implementação da pilha TCP/IP além de requer mais código e recursos
computacionais para rodar. O tamanho e a complexidade do DAP geram dificuldades para
rodar em máquinas de pequeno porte. Quando a pilha de implementação DAP é usada, ela
requer processo personalizado envolvido que limita a aceitação do X.500. O LDAP foi

28
OSI – modelo de referência de protocolo de rede
29
Framework – uma área de trabalho com função específica

47
desenvolvido para reduzir a carga do acesso X.500 à diretórios clientes, tornando o diretório
disponível para uma grande variedades de máquinas e aplicações, LDAP roda diretamente
sobre TCP/IP. Isso simplifica muito as operações X.500. LDAP usa codificação simples. O
resultado é um baixo overhead30 no método de acesso para diretórios X.500, e é adequado
para utilizar em virtualmente todas as plataformas. [HOWES,1995] [ISQUIERDO,2001]

3.12.2. PROTOCOLO LDAP

O LDAP assumiu o modelo de informação do X.500. É baseado no modelo


Cliente-Servidor, mas existe uma diferença importante o LDAP não retorna referências. Um
servidor LDAP retorna apenas resultados ou erros para o cliente.
O modelo Funcional LDAP é uma sub-configuração do modelo X.500. LDAP
suporta as seguintes operações: adicionar, apagar, modificar, associar, dissociar, buscar,
comparar, remover e abandonar. A operação de procura ou busca é similar a do DAP. Um
objeto base e um escopo são especificados, determinando cada partição da árvore de busca.
[HOWES,1995] [ISQUIERDO,2001]

Figura 10 - Funcionamento X500 x LDAP.

Como pode ser observado na Figura 11 o fato do protocolo LDAP não utilizar
as camadas superiores do modelo de referência OSI, vem a simplificar o modo de
funcionamento do serviço de diretórios LDAP.

30
Overhead – excesso de carga de leitura ou processamento
48
3.12.3. VANTAGENS DO LDAP

LDAP possui quatro vantagens chave sobre o DAP:


• Roda sobre o protocolo TCP/IP
• Leitura e operações simplificadas
• DNs e Codificação Simples
• Sem referências

Primeira, ele roda diretamente sobre TCP ou outro transporte confiável, na


teoria, eliminando muitas das configurações de conexão e a utilização excessiva de pacotes de
camada de sessão e apresentação do modelo OSI requeridos para o DAP.
Segundo, LDAP simplifica o modelo funcional do X.500 em dois pontos,
facilidade de leitura e lista de operações.
Terceiro, embora X.500 e LDAP descrevam o protocolo utilizando o código
elementar ASN.131 e BER32, o LDAP usa codificação de caracteres por nomes distintos e
elementos de dados. X.500 usa uma complexa e altamente estruturada codificação para
elementos de dados relativamente simples; elemento de dados do LDAP são tipos de
caracteres. Essa codificação é otimizada por nomes distintos, cada um deles possui estrutura
considerável para codificação/decodificação, complexidade e tamanho. LDAP delega o
conhecimento do valor da sintaxe para a aplicação.
Finalmente, os clientes LDAP estão livres da responsabilidade de encontrar
referências. O servidor LDAP é responsável por encontrar todas as referências retornando
para o X.500, cada resultado ou erro para o lado cliente. O cliente assume um único modelo
de conexão em cada X.500 surgindo um único diretório lógico. [HOWES,1995]

DESEMPENHO

O desempenho do LDAP é satisfatório para a maioria das aplicações. Será


comparado o desempenho do DAP e LDAP em quatro áreas, tempo de resposta às perguntas;
o tamanho das perguntas, velocidade de codificação e decodificação e o tamanho da
complexidade da implementação no lado cliente.

31
(Abstract Syntax Notation One) notação definida pela ISO que permite definir tipos de dados simples e
complexos, bem como os valores que tais tipos podem assumir.
32
BER – (Basic Encoding Rules) Regras Básicas de codificação.
49
3.12.5. COMPARAÇÕES DAP X LDAP

A tabela 1 mostra o desempenho de uma classe de perguntas (Query) típicas


DAP e LDAP. Os testes são conduzidos em uma máquina dedicada, rodando o DAP e o
cliente LDAP, o servidor LDAP, e o DSA. Como pode ser observado na tabela, o atraso
introduzido pelo LDAP é mínimo. [HOWES,1995]

Tabela 4 Comparação do DAP e LDAP, tempo de respostas às perguntas (Query).


Perguntas são realizadas usando o mesmo DSA, com um cache de entradas. Os tempos
são em milisegundos

Pergunta (Query) DAP LDAP


Sem Autenticação 30 68
Autenticado 34 56
Pesquisa Simples (uma entrada) 32 41
Pesquisa Simples (50 entradas) 293 353

A tabela 2 mostra o tamanho das perguntas (Query) usados na tabela 1. Isso


demonstra que as perguntas LDAP são consideravelmente menores do que as perguntas
equivalentes em DAP. A economia é dividida primeiramente pela simplicidade do DN e o
valor de codificação. O tamanho das perguntas também são reduzidos pela falta de controle de
serviço em cada operação. [HOWES,1995]

Tabela 5 Comparação do tamanho das perguntas (Query) entre DAP e LDAP. As


perguntas LDAP são significativamente menores que as do DAP. O tamanho das
perguntas são em bytes.
Pergunta (Query) DAP LDAP
Sem Autenticação 192 14
Autenticado 409 138
Requisição de Pesquisas Simples 237 105
Resultados de Pesquisas Simples 547 355

As tabelas 3 e 4 mostram o tempo de decodificação e codificação, utilizando


uma variedade de típicas PDUs, DAP e LDAP. Elas mostram que o LDAP possui uma
pequena vantagem para PDUs simples e uma grande vantagem para PDUs complexas,
especialmente essas contendo muitos DNs onde a representação de caracteres LDAP é mais
significativa. [HOWES,1995]

50
Tabela 6 Comparação do tempo de decodificação entre DAP e LDAP. Elementos do
protocolo LDAP são facilmente decodificados, especialmente para PDUs complexos em
milisegundos.

Complexidade PDU DAP LDAP


Simples 550 110
Média 7925 714
Complexa 38393 2702

Tabela 7 Comparação do tempo de codificação entre DAP e LDAP em milisegundos.

Complexidade PDU DAP LDAP


Simples 24 6
Médio 1084 324
Complexo 2656 989

Finalmente, foi comparado o tamanho das implementações e complexidade do


código. A complexidade do código do DAP e a biblioteca de clientes LDAP são também
comparadas. Foram utilizadas duas medidas complexas. A primeira, um controle do número
aproximado de semi-colunas. A Segunda, um contador do número aproximado de declarações
“if”. No calculo de ambas métricas, houve um esforço para fazer uma única inclusão dessas
partes de código requerido para acesso X.500. [HOWES,1995]

Tabela 8 Comparação da complexidade de implementação entre DAP e LDAP. Contadores


de semicolunas, o número aproximado de declarações, e contador de declarações “if”, o
número aproximado de caminhos de código são outras medidas de complexidade.

Medida DAP LDAP


Texto 958.464 221.184
Dados 385.024 73.728
Contador de semi-colunas 46.746 1.989
Contadores IF 9369 568
São notáveis as diferenças no desempenho do LDAP em face ao DAP do
X500. Podemos observar que o LDAP simplifica de forma considerável a operações
utilizadas no X500 tanto para as perguntas (Query) quanto para as respostas do servidor, além
da codificação que também é mais simplificada o que dá maior agilidade e exige menos carga
aos seus processos e ao sistema. [HOWES,1995]

51
52
CAPÍTULO IV – PRINCIPAIS FERRAMENTAS LDAP

4.1. INTRODUÇÃO

Com a crescente abrangência da tecnologia da informação nas mais variadas


áreas do conhecimento humano, surge uma notável demanda de software para essas inclusões.
No entanto quando se faz necessário um tratamento mais específico, o problema se agrava
com a utilização de ferramentas proprietárias, ou seja, que tem todos os seus direitos
reservados a uma empresa que o produziu, na qual e qualquer pessoa ou empresa que deseje
utilizá-la, terá que pagar Royalty23.Com isso não é possível realizar adaptações necessárias a
esses softwares tornam-se ineficiente impedindo assim a continuidade de sua utilização.
Em oposição a isso, o Software Livre tem a seguinte proposta:
“Liberdade dos usuários executarem, copiarem, distribuírem, estudarem,
modificarem e aperfeiçoarem o software”. [GNU, 2005]
Ou seja:
• A liberdade de executar o programa, para qualquer propósito.
• A liberdade de estudar como o programa funciona, e adaptá-lo para as suas
necessidades.
• A liberdade de redistribuir cópias de modo que você possa ajudar ao seu
próximo.
• A liberdade de aperfeiçoar o programa, e liberar os seus aperfeiçoamentos,
de modo que toda a comunidade se beneficie.

23
Royalt – Tributo que é cobrado para a utilização de um serviço ou produto.
53
Nessa proposta, um software que em algum ponto deixasse de atender a uma
necessidade, poderia sem ônus algum ser alterado e adequado a sua função e posteriormente
redistribuído como forma de contribuição. Um outro ponto de grande relevância na proposta é
que nada é pago pela utilização da ferramenta.

4.1.1 FREEWARE

São os programas gratuitos e completos, não exigem registro e não têm taxa de
uso. Não é permitida sua alteração. [GNU, 2005].

4.1.2 OPEN SOURCE

A licença do Open Source Initiative em essência contém critérios para a


distribuição que incluem, além da exigência da publicação do código fonte, os seguintes
pontos:
 A redistribuição deve ser livre;
 O código fonte deve ser incluído e deve poder ser redistribuído;
 Trabalhos derivados devem poder ser redistribuídos sob a mesma licença do
original;
 Pode haver restrições quanto a redistribuição do código fonte, se o original foi
modificado;
 A licença não pode discriminar contra qualquer pessoa ou grupo de pessoas,
nem quanto a formas de utilização do software;
 Os direitos outorgados não podem depender da distribuição onde o software se
encontra.
 A licença não pode contaminar outro software.[OPEN SOURCE, 2005].

4.1.3 FERRAMENTAS LDAP

A cerca do estudo em questão, é proposto a utilização de softwares que se


enquadre nessa definição e para tanto será apresentado ferramentas para administração e
outros utilitários LDAP.

54
4.2. PHP LDAP ADMIN

O phpLDAPadmin é uma ferramenta poderosa, oferece facilidade em sua


configuração e intuitivo. É a ferramenta utilizada para administração de um servidor.
Fornece fácil acesso a seu usuário, ou seja, pode ser acessado em qualquer
lugar, possui forma hierárquica e funcionalidade avançada da busca. Trabalha em muitas
plataformas e sua base de usuários é composta na maior parte de profissionais da
administração do LDAP.

4.2.1 CARACTERÍSTICAS

• Browser da árvore de LDAP;


• Copia as entradas de LDAP (mesmo cópia entre usuários diferentes);
• Copias recursivas, árvores inteiras;
• Browser avançado do esquema de LDAP
• Buscas de LDAP ( simples e avançado)
• Exportação de LDIF e de DSML
• Importação de LDIF
• Controle da senha do usuário
• Determina automaticamente a raiz DN do seu usuário de LDAP
• Tradução amigável dos atributos
• Sustentação binária do atributo
• Configuração de modalidades de leitura apenas e de leitura/gravação.

55
Figura 11 - Página Inicial do phpLDAPadmin.

A primeira página é simples. Todas as características do phpLDAPadmin estão


acessíveis através do visor da árvore no frame esquerdo.

4.2.2 CRIANDO ENTRADAS DE LDAP

O sistema de templating flexível do phpLDAPadmin, permite que os


administradores criem entradas usando um processo automatizado.

56
Figura 12 – Criação de entradas.

Criação automatizada das entradas do LDAP com os moldes do


phpLDAPadmin.

4.2.3 EDITANDO ENTRADAS

Os moldes usados para editar entradas com o phpLDAPadmin, suportam uma


escala larga de atributos complexos, including campos booleanos, de jpegPhotos, de atributos
binários, e outros.

57
Figura 13 – Opções de manuseio phpLDAPadmin.

Visualização, adição, adição e remoção com o phpLDAPadmin de jpegPhotos


e vários outros.

4.2.4 MANUTENÇÃO DE DADOS

As sustentações do phpLDAPadmin automatizaram tarefas como entradas e


sub-árvores do LDAP, exporta o LDIF, o DSML e ainda importa no formato LDIF.

4.2.5 BUSCAS DE LDAP

58
Procura entradas com diferentes formulários de busca.

Figura 14 – Formulário de buscas.

O formulário simples é usado para fazer buscas rápidas e fáceis. Os resultados


são paginados em grupos e o formulário avançado faz a busca de acordo com suas
necessidades.

4.2.6 SUSTENTAÇÃO COMERCIAL DE SERVIDOR LDAP

O phpLDAPadmin suporta uma escala larga de servidores comerciais LDAP,


Novell, Sun, Microsoft, e de outros. Todo o servidor do diretório que usar LDAP, pode ser
administrado pelo phpLDAPadmin.

59
4.2.7 NOVELL

Figura 15 - Entrada de certificado LDAP Novell.

60
4.2.8 SUN ONE DIRECTORY SERVER

Figura 16 - Grupo de administradores do diretório SUN ONE.

4.2.9 MICROSOFT ACTIVEDIRECTORY

61
Figura 17 - Entrada Microsoft ActiveDirectory.

4.2.10 SUSTENTAÇÃO INTERNACIONAL DA LÍNGUA

O phpLDAPadmin determina automaticamente o idioma sem nenhuma


configuração extra (tem suporte para 11 idiomas). Dados do UTF-8 LDAP são suportados.

4.3. YALA

62
YALA é um GUI33 web para a administração do LDAP. A idéia é que ele
simplifique a administração do diretório com uma relação gráfica e características puras ao
contrário de outros browsers para o LDAP que são feitos especificamente para que usuários
controlem um determinado sistema.

4.3.1 CARACTERÍSTICAS

• Possui relação desobstruída e simples;


• Pode ser alcançado por toda a plataforma desde que se utilize um browser moderno
(Cross-Platform);
• Utiliza Javascript para melhorar a interface web, podendo ser ajustada de acordo a
preferência;
• Faz a leitura do esquema do usuário LDAP;
• Permite fazer uma configuração que reconheça uma entrada referente as classes de
objetos.

Figura 18 - Tela do início de uma sessão do YALA.

33
Grafic User Interface
63
64
Figura 19 – Árvore e índices de entrada específica.

Árvore LDAP no frame esquerdo e os índices de uma entrada específica (seus


atributos e valores) no frame direito.

65
Figura 20 – Sendo executado no Internet Explorer.

Figura 21 - Árvore de buscas no frame direito.

66
Figura 22 – Criação de uma nova entrada.

A árvore vista do frame esquerdo “cria uma tela com uma nova entrada” no
frame direito.

67
Figura 23 – Browser text-mode.

O YALA trabalha melhor com o browser das ligações text-mode.

4.4 LDAP BROWSER/EDITOR

Ferramenta utilizada para o gerenciamento de diretórios LDAP, desenvolvida


em Java (portanto bem portável), que auxilia na administração do LDAP.

4.4.1 CARACTERÍSTICAS:

• Sustentação do LDIF . As árvores inteiras e entradas únicas podem ser facilmente


exportadas para e importado LDIF.
• Moldes do objeto. Os moldes do objeto são usados criando e adicionando entradas
novas. Podem ser criados de forma manual ou automática.
• Sustentação binária do valor . Os índices do atributo podem ser conservados ou
carregados.

68
• LDAP. Permite especificar e indicar os atributos operacionais e também recuperar
contextos de nomes da raiz DSE do usuário.
• Sustentação do SSL.
• Arrasto (cópia-e-cola). Permite que entradas ou atributos sejam copiados, colados ou
arrastados dentro de um único browser.
• Sessões nomeadas. Permite trabalhar com LDAP fazendo configurações diferentes.
• Atributo viewers/editors . Cada atributo pode ser associado com um visualizador
particular que ajude a mostrar e editar os índices do atributo de uma maneira
específica.
• Sustentação do applet. O browser pode funcionar como um applet singed dentro de
um web browser.

Figura 24 – LDAP Browser editor.

4.5. SMBLDAP

É definido como um pacote de ferramentas que contem alguns certificados


úteis para controlar grupos quando se está utilizando LDAP. Estes certificados são aqueles
utilizados pelo samba-LDAP, que é integrado oficialmente ao samba. Ajuda a configurar o
samba e o OpenLDAP como um controlador preliminar de domínio para estações de trabalho

69
de Windows (e, usando o nss_LDAP e o pam_LDAP , uma fonte original do authentification
para todas as estações de trabalho, incluindo Linux e outros sistemas de Unix).

A versão mais atual, traz características como:

• Remendo ao smbLDAP-passwd para ser mais seguro;


• Reparos do erro para: relacionamentos e mensagens de erro ao usar o UserManager;
• Diretrizes orientadoras dos certificados para a sustentação de TLS;
• É compatível com samba v3.

Figura 25 – Tela de login do SMLDAP.

70
CAPÍTULO V – O LDAP E O GERENCIAMENTO DE USUÁRIOS

5.1. USUÁRIOS

Usuário é alguém que possui uma identificação e no uso dessa, lhe será
permitido usufruir de um serviço.Em termos técnicos, um usuário é uma entidade
identificada, e com essa identificação terá ou não acesso a um determinado serviço num dado
sistema. [AURÉLIO 1999][ADMINISTRADOR LINUX]

Exemplos de usuários:

• Usuários de rede;
• Usuários do Banco de Dados;
• Usuários de um web-server;
• Correntista de uma instituição financeira

5.2. GERENCIAMENTO

É o Ato de planejar, administrar, direcionar e organizar processos específicos a


uma determinada atividade. O gerenciamento é utilizado para viabilizar resultados concretos,
fazendo uso de todo e qualquer recurso, seja ele humano ou não. [AURÉLIO 1999]
[ADMINISTRADOR LINUX]

71
5.3. GERENCIAMENTO DE USUÁRIOS

Decorre do fato de organizar usuários, seus atributos, direitos, privilégios e


suas restrições em um sistema. A organização dos usuários em sistemas é feita de forma
estruturada, ou seja, cada usuário é inserido em um contexto ideal na regra do negócio.
A definição das regras de negócio é um estudo prévio para se delimitar as
prioridades e delegar níveis de importância aos processos que os usuários venham iteragir.
Um dos requisitos fundamentais para a existência de um usuário são suas
características para o contexto no qual se enquadra. Essas características impõem como ele
será identificado e tratado.
De maneira geral, o que define os atributos são as políticas de usuários, que
contém as regras de composição onde estão citadas, as prioridades e as formas de
administração. Uma criação de uma conta em uma instituição financeira exemplifica uma
política, onde o cliente deverá informar: nome, CPF, endereço, telefone, tipo de conta e senha.
A regra de criação de usuário da instituição complementará os atributos necessários, para que
o usuário interaja com o sistema, tais como: n° de agência, n° de conta, limite de cheque (caso
seja conta corrente), data para renovação dos dados cadastrais.
Com esse exemplo o usuário é criado através de atributos que servem para
identificá-lo, controlá-lo e agrupá-lo a outros usuários com perfil similar. Com um conjunto
de atributos definidos pela regra de negócio da instituição, o sistema é capaz de ter um
controle maior sobre as ações do usuário.

5.4. LDAP NO GERENCIAMENTO DE USUÁRIOS

O LDAP tem como objetivo gerenciar diretórios. Os diretórios são conjuntos


de atributos que contém dados sobre usuários, recursos e serviços de uma corporação e essa
pode estar distribuída, em uma matriz com várias filiais espalhadas pelo mundo.
Existe uma grande necessidade de gerenciar e manusear os dados de todos os
funcionários de uma determinada corporação. Um esforço desnecessário seria utilizado se,por
exemplo, um dos diretores de uma empresa com matriz em Londres, quisesse saber o e-mail
de um funcionário que trabalhe numa filial em Porto Alegre, incumbe sua secretária de entrar
em contato com o departamento de recurso humanos da matriz. O RH da matriz contata o RH
da filial, então é repassada a requisição para a gerência do departamento do funcionário que
irá consultar o sistema para recuperar esse dado, e por fim fazer todo caminho de volta.

72
Se houvesse uma re-alocação de um funcionário de uma matriz para uma filial,
o diretório onde contém informações do funcionário deve sofrer uma manutenção e todos os
diretórios com dados semelhantes, caso sejam descentralizados, devem ser encontrados para
que seja feito o mesmo procedimento. Isto acaba tornando o diretório ingerenciável, porque
sempre que vários serviços implementam suas próprias versões do mesmo estilo de diretório,
há uma duplicação de esforços.Cada serviço cria seu próprio diretório, e o administrador de
cada serviço tem que manter os diretórios separadamente, e é quase impossível administrar
centralizadamente estes múltiplos diretórios. Um outro problema de não se usar um diretório
unificado é a segurança, onde, cada serviço terá políticas de seguranças diferentes e
possivelmente conflitantes.
Então o LDAP traz uma solução para o compartilhamento e acesso a esses
dados em um sistema
Como o LDAP é um padrão aberto mantido pela IETF, ele pode ser utilizado
por qualquer corporação sem receio de ficar aprisionado a protocolos proprietários e permite
que a escolha da implementação seja baseada nos detalhes do projeto em vez de preocupações
de interoperabilidade.
Como o LDAP foi projetado para ser um diretório de propósito geral, ele teve
que ser extensível. Usando um esquema de definição orientado a objeto, baseado em herança,
que permite fácil extensão para qualquer uso. Existe um esquema básico que é parte da
especificação do LDAP, e existem outros padrões de fato para vários serviços.
Um dos mais importantes aspectos do desenvolvimento do LDAP, e que fez
com que o mesmo fosse adotado é que ele é um protocolo simples de implementar e trabalhar.
Isto fica transparente pelo fato que o LDAP é suportado pela maior parte das linguagens de
programação e também por grande parte dos sistemas operacionais de mercado.
É possível replicar todo ou parte de um diretório LDAP para locais separados
fisicamente, o que permite que os dados tenham alta disponibilidade e coloca os mesmos tão
próximos quanto necessários do cliente. Utilizando referências, porções de diretório podem
ser distribuídas em diferentes servidores LDAP, permitindo assim que partes de uma
corporação ou projeto tenham controle sobre os dados necessários ao mesmo tempo em que
mantém uma única autoridade sobre cada parte dos dados.O LDAP é totalmente integrado
com esse recurso de replicação través de um deamon chamado slurpd
Outra função muito importante do LDAP no gerenciamento de usuários, diz
respeito aos direitos de acesso, através dos serviços do LDAP é possível definir qual o nível
de acesso que cada componente da corporação possui para cada tipo de arquivo, diretório ou

73
pasta, que ele pode acessar. Define por exemplo se um usuário tem acesso de escrita em um
determinado diretório ou apenas de leitura, dependendo do seu nível hierárquico e dentro do
organograma da empresa. Protegendo assim, que se tenha acesso indevido a arquivos
confidenciais da organização, não permitindo que usuários mal intencionados venham a ferir
sua integridade.
Existem três aspectos básicos na proteção de informação em um diretório:
acesso, autenticação e autorização. Acesso é a habilidade de conectar-se a um serviço e pode
ser restringido baseado em detalhes como: login ou endereço IP. Autenticação é a habilidade
de provar ao servidor que um cliente é um usuário válido, e autorização é o serviço
fornecendo ou negando direitos específicos ou funcionalidades ao cliente.
O LDAP fornece também recursos para autenticação e segurança dos dados,
com a utilização de chaves criptográficas e certificados digitais, esses métodos que são
indispensáveis para a segurança nas grandes organizações e no LDAP são facilmente
implementados, pois esses recursos são nativos do sistema, implementados pela ACL.
Para acesso seguro, o LDAP suporta o Transport Layer Security (TLS), que
criptografa toda a comunicação entre cliente e servidor. Para autenticação, o LDAP suporta a
Simple Authentication and Security Layer (SASL), e permite que o cliente e o servidor
negociem um método seguro de autenticação.
O TLS e o SASL provêm funcionalidades criptográfica, mas não o controle
sobre o acesso e autenticação. O LDAP irá fornecer a habilidade de controlar todos os três
aspectos através de Access Control Lists (ACLs). As ACLs podem ser usadas para autorizar o
acesso baseado em muitos fatores. Elas podem ser usadas para forçar tipos específicos de
autenticação e, uma vez que o cliente esteja plenamente autenticado como usuário válido, as
ACLs são usadas para autorizar o usuário.
Então, com a utilização do LDAP, é possível gerenciar usuários de grandes
corporações de forma simples, com grande segurança e agilidade que toda grande empresa
necessita, disponibilizar dados pessoais e profissionais dos usuários mesmo em longas
distâncias, pois e facilmente integrado a web. Direcionar níveis de acesso aos usuários de
acordo com seu nível de atuação dentro do organograma da empresa. Tudo isso disponível
com total transparência para o usuário e transmitindo grande confiabilidade tanto nos dados
quanto no serviço.

74
CONCLUSÃO

Neste trabalho de pesquisa, foram analisados os principais aspectos do


protocolo LDAP como: segurança, integração, funcionalidades, arquitetura e implementação.
Tudo isso aplicado a um serviço de grande importância nas grandes organizações que é o
gerenciamento de usuários.
O LDAP vêm se tornando um padrão para serviço de diretórios. Sabendo da
importância que grandes organizações dão hoje ao gerenciamento de usuários, da crescente
demanda por uma ferramenta padrão que possa fazer o serviço com baixo custo de
implementação, de recursos de processamento e, também, da crescente procura por esse tipo
de serviço através da comunidade da Internet e empresas de todo o mundo, como a IBM, a
At&t e muitas outras, veio a necessidade de conhecermos como o LDAP funciona e porque
deveríamos utilizá-lo.
Outro fator importante é que o LDAP possui seu código-fonte aberto e sua
distribuição é gratuita; possui também uma grande comunidade de desenvolvimento que
busca sempre aperfeiçoar o serviço, utilizando-se dessa ferramenta poderosa que emprega ao
mesmo tempo a integração de um protocolo de rede, que trabalha sobre o TCP/IP e um
serviço de diretórios robusto, fortemente integrado com diversos recursos.
Nosso estudo foi baseado em software livre, pelo grande enfoque que vem
sendo dado a esse tipo de distribuição, tanto pelo governo federal, quanto por grandes
organizações.
Pode ser percebido durante o trabalho de pesquisa e pela implementação do
protótipo que o serviço de diretórios LDAP é uma ferramenta robusta, de fácil implementação
e possui grande extensibilidade. Além disso, cumpriu o propósito pelo qual ela foi escolhida:
a gerência de usuários nas grandes corporações. Tivemos a oportunidade de observar na
prática o funcionamento do serviço de diretórios, utilizando uma situação hipotética e
percebemos como o LDAP é importante para o gerenciamento de usuários, além de o porque
dele estar se tornando um padrão. Portanto, conclui-se que é possível gerenciar usuários de
forma consistente e segura em um ambiente corporativo, aplicando as funcionalidades do
LDAP.

75
ANEXO I – DOCUMENTAÇÃO ACERCA DA IMPLEMENTAÇÃO DO PROTOCOLO LDAP PARA
GERENCIAMENTO DE USUÁRIOS

1. OBJETIVO GERAL

Visando utilizar uma só tecnologia para implementar autenticação de usuários


e centralização de informações em uma única base dados distribuída, serão demonstradas duas
das várias funcionalidades do LDAP: autenticação de usuários (integrando LDAP com PAM)
e busca de informações relevantes para um ambiente corporativo de forma rápida e simples
que serão detalhados oportunamente.

2. DESCRIÇÃO E ABRANGÊNCIA

O Protótipo se baseará em um ambiente simulado, caracterizando uma empresa


cujo seus serviços estarão dispostos de forma integrada, será salientado características do
LDAP que são: multiplataforma34, leveza de entrega de pacotes, distribuição de dados e
segurança. Mostrando para isso a autenticação de usuários e a busca de informações, sendo
necessário privilégio para acessá-las, fazendo uso das ACL's e de outros serviços como:
SAMBA35, NSS36 e PAM37.
Na primeira parte da demonstração do protótipo será configurado um sistema
de login, fazendo com que um usuário de uma estação de trabalho seja autenticado em um
Servidor LDAP, sendo que neste servidor estarão configurados níveis de acesso para cada
pasta compartilhada no servidor de arquivos SAMBA, fazendo uso das ACL’s da base de
dados LDAP.
Na segunda parte será demonstrada a centralização de informações e a busca
das mesmas por usuários, obedecendo a suas permissões de acesso à informação. Para isso
faremos uso do cliente de e-mail, o Microsoft® Outlook Express. Será simulado uma busca de
e-mails, telefone, endereço e departamento de usuários previamente cadastrados na base de
dados LDAP.

34
Multiplataforma é a característica de um mesmo software ser executado em vários tipos de sistemas
operacionais.
35
SAMBA, servidor open souce que permite integração do Linux com S.O. Microsoft e Machintosh.
36
NSS, Name Service Switch, software responsável pela informações sobre autenticação em sistemas UNIX.
37
PAM, software que provê autenticação de usuários, pode trabalhar em conjunto com outros sistemas de
autenticação.
76
3. RECURSOS DE HARDWARE E SOFTWARE

Será necessário para a execução do projeto dois micro computadores, cabos


UTP, HUB 10/100, um roteador para fazer o papel de gateway38 da rede, cabos de força e
estabilizador.
As configurações dos microcomputadores são: Atlhon XP 2.200 + com 512
MB de memória RAM, 40 GB de disco rígido, placa de rede 3com 10/100 e um NOTEBOOK
2 GIGAPRO com 30 GB de disco rígido, 256 MB de memória RAM com placa de rede
10/100. Os microcomputadores já estarão com os seus devidos sistemas operacionais
instalados.
Será enfatizada a potencialidade do software livre, porém somente no âmbito
da disponibilização dos serviços, onde se centraliza uma gama de funcionalidades que o
LDAP pode oferecer.
Em se tratando de um servidor LDAP, será utilizado o OpenLDAP integrado
com banco de dados hierárquico BerkeleyDB39. A grande motivação para a escolha desses
softwares é sua crescente valorização, tendendo a se transformar em um padrão de mercado.
Esses serviços terão como suporte o sistema operacional GNU/Linux Kurumin,
que foi escolhido, por seu módulo de detecção de hardware muito evoluído, sua leveza, sua
documentação e por ser baseado em umas das mais robustas distribuições GNU/Linux
existentes no mercado, o Debian. Como servidor de arquivos e PDC40 será utilizado o
SAMBA e como suporte a autenticação de usuários, será utilizada a biblioteca PAM e NSS
integrados com o LDAP.

3.1. GNU/LINUX – KURUMIN

O Kurumin é uma distribuição Linux destinada a Desktops41 baseada


originalmente no Debian/Knoppix.
Existem muitas distribuições Linux recomendadas para uso em servidores,
como: Debian, Red Hat, Fedora, Mandrake e Slackware. Poucas distribuições implementam
um sistema de reconhecimento de hardware e facilidade em seu uso como o Kurumin.[GUIA
DO HARDWARE]

38
equipamento responsável pela interligação de duas ou mais segmentos de rede.
39
Banco de dados hierarquico
40
PDC primary Domain Contrller , sistema que controla um domínio de rede
41
Desktops é o termo em língua inglesa que exprime um equipamento computacional voltado para usuários
77
3.2 OPENLDAP

O projeto OpenLDAP é um esforço colaborativo da comunidade Open Source


para desenvolver um sistema de aplicações LDAP. O fundador deste projeto é o americano
Kurt Zeilenga. Hoje existem vários desenvolvedores engajados neste sistema que está se
tornando um padrão universal. Logo abaixo são explanados seus principais componentes:

3.2.1. SLAPD

SLAPD é um servidor standalone de diretórios utilizado para prover serviços


LDAP, por meio dele podemos configurar todas as funcionalidades deste serviço, tais como:
base DN, login de administrador, requisitos de segurança e ACL’s. Algumas das
características importantes do SLAPD são:
• SLAPDv3 - O Slapd versão 3 possui suporte a IPv4 e IPv642;

• Simples autenticação segura - O Slapd suporta uma forte segurança através do


uso de SASL, o qual utiliza mecanismos como MD5, EXTERNAL e GSSAPI;
• Suporte a SSL;
• Controle de acesso - possui um rico e poderoso controle de acesso, garantindo
a segurança das informações no banco de dados e controlando as entradas
baseadas no sistema de autenticação, endereço IP, domínio, e outros critérios;
• Diversificação de banco de dados - O Slapd possui diversas opções de banco
de dados, Incluindo BDB e LDBM;
• Permite vários bancos de dados no mesmo servidor;
• Possui Threads para alto desempenho;

• Replicação (slurpd) - o slapd permite ser copiado para outros servidores,


podendo existir servidores master e slave, aumentando sua disponibilidade;
• É configurado através de um único arquivo de
configuração, facilitando sua manutenção.

3.2.2 BACKEND DE BANCO DE DADOS – BERKELEYDB

42
Versões de protocolo da internet
78
Uma observação importante a respeito do OpenLDAP, diz que ele apenas
provê o serviço LDAP e manipulação de informações, ou seja, há necessidade de um backend
de banco de dados para armazenar estas informações.
BerkeleyDB é um banco de dados famoso por sua robustez, produtividade e
escalabilidade. É utilizado em soluções de missão crítica por grandes empresas como a
Hitachi, HP, Sun, Amazon, NASDAQ, FujiXerox, Alcatel, British Telecom, Cisco,
RSA Security, EMC, Veritas e Motorola.
O BerkeleyDB pode ser usado em aplicações que necessitem de storages
concorrentes de alta produtividade, na recuperação de pares de chaves e valores. O software é
distribuído como uma biblioteca que pode ser compilada diretamente nas aplicações. Também
pode ser acessado através de interfaces definidas para algumas linguagens como: C, C++,
Java, Perl, Python e TCL. É importante saber que o BerkeleyDB não é um servidor de banco
de dados que manipula conexões de rede, não pode ser considerado como um SGBD
relacional ou orientado a objetos e também não possui uma linguagem de consulta como o
SQL.

3.3. APACHE, PHP E PHPLDAPADMIN

O Projeto Apache é o resultado de um esforço coletivo de colaboradores para o


desenvolvimento de um software robusto, gratuito e com qualidade para a implementação de
um servidor HTTP (HyperText Transfer Protocol) altamente usado na Internet. O projeto é
administrado por um grupo de voluntários distribuídos no mundo todo, que se comunicam
através da Internet para planejar e desenvolver o Apache e sua documentação. [APACHE]
Este software é extremamente necessário, pois juntamente com o PHP formam
a base para viabilizar o uso da ferramenta gráfica de configuração do servidor LDAP, o
PHPLDAPADMIN.
A manipulação de objetos será feita através desta interface.
O PHPLDAPADMIN é uma ferramenta web para controlar todos os aspectos
do servidor LDAP, sendo uma ferramenta versátil e open source para administração de
usuários e grupos em um serviço de diretório. Existem aplicações front end no mercado mas
essa ferramenta foi escolhida por ser bem intuitiva e de fácil configuração, contendo uma

79
gama de recursos que vem sendo utilizados no protótipo. O PHPLDAPADMIN pode ser
usado para administrar: OpenLDAP, Active Directory, Novell eDirectory e iPlanet43

3.4. MICROSOFT WINDOWS XP®

O Windows XP® é a última versão do sistema operacional para desktops da


Microsoft, tem como características suportar vários processadores, ser multiusuário e de boa
integração com o Hardware devido ao sistema Plug and Play44.
Este Sistema Operacional será usado por dois motivos: para mostrar uma das
características mais importantes do LDAP que é sua capacidade de integração com diversas
plataformas, ou seja, um software multiplataforma, o outro motivo é sua grande utilização no
mercado corporativo e sua facilidade de utilização. O Microsoft Windows XP® será usado
apenas como host cliente.

3.5 OUTLOOK EXPRESS®

O software Outlook Express® é um dos clientes de e-mail da Microsoft®, por


meio deste será demonstrada a facilidade de busca de informações sobre usuários do sistema,
e mais uma vez comprovando o poder de integração do LDAP.

4. CONFIGURAÇÕES

Neste tópico serão abordadas a instalação e configuração dos softwares


necessários para o funcionamento do protótipo, que serão divididas em: configuração dos
servidores e do cliente. Sendo observados os aspectos de lógica e ordem de configuração dos
serviços, abordaremos primeiramente as configurações da máquina servidora.

43
Active Diretory, Novell e iPlanet são serviços de diretórios similares ao OPENLDAP, porém softwares
proprietários.
44
Plug and Play é um sistema automático de detecção de hardware, esse sistema facilitou muito a utilização de
periféricos por usuários leigos.
80
4.1 SERVIDOR

4.1.1 BERKLEYDB

Para que o OpenLDAP possa armazenar as informações em nodos, será


utilizado o Banco de dados BerkeleyDB versão 4.1.25. Este software é distribuído no formato
tar.gz no site oficial do software, o nome do arquivo é db-4.1.25.Nc.tar.gz. Este é um formato
que possibilita fazer configurações no aplicativo diretamente em seu código fonte.
[SLEEPCAT]

4.1.1.1 INSTALAÇÃO E CONFIGURAÇÃO

Com o arquivo db-4.1.25.Nc.tar.gz, já baixado e executado uma rotina de


descompactação (gz), desempacotamento (tar), compilação do Makefile e finalmente a
instalação dos binários e bibliotecas, foram obedecidos os seguintes passos:
Desempacotar e descompactar:
$ tar -zvxf db-4.1.25.Nc.tar.gz;
• Após a execução do procedimento anterior, uma nova pasta será criada com o
nome do pacote, então o caminho completo ficará “/home/kurumin/db-4.1.25”,
pois o procedimento foi efetuado como usuário comum chamado “kurumin”;
• Dentro da pasta db-4.1.25, existe uma sub-pasta denominada dist, nesta deverá
ser feito os procedimentos de configuração, compilação do código fonte e
instalação dos binários gerados pela configuração.
• Na pasta dist existe um arquivo chamado configure, que é, a base da
configuração de qualquer pacote distribuído em código fonte, em sistemas
Linux.
O arquivo configure é um script shell que examina o sistema para verificar se
as diversas dependências necessárias para compilar o projeto serão satisfeitas. Ele procura por
compiladores, bibliotecas, utilitários e outros itens que deverão estar presentes no sistema,
também pode receber informações extras do usuário através de diretivas de compilação como:
habilitar ou desabilitar opções incluídas ou excluídas do objeto a ser compilado.
Se uma ou mais dependências não forem satisfeitas, este script avisará ao
usuário para que ele possa resolver tais pendências, instalando arquivos e programas

81
necessários ao projeto. Depois de reunir toda informação necessária o configure gera um
arquivo Makefile customizado para o sistema.[CERTIFICAÇÃO LINUX]
Para que seja feita a conferência das dependências no sistema, deve-se executar
o script configure como super usuário do sistema:

kurumin@angel:~/db-4.1.25/dist# .configure

Após a etapa de conferência das dependências, será necessário compilar e instalar o


backend de banco de dados BerkeleyDB:
Compilando:

kurumin@angel:~/db-4.1.25/dist# make

Instalando:

kurumin@angel:~/db-4.1.25/dist# make install

Executado os processos citados acima, a biblioteca BerkeleyDB estará


devidamente instalada e configurada no sistema Linux.

4.1.2 OPENLDAP

4.1.2.1 INSTALAÇÃO E CONFIGURAÇÃO

Neste tópico será abordada a instalação do servidor LDAP Open Source


OpenLDAP em um ambiente GNU/Linux utilizando o shell padrão bash como interface de
configuração.
Para a instalação, será usado como gerenciador de Pacotes (.deb) o padrão apt
da Debian, por ter um sistema de busca de pacotes e conferência de dependências muito
eficientes. Serão resolvidas questões de dependências deste pacote instalando as bibliotecas
necessárias para que o sistema funcione corretamente e por último instalaremos o servidor

82
LDAP slapd.
Para utilizar o apt, será necessário acessar como super usuário no sistema
linux, depois disso será executado o comando apt-get com o parâmetro install e em seguida o
nome do pacote .deb. Também serão instalados os utilitários do OpenLDAP , ou seja, o
cliente LDAP e suas bibliotecas:

Figura 26 – apt-get listando os pacotes e suas dependências.

Conforme a figura 29, ao chamar o pacote LDAP-utils 2.2.23-1.deb, o apt-get


checa as dependências do pacote e as instala, neste caso, foi instalado por dependência, o
pacote libLDAP-2.2-7 2.2.23-1 que são as bibliotecas responsáveis pela execução do LDAP e
foi atualizado o pacote de SASL chamado libsasl2_2.1.19-1.5_i386.deb.
Com o BerkeleyDB e o cliente instalados, deverá ser executada à instalação do
Servidor SLAPD e também configurá-lo através do Debconf. Para tanto será usado
novamente o apt para a instalação do pacote slapd:

83
Figura 27 - apt listando os pacotes slapd e suas dependências.

Ao chamar a instalação do slapd, o apt informa a versão slapd_2.2.23-


1_i386.deb que irá instalar também duas bibliotecas necessárias para a execução do servidor,
estas bibliotecas são libiodbc2_3.52.2-3_i386.deb e libltdl3_1.5.6-6_i386.deb.
Depois de instalado, o Debconf é chamado automaticamente para que sejam
inseridos os parâmetros iniciais de configuração do arquivo slapd.conf, localizado no diretório
/etc/LDAP/slapd.conf conforme a figura a seguir:

84
Figura 28 – Debconf iniciado, para iniciar os primeiros parâmetros do servidor LDAP.

Na figura 31, foi informado o domínio DN que o servidor LDAP irá responder.
No caso do protótipo, foi escolhido o domínio “LDAP.DF” ou DN dc=LDAP,dc=df.
Na figura 32, o DEBconf permitirá a escolha da compatibilidade com o
protocolo LDAPv2, protocolo antigo que ainda é usado por algumas aplicações. Como o
protótipo baseia-se totalmente no protocolo LDAPv3, não há a necessidade de habilitar a
opção de compatibilidade.

Figura 29 - Debconf pergunta sobre compatibilidade para o LDAPv2.

85
A figura 33 mostra a escolha de uma senha para o administrador da base de
dados LDAP chamado “cn=admin, dc=ldap,dc=df”, este usuário tem acesso total às
informações contidas nos diretórios.

Figura 30 – Debconf na configuração do slapd, solicitando a senha do administrador.

Após Escolha da senha, o slapd cria suas diretivas iniciais no arquivo


slapd.conf e uma base de dados inicial para que se possa utilizar e povoar essa base de acordo
com as necessidades.
Após a instalação do servidor OpenLDAP , será necessária a configuração de
sua Base DN.
Será demonstrada na íntegra a estrutura do arquivo de configuração do servidor
slapd, que fica localizado em /etc/LDAP/slapd.conf, afim de melhor visualizar os parâmetros,
características e a maneira de como o servidor irá se comportar. Também será demonstrada a
inclusão de schemas como: samba3x.schema. É neste arquivo de configuração que se pode
visualizar o usuário root do serviço LDAP no protótipo e o tipo de Banco de dados, no caso o
berkeleyDB, que é identificado pelo daemom dbd.

86
#########################################################
# Allow LDAPv2 binds
allow bind_v2

# This is the main slapd configuration file. See slapd.conf(5) for more
# info on the configuration options.

#########################################################
# Global Directives:

# Features to permit
#allow bind_v2
rootdn="cn=admin,dc=ldap,dc=df"
rootpw= deus

# 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
include /etc/ ldap /schema/samba3x.schema
# Schema check allows for forcing entries to
# match schemas for their objectClasses's
schemacheck on

# 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.args

# Read slapd.conf(5) for possible values


loglevel 0

# Where the dynamically loaded modules are stored


modulepath /usr/lib/ ldap
moduleload back_bdb

#########################################################
# Specific Backend Directives for bdb:
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend bdb
checkpoint 512 30

#########################################################
# Specific Directives for database #1, of type bdb:
# Database specific directives apply to this databasse until another
# 'database' directive occurs
database bdb

# The base of your directory in database #1


suffix "dc= ldap,dc=df"

87
# Where the database file are physically stored for database #1
directory "/var/lib/ldap"

# Indexing options for database #1


index objectClass eq

# Save the time that the entry gets modified, for database #1
lastmod on

# The userPassword by default can be changed


# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below

access to attrs=userPassword
by dn="cn=admin,dc=ldap,dc=df" write
by anonymous auth
by self write
by * none

access to dn.base="" by * read

# The admin dn has full write access, everyone else


# can read everything.
access to *
by dn="cn=admin,dc=ldap,dc=df" write
by * read

########################################################

4.1.2.2 MIGRAÇÃO

Para que se viabilize a migração de dados de usuário do GNU/linux para um


arquivo padrão LDIF é necessária a instalação do pacote migrationtools executando o
comando: # apt-get install migrationtools. Para que funcione corretamente este software
necessita da versão 5 da linguagem perl, o apt resolveu todas as questões de dependência de
pacotes.
Diferente da maioria dos pacotes linux, o arquivo de configuração não fica na
pasta /etc (padrão linux) entretanto, localiza-se na pasta /usr/share/migrationtools/, essa
diferença é devido a extensão do arquivo de configuração que não pertence ao padrão .conf e
sim ao padrão .ph, o nome do arquivo de configuração é migrate_common.ph. Neste será
informado o DNS do servidor de e-mail e o sufixo da base LDAP.

88
#############/usr/share/migrationtools/migrate_common.ph##########

#Default DNS domains

$DEFAULT_MAIL_DOMAIN = “angel.ldap.df”

$DEFAULT_BASE = “dc=ldap, dc=df”

##################################################

Após a configuração basta executar os seguintes comandos:


O comando a seguir irá criar entradas de dados sobre todos os usuários do
sistema, incluindo usuários de serviços, como por exemplo bind.

#./migrate_passwd.pl /etc/passwd /tmp/usuarios.ldif

O comando a seguir irá criar entradas sobre os grupos do sistema linux em


formato padrão LDIF.

#./migrate_group.pl /etc/group /tmp/grupos.ldif

Ao executar o comando a seguir, o script definirá os objetos básicos para a


criação diretório.

#./migrate_base.pl > base.ldif

Os comandos acima apenas geram arquivos em formato LDIF, ou seja, geram


entradas padrão para inserção de objetos no diretório LDAP. Para que essas informações
realmente sejam inseridas no contexto LDAP, será necessário executar o comando: LDAPadd
-x -D “cn=admin, dc=LDAP, dc=df” -f arquivo.ldif e deverá seguir uma ordem lógica: base -
grupos – usuários. Para cada arquivo gerado anteriormente deverá ser executado um comando
de inserção LDAPadd. O sistema estará pronto para receber autenticações via LDAP, pois
todo seu esquema de usuários foi migrado para a base LDAP.

89
4.1.3 SISTEMA DE AUTENTICAÇÃO

A autenticação é um processo que ocorre quando um usuário está tentando ter


acesso a um sistema, tendo suas credenciais checadas antes de ter permissão de acesso.
Normalmente isso significa que é necessário o usuário fornecer um nome de login e senha.
Muitos programas diferentes fornecem autenticação, cada um usando um método diferente,
desde o mais simples até os mais sofisticados utilizando chaves públicas.

4.1.3.1 PAM E NSS

O PAM (Pluggable Authentication Modules – Módulos de autenticação


Plugáveis) é um conjunto de bibliotecas que fornecem uma interface consistente a um
protocolo de autenticação. Uma aplicação pode usar as bibliotecas PAM para permitir o uso
de qualquer protocolo de autenticação dentro da aplicação, desde que exista um módulo PAM
para o sistema de autenticação.
O PAM somente fornece parte da informação necessária para controlar os
usuários em um sistema linux. Além de permitir checar se um usuário entrou com a senha
correta, um sistema Linux precisa de informações como: o ID numérico do usuário, o
diretório HOME, o Shell padrão, etc. Estas informações, que normalmente é armazenada no
arquivo /etc/passwd, podem ser determinadas através de uma interface de sistema conhecida
como NSS, ou Name Service Switch.

4.1.3.2 INSTALAÇÃO E CONFIGURAÇÃO DO NSS E PAM

Para que todos os serviços do sistema autentiquem no LDAP, é necessário


informar ao sistema que deverá buscar as informações no diretório LDAP e não mais nos
arquivos relacionados a usuários como /etc/passwd, /etc/group e /etc/shadow, onde ficam em
uma configuração padrão do linux, as informações sobre o esquema de usuários, grupos e
senhas.
O LDAP inclui funcionalidades que o tornam útil tanto para o PAM quanto
para o NSS, pois podem autenticar usuários e obter informações adicionais sobre os mesmos
como: nomes de diretórios home e shell.
Para que o sistema NSS possa interagir com o LDAP é necessária à instalação
e configuração do módulo NSS para LDAP chamado libnss-LDAP, que podem ser executadas

90
através do apt, conforme comando abaixo:

# apt-get install libnss-ldap

Será obtido os arquivos necessários e satisfeitas todas as dependências do


pacote, novamente o Debconf será utilizado para inserção de informações necessárias para
que o modulo libnss-LDAP funcione.

Figura 31 - Debconf inicia os parâmetros de configuração do nss-ldap.

Conforme a figura 7, o libnss-ldap solicita o nome do computador no domínio


ou aconselha a utilização do IP, caso haja algum problema com serviço DNS o serviço libnss-
ldap não pare de funcionar.
O endereço da Base de dados LDAP também é solicitado, já que é dela a fonte
de dados sobre usuários do sistema.

91
Figura 32 - Debconf solicita a base DN do LDAP.

É necessário para que a biblioteca libnss-ldap funcione, a definição da versão do


protocolo LDAP que está instalado no sistema. Como dito anteriormente no tópico sobre a
instalação do OpenLDAP, a versão do protocolo LDAP é o LDAPv3.

Figura 33 – Debconf pergunta qual versão LDAP foi instalada.

92
Concluída a instalação e configuração da biblioteca libnss-ldap, será necessária
a instalação da biblioteca PAM para se integrada com LDAP, chamada libpam-ldap,
responsável pela passagem de diretivas para que o PAM busque informações na base do
LDAP. Executando o comando apt seguido do nome desta biblioteca, está será instalada
conforme abaixo.

# apt-get libpam-ldap

Após a execução do comando acima, o Debconf é chamado para que sejam


informados parâmetros de configuração, necessários para o funcionamento da biblioteca. O
principal parâmetro é a base DN do servidor LDAP.

Figura 34 – Debconf solicita o usuário administrador da Base DN.

Após a instalação e pré-configuração de ambas as bibliotecas, deverá ser


checado o arquivo de configuração do cliente LDAP, para que ele possa buscar informações
sobre usuários na base LDAP, para isso será necessário acrescentar parâmetros de um usuário,
senha e a autenticação PAM, conforme a figura abaixo:

93
Figura 35 – Arquivo de configuração do cliente LDAP.

O sistema operacional deverá agora ser informado de que deverá buscar informações
sobre usuários no LDAP e não mais nos arquivos padrão. O arquivo /etc/nsswith.conf deverá
conter o parâmetro “LDAP” nas entradas “passwd”, “group”, “shadow”.

Figura 36 – Arquivo de configuração do nsswitch.

94
Configurar a PAM para autenticar no LDAP e também para autenticar
localmente no sistema, caso esse serviço pare de funcionar consiga autenticar pelo sistema.
Para isso é adicionado os parâmetros “auth sufficient /lib/security/pam_LDAP.so
use_first_pass” e “account sufficient /lib/security/pam_LDAP.so” com essas configurações o
sistema está pronto, um teste deverá ser feito para assegurar que a autenticação está sendo
realizada na base de dados LDAP, com os comandos: getent passwd e getent group. Deve
retornar usuários e grupos que estão no diretório.

4.1.4 SAMBA

O SAMBA terá papel importante nesse ambiente, pois a partir dele, se proverá
um PDC (Primary Domain Controller), ou seja, um serviço que responderá por um domínio
(LDAP.df) para que máquinas com sistema operacional Windows (devidamente configuradas)
possam ingressar no domínio e usufruir dos serviços de arquivos. O SAMBA será
devidamente configurado para que haja uma integração entre o LDAP, o mesmo armazenará
todas as contas e restrições de usuários, ou seja, nenhum usuário será armazenado no
smbpasswd.

4.1.4.1 INSTALAÇÃO E CONFIGURAÇÃO

O gerenciador de pacotes .deb será novamente utilizado, porém com um


pequeno ajuste, pois, a versão utilizada será a versão 3 do SAMBA, o apt apenas instala os
pacotes considerados “estáveis”, no caso o SAMBA versão 2. Para o apt instalar a última
versão do samba, será necessário executar o seguinte comando:

#apt-get install samba -t unstable

A versão 3 do SAMBA é uma versão mais evoluída e com menos “bugs” e


com maior integração com outros sistemas como: Windows, LDAP, etc.
O SAMBA possui somente um arquivo de configuração situado no diretório
/etc/samba, é identificado pelo nome de smb.conf e toda sua configuração será feita através
deste arquivo. O arquivo será mostrado na íntegra e possui duas partes bem divididas, a parte
global que é responsável pela configuração do samba com integração com outros sistemas e
nomeação de PDC e a parte de diretórios compartilhados, onde são declarados diretórios de

95
armazenamento de arquivos e impressoras. A seguir é demonstrado o arquivo smb.conf com
comentários somente nas partes relevantes:
[global]
workgroup = ldap.df (identifica o nome do domínio)
netbios name = PDC (identifica o nome do servidor samba)
server string = PDC (comentário breve do sobre o servidor samba)
security = user
encrypt passwords = yes
load printers = yes
log file = /var/log/samba/log.%m
max log size = 100
os level = 100 (essa numeração indica que o samba sempre será o PDC de uma
rede windows)
local master = yes
domain master = yes
preferred master = yes
domain logons = yes (libera que usuários loguem no domínio)
admin users = root (usuário administrador)
logon script = %U.bat (script que maquinas windows usaram)
logon path = \\%L\profiles\%U
wins support = no
dns proxy = no
LDAP passwd sync = yes
LDAP delete dn = yes
passdb backend = LDAPsam:LDAP://127.0.0.1/ (informa que os usuários estão no
LDAP)
LDAP admin dn = cn=admin,dc=LDAP,dc=df
LDAP suffix = dc=LDAP,dc=df
LDAP group suffix = ou=Grupos
LDAP user suffix = ou=Pessoas
LDAP machine suffix = ou=Computadores
idmap uid = 10000-15000
idmap gid = 10000-15000
nt acl support = yes
create mask = 600
directory mask = 0700
force directory mode = 0700
passwd chat = *New*password* %n\n *Retype*new*passoword*
%n\n*passwd:*all*autentication*tokens*update*successfuly*

96
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=8192 SO_SNDBUF=8192
#script de adicionar maquinas ao dominio utilizando uma ferramenta chamada smbLDAP -tools
que será #explicada posteriormente
add machine script = /urs/local/sbin/smbLDAP-useradd -w "%u”
add user script = /usr/local/sbin/smbLDAP-useradd -m "%u"
delete user script = /usr/local/sbin/smbLDAP-userdel "%u"
add group script = /usr/local/sbin/smbLDAP-groupadd -p '%g"
delete group script = /usr/local/sbin/smbLDAP-groupdel "%g"
add user to group script = /usr/local/sbin/smbLDAP-groupmod -m "%u"
delete user from group script = /usr/local/sibn/smbLDAP-groupmod -x "%u" "%g"
set primary group script = /usr/local/sbin/smbLDAP-usermod -g "%g" "%u"
dos charset = UTF-8 (codificação de caracteres para o DOS)
unix charset = UTF-8
cups server = 127.0.0.1 (servidor de impressão cups)
#### apartir deste ponto o Global settings acaba###
[homes]
comment = Diretorio home
browseable = no
writable = yes
force user = %U
[profiles]
path = /home/profiles
read only = no
create mask = 0600
directory mask = 0700
browseable = no
guest ok = Yes
profile acls = yes
csc policy = disable
force user = %U
valid users = %U @"Domain Admins", %U @”Domain Users”
[netlogon]
path = /home/netlogon
browseable = no
read only = yes
[printers]
comment = Impressoras
path = /var/spool/samba
browseable = no
guest ok = no
writable = no
printable = yes

97
[dados]
comment = Diretório de provas e dados secretos
path = /home/dados
public = no
writable = yes
printable = no
create mask = 0765
read lis = @Dados
invalid users = @Material
read list = @Dados
valid users = @Dados
user = @Dados
[Material]
comment= Diretório de Material escolar
path = /home/material
public = yes
writable = yes
printable = no
create mask = 0765
valid users = %U @"Domain Admins"
[secreto]
path = /home/secreto
comment = docs administrativos
read list = @Dados
invalid users = @Material
write list = @Dados
browseable = No
valid users = @Dados
user = @Dados

Para que a integração LDAP x SAMBA aconteça é preciso informar ao


sistema, o SID24 do samba, com o comando #net getlocalsid e também será necessário
popular a base de dados LDAP com todo esquema necessário como: domínio, usuário,
grupos, schemas, etc. A ferramenta smbldap-tools provê mais uma funcionalidade para esta
integração, pois é um conjunto de scripts para criação, manutenção e remoção de objetos do
samba3x.schema, ou seja, para adicionar um usuário, um computador ou um grupo, deverá
ser através do smbldap-tools.

4.1.5 SMBLDAP-TOOLS

O smbldap-tools é um pacote que contém scripts escritos na linguagem de


programação perl para fazer a administração dos usuários com acesso ao samba via LDAP,
em resumo, esses scripts perl criam as contas UNIX no LDAP já com o objeto SambaAccount
para o usuário ter acesso ao SAMBA e também facilitar a criação da base com as entradas
necessárias para que a estação de trabalho utilize o domínio.

24
SID – Código numérico que identifica um servidor SAMBA
98
4.1.5.1 INSTALAÇÃO E CONFIGURAÇÃO

A instalação do smbldap-tools é feita através do gerenciador de pacotes apt. e


executando o comando #apt-get install smbldap-tools o pacote é devidamente instalado no
sistema.
O smbldap-tools não instala os arquivos de configuração na pasta /etc padrão
do Linux mas os mesmos ficam armazenados como modelos no diretório
/usr/share/doc/smbldap-tools/examples. Os arquivos smbldap.conf.gz e o smbldap_bind.conf
deverão ser copiados para a pasta /etc/smbldap-tool, o arquivo smbldap.conf.gz deverá ser
descompactado com o utilitário gzip, executando o comando # gunzip /etc/smbldap-
tools/smbldap.conf.gz.
O arquivo de configuração smbldap.conf é usado para definir parâmetros que
serão utilizados pelos scripts, neste arquivo deverá ser inserido informações sobre o servidor
LDAP e o servidor SAMBA. Segue o arquivo smbldap.conf na íntegra, configurado e
comentado.
##############################################################################
#
# General Configuration
#
##############################################################################

# Put your own SID


# SID do servidor samba pode-se obtê-lo atraves : net getlocalsid
SID="S-1-5-21-2418787199-2116653073-2306110236"

##############################################################################
#
# LDAP Configuration
#
##############################################################################
#Servidor escravo, não foi necessário a utilização de um slave.
# Ex: slaveldap=127.0.0.1
#slaveldap="127.0.0.1"
#slavePort="389"
(continua na próxima página)

99
# Master LDAP : Servidor mestre, tem que ter permissões de escrita nele
# Ex: masterldap=127.0.0.1
masterldap="127.0.0.1"
masterPort="389"

# Use TLS for LDAP


# If set to 1, this option will use start_tls for connection
# (you should also used the port 389)
LDAPTLS="0"

# How to verify the server's certificate (none, optional or require)


# see "man Net::LDAP" in start_tls section for more details
verify="none"

# LDAP Suffix: Sufixo do servidor LDAP.


suffix="dc=ldap,dc=df"

# Aqui será armazenado os usuários samba


usersdn="ou=Pessoas,${suffix}"

# Aqui será armazenado os computadores que terão acesso ao dominio


computersdn="ou=Computadores,${suffix}"

# Aqui será armazenado os grupos dos usuários


groupsdn="ou=Grupos,${suffix}"

# Onde são armazenadas entradas idmap (usadas se o samba é um servidor membro do domínio).
idmapdn="ou=Idmap,${suffix}"

# objeto em que os próximos uidNumber e gidNumber disponíveis são armazenados


sambaUnixIdPooldn="cn=NextFreeUnixId,${suffix}"
# escopo de pesquisa
scope="sub"
# Unix password encryption (CRYPT, MD5, SMD5, SSHA, SHA, CLEARTEXT)
hash_encrypt="MD5"
##############################################################################
#
# Unix Accounts Configuration
#
##############################################################################
(continua)

100
# Login defs
# Default Login Shell
# The default Home Drive Letter mapping
# Ex: userLoginShell="/bin/bash"
# (will be automatically mapped at logon time if home directory exist)
userLoginShell="/bin/bash"
# Ex: H: for H:
userHomeDrive="H:"
# Home directory
# Ex: userHome="/home/%U"
# The default user netlogon script name (%U username substitution)
userHome="/home/%U"
# if not used, will be automatically username.cmd
# make sure script file is edited under dos
# Gecos
# Ex: %U.cmd
userGecos="System User"
# userScript="startup.cmd" # make sure script file is edited under dos
userScript=logon.bat"
# Default User (POSIX and Samba) GID
defaultUserGid="513"
# Domain appended to the users "mail"-attribute
# when smbldap-useradd -M is used
# Default Computer (Samba) GID
mailDomain="ldap.df"
defaultComputerGid="515"

################################################
# Skel dir
skeletonDir="/etc/skel"

# Default password validation time (time in days) Comment the next line if
# you don't want password to be enable for defaultMaxPasswordAge days (be
# careful to the sambaPwdMustChange attribute's value)
defaultMaxPasswordAge="30"

##############################################################################
#
# SAMBA Configuration
#
##############################################################################
# The UNC path to home drives location (%U username substitution)
# Ex: \\My-PDC-netbios-name\homes\%U
# Just set it to a null string if you want to use the smb.conf 'logon home'
userSmbHome="\\PDC\homes\%U"
# The UNC path to profiles locations (%U username substitution)
# Ex: \\My-PDC-netbios-name\profiles\%U
# Just set it to a null string if you want to use the smb.conf 'logon path'
# directive and/or disable roaming profiles
userProfile="\\PDC\profiles\%U"
(continua)

101
############################
# Credential Configuration #
############################
# Notes: you can specify two differents configuration if you use a
# master LDAP for writing access and a slave LDAP server for reading access
# By default, we will use the same DN (so it will work for standard Samba
# release)
masterDN="cn=admin,dc=ldap,dc=df"
#senha do administrador cn=admin
masterPw="deus"

Com o smblldap-tools devidamente configurado é necessário executar o


comando #smbldap-populate para popular o diretório, esse script irá gerar toda base, para que
usuários Windows ingressem no sistema de domínio. Segue abaixo figura ilustrando o
preenchimento inicial do diretório.

102
Figura 37 – smbldap-populate inserindo entradas na base dc=ldap, dc=df.

Partindo deste ponto, a base LDAP está pronta para configuração de usuários,
grupos e computadores que possam ingressar no sistema.

4.1.6 APACHE

A ferramenta apt será utilizada para instalação do servidor apache, não será
necessária nenhuma alteração em sua configuração padrão. Este serviço é instalado apenas
para dar suporte à ferramenta administrativa phpldapadmin.

103
4.1.6.1 INSTALAÇÃO E CONFIGURAÇÃO

Para iniciar a instalação, será executado o comando #apt-get install apache.


Como já foi citado anteriormente esse comando resolve as dependências de pacotes e os
instala. Segue a figura que ilustra o inicio da instalação no sistema Linux:

Figura 38 - apt lista os pacotes do apache e suas dependências.

Para que o apache funcione, é necessário que o apt atualize , remova e instale
algumas bibliotecas, conforme as figuras 38 e 39.

104
105
106
Figura 39 - apt obtendo os pacotes de mirrors como ftp.br.debian.org.

A figura 39 mostra como o apt lista as URL’s25 para obter os pacotes


necessários. Após o apt baixar os pacotes, ele se encarrega de definir diretrizes padrão no
arquivo /etc/apche/httpd.conf, que será posteriormente modificado para dar suporte a
linguagem php4.

4.1.7 PHP

Para que se viabilize a utilização do phpldapadmin é necessária que seja


instalada e configurada a linguagem php, esta instalação atualiza o arquivo
/etc/apache/httpd.conf para que haja integração do PHP com o Apache.
Duas bibliotecas são instaladas para que exista uma interface entre o php e o
servidor LDAP, essas bibliotecas não são obrigatórias para o funcionamento do php, por esse
motivo elas não foram checadas no primeiro comando apt, para tanto foram instaladas
individualmente, conforme figura 40.

25
Url – endereço eletrônico de sítio na internet.
107
Figura 40 - apt iniciando a instalação do php-ldap e php4-pear.

Após a instalação das bibliotecas de interface do php com LDAP, o sistema


estará pronto para receber o software phpldapadmin.

4.1.8 PHPLDAPADMIN

O phpldapmin é uma interface WEB, onde se pode visualizar e administrar o


banco do OpenLDAP, assim como sua estrutura de objetos, no entanto, nada tão poderoso se
comparado aos comandos em modo texto. O phpldapadin usará a porta 389 padrão não
criptografada, aberta pelo slapd, apesar desta diretiva ser configurável.

Figura 41 - apt instalando o pacote phpldapadmin e o obtendo.

Depois de baixado e configurado, o script chama o Debconf para que seja


informado os primeiros parâmetros de configuração no arquivo
/var/www/phpldapadmin/config.php. Na figura seguinte o Debconf pergunta qual o tipo de

108
iteração de perfil que terá com o usuário, se será através de sessão ou através de cookies. Foi
selecionada a opção sessão por questão de conveniência, não sendo interessante a gravação de
arquivos temporário no sistema.

Figura 42 - Debconf iniciando as primeiras configurações do phpldapadmin.

A próxima etapa da configuração definirá qual servidor estará pronto para


receber o phpldapadmin, será então selecionadas as opções: apache (servidor WEB), apache-
ssl(plugin SSL) e Apache-perl (plugin Perl para apache).

109
Figura 43 - Debconf solicitando qual o servidor está instalado no sistema.

Após a execução das configurações anteriores, deverá se iniciar o servidor apache


com o comando: #service apache start. O servidor será iniciado com as configurações
atualizadas e com a pasta do phpldapadmin no diretório /var/www/, o que significa que já é
possível acessar o sistema LDAP através da url: 10.1.1.4/phpldapadmin. O sistema necessita
que se autentique um usuário, que deve estar previamente cadastrado no servidor com o perfil
de administrador.

110
Figura 44 - Tela inicial do phpldapadmin.

Será demonstrado um trecho do arquivo de configuração do phpldapadmin, o


nome deste arquivo é config.php e fica localizado em /etc/phpldapadmin.

<?php
/*
* The phpLDAPadmin config file
* This is where you customize phpLDAPadmin. The most important
* part is immediately below: The "LDAP Servers" section.
* You must specify at least one LDAP server there. You may add
* as many as you like. You can also specify your language, and
* many other options.
*
*/
/**
* phpLDAPadmin can encrypt the content of sensitive cookies if you set this
* to a big random string.
*/
$blowfish_secret = '';

111
// YOUR LDAP SERVERS
$I=0;
$SERVERS = ARRAY();
$SERVERS[$I]['NAME'] = 'MY LDAP SERVER'; /* A CONVENIENT NAME THAT WILL APPEAR IN
THE TREE VIEWER AND THROUGHOUT PHPLDAPADMIN TO

IDENTIFY THIS LDAP SERVER TO USERS. */


$SERVERS[$I]['HOST'] = 'ANGEL.LDAP.DF.'; /* EXAMPLES:
'LDAP.EXAMPLE.COM',
'LDAPS://LDAP.EXAMPLE.COM/',
'LDAPI://%2FUSR%LOCAL%2FVAR%2FRUN%2FLDAPI'
(UNIX SOCKET AT /USR/LOCAL/VAR/RUN/LDAP)
NOTE: LEAVE 'HOST' BLANK TO MAKE PHPLDAPADMIN
IGNORE THIS SERVER. */
$SERVERS[$I]['BASE'] = 'DC=LDAP,DC=DF'; /* THE BASE DN OF YOUR LDAP SERVER. LEAVE THIS
BLANK TO HAVE PHPLDAPADMIN AUTO-DETECT IT FOR YOU. */
$SERVERS[$I]['PORT'] = 389; /* THE PORT YOUR LDAP SERVER LISTENS ON
(NO QUOTES). 389 IS STANDARD. */
$SERVERS[$I]['AUTH_TYPE'] = 'SESSION'; /* THREE OPTIONS FOR AUTH_TYPE:
1. 'COOKIE': YOU WILL LOGIN VIA A WEB FORM,
AND A CLIENT-SIDE COOKIE WILL STORE YOUR

LOGIN DN AND PASSWORD.

2. 'SESSION': SAME AS COOKIE BUT YOUR LOGIN DN

AND PASSWORD ARE STORED ON THE WEB SERVER IN

A PERSISTENT SESSION VARIABLE.

3. 'CONFIG': SPECIFY YOUR LOGIN DN AND PASSWORD

HERE IN THIS CONFIG FILE. NO LOGIN WILL BE


REQUIRED TO USE PHPLDAPADMIN FOR THIS SERVER.

CHOOSE WISELY TO PROTECT YOUR AUTHENTICATION


INFORMATION APPROPRIATELY FOR YOUR SITUATION. IF

YOU CHOOSE 'COOKIE', YOUR COOKIE CONTENTS WILL BE

ENCRYPTED USING BLOWFISH AND THE SECRET YOUR SPECIFY

ABOVE AS $BLOWFISH_SECRET. */
$SERVERS[$I]['LOGIN_DN'] = 'CN=ADMIN,DC=LDAP,DC=DF';
/* THE DN OF THE USER FOR PHPLDAPADMIN TO BIND WITH.

112
A atualização de dados de usuários e grupos será feita em grande parte pela
ferramenta de gerenciamento da base de dados LDAP. O serviço de administração WEB
estará disponível em rede, para que o sistema ganhe mais mobilidade em sua administração.
Para que o samba3x.schema26 se integre perfeitamente com o LDAP é
necessário alterar mais um arquivo de configuração do phpldapadmin. Como visto
anteriormente, o SID local é responsável pela identificação do servidor de domínio que deverá
ser informado ao phpldapadmin. O arquivo que será alterado é o template_config.php que fica
localizado no diretório /usr/share/phpldapadmin/templates. É demonstrado abaixo o
fragmento que será alterado conforme o SID do servidor samba.

...
// DEFAULT DOMAINS DEFINITION (CUSTOMIZE)
// (USE `NET GETLOCALSID` ON SAMBA SERVER)
$SAMBA3_DOMAINS = ARRAY();
$SAMBA3_DOMAINS[] =
ARRAY( 'NAME' => 'MY SAMBA DOMAIN NAME',
'SID' => 'S-1-5-21-2418787199-2116653073-2306110236' );
...

5.1 ESTAÇÃO DE TRABALHO

Partindo para o âmbito dos clientes do serviço LDAP, será demonstrada a


configuração dos clientes de autenticação, para que estações de trabalho possam acessar
informações sobre usuários, viabilizando as buscas em um ambiente corporativo.

5.1.1 AUTENTICAÇÃO

Como a configuração do servidor SAMBA foi feita para ser um PDC, serão
configurados então os clientes, para que ingressem no domínio e possam interagir com o
sistema. Toda a configuração será feita no sistema operacional Windows XP.

CONFIGURAÇÃO

26
Samba3x.schema – é o esquema de objetos que poderão ser usados pela LDAP e suportados pelo SAMBA
versão 3
113
Para que computadores com sistema operacional Windows XP® possas ingressar
em um domínio SAMBA é preciso realizar uma série de tarefas como: alteração de registros e
de diretivas de segurança. Será mostrado de forma lógica como fazer essas configurações na
estação de trabalho.
Primeiramente deverá ser configurado o Windows® para fazer parte de um
domínio, isso pode ser feito alterando o ID da rede no painel de controle, colocando o nome
do computador (previamente cadastrado no PDC) e o domínio a ingressar, nesse caso o
LDAP.DF. Essa primeira operação necessita do super-usuário do SAMBA para poder
ingressar a estação de trabalho no domínio.
Passado a primeira etapa o computador irá pedir para reiniciar. A pergunta dessa
resposta deverá ser não, pois serão feitos mais dois importantes procedimentos para que o
Windows XP® possa de fato ingressar no domínio.
A segunda etapa é alterar o registro do Windows XP ®, ou seja será desligado um
flag27 do registro que ficará dessa maneira:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
netlogon\parameters"RequireSignOrSeal"=dword:00000000

A terceira e última parte é a desabilitação das diretivas locais de segurança, essa


desabilitação pode ser feita através do aplicativo “ferramentas administrativas” na opção
“diretivas de segurança local” dentro dessa janela poderá ser vista as seguintes diretivas que
deverão ser desabilitadas:

• Membro do domínio: criptografar ou assinar digitalmente os dados do canal


seguro (sempre).

• Membro do domínio: desativar alterações de senha de conta da máquina.

• Membro do domínio: requerer uma chave de sessão de alta segurança


(Windows 2000 ou posterior).
Após procedimentos anteriores a maquina poderá ser reiniciada e após a carga
completa do sistema será exibida uma tela de ingresso ao domínio, com a opção “LDAP.DF”
habilitada, bastando escolher um usuário e uma senha válidos, ou seja, que estejam
27
Flag – termo inglês amplamente utilizado para explicar um bit que define a execução de um procedimento.
114
armazenados na base LDAP e com permissões de ingresso, para que o SAMBA possa validá-
lo.

CLIENTE DE E-MAIL

Com o servidor LDAP devidamente configurado, e que seja viabilizado a


pesquisa de informações, os softwares de cliente de e-mail têm opções diversas de integração
com serviços de diretório. Neste tópico será abordado a configuração do Cliente de e-mail
Outlook Express® para que possa acessar informações pertinentes sobre usuários.

5.1.2.1 OUTLOOK EXPRESS

A busca de informações em um ambiente corporativo também é um objeto de


estudo da Gerência de Usuários. Sabendo que estas informações estão contidas em uma única
base de dados é possível fazer buscas simples ou complexas de informações úteis.
Será feita uma configuração do cliente de e-mail Microsoft Outlook Express®
para que possa acessada a base LDAP, já configurada e em execução.
Existe na barra de ferramentas, o sub-menu ‘contas’ do Outlook Express®, uma
opção para adicionar serviços de diretório, o Outlook Express® pode ser configurado para
acessar informações na base LDAP. Serão demonstradas em ordem seqüencial, as telas para a
configuração do cliente de e-mail.

115
Figura 45 – Tela do Outlook express, configuração de contas.

A figura 45 identifica todos os serviços de diretório configurados. Para se


cadastrar um novo serviço de diretório, seleciona-se o botão adicionar – sub-menu serviço de
diretório. A tela a seguir mostra esta seleção.

Figura 46 – configuração do serviço LDAP no Outlook express.

116
Deve-se configurar o IP do servidor LDAP em conjunto com regras como:
requerer ou não autenticação para pesquisa, neste caso o servidor não necessita disso, pois a
ACL é configurada para aceitar consultas de informações. Existem outras opções na aba
“Avançado” como mostrado na próxima figura.

Figura 47 – Configurações avançadas do serviço LDAP no outlook.

Nas configurações avançadas pode-se alterar a porta de comunicação com o


servidor LDAP e se requer SSL. A principal configuração é a escolha da base de pesquisa que
deve ser “dc=ldap,dc=df”. Após essa etapa o Outlook Express® está devidamente configurado
para pesquisar na base LDAP.

5.1.2.2 PESQUISA DE INFORMAÇÕES

Com o cliente de e-mail devidamente configurado a pesquisa de informações


pode ser feita através da opção “endereços” do Outlook Express ®, nessa opção será mostrada
uma janela com uma outra opção chamada localizar pessoas. Nesta opção pode-se escolher
um serviço de diretório para a pesquisa, pode-se filtrar resultados com entradas específicas.
Segue ilustração que representa uma pesquisa de e-mail pelo nome de uma pessoa chamada
Angélica.

117
Figura 48 – representa uma busca pelo nome através da Base LDAP.

Sendo assim o cliente pode buscar informações importantes sobre determinada


pessoa ou departamento, desde que esteja mapeado na DIT. Toda essa busca é realizada na
base de dados LDAP. Mostrando sua funcionalidade e capacidade de integrar os sistemas de
maneira eficiente.

6. ESQUEMA DE FUNCIONAMENTO

Exemplificando o esquema de funcionamento da autenticação, foi elaborado


um diagrama de processos para simular situações onde o usuário, servidor LDAP e os
principais módulos interagem nos processos.

118
Figura 49 – Esquema de funcionamento do Protótipo.

Para se fazer a pesquisa de informações básicas sobre usuários, por exemplo:


nome, e-mail e telefone. Não é necessária a autenticação pela PAM e NSS, nem mesmo o
ingresso no PDC SAMBA.

7. SIMULAÇÃO DO AMBIENTE

Com o sistema totalmente configurado deve-se realizar testes nas


configurações, realizando autenticações, tentativas de acesso a pastas e pesquisas de
informações. Será mostrado primeiramente a criação e esplicação do esquema de grupos e
usuário e posteriormente as tentativas de acesso as pastas do SAMBA e a autenticação no
domínio LDAP.DF.

119
7.1 USUÁRIOS E GRUPOS

Como o sistema de autenticação é baseado no domínio LDAP.DF no PDC do


SAMBA com os todos seus usuários na base LDAP, será usado como foco a criação de contas
com o esquema samba3x utilizando os scripts de criação de usuários e grupos do smbldap-
tools. No esquema de usuários existem dois grupos chamados “Dados” e “Material”, os
usuários do Grupo “Dados” são usuários avançados que necessitam de uma certa segurança já
que todos as informações sigilosas ficam armazenadas nessa pasta, entretanto nenhum outro
grupo pode abri-la. Os usuários do grupo “Material” podem apenas abrir a pasta “Material” e
podem ler apenas o conteúdo desta pasta, não sendo permitido a gravação por estes usuários.
Os membros do grupo “Dados” podem ler e gravar em ambas as pastas “Dados” e “Material”.

CRIAÇÃO DE GRUPOS E USUÁRIOS


Para se começar a adicionar usuários, grupos e maquinas na base LDAP para
acesso ao SAMBA, é preciso primeiramente inserir os grupos “Dados” e “Material”.
Lembrando que para cada objeto sendo ele grupo ou usuário é gerado um ID próprio para
identificá-lo no sistema.
Para a criação dos grupos será utilizado o script smbldap-grupadd seguido do
nome do grupo, ou seja:

#SMBLDAP-GROUPADD DADOS
#SMBLDAP-GROUPADD MATERIAL

Executado este script, será inserido na base LDAP ou=Grupos, dc=ldap, dc=df,
os grupos cn=Dados e cn= Material.
Para teste serão criados dois usuários cada um com seu perfil, o “usermaterial”
e o “userdados” com seus respectivos grupos “material” e “dados”. Segue os scripts de
criação de cada usuário:
Para a criação de usuários o script smbldap-useradd será usado juntamente
com alguns dos seus parâmetros:

#SMBLDAP-USERADD –A –G 2005 –M –S /BIN/BASH –D /DEV/NULL –F “” –P USERDADOS


#SMBLDAP-USERADD –A –G 2003 –M –S /BIN/BASH –D /DEV/NULL –F “” –P USERMATERIAL

120
Os usuários estão sendo criados na base de dados LDAP ou=Pessoas,
dc=ldap,dc=df. Os testes de autenticação de usuários na base LDAP e as suas respectivas
permissões já podem ser testadas no próprio servidor utilizando um shell ou mesmo algum
gerenciador de arquivos gráfico, foi usado o gerenciador de arquivos konqueror da GUI-KDE.
Com os serviços LDAP e SAMBA iniciados, pode-se pelo konqueror digitar o endereço
smb://10.1.1.4, aparecendo as pastas “dados” e “material”, para acessar a pasta “Material” o
usuário deverá estar no grupo “material” ou “dados”, e se quer acessar a pasta “Dados” deverá
ter um usuário no grupo “Dados”, caso contrário não terá acesso já que o LDAP fornece todos
as informações necessárias para o servidor samba libere o acesso. Após essa etapa serão
executados testes de autenticação destes usuários no sistema.

7.1.1.1 AUTENTICAÇÃO

Executada as tarefas de criação de usuários e seus respectivos grupos serão


testados a duas maneiras de autenticação, a primeira o usuário tentando acessar as pastas do
servidor SAMBA e a segunda o usuário ingressando no domínio do PDC chamado LDAP.DF,
serão ilustrados nas figuras abaixo as situações que podem ocorrer.

Primeira situação: acessando o servidor SAMBA sem tentar acessar as pastas.

Figura 50 – Konqueror acessando o serviço samba, ainda sem usuário definido.

121
Segunda situação: usuário “usermaterial” que é membro do grupo “material”
tentando acessar a pasta “dados” que é permitida leitura apenas por usuários membros do
grupo “dados”:

Figura 51 – Acessando a pasta dados como usuário do grupo material.

Como comentado anteriormente, os usuários não participantes do grupo “dados” não


têm acesso à pasta “dados”:

122
Figura 52 – Acesso Negado a pasta Dados como usuário usermaterial.

Terceira situação: o usuário “usermaterial” tem acesso livre à pasta “material”.


Quarta situação: o usuário “userdados”, que é membro do grupo “dados”, irá
tentar acessar esta pasta, colocando seu nome de usuário e senha definida como “123”:

Figura 53 – Acesso a pasta dados como usuário do grupo dados.

123
O usuário com perfil “dados” poderá visualizar, abrir, executar e gravar
arquivos tanto nesta pasta quanto na pasta “Material”.

Figura 54 – Navegação na pasta dados como usuário userdados.

Realizados os testes de autenticação LDAP no SAMBA, será feito agora a


autenticação pela estação de trabalho Windows XP® ingressando no domínio do PDC
SAMBA.
Com o PDC e a estação de trabalho devidamente configurados basta escolher
um usuário qualquer que está na base LDAP e que tenha permissões e atributos que o
possibilite de ingressar em um domínio. Todos os usuários citados no teste anterior podem
ingressar no domínio LDAP.
Ao ligar a estação de trabalho, aparecerá na tela uma opção de usuário, senha e
domínio. Será necessário informar o usuário “userdados”, a senha e o domínio LDAP.DF.
Ao submeter o ingresso neste domínio, o sistema SAMBA busca informações
na base LDAP e caso as informações fornecidas pela estação de trabalho sejam verdadeiras o
Sistema operacional inicia a carga da área de trabalho, habilitando usuário a usufruir da pasta
do seu respectivo grupo.

124
Figura 55 – Mostra o PDC já mapeado como unidade H:.

Feitos os testes, foi verificada a versatilidade do LDAP para facilitar a busca de


informações e principalmente para organizá-las, não esquecendo da propriedade deste
protocolo em integrar sistemas totalmente distintos.

125
ANEXO II – RFC’S

RFC 1777
Lightweight Directory Access Protocol
Protocolo de Leve Acesso a Diretórios
Projetado para fornecer acesso ao X. 500. É apontado especificamente nas
aplicações simples de gerência e nas aplicações do browser que fornecem acesso interativo de
leitura/gravação simples ao diretório X.500 . Os elementos desse Protocolo são carregados
diretamente sobre TCP ou outro transporte. Muitos elementos de dados desse protocolo são
codificados como barbantes.

RFC 1779
A String Representation of Distinguished Names
Representação de Barbantes de Nomes Distintos
O diretório OSI usa nomes distintos como as chaves preliminares às entradas
no diretório. Os nomes distintos são codificados em ASN.1. Quando um nome distinto for
comunicado no meio de usuários que não usam um protocolo do diretório (por exemplo, em
uma mensagem do correio), há a necessidade de ter uma respresentação user-oriented
(usuário-orientado) de barbante de nomes distintos. Define o formato do barbante para
representar nomes, que é projetada para dar uma respresentação limpa de nomes geralmente
usados, podendo representar algum nome distinto.

RFC 1798
Connection-less Lightweight X.500 Directory Access Protocol
Protocolo de Leve Acesso a Diretórios X.500 conexão-menos
Evita o tempo decorrido que é associado com uma comunicação connection-
oriented e facilita o uso do diretório em uma maneira analagous ao DNS. É destinado
especificamente nas aplicações simples do lookup, que requerem para ler um número pequeno
de valores, o atributo de uma única entrada. Pode ser usado como um repositório para muitos
tipos da informação. É desnecessário para as aplicações que requerem o acesso lido simples a
alguns valores do atributo.

126
RFC 1823
The LDAP Application Program Interface
Programa de Aplicação de Interface do LDAP
Define um Programa de Aplicação de Interface na línguagem C ao LDAP. O
LDAP API é projetado para ser poderoso, contudo simples de usar. Define relações síncronas
e assíncronas compatíveis ao LDAP para servir uma variedade larga das aplicações.

RFC 1959
An LDAP URL Format
Formato do URL de LDAP
Descreve um formato para um localizador de recurso uniforme de LDAP que
permita que os clientes de Internet tenham o acesso direto ao protocolo de LDAP. Quando o
protocolo for usado somente como uma extremidade dianteira ao diretório X.500, o formato
do URL descrito é, geralmente, bastante seguro para os usuários autônomos de LDAP (isto é,
usuários de LDAP back-ended (extremidade traseira) por X.500).

RFC 2044
UTF-8, a transformation format of Unicode and ISO 10646
UTF-8, um formato da transformação de Unicode e ISO
O padrão de Unicode, a versão 1.1, e os ISO/IEC 10646-1, definem
conjuntamente um carácter de 16 bits ajustado, que abranje a maioria dos sistemas do mundo.
Os carácteres 16-bit, entretanto, não são compatíveis com muitas aplicações e protocolos
atuais, e estes conduzem ao desenvolvimento de alguns formatos so-called da transformação
do UCS (UTF), cada um com características diferentes. O UTF-8 tem a característica de
preservar a escala cheia de US-ASCII. Os carácteres de US-ASCII são codificados em um
octeto que tem o valor usual de US-ASCII, e todo o octeto com tal valor, pode ser somente
um caráter de US-ASCII.

RFC 2251
Lightweight Directory Access Protocol (v3)
Protocolo de Leve Acesso a Diretórios v3
Projetado para fornecer acesso aos diretórios que suportam os modelos X.500.
É apontado especificamente nas aplicações da gerência e nas aplicações do browser que
fornecem o acesso interativo de leitura/gravação aos diretórios. Quando utilizado como um

127
diretório que suporta o X.500, pretende-se aproveita-lo para ser um complemento ao X.500
DAP.

RFC 2252
Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions
Protocolo de Leve Acesso a Diretórios V3: Definições da Sintaxe do Atributo
Requer que os índices de campos de AttributeValue em elementos do protocolo
sejam barbantes do octeto. Define um jogo de sintaxes para LDAPv3 e as regras pelas quais
são atribuídos os valores destas sintaxes além de representados como barbantes do octeto para
a transmissão no protocolo de LDAP. Podem ser definidas por este e por outros documentos
que definem os tipos do atributo. Define também os tipos dos atributos que os usuários de
LDAP devem suportar.

RFC 2253
Lightweight Directory Access Protocol (v3): UTF-8 String Representation of
Distinguished Names
Protocolo de Leve Acesso a Diretórios V3: UTF-8 Representação de Barbante de Nomes
Distintos
O diretório X.500 usa nomes distintos como chaves preliminares às entradas no
diretório. Os nomes distintos são codificados em ASN.1 nos protocolos do diretório X.500.
No LDAP, uma respresentação do barbante de nomes distintos é transferida. Esta
especificação define o formato do barbante para representar nomes, que é projetada para dar
uma respresentação limpa de nomes distintos geralmente usados, para poder representar
algum nome distinto.

RFC 2254
The String Representation of LDAP Search Filters
Respresentação do Barbante de filtros de busca do LDAP
Define uma respresentação da rede de um filtro de busca fazendo transmissões
a um usuário de LDAP. Algumas aplicações podem ser úteis se encontrado uma maneira
comum de representar estes filtros da busca em um formulário legível. Também define um
formato legível do barbante para representar filtros da busca de LDAP. Substitui a RFC 1960,
estendendo a definição do filtro do barbante do LDAP para incluir a sustentação de filtros

128
estendidos da versão 3 de LDAP e incluindo a sustentação para representar a escala cheia de
filtros possíveis da busca de LDAP.

RFC 2255
The LDAP URL Format
Formato do URL do LDAP
Descreve um formato para um localizador de recurso uniforme de LDAP e uma
operação de busca para executar e recuperar a informação de um diretório de LDAP. Substitui
a RFC 1959. Atualiza o formato do URL de LDAP para a versão 3 e esclarece como as URLs
são resolvidas. Define também um mecanismo da extensão para as URLs, de modo que os
originais futuros possam estender sua funcionalidade, como por exemplo, para fornecer o
acesso às novas extensões LDAPv3 enquanto são definidos.

RFC 2256
A Summary of the X.500(96) User Schema for use with LDAPv3
Um sumário X.500(96) do schema do usuário para o uso com LDAPv3
Fornece uma visão geral dos tipos de atributos e das classes dos objetos
definidos pelos comitês do ISO e do ITU-T, que são aqueles pretendidos para uso dos clientes
do diretório. Este é o esquema mais usado para os diretórios LDAP/X.500, além de muitas
outras definições do esquema para objetos dos white pages que o utilizam como base. Não
cobre os atributos usados para a administração de usuários do diretório X.500, nem inclui os
atributos definidos por outros originais de ISO/ITU-T.

RFC 1487
X.500 Lightweight Directory Access Protocol
Protocolo de Leve Acesso a Diretórios, X500
É desenvolvido especificamente para aplicações simples da gerência e nas
aplicações do browser que fornecem o acesso interativo de leitura/gravação simples ao
diretório. O interesse tremendo na tecnologia X.500 na Internet se da em conduzir aos
esforços para reduzir o "custo elevado da entrada" associada com o uso da tecnologia, tal
como o serviço do auxílio de diretório. Quando os esforços tiverem sucesso, serão soluções
como essas, baseadas em execuções particulares, que limitaram a aplicabilidade.

129
RFC 1558
The String Representation of LDAP Search Filters
Respresentação do Barbante de filtros da busca do LDAP
Define uma respresentação da rede de um filtro de busca fazendo transmissões
a um usuário de LDAP. Algumas aplicações podem ser úteis se encontrado uma maneira
comum de representar estes filtros da busca em um formulário legível.

RFC 1778
The String Representation of Standard Attribute Syntaxes
REPRESENTAÇÃO DO BARBANTE DE SINTAXES E PADRÃO DO ATRIBUTO
O LDAP requer que os índices de campos de AttributeValue do protocolo
sejam barbantes do octeto. Define as exigências que devem ser satisfeitas codificando as
regras usadas para as sintaxes do atributo do diretório X.500 em um formulário apropriado
para o uso no LDAP.

RFC 1960
The String Representation of LDAP Search Filters
RESPRESENTAÇÃO DO BARBANTE DE FILTROS DA BUSCA DE LDAP
Define uma respresentação da rede de um filtro de busca fazendo transmissões
a um usuário de LDAP. Algumas aplicações podem ser úteis se encontrado uma maneira
comum de representar estes filtros da busca em um formulário legível.

RFC 2079
Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource
Identifiers (URIs)
Definição de um tipo do atributo X.500 e de uma classe do objeto para prender
identificadores uniformes do recurso (URIs)
Os localizadores de recurso uniforme (URLs) são usados extensamente para
especificar a posição de recursos da Internet. Há uma grande necessidade poder incluir URLs
nos diretórios que se conformam aos modelos da informação LDAP e X.500 além de incluir
outros tipos de identificadores uniformes do recurso (URIs) como são definidos. As
configurações deste documento definem um tipo novo do atributo e uma classe auxiliar do

130
objeto para permitir que URIs, sejam armazenadas em entradas de diretório em uma maneira
padrão.

RFC 2116
X.500 Implementations Catalog-96
Implementações X. 500, CATALOG 96
Define um catálogo revisado das execuções X.500 disponíveis e é baseado nos
resultados do levantamento de dados de através de um Home Page WWW que permita se
submeter a novas descrições ou updated de execuções atualmente disponíveis do X.500,
incluindo produtos comerciais e abertamente disponíveis.

RFC 2164
Use of an X.500/LDAP directory to support MIXER address mapping
Uso de um diretório de X.500/LDAP de suporte para traçar endereços de um
Misturador
O Misturador (RFC 2156) define um algoritmo para o uso de mapas. Define
como representar e manter estes mapas em um X.500 ou no diretório de LDAP. Os
mecanismos para representar ou as hierarquias do endereço e do domínio ficam dentro do
DIT. Estas técnicas são usadas definir dois subtrees independentes nos DIT, que contêm a
informação, traçando os benefícios desta aproximação. A informação traçada é mantida em
uma área claramente definida que possa ser extensamente replicada de maneira eficiente. A
árvore é confinada para manter somente a informação necessitada. Isto é importante porque as
passagens necessitam de bom acesso para serem traçadas por inteiro.

RFC 2247
Using Domains in LDAP/X.500 Distinguished Names
Usando domínios de nomes distintos LDAP/X.500
O LDAP usa nomes compatíveis do X.500 e distintos fornecendo a
identificação original das entradas. Define um algoritmo, o qual, um nome registado com o
serviço do Domain Name da Internet, pode ser representado como um nome distinto LDAP.

131
RFC 2307
An Approach for Using LDAP as a Network Information Service
Uma aproximação para usar LDAP como um serviço de informação da rede
Descreve um mecanismo experimental que traça as entidades relacionadas ao
TCP/IP e ao sistema de UNIX nas entradas X.500 de modo que possam ser resolvidos com o
LDAP. Um conjunto de tipos dos atributos e as classes do objeto são propostos, junto com
guidelines específicos para interpretá-los. A intenção é ajudar à distribuição de LDAP como
um nameservice organizational. Nenhuma solução proposta é pretendida como padrões para a
Internet.

RFC 2377
Naming Plan for Internet Directory-Enabled Applications
Nomeação da planta para o diretório da Internet permitindo aplicações
A aplicação da aproximação X.500 convencional para nomeação, prova ser um
obstáculo à distribuição larga de aplicações permitidas na Internet. É proposto um diretório
novo que nomeia a planta e aumente as forças da Internet, o torne mais popular e mais bem
sucedido que nomeie esquemas para objetos em um diretório hierárquico.

RFC 2559
Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2
Protocolos Operacionais, Infraestrutura de Chave Pública do Internet X.509 - LDAPv2
Foi projetado para satisfer algumas das exigências operacionais dentro da
infraestrtura de chave pública do Internet X.509 (IPKI). Dirige-se a exigências para fornecer o
acesso aos repositórios de chaves públicas do infrastructure (PKI), para as finalidades de
recuperar a informação de PKI e de controlar a mesma informação. É baseado no LDAP v2,
definindo um perfil desse protocolo para o uso dentro do IPKI fazendo atualizações para
certificados e listas da revogação de RFC 1778.

RFC 2596
Use of Language Codes in LDAP
Uso de códigos da língua em LDAP
O LDAP fornece meios para que os clientes possam questionar e modificar as
informações armazenadas em um sistema distribuído do diretório. A informação no diretório
é mantida como os atributos das entradas. A maioria destes atributos têm as sintaxes que são

132
barbantes legíveis, podendo indicar a língua natural associada com os valores do atributo.
Descreve como os códigos da língua são carregados e devem ser interpretada por usuários de
LDAP. Todas as execuções devem ser preparadas para aceitar códigos da língua nos
protocolos de LDAP. Os usuários podem ou não podem ser capazes de armazenar atributos
com códigos da língua no diretório.

RFC 2649
An LDAP Control and Schema for Holding Operation Signatures
Controle e esquema de LDAP para proteger assinaturas da operação
Em muitos ambientes os clientes requerem habilidade ao avaliar a fonte e a
integridade da informação fornecida pelo diretório. Descreve um controle da mensagem de
LDAP que permita a recuperação da informação digital assinada. Define um mecanismo
baseado no LDAP v3 para operações, a fim criar informações seguras das mudanças que
foram feitas a cada entrada de diretório. O cliente e as assinaturas baseadas em usuários são
suportados. Uma classe do objeto para a recuperação subseqüente também é definida

RFC 2696
LDAP Control Extension for Simple Paged Results Manipulation
Extensão do controle de LDAP para a manipulação paginada simples dos resultados
Descreve uma extensão do controle LDAPv3 para a paginação simples de
resultados de busca. Esta extensão do controle permite que um cliente controle a taxa em que
um usuário de LDAP retorna os resultados de uma operação de busca de LDAP. Pode ser útil
quando o cliente de LDAP limita recursos e não pode processar o resultado inteiro de uma
pergunta dada, ou quando o cliente de LDAP está conectado sobre uma conexão de baixo-
largura de faixa. Esta extensão não é projetada fornecer gerência ajustada de um resultado
mais sofisticado.

RFC 2587
Internet X.509 Public Key Infrastructure LDAPv2 Schema
Esquema de Chave Pública de Infraestrutura do LDAPv2 do Internet X.509
Definido um esquema mínimo para suportar PKIX em um ambiente LDAPv2,
como definido em RFC 2559. Somente os componentes específicos de PKIX são
especificados aqui. Usuários de LDAP, agindo como os repositórios de PKIX, devem suportar
as classes auxiliares do objeto definidas nesta especificação e integrar esta especificação do

133
esquema com os esquemas genéricos e outras aplicações específicas, dependendo dos serviços
fornecidos por esses usuários.

RFC 2589
Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services
Protocolo de Leve Acesso a Diretórios V3: Extensões para serviços dinâmicos do
diretório
Define as exigências para serviços dinâmicos do diretório e especifica o
formato do pedido e operações estendidas do usuário em um ambiente dinâmico dos
diretórios. O LDAP suporta acesso aos serviços estáticos do diretório, permitindo um acesso
relativamente rápido da busca e do update. Os serviços estáticos do diretório armazenam
informação sobre a pessoa que persiste em sua exatidão e valor sobre um período de longo
tempo. Os serviços dinâmicos do diretório são diferentes, pois armazenam a informação que
persiste somente em sua exatidão e valor quando está sendo refrescada periodicamente. Esta
informação é armazenada como entradas dinâmicas no diretório.

RFC 2657
LDAPv2 Client vs. the Index Mesh
Cliente LDAPv2 contra o engranzamento do índice
Os clientes LDAPv2, como executados de acordo com RFC 1777, não têm
nenhuma noção referencial. A integração entre tal cliente e engranzamento do índice, como
definido pelo protocolo comum de indexação, depende pesadamente dos referenciais e
conseqüentemente das necessidades de segurança em uma maneira especial.

RFC 2713
Schema for Representing Java(tm) Objects in an LDAP Directory
Schema para representar objetos de Java(tm) em um diretório de LDAP
Define o esquema para representar objetos de Java(tm) em um diretório de
LDAPv3. Define elementos do esquema para representar um objeto colocado em série Java,
um objeto marshalled Java [ RMI ], um objeto remoto de Java [ RMI ] e uma referência de
[ JNDI ].

134
RFC 2739
Calendar Attributes for vCard and LDAP
Atributos do calendário para o vCard e o LDAP
Ao programar uma entidade do calendário, tal como um evento, é um pré-
requisito que um organizador tenha o endereço do calendário de cada participante que será
convidado ao evento. Adicionalmente, o acesso ao tempo "ocupado" atual de um participante
fornece uma indicação de que o participante estará livre participar no evento. A fim de se
encontrar com estes desafios, um agente usuário do calendário (CUA) necessita de um
mecanismo para encontrar um (URI), o calendário do usuário individual e o tempo de
free/busy. Define três mecanismos para obter um URI: transferência manual da informação;
troca de dados pessoal usando o formato do vCard e lookup do diretório usando o protocolo
de LDAP.

RFC 2798
Definition of the inetOrgPerson LDAP Object Class
Definição da classe do objeto do inetOrgPerson LDAP
Quando os padrões X.500 definem muitos tipos úteis do atributo [ X520 ] e
classes do objeto [ X521 ], não definem uma classe do objeto da pessoa que se encontre com
as exigências distribuídas do serviço no diretório da Internet e da Intranet. Define uma classe
nova do objeto chamada inetOrgPerson para o uso em serviços do diretório LDAP e X.500
que estende a classe padrão do organizationalPerson X.521.

RFC 2820
Access Control Requirements for LDAP
Exigências do controle de acesso para LDAP
Descreve as exigências fundamentais de um modelo do Access Control List
(ACL) para o serviço de (LDAP). Pretende-se ser um lugar de recolhimento para as
exigências do controle de acesso necessitadas fornecer o acesso autorizado e a
interoperabilidade entre diretórios.

135
RFC 2829
Authentication Methods for LDAP
Métodos de Autenticação para LDAP
Especifica combinações particulares dos mecanismos de segurança que são
requeridos e recomendados em execuções do LDAP. A versão 3 de LDAP é um protocolo
poderoso de acesso a diretórios. Oferece meios de procura, de busca e de manipulação do
índice do diretório, e as maneiras de alcançar um conjunto rico de funções de segurança. A
fim funcionar melhor para Internet, é vital que estas funções da segurança sejam bem
operadas, conseqüentemente tem que haver um subconjunto mínimo de funções da segurança
que seja comum a todas as execuções que reivindicam o conformidade ao LDAPv3.

RFC 2830
Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security
Protocolo de Leve Acesso a Diretórios V3: Extensão para a segurança da camada de
transporte
Define "a operação de segurança da camada de transporte (TLS)" para LDAP
Esta operação fornece para o estabelecimento de TLS uma associação de LDAP e é definida
nos termos de um pedido estendido do LDAP.

RFC 2849
The LDAP Data Interchange Format (LDIF) - Technical Specification
O Formato Do Intercâmbio Dos Dados de LDAP (LDIF) - Especificação Técnica
Descreve um formato da ferramenta apropriada para descrever a informação ou
as modificações do diretório feita à informação do diretório. O formato da ferramenta,
conhecido como LDIF, para o formato do intercâmbio dos dados de LDAP, é usado
tipicamente para importar e exportar a informação do diretório entre usuários LDAP ou
descrever um jogo das mudanças que devem ser aplicadas a um diretório.

RFC 2891
LDAP Control Extension for Server Side Sorting of Search Results
Extensão do controle de LDAP para a classificação lateral do usuário de resultados da
busca
Descreve duas extensões de controle do LDAPv3 para a classificação lateral do
usuário e de resultados da busca. Estes controles permitem que um cliente especifique os tipos

136
do atributo e combina regras que um usuário deve usar quando retornar os resultados de um
pedido da busca de LDAP. Os controles podem ser úteis quando o cliente de LDAP limitar a
funcionalidade ou não puder classificar os resultados que necessita.

RFC 2926
Conversion of LDAP Schemas to and from SLP Templates
Conversão de esquemas de LDAP e dos moldes de SLP
Descreve um procedimento para traçar propagandas do serviço do protocolo,
da posição do serviço (SLP) e das descrições do (LDAP). Um aspecto está traçando entre o
esquema do tipo moldes do serviço de SLP e do diretório de LDAP. A gramática do serviço
de SLP do molde é relativamente simples, traçar o tipo moldes ao tipo do LDAP é direto.
Traçar em outro sentido é direto, se os atributos, forem restringidos para usar apenas algumas
das sintaxes definidas em RFC 2252.

RFC 2927
MIME Directory Profile for LDAP Schema
Perfil do diretório do MIME para o schema de LDAP
Define um perfil de múltiplos propósitos do diretório das extensões do correio
da Internet (MIME) para prender um esquema do (LDAP). Pretende-se para uma
comunicação com o serviço da lista do esquema da Internet.

RFC 3045
Storing Vendor Information in the LDAP root DSE
Armazenamento de Informação para LDAP na raiz do DSE
Especifica dois atributos do (LDAP), vendedor de nomes e o vendedor de
versões, incluídos na entrada DSA -específica da raiz (DSE) para anunciar a informação
vendedor-específica. A informação presas nestes atributos podem ser usadas para a exposição
e finalidades informativas e não devem ser usadas para a propaganda ou a descoberta da
característica.

137
RFC 3062
LDAP Password Modify Extended Operation
A Senha de LDAP Modifica Operação Prolongada
A integração do LDAP e de serviços externos do authentication introduziu
identidades do authentication no DN e permitiu o armazenamento do diretório das senhas. Os
mecanismos que atualizam o diretório não podem ser usados para mudar a senha de um
usuário. Descreve uma operação estendida do LDAP para permitir a modificação de senhas
do usuário que não é dependente do formulário da identidade do authentication nem do
mecanismo de armazenamento da senha usada.

RFC 3088
OpenLDAP Root Service An experimental LDAP referral service
Serviço da raiz de OpenLDAP um serviço de referral experimental de LDAP
O projeto de OpenLDAP está operando num serviço experimental de LDAP,
como também "o serviço da raiz OpenLDAP". O sistema automatizado gera referencias
baseadas nas informaçãos das posições do serviço publicado em DNS SRV RRs (posição do
Domain Name System de registros do recurso dos serviços).

RFC 3112
LDAP Authentication Password Schema
Esquema de Senha de Autenticação do LDAP
Descreve o esquema na sustentação do authentication de user/password em um
diretório de LDAP incluindo o tipo do atributo do authPassword. Este tipo do atributo
mantem valores derivados do password(s) do usuário. O authPassword é pretendido para ser
usado no lugar do userPassword.

RFC 3296
Named Subordinate References in Lightweight Directory Access Protocol (LDAP)
Directories
Referência de nomes Subordinados em Diretórios (LDAP)
Detalha elementos do esquema e do protocolo para representar e controlar
referências subordinadas nomeadas em diretórios de LDAP.

138
RFC 3352
Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status
Conexão-menos do Protocolo CLDAP Status do Histórico
A especificação técnica de (CLDAP), RFC 1798, foi publicada como um
padrão proposto e discute as razões as quais a especificação técnica de CLDAP não foi
promovida na trilha padrão.

RFC 3377
Lightweight Directory Access Protocol (v3): Technical Specification
Protocolo de Leve Acesso a Diretórios V3: Especificação Técnica
Especifica o jogo de RFCs que compreendem a versão 3 do LDAPv3, e
endereços "a nota IESG" unida a RFCs 2251 a 2256. A especificação para a versão 3 do
LDAP compreende oito RFCs que foram emitidos em dois subconjuntos distintos. O RFC
2251 a 2256 não exige a execução de nenhuns mecanismos satisfatórios do authentication e
daqui não estêve publicado com "uma execução da nota IESG" e uma distribuição
desanimadoras dos clientes LDAPv3 ou dos usuários que executam a funcionalidade do
update até que um padrão proposto para o authentication imperativo em LDAPv3 esteja
publicado. O RFC 2829 foi publicado subseqüentemente na resposta à nota do IESG. A
finalidade deste original é especificar explicitamente o jogo de RFCs que compreende
LDAPv3, e dirige-se formalmente à nota do IESG através do inclusion explícito de RFC
2829.

RFC 3383
Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight
Directory Access Protocol (LDAP)
Considerações do Internet Assigned Numbers Authority (IANA) para Protocolo de Leve
Acesso a Diretórios (LDAP)
Fornece procedimentos registando elementos extensivos do (LDAP). Fornece
também guidelines ao Internet Assigned Numbers Authority (IANA) que descreve as
circunstâncias sob que os valores novos podem ser atribuídos. Sustentações de LDAP: adição
de operações novas, extensão de operações existentes, e esquema extenso.

139
RFC 3384
Lightweight Directory Access Protocol (version 3) Replication Requirements
Protocolo de Leve Acesso a Diretórios LDAP (versão 3) Exigências de Replicação
Discute as exigências fundamentais para a replicação dos dados acessíveis
através do (LDAPv3). Pretende-se ser um lugar de recolhimento para as exigências gerais do
replication necessitando fornecer o interoperability entre diretórios informativos.

RFC 3494
Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status
Protocolo de Leve Acesso a Diretórios Versão 2 (LDAPv2) Status do Histórico
Recomenda a aposentadoria da versão 2 (LDAPv2) e de outras especificações
dependentes. É usado alcançar serviços do diretório de X.500-based. Recomenda que
LDAPv2 e outras especificações dependentes estejam aposentados.

RFC 3663
Domain Administrative Data in Lightweight Directory Access Protocol (LDAP)
Dados administrativos do domínio no Protocolo de Leve Acesso a Diretórios (LDAP)
Os dados do registo do domínio foram expostos tipicamente ao público geral
através de Nicname/Whois para finalidades administrativas. Este original descreve o serviço
de (LDAP), um serviço experimental usando LDAP e tipos well-known de LDAP fazer
domínio dados administrativos disponíveis.

RFC 3671
Collective Attributes in the Lightweight Directory Access Protocol (LDAP)
Atributos coletivos dentro do Protocolo de Leve Acesso a Diretórios (LDAP)
Os atributos X.500 coletivos permitem que as características comuns sejam
compartilhadas entre as coleções das entradas. Ele sumaria o modelo da informação X.500
para os atributos coletivos e descreve o uso de atributos coletivos em LDAP. Fornece
definições do esquema para atributos coletivos para o uso em LDAP.

140
RFC 3672
Subentries in the Lightweight Directory Access Protocol (LDAP)
Subentries no Protocolo de Leve Acesso a Diretórios (LDAP)
Nos diretórios X.500, os subentries são entradas especiais usadas para manter a
informação associada com um subtree ou um refinement do subtree. Adapta mecanismos dos
subentries X.500 para o uso com o (LDAP).

RFC 3673
Lightweight Directory Access Protocol version 3 (LDAPv3): All Operational Attributes
Protocolo de Leve Acesso a Diretórios LDAP (versão 3): Todos os Atributos
Operacionais
O (LDAP) suporta um mecanismo para pedir o retorno de todos os atributos do
usuário mas de não todos os atributos operacionais. Descreve uma extensão de LDAP que os
clientes possam usar para pedir o retorno de todos os atributos operacionais.

RFC 3674
Feature Discovery in Lightweight Directory Access Protocol (LDAP)
Descoberta de características no Protocolo de Leve Acesso a Diretórios LDAP
O (LDAP) é um protocolo extensível com características numerosas. Introduz
um mecanismo geral para a descoberta das características e das extensões que não podem ser
descobertas usando mecanismos existentes.

RFC 3687
Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules
Protocolo de Leve Acesso a Diretórios LDAP e réguas combinando do componente
X.500
Define as sintaxes dos atributos em uma escala de (LDAP) ou do diretório
X.500 dos tipos de dados simples, tais como a corda de texto, o inteiro, o booleano, os tipos
de dados estruturados complexos e também as sintaxes dos atributos operacionais do esquema
do diretório. As regras definidas para as sintaxes complexas são mais imediatas e úteis,
combinando a potencialidade. Define as regras genéricas que podem combinar todas as partes
selecionadas usuário em um valor do atributo de qualquer sintaxe arbitrariamente complexa
do atributo.

141
RFC 3698
Lightweight Directory Access Protocol (LDAP): Additional Matching Rules
Protocolo de Leve Acesso a Diretórios LDAP : Réguas Combinando Adicionais
Fornece uma coleção de regras combinando o uso com o (LDAP). Estas regras
são adaptações simples das regras especificadas para o uso com o diretório X.500, a maioria
são já dentro uso largo.

RFC 3703
Policy Core Lightweight Directory Access Protocol (LDAP) Schema
Esquema do Protocolo de Leve Acesso a Diretórios Do Núcleo Da Política (LDAP)
Define o modelo da informação do núcleo da política a um formulário que
possa ser executado em um diretório que use o (LDAP) como seu protocolo do acesso. Define
duas hierarquias de classes do objeto: as classes estruturais que representam a informação
para dados de representação e controle da política como especificados em RFC 3060, e o
relacionamento que classifica e indica como os exemplos das classes estruturais são
relacionados. As classes são adicionadas também ao esquema de LDAP para melhorar o
desempenho de interações de um cliente com um usuário de LDAP quando o cliente está
recuperando quantidades grandes de informações relacionadas.

RFC 3712
Lightweight Directory Access Protocol (LDAP): Schema for Printer Services
Protocolo de Leve Acesso a Diretórios (LDAP) : Schema para Serviços de Impressora
Define um esquema de objeto que classifica e atribui, para impressoras e
serviços da impressora, o uso de diretórios que suportam o v3 (LDAP-TS). Baseado nos
atributos da impressora alistados no apêndice e no Internet Protocol/1.1 (IPP). Alguns
atributos adicionais da impressora são baseados em definições no MIB da impressora.

RFC 3727
ASN.1 Module Definition for the LDAP and X.500 Component Matching Rules
Definição do módulo ASN.1 para réguas combinando do componente LDAP e X.500
Atualiza a especificação das regras combinando componentes para o (LDAP) e
os diretórios X.500 coletando as definições do Abstract Syntax Notation One (ASN.1) das
regras combinando componentes em um módulo ASN.1, e identificado outras especificações

142
que possam referenciar as definições, combinando regras dos componentes dentro de seus
próprios módulos ASN.1.

RFC 3771
The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message
Protocolo de Leve Acesso a Diretórios (LDAP) Mensagem De Resposta Intermediária
Define e descreve a mensagem de IntermediateResponse, um mecanismo geral
para definir operações de single-request/multiple-response no (LDAP). A mensagem de
IntermediateResponse é definida de tal maneira que o comportamento do protocolo de
operações existentes de LDAP é mantido. Esta mensagem é usada conjuntamente com o
LDAP ExtendedRequest e ExtendedResponse para definir operações novas de
request/multiple-response ou conjuntamente com um controle ao estender operações
existentes de LDAP em uma maneira que as requeira retornar a informação intermediária da
resposta.

RFC 3829
Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and
Response Controls
Protocolo de Leve Acesso a Diretórios (LDAP) Controles do pedido e da resposta da
identidade da autorização
Estende a operação do (LDAP) com um mecanismo para pedir e retornar a
identidade para estabelecer uma autorização. Define os controles do pedido e da resposta da
identidade da autorização para o uso com a operação do ligamento.

143
BIBLIOGRAFIA

[APACHE] Apache Organization. Disponível em < http://www.apache.org >. Acesso em: 10


abril, 2005, 02:00.

[AURÉLIO,1999] Aurélio, B. H. Ferreira, Dicionário da Língua Portuguesa. 3ª Ed., Nova


Fronteira. Rio de Janeiro – Brasil, 1999.

[CARTER,2003] CARTER, Gerald – LDAP System Administration. 1ª Edição, O’Reilly &


Associates. USA, 2003.

[CERTIFICAÇÃO LINUX] Ribeiro, uirá. Editora Axcel ISBN: 85 - 7323 -232 -3.

[CONECTIVA 2004] EQUIPE CONECTIVA Copyright 2004 Conectiva


S.A. Guia do Servidor Conectiva Linux. Disponível em:
<http://www.conectiva.com/doc/livros/online/10.0/servidor/pt_BR/ > . Acesso em: 24 fev.
2005, 23:30.

[DONLEY,2002] DONLEY, Clayton – LDAP Programming, Management and Integration. 1ª


Edição, Manning Publications. USA, 2002.

[FERREIRA,2003] FERREIRA, Rubem E. – Linux Guia do Administrador do Sistema.


Primeira Edição, Novatec. São Paulo - Brasil, 2003.

[GROSSMANN,2001] GROSSMANN, César A.K. Linux by Grossmann. Disponível em:


<http://geocities.yahoo.com.br/cesarakg/artigos.html#ldap>. Acesso em: 23 Fev. 2005, 00:40.

[GUIA DO HARDWARE] Morimotto, carlos. Desvendando seus segredos. Editora


Altabooks, ISBN: 85-7608064-8.

144
[HOWES,1995] HOWES, timothy A. – The Lightweight Directory Access Protocol: X.500
Lite. Disponível em:< http://www.openldap.org/pub/umich/ldap.pdf >. Acesso em: 23 fev.
2005, 23:00.

[HOWES,1997] HOWES, timothy A.;Smith,Mark – Programming Directory-Enabled


Aplications with Lightweight Directory Access Protocol. 1ª Edição, MacMillan Technical
Publishing. USA, 1997.

[HOWES,2003] HOWES, timothy A.;Smith,Mark;Good,Gordon – Understanding And


Deploying LDAP Directory Services. 2º Edição, Addison-Wesley Pub Co. USA, 2003.

[ISQUIERDO,2001] ISQUIERDO, Gustavo S. – Integração do Serviço de Diretórios LDAP


com o Serviço de Nomes CORBA, Disponível em:<
http://www.teses.usp.br/teses/disponiveis/45/45134/tde-28052003-100121/>. Acesso em: 27
de Abril, 16:08.

[JOHNER,1998] JOHNER, Heinz;Brown, Larry;Hinner, Franz-Stefan;Reis, Wolfgang;


Westman, Johan – Understanding LDAP, IBM Redbook. USA ,1998.

[KAINES, 2001] KAINES, Luke A. Primeiros Passos com LDAP. Disponível em:
<http://geocities.yahoo.com.br/cesarakg/primeiros_passos_ldap.html>. Acesso em: 24 Fev.
2005, 00:50.

[KAINES, 2001] KAINES, Luke A. Uma Introdução ao LDAP. Disponível em:


<http://geocities.yahoo.com.br/cesarakg/IntroLDAP-ptBR.html>. Acesso em: 24 Fev. 2005,
00:15.

[LINUX 2005] Guia do Servidor Conectiva Linux, . Autenticação do Sistema. Disponível em:
<http://www.conectiva.com/doc/livros/online/9.0/servidor/autenticacao.html>. Acesso em: 23
Fev. 2005, 01:00.

[MARCELO,2003] MARCELO, Antonio – Apache – Configurando o Servidor Web para


LINUX. 2ª Edição, Brasport. São Paulo, 2003.

145
[NAGUEL1] NAGUEL, Frederico F.; Fernandes, Elaine; – Diretório Distribuido,
Disponível em:< http://www.ldap.liceu.com.br/conceitos/distribuido.htm>. Acesso em:27 de
Abril, 14:21.

[NAGUEL2] NAGUEL, Frederico F.; Fernandes, Elaine; – Diretório Replicado, Disponível


em:< http://www.ldap.liceu.com.br/conceitos/distribuido.htm>. Acesso em:27 de Abril,
14:25.

[RIBEIRO,2004] RIBEIRO, Uirá – Certificação LINUX. 1ª Edição Axel Books, São Paulo,
2004.

[RNP, 2001] RNP – Rede Nacional de Ensino e Pesquisa. ACL Como Funciona. Disponível
em: <http://www.rnp.br/newsgen/0103/filtros.html>. Acesso em: 27 Abr. 2005, 16:08.

[SLEEPCAT] Sleepycat Software: Berkeley DB Database, Native XML Database, Native


Java Database. Disponível em <www.sleepcat.com > . Acesso em: 10 abril, 2005, 23:43.

[WILCOX,1999] WILCOX,Mark – Implementing LDAP. 1ª Edição, WROK Press. USA,


1999.

[TUTTLE,2003] TUTTLE , Steven; Ehfenberg,Ami; Gorthi,Ramakrishna; Leiserson,Jay;


Macbeth,Richard; Owen,Nathan; Ranahandola,Sunil; Storrs,Michael; Yang,Chunhui –
Undertanding LDAP Desingn and Implementation. Edição,IBM RedBook. 2003.

[TUTTLE,2004] TUTTLE,Steven; Godbole Kedar; McCarthy,Grant – Using LDAP for


Directory Integration.IBM RedBook. USA, 2004.

[RFC 1777] W. Yeong, T. Howes, S. Kille - Lightweight Directory Access Protocol


Obsoletes: 1487. Disponível em < http://www.ietf.org/rfc/rfc1777.txt?number=1777 > Março
de 1995.

[RFC 1777] W. Yeong, T. Howes, S. Kille - Lightweight Directory Access Protocol


Obsoletes: 1487. Disponível em < http://www.ietf.org/rfc/rfc1777.txt?number=1777 > Março
de 1995.

146
[RFC 1779] S. Kille - A String Representation of Distinguished Names
Obsoletes: 1485. Disponível em < http://www.ietf.org/rfc/rfc1779.txt?number=1779>, Março
de 1995.

[RFC 1798] A. Young - A Connection-less Lightweight X.500 Directory Access Protocol


Disponível em < http://www.ietf.org/rfc/rfc1798.txt?number=1798 >, Junho de 1995.

[RFC 1823] T. Howes, M. Smith - The LDAP Application Program Interface


Disponível em < http://www.ietf.org/rfc/rfc1823.txt?number=1823 >, Agosto de 1995.

[RFC 1959] T. Howes, M. Smith - An LDAP URL Format


Disponível em < http://www.ietf.org/rfc/rfc1959.txt?number=1959 >, Junho de 1996

[RFC 2044] F. Yergeau - UTF-8, a transformation format of Unicode and ISO 10646
Disponível em < http://www.ietf.org/rfc/rfc2044.txt?number=2044 >, Outubro de 1996

[RFC 2251] M. Wahl, T. Howes, S. Kille - Lightweight Directory Access Protocol (v3)
Disponível em < http://www.ietf.org/rfc/rfc2251.txt?number=2251 >, Dezembro de 1997

[RFC 2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille - Lightweight Directory Access


Protocol (v3): Attribute Syntax Definitions Disponível em <
http://www.ietf.org/rfc/rfc2252.txt?number=2252 >, Dezembro de 1997.

[RFC 2253] M. Wahl, T. Howes, S. Kille - Lightweight Directory Access Protocol (v3):
UTF-8 String Representation of Distinguished Names. Obsoletes: 1779. Disponível em <
http://www.ietf.org/rfc/rfc2253.txt?number=2253 >, Dezembro de 1997.

[RFC 2254] T. Howes - The String Representation of LDAP Search Filters


Disponível em < http://www.ietf.org/rfc/rfc2254.txt?number=2254 >, Dezembro de 1997.

[RFC 2255] T. Howes , M. Smith - The LDAP URL Format


Disponível em < http://www.ietf.org/rfc/rfc2255.txt?number=2255 >, Dezembro de 1997.

147
[RFC 2256] M. Wahl - A Summary of the X.500(96) User Schema for use with LDAPv3.
Disponível em < http://www.ietf.org/rfc/rfc2256.txt?number=2256 >, Dezembro de 1997.

[RFC 1487] W. Yeong, T. Howes, S. Kille - X.500 Lightweight Directory Access Protocol
Disponível em < http://www.ietf.org/rfc/rfc1487.txt?number=1487 >, Julho de 1993.

[RFC 1558] T. Howes - A String Representation of LDAP Search Filters


Disponível em < http://www.ietf.org/rfc/rfc1558.txt?number=1558 >, Dezembro de 1993.

[RFC 1778] T. Howes, S. Kille, W. Yeong, C. Robbins - The String Representation of


Standard Attribute Syntaxes. Obsoletes: 1488. Disponível em
<http://www.ietf.org/rfc/rfc1778.txt?number=1778 >, Março de 1995.

[RFC 1960] T. Howes - A String Representation of LDAP Search Filters. Obsoletes: 1558.
Disponível em <http://www.ietf.org/rfc/rfc1960.txt?number=1960 >, Junho de 1996.

[RFC 2079] M. Smith - Definition of an X.500 Attribute Type and an Object Class to Hold
Uniform Resource Identifiers (URIs) Disponível em <http://www.ietf.org/rfc/rfc2079.txt?
number=2079 >, Janeiro de 1997.

[RFC 2164] S. Kille - Use of an X.500/LDAP directory to support MIXER address mapping
Obsoletes: 1838. Disponível em http://www.ietf.org/rfc/rfc2164.txt?number=2164 >, Janeiro
de 1998.

[RFC 2247] S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri - Using Domains in


LDAP/X.500 Distinguished Names. Disponível em <http://www.ietf.org/rfc/rfc2247.txt?
number=2247 >, Janeiro de 1998.

[RFC 2307] L. Howard - An Approach for Using LDAP as a Network Information Service
Disponível em <http://www.ietf.org/rfc/rfc2307.txt?number=2307 >, Março de 1998.

[RFC 2377] A. Grimstad, R. Huber, S. Sataluri, M. Wahl - Naming Plan for Internet
Directory-Enabled Applications. Disponível em <http://www.ietf.org/rfc/rfc2377.txt?
number=2377 >, Setembro de 1998.

148
[RFC 2559] S. Boeyen, T. Howes, P. Richard - Internet X.509 Public Key Infrastructure
Operational Protocols - LDAPv2.Updates: 1778. Disponível em <
http://www.ietf.org/rfc/rfc2559.txt?number=2559 >, Abril de 1999.

[RFC 2596] M. Wahl, T. Howes - Use of Language Codes in LDAP. Disponível em <
http://www.ietf.org/rfc/rfc2596.txt?number=2596 >, Maio de 1999.

[RFC 2649] B. Greenblatt, P. Richard - An LDAP Control and Schema for Holding Operation
Signatures. Disponível em <http://www.ietf.org/rfc/rfc2649.txt?number=2649>, Agosto de
1999.

[RFC 2696] C. Weider, A. Herron, A. Anantha, T. Howes - LDAP Control Extension for
Simple Paged Results Manipulation. Disponível em <http://www.ietf.org/rfc/rfc2696.txt?
number=2696 >, Setembro de 1999.

[RFC 2587] S. Boeyen, T. Howes, P. Richard - Internet X.509 Public Key Infrastructure
LDAPv2 Schema.Disponível em <http://www.ietf.org/rfc/rfc2587.txt?number=2587>, Junho
de 1999.

[RFC 2589] Y. Yaacovi, M. Wahl, T. Genovese - Lightweight Directory Access Protocol


(v3):
Extensions for Dynamic Directory Services .Disponível em
<http://www.ietf.org/rfc/rfc2589.txt?number=2589>, Maio de 1999.

[RFC 2567] R. Hedberg - LDAPv2 Client vs. the Index Mesh Services .Disponível em
<http://www.ietf.org/rfc/rfc2657.txt?number=2657 >, Agosto de 1999.

[RFC 2713] V. Ryan, S. Seligman, R. Lee - Schema for Representing Java(tm) Objects in
an LDAP Directory. Disponível em <http://www.ietf.org/rfc/rfc2713.txt?number=2713>,
Outubro de 1999.

[RFC 2739] T. Small, D. Hennessy , F. Dawson - Calendar Attributes for vCard and LDAP.
Disponível em <http://www.ietf.org/rfc/rfc2739.txt?number=2739>, Janeiro de 2000.

149
[RFC 2798] M. Smith - Definition of the inetOrgPerson LDAP Object Class. Disponível em
<http://www.ietf.org/rfc/rfc2798.txt?number=2798>, Abril de 2000.

[RFC 2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan - Authentication Methods for


LDAP
Disponível em <http://www.ietf.org/rfc/rfc2829.txt?number=2829>, Maio de 2000.

[RFC 2830] J. Hodges, R. Morgan, M. Wahl - Lightweight Directory Access Protocol (v3):
Extension for Transport Layer Security. Disponível em <http://www.ietf.org/rfc/rfc2830.txt?
number=2830>, Maio de 2000.

[RFC 2849] G. Good - The LDAP Data Interchange Format (LDIF) - Technical Specification
Disponível em <http://www.ietf.org/rfc/rfc2849.txt?number=2849>, Junho de 2000.

[RFC 2891] T. Howes, M. Wahl, A. Anantha - LDAP Control Extension for Server Side
Sorting of Search Results. Disponível em <http://www.ietf.org/rfc/rfc2891.txt?
number=2891>, Agosto de 2000.

[RFC 2926] J. Kempf, R. Moats, P. St. Pierre - Conversion of LDAP Schemas to and from
SLP Templates. Disponível em <http://www.ietf.org/rfc/rfc2926.txt?number=2926>,
Setembro de 2000.

[RFC 2927] M. Wahl - MIME Directory Profile for LDAP Schema. Disponível em
<http://www.ietf.org/rfc/rfc2927.txt?number=2927>, Setembro de 2000.

[RFC 3045] M. Wahl - Storing Vendor Information in the LDAP root DSE.Disponível em
<http://www.ietf.org/rfc/rfc3045.txt?number=3045>, Janeiro de 2001.

[RFC 3062] K. Zeilenga - LDAP Password Modify Extended Operation


.Disponível em <http://www.ietf.org/rfc/rfc3062.txt?number=3062>, Fevereiro de 2001.

[RFC 3088] K. Zeilenga - OpenLDAP Root Service An experimental LDAP referral service
.Disponível em <http://www.ietf.org/rfc/rfc3088.txt?number=3088>, Abril de 2001.

150

S-ar putea să vă placă și