EXTREME LDAPPOR GABRIEL STEIN
TÓPICOS ABORDADOS
● ANATOMIA DE SCHEMAS
● TRABALHANDO COM BACKEND SQL
● BOTANDO ORDEM NA CASA: PASSWORD POLICIES
● OPENLDAP TUNNING
Anatomia de Schemas
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
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)
Anatomia de schemas
MATCHING RULES
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
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
Anatomia de schemas
SINTAXES
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
Anatomia de schemas
ATRIBUTO
Anatomia de schemas 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} )
Anatomia de schemas Anatomia de schemas
ATRIBUTO – Desmembrando – parte 1
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} )
Alias do atributoOID
Descrição textual
Tipo Matching Rule
Qualificador do Tipo de Matching
Sintaxe do OIDTamanho / Valor único /
Multi-valores
Anatomia de schemas 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} )
Anatomia de schemas 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' )
Anatomia de schemas 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??
Anatomia de schemas 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 ] ")"
Anatomia de schemas
OBJECTCLASSES
Anatomia de schemas 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 )
Anatomia de schemas 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;
Anatomia de schemas 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;
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 )
Anatomia de schemas Anatomia de schemas
Anatomia de schemas 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 LDAPExemplo: top
Anatomia de schemas 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)
Trabalhando com Backend SQL
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;.
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;
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;
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...
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'),name varchar(64) NOT NULL,keytbl varchar(64) NOT NULL,keycol varchar(64) NOT NULL,create_proc varchar(255),delete_proc varchar(255),expect_return int NOT NULL);
Backend SQL
objectclass
chave(inteiroStored procedure para remover objetos das tabelas RDBM baseado na chave(valor inteiro)
Mapeamento de Atributos
tabela: ldap_attr_mappings
CREATE SEQUENCE ldap_attr_mappings_id_seq;CREATE TABLE ldap_attr_mappings(id int4 NOT NULL PRIMARY KEYdefault nextval('ldap_attr_mappings_id_seq'),oc_map_id int4 NOT NULL,name varchar(255) NOT NULL,sel_expr varchar(255) NOT NULL,sel_expr_u varchar(255),from_tbls varchar(255) NOT NULL,join_where varchar(255),
Backend SQL
atributo
expressão para o select(tabela.campo)
lista de tabelas envolvidas numa consulta separadas por vírgula
Expressão utilizada para joins diversos
id da objectclass correspondente na tabelaldap_oc_mappings
Mapeamento de Atributos
Backend SQL
Store Procedure para apagar o objeto e o seu id.
Store Procedure para adicionar um valor para esse atributo dando um id de objeto e um id.
tabela: ldap_attr_mappings
add_proc varchar(255),delete_proc varchar(255),param_order int NOT NULL,expect_return int NOT NULL,FOREIGN KEY (oc_map_id) REFERENCESldap_oc_mappings(id));
Mapeamento de dntabela: ldap_entries
CREATE SEQUENCE ldap_entries_id_seq;CREATE TABLE ldap_entries(id int4 NOT NULL PRIMARY KEYDEFAULT nextval('ldap_entries_id_seq'),dn varchar(255) NOT NULL UNIQUE,-- dn_ru varchar(255),oc_map_id int4 NOT NULL,parent int NOT NULL,keyval int NOT NULL,UNIQUE (oc_map_id,keyval),FOREIGN KEY (oc_map_id) REFERENCES ldap_oc_mappings (id));
Backend SQL
dn Virtual
id da object class emldap_oc_mappingsr
id de referência do “parent” para fazer o mapeamento correto do objeto. Raiz da base: 0
Valor inteiro para mapear o objeto a dn atual
Mapeamento de ObjectClassestabela: ldap_entry_objclasses
CREATE TABLE ldap_entry_objclasses(entry_id int4 NOT NULL,oc_name varchar(64),FOREIGN KEY (entry_id) REFERENCES ldap_entries(id));
Backend SQL
id do objeto virtual da tabela ldap_entries
nome da object class
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.
Password Policies
Password Pol ic ies
● 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 ppolicyppolicy_default "cn=default,ou=Policies,dc=tchelinux,dc=org"
Password Pol ic ies
Exemplo de entrada na base:
dn: cn=gabriel,ou=usuarios,ou=policies,dc=tchelinux,dc=orgobjectClass: pwdPolicyobjectClass: topobjectClass: devicecn: gabrielpwdAttribute: userPasswordpwdMaxAge: 7516800pwdExpireWarning: 432000pwdInHistory: 6pwdCheckQuality: 1pwdMinLength: 8pwdMaxFailure: 4pwdLockout: TRUEpwdLockoutDuration: 1920pwdGraceAuthNLimit: 0pwdFailureCountInterval: 0pwdMustChange: TRUEpwdAllowUserChange: TRUEpwdSafeModify: TRUE
Dicas
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;