LDAP LDAP

CAPTULO 1

LDAP
LDAP um protocolo de acesso a diretrios cada vez mais utilizado em redes de computadores. Ao final deste capitulo voc dever ser capaz de: Entender os conceitos de diretrios Entender atributos de classes de objetos Entender um arquivo LDIF

LDAP LDAP

1.1 Servios de Diretrios

Diretrios so simplesmente bancos de dados que armazenam informaes, mas com algumas diferenas importantes: Hierarquia: os bancos de dados de diretrios so hierrquicos, ou seja, em vez de utilizarem uma estrutura de tabelas com registros e comps, utilizam uma estrutura em arvore, semelhantemente a um sistema de arquivos; Otimizao para leitura: diretrios so caracterizados por terem muito mais acessos de leitura e consulta do que de escrita. Ou seja, no se espera que os dados armazenados ali mudem com frequncia; Distribuio: a estrutura em arvore permite que ramos especficos da arvore sejam armazenados em outros servidores sem prejudicar a viso global dos dados; Padronizao forte: os dados armazenados em diretrios seguem uma padronizao forte tanto na nomenclatura como no tipo de dado, normalmente baseados em RFCs. Nem sempre fcil decidir se um diretrio ser melhor ou pior para um dado sistema do que um banco de dados tradicional. Afinal, bancos de dados so bastante rpidos tambm, inclusive para escritas, que costuma ser o ponto fraco dos diretrios. Mas utilizam tabelas, sendo que uma estrutura hierrquica pode ser melhor para alguns casos. Afinal, quando usar um e quando usar outro? Diretrios so mais recomendados para as seguintes situaes: Baixo volume de escritas: nada de utilizar um diretrio para armazenar transaes bancarias ou pedidos de clientes de uma loja virtual, por exemplo; Natureza hierrquica do servio: por exemplo, autenticao de usurios em uma grande empresa com vrios setores e filiais geograficamente distantes; Padronizao: o servio ser utilizado por uma enorme variedades de clientes de sistemas operacionais distintos. Por exemplo, um catalogo de endereos pode ser acessado por clientes de e-mail, navegadores Web, sistemas de autenticao, etc; Delegao: a necessidade de delegao de parte do banco de dados para outro servidor e outro administrador reflete a natureza hierrquica do servio, ou pelo menos esta necessidade. Com um diretrio voc pode decidir mover um ramo inteiro da arvore para outro servidor sem prejudicar a viso global dos dados. Basta inserir um ponteiro no local original da arvore apontando para o novo servidor. De forma geral, um diretrio no deve ser usado para armazenar dados binrios grandes. Pequenas imagens para identificao de usurios, ou sertificados digitais, so aceitveis, mas no coisas como cach do navegador de internet, mensagens de e-mail, arquivos genricos, copias de documentos, etc.

LDAP LDAP

1.2 LDAP
LDAP (Lightweight Directory Access Protocol) um protocolo simples de acesso a servios de diretrios. Muitas vezes se fala em banco de dados LDAP, mas esta uma expresso tecnicamente incorreta: o banco do diretrio e LDAP so entidades diferentes. A figura a seguir ilustra esta distino:

Servidor LDAP Cliente LDAP

Consulta LDAP Resposta

Banco de Dados
Backend

Nesta figura, banco de dadosno servidor LDAP pode ser at um banco de dados SQL (embora no seja muito adequado para armazenar estruturas hierrquicas). Do ponto de vista do cliente, no importa qual a implementao, e fato que existem varias. Por ser padronizado e simples de implementar do ponto de vista do desenvolvedor, a utilizao de LDAP para acessar diretrios bastante tentadora para centralizar as mais diferentes informaes visto que diversos programas possuem suporte a este protocolo. A grande maioria dos clientes de e-mail, por exemplo, suporta LDAP para funo de catlogo de endereos.

1.3 Schemas
Todas as informaes armazenadas em um diretrio precisam obedecer a um conjunto de definies chamado schema. O schema de um diretrio define: Classes de objetos; Atributos; Regra de ordenao e ndice para atributos; Qual o OID (Object IDentifier) dos objetos/atributos; Herana de classes de objetos. Atributos e classes de objetos so a parte principal da estrutura dos diretrios: Atributos: semelhantes a campos em tabelas de bancos de dados, fazem parte das entradas do diretrio. Alguns atributos podem ser repetidos (como um atributo de

LDAP LDAP numero de telefone) e outros devem ser nicos (como um cdigo de identificao de usurio); Classes de objetos: so definies que determinam que tipos de atributos podem fazer parte da entrada do diretrio e que atributos devem obrigatoriamente fazer parte do diretrio. Classes ainda so divididas em estruturais, que representam um objeto do mundo real, e auxiliares, que simplismente agregam informaes a uma entrada. Veremos exemplos mais adiante. Todas as entradas do diretrio devem ter uma e somente uma classe de objeto do tipo estrutural. Muitas classes j vm criadas nos servidores de diretrios e so padronizadas em RFCs e registradas no IANA (Internet Assigned Numbers Authority, www.iana.org). Por exemplo, considere o seguinte diretrio:
dc = exemplo, dc = com, dc = br

ou = grupos

ou = pessoas

objectClass: organizationalUnit ou: pessoas

cn = Benjamin objectClass: person sn: sisko atributos obrigatrios cn: Benjamin telefoneNumber: 999-9999 atributos opcionais telefoneNumber: 123-1133

DN: cn= benjamin , ou=pessoas , dc=exemplo , dc=com , dc=br RDN Este diretrio pode ser representado atravs de um formato texto chamado de LDIF (LDAP Data Interchange Format):
dn: dc=exemplo,dc=com,dc=br dc: exemplo objectClass: top objectClass: domain objectClass: domainRelatedObject associateDomain: exemplo.com.br dn: ou=Pessoas,dc=exemplo,dc=com,dc=br objectClass: top objectClass: organizationalUnit ou: pessoas description: Ramo contendo as entradas de pessoas dn: cn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br cn: benjamin sn: sisko objectClass: person telephoneNumber: 999-9999 telephoneNumber: 123-1133 dn: ou=grupos,dc=exemplo,dc=com,dc=br objetcClass: top objetcClass: organizationalUnit ou: grupos
4

LDAP LDAP A sintaxe do formato LDIF bem simples, obedecendo basicamente as seguintes regras: Uma linha identificando o DN (Distinguished Name), ou seja, o local onde os atributos listados nas linhas seguintes devem ser adicionados; Listagem de atributos no formato atributo: valor. Caso o atributo contenha dados binrios, eles devem ser codificados em BASE-64 e inseridos ao final de atributo:: (ou seja, dois sinais de : em vez de apenas um); Caracteres acentuados devem utilizar a codificao UTF-8; Uma linha em branco separando as entradas umas das outras. O nome cn=benjamin,ou=pessoas,dc=exemplo,dc=com,dc=br considerado o nome completo desta entrada, tambm chamado de DN (Distinguished Name, ou Nome Distinto). Representa o caminho completo desde a raiz do diretrio at o elemento que estamos referenciando. O nome cn=benjamin, por sua vez, chamado de RDN (Relative Distinguished Name, ou Nome Distinto Relativo), pois somente possui a parte mais especfica. Os atributos tm o seguinte significado: cn: common name, ou nome comum; sn: surname (sobrenome); telephoneNumber: nmero de telefone; objectClass: classe de objeto. A escolha do RDN muito importante: ela representa o nome da entrada. Neste exemplo, foi escolhido o atributo cn. As nicas exigncias para uma RDN so: o DN resultante deve ser nica em todo o diretrio; a entrada deve possuir um atributo com o mesmo nome da RDN (no exemplo, temos o atributo cn: benjamin fazendo parte da entrada). Note que a entrada obrigatoriamente utiliza os atributos objectClass, sn e cn. O primeiro obrigatrio para todo tipo de entradas em diretrios, e os outros dois (sn e cn) so exigidos pela classe escolhida, person. Esta classe possui ainda vrios atributos opcionais, sendo que foi utilizado apenas um neste exemplo para indicar o numero de telefone desta pessoa. Conhecer as classes de objetos e atributos suportados por um diretrio de suma importncia para o armazenamento dos dados. Antes de criar classes e atributos novos, o administrador deve consultar os j existentes no diretrio e tentar utiliz-los. Afinal, padronizao s til se for usada por todos.

1.3.1

Definio de atributos

Atributos em um diretrio so bastante semelhantes a campos de tabelas ou variveis em alguma linguagem de programao e possuem uma sintaxe bem definida.estas definies, tanto do nome do atributo como sua sintaxe, fazem parte do schema do servidor LDAP.

LDAP LDAP A sintaxe do atributo define as regras que devem ser utilizadas pelo servidor LDAP ao lidar com este atributo com relao a ndices, consultas e comparaes. Vejamos um exemplo:
attributetype ( 2.5.4.20 NAME telephonenumber DESC RFC2256: Telephone Number EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} )

A definio acima para o atributo de numero de telefone, telephoneNumber, estabelece: O OID (Object IDentifier) deste atributo: 2.5.4.20; A descrio: RFC2256: Telephone Number; As regras de comparao: uma de igualdade (EQUALITY) chamada telephoneNumberMatche outra de substring, para pesquisas de subconjuntos de caracteres, chamada de telephoneNumberSubstringsMatch; A sintaxe (SYNTAX), ou seja, o tipo de dado que pode ser aceito para este atributo. As diversas definies de sintaxe, ordenao e outras utilizadas nos schemas podem ser encontradas na RFC 2252 e tambm no site http://www.alvestrand.no/objectid. Note que as duas definies de regras de comparao so especficas para o atributo telephoneNumber, e que no h uma regra de comparao do tipo maior queou menor que (que seria chamada de ORDERING). Afinal, faz sentido o conceito de um nmero de telefone maior que o outro? A regra de igualdade pode aparecer muito simples primeira vista, mas vejamos: o telefone 555-1234 igual a 555 1234? Segundo a definio da regra telephoneNumberMatch, sim! No precisamos nos preocupar com este tipo de detalhe quando estivermos fazendo uma consulta ao diretrio, desde que o atributo tenha cido corretamente definido, claro. E como se utilizaria este atributo para o caso da pessoa em questo ter mais de um numero de telefone? Simples, basta acrescentar o atributo, tantas vezes quanto necessrio, desde que sua definio permita isso. E o atributo de numero de telefone permite. Por exemplo:
dn: cn=benjamin,ou=pessoas,dc=exemplo,dc=com,dc=br cn: benjamin sn: sisko telephoneNumber: 999-9999 --nenhum problema com mais de um telefone telephoneNumber: 123-1133 --mais de um telefone objectClass: person

Um exemplo de atributo onde isto no permitido uidNumber. Vejamos sua definio:

attribute type ( 1.3.6.1.1.1.1.0 NAME uidNumber DESC Na integer uniquely identifying a user in na administrative domain EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

A palavra-chave est marcada em negrito: SINGLE-VALUE. Isto determina que o atributo s pode ser utilizado uma vez por entrada do diretrio.

LDAP LDAP O assunto da definio de atributos pode ficar terrivelmente complexo bem rpido. Vale a mesma regra j repetida varias vezes: o administrador do servio de diretrios deve evitar a utilizao de atributos prprios definidos em casa. Sempre de preferncia para atributos padronizados, o que vai inclusive ajudar na interoperabilidade do servidor LDAP com as aplicaes que utilizam o diretrio.

1.3.2

Definio de classes de objetos

As classes de objetos definem que atributos podem e devem ser utilizados em uma entrada de diretrio. Por exemplo, a classe de unidade organizacional, organizationalUnit, definida da seguinte forma no OpenLDAP: Caractersticas desta classe:
objectClass ( 2.5.6.5 NAME organizationalUnit DESC RFC2256: an organizational unit SUP top STRUCTURAL MUST ou MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ X121Address $ registerAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ telexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ))

Seu OID 2.5.6.5, definido na RFC 2256; uma classe do tipo estrutural Herda definies da classe top (SUP top). Quaisquer atributos da classe top, opcionais ou obrigatrios, inclusive os herdados por ela, tambm faro parte da definio de organizationalUnit; Exige a presena do atributo ou; Permite a existncia dos diversos outros atributos listados (userPassword, searchGuide, etc.). bastante comum que classes de objetos compartilhem atributos. O atributos userPassword, por exemplo, usado em nove classes do OpenLDAP. Tambm no h o menor problema em utilizar ao mesmo tempo classes que utilizam atributos em comum. Por exemplo, tanto a classe person como a classe posixAccount utilizam o atributo userPassword e so comunmente usadas ao mesmo tempo em entradas representando pessoas.

1.4 Dicas
No use LDAP apenas porque esta na moda: avalie bem a situao. Considere por alguns momentos que LDAP ser apenas uma forma de acesso a um banco de dados. A padronizao forte do LDAP ao mesmo tempo uma vantagem e uma fraqueza: precisa ser bem utilizada. Tente sempre utilizar os atributos e classes j existentes.

LDAP LDAP DNS um exemplo de servio de diretrio de larga escala. Muitos dos conceitos vistos aqui, em especial os de hierarquia e delegao de administrao de ramos da arvore, so aplicados l.

