TD EdsonMachadodeSousa 2004 2

SOCIEDADE EDUCACIONAL DE SANTA CATARINA - SOCIESC
INSTITUTO SUPERIOR TUPY

BACHARELADO EM SISTEMAS DE INFORMAO - BSI

IMPLEMENTAO DE UM SERVIO DE DIRETRIOS
UTILIZANDO O PROTOCOLO LDAP

EDSON MACHADO DE SOUSA
ORIENTADOR: MEHRAN MISAGHI

Trabalho de Diplomao

Joinville
2004
EDSON MACHADO DE SOUSA


Trabalho de Concluso de Curso
submetido ao Instituto Superior
Tupy, como parte dos requisitos
para a obteno do grau de
Bacharel em Sistemas de
Informao, sob orientao do
professor Mehran Misaghi.

Joinville
2004

2

Edson Machado de Sousa

Este trabalho de concluso de curso foi julgado adequado para obteno do Ttulo de Bacharel
em Sistemas de Informao, e aprovado em sua forma final pelo departamento de Sistemas de
Informao do Instituto Superior Tupy.

Joinville, 16 de Dezembro de 2004.

__________________________________________________________
Mehran Misaghi, Mestre em Cincia da Computao.

__________________________________________________________
Marco Andr Lopes Mendes, Coordenador do Curso de Bacharelado em Sistemas de
Informao e Mestre em Cincia da Computao.

Banca Examinadora:

_________________________________________
Ricardo Saldanha

_________________________________________
Sandro Alves Eda

3
AGRADECIMENTOS

Agradeo a SOCIESC pela oportunidade de realizar o
curso de Bacharelado de Sistemas de Informao,
ao qual me deu todo auxlio necessrio para complet-lo.
Aos meus pais que sempre me incentivaram aos estudos
e nunca deixaram que me abatesse s dificuldades encontradas.
minha companheira Elaine que com sua determinao,
incentivou-me sempre a realizar o melhor.
Ao meu orientador Mehran Misaghi que doou seu tempo e conhecimento para
direcionar-me ao melhor caminho e a todos os que fizeram parte desta realizao.

(Edson Machado de Sousa)

4
RESUMO

Este trabalho aborda a necessidade da utilizao do servio de diretrio, conceituando a
tecnologia utilizada atualmente para fornecer este tipo de servio. O objetivo deste
demonstrar e detalhar algumas ferramentas que utilizam esta tecnologia, atestar suas
funcionalidades e qualidades e ao apresentar a implementao que est sendo utilizada no
ambiente da SOCIESC a fim de integrar todas as informaes possveis em um nico
repositrio.

5
ABSTRACT

This article presents the necessity of utilization of the directory service giving a concept to the
technology used nowadays to provide this kind of service. The objective of this is to
demonstrate and detail some tools which use this technology, it atests this funcionality and
qualities to present the implementarion which is being used in the Sociesc environment in
order to integrate all the possible information in an unique place.

6
LISTA DE FIGURAS

Figura 1.1 Autenticao sem LDAP.................................................................................... 11
Figura 2.1 Modelo de uma raiz DNS................................................................................. 14
Figura 3.1 Operao dos protocolos DAP e LDAP ............................................................ 23
Figura 3.2 Relacionamento entre um cliente LDAP, servidor LDAP e um Armazenador de
Dados .................................................................................................................................. 25
Figura 3.3 Modelo de uma Raiz LDAP baseada em DNS .................................................. 27
Figura 4.1 Requisies e respostas LDAP.......................................................................... 32
Figura 6.1 Viso geral da rede SOCIESC.......................................................................... 55
Figura 6.2 Ilustrao de um usurio na SOCIESC ............................................................. 56
Figura 6.3 Contedo do arquivo sources.list utilizado pelo apt.......................................... 65
Figura 6.4 Processo de instalao do OpenLDAP mdulo cliente e servidor ...................... 68
Figura 6.5 Configurando LDAP com authconfig................................................................ 69
Figura 6.6 Configurando LDAP com authconfig................................................................ 70
Figura 6.7 Gerao dos arquivos LDIF com o migrationtools............................................ 71
Figura 6.8 Criando a base para o diretrio LDAP .............................................................. 72
Figura 6.9 Criao da base do diretrio ............................................................................. 75
Figura 6.10 Configurao do servidor Proxy para Mozilla................................................. 77
Figura 6.11 Administrao da base com o software GQ .................................................... 79
Figura 7.1 Autenticao com LDAP.................................................................................. 81

7
LISTA DE TABELAS

Tabela 2.1 Histrico da padronizao do X.500................................................................. 17
Tabela 6.1 Programas do pacote smbldap-tools ................................................................. 76

8
SUMRIO

1 INTRODUO........................................................................................................................................... 10
2 SERVIO DE DIRETRIO...................................................................................................................... 13
2.1 PROTOCOLO X.500 (DAP) ................................................................................................................... 16
3 CONHECENDO O LDAP.......................................................................................................................... 19
3.1 LDAPV3.................................................................................................................................................. 20
3.2 LIGHTWEIGHT..................................................................................................................................... 22
3.3 DIRECTORY.......................................................................................................................................... 24
3.3.1 Tipos de informaes que podem ser armazenadas em um diretrio ldap ..................................... 26
3.3.2 Organizao das informaes ........................................................................................................ 27
3.3.3 Referenciando uma informao...................................................................................................... 28
3.3.4 Acessando as informaes .............................................................................................................. 29
3.3.5 Segurana das informaes ............................................................................................................ 29
3.4 ACCESS PROTOCOL............................................................................................................................ 30
4 ARQUITETURA DO LDAPV3................................................................................................................. 31
4.1 MODELOS LDAP................................................................................................................................... 31
4.1.1 Modelo do protocolo....................................................................................................................... 31
4.1.2 Modelos de dados (data model) ...................................................................................................... 33
4.2 ELEMENTOS DO PROTOCOLO.......................................................................................................... 35
4.2.1 Envelope da mensagem................................................................................................................... 35
4.2.2 Tipos de string ................................................................................................................................ 38
4.2.3 Distinguished name and relative distinguished name (DN/RDN)................................................... 38
4.2.4 Resultado da mensagem.................................................................................................................. 39
4.3 OPERAO DE CONEXO................................................................................................................. 41
4.3.1 Resposta de desconexo.................................................................................................................. 42
4.4 OPERAO DE DESCONEXO.......................................................................................................... 43
4.5 OPERAO DE BUSCA....................................................................................................................... 43
4.5.1 Requisio de busca........................................................................................................................ 44
4.6 OPERAO DE MODIFICAO ........................................................................................................ 45
4.7 OPERAO DE ADIO..................................................................................................................... 46
4.8 OPERAO DE REMOO................................................................................................................. 47
4.9 OPERAO DE COMPARAO ........................................................................................................ 47
4.10 OPERAO DE ABANDONO.............................................................................................................. 48
5 SERVIDORES DE DIRETRIO LDAP.................................................................................................. 49
5.1 ACTIVE DIRECTORY........................................................................................................................... 49
5.2 OPENLDAP............................................................................................................................................ 51
5.3 IBM TIVOLI DIRECTORY SERVER.................................................................................................... 52
5.4 NOVELL EDIRECTORY....................................................................................................................... 53
6 IMPLEMENTAO.................................................................................................................................. 55
6.1 FERRAMENTAS UTILIZADAS ........................................................................................................... 57
6.1.1 Conectiva Linux .............................................................................................................................. 58
6.1.2 Openldap......................................................................................................................................... 59
6.1.3 Samba ............................................................................................................................................. 59
6.1.4 Pacote Migrationtools .................................................................................................................... 61
6.1.5 Smbldap-tools ................................................................................................................................. 61
6.1.6 PAM................................................................................................................................................ 62
6.1.7 NSS.................................................................................................................................................. 63
6.1.8 APT ................................................................................................................................................. 63
6.2 INSTALAO E CONFIGURAO.................................................................................................... 65
6.2.1 Definindo o ambiente...................................................................................................................... 66
6.2.2 Openldap......................................................................................................................................... 67
6.2.3 Migrationtools ................................................................................................................................ 70
6.2.4 Samba ............................................................................................................................................. 73

9
6.2.5 Smbldap-tools ................................................................................................................................. 74
6.2.6 Integrao do servidor Proxy ......................................................................................................... 76
6.2.7 Adicionando um computador ao domnio....................................................................................... 78
6.2.8 Administrao da base LDAP......................................................................................................... 79
7 CONSIDERAES FINAIS ..................................................................................................................... 80
REFERNCIAS .................................................................................................................................................. 85
GLOSSRIO....................................................................................................................................................... 88
ANEXOS .............................................................................................................................................................. 90

10
1 INTRODUO

Ao longo dos anos a utilizao de sistemas em rede tem aumentado
significativamente. As aplicaes hoje no se limitam somente a uma rede local ou a Intranet,
mas esto tambm instaladas em unidades interligadas de uma mesma empresa e at mesmo
na Internet.
A quantidade de usurios e sistemas especializados conduzem ao fato da dificuldade
de administrao, redundncia e inconsistncia das informaes. Algumas das reas mais
crticas para o gerenciamento so os sistemas de autenticao e controle de usurios. Essa
dificuldade compartilhada por administradores de rede e seus usurios, j que o
administrador precisa gerenciar todas estas informaes que muitas vezes esto em locais e
sistemas totalmente diferentes, j para o usurio a dificuldade maior o gerenciamento de
suas senhas e suas informaes armazenadas em vrios locais da rede, a figura 1.1 demonstra
esta realidade, onde o usurio acessa os servidores e precisa autenticar em cada um destes
com usurios e senhas diferentes, e do outro lado o administrador de rede precisa administrar
estas bases de informaes.
So servidores de login, e-mail, Internet, Bancos de Dados, etc. Todos com suas
prprias informaes de usurio e nenhuma delas compartilhadas. Para cada acesso
necessrio efetuar um processo diferente.
Uma forma de resolver esta situao seria a centralizao destas informaes em nico
repositrio atravs de um servio de diretrio.
O conceito de diretrio pode causar confuso, pois as literaturas do vrios
significados a ele. Em um sistema de arquivo, um diretrio o lugar onde esto listados os
arquivos de um determinado usurio, por exemplo. Em um banco de dados, o diretrio o
local onde esto armazenadas todas as informaes armazenadas na base de dados. No

11
contexto que ser descrito, um diretrio basicamente um servio especializado para prover
acesso rpido aos dados de uma maneira padronizada.

Figura 1.1 Autenticao sem LDAP
Fonte: Figura elaborada pelo autor com base na reviso bibliogrfica

Para um melhor entendimento do que um diretrio tratado no contexto do trabalho,
primeiro deve-se imaginar a seguinte situao: uma pessoa possui uma agenda de telefones,
onde esto armazenadas informaes como nome, endereo e telefone. Ela efetua atualizaes
constantes na agenda o que gera um processo complexo para a administrao, imagine
ainda que a vida dela gira em torno desta agenda e quanto mais contatos consegue, mais a
agenda aumenta. Depois de algum tempo, o nmero de informaes to grande que fica
Administrador
de rede
?
? ?
Servidor de banco de dados
Servidor de login
Servidor de E-mail
Usurio
Informaes
do usurio
Informaes
do usurio
Informaes
do usurio

12
praticamente invivel mant-la, o que obriga a dividi-la, como por exemplo, uma outra
agenda para amigos, uma para clientes e outra para fornecedores. Ao longo do tempo estas
agendas iro aumentar, e sero divididas novamente. Um dia ser quase impossvel continuar
utilizando-as devido dificuldade de pesquisar alguma informao e o alto grau de
inconsistncia gerada pelas constantes atualizaes. Ter acesso s informaes dessa agenda,
armazenadas em nico local e que possam ser acessadas a qualquer momento de forma
simples e rpida o que prope um servio de diretrios centralizados.
Em um diretrio, possvel armazenar todas as informaes que so comuns aos mais
variados servios em uma rede local, como informaes de login de usurio e senha, e
tambm informaes que so pertinentes somente a esses servios. Um servidor de e-mail,
por exemplo, armazena, alm do login do usurio e sua senha, informaes como a caixa
postal do usurio e apelidos relevantes a esse usurio. Assim, o servidor de diretrio
compartilha as informaes comuns a outros servidores. Por exemplo, se em um servidor de
banco de dados for necessrio identificar o endereo eletrnico de algum usurio, possvel
compartilhar esta informao, que armazenada na rea do diretrio do servidor de e-mail
com o servidor de banco de dados. Assim todas as informaes so centralizadas em nico
diretrio.
Ao longo deste trabalho ser possvel conhecer um pouco do histrico da tecnologia
de servidores de diretrio e como este poder resolver ou amenizar os problemas citados.
Demonstra tambm partes da construo do seu principal componente, o protocolo LDAP. A
sua funcionalidade ser comprovada por meio da implementao apresentada ao final, onde
foi utilizado como laboratrio o ambiente de ensino da SOCIESC.

13
2 SERVIO DE DIRETRIO

O princpio pelo qual o Modelo de Servios de Diretrio X.500/DAP foi desenvolvido,
de poder armazenar vrios tipos de dados em um nico repositrio e ter acesso a esses dados
a qualquer momento e de qualquer lugar em uma rede de computadores.
Segundo Chadwick ( 1996, p.1):
[...] um computador acessando uma base de dados convencional, fornece
muito mais caractersticas tais como: rapidez na consulta de milhares de
entradas, recuperao de entradas com similaridade nos nomes e retornando
o nome de uma pessoa com seu nmero de telefone e endereo. Se pudermos
computar um conjunto de entradas em um diretrio global de telefone, e
interconect-los, e ento dar acesso s pessoas via uma interface padro, a
ns podemos ter um real servio de diretrio. (Traduzido por mim)

Analisando a afirmao anterior, podemos perceber a inteno de fazer com que as
pessoas possam ter acesso informao de qualquer lugar, sempre que for necessrio. Para
isso prope-se a criao deste tipo de servio em vrios setores computacionais e que estes
possam estar ligados entre si de uma forma padronizada, para que assim qualquer pessoa
possa ter acesso s informaes, mediante sempre a uma prvia permisso.
Os servios de diretrios baseados no modelo X.500 seguem uma estrutura
hierrquica, possibilitando assim que as informaes sejam organizadas de acordo com a
estrutura organizacional de uma empresa ou nao. E por que no de uma agenda? Assim o
administrador pode implementar este servio e acordo com a sua necessidade.
Um servio de diretrio uma base de dados especializada para leitura, navegao e
procura. Geralmente tem contedo descritivo, informaes baseadas em atributos e com
capacidade de implementar filtros de pesquisas. Os servios de diretrio geralmente no

14
suportam transaes complexas, encontradas em SGBD's que so projetados para manusear
uma grande quantidade de atualizaes. Sua finalidade organizar as informaes de modo
que sejam facilmente encontradas e que possam estar disponveis a qualquer momento para
qualquer pessoa ou aplicao. Os servios de diretrio so ajustados para responderem mais
rapidamente s requisies de visualizao e consulta, tendo a habilidade de replicar as
informaes a fim de aumentar a disponibilidade e a confiabilidade e sempre no menor tempo
possvel. Quando as informaes em um diretrio so replicadas, podem sofrer
inconsistncias provisrias que so eliminadas assim que os diretrios so sincronizados, esta
sincronizao vai depender da aplicao que utiliza o modelo X.500.
Diferentes mtodos permitem que diferentes tipos de informaes possam ser
armazenadas em um servio de diretrio, por meio de requisitos de como a informao pode
ser referenciada, consultada ou atualizada, por exemplo. Alguns servios de diretrios so
locais e outros globais. Um exemplo de servio de diretrio global o DNS. As informaes
de DNS esto disponibilizadas em vrios servidores espalhados na Internet hierarquicamente,
como ilustra a figura 2.1, todos cooperando entre si e seguindo uma mesma rvore de
diretrios j definida.

Figura 2.1 Modelo de uma raiz DNS
Fonte: Figura elaborada pelo autor com base no OpenLDAP 2.2 Administrator's Guide

SOCIESC
com
edu
net
A organizao
Raz do domnio

