Autenticação de Usuários em Um Diretório LDAP

JEDSON ZENDRON FIGUEIREDO
AUTENTICAÇÃO E MANUTENÇÃO DAS CONTAS DE USUÁRIOS DE

SISTEMAS INTEGRADOS A SERVIÇOS DE DIRETÓRIOS
Assis
2008
Trabalho de Conclusão de Curso apresentado ao Instituto Municipal de Ensino

Superior de Assis, como requisito do Curso de Graduação, analisado pela comissão
examinadora:
Orientador: Douglas Sanches da Cunha
Analisador (1): Alex Sandro Romeo de Souza Poletto
Analisador (2): Domingos de Carvalho Villela Júnior
Assis
2008

Trabalho de Conclusão de Curso apresentado ao Instituto Municipal de Ensino

Superior de Assis, como requisito do Curso de Graduação, analisado pela comissão
examinadora:
Orientador: __________________________________________________________
Área de Concentração: ________________________________________________

___________________________________________________________________
Assis
2008
DEDICATÓRIA
Dedico este trabalho a todos os professores que me ajudaram nessa batalha de

graduação, em especial, para o meu orientador que desde o início do meu interesse
pelo tema, me incentivou, mostrando caminhos a serem traçados para expor, ou
mesmo, aplicar esse trabalho em investimentos futuros.
AGRADECIMENTOS
Agradeço principalmente, á Deus por abençoar nas horas de cansaço e pela

empolgação e vontade de escrever.
Aos meus familiares, que constantemente me incentivaram e me ajudaram a dedicar

ativamente aos estudos, mostrando-me a realidade da vida.
Em especial, ao meu pai pelo incentivo e determinação pelo meu sucesso. Pelo meu
primo Osvandre Martins, na qual apresentou algumas formas de escrita e conteúdo
do trabalho.
Ao professor, Douglas Sanches da Cunha, pela orientação e pelo constante estímulo

transmitido durante o trabalho.
Aos amigos, Claudinei Moreira, Almir Rogério Camolesi, Alex Sandro Romeo de
Souza Poletto e a todos que colaboraram direta ou indiretamente na execução deste
trabalho.
RESUMO
As instituições de médio e grande porte demonstram dificuldade na manutenção das

contas on-line de usuários, em virtude dos diferentes sistemas computacionais
utilizados, de diferentes fornecedores. Promovendo, redundância nas informações e
autenticações desencontradas. Com isso, uma das tecnologias de redes de
computadores, pode auxiliar nessa circunstância, é o LDAP (Lightweight Directory
Access Protocol). Conhecido como, um protocolo leve de acesso a diretórios, na
qual tem por objetivo resolver os problemas de descentralização das informações do
usuário, bem como, centralizar a autenticação. Favorece maior segurança nas
informações de usuários, diminuição nos custos de implantação e gerenciamento,
suportes para quaisquer recursos de redes acessarem serviços de diretórios. A partir
disso, foi elaborado um aplicativo de manutenção dos usuários integrado a esses
serviços do protocolo LDAP. E outro software, com dois algoritmos de teste,
avaliando estatisticamente, conforme um cenário envolvendo outras tecnologias de
rede, para testar o tempo (em segundos) da autenticação em até cem mil usuários.
Palavras-chave: LDAP. Autenticação. Serviço de Diretórios.

ABSTRACT
The institutions of medium and large show difficulty keeping the accounts of users
online, owing to different computer systems used in different suppliers. Promoting,
redundancy in the information and endorsements missing. With this, one of the
technologies of computer networks, can assist in that circumstance, is the LDAP
(Lightweight Directory Access Protocol). Known as a lightweight protocol for access
to directories, which aims to solve the problems of decentralization of user
information, and to centralize authentication. It encourages greater security in the
user's information, reduction in the cost of deployment and management, media
resources for any network access services directories. From there, a new application
for maintenance of the users of these services integrated with LDAP protocol. And
other software with two algorithms for testing, evaluating statistically, as a scenario
involving other network technologies, to test the time (in seconds) for authentication
in up to one thousand thou and users.
Keywords: LDAP. Authentication. Service Directories.

LISTA DE ILUSTRAÇÕES
Figura 1 – História do LDAP ..................................................................................... 23

Figura 2 – Utilizando DIXIE para se comunicar com diretórios X.500 ...................... 24
Figura 3 – Modelo gateway LDAP/DAP .................................................................... 25
Figura 4 – Cliente do X.500 ...................................................................................... 26
Figura 5 – DAP (Directory Access Protocol) ............................................................. 26
Figura 6 – Pilha de Protocolos .................................................................................. 27
Figura 7 – Arquitetura LDAP ..................................................................................... 28
Figura 8 – Representação de parte de um Diretório LDAP ...................................... 29
Figura 9 – RDNs idênticos ........................................................................................ 30
Figura 10 – DN é uma seqüência de RDN’s ............................................................. 30
Figura 11 – Exemplo de entradas em um arquivo LDIF ........................................... 32
Figura 12 – Classe de objeto person, retirada do core.schema................................ 33
Figura 13 – Recebimento de uma única entrada ...................................................... 35
Figura 14 – Recebimento de várias entrada ............................................................. 35
Figura 15 – Uma simples pesquisa no LDAP ........................................................... 36
Figura 16 – Estabelecimento de conexão, consultas e fechamento de uma conexão
LDAP ........................................................................................................................ 37
Figura 17 – LDAP usando SASL com SSL/TLS ....................................................... 41
Figura 18 – Pontos de Falha da Replicação de Diretórios........................................ 43
Figura 19 – Redundância de Diretórios .................................................................... 43
Figura 20 – Ponto de Falha e Troca de Servidor ...................................................... 44
Figura 21 – Vários Clientes de Diretórios acessando somente um Servidor ............ 45
Figura 22 – Vários Clientes de Diretórios acessando Servidores Replicados .......... 45
Figura 23 – Detalhes da estrutura do diretório e tela de criação de novas entradas no
diretório usando phpLDAPadmin .............................................................................. 47
Figura 24 – Administração do diretório com LDAP Adm........................................... 48
Figura 25 – Edição avançada de atributos com o LDAP Admin ............................... 48
Figura 26 – Arquitetura da FEMA ............................................................................. 51
Figura 27 – Estrutura de Diretórios da FEMA ........................................................... 52
Figura 28 – Variáveis que determinam a quantidade de Usuários de acordo com a
Proporção ................................................................................................................. 53
Figura 29 – Criação dos Usuários no Diretório LDAP, para cada Grupo, dependendo
da proporção............................................................................................................. 53
Figura 30 – Manutenção das Contas de Usuários .................................................... 54
Figura 31 – Forma A e B de Autenticações de Usuários .......................................... 55
Figura 32 – Resultados em Segundos de duas formas de Autenticações de Usuários
para quatro tipo de conexões a Internet com três quantidades de Usuários ............ 57
Figura 33 – Integração dos Usuários de Sistemas ao Serviço de Diretórios
OpenLDAP................................................................................................................ 59
Figura 34 – Caso de Uso do Modelo de Negócio ..................................................... 61
Figura 35 – Diagrama de Classes Beans e LDAP .................................................... 62
Figura 36 – Página de Autenticações dos Usuário para efetuar o acesso ao
Aplicativo Demonstrativo .......................................................................................... 63
Figura 37 – Aplicativo Demonstrativo ....................................................................... 64
Figura 38 – Permissões de Ação do Usuário Simples que acessou ao Aplicativo
Demonstrativo........................................................................................................... 65
Figura 39 – Algoritmo que Insere os Usuários no diretório LDAP, de acordo com a
Proporção ................................................................................................................. 70
Figura 40 – Algoritmo que Autenticar os Usuários, a partir de somente uma abertura
e um fechamento da conexão com o LDAP (Avaliação A), de acordo com a
Proporção ................................................................................................................. 71
Figura 41 – Algoritmo que Autenticar os Usuários, a partir da abertura e fechamento
da conexão com o LDAP para cada validação (Avaliação B), de acordo com a
Proporção ................................................................................................................. 72
Figura 42 – Algoritmo que Apaga todos os Usuários do diretório LDAP, de acordo
com a Proporção ...................................................................................................... 73
Figura 43 – Avaliação A da Autenticação de Mil Usuários com Conexão de Internet
Dial Up ...................................................................................................................... 74
Figura 44 – Avaliação A da Autenticação de Mil Usuários com Conexão de Internet
Rede Local................................................................................................................ 75
Figura 45 – Avaliação A da Autenticação de Cem Mil Usuários com Conexão de
Internet Wireless ....................................................................................................... 76
Figura 46 – Avaliação B da Autenticação de Dez Mil Usuários com Conexão de
Internet Rede Local .................................................................................................. 77
Figura 47 – Autenticação de Usuário........................................................................ 78
Figura 48 – Manutenção de Dados dos Usuários ..................................................... 78
Figura 49 – Movimentação das Permissões de Ação dos Usuários ......................... 79
Figura 50 – Relatório das Permissões de Ação aos Grupos e Usuários .................. 79
Figura 51 – Autenticação do Usuário no Diretório LDAP .......................................... 80
Figura 52 – Manutenção de Usuários de Sistemas Integrada ao Diretório LDAP .... 81
LISTA DE TABELAS
Tabela 1 – Alguns exemplos de Object Identifie ....................................................... 31

Tabela 2 – Algumas abreviaturas de atributos, com seus respectivos nomes.......... 32
Tabela 3 – Resultados do Tempo de Autenticações de Usuários ............................ 56
LISTA DE ABREVIATURAS E SIGLAS
SGBD Sistema de Gerenciamento de Base de Dados

DNS Domain Name System
DIT Directory Information Tree
RFC Request For Comments
LDAP Lightweight Directory Access Protocol
LDAPv1 LDAP primeira versão
LDAPv2 LDAP segunda versão
LDAPv3 LDAP terceira versão
Kerberos v4 Kerberos quarta versão
Kerberos v5 Kerberos quinta versão
TCP/IP Transmition Control Protocol / Internet Protocol
IETF Internet Engineering Task Force
OSI-DS Open Service Interface Definitions
SMTP Simple Mail Transfer Protocol
HTTP Hypertext Transfer Protocol
FTP File Transfer Protocol
TELNET Tipos de Acesso na Internet
ISO International Standardization Organization
CCITT Consultative Committee for International Telegraphy and Telephony
DAP Directory Access Protocol
OSI Open System Interconnection
DAS Directory Assistance Service
DIXIE Directory Interface to X.500 Implemented Efficiently
LDBP Lightweight Directory Browsing Protocol
DSML Directory Services Markup Language
SPML Service Provisioning Markup Language
SLP Service Location Protocol
SASL Simple Authentication Security Layer
DIGEST-MD5 Using Digest Authentication as a SASL Mechanism
StartTLS Extension for Transport Layer Security
TLS Transport Layer Security
SSL Secure Sockets Layer
SSO Single Sing On
DN Distinguished Name
CN Common Name
RDN Relative Distinguished Name
LDIF LDAP Data Interchange Format
OID Object Identifier
IANA Internet Assigned Number Authority
SN Surname
GN Given Name
O Organization Name
OU Organization Unit Name
ST State or Province Name
L Locality Name
C Country
DC Domain Component
UID User Identification
MSGID Identificador de mensagens
IP Internet Protocol
PAM Pluggable Authentication Modules
NSS Name Service Switch
POSIX Portable Operating System Interface
FEMA Fundação Educacional do Município de Assis
IDE Intelligent Drive Electronics ou também Integrated Drive Electronics
JSP Java Server Pages
JNDI Java Naming and Directory Interface
JEE Java Enterprise Edition
JMS Java Message Service
API Application Programming Interface
SPI Service Provider Interface
IEEE Institute of Electrical and Electronics Engineers
ADSL Asymmetric Digital Subscriber Line
AJAX Asynchronous Javascript And XML
XML Extensible Markup Language
MVC Model View Controller
UML Unified Modeling Language
JUDE Java and UML Developers Environment
SUMÁRIO
1 INTRODUÇÃO ................................................................................... 17
1.1 JUSTIFICATIVA E MOTIVAÇÕES............................................................... 17
1.2 OBJETIVOS ...................................................Erro! Indicador não definido.
1.3 ESTRUTURA DO TRABALHO .....................Erro! Indicador não definido.