1.5 Exerccios
1. Quais os atributos obrigatrios exigidos por uma entrada que contenha a classe de objeto inetOrgPerson? Porqu? As definies relevantes esto a seguir: inetOrgPerson:
objectclass ( 2.16.840.1.113730.3.2.2 NAME inetOrgPerson DESC RFC2798: Internet Organizational Person SUP organizationalPerson STRUCTURAL MAY ( audio $ businessCategory $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $ roomNumber $ secretary $ uid $ userCertificate $ x500uniqueIdentifier $ preferredLanguage $ userSMIMECertificate $ user PKCS12 )

organizationalPerson:
objectclass ( 2.5.6.7 NAME organizationalPerson DESC RFC2256: na organizational person SUP person STRUCTURAL MAY (title $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) )

person:
objectclass ( 2.5.6.6 NAME person DESC RFC2256: a person SUP top STRUCTURAL MUST ( Sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

LDAP LDAP 2. Desenhe o diretrio representado pelo arquivo LDIF a seguir:

dn: o=empresa,c=br objectClass: organization o: empresa dn: ou=Marketing,o=empresa,c=br objectClass: organizationalUnit ou: Marketing dn: ou=Comercial,o=empresa,c=br objectClass: organizationalUnit ou: Comercial dn: cn=Maria,ou=Marketing,o=empresa,c=br objectClass: organizationalPerson cn: maria sn: silva telephoneNumber: 333-1122 title: Gerente

3. Qual (ou quais) o(s) erro(s) da entrada LDIF a seguir?

dn: Sn=mendes,ou=Pessoas,o=empresa,c=br objectClass: person sn: carlos userPassword: {SSHA}zUwaxRfNCFOTiTZk5+3i9tRdsHY8ncjG

Referncias: Understanding and Deploying LDAP Directory Services (em ingls) Timothy A. Howes, Ph.D., Mark C. Smith e Gordon S. Good ISBN 1-57870-070-1 RFC 2251: Lightweight Directory Protocol (v3) http://www.ietf.org/rfc/rfc2251.txt RFC 3377: Lightweight Directory Access Protocol (v3): Technical Specification http://www.ietf.org/rfc/rfc3377.txt RFC 2849: The LDAP Data Interchange Format (LDIF) Technical Specification http://www.ietf.org/rfc/rfc2849.txt LDAP schema browser (em ingls) http://ldap.akbkhome.com/index.php Site brasileiro que agrega vrias informaes sobre LDAP, inclusive uma lista de discusso. http://www.ladp.org.br/ 9

LDAP LDAP

CAPTULO 2

OPENLDAP
OpenLDAP um servidor de diretrios que utiliza o protocolo LDAP para comunicao. Ao final deste capitulo, voc devera ser capaz de: Criar um diretrio simples Utilizar as ferramentas do OpenLDAP Criar arquivos LDIF para importao no diretrio

10

LDAP LDAP

2.1 OpenLDAP
OpenLDAP uma implementao de cdigo aberto do protocolo LDAPv3 (Lightweight Directory Access Protocol verso 3). Algumas caractersticas deste servidor: Protocolo: LDAPv3 (padro) e para clientes antigos LDAPv2; Autenticao: suporta SASL (Simple Authentication and Security Layer) utilizando mecanismos DIGEST-MD5, GSSAPI e outros; Criptografia: atravs da biblioteca OpenSSL, suporta conexes SSL/TLS atravs de ldaps:// ou do mecanismo START TLS. Conexes autenticadas por SASL tambm podem opcionalmente ser criptografadas, desde que o mecanismo utilizado tenha esta opo ( o caso de GSSAPI e DIGEST-MDS, por exemplo); Controle de acesso: permite o uso de ACLs para ajuste fino do acesso aos dados contidos no diretrio; Internacionalizao: suporta Unicode; Backend: suporta diferentes tipos de backends, como Berkeley DB verso 4 (BDB), LDBM, SQL ou at mesmo outro servidor LDAP; Mltiplos bancos de dados: um nico servidor LDAP pode ser configurado para utilizar vrios bancos de dados simultaneamente; API: fornece uma biblioteca de desenvolvimento para aplicaes que desejem utilizar LDAP; Threads: o servidor multi-threaded, permitindo alta performance principalmente em sistemas multi-processados; Replicao: possui suporte a replicao de dados, permitindo a utilizao de servidores adicionais contendo um,a imagem da base de dados para sites de alto trafego; Os pacotes do LDAP esto assim divididos no Linux:
Pacote RPM Descrio

openldap openldap-clients openldap-servers libldap libldap-devel, libldap-devel-static openldap-doc

Pacote base do OpenLDAP Ferramentas cliente LDAP de linha de comando Servidor OpenLDAP e ferramentas especficas para Servidor Bibliotecas dinmicas (libldap e liblber) Arquivos e bibliotecas utilizados para desenvolvimento Documentao adcional, incluindo diversas RFCs

Arquivos e diretrios importantes:

Arquivo ou diretrio Descrio

/etc/openldap/ldap.conf /etc/openldap/slapd.conf /etc/openldap/schema

Arquivo de configurao da biblioteca OpenLDAP Arquivo de configurao do servidor OpenLDAP Diretrio contendo arquivos de definio de schemas locais

11

LDAP LDAP /usr/share/openldap/schema /var/lib/ldap Diretrio contendo arquivos de definio dps schemas padro Diretrio padro para o banco de dados

2.2 Configurao
Vamos criar um arquivo de configurao para o nosso diretrio de exemplo. Ao longo desta apostila iremos melhorando este arquivo at chegar em uma verso final de produo. Queremos criar um diretrio cuja raiz comea em dc=exemplo,dc=com,dc=br. O arquivo de configurao com o qual vamos comear para o servidor OpenLDAP hospedar este diretrio : /etc/openldap/slapd.conf:
# opes globais include /usr/share/openldap/schema/core.schema include /usr/share/openldap/schema/cosine.schema include /usr/share/openldap/schema/inetorgperson.schema include /usr/share/openldap/schema/nis.schema pidfile /var/run/ldap/slapd.pid argsfile /var/run/ldap/slapd.args # opes do banco de dados database bdb suffix dc=exemplo,dc=com,dc=br rootdn cn=Manager,dc=exemplo,dc=com,dc=br #hash SSHA obtido com slappasswd(8) rootpw {SSHA}pzp96ZACsCrWbeos2D4ujmGvKRyJFQiY directory /var/lib/ldap index objectClass eq

Opes globais utilizadas: include: diretiva utilizada para incluir trechos de configurao de outro arquivo. No caso do exemplo, est sendo utilizada para incluir alguns arquivos de definio de schema; pidfile, argsfile: opes que especificam a localizao do arquivo pid e de argumentos do servidor, respectivamente; Opes especficas do banco de dados utilizadas: database: especificao do tipo de banco de dados utilizado. O tipo recomendado para a grande maioria dos casos bdb, de Berkeley Data Base. Este um banco de dados robusto, com suporte a transaes, rollback e backup a quente. Outros detalhes da configurao deste importante banco de dados sero vistos mais adiante; suffix: este o tipo da nossa rvore LDAP; rootdn: especifica o nome do administrador do diretrio. Este nome no precisa corresponder a uma entrada existente no diretrio;

12

LDAP LDAP

rootpw: especifica a senha do administrador do diretrio. H diversas formas de se informar esta senha que sero vistas em detalhe mais adiante. A forma mais insegura simplesmente escrever a senha diretamente ali. Uma menos insegura utilizar um hash da senha, a exemplo do que acontece com as senhas do arquivo /etc/shadow. No exemplo, foi utilizado um hash para a senha senhasecreta obtido da seguinte forma:
# slappasswd New password: foi digitado senhasecreta (sem as aspas) Re-enter new password: repetido {SSHA}pzp96ZACsCrWbeos2D4ujmGvKRyJFQiY este o hash que vamos utilizar

directory: especifica qual o diretrio do sistema de arquivos onde ficaro armazenados os dados contidos no diretrio. Este diretrio j deve existir e ter permisses 0700 e com dono ldap:ldap; ndex: especifica que atributos devero ser indexados. Como o atributo objectClass obrigatrio para todas as entradas, ele deve ser indexado. O tipo de ndice especificado equality (teste de qualidade). Ou seja, para pesquisas do tipo objectClass=algumacoisa. medida que formos acrescentando dados ao diretrio veremos outros tipos de ndices. Na instalao do pacote openldap-servers, o log do sistema configurado para capturar as informaes do OpenLDAP e grav-las em um arquivo especfico. Por padro, o OpenLDAP utiliza a categoria (facility) LOCAL0, portanto a seguinte linha foi acrescentada ao /etc/syslog.conf:
Local0.* /var/log/ldap/ldap.log

Para iniciar o servidor, basta executar o seu script de inicializao padro:

# service ldap start Iniciando ldap:

[ ok ]

O log conter uma mensagem semelhante seguinte: /var/log/ldap/ldap.log:

Slapd [27117]: slapd starting

Neste momento, o daemon slapd j criou alguns arquivos em /var/lib/ldap, o diretrio da base de dados. Que arquivos so estes e qual o seu formato depende do tipo de banco de dados utilizado. O diretrio est no ar. Mas ainda no possui nenhum dado para fornecer, ou seja, est vazio, com exceo dos schemas e algumas outras informaes operacionais. J vamos cuidar disto.

2.3 Criando e Manipulando um Diretrio

A sute OpenLDAP fornece diversas ferramentas para lidar com o diretrio, mas todas modo texto. Temos ferramentas de pesquisa de teste de autenticao, de insero de dados, remoo, etc.

13

LDAP LDAP Com exceo das ferramentas de acesso direto ao banco de dados, as outras utilizam o protocolo LDAP na sua operao. OpenLDAP fornece um arquivo de configurao global para os programas que utilizam a biblioteca: /etc/openldap/ldap.conf. l podemos especificar coisas bsicas camo endereo do servidor LDAP e qual a base do diretrio (o topo da rvore, ou o ponto onde queremos comear as procuras): /etc/openldap/ldap.conf:
BASE URI dc=exemplo,dc=com,dc=br ldap://ldap.exemplo.com.br

Desta forma, no ser necessrio especificar na linha de comando qual o servidor LDAP que dever ser consultado nem a partir de que ponto da arvore as pesquisas devem comear, a no ser que se queira acessar outro servidor ou outro ponto base de procura.

2.3.1 Inicializando a base de dados

H duas formas de se inserir dados no diretrio servido pelo OpenLDAP: atravs do protocolo LDAP e diretamente na base de dados. A insero atravs do protocolo LDAP utiliza operaes de escrita deste protocolo e feita via rede, mesmo que localhost. Junta-se a isto o fato da escrita ser relativamente lenta em diretrios e teremos uma baixa performance. Isto aceitvel para algumas escritas, mas geralmente um problema srio para a carga inicial da base. Imagine inicializar a base com milhares de contas: isto poderia levar horas se feito atravs do protocolo LDAP. A carga inicial da base de dados portanto melhor feita acessando a base de dados diretamente. No ser utilizado o protocolo LDAP para isso, o que significa que no haver autenticao, trfego de rede nem controle de acesso por ACLs, resultando em uma operao vrias vezes mais rpida. quase como se fosse apenas uma operao de converso de um arquivo LDIF para o formato da base de dados. O comando para fazer a carga inicial da base de dados slapadd e possui as seguintes opes importantes: /usr/sbin/slapadd Ativa modo detalhado (verbose). Continua a insero mesmo aps encontrar algum erro. Especifica qual sufixo estar sendo tratado. Somente til caso haja mais de uma base de dados definida. Especifica o arquivo LDIF que ser importado para o diretrio. caso esta opo no esteja presente, os dados LDIF sero lidos da entrada padro.

-v -c -b -l <arquivo.ldif>

Para comear o processo, precisamos primeiro parar o servio LDAP:

# servise ldap stop Desligando ldap: [ ok ]

Antes de prosseguir, o diretrio da base de dados pode ser zerado manualmente, apagando todos os arquivos. Apenas no apague o arquivo DB_CONFIG caso ele esteja presente, pois utilizado pelo backend BDB para importantes opes de configurao que iremos detalhar mais adiante. O arquivo LDIF que iremos inserir na base e que representa o nosso diretrio atual est reproduzido a seguir:

14

LDAP LDAP exemplo.ldif

dn: dc=exemplo,dc=com,dc=br dc: exemplo objectClass: top objectClass: domain objectClass: domainRelatedObject associateDomain: exemplo.com.br dn: ou=Pessoas,dc=exemplo,dc=com,dc=br objectClass: top objectClass: organizationalUnit ou: pessoas description: Ramo contendo as entradas de pessoas dn: cn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br cn: benjamin sn: sisko objectClass: person telephoneNumber: 999-9999 telephoneNumber: 123-1133

Para inserir estes dados no diretrio, executamos o comando slapadd e fornecemos este arquivo para sua entrada padro (alternativamente, o parmetro l exemplo.ldif poderia ser usada):
# slapadd v < exemplo.ldif added: dc=exemplo,dc=com,dc=br (00000001) added: ou=Pessoas,dc=exemplo,dc=com.dc=br (00000002) added: cn=benjamim,dc=Pessoas,dc=exemplo,dc=com,dc=br (00000003)

O modo detalhado til para ver o que est acontecendo, mas tambm pode atrasar a insero dos dados caso a quantidade de entradas seja muito grande (dezenas de milhares, por exemplo). O contrrio de slapadd o comando slapcat, que faz um dump do banco de dados. Ou seja, converte os dados de volta para o formato LDIF:
# slapcat Dn: dc=exemplo,dc=com,dc=br Dc: exemplo objectClass: top objectClass: domain objectClass: domainRelaredObject associatedDomain: exemplo.com.br structuralObjectClass: domain entryUUID: 628bdb82-a2a7-1028-97fa-efe6c83d0f3c creatorsName:cn=manager,dc=exemplo,dc=com,dc=br modifiersName: cn=manager,dc=exemplo,dc=com,dc=br createTimestamp: 20040924185753Z mofifyTimestamp: 20040924185753Z entryCSN: 2004092418:57:53Z#0x0001#0#0000 dn: ou=Pessoas,dc=exemplo,dc=com,dc=br objectClass: top objectClass: organizationalUnit (...)

15

LDAP LDAP Note que cada entrada recebeu mais alguns atributos, destacados em negrito na sada acima. Estes so atributos internos de controle do OpenLDAP e so adicionados e modificados automaticamente, no sendo necessrio nos preocuparmos com eles. A sintaxe do comando slapcat exatamente a mesma do comando slapadd: /usr/sbin/slapcat [opes] Ativa o modo detalhado (verbose). Continua o dump mesmo aps encontrar algum erro. Especifica qual sufixo estar sendo tratado. Somente til caso haja mais de uma base de dados definida. Especifica o arquivo onde a sada ser gravada. Caso esta opo no esteja presente, os dados LDIF sero enviados para a sada padro.

-v -c -b -l <arquivo.ldif>

A dupla slapadd/slapcat representa uma boa ferramenta de backup para o diretrio. pode-se periodicamente armazenar o arquivo LDIF resultante do slapcat e, se necessrio, recarregar a base com slapadd a partir do ultimo backup. O nico detalhe que o processo de dump dever ser feito com o servio parado ou pelo menos em modo somente leitura (read-only) para garantir a consistncia da base.

2.3.2 Fazendo consultas

Consultas e servios de diretrios obedecem a uma sintaxe bem especfica, o que no de surpreender: novamente, a interoperabilidade em ao. Esta sintaxe est definida na RFC 2254 e nada melhor do que exemplos para ajudar no seu entendimento (o parmetro x ser explicado mais adiante):
OBS: O comando ldapsearch (e todos os outros da famlia ldap*) utiliza o protocolo LDAP e, requer que o servio ldap esteja iniciado.

ldapsearch x (sn=sisko) Todas as entradas que possuem o atributo sn igual a sisko; ldapsearch x (!(SM=sisko)) Todas as entradas que no possuem o atributo sn ou o possuem mas ele diferente de sisko; ldapsearch x (&(sn=benjamin) (telephoneNumber=9*)) todas as entradas que possuem o atributo cn igual a benjamin e o atributo telephoneNumber comeando com 9; Os operadores lgicos que temos disponveis so:
Teste Descrio

& | !

E lgico OU lgico NO lgico (negao)

Podemos combinar diversos destes operadores em uma nica especificao de filtragem, fazendo agrupamentos com parnteses. Por exemplo:

16

LDAP LDAP

(&(|(cn=marcos) (cn=Luiz) (cn=Jose)) (sn=silva))

Este filtro casar com todas as entradas que tiverem o atributo sn (sobrenome) igual a silva e o atributo cn (primeiro nome) igual a marcos, luiz ou jose. luiz silva seria encontrado, bem como marcos silva e jose silva", mas no pedro silva. Os atributos de comparao disponveis para testes so:
Comparao Descrio

= ~= >= <=

Igual a Aproximadamente igual a Maior ou igual a Menor ou igual a

O programa ldapsearch, presente no pacote openldap-clientes, permite enviar consultas ao diretrio utilizando LDAP. As opes mais importantes para ns neste momento esto listadas na tabela a seguir: /usr/Bin/ldapsearch [opes] [filtro de pesquisa] [atributos] Utiliza autenticao simples (simple bind). Se no especificado, -x ser utilizada autenticao SASL. Especificao do filtro LDAP segundo RFC 2254. Se for omitido [filtro] ser utilizado (objectClass=*). Atributos que devem ser retornados. Se no for especificado, todos [atributos] os existentes nas entradas encontradas sero retornados. Indica o endereo do servidor LDAP a ser consultado. Se no for -h especificado, ser utilizado o servidor existente em /etc/openldap/ldap.conf. Indica a base de procura. Se no for especificada, ser utilizada a -b base existente no arquivo /etc/openldap/ldap.conf Se no especificado, a sada do comando ser exibida no formato LDIF estendido. Se for especificado apenas uma vez, ser utilizado -L LDIFv1: duas vezes (-LL) faz com que os comentrios sejam suprimidos, e trs vezes (-LLL), o mximo, suprime tambm o nmero da verso LDIF. Exemplo de pesquisa utilizando o comando ldapsearch:
$ ldapsearch x (&(cn=benjamin) (telephoneNumber=9*)) cn # extended LDIF # #LDAPv3 # base <> with scope sub # filter: (&(cn=benjamin) (telephoneNumber=9*)) # requesting: cn # # benjamin, Pessoas, exemplo.com.br dn: cn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br cn: benjamin atributo pedido # search result Search: 2 Result: 0 Success # numResponses: 2 # numEntries: 1

DN da resposta

quantidade de entradas que foram encontradas

17

LDAP LDAP O mesmo comando com o parmetro LLL mais sucinto na sua resposta:
$ ldapsearch x LLL (&(cn=benjamin) (telphoneNumber=9*)) cn dn:cn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br cn: benjamin

Note que necessrio utilizar aspas no critrio de pesquisa, pois ele utiliza caracteres reservados pelo Shell do sistema.

2.3.3 ndices
Se observarmos os logs do servidor LDAP durante estas pesquisas, perceberemos algumas mensagens de erro (linhas sublinhadas): /var/log/ldap/ldap.log
slapd[855]: conn=32 op=1 SRCH base=dc=exemplo,dc=exemplo,dc=com,dc=br scope=2 filter=(&(cn=benjamin) (telephoneNumber=9*)) slaps[855]: conn=32 op=1 SRCH attr=cn slap[855]: <= bdb_equality_candidates: (cn) ndex_param failed (18) slapd[855]: <= bdb_substring_candidates: (telephoneNumber) ndex_param failed (18) slapd{855]: conn=32 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= slapd[856]: conn=32 op=2 UNBIND slapd[856]: conn=32 fd=14 closed

A mensagem de erro do banco de dados BDB utilizado e est informando que houve falha no ndice dos atributos cn e telephoneNumber. Mas especificamente, no foi possvel encontrar ou utilizar os ndices do tipo equality (igualdade) e substring (subconjuntos de caracteres). Olhando novamente o nosso arquivo de configurao do servidor, vemos que realmente no temos estes ndices. Mas mesmo assim a pesquisa funcionou. O que estamos perdendo? Performance. Consultas envolvendo atributos no indexados so muito mais lentas do que quando existem ndices disponveis. Vamos, portanto, tratar de indexar estes atributos (e os outros que tambm podero fazer partir de consultas) o quanto antes. As alteraes necessrias esto destacadas a seguir: /etc/openldap/slapd.conf:
# opes globais include /usr/share/openldap/schema/core.schema include /usr/share/openldap/schema/cosine.schema include /usr/share/openldap/schema/inetorgperson.schema include /usr/share/openldap/schema/nis.schema pidfile /var/run/ldap/slapd.pid argsfile /var/run/ldap/slapd.args # opes do banco de dados database bdb suffix dc=exemplo,dc=com,dc=br rootdn cn=Manager,dc=exemplo,dc=com,dc=br # hash SSHA obtido com slapasswd(8) rootpw {SSHA}pzp96ZACsCrWbeos2D4ujmGvKRyJFQiY directory /var/lib/ldap index objectClass eq index objectClass eq index sn,cn eq,sub ndex tellephoneNumber eq,sub
18

LDAP LDAP Os tipos de ndices que podemos usar dependem da definio de cada atributo, ou seja, o atributo precisa suportar o ndice escolhido. Os tipos de ndices suportadas pelo OpenLDAP so:
ndice Descrio

eq sub pres approx

Igualdade. Utilizado em consultas do tipo (atributo=valor). Substring. Utilizado em consultas do tipo (atributo=*valor*) Presena. Utilizado em consultas que apenas testam a presena do atributo. Aproximado. Utilizado em consultas do tipo (atributo~=valor).

Qualquer alterao na configurao dos ndices necessita que eles sejam reconstrudos.
# service ldap stop Desligando ldap: # slapindex v indexing id=00000001 indexing id=00000002 indexing id=00000003 [ ok ]

Isto feito parando-se o servio e executando o programa slapindex: A opo -v opcional e foi apenas usada para mostar o processo da operao. As outras opes so bastante semelhantes s da ferramenta slapadd: /usr/sbin/slapindex [opes] Modo detalhado (Verbose). Continua mesmo aps erros. Sufixo do banco de dados a indexar, til caso haja mais de um.

-v -c -b <sufixo>

Uma vez que os ndices foram reconstrudos, o servidor pode ser novamente iniciado. Note que este procedimento somente necessrio quando forem feitas mudanas nos ndices (como novos ndices sendo acrescentados, novos atributos sendo indexados, etc.). durante a operao normal do servidor, escritas no diretrio so automaticamente indexadas. Assim, os passos para o processo de alterar ndices so: 1. alterar o ndice; 2. parar o servio slapd; 3. executar o comando slapindex; 4. reiniciar o servio slapd; Um ndice interessante o approx. Ele permite pesquisas aproximadas nos atributos que o suportam, como por exemplo commonName (cn). Caso este ndice seja utilizado (opo approx na linha index), podemos fazer consultas como a mostrada a seguir:
$ slapsearch x LLL (sn~=cysqo) sn dn: cn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br sn: sisko

Mesmo tendo procurado por cysqo, a entrada sisko foi encontrada. Bastante til no caso de nomes de grafia diferente ou complexa. Utilizar os ndices corretos no diretrio fundamental para a performance do sistema. O administrador deve verificar quais as consultas mais utilizadas e indexar os atributos

19

LDAP LDAP necessrios. Por outro lado, ndices ocupam memria. Se fossem usadas de forma exagerada (por exemplo, todos os atributos, mesmo os que no fazem parte de consultas), podem prejudicar o sistema.

2.3.4 Acrescentando dados

Uma vez que o diretrio esteja em funcionamento, alteraes somente podem ser feitas atravs do protocolo LDAP. O pacote openldap-clients tem duas ferramentas para este propsito: ldapadd (para acrescentar entradas novas) e ldapmodify (para modificar entradas existentes). Vamos criar uma nova entrada de usurio na nossa arvore, sob o ramo ou=Pessoas. A seguir est o arquivo LDIF correspondente: jadziz.ldif:
dn: cn=jadzia,ou=Pessoas,dc=exemplo,dc=com,dc=br cn: jadzia sn: dax objectClass: person

At o momento, o nico usurio que consegue escrever no nosso diretrio o administrador. Em breve veremos como mudar isso, mas por enquanto precisamos realizar esta operao de escrita com os privilgios deste usurio. O comando :
# ldapadd x D cn=manager,dc=exemplo,dc=com,dc=br W < jadzia.ldif Enter LDAP password: digite a senha do administrador do OpenLDAP Adding new entry cn=jazia,ou=Pessoas,dc=exemplo,dc=com,dc=br

A nova entrada foi adicionada. Podemos verificar com ldapsearch:

$ slapsearch x LLL cn=jadzia dn: cn=jadzia,ou=Pessoas,dc=exemplo,dc=com,dc=br cn: jadzia sn: dax objectClass: person

As opes mais importantes para ldapadd so: /usr/sbin/slapadd [opes] Continua a operao mesmo em caso de erros. Desativa autenticao SASL. Para autenticao simples (no SASL), especifica o login (tambm conhecido como binddn). Pede a senha para o binddn. Utiliza a senha na linha de comando. Insere as entradas contidas em arquivo.ldif ao invs da entrada padro. Especifica o endereo do servidor LDAP. Se esta opo no for utilizada, ser utilizado o servidor especializado em /etc/openldap/ldap.conf.

-c -x -D <binddn> -W -w <senha> -f <arquivo.ldif> -h <servidor>

No nosso exemplo, utilizamos autenticao simples e o loguin de administrador, cuja DN est especificada no arquivo de configurao /etc/openldap/slapd.conf na diretiva rootdn. A senha a que criamos para a diretiva rootpw. Mais de uma entrada pode ser inserida por vez, basta separ-las com uma linha em branco no arquivo LDIF.

20

LDAP LDAP

A operao contrria naturalmente a remoo de uma entrada. A ferramenta utilizada para isto ldapdelete e sua sintaxe praticamente a mesma que no caso de ldapadd, sendo que a nica diferena que trabalha com DNs, e no arquivos LDIF.

2.3.5 Alterando dados j existentes

A modificao de dados no diretrio tambm utiliza o protocolo LDAP e pode ser feita com a ferramenta ldapmodify. A sintaxe, no entanto, um pouco diferente. Vamos a um exemplo. Digamos que precisamos acrescentar o atributo telephoneNumber para a entrada cn=jadzia. Este arquivo que utilizaremos para isto: A sintaxe bastante semelhante a dos arquivos LDIF, mas h diferenas. A primeira linha
dn: cn=jadzia,ou=Pessoas,dc=exemplo,dc=com,dc=br changetype: modify add: telephoneNumber telephoneNumber: 111-4343

est especificando o DN da entrada que iremos alterar. As outras linhas especificam a mudana em detalhes: changetype: esta diretiva especifica que estamos realizando uma operao de modificao em uma entrada j existente; add: esta diretiva indica qual atributo est sendo adicionado. Note que, caso um atributo com este nome j exista e possa ter mais um valor, ele no ser substitudo. Realizando a operao: Uma rpida pesquisa confirma o sucesso da alterao:
$ ldapmodify x D cn=manager,dc=exemplo,dc=com,dc=br W < phone.ldif Enter LDAP Password: digite a senha do administrador do OpenLDAP modifying entry cn=jadzia,ou=Pessoas,dc=exemplo,dc=com,dc=br

Os valores possveis para changetype so:

$ ldapsearch x LLL cn=jadzia telephoneNumber dn:cn=jadzia,ou=Pessoas,dc=exemplo,dc=com,dc=br telephoneNumber: 111-4343 o atributo novo

modify: a entrada apontada por dn: ser modificada conforme descrito nas linhas seguintes. Neste caso, podemos realizar as seguintes operaes de modificao: add: acrescentar o atributo indicado; delete: remover o atributo indicado; replace: substituir o valor do atributo indicado por outro valor; add: neste caso, o comportamento de ldapmodify o mesmo de ldapadd e considera-se que a entrada apontada por dn: ainda no existe e ser criada nesta operao.

21

LDAP LDAP

Vrias modificaes podem ser realizadas no mesmo tempo, e em mais de uma entrada. Basta junt-las no mesmo arquivo. Por exemplo: changes.ldif:
dn: cn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br changetype: modify replace: telphoneNumber primeira mudana telephoneNumber: 111-1111 add: description segunda mudana description: Chefe a entrada que ser mudada

dn: cn=jadzia,ou=Pessoas,dc=exemplo,dc=com,dc=br outra entrada changetype: modify add: description apenas esta mudana description: Dois em um

Cada mudana dentro de uma mesma entrada precisa ser separada por uma linha contendo o caractere hfen (-), e outras entradas comeam aps uma linha em branco. O arquivo acima realiza as seguintes modificaes: a entrada cn=benjamin ter todos os atributos telephonerNumber substitudos pelo novo valor 111-1111. Ou seja, se antes tnhamos dois nmeros telefnicos, agora teremos apenas um e com um novo valor; a entrada cn=benjamin ter um novo atributo chamado description que conter o valor Chefe; a entrada cn=jadzia ter um novo atributo chamado description que conter o valor Dois em um. Mais uma vez nos autenticamos como administrador do diretrio e realizamos a alterao atravs do comando ldapmodify:
$ ldapmodify x D cn=manager,dc=exemplo,dc=com,dc=br W < changes.ldif Enter LDAP Password: digite a senha do administrador do OpenLDAP modifying entry cn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br modifying entry cn=jadzia,ou=Pessoas,dc=exemplo,dc=com,dc=br

2.3 Dicas
Crie ndices para todos os atributos utilizados nas consultas feitas ao diretrio. por outro lado, no exagere: ndices tambm consomem memria. Algumas vezes no possvel trocar uma classe de objeto por outra sem remover a entrada do diretrio e cri-la novamente, desta vez com a classe nova. Alguns programas ainda utilizam o protocolo LDAPv2 em vez da verso LDAPv3. Por padro, o OpenLDAP no suporta este protocolo mais antigo, mas esta configurao pode ser alterada se for necessrio atravs da diretiva allow bind_v2 no arquivo /etc/openldap/slap.conf.

22

LDAP LDAP No entanto, antes de fazer esta mudana convm verificar se a aplicao no pode passar a utilizar LDAPv3. Postfix, por exemplo, utiliza LDAPv2 por padro mas perfeitamente capaz de utilizar a verso trs do protocolo se assim for configurado. Para rapidamente converter um texto com caracteres acentuados para o formato UTF-8 exigido pelo LDAP, podemos utilizar a ferramenta iconv que faz parte do pacote glibc no Linux. Por exemplo, o texto Ramo contendo funcionrios ficaria da seguinte forma em UTF-8:
$ echo Ramo contendo funcionrios | iconv t utf-8 Ramo contendo funcionirios

Agora esse texto (Ramo contendo funcionirios) pode ser inserido no arquivo LDIF e importado para o servidor LDAP. Mas ateno: nem todos os atributos permitem caracteres acentuados. Isto faz parte da definio do atributo (o campo SYNTAX). Uma outra dica para melhorar a performance do servidor OpenLDAP particionar o disco do servidor de tal forma que o banco de dados fique numa partio separada e montada com a opo noatime. Isto desligar a modificao do atributo atime (Access time) dos arquivos pelo kernel, resultando em um aumento de performance no acesso a disco. Referrals podem ser criados em qualquer entrada da seguinte forma:
dn: ou=Filial,dc=exemplo,dc=com,dc=br objectClass: referral objectClass: extensibleobject ou: Filial ref: ldap://servidor.filial/ou=Filial,dc=exemplo,dc=com,dc=br

Cuidado com permisses no arquivo de configurao do OpenLDAP: /etc/openldap/slapd.conf. o recomendado (e o padro do pacote no Linux) 0640 root:ldap. Antes usar slapadd, certifique-se que a base de dados esteja vazia. Em um servidor com alto trfego os logs do OpenLDAP podem contribuir para uma perda de performance. Neste caso, pode-se desativar a gerao destas mensagens de log (diretiva loglevel 0) e s voltar a ativ-las caso seja necessrio para depurar algum problema.

2.5 Exerccios
1. Construa os filtros de pesquisa LDAP pedidos a seguir: a) Todas as entradas que contenham o atributo de sobrenome igual a silva;

b) Todas as entradas que tenham a classe posixGroup e o atributo memberUid igal a carlos;

23

LDAP LDAP c) Todas as entradas que tenham a classe person e o atributo title igal a gerente ou igual a coordenador;

