O documento discute tópicos relacionados ao LDAP, incluindo a anatomia de esquemas, trabalhando com banco de dados SQL como backend, políticas de senha e dicas para melhorar o desempenho e segurança do OpenLDAP.

1. EXTREME LDAP
POR GABRIEL STEIN

2. TÓPICOS ABORDADOS
● ANATOMIA DE SCHEMAS
● TRABALHANDO COM BACKEND SQL
● BOTANDO ORDEM NA CASA: PASSWORD POLICIES
● OPENLDAP TUNNING

3. Anatomia de Schemas

4. Anatomia de schemas
●Schemas são arquivos texto compostos de vários atributos
e objectclasses
●As objectclasses nos schemas dizem quais os atributos
DEVEM e quais os atributos PODEM ter uma entrada
● Cada atributo e cada objectclass tem um número
identificador conhecido como Object Identifier - OID

5. Anatomia de schemas - 2
●OIDs são fornecidos pela IANA - http://www.iana.org/cgi-
bin/enterprise.pl
● Schemas definem quais os tipos de comparações serão
feitas com atributos(Case Sensitive e Case Insensitive)

6. Anatomia de schemas
MATCHING RULES

7. Anatomia de schemas
MATCHING RULES
●São as regras que determinam as comparações dos valores de
atributos
● Comparações podem ser feitas de acordo com a caixa das letras:
- Case Sensitive: Sensível a letras maiúsculas e minúsculas(LINUX é
diferente de linux)
Exemplo: CaseExactMatch
- Case Insensitive: Não sensível a letras maiúsculas e
minúsculas(LINUX é igual a linux)
Exemplo: CaseIgnoreMatch

8. Anatomia de schemas
MATCHING RULES - continuação
●Comparações podem ser feitas de acordo com o valor do
atributo:
- Booleanos
Exemplo: booleanMatch
- Inteiros
Exemplo: integerMatch

9. Anatomia de schemas
SINTAXES

10. Anatomia de schemas
SINTAXES
● Determinam como os valores dos atributos serão representados;
DADO OID DESC.
● Binary 1.3.6.1.4.1.1466.115.121.1.5 BER/DER data
● Boolean 1.3.6.1.4.1.1466.115.121.1.7 Booleano
● Integer 1.3.6.1.4.1.1466.115.121.1.27 Inteiro

11. Anatomia de schemas
ATRIBUTO

12. Anatomia de schemas
ATRIBUTO
●Atributos são componentes responsáveis por armazenar valores
numa base;
●Podem ser herdados de uma objectclass desde que sejam
obrigatórios
attributetype ( 2.5.4.5 NAME 'serialNumber'
DESC 'RFC2256: serial number of the entity'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} )

13. Anatomia de schemas
ATRIBUTO – Desmembrando – parte 1
Alias do atributo
OID
Descrição textual
attributetype ( 2.5.4.5 NAME 'serialNumber'
DESC 'RFC2256: serial number of the entity'
EQUALITY caseIgnoreMatch Qualificador do
SUBSTR caseIgnoreSubstringsMatch Tipo de Matching
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} )
Sintaxe do OID
Tipo Matching Rule
Tamanho / Valor único /
Multi-valores

14. Anatomia de schemas
ATRIBUTO – Desmembrando – parte 2
● No slide anterior, constatamos:
● O OID da ObjectClass é 2.5.4.5. Esse número identifica unicamente o atributo;
● O nome do atributo que pode ser utilizado em uma entrada é serialNumber;
●O parâmetro DESC oferece informações descritivas sobre o atributo, além de referenciar
uma RFC, que no caso é a 2258. Consultando a RFC, no item 5.6 temos o próprio atributo:
5.6. serialNumber
This attribute contains the serial number of a device.
( 2.5.4.5 NAME 'serialNumber' EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} )

15. Anatomia de schemas
ATRIBUTO – Desmembrando – parte 3
● insistindo....
●Temos a indicação da utilização de um método de comparação através da diretiva
EQUALITY. caseIgnoreMatch indica que maiúsculas e minúsculas terão valor igual.
●Outro método de comparação na busca: SUBSTRing. Também ignora maiúsculas e
minúsculas, igualando-as;
●A diretiva SYNTAX referece ao tipo de dado armazenado. Então, pesquisando a RFC 4517
que descreve isso temos:
1.3.6.1.4.1.1466.115.121.1.44 = PrintableString (O que é isso??)
A definição no LDAP de PrintableString:
( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )

16. Anatomia de schemas
ATRIBUTO – Desmembrando – parte 4
● Continuando, de forma incansável....
●Continuando a investigar mais sobre o tipo de syntax conhecido como PrintableString na
RFC 4517(livre-tradução):
O valor da syntax Printable String é uma string de um ou mais caracteres do alfabeto latino,
números, pontuação especificados pela regra PrintableCharacter.
PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
PLUS / COMMA / HYPHEN / DOT / EQUALS /
E se você ainda está curioso sobre as regras acima... leia a RFC 4512.
● E o valor que está entre chaves na diretiva SYNTAX??

