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................................................................................................................................................................3Lista de figuras..........................................................................................................................................................8Abstract.....................................................................................................................................................................9Resumo....................................................................................................................................................................10Capítulo I – Introdução...........................................................................................................................................11

1.1. Introdução....................................................................................................................................................111.2. Motivação.....................................................................................................................................................121.3. Objetivo Geral..............................................................................................................................................121.4. Objetivos Específicos...................................................................................................................................121.5. Metodologia.................................................................................................................................................13

Capítulo II – Diretórios...........................................................................................................................................142.1 - O que é um diretório...................................................................................................................................142.2 - Vantagens de usar um diretório..................................................................................................................152.3 - Diretórios distribuídos................................................................................................................................162.4 - Diretório Cliente E Servidor.......................................................................................................................17

Capítulo III – LDAP................................................................................................................................................193.1. Histórico do LDAP.......................................................................................................................................193.1.1. Precursores do LDAP................................................................................................................................193.1.2. Versões e características............................................................................................................................203.1.3. RFC’s que padronizam o LDAP...............................................................................................................213.1.4. O LDAP atualmente..................................................................................................................................233.2. LDAP Lightweight Directory Access Protocol............................................................................................233.3. LDAP: Protocolo ou diretório......................................................................................................................243.4. Arquitetura...................................................................................................................................................253.5. Modelos LDAP...........................................................................................................................................253.5.1. Modelo da informação..............................................................................................................................263.5.2. Modelo de nomes......................................................................................................................................263.5.3. Modelo Funcional.....................................................................................................................................273.5.4. Modelo de segurança.................................................................................................................................273.6. LDIF............................................................................................................................................................273.7. Classes de Objetos, Atributos e Esquemas...................................................................................................283.8. Segurança.....................................................................................................................................................313.8.1. Segurança no LDAP.................................................................................................................................323.8.2. Sem Autenticação.....................................................................................................................................333.8.3. Autenticação Básica.................................................................................................................................333.8.4. Autenticação simples e camada segura (SASL - Simple Authentication and Security Layer)................333.8.5. SSL e TLS................................................................................................................................................35

Cliente.....................................................................................................................................................................36Servidor...................................................................................................................................................................36

3.8.6. Outros mecanismos de autenticação SASL..............................................................................................373.9. ACL.................................................................................................................................................................37

3.9.1. Autorização..............................................................................................................................................373.9.2. Políticas de Segurança..............................................................................................................................383.9.3. Definindo Listas de Controle de Acesso..................................................................................................383.9.4. Aspectos Gerais do modelo ACL para LDAP.........................................................................................393.9.5. Semântica / Política..................................................................................................................................39Usabilidade..........................................................................................................................................................403.10. Replicação.................................................................................................................................................403.10.1. Replicação no LDAP..............................................................................................................................423.10.2. Daemon “SLURPD”.............................................................................................................................423.10.2.1. Log de replicação e aquivos auxiliares...............................................................................................433.10.2.2. Modos de operação..............................................................................................................................443.10.2.3. Funcionamento....................................................................................................................................44

5

3.10.3. Ocorrência de falhas no SLAPD e no SLURPD durante a replicação....................................................453.10.4. Concluindo replicação............................................................................................................................453.11. Banco de Dados x LDAP...........................................................................................................................463.11.1. Banco de dados relacional.......................................................................................................................463.11.2. Banco de dados hierárquico....................................................................................................................46

3.12. X.500 x LDAP...............................................................................................................................................473.12.1. Protocolo DAP.......................................................................................................................................473.12.2. Protocolo LDAP......................................................................................................................................483.12.3. Vantagens do LDAP...............................................................................................................................49Desempenho........................................................................................................................................................493.12.5. Comparações DAP x LDAP...................................................................................................................50

Capítulo IV – Principais Ferramentas LDAP..........................................................................................................534.1. Introdução.....................................................................................................................................................534.1.1 Freeware.....................................................................................................................................................534.1.2 Open Source...............................................................................................................................................544.1.3 Ferramentas LDAP.....................................................................................................................................544.2. PHP LDAP ADMIN.....................................................................................................................................544.2.1 Características............................................................................................................................................554.2.2 Criando entradas de LDAP........................................................................................................................564.2.3 Editando entradas.......................................................................................................................................574.2.4 Manutenção de dados.................................................................................................................................584.2.5 Buscas de LDAP........................................................................................................................................584.2.6 Sustentação comercial de servidor LDAP..................................................................................................594.2.7 Novell.........................................................................................................................................................594.2.8 Sun ONE Directory Server.........................................................................................................................604.2.9 Microsoft ActiveDirectory.........................................................................................................................614.2.10 Sustentação internacional da língua.........................................................................................................614.3. YALA ..........................................................................................................................................................624.3.1 Características............................................................................................................................................624.4 LDAP Browser/Editor ..................................................................................................................................704.4.1 Características: ..........................................................................................................................................704.5. SMBLDAP...................................................................................................................................................71

