Monografia Ldap

André Luiz Félix Pacheco Eduardo Luiz da Silva Luiz Gustavo Queiroga Pena Márcio Flávio da Silva Tiago Alves de Assis

Gerenciamento de Usuários em Ambiente Corporativo, Utilizando LDAP - Lightweight Directory Access Protocol

Ciência da Computação

FIPLAC – 2005.

André Luiz Félix Pacheco Eduardo Luiz da Silva Luiz Gustavo Queiroga Pena Márcio Flávio da Silva Tiago Alves de Assis

Gerenciamento de Usuários em Ambiente Corporativo, Utilizando LDAP - Lightweight Directory Access Protocol

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

2

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

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

3

TERMO DE APROVAÇÃO

Monografia apresentada e aprovada em __/__/__, pela banca examinadora constituída pelos professores:

Prof ... Prof ... Prof ...

FIPLAC , __ de ____________ de 2005.

4

SUMÁRIO Dedicatória................................................................................................................................................................3 Lista de figuras..........................................................................................................................................................8 Abstract.....................................................................................................................................................................9 Resumo....................................................................................................................................................................10 Capítulo I – Introdução...........................................................................................................................................11 1.1. Introdução....................................................................................................................................................11 1.2. Motivação.....................................................................................................................................................12 1.3. Objetivo Geral..............................................................................................................................................12 1.4. Objetivos Específicos...................................................................................................................................12 1.5. Metodologia.................................................................................................................................................13 Capítulo II – Diretórios...........................................................................................................................................14 2.1 - O que é um diretório...................................................................................................................................14 2.2 - Vantagens de usar um diretório..................................................................................................................15 2.3 - Diretórios distribuídos................................................................................................................................16 2.4 - Diretório Cliente E Servidor.......................................................................................................................17 Capítulo III – LDAP................................................................................................................................................19 3.1. Histórico do LDAP.......................................................................................................................................19 3.1.1. Precursores do LDAP................................................................................................................................19 3.1.2. Versões e características............................................................................................................................20 3.1.3. RFC’s que padronizam o LDAP...............................................................................................................21 3.1.4. O LDAP atualmente..................................................................................................................................23 3.2. LDAP Lightweight Directory Access Protocol............................................................................................23 3.3. LDAP: Protocolo ou diretório......................................................................................................................24 3.4. Arquitetura...................................................................................................................................................25 3.5. Modelos LDAP...........................................................................................................................................25 3.5.1. Modelo da informação..............................................................................................................................26 3.5.2. Modelo de nomes......................................................................................................................................26 3.5.3. Modelo Funcional.....................................................................................................................................27 3.5.4. Modelo de segurança.................................................................................................................................27 3.6. LDIF............................................................................................................................................................27 3.7. Classes de Objetos, Atributos e Esquemas...................................................................................................28 3.8. Segurança.....................................................................................................................................................31 3.8.1. Segurança no LDAP.................................................................................................................................32 3.8.2. Sem Autenticação.....................................................................................................................................33 3.8.3. Autenticação Básica.................................................................................................................................33 3.8.4. Autenticação simples e camada segura (SASL - Simple Authentication and Security Layer)................33 3.8.5. SSL e TLS................................................................................................................................................35 Cliente.....................................................................................................................................................................36 Servidor...................................................................................................................................................................36 3.8.6. Outros mecanismos de autenticação SASL..............................................................................................37 3.9. ACL.................................................................................................................................................................37 3.9.1. Autorização..............................................................................................................................................37 3.9.2. Políticas de Segurança..............................................................................................................................38 3.9.3. Definindo Listas de Controle de Acesso..................................................................................................38 3.9.4. Aspectos Gerais do modelo ACL para LDAP.........................................................................................39 3.9.5. Semântica / Política..................................................................................................................................39 Usabilidade..........................................................................................................................................................40 3.10. Replicação.................................................................................................................................................40 3.10.1. Replicação no LDAP..............................................................................................................................42 3.10.2. Daemon “SLURPD”.............................................................................................................................42 3.10.2.1. Log de replicação e aquivos auxiliares...............................................................................................43 3.10.2.2. Modos de operação..............................................................................................................................44 3.10.2.3. Funcionamento....................................................................................................................................44 5

3.10.3. Ocorrência de falhas no SLAPD e no SLURPD durante a replicação....................................................45 3.10.4. Concluindo replicação............................................................................................................................45 3.11. Banco de Dados x LDAP...........................................................................................................................46 3.11.1. Banco de dados relacional.......................................................................................................................46 3.11.2. Banco de dados hierárquico....................................................................................................................46 3.12. X.500 x LDAP...............................................................................................................................................47 3.12.1. Protocolo DAP.......................................................................................................................................47 3.12.2. Protocolo LDAP......................................................................................................................................48 3.12.3. Vantagens do LDAP...............................................................................................................................49 Desempenho........................................................................................................................................................49 3.12.5. Comparações DAP x LDAP...................................................................................................................50 Capítulo IV – Principais Ferramentas LDAP..........................................................................................................53 4.1. Introdução.....................................................................................................................................................53 4.1.1 Freeware.....................................................................................................................................................53 4.1.2 Open Source...............................................................................................................................................54 4.1.3 Ferramentas LDAP.....................................................................................................................................54 4.2. PHP LDAP ADMIN.....................................................................................................................................54 4.2.1 Características............................................................................................................................................55 4.2.2 Criando entradas de LDAP........................................................................................................................56 4.2.3 Editando entradas.......................................................................................................................................57 4.2.4 Manutenção de dados.................................................................................................................................58 4.2.5 Buscas de LDAP........................................................................................................................................58 4.2.6 Sustentação comercial de servidor LDAP..................................................................................................59 4.2.7 Novell.........................................................................................................................................................59 4.2.8 Sun ONE Directory Server.........................................................................................................................60 4.2.9 Microsoft ActiveDirectory.........................................................................................................................61 4.2.10 Sustentação internacional da língua.........................................................................................................61 4.3. YALA ..........................................................................................................................................................62 4.3.1 Características............................................................................................................................................62 4.4 LDAP Browser/Editor ..................................................................................................................................70 4.4.1 Características: ..........................................................................................................................................70 4.5. SMBLDAP...................................................................................................................................................71 Capítulo V – O LDAP e o Gerenciamento de Usuários..........................................................................................72 5.1. Usuários........................................................................................................................................................73 5.2. Gerenciamento.............................................................................................................................................73 5.3. Gerenciamento de Usuários.........................................................................................................................73 5.4. LDAP no Gerenciamento de Usuários.........................................................................................................74 Conclusão................................................................................................................................................................76 Anexo I – Documentação acerca da Implementação do Protocolo LDAP para Gerenciamento de Usuários........77 1. Objetivo geral..................................................................................................................................................77 2. Descrição e abrangência..................................................................................................................................78 3. Recursos de hardware e software....................................................................................................................78 3.1. GNU/Linux – Kurumin................................................................................................................................79 3.2 OpenLDAP....................................................................................................................................................79 3.2.1. SLAPD......................................................................................................................................................79 3.2.2 Backend de Banco de Dados – BerkeleyDB..............................................................................................80 3.3. APACHE, PHP e PHPLDAPADMIN.........................................................................................................81 3.4. Microsoft Windows XP®.............................................................................................................................81 3.5 Outlook Express®.........................................................................................................................................82 4. Configurações..................................................................................................................................................82 4.1 Servidor ........................................................................................................................................................82 4.1.1 BerkleyDB..................................................................................................................................................82 4.1.1.1 Instalação e configuração.......................................................................................................................82 4.1.2 OpenLDAP.................................................................................................................................................84 4.1.2.1 Instalação e configuração........................................................................................................................84 4.1.2.2 Migração.................................................................................................................................................91 4.1.3 Sistema de Autenticação............................................................................................................................93 4.1.3.1 PAM e NSS............................................................................................................................................93 4.1.3.2 Instalação e Configuração do NSS e PAM............................................................................................93 4.1.4 Samba.........................................................................................................................................................98 4.1.4.1 Instalação e Configuração.......................................................................................................................98 6

4.1.5 Smbldap-tools...........................................................................................................................................101 4.1.5.1 Instalação e configuração......................................................................................................................102 4.1.6 Apache......................................................................................................................................................106 4.1.6.1 Instalação e Configuração.....................................................................................................................107 4.1.7 PHP...........................................................................................................................................................112 4.1.8 PHPLDAPADMIN...................................................................................................................................113 5.1 Estação de trabalho......................................................................................................................................118 5.1.1 Autenticação.............................................................................................................................................118 Configuração.....................................................................................................................................................118 Cliente de E-mail...............................................................................................................................................120 5.1.2.1 Outlook Express...............................................................................................................................120 5.1.2.2 Pesquisa de Informações ......................................................................................................................122 6. Esquema de Funcionamento..........................................................................................................................123 7. Simulação do ambiente.................................................................................................................................124 7.1 Usuários e Grupos.......................................................................................................................................125 Criação de Grupos e Usuários...........................................................................................................................125 7.1.1.1 Autenticação..........................................................................................................................................126 Anexo II – RFC’s..................................................................................................................................................131 RFC 1777..........................................................................................................................................................131 RFC 1779..........................................................................................................................................................131 RFC 1798 .........................................................................................................................................................131 RFC 1823..........................................................................................................................................................132 RFC 1959..........................................................................................................................................................132 RFC 2044..........................................................................................................................................................132 RFC 2251..........................................................................................................................................................132 RFC 2252..........................................................................................................................................................133 RFC 2253..........................................................................................................................................................133 RFC 2254..........................................................................................................................................................133 RFC 2255..........................................................................................................................................................134 RFC 2256 ........................................................................................................................................................134 RFC 1487..........................................................................................................................................................134 RFC 1558..........................................................................................................................................................135 RFC 1778..........................................................................................................................................................135 RFC 1960..........................................................................................................................................................135 RFC 2079..........................................................................................................................................................135 RFC 2116..........................................................................................................................................................136 RFC 2164..........................................................................................................................................................136 RFC 2247..........................................................................................................................................................136 RFC 2307 .........................................................................................................................................................137 RFC 2377..........................................................................................................................................................137 RFC 2559..........................................................................................................................................................137 RFC 2596..........................................................................................................................................................137 RFC 2649..........................................................................................................................................................138 RFC 2696..........................................................................................................................................................138 RFC 2587..........................................................................................................................................................138 RFC 2589..........................................................................................................................................................139 RFC 2657..........................................................................................................................................................139 RFC 2713..........................................................................................................................................................139 RFC 2739..........................................................................................................................................................140 RFC 2798..........................................................................................................................................................140 RFC 2820..........................................................................................................................................................140 RFC 2829..........................................................................................................................................................141 RFC 2830..........................................................................................................................................................141 RFC 2849..........................................................................................................................................................141 RFC 2891..........................................................................................................................................................141 RFC 2926..........................................................................................................................................................142 RFC 2927..........................................................................................................................................................142 RFC 3045..........................................................................................................................................................142 RFC 3062..........................................................................................................................................................143 RFC 3088..........................................................................................................................................................143 RFC 3112..........................................................................................................................................................143 7

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

LISTA DE FIGURAS

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

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

ABSTRACT

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

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

RESUMO

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

10

CAPÍTULO I – INTRODUÇÃO

1.1.

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

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

11

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

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

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

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

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

OBJETIVOS ESPECÍFICOS Este estudo tem como objetivos específicos: •

Apresentar conceitos básicos sobre diretórios; 12

•

Conceituar e descrever os aspectos do protocolo LDAP;

•

Apresentar arquivos gerados pelo padrão LDAP (LDIF); •

Citar as principais ferramentas opensource de mercado para as aplicações LDAP;

1.5.

•

Discorrer sobre o LDAP na gerência de usuários;

•

Demonstrar o ambiente de funcionamento LDAP.

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

bibliográfica em fontes escritas como; livros, artigos e manuais, bem como: •

Pesquisas na Internet;

•

Orientação e supervisão semanal do Prof. Orientador; •

Reuniões Semanais do grupo para prover um bom desenvolvimento do trabalho proposto;

•

Correio eletrônico (e-mail)

•

Visitas a empresas e consultas a profissionais especializados no

assunto.

13

CAPÍTULO II – DIRETÓRIOS

2.1 - O QUE É UM DIRETÓRIO O termo diretório significa lista de informações sobre um arranjo de objetos com detalhes ordenados. Partindo desse princípio objetos podem ser arquivos de um sistema, serviço de rede, lista de endereços, sistema de domínio de nomes - DNS1, sistema de informações de redes - NIS 2, listas telefônicas e etc. [JOHNER,1998] A todo instante se vê exemplo de lista de objetos, um deles é a lista telefônica que, como um diretório, tem objetos e neste caso, são pessoas e os nomes desses objetos estão ordenados alfabeticamente. Cada uma dessas pessoas tem alguns dados detalhados tais como: o endereço e o número de telefone. Um outro exemplo cabível seria um catálogo de livros de uma livraria, onde os livros estariam ordenados por autor, por título, ISBN ou qualquer outra informação de publicação. Em termos técnicos, um diretório é uma base de dados especializada, também chamada de repositório de dados, que armazena e organiza informações sobre objetos. Um determinado diretório pode ter informações sobre: impressoras distribuídas na rede, no qual deve listar informações sobre impressoras (objeto), velocidade de impressão por minuto (numérico), fluxo de impressão suportada (PostScript 3 ou ASCII4) e assim por diante. 1

Domain Name System – Sistema de Nome de Domínio. Amplamante utilizado na internet. Name information system - Serviço de Informação de Rede. 3 Linguagem projetada para fazer uma coisa apenas; descreve de forma extremamente apurada tudo o que contém uma página. 4 Código de caracteres de texto 2

14

Os diretórios corporativos normalmente contêm informações de um vasto número de objetos em sua rede, que vão desde informações de equipamentos a detalhe de um funcionário de uma dada filial. Com essas informações, esses diretórios permitem aos usuários utilizá-los para a busca de, por exemplo, um endereço de e-mail ou para encontrar algum equipamento específico ou até mesmo para buscar informações sobre o faturamento de um cliente. Nos diretórios em geral, quando é conhecido algum atributo que sirva como parâmetro de busca é possível conhecer os demais atributos ou características desse objeto. Isso é similar a procurar um nome em uma lista telefônica. Entretanto, diretórios em informática são muito mais flexíveis do que uma lista telefônica, pois podem ser procurados por um critério específico, não por algumas categorias pré-definidas. 2.2 - VANTAGENS DE USAR UM DIRETÓRIO Um diretório de aplicação específica5 armazena somente a informação necessária por uma aplicação particular e não é acessível por outras aplicações, pois um serviço de diretório com todas as funcionalidades é complexo para se construir e os diretórios de aplicação específica são tipicamente muito limitados, provavelmente armazenam somente um tipo específico de informação, não têm potencialidades de busca, não suportam a replicação e a divisão e provavelmente não têm um pacote completo de ferramentas para administração. Em tal ambiente, cada aplicação cria e controla seu próprio diretório, que se transforma rapidamente num pesadelo administrativo. O mesmo endereço de e-mail armazenado pela aplicação do calendário pode também ser armazenado por uma aplicação do correio e também por uma aplicação que notificasse operadores de sistema a respeito de problemas do equipamento. Manter cópias múltiplas da informação é difícil, especialmente quando as relações de servidor são diferentes e até mesmo os administradores de sistema envolvidos são diferentes. O que é necessário é um diretório comum, independente da aplicação. Sendo assim os desenvolvedores de aplicação poderiam ser certificados da existência de um serviço do diretório, então os diretórios de aplicação específica não seriam necessários. Entretanto, esses diretórios devem ser baseados em um padrão aberto que seja suportado por muitos

5

Diretório onde contém informações úteis a aplicações específicas 15

