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

EXTREME LDAP - GABRIEL STEIN

on

  • 2,246 views

 

Statistics

Views

Total Views
2,246
Slideshare-icon Views on SlideShare
2,245
Embed Views
1

Actions

Likes
0
Downloads
63
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    EXTREME LDAP - GABRIEL STEIN EXTREME LDAP - GABRIEL STEIN Presentation Transcript

    • EXTREME LDAP POR 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 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 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
    • 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 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 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 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 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 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 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;
    • 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 )
    • 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
    • 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;.
    • 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;
    • 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'), 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)
    • 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
    • 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) );
    • 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) );
    • 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.
    • Password Policies
    • 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"
    • 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
    • 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;
    • ? ? ? ? ? MUITO OBRIGADO!!! ? gabriel@gabrielstein.org