Kerberos+LDAP+NFSv4

Kerberos

Kerberos é un protocolo de autenticación que permite a ordenadores nunha rede insegura identificarse mutuamente de xeito seguro. Tanto os clientes coma o servidor verificarán a identidade un do outro. Kerberos básase en criptografía de chave simétrica e precisa dun terceiro de confianza, ainda que existen extensións que permiten o uso de criptografía de chave asimétrica. Kerberos establece tamén unha duración das autorizacións, de xeito que únicamente é necesario autenticarse unha vez ata que caduque a concesión.

Kerberos permite evitar o envío de contrasinais sen cifrar pola rede, centralizar a xestión de usuarios e contrasinais, e almacenar as credenciais en unha única máquina.

O funcionamento de Kerberos emprega 2 entidades (servidores), o Servidor de Autenticación (SA) e o Servidor de Tickets de Acceso (TGS) co obxecto de asegurar o acceso a un servicio ofrecido por un Proveedor de Servizo (SS) como NFS. Estes dous servidores forman parte do servidor kerberos, que atenderá as solicitudes mediante o seguinte intercambio de mensaxes:

1.-Identificación do cliente

a) O usuario introduce no cliente o seu usuario e contrasinal

b) O cliente transforma o contrasinal con cifrado de un so sentido, creando a chave segreda do cliente.

c) O cliente envía unha mensaxe en claro ao SA solicitando servicio para o usuario identificado e suministrando a chave segreda do cliente.

2.- Verificación de identidade

a) O SA verifica que o usuario está na súa base de datos obtendo a súa contrasinal da BBDD e xerando a chave segreda do cliente que cotexará coa recibida. Si coinciden se crearán dúas mensaxes que se envían ao cliente:

Mensaxe A

Mensaxe cifrada coa chave segreda do cliente, chamada Client/TGS Session Key.

Mensaxe B

Mensaxe cifrada coa contrasinal do TGS obtida da BBDD que conten: ID de cliente, dirección IP do cliente, periodo de validez do ticket, e o Client/TGS Session Key. Esta mensaxe é o Ticket Granting Ticket (TGT).

b) O cliente descifra a Client/TGS Session Key da Mensaxe A, que se utilizará para a comunicación co TGS.

6. Cando o cliente precise un servicio, necesitará solicitarllo ao TGS mediante as seguintes mensaxes:

Mensaxe C

Composta polo TGT e a ID do servicio solicitado.

Debemos recordar que o cliente non ten acceso ao contido do TGT xa que está cifrado coa contrasinal do TGS.

Mensaxe D

Cifrado coa Client/TGS Session Key obtida da Mensaxe A e composta polo ID de cliente e unha marca de tempo, chamada Autenticador.

7. O TGS descifra o TGT da Mensaxe C obtendo a Client/TGS Session Key necesaria para descifrar a Mensaxe D (Autenticador) e obtendo así o ID de cliente e a marca de tempo

8. O TGS con esta información crea unha mensaxe composta pola ID de cliente,IP do cliente,Periodo de validez e a Client/Server Session Key xenerada para a comunicación. Esta mensaxe se cifra coa Chave Segreda do Servizo e se chama Client-To-Server Ticket (Mensaxe E). Tamén se crea outra mensaxe composta pola Client/Server Session Key cifrada coa Client/TGS Session Key (Mensaxe F). Se envían estas dúas mensaxes ao cliente

9. Unha vez recibidas estas mensaxes, o cliente poderá autenticarse para acceder ao servizo enviando ao Proveedor do Servizo (SS) a Mensaxe E, e unha nova mensaxe cifrada coa Client/Server Session Key obtida da Mensaxe F que terá o ID do cliente e unha Marca de Tempo.

10. O proveedor de servizo (SS) descifrará a Mensaxe E coas súa chave sergreda obtendo así a Client/Server Session Key que lle permitirá descifrar a Mensaxe F e crear unha mensaxe de autorización de acceso ao servizo (Mensaxe H) composta pola marca de tempo obtida da Mensaxe F+1 e cifrada coa Client/Server Session Key.