distribuidores e em muitas plataformas. Deve ser acessível com um API 6 padrão. Deve ser extensível de modo que possa prender os tipos de dados necessários às aplicações arbitrárias e deve fornecer uma funcionalidade completa sem requerer recursos excessivos em sistemas menores. Assim, como mais usuários e aplicações acessarão e dependerão do diretório comum, outras características importantes seriam: a robustez e a segurança com grande escalabilidade. Com tal infra-estrutura de diretório, os desenvolvedores de aplicação podem alocar seu tempo para desenvolver novas aplicações em vez de desenvolver diretórios de aplicação específica. Da mesma maneira que os desenvolvedores confiam na infra-estrutura das comunicações de TCP/IP7 e de Chamada de Procedimento Remoto (RPC)8 [RFC 1831] para os livrar do fluxo da comunicação de baixo nível, poderão confiar em poderosos serviços de diretório completo. Armazenar dados em um diretório e os compartilhar entre aplicações, reduz gasto de tempo e dinheiro mantendo a manutenção com um baixo custo. 2.3 - DIRETÓRIOS DISTRIBUÍDOS Os termos locais, globais, centralizados, e distribuídos são usados freqüentemente para descrever um diretório. Estes termos significam coisas diferentes em contextos diferentes. O termo local significa algo que está fisicamente próximo. Global significa que é algo que engloba um universo de interesses. O universo de interesse pode ser uma companhia ou um país. Centralizado significa que algo é, como o próprio nome diz, centralizado em um lugar e distribuído significa que algo está espalhado fisicamente no universo de interesses. As informações armazenadas em um servidor de diretório podem ser locais ou globais, dependendo do escopo e de sua utilização. Um diretório que tenha informações sobre um departamento, tem um contexto local. Essas mesmas informações, num contexto maior, como informações de uma corporação, teriam uma visão global. Os clientes que por ventura acessem a informação no diretório podem ser locais ou remotos. Os clientes locais são todos situados no mesmo edifício ou na mesma LAN

6

Application Programming Interface, um conjunto de funções e sub-rotinas usadas pelos programas que informam ao sistema operacional como executar determinada tarefa. 7 Transmission Control Protocol / Internet Protocol. 8 É um protocolo que os programas usam para requisitar serviços de outros programas rodando em servidores num ambiente de rede 16

9

Rede local. Os clientes remotos estão geograficamente dispersos através do continente ou do

planeta. O próprio diretório pode ser centralizado ou distribuído. Se um diretório for centralizado ele pode ser um servidor de diretório em um local ou um servidor do diretório em um sistema distribuído. Se o diretório for distribuído, há múltiplos servidores espalhados no universo de interesse que fornecem o acesso ao diretório. Quando um diretório é distribuído, a informação armazenada no diretório pode ser dividida ou replicada. Quando a informação é dividida, cada servidor de diretório armazena um subconjunto original sem sobrepor informação. Isto é, cada entrada de diretório é armazenada por um, e somente um, servidor. Quando a informação é replicada, a mesma entrada de diretório está armazenada por mais de um servidor. As três dimensões de um diretório (espaço da informação, posição dos clientes, e distribuição dos servidores) são independentes entre si. Como exemplo, os clientes dispersos através do globo podem acessar um diretório que contém somente informação sobre um único departamento, e esse diretório pode ser replicado em muitos servidores de diretório. Os clientes em uma única posição podem acessar um diretório que contenha informação sobre toda a empresa, que é armazenado por um único servidor do diretório. O espaço da informação a ser armazenada em um diretório é dado freqüentemente como uma exigência da aplicação. A distribuição dos servidores de diretório e a maneira em que os dados são divididos ou replicados são controlados para não afetar o desempenho e aumentar a disponibilidade do diretório. 2.4 - DIRETÓRIO CLIENTE E SERVIDOR Os diretórios são acessados geralmente usando o modelo cliente/servidor de comunicação. Uma aplicação que faz uso de um diretório e que queira realizar uma consulta ou até mesmo fazer alguma atualização, não conseguirá acessar esse diretório diretamente. Em vez disso, é chamada uma função podendo ser da API(Application Programming Interface) da linguagem do cliente, originando uma mensagem a ser emitida a um outro processo. Esse segundo processo acessa a informação no diretório de interesse de uma requisição via TCP/IP. As portas padrões TCP/IP são 636 para comunicações seguras (criptografadas) e 389 para comunicações sem criptografia. Os resultados das ações de leitura e escrita são retornados a requisições da aplicação, como mostrado na figura 1. 9

Local Area Network ou Rede Local. 17

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

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

18

CAPÍTULO III – LDAP 3.1.

HISTÓRICO DO LDAP Nos anos 70, a integração de comunicações e tecnologias de computação levou

ao desenvolvimento de novas tecnologias de comunicação. Muitos dos sistemas servidores que foram desenvolvidos eram incompatíveis com outros sistemas, tornou-se evidente a necessidade de padrões que permitissem que equipamentos e sistemas diferentes tivessem operacionalização

compatível.

Diante

disso,

as

duas

principais

e

independentes

padronizações, o CCITT10, que mais tarde tornou-se ITU11 e a ISO12 trabalharam juntamente na definição de um padrão de serviço de diretório que permitisse tratar melhor aspectos de denominação e de endereçamento. 3.1.1.

PRECURSORES DO LDAP O CCITT criou o X.500 básico em 1988, que se tornou o ISO 9594, Data

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

CCITT- Consultatif et Comite Telephonique Internacional et Telegraphique, (Comitê Consultivo Internacional em Telefonia e Telegrafia) 11 ITU International Telecommunications Union: (União Internacional de Telecomunicações - Setor de Padronização de Telecomunicação) 12 ISO International Organization for Standardization (Organização Internacional de Padrões) 19

Por causa da sua eficiência, o X.500 é freqüentemente usado junto com módulos agregadores para a interoperação entre serviços de diretórios incompatíveis. O X.500 especifica a comunicação entre cliente e servidor no uso do diretório de protocolo de acesso DAP13, no entanto, como um protocolo da camada de aplicação, o DAP exige a pilha inteira de protocolo OSI14 para operar. Suportar a pilha de protocolo OSI exige uma grande quantidade de recursos, portanto, foi desenvolvida uma interface para um servidor de diretório X.500 utilizando um protocolo mais leve tanto para o acesso como para os recursos computacionais. 3.1.2.

VERSÕES E CARACTERÍSTICAS Em 1992 o grupo de trabalho OSI-DS15 da IETF16 partiu das especificações do

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

13

DAP Directory Access Protocol (Protocolo de acesso a diretório) OSI Open System Interconnection (Sistemas abertos de interconexão) 15 OSI-DS OSI Directory Service (OSI serviço de diretório) 16 IETF Internet Engineering Task Force 17 O protocolo DIXIE foi projetado para ser usado em equipamentos pequenos (exemplo, PCs e Macintoshes) e sem potência computacional ou software necessário para implementar a pilha completa de protocolos OSI. 18 O gateway pode ser um PC com duas (ou mais) placas de rede, ou um dispositivo dedicado, utilizado para unir duas redes. Existem vários usos possíveis, desde interligar duas redes que utilizam protocolos diferentes, até compartilhar aconexão com a Internet entre várias estações. 19 DSA Directory Assistence Service (Serviço de assistencia a diretório) 20 14

•

Transporte: O LDAP executa diretamente sobre TCP, evitando

a sobrecarga das camadas superiores de pilhas de protocolos OSI. •

Representação de Dados: No LDAP a maioria dos elementos

de dados são representados como cadeias de caracteres, processadas bem mais facilmente que dados na representação estruturada ASN.l20 usada pelo X.500. •

Codificação de Dados: O LDAP codifica dados para transporte

em redes usando uma versão simplificada das mesmas regras de codificação usadas pelo X.500. •

Funcionalidade: O LDAP elimina características pouco usadas

e operações redundantes do X.500. A falta de suporte para o X.500 e para a pilha de protocolos OSI levou os pesquisadores e desenvolvedores da Universidade de Michigan a criarem um servidor LDAP standalone, o slapd. Esse grupo disponibilizou os fontes do slapd na Internet e criou listas de usuários para divulgar e aperfeiçoar o novo serviço. O desenvolvimento foi acompanhado por usuários e desenvolvedores do mundo inteiro. Com a popularização do slapd, o LDAP deixou de ser uma mera alternativa ao DAP do X.500 e se tornou um serviço de diretório completo, passando a competir com X.500. Em dezembro de l997, a IETF aprovou a versão 3 do LDAP como proposta de padrão Internet para serviços de diretório. Parte dessa nova versão foi realizada na Universidade de Michigan, à qual estavam vinculados vários membros do grupo OSI-DS. A universidade também fornece implementações de referência de LDAP e possui páginas na web que tratam sobre o assunto. 3.1.3.

RFC’S QUE PADRONIZAM O LDAP A primeira versão do LDAP foi definida em X.500 como DAP (Protocolo de

Acesso Leve), [RFC 1487], que foi substituído por LDAP (Protocolo Leve de Acesso a Diretório), [RFC 1777]. A [RFC 1777] define por si mesmo o protocolo de LDAP: •

Representação de strings de atributos de sintaxes básicos,

[RFC 1778]; • 20

Representação de strings de nomes distintos, [RFC 1779];

Abstract Syntax Notation One 21

•

Formato de URL de LDAP [RFC 1959];

•

Representação de strings de filtros de pesquisa LDAP [RFC

1960]. A Versão LDAP 2 alcançou o estado de padrão de esboço, no processo de padronização do IETF. Todos os atuais diretórios de implementação de servidor são baseados na especificação LDAPv3. A Versão LDAP 3 é definida por Protocolo Leve de Acesso a Diretório (v3) [RFC 2251]. As novas RFCs da versão LDAP 3 são: •

Protocolo Leve de Acesso a Diretório (v3): Definições de

sintaxe de atributo [RFC 2252]; •

Protocolo Leve de Acesso a Diretório (v3): Representação de

strings de nomes distintos [RFC 2253]; •

Representação de strings de filtros de pesquisa LDAP [RFC

2254]; •

Formato URL LDAP [RFC 2255];

•

Resumo do X.500(96) esquema de operador para uso com

LDAP v3 [RFC 2256]; •

Métodos de autenticação para LDAP [RFC 2829];

•

LDAPv3: Extensão para segurança da camada de transporte

[RFC 2830]; •

Protocolo Leve de Acesso a Diretório (v3): Especificação

técnica [RFC 3377]. A [RFC 2251] é um padrão proposto, uma forma de padrão de esboço. O LDAPv3 estendeu o LDAPv2 nas seguintes áreas: •

Referências: um servidor que não armazena os dados solicitados

pode referir o cliente a outro servidor. •

Segurança: autenticação extensa usando os mecanismos de

autenticação simples e camada de segurança (SASL)21. •

Internacionalização:

UTF-822

apoio

para

caracteres

internacionais.

21 22

SASL (Simple Authentication And Security Layer) Unicode Transformation Formats 22

•

Extensão: novos tipos de objeto e operações podem ser

dinamicamente definidos e o esquema publicado numa maneira básica.

3.1.4.

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

utilizando o LDAP e a concepção de diretório para centralizar e/ou sincronizar diretórios diferentes. Atualmente várias empresas oferecem produtos LDAP, incluindo Microsoft®, Netscape® e Novell®. A Open LDAP Foundation, mantém e disponibiliza uma implementação open source de serviços de diretório LDAP, baseada na Universidade de Michigan, que inclui os seguintes módulos: •

Slapd - servidor LDAP standalone;

•

Slurpd - servidor de replicação LDAP standalone;

•

Bibliotecas que implementam o protocolo LDAP;

•

Utilitários e ferramentas clientes LDAP.

O desenvolvimento do Open LDAP prossegue acompanhando a evolução dos padrões do IETF e importantes empresas em todo o mundo o vem utilizando, como: IG ®, Yahoo®, Pop®, Ret Hat®, Conectiva®, HP®, APLLE®, IBM®, etc. No Brasil, utilizam LDAP: metrô de São Paulo, Prodesp, Sangari®, Bombril®, etc. 3.2.

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

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

23

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

LDAP: PROTOCOLO OU DIRETÓRIO O LDAP é definido como um protocolo de mensagens usadas por clientes do

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

23 25

Structured Query Language Active Directory 24

3.4.

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

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

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

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

Distinct Name – utilizado para definir uma base LDAP 25

3.5.1.

MODELO DA INFORMAÇÃO Fornece a estrutura e o tipo de dado necessário para a construção de uma

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

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

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

ou = pessoas

ou = grupos

ou = computador

uid = tiago

Figura 2 - Árvore de diretório. 27

Directory Information Tree – Árvore de Informação do Diretório 26

3.5.3.

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

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

MODELO DE SEGURANÇA É baseado na operação de ligamento (Bind operation). Existem diversas

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

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

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

27

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

CLASSES DE OBJETOS, ATRIBUTOS E ESQUEMAS As classes de objetos são conjuntos de atributos referentes a uma entrada. São

termos do LDAP que denotam o tipo de objeto que está sendo representado por uma entrada ou por um registro de diretório. Os objetos podem ser: pessoas, organizações, unidade organizacional, grupo de nomes, entre outros. Existem também as classes de objetos que definem o relacionamento entre um objeto e outro, tais como: a classe em que o objeto possui objetos subordinados sob ele em uma estrutura de árvore hierárquica. As classes podem ser declaradas como: abstrata, estrutural ou auxiliar. Uma classe abstrata do objeto é usada quando se tem um molde para a criação de outro objeto. Uma entrada de diretório não pode ser imediata a uma classe abstrata do objeto. As entradas de um diretório são imediatas quando se trata das classes estruturais do objeto. Já uma classe auxiliar do objeto não pode ser imediata, por ter unida a si, às entradas dos diretório que são imediatas as classes estruturais do objeto. As classes auxiliares do objeto fornecem um método que estende as classes estruturais, sem ter que mudar, a definição do esquema de uma classe estrutural. Também definem um arranjo de atributos padrões, listados como obrigação (atributos imperativos) e que ainda podem conter atributos opcionais. As diferentes classes de um objeto podem prescrever alguns atributos que sobrepõem ou são redundantes a outras classes do objeto. É comum em diretórios LDAP, usar classes múltiplas do objeto, para 28

definir uma única entrada de um diretório. A maioria das classes de objeto, são definidas em uma ordem hierárquica, onde uma classe de objeto "herda" de outra classe superior. [JOHNER,1998] Não se pode simplesmente criar classes de objetos e acrescentar as mesmas a um objeto, o servidor deve ter cada classe de objeto definida, no que é chamado de schema (esquema). Não é possível acrescentar um registro com uma classe de objeto indefinida, isso implicará numa tentativa de violação do esquema, e a operação irá falhar. Algumas classes de objetos usados no LDAP: Tabela 1 Algumas classes de objetos account adminPerson alias

applicationEntity applicationProcess certificationAuthority

certificationAuthority-V2

country

cRLDistributionPoint device dNSDomain documentSeries domainRelatedObject dynamicObject extensibleObject groupOfNames inetOrgPerson LDAPsubEntry mailAlias organization organizationalRole person pilotOrganization referral residentialPerson room strongAuthenticationUser top uflEduPerson uidObject

dcObject dmd document domain dSA eduPerson friendlyCountry groupOfUniqueNames labeledURIObject locality OpenLDAProotDSE organizationalPerson organizationalUnit pilotDSA qualityLabelledData reserved RFC822localPart simpleSecurityObject subschema uflEduOrganization uflEduRelationship userSecurityInformation

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

os objetos e atributos que são utilizados no SAMBA e que possam ser migrado para para o LDAP, segue abaixo exemplos de schemas existentes. Tabela 2 Alguns esquemas. corba.schema

core.schema

cosine.schema

inetorgperson.schema

java.schema

nis.schema

openldap.schema

qmail.schema

samba3x.schema

authldap.schema

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

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

