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

IMPLEMENTAO DE UM SERVIO DE DIRETRIOS UTILIZANDO O PROTOCOLO LDAP

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

IMPLEMENTAO DE UM SERVIO DE DIRETRIOS UTILIZANDO O PROTOCOLO LDAP

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

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)

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.

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.

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

LISTA DE TABELAS

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

SUMRIO

1 2 2.1 3 3.1 3.2 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.4 4 4.1 4.1.1 4.1.2 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.3 4.3.1 4.4 4.5 4.5.1 4.6 4.7 4.8 4.9 4.10 5 5.1 5.2 5.3 5.4 6 6.1 6.1.1 6.1.2 6.1.3 6.1.4 6.1.5 6.1.6 6.1.7 6.1.8 6.2 6.2.1 6.2.2 6.2.3 6.2.4

INTRODUO........................................................................................................................................... 10 SERVIO DE DIRETRIO...................................................................................................................... 13 PROTOCOLO X.500 (DAP) ................................................................................................................... 16 CONHECENDO O LDAP.......................................................................................................................... 19 LDAPV3.................................................................................................................................................. 20 LIGHTWEIGHT ..................................................................................................................................... 22 DIRECTORY .......................................................................................................................................... 24 Tipos de informaes que podem ser armazenadas em um diretrio ldap ..................................... 26 Organizao das informaes ........................................................................................................ 27 Referenciando uma informao ...................................................................................................... 28 Acessando as informaes .............................................................................................................. 29 Segurana das informaes ............................................................................................................ 29 ACCESS PROTOCOL ............................................................................................................................ 30 ARQUITETURA DO LDAPV3 ................................................................................................................. 31 MODELOS LDAP ................................................................................................................................... 31 Modelo do protocolo....................................................................................................................... 31 Modelos de dados (data model) ...................................................................................................... 33 ELEMENTOS DO PROTOCOLO .......................................................................................................... 35 Envelope da mensagem................................................................................................................... 35 Tipos de string ................................................................................................................................ 38 Distinguished name and relative distinguished name (DN/RDN)................................................... 38 Resultado da mensagem.................................................................................................................. 39 OPERAO DE CONEXO ................................................................................................................. 41 Resposta de desconexo.................................................................................................................. 42 OPERAO DE DESCONEXO.......................................................................................................... 43 OPERAO DE BUSCA ....................................................................................................................... 43 Requisio de busca........................................................................................................................ 44 OPERAO DE MODIFICAO ........................................................................................................ 45 OPERAO DE ADIO ..................................................................................................................... 46 OPERAO DE REMOO................................................................................................................. 47 OPERAO DE COMPARAO ........................................................................................................ 47 OPERAO DE ABANDONO.............................................................................................................. 48 SERVIDORES DE DIRETRIO LDAP .................................................................................................. 49 ACTIVE DIRECTORY........................................................................................................................... 49 OPENLDAP ............................................................................................................................................ 51 IBM TIVOLI DIRECTORY SERVER.................................................................................................... 52 NOVELL EDIRECTORY ....................................................................................................................... 53 IMPLEMENTAO.................................................................................................................................. 55 FERRAMENTAS UTILIZADAS ........................................................................................................... 57 Conectiva Linux .............................................................................................................................. 58 Openldap......................................................................................................................................... 59 Samba ............................................................................................................................................. 59 Pacote Migrationtools .................................................................................................................... 61 Smbldap-tools ................................................................................................................................. 61 PAM ................................................................................................................................................ 62 NSS.................................................................................................................................................. 63 APT ................................................................................................................................................. 63 INSTALAO E CONFIGURAO.................................................................................................... 65 Definindo o ambiente ...................................................................................................................... 66 Openldap......................................................................................................................................... 67 Migrationtools ................................................................................................................................ 70 Samba ............................................................................................................................................. 73

6.2.5 6.2.6 6.2.7 6.2.8 7

Smbldap-tools ................................................................................................................................. 74 Integrao do servidor Proxy ......................................................................................................... 76 Adicionando um computador ao domnio ....................................................................................... 78 Administrao da base LDAP......................................................................................................... 79 CONSIDERAES FINAIS ..................................................................................................................... 80

REFERNCIAS .................................................................................................................................................. 85 GLOSSRIO ....................................................................................................................................................... 88 ANEXOS .............................................................................................................................................................. 90

10

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.

Informaes do usurio

