Serviço de diretório com LDAP [4]: ​​OpenLDAP (I)

Olá amigos!. Vamos ao que interessa e, como sempre recomendamos, leia os três artigos anteriores da série:

• Serviço de diretório com LDAP. Introdução.
• Serviço de diretório com LDAP [2]: NTP e dnsmasq.
• Serviço de diretório com LDAP [3]: Isc-DHCP-Server e Bind9.

DNS, DHCP e NTP são os serviços essenciais mínimos para nosso diretório simples baseado em OpenLDAP nativo, funciona corretamente no Debian 6.0 "Squeeze", ou no Ubuntu 12.04 LTS "Precise Pangolin".

Rede de exemplo:

Lan: 10.10.10.0/24
Dominio: amigos.cu
Servidor: mildap.amigos.cu
Sistema Operativo Servidor: Debian 6 "Squeeze
Dirección IP del servidor: 10.10.10.15
Cliente 1: debian7.amigos.cu
Cliente 2: raring.amigos.cu
Cliente 3: suse13.amigos.cu
Cliente 4: seven.amigos.cu

Na Parte Um, veremos:

• Instalação OpenLDAP (tapa 2.4.23-7.3)
• Verificações após a instalação
• Índices a serem considerados
• Regras de controle de acesso a dados
• Geração de certificados TLS no Squeeze

enquanto na segunda parte continuaremos com:

• Autenticação de usuário local
• Preencher o banco de dados
• Gerenciar o banco de dados usando utilitários de console
• Resumo até agora ...

Instalação OpenLDAP (tapa 2.4.23-7.3)

O servidor OpenLDAP é instalado usando o pacote bofetada. Devemos também instalar o pacote LDAP-utils, que nos fornece algumas ferramentas do lado do cliente, bem como utilitários próprios do OpenLDAP.

: ~ # aptitude install slapd ldap-utils

Durante o processo de instalação, o debconf Ele nos pedirá a senha do administrador ou usuário «admin«. Várias dependências também são instaladas; usuário é criado openldap; a configuração inicial do servidor é criada, bem como o diretório LDAP.

Em versões anteriores do OpenLDAP, a configuração do daemon bofetada foi feito inteiramente por meio do arquivo /etc/ldap/slapd.conf. Na versão que estamos usando e posteriores, a configuração é feita no mesmo bofetada, e para este propósito um DIT «Árvore de informações do diretório»Ou árvore de informações do diretório, separadamente.

O método de configuração conhecido como RTC «Configuração em tempo real»Configuração em tempo real ou como método cn = config, nos permite configurar dinamicamente o bofetada sem a necessidade de reiniciar o serviço.

O banco de dados de configuração consiste em uma coleção de arquivos de texto no formato LDIF «Formato de intercâmbio de dados LDAP»Formato LDAP para Data Exchange, localizado na pasta /etc/ldap/slapd.d.

Para se ter uma ideia da organização da pasta tapa.d, vamos correr:

: ~ # ls -lR /etc/ldap/slapd.d/
/etc/ldap/slapd.d/: total 8 drwxr-x --- 3 openldap openldap 4096 fev 16 11:08 cn = config -rw ------- 1 openldap openldap 407 fev 16 11:08 cn = config.ldif /etc/ldap/slapd.d/cn=config: total 28 -rw ------- 1 openldap openldap 383 fev 16 11:08 cn = módulo {0} .ldif drwxr-x --- 2 openldap openldap 4096 fev 16 11:08 cn = schema -rw ------- 1 openldap openldap 325 fev 16 11:08 cn = schema.ldif -rw ------- 1 openldap openldap 343 fev 16 11:08 olcBackend = {0} hdb.ldif -rw ------- 1 openldap openldap 472 fev 16 11:08 olcDatabase = {0} config.ldif -rw ------- 1 openldap openldap 586 16 de fevereiro 11:08 olcDatabase = {- 1} frontend.ldif -rw ------- 1 openldap openldap 1012 16 de fevereiro 11:08 olcDatabase = {1} hdb.ldif /etc/ldap/slapd.d/cn = config / cn = schema: total 40 -rw ------- 1 openldap openldap 15474 fev 16 11:08 cn = {0} core.ldif -rw ------- 1 openldap openldap 11308 fev 16 11:08 cn = {1} cosine.ldif -rw ------- 1 openldap openldap 6438 fev 16 11:08 cn = {2} nis.ldif -rw ------- 1 openldap openldap 2802 16 de fevereiro 11:08 cn = {3} inetorgperson.ldif