dc co gn homePhone l mail mobile o ou -

Nome countryName commonName

Objeto Classe country person organizationalPerson organizationalRole groupOfNames applicationProcess applicationEntity posixAccount device domainComponent dcObject facsimileTelephoneNumber residentialPerson organizationalRole organizationalPerson friendlyCountryName friendlyCountry givenName inetOrgPerson homeTelephoneNumber inetOrgPerson jpegPhoto inetOrgPerson localityName locality organizationalPerson rfc822Mailbox inetOrgPerson mobileTelephoneNumber inetOrgPerson organizationName organization organisationalUnitName organizationUnit owner groupOfNames device

Esquema core.schema core.schema

core.schema core.schema cosine.schema core.schema cosine.schema inetorgperson.schema core.schema core.schema cosine.schema core.schema core.schema core.schema 30

pager postalCode sn st street userPassword

pagerTelephoneNumber postalAddress postalCode surname stateOrProvinceName streetAddress telephoneNumber -

uid

userid

groupOfUniqueNames inetOrgPerson organizationalPerson organizationalPerson person organizationalPerson organizationalPerson organizationalPerson organization organizationalUnit person dmd simpleSecurityObject domain posixAccount account inetOrgPerson posixAccount

cosine.schema core.schema core.schema core.schema core.schema core.schema core.schema core.schema

core.schema

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

3.8.

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

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

31

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

SEGURANÇA NO LDAP O aspecto segurança é de grande importância em uma rede mundial de

computadores, e com o LDAP não é diferente. Quando são enviados dados em uma rede interna ou externa, precisa-se que esses dados sejam protegidos de ataques e violações por parte de pessoas mal intencionadas, durante o transporte. Essa proteção é especialmente importante nas operações de atualização em um diretório. O Termo segurança nesse contexto atua sobre quatro aspectos: •

Autenticação: Garante que a parte oposta (máquina ou pessoa) realmente é

quem ela afirma ser; •

Integridade: Garante que a informação que chegou é realmente a mesma que

foi enviada; •

Confidencialidade: Protege as informações divulgadas, por meio de

criptografia, para que pessoas que não sejam autorizadas, entendam essas informações; •

Autorização: Garante que é realmente permitido a uma pessoa fazer o que está

pedindo. Isso é normalmente conferido após a autenticação do usuário. A autorização do LDAP, não faz parte da especificação do protocolo e é portanto implementação específica. Isso é basicamente arquivado por algum controle de acesso, como leitura, escrita, ou exclusão, por identidades de usuários ou nomes comuns. Quem é responsável por proporcionar os controles de acesso são as ACLs, Listas de controle

32

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

SEM AUTENTICAÇÃO

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

AUTENTICAÇÃO BÁSICA O mecanismo seguro no LDAP é negociado quando a conexão entre cliente e

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

AUTENTICAÇÃO

SIMPLES E CAMADA SEGURA

(SASL - SIMPLE AUTHENTICATION

AND

SECURITY LAYER). SASL é um framework para adicionar mecanismos de autenticação para protocolos orientados a conexão. Isso foi adicionado na versão 3 do LDAP para sobrepor a autenticação deficiente da versão 2. 33

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

DN:

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

•

Mecanismo : Esse é o nome do método de segurança que deve ser usado. No LDAP o mecanismo mais utilizado é o SSL ou TLS, que é provido por um mecanismo externo.

•

Credenciais:

Contém os dados arbitrários que identificam o DN. O formato e o conteúdo dos parâmetros dependem do mecanismo escolhido. Se, por exemplo, o mecanismo anônimo, for escolhido, pode ser uma cadeia de caracteres arbitrários ou um endereço de e-mail que identifiquem o usuário.

O funcionamento do mecanismo SASL acontece da seguinte forma: a aplicação cliente do LDAP chama o driver do protocolo SASL no servidor, que retorna as conexões do sistema de autenticação, nomeados no mecanismo SASL, para devolver a informação de autenticação requerida pelo usuário. SASL pode ser visto como um mediador entre o sistema de autenticação e o protocolo LDAP.

34

Chamadas

do

Mecanismos SASL (Cliente LDAP)

Driver SASL no Servidor LDAP

Sistema de Autenticação

Figura 3 - Mecanismo SASL.

3.8.5.

SSL E TLS O protocolo de conexão segura (SSL), foi desenvolvido para promover

autenticação e segurança nos dados. Ele é encapsulado sobre a camada TCP/IP nos protocolos de rede.

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

HTTP

SMTP

LDAP Protocolos de Aplicação

Security Layer (SSL/TLS) Protocolos de Rede TCP/IP layer

O SSL foi desenvolvido pela Netscape. TLS é um padrão aberto. Figura 4 - SSL/TLS no relacionamento com outros protocolos. 35

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

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

CLIENTE

Mensagem, Digest

SERVIDOR

Chave Simétrica (encriptada) Mensagem aleatória (encriptada)

Figura 5 - Acordo SSL/TLS.

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

O cliente então requisita que o servidor prove sua identidade. Isso para saber se o certificado não foi enviado por outra pessoa qualquer ou foi interceptado. 36

4.

O servidor retorna uma mensagem que inclui uma message digest, mensagem condensada, que é encriptada com a sua chave privada. Uma message digest que é computada de uma mensagem satisfatória usando uma função distribuída (hash) tem duas características: são extremamente difíceis de serem revertidas e é praticamente impossível encontrar duas mensagens que produzam o mesmo message digest.

5.

Servidor e cliente precisam combinar sobre uma chave secreta a ser usada para encriptação dos dados. A encriptação dos dados é definida por um algoritmo de chave simétrica pois é mais eficiente. O cliente, depois de gerada uma chave simétrica, encripta com a chave pública do servidor e a envia. Apenas o servidor com a chave privada pode desencriptar a chave secreta.

6. O servidor desencripta a chave secreta e envia de volta uma mensagem de teste, encriptada com a chave secreta para provar que a mesma chegou seguramente. Eles podem então iniciar a comunicação usando a chave simétrica para encriptar os dados. 3.8.6.

OUTROS MECANISMOS DE AUTENTICAÇÃO SASL Embora a concepção do SASL suporte múltiplos mecanismos, produtos de

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

3.9.

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

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

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

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

37

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

POLÍTICAS DE SEGURANÇA As políticas de segurança, é um termo geral que define como, quando, quem e

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

3.9.3.

DEFININDO LISTAS DE CONTROLE DE ACESSO As Listas de Controle de Acesso são listas que contém atributos específicos

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

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

ASPECTOS GERAIS DO MODELO ACL PARA LDAP O modelo de controle se acesso para LDAP deve ser um modelo geral,

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

SEMÂNTICA / POLÍTICA •

As regras mais específicas devem sobrepor as menos

específicas; •

As políticas múltiplas de mesmo nível devem ser facilmente

compreendida, quando não tiver uma política de segurança específica deve haver uma interpretação de negado ou concedido o ideal é negar o acesso às entradas de mesma especificação em que não poder ser determinada que a concessão do acesso; •

A gerência dos direitos acesso não devem surtir efeitos

colaterais, conceder direito de acesso o um usuário em um determinado objeto não deve implicitamente conceder a ele ou a qualquer outro usuário, direitos de acesso diferentes ao mesmo objeto; •

A política de segurança deve ser única para entradas múltiplas,

mesmo que elas estejam em sub-árvores diferentes. 39

USABILIDADE •

O sistema deve ser o mais simples possível;

•

O modelo de ACL deve ser de fácil compreensão;

•

Ao administrador não deve ser dado a autorização para travar

todos os usuários; •

Deve suportar controle de acesso específico à cada entrada;

•

Administrador deverá agregar usuários em grupos e/ou papéis

para facilitar a administração, poderá delegar a administração da política de sub-arvores específicas a outros usuários; •

Deve ser possível autorizar ao usuário, que possam acessar toda

estrutura da árvore de diretórios mesmo que não tenham direito de alterar ou examinar algumas entradas e também deve ser possível negar que façam isso; •

As informações da política de acesso herdadas, devem ser

facilmente identificadas pelos administradores, sabendo definir de quem e de onde as ACLs são derivadas. Esses são alguns pontos que norteiam a criação de ACLs, para que sejam utilizados da forma mais otimizada possível e também buscando organizar as idéias para que não divirjam muito umas das outras, apesar de serem implementações individuais. Abaixo, será mostrado um exemplo da configuração ACL no servidor LDAP, o slapd: Acess to attrs = userPassword By dn= ”cn=admin, dc=LDAP, dc=df” write By anonymous auth By self write By x nome Access to dn.base=”” by * read

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

3.10.

REPLICAÇÃO

40

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

Figura 6 - Sistema com uma única base.

Figura 7 - Sistema com a base distribuída.

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

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

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

3.10.1.

REPLICAÇÃO NO LDAP O conjunto do serviço de diretórios do LDAP

oferece possibilidade de

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

DAEMON “SLURPD” Como citado acima, o slurpd oferece a um servidor slapd mestre a

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

42

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

O slurpd deve sempre trabalhar na mesma máquina do servidor slapd para que funcione corretamente, pois ele irá detectar no servidor mestre as alterações e modifica-las nos servidores escravo. Para a sua operação o slurpd precisa de algumas informações de configurações as quais ele utiliza o arquivo de configuração do servidor LDAP o slapd.conf. Durante suas operações o slurpd utiliza dois artifícios importantes; o log de replicação e o arquivo auxiliar. 3.10.2.1. LOG DE REPLICAÇÃO E AQUIVOS AUXILIARES Os logs de replicação são arquivos que são modificados a cada alteração realizada no servidor mestre, são incluídas nesses arquivos as entradas que foram modificadas. Esse arquivo serve como base de referencias para as operações de slurpd, pois o informam as novas alterações a serem replicadas. O slurpd lê esse arquivo de log, e localiza as novas entradas adicionadas e efetua as operações e logo em seguida o arquivo e esvaziado para poder dar lugar às novas entradas. Os arquivos auxiliares recebem as informações das modificações realizadas, logo depois do processo citado acima, servindo como uma base de referencia, para se ter um histórico das operações realizadas, a cada processo de atualização das modificações, o conteúdo da log de replicação é copiado para o arquivo auxiliar onde lá permanece. [NAGUEL2]

43

3.10.2.2. MODOS DE OPERAÇÃO Existem dois modos de operação de replicação, oferecidas pelo slurpd. A primeira é a forma mais utilizada e mais segura, ele permanece ativo, e periodicamente verifica o arquivo de log em busca de novas entradas adicionadas e então executá-las. A Segunda forma de operação o slurpd processa o log de replicação e finaliza imediatamente fazendo com que o arquivo de log não seja apagado e não adicionará uma cópia das atualizações efetuadas no arquivo auxiliar (modo “one-shot”). [NAGUEL2] 3.10.2.3. FUNCIONAMENTO Para colocar o slurpd em funcionamento, algumas configurações básicas no servidor mestre e no servidor escravo, são necessárias são elas; Servidor mestre: um servidor slapd pode ser mestre de várias replicações, basta que seja especificado cada uma delas através da diretiva “replica”. [NAGUEL] Exemplo: Erro: Origem da referência não encontrada

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

44

Para evitar que a senha seja transmitida do servidor mestre para o servidor escravo em texto claro, é definida a diretiva “TLS” na linha 5, como “critical” para que seja utilizado uma conexão TLS com o servidor escravo. O Servidor slapd escravo deve possuir as seguintes configurações: o "dn" definido em “udatedn” deve ser o mesmo definido no “binddn”, o usuário que tentar fazer alguma alteração no escravo e que o "dn" não seja o mesmo do “updatedn” será impedido de realizar qualquer alteração. Será retornado, uma referencia indicando-o para o servidor mestre, onde deverá fazer as alterações. Se a alteração não for realizada através do slurpd mesmo que o “dn” seja o mesmo do “updatedn”, será recebida por ele uma mensagem de erro. É importante observar que os direitos de acesso do escravo sobrepõe aquelas definidas no servidor mestre, portanto é preciso tem muito cuidado no gerenciamento desses direitos, para evitar que um usuário tenha direito de escrito na base do escravo, e acabe criando inconsistências. Estando slapd mestre e escravo configurados corretamente, basta colocar o slurpd em funcionamento. Para isso deve-se; interromper a execução do servidor, e criar uma cópia de sua base de dados. Copiar a base de dados para um arquivo LDIF, podemos utilizar o “slapcat” para isso. Copiar a base do mestre para o escravo utilizando “slapdadd” no arquivo LDIF gerado. Reinicializar o funcionamento do slapd mestre e escravo. Por fim inicializar o slurpd na mesma máquina do servidor mestre. 3.10.3. OCORRÊNCIA DE FALHAS NO SLAPD E NO SLURPD DURANTE A REPLICAÇÃO Quando o servidor slapd escravo para de funcionar durante uma replicação, o arquivo de log é apagado e é registrada a alteração no arquivo auxiliar. Quando o servidor voltar, as modificações são feitas normalmente. Quando o servidor slapd mestre é interrompido, o servidor escravo continua a responder as requisições, e a retornar a referência para o servidor mestre no caso de alterações. No caso do slurpd, quando seu funcionamento é interrompido, as alterações permanecem registradas no arquivo de log, assim que voltar a operar, ele irá ler o arquivo e executar as modificações. 3.10.4.

CONCLUINDO REPLICAÇÃO

45

Como podemos observar nos esclarecimentos acima, a replicação é fundamental para a melhor disponibilidade dos sistemas distribuídos, e o serviço de diretórios LDAP, que trabalha fundamentalmente dessa forma não poderia deixar de implementar essa solução. Utilizando-se de uma ferramenta poderosa e ao mesmo tempo simples, traz a solução para a gerência de replicação, implementada pelo daemon “slurpd”. Com configurações simples e rápidas é possível criar um sistema de replicação e colocar em funcionamento o “slurpd”, resultando em alta disponibilidade e integridade dos dados tanto para os usuários quanto para os administradores do sistema. 3.11. BANCO DE DADOS X LDAP No serviço de diretórios LDAP, o principal insumo para a realização de seus serviços são dados. Dados esses que precisam ser armazenados em algum lugar para poderem ser usados posteriormente quando requisitados. O local de armazenamento dos dados e convencionalmente chamado de “banco de dados”. Existem dois modelos de banco de dados que são mais utilizados atualmente, são eles: •

Banco de dados relacional

•

Banco de Dados Hierárquico

3.11.1. BANCO DE DADOS RELACIONAL Um dos tipos de banco de dados existentes é o relacional. Nesse modelo de banco os dados são armazenados de forma que haja uma referência entre esses dados. De forma que fiquem amarrados as sua identificações e possam retornar para uma requisição essa referência. Esse banco trabalha com o intuito de responder a um grande número de transações o que não é adequado ao LDAP. 3.11.2. BANCO DE DADOS HIERÁRQUICO Outro tipo de banco de dados é o hierárquico, um banco que armazena seus dados em forma de uma árvore, onde existem os nós raiz e seus nós filho. Nesse banco não

46

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

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

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

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

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

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

desenvolvido para reduzir a carga do acesso X.500 à diretórios clientes, tornando o diretório disponível para uma grande variedades de máquinas e aplicações, LDAP roda diretamente sobre TCP/IP. Isso simplifica muito as operações X.500. LDAP usa codificação simples. O resultado é um baixo overhead30 no método de acesso para diretórios X.500, e é adequado para utilizar em virtualmente todas as plataformas. [HOWES,1995] [ISQUIERDO,2001] 3.12.2. PROTOCOLO LDAP O LDAP assumiu o modelo de informação do X.500. É baseado no modelo Cliente-Servidor, mas existe uma diferença importante o LDAP não retorna referências. Um servidor LDAP retorna apenas resultados ou erros para o cliente. O modelo Funcional LDAP é uma sub-configuração do modelo X.500. LDAP suporta as seguintes operações: adicionar, apagar, modificar, associar, dissociar, buscar, comparar, remover e abandonar. A operação de procura ou busca é similar a do DAP. Um objeto base e um escopo são especificados, determinando cada partição da árvore de busca. [HOWES,1995] [ISQUIERDO,2001]