17. Anatomia de schemas
ATRIBUTO – Desmembrando – parte 5
● E chegando ao final!
●O último campo da diretiva SYNTAX define qual o tamanho do campo e configurações
diversas sobre o valor;
● Um esqueleto de montagem de atributo: attributetype ( <OID do atributo>
[ "NAME" <nome do atrituto> ]
[ "DESC" <descrição do atributo> ]
[ "OBSOLETE" ]
[ "SUP" <OID do atributo ancestral> ]
[ "EQUALITY" <regra de comparação>
[ "ORDERING" <regra de comparação>
[ "SUBSTR" <regra de comparação> ]
[ "SYNTAX" <OID da SYNTAX> ]
[ "SINGLE-VALUE" ]
[ "COLLECTIVE" ]
[ "NO-USER-MODIFICATION" whsp ]
[ "USAGE" whsp AttributeUsage ] ")"

18. Anatomia de schemas
OBJECTCLASSES

19. Anatomia de schemas
OBJECTCLASSES
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 $ userPKCS12 )

20. Anatomia de schemas
OBJECTCLASS - InetOrgPerson
● Possuem um número identificador: OID;
● Possuem nome;
● Possuem descrição informativa e referência a RFCs;
● Existe a herança entre objectclasses, onde uma pode herdar os
atributos obrigatórios de outra;
● São separadas em 3 tipos: STRUCTRAL, AUXILIARY e ABSTRACT;
● Possuem um conjunto de atributos que uma entrada DEVE ter;
● Possuem um conjunto de atributos que uma entrada PODE ter;

21. Anatomia de schemas
OBJECTCLASSES – Descrição – RFC 2798
Seção 1: Cenário e uso
A object class inetOrgPerson é uma object class de uso geral e que
possui atributos sobre pessoas. Os atributos armazenam o que é
exigido para acomodar informações típicas na implementação de
serviços de internet e intranets;

22. Anatomia de schemas
OBJECTCLASSES – Heranças
●A diretiva SUP indica que a referida object class herda atributos de
outra object class;
No exemplo, é indicada a object class organizationalPerson –
seguindo(core.schema):
objectclass ( 2.5.6.7 NAME 'organizationalPerson'
DESC 'RFC2256: an organizational person'
SUP person STRUCTURAL
Seguindo.... objectclass ( 2.5.6.6 NAME 'person'
DESC 'RFC2256: a person'
SUP top STRUCTURAL
MUST ( sn $ cn )

23. Anatomia de schemas
OBJECTCLASSES – Tipos
●STRUCTURAL: São objectclasses básicas para cada objeto;
Exemplo: person
●AUXILIARY: São objectclasses aditivas, complementam as
objectclasses STRUCTURAL;
Exemplo: pilotObject
●ABSTRACT: São utilizadas para definir o modelo básico de dados do
LDAP
Exemplo: top

24. Anatomia de schemas
OBJECTCLASSES – Relações de Atributos
● MUST: Atributos que são obrigatórios quando uma object class é
referenciada numa entrada na base, ou quando existem heranças em
outras objectclass;
MUST ( sn $ cn )
● MAY: Atributos que são opcionais quando uma object class é
referenciada na base;
MAY (audio $ businessCategory $ carLicense $
departmentNumber $ displayName $ employeeNumber)

25. Trabalhando com Backend SQL

26. Backend SQL
●O backend SQL não é para ser utilizado para criar primeira porção da
árvore LDAP, mas sim dados relacionais, utilizando MySQL,
PostgreSQL;
● O overhead feito pelo ODBC e o mapeamento do modelo de dados
relacional para o modelo de dados LDAP que deve ser feito pela
própria database relacional, o que limita a performance do back-sql;.

27. Backend SQL
Configuração – Compilação
●Deve ser atribuída a opção –enable-sql junto com o script configure
do pacote fonte do OpenLDAP;
● O suporte OpenLDAP SQL requer que as bibliotecas iODBC ou
● as bibliotecas unixODBC estejam instaladas no sistema;

28. Backend SQL
Conceitos de mapeamento
● O back-sql utiliza um conjunto de tabelas na própria database
relacional para armazenar informação em qual tabela e campos
correspondem a um determinado atributo LDAP e quais chaves
correspondem a um determinado objeto LDAP;
● As chaves na database devem ser inteiros(o que é o padrão)
● O conceito de mapeamento requer inúmeros joins numa tabela, então
indexar campos chave é essencial para uma melhor performance;

29. Backend SQL
Inserção de dados no banco
● O pacote fonte do OpenLDAP possui um diretório com o nome de
rdbm_depends que contém inúmeros scripts sql para preencher a
database relacional;
●Existem versões desses scripts sql para MySQL, PostgreSQL,
Oracle...

30. Backend SQL
Mapeamento de ObjectClasses
tabela: ldap_oc_mappings
CREATE SEQUENCE ldap_oc_mappings_id_seq;
CREATE TABLE ldap_oc_mappings (
id int4 NOT NULL PRIMARY KEY DEFAULT nextval
('ldap_oc_mappings_id_seq'), objectclass
name varchar(64) NOT NULL,
keytbl varchar(64) NOT NULL,
keycol varchar(64) NOT NULL,
create_proc varchar(255),
chave(inteiro
delete_proc varchar(255),
expect_return int NOT NULL Stored procedure para
); remover objetos das
tabelas RDBM baseado na
chave(valor inteiro)

31. Backend SQL
Mapeamento de Atributos
tabela: ldap_attr_mappings
CREATE SEQUENCE ldap_attr_mappings_id_seq;
CREATE TABLE ldap_attr_mappings id da objectclass
correspondente na tabela
( ldap_oc_mappings
id int4 NOT NULL PRIMARY KEY
default nextval('ldap_attr_mappings_id_seq'), atributo
oc_map_id int4 NOT NULL,
name varchar(255) NOT NULL, expressão para o
sel_expr varchar(255) NOT NULL, select(tabela.ca
mpo)
sel_expr_u varchar(255),
lista de tabelas
from_tbls varchar(255) NOT NULL, envolvidas numa
join_where varchar(255), consulta
Expressão utilizada para joins separadas por
diversos vírgula

32. Backend SQL
Mapeamento de Atributos
tabela: ldap_attr_mappings Store Procedure para adicionar
um valor para esse atributo
dando um id de objeto e um id.
add_proc varchar(255),
delete_proc varchar(255), Store Procedure para apagar o
param_order int NOT NULL, objeto e o seu id.
expect_return int NOT NULL,
FOREIGN KEY (oc_map_id) REFERENCES
ldap_oc_mappings(id)
);

33. Backend SQL
Mapeamento de dn
tabela: ldap_entries
CREATE SEQUENCE ldap_entries_id_seq;
dn Virtual
CREATE TABLE ldap_entries
( id da object class em
id int4 NOT NULL PRIMARY KEY ldap_oc_mappingsr
DEFAULT nextval('ldap_entries_id_seq'),
dn varchar(255) NOT NULL UNIQUE, id de referência do “parent” para
fazer o mapeamento correto do
-- dn_ru varchar(255), objeto. Raiz da base: 0
oc_map_id int4 NOT NULL,
parent int NOT NULL, Valor inteiro para mapear o objeto a dn
keyval int NOT NULL, atual
UNIQUE (oc_map_id,keyval),
FOREIGN KEY (oc_map_id) REFERENCES ldap_oc_mappings (id)
);

34. Backend SQL
Mapeamento de ObjectClasses
tabela: ldap_entry_objclasses
id do objeto virtual da tabela
CREATE TABLE ldap_entry_objclasses ldap_entries
(
entry_id int4 NOT NULL, nome da object class
oc_name varchar(64),
FOREIGN KEY (entry_id) REFERENCES ldap_entries(id)
);
O campo oc_map_id da tabela ldap_entries permite o mapeamento de apenas 1 object
class, mas essa tabela trabalha para que mais objectclasses sejam utilizadas em um
objeto.

35. Password Policies

36. Password Policies
● Possibilita fazer um controle de senha dos usuários da base;
● Permite controlar o vencimento da senha, tamanho mínimo, histórico,
“qualidade” da senha;
●O OpenLDAP deve ser compilado para que o overlay funcione. Na
configuração da compilação(./configure) deve ser habilitado o password
policy com o –enable-ppolicy;
● Após a compilação, deve ser referido o schema ppolicy.schema no
slapd.conf;
● Outra configuração slapd.conf:
overlay ppolicy
ppolicy_default "cn=default,ou=Policies,dc=tchelinux,dc=org"

37. Password Policies
Exemplo de entrada na base:
dn: cn=gabriel,ou=usuarios,ou=policies,dc=tchelinux,dc=org
objectClass: pwdPolicy
objectClass: top
objectClass: device
cn: gabriel
pwdAttribute: userPassword
pwdMaxAge: 7516800
pwdExpireWarning: 432000
pwdInHistory: 6
pwdCheckQuality: 1
pwdMinLength: 8
pwdMaxFailure: 4
pwdLockout: TRUE
pwdLockoutDuration: 1920
pwdGraceAuthNLimit: 0
pwdFailureCountInterval: 0
pwdMustChange: TRUE
pwdAllowUserChange: TRUE
pwdSafeModify: TRUE

38. Dicas

39. Dicas
● Use e abuse de índices;
● Preste atenção na configuração do banco(DB_CONFIG);
● Use replicação sempre!
● Mantenha sempre o backup atualizado;
● Um bom planejamento é fundamental;
●O OpenLDAP possui inúmeras funcionalidades, portanto, existem inúmeras formas da
implementação do serviço de diretório;
● Criptografia de dados!!
● Log separado ==> (syslog.conf) diretiva local4.* -/var/log/ldap.log
●Para uma boa performance, use filesystem journalized e mantenha o journal em outra
partição;

40. ?
? ? ? ?
MUITO OBRIGADO!!!
?
gabriel@gabrielstein.org