11. O cliente descifra a mensaxe de autorización e confirma a corrección da marca de tempo. Si é correcto, poderá empezar a utilizar o servizo.

Instalación de Kerberos

En Linux existen dúas versións de Kerberos: Heimdall e MIT. Utilizaremos MIT.

Os tickets kerberos teñen periodos de validez establecidos, polo que resulta importante a sincronización dos distintos ordenadores da rede. Para manter a sincronización podemos facer uso de ntp ou do paquete ntpdate, que combinado con cron nos permitirá manter o tempo en sincronía en todos os ordenadores da rede. Se recomenda a versión 5 de Kerberos, xa que a versión 4 ten diversas vulnerabilidades e debilidades no cifrado. E tamén necesario que todos os equipos que utilicen Kerberos sexan resoltos de modo axeitado, tanto de modo directo como inverso, polo que e convinte un servidor DNS, e incluso engadir ao /etc/hosts os servidores e clientes implicados para asegurar o posible fallo do DNS.

Kerberos soporta replicación a múltiples servidores, recomendándose o uso de polo menos dous, un maestro que será o servidor Primario (PDC) e outro Secundario que estará dispoñible para cubrir posibles fallos do maestro (BDC). Os clientes Kerberos utilizarán o servidor secundario automáticamente no caso de fallo do primario.

Para utilizar as ferramentas administrativas como kadmin e imprescindible a existencia dun servidor Primario. En caso de fallo do PDC será imposible a agregación ou modificación de entradas no dominio Kerberos mentras que o PDC non sexa posto de novo en liña

Instalaremos o servidor Kerberos:

1. Instalación do software:

 apt-get install krb5-kdc krb5-admin-server

Durante a instalación se solicitará:

• O nome do dominio Kerberos (Realm), que normalmente será o noso dominio en maiúsculas: IESRODEIRA.COM
• Os servidores Kerberos para o dominio, que serán en primeiro lugar o PDC, e logo o BDC: krbldap-pdc.iesrodeira.com krbldap-bdc.iesrodeira.com
• O nome do servidor administrativo (PDC): krbldap-pdc.iesrodeira.com

2. Debemos modificar /etc/krb5.conf para incluir a información do noso dominio kerberos na sección [domain-realm] e un apartado para configurar os log de kerberos

 mkdir /var/log/kerberos
 chmod 750 /var/log/kerberos

 [domain-realm]
       .iesrodeira.com = IESRODEIRA.COM
       iesrodeira.com = IESRODEIRA.COM
 [logging]
       kdc=FILE:/var/log/kerberos/krb5kdc.log
       admin_server=FILE:/var/log/kerberos/kadmin.log
       default=FILE:/var/log/kerberos/krb5lib.log

3. A continuación creamos a base de datos para Kerberos, para o que necesitará recolectar información aleatoria (tardará un pouco) e solicitarnos unha password que será imprescindible para o decodificado da base de datos:

 krb5_newrealm
 service krb5-admin-server restart && service krb5-kdc restart

4. Xa podemos empezar a engadir servidores e usuarios a base de datos Kerberos (principals) mediante a utilidade kadmin.local. Os principals Kerberos teñen a forma SPEC@REALMKERBEROS (no noso caso SPEC@IESRODEIRA.COM), donde SPEC normalmente ten a forma de usuario/rol ou servizo/hostname (por exemplo, root/admin, ou nfs/nfs.iesrodeira.com). Estas SPEC se poden utilizar logo no ficheiro /etc/krb5kdc/kadm5.acl para establecer ACLS especificando permisos.

As password para os principals poden organizarse mediante políticas (policies) que forzan distintos graos de fortaleza (-minlength, -minclasses, -maxlife, -minlife, -maxfailure, -failurecountinterval, -lockoutduration), creando primeiro as políticas como por exemplo:

  add_policy  -minlength 8  -minclasses 1 user
  add_policy  -minlength 8  -minclasses 3 admin

Para posteriormente crear o principal cunha política determiñada:

  addprinc -policy user root/admin

Ou cambiar de política un principal existente:

  modprinc -policy admin root/admin