Figura 10 - Funcionamento X500 x LDAP.

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

30

Overhead – excesso de carga de leitura ou processamento 48

3.12.3.

VANTAGENS DO LDAP LDAP possui quatro vantagens chave sobre o DAP: •

Roda sobre o protocolo TCP/IP

•

Leitura e operações simplificadas

•

DNs e Codificação Simples

•

Sem referências

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

31

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

3.12.5. COMPARAÇÕES DAP X LDAP A tabela 1 mostra o desempenho de uma classe de perguntas (Query) típicas DAP e LDAP. Os testes são conduzidos em uma máquina dedicada, rodando o DAP e o cliente LDAP, o servidor LDAP, e o DSA. Como pode ser observado na tabela, o atraso introduzido pelo LDAP é mínimo. [HOWES,1995] Tabela 4 Comparação do DAP e LDAP, tempo de respostas às perguntas (Query). Perguntas são realizadas usando o mesmo DSA, com um cache de entradas. Os tempos são em milisegundos Pergunta (Query) Sem Autenticação Autenticado Pesquisa Simples (uma entrada) Pesquisa Simples (50 entradas)

DAP 30 34 32 293

LDAP 68 56 41 353

A tabela 2 mostra o tamanho das perguntas (Query) usados na tabela 1. Isso demonstra que as perguntas LDAP são consideravelmente menores do que as perguntas equivalentes em DAP. A economia é dividida primeiramente pela simplicidade do DN e o valor de codificação. O tamanho das perguntas também são reduzidos pela falta de controle de serviço em cada operação. [HOWES,1995] Tabela 5 Comparação do tamanho das perguntas (Query) entre DAP e LDAP. As perguntas LDAP são significativamente menores que as do DAP. O tamanho das perguntas são em bytes. Pergunta (Query) Sem Autenticação Autenticado Requisição de Pesquisas Simples Resultados de Pesquisas Simples

DAP 192 409 237 547

LDAP 14 138 105 355

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

50

Tabela 6 Comparação do tempo de decodificação entre DAP e LDAP. Elementos do protocolo LDAP são facilmente decodificados, especialmente para PDUs complexos em milisegundos. Complexidade PDU Simples Média Complexa

DAP 550 7925 38393

LDAP 110 714 2702

Tabela 7 Comparação do tempo de codificação entre DAP e LDAP em milisegundos. Complexidade PDU Simples Médio Complexo

DAP 24 1084 2656

LDAP 6 324 989

Finalmente, foi comparado o tamanho das implementações e complexidade do código. A complexidade do código do DAP e a biblioteca de clientes LDAP são também comparadas. Foram utilizadas duas medidas complexas. A primeira, um controle do número aproximado de semi-colunas. A Segunda, um contador do número aproximado de declarações “if”. No calculo de ambas métricas, houve um esforço para fazer uma única inclusão dessas partes de código requerido para acesso X.500. [HOWES,1995] Tabela 8 Comparação da complexidade de implementação entre DAP e LDAP. Contadores de semicolunas, o número aproximado de declarações, e contador de declarações “if”, o número aproximado de caminhos de código são outras medidas de complexidade. Medida DAP Texto 958.464 Dados 385.024 Contador de semi-colunas 46.746 Contadores IF 9369 São notáveis as diferenças no desempenho do

LDAP 221.184 73.728 1.989 568 LDAP em face ao DAP do

X500. Podemos observar que o LDAP simplifica de forma considerável a operações utilizadas no X500 tanto para as perguntas (Query) quanto para as respostas do servidor, além da codificação que também é mais simplificada o que dá maior agilidade e exige menos carga aos seus processos e ao sistema. [HOWES,1995]

51

52

CAPÍTULO IV – PRINCIPAIS FERRAMENTAS LDAP 4.1.

INTRODUÇÃO Com a crescente abrangência da tecnologia da informação nas mais variadas

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

A liberdade de redistribuir cópias de modo que você possa ajudar ao seu próximo.

• A liberdade de aperfeiçoar o programa, e liberar os seus aperfeiçoamentos, de modo que toda a comunidade se beneficie.

23

Royalt – Tributo que é cobrado para a utilização de um serviço ou produto. 53

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

FREEWARE São os programas gratuitos e completos, não exigem registro e não têm taxa de

uso. Não é permitida sua alteração. [GNU, 2005]. 4.1.2

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

distribuição que incluem, além da exigência da publicação do código fonte, os seguintes pontos: 

A redistribuição deve ser livre;



O código fonte deve ser incluído e deve poder ser redistribuído;



Trabalhos derivados devem poder ser redistribuídos sob a mesma licença do original;



Pode haver restrições quanto a redistribuição do código fonte, se o original foi modificado;



A licença não pode discriminar contra qualquer pessoa ou grupo de pessoas, nem quanto a formas de utilização do software;



Os direitos outorgados não podem depender da distribuição onde o software se encontra.

 4.1.3

A licença não pode contaminar outro software.[OPEN SOURCE, 2005]. FERRAMENTAS LDAP A cerca do estudo em questão, é proposto a utilização de softwares que se

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

54

4.2.

PHP LDAP ADMIN O phpLDAPadmin é uma ferramenta poderosa, oferece facilidade em sua

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

CARACTERÍSTICAS

•

Browser da árvore de LDAP;

•

Copia as entradas de LDAP (mesmo cópia entre usuários diferentes);

•

Copias recursivas, árvores inteiras;

•

Browser avançado do esquema de LDAP

•

Buscas de LDAP ( simples e avançado)

•

Exportação de LDIF e de DSML

•

Importação de LDIF

•

Controle da senha do usuário

•

Determina automaticamente a raiz DN do seu usuário de LDAP

•

Tradução amigável dos atributos

•

Sustentação binária do atributo

•

Configuração de modalidades de leitura apenas e de leitura/gravação.

55

Figura 11 - Página Inicial do phpLDAPadmin.

A primeira página é simples. Todas as características do phpLDAPadmin estão acessíveis através do visor da árvore no frame esquerdo. 4.2.2

CRIANDO ENTRADAS DE LDAP O sistema de templating flexível do phpLDAPadmin, permite que os

administradores criem entradas usando um processo automatizado.

56

Figura 12 – Criação de entradas.

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

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

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

57

Figura 13 – Opções de manuseio phpLDAPadmin.

Visualização, adição, adição e remoção com o phpLDAPadmin de jpegPhotos e vários outros. 4.2.4

MANUTENÇÃO DE DADOS As sustentações do phpLDAPadmin automatizaram tarefas como entradas e

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

4.2.5

BUSCAS DE LDAP

58

Procura entradas com diferentes formulários de busca.

Figura 14 – Formulário de buscas.

O formulário simples é usado para fazer buscas rápidas e fáceis. Os resultados são paginados em grupos e o formulário avançado faz a busca de acordo com suas necessidades. 4.2.6

SUSTENTAÇÃO COMERCIAL DE SERVIDOR LDAP O phpLDAPadmin suporta uma escala larga de servidores comerciais LDAP,

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

59

4.2.7

NOVELL

Figura 15 - Entrada de certificado LDAP Novell.

60

4.2.8

SUN ONE DIRECTORY SERVER

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

4.2.9

MICROSOFT ACTIVEDIRECTORY

61

Figura 17 - Entrada Microsoft ActiveDirectory.

4.2.10

SUSTENTAÇÃO INTERNACIONAL DA LÍNGUA O phpLDAPadmin determina automaticamente o idioma sem nenhuma

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

4.3.

YALA

62

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

CARACTERÍSTICAS

•

Possui relação desobstruída e simples;

•

Pode ser alcançado por toda a plataforma desde que se utilize um browser moderno (Cross-Platform);

•

Utiliza Javascript para melhorar a interface web, podendo ser ajustada de acordo a preferência;

•

Faz a leitura do esquema do usuário LDAP;

•

Permite fazer uma configuração que reconheça uma entrada referente as classes de objetos.

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

33

Grafic User Interface 63

64

Figura 19 – Árvore e índices de entrada específica.

Árvore LDAP no frame esquerdo e os índices de uma entrada específica (seus atributos e valores) no frame direito.

65

Figura 20 – Sendo executado no Internet Explorer.

Figura 21 - Árvore de buscas no frame direito. 66

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

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

67

Figura 23 – Browser text-mode.

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

4.4

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

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

CARACTERÍSTICAS:

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

•

Moldes do objeto. Os moldes do objeto são usados criando e adicionando entradas novas. Podem ser criados de forma manual ou automática.

•

Sustentação binária do valor . Os índices do atributo podem ser conservados ou carregados.

68

•

LDAP. Permite especificar e indicar os atributos operacionais e também recuperar contextos de nomes da raiz DSE do usuário.

•

Sustentação do SSL.

•

Arrasto (cópia-e-cola). Permite que entradas ou atributos sejam copiados, colados ou arrastados dentro de um único browser.

•

Sessões nomeadas. Permite trabalhar com LDAP fazendo configurações diferentes.

•

Atributo viewers/editors . Cada atributo pode ser associado com um visualizador particular que ajude a mostrar e editar os índices do atributo de uma maneira específica.

•

Sustentação do applet. O browser pode funcionar como um applet singed dentro de um web browser.

Figura 24 – LDAP Browser editor.

4.5.

SMBLDAP

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

de Windows (e, usando o nss_LDAP e o pam_LDAP , uma fonte original do authentification para todas as estações de trabalho, incluindo Linux e outros sistemas de Unix). A versão mais atual, traz características como: •

Remendo ao smbLDAP-passwd para ser mais seguro;

•

Reparos do erro para: relacionamentos e mensagens de erro ao usar o UserManager;

•

Diretrizes orientadoras dos certificados para a sustentação de TLS;

•

É compatível

com samba v3.

Figura 25 – Tela de login do SMLDAP.

70

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

5.1.

USUÁRIOS Usuário é alguém que possui uma identificação e no uso dessa, lhe será

permitido usufruir de um serviço.Em termos técnicos, um usuário é uma entidade identificada, e com essa identificação terá ou não acesso a um determinado serviço num dado sistema. [AURÉLIO 1999][ADMINISTRADOR LINUX] Exemplos de usuários:

5.2.

•

Usuários de rede;

•

Usuários do Banco de Dados;

•

Usuários de um web-server;

•

Correntista de uma instituição financeira

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

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

71

5.3.

GERENCIAMENTO DE USUÁRIOS Decorre do fato de organizar usuários, seus atributos, direitos, privilégios e

suas restrições em um sistema. A organização dos usuários em sistemas é feita de forma estruturada, ou seja, cada usuário é inserido em um contexto ideal na regra do negócio. A definição das regras de negócio é um estudo prévio para se delimitar as prioridades e delegar níveis de importância aos processos que os usuários venham iteragir. Um dos requisitos fundamentais para a existência de um usuário são suas características para o contexto no qual se enquadra. Essas características impõem como ele será identificado e tratado. De maneira geral, o que define os atributos são as políticas de usuários, que contém as regras de composição onde estão citadas,

as prioridades e as formas de

administração. Uma criação de uma conta em uma instituição financeira exemplifica uma política, onde o cliente deverá informar: nome, CPF, endereço, telefone, tipo de conta e senha. A regra de criação de usuário da instituição complementará os atributos necessários, para que o usuário interaja com o sistema, tais como: n° de agência, n° de conta, limite de cheque (caso seja conta corrente), data para renovação dos dados cadastrais. Com esse exemplo o usuário é criado através de atributos que servem para identificá-lo, controlá-lo e agrupá-lo a outros usuários com perfil similar. Com um conjunto de atributos definidos pela regra de negócio da instituição, o sistema é capaz de ter um controle maior sobre as ações do usuário. 5.4.

LDAP NO GERENCIAMENTO DE USUÁRIOS O LDAP tem como objetivo gerenciar diretórios. Os diretórios são conjuntos

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

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

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

74

CONCLUSÃO

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

75

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

1.

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

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

DESCRIÇÃO E ABRANGÊNCIA O Protótipo se baseará em um ambiente simulado, caracterizando uma empresa

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

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

3.

RECURSOS DE HARDWARE E SOFTWARE Será necessário para a execução do projeto dois micro computadores, cabos

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

GNU/LINUX – KURUMIN O Kurumin é uma distribuição Linux destinada a Desktops41 baseada

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

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

77

3.2

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

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

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

LDAP, por meio dele podemos configurar todas as funcionalidades deste serviço, tais como: base DN, login de administrador, requisitos de segurança e ACL’s. Algumas das características importantes do SLAPD são:

•

SLAPDv3 - O Slapd versão 3 possui suporte a IPv4 e IPv642;

• Simples autenticação segura - O Slapd suporta uma forte segurança através do uso de SASL, o qual utiliza mecanismos como MD5, EXTERNAL e GSSAPI; • Suporte a SSL; • Controle de acesso - possui um rico e poderoso controle de acesso, garantindo a segurança das informações no banco de dados e controlando as entradas baseadas no sistema de autenticação, endereço IP, domínio, e outros critérios;

• Diversificação de banco de dados - O Slapd possui diversas opções de banco de dados, Incluindo BDB e LDBM; •

Permite vários bancos de dados no mesmo servidor;

•

Possui Threads para alto desempenho;

• Replicação (slurpd) - o slapd permite ser copiado para outros servidores, podendo existir servidores master e slave, aumentando sua disponibilidade; •

É configurado através de um único arquivo de

configuração, facilitando sua manutenção. 3.2.2

42

BACKEND DE BANCO DE DADOS – BERKELEYDB

Versões de protocolo da internet 78

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

APACHE, PHP E PHPLDAPADMIN O Projeto Apache é o resultado de um esforço coletivo de colaboradores para o

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

79

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

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

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

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

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

CONFIGURAÇÕES Neste tópico serão abordadas a instalação e configuração dos softwares

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

43

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

4.1

SERVIDOR

4.1.1

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

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

INSTALAÇÃO E CONFIGURAÇÃO Com o arquivo db-4.1.25.Nc.tar.gz, já baixado e executado uma rotina de

descompactação (gz), desempacotamento (tar), compilação do Makefile e finalmente a instalação dos binários e bibliotecas, foram obedecidos os seguintes passos: Desempacotar e descompactar: $ tar -zvxf db-4.1.25.Nc.tar.gz; •

Após a execução do procedimento anterior, uma nova pasta será criada com o nome do pacote, então o caminho completo ficará “/home/kurumin/db-4.1.25”, pois o procedimento foi efetuado como usuário comum chamado “kurumin”;

•

Dentro da pasta db-4.1.25, existe uma sub-pasta denominada dist, nesta deverá ser feito os procedimentos de configuração, compilação do código fonte e instalação dos binários gerados pela configuração.

•

Na pasta dist existe um arquivo chamado configure, que é, a base da configuração de qualquer pacote distribuído em código fonte, em sistemas Linux. O arquivo configure é um script shell que examina o sistema para verificar se

as diversas dependências necessárias para compilar o projeto serão satisfeitas. Ele procura por compiladores, bibliotecas, utilitários e outros itens que deverão estar presentes no sistema, também pode receber informações extras do usuário através de diretivas de compilação como: habilitar ou desabilitar opções incluídas ou excluídas do objeto a ser compilado. Se uma ou mais dependências não forem satisfeitas, este script avisará ao usuário para que ele possa resolver tais pendências, instalando arquivos e programas

81

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

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

Após a etapa de conferência das dependências, será necessário compilar e instalar o backend de banco de dados BerkeleyDB: Compilando: kurumin@angel:~/db-4.1.25/dist# make

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