d) Com o mesmo filtro do item b) mostre como seria a linha de comando do ldapsearch para restringir esta pesquisa ao ramo ou=Filial,o=empresa,c=br (e qualquer ramo abaixo desse). Alem disso, somente deve ser retornado o atributo cn e deve ser usada autenticao simples annima;

2. Considerando a entrada de diretrio seguinte:

dn: uid=carlos,ou=Pessoas,dc=exemplo,dc=com,dc=br objectClass: posixAccount objectClass: shadowAccount objectClass: intOrgPerson cn: carlos sn: silva uid: carlos uidNumber: 19420 gidNumber: 19420 homeDirectory: /home/carlos loginShell: /bin/bash gecos: Carlos Silva shadowLastChange: 12691 shadowMax: 99999 shadowWarning: 7 carLicense: AAA-1234

Construa arquivos de modificao para o comando ldapmodify que faam o seguinte: a) Troque o valor do atributo shadowWarning para 5;

b) Acrescente o atributo userPassword com o valor senhasecreta (sem aspas);

c) Acrescente dois nmeros de telefone (555-1472 e 555-1472) utilizando o atributo homePhone;

24

LDAP LDAP d) Remova o atributo carLicense;

e) Realize todas as mudanas das perguntas anteriores em um arquivo de modificao apenas.

Referncias: RFC 2254: The string Representation of LDAP Search Filters (em ingls) http://www.ieft.org/rfc/rfc2254.txt Site do projeto OpenLDAP (em ingls) http://www.openldap.org Pginas de manual dos comandos e arquivos mencionados: Ldapsearch(1), ldapadd(1), ldapdelete(1), ldapmodify(1), slapadd(8C), slapcat(8C), slapindex(8C), slapd.conf(5), ldap.conf(5). 25

LDAP LDAP

CAPTULO 3

AUTENTICAO E ACLS
O servidor OpenLDAP fornece diversas possibilidades de autenticar um conexo de controles de acesso. Ao final deste captulo, voc dever ser capaz de: Conhecer os tipos de autenticao disponveis; Utilizar autenticao simples; Utilizar autenticao SASL Mapear entidades SASL Utilizar listas de controle de acesso (ACL: Access Control List)

26

LDAP LDAP

3.1 bind
A operao de autenticao no mundo LDAP chamada de bind. H trs possibilidades de autenticao de conexes no servidor OpenLDAP: annimo, simples e autenticao SASL. Todas as conexes so autenticadas atravs de uma dessas formas, sendo que autenticao SASL somente est disponvel em servidores que suportam LDAPv3.

3.2 Autenticao Annima Simples

A autenticao annima acontece quando o cliente no fornece credenciais de autenticao, ou seja, o DN de loguin vazio. Ela possvel no modo de autenticao simples ou at mesmo SASL, mas o mais comum em conjunto com autenticao simples. Nos logs do servidor OpenLDAP, ela aparece da seguinte forma: /var/log/ldap:
slapd[24020]: conn=102 op=0 BIND dn= method=128 bind vazio (dn=) slapd[24020]: conn=102 op=0 RESULT tag=97 err=0 text=

As ferramentas do pacote openldap-clients utilizam autenticao annima quando nenhum bind (opo -D) especificado e for utilizada autenticao simples (opo x). Portanto, o comando seguinte far uma autenticao annima no servidor:
$ ldapsearch X LLL cn=jadzia cn dn: cn=jadzia,ou=Pessoas,dc=exemplo,dc=com,dc=br

3.3 Autenticao Simples

A autenticao simples de longe a mais comum e, como o prprio nome diz, simples, do protocolo LDAP. O grande problema deste tipo de autenticao a sua segurana: o binddn e sua senha trafegam em texto claro pela rede. Na verso LDAPv2, era a nica forma de autenticao possvel alm da annima (e com exceo da autenticao por certificados que bem mais complexa). A nica forma de utiliz-la de maneira segura atravs do acrscimo de uma camada de criptografia a conexo, normalmente utilizando TLS (Transport Layer Security). A autenticao simples utilizada pelas ferramentas do pacote openldap-clients quando passamos a opo x na linha de comando. Uma vez neste modo de autenticao, podemos fornecer o binddn, ou seja, o DN a ser utilizado no login. Por exemplo:
$ ldapsearch x LLL D cn=manager,dc=exemplo,dc=com,dc=br W cn=jadzia cn Enter LDAP Password: senha do cn=manager dn: cn=jadzia,ou=Pessoas,dc=exemplo,dc=com,dc=br cn: jadzia

Nos logs desta vez temos uma informao de login um pouco diferente do caso da autenticao annima: /var/log/ldap.log:
slapd[240]: conn=108 op=0 BIND dn=cn=manager,dc=exemplo,dc=com,dc=br method=128 slapd[240]: conn=108 op=0 BIND dn=cn=Manager,dc=exemplo,dc=com,dc=br mech=SIMPLE ssf=0

27

LDAP LDAP

Agora em vez do binddn aparecer vazio, temos ali a informao passada pelo parmetro D. alm disso: mech: indica o mecanismo utilizado. No caso, foi simple (autenticao simples); ssf: security strength factor, indica o fator de segurana da autenticao. Autenticao simples no possui nenhuma segurana (a senha trafega na rede em texto claro), portanto temos aqui o valor zero. Se a conexo estivesse protegida por TSL, ssf teria um valor mais alto dependendo do algoritmo de criptografia utilizado (por exemplo, 112 para 3DES). O valor de ssf pode inclusive ser utilizado em ACLs do servidor, somente permitindo acesso a certos atributos caso a conexo esteja criptografada. At agora estivemos sempre usando como binddn o usurio administrador do diretrio. mas j temos dois usurios adicionais no nosso banco de dados, como fazer para nos autenticarmos como estas entidades? J vimos que o nome de loguin no diretrio apenas um DN, que basicamente o ttulo de alguma entrada no diretrio. se passarmos como DN a entrada de um dos nossos usurios, e fizermos uma autenticao simples, o servidor procurar nesta entrada um atributo especial para validar a senha. O nome deste atributo userPassword. Portanto, para que possamos nos autenticar como o usurio cn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br, basta inserirmos o atributo da senha e preenche-lo. Vamos utilizar um hash da senha ds9 para no precisarmos colocar algo em texto claro no diretrio. o hash obtido da mesma forma que fizermos a diretiva rootdn do arquivo de configurao do servidor OpenLDAP (utilizando o programa auxiliar slappasswd). Inserindo o atributo de senha na entrada cn=benjamin:
$ ldapmodify -x D cn=manager,dc=exemplo,dc=com,dc=br W Enter LDAP Password: senha do administrador do OpenLDAP dn: cn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br acrescentando o atributo changetype: modify add: userPassword userPassword:{SSHA}dBnbmtEaihY/bl3nqD7QjRJGMmGlBuKN ds9 modifying entry cn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br

Agora podemos realizar consultas autenticando o usurio cn=benjamin:

$ ldapsearch x LLL D cn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br W cn=jadzia cn Enter LDAP Password: senha do benjamin dn: cn=jadzia,ou=Pessoas,dc=exemplo,dc=com,dc=br cn: jadzia

E nos logs:
slapd[648]: conn=111 method=128 slapd[648]: conn=111 mech=SIMPLE ssf=0 op=0 op=0 BIND BIND dn=cn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br dn=cn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br

28

LDAP LDAP Poderamos tambm ter utilizado simplesmente ds9 no atributo userPassword, funcionaria da mesma forma. Neste ponto convm fazermos uma pequena pausa e examinar exatamente como a autenticao est sendo feita. O cliente est enviando para o servidor LDAP um pedido de bind e fornecendo as credenciais do usurio. No caso, o DN do usurio cn=benjamin e a senha ds9. Mas o que est armazenado no atributo userPassword no ds9 (embora pudesse ser), mas sim algo como {SSHA}dBnbmtEaihY/bl3nqD7QjRJGMmGlBuKN. Como comparar os dois valores? Note a presena do texto {SSHA} na frente da senha. Isto indica para quem quer que esteja lendo este atributo o tipo de algoritmo de hash que foi utilizado naquela senha. Assim, para comparar a senha recebida do usurio com o valor contido neste campo o que o servidor precisa fazer aplicar o mesmo algoritmo senha recebida via rede e comparar o resultado com o que est armazenado em userPassword. Se forem iguais, ento a senha est correta: Servidor
Cn=Benjamim Bind dn:cn=... Bind pw:ds9
userPassword:{ssha} n#k*njh

Ok

Hash (ds9)

Esta a forma recomendada de se fazer a autenticao. Alguns programas, no entanto, fazem isto de forma diferente. Em vez de realizar uma operao de bind no diretrio com as credenciais fornecidas, eles simplesmente pesquisam o diretrio procurando o atributo userPassword e fazem o hash final eles mesmos: Servidor LDAP
Bind dn:cn=... Bind pw:ds9

Programa xyz

userPassword ?

Ok

{ssha}smk*j#ji

? Hash (ds9)={ssha}smk*j#ji

Esta segunda forma somente recomentada caso o servidor LDAP no suporte o algoritmo de hash utilizado (e realmente no h outra sada). o caso, por exemplo, do samba verso 3.0x at o momento (3.0.20 a verso atual nesta data). Para autenticar um usurio Windows, cuja senha utiliza algoritmos de hash no suportados pelo OpenLDAP ainda (serie 2.3.x), ele (o samba) precisa obter o atributo e fazer o hash e a comparao localmente para decidir se a senha est correta ou no. Ou seja, a autenticao no foi verificada atravs de uma operao de bind no diretrio.

29

LDAP LDAP

3.3.1 Protegendo a senha

Qualquer usurio consegue obter o atributo userPassword do nosso diretrio com a configurao atual, inclusive usurios annimos. Isto seria equivalente a deixar o arquivo /etc/shadow modo 0644, por exemplo, e definitivamente no algo que queremos:
$ ldapsearch x LLL D cn=benjamin userPassword dn: cn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br userPassword: e1NTSEF9NURtRlJkUS9sUjA2Ry96NDFSswczB6b3JWM05mTle=

uhoh...

Para proteger o atributo da senha, vamos utilizar o recurso de ACLs do servidor OpenLDAP. A alterao necessria no nosso arquivo de configurao est destacada a seguir: /etc/openldap/slapd.conf:
# opes globais include /usr/share/openldap/schema/core.schema include /usr/share/openldap/schema/cosine.schema include /usr/share/openldap/schema/inetorgperson.schema include /usr/share/openldap/schema/nis.schema pidfile /var/run/ldap/slapd.pid argsfile /var/run/ldap/slapd.args # opes do banco de dados database bdb suffix dc=exemplo,dc=com,dc=br rootdn cn=Manager,dc=exemplo,dc=com,dc=br # hash SSHA obtido com slapassword (8) rootpw {SSHA}pzp96ZACsCrWbeos2D4ujmGvKRyJFQiY directory /var/lib/ldap index objectClass eq index index ndex objectClass sn,cn telephoneNumber eq eq,sub,approx eq,sub

access to attrs=userPassword by anonymous auth by self write by * none Access to * By * read

As ACLs no OpenLDAP so processadas na ordem em que aparecem no arquivo de configurao. A sua forma genrica simples acesso a <que> por <quem> <direitos>, ou, no ingls, Access to <what> by <whom> <rights>. ACLs mais avanadas esto descritas na manpage slapd.access (5) e ainda veremos outros exemplos medida que formos acrescentando informaes ao nosso diretrio. Vamos analizar as nossas ACLs: Access to attrs=userPassword Esta ACL controla o acesso ao atributo (attrs) userPassword. As clusulas so: by anonymous auth: usurios annimos somente podem ter acesso a este atributo para efeitos de autenticao. Isto necessrio, pois seno teramos o problema da gaveta trancada com a chave dentro;

30

LDAP LDAP

by self write: usurios donos de entrada onde userPassword se encontra (self) tm acesso de escrita. normalmente desejvel para que os prprios usurios possam trocar a sua senha; by * none: esta clusula garante que nenhum outro usurio ter acesso a este atributo. Access to * by * read Esta ACL controla o acesso ao restante do diretrio. Por enquanto, no vamos criar restries adicionais, portanto garantimos acesso a leitura para todos. Como a clausula mais especfica com relao ao atributo userPassword est antes, no estaremos garantindo permisses adicionais a este atributo. importante notar que o administrador do diretrio (rootdn) no restrito pelas ACLs. Ou seja, no necessrio abrir uma exceo nas regras de acesso para administrador, pois ele sempre ter acesso. Agora o acesso ao atributo userPassword est restrito:
$ ldapsearch x LLL D cn=benjamin userPassword dn: cn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br nenhuma resposta, no temos acesso a este atributo (userPassword) $

Mas se nos autenticarmos como o usurio dono da entrada, teremos acesso:

$ ldapsearch x LLL D cn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br W cn=benjamin userPassword Enter LDAP Password: senha do benjamin dn: cn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br userPassword:: e1NTSEF9NURtRlJkUS9sUjA2Ry96NDFSRSswczB6b3JWM05mTle= agora sim

3.4 Autenticao SASL

A autenticao SASL (Simple Authentication and Security Layer), definida na RFC 2222, foi tornada obrigatria para implementao do protocolo LDAPv3. SASL nos fornece uma srie de mecanismos de autenticao, desde o bsico PLAIN, onde a senha trafega em texto claro, at o avanado GSSAPI que utiliza tickets de autenticao, criptografa a senha e o trafego e permite o recurso de single sing on. Para facilitar o entendimento, SASL pode muitas vezes ser comparado a PAM: se uma aplicao suporta SASL, ento quase certo que vai aceitar qualquer mecanismo SASL vlido. A figura a seguir ilustra os diferentes mecanismos de autenticao SASL disponveis:

31

LDAP LDAP

SASL

GSSAPI

Mecanismos kerberos

Mecanismos de verificao de senhas

PWCHECK_MET HOD

SASLAUTHD
Senhas compartilhadas (DIGEST-MD5,CRAM-MD5, etc)

Senhas plain text (PLAIN, LOGIN)

AUXPROP PAM LDAP SHADOW

SASLDB
/var/lib/sasl2/sasl.db

LDAPDB
Servidor LDAP

SQL
Servidor SQL

H trs grandes grupos de autenticao SASL: mecanismos Kerberos (GSSAPI), mecanismos plaintext (texto claro, como PLAIN e LOGIN) e mecanismos de senhas compartilhadas, onde as senhas no trafegam em texto claro (como DIGEST-MD5). Estes ltimos necessitam de um plugin auxiliar chamado de auxprop. No Linux, SASL est dividido nos seguintes pacotes: Pacote libsasl2 cyrus-sasl libsasl2-devel libsasl2-plug-sasldb, gssapi, -digestmd5, crammd5, -plain, -login, -anonymous, -ntlm, -otp, -sql, -ldapdb, -srp Descrio Biblioteca SASL Programas auxiliares da biblioteca SASL Contem arquivos necessrios para desenvolvimento com SASL

Pacotes contendo os respectivos plugins SASL

3.4.1 Mecanismos de senhas compartilhadas

Vamos configurar o nosso servidor OpenLDAP para aceitar autenticao SASL com o mecanismo DIGEST-MD5. Este mecanismo no expe a senha do usurio e pode opcionalmente criptografar at o trafego ps-autenticao. Estes mecanismos possuem este nome por um motivo: a senha dos usurios precisa ficar armazenada em texto claro em algum lugar acessvel pelo servidor. Este um paradoxo interessante: embora a senha nunca trafegue em texto claro pela rede, ela precisa ficar armazenada em texto claro em algum lugar. Segundo a figura anterior, vemos que precisamos escolher um plugin auxprop para este mecanismo. Vamos utilizar o plugin sasl2-sasldb que armazena as senhas em um arquivo local (/var/lib/sasl2/sasl.db).

32

LDAP LDAP Guia passo-a-passo: 1. Instalar os pacotes Os pacotes necessrios so: libsasl2, digestmd5 e cyrus-sasl. libsasl2-plug-sasl2, libsasl2-plug-

Para verificar que o servidor ldap reconheceu os plugins instalados, vamos realizar uma pesquisa especial que listar os mecanismos de autenticao suportados pelo servidor. Aps reiniciar o servio ldap, execute:
$ ldapsearch x LLL s base b supportedSASLMechanisms dn: supportedSASLMechanisms: DIGEST-MD5 temos DIGEST-MD5

Dependendo da instalao do sistema, outros mecanismos podem ser listados. Uma outra consulta interessante a ser feita a respeito das caractersticas do servidor LDAP pode ser feita substituindo-se supportedSASLMechanisms pelo caractere +. Sero retornados os mecanismos de autenticao suportadas e diversos outros detalhes. 2. Criar os usurios Precisamos agora criar os usurios e suas senhas no arquivo /var/lib/sasl.db. isto feito atravs da ferramenta saslpasswd2:
# saslpasswd2 c benjamin Password: Again (for verification): digite a senha repita a senha

Isto vai acrescentar a conta de usurio no arquivo /var/lib/sasl2/sasl.db. A opo c somente necessria quando a conta do usurio est sendo criada pela primeira vez. O programa sasldblistusers2 lista os usurios presentes no arquivo de senhas:
# sasldblistusers2 benjamin@servidor.empresa: userPassword