Servidor de banco de dados

?
Informaes do usurio

Usurio Servidor de login Administrador de rede

Informaes do usurio

Servidor de E-mail

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

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

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.

Raz do domnio net com edu

A organizao

SOCIESC

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

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 CCITT Study Group VII, raise Question 35 ISO start work on Directories in SC21 WG4 First Joint Meeting is held (Melbourne) ISO Draft Proposal (DP) starts its ballot (3 months) ISO 2 DP is balloted (3 months) ISO Draft Standard is balloted (6 months)
nd

Data 1984 1984 Abril, 1986 Novembro, 1986 Julho, 1987 Dezembro, 1987

Work starts on the ('92) extensions to the ('88) joint Standard (Question 20 within CCITT SG Maro, 1988 VII) Final Editing Meeting of the ('88) joint Standard Access Control ('92) Provisional Draft Amendment (PDAM) is balloted (3 months) Outubro, 1988 Novembro, 1989

CCITT X.500 Blue Book Recommendations are published (The official CCITT version of the Janeiro, 1990 '88 Standard) Replication and remaining ('92) extension work PDAMs are balloted (3 months) ISO/IEC 9594 - The Directory is published (The official ISO version of the '88 Standard) ('92) extension work ISO second PDAMs ballot starts (3 months) ('92) extension work ISO DAMs are balloted (6 months) ('96) extension work starts Final Editing Meeting of 1992 extension work ISO/IEC 9594 (1993) - The Directory will be published (The official ISO version of the '93 Standard) Dezembro, 1990 Janeiro, 1991 Maio, 1991 Novembro, 1991 Maio, 1992 Outubro 1992 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

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 email, 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. X.500
Aplicao Apresentao Sesso
Camadas OSI

LDAP
Aplicao TCP IP UDP
Camadas TCP/IP

Transporte Rede Enlace Fsica

Fsica

mdia de rede

Figura 3.1 Operao dos protocolos DAP e LDAP Fonte: Figura elaborada com base no Ldap System Administrator, O Reilly.

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.

Cliente LDAP

Servidor LDAP

Armazenador de dados

Requisies e respostas do protocolo

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

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.

dc=net

dc=com

dc=edu

A organizao dc=exemplo

ou=usurios

ou=computadores

uid=paulo Unidade Organizacional

Usurio

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

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

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. Cliente LDAP
Requisio 1

Servidor LDAP

Requisio 2

Resposta 1

Requisio 3

Resposta 3

Resposta 2

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.

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). (Traduzido por mim).

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. (Traduzido por mim). 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), adminLimitExceeded (11), unavailableCriticalExtension (12), confidentialityRequired (13), saslBindInProgress (14), 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),

-- new -- new -- new -- new -- new

40

invalidCredentials insufficientAccessRights busy unavailable unwillingToPerform loopDetect -- 55-63 unused -namingViolation objectClassViolation notAllowedOnNonLeaf notAllowedOnRDN entryAlreadyExists objectClassModsProhibited -- 70 reserved for CLDAP -affectsMultipleDSAs -- 72-79 unused -other -- 81-90 reserved for APIs -matchedDN LDAPDN, errorMessage LDAPString, referral [3] Referral OPTIONAL }

(49), (50), (51), (52), (53), (54), (64), (65), (66), (67), (68), (69), (71), -- new (80) },

Fonte: Request For Comments RFC2251

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 } Fonte: Request For Comments RFC2251

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 } Fonte: Request For Comments RFC2251

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 } Fonte: Request For Comments RFC2251

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 } Fonte: Request For Comments RFC2251

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

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

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.

- login - senha 1

- login - senha 2

- login - senha 3

- login - senha 4

Servidor de e-mail

Servidor ERP/Sistema Acadmico

Servidor de login da rede corporativa

Servidor de login da rede de ensino

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

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 Fonte: Figura elaborada pelo autor na implementao em laboratrio

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 Fonte: Figura elaborada pelo autor na implementao em laboratrio

70