2 CONCEITOS DE SERVIÇOS DE DIRETÓRIOS .............................. 21
2.1 O QUE É UM SERVIÇO DE DIRETÓRIO? ............................................. 21
2.2 O QUE É LDAP? ...................................................................................... 22
2.3 HISTÓRIA DO LDAP ............................................................................... 22
2.4 ORIGEM DO LDAP .................................................................................. 25
2.4.1 Diretório X.500 ............................................................................................ 25
2.4.2 Cliente do X.500 ......................................................................................... 26
2.4.3 DAP ............................................................................................................. 26
2.4.4 Pilhas de protocolos .................................................................................. 26
2.4.5 Versões ....................................................................................................... 27
2.5 POR QUE USAR LDAP? ......................................................................... 28
2.6 DIRETÓRIO LDAP ................................................................................... 29
2.7 SCHEMA .................................................................................................. 29
2.8 DISTINGUISHED NAMES (DN) .............................................................. 30
2.9 O QUE É LDIF? ....................................................................................... 30
2.10 OBJECT IDENTIFIER (OID) .................................................................... 31
2.11 ATRIBUTO .............................................................................................. 31
2.12 ENTRADA ............................................................................................... 32
2.13 OBJECT CLASS ..................................................................................... 33

3 PROTOCOLO LDAP ......................................................................... 34
3.1 OPERAÇÕES .......................................................................................... 34
3.2 SEGURANÇA .......................................................................................... 37
3.2.1 Métodos de Autenticação.......................................................................... 38
3.2.2 Métodos de Criptografia ............................................................................ 40
3.2.3 Modelo de Controle de Acesso ................................................................. 41
3.3 OTIMIZAÇÕES DO LDAP ....................................................................... 42
3.3.1 Replicação do serviço de diretórios......................................................... 42
3.3.2 Diretórios distribuídos............................................................................... 44
3.4 OPENLDAP ............................................................................................. 46
3.5 FERRAMENTAS PARA GERENCIAR UM SERVIDOR LDAP ................ 46

4 ARQUITETURA DE DIRETÓRIOS ................................................... 50
4.1 CONSIDERAÇÕES ................................................................................. 50
4.2 AVALIAÇÃO DA AUTENTICAÇÃO DE USUÁRIOS ............................... 52
4.3 ESTATÍSTICA DA ESTRUTURA DE DIRETÓRIOS DA FEMA .............. 56

5 APLICATIVO DEMONSTRATIVO .................................................... 58
5.1 CONSIDERAÇÕES ................................................................................. 59
5.2 MODELAGEM E APRESENTAÇÃO DO APLICATIVO ........................... 60

6 CONCLUSÕES .................................................................................. 66
REFERÊNCIAS BIBLIOGRÁFICAS ....................................................... 68
ANEXO A – ALGORÍTMOS DA AVALIAÇÃO DA AUTENTICAÇÃO .. 70
ANEXO B – RESULTADOS DOS TESTES DAS AUTENTICAÇÕES .. 74
ANEXO C – DIAGRAMAS DE CASO DE USO – CAPÍTULO 5 ............ 78
ANEXO D – DIAGRAMAS DE SEQÜÊNCIA – CAPÍTULO 5 ............... 80
17
1 INTRODUÇÃO
A evolução tecnológica nas redes de computadores se tornou estratégica para as

mais diversas organizações. Com essa realidade, é fundamental a criação de
métodos de aplicação e estudos voltados para garantir a segurança das
informações.
As empresas estão cada vez mais informatizando seus processos e nem sempre é
possível ter um único sistema que atenda a todas as necessidades, principalmente
se estes não forem desenvolvidos internamente, mas sim, adquiridos ou contratados
de fornecedores. Diante disso, é comum encontrar organizações que usam vários
sistemas diferentes, oriundos de fornecedores diferentes nos quais cada um possui
recursos específicos de controle de acesso (LUPPI, 2008).
O referido fato geralmente resulta num oneroso trabalho de administração de contas

de usuário e senhas. As instituições nem sempre possuem uma boa administração
na segurança das informações, devido à existência de poucos recursos para
gerenciá-las, na qual acarreta problemas, que conseqüentemente oferecem várias
oportunidades para ataques de hackers, crackers e outros tipos de invasões.
1.1 JUSTIFICATIVAS E MOTIVAÇÕES
As aplicações de uma instituição, localizadas em diferentes servidores, têm

desvantagens quando se pretende aproveitar as informações dos usuários, devido
às autenticações serem em bancos de dados e tabelas diferentes. Com isso, as
manutenções das contas tornam-se complexas, por causa da ambigüidade das
informações, visto que, para cada aplicativo serão necessárias as mesmas
credenciais.
No entanto, pode-se criar uma hierarquia em árvore que denomina uma estrutura do
ponto de vista lógico que se distribui fisicamente em repositórios de diferentes
servidores de diretórios, a fim de dividir os tipos de usuários por um único domínio
(Organização).
A relevância do problema e a existência de tecnologias que se propõem a auxiliar e

resolvê-los, constituem na principal motivação para a realização deste trabalho. Uma
18
dessas tecnologias é o protocolo de rede chamado LDAP (Lightweight Directory

Access Protocol), conhecido como sendo protocolo leve de acesso a diretórios, que
se propõe resolver o problema da descentralização de informações de usuários, dos
vários sistemas das instituições de médio e grande porte, proporcionando agilidade
e redução de custo (MALDANER, 2004).
Segundo MALDANER (2004), o uso do LDAP pode trazer mais agilidade em vários
sistemas de empresas: “A pessoa não precisa lembrar de todas as senhas, basta
apenas lembrar da sua senha para abrir todos os sistemas da empresa e as demais
senhas são armazenadas no diretório LDAP".
A idéia da centralização das informações dos usuários facilitará os acessos aos

vários sistemas e recursos da rede, a partir de uma única identificação coletada
após a autenticação do usuário no diretório LDAP.
1.2 OBJETIVOS
A proposta de uma alternativa (Open Source e Freeware) para a implementação das

funcionalidades de autenticações aplicáveis a sistema de software.
Fundamentar e avaliar a autenticação de usuários, a partir da criação de dois

algoritmos específicos, nas quais um deles executará, seqüencialmente (em clientes
Windows ou Linux), uma rotina de autenticações com somente uma abertura e
fechamento da conexão com o serviço de diretórios, já outro algoritmo, após cada
autenticação. Essa avaliação coletará, estatisticamente, informações com o intuito
de integrar os usuários de sistemas aos diretórios LDAP. Para a realização dos
cálculos de autenticação em até cem mil usuários, será necessária a implementação
de outro algoritmo para a criação automática das contas.
A elaboração de um aplicativo demonstrativo que realizará a manutenção das contas

de usuários no diretório LDAP, porém, integrada com as permissões de acessos há
sistemas on-line, que conseqüentemente, após uma única autenticação,
disponibilizará as credenciais válidas (retornadas pelo serviço de diretórios), na qual
será a chave de acesso às informações do usuário de sistemas e também a
possibilidade de efetuar a mesma autenticação a quaisquer recursos de rede.
19
Agregar conhecimentos sobre os conceitos, tecnologias, métodos e técnicas de

autenticação dos usuários baseada em serviços de diretórios.
1.3 ESTRUTURA DO TRABALHO
Esse trabalho foi organizado em seis capítulos, da seguinte forma: o Capítulo 1

apresenta o esboço do que será apresentado, os interesses pela pesquisa,
juntamente com a idéia de centralização das contas de usuários com a criação de
uma árvore de diretórios. No Capítulo 2 explica-se alguns conceitos de serviços de
diretórios, o significado de LDAP, a história delimitando o protocolo que originou, a
forma que o mesmo se comunicava com o diretório X.500, a apresentação da pilha
de protocolos com a demonstração do local em que o LDAP atua, as versões, a
importância de se usar essa tecnologia, a apresentação da arquitetura, como
também todas as diretrizes que são utilizadas.
O Capítulo 3 descreve o protocolo LDAP, visto que opera quatro modelos básicos
com operações baseadas na comunicação entre cliente e servidor. Os aspectos
fundamentais para a segurança das informações, com a utilização de métodos de
autenticação e criptografia, bem como, o modelo de controle de acesso na qual,
restringe o tipo de acesso dos usuários e grupos. A otimização do LDAP a partir da
replicação e distribuição de diretórios, averiguando os pontos de falha e as maneiras
eficientes para a utilização do serviço de diretórios. O relato do padrão de código
aberto chamado OpenLDAP, na qual, traz este protocolo ao alcance dos usuários
Linux, ou mesmo, do desenvolvimento de sistemas para aplicações LDAP. E as
ferramentas que gerenciam as contas dos usuários contidas nos diretórios.
Após a apresentação de todo o conceito da tecnologia LDAP, no Capítulo 4 será

apresentado à depuração de todos os resultados da autenticação dos usuários, a fim
de calcular o tempo, em segundos, de identificação no diretório LDAP, aplicando
uma estatística para a análise de performance a fim de averiguar a possibilidade de
integração dos usuários de sistemas ao serviço de diretório.
Já no Capítulo 5, a criação de um aplicativo em Java para Web, que fará a

manutenção as contas dos usuários de sistemas, incluindo os mesmos no diretório
LDAP e atribuindo permissões de acesso há sistemas de software.
20
E por fim, as considerações finais, demonstrando os resultados da pesquisa,

vantagens e desvantagens, ou mesmo, a contribuição com outros pesquisadores.
21
2 CONCEITOS DE SERVIÇO DE DIRETÓRIOS
O serviço de diretórios relaciona-se a um conjunto de funções para criação,

armazenamento e recuperação de informações de um diretório.
Esse serviço, por muitos motivos, é um componente vital para o gerenciamento

integrado de identidades, o principal deles é a constituição da forma mais comum
para armazenamento e disponibilização das informações para os diversos sistemas
operacionais de rede (REINHART et. al., 2005).
2.1 O QUE É UM SERVIÇO DE DIRETÓRIOS?
O serviço de diretórios, de uma forma simples, é uma base de dados em que podem
ser armazenadas informações de usuários, na qual poderão ser recuperadas a
qualquer momento, assim como em SGBD (Sistema de Gerenciamento de Base de
Dados) convencional (Mysql, Postgresql, Oracle, Microsoft SQL Server e etc)
(SUNGAILA, 2007).
Os diretórios disponibilizam prontamente os dados solicitados com alta otimização

de leitura, a qual se cria uma estrutura em formato hierárquico de árvore
(semelhante ao modelo DNS – Domain Name System), de modo que dentro de cada
registro será armazenado um ramo específico da árvore. Para isso, foi criado um
padrão de diretórios globais, chamado DIT (Directory Information Tree), ou seja,
árvore de diretório que acessa as informações contidas nos diretórios de forma
hierárquica.
Com base numa empresa (raiz da DIT), podem ser criadas estruturas independentes
para cada departamento ou unidade (ramos da DIT). Tais informações apresentarão
um modelo distribuído para armazenamento em servidores diferentes.
Todos os dados armazenados em um diretório seguem uma forte padronização,

normalmente estabelecida em RFC (Request For Comments), ou mesmo, pedido de
comentários, contendo nomenclatura específica e tipos de dados de forma
consistente.
22
Optar pelo uso de um diretório, em alguns casos, torna-se uma tarefa difícil. Com
isso, para afirmar que uma base de dados terá desempenho mais adequado do que
um diretório para aplicação específica, envolve a análise de vários pontos, visto que
o SGBD contém estruturas muito similares à servidores de diretórios e compartilham
muitas características como pesquisa rápida e base de dados com fácil
personalização.
O volume de escrita dos servidores de diretórios geralmente não possui métodos