Executado os processos citados acima, a biblioteca BerkeleyDB estará devidamente instalada e configurada no sistema Linux. 4.1.2

OPENLDAP

4.1.2.1 INSTALAÇÃO E CONFIGURAÇÃO Neste tópico será abordada a instalação do servidor LDAP Open Source OpenLDAP em um ambiente GNU/Linux utilizando o shell padrão bash como interface de configuração. Para a instalação, será usado como gerenciador de Pacotes (.deb) o padrão apt da Debian, por ter um sistema de busca de pacotes e conferência de dependências muito eficientes. Serão resolvidas questões de dependências deste pacote instalando as bibliotecas necessárias para que o sistema funcione corretamente e por último instalaremos o servidor 82

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

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

Conforme a figura 29, ao chamar o pacote LDAP-utils 2.2.23-1.deb, o apt-get checa as dependências do pacote e as instala, neste caso, foi instalado por dependência, o pacote libLDAP-2.2-7 2.2.23-1 que são as bibliotecas responsáveis pela execução do LDAP e foi atualizado o pacote de SASL chamado libsasl2_2.1.19-1.5_i386.deb. Com o BerkeleyDB e o cliente instalados, deverá ser executada à instalação do Servidor SLAPD e

também configurá-lo através do Debconf. Para tanto será usado

novamente o apt para a instalação do pacote slapd:

83

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

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

84

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

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

Figura 29 - Debconf pergunta sobre compatibilidade para o LDAPv2.

85

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

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

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

86

######################################################### # Allow LDAPv2 binds allow bind_v2 # This is the main slapd configuration file. See slapd.conf(5) for more # info on the configuration options. ######################################################### # Global Directives: # Features to permit #allow bind_v2 rootdn="cn=admin,dc=ldap,dc=df" rootpw= deus # Schema and objectClass definitions include /etc/ ldap /schema/core.schema include /etc/ ldap /schema/cosine.schema include /etc/ ldap /schema/nis.schema include /etc/ ldap /schema/inetorgperson.schema include /etc/ ldap /schema/samba3x.schema # Schema check allows for forcing entries to # match schemas for their objectClasses's schemacheck on # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd/slapd.pid # List of arguments that were passed to the server argsfile /var/run/slapd.args # Read slapd.conf(5) for possible values loglevel 0 # Where the dynamically loaded modules are stored modulepath /usr/lib/ ldap moduleload back_bdb ######################################################### # Specific Backend Directives for bdb: # Backend specific directives apply to this backend until another # 'backend' directive occurs backend bdb checkpoint 512 30 ######################################################### # Specific Directives for database #1, of type bdb: # Database specific directives apply to this databasse until another # 'database' directive occurs database bdb # The base of your directory in database #1 suffix "dc= ldap,dc=df"

87

# Where the database file are physically stored for database #1 directory "/var/lib/ldap" # Indexing options for database #1 index objectClass eq # Save the time that the entry gets modified, for database #1 lastmod on # The userPassword by default can be changed # by the entry owning it if they are authenticated. # Others should not be able to see it, except the # admin entry below access to attrs=userPassword by dn="cn=admin,dc=ldap,dc=df" write by anonymous auth by self write by * none access to dn.base="" by * read # The admin dn has full write access, everyone else # can read everything. access to * by dn="cn=admin,dc=ldap,dc=df" write by * read ########################################################

4.1.2.2

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

arquivo padrão LDIF é necessária a instalação do pacote migrationtools executando o comando: # apt-get install migrationtools. Para que funcione corretamente este software necessita da versão 5 da linguagem perl, o apt resolveu todas as questões de dependência de pacotes. Diferente da maioria dos pacotes linux, o arquivo de configuração não fica na pasta

/etc (padrão linux) entretanto, localiza-se na pasta /usr/share/migrationtools/, essa

diferença é devido a extensão do arquivo de configuração que não pertence ao padrão .conf e sim ao padrão .ph, o nome do arquivo de configuração é migrate_common.ph. Neste será informado o DNS do servidor de e-mail e o sufixo da base LDAP.

88

#############/usr/share/migrationtools/migrate_common.ph########## #Default DNS domains $DEFAULT_MAIL_DOMAIN = “angel.ldap.df” $DEFAULT_BASE = “dc=ldap, dc=df” ##################################################

Após a configuração basta executar os seguintes comandos: O comando a seguir irá criar entradas de dados sobre todos os usuários do sistema, incluindo usuários de serviços, como por exemplo bind. #./migrate_passwd.pl /etc/passwd /tmp/usuarios.ldif

O comando a seguir irá criar entradas sobre os grupos do sistema linux em formato padrão LDIF. #./migrate_group.pl /etc/group /tmp/grupos.ldif

Ao executar o comando a seguir, o script definirá os objetos básicos para a criação diretório. #./migrate_base.pl > base.ldif

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

89

4.1.3

SISTEMA DE AUTENTICAÇÃO A autenticação é um processo que ocorre quando um usuário está tentando ter

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

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

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

INSTALAÇÃO E CONFIGURAÇÃO DO NSS E PAM Para que todos os serviços do sistema autentiquem no LDAP, é necessário

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

através do apt, conforme comando abaixo:

# apt-get install libnss-ldap

Será obtido os arquivos necessários e satisfeitas todas as dependências do pacote, novamente o Debconf será utilizado para inserção de informações necessárias para que o modulo libnss-LDAP funcione.

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

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

91

Figura 32 - Debconf solicita a base DN do LDAP.

É necessário para que a biblioteca libnss-ldap funcione, a definição da versão do protocolo LDAP que está instalado no sistema. Como dito anteriormente no tópico sobre a instalação do OpenLDAP, a versão do protocolo LDAP é o LDAPv3.

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

92

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

# apt-get libpam-ldap

Após a execução do comando acima, o Debconf é chamado para que sejam informados parâmetros de configuração, necessários para o funcionamento da biblioteca. O principal parâmetro é a base DN do servidor LDAP.

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

Após a instalação e pré-configuração de ambas as bibliotecas, deverá ser checado o arquivo de configuração do cliente LDAP, para que ele possa buscar informações sobre usuários na base LDAP, para isso será necessário acrescentar parâmetros de um usuário, senha e a autenticação PAM, conforme a figura abaixo:

93

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

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

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

94

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

SAMBA O SAMBA terá papel importante nesse ambiente, pois a partir dele, se proverá

um PDC (Primary Domain Controller), ou seja, um serviço que responderá por um domínio (LDAP.df) para que máquinas com sistema operacional Windows (devidamente configuradas) possam ingressar no domínio e usufruir dos serviços de arquivos. O SAMBA será devidamente configurado para que haja uma integração entre o LDAP, o mesmo armazenará todas as contas e restrições de usuários, ou seja, nenhum usuário será armazenado no smbpasswd. 4.1.4.1 INSTALAÇÃO E CONFIGURAÇÃO O gerenciador de pacotes .deb será novamente

utilizado, porém com um

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

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

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

chat

=

*New*password*

%n\n

*Retype*new*passoword*

%n\n*passwd:*all*autentication*tokens*update*successfuly*

96

socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=8192 SO_SNDBUF=8192 #script de adicionar maquinas ao dominio utilizando uma ferramenta chamada smbLDAP -tools que será

#explicada posteriormente

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

97

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

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

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

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

SID – Código numérico que identifica um servidor SAMBA 98

4.1.5.1 INSTALAÇÃO E CONFIGURAÇÃO A instalação do smbldap-tools é feita através do gerenciador de pacotes apt. e executando o comando #apt-get install smbldap-tools o pacote é devidamente instalado no sistema. O smbldap-tools não instala os arquivos de configuração na pasta /etc padrão do

Linux

mas

os

mesmos

ficam

armazenados

como

modelos

no

diretório

/usr/share/doc/smbldap-tools/examples. Os arquivos smbldap.conf.gz e o smbldap_bind.conf deverão ser copiados para a pasta /etc/smbldap-tool, o arquivo smbldap.conf.gz deverá ser descompactado com o utilitário gzip, executando o comando # gunzip /etc/smbldaptools/smbldap.conf.gz. O arquivo de configuração smbldap.conf é usado para definir parâmetros que serão utilizados pelos scripts, neste arquivo deverá ser inserido informações sobre o servidor LDAP e o servidor SAMBA. Segue o arquivo smbldap.conf na íntegra, configurado e comentado. ############################################################################## # # General Configuration # ############################################################################## # Put your own SID # SID do servidor samba pode-se obtê-lo atraves : net getlocalsid SID="S-1-5-21-2418787199-2116653073-2306110236" ############################################################################## # # LDAP Configuration # ############################################################################## #Servidor escravo, não foi necessário a utilização de um slave. # Ex: slaveldap=127.0.0.1 #slaveldap="127.0.0.1" #slavePort="389" (continua na próxima página)

99

# Master LDAP : Servidor mestre, tem que ter permissões de escrita nele # Ex: masterldap=127.0.0.1 masterldap="127.0.0.1" masterPort="389" # Use TLS for LDAP # If set to 1, this option will use start_tls for connection # (you should also used the port 389) LDAPTLS="0" # How to verify the server's certificate (none, optional or require) # see "man Net::LDAP" in start_tls section for more details verify="none" # LDAP Suffix: Sufixo do servidor LDAP. suffix="dc=ldap,dc=df" # Aqui será armazenado os usuários samba usersdn="ou=Pessoas,${suffix}" # Aqui será armazenado os computadores que terão acesso ao dominio computersdn="ou=Computadores,${suffix}" # Aqui será armazenado os grupos dos usuários groupsdn="ou=Grupos,${suffix}" # Onde são armazenadas entradas idmap (usadas se o samba é um servidor membro do domínio). idmapdn="ou=Idmap,${suffix}" # objeto em que os próximos uidNumber e gidNumber disponíveis são armazenados sambaUnixIdPooldn="cn=NextFreeUnixId,${suffix}" # escopo de pesquisa scope="sub" # Unix password encryption (CRYPT, MD5, SMD5, SSHA, SHA, CLEARTEXT) hash_encrypt="MD5" ############################################################################## # # Unix Accounts Configuration # ############################################################################## (continua) 100

# Login defs # Default Login Shell # The default Home Drive Letter mapping # Ex: userLoginShell="/bin/bash" # (will be automatically mapped at logon time if home directory exist) userLoginShell="/bin/bash" # Ex: H: for H: userHomeDrive="H:" # Home directory # Ex: userHome="/home/%U" # The default user netlogon script name (%U username substitution) userHome="/home/%U" # if not used, will be automatically username.cmd # make sure script file is edited under dos # Gecos # Ex: %U.cmd userGecos="System User" # userScript="startup.cmd" # make sure script file is edited under dos userScript=logon.bat" # Default User (POSIX and Samba) GID defaultUserGid="513" # Domain appended to the users "mail"-attribute # when smbldap-useradd -M is used # Default Computer (Samba) GID mailDomain="ldap.df" defaultComputerGid="515" ################################################ # Skel dir skeletonDir="/etc/skel" # Default password validation time (time in days) Comment the next line if # you don't want password to be enable for defaultMaxPasswordAge days (be # careful to the sambaPwdMustChange attribute's value) defaultMaxPasswordAge="30" ############################################################################## # # SAMBA Configuration # ############################################################################## # The UNC path to home drives location (%U username substitution) # Ex: \\My-PDC-netbios-name\homes\%U # Just set it to a null string if you want to use the smb.conf 'logon home' userSmbHome="\\PDC\homes\%U" # The UNC path to profiles locations (%U username substitution) # Ex: \\My-PDC-netbios-name\profiles\%U # Just set it to a null string if you want to use the smb.conf 'logon path' # directive and/or disable roaming profiles userProfile="\\PDC\profiles\%U" (continua)

101

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

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

102

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

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

APACHE A ferramenta apt será utilizada para instalação do servidor apache, não será

necessária nenhuma alteração em sua configuração padrão. Este serviço é instalado apenas para dar suporte à ferramenta administrativa phpldapadmin.

103

4.1.6.1 INSTALAÇÃO E CONFIGURAÇÃO Para iniciar a instalação, será executado o comando #apt-get install apache. Como já foi citado anteriormente esse comando resolve as dependências de pacotes e os instala. Segue a figura que ilustra o inicio da instalação no sistema Linux:

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

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

104

105

106

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

A figura 39 mostra como o apt lista as URL’s25 para obter os pacotes necessários. Após o apt baixar os pacotes, ele se encarrega de definir diretrizes padrão no arquivo /etc/apche/httpd.conf, que será posteriormente modificado para dar suporte a linguagem php4. 4.1.7

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

instalada

e

configurada

a

linguagem

php,

esta

instalação

atualiza

o

arquivo

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

25

Url – endereço eletrônico de sítio na internet. 107

Figura 40 - apt iniciando a instalação do php-ldap e php4-pear.

Após a instalação das bibliotecas de interface do php com LDAP, o sistema estará pronto para receber o software phpldapadmin. 4.1.8

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

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

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

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

os

primeiros

parâmetros

de

configuração

no

arquivo

/var/www/phpldapadmin/config.php. Na figura seguinte o Debconf pergunta qual o tipo de 108

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

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

A próxima etapa da configuração definirá qual servidor estará pronto para receber o phpldapadmin, será então selecionadas as opções: apache (servidor WEB), apachessl(plugin SSL) e Apache-perl (plugin Perl para apache).

109

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

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

110

Figura 44 - Tela inicial do phpldapadmin.

Será demonstrado um trecho do arquivo de configuração do phpldapadmin, o nome deste arquivo é config.php e fica localizado em /etc/phpldapadmin.


The phpLDAPadmin config file

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

111

// YOUR LDAP SERVERS $I=0; $SERVERS = ARRAY(); $SERVERS[$I]['NAME'] = 'MY LDAP SERVER';

/* A CONVENIENT NAME THAT WILL APPEAR IN

THE TREE VIEWER AND THROUGHOUT PHPLDAPADMIN TO IDENTIFY THIS

LDAP SERVER TO USERS. */

$SERVERS[$I]['HOST'] = 'ANGEL.LDAP.DF.'; /* EXAMPLES: 'LDAP.EXAMPLE.COM', 'LDAPS://LDAP.EXAMPLE.COM/', 'LDAPI://%2FUSR%LOCAL%2FVAR%2FRUN%2FLDAPI' (UNIX SOCKET AT /USR/LOCAL/VAR/RUN/LDAP) NOTE: LEAVE 'HOST' BLANK TO MAKE PHPLDAPADMIN IGNORE THIS SERVER.

*/

$SERVERS[$I]['BASE'] = 'DC=LDAP,DC=DF'; /* THE BASE DN OF YOUR LDAP SERVER. LEAVE THIS BLANK TO HAVE PHPLDAPADMIN AUTO-DETECT IT FOR YOU.

$SERVERS[$I]['PORT'] = 389;

*/

/* THE PORT YOUR LDAP SERVER LISTENS ON (NO QUOTES). 389 IS STANDARD. */

$SERVERS[$I]['AUTH_TYPE'] = 'SESSION';

/* THREE OPTIONS FOR AUTH_TYPE:

1. 'COOKIE': YOU WILL LOGIN VIA A WEB FORM, AND A CLIENT-SIDE COOKIE WILL STORE YOUR LOGIN DN AND PASSWORD.

2. 'SESSION': SAME AS COOKIE BUT YOUR

LOGIN DN AND PASSWORD ARE STORED ON THE WEB SERVER IN

A PERSISTENT SESSION VARIABLE.

3. 'CONFIG': SPECIFY YOUR

LOGIN DN AND PASSWORD

HERE IN THIS CONFIG FILE.

NO LOGIN WILL BE

REQUIRED TO USE PHPLDAPADMIN FOR THIS SERVER.

CHOOSE WISELY TO PROTECT YOUR AUTHENTICATION INFORMATION APPROPRIATELY FOR YOUR SITUATION. IF YOU CHOOSE 'COOKIE', YOUR COOKIE CONTENTS WILL BE ENCRYPTED USING BLOWFISH AND THE SECRET YOUR SPECIFY ABOVE AS

$BLOWFISH_SECRET. */

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