15
Segundo Carter (2003, p. 6), existem cinco caractersticas principais que so comuns
entre o DNS e os servios de diretrio, sendo que tais caractersticas podem ajudar a
compreender o seu funcionamento. So elas:
Um servio de diretrio altamente otimizado para leitura. Esta no uma
restrio em um modelo DNS, mas por razes de performance muitos servidores DNS
guardam informaes em memria cache. Adicionando, modificando, ou removendo
uma entrada referente a uma informao, o servidor forado a repassar esta mudana
aos outros servidores DNS espalhados pela Internet.
Um servio de diretrio implementa um modelo distribudo para armazenamento
de informaes. DNS gerenciado por milhares de servidores locais que esto
conectados pela raiz (.com, .edu, .net, etc.) de um DNS gerenciado pela InterNIC.
Um servio de diretrio pode estender os tipos de informaes armazenadas.
Recentes RFCs, como a RFC 2787, tm estendidos os tipos de registros DNS para
incluir informaes tais como um servidor de registros de recursos.
Um servio de diretrio tem avanadas capacidades de procura. DNS suporta
procuras por qualquer registro implementado (exemplo: NS, MX, A, etc.).
Um servio de diretrio tem uma replicao consistente entre os servidores de
diretrios. Os pacotes mais populares de software DNS suportam servidores DNS
secundrios que periodicamente transferem informaes de suas zonas, estas
transferncias contm as ltimas atualizaes das informaes de uma zona DNS.

Analisando essas comparaes podemos afirmar que o objetivo principal de um
servio de diretrio prover um local nico para todas as informaes e que estas possam
estar sempre disponveis de uma forma padronizada.

16
possvel utilizar um servio de diretrio para armazenar qualquer tipo de
informao, desde textos e nmeros, at imagens. Vrias aplicaes utilizam servios de
diretrio, mas isso no assim to visvel. O DNS, como visto anteriormente, um deles, um
arquivo de usurios e senhas como o do passwd, nos sistemas UNIX, onde so armazenadas
informaes como nome completo de um usurio, pasta do usurio no servidor e outras. E
assim muitas outras aplicaes possuem seus diretrios de informaes que so pertinentes
somente a elas.
Agora para entender a necessidade de centralizar essas informaes, imaginemos a
seguinte situao: em uma rede local temos um servidor de login, um servidor de correio
eletrnico, um servidor de banco de dados, cada um deles com sua base de informaes de
usurio. Isto causa redundncia e inconsistncia das informaes e ainda um maior grau de
dificuldade para a manuteno destas informaes. Sempre que for necessrio alterar alguma
informao de um usurio, ser preciso faz-lo em todos os servidores.
Imagine a economia de tempo para administrao se todos estes dados
redundantes pudessem ser consolidados em um s local. Como feito para
remover uma conta de usurio? Ns todos sabemos como isto feito agora:
voc remove o usurio do /etc/passwd, remove manualmente de todas as
listas de envio, do catlogo de endereos e assim por diante. (CARTER,
2003, pg.3).(Traduzido por mim).

2.1 PROTOCOLO X.500 (DAP)

A histria do X.500 data de meados dos anos 80, quando trs organizaes tentavam
criar um padro para fornecimento do servio de diretrios. O CCITT, atual ITU-T, teve
como intuito principal fornecer um servio de White Pages, como numa lista telefnica onde

17
as paginas brancas informam nome, endereo e telefone. A ISO e a ECMA conceberam
normas para fornecer servios de diretrio para aplicaes do modelo OSI. O caminho para a
definio destas normas foi longo como descrito na tabela 1.1, devido a vrios fatores. Um
desses fatores a rpida mudana na rea de tecnologia, a informtica mais precisamente. A
cada momento surgem novas tecnologias e outras j existentes so modificadas e atualizadas
tornando difcil padronizao de qualquer nova tecnologia.
Tabela 2.1 Histrico da padronizao do X.500.

