EXTREME LDAP - GABRIEL STEIN
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
2,340
On Slideshare
2,339
From Embeds
1
Number of Embeds
1

Actions

Shares
Downloads
65
Comments
0
Likes
0

Embeds 1

http://www.slideshare.net 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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