112

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

'NAME' => 'MY SAMBA DOMAIN NAME', 'SID' => 'S-1-5-21-2418787199-2116653073-2306110236' );

...

5.1

ESTAÇÃO DE TRABALHO Partindo para o âmbito dos clientes do serviço LDAP, será demonstrada a

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

AUTENTICAÇÃO Como a configuração do servidor SAMBA foi feita para ser um PDC, serão

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

CONFIGURAÇÃO 26

Samba3x.schema – é o esquema de objetos que poderão ser usados pela LDAP e suportados pelo SAMBA versão 3 113

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

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

A terceira e última parte é a desabilitação das diretivas locais de segurança, essa desabilitação pode ser feita através do aplicativo “ferramentas administrativas” na opção “diretivas de segurança local” dentro dessa janela poderá ser vista as seguintes diretivas que deverão ser desabilitadas: • Membro do domínio: criptografar ou assinar digitalmente os dados do canal seguro (sempre). • Membro do domínio: desativar alterações de senha de conta da máquina. • Membro do domínio: requerer uma chave de sessão de alta segurança (Windows 2000 ou posterior). Após procedimentos anteriores a maquina poderá ser reiniciada e após a carga completa do sistema será exibida uma tela de ingresso ao domínio, com a opção “LDAP.DF” habilitada, bastando escolher um usuário e uma senha válidos, ou seja, que estejam 27

Flag – termo inglês amplamente utilizado para explicar um bit que define a execução de um procedimento. 114

armazenados na base LDAP e com permissões de ingresso, para que o SAMBA possa validálo.

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

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

115

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

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

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

116

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

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

Nas configurações avançadas pode-se alterar a porta de comunicação com o servidor LDAP e se requer SSL. A principal configuração é a escolha da base de pesquisa que deve ser “dc=ldap,dc=df”. Após essa etapa o Outlook Express® está devidamente configurado para pesquisar na base LDAP. 5.1.2.2 PESQUISA DE INFORMAÇÕES

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

117

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

Sendo assim o cliente pode buscar informações importantes sobre determinada pessoa ou departamento, desde que esteja mapeado na DIT. Toda essa busca é realizada na base de dados LDAP. Mostrando sua funcionalidade e capacidade de integrar os sistemas de maneira eficiente. 6.

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

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

118

Figura 49 – Esquema de funcionamento do Protótipo.

Para se fazer a pesquisa de informações básicas sobre usuários, por exemplo: nome, e-mail e telefone. Não é necessária a autenticação pela PAM e NSS, nem mesmo o ingresso no PDC SAMBA. 7.

SIMULAÇÃO DO AMBIENTE Com o sistema totalmente configurado deve-se realizar testes nas

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

119

7.1

USUÁRIOS E GRUPOS Como o sistema de autenticação é baseado no domínio LDAP.DF no PDC do

SAMBA com os todos seus usuários na base LDAP, será usado como foco a criação de contas com o esquema samba3x utilizando os scripts de criação de usuários e grupos do smbldaptools. No esquema de usuários existem dois grupos chamados “Dados” e “Material”, os usuários do Grupo “Dados” são usuários avançados que necessitam de uma certa segurança já que todos as informações sigilosas ficam armazenadas nessa pasta, entretanto nenhum outro grupo pode abri-la. Os usuários do grupo “Material” podem apenas abrir a pasta “Material” e podem ler apenas o conteúdo desta pasta, não sendo permitido a gravação por estes usuários. Os membros do grupo “Dados” podem ler e gravar em ambas as pastas “Dados” e “Material”. CRIAÇÃO DE GRUPOS E USUÁRIOS Para se começar a adicionar usuários, grupos e maquinas na base LDAP para acesso ao SAMBA, é preciso primeiramente inserir os grupos “Dados” e “Material”. Lembrando que para cada objeto sendo ele grupo ou usuário é gerado um ID próprio para identificá-lo no sistema. Para a criação dos grupos será utilizado o script smbldap-grupadd seguido do nome do grupo, ou seja:

#SMBLDAP-GROUPADD DADOS #SMBLDAP-GROUPADD MATERIAL

Executado este script, será inserido na base LDAP ou=Grupos, dc=ldap, dc=df, os grupos cn=Dados e cn= Material. Para teste serão criados dois usuários cada um com seu perfil, o “usermaterial” e o “userdados” com seus respectivos grupos “material” e “dados”. Segue os scripts de criação de cada usuário: Para a criação de usuários o script smbldap-useradd será usado juntamente com alguns dos seus parâmetros: #SMBLDAP-USERADD –A –G 2005 –M –S /BIN/BASH –D /DEV/NULL –F “” –P USERDADOS #SMBLDAP-USERADD –A –G 2003 –M –S /BIN/BASH –D /DEV/NULL –F “” –P USERMATERIAL

120

Os usuários estão sendo criados na base de dados LDAP ou=Pessoas, dc=ldap,dc=df. Os testes de autenticação de usuários na base LDAP e as suas respectivas permissões já podem ser testadas no próprio servidor utilizando um shell ou mesmo algum gerenciador de arquivos gráfico, foi usado o gerenciador de arquivos konqueror da GUI-KDE. Com os serviços LDAP e SAMBA iniciados, pode-se pelo konqueror digitar o endereço smb://10.1.1.4, aparecendo as pastas “dados” e “material”, para acessar a pasta “Material” o usuário deverá estar no grupo “material” ou “dados”, e se quer acessar a pasta “Dados” deverá ter um usuário no grupo “Dados”, caso contrário não terá acesso já que o LDAP fornece todos as informações necessárias para o servidor samba libere o acesso. Após essa etapa serão executados testes de autenticação destes usuários no sistema. 7.1.1.1 AUTENTICAÇÃO Executada as tarefas de criação de usuários e seus respectivos grupos serão testados a duas maneiras de autenticação, a primeira o usuário tentando acessar as pastas do servidor SAMBA e a segunda o usuário ingressando no domínio do PDC chamado LDAP.DF, serão ilustrados nas figuras abaixo as situações que podem ocorrer. Primeira situação: acessando o servidor SAMBA sem tentar acessar as pastas.

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

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

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

Como comentado anteriormente, os usuários não participantes do grupo “dados” não têm acesso à pasta “dados”:

122

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

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

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

123

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

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

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

124

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

Feitos os testes, foi verificada a versatilidade do LDAP para facilitar a busca de informações e principalmente para organizá-las, não esquecendo da propriedade deste protocolo em integrar sistemas totalmente distintos.

125

ANEXO II – RFC’S RFC 1777 Lightweight Directory Access Protocol Protocolo de Leve Acesso a Diretórios Projetado para fornecer acesso ao X. 500. É apontado especificamente nas aplicações simples de gerência e nas aplicações do browser que fornecem acesso interativo de leitura/gravação simples ao diretório X.500 . Os elementos desse Protocolo são carregados diretamente sobre TCP ou outro transporte. Muitos elementos de dados desse protocolo são codificados como barbantes. RFC 1779 A String Representation of Distinguished Names Representação de Barbantes de Nomes Distintos O diretório OSI usa nomes distintos como as chaves preliminares às entradas no diretório. Os nomes distintos são codificados em ASN.1. Quando um nome distinto for comunicado no meio de usuários que não usam um protocolo do diretório (por exemplo, em uma mensagem do correio), há a necessidade de ter uma respresentação user-oriented (usuário-orientado) de barbante de nomes distintos. Define o formato do barbante para representar nomes, que é projetada para dar uma respresentação limpa de nomes geralmente usados, podendo representar algum nome distinto. RFC 1798 Connection-less Lightweight X.500 Directory Access Protocol Protocolo de Leve Acesso a Diretórios X.500 conexão-menos Evita o tempo decorrido que é associado com uma comunicação connectionoriented e facilita o uso do diretório em uma maneira analagous ao DNS. É destinado especificamente nas aplicações simples do lookup, que requerem para ler um número pequeno de valores, o atributo de uma única entrada. Pode ser usado como um repositório para muitos tipos da informação. É desnecessário para as aplicações que requerem o acesso lido simples a alguns valores do atributo.

126

RFC 1823 The LDAP Application Program Interface Programa de Aplicação de Interface do LDAP Define um Programa de Aplicação de Interface na línguagem C ao LDAP. O LDAP API é projetado para ser poderoso, contudo simples de usar. Define relações síncronas e assíncronas compatíveis ao LDAP para servir uma variedade larga das aplicações. RFC 1959 An LDAP URL Format Formato do URL de LDAP Descreve um formato para um localizador de recurso uniforme de LDAP que permita que os clientes de Internet tenham o acesso direto ao protocolo de LDAP. Quando o protocolo for usado somente como uma extremidade dianteira ao diretório X.500, o formato do URL descrito é, geralmente, bastante seguro para os usuários autônomos de LDAP (isto é, usuários de LDAP back-ended (extremidade traseira) por X.500). RFC 2044 UTF-8, a transformation format of Unicode and ISO 10646 UTF-8, um formato da transformação de Unicode e ISO O padrão de Unicode, a versão 1.1, e os ISO/IEC 10646-1, definem conjuntamente um carácter de 16 bits ajustado, que abranje a maioria dos sistemas do mundo. Os carácteres 16-bit, entretanto, não são compatíveis com muitas aplicações e protocolos atuais, e estes conduzem ao desenvolvimento de alguns formatos so-called da transformação do UCS (UTF), cada um com características diferentes. O UTF-8 tem a característica de preservar a escala cheia de US-ASCII. Os carácteres de US-ASCII são codificados em um octeto que tem o valor usual de US-ASCII, e todo o octeto com tal valor, pode ser somente um caráter de US-ASCII. RFC 2251 Lightweight Directory Access Protocol (v3) Protocolo de Leve Acesso a Diretórios v3 Projetado para fornecer acesso aos diretórios que suportam os modelos X.500. É apontado especificamente nas aplicações da gerência e nas aplicações do browser que fornecem o acesso interativo de leitura/gravação aos diretórios. Quando utilizado como um 127

diretório que suporta o X.500, pretende-se aproveita-lo para ser um complemento ao X.500 DAP. RFC 2252 Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions Protocolo de Leve Acesso a Diretórios V3: Definições da Sintaxe do Atributo Requer que os índices de campos de AttributeValue em elementos do protocolo sejam barbantes do octeto. Define um jogo de sintaxes para LDAPv3 e as regras pelas quais são atribuídos os valores destas sintaxes além de representados como barbantes do octeto para a transmissão no protocolo de LDAP. Podem ser definidas por este e por outros documentos que definem os tipos do atributo. Define também os tipos dos atributos que os usuários de LDAP devem suportar. RFC 2253 Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names Protocolo de Leve Acesso a Diretórios V3: UTF-8 Representação de Barbante de Nomes Distintos O diretório X.500 usa nomes distintos como chaves preliminares às entradas no diretório. Os nomes distintos são codificados em ASN.1 nos protocolos do diretório X.500. No LDAP, uma respresentação do barbante de nomes distintos é transferida. Esta especificação define o formato do barbante para representar nomes, que é projetada para dar uma respresentação limpa de nomes distintos geralmente usados, para poder representar algum nome distinto. RFC 2254 The String Representation of LDAP Search Filters Respresentação do Barbante de filtros de busca do LDAP Define uma respresentação da rede de um filtro de busca fazendo transmissões a um usuário de LDAP. Algumas aplicações podem ser úteis se encontrado uma maneira comum de representar estes filtros da busca em um formulário legível. Também define um formato legível do barbante para representar filtros da busca de LDAP. Substitui a RFC 1960, estendendo a definição do filtro do barbante do LDAP para incluir a sustentação de filtros

128

estendidos da versão 3 de LDAP e incluindo a sustentação para representar a escala cheia de filtros possíveis da busca de LDAP. RFC 2255 The LDAP URL Format Formato do URL do LDAP Descreve um formato para um localizador de recurso uniforme de LDAP e uma operação de busca para executar e recuperar a informação de um diretório de LDAP. Substitui a RFC 1959. Atualiza o formato do URL de LDAP para a versão 3 e esclarece como as URLs são resolvidas. Define também um mecanismo da extensão para as URLs, de modo que os originais futuros possam estender sua funcionalidade, como por exemplo, para fornecer o acesso às novas extensões LDAPv3 enquanto são definidos. RFC 2256 A Summary of the X.500(96) User Schema for use with LDAPv3 Um sumário X.500(96) do schema do usuário para o uso com LDAPv3 Fornece uma visão geral dos tipos de atributos e das classes dos objetos definidos pelos comitês do ISO e do ITU-T, que são aqueles pretendidos para uso dos clientes do diretório. Este é o esquema mais usado para os diretórios LDAP/X.500, além de muitas outras definições do esquema para objetos dos white pages que o utilizam como base. Não cobre os atributos usados para a administração de usuários do diretório X.500, nem inclui os atributos definidos por outros originais de ISO/ITU-T. RFC 1487 X.500 Lightweight Directory Access Protocol Protocolo de Leve Acesso a Diretórios, X500 É desenvolvido especificamente para aplicações simples da gerência e nas aplicações do browser que fornecem o acesso interativo de leitura/gravação simples ao diretório. O interesse tremendo na tecnologia X.500 na Internet se da em conduzir aos esforços para reduzir o "custo elevado da entrada" associada com o uso da tecnologia, tal como o serviço do auxílio de diretório. Quando os esforços tiverem sucesso, serão soluções como essas, baseadas em execuções particulares, que limitaram a aplicabilidade.

129

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

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

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

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

objeto para permitir que URIs, sejam armazenadas em entradas de diretório em uma maneira padrão. RFC 2116 X.500 Implementations Catalog-96

X. 500, CATALOG 96

Implementações

Define um catálogo revisado das execuções X.500 disponíveis e é baseado nos resultados do levantamento de dados de através de um Home Page WWW que permita se submeter a novas descrições ou updated de execuções atualmente disponíveis do X.500, incluindo produtos comerciais e abertamente disponíveis. RFC 2164 Use of an X.500/LDAP directory to support MIXER address mapping Uso de um diretório de X.500/LDAP de suporte para traçar endereços de um Misturador O Misturador (RFC 2156) define um algoritmo para o uso de mapas. Define como representar e manter estes mapas em um X.500 ou no diretório de LDAP. Os mecanismos para representar ou as hierarquias do endereço e do domínio ficam dentro do DIT. Estas técnicas são usadas definir dois subtrees independentes nos DIT, que contêm a informação, traçando os benefícios desta aproximação. A informação traçada é mantida em uma área claramente definida que possa ser extensamente replicada de maneira eficiente. A árvore é confinada para manter somente a informação necessitada. Isto é importante porque as passagens necessitam de bom acesso para serem traçadas por inteiro. RFC 2247 Using Domains in LDAP/X.500 Distinguished Names Usando domínios de nomes distintos LDAP/X.500 O LDAP usa nomes compatíveis do X.500 e distintos fornecendo a identificação original das entradas. Define um algoritmo, o qual, um nome registado com o serviço do Domain Name da Internet, pode ser representado como um nome distinto LDAP.

131