Evento Data
CCITT Study Group VII, raise Question 35 1984
ISO start work on Directories in SC21 WG4 1984
First Joint Meeting is held (Melbourne) Abril, 1986
ISO Draft Proposal (DP) starts its ballot (3 months) Novembro, 1986
ISO 2
nd
DP is balloted (3 months) Julho, 1987
ISO Draft Standard is balloted (6 months) Dezembro, 1987
Work starts on the ('92) extensions to the ('88) joint Standard (Question 20 within CCITT SG
VII)
Maro, 1988
Final Editing Meeting of the ('88) joint Standard Outubro, 1988
Access Control ('92) Provisional Draft Amendment (PDAM) is balloted (3 months) Novembro, 1989
CCITT X.500 Blue Book Recommendations are published (The official CCITT version of the
'88 Standard)
Janeiro, 1990
Replication and remaining ('92) extension work PDAMs are balloted (3 months) Dezembro, 1990
ISO/IEC 9594 - The Directory is published (The official ISO version of the '88 Standard) Janeiro, 1991
('92) extension work ISO second PDAMs ballot starts (3 months) Maio, 1991
('92) extension work ISO DAMs are balloted (6 months) Novembro, 1991
('96) extension work starts Maio, 1992
Final Editing Meeting of 1992 extension work Outubro 1992
ISO/IEC 9594 (1993) - The Directory will be published (The official ISO version of the '93
Standard)
1 semestre, 1994

FONTE: Understanding X.500 - The Directory

18
O X.500, tambm conhecido como DAP um protocolo de acesso a diretrios. O
padro X.500 foi construdo para prover uma administrao distribuda da base de dados,
funes especficas foram construdas para isto. Foi projetado para prover o acesso aos
servios de diretrios, baseado nele que outras ferramentas de servios de diretrios so
implementadas, tambm foi desenhado para armazenar informaes em lote na mesma base
de dados.
O DAP gera um problema de performance, pois foi construdo para operar em toda a
pilha de protocolos OSI, requer que o servidor e o cliente operem desta forma, gerando uma
demanda computacional muito elevada. Por este motivo considerado heavyweight, muito
pesado, e sua utilizao acabou por no ser difundida.
[...] Esta pilha de sete camadas foi um bom exerccio acadmico para
desenhar um conjunto de protocolos de rede, mas quando comparado ao
conjunto de protocolos TCP/IP, semelhante a estar viajando por um
sistema de trens europeus com os bagageiros completamente
carregados.(Carter, 2003, p. 3).(Traduzido por mim).

Esta afirmao refora a idia de que o X.500 faz muito mais do que realmente
necessrio. Muitas das funes implementadas no so utilizadas e ainda h a necessidade da
operao na pilha de sete camadas do modelo OSI, o que causa a sobrecarga na comunicao.
Quando Carter (2003, p. 3) diz, que semelhante a estar viajando por um sistema de trens
europeus com seus bagageiros completamente carregados, possvel fazer um paralelo a uma
situao do nosso cotidiano, como andar de nibus partindo de um bairro para o centro da
cidade, com a finalidade de ir ao banco pagar contas e levando uma mala cheia de roupas. So
itens desnecessrios para o objetivo da viajem que apenas pagar contas. Toda esta bagagem
extra embutida no protocolo torna-o pesado demais.

19
3 CONHECENDO O LDAP

A verso 3 do protocolo LDAP veio para suprir algumas inadequaes das verses
anteriores .
A primeira verso do protocolo, descrita na RFC1487 de 1993, traz as operaes
principais de operao, mas no se preocupava, por exemplo, com a segurana das
informaes. Provia apenas autenticao por senha em texto plano e Kerberos IV.
O LDAPv2 foi publicado em 1995 na RFC1777 como um rascunho para a
padronizao. medida que servios eram implementados sobre as definies deste
protocolo, vrios problemas foram sendo descobertos.
Algumas implementaes realizadas no seguem totalmente as definies do
protocolo LDAPv2. A no utilizao de caracteres ASCII e T.61 uma das incompatibilidades
com as definies do protocolo na segunda verso. Uma outra incompatibilidade a no
utilizao das strings de texto dos tipos de atributos associados aos padres X.500, ao invs
disso, associam estas strings como o padro relacionado terceira verso.
O LDAPv2 no fornece caractersticas adequadas para sua utilizao na Internet, no
podendo garantir assim confidencialidade e integridade das informaes. Ao contrrio do
LDAPv3 ele no suporta mecanismos de segurana baseados em DIGEST-MD5, Kerberos V e
chaves pblicas.

20
3.1 LDAPV3

O objetivo principal deste protocolo minimizar a complexidade na utilizao de
diretrios a fim de facilitar a distribuio de aplicaes que utilizem este tipo de
implementao difundindo esta metodologia para que outras ferramentas sejam construdas
sobre este tipo de servio. Foi desenvolvido pela Universidade de Michigan dos Estados
Unidos como uma alternativa ao DAP.
Carter (2003, p. 3) assim escreveu:
[...]LDAPv3 tem somente nove operaes principais e prov um modelo
simplificado para programadores e administradores. Provendo pequenos e
simples conjunto de operaes permite aos desenvolvedores focarem na
semntica de seus programas sem ter a preocupao de conhecer aspectos do
protocolo que so raramente utilizados. Neste caminho os desenvolvedores
do LDAP esperam aumentar sua utilizao no desenvolvimento de
aplicaes.(Traduzido por mim).

A necessidade de centralizar as informaes est cada vez mais presente nas
organizaes, haja vista a quantidade cada vez maior de utilizao de sistemas
informatizados. A partir de afirmaes como estas, e verificando a necessidade de simplificar
a utilizao dos meios computacionais, os desenvolvedores de softwares e solues esto cada
vez mais implementando funes em seus programas para que estas facilidades possam ser
alcanadas. Algumas dessas funes esto sendo implementadas em diversos aplicativos para
que possam interagir com o protocolo LDAP.
O LDAP foi projetado para resolver os problemas causados pela proliferao de
diretrios pela rede, segundo Kanies (2001, p. 1). Esta proliferao torna complexo o
gerenciamento das informaes nesses diretrios e causa problemas como a redundncia e
inconsistncia das informaes. Desta forma, os administradores precisam estar cada vez mais

21
atentos s mudanas. Para resolver tais problemas, segundo Kanies (2001, p. 2), existem sete
aspectos de sua implementao atual que lhe do habilidade. So elas:
Desenho genrico
Simplicidade do protocolo
Arquitetura distribuda
Segurana
Padro aberto
Solicitao de funcionalidades e esquemas do servidor
Internacionalizao
Essas caractersticas da construo do LDAP auxiliam o protocolo na sua
disseminao entre os desenvolvedores de software. Quanto mais aplicativos incorporam em
seu cdigo as funes do protocolo LDAP e passam a interagir com o ele, os administradores
de rede vem nestas ferramentas a soluo para alguns de seus problemas.
Isto evidenciado pelo fato do surgimento cada vez maior de ferramentas
incorporando e suportando as especificaes do protocolo. So servidores de diretrio como o
Directory Server da Netscape, Active Directory da Microsoft e o OpenLDAP, clientes de e-
mail, sistemas operacionais, linguagem de programao como Java e .Net, todos atendendo a
especificaes padro como a iniciativa DEN, que visa integrar o gerenciador de servidores e
servios de rede de forma que atendam s especificaes das novas geraes de aplicaes de
rede.

22
Carter ( 2003, p. 2), diz ainda que:
Isto soa como uma utopia dos administradores. Embora, eu acredite que
quanto mais e mais aplicaes clientes usem diretrios LDAP, fazendo um
investimento para adequar os servidores LDAP, poderemos ter uma grande
recompensa a longo prazo. Realmente, ns no estamos motivados por uma
utopia. Ns estamos neste projeto para ser responsveis por mais servidores
e mais servios, rodando em mais plataformas. Os dividendos de nosso
investimento em LDAP vm quando ns significativamente reduzimos o
nmero de tecnologias de diretrios que temos que entender e
administrar.(Traduzido por mim).

Isso leva a crer que esta tecnologia s vem para facilitar a vida de administradores e
tambm de usurios, tornando mais fcil manuteno das informaes para ambos. O
administrador precisa manter apenas uma base de usurios, por exemplo, provendo acesso a
vrios servios e melhorando inclusive a segurana. O usurio no precisa saber vrias
informaes sobre login e senha, basta que saiba apenas uma, a que esta gravada no diretrio
LDAP.

3.2 LIGHTWEIGHT

O LDAP foi projetado para operar sobre o protocolo TCP/IP executando somente
alguns subconjuntos do modelo X.500 e disponibilizando muitas das funcionalidades do DAP
por um custo computacional muito menor, por isso ele um protocolo leve (Lightweight).
Segundo Carter (2003, p. 3), O LDAP considerado leve porque omite muitas
operaes do X.500, operaes que so raramente utilizadas.(Traduzido por mim).
O X.500 precisa operar sobre toda pilha OSI, acarretando em um grande carregamento
de informaes no cabealho, isto conhecido como high overhead, pois o modelo OSI

23
possui sete camadas e toda a comunicao no modelo X.500 precisa obrigatoriamente passar
por todas estas camadas a cada operao realizada.
O LDAP trabalha diretamente no TCP, orientado a conexo, todo o mapeamento das
mensagens LDAP so direcionadas para a porta 389, exclusiva para a conexo do LDAP,
assim gera um low overhead, ou um baixo carregamento de informaes no cabealho, pois
opera diretamente sobre o protocolo TCP/IP, que possui apenas quatro camadas. A operao
dos protocolos ilustrada na figura 3.1.

Figura 3.1 Operao dos protocolos DAP e LDAP
Fonte: Figura elaborada com base no Ldap System Administrator, O Reilly.
mdia de rede
Camadas
OSI
Aplicao
Apresentao
Sesso
Transporte
Rede
Enlace
Fsica
Aplicao
TCP UDP
IP
Fsica
Camadas
TCP/IP
LDAP
X.500

24
3.3 DIRECTORY

comum confundir um servio de diretrio de rede com um banco de dados, j que os
dois compartilham vrias caractersticas. O que difere um do outro basicamente como eles
foram desenhados para trabalhar. Como j foi dito anteriormente, os diretrios so otimizados
para executar mais operaes de leitura do que gravao, j os bancos de dados so
desenhados para efetuar tanto operaes de leitura como gravao e ocorrendo muitas vezes
ao mesmo tempo.
Carter (2003, p.3) diz que:
[...] um diretrio freqentemente lido, mas raramente escrito. Estas
caractersticas so essenciais para banco de dados, tal como suporte para
transaes e bloqueios de escritas, no so essenciais para um servio de
diretrio como LDAP. (Traduzido por mim)

importante tambm lembrar que o LDAP um protocolo, ele no indica onde os
dados sero armazenados. Cabe ao protocolo prover meios para estabelecer a comunicao
entre o cliente e o servidor de forma que as informaes sejam encapsuladas de uma maneira
comum s aplicaes.
O LDAP como dito antes possui um desenho genrico, por isso altamente extensvel,
podendo ser implementado com qualquer banco de dados relacional ou outro tipo de
armazenamento de dados existente, como ilustra a figura 3.2, desde que este possua
caractersticas para operar com o protocolo LDAP. Segundo Carter (2003,p. 4), o protocolo
no informa onde o dado amazenado, o desenvolvedor ao implementar um servidor de
diretrio pode utilizar o meio de armazenamento que for mais apropriado para a aplicao.
importante frisar que mesmo utilizando um banco de dados, isto no significa que o

25
LDAP ir conseguir efetuar operaes complexas atribudas aos bancos de dados, pois quem
ir controlar estas operaes ser o protocolo e no o meio de armazenamento. Se o LDAP
viesse a incorporar estes tipos de operaes acabaria por fugir de sua prioridade de ser um
protocolo leve.
Possui a capacidade de sincronizao dos diretrios atravs do estabelecimento de
servidores escravos. possvel ter todas as informaes em um nico diretrio e estas serem
replicadas aos servidores escravos periodicamente. Isto garante um aumento na performance
nas consultas realizadas na base. Uma consulta realizada na filial de uma empresa levaria
tempo elevado se fosse feita diretamente na base principal, pois o fator do meio de
comunicao influenciaria nesta atividade. Com a sincronizao uma rplica da base estaria
instalada localmente no servidor escravo, assim todas as consultas sero realizadas mais
rapidamente.

Figura 3.2 Relacionamento entre um cliente LDAP, servidor LDAP e um Armazenador de Dados
Fonte: Figura elaborada com base no Ldap System Administrator, O Reilly

Requisies
e respostas
do protocolo
Cliente LDAP Servidor LDAP
Armazenador de dados

26
3.3.1 Tipos de informaes que podem ser armazenadas em um diretrio ldap

Vrios tipos de informaes podem ser armazenadas em um diretrio LDAP, desde
cadeias de caracteres at arquivos de imagens em formato binrio. Porm preciso lembrar
que o LDAP no foi desenvolvido para substituir diretrios especializados como os sistemas
de arquivos ou o DNS. interessante guardar em diretrios imagens em formato binrio
Um servio de diretrio como LDAP, deve ser utilizado para centralizar e armazenar
certos tipos de informaes. Informaes e configuraes pessoais de cada usurio,
informaes globais de setores de uma empresa, todas estas informaes devem ser de cunho
descritivo e utilizadas geralmente para consultas.
O modelo de armazenamento da informao em um servio LDAP baseado em
entradas. Uma entrada um conjunto de atributos concatenados que formam um DN, ou um
nome distinto que vai referenciar esta entrada de forma nica na rvore de diretrios. Cada
entrada pode ter tipos de atributos que permitem o armazenamento de um ou mais valores.
Um atributo que armazena o endereo de correio eletrnico de um usurio pode ter vrios
valores, pois ele pode possuir vrios. J o atributo que armazena o nome o usurio ir permitir
o armazenamento de apenas um valor.

27
3.3.2 Organizao das informaes

As entradas no diretrio LDAP so organizadas de forma concatenada e hierrquica.
Geralmente a estrutura de uma rvore de diretrio reflete uma organizao ou estrutura
geogrfica. As entradas podem ser iniciadas representando pases, depois estados, cidades ou
ento refletir a estrutura organizacional de uma empresa, formando hierarquicamente a
estrutura da rvore.

Figura 3.3 Modelo de uma Raiz LDAP baseada em DNS
Fonte: Figura elaborada pelo autor com base no OpenLDAP 2.2 Administrator's Guide

dc=exemplo
ou=computadores
ou=usurios
dc=com
dc=edu
dc=net
uid=paulo
A organizao
Unidade Organizacional
Usurio

28
Atualmente as organizaes que implementam um servio LDAP, tendem a construir
sua rvore de diretrios, unindo a forma tradicional de formao de uma rvore baseada na
estrutura organizacional da empresa, aliada ao modelo de rvore DNS, a juno destas duas
formas geram uma rvore de diretrios baseada em Internet, como mostra a figura 3.3,
tornando-a mais flexvel para futuras adaptaes como a interligao de vrias rvores
correspondentes as filiais de uma mesma empresa.

3.3.3 Referenciando uma informao

Cada entrada em uma rvore possui um nome distinto (DN), por este DN que as
informaes so referenciadas na rvore. Uma entrada possui uma RDN, ou nome distinto
relativo. O termo relativo significa que relativo ao atributo ao qual referenciado. Por
exemplo, um atributo uid=jose o nome distinto relativo ao DN uid=jos, ou=informtica,
dc=SOCIESC, dc=com, dc=br, este que identifica de forma nica uma entrada no diretrio.
possvel ter outros Joss em uma empresa, mas estes devem estar locados em outros
departamentos, estas e outras caractersticas forma uma DN de um diretrio.

29
3.3.4 Acessando as informaes

Geralmente o LDAP utilizado para consultar informaes no diretrio, como j foi
dito anteriormente um servio de diretrio especializado para leitura. Porm operaes de
adio, remoo e atualizao de entradas so bastante utilizadas.
Uma consulta LDAP permite que apenas partes do diretrio sejam consultadas, isto
conseguido atravs da implementao de filtros de pesquisa.

3.3.5 Segurana das informaes

O LDAP prov mecanismos para que cada cliente ou usurio seja autenticado antes de
ter acesso s informaes, protegendo e garantindo a integridade das informaes. O LDAPv3
prov vrios mtodos para implementar segurana para as informaes que trafegam e so
armazenadas em um diretrio como, SSL/TLS e SASL.

30
3.4 ACCESS PROTOCOL

Todas as caractersticas apresentadas pelo LDAP fazem com que seja gerada uma
confuso sobre sua real definio. O LDAP um protocolo, suas especificaes tcnicas esto
definidas na RFC2251 de 1997. No incomum achar que se trata de um servio da rede, um
banco de dados ou outros. Carter (2003, p. 4), diz que: Com tudo isto que dito sobre
servios de diretrio fica fcil esquecer que ele um protocolo..(Traduzido por mim).
importante salientar que os desenvolvedores apenas criam servidores LDAP (Active
Directory, OpenLDAP) baseados nas especificaes definidas nas RFCs do protocolo.

31
4 ARQUITETURA DO LDAPv3

4.1 MODELOS LDAP

No LDAPv3 so identificados dois tipos de modelos, o modelo do protocolo e o
modelo de dados. Estes modelos so definidos por Howes (1997, p. 3, p. 4). No modelo do
protocolo definido como este deve agir quando uma comunicao estabelecida, a forma
como o protocolo deve responder a esta solicitao e como vai execut-la no diretrio. O
modelo de dados define como as informaes sero armazenadas no diretrio. A forma como
as entradas e os atributos sero gerados no diretrio.

4.1.1 Modelo do protocolo

Em um sistema LDAP, o cliente envia uma requisio ao servidor descrevendo a
operao que deve ser realizada e o servidor responsvel por realizar esta operao no
diretrio.
Howes (1997, p. 4) define que:
No modelo geral adotado por este protocolo os clientes devem executar
operaes do protocolo de encontro aos servidores. Neste modelo, um
cliente transmite um pedido do protocolo que descreve a operao a ser
executada no servidor. O servidor ento responsvel por executar esta
operao no diretrio. Com base na concluso desta operao, o servidor
retorna uma resposta que contem todos os resultados ou erros ao cliente.
(Traduzido por mim).

32
Embora seja requerida sempre uma resposta do servidor ou do cliente, no exigido
um sincronismo por parte de qualquer um dos dois, cliente ou servidor. Pedidos e respostas
para mltiplas operaes podem ser mudados a qualquer momento entre cliente e servidor,
mas antes necessrio que o cliente receba uma resposta de um pedido anterior como
demonstra a figura 4.1, onde vrias requisies so feitas alternadamente e as respostas no
so retransmitidas em ordem de chegada. Isto pode ser causado por vrios fatores, como por
exemplo, uma consulta mais elaborada pode levar mais tempo para ser processada, enquanto
isto acontece, outras requisies esto sendo executadas e as respostas a estas requisies no
devem esperar que uma operao realizada anteriormente receba sua resposta para que
somente depois as outras requisies sejam atendidas.

Figura 4.1 Requisies e respostas LDAP
Fonte:Figura elaborada pelo autor com base no OpenLDAP 2.2 Administrator's Guide

O protocolo permite aos servidores retornar requisies aos clientes de outros
servidores desde que estes estejam ligados entre si. Isso faz com que vrias rvores de
diretrios possam estar interligadas podendo fornecer uma informao requisitada por
qualquer cliente destas rvores.
Resposta 3
Resposta 2
Requisio 3
Requisio 1
Requisio 2
Resposta 1
Cliente LDAP Servidor LDAP

33
4.1.2 Modelos de dados (data model)

Protocolo LDAP define que um ou mais servidores devem fornecer de forma conjunta
o acesso a uma rvore de informao do diretrio, a DIT. A rvore composta de entradas.
As entradas possuem atributos e um ou mais atributos formam um RDN nico. A
concatenao de um RDN a uma seqncia de entradas, de uma entrada particular, a um
ponto anterior imediato da raiz da rvore de diretrio d forma ao DN, que nico na rvore.
A seguir um exemplo de um DN:

uid=robertos, cn=Roberto Silva, ou=Funcionarios, dc=enterprise, dc=com, dc=br
Onde:
uid = UniqueIDentifier
cn = CommonName
ou = OrganizationalUnit
dc = DomainComponent

4.1.2.1 Atributos das entradas

O conceito de atributo pode ser relacionado com o de variveis nas linguagens de
programao procedural. Assim como uma varivel, um atributo definido para armazenar
somente um tipo de dado, numrico ou alpha-numrico. Uma diferena em relao as
variveis que quando um novo valor atribudo a ela, o antigo sobrescrito, enquanto que
em um atributo o valor continua, ele apenas recebe um novo valor e o antigo somente ser
removido se uma operao de remoo for executada.

34
As entradas podem ser vistas como conjuntos de atributos que possuem um valor
associado. Cada tipo de atributo definido por um OID e tem suas caractersticas prprias que
fazem com que tenham funes especficas dentro do diretrio. Estas caractersticas definem
se um atributo pode ter um ou mais valores de um tipo em uma entrada, a sintaxe que os
valores devem utilizar, os tipos de funes que podem ser realizadas em cada valor deste
atributo.
Cada entrada possui um atributo ObjectClass que define a qual classe de objeto
pertence esta entrada. Estas classes possuem atributos que respectivos a cada uma delas.
Muitas vezes classes so inseridas em um servidor para que possam ser armazenados novos
tipos de dados. Os valores dos atributos podem ser modificados por um cliente o atributo
ObjectClass no pode ser removido, esta operao poderia causar a danos a entrada, j que
outros valores so relacionados a ele.
A implementao no servidor pode restringir estas modificaes para impedir que a
estrutura bsica de uma entrada no seja modificada. Se o valor do atributo ObjectClass for
modificado em uma determinada entrada, todas as entradas associadas a ela sero modificadas
tambm.
O schema uma forma de agrupar definies do tipo do atributo, definies da classe
do objeto, e outras informaes que um servidor pode usar para realizar algumas operaes,
como operaes de consulta, por exemplo. Suas especificaes tcnicas esto definidas nas
RFC 2252 e RFC 2256. Existem vrios tipos de schemas que podem ser utilizados conforme a
necessidade da implementao.
Os servidores s devem permitir que os clientes adicionem atributos a uma entrada se
for permitido pelas definies da classe do objeto, se o schema controlar a entrada especifica
ou se so atributos operacionais conhecidos por este servidor para finalidades administrativas.

35
4.1.2.2 Entradas e subentradas do subschema

Uma entrada do subschema pode conter todas as definies do schema utilizado pelas
entradas em uma parte da rvore do diretrio. Atributos como cn, objectClass, objectClasses e
o attributeTypes, devem ser definidos em todas as entradas do subschema.
As entradas dos subschemas so utilizadas para administrar as informaes
sobre o schema do diretrio, em particular as classes do objeto e tipos de
atributos suportados por servidores de diretrio. (Howes, 1997, p. 7).
(Traduzido por mim)

4.2 ELEMENTOS DO PROTOCOLO

A notao ASN.1 utilizada para descrever o protocolo. Um servidor LDAP deve ser
desenvolvido de forma que suporte futuras atualizaes do protocolo.

4.2.1 Envelope da mensagem

Para as finalidades de troca de mensagens, entenda-se mensagem como as operaes
de requisio e resposta a uma consulta, entre outras, todas as operaes so encapsuladas em
um s envelope, o LDAPMessage. A seguir a definio de um envelope LDAP:

36
LDAPMessage ::= SEQUENCE {
messageID MessageID,
protocolOp CHOICE {
bindRequest BindRequest,
bindResponse BindResponse,
unbindRequest UnbindRequest,
searchRequest SearchRequest,
searchResEntry SearchResultEntry,
searchResDone SearchResultDone,
searchResRef SearchResultReference,
modifyRequest ModifyRequest,
modifyResponse ModifyResponse,
addRequest AddRequest,
addResponse AddResponse,
delRequest DelRequest,
delResponse DelResponse,
modDNRequest ModifyDNRequest,
modDNResponse ModifyDNResponse,
compareRequest CompareRequest,
compareResponse CompareResponse,
abandonRequest AbandonRequest,
extendedReq ExtendedRequest,
extendedResp ExtendedResponse },
controls [0] Controls OPTIONAL }

MessageID ::= INTEGER (0 .. maxInt)

maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --

Fonte: Request For Comments RFC2251
A funo do LDAPMessage fornecer um envelope contendo todos os
campos comuns requeridos nas trocas de mensagens. Neste momento os
nicos campos comuns so o messageID e os de controle. (Howes, 1997, p.
10). (Traduzido por mim).

por meio deles que o protocolo entende qual funo est sendo solicitada naquele
momento. Quando um servidor recebe um pedido de conexo do cliente e ele no reconhece
esta requisio, uma tag desconhecida na mensagem, uma codificao de estrutura ou o
tamanho dos campos de dados esto incorretos, ou um outro motivo, o servidor ento deve
retornar a mensagem apropriada de acordo com o erro encontrado.

37
Se um servidor receber um PDU do cliente em que a tag de seqncia da
LDAPMessage no pode ser reconhecido, o messageID no pode ser
analisado, a tag do protocolOP no reconhecido como uma requisio, a
codificao das estruturas ou o tamanho dos campos de dados esto
incorretos, o servidor precisa retornar uma mensagem de desconexo com o
resultado do erro e imediatamente fechar a conexo. (Howes, 1997, p. 10).

4.2.1.1 ID da mensagem

O valor do ID da mensagem deve estar contido no pacote LDAPMessage para que as
respostas sejam encaminhadas para seus respectivos requisitantes. Howes (1997, p. 10) define
que, Todo envelope LDAPMessage deve conter o valor do messageID da requisio
LDAPMessage correspondente. (Traduzido por mim).
Howes (1997, p. 10) diz ainda que, O messageID de uma requisio deve ter o valor
diferente de todas as outras requisies proeminentes desta seo LDAP da qual faz parte.
Assim um cliente no pode emitir uma outra requisio com o mesmo ID de
mensagem sem que uma requisio anterior receba uma resposta. Tambm nenhum ID de
mensagem, de uma requisio abandonada poder ser usado enquanto esta no receber uma
resposta correspondente.

38
4.2.2 Tipos de string

O LDAP desenvolvido para utilizar o conjunto de caracteres Unicode, codificados
seguindo o algoritmo UTF-8. O tipo utilizado OCTET STRING.
O tipo LDAPString utilizado para definir que o conjunto de caracteres utilizados seja
definido com um tipo OCTET STRING. Ele utiliza o conjunto de caracteres Unicode
codificados depois do algoritmo UTF-8.

4.2.3 Distinguished name and relative distinguished name (DN/RDN)

J foi evidenciado antes que o DN o responsvel por garantir a unicidade de uma
entrada em um rvore de diretrios e o RDN um nome relativo utilizado, por exemplo, em
operaes de consulta. preciso salientar que estes so apenas conceitos, j que em um
diretrio no definido um valor para um DN ou RDN, eles devem ser compreendidos como
atributos que receberam valores. Um DN formado pela concatenao de vrios atributos que
do seu formato nico na rvore.
Fazendo uma analogia a um sistema de arquivos, pode-se dizer que o DN o caminho
onde se pode encontrar um arquivo e o RDN o arquivo propriamente dito. Ento, um RDN
o caminho onde est o valor que se deseja encontrar na rvore e o RDN este valor.

39
4.2.4 Resultado da mensagem

O LDAPResult o pacote responsvel por retornar as mensagens de sucesso ou falha
dos servidores para os clientes. Em reposta vrias requisies os servidores retornaro as
respostas que esto no campo do tipo LDAPResult para indicar o status final de uma operao
realizada, seja ela de leitura, pesquisa ou qualquer uma outra. O campo errorMessage pode
retornar uma string ASCII com uma mensagem de texto que possa ser lida pelos usurios. Se
o servidor no retornar uma mensagem de erro o campo errorMessage dever conter uma
string de tamanho zero.
O texto abaixo demonstra a estrutura do pacote LDAPResult.

LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),
authMethodNotSupported (7),
strongAuthRequired (8),
-- 9 reserved --
referral (10), -- new
adminLimitExceeded (11), -- new
unavailableCriticalExtension (12), -- new
confidentialityRequired (13), -- new
saslBindInProgress (14), -- new
noSuchAttribute (16),
undefinedAttributeType (17),
inappropriateMatching (18),
constraintViolation (19),
attributeOrValueExists (20),
invalidAttributeSyntax (21),
-- 22-31 unused --
noSuchObject (32),
aliasProblem (33),
invalidDNSyntax (34),
-- 35 reserved for undefined isLeaf --
aliasDereferencingProblem (36),
-- 37-47 unused --
inappropriateAuthentication (48),

40
invalidCredentials (49),
insufficientAccessRights (50),
busy (51),
unavailable (52),
unwillingToPerform (53),
loopDetect (54),
-- 55-63 unused --
namingViolation (64),
objectClassViolation (65),
notAllowedOnNonLeaf (66),
notAllowedOnRDN (67),
entryAlreadyExists (68),
objectClassModsProhibited (69),
-- 70 reserved for CLDAP --
affectsMultipleDSAs (71), -- new
-- 72-79 unused --
other (80) },
-- 81-90 reserved for APIs --
matchedDN LDAPDN,
errorMessage LDAPString,
referral [3] Referral OPTIONAL }


Os cdigos que no significam sucesso so tratados com o significado de que a
operao no pode ser terminada totalmente, algum problema ocorreu para que esta operao
no chegasse ao seu final com sucesso.
Os cdigos de 16 a 21 so problema de atributo, de 32 a 34 indicam o nome do
problema, de 48 a 50 indicam problemas de segurana, de 51 a 54 so problemas de servio e
de 64 a 69 e 71 indicam problemas de sincronismo.

41
4.3 OPERAO DE CONEXO

atravs da operao de conexo que se estabelece comunicao entre o servidor e
cliente em uma sesso do protocolo, esta operao que permite a autenticao entre eles, o
cdigo da requisio de conexo mostrada a seguir:

BindRequest ::= [APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice }

AuthenticationChoice ::= CHOICE {
simple [0] OCTET STRING,
-- 1 and 2 reserved
sasl [3] SaslCredentials }

SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }


Aps o pedido de conexo o servidor efetua a autenticao se necessrio e ento
retorna uma resposta ao cliente com o status da autenticao.
Em alguns mecanismos de autenticao SASL podem ser necessrios vrios pedidos de
conexo ao mesmo tempo e se em algum momento for necessrio, o cliente pode enviar um
pedido de desconexo para o servidor.
Se um cliente envia um pedido de conexo com o campo de mecanismo SASL vazio o
servidor retorna uma resposta de conexo como mtodo de autenticao no suportado, isto
permitir ao servidor abortar uma negociao de conexo para tentar novamente.

42
Ao contrrio de LDAPv2, o cliente no necessita emitir um pedido de
desconexo no primeiro PDU da conexo. O cliente pode pedir todas as
operaes e o servidor deve tratar estes como no autenticado. Se o servidor
requerer a conexo do cliente antes de navegar ou modificar o diretrio, o
servidor pode rejeitar um pedido de conexo, de desconexo ou de um
pedido prolongado com o resultado de "operationsError". (Howes, 1997, p.
21)

4.3.1 Resposta de desconexo

Este componente responsvel por emitir um tipo de resposta do servidor ao cliente a
uma solicitao de conexo.
A seguir o cdigo da resposta de desconexo:

BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL }


Se um pedido de conexo no obteve sucesso ento os seguintes resultados sero enviados ao
cliente:
- operationsError: servidor encontrou um erro interno;
- protocolError: nmero da verso no reconhecido ou estrutura incorreta do PDU;
- authMethodNotSupported: nome do mecanismo SASL no reconhecido;
- strongAuthRequired: o servidor requer autenticao para ser executado com um
mecanismo SASL;
- referral: o servidor no pode aceitar esta conexo e o cliente deve tentar outra;
- saslBindInProgress: o servidor requer que o cliente envie um novo pedido de conexo
com o mesmo mecanismo SASL para continuar o processo de autenticao;

43
- inappropriateAuthentication: o servidor requer que o cliente que havia tentado conectar
anonimamente ou sem fornecer credenciais as fornea para o continuar o processo de
conexo;
- invalidCredentials: a senha fornecida est errada ou as credenciais no puderam ser
processadas;
- unavaliable: o servidor est parado.

4.4 OPERAO DE DESCONEXO

Esta operao do protocolo, como o prprio nome sugere, utilizada para finalizar
uma sesso de conexo entre o cliente e o servidor.
No existe uma resposta definida para uma operao de desconexo. Atravs da
transmisso de uma requisio de desconexo qualquer cliente supe que a sesso est
terminada, assim como tambm o servidor ao receber uma requisio de desconexo entende
que o pedido de conexo pelo cliente est encerrado. Um tempo excedido pode ser entendido
como uma requisio de desconexo pelo servidor.

4.5 OPERAO DE BUSCA

Esta operao permite ao cliente solicitar pesquisas a um servidor a fim de localizar
informaes contidas nas entradas.

44
4.5.1 Requisio de busca

Este componente utilizado para efetuar a operao de busca. atravs dele que um
servidor LDAP receber os parmetros necessrios para realizar uma busca solicitada. A
seguir o cdigo deste componente:
SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2) },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
attributes AttributeDescriptionList }
Filter ::= CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion }
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
-- at least one must be present
substrings SEQUENCE OF CHOICE {
initial [0] LDAPString,
any [1] LDAPString,
final [2] LDAPString } }
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }


45
A seguir informaes sobre alguns parmetros utilizados:

baseObject define a raiz onde a pesquisa deve ser iniciada;
scope define o espao no diretrio onde esta pesquisa dever ser executada;
derefAliases indica como os objetos devem ser manuseados para a procura;
sizelimit define o nmero mximo de entradas que podero ser retornadas em funo
de uma pesquisa;
timelimit define o tempo mximo que uma pesquisa deve levar;
attrsOnly define se apenas os tipos de atributos sero retornados ou se tambm os
valores. Se o campo for definido como true (verdadeiro) ento somente os tipos de
atributos sero retornados, se definido como false (falso) ento sero retornados os
valores destes atributos;
filter define as condies que sero cumpridas para que a pesquisa retorne a
informao desejada;
Attributes define a lista de atributos retornada de acordo com o filtro de pesquisa
aplicado;

4.6 OPERAO DE MODIFICAO

Esta operao permite ao cliente requisitar a modificao de uma entrada ao servidor.
O resultado da modificao tentada pelo servidor retornado ao cliente como uma resposta de
modificao.
A resposta de uma modificao retorna ao cliente o sucesso ou a razo pela qual no

46
obteve xito. Se resposta retornar como sucesso ento todas as modificaes solicitadas foram
feitas, porm se apenas uma modificao no pode ser executada ento nenhuma das outras
pode ser realizada.
Sintaxe do componente:

ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object LDAPDN,
modification SEQUENCE OF SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2) },
modification AttributeTypeAndValues } }
AttributeTypeAndValues ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }


4.7 OPERAO DE ADIO

Esta operao responsvel por permitir que um cliente adicione uma nova entrada
em um diretrio. Para que esta operao seja bem sucedida o nome da entrada informada no
dever existir no diretrio, o que causar erro no momento de adicion-la. Sempre que uma
nova entrada for adicionada, processo geralmente realizado por meio de um arquivo LDIF,
necessrio verificar se as informaes da raiz de diretrio foram informadas corretamente.
A entrada nomeada no campo de entrada do AddRequest no deve existir
para que o AddRequest seja bem sucedido. O pai da entrada a ser adicionada
deve existir. Por exemplo, se o cliente tentar adicionar "CN=JS, O=Foo,
C=US", a entrada de "O=Foo, C=US" no existir, e a entrada de "C=US"
exista, ento o servidor retornaria o erro noSuchObject com o campo do
matchedDN que contem "C=US". (Howes, 1997, p. 35). (Traduzido por
mim)

47
4.8 OPERAO DE REMOO

Esta operao permite ao cliente remover uma entrada do diretrio. Basicamente
consiste na remoo de um DN da rvore. importante lembrar que apenas as entradas que
no possuem mais nenhuma subordinada a ela, chamadas folhas, podem ser removidas com
esta operao.
O servidor aps executar a operao de remoo, retorna ao cliente o resultado da
operao atravs de uma resposta de remoo, seja ela bem ou mal sucedida.

4.9 OPERAO DE COMPARAO

Esta operao a responsvel por permitir que um cliente execute operaes de
comparao, como por exemplo, em uma operao de busca.
Os erros e resultado da operao sero retornados atravs de uma resposta de
comparao e todos na mesma construo, no havendo uma resposta para cada tipo de
situao, erro ou sucesso.
Alguns sistemas de diretrio estabelecem controle de acesso aos valores de alguns
tipos de atributos, so as ACLs. Atravs destas ACLs possvel restringir ao acesso, por
exemplo, ao atributo password. Segundo Howes (1997, p. 38): Em um resultado de busca
este atributo pode ser retornado mas com um conjunto de valores vazios. (Traduzido por
mim).

48
4.10 OPERAO DE ABANDONO

Esta operao permite ao cliente solicitar ao servidor o abandono de uma operao
previamente executada.
No h nenhuma resposta definida na operao do abandono. O cliente faz o pedido de
abandono e aguarda que a operao identificada no ID seja abandonada. Se um pedido de
abandono for recebido no meio da transmisso de respostas de uma operao de busca, o
servidor ir cessar a transmisso imediatamente e no emitir uma resposta de busca para a
operao.

49
5 SERVIDORES DE DIRETRIO LDAP

5.1 ACTIVE DIRECTORY

A evoluo das redes fez com que a Microsoft tivesse que desenvolver uma ferramenta
de administrao de usurios que pudesse ser mais flexvel e adaptvel a grandes empresas. O
sistema de gerenciamento de domnios e usurios at ento era provido pelas ferramentas do
Windows NT, ferramentas estas que com o aumento das organizaes e a necessidade de
interlig-las no conseguiam suprir tais necessidades.
Minasi (2001, p. 26) diz que:
No faz muito tempo, as redes eram pequenas, assim com suas plataformas.
Mas hoje em dia no raro ver redes globais conectando centenas de
milhares de PCs e usurios. Gerenciar este tipo de complexidade traz
grandes problemas opa, devemos cham-los de desafios, sempre esqueo.
Uma das respostas para a questo bvia - Por que se incomodar com o
Windows 2000, afinal de contas? - o fato de ele ter sido projetado para ter
em mente alguns destes desafios. Isso importante, porque o NT4 no havia
considerado muitos destes problemas.

O Active Directory o servidor de diretrio desenvolvido pela Microsoft sobre as
especificaes dos modelos de diretrios LDAP descritos na RFC2251. Ele uma ferramenta
do Windows 2000 Server que garante muito mais funcionalidades que o antigo User Manager
do Windows NT4. As nicas informaes possveis de serem armazenadas para cada usurio
eram o nome do usurio (nome de login), nome completo, senha, horrios autorizados para
conexo, data de expirao da conta, descrio, nome de grupo primrio e informaes de
perfil. Todas estas informaes eram armazenadas em um arquivo encriptado chamado SAM.
Com o Active Directory possvel armazenar no s estas informaes, mas tambm,

50
informaes como telefone, endereo, informaes da empresa, departamento e outras.
O Active directory possui vrias ferramentas para administrao de suas
funcionalidades. Mesmo assim possvel que outros desenvolvedores criem outras que
possam ser mais maleveis e que atendam a seus requisitos, afinal, o Active Directory foi
projetado sobre o protocolo LDAP, assim teoricamente possvel trabalhar seus dados.
Segundo Minasi (2001, p. 29):
Agora, o LDAP pode inicialmente soar como um outro acrnimo esquisito,
mas ele mais do que isto o que a Microsoft fez colocando a interface
LDAP no Active Directory foi abrir uma porta para outros desenvolvedores.
E eis aqui o quanto ele importante: sim, o LDAP tornar o trabalho da
Oracle ou da Lotus mais fcil quando elas decidirem integrar a segurana
dos seus produtos com a segurana embutida do NT. Mas o LDAP tambm
significa que (pelo menos teoricamente) possvel construir ferramentas que
criam estruturas do Active Directory domnios, rvores, florestas, unidades
organizacionais, contas de usurios, todos os componentes.

Como o Active Directory foi escrito sobre o LDAP, permite que vrios servios
possam ser autenticados em sua base. Praticamente todas as aplicaes Microsoft tm suporte
a este mtodo. Outras empresas que utilizam a base Microsoft para executar suas aplicaes
esto cada vez mais procurando se adequar a esta realidade, o caso da Oracle e da Lotus.
A segurana no Active Directory semelhante ao que j existia no Windows NT4,
atravs do controle de grupos e permisses de acesso para cada grupo, alm das polticas de
grupos que agora so muito mais fceis de implementar.

51
5.2 OPENLDAP

A fundao OpenLDAP a responsvel por manter o projeto LDAP desde agosto de
1998. Este projeto foi iniciado com o intuito de desenvolver um servidor de diretrio LDAP
de cdigo aberto e gratuito, a fim de disseminar a utilizao do protocolo. A grande maioria
das implementaes de servidores LDAP no ambiente Linux so realizadas com o
OpenLDAP. Pontos como forte parceria de grandes empresas internacionais do setor de
informtica e grande colaborao da comunidade de software livre no desenvolvimento e
aprimoramento do software, tornam o OpenLDAP uma ferramenta confivel e constantemente
atualizada, por essas razes faz um grande sucesso entre os administradores de rede Linux.
O OpenLDAP construdo sobre as ltimas RFCs que descrevem o protocolo,
garantindo assim sua atualizao. possvel criar qualquer estrutura de rvores, florestas e
diretrios que seja necessrio. capaz de aplicar todos os modelos de segurana descritos no
protocolo, alm de implementar o controle de acesso por ACLs.
Uma das caractersticas negativas do OpenLDAP a falta de uma ferramenta de
administrao nativa. Quando necessrio realizar qualquer manuteno nas configuraes
do servidor ou nas informaes mantidas no diretrio preciso efetuar estas operaes
manualmente ou utilizar softwares de terceiros, uma simples criao de um novo usurio ou
modificao pode se tornar uma tarefa complicada se o administrador no estiver ambientado
como os comandos do OpenLDAP.
Felizmente existem vrias opes em softwares livres para administrar as informaes
mantidas no diretrio LDAP, porm nenhuma delas atende todos os requisitos necessrios
para uma fcil administrao. Operaes como busca ou alterao de uma certa informao
torna-se algumas vezes uma tarefa complicada. O administrador necessita por muitas vezes
saber como o diretrio foi desenhado para que assim possa realizar alguns tipos de operaes.

52
Uma alternativa seria o desenvolvimento de uma ferramenta que possua as
funcionalidades necessrias para efetuar todas as operaes de acordo com a necessidade do
administrador. Tendo em vista que o OpenLDAP um software livre, a construo de uma
ferramenta fica facilitada.

5.3 IBM TIVOLI DIRECTORY SERVER

O Tivoli Directory Server foi implementado sobre as definies do protocolo LDAPv3.
Uma particularidade deste servio de diretrio a utilizao do IBM DB2, um Sistema
Gerenciador de Banco de Dados, como armazenador de suas informaes, diferente dos
outros servios de diretrio que procuram utilizar em suas implementaes bases de dados
menos sofisticadas e especializadas em leitura.
Ele possui ferramentas para configurar e administrar o diretrio. Estas ferramentas
podem ser utilizadas como aplicaes WEB, em linhas de comando e em programas front-end.
Diferentemente do Active Directory que possui caractersticas prprias para a criao das
rvores de diretrios, ele se assemelha muito com o OpenLDAP, mas com uma maior
facilidade na administrao das informaes, pois possui vrias ferramentas que ajudam nesta
tarefa.
Assim como o OpenLDAP, seus mecanismos de segurana so os mesmo descritos na
RFC2829, ela descreve todos os mtodos suportados pelo protocolo.

53
Segundo Tuttle (2004, p. 6):
Com o IBM Tivoli Directory Server voc pode escolher sua estratgia de
autenticao, pode usar uma autenticao simples por com usurio e senha,
ou pode implementar mais segurana com uma estrutura de autenticao
baseada em certificado digital. Tambm inclui uma interface para Simple
Authentication Security Layer SASL, incluindo mecanismo de
autenticao MD5 (CRAM-MD5) e autenticao Kerberos se requerido.

Como no Active Directory, o Tivoli Directory Server procura integrar todas as
ferramentas IBM em uma nica base de informaes facilitando assim a administrao. Pode
ser instalando nos sistemas operacionais Windows 2000/2003 Server, Linux, AIX e no IBM
Z/series.

5.4 NOVELL EDIRECTORY

O eDirectory tenta ser mais que um armazenamento de dados LDAP, uma base de
identidade que vincula os usurios e seus direitos de acesso aos recursos, dispositivos e
polticas de segurana da empresa. Entre os servios de diretrio, o eDirectory o nico
capaz de atender s exigncias de distribuies avanadas de diretrio em grande escala. Ele
oferece a compatibilidade, segurana, confiabilidade, escalabilidade e gerenciabilidade
necessrias para distribuies internas e de Internet que sustentam milhes de identidades.
compatvel com todas as especificaes do protocolo LDAPv3 e compatvel com
XML, DSML e SOAP, tendo certificao LDAP pelo The Open Group, rgo responsvel por
certificar aplicaes sobre plataformas livres. compatvel com Linux Windows, Solaris, AIX,
NetWare e HP-UX.