avançados que controle as transações ou esquemas de roll-back (comando que
desfaz a transação corrente, fazendo com que todas as modificações realizadas
pela transação sejam rejeitas). Isso ocasiona um baixo desempenho na escrita, na
qual está seu ponto fraco. Pois têm como base, que as informações dificilmente
serão alteradas.
A hierarquia denomina uma estrutura em forma de árvore do ponto de vista lógico

que distribui fisicamente em repositórios de diferentes servidores de diretórios, que
podem ser agrupados por departamentos, ou mesmo, por unidades geograficamente
distantes.
A descentralização possibilita a administração de parte do diretório (unidades ou

ramos) a outros usuários, sendo que os “ramos” podem estar localizados fisicamente
em outros servidores (SUNGAILA, 2007).
2.2 O QUE É LDAP?
O LDAP é um protocolo leve de acesso a diretórios que atua na camada de

aplicação da pilha de protocolos TCP/IP (Transmition Control Protocol / Internet
Protocol), nos padrões IETF (Internet Engineering Task Force) e OSI-DS (Open
Service Interface Definitions), como por exemplo, o SMTP (Simple Mail Transfer
Protocol), HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol), TELNET
(Tipos de Acesso na Internet) e tantos outros (BRESSAN, 2007).
2.3 HISTÓRIA DO LDAP
No início da década de 80, as duas instituições ISO (International Standardization

Organization) e CCITT (Consultative Committee for International Telegraphy and
23
Telephony), se uniram para desenvolver um serviço de mensagem. Entretanto,

houve necessidade em organizarem entradas num serviço de nomes de forma
hierárquica, que tivesse grande capacidade de armazenamento e pesquisa da
informação. Esse trabalho foi concluído no final da década de 80, recebendo o nome
de X.500, o qual especificava que a comunicação entre o cliente e o servidor de
diretório deveria utilizar o protocolo DAP (Directory Access Protocol), baseado no
modelo OSI (Open System Interconnection) (Figura 1) (BARTH, SIEWERT, 2006).
Figura 1. História do LDAP, estimada por (PAPOTTI et. al., 2006)
O DAP é um protocolo pesado, que roda sobre uma camada OSI completa, e
precisa de uma quantidade significante de recursos computacionais para ser
executado. Tendo isso em vista, pensou-se em criar um protocolo mais leve para
que também fosse utilizado em máquinas de menor poder computacional, em
desktops convencionais. Então foram desenvolvidos dois protocolos, o DAS
(Directory Assistance Service) e o DIXIE (Directory Interface to X.500 Implemented
Efficiently), que foram os predecessores do LDAP, mas que ainda eram muito
ligados ao X.500, já que precisavam de um servidor intermediário para efetuar a
“tradução” desses protocolos para o DAP, que se comunicaria com o diretório X.500
(Figura 2).
24
Figura 2. Utilizando DIXIE para se comunicar com diretórios X.500, estimada

por (PAPOTTI et. al., 2006)
O protocolo LDAP foi desenvolvido originalmente por três pesquisadores em 1993,

na universidade de Michigan, chamados Steve Killi, Tim Howes e Wengyik Yeong.
De acordo com o que foi comentado anteriormente, o LDAP funciona sobre o padrão
de diretórios X.500 melhorado, na qual foi uma tentativa bem sucedida de ser um
protocolo compatível com o DAP, que deu origem ao LDAP, proporcionando um
custo menor, além de utilizar pouco poder computacional. As razões da melhoria de
desempenho devem-se ao fato do LDAP não fazer uso do protocolo OSI, mas
construiu conexões diretas do cliente com o servidor de diretórios (SEZANOWITCH,
2006).
Devido a desenvolvimento do protocolo X.500, ter sido baseado no modelo OSI de

sete camadas de implementação de redes, determinou-se uma quantidade enorme
de informações e controles. Com isso, a implementação mostrava-se impraticável,
por que não conseguia ser utilizada com o modelo TCP/IP largamente adotado nas
redes de computadores. Por esse motivo, esse conjunto de regras, deu origem a
uma implementação mais simples, o LDAP.
O LDAP, inicialmente, era chamado de LDBP (Lightweight Directory Browsing

Protocol), no qual os acessos aos servidores de diretórios só permitiam a leitura de
dados. Com a evolução tecnológica, o LDBP além de passar a escrever e editar os
diretórios, ele manteve-se autonomamente, como um servidor que foi nomeado
25
como LDAP, tornando uma alternativa independente do DAP, que ainda era mantido
compatível e paralelamente ao serviço de diretórios (SEZANOWITCH, 2006).
2.4 ORIGEM DO LDAP
Esse protocolo originou-se como um meio de acesso a diretórios do tipo X.500, a

partir do serviço de diretório OSI. Inicialmente, os clientes LDAP acessavam
gateways para esse tipo de serviço. Esses gateways (também chamados de proxy
ou front-end) rodavam o LDAP entre o cliente e o gateway, já o DAP entre gateway e
o servidor X.500 (Figura 3) (MACHADO; MORIJR, 2006).
Figura 3. Modelo gateway LDAP/DAP, estimada por (MACHADO; MORIJR, 2006)
A partir daí, como foi citado anteriormente, o LDAP não precisa rodar na pilha de
sete camadas OSI, como o protocolo de camada de aplicação X.500. Os pacotes
X.500 carregam mais bagagem, pois precisam de cabeçalho para cada uma das
camadas da pilha de protocolos OSI. A suíte de protocolos TCP/IP, na qual o LDAP
roda, também necessita de cabeçalho nos pacotes, mas tem um overhear (escutar
algo sem que os outros saibam, ouvir por acaso) menor (MACHADO; MORIJR, 2006).
2.4.1 Diretório X.500
O diretório X.500 caracteriza-se em conexões de serviços de diretórios locais, a fim

de formar um diretório global distribuído, parte do diretório fica global e suas
informações são disponibilizadas através de um agente do sistema de diretórios e
trabalha com funções de gerenciamento, isto é, adição, modificação e deleção de
entradas (PAPOTTI et. al., 2006).
26
2.4.2 Cliente do X.500
O LDAP foi desenvolvido para ser um cliente para o X.500 (Serviço de Diretório
OSI), que define o DAP para os clientes usarem quando estiverem em contato com
servidores de diretório (Figura 3) (PAPOTTI et. al., 2006).
Figura 4. Cliente do X.500, estimada por (PAPOTTI et. al., 2006)
2.4.3 DAP
Comentado anteriormente, o DAP era um protocolo de acesso a diretórios, da

camada de aplicação, difícil de trabalhar e implementar, visto que os protocolos mais
fáceis foram desenvolvidos com a maior parte de sua funcionalidade, mas com
menor complexidade (Figura 5) (PAPOTTI et. al., 2006).
Figura 5. DAP (Directory Access Protocol), adaptada por (PAPOTTI et. al., 2006)
2.4.4 Pilha de Protocolos
No modelo de referência OSI, os dados descem a pilha de protocolos para chegar à

rede e sobem para chegar às aplicações. Cada camada da pilha de protocolos
adiciona um cabeçalho com informações de controle e trata o que recebe da
camada superior com dados. Esta adição de informações de controle em cada nível
é denominada encapsulamento. No entanto, sendo o DAP um protocolo da camada
27
de aplicação, usá-lo implicava suportar toda a pilha de protolocos desse modelo

(Figura 6) (LEITE, 2008).
A Internet (que entretanto adotava definitivamente o TCP/IP), não estava

preocupada, pois não queria perder o mercado dos computatores menos poderosos,
com recursos insuficientes para suportar o modelo OSI. Com isso, o protocolo LDAP
atua diretamente sobre o TCP/IP, porém não requer hardware pesado para
operações (LEITE, 2008).
Figura 6. Pilha de Protocolos, estimada por (LEITE, 2008)
2.4.5 Versões
O LDAP influenciou protocolos de Internet subseqüentes, incluindo versões

posteriores do X.500, DSML (Directory Services Markup Language), SPML (Service
Provisioning Markup Language) e o SLP (Service Location Protocol).
A primeira versão foi publicada como a RFC 1487 em 1993, mas o LDAP ganhou
uso somente em 1996, na segunda versão (LDAP v2), especificada na RFC 1777,
na qual, existiam autenticações fortes com o Kerberos v4 e v5.
Em 1997, publicou-se a terceira e última versão, na RFC 3377, que foi desenvolvida
para solucionar uma série de limitações existentes na anterior, a qual inclui aspectos
de segurança, que passa a suportar protocolos de autenticação forte, como o SASL
(Simple Authentication Security Layer) e o SSL (Secure Sockets Layer) / TLS
(Transport Layer Security) (Figura 1) (PAPOTTI et. al., 2006).
28
2.5 POR QUE USAR LDAP?
O LDAP é otimizado para fazer pesquisas de informações, na qual centralizam todas

