HowTo, Segurança, Sysadmin

Implantando autenticação centralizada e segura usando Openldap

Openldap

Uma autenticação centralizada faz parte do processo de adequação do ambiente as boas práticas de segurança. Esta solução provê recursos que atendem aos principios de autenticidade e não-repúdio. Usando a criptografia juntamente com esta solução poderemos previnir ataques de hijacking, spoofing e man in the middle.

O LDAP (Lightweight Directory Access Protocol) é um protocolo cliente-servidor, utilizado para acessar um serviço de Diretório. Ele foi inicialmente usado como uma interface para o X.500, mas também pode ser usado com autonomia e com outros tipos de servidores de Diretório. Atualmente vem se tornando um padrão, diversos programas já têm suporte a LDAP. Livros de endereços, autenticação, armazenamento de certificados digitai
s (S/MIME) e de chaves públicas (PGP), são alguns dos exemplos onde o LDAP já é amplamente utilizado.

O Openldap é a solução livre para a implementação do LDAP. Diferentemente das soluções proprietárias ( e.g. Active Directory ™ ), ele implementa de forma fidedigna as especificações das RFCs deste protocolo.

Este artigo têm como principal objetivo ensinar como implantar uma solução livre e gratuita de autenticação com segurança. Não abordarei conceitos sobre o funcionamento do protocolo, para isso recomendo a leitura das referências.

Inicialmente irei configurar um servidor LDAP e um cliente autenticando nesta base. Os próximos artigos apresentarei como integrar outros serviços com HTTP ( Apache ), Proxy ( Squid ) , Email ( Postfix + Dovecot ) ao serviço de diretório.

Divirtam-se!!

= Configurando o LDAP server ==

Instale os pacotes necessários

aptitude install slapd ldap-utils migrationtools

dpkg-reconfigure slapd

DNS domain name: acme.local
Organization name: acme
Database backend to set: HDB
Do you want the database to be removed when slapd is purged? No
Move old database? Yes
Allow LDAPv2 protocol? Yes

== Adicionando Schemas ==

Acesso o diretório /etc/ldap/schemas

cd /etc/ldap/schemas

Faça o download dos schemas. Eles serão importantes na implementação do kerberos e na autenticação dos usuários do Postfix

wget http://www.bayour.com/openldap/schemas/krb5-kdc.schema

wget http://trac.kyapanel.com/export/360/trunk/ldap/schema/qmailuser.schema

Edite o arquivo /etc/ldap/slapd adicionando os novos schemas e novos indices no index

vim /etc/ldap/slapd.conf

include /etc/ldap/schema/krb5-kdc.schema
include /etc/ldap/schema/qmailuser.schema

index objectClass,ou,cn,sn,uid,uidNumber,mail,mailAlternateAddress,mailForwardingAddress,memberUid eq

Reinicie o slapd

invoke-rc.d slapd restart

== Testando ==

ldapsearch -x -b “dc=acme,dc=local”

# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# acme.local
dn: dc=acme,dc=local
objectClass: top
objectClass: dcObject
objectClass: organization
o: acme
dc: acme

# admin, acme.local
dn: cn=admin,dc=acme,dc=local
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

== Migrando os usuários e grupos locais com o migration tools ==

O migrationtools é um conjunto de scripts responsáveis por migrar as informações locais como hosts, serviços, usuários, grupos e etc para a infraestrutura do LDAP.

Edite as seguintes linhas do arquivo /usr/share/migrationtools

vim migrate_common.ph

$DEFAULT_MAIL_DOMAIN = “acme.local”;

$DEFAULT_BASE = “dc=acme,dc=local”;

$EXTENDED_SCHEMA = 1;

Importe a base

./migrate_base.pl > base.ldif

O arquivo base.ldif contém a infraestrutura básica de OUs ( Unidades Organizacionais ). Como o objetivo de nosso LDAP é autenticação então edite o arquivo base.ldif deixando somente as seguintes informações:

dn: dc=acme,dc=local
dc: acme
objectClass: top
objectClass: domain
objectClass: domainRelatedObject
associatedDomain: acme.local

dn: ou=People,dc=acme,dc=local
ou: People
objectClass: top
objectClass: organizationalUnit
objectClass: domainRelatedObject
associatedDomain: acme.local

dn: ou=Group,dc=acme,dc=local
ou: Group
objectClass: top
objectClass: organizationalUnit
objectClass: domainRelatedObject
associatedDomain: acme.local

Migre as contas e as senhas dos usuários

ETC_SHADOW=/etc/shadow ./migrate_passwd.pl /etc/passwd > passwd.ldif

Migre os grupos

./migrate_group.pl /etc/group > group.ldif

== Atualize o BD do LDAP ==

ldapadd -h localhost -x -W -D “cn=admin,dc=acme,dc=local” -c -f base.ldif

ldapadd -h localhost -x -W -D “cn=admin,dc=acme,dc=local” -c -f passwd.ldif

ldapadd -h localhost -x -W -D “cn=admin,dc=acme,dc=local” -c -f group.ldif

== Testando ==

ldapsearch -LL -H ldap://localhost -b”dc=acme,dc=local” -x “(uid=alexos)”

dn: uid=alexos,ou=People,dc=acme,dc=local
uid: alexos
cn: alexos
sn: alexos
mail: [email protected]
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: krb5Principal
objectClass: shadowAccount
shadowMax: 99999
shadowWarning: 7
krb5PrincipalName: [email protected]
loginShell: /bin/bash
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/alexos
gecos: alexos,,,

Referências:

Andreaswacker
Linsec.ca
Openldap.org

Continua….

6 Comments

  1. Olá, poderia falar qual a distro, e a versão, q vc está usando para implementar este serviço?? Posta tbm o teu sources.list para vermos quais os repositórios que vc ta usando. Estou tendo problemas em várias dependências, ex: ldap-utils >> migrationtools << .
    AbraÇO. Parabéns pelo post!

  2. Ok, mas poderia colocar pelo menos a confguração de um cliente Linux autenticando login de usuários neste ambiente.

  3. Leonard todas estas configurações são feitas no servidor ldap ou tem alguma parte no cliente

    1. Olá William,

      Sim toda a configuração é realizada no servidor. No cliente você terá que configurar o pam_ldap, o libnss_ldap e os arquivos common-* localizados no pam.d

Comments are closed.