54
O Novell eDirectory como todos os outros servios de diretrio, possui caractersticas
semelhantes de, segurana, escalabilidade, confiabilidade e gerenciamento. Todas essas
caractersticas so conseqncias da utilizao dos padres do LDAPv3.
Em testes comparativos realizados pela prpria Novell, o eDirectory, demonstrou de
uma forma geral, ser melhor que o Active Directory. Foi considerado pela META Group's,
como o melhor servio de diretrio atualmente no mercado.

55
6 IMPLEMENTAO

A SOCIESC uma entidade civil, filantrpica e sem fins lucrativos, tem como sua
misso buscar sempre ampliar seu compromisso no sentido de corresponder s expectativas
de ordem social, aumentando os investimentos dirigidos formao continuada dos valores
humanos, de modo condizente com as exigncias atuais do mercado globalizado.
Possui sua matriz na cidade de Joinville e filiais nas cidades de So Bento de Sul,
Curitiba, Florianpolis e Apucarana. A figura 6.1 ilustra a rede SOCIESC.

Figura 6.1 Viso geral da rede SOCIESC
Fonte: Figura elaborada pelo autor com base na interligao da rede SOCIESC

56
Cada unidade possui servios semelhantes, e todas enfrentam o mesmo problema de
possuir vrias senhas para obter acesso aos diversos servios da rede. O objetivo no futuro
diminuir ao mximo a situao vista na figura 6.2, onde os usurios da rede tm o mesmo
problema de ter que gerenciar um grande nmero de senhas, e outras informaes que
poderiam ser centralizadas, desta forma ajudando-o na administrao destas informaes.

Figura 6.2 Ilustrao de um usurio na SOCIESC
Fonte: Figura elaborada pelo autor com base no ambiente da SOCIESC

A partir desta implementao espera-se conseguir, no futuro, com que um usurio
consiga em qualquer filial, se autenticar em servios localizados na matriz com apenas uma
nica informao de login e senha.
A implementao relatada faz parte de um processo que foi iniciado ao final do ano de
2003 com a instalao de um servidor de LDAP integrado ao servio SAMBA, a fim de
guardar as informaes da rede local conhecida como Rede de Ensino, responsvel pela
autenticao e acesso de todos os alunos localizados na matriz Joinville. A principio o LDAP
estaria provendo apenas acesso a rede para os alunos, abrigando posteriormente todas as
Servidor de
e-mail
Servidor
ERP/Sistema
Acadmico
Servidor de login
da rede
corporativa
Servidor de login
da rede de
ensino
- login
- senha 1
- login
- senha 2
- login
- senha 3
- login
- senha 4

57
informaes referentes aos outros servios.
O que ser mostrado a seguir a atualizao e ampliao desta implementao. Foram
instaladas e testadas novas verses dos softwares j instalados no ano anterior e que garantem
novas funcionalidades. Tambm outros servios foram alterados para que busquem as
informaes necessrias para o acesso.

6.1 FERRAMENTAS UTILIZADAS

O ambiente computacional da SOCIESC bastante variado, portanto foi necessrio
um planejamento do que seria necessrio para a implantao do servio LDAP. O primeiro
passo foi mapear todos os servios disponveis, depois deste passo foi necessrio levantar
quais softwares seriam necessrios para que fosse possvel no final da implantao integrar o
maior nmero possvel de servios.
A escolha dos softwares utilizados na implementao levou tambm em considerao
o custo, maior facilidade encontrada para a configurao, e ambientao da equipe de
implantao. Procurou-se fazer uma implementao que pudesse sofrer atualizaes sem que
os servios precisassem ser parados ou que fosse necessrio efetuar novas configuraes
devido atualizao de algum destes softwares, por isso optou-se pelo sistema operacional
Conectiva Linux e softwares compatveis com esta distribuio.

58
6.1.1 Conectiva Linux

O Linux o sistema operacional de cdigo aberto que mais cresce no mundo. Sua
distribuio livre podendo ser instalado em quantos computadores forem necessrios sem
que seja exigido qualquer tipo de pagamento.
A escolha da distribuio Conectiva Linux, deu-se a facilidade de atualizao,
instalao e continuidade. A continuidade de uma distribuio um fator importante na
escolha para a adoo do sistema operacional, comum ver empresas do ramo que lanam
seus produtos e aps um perodo o descontinuam, deixando seus usurios a merc da falta de
correo de falhas do prprio software e de outros que venham agregados. A continua
atualizao da distribuio e de seus softwares garantem a confiabilidade na performance e
segurana da implementao
O Conectiva Linux construdo sobre os padres LSB, atendendo aos padres
determinados pelo Free Standards Group, rgo responsvel por determinar uma linha de
desenvolvimento para o Software Livre, a fim de que uma distribuio possa suportar todas as
solues desenvolvidas para o sistema operacional Linux.
O processo de instalao do sistema operacional no ser descrito neste documento
por no se tratar do foco do mesmo. Apenas vale ressaltar que a instalao realizada na
implementao foi a de perfil mnimo, ou seja, a mais simples possvel, assim garantiu que
apenas os mdulos essenciais para o funcionamento do sistema operacional foram instalados.

59
6.1.2 Openldap

A escolha do OpenLDAP deveu-se a dois motivos principais, o custo, pois se trata de
uma ferramenta livre e a sua credibilidade na comunidade de software livre. Alm disso, ele
se mostrou fcil de configurar e trabalhar. Existe uma ampla documentao sobre formas de
instalao. A maturidade do software e ainda por ser um projeto ligado a Universidade de
Michigan, onde no o LDAP, aliada a todas as suas outras qualidades mostrou-se como sendo
a melhor escolha para o ambiente que se propunha a ser implementado.

6.1.3 Samba

O Samba foi criado por Andrew Tridgell no inicio de 1992, aps se deparar com a
necessidade de conectar sua maquina com sistema operacional UNIX com uma outra com o
sistema operacional DOS, ele ento fez um engenharia reversa no protocolo SMB e conseguiu
desenvolver um cdigo que possibilitou esta conexo. O Samba foi ao longo dos anos
aprimorado e hoje atravs dele possvel obter as seguintes funcionalidades:

Um computador com sistema operacional Linux, pode ser adicionado a um controlador
de domnio Windows, como se este tambm fosse um computador com o sistema
operacional Windows;
possvel compartilhar arquivos e impressoras em computadores com Linux como se
estas fossem computadores do ambiente Windows;

60
Um computador com Samba instalado, pode ser configurado para que este seja um
servidor de login e um servidor de arquivos, estes apareceram em uma rede Windows
como se fossem servidores Microsoft;
Computadores com sistema operacional Windows podem ser adicionados a um
domnio criado em um servidor Samba como se fizessem parte de uma rede Windows
clssica.
Na verso 3 do Samba, j possvel configur-lo para que este seja um Controlador de
domnio adicional de uma rede Windows 2000.

Enfim, ele uma ferramenta que permite a coexistncia de maquinas Linux e Windows
em uma mesma rede atravs da utilizao do protocolo SMB. O SMB o protocolo utilizado
pela Microsoft para compartilhar arquivos e impressoras.
A SOCIESC possui um ambiente de rede quase que totalmente voltado para o
ambiente Windows, por isso a instalao desta ferramenta tornou-se necessria na
implementao para que assim pudesse haver a interao entre as tecnologias Linux e
Windows.

61
6.1.4 Pacote Migrationtools

Esta ferramenta um conjunto de programas escritos em Perl utilizados para migrao
da base de informaes de usurios, grupos, protocolos e outros servios existentes em
ambientes UNIX para o formato do LDAP. uma ferramenta livre que possui vrios
programas para as mais variadas utilizaes, podendo estes ainda ser alterados conforme a
necessidade da implantao. Este pacote somente utilizado quanto preciso efetuar a
migrao de uma base de informaes UNIX para LDAP.

6.1.5 Smbldap-tools

Esta ferramenta um conjunto de scripts criados para auxiliar no processo de
integrao e administrao de uma soluo com Samba e LDAP. Com ela possvel realizar,
por exemplo, operaes como criao de usurios, grupos e alterao de senhas. So
programas construdos com a linguagem perl, em funo disto, necessrio instalao desta
linguagem no servidor a ser executado esta implementao.

62
6.1.6 PAM

Quando se fala em sistemas Linux, deve-se lembrar que o modo nativo de autenticao
dele por meio do programa login lendo as informaes armazenadas no arquivo /etc/passwd.
Quando se fala em uma autenticao remota, como o caso deste documento, o mdulo
nativo do Linux no atende as necessidades, portanto preciso utilizar-se de algum artifcio
para realizar esta autenticao. Um mtodo seria modificando o programa login de tal maneira
que pudesse realizar esta autenticao, mas, isto se tornaria incomodo medida que fosse
necessrio modificar, acrescentar mais um mtodo de autenticao ou ainda se for preciso
modificar o mtodo de criptografia. Ento uma forma encontrada foi criao do PAM,
criado pela Sun Microsystems que logo aps liberou suas especificaes em RFCs. Sobre
essas especificaes o PAM para Linux foi escrito e a partir da o programa login precisou ser
reescrito apenas para suport-lo. Com a utilizao do PAM, sempre que for preciso modificar
o mtodo de autenticao basta adicionar o mdulo necessrio ao sistema e efetuar as
configuraes necessrias. Com o PAM possvel implementar muitas outras caractersticas
de autenticao, mas que no sero contempladas neste documento por no fazerem parte do
escopo.

63
6.1.7 NSS

O NSS a forma utilizada em sistemas Linux para permitir que diferentes servios de
pesquisa de nomes sejam usados na procura de hostnames, nomes de usurio, nomes de grupo
etc. A configurao realizada no arquivo /etc/nsswicth.conf e geralmente aponta para os
arquivos locais de informaes do computador, como por exemplo o passwd, group, shadow,
entre outros. Existem vrios outros mdulos disponveis para fornecer esta funcionalidade de
pesquisa de informaes, entre eles est o mdulo para o LDAP.
O NSS aliado ao PAM so os responsveis por fornecer o mtodo para que um
computador com sistema operacional Linux possa efetuar a autenticao em um ambiente de
rede regido pelo LDAP. Esta configurao tambm realizada no servidor, se isto no for
feito ele no poder, por exemplo, saber quais so os usurios armazenados na base LDAP,
pois sua referncia de procura ainda so os arquivos locais. Estas configuraes sero
descritas mais frente quando for tratado da instalao e configurao.

6.1.8 APT

O APT um conjunto de ferramentas utilizadas para gerenciar os pacotes de uma
distribuio Linux de uma forma automatizada, de maneira que, quando o usurio solicita a
instalao de um pacote, o sistema tambm instala todos os pacotes necessrios para o
funcionamento do pacote solicitado. Ele pode ser utilizado para instalar, remover ou atualizar
estes pacotes.

64
O APT inicialmente era utilizado somente pela distribuio Linux da Debian. Este
sistema de gerenciamento de pacotes se mostrou muito eficiente fazendo com que vrias
outras distribuies viessem a adot-lo como padro de gerenciamento de pacotes, entre elas a
Conectiva. Todas as instalaes desta implementao foram feitas utilizando o apt, devido a
sua facilidade de utilizao.
O APT utiliza repositrios de arquivos RPM. Esses repositrios podem estar em sites
na Internet, no CD-ROM da distribuio, ou podem ser construdos pelo administrador. A
configurao da localizao desses repositrios feita atravs do arquivo
/etc/apt/sources.list. Cada linha deste arquivo contm as informaes relativas a um
repositrio de arquivos RPM. A figura 6.3 mostra o contedo do arquivo sources.list, onde se
pode observar onde esto localizados os repositrios de arquivos RPM utilizados nesta
implementao, com configuraes de repositrios criados por um administrador e um outro
disponvel na Internet. Aps a instalao do sistema operacional, importante que este seja
atualizado para evitar possveis problemas causados por falhas de software e segurana. Para
isto preciso executar o comando apt-get update e apt-get dist-upgrade. O arquivo
sources.list possui vrios locais da Internet onde estas atualizaes podem ser encontradas.

65

Figura 6.3 Contedo do arquivo sources.list utilizado pelo apt
Fonte: Figura elaborada pelo autor na implementao em laboratrio

6.2 INSTALAO E CONFIGURAO

Como descrito anteriormente, todas as instalaes foram realizadas visando uma fcil
atualizao, portanto foi definido como padro, a instalao por pacotes RPM. Esse mtodo
de instalao o padro das distribuies Conectiva, assim pode-se garantir a uma fcil
atualizao sem que sejam gerados problemas nas configuraes dos arquivos devido a estas
atualizaes.
Um passo importante quando se fala deste tipo de implementao a definio do
ambiente onde ser aplicado esta soluo. Para isto preciso definir o ambiente da
organizao, relacionando os servios, servidores e a prpria estrutura organizacional e

66
encontrar o melhor desenho para a definio da rvore de diretrios.

6.2.1 Definindo o ambiente

O principal objetivo dessa implementao o de fornecer uma forma nica de
autenticao para todos os usurios da rede. Devido aos vrios servios dispostos na rede,
necessrio ter vrias senhas de acesso o que causa um transtorno tanto para os usurios quanto
para os administradores. Neste caso o LDAP serve como um repositrio de senhas.
Em cada filial existe um ambiente semelhante ao da matriz, por essa razo a definio
da rvore de diretrio procurou contemplar um modelo onde estas filiais pudessem no futuro
serem integradas implementao, centralizando assim todas as informaes possveis na
matriz.
Na definio de quais servios seriam integrados levada em conta compatibilidade
com o protocolo LDAP. Desta forma, a princpio, apenas o sistema acadmico no ser
integrado, pois seu mtodo de autenticao utiliza uma base de informaes de usurios
prpria, no permitindo esta integrao.
Como a idia inicial foi utilizar todos os softwares distribudos como padro pela
Conectiva, resolveu-se definir a estrutura do diretrio como a sugerida pelos arquivos de
configurao dos prprios pacotes. Esta configurao, aps alguns estudos, mostrou-se
eficiente para o que se estava pretendendo em termos de centralizao das informaes alm
de ter se mostrado tambm eficiente quando so aplicadas polticas de grupos.

67
6.2.2 Openldap

Depois de definida a rvore de diretrio inici-se a instalao do programa principal
para a implementao, o OpenLDAP. A implementao sugerida atravs do processo de
instalao padro do Conectiva Linux, torna esta tarefa muito simples, j que no ser
necessrio a compilao dos programas.
A figura 6.4 demonstra o processo de instalao do OpenLDAP, mdulo cliente e
servidor, utilizando o apt, onde possvel observar o comando para a instalao, o repositrio
de onde o pacote est sendo copiado e todo o processo de instalao.

68

Figura 6.4 Processo de instalao do OpenLDAP mdulo cliente e servidor

Aps a instalao preciso iniciar a configurao do servidor LDAP com base nas
informaes definidas no levantamento do ambiente. As configuraes so realizadas no
arquivo /etc/openldap/slapd.conf, os detalhes podem ser vistos no anexo II.
Uma outra configurao importante feita no arquivo /etc/ldap.conf. Esta
configurao deve ser realizada em todos os clientes LDAP Linux, sejam eles servidores ou
no. Isto necessrio para que os clientes consigam buscar as informaes no servidor LDAP.

69
Esta configurao pode ser realizada de duas formas, editando o arquivo ou usando o utilitrio
do Conectiva Linux como ilustrado nas figuras 6.5 e 6.6, para isto basta digitar o comando
authconfig e depois selecionar os itens relacionados ao LDAP, se algum mdulo necessrio
para o funcionamento do LDAP estiver faltando este utilitrio ir informar, basta instalar aps
o trmino da configurao. O quadro a seguir demonstra as configuraes realizadas no
arquivo ldap.conf.
ssl no
pam_password md5
base dc=sociesc,dc=com,dc=br
rootbinddn cn=root,dc=sociesc,dc=com,dc=br
nss_base_passwd dc=sociesc,dc=com,dc=br?sub
nss_base_shadow dc=sociesc,dc=com,dc=br?sub
nss_base_group dc=sociesc,dc=com,dc=br?sub