Se olharmos um pouco para a saída anterior, vemos que o Backend usado no Squeeze é o tipo de banco de dados HDB, que é uma variante de bdb "Berkeley Database", e que é totalmente hierárquico e suporta a renomeação de subárvores. Para saber mais sobre o possível Backends compatível com OpenLDAP, visite http://es.wikipedia.org/wiki/OpenLDAP.

Também vemos que três bancos de dados separados são usados, ou seja, um dedicado à configuração, outro para Frontend, e o último que é o banco de dados HDB em si.

Além disso, bofetada é instalado por padrão com o esquema núcleo, Cosseno, Nis e Inetorgpessoa.

Verificações após a instalação

Em um terminal, executamos e lemos calmamente as saídas. Verificaremos, principalmente com o segundo comando, a configuração deduzida da listagem da pasta tapa.d.

: ~ # ldapsearch -Q -LLL -Y EXTERNO -H ldapi: /// -b cn = config | mais: ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b cn = config dn
dn: cn = config dn: cn = módulo {0}, cn = config dn: cn = schema, cn = config dn: cn = {0} core, cn = schema, cn = config dn: cn = {1} cosseno , cn = schema, cn = config dn: cn = {2} nis, cn = schema, cn = config dn: cn = {3} inetorgperson, cn = schema, cn = config dn: olcBackend = {0} hdb, cn = config dn: olcDatabase = {- 1} frontend, cn = config dn: olcDatabase = {0} config, cn = config dn: olcDatabase = {1} hdb, cn = config

Explicação de cada saída:

• cn = config: Parâmetros globais.
• cn = módulo {0}, cn = config: Módulo carregado dinamicamente.
• cn = esquema, cn = config: Contém o hard-coded ao nível dos esquemas do sistema.
• cn = {0} núcleo, cn = esquema, cn = configuração: O hard-coded do esquema do kernel.
• cn = {1} cosseno, cn = esquema, cn = config: O esquema Cosseno.
• cn = {2} nis, cn = esquema, cn = config: O esquema Não.
• cn = {3} inetorgperson, cn = schema, cn = config: O esquema Inetorgpessoa.
• olcBackend = {0} hdb, cn = config: Backend tipo de armazenamento de dados HDB.
• olcDatabase = {- 1} frontend, cn = config: Frontend do banco de dados e parâmetros padrão para os outros bancos de dados.
• olcDatabase = {0} config, cn = config: Banco de dados de configuração do bofetada (cn = config).
• olcDatabase = {1} hdb, cn = config: Nossa instância de banco de dados (dc = amigos, dc = cu)

: ~ # ldapsearch -x -LLL -H ldap: /// -b dc = exemplo, dc = com dn
dn: dc = amigos, dc = cu dn: cn = admin, dc = amigos, dc = cu

• dc = amigos, dc = cu: Árvore de informações do diretório de base DIT
• cn = admin, dc = amigos, dc = cu: Administrador (rootDN) do DIT declarado durante a instalação.

Nota: O sufixo básico dc = amigos, dc = cu, ele pegou debconf durante a instalação de FQDN do servidor lightap.amigos.cu.

Índices a serem considerados

A indexação das entradas é realizada para melhorar o desempenho das pesquisas no DIT, com critérios de filtro. Os índices que iremos considerar são os mínimos recomendados de acordo com os atributos declarados nos esquemas padrão.

Para modificar dinamicamente os índices no banco de dados, criamos um arquivo de texto no formato LDIFe, posteriormente, o adicionamos ao banco de dados. Nós criamos o arquivo olcDbIndex.ldif e o deixamos com o seguinte conteúdo:

: ~ # nano olcDbIndex.ldif
dn: olcDatabase = {1} hdb, cn = config changetype: modificar add: olcDbIndex olcDbIndex: uidNumber eq - adicionar: olcDbIndex olcDbIndex: gidNumber eq - adicionar: olcDbIndex olcDbIndex olcDbIndex: uidNumber eq - adicionar: olcDbIndex olcDbIndex: gidNumber eq - add: olcDbIndex olcDbIndex olcDbIndex: uidNumber eq - adicionar: olcDbIndex olcDbIndex: gidNumber eq - adicionar: olcDbIndex olcDbIndex olcDbIndex: memberUid eIcellDex, loginDbq, loginDex: eIcellDex: eIcellDex, loginDex: eIcellDex: eIcellDex: eqcellDex, loginDex: eIcellDex: eIcellDex; - adicionar: olcDbIndex olcDbIndex: uid pres, sub, eq - adicionar: olcDbIndex olcDbIndex: cn pres, sub, eq - adicionar: olcDbIndex olcDbIndex: sn pres, sub, eq - adicionar: olcDbIndex olcDbIndex, ouq - add: olcDbIndex olcDbIndex: displayName pres, sub, eq - add: olcDbIndex olcDbIndex: default sub - add: olcDbIndex olcDbIndex: mail eq, subinitial - add: olcDbIndex olcDbIndex: dc eq