Note como foi automaticamente acrescentado um domnio ao nome do usurio. Esta uma caracterstica dos mecanismos de senhas compartilhadas. Por padro, o domnio utilizado o nome completo da maquina. 3. Ajustar permisses Precisamos garantir que os programas que vo utilizar autenticao SASL tenham acesso ao arquivo de senhas /var/lib/sasl2/sasl.db. a melhor forma de se fazer isto usando o grupo sasl (criado durante a instalao do plugin sasl2-sasldb), e mantendo as permisses do arquivo desta forma:
# ls l /var/lib/sasl2/sasl.db -rw- r----- 1 root sasl 12288 Dez 27 11:23 /var/lib/sasl2/sasl.db

Agora basta inserir no grupo sasl os usurios dos programas que precisam ter acesso a esta base de dados. No nosso caso, precisamos fazer o usurio ldap membro deste grupo. Basta editar o arquivo /etc/group e fazer a modificao destacada a seguir:

33

LDAP LDAP /etc/group:

(...) Machines:x:421: sasl:x:422:ldap Gdm:x:423: (...)

inserindo o usurio ldap no grupo sasl

4. Testando Como o arquivo no existia antes, recomenda-se reiniciar o servio ldap agora. Futuras alteraes no arquivo /var/lib/sasl2/sasl.db no implicaro mais nesta necessidade, no entanto. A nossa consulta de teste ser feita com o usurio criado, benjamin. Como este usurio no existe no sistema (/etc/shadow), precisamos especificar seu nome na linha de comando caso contrario o ldapsearch utilizaria o usurio do shell corrente:
$ ldapsearch LLL Y digest-md5 U benjamin cn=jadzia cn SASL/DIGEST-MD5 authentication started Please enter your password: foi digitada a senha do benjamin do sasl.db SASL username: benjamin SASL SSF: 128 temos criptografia na conexo! SASL installing layers dn: cn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br cn: jadzia

Este teste merece alguns comentrios: No utilizamos mais a opo -x, pois agora queremos utilizar SASL e no autenticao simples; Atravs da opo -Y foramos a escolha do mecanismo de autenticao SASL para ser DIGEST-MD5. Sem essa opo, a prpria biblioteca OpenLDAP escolheria o mecanismo mais adequado baseado no que o servidor suporta. Se o servidor suportar GSSAPI e DIGEST-MD5, por exemplo, a biblioteca escolheria GSSAPI em detrimento de DIGEST-MD5; A conexo de teste foi protegida por um fator de segurana (SSF) de 128 bits. Isto significa que alm da senha no ter trafegado em texto claro pela rede, o resto da conexo tambm foi criptografado; A senha utilizada na conexo no mais a do atributo userPassword! Como estamos utilizando autenticao SASL, este atributo ignorado e utilizada a senha do mecanismo SASL que foi escolhido, seja ele qual for. No nosso caso, a senha armazenada no arquivo /var/lib/sasl2/sasl.db. possvel fazer SASL utilizar a senha contida no atributo userPassword, mas isso implica na configurao do plugin ldapdb.

3.4.2 Mapeamento SASL para DN

Se tentarmos obter o atributo userPassword atravs de uma conexo autenticada via SASL, teremos uma surpresa:

34

LDAP LDAP
$ ldapsearch LLL Y digest-md5 U benjamin cn=benjamin userPassword SASL/DIGEST-MD5 authentication started Please enter your password: SASL username: benjamin SASL SSF: 128 SASL installing layers dn: cn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br $

No funcionou! Mas como? Nossa ACL explicitamente d privilgios de acesso para o atributo userPassword no caso da conexo estar autenticada pelo dono da entrada. Vejamos os logs: /var/log/ldap/ldap.log:
slapd[18704]: conn=0 op=0 slapd[18704]: conn=0 op=0 slapd[18704]: conn=0 op=0 slapd[18704]: conn=0 op=0 mech=DIGEST-MD5 ssf=128 BIND BIND BIND BIND dn="" method=163 dn="" method=163 authcid="benjamin" authzid="benjamin" dn="uid=benjamin,cn=digest-md5,cn=auth"

O problema o binddn. No caso da autenticao simples, o binddn (login) fornecido pelo cliente (no caso do ldapsearch, atravs do parmetro D). Mas no caso da autenticao SASL, o binddn construdo pelo servidor usando a seguinte sintaxe:
uid=<usurio>,[cn=realm,]cn=<mecanismo>,cn=auth

O componente cn=realm somente utilizado por mecanismos SASL que suportam este conceito, como GSSAPI. No nosso caso, podemos ver nos logs que o componente realm no utilizado e o binddn do usurio benjamin ficou:
uid=<usurio>,[cn=realm,]cn=<mecanismo>,cn=auth

Este DN no mais igual entrada onde est o atributo que queremos, portanto no mais considerado self naquela ACL e o acesso ao atributo negado: entrada no diretrio: dn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br binddn: uid=benjamin,cn=digest=md5,cn=auth trecho de /etc/openldap/slapd.conf:
access to attrs=userPassword by anonymous auth by self write s vale se o binddn for igual ao dn da entrada by * none

Para corrigir isso, precisamos mapear o binddn da autenticao SASL para um DN existente no diretrio. Isto feito atravs da diretiva sasl-regexp que acrescentaremos configurao do nosso servidor OpenLDAP:
include include include include pidfile argsfile /usr/share/openldap/schema/core.schema /usr/share/openldap/schema/cosine.schema /usr/share/openldap/schema/inetorgperson.schema /usr/share/openldap/schema/nis.schema /var/run/ldap/slapd.pid /var/run/ldap/slapd.args
35

LDAP LDAP
database suffix rootdn rootpw directory index index index index bdb dc=exemplo,dc=com,dc=br cn=Manager,dc=exemplo,dc=com,dc=br {SSHA}pzp96ZACsCrWbeos2D4ujmGvKRyJFQiY /var/lib/ldap objectClass eq objectClass sn,cn telephoneNumber eq eq,sub,approx eq,sub

access to attrs=userPassword by anonymous auth by self write by * none Access to * By * read # DN de autenticao SASL: uid=<Lusuario>,[cn=realm,]cn=<mecanismo>,cn=auth authz-regexp ^uid=([^,]+),cn=digest-md5,cn=auth$ cn=$1,ou=Pessoas,dc=exemplo, dc=com,dc=br

A diretiva sasl-regexp utiliza expresses regulares para fazer o mapeamento, sendo a nica diferena a utilizao de $ em vez de \ para referencias a grupos anteriores (como no exemplo:$1 em vez de \1). Com esta configurao, aps reiniciar o servidor LDAP e tentarmos novamente a pesquisa a resposta agora ter o atributo userPassword:
$ ldapsearch LLL Y digest-md5 U benjamin userPassword SASL/DIGEST-MD5 authentication started Please enter you password: SASL username: benjamin SASL SSF: 128 SASL installing layers dn: cn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br userPassword:: e1NTSEF9NURtRlJkUS9sUiA2Ry96NDFSRSswczB6b3JWM05mTlE=

Os logs confirmam que o binddn mudou para o formato que utilizamos no nosso diretrio para a entrada deste usurio, de forma que a ACL com self agora se aplica novamente e o acesso ao atributo foi garantido: /var/log/ldap/ldap.log:
Slapd[21641]: conn=0 op=1 BIND dn="" method=163 Slapd[21641]: conn=0 op=1 BIND authcid="benjamin" Slap[21641]: conn=0 op=1 BIND dn="cn=benjamin,ou=pessoas,dc=exemplo,dc=com,dc=br" mech=DIGEST-MD5 ssf=128

Usos mais avanados da diretiva sasl-regexp podem ser vistos no Guia do Administrador do OpenLDAP e na documentao contida nas manpages, em particular slapd.conf (5).

3.4.3 SASL para rootdn

Tambm possvel utilizar mecanismos SASL para autenticar o administrador do diretrio. Neste caso, no especificamos a diretiva rootpw (que representa a senha do administrador), pois a autenticao ser controlada pelos mecanismos SASL.

36

LDAP LDAP Para utilizarmos autenticao SASL para o administrador do diretrio (manager), basta removermos a diretiva rootpw e trocarmos a identificao do rootdn para uma notao SASL: trecho de /etc/openldap/slapd.conf:
rootdn #rootpw uid=manager,cn=digest-md5,cn=auth {SSHA}LK5sIfbie0PnNyUL6TTrJYZ6nA6oPxLo no usado para SASL

Infelizmente devido nossa utilizao da diretiva sasl-regexp para mapear DNs SASL para outra notao, o DN final do administrador ser cn=manager,ou=Pessoas,dc=exemplo,dc=com,dc=br. H duas alternativas para solucionar este problema: Utilizar ACLs para permitir que essa entidade cn=manager possa escrever em qualquer parte do diretrio; Utilizar o rootdn j no formato final, ou seja, o resultante da modificao feita por sasl-regexp. A melhor alternativa costuma ser a ultima: trecho de /etc/openldap/slapd.conf:
rootdn cn=manager,ou=Pessoas,dc=exemplo,dc=com,dc=br #rootpw {SSHA}LK5sIfbie0PnNyUL6TTrJYZ6nA6oPxLo no usado para SASL (...) # DN de autenticao SASL da forma uid=<usurio>,[cn=realm,]cn=<mecanismo>,cn=auth sasl-regexp ^uid=([^,]+),cn=digest-md5,cn=auth$ cn=$1,ou=Pessoas,dc=exemplo,dc=com,dc=br

No necessrio que exista uma entrada para esse rootdn no diretrio, pois estaremos utilizando autenticao SASL.

3.5 Exemplos de ACLs

Quando inserimos o atributo userPassword no nosso diretrio, vimos rapidamente uma configurao de ACL para proteger o acesso a este atributo. As ACLs do OpenLDAP podem ser bastante complexas devido a sua flexibilidade. Veremos aqui alguns exemplos prticos. Todas as opes de configurao podem ser vistas na pgina de manual slapd.access (5). Sintaxe: access to <que> by <quem> <direitos>

A clausula <que> (<what> na documentao em ingls) determina a que elemento a ACL se aplica. Este elemento pode ser desde um DN literal, um ou mais atributos, uma expresso regular e at uma pesquisa LDAP. Os possveis valores esto descritos na tabela a seguir:

37

LDAP LDAP <que> * dn[.estilo]=<DN> filter=<ldapfilter> attrs=<lista-de-atributos> Descrio Casa com tudo (qualquer atributo, qualquer DN). Especifica uma DN. Se .estilo no for especificado, o padro para OpenLDAP-2.1.x regex (indicando uma expresso regular). No OpenLDAP-2.2.x, o estilo padro exact. Especifica um filtro LDAP conforme RFC 2254 sendo que o resultado desta consulta o que ser utilizado. Especifica uma lista de atributos separados por vrgulas.

Os valores possveis para o estilo da DN so: Estilo (dn.estilo) regex base ou exact one subtree children Descrio A DN especificada como uma expresso regular A DN especificada de forma exata Indica todas as entradas um nvel abaixo da DN especificada Indica a prpria entrada e todas as entradas abaixo dela Indica todas as entradas abaixo da DN especificada, excluindo a prpria entrada

A clusula <quem> (<Who> na documentao em ingls) determina quem ter os direitos de acesso. Os valores possveis so: <quem> * anonymous users self dn[.estilo]=<DN> snattr=<atributo> ssf=<valor> Descrio Casa com tudo. Usurios annimos, isto com binddn vazio. Usurios autenticados, seja via autenticao simples ou SASL. Usado para permitir que uma entrada modifique a si mesma. Por exemplo, o caso onde o binddn igual ao DN da entrada sendo acessada. Mesma sintaxe que dn[.estilo} da clausula <que>. O DN usado est armazenado em <atributo>. Valor mnimo para ssf (security strenght factor).

Por fim, os valores possveis para a clausula <direitos> (<rights> na documentao em ingls) so: <direito> none auth compare search read write Descrio Sem acesso Acesso apenas para operaes de autenticao ou autorizao Acesso para operaes de comparao Acesso para operaes de pesquisa Acesso para leitura Acesso para escrita

Cada nvel de acesso implica tambm nas permisses dos nveis anteriores. Por exemplo, acesso search implica em acesso compare e auth tambm, e acesso white implica em acesso completo.

38

LDAP LDAP A seguir veremos alguns exemplos prticos de ACLs do OpenLDAP.

3.5.1 Impedir consultas annimas

Um conjunto de ACLs que impede consultas annimas arbitrrias est reproduzido a seguir. Esta configurao pode ser bastante interessante para algumas redes, pois somente permite acesso aos dados do diretrio para usurios autenticados. trecho de /etc/openldap/slapd.conf:
access to attrs=userPassword by anonymous auth by self write by * none access to dn.exact="" by * read access to dn.exact="cn=subschema" by * read access to dn.subtree="dc=exemplo,dc=com,dc=br" by users read by * none

Em um primeiro momento, poderamos ser tentados a utilizar a ACL seguinte para impedir acesso annimo a todo diretrio:
access to * by users read by * none

Mas ela traz um problema: o acesso raiz do diretrio (base de procura igual a ) deve ser garantido mesmo para usurios annimos, pois fornece informaes bsicas sobre o servio. Uma destas informaes so justamente os mecanismos SASL de autenticao suportados, e usurios annimos precisam ter acesso a isto caso queiram usar autenticao SASL em seguida. Precisamos, portanto, dar acesso raiz do diretrio para usurios annimos, e ento poderemos fechar o resto. isso que a ACL dn.exact=" faz no caso da raiz, e dn.subtree="dc=exemplo,dcx=com,dc=br para o caso do resto da nossa rvore abaixo do ponto indicado (inclusive). Por fim, ainda ser til liberar acesso annimo para consultar o schema suportado pelo servidor. No caso do OpenLDP, o schema publicado a partir do ponto cn=subschema.

3.5.2 Forar o uso de criptografia

Algumas vezes desejvel que o acesso a um atributo somente possa ser feito quando a conexo estiver protegida por criptografia. Por exemplo, o atributo de troca de senha. Isto pode ser controlado com a ACL seguinte: trecho de /etc/openldap/slapd.conf:
access to attrs=userPassword by anonymous ssf=56 auth by self ssf=56 write by * none
39

LDAP LDAP

Simplesmente acrescentamos a clausula ssf=56 ACL conforme enfatizado em negrito no trecho de configurao anterior. Isto faz com que o acesso somente seja permitido se houver um ssf (Security Strengtyh Factor) de 56 bits ou mais. Agora a operao de simple bind somente vai ter sucesso caso seja utilizada uma camada adicional de criptografia:
$ ldapsearch -x -D cn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br cn=benjamin userpassword Enter LDAP Password: ldap_bind: Insulfficient Access (50) -W -LLL

Autenticao SASL com diget-md5, por outro lado, j vai ter sucesso, pois utiliza um ssf de 128 bits:
$ ldapsearch -U benjamin -Y digest-md5 -LLL cn=benjamin userpassword SASL/DIGEST-MD5 authentication started Please enter LDAP Password: SASL username: benjamin SASL SSF: 128 temos criptografia SASL installing layers dn: cn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br userPassword: e1NTSEF9NURtRlJkUS9sUjA2Ry96NDFSRSswczB6b3JWM05mTlE=

sucesso!

3.6 Dicas
Muitas vezes erros na autenticao SASL atravs do plugin sasldb esto relacionados a algum problema de permisso no arquivo de senhas /var/lib/sasl2/sasl.db. Sempre verifique se o servidor em questo tem permisses de leitura neste arquivo. Nunca esquea que a autenticao simples no possui nenhuma proteo prpria para a senha: ela trafega em texto claro pela rede. Se isto no for desejvel, utilize criptografia na conexo (explicada mais adiante nesta apostila) ou algum mecanismo SASL que fornece esta criptografia (como DIGEST-MD5 e GSSAPI). ldappasswd pode ser utilizado para trocar a senha da autenticao simples (atributo userPassword). Este comando utiliza a extenso EXOP do OpenLDAP. Mecanismos de autenticao SASL so bastante flexveis e poderosos. possvel, por exemplo, utilizar o conceito de autorizao onde os usurios se autenticam como uma entidade, mas age em nome de outra. ACLs no OpenLDAP podem utilizar o recurso de expresses regulares. Embora poderoso, tem seu preo: podem deixar o servidor mais lento. Sempre de preferncia a ACLs mais especificas para evitar surpresas. Aps qualquer alterao nas ACLs sempre necessrio reiniciar o servidor OpenLDAP. Existe uma extenso, ainda experimental, chamada ACI que permite o uso de ACLs dentro das entradas do diretrio. Estas ACls no necessitam que o servio seja reiniciado aps alguma alterao.

3.7 Exerccios

40

LDAP LDAP

1. Troque a senha (autenticao simples) da entrada cn=benjamin, ou=Pessoas,dc=com,dc=br para teste usando ldapmodify e o hash MD5. Utilize as credenciais de administrador para isto e autenticao SASL DIGEST-MD5;

2. Crie uma ACL para o atributo userPassword de forma a atender aos requisitos seguintes: Usurio annimo s tem acesso para efeitos de autenticao; O prprio usurio pode trocar sua senha desde que utilize uma segurana de 64 bits ou superior; O usurio representado pela dn uid=Maria,ou=gerentes,dc=exemplo,dc=com, dc=br pode alterar a senha desde que utilize uma segurana de 64 bits ou superior; Nenhum outro usurio pode ter acesso a este atributo.

3. Crie uma conta de usurio maria na base /var/lib/dadl2/sasl.db.

Referencias: RFC 2222: Simple Authentication and Security Layer (SASL) (em ingls) http://www.ieft.org/rfc/rfc2222.txt Site do pacote Cyrus-SASL (em ingls) http://www.asg.web.cmu.edu/sasl/ FAQ sobre o uso de ACLs no OpenLDAP (em ingls) http://www.openldap.org/fag/data/cache/189.html Pagina de manual descrevendo ACLs no OpenLDAP slapd.access (5)

41

LDAP LDAP

CAPTULO 4

LDAP E USURIOS DO SISTEMA

A utilizao do OpenLDAP como repositrio de informaes somente mostra sua utilidade a partir do momento que os diversos sistemas da rede o acessam para obter suas informaes. Ao final deste captulo, voc dever ser capaz de: Fazer o sistema reconhecer usurios no OpenLDAP Utilizar OpenLDAP para autenticao de usurios

42

LDAP LDAP

4.1 Armazenando Usurios no OpenLDAP

Antes de partirmos para o armazenamento de usurios do sistema no diretrio, precisamos definir quais informaes de um usurio o sistema necessita possuir. Quais as suas caractersticas? Tradicionalmente as informaes de usurios ficam armazenadas em arquivos diversos no sistema, como /etc/passwd, /etc/shadow e /etc/group. De forma a conseguir utilizar unicamente o OpenLDAP como substituto dessas informaes, precisamos armazen-las todas no diretrio. Vamos criar um usurio local no sistema chamado Carlos Silva, com login carlos, e analisar quais os atributos que compem este usurio. Primeiro, informaes do /etc/passwd:
# cat /etc/passwd grep carlos carlos:x:19420:Carlos Silva:/home/carlos:/Bin/bash

Vejamos: Campo nome de login senha uid gid primrio gecos diretrio home shell Contedo carlos x 19420 19420 Carlos Silva /home/carlos /bin/bash

Ainda faltam informaes relacionadas a grupos (que ficam em /etc/group) e relacionadas senha (que ficam em /etc/shadow). Como o usurio foi recm criado, s existe seu grupo primrio:
# cat /etc/group | grep carlos carlos:x:19420:

E as informaes de senha:
# cat /etc/shadow | grep carlos carlos:$1$zrKL3tDK$lpPk6KBOIBXetAsFPCTj10:12691:0:99999:7:::

Isso tudo representa o conjunto de informaes que precisamos migrar para o diretrio de forma que o sistema consiga utiliza-lo para reconhecer usurios.

4.1.1 Escolha das classes e atributos

Uma vez que j temos as informaes necessrias a respeito de um usurio do sistema, podemos escolher que classe de objetos e atributos iremos representar este usurio no OpenLDAP. Felizmente esta tarefa j foi feita por outras pessoas e padronizada na RFC 2307 que determina justamente que classe e atributos devem ser usados para esta tarefa. Esta RFC ainda est categorizada como experimental, mas j suportada por diversos programas. A

43

LDAP LDAP tabela a seguir associa as classes de objetos com as respectivas fontes de informaes de usurios tradicionalmente armazenadas em disco: Arquivo do Sistema /etc/passwd /etc/group /etc/shadow objectClass no Diretrio posixAccount posixGroup shadowAccount

Estas trs classes de objetos so o mnimo necessrio para representarmos usurios do sistema no diretrio. se formos analisar suas definies, no entanto, veremos que so todas classes auxiliares, o que significa que precisaremos de uma classe estrutural ainda. Recapitulando, classes estruturais so classes que representam objetos fsicos verdadeiro. Duas escolhas bastante populares costumam ser account e classes derivadas da person (como intOrgPerson ou organizationalPerson). Para representar usurios, estas ultimas costumam ser uma escolha melhor por permitirem diversos outros atributos que podem vir a ser utilizados no futuro, como endereos de e-mail, placa do carro, foto, certificado digital e vrias outras. Sempre pense adiante ao projetar um diretrio! De posse destas classes de objetos e atributos, podemos construir nossa primeira verso da entrada no diretrio do usurio carlos. Vamos comear com a classe posixAccount e seus atributos, listados a seguir. Em negrito esto os atributos obrigatrios:
objectClass: posixAccount cn: carlos uid: carlos uidNumber: 19420 gidNumber: 19420 homeDirectory: /home/carlos loginShell: /bin/bash gecos: Carlos Silva