elas a fim de disponibilizar enormes benefícios, tais como um único ponto de
administração, como também, reduz os dados duplicados. Possui mecanismos de
replicação incluída (slurpd) e de segurança tanto para autenticação (SASL) como
para a troca de dados (SSL/TLS) (CARTER, 2003).
Porém, em alguns casos não substitui as bases de dados relacionais, raramente são
efetuadas atualizações, apenas convém guardar os dados estáticos. Obviamente
não é possível relacionar dois atributos, visto que não se trata de uma base de
dados relacional, mas sim de uma base de dados estruturada hierarquicamente.
Exemplo: “Não é possível relacionar o código de uma disciplina com o nome da
mesma” (CARTER, 2003).
Em algumas aplicações que o LDAP exerce, se conscientiza em SSO (Single Sing

On), ou seja, autenticação única que facilita a integração com outros serviços, como
por exemplo, servidor de arquivos, de proxy, de domínio, de impressão, de e-mail,
entre outros. Sendo assim, o usuário tem apenas um “uid” (identificador do usuário)
(Figura 8), e uma senha para acessar os diversos recursos da rede e não mais para
cada serviço que queria utilizar (Figura 7).
Figura 7. Arquitetura LDAP (http://www.ldap.org.br)

29
2.6 DIRETÓRIO LDAP
O modelo de serviço do diretório LDAP é baseado em entradas. Uma entrada é um

conjunto de atributos e é referenciada através de um nome distinto – DN
(Distinguished Name). Porém, é usado para referenciar uma entrada de forma não
ambígua. Cada um dos atributos de entrada tem um tipo, e um ou mais valores
chamados de objetos. Estes tipos geralmente são palavras mnemônicas, como CN
(common name). (Figura 8) (KELLERMANN, SILVELLO, 2001).
Figura 8. Representação de parte de um Diretório LDAP
2.7 SCHEMA
Os schemas permitem manter a consistência dos dados de um diretório, é

extensível, ou seja, trabalham com a herança e permitem adicionar mais atributos e
classes de acordo com as necessidades. Porém, eles definem a classe de objeto, os
atributos e seus possíveis valores, que podem ser inseridos em um diretório
(SUNGAILA, 2007).
Se uma entrada, que é tratada como um objeto, não obedecer às regras do schema,
este não poderá ser inserido.
30
2.8 DISTINGUISHED NAMES (DN)
O DN é utilizado para identificar e diferenciar uma entrada para não gerar

informações repetidas em um serviço de diretórios, ou seja, esta entrada vai ser
única e não haverá outra entrada com o mesmo nome. São compostos por uma
seqüência de RDN (Relative Distinguished Name), sendo que, cada seqüência é um
ramo da DIT, desde a raiz até o objeto ao qual o DN faz referência (Figura 9)
(PAPOTTI et. al., 2006).
Figura 9. RDNs idênticos
Um DN é formado por uma seqüência de RDN’s separados por vírgulas (Figura 10).
Figura 10. DN é uma seqüência de RDN’s
2.9 O QUE É LDIF?
O LDIF (LDAP Data Interchange Format) é a troca de dados entre diferentes

formatos que se baseia em um formato de texto padrão, utilizado para descrever
diretórios, tendo a sua estrutura definida pela RFC 2849 (CARTER, 2003).
Os arquivos LDIF permitem a importação, exportação e backup dos dados de um

servidor de diretório para o outro, sem que os mesmos utilizem uma mesma base de
dados. Com esse padrão, para distribuir as informações entre eles, é possível utilizar
31
somente comandos padronizados, como por exemplo, adição, modificação, deleção

e etc.
Atualmente existem dois tipos de arquivos LDIF. Um deles descreve um conjunto de

entradas de diretórios, que serve para agregar diretamente a um diretório, enquanto
que o outro tipo contém uma série de comandos de atualização que descrevem as
mudanças que devem ser aplicadas aos atributos de entradas de um diretório.
2.10 OBJECT IDENTIFIER (OID)
Cada classe de objeto, ou tipo de atributo, é identificada de forma sintática, isto quer
dizer que o OID (Object Identifier) é único em toda a estrutura de diretórios do LDAP.
Isso é representado, por números decimais separados por pontos, dando origem a
uma árvore hierárquica, ou mesmo, a uma DIT, propriamente dita (SUNGAILA, 2007).
A IANA (Internet Assigned Number Authority) é a entidade responsável pelo registro

de “sub-árvores” de OID’s (Tabela 1).
OID Utilização
1.1 Organizações OID
1.1.1 Elementos SNMP
1.1.2 Elementos LDAP
1.1.2.1 Tipos de atributos
1.1.2.1.1 Meus atributos
1.1.2.2 Classes de objetos
1.1.2.2.1 Minhas classes de
objetos
Tabela 1. Alguns exemplos de Object Identifier
2.11 ATRIBUTOS
São identificados por um nome ou abreviatura que possui um único tipo com um ou
mais valores, sendo o tipo associado a uma sintaxe que define o tipo de valor que
pode ser armazenados no atributo (Tabela 2) (SUNGAILA, 2007).
32
Abreviatura Nome do atributo por

extenso
dn distinguished name
cn commom name
sn surname
gn given name
o organization name
ou organization unit name
st state or province name
l Locality name
c country
jpegPhoto Fotografia e formato jpeg
telephoneNumber Número telefônico
postalCode código postal
dc domain component
uid id de usuário
Tabela 2. Algumas abreviaturas de atributos, com seus respectivos nomes
2.12 ENTRADA
É um unidade básica de informações armazenadas em um diretório que é composta

por um conjunto de atributos que referenciam objetos que são organizados conforme
uma DIT. Porém, como foi citado acima, existem arquivos texto, do tipo LDIF, que
são utilizados para importar, exportar e realizar backup’s de dados dos diretórios,
onde podem ser adicionadas várias entradas em somente um arquivo (Figura11)
(PAPOTTI et. al., 2006).
Figura 11. Exemplo de entradas em um arquivo LDIF

33
2.13 OBJECT CLASS
É um conjunto de atributos referentes a uma entrada, sempre que uma entrada é

definida, é atribuído uma ou mais classes e estes atributos podem ser opcionais ou
obrigatórios.
Existem três tipos de classes de objetos, as estruturais, as auxiliares e as abstratas,

nas quais, todas as entradas devem ter no mínimo uma classe de objeto estrutural e
pode ter uma ou mais auxiliares. A abstrata possui uma especificação parcial da
hierarquia de uma classe de objetos, visto que apenas subclasses estruturais ou
auxiliares permitem esta classe de objetos. Um exemplo tirado do core.schema, a
classe de objeto “person” (Figura 12), mostra os campos obrigatórios que são o “sn”
e “cn” e os atributos opcionais: userPassword, telephoneNumber, seeAlso e
description (SUNGAILA, 2007).
Figura 12. Classe de objeto person, retirada do core.schema
A abordagem quantitativa se originou a alguns conceitos de serviço de diretórios

bem como, historia e origem do protocolo LDAP, delimitando toda a estrutura que
está relaciona a representação dos diretórios. A vantagem para a implantação dessa
tecnologia na questão da arquitetura LDAP, visando às fáceis manutenções e
consistência dos dados. O aspecto de identificar e diferenciar as entradas para não
gerar informações repetidas. A oportunidade de manutenção dos dados a partir de
um arquivo texto (LDIF). A identificação de forma sintática de uma entrada, na qual
designa que é o único em toda a estrutura de diretórios. As abreviaturas que são
associadas a uma sintaxe que define o tipo de valores que podem ser armazenados
no atributo e as restrições das entradas já existentes ou campos obrigatórios.
34
3 PROTOCOLO LDAP
O protocolo LDAP define operações para a realização de consultas e atualizações

de diretórios, na qual são fornecidas para adição, remoção e modificação de uma
entrada existente, ou mesmo, do nome dela.
Esse protocolo opera quatro tipos de modelos básicos, que podem ser armazenados
nos diretórios, bem como, a determinação de qual será o destino desses dados
(PAPOTTI et. al., 2006). Os modelos são:
• Modelo de Informação – define os tipos que podem ser armazenadas num

diretório LDAP. A unidade básica da informação armazenada no diretório é
chamada de entrada. Esse modelo herdado, quase sem alterações do X.500, é
extensível. Ao definir novos object classes, pode-se adicionar a um diretório
qualquer tipo de informação;
• Modelo de Nomes – este modelo define a forma como a informação no diretório

LDAP pode ser organizada e referenciada. As entradas são organizadas numa
DIT e divididas segundo uma distribuição geográfica e/ou organizacional. Cada
entrada tem um DN que especifica o caminho da raiz até a entrada;
• Modelo de Segurança – define quais procedimentos podem ser tomados para

evitar o acesso não autorizado às informações do diretório, como protocolos de
encriptação e autenticação;
• Modelo Funcional – descreve as operações que podem realizar-se no diretório

utilizando o protocolo LDAP;
3.1 OPERAÇÕES
As operações são baseadas na comunicação entre cliente e servidor LDAP,

restringindo o envio e retorno das informações. A operação do tipo busca, por
exemplo, pode abranger toda a árvore (uma busca com escopo da sub-árvore) ou
apenas um ramo, sem descer ou subir para os demais. Além de especificar com
filtros, quais entradas se desejam encontrar. É possível também, especificar quais
35
atributos desta entrada são procurados, porém se não forem especificados, todos
serão retornados (TEIXEIRA; MERCER, 2000).
Existem tipos de operações que podem ser utilizadas de acordo com a necessidade,
visto que depende do número de entradas e requisições, para uma ou várias
operações.
Um servidor LDAP, ao encontrar apenas um valor para a operação de busca

realizada, ele imediatamente retorna o mesmo. Na requisição, o cliente LDAP envia
uma identificação (ID) única, “msgid” (identificador de mensagens), ou seja, somente
uma informação que comprove a existência dele no diretório (PAPOTTI et. al.,
2006). Esse ID é usado nas repostas para identificar as mensagens (Figura 13).
Figura 13. Recebimento de uma única entrada, estimada por PAPOTTI et. al.
(2006)
Todavia, se o servidor encontrar diversos valores, os mesmos serão retornados em

mensagens separadas (PAPOTTI et. al., 2006) (Figura 14). Para cada entrada
retornada, existe um único nome, que é identificado como DN.
Figura 14. Recebimento de várias entradas, estimada por PAPOTTI et. al. (2006)
Como o LDAP é orientado a mensagem, é possível realizar diversas operações ao

mesmo tempo (Figura 15). Isto torna o protocolo mais flexível e eficiente, pois não
36
há a necessidade de esperar uma resposta do servidor antes de esperar outra

operação, como no HTTP (PAPOTTI et. al., 2006).
Figura 15. Uma simples pesquisa no LDAP, estimada por PAPOTTI et. al. (2006)
Note que o cliente envia outra solicitação sem aguardar pela finalização da primeira
solicitação, com isso, não ocasionará nenhum problema, pois todas as mensagens
são identificadas, tornando o protocolo LDAP mais ágil na pesquisa das
informações, visto que uma mesma conexão aberta pode-se realizar várias
consultas ao invés de abrir uma conexão a todo instante (PAPOTTI et. al., 2006).
O LDAP é dividido em três tipos de operações: operação de pergunta, de

atualização e de autenticação e controle (BAPTISTA, Miguel; DOMINGUES, M., 2005).
1) Operações de pergunta
a) ldapsearch - faz pesquisas das entradas no diretório;
b) ldapcompare - verifica se uma entrada contém um dado valor num atributo;
2) Operações de atualização
a) ldapadd - adiciona uma nova entrada;
b) ldapdelete – apaga uma entrada existente;
c) ldapmodify - altera uma entrada existente;
d) ldapmodrdn - renomeia uma entrada existente (modificar o RDN);
3) Operações de autenticação e controle
a) ldapbind - cliente se autentica com o servidor;
b) ldapunbind - cliente encerra sessão com o servidor;
c) ldapabandon - cliente não está mais interessado nas respostas da requisição

anteriormente enviada;
37
O cliente abre uma conexão com o servidor LDAP e envia uma operação “ldapbind”.
Esta operação inclui o nome da entrada do diretório com a qual ele deseja
autenticar-se, seguido das credenciais que serão usadas na autenticação (PAPOTTI
et. al., 2006). As credenciais podem ser simples senhas ou até mesmo digitais.
Após o servidor conferir se as credenciais são válidas, ele retorna uma mensagem
de sucesso ao cliente, que posteriormente, enviará uma operação “ldapsearch”, visto
que o servidor realizará a operação e retornará as duas entradas encontradas para o
pedido (PAPOTTI et. al., 2006).
Porém, o servidor enviará uma mensagem com o resultado total. Com isso, o cliente
envia uma operação “ldapunbind”, indicando que o cliente deseja desconectar-se, e
por fim, o servidor obedecerá, terminando a conexão (PAPOTTI et. al., 2006) (Figura
16).
Figura 16. Estabelecimento de conexão, consultas e fechamento de uma

conexão LDAP, estimada por PAPOTTI et. al. (2006)
3.2 SEGURANÇA
Um dos aspectos fundamentais do serviço de diretórios LDAP é segurança das

informações armazenadas no servidor LDAP. De acordo com o modelo de
segurança, são definidos, quais os procedimentos que devem ser tomados para
evitar o acesso não autorizado às informações dos diretórios, como protocolos de
autenticação e encriptação (PAPOTTI et. al., 2006).
Na atual versão do LDAP (LDAPv3), que trata a autenticação baseada nos modos
de como os servidores são acessados. Com isso, utilizam-se frameworks SASL,
bem como, múltiplos mecanismos de autenticação (SUNGAILA, 2007).
38
3.2.1 Métodos de Autenticação
A terceira e última versão do LDAP (LDAPv3), possuí métodos de autenticação que

foram definidos na RFC 2829 (Authentication Methods for LDAP) (SUNGAILA,
2007). Nessa RFC, os servidores LDAP foram classificados em três grupos:
1) Públicos para somente-leitura, na qual permitem “login” anônimos, ou seja, sem

que o usuário informe a senha.
2) Com autenticação usando senhas e mecanismo SASL DIGEST-MD5 (RFC 2831

– Using Digest Authentication as a SASL Mechanism).
3) Autenticação e criptografia de dados, utilizando StartTLS (RFC 2830 LDAPv3:

Extension for Transport Layer Security) para camada de transporte segura e
certificados com chaves públicas para autenticação de ambos os lados.
As interfaces de gerenciamento, em padrão UNIX (inclui Linux também) e Samba

(para autenticar estações Windows), por exemplo, das contas de usuários são
realizadas nos arquivos passwd e shadow. O processo de autenticação é realizado
com o usuário digitando o login e a senha de acesso, ao passo que o sistema efetua
a checagem da senha fornecida corresponde à oficial criptografada que é
armazenada no arquivo-texto (/etc/passwd). Esse processo baseia-se no conceito de
que o usuário é realmente o solicitado, e a senha de acesso está correta. Para que
esse processo funcione adequadamente, foram desenvolvidas aplicações, levando
em consideração estes procedimentos (login, ftpd etc) (SUNGAILA, 2007).
Desde então, vários métodos de autenticação têm sido criados, desenvolvidos,