Capítulo V – O LDAP e o Gerenciamento de Usuários..........................................................................................725.1. Usuários........................................................................................................................................................735.2. Gerenciamento.............................................................................................................................................735.3. Gerenciamento de Usuários.........................................................................................................................735.4. LDAP no Gerenciamento de Usuários.........................................................................................................74

Conclusão................................................................................................................................................................76Anexo I – Documentação acerca da Implementação do Protocolo LDAP para Gerenciamento de Usuários........77

1. Objetivo geral..................................................................................................................................................772. Descrição e abrangência..................................................................................................................................783. Recursos de hardware e software....................................................................................................................783.1. GNU/Linux – Kurumin................................................................................................................................793.2 OpenLDAP....................................................................................................................................................793.2.1. SLAPD......................................................................................................................................................793.2.2 Backend de Banco de Dados – BerkeleyDB..............................................................................................803.3. APACHE, PHP e PHPLDAPADMIN.........................................................................................................813.4. Microsoft Windows XP®.............................................................................................................................813.5 Outlook Express®.........................................................................................................................................824. Configurações..................................................................................................................................................824.1 Servidor ........................................................................................................................................................824.1.1 BerkleyDB..................................................................................................................................................824.1.1.1 Instalação e configuração.......................................................................................................................824.1.2 OpenLDAP.................................................................................................................................................844.1.2.1 Instalação e configuração........................................................................................................................844.1.2.2 Migração.................................................................................................................................................914.1.3 Sistema de Autenticação............................................................................................................................934.1.3.1 PAM e NSS............................................................................................................................................934.1.3.2 Instalação e Configuração do NSS e PAM............................................................................................934.1.4 Samba.........................................................................................................................................................984.1.4.1 Instalação e Configuração.......................................................................................................................98

6

4.1.5 Smbldap-tools...........................................................................................................................................1014.1.5.1 Instalação e configuração......................................................................................................................1024.1.6 Apache......................................................................................................................................................1064.1.6.1 Instalação e Configuração.....................................................................................................................1074.1.7 PHP...........................................................................................................................................................1124.1.8 PHPLDAPADMIN...................................................................................................................................1135.1 Estação de trabalho......................................................................................................................................1185.1.1 Autenticação.............................................................................................................................................118Configuração.....................................................................................................................................................118Cliente de E-mail...............................................................................................................................................120 5.1.2.1 Outlook Express...............................................................................................................................1205.1.2.2 Pesquisa de Informações ......................................................................................................................1226. Esquema de Funcionamento..........................................................................................................................1237. Simulação do ambiente.................................................................................................................................1247.1 Usuários e Grupos.......................................................................................................................................125Criação de Grupos e Usuários...........................................................................................................................1257.1.1.1 Autenticação..........................................................................................................................................126

Anexo II – RFC’s..................................................................................................................................................131RFC 1777..........................................................................................................................................................131RFC 1779..........................................................................................................................................................131RFC 1798 .........................................................................................................................................................131RFC 1823..........................................................................................................................................................132RFC 1959..........................................................................................................................................................132RFC 2044..........................................................................................................................................................132RFC 2251..........................................................................................................................................................132RFC 2252..........................................................................................................................................................133RFC 2253..........................................................................................................................................................133RFC 2254..........................................................................................................................................................133RFC 2255..........................................................................................................................................................134RFC 2256 ........................................................................................................................................................134RFC 1487..........................................................................................................................................................134RFC 1558..........................................................................................................................................................135RFC 1778..........................................................................................................................................................135RFC 1960..........................................................................................................................................................135RFC 2079..........................................................................................................................................................135RFC 2116..........................................................................................................................................................136RFC 2164..........................................................................................................................................................136RFC 2247..........................................................................................................................................................136RFC 2307 .........................................................................................................................................................137RFC 2377..........................................................................................................................................................137RFC 2559..........................................................................................................................................................137RFC 2596..........................................................................................................................................................137RFC 2649..........................................................................................................................................................138RFC 2696..........................................................................................................................................................138RFC 2587..........................................................................................................................................................138RFC 2589..........................................................................................................................................................139RFC 2657..........................................................................................................................................................139RFC 2713..........................................................................................................................................................139RFC 2739..........................................................................................................................................................140RFC 2798..........................................................................................................................................................140RFC 2820..........................................................................................................................................................140RFC 2829..........................................................................................................................................................141RFC 2830..........................................................................................................................................................141RFC 2849..........................................................................................................................................................141RFC 2891..........................................................................................................................................................141RFC 2926..........................................................................................................................................................142RFC 2927..........................................................................................................................................................142RFC 3045..........................................................................................................................................................142RFC 3062..........................................................................................................................................................143RFC 3088..........................................................................................................................................................143RFC 3112..........................................................................................................................................................143