A relao entre os campos de cada linha do arquivo /etc/passwd e os atributos da classe posixAccount a seguinte:

uid:userPassword:uidNumber:gidNumber:gecos:homeDirectory:loginShell

/etc/passwd: Onde: Atributo uid userPassword uidNumber gidNumber gecos homeDirectory loginShell Descrio Nome de login do usurio Hash da senha. Normalmente contm apenas x, indicando que se est utilizando senhas do arquivo /etc/shadow. Cdigo numrico de identificao do usurio. Cdigo numrico de identificao do grupo primrio do usurio. Descrio, normalmente contendo o nome completo do usurio. Diretrio home do usurio. Shell utilizada pelo usurio.

44

LDAP LDAP loginShell um atributo opcional para esta classe, mas uma informao que temos disponvel no arquivo /etc/passwd e vamos utiliza-la. E gecos, apesar de no ser um atributo obrigatrio do ponto de vista do schema, obrigatrio segundo a RFC 2307. Se esta informao no existir no arquivo /etc/passwd, o atributo deve ser preenchido com o mesmo valor de cn. Por fim, no vamos utilizar o atributo userPassword desta vez porque a senha vir do arquivo /etc/shadow. O prximo passo acrescentar as informaes da classe shadowAccount que contem os detalhes de senha e autenticao. Os novos atributos esto novamente em negrito:
objectClass: posixAccount objectClass: shadowAccount cn: carlos uid: carlos uidNumber: 19420 gidNumber: 19420 homeDirectory: /home/carlos loginShell: /bin/bash gecos: Carlos Silva userPassword: {crypt}$1$zrKL3tDK$lpPk6KBOIBXetAsFPCTj10 shadowLastChange: 12691 shadowMax: 99999 shadowWarning: 7

A relao entre a linha do usurio no arquivo /etc/shadow e os atributos da classe shadowAccount est descrita a seguir:
usuario:userPassword:shadowLastChange:shadowMin:shadowMax:shadowWarning:shadowInac tive:shadowExpire:shadowFlag

/etc/shadow: Onde: Atributo userPassword shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag Descrio Hash da senha do usurio Data da ultima troca de senha (nmero de dias desde 01/JAN/1970) Quantidade mnima de dias entre troca de senhas Quantidade mxima de dias entre troca de senhas Nmero de dias antes da expirao da senha para avisar o usurio. Numero de dias aps a senha ter expirado que a conta desativada. Data de desativao da conta (nmero de dias desde 01/JAN/1970) Reservado para uso futuro.

Nossa entrada est quase completa: ainda nos falta uma classe estrutural. Vamos utilizar inetOrgPerson, que completa e com vrios atributos teis para informaes de usurio em uma empresa. A definio desta classe est no arquivo /etc/openldap/schema/inetorgperson.schema.

45

LDAP LDAP

Novamente, as alteraes esto em negrito:

objectClass: posixAccount objectClass: shadowAccount objectClass: inetOrgPerson cn: carlos sn: silva uid: carlos uidNumber: 19420 gidNumber: 19420 homeDirectory: /home/carlos loginShell: /bin/bash gecos: Carlos Silva userPassword: {crypt}$1$zrKL3tDK$lpPk6KBOIBXetAsFPCTj10 shadowLastChange: 12691 shadowMax: 99999 shadowWarning: 7

A definio da classe inetOrgPerson no exige nenhum atributo obrigatrio, mas precisamos tomar cuidado. Esta classe herda todas as definies da classe organizationalPerson, que por sua vez herda as definies de person. Disto resulta que temos um atributo obrigatrio sim, o sn (surname, ou sobrenome). As informaes especficas deste usurio esto prontas agora. Para inserirmos a entrada no diretrio, no entanto, precisamos escolher uma RDN. Os atributos mais usados para isto so cn (common name) e uid (userid). A RFC2307 sugere fortemente o uso do atributo uid para isto no caso da classe posixAccount, e o que faremos aqui. OBS: A utilizao do atributo uid possui um pequeno efeito colateral: tanto carlos como Carlos sero o mesmo usurio. O arquivo LDIF que representa nosso usurio est reproduzido a seguir: carlos.ldif:
dn: uid=carlos,ou=Pessoas,dc=exemplo,dc=com,dc=br objectClass: posixAccount objectClass: shadowAccount objectClass: inetOrgPerson cn: carlos sn: silva uid: carlos uidNumber: 19420 gidNumber: 19420 homeDirectory: /home/carlos loginShell: /bin/bash gecos: Carlos Silva userPassword: {crypt}$1$zrKL3tDK$lpPk6KBOIBXetAsFPCTj10 shadowLastChange: 12691 shadowMax: 99999 shadowWarning: 7

Podemos inserir este arquivo no diretrio agora com ldapadd:

$ ldapadd U manager Y gidest-md5 < carlos.ldif SASL/DIGEST-MD5 authentication started Please enter your password: SASL username: manager SASL SSF: 128 Adding new entry uid=carlos,ou=Pessoas,dc=exemplo,dc=com,dc=br
46

LDAP LDAP

4.1.2 Grupos
J migramos as informaes dos arquivos /etc/passwd e /etc/shadow para o LDAP: falta migrarmos os grupos. Continuando o nosso exemplo do usurio Carlos, precisamos criar seu grupo primrio no diretrio. a classe utilizada para isto ser posixGroup e a entrada ter os seguintes atributos (em negrito os que so obrigatrios):
objectClass: posixGroup cn: carlos gidNumber: 19420 memberUid: carlos

O atributo memberUid lista os membros do grupo, um por atributo. Portanto, para colocar outro usurio no mesmo grupo basta acrescentar outro atributo memberUid com o nome do outro usurio. No h muita dvida sobre qual RDN utilizar neste caso, visto que precisamos utilizar um atributo existente na entrada: ser cn. Mas na arvore armazenaremos os grupos? Bom, se pessoas esto armazenadas em ou=Pessoas, nada mais lgico que criarmos uma outra unidade organizacional chamada ou=Grupos. Portanto, o arquivo LDIF final ser: grupos.ldif:
dn: ou=Grupos,dc=exemplo,dc=com,dc=br objectClass: organizationalUnit ou: Grupos dn: cn=carlos,ou=Grupos,dc=exemplo,dc=com,dc=br objectClass: posixGroup cn: carlos gidNumber: 19420 memberUid: carlos

Note que a entrada do grupo carlos s pode ser criada aps a criao da unidade organizacional dos grupos, por isso a ordem das entradas neste arquivo LDIF importante. Podemos aproveitar e criar um outro grupo chamado usuarios onde colocaremos todos os nossos usurios. O arquivo LDIF para isto seria: grupo-usuarios.ldif:
dn: cn=usurios,ou=Grupos,dc=exemplo,dc=com,dc=br objectClass: posixGroup cn: usuarios gidNumber: 900 memberUid: carlos

o gidNumber 900 foi arbitrariamente escolhido neste caso. Deve-se tomar apenas cuidado para no repetir este nmero para outros grupos. O mesmo vale para o atributo uidNumber da classe posixAcount.

47

LDAP LDAP

4.1.3 A RFC2307bis
A RFC2307bis introduz algumas modificaes na RFC2307, em particular com relao aos grupos. A utilizao unicamente do atributo memberUid, conforme especificado na RFC2307, pode ser inconveniente para alguns diretrios por poder deixar margem a duvidas em um primeiro momento. Afinal, a consulta de membros de um dado grupo simplesmente obtida atravs de uma pesquisa no diretrio procurando por entradas que contenham o atributo uid igual ao que est listado em memberUid. A notao introduzida na RFC2307bis bem mais especfica. Nela so utilizadas duas classes para a especificao de grupos: posixGroup, que foi modificada para ser uma classe auxiliar e no mais estrutural, e a classe groupOfUniqueNames, que estrutural. Nesta notao, o grupo usuarios dos nossos exemplos seria definido da seguinte maneira:
dn: cn=usurios,ou=Grupos,dc=exemplo,dc=com,dc=br objectClass: posixGroup objectClass: groupOfNames cn: usuarios gidNumber: 900 member: uid=carlos,ou=pessoas,dc=exemplo,dc=com,dc=br

Em vez de usarmos memberUid, utilizamos o atributo member cujo valor deve ser um DN apontando para o membro do grupo. Como um DN nico em um diretrio, esta forma mais precisa na definio dos membros dos grupos. Espera-se que a RFC2307bis entre em vigor em um futuro prximo. Administradores que desejarem utiliza-la podem faz-lo desde j, pois nss_ldap a suporta integralmente. Infelizmente isso ir requerer uma mudana no schema oficial, pois a classe posixAccount precisar ser auxiliar, e no mais estrutural.

4.2 Reconhecimento do Usurio pelo Sistema

chegada a hora de fazermos o sistema reconhecer os usurios e grupos armazenados no nosso diretrio OpenLDAP. Isto feito atravs da instalao e configurao do pacote nss_ldap. Em primeiro lugar, precisaremos configurar o nss_ldap propriamente dito, e depois configurar o sistema para que ele considere o LDAP como uma fonte de informaes adicional. Toda esta configurao pode ser feita atravs da ferramenta drakauth, que tambm configura o aspecto de autenticao do sistema. Mas iremos primeiro ver em detalhe como as coisas funcionam, pois importante para poder diagnosticar eventuais problemas que venham a surgir. Inicialmente vamos utilizar consultas annimas no nosso servidor. Vamos ento revisar o arquivo de configurao do OpenLDAP para que as ACLs permitam este tipo de acesso: trecho de /etc/openldap/slapd.conf:
access to attrs=userPassword by anonymous auth by self write by * none access to * by * read
48

LDAP LDAP

A configurao mnima para nss_ldap a seguinte: /etc/ldap.conf:

host 127.0.0.1 base dc=exemplo,dc=com,dc=br

Onde: host: endereo do servidor LDAP; base: base da procura. E apartir deste ponto que o nss_ldap far suas consultas. E, por fim, configuramos o sistema para utilizar o mapa LDAP como fonte de informaes adicionais. Isto feito no arquivo /etc/nsswitch.conf nas linhas passwd, group e shadow; /etc/nsswitch.conf:
passwd: shadow: group: files ldap files ldap files ldap

A partir do momento que este arquivo for salvo com estas modificaes, o sistema j estar utilizando nss_ldap para pesquisar usurios (mapas passwd e shadow) e grupos (mapa group). Antes de fazer um teste, vamos remover o usurio carlos dos arquivos do sistema para termos certeza que a consulta estar sendo feita no LDAP:
# grep carlos /etc/passwd # grep carlos /etc/group # grep carlos /etc/shadow #

Agora vamos ver o que sistema sabe sobre seus usurios:

$ getent passwd root:x:0:0:root:/root:/Bin/bash bin:x:1:1:bin:/bin: daemon:x:2:2:daemon:/sbin: adm:x:3:4:adm:/var/adm: lp:x:4:7:lp:/var/spool/lpd: sync:x:5:65:sync:/sbin:/bin/sync shutdown:x:6:66:shutdown:/sbin:/sbin/shutdown halt:x:7:67:halt:/sbin/:/sbin/halt mail:x:8:12:mail:/var/spool/mail: uupc:x:10:14:uupc:/var/spool/uucp: (...) ldap:x:103:106:Ldap user:/var/lib/openldap-data:/bin/false rpcuser:x:29:108:RPC Service User:/var/lib/nfs:/sbin/nologin postgres:x:104:109:PostgreSQL Server:/var/lib/pgsql:/bin/bash carlos:x:19420:19420:Carlos Silva:/home/carlos:/bin/bash

carlos!

No log do servidor LDAP:

49

LDAP LDAP /var/log/ldap/ldap.log:

slapd[16270]: conn=95 op=1 SRCH base=dc=exemplo,dc=com,dc=br scope=2 filter=(objectClass=posixAccount) slapd[16270]: conn=95 op=1 SRCH attr=uid userPassword uidNumber cn homeDirectory loginShell gecos description objectClass slapd[16270]: conn=95 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=

Vemos que foi feita uma consulta com o filtro (objectClass=posixAccount), ou seja, foram listadas todas as entradas (e alguns atributos selecionados) que possuem esta classe, que so justamente os nossos usurios. Algo semelhante ocorre para grupos:
$ getent group root:x:0:root bin:x:1:root,bin,daemon daemon:x:2:root,bin,daemon sys:x:3:root,bin,adm adm:x:4:root,adm,daemon tty:x:5: disk:x:6:root lp:x:7:daemon,lp mem:x:8: (...) rpcuser:x:108: postgres:x:109: carlos:x:19420:carlos usuarios:x:900:carlos

nossos grupos do LDAP comeam aqui

L esto nossos dois grupos do diretrio. E os logs do servidor mostram a consulta efetuada: /var/log/ldap/ldap.log:
slapd[16271]: conn=106 op=1 SRCH base=dc=exemplo,dc=com,dc=br scope=2 filter="(&(objectClass=posixGroup) slapd[16271]: conn=106 op=1 SRCH attr=cn userPassword memberUid uniqueMember gidNumber slapd[16271]: conn=106 op=1 SEARCH RESULT tag=101 err=0 nentries=2 text=

Desta vez a consulta foi feita pela classe posixGroup, e foram encontradas duas ocorrncias (nentries=2) conforme previsto. Uma consulta um pouco mais especfica tambm pode ser feita:
$ getent passwd carlos carlos:x:19420:Carlos Silva:/home/carlos:/bin/bash

Desta vez, a consulta feita ao servidor LDAP (&(objectClass=posixAccount) (uidcarlos)), o que retorna exatamente uma entrada: /var/log/ldap.log:
slapd[16270]: conn=127 op=1 SRCH base=dc=exemplo,dc=com,dc=br scope=2 filter="(&(objectClass=posixAccount) (uid=carlos)) slapd[16270]: conn=127 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass slapd[16270]: conn=127 op=1 SEARCH RESULT tag=101 err=0 nentries=2 text=

50

LDAP LDAP A pesquisa de grupos suplementares (mapa group) tambm funciona:

$ id carlos uid:x:19420(carlos) gid=19420(carlos) grupos=19420(carlos),900(usuarios)

O comando id infelizmente no utiliza a melhor forma para calcular os grupos suplementares. Ao invs de utilizar funes especificas para esta tarefa (como getgrouplist()), id enumera todos os grupos e procura manualmente os seus membros. Desta forma, seu resultado ser bastante lento em diretrios com muitos usurios e grupos.

4.2.1 Refinando a configurao

possvel, e algumas vezes desejvel, fazer com que o nss_ldap consulte um ramo especfico da arvore para um dado mapa, ou limiar de outra forma a abrangncia desta consulta. Por exemplo, todos os nossos usurios esto sob o ramo ou=Pessoas, enquanto os grupos esto sob ou=Grupos. Com o arquivo de configurao anterior, nss_ldap est encontrando os usurios e grupos porque est realizando uma busca do tipo subtree a partir do topo da arvore. Para especificar os ramos para cada mapa, fazemos as seguintes alteraes no arquivo de configurao: /etc/ldap.conf:
host servidor.ldap base dc=exemplo,dc=com,dc=br nss_base_passwd ou=Pessoas,dc=exemplo,dc=com,dc=br?one nss_base_shadow ou=Pessoas, dc=exemplo,dc=com,dc=br?one nss_base_group ou=Grupos,dc=exemplo,dc=com,dc=br?one

Note como agora a pesquisa do usurio (resultante do mesmo comando getent passwd carlos usado nos exemplos anteriores) comea diretamente no ramo ou=Pessoas: /var/log/ldap/ldap.log:
slapd[16270]: conn=773 op=1 SRCH base="ou=Pessoas,dc=exemplo,dc=com,dc=br" scope=1 filter="(&(objectClass=posixAccount) (uid=carlos))" slapd[16270]: conn=773 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass slapd[16270]: conn=773 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=

Alm disto, a pesquisa no mais do tipo subtree no nosso exemplo (scope=1): foi especificada uma pesquisa de um nvel de profundidade apenas (?one no /etc/ldap.conf). Isto funciona na nossa arvore porque sabemos que no existem outros ramos sob ou=Pessoas e ou=Grupos. Os valores possveis para este parmetro so: Tipo de pesquisa base one sub Descrio A pesquisa somente feita na DN especificada A pesquisa feita um nvel abaixo da DN especificada, sem incluir a DN A pesquisa feita comeando na DN especificada e descendo at o ultimo nvel disponvel

51

LDAP LDAP O arquivo de configurao padro no nss_ldap possui diversos outros exemplos de bases de pesquisa e mapeamentos de atributos e leitura recomendada para os administradores da rede.

4.3 Autenticando Usurios via LDAP

Fazer com que o sistema reconhea os usurios via LDAP o primeiro passo para autenticao no diretrio. Afinal, para efetuar um login em um sistema GNU/Linux e obter um prompt, muito mais que apenas utilizar a senha correta necessrio: precisamos ter um diretrio home, um interpretador de comandos (shell), um cdigo numrico de identificao (uidNumber), etc. Para configurarmos o sistema para autenticar usurios atravs de LDAP utilizaremos um modulo PAM chamado pam_ldap. Este mdulo compartilha com nss_ldap o arquivo de configurao /etc/ldap.conf. OBS: pam_ldap somente passou a suportar autenticao SASL a partir da verso 172. Verses anteriores utilizam autenticao simples (simple bind). A melhor forma de configurar autenticao LDAP no sistema atravs da ferramenta drakauth. Esta ferramenta tambm serve para configurar vrias outras formas de autenticao, alm de tambm configurar o nss_ldap e /etc/nsswitch.conf. O drakauth modificar os arquivos /etc/nsswitch.conf e, para que o OpenSSH passe a utilizar o PAM, modificar tambm o arquivo /etc/ssh/sshd-config. Note que necessrio reiniciar manualmente o servio do OpenSSH para que as modificaes feitas pelo drakauth tenham efeito. Um arquivo de configurao do PAM, o /etc/pam.d/system-auth, tambm ser modificado pelo drakauth. Vrios servios simplesmente incluem este arquivo, e desta forma conseguimos alterar a configurao de todos ao mesmo tempo. A tabela a seguir ilustra este processo:
/etc/pam.d/login:
auth auth auth required required required pam-securetty.so pam_stack.so service=system-auth pam_nologin.so

/etc/pam.d/system-auth:
auth required pam-env.so auth sufficient pam_unix.so auth required pam_deny.so account sufficient pam_unix.so account required pam_deny.so password requisite pam_cracklib.so password sufficient pam_unix.so md5 shadow password required pam_deny.so session required pam_limits.so session required pam_unix.so

account required pam_stack.so service=system-auth

password required pam_stack.so service=systemauth Session required pam_stack.so service=system-auth session optional pam_console.so

OBS: No Linux, a maioria dos servios de rede inclui a configurao do /etc/pam.d/system-auth. O programa drakauth est disponvel em duas verses: modo texto (se executado atravs do console) e modo grfico (se executado em um ambiente grfico).

52

LDAP LDAP Pelo modo grfico, na janela Autenticao LDAP, podemos escolher entre os diversos mtodos de autenticao e armazenamento de informaes de usurios disponveis no sistema. Devemos marcar a opo LDAP e em seguida clicar em OK. Ela j estar preenchida com os valores corretos, pois j criamos o arquivo /etc/ldap.conf anteriormente de forma manual. Aps clicar em OK para finalizar a configurao, podemos dar uma olhada em nossos arquivos de configurao para ver como a ferramenta os alterou: /etc/ldap.conf:
host servidor.ldap base dc=exemplo,dc=dc,dc=br nss_base_passwd ou=Pessoas,dc=exemplo,dc=com,dc=br?one nss_base_shadow ou=Pessoas,dc=exemplo,dc=com,dc=br?one nss_base_group ou=Grupos,dc=exemplo,dc=com,dc=br?one

O arquivo /etc/pam.d/system-auth tambm foi modificado, e esta a parte que nos interessa no momento. As linhas marcadas em negrito mostram as alteraes:
#%PAM-1.0 auth auth auth auth required sufficient sufficient required pam_env.so pam_unix.so likeauth nullok pam_ldap.so use first pass pam_deny.so pam_unix.so pam_ldap.so pam_deny.so

account account account password password password password session session session

sufficient sufficient required required sufficient sufficient required optional required required

use_first_pass

pam_cracklib.so retry=3 minlen=2 dcredit=0 ucredit=0 pam_unix.so nullok use_authtok md5 shadow pam_ldap.so pam_deny.so pam_mkhomedir.so skel=/etc/skel/ umask=0022 pam_limits.so pam_unix.so