Figura 6.5 Configurando LDAP com authconfig

70

Figura 6.6 Configurando LDAP com authconfig

Para que o cliente LDAP possa estabelecer esta comunicao com o servidor preciso
que este conhea a senha do usurio administrador da base, neste caso o root, para isto deve
ser criado o arquivo /etc/ldap.secret com permisses apenas para leitura e gravao para o
root, dentro deste arquivo deve ser adicionada a senha.

6.2.3 Migrationtools

A instalao desta ferramenta realizada com o apt, o pacote a ser instalado o
migrationtools-online, os arquivos so instalados no diretrio /usr/share/openldap/migration.
Eles sero utilizados para gerar os arquivos LDIF para posterior criao da rvore de
diretrio. Se o arquivo LDIF for criado manualmente, ento no ser preciso utiliz-lo, mas a

71
sua utilizao torna mais fcil a configurao destes arquivos, bastando apenas efetuar
algumas alteraes.
Para gerar estes arquivos LDIF, primeiro preciso editar o arquivo
migration_common.ph , que est localizado junto ao diretrio de instalao do pacote,
conforme detalhe visto no quadro seguinte. Depois de realizada esta configurao, os arquivos
LDIF podem ser criados conforme demonstra a figura 6.7.

# migration_common.ph
# Default DNS domain
$DEFAULT_MAIL_DOMAIN = "sociesc.com.br";

# Default base
$DEFAULT_BASE = "dc=sociesc,dc=com,dc=br";

# Turn this on for inetLocalMailReceipient
# sendmail support; add the following to
# sendmail.mc (thanks to Petr@Kristof.CZ):
##### CUT HERE #####
#define(`confLDAP_DEFAULT_SPEC',`-h "ldap.padl.com"')dnl
#LDAPROUTE_DOMAIN_FILE(`/etc/mail/ldapdomains')dnl
#FEATURE(ldap_routing)dnl
##### CUT HERE #####
# where /etc/mail/ldapdomains contains names of ldap_routed
# domains (similiar to MASQUERADE_DOMAIN_FILE).
$DEFAULT_MAIL_HOST = "mail.sociesc.com.br";

Figura 6.7 Gerao dos arquivos LDIF com o migrationtools

Quando estes arquivos so gerados, muitas informaes desnecessrias so criadas
tambm, possvel editar estes arquivos e deix-los mais organizados conforme anexo III.
Depois disso hora de adicionar estas informaes na base LDAP. A figura 6.8 ilustra

72
a criao da base do diretrio utilizando o arquivo base.ldif gerado anteriormente. Este
processo ser repetido para todos os arquivos criados.

Figura 6.8 Criando a base para o diretrio LDAP

Para adicionar novos usurios ou grupos, basta editar o arquivo passwd.ldif e incluir os
novos usurios neste arquivo, respeitando o mesmo formato j escrito no arquivo, no
esquecendo de incrementar o valor do atributo uidNumber e alterando as informaes
relevantes de cada usurio. Depois basta utilizar o comando mostrado na figura anterior para
adicionar os novos usurios.
Depois de terminado este processo basta conferir se os arquivos de configurao do
PAM e NSS esto configurados corretamente como no anexo IV. Como foi dito antes, existem
vrias bibliotecas PAM disponveis. A biblioteca para o LDAP chama-se pam_ldap e esta
deve estar instalada para que possa prover a autenticao.

73
6.2.4 Samba

Como j descrito anteriormente, a instalao realizada com o apt. Os pacotes a serem
instalados so o Samba-common, Samba-clients, Samba-server.
Depois de instalados estes pacotes, executa-se as alteraes nos arquivos
/etc/Samba/smb.conf e /etc/openldap/slapd.conf adicionando as informaes conforme anexo
V.
Uma configurao no arquivo slapd.conf gera problemas, quando se especifica o
schema para o Samba. Isto acontece por que os pacotes de instalao no possuem este
schema como padro. Para obter este arquivo foi necessrio baixar o cdigo fonte do Samba
diretamente do site oficial. Dentro deste pacote existe o arquivo necessrio para o schema do
Samba. Ento basta copi-lo para o diretrio onde ficam localizados todos os arquivos de
schema do OpenLDAP como mostra o quadro seguinte.

[root@odisseo root]# cp samba-3.0.9/examples/LDAP/samba.schema /etc/openldap/schema

Quando o Samba instalado algumas configuraes e arquivos so criados. Como
agora o Samba estar operando com o LDAP, estes arquivos e configuraes devero ser
excludos e outros sero criados, para isto os passos descritos no quadro a seguir devem ser
executados:
[root@odisseo root]# rm /etc/samba/*.tdb Rf
[root@odisseo root]# rm /var/lib/samba/
[root@odisseo root]# rm /var/lib/samba/*.tdb -Rf
[root@odisseo root]# rm /var/lib/samba/*.dat -Rf
[root@odisseo root]# rm /var/log/samba/* -Rf
[root@odisseo root]# smbpasswd -w openldap
Setting stored password for "cn=root,dc=SOCIESC,dc=com,dc=br" in secrets.tdb
[root@odisseo root]#
[root@odisseo root]# net getlocalsid
SID for domain ODISSEO is: S-1-5-21-3640286243-1420693789-3549743140

74
Um detalhe no comando smbpasswd executado no quadro anterior deve ser explicado.
Este comando est sendo usado para gerar uma senha para que possa haver a comunicao
entre o OpenLDAP e o Samba, portanto a senha indicada neste comando deve ser a mesma
configurada no arquivo slapd.conf.
Mais alguns detalhes importantes:
O servio smb precisa estar executando;
Aguardar alguns segundos antes de executar o comando net getlocalsid;
Guarde o nmero gerado; ser preciso para as configuraes do smbldap-tools.

6.2.5 Smbldap-tools

Para o funcionamento deste pacote, vrios outros precisaro ser instalados, mas
utilizando o apt basta instalar o pacote smbldap-tools para que todas as dependncias sejam
instaladas. Deve ser utilizado o smbldap-tools-0.8.5 ou superior.
Este pacote bastante til para a administrao de diretrios LDAP integrados ao
Samba, porm ele possui uma limitao: seus arquivos de configurao possuem uma
estrutura de rvore de diretrio padro, por isso se for necessrio uma rvore diferente, como
o caso desta implementao, vrias alteraes devem ser realizadas. O anexo VI mostra as
configuraes que foram realizadas no arquivo /etc/smbldap-tools/smbldap.conf e
/etc/smbldap-tools/smbldap.conf, para que pudessem ser gravadas as informaes na raiz da
rvore de diretrio de acordo com o que foi definido anteriormente.
Como foi dito anteriormente, resolveu-se utilizar a estrutura de diretrio sugerida
pelos softwares. Esta estrutura criada por um dos scripts deste pacote, o smbldap-populate,
como mostra a figura 6.9.

75

Figura 6.9 Criao da base do diretrio

Este script cria uma base interessante para a administrao das informaes,
mostrando-se bastante funcional nos teste realizados em laboratrio.
O pacote smbldap-tools possui vrios programas que auxiliam muito na administrao
da base, sendo possvel com eles realizar vrias operaes como descrito na tabela 6.1.

76
Tabela 6.1 Programas do pacote smbldap-tools

Comando Descrio
Smbldap-groupadd Adiciona um novo grupo
Smbldap-groupdel Remove um grupo existente
Smbldap-groupmod Modifica informaes de um grupo
Smbldap-groupshow Mostra informaes de um grupo
Smbldap-migrate-accounts Migra informaes de contas baseadas em Windows
Smbldap-migrate-groups Migra informaes de grupos baseados em Windows
Smbldap-passwd Altera a senha de um usurio
Smbldap-populate Cria uma base para rvore do diretrio
Smbldap-useradd Adiciona um novo usurio
Smbldap-userdel Remove um usurio existente
Smbldap-usermod Modifica informaes do usurio
Smbldap-show Mostra informaes do usurio

6.2.6 Integrao do servidor Proxy

O software utilizado como Proxy de Internet na SOCIESC o Squid, um dos mais
utilizados para Linux. As configuraes so simples, basta instalar o pacote squid-auth
utilizado para prover mtodos de autenticao e realizar as alteraes, descritas no quadro a
seguir, no arquivo de configuraes do squid, o squid.conf.

77

auth_param basic program /usr/lib/squid/squid_ldap_auth b
ou=people,dc=sociesc,dc=com,dc=br" -h odisseo.sociesc -v 3 -a always

auth_param basic children 5
auth_param basic realm Sociedade Educacional de Santa Catarina
auth_param basic credentialsttl 2 hours

acl corporativa proxy_auth REQUIRED

Depois de efetuada a configurao do servidor preciso configurar o navegador de
Internet (Mozilla, Internet Explorer, etc.) como mostra a figura 6.10.

Figura 6.10 Configurao do servidor Proxy para Mozilla

78
6.2.7 Adicionando um computador ao domnio

Para que um computador possa acessar o domnio criado pelo SAMBA com o LDAP,
algumas configuraes precisam ser realizadas.
As configuraes para que um computador com sistema operacional Linux possa
acessar as informaes j foram demonstradas o item 6.3.2 na pgina 71.
Para que um computador com sistema operacional Windows possa fazer parte do
domnio ser preciso efetuar algumas operaes como mostra o quadro a seguir:
[root@odisseo root]# smbldap-useradd -w SOCIESC244
[root@odisseo root]# smbpasswd -am SOCIESC244
Added user SOCIESC244$.
[root@odisseo root]

O commando smbldap-useradd juntamente com o parmetro w adiciona
computadores base LDAP. O Samba entende um computador como mais um usurio no
domnio, por isso preciso gerar uma senha para que este novo computador possa ter acesso
rede, por meio do comando smbpassswd juntamente com o parmetro am esta senha
gerada. Para computadores com sistema operacional Windows 2000 ou XP, esta operao no
necessria, j que estes sistemas operacionais conseguem adicionar diretamente na base
LDAP a conta do computador, desde que seja fornecido informaes de usurio e senha
capazes de gravar na base. Aqui foi utilizado o usurio root para esta operao, portanto
preciso que seja criada uma conta e senha para este usurio com os programas smbldap-
useradd e smbldap-passwd respectivamente.
Se o computador em questo possuir o sistema operacional Windows XP ou Windows
2000, ser preciso realizar uma modificao no registro do sistema como mostra o quadro
seguinte, alterando o valor da chave de 1 para 0.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\
Requiresignorseal

79
6.2.8 Administrao da base LDAP

A administrao da base pode ser feita de duas maneiras, com os comandos do prprio
LDAP ou com algum software desenvolvido para isto. Infelizmente no existem softwares
livres que consigam realizar todas as operaes necessrias em um diretrio de uma forma
amigvel, por esse motivo a escolha aqui foi efetuar algumas operaes com os comandos,
como adicionar usurios e grupos, e para algumas outras, como buscas e modificaes foi
utilizado o software GQ como mostra a figura 6.11.

Figura 6.11 Administrao da base com o software GQ

80
7 CONSIDERAES FINAIS

A utilizao de servidores de diretrio uma tendncia mundial que vem se tornando
cada dia mais evidente. Como foi visto grandes empresas do setor de informtica como,
Microsoft, IBM, Novell e Sun, tem investido cada vez mais em ferramentas que desempenhem
o papel de servidores de diretrio. Alm dessas, existem tambm projetos da comunidade de
software livre voltados somente para o desenvolvimento desta implementao. o caso do
OpenLDAP Project, um projeto livre que teve seu embrio formado na Universidade de
Michigan nos Estados Unidos e patrocinado por empresas de diversos ramos da informtica
dos Estados Unidos e Japo.
Uma outra evidncia a apresentao do tema em vrios congressos nacionais e
internacionais. No Brasil podemos citar as apresentaes realizadas no 5 Congresso de
Software Livre, em Junho de 2004 na cidade de Porto Alegre - RS, e no 2 Congresso
Catarinense de Software Livre, em Outubro de 2004 na Cidade de Joinville - SC. O Anexo I
mostra o material utilizado em uma destas apresentaes, a qual foi realizada por mim.
importante que a cada dia, sejam implementadas novas tecnologias para facilitar o
cotidiano dos usurios e administradores de rede. O servio de diretrio descrito neste
trabalho uma dessas tecnologias que apresenta um leque enorme de utilizaes, que
estudada constantemente poder fornecer ainda mais opes para prover cada vez mais
facilidades para o mundo da computao.
necessrio que os desenvolvedores de softwares e solues tentem fazer cada vez
mais com que esses se adeqem a esta tecnologia, tornando-os mais flexveis s mudanas e
se adequando qualquer sistema computacional. Um grande problema encontrado a falta de
conhecimento por parte dos desenvolvedores sobre a tecnologia de servios de diretrio.
Felizmente, grandes empresas do setor atentaram para isso e esto cada vez mais se dedicando

81
ao desenvolvimento de ferramentas que auxiliem nesta conquista de centralizao da
informao.
Este documento demonstrou alguns dos problemas enfrentados por usurios e
administradores de rede, utilizando diversas senhas para utilizao de diversos servios da
rede. Alm disso, conceituou-se o que e como um servio de diretrios centralizado pode
auxiliar no cotidiano de quem vive e trabalha nesse meio, sejam usurios ou administradores.
A figura 7.1 mostra um ambiente onde as informaes so centralizadas em nico
servidor. O usurio acessa um servidor e este efetua a autenticao por meio das informaes
armazenadas no servidor de diretrio, o usurio precisa lembrar apenas de uma informao de
login e senha, pois todos os servidores da rede iro consultar a mesma base, a que est no
servidor de diretrio. Para o administrador tudo fica mais fcil, pois agora existe apenas um
local da rede onde todas as informaes dos usurios estaro armazenadas.

Figura 7.1 Autenticao com LDAP
Fonte: Figura elaborada pelo autor com base na reviso bibliogrfica
Servidor de banco de dados
Servidor de login
Servidor de E-mail
Administrador
de rede
Servidor de Diretrio
Informaes
do usurio

82
A utilizao de servios de diretrios tem sido uma alternativa cada vez mais
difundida no meio computacional para minimizar problemas gerados pelo aumento cada vez
maior das inovaes tecnolgicas, fazendo com que o ambiente computacional torne-se mais
amigvel s pessoas que o utilizam. A cada dia novos sistemas so desenvolvidos, como
sistemas financeiros, sistemas de rede e muitos outros, trazendo facilidades para a gesto de
uma empresa, mas tambm dificuldades novas para os administradores. So mais informaes
a serem armazenadas, que os usurios precisam ter sempre nas mos e que estejam dispor
de todos de forma mais fcil.
A tecnologia mais utilizada atualmente a do protocolo LDAP, por ser uma tecnologia
aberta que vem sendo amadurecida ao longo dos anos e com constantes atualizaes. Por
esses motivos, esse documento ilustrou o funcionamento deste protocolo, alm de demonstrar
uma implementao que vem sendo realizada no ambiente da SOCIESC, por meio das
ferramentas livres existentes, como forma de difundir a sua utilizao e gerar confiana para
qualquer pessoa que queira se aventurar no mundo das informaes centralizadas.
A implementao realizada teve como premissas centralizar o mximo de informaes
possveis, e que as ferramentas utilizadas pudessem ser atualizadas sem que gerassem impacto
no transcorrer das atividades, ou seja, sem que fosse preciso refazer as configuraes de tais
ferramentas depois de uma atualizao.
Atualmente este servio est em execuo no domnio de rede conhecido como
ENSINO, onde todas as informaes dos alunos esto sendo armazenadas. Em experimentos
realizados em laboratrio foi possvel centralizar as informaes dos domnios de rede
existentes na empresa, SOCIESC e ENSINO, em um nico chamado JVE, alm de conseguir
efetuar a autenticao para acesso Internet diretamente no diretrio de informaes.
No foi possvel ainda integrar os servios de e-mail devido forma com que ele est
implementado. Para tal, novas pesquisas devero ser realizadas no futuro para que possa ser
definida uma forma de como integr-lo. Os sistemas financeiro e acadmico dependem de