Nós adicionamos os índices ao banco de dados e verificamos a modificação:

: ~ # ldapmodify -Y EXTERNAL -H ldapi: /// -f ./olcDbIndex.ldif

: ~ # ldapsearch -Q -LLL -Y EXTERNO -H ldapi: /// -b \ cn = config '(olcDatabase = {1} hdb)' olcDbIndex

dn: olcDatabase = {1} hdb, cn = config olcDbIndex: objectClass eq olcDbIndex: uidNumber, gidNumber eq olcDbIndex: memberUid eq, pres, sub olcDbIndex: loginShell eq olc olcDbIndex: uid presc, eq presc, sub olcDbIndex: sn pres, sub, eq olcDbIndex: givenName, ou pres, eq, sub olcDbIndex: displayName pres, sub, eq olcDbIndex: sub olcDbIndex padrão: mail eq, subinicial olcDbIndex: dc eq

Regras de controle de acesso a dados

As regras que são estabelecidas para que os usuários possam ler, modificar, adicionar e excluir dados no banco de dados do Directory são chamadas de Controle de Acesso, enquanto chamaremos Listas de Controle de Acesso ou «Lista de controle de acesso ACL»Às políticas que configuram as regras.

Para saber qual ACLs foram declarados por padrão durante o processo de instalação do bofetada, nós executamos:

: ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b \
cn = config '(olcDatabase = {1} hdb)' olcAccess

: ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b \
cn = config '(olcDatabase = {- 1} frontend)' olcAccess

: ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b \
cn = config '(olcDatabase = {0} config)' olcAccess

: ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b \
cn = config '(olcAccess = *)' olcAccess olcSuffix

Cada um dos comandos anteriores nos mostrará o ACLs que até agora declaramos em nosso Diretório. Especificamente, o último comando mostra todos eles, enquanto os três primeiros nos fornecem as regras de controle de acesso para todos os três. DIT envolvido em nosso bofetada.

Sobre o assunto de ACLs e para não fazer um artigo muito mais longo, recomendamos a leitura das páginas de manual homem tapa.access.

Para garantir o acesso de usuários e administradores para atualizar suas entradas de loginShell y Lagartixas, adicionaremos a seguinte ACL:

## Criamos o arquivo olcAccess.ldif e o deixamos com o seguinte conteúdo: ~ # nano olcAccess.ldif
dn: olcDatabase = {1} hdb, cn = config changetype: modificar add: olcAccess olcAccess: {1} to attrs = loginShell, gecos by dn = "cn = admin, dc = friends, dc = cu" escrever por self write por * ler

## Adicionamos o ACL
: ~ # ldapmodify -Y EXTERNAL -H ldapi: /// -f ./olcAccess.ldif

# Nós verificamos as mudanças
ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b \
cn = config '(olcAccess = *)' olcAccess olcSuffix

Geração de Certificados TLS em Squeeze

Para ter uma autenticação segura com o servidor OpenLDAP, devemos fazê-lo por meio de uma sessão criptografada que podemos alcançar usando o TLS «Segurança da Camada de Transporte» o Camada de transporte seguro.

O servidor OpenLDAP e seus clientes são capazes de usar o quadro TLS para fornecer proteção em relação à integridade e confidencialidade, bem como suporte para autenticação LDAP segura através do mecanismo SASL «Camada de autenticação e segurança simples« Externo.