Vamos fazer um teste? Basta ir para um terminal e tentar efetuar o login como usurio carlos:
Linux release 2006.0 (official) for i586 Kernel 2.6.12-15.uc2mdk on an i686 / tty4 maestro login: carlos Password: Creating directory /home/carlos. mdulo pam_mkhomedir.so em ao Creating directory /home/carlos/tmp. Last login: Mon Jan 16 17:00:54 from boot.linux [carlos@maestro ~] pwd /home/carlos [carlos@maestro ~]$ l /home/carlos d drwxr----- 3 carlos carlos 4096 2006-10-03 12:01 /home/carlos/

53

LDAP LDAP importante notar que a ferramenta drakauth configurou automaticamente o mdulo PAM pam_mkhomedir.so que automaticamente cria o diretrio home para ns. As opes de linha de comando aceitas pelo mdulo esto detalhadas na tabela a seguir: /lib/security/pam_mkhomedir.so [opes] Especifica qual umask a utilizar (notao octal). Especifica o diretrio de esqueleto a ser utilizado. Todos os arquivos e subdiretrios deste diretrio skel=<diretrio> esqueleto sero copiados para o home. Valor padro: /etc/skel Ativa o modo de depurao. Utilizado para detectar debug problemas. umask=<umask>

4.3.1 Autenticao local

Um problema que pode ser encontrado em mquinas que possuem autenticao LDAP configurada : se o servidor LDAP estiver parado, no s os usurios contidos nos diretrios no podero se autenticar (o que esperado), mas tambm usurios locais no conseguiro acesso ao sistema. Nem mesmo no boot:
Linux release 2006.0 (Official) for i586 Kernel 2.6.12-15.uc2mdk on na i686 / tty4 maestro login: root Password: Authentication service cannot retrieve authentication info.

Nos logs da estao temos as seguintes mensagens (/var/log/messages):

maestro login: pam_ldap: ldap_simple_bind Cant contact LDAP Server maestro login: Authentication service cannot retrieve authentication info.

Para resolver esta situao, precisamos acrescentar uma configurao ao arquivo geral system-auth (destacada em negrito a seguir): /etc/pam.d/system-auth:
#%PAM-1.0 auth auth auth auth required sufficient sufficient required pam_env.so pam_unix.so likeauth nullok pam_ldap.so use_first_pass pam_deny.so

account sufficient pam_unix.so account [default=bad success=ok user unknown authinfo_unavail=ignore service_err=ignore system_err=ignore] pam_ldap.so use_first_pass account required pam_deny.so password password password password session session session required pam_cracklib.so retry=3 minlen=2 dcredit=0 ucredit=0 sufficient pam_unix.so nullok use authok md5 shadow sufficient pam_ldap.so required pam_deny.so optional required required pam_mkhomedir.so skel=/etc/skel/ umask=0022 pam_limits.so pam_unix.so

54

LDAP LDAP Aps esta modificao, o login de usurio locais voltar a funcionar mesmo se o servidor LDAP estiver parado. Vale notar que no Linux esta configurao padro.

4.3.2 Troca de senha

A operao de troca de senha consiste na utilizao do atributo userPassword (ou algum outro, dependendo do servidor) com a nova senha do usurio, seja em texto claro ou em algum dos formatos de hashes suportados como MD5, CRYPT e SSHA. OBS: A troca de senha no pode ser feita via pam_ldap. A diretiva pam_password do arquivo de configurao /etc/ldap.conf controla como feita esta troca de senha. A tabela a seguir resume as opes possveis: pam_password <valor> Armazene a senha em texto claro, sem aplicar hashes Utilize CRYPT Utilize MD5 Utilize mecanismo de troca de senha necessrio para servidor NDS Utilize mecanismo de troca de senha necessrio para servidor Active Directory Utilize a operao estendida (EXOP, Extended Operation) disponvel no servidor OpenLDAP

clear crypt md5 nds ad exop

Na operao estendida, pam_ldap fornece para o servidor LDAP a senha nova diretamente, em texto claro, e deixa a atualizao do atributo userPassword a cargo do servidor mesmo. O hash utilizado depender da configurao do servidor. A figura a seguir ilustra de forma bsica a operao estendida de troca de senha do OpenLDAP: Servidor LDAP
Nova senha: star Exop:senha=star Hash (star)

userPassword

No OpenLDAP, a configurao do hash que ser utilizado para aoperao estendida feita no arquivo /etc/openldap/slap.conf atravs da diretiva password-hash que aceita como argumento o nome do algoritmo de hash a ser utilizado entre chaves. So suportados: {SSHA}, {SHA}, {MD5}, {CRYPY} e {CLEARTEXT}, sendo que este ltimo faz com que a senha seja armazenada em texto claro no atributo sem qualquer tipo de hash aplicado. Os parmetros md5 e crypt para a diretiva pam_password servem em enviar para o servidor LDAP uma simples operao de modificao de valor do atributo userPassword com o respectivo hash j aplicado senha. O servidor o armazenar em userPassword como se fosse algum outro atributo qualquer. Ou seja, quem aplica o hash o cliente.

55

LDAP LDAP

A figura a seguir ilustra este caso: Servidor LDAP

Grave Md5 (star) em userPassword

Nova senha: star

4.3.2.1 Atributos shadow

Se formos observar os logs do servidor OpenLDAP durante uma operao de troca de senha feita atravs do mdulo pam_ldap perceberemos que h uma tentativa de alterar um outro atributo alm do userPassword: /var/log/ldap/ldap.log:
(...) slapd[12003]: slapd[12003]: slapd[12003]: slapd[12002]: slapd[12002]: slapd[12002]: conn=48 conn=48 conn=48 conn=48 conn=48 conn=48 op=5 op=5 op=5 op=6 op=6 op=6 MOD dn="uid=carlos,ou=Pessoas,dc=exemplo,dc=com,dc=br" MOD attr=userPassword RESULT tag=103 err=0 text= MOD dn="uid=carlos,ou=Pessoas, dc=exemplo,dc=com,dc=br" MOD attr=shadowLastChange RESULT tag=103 err=50 text=

As primeiras linhas mostram a alterao do atributo userPassword, mas temos tambm uma tentativa (que no deu certo) de alterao do atributo shadowLastChange. Esta alterao no deu certo por causa das ACLs do servidor que somente permitem que o prprio usurio troque o atributo userPassword, e no shadowLastChange. Este atributo novo utilizado pela sute shadow e controla quando ocorreu a ultima troca de senha. O que pam_ldap est tentando fazer simplesmente atualizar o atributo com uma nova data/hora, pois est ocorrendo uma troca de senha. Como esta operao realizada com os privilgios do prprio usurio, e no administrador, precisamos acrescentar este atributo lista de atributos modificveis pelo prprio usurio: Trecho /etc/openldap/slapd.conf:
access to attrs=userPassword by anonymous auth by self write by * none access to attrs=shadowLastChange by self write by * read

4.3.2.2 Troca de Senha pelo root

Quando um usurio executa o comando passwd para trocar sua senha, normal e correto para o sistema pedir antes a senha atual para ter certeza que o prprio usurio que est

56

LDAP LDAP executando a operao. Este passo desnecessrio caso seja o administrador trocando a senha do usurio. No caso de autenticao via LDAP (ou qualquer outra base remota de usurios), ser root na mquina local no significa nada para o servidor. Isto provoca a seguinte situao quando o root tenta trocar a senha de um usurio:
# passwd carlos changing password for user carlos. Enter login(LDAP) password: ops, precisamos da senha atual do usurio! New password: Retype new password: LDAP password information changed for carlos Password: all authentication tokens updated successfully.

Ou seja, se formos utilizar o comando passwd (e, portanto, o mdulo pam_ldap) para trocar a senha do usurio, precisamos da senha atual dele, o que pouco provvel que venhamos a ter. H duas solues: utilizar algum outro programa para trocar a senha do usurio (como ldappasswd, por exemplo, utilizando as credenciais de administrador do diretrio) ou fazer uma mudana de configurao para que pam_ldap se autentique como administrador do diretrio quando for realizar a mudana de senha. A segunda alternativa implica na seguinte mudana (destaca em negrito) no arquivo de configurao do pam_ldap: /etc/ldap.conf:
Host 192.168.1.1 base dc=exemplo,dc=com,dc=br nss_base_passwd ou=Pessoas,dc=exemplo,dc=com,dc=br?one nss_base_shadow ou=Pessoas,dc=exemplo,dc=com,dc=br?one nss_base_group ou=Group,dc=exemplo,dc=com,dc=br?one ssl no pam_password md5 rootbinddn cn=manager,dc=exemplo,dc=com,dc=br

Agora pam_ldap muda seu comportamento caso esteja sendo executado como root local: utilizar as credenciais indicadas em rootbinddn para se autentica no diretrio, ignorando as credenciais do usurio. Detalhe: precisamos armazenar a senha associada a rootbinddn em um arquivo local. OBS: Este mtodo utiliza autenticao simples, e no SASL. A senha utilizada com a credencial rootbinddn fica armazenada em /etc/ldap.secret e este arquivo deve obrigatoriamente ter permisses 0600 e dono e grupo root: /etc/ldap.secret:
senhasecreta

57

LDAP LDAP Agora, sempre que root executar o comando passwd carlos", por exemplo, sero usadas as credenciais rootbinddn e a senha contida em /etc/ldap.secret para utilizao no diretrio:
# passwd carlos Changing password for user carlos New password: pediu a senha nova diretamente Retype new password: LDAP password information changes for carlos passwd: allauthentication tokens updated successfully.

O log do servidor comprova a mudana de comportamento: /var/log/ldap/ldap.log:

(...) slapd[13698]: conn=19 slapd[13698]: conn=19 mech=SIMPLE ssf=0 slapd[13698]: conn=19 slapd[13698]: conn=19 filter="(uid=carlos)" slapd[13698]: conn=19 slapd[13698]: conn=19 slapd[13698]: conn=19 slapd[13698]: conn=19 slapd[13698]: conn=19 slapd[13698]: conn=19 slapd[13698]: conn=19 slapd[13698]: conn=19 (...) op=0 BIND dn="cn=manager,dc=exemplo,dc=com,dc=br" method=128 op=0 BIND dn="cn=Manager,dc=exemplo,dc=com,dc=br" op=0 RESULT tag=97 err=0 text= op=1 SRCH base="ou=Pessoas,dc=exemplo,dc=com,dc=br" scope=1 op=1 op=2 op=2 op=2 op=3 op=2 op=3 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= MOD dn="uid=carlos,ou=Pessoas,dc=exemplo,dc=com,dc=br" MOD attr=userPassword RESULT tag=103 err=0 text= MOD dn="uid=carlos,ou=Pessoas,dc=exemplo,dc=com,dc=br" RESULT tag=103 err=0 text= MOD attr=shadowLastChange RESULT tag=103 err=0 text=

A diretiva rootbinddn no utilizada somente pelo pam_ldap: nss_ldap tambm a utiliza sempre que o processo estiver sendo executado com privilgios de root. Note que, apesar do nome, a diretiva rootbinddn no precisa necessariamente conter o DN do administrador do diretrio: pode ser outra entidade qualquer. Basta que ela tenha direitos de escrita sobre atributo userPassword e shadowLastChange alm de, claro, ter direitos de leitura apropriados sobre o diretrio, caso contrrio o usurio root local no conseguir mais realizar nenhuma consulta ou pesquisa.

4.4 Scripts
Saber lidar com os atributos e classes de objetos diretamente no diretrio essencial para o administrador. Sem este conhecimento, no adianta partir para ferramentas mais avanadas de gerenciamento de usurios, pois no entender como ecas funcionam nem suas limitaes. Uma vez que j passamos pela etapa de criar usurios e grupos manualmente no diretrio e fazer o sistema reconhec-los e inclusive autentic-los, podemos comear a analisar algumas ferramentas disponveis para as tarefas mais repetitivas ou mais demoradas de manuteno de diretrios LDAP. Um pacote de ferramentas bastante til o Migration Tools. Este pacote possui scripts em Perl para migrao de usurios e grupos do sistema para um servidor LDAP utilizando como

58

LDAP LDAP padro a RFC2307 (no a RFC2307bis). No Linux, o Migration Tools est disponvel no pacote migrationtools. Neste pacote, temos dois tipos de scripts divididos quanto a forma da migrao: com o servidor LDAP iniciado (os scripts utilizam ldapadd ento) ou parado (os scripts usam slapadd, mais rpido). Todos os arquivos so instalados sob o diretrio /usr/share/migrationtools. Existem scripts isolados para cada tarefa: um para migrar grupos, outro para migrar grupos, outro para migrar usurios, mais um para servios (/etc/services) e assim por diante. Alm destes scripts especficos, existe ainda um script geral que os chama individualmente e efetua, portanto a migrao completa. Os scripts principais e sua funo esto definidos na tabela a seguir: Script em /usr/share/migrationtools migrate_common.ph migrate_base.pl migrate_password.pl <arquivo> migrate_group.pl <arquivo> migrate_all_offline.sh migrate_all_online.sh Funo Configurao do Migration Tools Cria a estrutura bsica da rvore (topo, unidades para armazenar grupos, pessoas, etc.) Migra os usurios do arquivo indicado, normalmente /etc/passwd. Tambm l /etc/shadow se este existir. Migra as informaes do arquivo indicado, normalmente /etc/group Realiza migraes offline de todas as informaes Realiza migrao online de todas as informaes

OBS: todos os scripts de migrao precisam ser sempre executados a partir do diretrio de instalao: /usr/share/migrationtools. O arquivo de configurao /usr/share/migrationtools/migrate_common.ph na verdade um trecho de um script Perl que includo por todos os outros scripts. A tabela a seguir lista as variveis que podem ser definidas: Varivel de migrate_common.ph $DEFAULT_MAIL_DOMAIN $DEFAULT_BASE $DEFAULT_MAIL_HOST $EXTENDED_SCHEMA Descrio Domnio para endereos de e-mail. Tambm utilizado para domnio Kerberos. Base padro do LDAP. Ser o topo da arvore. Servidor de correio eletnico (SMTP) padro. Se definido em 1, utilizar classes derivadas de person. Caso contrario ser utilizada a combinao account e posixAccount.

Por exemplo, vamos definir as variveis de configurao da seguinte forma:

$DEFAULT_MAIL_DOMAIN = exemplo.com.br; $DEFAULT_BASE = dc=exemplo,dc=com,dc=br; $DEFAULT_MAIL_HOST = smtp.exemplo.com.br; $EXTENDED_SCHEMA = 0;

Trechos de /usr/share/migrationtools/migrate_common.ph OBS: necessrio exportar a varivel de ambiente ETC_SHADOW (export ETC_SHADOW=/etc/shadow) para que o migrate_passwd migre tambm as senhas do shadow.

59

LDAP LDAP
# ./migrate_passwd.pl /etc/passwd dn:uid=marcelo,ou=People,dc=exemplo,dc=com,dc=br
uid: marcelo cn: Marcelo Soares objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword: {crypt}$1$YnTa4Rjt$sNOcuN.77C/7q62gUU2Ry1 shadowLastChange: 12695 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 19421 gidNumber: 19421 homeDirectory: /home/marcelo gecos: Marcelo Soares dn: (...)

Existindo algum usurio no sistema com cdigo de identificao (uid) maior ou igual a 500, a sada do script migrate_passwd.pl ser semelhante a seguinte, podendo naturalmente ter mais usurios (exemplo para um usurio chamado Marcelo Soares):
# ./migrate_passwd.pl /etc/passwd dn:uid=marcelo,ou=People,dc=exemplo,dc=com,dc=br
uid: marcelo cn: Marcelo Soares givenName: Marcelo sn: Soares mail: marcelo@exemplo.com.br mailRoutingAddress: marcelo@smtp.exemplo.com.br mailHost: smtp.exemplo.com.br objectclass: inetLocalMailRecipient objectClass:person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: krb5Principal objectClass: shadowAccount userPassword: {crypt}$1$YnTa4Rjt$sNOcuN.77C/7q62gUU2Ry1 shadowLastChange: 12695 shadowMax: 99999 shadowWarning: 7 krb5PrincipalName: marcelo@EXEMPLO.COM>BR loginShell: /bin/bash uidNumber: 19421 gidNumber: 19421 homeDirectory: /home/marcelo gecos: Marcelo Soares dn: (...)

Agora, se a varivel $EXTENDED_SCHEMA for trocada para 1, os atributos dos usurios mudaro: Temos vrias classes novas, e esta entrada est pronta para ser inserida no diretrio. Note tambm que estes scripts de migrao utilizam nomes em ingls para os ramos de pessoas (e grupos tambm, e vrios outros). Portanto, temos ou=People ao invs de ou=Pessoas como temos visto nos exemplos at aqui. Se isto vai ser relevante ou no

60

LDAP LDAP depender das aplicaes que acessam o diretrio. Normalmente no h problemas, pois o nome em portugus foi utilizado na DN, e no no nome do atributo. A migrao mnima necessria conste na execuo dos seguintes scripts: migrate_base.pl: ir gerar um arquivo LDIF com a estrutura da arvore com o topo e as unidades organizacionais para manter contas de pessoas, grupos, nomes de hosts, etc. migrate_passwd.lp: ir gerar um arquivo LDIF as contas de pessoas sob ou=People. Migrate_group.pl: ir gerar um arquivo LDIF as definies de grupos sob ou=Groups. Dependendo da verso do Migration Tools, pode haver problemas com estruturas contendo trs ou mais componentes no topo da arvore. Por exemplo,
# ./migrate_base.pl dn: dc=com,dc=br dc: com no incluir esta dn:

objectClass: top objectClass: domain objectClass: domainRelatedObject associatedDomain: exemplo.com.br

dn: dc=exemplo,dc=com,dc=br dc: exemplo

objectClass: top objectClass: domain objectClass: domainRelatedObject associatedDomain: exemplo.com.br dn: ou=Hosts,dc=exemplo,dc=com,dc-br (...)

incluir somente a partir daqui

dc=exemplo,dc=com,dc=br. O script migrate_base.pl vai criar primeiro dc=com,dc=br e somente depois dc=exemplo, quando deveria na verdade criar somente a entrada completa. Neste caso, basta suprimir a primeira dn: retomada pelo script. Por exemplo:

4.4.1 O problema do uidNumber e gidNumber

Criar entradas para usurios e grupos no diretrio realmente no difcil, basta escolher os atributos e as classes mais apropriadas e gerar o arquivo LDIF. O problema maior que se costuma enfrentar na escolha dos indicadores numricos de usurios e grupos. Estes identificadores devem ser nicos no diretrio, e o OpenLDAP no possui um atributo de incremento automtico como algumas bases de dados tradicionais, necessrio algum mecanismo para localizar o prximo identificador livre e utiliz-lo automaticamente para tirar esta tarefa do administrador. Afinal, localizar identificadores numricos para usurios e grupos realmente no um tarefa para uma pessoa, mas sim para uma maquina. Uma alternativa varrer o diretrio inteiro listando todos os identificadores e procurando alguma vaga. Infelizmente esta sada no muito pratica para diretrios grandes, sendo lenta. Alm disso, provoca a reutilizao de identificadores antigos que passaram a ficar livres, o que pode no ser interessante.

61

LDAP LDAP

O que alguns scripts acabam fazendo armazenar no diretrio em um atributo especial os valores dos prximos uidNumber e gidNumber livres. Assim, quando o script cria um usurio novo, obtm os identificadores necessrios a partir destes atributos e tambm os incrementa, sinalizando os prximos valores livres. O nico problema com esta soluo que ela obriga toda a criao e remoo de usurios a ser feita atravs desta ferramenta de forma que estes atributos especiais sejam atualizados. Mesmo assim esta parece ser a melhor soluo por enquanto.

4.5 Dicas
Nem sempre necessrio utilizar nss_ldap em conjunto com autenticao de usurios. Este mdulo somente precisa ser utilizado se for necessrio para o sistema reconhecer estes usurios. Por exemplo, a utilizao de autenticao LDAP no Apache para controlar acesso a um certo diretrio normalmente no precisa do nss_ldap, pois o Apache somente est interessado na senha, no precisando saber o diretrio home do usurio, seu uidNumber, etc. possvel realizar autenticao de usurios sem a utilizao do mdulo pam_ldap. Se o atributo da senha (userPassword) estiver disponvel para todos os usurios, inclusive os annimos, a autenticao funcionar tambm com o mdulo pam_unix tradicional (e tambm em sistemas que no utilizam PAM, como Slackware). Este cenrio o equivalente ao das senhas estarem armazenadas no arquivo /etc/passwd e no no /etc/shadow. nscd um daemon que realiza cach de consultas feitas via NSS. Este servio pode acelerar bastante o sistema, mas tambm pode atrapalhar. Em situaes de depurao, deve ser sempre desligado, pois o cach demora alguns minutos para ser atualizado e ir dar informaes falsas. Se algo no estiver funcionando, analise os logs do servidor OpenLDAP. Todas as informaes necessrias para a depurao do problema estaro l, como qual a consulta que foi feita, que atributos foram pesquisados, se falta algum ndice, como foi feita a autenticao, etc. LDAP no faz mgica: simplesmente uma forma de acesso a um diretrio. No s isso que vai fazer com que todos os sistemas da sua rede miraculosamente comecem a se comunicar entre si. As informaes armazenadas no diretrio
echo $(($(date "+%s")/86400))