83
mudanas em seus programas de autenticao e armazenamento de informaes de usurios
para que possam interagir com o sistema proposto. Conversaes vm sendo realizadas junto
aos fornecedores dos softwares para que em conjunto consiga-se efetuar as modificaes
necessrias.
Depois de comprovada a eficincia da implementao em laboratrio, decidiu-se
realizar um plano piloto nas unidades da SOCIESC em Curitiba e So Bento do Sul, a fim de
coletar informaes da nova implementao em um ambiente real. Dessa forma, ser possvel
verificar os problemas que podero surgir e solucion-los para que, quando possvel, o
ambiente da unidade de Joinville possa tambm ser migrado. Esta migrao ser feita
gradativamente, sendo realizada por departamentos.
importante lembrar que uma mudana como esta deve ser realizada com muita
responsabilidade, afinal, ser preciso em alguns casos, modificar a forma como as pessoas
trabalham. Portanto, cautela muito importante. Devem ser verificados alguns pontos
importantes antes de seguir num processo como este, tais como: descrever o ambiente e
analisar se a soluo ser vivel e no trar traumas empresa. Definido este ponto, deve-se
implementar o plano piloto para se avaliar os resultados; escolher bem as ferramentas a serem
utilizadas na implementao; definir os servios a serem integrados e realizar este processo
gradativamente.
Um ponto importante que no pode ser esquecido a segurana. O protocolo prov
vrias formas de implementar segurana na implementao, mas um item bsico quando todas
as informaes esto centralizadas a senha. No se pode esquecer que a partir de uma
implementao como essa, todas as informaes podero ser acessadas por meio de uma
nica senha, portanto uma poltica rgida de controle dever ser implantada. As senhas, a
partir de agora, precisaram tomar um grau de importncia ainda maior. No adianta o
protocolo permitir a utilizao de vrios mtodos de criptografia se a senha for fraca. Ser
preciso uma conscientizao junto aos usurios a respeito da importncia de sua senha.

84
preciso dar ateno especial capacidade do servidor a ser utilizado. Aps a
implementao percebeu-se um aumento na utilizao de memria e processamento na
mquina, e esta utilizao aumenta medida que mais usurios acessam o servidor, isto deve-
se utilizao da base de dados para armazenamento das informaes. Por meio de destes
realizados, chegou-se concluso que a configurao mnima para que todo o sistema
funcionasse sem maiores problemas seria de um servidor com processador de 1GHZ e 1GB de
memria RAM, para atender a um pico mximo de 400 usurios, efetuando operaes de
logon, alterao de senha e operaes de leitura e gravao de arquivos armazenados.
Todo este projeto serve para evidenciar a facilidade de um ambiente onde as
informaes so centralizadas, como tambm as vrias mudanas que devem ser realizadas
neste ambiente.
preciso lembrar que uma das tarefas de um profissional de informtica inovar,
descobrir formas de facilitar o cotidiano de seus usurios e ainda reduzir custos sem causar
impacto relevante ao andamento natural da empresa onde trabalha. O estudo realizado neste
documento ilustra essa tarefa. possvel a reduo de custos, j que as ferramentas utilizadas
so todas de livre distribuio. Alm disso, uma implementao como esta pode ser utilizada
para substituir uma implantao que traz nus a empresa. Traz benefcios aos usurios pois
no preciso mais se preocupar com o alto grau de informaes para acessar os mais variados
servios dispostos no ambiente computacional.
Para trabalhos futuros, novas pesquisas podem ser desenvolvidas, a fim de realizar a
integrao de novos servios como o de e-mail e sistemas proprietrios como os que no
puderam ser integrados nesta pesquisa. Tambm o desenvolvimento de uma ferramenta de
administrao que contemple todas as operaes possveis, que seja fcil de manusear e
possua caractersticas voltadas para Internet, seria uma excelente linha para pesquisas.

85
REFERNCIAS

ACTIVE Directory. Disponvel em:
http://www.Microsoft.com/brasil/Windowsserver2003/tec_active.mspx. Acesso em 05 nov
2004.

BANFFY, Letcia. Active Directory - Criao de seu primeiro domnio Windows 2003.
Disponvel em: http://www.imasters.com.br/artigo.php?cn=1068&cc=46. Acesso em 30 out
2004.

BARLON, Thomas. Implementation and Practical Use of LDAP. Disponvel em:
http://www.redbooks.ibm.com/redbooks/pdfs/sg246193.pdf. Acesso em 03 nov 2004.

CAPELA, Michael. Entendendo o Diretrio Ativo do Windows 2000. (Software).
Disponvel em: http://www.clubedasredes.eti.br/soft0010.htm. Acesso em 10 nov 2004.

CARTER, Gerald. LDAP System Administration. United States of Amrica :O'Reilly &
Associates, 2003

CHADWICK, D. W. Understanding X.500 - The Directory. Disponvel em:
http://www.isi.salford.ac.uk/staff/dwc/Version.Web/Contents.htm. Acesso em 26 set 2004.

ECKSTEIN, Robert., COLLIER-BROWN, David., KELLY, Peter. Using Samba.
Disponvel em: http://www.oreilly.com/catalog/Samba/chapter/book/ch01_01.html. Acesso
em 25 out 2004.

ECKSTEIN, Robert., COLLIER-BROWN, David. Using Samba, 2nd Edition. Disponvel
em: http://us1.Samba.org/Samba/docs/using_Samba/toc.html. Acesso em 13 nov 2004.

ELSON, David. Linux Authentication Using OpenLDAP parte 1. Disponvel em:
http://www.securityfocus.com/infocus/1427 . Acesso em 20 set 2004.

HERTEL, Chris. Samba: An Introduction. Disponvel em:
http://ar.Samba.org/Samba/docs/SambaIntro.html. Acesso em 20 nov 2004.

HOWES, Timothy A. An X.500 and LDAP Database: Design and Implementation.
Disponvel em: http://www.openldap.org/pub/umich/xldbm.pdf. Acesso em 16 out 2004.

HOWES, Timothy A. The Lightweight Directory Access Protocol: X.500 Lite. Disponvel
em: http://www.openldap.org/pub/umich/ldap.pdf. Acesso em 20 out 2004.

ISERIES LDAP. Disponvel em:
http://www1.ibm.com/servers/eserver/iseries/ldap/ldapspec.htm. Acesso em 07 nov 2004.

KANIES, Luke A. An Introduction to LDAP. Disponvel em:
http://www.onlamp.com/pub/a/onlamp/2001/08/16/ldap.html. Acesso em 21 set 2004.

86
LEMAIRE, Jrme Tournier Olivier. The Linux Samba-OpenLDAP Howto (Revision:
1.6). Disponvel em: http://www.idealx.org/prj/Samba/smbldap-howto.en.html#htoc10.
Acesso em 01 nov 2004.

LIGHTWEIGHT Directory Access Protocol. Disponvel em:
http://www.ldap.liceu.com.br/conceitos/porque.htm. Acesso em 25 out 2004.

MARIMOTO, Carlos E. Configurando o Squid e monitorando as pginas acessadas com
o sarg. Disponvel em: http://www.guiadohardware.net/linux/dicas/71.htm. Acesso em 30 out
2004.

MINASI, Mark. et al. Dominando Windows 2000 Server A Bblia. So Paulo. Makron
Books. 2001.

OPENLDAP Project. OpenLDAP 2.2 Administrator's Guide. Disponvel em:
http://www.openldap.org/doc/admin22/guide.html. Acesso em 02 set 2004.

SUN Java System Directory Server Enterprise Edition. Disponvel em:
http://wwws.sun.com/software/products/directory_srvr_ee/index.html. Acesso em 09 nov
2004.

TERPSTRA, John H. Samba 3 Example Practical Exercises to Successful
Deployment. New Jersey: Prentice Hall PTR, 2004.

TUTTLE, Steve. et al. Understanding LDAP. Design and Implementation. Disponvel em:
http://www.redbooks.ibm.com/redbooks/pdfs/sg244986.pdf. Acesso em 03 nov 2004.

UNIVERSITY OF MICHIGAN. The SLAPD and SLURPD Administrators Guide.
Michigan, 1996.

UNIVERSITY OF MICHIGAN. The SLAPD and SLURPD Administrators Guide.
Disponvel em: http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html. Acesso em 05
nov 2004.

VERNOOIJ, Jelmer R., TERPSTRA, John H., CARTER, Gerald. The Official Samba-3
HOWTO and Reference Guide. Disponvel em:
http://us1.Samba.org/Samba/docs/man/Samba-HOWTO-Collection/. Acesso em 11 nov 2004.

WAHL, M. et al. RFC-2252-Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions. Disponvel em: http://www.rfc-editor.org/rfc/rfc2252.txt. Acesso em 25
out 2004.

WAHL, M. RFC-2256-A Summary of the X.500(96) User Schema for use with LDAPv3.
Disponvel em: http://www.rfc-editor.org/rfc/rfc2256.txt. Acesso em 19 out 2004.

WAHL, M., HOWES, T., KILLE, S. RFC-2251-Lightweight Directory Access Protocol
(v3). Disponvel em: http://www.rfc-editor.org/rfc/rfc2251.txt. Acesso em: 21 out 2004.

WEIDER,C., REYNOLDS, J. RFC-1308-Executive Introduction to Directory Services
Using the X.500 Protocol. Disponvel em: http://www.rfc-editor.org/rfc/rfc1308.txt. Acesso
em: 19 out 2004.

87
YEONG, W., HOWES, T., KILLE, S. RFC-1777-Lightweight Directory Access Protocol.
Disponvel em: http://www.rfc-editor.org/rfc/rfc1777.txt. Acesso em 18 out 2004.

YEONG, W., HOWES, T., KILLE, S. RFC-1487-X.500 Lightweight Directory Access
Protocol. Disponvel em: http://www.rfc-editor.org/rfc/rfc1487.txt. Acesso em 18 out 2004.

ZEILENGA, K. RFC-3494 - Lightweight Directory Access Protocol version 2 (LDAPv2)
to Historic Status. Disponvel em: http://www.rfc-editor.org/rfc/rfc3494.txt. Acesso em 15
out 2004.

88
GLOSSRIO

.Net - Linguagem de programao desenvolvida pela Microsoft.
ACL - Access Control Lists.
APT - Advanced Package Tool.
ASCII - American Standard Code for Information Interchange.
ASN.1 - Abstract Syntax Notation.
CCITT - Consultative Committee on International Telephony and Telegraphy.
DAP - Directory Access Protocol.
DEN - Directory Enable Networks.
DIGEST-MD5 - Tipo de algoritmo de criptografia.
DIT - Data Information Tree.
DN - Distingueshed Name.
DNS - Domain Name Service.
DOS - Primeiro sistema operacional da Microsoft.
DSML - Directory Services Markup Language.
ECMA - European Computers Manufacturing Association.
IBM DB2 - SGBD proprietrio da IBM.
InterNic - Internets Netowrk Information Center.
ISO - International Standards Organization.
ITU-T - International Telecommunication Union.
Java - Linguagem de programao desenvolvida pela SUN.
Kerberos - Protocolo desenvolvido para fornecer autenticao em aplicaes cliente/servidor
LDAPv3 - Lightweight Directory Access Protocol Version 3.
LINUX - Sistema operacional baseado no UNIX.
LSB - Linux Standard Base.
META Group's - Grupo de consultoria, alm de outras atividades tambm realiza testes de
tecnologias existentes no mercado.
NSS - Name Service Switch.
OID - Object IDentifier.
OSI - Open System Interconnection.
PAM - Pluggable Authentication Modules Mdulos criados para fornecer outros mtodos de

89
autenticao para os sistemas Linux.
PDU - Protocol Data Units.
PERL - Practical Extraction and Reporting Language Linguagem de programao utilizada
em servidores UNIX, muito difundida entre desenvolvedores de Internet.
RDN - Relative Distingueshed Name.
RFC - Request For Comments.
RPM - Red Hat Package Manager.
SAM - Security Account Manager.
SAMBA - Software de integrao de redes Linux com Windows.
SASL - Simple Authentication and Security Layer.
SGBD - Sistemas de Gerenciadores de Banco de Dados.
SMB - Server Message Block.
SOAP - Simple Object Access Protocol.
SOCIESC - Sociedade Educacional de Santa Catarina.
SSL - Secure Socket Layer.
Strings - Cadeias de caracteres.
T.61 - Padro de caracteres utilizados em desenvolvimento de software.
TCP/IP - Transmission Control Protocol/Internet Protocol protocolo de comunicao de
uma rede.
Tivoli Directory Server - Servidor de diretrio desenvolvido pela IBM.
UNIX - Um dos primeiros sistemas operacionais desenvolvidos.
User Manager - Gerenciador de usurios do Windows NT.
UTF-8 - Padro de caracteres utilizado para desenvolvimento de softwares.
XML - Extensible Markup Language.

90
ANEXOS

Anexo I Apresentao realizada no 2 Congresso Catarinense de Software Livre
Anexo II Configuraes realizadas no arquivo slapd.conf
Anexo III Arquivos LDIF gerados pelos scripts do pacote migration-tools
Anexo IV Alteraes realizadas para que os clientes efetuem o logon utilizando LDAP
Anexo V Alteraes realizadas no SAMBA e LDAP para que possam interagir
Anexo VI Alteraes realizadas no smbldap-tools para que possa gravar as
informaes corretamente na base LDAP

91
Anexo I Apresentao realizada no 2 Congresso Catarinense de Software Livre

Case SOCI ESC - LDAP
Acadmico do 8 perodo do curso de
Bacharelado em Sistemas de Informao do
Instituto Superior Tupy IST
Tcnico em Informtica formado pela Escola
Tcnica Tupy
Administrador de Redesda Sociesc
Usurio Linux desde 2000

Quem a Sociesc?
Sociedade Educacional de Santa Catarina
Entidade mantenedora do Instituto Superior Tupy,
Escola Tcnica Tupy e Colgio Tupy

Qual a minha inteno aqui?
???????

Servio de Diretrio
Banco de Dadosespecializado em leitura
No suporta operaes complexas
Pensem em uma agenda Telefnica...

X.500 DAP (Data Access Protocol)
Protocolo pesado, opera sobre toda a pilha de
protocolos OSI
Requer alta demanda computacional

LDAP (Lightweight Directory Access Protocol)
Protocolo Leve de acesso a diretrio
Opera sobre TCP/ IPou outros tiposde servio
orientado a conexo
Foi criado para popularizar a utilizao deste
tipo de conceito

92

Por que implementar este tipo de servio?
Custos
Otimizao
Usurios felizes
Administradores felizes!!!
Aprendizado...

Idia inicial...
Utilizar o LDAP para guardar todas as informaes
de acesso a rede para osalunos
Fazer com que as esta es de trabalho
Windows conseguissem acesso s informaes
Depois...
Conseguir fazer com que os outros servios
acessem estas informaes

Reflita sobre alguns pontosantes de prosseguir?
Defina sua inteno
Descreva o ambiente onde deseja implementar este
servio
Verifique se traz benefcios

Ambiente Sociesc
Servidor Windows
Rede Corporativa
Servidor de Correio
Webmail
Servidor Samba
Rede Ensino
Servidor de Banco
de Dados
Usurios em todos os servidores, gerando redundncia, inconsistncia e
dificuldades de administrao.

Autenticao hoje...
Servidor Windows
Rede Corporativa
Servidor de Correio
Webmail
Servidor Samba
Rede Ensino
Servidor de Banco
de Dados
Estao de trabalho windows

Autenticao no
futuro
Servidor Windows
Rede Corporativa
Servidor de Correio
Webmail
Servidor Samba
Rede Ensino
Servidor de Banco
de Dados
Servidor LDAP
Estao de trabalho windows

93

Definio da arvore de
diretrios
dc=sociesc
dc=com
dc=br
ou=professores ou=computadores
uid=edson
Usurio
Unidade organizacional
Organizao
ou=alunos

Softwares utilizados
Conectiva Linux 9.0
Openldap 2.1.21
Samba-2.2.8a
Smbldap-tools-0.8.4

Configurao Openldap / etc/ openldap/ slapd.conf
include / etc/ openldap/ schema/ samba.schema
suffix " dc= sociesc,dc= com,dc= br"
rootdn " cn= admin,dc= sociesc,dc= com,dc= br"
sizelimit 100000
Timelimit 3600

accessto dn= *
by dn= " cn= admin,dc= sociesc,dc= com,dc= br" write
by self write
by * read

Configurao Openldap / etc/ ldap.conf
host 127.0.0.1
base dc= sociesc,dc= com,dc= br
binddn cn= admin,dc= sociesc,dc= com,dc= br
bindpw * * * * *
rootbinddn cn= admin,dc= sociesc,dc= com,dc= br
port 389