Figura 6.6 Configurando LDAP com authconfig Fonte: Figura elaborada pelo autor na implementao em laboratrio

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 Fonte: Figura elaborada pelo autor na implementao em laboratrio

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 Fonte: Figura elaborada pelo autor na implementao em laboratrio

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 Fonte: Figura elaborada pelo autor na implementao em laboratrio

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 Smbldap-groupadd Smbldap-groupdel Smbldap-groupmod Smbldap-groupshow Smbldap-migrate-accounts Smbldap-migrate-groups Smbldap-passwd Smbldap-populate Smbldap-useradd Smbldap-userdel Smbldap-usermod Smbldap-show Descrio Adiciona um novo grupo Remove um grupo existente Modifica informaes de um grupo Mostra informaes de um grupo Migra informaes de contas baseadas em Windows Migra informaes de grupos baseados em Windows Altera a senha de um usurio Cria uma base para rvore do diretrio Adiciona um novo usurio Remove um usurio existente Modifica informaes do usurio 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 Fonte: Figura elaborada pelo autor na implementao em laboratrio

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 smbldapuseradd 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 Fonte: Figura elaborada pelo autor na implementao em laboratrio

80

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.

Servidor de banco de dados

Informaes do usurio

Servidor de login

Servidor de Diretrio Administrador de rede

Servidor de E-mail

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

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 devese 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 SO CIESC - LDA P

Case SO CI ESC - LDA P

Edson Machado de Sousa A cadmico do 8 perodo do curso de Bacharelado em Sistemas de Informao do Instituto Superior Tupy IST Tcnico em Informtica formado pela Escola Tcnica Tupy A dministrador de Redes da 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

Case SO CIESC - LDA P

Case SO CI ESC - LDA P

Qual a minha inteno aqui?

Servio de Diretrio

???????

Banco de Dados especializado em leitura No suporta operaes complexas

Pensem em uma agenda Telefnica...

Case SO CIESC - LDA P

Case SO CI ESC - LDA P

X.500 DA P (Data A ccess Protocol)

LDA P (Lightweight Directory A ccess Protocol)

Protocolo pesado, opera sobre toda a pilha de protocolos OSI Requer alta demanda computacional

Protocolo Leve de acesso a diretrio Opera sobre TCP/ IP ou outros tipos de servio orientado a conexo

Foi criado para popularizar a utilizao deste tipo de conceito

92

Case SO CIESC - LDA P

Case SO CI ESC - LDA P

Por que implementar este tipo de servio?

Idia inicial...

Custos Otimizao Usurios felizes A dministradores felizes!!! A prendizado...

Utilizar o LDA P para guardar todas as informaes de acesso a rede para os alunos Fazer com que as esta es de trabalho Windows conseguissem acesso s informaes

Depois...

Conseguir fazer com que os outros servios acessem estas informaes

Case SO CIESC - LDA P

Case SO CI ESC - LDA P

Reflita sobre alguns pontos antes de prosseguir?

A mbiente Sociesc

Defina sua inteno Descreva o ambiente onde deseja implementar este servio V erifique se traz benefcios

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.

Case SO CIESC - LDA P

Case SO CI ESC - LDA P

A utenticao hoje...

A utenticao no futuro

Servidor LDAP

Servidor Windows Rede Corporativa

Servidor de Correio Webmail

Servidor Samba Rede Ensino

Servidor de Banco de Dados Servidor Windows Rede Corporativa Servidor de Correio Webmail Servidor Samba Rede Ensino Servidor de Banco de Dados

Estao de trabalho windows Estao de trabalho windows

93

Case SO CIESC - LDA P

Case SO CI ESC - LDA P

dc=com dc=br

Definio da arvore de diretrios

Organizao

Softwares utilizados

dc=sociesc ou=professores uid=edson ou=computadores ou=alunos

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

Unidade organizacional Usurio

Case SO CIESC - LDA P

Case SO CI ESC - LDA P

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

Configurao Openldap / etc/ openldap/ slapd.conf

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

Case SO CIESC - LDA P

Case SO CI ESC - LDA P

Configurao Openldap / etc/ ldap.conf

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--drwxr-s--drwxr-s--drwxr-s---

4 3 5 2

7835 7837 7845 6407

501 501 501 501

4096 4096 4096 4096

Set 22 19:37 a20048919/ Set 14 19:58 a20048972/ Set 29 20:38 a20048983/ A go 13 16:38 a20035831/

94

Case SO CIESC - LDA P

Case SO CI ESC - LDA P

Configurao Openldap / etc/ ldap.conf

Instalao do Samba

Tentativas...

drwxr-s--drwxr-s--drwxr-s--drwxr-s---

4 3 5 2

a2004891 a2004897 a2004898 a2003583

prof prof prof prof