Polo tanto, creamos as políticas e un principal para poder acceder a configuración Kerberos dende calqueira equipo cliente:

  add_policy -minlength 6 -minclasses 1 user
  add_policy -minlength 8 -minclasses 2 admin
  addprinc -policy admin root/admin

E editaremos /etc/krb5kdc/kadm5.acl, especificando */admin *, indicando que todos os usuarios co rol admin teñen todos os privilexios de administración. A partir deste momento poderemos administrar o servicio Kerberos dende calqueira cliente coa utilidade kadmin, crear tickets coa utilidade kinit, examinalos (klist) e eliminalos (kdestroy).

Nos clientes Kerberos será necesario instalar os paquetes krb5-config, krb5-clients e krb5-user. En caso de problemas se deberá verificar en /etc/krb5.conf que:

• [domain_realm] conten o mapeo ao dominio correcto
• default_realm ten o valor correcto
• o realm está definido na sección [realms]

Podemos comprobar o correcto funcionamento creando un ticket para o principal creado, listando o ticket (TGT) e destruíndolo:

 kinit -p root/admin
 klist
 kdestroy

5. Creamos un principal no PDC para o servidor PDC mediante a utilidade kadmin cunha chave aleatoria, xa que unha máquina non pode introducir unha chave, e creamos o ficheiro local para as chaves.

 addprinc -randkey host/krbldap-pdc.iesrodeira.com
 ktadd host/krbldap-pdc.iesrodeira.com

Unha boa idea sería crear o ficheiro /etc/logrotate.d/krb5-kdc cun contido similar a este:

 /var/log/kerberos/krb5lib.log  /var/log/kerberos/kadmin.log /var/log/kerberos/krb5lib.log {
       daily
 	missingok
 	rotate 7
 	compress
 	delaycompress
 	notifempty
 	postrotate
 		/etc/init.d/krb5-kdc restart > /dev/null
               /etc/init.d/krb5-admin-server restart > /dev/null
 	endscript
 }

Tamén sería unha boa práctica alterar a vida dos tickets:

 ~# kadmin.local
 Authenticating as principal root/admin@EXAMPLE.COM with password.
 kadmin.local:  modprinc -maxlife "1 day" -maxrenewlife "90 day" krbtgt/IESRODEIRA.COM@IESRODEIRA.COM
 Principal "krbtgt/IESRODEIRA.COM@IESRODEIRA.COM" modified.  
 kadmin.local:  q

e modificando o ficheiro /etc/krb5kdc/kdc.conf para reflexar os cambios cambiando as liñas:

 max_life = 1d 0h 0m 0s
 max_renewable_life = 90d 0h 0m 0s

Servidor Slave (BDC)

• Debemos instalar o paquete krb5-user e contestar ás preguntas:

 apt-get install krb5-user

O ficheiro /etc/krb5.conf e o script de rotación de logs /etc/logrotate.d/krb5-kdc serán idénticos aos do controlador primario (KDC).

• Creamos un principal no PDC para o servidor esclavo mediante a utilidade kadmin cunha chave aleatoria, xa que unha máquina non pode introducir unha chave, e creamos o ficheiro local para as chaves.

 addprinc -randkey host/krbldap-bdc.iesrodeira.com
 ktadd host/krbldap-bdc.iesrodeira.com

• Instalamos a parte servidor. Necesitaremos xinetd para configurar o servicio de propagación kpropd.

 apt-get install krb5-kdc xinetd

• Engadimos o servizo kpropd a xinetd creando o ficheiro /etc/xinetd.d/krb_prop e poñendo:

 service krb_prop
 {
       disable         = no
       socket_type     = stream
       protocol        = tcp
       user            = root
       wait            = no
       server          = /usr/sbin/kpropd
 }

• Inciamos o servizo xinetd

 service xinetd restart

• Configuramos a propagación da base de datos Kerberos do primario ao secundario

1. Creamos o ficheiro cos controladores Kerberos do noso reino en /etc/krb5kdc/kpropd.acl nos dous controladores. O contido será o seguinte:

  host/krbldap-pdc.iesrodeira.com@IESRODEIRA.COM
  host/krbldap-bdc.iesrodeira.com@IESRODEIRA.COM