RFC 2307 An Approach for Using LDAP as a Network Information Service Uma aproximação para usar LDAP como um serviço de informação da rede Descreve um mecanismo experimental que traça as entidades relacionadas ao TCP/IP e ao sistema de UNIX nas entradas X.500 de modo que possam ser resolvidos com o LDAP. Um conjunto de tipos dos atributos e as classes do objeto são propostos, junto com guidelines específicos para interpretá-los. A intenção é ajudar à distribuição de LDAP como um nameservice organizational. Nenhuma solução proposta é pretendida como padrões para a Internet. RFC 2377 Naming Plan for Internet Directory-Enabled Applications Nomeação da planta para o diretório da Internet permitindo aplicações A aplicação da aproximação X.500 convencional para nomeação, prova ser um obstáculo à distribuição larga de aplicações permitidas na Internet. É proposto um diretório novo que nomeia a planta e aumente as forças da Internet, o torne mais popular e mais bem sucedido que nomeie esquemas para objetos em um diretório hierárquico. RFC 2559 Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2 Protocolos Operacionais, Infraestrutura de Chave Pública do Internet X.509 - LDAPv2 Foi projetado para satisfer algumas das exigências operacionais dentro da infraestrtura de chave pública do Internet X.509 (IPKI). Dirige-se a exigências para fornecer o acesso aos repositórios de chaves públicas do infrastructure (PKI), para as finalidades de recuperar a informação de PKI e de controlar a mesma informação. É baseado no LDAP v2, definindo um perfil desse protocolo para o uso dentro do IPKI fazendo atualizações para certificados e listas da revogação de RFC 1778. RFC 2596 Use of Language Codes in LDAP Uso de códigos da língua em LDAP O LDAP fornece meios para que os clientes possam questionar e modificar as informações armazenadas em um sistema distribuído do diretório. A informação no diretório é mantida como os atributos das entradas. A maioria destes atributos têm as sintaxes que são 132

barbantes legíveis, podendo indicar a língua natural associada com os valores do atributo. Descreve como os códigos da língua são carregados e devem ser interpretada por usuários de LDAP. Todas as execuções devem ser preparadas para aceitar códigos da língua nos protocolos de LDAP. Os usuários podem ou não podem ser capazes de armazenar atributos com códigos da língua no diretório. RFC 2649 An LDAP Control and Schema for Holding Operation Signatures Controle e esquema de LDAP para proteger assinaturas da operação Em muitos ambientes os clientes requerem habilidade ao avaliar a fonte e a integridade da informação fornecida pelo diretório. Descreve um controle da mensagem de LDAP que permita a recuperação da informação digital assinada. Define um mecanismo baseado no LDAP v3 para operações, a fim criar informações seguras das mudanças que foram feitas a cada entrada de diretório. O cliente e as assinaturas baseadas em usuários são suportados. Uma classe do objeto para a recuperação subseqüente também é definida RFC 2696 LDAP Control Extension for Simple Paged Results Manipulation Extensão do controle de LDAP para a manipulação paginada simples dos resultados Descreve uma extensão do controle LDAPv3 para a paginação simples de resultados de busca. Esta extensão do controle permite que um cliente controle a taxa em que um usuário de LDAP retorna os resultados de uma operação de busca de LDAP. Pode ser útil quando o cliente de LDAP limita recursos e não pode processar o resultado inteiro de uma pergunta dada, ou quando o cliente de LDAP está conectado sobre uma conexão de baixolargura de faixa. Esta extensão não é projetada fornecer gerência ajustada de um resultado mais sofisticado. RFC 2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema Esquema de Chave Pública de Infraestrutura do LDAPv2 do Internet X.509 Definido um esquema mínimo para suportar PKIX em um ambiente LDAPv2, como definido em RFC 2559. Somente os componentes específicos de PKIX são especificados aqui. Usuários de LDAP, agindo como os repositórios de PKIX, devem suportar as classes auxiliares do objeto definidas nesta especificação e integrar esta especificação do 133

esquema com os esquemas genéricos e outras aplicações específicas, dependendo dos serviços fornecidos por esses usuários. RFC 2589 Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services Protocolo de Leve Acesso a Diretórios V3: Extensões para serviços dinâmicos do diretório Define as exigências para serviços dinâmicos do diretório e especifica o formato do pedido e operações estendidas do usuário em um ambiente dinâmico dos diretórios. O LDAP suporta acesso aos serviços estáticos do diretório, permitindo um acesso relativamente rápido da busca e do update. Os serviços estáticos do diretório armazenam informação sobre a pessoa que persiste em sua exatidão e valor sobre um período de longo tempo. Os serviços dinâmicos do diretório são diferentes, pois armazenam a informação que persiste somente em sua exatidão e valor quando está sendo refrescada periodicamente. Esta informação é armazenada como entradas dinâmicas no diretório. RFC 2657 LDAPv2 Client vs. the Index Mesh Cliente LDAPv2 contra o engranzamento do índice Os clientes LDAPv2, como executados de acordo com RFC 1777, não têm nenhuma noção referencial. A integração entre tal cliente e engranzamento do índice, como definido pelo protocolo comum de indexação, depende pesadamente dos referenciais e conseqüentemente das necessidades de segurança em uma maneira especial. RFC 2713 Schema for Representing Java(tm) Objects in an LDAP Directory Schema para representar objetos de Java(tm) em um diretório de LDAP Define o esquema para representar objetos de Java(tm) em um diretório de LDAPv3. Define elementos do esquema para representar um objeto colocado em série Java, um objeto marshalled Java [ RMI ], um objeto remoto de Java [ RMI ] e uma referência de [ JNDI ].

134

RFC 2739 Calendar Attributes for vCard and LDAP Atributos do calendário para o vCard e o LDAP Ao programar uma entidade do calendário, tal como um evento, é um prérequisito que um organizador tenha o endereço do calendário de cada participante que será convidado ao evento. Adicionalmente, o acesso ao tempo "ocupado" atual de um participante fornece uma indicação de que o participante estará livre participar no evento. A fim de se encontrar com estes desafios, um agente usuário do calendário (CUA) necessita de um mecanismo para encontrar um (URI), o calendário do usuário individual e o tempo de free/busy. Define três mecanismos para obter um URI: transferência manual da informação; troca de dados pessoal usando o formato do vCard e lookup do diretório usando o protocolo de LDAP. RFC 2798 Definition of the inetOrgPerson LDAP Object Class Definição da classe do objeto do inetOrgPerson LDAP Quando os padrões X.500 definem muitos tipos úteis do atributo [ X520 ] e classes do objeto [ X521 ], não definem uma classe do objeto da pessoa que se encontre com as exigências distribuídas do serviço no diretório da Internet e da Intranet. Define uma classe nova do objeto chamada inetOrgPerson para o uso em serviços do diretório LDAP e X.500 que estende a classe padrão do organizationalPerson X.521. RFC 2820 Access Control Requirements for LDAP Exigências do controle de acesso para LDAP Descreve as exigências fundamentais de um modelo do Access Control List (ACL) para o serviço de (LDAP). Pretende-se ser um lugar de recolhimento para as exigências do controle de acesso necessitadas fornecer o acesso autorizado e a interoperabilidade entre diretórios.

135

RFC 2829 Authentication Methods for LDAP Métodos de Autenticação para LDAP Especifica combinações particulares dos mecanismos de segurança que são requeridos e recomendados em execuções do LDAP. A versão 3 de LDAP é um protocolo poderoso de acesso a diretórios. Oferece meios de procura, de busca e de manipulação do índice do diretório, e as maneiras de alcançar um conjunto rico de funções de segurança. A fim funcionar melhor para Internet, é vital que estas funções da segurança sejam bem operadas, conseqüentemente tem que haver um subconjunto mínimo de funções da segurança que seja comum a todas as execuções que reivindicam o conformidade ao LDAPv3. RFC 2830 Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security Protocolo de Leve Acesso a Diretórios V3: Extensão para a segurança da camada de transporte Define "a operação de segurança da camada de transporte (TLS)" para LDAP Esta operação fornece para o estabelecimento de TLS uma associação de LDAP e é definida nos termos de um pedido estendido do LDAP. RFC 2849 The LDAP Data Interchange Format (LDIF) - Technical Specification O Formato Do Intercâmbio Dos Dados de LDAP (LDIF) - Especificação Técnica Descreve um formato da ferramenta apropriada para descrever a informação ou as modificações do diretório feita à informação do diretório. O formato da ferramenta, conhecido como LDIF, para o formato do intercâmbio dos dados de LDAP, é usado tipicamente para importar e exportar a informação do diretório entre usuários LDAP ou descrever um jogo das mudanças que devem ser aplicadas a um diretório. RFC 2891 LDAP Control Extension for Server Side Sorting of Search Results Extensão do controle de LDAP para a classificação lateral do usuário de resultados da busca Descreve duas extensões de controle do LDAPv3 para a classificação lateral do usuário e de resultados da busca. Estes controles permitem que um cliente especifique os tipos 136

do atributo e combina regras que um usuário deve usar quando retornar os resultados de um pedido da busca de LDAP. Os controles podem ser úteis quando o cliente de LDAP limitar a funcionalidade ou não puder classificar os resultados que necessita. RFC 2926 Conversion of LDAP Schemas to and from SLP Templates Conversão de esquemas de LDAP e dos moldes de SLP Descreve um procedimento para traçar propagandas do serviço do protocolo, da posição do serviço (SLP) e das descrições do (LDAP). Um aspecto está traçando entre o esquema do tipo moldes do serviço de SLP e do diretório de LDAP. A gramática do serviço de SLP do molde é relativamente simples, traçar o tipo moldes ao tipo do LDAP é direto. Traçar em outro sentido é direto, se os atributos, forem restringidos para usar apenas algumas das sintaxes definidas em RFC 2252. RFC 2927 MIME Directory Profile for LDAP Schema Perfil do diretório do MIME para o schema de LDAP Define um perfil de múltiplos propósitos do diretório das extensões do correio da Internet (MIME) para prender um esquema do (LDAP). Pretende-se para uma comunicação com o serviço da lista do esquema da Internet. RFC 3045 Storing Vendor Information in the LDAP root DSE Armazenamento de Informação para LDAP na raiz do DSE Especifica dois atributos do (LDAP), vendedor de nomes e o vendedor de versões, incluídos na entrada DSA -específica da raiz (DSE) para anunciar a informação vendedor-específica. A informação presas nestes atributos podem ser usadas para a exposição e finalidades informativas e não devem ser usadas para a propaganda ou a descoberta da característica.

137

RFC 3062 LDAP Password Modify Extended Operation A Senha de LDAP Modifica Operação Prolongada A integração do LDAP e de serviços externos do authentication introduziu identidades do authentication no DN e permitiu o armazenamento do diretório das senhas. Os mecanismos que atualizam o diretório não podem ser usados para mudar a senha de um usuário. Descreve uma operação estendida do LDAP para permitir a modificação de senhas do usuário que não é dependente do formulário da identidade do authentication nem do mecanismo de armazenamento da senha usada. RFC 3088 OpenLDAP Root Service An experimental LDAP referral service Serviço da raiz de OpenLDAP um serviço de referral experimental de LDAP O projeto de OpenLDAP está operando num serviço experimental de LDAP, como também "o serviço da raiz OpenLDAP". O sistema automatizado gera referencias baseadas nas informaçãos das posições do serviço publicado em DNS SRV RRs (posição do Domain Name System de registros do recurso dos serviços). RFC 3112 LDAP Authentication Password Schema Esquema de Senha de Autenticação do LDAP Descreve o esquema na sustentação do authentication de user/password em um diretório de LDAP incluindo o tipo do atributo do authPassword. Este tipo do atributo mantem valores derivados do password(s) do usuário. O authPassword é pretendido para ser usado no lugar do userPassword. RFC 3296 Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories Referência de nomes Subordinados em Diretórios (LDAP) Detalha elementos do esquema e do protocolo para representar e controlar referências subordinadas nomeadas em diretórios de LDAP.

138

RFC 3352 Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status Conexão-menos do Protocolo CLDAP Status do Histórico A especificação técnica de (CLDAP), RFC 1798, foi publicada como um padrão proposto e discute as razões as quais a especificação técnica de CLDAP não foi promovida na trilha padrão. RFC 3377 Lightweight Directory Access Protocol (v3): Technical Specification Protocolo de Leve Acesso a Diretórios V3: Especificação Técnica Especifica o jogo de RFCs que compreendem a versão 3 do LDAPv3, e endereços "a nota IESG" unida a RFCs 2251 a 2256. A especificação para a versão 3 do LDAP compreende oito RFCs que foram emitidos em dois subconjuntos distintos. O RFC 2251 a 2256 não exige a execução de nenhuns mecanismos satisfatórios do authentication e daqui não estêve publicado com "uma execução da nota IESG" e uma distribuição desanimadoras dos clientes LDAPv3 ou dos usuários que executam a funcionalidade do update até que um padrão proposto para o authentication imperativo em LDAPv3 esteja publicado. O RFC 2829 foi publicado subseqüentemente na resposta à nota do IESG. A finalidade deste original é especificar explicitamente o jogo de RFCs que compreende LDAPv3, e dirige-se formalmente à nota do IESG através do inclusion explícito de RFC 2829. RFC 3383 Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) Considerações do Internet Assigned Numbers Authority (IANA) para Protocolo de Leve Acesso a Diretórios (LDAP) Fornece procedimentos registando elementos extensivos do (LDAP). Fornece também guidelines ao Internet Assigned Numbers Authority (IANA) que descreve as circunstâncias sob que os valores novos podem ser atribuídos. Sustentações de LDAP: adição de operações novas, extensão de operações existentes, e esquema extenso.

139

RFC 3384 Lightweight Directory Access Protocol (version 3) Replication Requirements Protocolo de Leve Acesso a Diretórios LDAP (versão 3) Exigências de Replicação Discute as exigências fundamentais para a replicação dos dados acessíveis através do (LDAPv3). Pretende-se ser um lugar de recolhimento para as exigências gerais do replication necessitando fornecer o interoperability entre diretórios informativos. RFC 3494 Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status Protocolo de Leve Acesso a Diretórios Versão 2 (LDAPv2) Status do Histórico Recomenda a aposentadoria da versão 2 (LDAPv2) e de outras especificações dependentes. É usado alcançar serviços do diretório de X.500-based. Recomenda que LDAPv2 e outras especificações dependentes estejam aposentados. RFC 3663 Domain Administrative Data in Lightweight Directory Access Protocol (LDAP) Dados administrativos do domínio no Protocolo de Leve Acesso a Diretórios (LDAP) Os dados do registo do domínio foram expostos tipicamente ao público geral através de Nicname/Whois para finalidades administrativas. Este original descreve o serviço de (LDAP), um serviço experimental usando LDAP e tipos well-known de LDAP fazer domínio dados administrativos disponíveis. RFC 3671 Collective Attributes in the Lightweight Directory Access Protocol (LDAP) Atributos coletivos dentro do Protocolo de Leve Acesso a Diretórios (LDAP) Os atributos X.500 coletivos permitem que as características comuns sejam compartilhadas entre as coleções das entradas. Ele sumaria o modelo da informação X.500 para os atributos coletivos e descreve o uso de atributos coletivos em LDAP. Fornece definições do esquema para atributos coletivos para o uso em LDAP.

140

RFC 3672 Subentries in the Lightweight Directory Access Protocol (LDAP) Subentries no Protocolo de Leve Acesso a Diretórios (LDAP) Nos diretórios X.500, os subentries são entradas especiais usadas para manter a informação associada com um subtree ou um refinement do subtree. Adapta mecanismos dos subentries X.500 para o uso com o (LDAP). RFC 3673 Lightweight Directory Access Protocol version 3 (LDAPv3): All Operational Attributes Protocolo de Leve Acesso a Diretórios LDAP (versão 3): Todos os Atributos Operacionais O (LDAP) suporta um mecanismo para pedir o retorno de todos os atributos do usuário mas de não todos os atributos operacionais. Descreve uma extensão de LDAP que os clientes possam usar para pedir o retorno de todos os atributos operacionais. RFC 3674 Feature Discovery in Lightweight Directory Access Protocol (LDAP) Descoberta de características no Protocolo de Leve Acesso a Diretórios LDAP O (LDAP) é um protocolo extensível com características numerosas. Introduz um mecanismo geral para a descoberta das características e das extensões que não podem ser descobertas usando mecanismos existentes. RFC 3687 Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules Protocolo de Leve Acesso a Diretórios LDAP e réguas combinando do componente X.500 Define as sintaxes dos atributos em uma escala de (LDAP) ou do diretório X.500 dos tipos de dados simples, tais como a corda de texto, o inteiro, o booleano, os tipos de dados estruturados complexos e também as sintaxes dos atributos operacionais do esquema do diretório. As regras definidas para as sintaxes complexas são mais imediatas e úteis, combinando a potencialidade. Define as regras genéricas que podem combinar todas as partes selecionadas usuário em um valor do atributo de qualquer sintaxe arbitrariamente complexa do atributo.