4096 4096 4096 4096

Set 22 19:37 a20048919/ Set 14 19:58 a20048972/ Set 29 20:38 a20048983/ A go 13 16:38 a20035831/

Samba-2.2.9a Samba-3.0.0

Funcionou

Samba-2.2.8a

Case SO CIESC - LDA P

Case SO CI ESC - LDA P

Importante na instalao do samba

Configuraes no arquivo smb.conf

./ configure --with-ldap with-ldapsam

Existem outros parmetros que podem ser adicionados dependendo da funcionalidade que se deseja no servidor

ldap suffix = " dc= sociesc,dc= com,dc= br" ldap admin dn = " cn= admin,dc= sociesc,dc= com,dc= br" ldap filter = " (& (uid= %u)(objectclass= sambaA ccount))" 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

Case SO CIESC - LDA P

Case SO CI ESC - LDA P

Instalao do Smbldap-tools-0.8.4

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/

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

Case SO CIESC - LDA P

Case SO CI ESC - LDA P

A daptaes no smbldap-tools

A daptaes no smbldap_conf_professores.pm

smbldap_conf_professores.pm smbldap_conf_alunos.pm smbldap_conf_comp.pm

$usersou = q(Professores); $_userHomePrefix = q(/ home/ professores/ );

Case SO CIESC - LDA P

Case SO CI ESC - LDA P

Definio da rvore de diretrios

Organizao

dc=com dc=br dc=sociesc

Finalizando configuraes Samba

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

ou=professores uid=edson

ou=computadores

ou=alunos

Unidade organizacional Usurio

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

Case SO CIESC - LDA P

Case SO CI ESC - LDA P

Finalizando configuraes Samba

Utilizando Samba+ Ldap

smbpasswd -a root

smbldap-useradd.pl -w computador$

A senha gerada ser utilizada para que seja possvel por exemplo adicionar uma estao de trabalho windows ao domnio samba anteriormente criado

Criando a conta de um computador no domnio samba, mas agora as informaes esto sendo guardadas na base LDAP

96

Case SO CIESC - LDA P

Case SO CI ESC - LDA P

Utilizando Samba+ Ldap

Utilizando Samba+ Ldap

smbldap-useradd.pl

-a

edson

smbldap-passwd.pl smbpasswd edson

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

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.

Case SO CIESC - LDA P

Case SO CI ESC - LDA P

Estamos testando...

Nem tudo so flores....

A utenticao do proxy A utenticao para o e-mail

A lta utilizao de processamento e memria causava instabilidade do servio Computadores no acessavam o dominio Usurios no conseguiam efetuar o logon Perda da base

Case SO CIESC - LDA P

Case SO CI ESC - LDA P

Como resolvemos....

Como resolvemos....

A lta utilizao de processamento e memria

Computadores no acessavam o domnio Usurios no conseguiam efetuar o logon

Dobramos a memria do servidor e o servio estabilizou

Aumentamos o valor da varivel sizelimit de 500 para 100000

97

Case SO CIESC - LDA P

Case SO CI ESC - LDA P

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

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

Case SO CIESC - LDA P

Case SO CI ESC - LDA P

Lies que podemos tirar desta nossa aventura

Referncias

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

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

Edson Machado de Sousa

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 argsfile # # # # # # # /var/run/slapd/slapd.pid /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 objectClass: organizationalUnit dn: ou=Group,dc=sociesc,dc=com,dc=br ou: Group objectClass: top objectClass: organizationalUnit #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 account auth auth auth account password session session sufficient sufficient required required required required required required optional /lib.security/pam_ldap.so use_first_pass /lib/security/pam_ldap.so /lib/security/pam_securetty.so /lib/security/pam_stack.so service=system-auth /lib/security/pam_nologin.so /lib/security/pam_stack.so service=system-auth /lib/security/pam_stack.so service=system-auth /lib/security/pam_stack.so service=system-auth /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: netmasks: networks: protocols: rpc: services: netgroup: publickey: automount: aliases: files files files files nisplus ldap files files nisplus ldap files nisplus ldap nisplus files nisplus ldap 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/smbldapgroupmod.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 # see "man Net::LDAP" in start_tls section for more details cafile="" # certificate to use to connect to the ldap server # see "man Net::LDAP" in start_tls section for more details clientcert="" # key certificate to use to connect to the ldap server # see "man Net::LDAP" in start_tls section for more details 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"