testados e colocados em produção, incluindo mecanismos complicados de
substituição do passwd, dispositivos de hardware como o Smart Cards e outros. O
problema gerado com isto é que, a cada novo esquema de autenticação
apresentado, todos os aplicativos envolvidos em autenticação de usuários, devem
ser reescritos para suportá-los (SUNGAILA, 2007).
A partir desse contexto, pode-se utilizar o PAM (Pluggable Authentication Modules)

que equivale a dizer que é um método flexível de checagem de itens de segurança
quando um usuário efetua logon.
39
O PAM foi criado pela Sun Microsystems para oferecer um método de desenvolver
aplicações que sejam independentes do mecanismo de autenticação em uso. Estas
aplicações passam a solicitar ao PAM que o usuário seja autenticado. Este, por sua
vez, utiliza o módulo de autenticação definido pelo administrador local, durante a
fase de configuração do equipamento, e é totalmente transparente para as
aplicações (o login é uma destas) (CERQUEIRA, 2005). Todas as aplicações do PAM
foram publicadas pela Sun no formato de RFC, na qual o Linux baseia-se para a
utilização.
Os módulos de autenticação PAM foram divididos em quatro categorias distintas

(SUNGAILA, 2007), definindo os tipos disponíveis:
• auth – faz a validação do usuário, verificando a identidade por várias maneiras:

checando usuário e senha, método mais simples e mais usual, utilizando a
verificação biométrica como impressão digital, timbre voz ou imagem da retina.
Pode ainda limitar o número de usuários ou restringir o acesso do root em algum
serviço.
• account - verifica se o usuário pode utilizar o serviço na qual está tentando

autenticação, checando o horário da conexão, o grupo do usuário, o dia da
semana, o IP (Internet Protocol) de origem ou ainda o número de logins
simultâneos.
• passwd – entra em funcionamento durante o processo de troca de senhas dos

usuários. Módulos deste tipo incluem a cracklib que checa se a senha do usuário
é fraca ou se pertence a algum dicionário conhecido, melhorando a segurança
das senhas.
• session – cria o ambiente do usuário, habilitando dispositivos de hardware aos

quais o usuário tenha direito de acesso, como cdrom, placas de áudio e outros,
mapeia sistemas de arquivos remotos, efetua registros em log, além de criar
recursos como o diretório pessoal do usuário caso este não exista. Porém,
determina o que será necessário para que o usuário se conecte.
De forma ampla, o PAM é um conjunto de bibliotecas fornecido com a maioria das

distribuições Linux moderno e é instalado por padrão no RedHat Linux. As
bibliotecas do PAM fornecem uma interface consistente a um protocolo de
autenticação. Uma aplicação pode usar essas bibliotecas para permitir o uso de
40
qualquer protocolo de autenticação dentro da aplicação. Assim, se o administrador

de sistema mudar, por exemplo, a autenticação de /etc/passwd para o LDAP, a
aplicação não precisa ser reescrita ou recompilada (CERQUEIRA, 2005). Exige-se um
módulo para cada 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 checagem se um usuário entrou com a
senha correta, um sistema Linux precisa de outras informações, como o ID numérico
do usuário, o diretório, o shell padrão e etc. Esta informação, normalmente é
armazenada no arquivo /etc/passwd, pode ser determinada através de uma interface
de sistema conhecida como NSS (Name Service Switch) (CERQUEIRA, 2005).
3.2.2 Métodos de Criptografia
Uma forma de manter a confidencialidade dos dados é através da criptografia. Ela

fornece técnicas que permitem a codificação e decodificação dos dados, onde os
mesmos podem ser transmitidos e armazenados sem que haja alterações ou a
exposição à entidade não autorizada. O objetivo da criptografia é prover uma
comunicação segura, garantindo aos serviços a confidencialidade, autenticidade e
integridade.
A criptografia de chave pública e implementações dentro de um servidor LDAP

baseado num sistema de segurança, tem sido possível devido às redes e protocolos
de aplicações serem padronizados. Os protocolos mais importantes são SSL e TLS.
O SSL/ TLS (última versão do SSL) é um sistema aberto, protocolo não proprietário
desenvolvido pela Netscape para prover segurança durante as comunicações
sensíveis. Este é aceito pelo padrão WEB para a comunicação entre cliente-servidor
criptografada e autenticada, podendo rodar em baixo dos protocolos de aplicação
HTTP, SNMP, FTP, LDAP e Telnet [Baltimore] (COUTINHO; MSILVA, 2006). Este é
seguro, rápido e facilmente adaptado a outros protocolos WEB (Figura 17).
41
Figura 17. LDAP usando SASL com SSL/TLS, retirado do (BRANCO, 2004)
O TLS é um padrão do IETF, proposto pela Microsoft, que é definido como um

protocolo que fornece privacidade de comunicação e segurança entre duas
aplicações que comunicam-se através de uma rede. O TLS fornece um canal seguro
através da encriptação da comunicação e permite aos clientes autenticarem-se nos
servidores ou, opcionalmente, que os servidores autentiquem os clientes (KANIES,
2001).
Os clientes que usam TLS na comunicação, as mensagens não serão decifradas

caso sejam capturadas e nem alteradas (homem do meio), bem como, podem
autenticar o servidor e verificar a autenticidade de servidores nos quais ele já está
conectado, usando certificados com chaves públicas (KANIES, 2001).
Conforme foi citado anteriormente, o NSS é uma interface de sistema, que pode
guardar as informações do usuário, na qual, delimita um conjunto de bibliotecas
designadas para o suporte de desenvolvimento de uma plataforma de segurança –
aplicações de servidores e clientes habilitados. A construção de aplicações com
NSS podem suportar certificados de SSL v2 e v3, TLS e outros padrões de
segurança (SUNGAILA, 2007).
3.2.3 Modelo de Controle de Acesso
O modelo define os direitos de acesso as informações do diretório para cada usuário

ou grupo, como por exemplo, somente leitura de nomes para usuário administrador,
alteração de descrição para todos os usuários e leitura de informações básicas do
diretório para usuário anônimo (SUNGAILA, 2007).
42
Porém, esse controle de acesso não foi padronizado pela IETF (PAPOTTI et. al.,
2006), por que ainda está sendo definido um padrão. Cada fabricante tem um
padrão distinto, com muito trabalho de migração, visto que às vezes é necessária a
mudança de fabricante.
3.3 OTIMIZAÇÕES DO LDAP
Além de todas as otimizações de serviços de organização de informações, o LDAP

oferece também recursos para a replicação de dados em caso das mesmas serem
apagadas ou alteradas por intrusos. Um exemplo de um servidor para Linux que
auxilia o LDAP (mais precisamente o SLAPD – servidor que pode ser executado em
diversas plataformas), provendo a replicação do banco de dados é o SLURPD (um
daemon para ajudar o SLAPD a replicar seus serviços). O SLAPD e o SLURPD
comunicam-se através de um simples arquivo texto, ou seja, arquivo LDIF, que é
utilizado para registrar as mudanças (SUNGAILA, 2007).
Com isso, é utilizado um outro conceito, que é o de diretórios distribuídos,

juntamente com a replicação, a fim de diminuir os custos e também aumentar a
performace da busca de informação em formato de árvore distribuída.
3.3.1 Replicação do serviço de diretórios
Conceito de prover mecanismos de tolerância a falhas, a fim que manter o acesso

as informações dos usuários sempre íntegras.
A replicação de diretórios pode ocasionar pontos de falha quando muitos

computadores acessam somente um servidor (PAPOTTI et. al., 2006) (Figura 18).
43
Figura 18. Pontos de Falha da Replicação de Diretórios, estimada por

(PAPOTTI et. al., 2006)
Para solucionar tal problema, é necessário usar o conceito de diretórios replicados

para usar uma redundância quando for necessário (Figura 19).
Figura 19. Redundância de Diretórios, estimada por (PAPOTTI et. al., 2006)
Quando se tem uma falha no serviço, o outro servidor entra em operação de forma
automática (Figura 20).
44
Figura 20. Ponto de Falha e Troca de Servidor, estimada por (PAPOTTI et. al.,
2006)
Após falhas no serviço principal (Servidor A) a aplicação de diretório será habilitada,

de forma automática, uma replicação para outro serviço (Servidor B).
3.3.2 Diretórios distribuídos
A distribuição de diretórios visa à redução dos pontos de falhas, além de prover

menor consumo de banda e tempo quando uma consulta é realizada. O principal
benefício é a possibilidade de redução de custos com hardware.
Uns dos problemas abrangentes nos diretórios distribuídos são muitos

computadores acessando o local que reside à informação. Tempo elevado e
utilização do hardware para leitura (Figura 21).
45
Figura 21. Vários Clientes de Diretórios acessando somente um Servidor,

estimada por (PAPOTTI et. al., 2006)
Para a solução desse problema é necessário a utilização de vários computadores na

formação da árvore de diretórios, agregando os clientes em servidores replicados, a
fim de agilizar a busca e evitar a perda das informações (Figura 22).
Figura 22. Vários Clientes de Diretórios acessando Servidores Replicados,

estimada por (PAPOTTI et. al., 2006)
46
3.4 OPENLDAP
No inicio a maioria dos servidores LDAP eram comerciais, como o servidor de

diretórios da Netscape.
Segundo o SUNGAILA (2007), no mercado encontram-se algumas implementações

de serviços de diretórios, entre eles têm os de cunho comercial – IBM Tivoli Directory
Server, Microsoft ADS e Novel Directory, Netscape Directory Server e Sun Java
System Directory Server – e os de padrão aberto – OpenLDAP.
A primeira versão OSS era o servidor LDAP da Universidade de Michigan. Mas

eventualmente, o código da Universidade deixou de ser atualizado e no lugar dele
passou a ser utilizado o OpenLDAP que traz este protocolo ao alcance dos usuários
Linux , com o intuito de testar a versatilidade do LDAP com um código atualizado, ao
mesmo tempo que mantém compatibilidade de API (Application Programming
Interface) com outros programas (v. Capítulo 4). O OpenLDAP foi codificado para
ser escalável, fornecendo suporte para replicação de servidores, e uma escolha de
servidores de bancos de dados de backend (servidor que está rodando um serviço
de diretórios) (CARTER, 2003).
O 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 (SUNGAILA, 2007).
3.5 FERRAMENTAS PARA GERENCIAR UM SERVIDOR LDAP
Até o momento foi caracterizado o funcionamento, a arquitetura do servidor LDAP,

os conceitos que abrange essa tecnologia. Porém, existem ferramentas Open
Sources que são utilizadas no gerenciamento dos diretórios LDAP, tornando o
processo mais simples e eficiente (SUNGAILA, 2007).
Essas ferramentas podem ser com interface gráfica, bem como, módulo Web para
administração do servidor LDAP. A visualização é de forma hierárquica da árvore
LDAP, na qual são intuitivos e fáceis de serem configurados, e a cima de tudo,
livres, ou seja, gratuitos. A vantagem relaciona-se ao funcionamento para quaisquer
sistemas operacionais, e também pelo suporte internacional de oito idiomas.
47
Existem alguns programas aptos para gerenciar um servidor LDAP. As mais

indicadas pela versatilidade e desenvolvimento são GQ e Luma via interface gráfica
do Linux, com muitos recursos interessantes como inspeção de schemas
(SUNGAILA, 2007). O aplicativo GQ pode ser obtido no site: http://biot.com/gq, e o
Luma no http://luma.sourceforge.net.
Um dos aplicativos mais práticos para o visualização e gerenciamento das