141

RFC 3698 Lightweight Directory Access Protocol (LDAP): Additional Matching Rules Protocolo de Leve Acesso a Diretórios LDAP : Réguas Combinando Adicionais Fornece uma coleção de regras combinando o uso com o (LDAP). Estas regras são adaptações simples das regras especificadas para o uso com o diretório X.500, a maioria são já dentro uso largo. RFC 3703 Policy Core Lightweight Directory Access Protocol (LDAP) Schema Esquema do Protocolo de Leve Acesso a Diretórios Do Núcleo Da Política (LDAP) Define o modelo da informação do núcleo da política a um formulário que possa ser executado em um diretório que use o (LDAP) como seu protocolo do acesso. Define duas hierarquias de classes do objeto: as classes estruturais que representam a informação para dados de representação e controle da política como especificados em RFC 3060, e o relacionamento que classifica e indica como os exemplos das classes estruturais são relacionados. As classes são adicionadas também ao esquema de LDAP para melhorar o desempenho de interações de um cliente com um usuário de LDAP quando o cliente está recuperando quantidades grandes de informações relacionadas. RFC 3712 Lightweight Directory Access Protocol (LDAP): Schema for Printer Services Protocolo de Leve Acesso a Diretórios (LDAP) : Schema para Serviços de Impressora Define um esquema de objeto que classifica e atribui, para impressoras e serviços da impressora, o uso de diretórios que suportam o v3 (LDAP-TS). Baseado nos atributos da impressora alistados no apêndice e no Internet Protocol/1.1 (IPP). Alguns atributos adicionais da impressora são baseados em definições no MIB da impressora. RFC 3727 ASN.1 Module Definition for the LDAP and X.500 Component Matching Rules Definição do módulo ASN.1 para réguas combinando do componente LDAP e X.500 Atualiza a especificação das regras combinando componentes para o (LDAP) e os diretórios X.500 coletando as definições do Abstract Syntax Notation One (ASN.1) das regras combinando componentes em um módulo ASN.1, e identificado outras especificações

142

que possam referenciar as definições, combinando regras dos componentes dentro de seus próprios módulos ASN.1. RFC 3771 The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message Protocolo de Leve Acesso a Diretórios (LDAP) Mensagem De Resposta Intermediária Define e descreve a mensagem de IntermediateResponse, um mecanismo geral para definir operações de single-request/multiple-response no (LDAP). A mensagem de IntermediateResponse é definida de tal maneira que o comportamento do protocolo de operações existentes de LDAP é mantido. Esta mensagem é usada conjuntamente com o LDAP

ExtendedRequest

e

ExtendedResponse

para

definir

operações

novas

de

request/multiple-response ou conjuntamente com um controle ao estender operações existentes de LDAP em uma maneira que as requeira retornar a informação intermediária da resposta. RFC 3829 Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls Protocolo de Leve Acesso a Diretórios (LDAP) Controles do pedido e da resposta da identidade da autorização Estende a operação do (LDAP) com um mecanismo para pedir e retornar a identidade para estabelecer uma autorização. Define os controles do pedido e da resposta da identidade da autorização para o uso com a operação do ligamento.

143

BIBLIOGRAFIA

[APACHE] Apache Organization. Disponível em < http://www.apache.org >. Acesso em: 10 abril, 2005, 02:00. [AURÉLIO,1999] Aurélio, B. H. Ferreira, Dicionário da Língua Portuguesa. 3ª Ed., Nova Fronteira. Rio de Janeiro – Brasil, 1999. [CARTER,2003] CARTER, Gerald – LDAP System Administration. 1ª Edição, O’Reilly & Associates. USA, 2003. [CERTIFICAÇÃO LINUX] Ribeiro, uirá. Editora Axcel ISBN: 85 - 7323 -232 -3. [CONECTIVA 2004] EQUIPE CONECTIVA Copyright 2004 S.A.

Guia

do

Servidor

Conectiva

Linux.

Conectiva Disponível

em:

. Acesso em: 24 fev. 2005, 23:30. [DONLEY,2002] DONLEY, Clayton – LDAP Programming, Management and Integration. 1ª Edição, Manning Publications. USA, 2002. [FERREIRA,2003] FERREIRA, Rubem E. – Linux Guia do Administrador do Sistema. Primeira Edição, Novatec. São Paulo - Brasil, 2003. [GROSSMANN,2001] GROSSMANN, César A.K. Linux by Grossmann. Disponível em: . Acesso em: 23 Fev. 2005, 00:40. [GUIA DO HARDWARE] Morimotto, carlos. Desvendando seus segredos. Editora Altabooks, ISBN: 85-7608064-8.

144

[HOWES,1995] HOWES, timothy A. – The Lightweight Directory Access Protocol: X.500 Lite. Disponível em:< http://www.openldap.org/pub/umich/ldap.pdf >. Acesso em: 23 fev. 2005, 23:00. [HOWES,1997] HOWES, timothy A.;Smith,Mark – Programming Directory-Enabled Aplications with Lightweight Directory Access Protocol. 1ª Edição, MacMillan Technical Publishing. USA, 1997. [HOWES,2003] HOWES, timothy A.;Smith,Mark;Good,Gordon – Understanding And Deploying LDAP Directory Services. 2º Edição, Addison-Wesley Pub Co. USA, 2003. [ISQUIERDO,2001] ISQUIERDO, Gustavo S. – Integração do Serviço de Diretórios LDAP com

o

Serviço

de

Nomes

CORBA,

Disponível

em:<

http://www.teses.usp.br/teses/disponiveis/45/45134/tde-28052003-100121/>. Acesso em: 27 de Abril, 16:08. [JOHNER,1998] JOHNER, Heinz;Brown, Larry;Hinner, Franz-Stefan;Reis, Wolfgang; Westman, Johan – Understanding LDAP, IBM Redbook. USA ,1998. [KAINES, 2001] KAINES, Luke A. Primeiros Passos com LDAP. Disponível em: . Acesso em: 24 Fev. 2005, 00:50. [KAINES, 2001] KAINES, Luke A. Uma Introdução ao LDAP. Disponível em: . Acesso em: 24 Fev. 2005, 00:15. [LINUX 2005] Guia do Servidor Conectiva Linux, . Autenticação do Sistema. Disponível em: . Acesso em: 23 Fev. 2005, 01:00. [MARCELO,2003] MARCELO, Antonio – Apache – Configurando o Servidor Web para LINUX. 2ª Edição, Brasport. São Paulo, 2003.

145

[NAGUEL1] NAGUEL,

Frederico F.; Fernandes, Elaine;

– Diretório Distribuido,

Disponível em:< http://www.ldap.liceu.com.br/conceitos/distribuido.htm>. Acesso em:27 de Abril, 14:21. [NAGUEL2] NAGUEL, Frederico F.; Fernandes, Elaine; – Diretório Replicado, Disponível em:< http://www.ldap.liceu.com.br/conceitos/distribuido.htm>. Acesso em:27 de Abril, 14:25. [RIBEIRO,2004] RIBEIRO, Uirá – Certificação LINUX. 1ª Edição Axel Books, São Paulo, 2004. [RNP, 2001] RNP – Rede Nacional de Ensino e Pesquisa. ACL Como Funciona. Disponível em: . Acesso em: 27 Abr. 2005, 16:08. [SLEEPCAT] Sleepycat Software: Berkeley DB Database, Native XML Database, Native Java Database. Disponível em <www.sleepcat.com > . Acesso em: 10 abril, 2005, 23:43. [WILCOX,1999] WILCOX,Mark – Implementing LDAP. 1ª Edição, WROK Press. USA, 1999. [TUTTLE,2003] TUTTLE , Steven; Ehfenberg,Ami; Gorthi,Ramakrishna; Leiserson,Jay; Macbeth,Richard; Owen,Nathan; Ranahandola,Sunil; Storrs,Michael; Yang,Chunhui – Undertanding LDAP Desingn and Implementation. Edição,IBM RedBook. 2003. [TUTTLE,2004] TUTTLE,Steven; Godbole Kedar; McCarthy,Grant –

Using LDAP for

Directory Integration.IBM RedBook. USA, 2004. [RFC 1777] W. Yeong, T. Howes, S. Kille - Lightweight Directory Access Protocol Obsoletes: 1487. Disponível em < http://www.ietf.org/rfc/rfc1777.txt?number=1777 > Março de 1995. [RFC 1777] W. Yeong, T. Howes, S. Kille - Lightweight Directory Access Protocol Obsoletes: 1487. Disponível em < http://www.ietf.org/rfc/rfc1777.txt?number=1777 > Março de 1995. 146

[RFC 1779] S. Kille - A String Representation of Distinguished Names Obsoletes: 1485. Disponível em < http://www.ietf.org/rfc/rfc1779.txt?number=1779>, Março de 1995. [RFC 1798] A. Young - A Connection-less Lightweight X.500 Directory Access Protocol Disponível em < http://www.ietf.org/rfc/rfc1798.txt?number=1798 >, Junho de 1995. [RFC 1823] T. Howes, M. Smith - The LDAP Application Program Interface Disponível em < http://www.ietf.org/rfc/rfc1823.txt?number=1823 >, Agosto de 1995. [RFC 1959] T. Howes, M. Smith - An LDAP URL Format Disponível em < http://www.ietf.org/rfc/rfc1959.txt?number=1959 >, Junho de 1996 [RFC 2044] F. Yergeau - UTF-8, a transformation format of Unicode and ISO 10646 Disponível em < http://www.ietf.org/rfc/rfc2044.txt?number=2044 >, Outubro de 1996 [RFC 2251] M. Wahl, T. Howes, S. Kille - Lightweight Directory Access Protocol (v3) Disponível em < http://www.ietf.org/rfc/rfc2251.txt?number=2251 >, Dezembro de 1997 [RFC 2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille - Lightweight Directory Access Protocol

(v3):

Attribute

Syntax

Definitions

Disponível

em

<

http://www.ietf.org/rfc/rfc2252.txt?number=2252 >, Dezembro de 1997. [RFC 2253] M. Wahl, T. Howes, S. Kille - Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names. Obsoletes: 1779. Disponível em < http://www.ietf.org/rfc/rfc2253.txt?number=2253 >, Dezembro de 1997. [RFC 2254] T. Howes - The String Representation of LDAP Search Filters Disponível em < http://www.ietf.org/rfc/rfc2254.txt?number=2254 >, Dezembro de 1997. [RFC 2255] T. Howes , M. Smith - The LDAP URL Format Disponível em < http://www.ietf.org/rfc/rfc2255.txt?number=2255 >, Dezembro de 1997.

147

[RFC 2256] M. Wahl - A Summary of the X.500(96) User Schema for use with LDAPv3. Disponível em < http://www.ietf.org/rfc/rfc2256.txt?number=2256 >, Dezembro de 1997. [RFC 1487] W. Yeong, T. Howes, S. Kille - X.500 Lightweight Directory Access Protocol Disponível em < http://www.ietf.org/rfc/rfc1487.txt?number=1487 >, Julho de 1993. [RFC 1558] T. Howes - A String Representation of LDAP Search Filters Disponível em < http://www.ietf.org/rfc/rfc1558.txt?number=1558 >, Dezembro de 1993. [RFC 1778] T. Howes, S. Kille, W. Yeong, C. Robbins - The String Representation of Standard

Attribute

Syntaxes.

Obsoletes:

1488.

Disponível

em

, Março de 1995. [RFC 1960] T. Howes - A String Representation of LDAP Search Filters. Obsoletes: 1558. Disponível em , Junho de 1996. [RFC 2079] M. Smith - Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs) Disponível em , Janeiro de 1997. [RFC 2164] S. Kille - Use of an X.500/LDAP directory to support MIXER address mapping Obsoletes: 1838. Disponível em http://www.ietf.org/rfc/rfc2164.txt?number=2164 >, Janeiro de 1998. [RFC 2247] S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri - Using Domains in LDAP/X.500 Distinguished Names. Disponível em , Janeiro de 1998. [RFC 2307] L. Howard - An Approach for Using LDAP as a Network Information Service Disponível em , Março de 1998. [RFC 2377] A. Grimstad, R. Huber, S. Sataluri, M. Wahl Directory-Enabled

Applications.

Disponível

em

Naming Plan for Internet


number=2377 >, Setembro de 1998. 148

[RFC 2559] S. Boeyen, T. Howes, P. Richard - Internet X.509 Public Key Infrastructure Operational

Protocols

-

LDAPv2.Updates:

1778.

Disponível

em

<

http://www.ietf.org/rfc/rfc2559.txt?number=2559 >, Abril de 1999. [RFC 2596] M. Wahl, T. Howes - Use of Language Codes in LDAP. Disponível em < http://www.ietf.org/rfc/rfc2596.txt?number=2596 >, Maio de 1999. [RFC 2649] B. Greenblatt, P. Richard - An LDAP Control and Schema for Holding Operation Signatures. Disponível em , Agosto de 1999. [RFC 2696] C. Weider, A. Herron, A. Anantha, T. Howes - LDAP Control Extension for Simple Paged Results Manipulation. Disponível em , Setembro de 1999. [RFC 2587] S. Boeyen, T. Howes, P. Richard - Internet X.509 Public Key Infrastructure LDAPv2 Schema.Disponível em , Junho de 1999. [RFC 2589] Y. Yaacovi, M. Wahl, T. Genovese - Lightweight Directory Access Protocol (v3): Extensions

for

Dynamic

Directory

Services

.Disponível

em

, Maio de 1999. [RFC 2567] R. Hedberg - LDAPv2 Client vs. the Index Mesh Services .Disponível em , Agosto de 1999. [RFC 2713] V. Ryan, S. Seligman, R. Lee -

Schema for Representing Java(tm) Objects in

an LDAP Directory. Disponível em , Outubro de 1999. [RFC 2739] T. Small, D. Hennessy , F. Dawson - Calendar Attributes for vCard and LDAP. Disponível em , Janeiro de 2000.

149

[RFC 2798] M. Smith - Definition of the inetOrgPerson LDAP Object Class. Disponível em , Abril de 2000. [RFC 2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan - Authentication Methods for LDAP Disponível em , Maio de 2000. [RFC 2830] J. Hodges, R. Morgan, M. Wahl - Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security. Disponível em , Maio de 2000. [RFC 2849] G. Good - The LDAP Data Interchange Format (LDIF) - Technical Specification Disponível em , Junho de 2000. [RFC 2891] T. Howes, M. Wahl, A. Anantha - LDAP Control Extension for Server Side Sorting

of

Search

Results.

Disponível

em


number=2891>, Agosto de 2000. [RFC 2926] J. Kempf, R. Moats, P. St. Pierre - Conversion of LDAP Schemas to and from SLP

Templates.

Disponível

em

,

Setembro de 2000. [RFC 2927] M. Wahl - MIME Directory Profile for LDAP Schema. Disponível em , Setembro de 2000. [RFC 3045] M. Wahl - Storing Vendor Information in the LDAP root DSE.Disponível em , Janeiro de 2001.

[RFC 3062] K. Zeilenga - LDAP Password Modify Extended Operation .Disponível em , Fevereiro de 2001. [RFC 3088] K. Zeilenga - OpenLDAP Root Service An experimental LDAP referral service .Disponível em , Abril de 2001. 150