Os servidores OpenLDAP modernos favorecem o uso de */ StartTLS /* o Iniciar uma camada de transporte segura para o /LDAPS: ///, que está obsoleto. Qualquer dúvida, visite * Start TLS v. ldaps: // * en http://www.openldap.org/faq/data/cache/605.html

Apenas deixe o arquivo como instalado por padrão / etc / default / slapd com a declaração SLAPD_SERVICES = »ldap: /// ldapi: ///», com o objetivo de utilizar um canal criptografado entre o cliente e o servidor, e as próprias aplicações auxiliares para gerenciar o OpenLDAP que se instalam localmente.

O método descrito aqui, com base nos pacotes gnutls-bin y certificado SSL é válido para Debian 6 "Squeeze" e também para Ubuntu Server 12.04. Para Debian 7 "Wheezy", outro método baseado em OpenSSL.

A geração dos certificados no Squeeze é realizada da seguinte forma:

1.- Instalamos os pacotes necessários
: ~ # aptitude install gnutls-bin ssl-cert

2.- Criamos a chave primária para a autoridade de certificação
: ~ # sh -c "certtool --generate-privkey> /etc/ssl/private/cakey.pem"

3.- Criamos um template para definir a CA (Autoridade Certificadora)
: ~ # nano /etc/ssl/ca.info cn = Amigos cubanos ca cert_signing_key

4.- Criamos o certificado autoassinado ou autoassinado de CA para clientes
: ~ # certtool --generate-self-signed \ --load-privkey /etc/ssl/private/cakey.pem \ --template /etc/ssl/ca.info \ --outfile / etc / ssl / certs / cacert.pem

5.- Geramos uma chave privada para o servidor
: ~ # certtool --generate-privkey \ --bits 1024 \ --outfile /etc/ssl/private/mildap-key.pem

Nota: Substitua "suave"no nome do arquivo acima pelo do seu próprio servidor. Nomear o certificado e a chave, tanto para o servidor quanto para o serviço que os utiliza, nos ajuda a manter as coisas claras.

6.- Criamos o arquivo /etc/ssl/mildap.info com o seguinte conteúdo:
: ~ # nano /etc/ssl/mildap.info organization = Amigos cubanos cn = lightap.amigos.cu tls_www_server encryption_key customization_key expiration_days = 3650

Nota: No conteúdo acima declaramos que o certificado é válido por um período de 10 anos. O parâmetro deve ser ajustado para nossa conveniência.

7.- Criamos o Certificado de Servidor
: ~ # certtool --generate-certificate \ --load-privkey /etc/ssl/private/mildap-key.pem \ --load-ca-certificate /etc/ssl/certs/cacert.pem \ --load- ca-privkey /etc/ssl/private/cakey.pem \ --template /etc/ssl/mildap.info \ --outfile /etc/ssl/certs/mildap-cert.pem

Até agora geramos os arquivos necessários, só temos que adicionar ao diretório a localização do certificado autoassinado cacert.pem; o do certificado do servidor lightap-cert.pem; e a chave privada do servidor lightap-key.pem. Devemos também ajustar as permissões e o proprietário dos arquivos gerados.

: ~ # nano /etc/ssl/certinfo.ldif
dn: cn = config add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem - adicionar: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/mildap-certificateFile: /etc/ssl/certs/cacert.pem - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/mildap-certificateFile /mildap-key.pem

8.- Adicionar: ~ # ldapmodify -Y EXTERNAL -H ldapi: /// -f /etc/ssl/certinfo.ldif

9.- Ajustamos o proprietário e as permissões
: ~ # adduser openldap ssl-cert: ~ # chgrp ssl-cert /etc/ssl/private/mildap-key.pem: ~ # chmod g + r /etc/ssl/private/mildap-key.pem: ~ # chmod ou /etc/ssl/private/mildap-key.pem

O certificado cacert.pem É o que devemos copiar em cada cliente. Para que este certificado seja usado no próprio servidor, devemos declará-lo no arquivo /etc/ldap/ldap.conf. Para fazer isso, modificamos o arquivo e o deixamos com o seguinte conteúdo:

: ~ # nano /etc/ldap/ldap.conf
BASE dc = amigos, dc = cu URI ldap: //mildap.amigos.cu TLS_CACERT /etc/ssl/certs/cacert.pem

Por fim e também como verificação, reiniciamos o serviço bofetada e verificamos a saída do syslog do servidor, para descobrir se o serviço foi reiniciado corretamente usando o certificado recém-declarado.

: ~ # service slapd restart
: ~ # tail / var / log / syslog

Se o serviço não reiniciar corretamente ou observarmos um erro grave no syslog, não vamos desanimar. Podemos tentar reparar o dano ou recomeçar. Se decidirmos começar do zero a instalação do bofetada, não é necessário formatar nosso servidor.

Para apagar tudo o que fizemos até agora por um motivo ou outro, devemos desinstalar o pacote bofetadae, em seguida, exclua a pasta / var / lib / ldap. Devemos também deixar o arquivo em sua versão original /etc/ldap/ldap.conf.

É raro que tudo funcione corretamente na primeira tentativa. 🙂

Lembre-se que na próxima edição veremos:

• Autenticação de usuário local
• Preencher o banco de dados
• Gerenciar o banco de dados usando utilitários de console
• Resumo até agora ...

Até logo amigos!.