informações dos diretórios é o acesso via Web chamado phpLDAPadmin , que pode
ser obtida no site oficial em http://www.phpldapadmin.com.
Um dos pontos fortes do phpLDAPadmin é a criação de uma série de objetos por

meio de opções predefinidas como, por exemplo, contas de usuários padrão POSIX
(Portable Operating System Interface) para estações Linux ou padrão Samba para
autenticação de uma rede Windows, criação de novas unidades organizacionais ou
grupos de usuários, além de uma série de objetos específicos para os diretórios. Por
último, permite a criação de entradas customizadas pelo usuário, de modo que,
pode-se escolher qual objectClass e quais atributos irão compor o registro
(SUNGAILA, 2007). Os conteúdos do diretórios expandem detalhes de toda a
estrutura da árvore (DIT), confome representado na Figura 23.
Figura 23. Detalhes da estrutura do diretório e tela de criação de novas

entradas no diretório usando phpLDAPadmin
48
Além dos aplicativos mencionados, pode-se contar com o LDAP Admin, que é uma
ferramenta gráfica que roda em estação Windows e pode ser obtida no site oficial
em http://ldapadmin.sourceforge.net. Este aplicativo é distribuído em dois pacotes:
um com os modelos de dados (templates) e outro com arquivo executável da
aplicação (SUNGAILA, 2007).
Após efetuar a conexão com o servidor LDAP através desse aplicativo, na Figura 24,
exibe a estrutura de diretórios.
Figura 24. Administração do diretório com LDAP Adm
O ponto forte desse aplicativo é a permissão da visualização de todos os atributos

que uma entrada suporta, ou mesmo, editá-las (Figura 25);
Figura 25. Edição avançada de atributos com o LDAP Admin
De acordo com os aplicativos demonstrados, para que os usuários tenham a

permissão de editarem as entradas dos diretórios é necessário que as bibliotecas de
49
autenticação (PAM e NSS) estejam configuradas. Se isso não ocorrer, o servidor

LDAP permitirá somente acessos anônimos, ou seja, somente leitura dos dados.
Diante de todo conceito do protocolo LDAP, o uso do serviço de diretórios

OpenLDAP é uma alternativa de integração, aplicável a sistema de software, e
segurança das contas de usuários a fim de realizar fáceis manutenções que distribui
os diretórios em forma hierárquica em árvore (DIT), com uma representação
geográfica facilitando a visualização e busca dos dados. A partir disso, a criptografia
e autenticação dos usuários foi uma maneira eficaz de garantir a segurança e busca
de informações, visto que, podem ser operadas por meio de aplicativos gratuitos
(PHPLdapAdmin, LDAPadmin, dentre outros).
Com a utilização da replicação e distribuição de diretórios, evitam-se as colisões e

tolerâncias de informações, demonstrando mais eficiência no acesso aos diretórios.
Na apresentação deste capítulo, demonstrou os modelos básicos de

armazenamento de diretórios, as operações baseadas na comunicação entre cliente
e servidor e a segurança para evitar os acessos não autorizados das informações
dos diretórios. E também os métodos de autenticação e criptografia, bem como, o
modelo de controle de acesso, visando às otimizações dos serviços de organização
das informações, como o mecanismo de tolerância de falhas (replicação dos
serviços de diretórios) e redução dos pontos de falhas (diretórios distribuídos). Logo
após, foi abordado o serviço de diretórios OpenLDAP e as ferramentas para
gerenciamento dos diretórios no servidor LDAP.
50
4 ARQUITETURA DE DIRETÓRIOS
A abordagem da arquitetura de diretórios visa algumas aplicações que o LDAP

exerce. Porém, a autenticação única facilita a integração com outros serviços por
meio de uma identificação e senha, na qual é possível acessar diversos recursos de
uma rede e não mais para cada serviço.
A partir desse conceito, a construção de uma arquitetura de diretórios da FEMA

(Fundação Educacional do Município de Assis), possibilitará a centralização da
autenticação dos usuários de sistemas, na qual tornará as consultas e
gerenciamentos mais eficientes. Todos os serviços fornecidos pelo provedor
FEMAnet (provedor da própria instituição), dentre eles (webMail, autenticação DNS,
FTP, Wireless e etc), servidores de intranet da FEMA (sistemas legados, aplicativos
web, Proxy, Samba e outros).
4.1 CONSIDERAÇÕES
Para averiguar se a arquitetura será eficiente para a autenticação dos usuários de

sistemas no diretório LDAP, serão realizados testes para avaliação de desempenho
em busca das identificações válidas no serviço de diretórios, proporcionando
expectativas para novas implementações.
A arquitetura de diretórios da FEMA, a ser demonstrada, está constituída de clientes

Windows e Linux, aplicativos em sistemas Web implementados na linguagem Java
e autenticação de usuários no Samba, dentre outros recursos de rede que
interceptam ao serviço de diretórios OpenLDAP (Figura 26).
51
Figura 26. Arquitetura da FEMA
Os testes a serem demonstrados e avaliados serão, somente, a partir do aplicativo

implementado na linguagem Java, de forma que o mesmo foi criado através da IDE
(Intelligent Drive Electronics ou também Integrated Drive Electronics) Netbeans
(versão 6.0). Para a construção de uma interface Web em JSP (Java Server Pages)
com a utilização de servlets para o processamento dos usuários a serem
autenticados, ou mesmo, inseridos ou removidos no diretório LDAP. Para que a
aplicação se comunique com os diretórios, foi utilizado uma API (Application
Programming Interface) Java chamada JNDI (Java Naming and Directory Interface),
que acessa serviço de diretórios OpenLDAP. Ela permite que aplicações descubram
e obtenham dados ou objetos através de um nome. Assim como todas as APIs
Java, ela é independente de plataforma. Adicionalmente, ela especifica uma
interface de serviço – SPI (Service Provider Interface), na qual permite que
softwares de serviço de diretório suportem o framework (PIRES, 2003).
A API JNDI acessam recursos externos, como base de dados, filas ou tópicos JMS
(Java Message Service) e componentes JEE (Java Enterprise Edition). A API
disponibiliza um mecanismo para ligar um objeto a um nome, bem como, uma
interface padronizada de busca de objetos no serviço de diretório, e uma outra, de
eventos que permite que um usuário saiba quando uma entrada (nome mais objeto)
foi modificada, e por fim, as extensões que suportam as capacidades do padrão
LDAP (PIRES, 2003).
52
Diante disso, a arquitetura definida conterá no serviço de diretórios OpenLDAP,

cinco grupos: Alunos, Professores, Funcionários, Visitantes e Externos (Figura 27).
Em cada grupo terá um número de usuários, conforme a quantidade referente à
instituição.
Figura 27. Estrutura de Diretórios da FEMA
A quantidade nem sempre será a mesma. Após a análise de performance,

constatará se a autenticação de usuários num diretório LDAP será eficiente, dentre
várias autenticações simultâneas, independente da quantidade de usuários contido
na estrutura de diretórios definida para esta avaliação.
4.2 AVALIAÇÃO DA AUTENTICAÇÃO DE USUÁRIOS
A abordagem quantitativa foi fundamentada na criação do aplicativo Java,

comentado anteriormente, com quatro tarefas divididas em duas fases, uma dessas
efetua a manutenção de usuários simples de um servidor LDAP, no aspecto de
criação e remoção das contas (tarefas) (Figura 30). Porém, as mesmas serão
criadas por loops (repetição de processo a partir de uma condição verdadeira)
contando de 1 a 1000 (para o primeiro teste), de 1 a 10000 (para o segundo teste) e
de 1 a 100000 (para o terceiro teste), dependendo da proporção estabelecida pelo
teste “x” (Figura 28). Essa proporção está relacionada a uma variável “x” que
designa a quantidade de usuários que existem ou não nos diretórios.
53
Figuras 28. Variáveis que determinam a quantidade de Usuários de acordo com

a Proporção
De acordo com a variável “x” (Proporção) demonstrada na Figura 28, se o mesmo

receber o valor igual a “1”, então será criado 1000 usuários subdivididos a partir da
multiplicação das constantes fixas na prototipação das variáveis de cada grupo. Por
exemplo, na grupo “Visitantes” conterá “7” usuários, devido a multiplicação da
proporção com o valor inteiro “7”. Assim será para 10000 usuários, com a proporção
igual a “10” e 100000 com o valor “x” referente a “100”.
Figura 29. Criação dos Usuários no Diretório LDAP, para cada Grupo,
dependendo da proporção
54
A classe que interage com o serviço de diretórios é chamada de “ClassLDAP”. Ela

foi criada, ou seja, estruturada para executar ações de autenticação e manutenção
dos usuários LDAP. Porém, após estância a mesma, o método construtor receberá a
identificação do usuário (uid), ou mesmo o login, na qual será a palavra “usuário”
sucedido do contador, já a senha será uma seqüência de caracteres, como por
exemplo, “J-%&i4/” (essa seqüência é mesma para todos os usuários) concatenada
com o mesmo contador. No entanto, a tarefa que insere, remove ou autentica os
usuários, serão a partir dos mesmos loops, mas é modificado somente o método que
corresponde à ação. Os códigos fontes estão apresentados no Anexo A.
Para a realização dos testes, foram estruturados os usuários dessa forma, para que
a base de dados ficasse completamente carregada de caracteres, simulando como
se fossem usuários comuns.
Figura 30. Manutenção das Contas de Usuários

55
A outra fase é constituída também de duas tarefas na qual determinarão os tempos

de resposta em segundos das autenticações simultâneas de usuários, baseadas nas
quantidades definidas acima. Os testes de autenticação foram realizados conforme a
abertura e fechamento da conexão com o servidor LDAP. A primeira tarefa constitui-
se em somente uma abertura e um fechamento da conexão, ou seja, abre a conexão
e autentica todos os usuários depois realiza o fechamento. Já a outra tarefa, a cada
autenticação, realizou-se a abertura e fechamento da conexão (Figura 31).
Figura 31. Forma A e B de Autenticações de Usuários
Após a criação das contas de usuários, referentes à quantidade foram realizados

cinco testes de autenticação de usuários com o intervalo de 20 minutos. A partir
disso, a cada teste foi estipulado tipos de conexão à Internet, como também, a
velocidade fornecida. Essas conexões foram: dial up (linha discada), wireless padrão
IEEE (Institute of Electrical and Electronics Engineers) 802.11bg (rádio digital), ADSL
(Asymmetric Digital Subscriber Line) e rede local, com velocidades variando de
56kbps a 100mbps.
56
Os testes práticos poderão ser visualizados no Anexo B com a representação das

autenticações com resultados do tempo de resposta no OutPut, ou seja, na saída da
IDE NetBeans.
Os resultados estão relacionados a uma tabela abaixo com as quantidades definidas

de usuários, os tipos de conexões e as duas formas de autenticações, sendo uma, a
autenticação com conexão aberta para todos os usuários e fechada no final do
processo (A), e a outra para cada usuário, fechando a cada autenticação (B)
(Tabela 3). Esses valores serão a média dos cinco testes, com uma margem
aproximada, em segundo.
Quantidade Tempo de Resposta em Segundos

de Dial Up Wireless ADSL Rede Local
Usuários (56kbps) (256kbps) (2MB) (100MB)
A 189 A 27 A 74 A 4
1 a 1000
B 828 B 178 B 241 B 33
A 1548 A 117 A 884 A 51
1 a 10000
B 67084 B 1191 B 3734 B 719
A 13312 A 1641 A 8011 A 673
1 a 100000
B 94142 B 14297 B 44808 B 7863
Tabela 3. Resultados do Tempo de Autenticações de Usuários
Esses resultados foram obtidos através de um Cliente (Windows) (local do aplicativo

Java) com o processador Core 2 Duo e 2G de memória RAM e um servidor LDAP
com um processador Pentium 1.8 e 256MB de RAM, contendo velocidade de
Internet de 512kbps. Mas, conforme citado em seções anteriores, a autenticação de
usuários num diretório LDAP, não exige poder computacional para a realização
dessas tarefas.
4.3 ESTATÍSTICA DA ESTRUTURA DE DIRETÓRIOS DA FEMA
A tabela demonstrada anteriormente comprova que o LDAP autentica cada um de