7

RFC 3296..........................................................................................................................................................143RFC 3352..........................................................................................................................................................144RFC 3377..........................................................................................................................................................144RFC 3383..........................................................................................................................................................144RFC 3384..........................................................................................................................................................145RFC 3494..........................................................................................................................................................145RFC 3663..........................................................................................................................................................145RFC 3671..........................................................................................................................................................145RFC 3672..........................................................................................................................................................146RFC 3673..........................................................................................................................................................146RFC 3674..........................................................................................................................................................146RFC 3687..........................................................................................................................................................146RFC 3698..........................................................................................................................................................147RFC 3703..........................................................................................................................................................147RFC 3712..........................................................................................................................................................147RFC 3727..........................................................................................................................................................147RFC 3771..........................................................................................................................................................148RFC 3829..........................................................................................................................................................148

Bibliografia............................................................................................................................................................149

LISTA DE FIGURAS

Figura 1 - Representação, requisições feitas de clientes de LDAP a um servidor LDAP......................................18Figura 2 - Árvore de diretório.................................................................................................................................26Figura 3 - Mecanismo SASL...................................................................................................................................35Figura 4 - SSL/TLS no relacionamento com outros protocolos..............................................................................35Figura 5 - Acordo SSL/TLS....................................................................................................................................36Figura 6 - Sistema com uma única base..................................................................................................................41Figura 7 - Sistema com a base distribuída...............................................................................................................41 Figura 8 - Replicação do servidor mestre para os sevidores escravos..................................................................42Figura 9 - Serviço de replicação..............................................................................................................................43Figura 10 - Funcionamento X500 x LDAP.............................................................................................................48Figura 11 - Página Inicial do phpLDAPadmin........................................................................................................56Figura 12 – Criação de entradas..............................................................................................................................57Figura 13 – Opções de manuseio phpLDAPadmin.................................................................................................57Figura 14 – Formulário de buscas...........................................................................................................................58Figura 15 - Entrada de certificado LDAP Novell...................................................................................................59Figura 16 - Grupo de administradores do diretório SUN ONE...............................................................................60Figura 17 - Entrada Microsoft ActiveDirectory......................................................................................................61Figura 18 - Tela do início de uma sessão do YALA...............................................................................................63Figura 19 – Árvore e índices de entrada específica................................................................................................63Figura 20 – Sendo executado no Internet Explorer................................................................................................64Figura 21 - Árvore de buscas no frame direito........................................................................................................68Figura 22 – Criação de uma nova entrada...............................................................................................................68Figura 23 – Browser text-mode...............................................................................................................................69

8