precisam estar corretas e de acordo com o que cada sistema espera encontrar. Vrios dos atributos shadow utilizam o nmero de dias deste 01/JAN/1970. Para obter rapidamente a data de hoje nesta notao, utilize:

4.6 Exerccios
1. Mostre o arquivo LDIF necessrio para criar a seguinte estrutura de grupos posix definida a seguir (considere a base ou=Grupos,dc=exemplo,dc=com,dc=br): grupos administrativo (cdigo 1000), marketing (cdigo 1010) e comercial (cdigo 1020); administrativo possui os seguintes membros: maria e joana; marketing possui os seguintes membros: maria e carlos

62

LDAP LDAP comercial possui os seguintes membros: alexandre, marcos e Cleber

2. Refaa a questo anterior utilizando a notao definida para grupos na RFC2307bis. Considere que os usurios esto em ou=Pessoas, dc=exemplo,dc=com,dc=br e utilizam o atributo uid como RDN.

3. Mostre o arquivo LDIF que cria no diretrio os usurios listados a seguir, utilizando como base ou=Pessoas,dc=exemplo,dc=com,dc=br. O sistema dever reconhecelos como usurios vlidos e eles devero poder se autenticar e logar no sistema. Utilize valores apropriados para os atributos no especificados aqui. No esquea do grupo primrio (utilize como identificador o mesmo valor que para o usurio). Maria da Silva (cdigo 10000) Joana Salgueiro (cdigo 10001)

63

LDAP LDAP

CAPTULO 5

O BACKEND BDB
LDAP apenas um protocolo que conecta o cliente ao servidor. Onde as informaes esto realmente armazenadas dito ser o backend, e BDB o backend mais importante do OpenLDAP. Ao final deste captulo, voc dever ser capaz de:

Melhorar a performance do OpenLDAP Ajustar parmetros importantes do backend BDB Utilizar as ferramentas BDB Dar manuteno ao banco de dados quando necessrio

64

LDAP LDAP

5.1 Backend BDB

O backend BDB utilizado pelo OpenLDAP extremamente importante para o funcionamento do diretrio e merece uma seo parte. de suma importncia conhecer seus principais aspectos de configurao para que se tenha um diretrio rpido, estvel e confivel. BDB possui diversos parmetros de configurao que podem ser ajustados de diversas formas. Veremos aqui as diretivas principais, que afetam a performance e confiabilidade diretamente.

5.2 O Arquivo DB_CONFIG

Os principais parmetros de configurao do BDB podem ser ajustados em um arquivo de nome DB_CONFIG localizado no mesmo diretrio do banco de dados. No caso do OpenLDAP, o arquivo ficar no diretrio especificado na diretiva directory do arquivo /etc/openldap/slapd.conf, sendo que seu valor padro /var/lib/ldap/. Os pacotes do Linux j possuem um arquivo DB_CONFIG de exemplo neste diretrio, mas esta configurao no faz parte do OpenLDAP padro. A configurao de exemplo e uma explicao sobre os parmetros est a seguir:
# Sample BDB configuration file. # This configuration file sets BerkeleyDB options when using the bdb #backend, for the database held in the directory where this file resides # # Please see the OpenLDAP FAQ-O-Matic # (http://www.openldap.org/faq/data/cache/893.html) and the Barkeley DB # documentation (http://www.sleepycat.com/docs/ref/env/db_config.html) # for more information on the settings available # # Set directory to use for transaction logs: #set_lg_dir /var/lib/ldap/logs # Set in memory transaction log cache (2MB) set_lg_bsize 2097152
$ Set max transaction log file size, must be >=4* lg_bsize (10MB) set_lg_max 10485760 # Set in-memory database cache set_cachesize 0 1048576 0 # For batch imports, disabling transaction logging totally can dramatically # improve performance: # set_flags DB_TXN_NOT_DURABLE

set_cachesize gigabytes bytes nmero-de-caches Uso: tamanho do cach Exemplo: set_cachesize 0 1048576 1 configura 1Mbyte de cach Descrio: esta diretiva ajusta o tamanho do cach em memria RAM que o backend far dos dados. Isto acelera bastante as leituras no diretrio e at as escritas e de crucial importncia que seja bem ajustado. Atravs da ferramenta db_stat executada no diretrio do banco de dados ou no bastando verificar o percentual de hits:

65

LDAP LDAP
# db_stat m | grep % 1566 Requested pages 455 Requested pages 335 Requested pages 495 Requested pages 195 Requested pages 38 Requested pages 48 Requested pages found found found found found found found in in in in in in in the the the the the the the cache cache cache cache cache cache cache (98%). (99%). (99%). (99%). (99%). (95%). (96%).

A ferramenta mostra diversas outras informaes, naturalmente. Neste momento, a que nos interessa a do aproveitamento do cache. Valores acima de 90 ou 95% so considerados muito bons j. Valores menores indicam que o sistema poderia ter um aproveitamento melhor se o cach for aumentado. medida que a base de dados for aumentando, o valor de cach deve ser aumentado tambm para manter a performance. OBS: A configurao do cach de extrema importncia para uma boa performance do OpenLDAP! set_lg_bsize bytes Uso: tamanho do buffer de escrita para o log de transaes Exemplo: "set_lg_bsize 1048576" configura 1Mbyte para buffer de log de transaes Descrio: o banco de dados BDB possui o recurso de transaes que utiliza um arquivo de log onde as transaes feitas ficam armazenadas. O parmetro set_lg_bsize controla o tamanho em memria do buffer que armazena as transaes enquando eles no so gravadas em disco. O valor padro deste parmetro, 32Kbytes, insulficiente para uma boa operao do OpenLDAP; OBS: A configurao do buffer de extrema importncia para uma boa performance do OpenLDAP! set_lg_dir /diretrio/arquivos/log/ Uso: nome do diretrio onde ficaro os arquivos de log de transaes Exemplo: "set_lg_dir /var/lib/ldap/logs Descrio: os arquivos de log de transaes so por padro criados no mesmo diretrio do banco de dados e possuem o nome no formato log.numero-sequencial. Por exemplo: Como criao e utilizao dos arquivos de log de transaes gera muito I/O
# l /var/lib/ldap/ total 362 drwx-----2 ldap ldap drwxr-xr-x 17 root root -rw-r--r-1 ldap ldap -rw------1 ldap ldap -rw------1 ldap ldap -rw------1 ldap ldap -rw------1 ldap ldap -rw------1 ldap ldap -rw------1 ldap ldap -rw------1 ldap ldap -rw------1 ldap ldap -rw------1 ldap ldap -rw------1 ldap ldap -rw------1 ldap ldap -rw------1 ldap ldap

416 456 1023 8192 1318912 1114112 368640 16384 20480 8192 32768 197778 20480 20480 20480

2004-09-28 14:57 ./ 2004-09-27 17:17 ./ 2004-09-28 14:57 DB_CONFIG 2004-09-28 14:57 __db.001 2004-09-28 14:57 __db.002 2004-09-28 14:57 __db.003 2004-09-28 14:57 __db.004 2004-09-28 14:57 __db.005 2004-09-28 12:25 cn.bdb 2004-09-28 14:57 dn2id.bdb 2004-09-28 14:57 id2entry.bdb 2004-09-28 14:57 log.0000000001 log de transaes 2004-09-28 12:25 objectClass.bdb 2004-09-27 16:36 sn.bdb 2004-09-27 16:36 telephoneNumber.bdb
66

LDAP LDAP (Entradas/Sadas) de disco, podemos usar esta diretiva para criar estes arquivos em outro disco, o que deve acelerar significativamente o servidor LDAP. Assim, o banco de dados fica armazenado em um disco e os arquivos de log de transaes em outro; set_lg_max bytes Uso: especificar tamanho mximo do arquivo de log de transao Exemplo: set_lg_max 20971520 configura um tamanho mximo de 20Mbytes Descrio: este parmetro especifica um tamanho mximo para o arquivo de log de transao. O valor padro de 10Mbytes, podendo ser aumentado caso hajam muitas escritas no diretrio, o que geraria vrios arquivos deste tamanho. Quando o tamanho mximo atingido, um novo arquivo criado automaticamente aumentando-se o numero seqencial. Com um numero maior, menos arquivos de log de transao sero criados, mas eles sero maiores. apenas necessrio que este valor seja no mnimo quatro vezes maior que o valor do parmetro set_lg_bsize. Para que estas alteraes tenham efeito, necessrio parar o servidor ldap e executar o comando db_recover no diretrio do banco de dados. Isto ar destruir o cach j acumulado at ento, mas necessrio (a opo -v ativa o modo detalhado):
# cd /var/lib/ldap # db_recover v db_recover: Finding last valid log LSN: file: 1 offset 198005 db_recover: Recovery starting from [1][197864] db_recover: Recovery complete at Tue Sep 28 15:09:20 2004 db_recover: Maximum transaction ID 80000002 Recovery checkpoint [1][198005]

Nem todas as alteraes no arquivo DB_CONFIG necessitam desta operao: a documentao do BDB dever ser consultada para mais detalhes.

5.3 Ferramentas DB
J vimos brevemente a utilizao da ferramenta db_recoveer, e agora chegou o momento de analisarmos os outros programas disponveis para lidar com o banco de dados BDB. As ferramentas esto todas disponveis no pacote db42-utils e so: Programa db_archive db_checkpoint db_deadlock db_dump db_load db_printlog db_recover db_stat db_upgrade db_verify Descrio Manipulao de arquivos de log de transao Fora checkpoint peridico Conserta situaes de deadlock Faz um dump da base de dados (sida texto) Importa um dump previamente feito Mostra o contedo dos arquivos de log de transao Recuperao da base de dados Estatsticas da base de dados Atualizao da base de dados Verificao da base de dados

67

LDAP LDAP importante para o administrador do diretrio conhecer todas estas ferramentas, mas as mais importantes so db_archive, db_recover e db_stat. A documentao de cada uma delas tambm est includa no pacote db42-utils.

5.3.1 db_archive
Durante a operao normal do diretrio so gerados registros de transaes que ficam armazenados nos chamados arquivos de log de transao. Quando este arquivo de log atinge seu tamanho Maximo (conforme definido em set_lg_max), um arquivo novo criado e o antigo deixado de lado no disco. Dependendo da atividade do diretrio, dezenas de arquivos de log de transao podem permanecer no disco em pouco tempo. O programa db_archive nos permite lidar com estes arquivos de log e decidir quais j podem ser apagados e quais ainda esto em uso pelo banco de dados contendo transaes no commitadas ainda. Arquivos de log que no estiverem mais em uso podem ser apagados se for necessrio: sua utilidade se resume agora apenas situao de recuperao catastrfica da base. Portanto, pode ser til fazer um backup destes arquivos em algum outro lugar, mas no so mais necessrios para a operao normal do sistema. Para listar os arquivos de log que no esto mais em uso basta executar o programa dentro do diretrio da base de dados, ou utilizar o parmetro h para indicar um diretrio. Se nada for retornado, ento todos os arquivos de log esto em uso ainda. Por exemplo:
# db_archive h /var/lib/ldap/ #

Todos os arquivos de log em uso

# db_archive h /var/lib/ldap/ log.0000008532 log.0000008533

Os arquivos log.0000008532 e log.0000008533 no esto mais em uso, podendo ser ou apagados ou movidos para algum backup Tabela de opes de comando: db_archive [opes] -a Todos os diretrios sero mostrados como absolutos, e no relativos ao diretrio do banco de dados. -d Remoo automtica dos arquivos de log que no esto mais em uso. -h Indica o diretrio do banco de dados. Se no estiver presente, assumir que <diretrio> o banco de dados est no diretrio corrente. -l Lista todos os arquivos de log, inclusive os que ainda esto em uso. O programa db_archive pode ser usado sem problemas mesmo com o servio LDAP em execuo.

5.3.2 db_recover
O programa db_recover utilizado para recuperar a base de dados de algum problema que tenha ocorrido. H duas formas de utilizao:

68

LDAP LDAP Recuperao normal

# db_stat m h /var/lib/ldap/ 1MB 257kb 604B Total cache size. 1 Number of caches. 1MB 264kb Pool individual cache size. 0 Requested pages mapped into the progress' adderss space. 39 Requested pages found in the cache (91%). eficiencia do cache 4 Requested pages not found in the cache. 0 Pages create in the cache. 4 Pages read into the cache. 0 Pages written from the cache to the backing file. 0 Clean pages forced from the cache. (...)

Recuperao catastrfica
# service ldap stop Desligando ldap: [ok] # db_recover v h /var/lib/ldap db_recover: Finding last valid log LSN: file: 1 offset 456697 db_recover: Recovery starting from [1][456556] db_recover: Recovery complete at Tue Sep 28 18:35:05 2004 db_recover: Maximum transaction ID 800000db Recovery checkpoint [1][456697]

A recuperao catastrfica somente possvel caso todos os arquivos de log de transao estiverem disponveis, mesmo aqueles que no esto mais em uso. Esta recuperao demorada e no h garantias que v ter sucesso. As principais opes de utilizao do db_recover so: /usr/bin/db_recover [opes] Ativa modo detalhado (verbose) Realiza recuperao catastrfica Indica o diretrio em disco onde est a base de dados

-v -c -h <diretrio>

crucial que o servio LDAP esteja desativado antes de se executar a recuperao da base de dados, seja ela normal ou catastrfica. exemplo: Aps a execuo do comando, o ambiente da base de dados ser recriado, tendo como efeito colateral a aplicao de todas as diretivas do arquivo DB_CONFIG e a remoo do cach. Utilizar db_recover, por exemplo, a nica forma de se aplicar uma mudana no tamanho do cach feita no arquivo DB_CONFIG. Recomenda-se que os administradores responsveis pelo OpenLDAP leiam atentamente a documentao sobre backups (inclusive backup a quente, sem parar o servio) e recuperao de bases de dados disponvel no site da Sleepy Cat em http://sleepycat.com/docs/ref/toc.html.

5.3.3 db_stat
A ferramenta db_stat fornece uma srie de estatsticas sobre o banco de dados que so principalmente teis para fazer ajustes de performance. A medida mais importante e mais comumente utilizada a da eficincia do cach e obtida com a opo -m:

69

LDAP LDAP Valores acima de 90% geralmente so bons. Se houver mais memria disponvel na maquina, o cach pode ser aumentado um pouco mesmo neste caso. Chega um momento, no entanto, onde a performance no mais aumentada com um cach maior. Neste caso, chegou-se ao valor mximo para esta combinao particular de hardware e software. Da mesma forma que todas as outras ferramentas do Berkeley DB, esta tambm aceita o parmetro -h para indicar o diretrio da base de dados. Outras opes usadas com menos freqncia podem ser consultadas na documentao disponvel no pacote db42-utils.

5.4 Checkpoint Peridico

O backend BDB precisa ser configurado para realizar uma operao de checkpoint peridica na base de dados. Isto aumenta em muito a recuperabilidade da base caso ocorra uma situao inesperada de falta de energia, por exemplo, ou algum outro tipo de pane onde os dados podem no ter sido gravados em disco ainda. Esta operao pode ser feita manualmente atravs do programa db_checkpoint, mas o correto configur-la no prprio OpenLDAP no seu arquivo de configurao: /etc/openldap/slapd.conf:
include include include include pidfile argsfile database suffix rootdn rootpw directory /usr/share/openldap/schema/core.schema /usr/share/openldap/schema/cosine.schema /usr/share/openldap/schema/inetorgperson.schema /usr/share/openldap/schema/nis.schema /var/run/ldap/slapd.pid /var/run/ldap/slapd.args bdb dc=exemplo,dc=exemplo,dc=br" cn=Manager,dc=exemplo,dc=com,dc=br" {SSHA}pzp96ZACsCrWbeos2D4ujmGvKRyJFQiY /var/lib/ldap

# checkpoint <kbyte> <minutos> checkpoint 512 10 index objectClass eq index sn,cn eq,sub,approx index telephoneNumber eq,sub access to by by by access to by attrs=userPassword anonymous auth self write * none * * read

# DN de autenticao SASL: uid=<usuario>,[cn=realm,]cn=<mecanismo>,cn=auth sasl-regexp id=([^,]+),cn=digest-md5,cn=auth$ cn=auth$ cn=$1,ou=Pessoas,dc=exemplo,dc=com,dc=br

A diretiva checkpoint aceita dois parmetros: um tamanho em kbytes e um tempo em minutos. O checkpoint ser feito a cada <kbytes> escritos <minutos> passados desde o ultimo checkpoint, o que ocorre antes. OBS: Esta verificao somente feita no momento da prxima escrita. Uma forma de forar esta verificao periodicamente utilizando db_checkpoint no modo daemon. Operaes de checkpoint muito freqentes podem diminuir o risco de perda de dados, mas tambm diminuem a performance do diretrio. O valor sugerido no exemplo, 512kbytes ou dez minutos, pode ser exagerado ou muito pouco dependendo da utilizao do diretrio.

70

LDAP LDAP Apenas a pratica vai dizer. A regra geral : quanto mais escritas forem feitas no diretrio, mais freqente deve ser o checkpoint para que o risco de perda de dados seja diminudo.

5.5 Dicas
A documentao do backend BDB pode, primeira vista, parecer muito orientada a programadores e desenvolvedores, mas mesmo assim deve ser lida por administradores por conter muitas informaes teis. No despreze a configurao do backend BDB: seu diretrio agradece. Verifique periodicamente a utilizao do cache do seu servidor com db_stat m, em particular se a performance do diretrio estiver caindo. No esquea de remover os arquivos de log de transao antigos, seja apagando-os fazendo backup. Eles podem ocupar bastante espao em disco. No esquea de executar db_recover aps alterar o valor do cache no arquivo DB_CONFIG, caso contrario a alterao no ter efeito.

5.6 Exerccios
1. Qual a configurao a ser utilizada no arquivo DB_CONFIG para utilizar 900Mbytes de cache? E 1,5Gbytes?

71

LDAP LDAP 2. Analisando a sada dos comandos seguintes, quais os arquivos de log de transao que no esto mais em uso?
# db_archive ah /var/lib/ldap/ /var/lib/ldap/log.0000000001 /var/lib/ldap/log.0000000002 /var/lib/ldap/log.0000000003 /var/lib/ldap/log.0000000004 # db_archive alh /var/lib/ldap/ /var/lib/ldap/log.0000000001 /var/lib/ldap/log.0000000002 /var/lib/ldap/log.0000000003 /var/lib/ldap/log.0000000004 /var/lib/ldap/log.0000000005 /var/lib/ldap/log.0000000006

72

LDAP LDAP

CAPTULO 6

CRIPTOGRAFIA
O diretrio, como qualquer banco de dados, pode conter informaes sigilosas e de acesso restrito. J vimos como ACLs podem proteger essas informaes, mas e quanto ao trafego ate a maquina cliente? Ao final deste capitulo, voc dever ser capaz de: Instalar certificados digitais no servidor LDAP Utilizar uma conexo criptografada Detectar e resolver os problemas mais comuns

73

LDAP LDAP

6.1 Criptografia
OpenLDAP, atravs do uso da biblioteca OpenSSL, suporta o uso de criptografia para proteger o trafego de dados entre o cliente e o servidor. Esta criptografia afeta a conexo inteira, e no apenas a etapa da autenticao como alguns mecanismos SASL. H duas formas de utilizao deste recurso no OpenLDAP, atravs do protocolo ldaps:// (LDAP sobre TLS, porta 636/tcp) ou atravs do uso da extenso START TLS na porta normal do LDAP (389).

6.2 Instalando os Certificados

A configurao do servidor OpenLDAP para o uso de criptografia nas conexes feita no arquivo slap.conf atravs das diretivas listadas a seguir: Diretiva TLSCertificateFile <arquivo> TLSCertificateKeyFile <arquivo> Descrio Arquivo contendo o certificado do servidor Arquivo contendo a chave privada do servidor relacionada com o seu certificado

Um exemplo de configurao mostrado a seguir, com as entradas novas destacadas em negrito: Trecho de /etc/openldap/slapd.conf:
(...) pidfile argsfile /var/run/ldap/slapd.pid /var/run/ldap/slapd.args

TLSCertificateFile /etc/ssl/OPENLDAP/ldap.pem TLSCertificateKeyFile /etc/ssl/openldap/ldap.key database bdb suffix dc=exemplo,dc=exemplo,dc=br" rootdn cn=Manager,dc=exemplo,dc=com,dc=br" (...)

importante que a chave privada no esteja criptografada, caso contrrio o servidor LDAP no funcionar. Alm disto, este arquivo deve ter permisses bem restritas para que somente o usurio ldap possa ler seu contedo. Por exemplo:
-rw-r----- 1 root ldap 887 2004-09-29 16:30 /etc/ssl/openldap/ldap.key

A partir deste momento, assim que o servidor LDAP for reiniciado o suporte a START TLS j estar automaticamente ativado. Mas utilizar ldaps://, um passo adicional de configurao necessrio: /etc/svsconfig/ldap:
(...) # SLAP URL list SLAPDURLLIST="ldap:/// ldaps:///" (...)