seus usuários em menos de 1 segundo. Mas, qual será a forma, ou seja, tipo de
conexão a Internet mais adequada para autenticar os usuários LDAP a fim de
integrar os mesmos às contas de sistemas?
Logo abaixo estão relacionados, estatisticamente, os resultados dos testes

alimentados na tabela acima (Figura 30).
57
Figura 32. Resultados em Segundos de duas formas de Autenticações de

Usuários para quatro tipo de conexões a Internet com três quantidades de
Usuários
A Figura 32 demonstra que a realização de autenticações de usuários LDAP é muito

eficiente, com isso nem sempre haverá perda de informações, visto que poderão
decorrer conforme a distância das informações, ou mesmo, pela escassez da
velocidade da conexão a Internet.
A autenticação com abertura e fechamento de conexões no servidor LDAP, somente

após todos os usuários serem identificados (A), foi fundamental, por que apresentou
um tempo de resposta muito rápido do que a abertura e fechamento para cada
autenticação (B).
Com isso, o LDAP além de centralizar as informações das contas de usuários, ele
disponibiliza prontamente, de forma rápida e concisa, a resposta das autenticações.
Neste capítulo foi apresentada a avaliação da autenticação dos usuários no diretório

LDAP, a partir de dois algoritmos estruturados de acordo com a abertura e
fechamento da conexão com o servidor LDAP, a fim de realizar seqüencialmente a
autenticação em até cem mil usuários, através de quatro conexões a Internet. E o
intuito desses testes estava relacionados numa alternativa de implementação das
funcionalidades de uma integração do serviço de diretórios a sistema de software.
58
5 APLICATIVO DEMONSTRATIVO
O aplicativo a ser demonstrado está relacionado à manutenção das contas de

usuários de sistemas, integrada a serviço de diretórios OpenLDAP, com o intuito de
centralizar as informações dos mesmos, para que os sistemas e outros recursos de
rede, possam utilizar as mesmas credenciais para validar na autenticação.
Com relação à arquitetura definida para a FEMA, citadas no Capítulo 4, os

processos de autenticação dos usuários são de informações desencontradas, devido
cada um dos serviços possuírem maneiras diferentes para controle de acesso.
No laboratório de informática da instituição, atualmente estão disponíveis aos

usuários, um servidor Samba para a liberação de espaços no disco rígido do mesmo
para armazenamento de arquivos, e um servidor Proxy para controlar os acessos
não autorizados, a sites restritos, pela instituição. E para a informatização dos
processos da instituição, existem aplicativos Web que disponibilizam informações
relacionadas, principalmente, a professores, alunos e funcionários, as quais são
apresentadas as notas e faltas dos alunos, planejamento de aulas dos professores,
requisições de equipamentos para setores, entre outras funcionalidades. E também
os serviços oferecidos pelo provedor FEMAnet (provedor da instituição), as quais
podem ser controlados por um único usuários (Figura 33).
Para a unificação desses processos, motivaram-se a idéia da centralização das

informações dos usuários para facilitar a manutenção das contas, devido os
métodos de autenticações serem de maneiras diferenciadas, por causa dos
diferentes bancos de dados.
E com o aproveitamento desse conceito de integração, no aplicativo demonstrativo

serão efetuadas permissões de ação dos eventos aos grupos e usuários (acessar,
incluir, excluir e alterar) a fim de que os aplicativos e os recursos de rede utilizem as
mesmas informações dos usuários e que possam restringir as permissões de acesso
aos eventos dos sistemas de software.
59
Figura 33. Integração dos Usuários de Sistemas ao Serviço de Diretórios

OpenLDAP
As manutenções serão realizadas pelo usuário administrador do LDAP, devido o

mesmo conter as permissões de toda estrutura de diretórios, a fim de realizar a
iteração, com os diretórios, no aspecto de criação e remoção dos grupos
(Organization Units - ou) e usuários (User Identification - uid).
Para o acesso ao aplicativo demonstrativo, após a autenticação válida no diretório

LDAP, o DN do usuário irá para a session do servidor Web, a fim de restringir os
acessos não autorizados, bem como, a busca das permissões de ação do usuário
que acessou ao sistema.
Todos os usuários que pertencem às unidades organizacionais (ou), ou seja,

membros de grupos, só terão acesso a uma página que contem os informativos
atribuídos pelo usuário administrador do LDAP, visto que os usuários simples
visualizarão e acessarão somente as informações relacionadas a cada um deles.
5.1 CONSIDERAÇÕES
O aplicativo demonstrativo foi implementado com as mesmas considerações, de

linguagem de programação e componentes de acesso aos diretórios, utilizadas no
aplicativo de avaliação da autenticação, relatado no Capítulo 4. Porém, foi
60
implantado também, à tecnologia AJAX (Asynchronous Javascript And XML) para

processar somente as informações necessárias e permanecer as que ainda serão
utilizadas na página, a fim de tornarem-se as pesquisas mais rápidas. O AJAX é
uma ferramenta que faz analogia a requisição de javascript e XML (Extensible
Markup Language) assíncrona.
Foi utilizado o modelo de padrão de projetos MVC (Model View Controller), que tem
por objetivo básico separar a lógica de negócio da apresentação. O modelo MVC é
subdividido em três camadas físicas, delimitando o modelo, a visão e o controle, na
qual fornece uma maneira de dividir a funcionalidade envolvida na manutenção e
apresentação dos dados de uma aplicação. Na arquitetura MVC o modelo
representa os dados da aplicação e as regras do negócio que governam o acesso e
a modificação dos dados. O modelo mantém o estado persistente do negócio e
fornece ao controlador a capacidade de acessar as funcionalidades da aplicação
encapsuladas pelo próprio modelo. A visão está relacionada a tela que iterage com o
usuário (MACORATTI, 2005).
5.2 MODELAGEM E APRESENTAÇÃO DO APLICATIVO
O aplicativo foi modelado por uma linguagem chamada UML (Unified Modeling
Language), na qual não é proprietária de terceira geração, e basicamente, permite
que desenvolvedores visualizem os produtos do trabalho em diagramas
padronizados. Junto com uma notação gráfica, a UML também especifica
significados, isto é, semântica. É uma notação independente de processos (SILVA,
2001).
O JUDE (Java and UML Developers Environment) é uma IDE que foi utilizada para a
modelagem dos dados (UML) criada com Java. Com o IDE JUDE é possível realizar
uma modelagem de dados complexa, na qual apresenta os dados para o usuário de
forma clara e ainda possível a vantagem do layout ser bem intuitivo (CAMPOS, 2006).
Alguns diagramas desenvolvidos nessa IDE, poderão ser visualizados nos Anexos C
e D.
Para a apresentação dos dados no aplicativo demonstrativo foi utilizado o banco de

dados PostegreSQL 8.2, devido o mesmo ser gratuito e demonstrar fácil implantação
61
com a linguagem Java, a partir de uma biblioteca de comunicação disponibilizada

pelo mesmo.
A representação do modelo de negócio está relacionada com as funcionalidades de

o usuário administrador do LDAP, cadastrar um grupo ou usuário e interagir com o
diretório LDAP (Figura 34).
Figura 34. Caso de Uso do Modelo de Negócio

62
O modelo de classes são as apresentações das classes, juntamente com os

relacionamentos dos atributos e o campo “id_ldap” que guardará a identificação que
representa o usuário após a autenticação no diretório LDAP (Figura 35).
Figura 35. Diagrama de Classes Beans e LDAP

63
O levantamento dos dados foi realizado com a criação de cinco tabelas, que são
elas: usuários, grupos, grupos/Usuários, eventos e permissões, nas quais foram
apresentadas na Figura 35.
A identificação das permissões após a autenticação será comparada com o atributo

chamado “id_ldap” da tabela de usuários, a fim de verificar as permissões de ação
aos sistemas de software.
Para realizar a autenticação do usuário é necessário que o mesmo informe o login e

senha e logo após o grupo que ele o pertence, já o usuário administrador do LDAP,
não é necessário informar o grupo (Figura 36).
Figura 36. Página de Autenticação dos Usuários para efetuar o acesso ao

Aplicativo Demonstrativo
Após a validação da autenticação, será verificada primeiramente, a existência do

solicitante no diretório LDAP, logo em seguida, a possibilidade do mesmo ser o
administrador ou o usuário que pertence às unidades organizacionais.
64
Ao acaso do usuário ser o administrador, o mesmo acessará todas as

funcionalidades do aplicativo demonstrativo, a qual atribuirá as permissões aos
grupos e usuários (Figura 37).
Figura 37. Aplicativo Demonstrativo
Mas, se não for o administrador, será acessado somente uma página em que terá as
informações relacionadas ao usuário que autenticou no sistema (Figura 38).
65
Figura 38. Permissões de Ação do Usuário Simples que acessou ao Aplicativo

Demonstrativo
Levando em considerações a manutenção das contas dos usuários de sistemas.

Após o administrador do LDAP, excluir um grupo ou um usuário será eliminado
todas as informações que estão relacionadas, até então no serviço de diretórios. As
demais páginas receberão os mesmos conceitos e só não irão interagir com o
serviço OpenLDAP.
66
6 CONCLUSÕES
Os conceitos retirados das pesquisas elaboradas demonstraram uma maneira eficaz

de visualização das informações dos usuários (DIT). Com a unificação das contas,
facilitou as manutenções dos usuários, devido os mesmos estarem centralizados, e
aparentemente, separados pelas unidades organizacionais (ou), delimitando o tipo
do usuário.
Com as autenticações também centralizadas, facilitaram os acessos a quaisquer

recursos de rede e aplicativos, que comunicam com o serviço de diretórios, a fim de
utilizar, do usuário, as mesmas credenciais válidas para autenticação.
A grande vantagem na utilização dessa tecnologia é por atuar diretamente na

camada TCP/IP e não utilizar os poderes computacionais para validar a
autenticação. Isso quer dizer, que o LDAP é uma alternativa de implementação das
funcionalidades das autenticações de usuários de sistema, sem incriminar as
autenticações realizadas nos bancos de dados do SGBD. Porque as pesquisas
foram relacionadas somente na centralização e integração das contas dos usuários
de sistemas, para a diminuição de custos nas manutenções. E os testes de
autenticação foram para determinar uma possível integração dos usuários e grupos
de sistemas aos serviços de diretórios.
Para a instalação do sistema operacional Linux, serviço de diretórios OpenLDAP e

bibliotecas de autenticação (PAM e NSS) não há custos, devido essas tecnologias
serem gratuitas. A partir disso, além do LDAP proporcionar todas essas facilidades
de integração, o mesmo também mostra que não há custos de implantações.
Estatisticamente, os resultados obtidos na avaliação da autenticação dos usuários

no diretório LDAP demonstraram-se ágil e dinâmico em realizar uma possível
integração da manutenção dos usuários LDAP aos sistemas de software. Esses
testes demonstraram que o LDAP, além de centralizar as informações dos usuários,
ele também disponibilizar as autenticações válidas de forma rápida e concisa, devido
ele autenticar cada um dos usuários em menos de um segundo.
No aplicativo demonstrativo, o LDAP se apresentou ativamente compatível com

linguagem Java, na qual não houve dificuldades na implementação. Para ter certeza,
67
se os usuários e grupos estavam sendo inseridos, ou mesmo, removidos, foram

utilizados os gerenciadores de diretórios: phpLDAPadmin (gerenciador web) e
LDAPAdmin (gerenciador Desktop), para os dados serem visualizados de forma
clara e organizada.
Com todas as considerações demonstradas, o LDAP abrange perspectivas de

contribuições com implantações de sistemas integradas a esse serviço. Porém, o
resultado obtido nessa pesquisa foi de suma importância para quem pretende migrar
os sistemas e recursos de rede a serviço de diretórios, para efetuar uma única
autenticação do usuário.
Para as instituições que tenham sistemas diferentes oriundos de fornecedores