drwxr-s--- 4 7835 501 4096 Set 22 19:37 a20048919/
drwxr-s--- 3 7837 501 4096 Set 14 19:58 a20048972/
drwxr-s--- 5 7845 501 4096 Set 29 20:38 a20048983/
drwxr-s--- 2 6407 501 4096 Ago 13 16:38 a20035831/

94

drwxr-s--- 4 a2004891 prof 4096 Set 22 19:37 a20048919/
drwxr-s--- 2 a2003583 prof 4096 Ago 13 16:38 a20035831/

Instalao do Samba
Tentativas...
Samba-2.2.9a
Samba-3.0.0
Funcionou
Samba-2.2.8a

Importante na instalao do samba
./ configure --with-ldap with-ldapsam
Existem outros parmetrosque podem ser
adicionados dependendo da funcionalidade
que se deseja no servidor

Configuraes no arquivo smb.conf
ldap suffix = " dc= sociesc,dc= com,dc= br"
ldap admin dn = " cn= admin,dc= sociesc,dc= com,dc= br"
ldap filter = " (&(uid= %u)(objectclass= sambaAccount))"
ldap port = 389
ldap server = 127.0.0.1
add user script = / usr/ local/ sbin/ smbldap-useradd.pl -w %u
passwd program = / usr/ local/ sbin/ smbldap-passwd.pl -o %u
passwd chat = * new* password* %n\ n * new* password*
%n\ n * successfully*
unix password sync = yes

Instalao do Smbldap-tools-0.8.4
Descompactado na pasta / usr/ local/ sbin
O smbldap-tools precisa do perl para rodar e
mais...
ln -s / usr/ local/ sbin/ smbldap-*
/ usr/ lib/ perl5/ 5.8.0/

Instalao do Smbldap-tools-0.8.4
smbldap-groupadd.pl
smbldap-groupdel.pl
smbldap-groupmod.pl
smbldap-groupshow.pl
smbldap-useradd.pl
smbldap-userdel.pl
smbldap-usermod.pl
smbldap-usershow.pl
smbldap_conf.pm
smbldap_tools.pm

95

Adaptaes no smbldap-tools
smbldap_conf_professores.pm
smbldap_conf_alunos.pm
smbldap_conf_comp.pm

Adaptaes no smbldap_conf_professores.pm
$usersou = q(Professores);
$_userHomePrefix = q(/ home/ professores/ );

Definio da rvore de
diretrios
dc=sociesc
dc=com
dc=br
ou=professores ou=computadores
uid=edson
Usurio
Unidade organizacional
Organizao
ou=alunos

Finalizando configuraesSamba
smbpasswd -w senha
A senha deve ser a mesma
definida no arquivo slapd.conf,
ser utilizada para o samba
estabelecer uma comunicao
com o LDAP
Este parmentro identifica
que a senha gerada ser utilizada
para acesso a uma base LDAP, s
funciona se o Samba for compilado
com a opo --with-ldap

Finalizando configuraes Samba
smbpasswd -a root
A senha gerada ser utilizada para que
seja possvel por exemplo adicionar
uma estao de trabalho windows
ao domnio samba anteriormente criado

Utilizando Samba+ Ldap
smbldap-useradd.pl -w computador$
Criando a conta de um computador
no domnio samba, mas agora as
informaes esto sendo guardadas
na base LDAP

96

smbldap-useradd.pl -a edson
Criando uma conta de usurio
no domnio samba
Indica que o usurio criado ser um usurio windows, existem
vrios outros parmetros que podem ser utilizados

smbldap-passwd.pl edson
smbpasswd edson
A senha do usurio pode ser alterada
destas duas formas. Pelo script do smbldap-tools
ou pelo smbpasswd, como o Samba foi compilado
com a opo with-ldap, ele entende que o usurio
pode estar em uma base LDAP.

Estamos testando...
Autenticao do proxy
Autenticao para o e-mail

Nem tudo so flores....
Alta utilizao de processamento e memria
causava instabilidade do servio
Computadores no acessavam o dominio
Usurios no conseguiam efetuar o logon
Perda da base

Como resolvemos....
Alta utilizao de processamento e memria
Dobramos a memria do servidor
e o servio estabilizou

Como resolvemos....
Computadores no acessavam o domnio
Usurios no conseguiam efetuar o logon
Aumentamos o valor da varivel sizelimit de
500 para 100000

97

include / etc/ openldap/ schema/ samba.schema
suffix " dc= sociesc,dc= com,dc= br"
rootdn " cn= admin,dc= sociesc,dc= com,dc= br"
sizelimit 100000
Timelimit 3600

Como resolvemos....
Perda da base
Fazemos um backup dirio da base
(/var/lib/openldap-data) e efetuamos uma
reindexao do banco, tambm diariamente,
com o comando slapindex -v

Lies que podemos tirar desta nossa aventura
Simule em laboratrio
Por mais que voc simule, nunca ser com no
ambiente de produo
Leia com mais ateno os manuais que esto com os
softwares
Tente e no tenha medo de errar....porque seno
voc no vai ter coragem de se enfiar nesta...

Referncias
http:/ / www.samba.org
http:/ / www.openldap.org
Pedro Delfino dos Santos Neto, Integrao de rede
Linux e Windows com Samba e LDAP
http:/ / freshmeat.net/ projects/ smbldap-tools/

edson@sociesc.com.br

98
Anexo II Configuraes realizadas no arquivo slapd.conf

# $OpenLDAP: pkg/ldap/servers/slapd/slapd.conf,v 1.23.2.8 2003/05/24
23:19:14 kurt Exp $
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/java.schema
include /etc/openldap/schema/krb5-kdc.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/openldap.schema

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org

pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args

# Load dynamic backend modules:
# modulepath /usr/sbin/openldap
# moduleload back_bdb.la
# moduleload back_ldap.la
# moduleload back_ldbm.la
# moduleload back_passwd.la
# moduleload back_shell.la

# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64

# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy is:
# Allow read by all
#
# rootdn can always write!

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

99
# ldbm database definitions
#######################################################################

database bdb
suffix "dc=sociesc,dc=com,dc=br"
rootdn "cn=root,dc=sociesc,dc=com,dc=br"
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw openldap
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/openldap-data

# checkpoint configuration
# see the manpage and the Berkeley DB documentation for details
# checkpoint <kbyte> <min>
# The checkpoint will occur if either <kbyte> data has been written or
<min>
# minutes have passed since the last checkpoint.
# checkpoint 512 30

# Indices to maintain
index objectClass eq
# others you should really consider (at least the "eq" one)
#index uid,uidNumber,gidNumber,memberUid eq
#index cn,mail,surname,givenname eq,sub

# other indexes which are useful for Samba:
#index displayName pres,sub,eq
#index SambaSID eq
#index SambaPrimaryGroupSID eq
#index SambaDomainName eq

# ACLs
access to attr=userPassword
by anonymous auth
by self write
by * none

access to attr=shadowLastChange
by self write
by * read

# if using Samba, one has to protect these attributes as well
# allow the "ldap admin dn" access, but deny everyone else
#access to attrs=SambaLMPassword,SambaNTPassword
# by dn="cn=Samba Admin,ou=People,dc=my-domain,dc=com" write
# by * none

access to *
by * read

100
Anexo III Arquivos LDIF gerados pelos scripts do pacote migration-tools

#base.ldif

dn: dc=sociesc,dc=com,dc=br
dc: sociesc
objectClass: top
objectClass: domain

dn: ou=Hosts,dc=sociesc,dc=com,dc=br
ou: Hosts
objectClass: top
objectClass: organizationalUnit

dn: ou=People,dc=sociesc,dc=com,dc=br
ou: People
objectClass: top

dn: ou=Group,dc=sociesc,dc=com,dc=br
ou: Group
objectClass: top

#passwd.ldif

dn: uid=edson,ou=People,dc=sociesc,dc=com,dc=br
uid: edson
cn: Edson Machado de Sousa
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$1$VR6zNkVt$wCFKP4SI6E7J7F.nerGwN1
shadowLastChange: 12753
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 500
gidNumber: 500
homeDirectory: /home/edson
gecos: Edson Machado de Sousa

#grupos.ldif

dn: cn=users,dc=sociesc,dc=com,dc=br
objectClass: posixGroup
objectClass: top
cn: users
userPassword: {crypt}x
gidNumber: 100

101
Anexo IV Alteraes realizadas para que os clientes efetuem o logon utilizando LDAP

#%PAM-1.0
#/etc/pam.d/login

auth sufficient /lib.security/pam_ldap.so use_first_pass
account sufficient /lib/security/pam_ldap.so
auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_stack.so service=system-auth
auth required /lib/security/pam_nologin.so
account required /lib/security/pam_stack.so service=system-auth
password required /lib/security/pam_stack.so service=system-auth
session required /lib/security/pam_stack.so service=system-auth
session optional /lib/security/pam_console.so

#/etc/nsswitch.conf
passwd: files nisplus ldap
shadow: files nisplus ldap
group: files nisplus ldap

hosts: files nisplus dns

bootparams: nisplus [NOTFOUND=return] files

ethers: files
netmasks: files
networks: files
protocols: files nisplus ldap
rpc: files
services: files nisplus ldap

netgroup: files nisplus ldap

publickey: nisplus

automount: files nisplus ldap
aliases: files nisplus

102
Anexo V Alteraes realizadas no SAMBA e LDAP para que possam interagir

#/etc/samba/smb.conf
[global]
workgroup = JVE
server string = Servidor do dominio JVE
printcap name = cups
load printers = yes
printing = cups
log file = /var/log/samba/%m.log
max log size = 50
debug level = 1
security = user
encrypt passwords = yes
smb passwd file = /etc/Samba/smbpasswd
username map = /etc/Samba/smbusers
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
# see the smb.conf(5) manpage for other important backends, such as
tdbsam and ldap
passdb backend = ldapsam:ldap://odisseo.SOCIESC
add user script = /var/lib/Samba/sbin/smbldap-useradd.pl -a -m '%u'
delete user script = /var/lib/Samba/sbin/smbldap-userdel.pl '%u'
add group script = /var/lib/Samba/sbin/smbldap-groupadd.pl -p '%g'
delete group script = /var/lib/Samba/sbin/smbldap-groupdel.pl '%g'
add user to group script = /var/lib/Samba/sbin/smbldap-groupmod.pl -m
'%u' '%g'
delete user from group script = /var/lib/Samba/sbin/smbldap-
groupmod.pl -x '%u' '%g'
set primary group script = /var/lib/Samba/sbin/smbldap-usermod.pl -g
'%g' '%u'
add machine script = /var/lib/Samba/sbin/smbldap-useradd.pl -w '%u'
logon script = scripts\logon.bat
logon path = \\%L\profiles\%U
logon drive = X:
os level = 33
domain master = true
local master = yes
domain logons = Yes
preferred master = Yes
wins support = Yes
ldap suffix = dc=sociesc,dc=com,dc=br
ldap machine suffix = ou=Hosts
ldap user suffix = ou=People
ldap group suffix = ou=Group
ldap idmap suffix = ou=Idmap
ldap admin dn = cn=root,dc=sociesc,dc=com,dc=br
idmap backend = ldap:ldap://odisseo.sociesc
idmap uid = 10000-20000
idmap gid = 10000-20000

# $OpenLDAP: pkg/ldap/servers/slapd/slapd.conf,v 1.23.2.8 2003/05/24
23:19:14 kurt Exp $
#
include /etc/openldap/schema/samba.schema
index objectClass eq
index uid,uidNumber,gidNumber,memberUid eq
index sambaSID eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq
index default sub

103
Anexo VI Alteraes realizadas no smbldap-tools para que possa gravar as
informaes corretamente na base LDAP

#/etc/smbldap-tools/smbldap.conf
############################################################################
##
#
# General Configuration
#
############################################################################
##

# Put your own SID
# to obtain this number do: net getlocalsid
SID="S-1-5-21-3640286243-1420693789-3549743140"

############################################################################
##
#
# LDAP Configuration
#
###########################################################################

# Notes: to use to dual ldap servers backend for Samba, you must patch
# Samba with the dual-head patch from IDEALX. If not using this patch
# just use the same server for slaveLDAP and masterLDAP.
# Those two servers declarations can also be used when you have
# . one master LDAP server where all writing operations must be done
# . one slave LDAP server where all reading operations must be done
# (typically a replication directory)

# Ex: slaveLDAP=127.0.0.1
slaveLDAP="127.0.0.1"
slavePort="389"

# Master LDAP : needed for write operations
# Ex: masterLDAP=127.0.0.1
masterLDAP="127.0.0.1"
masterPort="389"

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

# How to verify the server's certificate (none, optional or require)
# see "man Net::LDAP" in start_tls section for more details
verify=""

# CA certificate
cafile=""

# certificate to use to connect to the ldap server
clientcert=""

# key certificate to use to connect to the ldap server
clientkey=""

104
# LDAP Suffix
# Ex: suffix=dc=IDEALX,dc=ORG
suffix="dc=sociesc,dc=com,dc=br"

# Where are stored Users
# Ex: usersdn="ou=Users,dc=IDEALX,dc=ORG"
usersdn="ou=People,${suffix}"

# Where are stored Computers
# Ex: computersdn="ou=Computers,dc=IDEALX,dc=ORG"
computersdn="ou=Hosts,${suffix}"

# Where are stored Groups
# Ex groupsdn="ou=Groups,dc=IDEALX,dc=ORG"
groupsdn="ou=Group,${suffix}"

# Where are stored Idmap entries (used if Samba is a domain member server)
# Ex groupsdn="ou=Idmap,dc=IDEALX,dc=ORG"
idmapdn="ou=Idmap,${suffix}"

# Where to store next uidNumber and gidNumber available
SambaUNIXIdPooldn="cn=NextFreeUNIXId,${suffix}"

# Default scope Used
scope="sub"

# UNIX password encryption (CRYPT, MD5, SMD5, SSHA, SHA)
hash_encrypt="SSHA"

# if hash_encrypt is set to CRYPT, you may set a salt format.
# default is "%s", but many systems will generate MD5 hashed
# passwords if you use "$1$%.8s". This parameter is optional!
crypt_salt_format="%s"

############################################################################
##
#
# UNIX Accounts Configuration
#
############################################################################
##

# Login defs
# Default Login Shell
# Ex: userLoginShell="/bin/bash"
userLoginShell="/bin/bash"

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

# Gecos
userGecos="System User"

# Default User (POSIX and Samba) GID
defaultUserGid="513"

# Default Computer (Samba) GID
defaultComputerGid="515"

# Skel dir

105
skeletonDir="/etc/skel"

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

############################################################################
##
#
# SAMBA Configuration
#
############################################################################
##

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

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

# The default Home Drive Letter mapping
# (will be automatically mapped at logon time if home directory exist)
# Ex: H: for H:
userHomeDrive="X:"

# The default user netlogon script name (%U username substitution)
# if not used, will be automatically username.cmd
# make sure script file is edited under dos
# Ex: %U.cmd
# userScript="startup.cmd" # make sure script file is edited under dos
userScript="%U.cmd"

# Domain appended to the users "mail"-attribute
# when smbldap-useradd -M is used
mailDomain="mail.sociesc.com.br"

############################################################################
##
#
# SMBLDAP-TOOLS Configuration (default are ok for a RedHat)
#
############################################################################
##

# Allows not to use smbpasswd (if with_smbpasswd == 0 in smbldap_conf.pm)
but
# prefer Crypt::SmbHash library
with_smbpasswd="0"
smbpasswd="/usr/bin/smbpasswd"

106

#/etc/smbldap-tools/smbldap_bind.conf
############################
# Credential Configuration #
############################
# Notes: you can specify two differents configuration if you use a
# master ldap for writing access and a slave ldap server for reading
access
# By default, we will use the same DN (so it will work for standard Samba
# release)
slaveDN="cn=root,dc=sociesc,dc=com,dc=br"
slavePw="openldap"
masterDN="cn=root,dc=sociesc,dc=com,dc=br"
masterPw="openldap"

TD EdsonMachadodeSousa 2004 2

Enviado por

Dados do documento

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

TD EdsonMachadodeSousa 2004 2

Enviado por

Direitos autorais:

Formatos disponíveis

SOCIEDADE EDUCACIONAL DE SANTA CATARINA - SOCIESC

INSTITUTO SUPERIOR TUPY

Você também pode gostar