2. No controlador primario creamos un backup da base de datos Kerberos e a enviamos ao controlador secundario

  kdb5_util dump /var/lib/krb5kdc/slave_datatrans
  kprop krbldap-bdc.iesrodeira.com

3. De volta no controlador secundario creamos un ficheiro cunha copia da chave mestra Kerberos:

  kdb5_util stash

4. Xa podemos iniciar o servizo co comando service krb5-kdc start

A propagación das modificacións da base de datos Kerberos no controlador primario non se propagan ao secundario de xeito automático, polo que é aconsellable crear un script que se encarge da migración de xeito periódico mediante a utilidade cron. Crearemos o ficheiro /etc/cron.hourly/krb5-prop co seguinte contido:

  #!/bin/sh
  slavekdcs=krbldap-bdc.iesrodeira.com
  /usr/sbin/kdb5_util dump /var/lib/krb5kdc/slave_datatrans
  error=$?
  if [ $error -ne 0 ]; then
  	echo "Kerberos database dump failed"
  	echo "with exit code $error. Exciting."
  	exit 1
  fi
  for kdc in $slavekdcs; do
  	/usr/sbin/kprop $kdc > /dev/null
  	error=$?
  	if [ $error -ne 0 ]; then
  		echo "Propagation of database to host $kdc"
  		echo "failed with exit code $error."
  	fi
   done
   exit 0

LDAP

X.500 é unha colección de protocolos, especificacións e definicións sobre o concepto de unha árbore global de información de directorio (DIT) sinxela, distribuída e replicada. Esta DIT sería capaz de almacenar todo tipo de información accesible mediante o Protocolo de Acceso ao Directorio (DAP).

Un DIT é un conxunto de datos xerarquizados, cada ún de eles identificado por un Distinguished Name (DT), unha lista de compoñentes únicos separados por comas que proporcionan o camiño a un dato ou obxecto dende o principio da árbore. Por exemplo, o DN da raíz de un DIT para o ies de rodeira podería ser dc=iesrodeira,dc=com, mentras que o DN de un profesor do instituto sería cn=Xavi,ou=Claustro,dc=iesrodeira,dc=com. O Relative Distinguished Name (RDN) de esta entrada sería cn=Xavi. Cada DN consiste en múltiples parellas de chave=valor. As chaves neste exemplo son abreviaturas para Common Name (cn), Organizational Unit (ou) e Domain Component (dc).

LDAP (LightWeight Directory Access Protocol) é un protocolo de acceso a bases de datos de directorio (Servicios de Directorio) que implementa un subconxunto do estándar X.500. Os servicios de directorio caracterízanse por ser sistemas con moitos accesos de lectura e moi poucas insercións e actualizacións, polo tanto están optimizadas para consultas rápidas.

Este tipo de bases de datos poden almacenar e organizar, por exemplo, a información sobre usuarios dunha rede e os recursos da mesma.LDAP xunto con Kerberos forma o núcleo do sistema de Active Directory de Microsoft Windows, e de moitas outras implementacións como Novell eDirectory ou o RedHat Directory Service.

As bases de datos LDAP teñen forma de árbore, dandolle ao administrador a posibilidade de crear as distintas ramas (DIT, Directory Information Tree), especificando en primeiro lugar a raíz da árbore, que normalmente é o dominio da organización, como pode ser dc=iesrodeira, dc=com (dc é unha abreviatura de Domain Component).

Todas as entradas LDAP teñen tipo. Cada DN pertence a un objectClass que identifica o tipo de información que representa. Ademáis, cada entrada consiste en múltiples atributos na forma de parellas chave=valor, donde cada entrada está definida por un attributeType.

Os objectClasses e attributeTypes están definidos en ficheiros de esquema. O administrador de LDAP decidirá que esquemas incluirá na súa árbore baseandose nas necesidades das aplicacións que fagan uso do DIT

As distintas entradas na árbore LDAP se representan habitualmente en formato LDIF (LDAP Data Interchange Format) que indican o nome (dn) da nova entrada e os seus atributos.

Realizaremos unha instalación de OpenLDAP para almacenar a base de datos dos usuarios do sistema e dos servicios Kerberos, e configuraremos os clientes do modo apropiado.