74

LDAP LDAP Aps desconectar a linha SLAPDURLLIST e reiniciar o servio, o protocolo ldaps:// estar disponvel.

6.3 Testando Acesso

O acesso criptografado ao diretrio atravs do protocolo LDAP pode ser testado das ferramentas do pacote openldap-clients. A utilizao de START TLS na conexo controlada pelo parmetro -Z. Se utilizado duas vezes, a criptografia ser considerada absolutamente necessria e o comando falhar se ela no estiver disponvel. O exemplo seguinte utiliza START TLS para proteger a autenticao simples e obter o atributo userPasswd:
$ ldapsearch LLL ZZ x D cn=Benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br W cn=benjamin userPassword Enter LDAP Password: dn: cn=Benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br userPassword: e1NTSEF9NURtRlJkUS9sUjA2Ry96NDFSRSswczB6b3JWM05mTLE=

Este comando funcionar mesmo que tenhamos a restrio ssf=56 de acesso ao atributo userPassword como foi visto em um dos exemplos anteriores, pois agora a conexo est protegida por criptografia. Para repetirmos a pesquisa mas utilizando ldaps://, utilizamos o parmetro H:
$ ldapsearch LLL H ldaps://servidor.ldap x D cn=benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br W cn=benjamin userPassword Enter LDAP Password: dn: cn=Benjamin,ou=Pessoas,dc=exemplo,dc=com,dc=br userPassword:: e1NTSEF9NURtRlJkUjA2y96NDFSswczB6b3JWM05mTLE=

6.4 Problemas Comuns

PKI (Public Key Infrastructure) reconhecidamente no um dos tpicos mais simples. Os trs problemas mais comuns so: Autoridade Certificadora desconhecida: o cliente precisa confiar na AC, que assinou o certificado do servidor; Nome do servidor incorreto no certificado: o atributo commonName (ou subjectAltName caso o servidor tenha mais de um nome) precisa conter o nome completo (FQDN) do servidor LDAP; Certificado fora do prazo de validade: cada certificado possui prazos de validade bem especficos e vlido fora destes prazos. Vamos exemplificar estes problemas criando um certificado auto-assinado para o nosso servidor. O comando seguinte cria um certificado deste tipo:
# openssl req new x509 nodes days 365 out /etc/openldap/ldap.pem keyout /etc/ssl/openldap/ldap.key Generating a 1024 bit RSA private key ...........++++++ ..........++++++ Wrinting new private key to /etc/ssl/openldap/ldap.key ----75

LDAP LDAP
You are about to be asked to enter information that will be incorporated Into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can some blank For some fields there will be a default value, If you enter ., the field will be left blak. ----Country Name (2 letter code) [AU]:BR State or Province Name (full name) [Some-State]:PR Locality Name (eg,city) []:Curitiba Organization Name (eg, company) [Internet Widgits Pty Ltd]:Exemplo Ltda Organizational Unit Name (eg, section) []:Intranet Common Name (eg, YOUR name) []:ldap.exemplo Email Address []:ca@exemplo.com.br

Uma vez com os arquivos do certificado instalados e o servidor LDAP reiniciado, vamos tentar novamente nossa pesquisa com START TLS:
$ ldapsearch LLL ZZ x D cn=benjamin,ou=pessoas,dc=exemplo,dc=com,dc=br W cn=benjamin userPassword ldap_start_tls: Connect error (91) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Ok, o programa nos avisou que h problemas com o certificado dizendo que ele no passou nos testes de verificao. Para analisarmos a causa do problema vamos acrescentar uma opo de debug mximo (-d -1). A sada ser bem mais longa, mas perto do final teremos a informao que nos interessa (destacada em negrito):
$ ldapsearch LLL ZZ x D cn=benjamin,ou=pessoas,dc=exemplo,dc=com,dc=br W cn=benjamin userPassword ldap_create ldap_extended_operation_s ldap_extended_operation (...) TLS certificate verification: Error, self signed certificate auto-assinado! tls_write? Want=7, written=7 0000? 15 03 01 00 02 02 30 TLS trace: SSL3 alert write:fatal:unknown CA Autoridade Certificadora desconhecida! TLS trace: SSL_connect:error in SSLv3 read Server certificate B TLS trace: SSL_connect:error in SSLv3 read Server certificate B TLS: cant connect. ldap_perror ldap_start tls: Connect error (91) additional info: error:14090086:SSL routines:SSL3 GET SERVER CERTIFICATE:certificate verify failed

Foram detectados dois problemas cuja causa uma s: a autoridade certificadora que emitiu o certificado do servidor desconhecida pelo cliente. Este problema resolvido copiando-se o certificado da AC para a mquina cliente. Como um certificado auto-assinado neste caso, o arquivo em questo o /etc/ssl/openldap/ldap.pem. No cliente, configuramos a biblioteca OpenLDAP para utilizar este arquivo como sendo o certificado de uma AC vlida e confivel:

76

LDAP LDAP /etc/openldap/ldap.conf:

BASE dc=exemplo,dc=com,dc=br URI ldap://ldap.server TLS_CACERT /etc/ssl/openldap/ldap.pem

A diretiva TLS_CACERT deve apontar para o arquivo da AC, onde quer que ele esteja. Neste exemplo ele foi copiado para /etc/ssl/openldap. Olhando o /etc/openldap/ldap.conf j podemos prever um outro problema: o nome do servidor LDAP. No certificado, consta ldap.exemplo, e neste arquivo estamos usando ldap.server. Mesmo que ambos tenham o mesmo endereo IP, o que vale o nome utilizado pelo cliente. Vejamos:
$ ldapsearch LLL ZZ x D cn=benjamin,ou=Pessoas,dc=exmplo,dc=com,dc=br W cn=Benjamin userPassword ldap_start_tls: Connect error (-11)

Desta vez no foi necessrio ativar o modo de depurao para identificar o problema.
$ ldapsearch LLL ZZ x D cn=benjamin,ou=Pessoas,dc=exmplo,dc=com,dc=br W cn=Benjamin userPassword () TLS: hostname (ldap.server) does not match common name in certificate (ldap.exemplo). ldap_start_tls: Connect error (-11) additional info: TLS: hostname does not match CN in peer certificate

Conforme visto o nome que consta no atributo commonName do certificado no bate com o nome utilizado para a conexo. Ou um certificado novo e gerado com o nome correto ou troca-se no DNS para usar o nome do certificado. Para cenrios de teste, e possvel desativar algumas destas verificaes de certificados no lado cliente atravs da diretiva TLS_REQCERT no arquivo de configurao da biblioteca OpenLDAP: /etc/openldap/ldap.conf:
BASE dc=exemplo,dc=com,dc=br URI ldap://ldap.server TLS_REQCERT never TLS_CACERT /etc/ssl/openldap/ldap.pem

H quatro alternativas para este parmetro que controlam a forma como a verificao e feita, indo desde nenhuma verificao ate uma verificao completa: TLS_REQCERT never allow try hard ou demand Descrio Nenhuma verificacao e feita e qualquer certificado ser aceito Certificados invlidos sero aceitos e o campo CN comparado com nome do servidor. Semelhante ao allow, mas exige um certificado que se for fornecido ser verificado; Todas as verificaes do certificado sero ativadas

77

LDAP LDAP Se colocarmos o valor never neste campo, ate o nosso certificado auto-assinado com o nome errado do servidor ser aceito. Isto so e aceitvel para ambientes de teste.

6.5 Dicas
Somente utilize criptografia na conexo aps ter feito o bsico do diretrio funcionar. Sempre que utilizar o START TLS, sempre utilize a opo ZZ na linha de comando das ferramentas ao invs do Z. Sempre que ocorrer algum problema, refaa a consulta utilizando ldapsearch com a opo debud maximo (-d -1)

6.6 Exerccios
1. Quais so as trs principais verificaes feitas em uma conexo criptografia por SSL ou START TLS?

2. A utilizao de START TLS ou ldaps:// a nica forma de criptografar o trfego da dedos no OpenLDAP utilizando os recursos do prprio OpenLDAP?

78

LDAP LDAP

CAPTULO 7

REPLICAO COM OPENLDAP

A centralizao de informaes em um servidor possui suas vantagens administrativas bem claras. No entanto, muitas coisas passam a depender de uma maquina apenas. A soluo para este problema e instalar servidores adicionais com o mesmo contedo. Ao final deste capitulo, voc devera ser capaz de:

Configurar a replicao entre servidores OpenLDAP Entender o funcionamento da replicao

79

LDAP LDAP

7.1 Topologia de Replicao

Um servidor OpenLDAP pode ser configurado para replicar toda a sua base ou algum ramo especifio dela) para outro servidor OpenLDAP. Esta configurao e conhecida como msterslave. Um servidor OpenLDAP pode ter vrios servidores slaves, mas apenas um mster. A chamada replicao multi-master , aonde h vrios servidores mster, ainda no e suportada. O servidor mster o nico que aceita operaes de escrita na base de dados. Uma vez que alguma alterao e feita, ela e gravada em um arquivo chamado log de replicao. Este arquivo e monitorado por outro processo, chamado de slurpd, que detecta a atividade e trata de enviar as mudanas para servidores slave cadastrados:

Servidor LDAP

Master
SLAPD SLURPD

Servidor LDAP

Alteraes

Slave SLAPD

DB

Log de Replicao

DB

Este log de replicao e praticamente idntico ao formato de arquivo utilizado pelo comando ldapmodify. Os comandos do protocolo LDAP para atualizar a base remota dos servidores slave. Uma caracterstica importante desta replicao e que ela so envia as diferenas: e necessrio que todas as bases de dados estejam no mesmo estado antes de ativar o mecanismo de replicao, Em outras palavras, e necessrio copiar a base de dados do servidor mster para todos os servidores slave e somente ento iniciar a replicao. Estes so os passos necessrios para configurar a replicao entre um servidor mster e um slave: 1. 2. 3. 4. 5. 6. Configurar o servidor mster Acertar detalhes de autenticao entre mster e slave Configurar o servidor slave Parar o mster e copiar a base de dados do mster para o slave Iniciar o servidor slave Iniciar o servidor mster

7.2 Configurao do Master

Precisamos acrescentar duas diretivas no arquivo de configurao do servidor OpenLDAP. replogfile: indica o arquivo que ser o log de replicao, Este arquivo ser criado pelo daemon slapd contendo as mudanas que devem ser enviadas para o servidor slave;

80

LDAP LDAP replica: indica quem e o servidor slave deste mster. Mltiplas diretivas replica podem ser utilizadas, uma para cada slave. As principais opes da diretiva replica esta descrita na tabela a seguir: Replica <opes> Designacao do servidor slave. Ex: ldap://servidor.ldap O valor pode ser yes ou critical. Na primeira opo uma conexo TLS ser tentada, e na segunda ela ser requerida. Se esta conexo estiver ausente toda a conexo ser em texto claro. Indica o ramo da arvore que devera ser replicado. Pode ser simple ou sasl. Na autenticao simples, indica o binddn a ser utilizado. Na autenticao simples, indica a senha a ser utilizada. Na autenticao SASL, indica o mecanismo a ser utilizado.

uri=<uri> starttls=<valor> suffix=<sufixo> bindmethod=<valor> binddn=<dn> credemtials=<senha> saslmech=<valor>

Para configurarmos o servidor slave-ldap.exemplo como nosso servidor slave utilizando autenticao simples e replicando toda a base de dados, a configurao do servidor mster ter as seguintes modificaes (destacadas em negrito): /etc/openldap/slapd.conf
include include include include pidfile argsfile database suffix rootdn rootpw directory checkpoint 512 10 index index index index index index index objectClass sn,cn uid uidNumber gidNumber telephoneNumber memberUid eq eq,sub,approx eq,sub eq eq eq,sub eq,sub /usr/share/openldap/schema/core.schema /usr/share/openldap/schema/cosine.schema /usr/share/openldap/schema/inetorgperson.schema /usr/share/openldap/schema/nis.schema /var/run/ldap/slapd.pid /var/run/ldap/slapd.args bdb dc=exemplo,dc=com,dc=br cn=manager,dc=exemplo,dc=com,dc=br {SSHA}pzp96ZACsCrwbeos2D4ujmGvKRyJFQiY /var/lib/ldap

access to attrs=userPassword by anonymous auth by self write by * none

81

LDAP LDAP
access to attrs=shadowLastChange by self write by * none access to * by * read sasl-regexp ^uid=([^,]+),cn=digest-md5,cn=auth$ cn=$1,ou=Pessoas,dc=exemplo,dc=com,dc=br replogfile /var/lib/ldap/replica/replica.log replica uri=ldap://slave-ldap.exemplo bindmethod=simple binddn=cn=manager,dc=exemplo,dc=com,dc=br credentials="senha"

Antes de prosseguirmos precisamos criar o diretrio onde ser armazenado o arquivo de log de replicao que especificamos no arquivo de configurao (/var/lib/ldap/replica) caso ele h no exista:
#mkdir m 0700 p /var/lib/ldap/replica #chow ldap:ldap /var/lib/ldap/replica

7.3 Configurao do Slave

O servidor slave conter todos os dados do mster, ou apenas alguma parte deles. No nosso exemplo, ser uma copia do mster, precisaremos compartilhar os mesmos schemas e ACLS. A nica diferena e que o slave ser uma copia somente leitura. Comearemos a configurao a partir do mesmo arquivo slapd.conf do mster. Aps remover as diretivas replogfile e replica as alteraes restantes estas marcadas em negrito e sero explicadas em seguida:
include include include include pidfile argsfile database suffix rootdn rootpw directory checkpoint 512 10 index index index index index index index objectClass sn,cn uid uidNumber gidNumber telephoneNumber eq,sub memberUid eq eq,sub,approx eq,sub eq eq eq,sub /usr/share/openldap/schema/core.schema /usr/share/openldap/schema/cosine.schema /usr/share/openldap/schema/inetorgperson.schema /usr/share/openldap/schema/nis.schema /var/run/ldap/slapd.pid /var/run/ldap/slapd.args bdb dc=exemplo,dc=com,dc=br cn=manager,dc=exemplo,dc=com,dc=br {SSHA}pzp96ZACsCrwbeos2D4ujmGvKRyJFQiY /var/lib/ldap

access to attrs=userPassword by anonymous auth by self write by * none

82

LDAP LDAP
access to attrs=shadowLastChange by self write by * none access to * by * read sasl-regexp ^uid=([^,]+),cn=digest-md5,cn=auth$ cn=$1,ou=Pessoas,dc=exemplo,dc=com,dc=br updated cn=manager,dc=exemplo,dc=com,dc=br updateref ldap://master-ldap.exemplo

Foram realizadas as seguintes alteraes: updatedn: esta diretiva diz quem e o DN autorizado a realizar modificaes na base. Este DN deve ser o mesmo utilizado no parmetro binddn da configurao do servidor mster; updateref: especifica que uma URI a ser retornada para clientes que tentarem realizar uma operao de escrita neste servidor slave. A URI deve apontar para o servidor mster. OBS: Se ocorrer alguma operao de escrita neste servidor slave que no seja atravs da DN especificada em updatedn, a escrita ser negada, no importando se h alguma ACL permitindo esse tipo de acesso.

LDAP Slave
LDAP Master SLURPD
Log Replicao

SLAPD
SLAPD

Cliente LDAP
1. O Cliente LDAP envia uma operao de escrita para servidor slave 2. O slave, como e somente-leitura, reponde com um referral para o mster 3. O cliente envia novamente a mesma operao de escrita, mas agora para o mster 4. O mster aceita a operao e a realiza, retornando um resultado positivo para o cliente 5. O mster grava a alterao no log de replicao 6 O servio slurpd detecta atividade no log de replicao e percebe que h mudanas pendentes que devem ser enviadas para o servidor slave 7. O servio slurpd envia a operao de escrita para o servidor slave.

7.4 Copiando a Base para o Slave

83

LDAP LDAP O servidor slave precisa estar completamente sincronizado com o servidor mster para que a replicao funcione a contento. Esta sincronizao inicial precisa ser feita manualmente. No mster, fazemos um dump da base de dados para um arquivo LDIF. Este arquivo devera ser enviado de forma segura para o servidor slave, onde ser carregado na base local. O dump poder ser realizado com o comando slapcat:
# slapcat > master.ldif # ls-l master.ldif -rw-rr1 root root 4278 2009-12-06 12:00 master.ldif

Este arquivo LDIF, depois de enviado ao servidor slave deve ser carregado de volta ao diretrio:
# slapcat v < master.ldif Added: dc=exemplo,dc=com,dc=br (00000001) Added: dc=pessoas,dc=exemplo,dc=com,dc=br (00000002) Added: cn=benjamin,ou=pessoas,dc=exemplo,dc=com,dc=br (00000003) Added: cn=marcelo,ou=pessoas,dc=exemplo,dc=com,dc=br (00000004) Added: cn=dias,ou=pessoas,dc=exemplo,dc=com,dc=br (00000005) Added: cn=joao,ou=pessoas,dc=exemplo,dc=com,dc=br (00000006)

Durante este procedimento todo o servidor mster deve estar parado, caso contrario a base poder sofrer modificaes neste intervalo de tempo e no estar mais sincronizada com a copia que foi enviada para o slave.

7.5 Reiniciando os Servicos

Com as bases sincronizadas, podemos iniciar os servios, Primeiro o slave, e depois o mster. Ao iniciarmos o servio no mster vemos que um servio adicional esta sendo iniciando automaticamente:
# service ldap start Iniciando ldap Iniciando slurp [ OK ] [ OK ]

O servio novo e o daemon slurpd, responsvel por monitorar o log de replicao e enviar as mudanas para os servidores slave. Para testar, basta fazermos uma modificao no servidor mster e observar os logs de ambos os servidores:
# ldapmodify x D uid=carlos,ou=pessoas,dc=exemplo,dc=com,dc=br W Enter LDAP Password: dn: uid=carlos,ou=Pessoas,dc=exemplo,dc=com,dc=br changetype:modify replace; userPassword userPassword: CARLOS modifying entry uid=carlos,ou=pessoas,dc=exemplo,dc=com,dc=br

Esta modificao provoca toda uma sequencia de eventos. Primeiro vejamos os logs do servidor mster:

84

LDAP LDAP

slapd[26752]: conn=1 method=128 slapd[26752]: conn=1 mech=SIMPLE ssf=0 slapd[26752]: conn=1 slapd[26752]: conn=1 slapd[26752]: conn=1 slapd[26752]: conn=1

op=0 BIND dn="uid=carlos,ou=Pessoas,dc=exemplo,dc=com,dc=br" op=0 BIND dn="uid=carlos,ou=Pessoas,dc=exemplo,dc=com,dc=br" op=0 op=0 op=0 op=0 RESULT tag=97 err=0 text= MOD dn="uid=carlos,ou=Pessoas,dc=exemplo,dc=com,dc=br" MOD attr=userPassword RESULT tag=103 err=0 text=

Podemos ver que a autenticao foi feita com o RDN uid=carlos e que o atributo userPassword foi modificado.
slapd[13982]: conn=0 method=128 slapd[13982]: conn=0 mech=SIMPLE ssf=0 slapd[13982]: conn=0 slapd[13982]: conn=0 slapd[13982]: conn=0 op=0 BIND dn="uid=replicador,ou=Pessoas,dc=exemplo,dc=com,dc=br" op=0 BIND dn="uid=replicador,ou=Pessoas,dc=exemplo,dc=com,dc=br" op=0 RESULT tag=97 err=0 text= op=0 MOD dn="uid=carlos,ou=Pessoas,dc=exemplo,dc=com,dc=br" op=1 MOD attr=userPassword entryCSN modifiersName modifyTimestamp

O servidor slave recebeu uma conexo vindo do mster que se autenticou com as credenciais do usurio utilizado para replicar a base. A replicao esta funcionando! A mesma alterao que fizemos no servidor mster foi enviada para o servidor slave.

7.6 Dicas
A replicao com o OpenLDAP e complexa de configurar pois existem muitos detalhes a serem observados. E absolutamente necessrio ser metdico e realizar todos os passos com a calma e segurana. Tanto nss_ldap como pam_ldap por padro seguem referrals, portanto no h problemas em utiliza-los com servidores slave. Erros na replicao so gravados em disco com a extenso err e normalmente so causados pelos seguintes motivos: Autenticacao incorreta do usurio replicador Inconsistencia entre a base do servidor mster e a base do servidor slave ACLs no servidor slave impedindo a gravao dos dados da replicao. Verses diferentes do OpenLDAP no mster e no slave.

85

LDAP LDAP

7.7 Exerccios
1. Mostre o trecho de configurao necessrio no servidor mster para replicar o ramo ou=Pessoas,dc=exemplo,dc=com,dc=br para um servidor slave da seguinte forma: Autenticao simples DN de autenticao uid=replicador,ou=Accounts,dc=exemplo,dc=com,dc=br Senha: copiando Endereo do servidor slave: 192.168.1.10

86