diferentes, ao aplicar essa tecnologia, facilitará o controle de acesso a todos os
serviços disponibilizados por cada instituição, através de um único domínio.
68
REFERÊNCIAS BIBLIOGRÁFICAS
BAPTISTA, Miguel; DOMINGUES, M.. Desenvolvimentos Avançados em Redes. Lisboa:

FCCN (Fundação para a Computação Científica Nacional), 2005.
BARTH, Douglas Graciano, SIEWERT Vanderson Clayton. Lightweight Directory Access

Protocol, Gestão da Segurança da Informação em Redes de Computadores, pp. 1-2, 2006.
BRANCO, Rodrigo Rubira. Segurança da Informação, Firewalls security. Bauru: 2004.
BRESSAN, Graça. Serviços de Nomes DNS, X.500 e LDAP. São Paulo: 2007.
CAMPOS, Augusto. A IDE para modelagem de dados JUDE. São Paulo: 2006. Disponível
em: < http://br-linux.org/linux/node/3335>. Acesso em: 27 Out. 2008.
CARTER, Gerald. LDAP System Administration. Sebastopol, CA: O’Reilly and

Associates, Inc, March 2003.
CERQUEIRA, Alisson Gomes. Implementação de Módulos PAM e NSS para

Autenticação Segura e Distribuída. Lavras: 2005.
COUTINHO, Gustavo Lacerda; MSILVA, Renan Galvão. Funcionamento do TLS. Rio de

Janeiro: 2006.
CRUZ, Carla; RIBEIRO, Uira. Metodologia Científica – Teoria e Prática, 1. ed. Belo
Horizontes: Axcel Books, pp. 35-36, 2003.
KANIES, Luke A., Um Introdução ao LDAP. The O'Reilly Network: 2001.
KELLERMANN, Gustavo Adolfo. SILVELLO, Júlio César. Introdução e Conceitos de

LDAP. Porto Alegre: 2001. Disponível em:
<http://www.inf.ufrgs.br/procpar/disc/inf01008/trabalhos/sem01-1/t1/openldap/capitulo1.html.
Acesso em: 04 abr. 2008.
LEITE, Ricardo Baía. Fundamentos de Redes de Computadores. Disponível em: <

http://www.transroll.com.br/rede/tcpip.htm >. Acesso em: 03 abr. 2008.
LUPPI, Iria. Tipos de Sistemas de Informação na empresa. Oficina da Net: 2008.

Disponível em:
69
<http://www.oficinadanet.com.br/artigo/738/tipos_de_sistemas_de_informacao_na_emprese
>. Acessado em: 31 mar. 2008.
MACHADO, Erich Soares; MORIJR, Flávio da Silva. Autenticação Integrada Baseada em

Serviço de Diretório LDAP. São Paulo: 2006.
MACORATTI, José Carlos. Padrões de Projetos: O modelo MVC - Model View

Controller. São Paulo: 2005. Disponível em: < http://www.macoratti.net/vbn_mvc.htm>.
Acesso em: 17 Out. 2008.
MALDANER, Giani. Revolucionando a sua empresa. Sisnema Informática – Porto Alegre:

2004. Disponível em: < http://sisnema.com.br/Materias/idmat014777.htm>. Acesso em: 17
mar. 2008.
OLIVEIRA, Marcelo Silva de. Orientações Metodológicas para Monografias de Lato

Sensu. Material submetido para apreciação junto ao Conselho Editorial do DEX-UFLA
visando tornar-se mais um volume da série Texto Acadêmico da Editora da UFLA . DEX-
UFLA. 2005.
PAPOTTI, Carlos Fernando; BEVILACQUA, José Ricardo M.; MARCONDES, Julio César
Costa; BALDIN, Raul. Lightweight Directory Access Protocol LDAP. Campinas: 2006.
PIRES, Paula. Fundamentos de JNDI, Núcleo de Computação Eletrônica – Universidade

Federal do Rio de Janeiro (UFRJ). Rio de Janeiro: 2003.
REINHART, Alessandro; MELLO, Daniel; MARTINS, Fabiano; MACHADO, Marcos.

Gerenciamento Integrado de Identidade em Ambientes Corporativos. São Leopoldo:
2005.
SEZANOWITCH, Robinson Luis, História do LDAP. Florianópolis: 2006. Disponível em:

<http://www.robinson.luis.nom.br/robinson/detalhes.php?recordID=466>. Acesso em: 15 mai.
2008.
SILVA, Douglas Marcos da. UML – Guia de Consulta Rápida. , 3. ed. São Paulo: Novatec,
2001.
SUNGAILA, Marcos. Autenticação Centralizada com Open LDAP, 1. ed. São Paulo:
Novatec, 2007.
TEIXEIRA, Roberto; MERCER, Carlos Daniel. Guia do Servidor. Curitiba: Conectiva S. A.,
2000.
70
ANEXO A – ALGORÍTMOS DA AVALIAÇÃO DA AUTENTICAÇÃO
A apresentação dos algoritmos que fazem parte da avaliação da autenticação dos

usuários no diretório LDAP.
Figura 39. Algoritmo que Insere os Usuários no diretório LDAP, de acordo com
a Proporção
71
Figura 40. Algoritmo que Autenticar os Usuários, a partir de somente uma

abertura e um fechamento da conexão com o LDAP (Avaliação A), de acordo
com a Proporção
72
Figura 41. Algoritmo que Autenticar os Usuários, a partir da abertura e

fechamento da conexão com o LDAP para cada validação (Avaliação B), de
acordo com a Proporção
73
Figura 42. Algoritmo que Apaga todos os Usuários do diretório LDAP, de

acordo com a Proporção
74
ANEXO B – RESULTADOS DOS TESTES DAS AUTENTICAÇÕES
Alguns resultados obtidos pela execução de dois algoritmos (A e B) do aplicativo de

avaliação da autenticação, em forma seqüencial, de até cem mil usuários, a partir de
quarto tipos de conexão a Internet.
Figura 43. Avaliação A da Autenticação de Mil Usuários com Conexão de

Internet Dial Up
75
Figura 44. Avaliação A da Autenticação de Mil Usuários com Conexão de

Internet Rede Local
76
Figura 45. Avaliação A da Autenticação de Cem Mil Usuários com Conexão de

Internet Wireless
77
Figura 46. Avaliação B da Autenticação de Dez Mil Usuários com Conexão de

Internet Rede Local
78
ANEXO C – DIAGRAMAS DE CASO DE USO – CAPÍTULO 5
O diagrama de caso de uso apresenta os autores que interceptarão com as

entidades relacionadas a cada evento do sistema.
Figura 47. Autenticação de Usuário
Figura 48. Manutenção de Dados dos Usuários

79
Figura 49. Movimentação das Permissões de Ação dos Usuários
Figura 50. Relatório das Permissões de Ação aos Grupos e Usuários

80
ANEXO D – DIAGRAMAS DE SEQÜÊNCIA – CAPÍTULO 5
Esse diagrama apresenta as linhas de execução das funcionalidades da integração

dos usuários de sistemas aos diretórios LDAP.
Figura 51. Autenticação do Usuário no Diretório LDAP

81
Figura 52. Manutenção de Usuários de Sistemas Integrada ao Diretório LDAP

Autenticação de Usuários em Um Diretório LDAP

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Autenticação de Usuários em Um Diretório LDAP

Enviado por

Direitos autorais:

Formatos disponíveis

JEDSON ZENDRON FIGUEIREDO

AUTENTICAÇÃO E MANUTENÇÃO DAS CONTAS DE USUÁRIOS DE

JEDSON ZENDRON FIGUEIREDO

Trabalho de Conclusão de Curso apresentado ao Instituto Municipal de Ensino

Orientador: Douglas Sanches da Cunha

Analisador (1): Alex Sandro Romeo de Souza Poletto

Analisador (2): Domingos de Carvalho Villela Júnior

AUTENTICAÇÃO E MANUTENÇÃO DAS CONTAS DE USUÁRIOS DE

Trabalho de Conclusão de Curso apresentado ao Instituto Municipal de Ensino

Área de Concentração: ________________________________________________

Dedico este trabalho a todos os professores que me ajudaram nessa batalha de

Agradeço principalmente, á Deus por abençoar nas horas de cansaço e pela

Aos meus familiares, que constantemente me incentivaram e me ajudaram a dedicar

Ao professor, Douglas Sanches da Cunha, pela orientação e pelo constante estímulo

As instituições de médio e grande porte demonstram dificuldade na manutenção das

Palavras-chave: LDAP. Autenticação. Serviço de Diretórios.

Keywords: LDAP. Authentication. Service Directories.

Figura 1 – História do LDAP ..................................................................................... 23

Tabela 1 – Alguns exemplos de Object Identifie ....................................................... 31

SGBD Sistema de Gerenciamento de Base de Dados

1.1 JUSTIFICATIVA E MOTIVAÇÕES............................................................... 17

1.2 OBJETIVOS ...................................................Erro! Indicador não definido.

1.3 ESTRUTURA DO TRABALHO .....................Erro! Indicador não definido.

2.1 O QUE É UM SERVIÇO DE DIRETÓRIO? ............................................. 21

2.2 O QUE É LDAP? ...................................................................................... 22

2.3 HISTÓRIA DO LDAP ............................................................................... 22

2.4 ORIGEM DO LDAP .................................................................................. 25

2.4.1 Diretório X.500 ............................................................................................ 25

2.4.2 Cliente do X.500 ......................................................................................... 26

2.4.3 DAP ............................................................................................................. 26

2.4.4 Pilhas de protocolos .................................................................................. 26

2.4.5 Versões ....................................................................................................... 27

2.5 POR QUE USAR LDAP? ......................................................................... 28

2.6 DIRETÓRIO LDAP ................................................................................... 29

2.7 SCHEMA .................................................................................................. 29

2.8 DISTINGUISHED NAMES (DN) .............................................................. 30

2.9 O QUE É LDIF? ....................................................................................... 30

2.10 OBJECT IDENTIFIER (OID) .................................................................... 31

2.11 ATRIBUTO .............................................................................................. 31

2.12 ENTRADA ............................................................................................... 32

2.13 OBJECT CLASS ..................................................................................... 33

3.1 OPERAÇÕES .......................................................................................... 34

3.2 SEGURANÇA .......................................................................................... 37

3.2.1 Métodos de Autenticação.......................................................................... 38

3.2.2 Métodos de Criptografia ............................................................................ 40

3.2.3 Modelo de Controle de Acesso ................................................................. 41

3.3 OTIMIZAÇÕES DO LDAP ....................................................................... 42

3.3.1 Replicação do serviço de diretórios......................................................... 42

3.3.2 Diretórios distribuídos............................................................................... 44

3.4 OPENLDAP ............................................................................................. 46

3.5 FERRAMENTAS PARA GERENCIAR UM SERVIDOR LDAP ................ 46

4.1 CONSIDERAÇÕES ................................................................................. 50

4.2 AVALIAÇÃO DA AUTENTICAÇÃO DE USUÁRIOS ............................... 52

4.3 ESTATÍSTICA DA ESTRUTURA DE DIRETÓRIOS DA FEMA .............. 56

5.1 CONSIDERAÇÕES ................................................................................. 59

5.2 MODELAGEM E APRESENTAÇÃO DO APLICATIVO ........................... 60

A evolução tecnológica nas redes de computadores se tornou estratégica para as

O referido fato geralmente resulta num oneroso trabalho de administração de contas

1.1 JUSTIFICATIVAS E MOTIVAÇÕES

As aplicações de uma instituição, localizadas em diferentes servidores, têm

A relevância do problema e a existência de tecnologias que se propõem a auxiliar e

dessas tecnologias é o protocolo de rede chamado LDAP (Lightweight Directory

A idéia da centralização das informações dos usuários facilitará os acessos aos