Figura 24 – LDAP Browser editor..........................................................................................................................71Figura 25 – Tela de login do SMLDAP..................................................................................................................72Figura 26 – apt-get listando os pacotes e suas dependências..................................................................................85Figura 27 - apt listando os pacotes slapd e suas dependências...............................................................................86Figura 28 – Debconf iniciado, para iniciar os primeiros parâmetros do servidor LDAP.......................................88Figura 29 - Debconf pergunta sobre compatibilidade para o LDAPv2...................................................................88Figura 30 – Debconf na configuração do slapd, solicitando a senha do administrador..........................................89Figura 31 - Debconf inicia os parâmetros de configuração do nss-ldap.................................................................94Figura 32 - Debconf solicita a base DN do LDAP..................................................................................................95Figura 33 – Debconf pergunta qual versão LDAP foi instalada.............................................................................95Figura 34 – Debconf solicita o usuário administrador da Base DN........................................................................96Figura 35 – Arquivo de configuração do cliente LDAP.........................................................................................97Figura 36 – Arquivo de configuração do nsswitch.................................................................................................97Figura 37 – smbldap-populate inserindo entradas na base dc=ldap, dc=df..........................................................106Figura 38 - apt lista os pacotes do apache e suas dependências............................................................................107Figura 39 - apt obtendo os pacotes de mirrors como ftp.br.debian.org.................................................................112Figura 40 - apt iniciando a instalação do php-ldap e php4-pear...........................................................................113Figura 41 - apt instalando o pacote phpldapadmin e o obtendo............................................................................113Figura 42 - Debconf iniciando as primeiras configurações do phpldapadmin......................................................114Figura 43 - Debconf solicitando qual o servidor está instalado no sistema..........................................................115Figura 44 - Tela inicial do phpldapadmin.............................................................................................................116Figura 45 – Tela do Outlook express, configuração de contas.............................................................................121Figura 46 – configuração do serviço LDAP no Outlook express.........................................................................121Figura 47 – Configurações avançadas do serviço LDAP no outlook...................................................................122Figura 48 – representa uma busca pelo nome através da Base LDAP..................................................................123Figura 49 – Esquema de funcionamento do Protótipo..........................................................................................124Figura 50 – Konqueror acessando o serviço samba, ainda sem usuário definido.................................................126Figura 51 – Acessando a pasta dados como usuário do grupo material................................................................127Figura 52 – Acesso Negado a pasta Dados como usuário usermaterial................................................................128Figura 53 – Acesso a pasta dados como usuário do grupo dados.........................................................................128Figura 54 – Navegação na pasta dados como usuário userdados..........................................................................129Figura 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íficas15

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.

10CCITT- Consultatif et Comite Telephonique Internacional et Telegraphique, (Comitê Consultivo Internacional em Telefonia e Telegrafia)11ITU 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 Force17 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 One21

• 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 Language25 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 LDAP25

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

Figura 2 - Árvore de diretório.

27 Directory Information Tree – Árvore de Informação do Diretório26

dc = ldap, dc = df

ou = pessoas ou = grupos ou = computador

uid = tiago

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=dfobjectclass: personuid: 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 applicationEntityadminPerson applicationProcessalias certificationAuthority

certificationAuthority-V2 country

cRLDistributionPoint dcObjectdevice dmddNSDomain documentdocumentSeries domain domainRelatedObject dSAdynamicObject eduPersonextensibleObject friendlyCountrygroupOfNames groupOfUniqueNamesinetOrgPerson labeledURIObjectLDAPsubEntry localitymailAlias OpenLDAProotDSEorganization organizationalPersonorganizationalRole organizationalUnitperson pilotDSApilotOrganization qualityLabelledDatareferral reservedresidentialPerson RFC822localPartroom simpleSecurityObjectstrongAuthenticationUser subschematop uflEduOrganizationuflEduPerson uflEduRelationshipuidObject 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 Esquemac countryName country core.schemacn commonName person

organizationalPersonorganizationalRolegroupOfNamesapplicationProcessapplicationEntityposixAccountdevice

core.schema

dc domainComponent dcObject core.schema- facsimileTelephoneNumber residentialPerson

organizationalRoleorganizationalPerson

core.schema

co friendlyCountryName friendlyCountry cosine.schemagn givenName inetOrgPerson core.schemahomePhone homeTelephoneNumber inetOrgPerson cosine.schema- jpegPhoto inetOrgPerson inetorgperson.schemal localityName locality

organizationalPerson core.schema

mail rfc822Mailbox inetOrgPerson core.schemamobile mobileTelephoneNumber inetOrgPerson cosine.schemao organizationName organization core.schemaou organisationalUnitName organizationUnit core.schema- owner groupOfNames

devicecore.schema

30

groupOfUniqueNamespager pagerTelephoneNumber inetOrgPerson cosine.schema- postalAddress organizationalPerson core.schemapostalCode postalCode organizationalPerson core.schemasn surname person core.schemast stateOrProvinceName organizationalPerson core.schemastreet streetAddress organizationalPerson core.schema- telephoneNumber organizationalPerson core.schemauserPassword - organization

organizationalUnitpersondmdsimpleSecurityObjectdomainposixAccount

core.schema

uid userid accountinetOrgPersonposixAccount

core.schema

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

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.

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

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

35

Chamadas do

Mecanismos SASL (Cliente LDAP)

Driver SASL no Servidor LDAP

Sistema de Autenticação

Protocolos de Aplicação

Protocolos de Rede

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

HTTP SMTP LDAP

Security Layer (SSL/TLS)

TCP/IP layer

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.

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

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

Certificado, Opções SSL/TLS

Confirmação

Mensagem, Digest

Chave Simétrica (encriptada)

Mensagem aleatória (encriptada)