Instalación de OpenLDAP

1.- Instalamos OpenLDAP

 apt-get install slapd ldap-utils

2.-Configuramos de modo apropiado o ficheiro /etc/ldap/ldap.conf

  BASE    dc=iesrodeira,dc=com
  URI     ldap://krbldap-pdc.iesrodeira.com ldap://krbldap-bdc.iesrodeira.com
  TLS_CACERT      /etc/ssl/certs/ca-certificates.crt

3.- A configuración inicial por defecto do esquema LDAP é a seguinte:

root@krbldap-pdc:~/LDAP_configs# slapcat
dn: dc=iesrodeira,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: iesrodeira.com
dc: iesrodeira
structuralObjectClass: organization
entryUUID: 8cfe1ca6-cadc-1032-8ccb-2d2a52bafa1f
creatorsName: cn=admin,dc=iesrodeira,dc=com
createTimestamp: 20131016182851Z
entryCSN: 20131016182851.761222Z#000000#000#000000
modifiersName: cn=admin,dc=iesrodeira,dc=com
modifyTimestamp: 20131016182851Z

dn: cn=admin,dc=iesrodeira,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: e1NTSEF9ekxHT0c5bXpjWnAvRkFrUVRkc0IweVVHejczZFVHbU0=
structuralObjectClass: organizationalRole
entryUUID: 8d29617c-cadc-1032-8ccc-2d2a52bafa1f
creatorsName: cn=admin,dc=iesrodeira,dc=com
createTimestamp: 20131016182852Z
entryCSN: 20131016182852.044793Z#000000#000#000000
modifiersName: cn=admin,dc=iesrodeira,dc=com
modifyTimestamp: 20131016182852Z

E os esquemas instalados:

root@krbldap-pdc:~/LDAP_configs# ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: cn=config
dn: cn=module{0},cn=config
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,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

Activaremos un modo que nos deixe máis información nos logs, e creamos varios índices para mellorar as velocidades de busca. Creamos o seguinte ficheiro inicializa.ldif

# 1.
dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: stats

# 2.1.
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: uid eq
-
# 2.2.
add: olcDbIndex
olcDbIndex: cn eq
-
# 2.3.
add: olcDbIndex
olcDbIndex: ou eq
-
# 2.4.
add: olcDbIndex
olcDbIndex: dc eq

e o cargamos no esquema LDAP coa orde:

  ldapmodify -QY EXTERNAL -H ldapi:/// -f inicializa.ldif

Podemos verificar os cambios executando:

 ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config "(|(cn=config)(olcDatabase={1}hdb))"

Replicación no BDC

A replicación se realiza co módulo Syncrepl. Syncrepl permite que os cambios se envíen seguindo un modelo proveedor-consumidor. O proveedor enviará os cambios do directorio LDAP aos consumidores. Instalaremos o servidor secundario:

  apt-get install slapd ldap-utils

e configuramos de modo apropiado o ficheiro /etc/ldap/ldap.conf

  BASE    dc=iesrodeira,dc=com
  URI     ldap://krbldap-bdc.iesrodeira.com ldap://krbldap-pdc.iesrodeira.com
  TLS_CACERT      /etc/ssl/certs/ca-certificates.crt

En primeiro lugar será necesario crear no servidor primario (productor)un obxecto de tipo organizationalRole no servidor primario (productor) para representar o secundario (consumidor). Crearemos un ficheiro consumer_role.ldif co seguinte contido:

dn: cn=krbldap-bdc,dc=iesrodeira,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: krbldap-bdc
description: LDAP replicator
userPassword: {SSHA}2jOUxdjQthjBS5Ot3/YlAo+IHJ1nbACi

O campo userPassword será a saída da execución de slappasswd -u, que nos devolverá a password cifrada

Engadiremos consumer_role.ldif a árbore ldap (no primario):

  ldapadd -cxWD cn=admin,dc=example,dc=com -f consumer_role.ldif

Necesitaremos autorizar no servidor primario (proveedor) o acceso ao secundario, para eso creamos o ficheiro consumer_auth.ldif co seguinte contido:

# 1.1.1.
dn: olcDatabase={1}hdb,cn=config
changetype: modify
delete: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange
  by self write
  by anonymous auth
  by dn="cn=admin,dc=iesrodeira,dc=com" write
  by * none
-
# 1.1.2.
add: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange
  by self write
  by dn="cn=admin,dc=iesrodeira,dc=com" write
  by dn="cn=krbldap-bdc,dc=iesrodeira,dc=com" read
  by anonymous auth
  by * none
-
# 1.2.
add: olcDbIndex
olcDbIndex: entryUUID eq
-
# 1.3.
add: olcDbIndex
olcDbIndex: entryCSN eq

# 2.
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: {1}syncprov

# 3.
dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpCheckpoint: 100 10
olcSpSessionlog: 100

Instalaremos o ldif co comando:

ldapmodify -QY EXTERNAL -H ldapi:/// -f consumer_auth.ldif

No servidor secundario (consumer) crearemos varios índices para acelerar o acceso, aumentaremos o nivel de log e indicaremos que active Syncreply para sincronizar a súa base de datos co productor. Para facer esto, creamos o arquivo consumer.ldif:

# 1.
dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: stats

# 2.1.1.
dn: olcDatabase={1}hdb,cn=config
changetype: modify
delete: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange
  by self write
  by anonymous auth
  by dn="cn=admin,dc=iesrodeira,dc=com" write
  by * none
-
# 2.1.2.
add: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange
  by anonymous auth
  by * none
-
# 2.2.1.
delete: olcAccess
olcAccess: {2}to *
  by self write
  by dn="cn=admin,dc=iesrodeira,dc=com" write
  by * read
-
# 2.2.2.
add: olcAccess
olcAccess: {2}to *
  by * read
-
# 2.3.
replace: olcRootDN
olcRootDN: cn=manager
-
# 2.4.
delete: olcRootPW
-
# 2.5.
add: olcDbIndex
olcDbIndex: entryCSN eq
-
# 2.6.
add: olcDbIndex
olcDbIndex: entryUUID eq
-
# 2.7.
add: olcDbIndex
olcDbIndex: uid eq
-
# 2.8.
add: olcDbIndex
olcDbIndex: cn eq
-
# 2.9.
add: olcDbIndex
olcDbIndex: ou eq
-
# 2.10.
add: olcDbIndex
olcDbIndex: dc eq
-
# 2.11.
add: olcSyncrepl
olcSyncrepl: rid=123
  provider="ldap://krbldap-pdc.iesrodeira.com:389/"
  type=refreshAndPersist
  retry="60 30 300 +"
  searchbase="dc=iesrodeira,dc=com"
  bindmethod=simple
  binddn="cn=krbldap-bdc,dc=iesrodeira,dc=com"
  credentials=xxxxxxxxxx

As credentials son a userPassword indicada no productor na autorización, pero en texto claro

Si as actualizacións da base de datos non son moi frecuentes, unha alternativa a anterior para a configuración Syncreply sería:

# 2.11. (alternative)
add: olcSyncrepl
olcSyncrepl: rid=123
  provider="ldap://krbldap-pdc.iesrodeira.com:389/"
  type=refreshOnly
  interval=00:00:05:00
  searchbase="dc=iesrodeira,dc=com"
  bindmethod=simple
  binddn="cn=krbldap-bdc,dc=iesrodeira,dc=com"
  credentials=xxxxxxxxx

Introducimos os cambios, paramos o servizo, eliminamos a base de datos vella, e iniciamos de novo o servizo:

ldapmodify -QY EXTERNAL -H ldapi:/// -f ~/olc-mod1.ldif
/etc/init.d/slapd stop
rm /var/lib/ldap/*
/etc/init.d/slapd start

Podemos comprobar o funcionamento executando no servidor secundario (consumidor):

root@krbldap-bdc:~# ldapsearch -x -LLL
dn: dc=iesrodeira,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: iesrodeira.com
dc: iesrodeira

dn: cn=admin,dc=iesrodeira,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator

dn: cn=krbldap-bdc,dc=iesrodeira,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: krbldap-bdc
description: LDAP replicator

Por defecto, os servidores LDAP secundarios non permiten a modificación da súa base de datos. Polo tanto, é necesario configurar o sistema para que redirixa as peticións de modificación ao servidor primario.

Agora poderíamos ir engadindo no servidor LDAP os esquemas que precisemos. Por exemplo, o seguinte esquema userschema.ldif serviría para almacenar usuarios do sistema:

dn: ou=people,dc=iesrodeira,dc=com
ou: people
objectClass: organizationalUnit

dn: ou=groups,dc=iesrodeira,dc=com
ou: groups
objectClass: organizationalUnit

O engadiríamos mediante a orde:

ldapadd -cxWD cn=admin,dc=iesrodeira,dc=com -f userschema.ldif

Posteriormente poderíamos ir engadindo usuarios ao sistema mediante ldif similares a novouser.ldif:

dn: cn=profes,ou=groups,dc=iesrodeira,dc=com
cn: profes
gidNumber: 20000
objectClass: top
objectClass: posixGroup

dn: uid=xavi,ou=people,dc=iesrodeira,dc=com
uid: xavi
uidNumber: 20000
gidNumber: 20000
cn: Francisco Javier
sn: Taboada Aguado
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
loginShell: /bin/bash
homeDirectory: /home/xavi
userPassword: secretpassword

que incluiríamos mediante:

ldapadd -cxWD cn=admin,dc=iesrodeira,dc=com -f novouser.ldif

Enlace Kerberos-LDAP

Listado de esquemas

ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn

Insertar o Esquema Kerberos en LDAP

Cambiar configuración

ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config "(|(cn=config)(olcDatabase={1}hdb))"

Borrar conta administrador LDAP (Se administra coa conta Kerberos)

ldapdelete -xh localhost -D cn=admin,dc=example,dc=com -w arietans cn=admin,dc=example,dc=com

Modificar configuracion kerberos

Configurar logs

Engadir entradas LDAP para Kerberos

Cifrar a password con slappasswd -h {SHA} -s

Crear o Realm

kdb5_ldap_util -D cn=admin,dc=example,dc=com -H ldap://kls1.example.com create -r EXAMPLE.COM -s

Crear password para admin en kdc-srv service.keyfile

kdb5_ldap_util -D cn=admin,dc=example,dc=com stashsrvpw -f /etc/krb5kdc/service.keyfile cn=kdc-srv,ou=krb5,dc=example,dc=com

Idem para adm-srv

kdb5_ldap_util -D cn=admin,dc=example,dc=com stashsrvpw -f /etc/krb5kdc/service.keyfile cn=adm-srv,ou=krb5,dc=example,dc=com

Engadir principal admin

kadmin.local

Modificamos o tempo de vida dos tickets

modprinc -maxlife "1 day" -maxrenewlife "90 day" krbtgt/EXAMPLE.COM@EXAMPLE.COM e modificamos /etc/krb5kdc/kdc.conf

Iniciamos o servidor Kerberos

/etc/init.d/krb5-admin-server start ; /etc/init.d/krb5-kdc start

Engadir o principal ldap/servidorldap

addprinc && ktadd

Kerberizar Slapd

apt-get install libsasl2-modules-gssapi-mit

Comprobar que /etc/krb5.keytab ten os permisos axeitados

~# chmod 640 /etc/krb5.keytab && chown root.openldap /etc/krb5.keytab

indicar o keytab en /etc/default/slapd

export KRB5_KTNAME=/etc/krb5.keytab

Indicar mecanismo de autenticación en /etc/ldap/ldap.conf

SASL_MECH GSSAPI

Mapear os usuarios LDAP cos usuarios GSSAPI modificando a database ldap

ldapadd -xWD cn=admin,dc=example,dc=com -f ~/people-groups.ldif

Modifiar a base de datos LDAP para o seu uso con GSSAPI

ldapmodify -QY EXTERNAL -H ldapi:/// -f ~/olc-mod2.ldif

Reiniciar LDAP

Fontes:

• http://www.rjsystems.nl/en/2100-d6-kerberos-openldap-provider.php
• http://www.rjsystems.nl/en/2100-d6-kerberos-openldap-consumer.php