CLIENTE SERVIDOR

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:

3.10. REPLICAÇÃO

40

Acess to attrs = userPasswordBy dn= ”cn=admin, dc=LDAP, dc=df” writeBy anonymous authBy self writeBy x nome

Access to dn.base=”” by * read

Access to *By dn=”cn=admin,dc=LDAP,dc=df”

write by*read.

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 rede29 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 processamento48

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 LDAPSem Autenticação 30 68Autenticado 34 56Pesquisa Simples (uma entrada) 32 41Pesquisa 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 LDAPSem Autenticação 192 14Autenticado 409 138Requisição de Pesquisas Simples 237 105Resultados 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 LDAPSimples 550 110Média 7925 714Complexa 38393 2702

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

Complexidade PDU DAP LDAPSimples 24 6Médio 1084 324Complexo 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 LDAPTexto 958.464 221.184Dados 385.024 73.728Contador de semi-colunas 46.746 1.989Contadores 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 Interface63

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 hierarquico40 PDC primary Domain Contrller , sistema que controla um domínio de rede41 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 internet78

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 iPlanet43

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:

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

backend de banco de dados BerkeleyDB:

Compilando:

Instalando:

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

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

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

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

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

87

########################################################## Allow LDAPv2 bindsallow 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_v2rootdn="cn=admin,dc=ldap,dc=df"rootpw= deus

# Schema and objectClass definitionsinclude /etc/ ldap /schema/core.schemainclude /etc/ ldap /schema/cosine.schemainclude /etc/ ldap /schema/nis.schemainclude /etc/ ldap /schema/inetorgperson.schemainclude /etc/ ldap /schema/samba3x.schema# Schema check allows for forcing entries to# match schemas for their objectClasses'sschemacheck 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 serverargsfile /var/run/slapd.args

# Read slapd.conf(5) for possible valuesloglevel 0

# Where the dynamically loaded modules are storedmodulepath /usr/lib/ ldapmoduleload back_bdb

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

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

# The base of your directory in database #1suffix "dc= ldap,dc=df"

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

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

# Indexing options for database #1index objectClass eq

# Save the time that the entry gets modified, for database #1lastmod 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

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

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.

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

formato padrão LDIF.

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

criação diretório.

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

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

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

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

#Default DNS domains

$DEFAULT_MAIL_DOMAIN = “angel.ldap.df”

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

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

#./migrate_base.pl > base.ldif

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:

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

# apt-get install libnss-ldap

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.

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

# apt-get libpam-ldap

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:

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

#apt-get install samba -t unstable

armazenamento de arquivos e impressoras. A seguir é demonstrado o arquivo smb.conf com

comentários somente nas partes relevantes:

96

[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*

97

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 = Impressoraspath = /var/spool/sambabrowseable = noguest ok = nowritable = noprintable = yes

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 SAMBA98

[dados]comment = Diretório de provas e dados secretospath = /home/dadospublic = no writable = yesprintable = nocreate mask = 0765read lis = @Dadosinvalid users = @Materialread list = @Dadosvalid users = @Dadosuser = @Dados

[Material]comment= Diretório de Material escolarpath = /home/materialpublic = yeswritable = yesprintable = nocreate mask = 0765valid 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

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.

99

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

#

# 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)

100

# 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)

101

# Login defs

# Default Login Shell

# Ex: userLoginShell="/bin/bash"

userLoginShell="/bin/bash"

# Home directory

# Ex: userHome="/home/%U"

userHome="/home/%U"

# Gecos

userGecos="System User"

# Default User (POSIX and Samba) GID

defaultUserGid="513"

# Default Computer (Samba) GID

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)

# The default Home Drive Letter mapping

# (will be automatically mapped at logon time if home directory exist)

# Ex: H: for H:

userHomeDrive="H:"

# The default user netlogon script name (%U username substitution)

# if not used, will be automatically username.cmd

# make sure script file is edited under dos

# Ex: %U.cmd

# userScript="startup.cmd" # make sure script file is edited under dos

userScript=logon.bat"

# Domain appended to the users "mail"-attribute

# when smbldap-useradd -M is used

mailDomain="ldap.df"

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

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

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

# 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"

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.

111

<?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 = '';

112

// 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.

…

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.

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

...

// 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' );

...

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:

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\

netlogon\parameters"RequireSignOrSeal"=dword:00000000

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:

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:

120

#SMBLDAP-GROUPADD DADOS

#SMBLDAP-GROUPADD MATERIAL

#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

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 LDAPDefine 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 96Define 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