Ver o código fonte de "Kerberos+LDAP+NFSv4"

=Kerberos=
[[Image:Kerberos.png|center|Diálogo Kerberos de Acceso a Servidor NFS]]
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.

{{boxinfo | 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 <u>Servidor de Autenticación ('''SA''')</u> e o <u>Servidor de Tickets de Acceso ('''TGS''')</u> 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''.

<ol start='6'><li>Cando o cliente precise un servicio, necesitará solicitarllo ao ''TGS'' mediante as seguintes mensaxes:</li></ol>
::;'''Mensaxe C''': Composta polo '''TGT''' e a ID do servicio solicitado.
{{boxinfo|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'''.
<ol start='7'><li>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''</li></ol>
<ol start='8'><li>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</li></ol>
<ol start='9'><li>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''.</li></ol>
<ol start='10'><li>''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''.</li></ol>
<ol start='11'><li>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.</li></ol>
==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. <u>Se recomenda a versión 5 de Kerberos</u>, 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.

{{boxinfo|Para utilizar as ferramentas administrativas como '''kadmin''' e <u>imprescindible</u> 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:

#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''

<ol start='2'><li>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</li></ol>

  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

<ol start='3'><li>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:</li></ol>

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

<ol start='4'><li>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.</li></ol>

::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'').

{{boxinfo|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

<ol start='5'><li>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.</li></ol>

  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

{{boxinfo|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
::#Creamos o ficheiro cos controladores Kerberos do noso ''reino'' en '''/etc/krb5kdc/kpropd.acl''' <u>nos dous controladores</u>. O contido será o seguinte:
   host/krbldap-pdc.iesrodeira.com@IESRODEIRA.COM
   host/krbldap-bdc.iesrodeira.com@IESRODEIRA.COM
::<ol start='2'><li>No '''<u>controlador primario</u>''' creamos un backup da base de datos Kerberos e a enviamos ao ''controlador secundario''</li></ol>
   kdb5_util dump /var/lib/krb5kdc/slave_datatrans
   kprop krbldap-bdc.iesrodeira.com
::<ol start='3'><li>De volta no '''<u>controlador secundario</u>''' creamos un ficheiro cunha copia da chave mestra Kerberos:</li></ol>
   kdb5_util stash
::<ol start='4'><li>Xa podemos iniciar o servizo co comando '''service krb5-kdc start'''</li></ol>

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 [[wikipedia:cron|cron]]. Crearemos o ficheiro ''/etc/cron.hourly/krb5-prop'' co seguinte contido:
<source lang='bash'>
  #!/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
</source>

=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 [[wikipedia:Active Directory|Active Directory]] de [[wikipedia:Microsoft Windows|Microsoft Windows]], e de moitas outras implementacións como [[wikipedia:Novell eDirectory|Novell eDirectory]] ou o [[wikipedia:389_Directory_Server|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''. 

{{boxinfo|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 [[wikipedia:OpenLDAP|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
<source lang='text'>
 apt-get install slapd ldap-utils
</source>

2.-Configuramos de modo apropiado o ficheiro ''/etc/ldap/ldap.conf''
<source lang='text'>
  BASE    dc=iesrodeira,dc=com
  URI     ldap://krbldap-pdc.iesrodeira.com ldap://krbldap-bdc.iesrodeira.com
  TLS_CACERT      /etc/ssl/certs/ca-certificates.crt
</source>

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

<source lang='text'>
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
</source>
: E os esquemas instalados:
<source lang='text'>
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
</source>

: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'' 
<source lang='text'>
# 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
</source>

:e o cargamos no esquema ''LDAP'' coa orde:
<source lang='text'>
  ldapmodify -QY EXTERNAL -H ldapi:/// -f inicializa.ldif
</source>
:Podemos verificar os cambios executando:
<source lang='text'>
 ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config "(|(cn=config)(olcDatabase={1}hdb))"
</source>
=== 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:

<source lang='text'>
  apt-get install slapd ldap-utils
</source>

:e configuramos de modo apropiado o ficheiro ''/etc/ldap/ldap.conf''
<source lang='text'>
  BASE    dc=iesrodeira,dc=com
  URI     ldap://krbldap-bdc.iesrodeira.com ldap://krbldap-pdc.iesrodeira.com
  TLS_CACERT      /etc/ssl/certs/ca-certificates.crt
</source>

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

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

{{boxinfo|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 (<u>no primario</u>):
<source lang='text'>
  ldapadd -cxWD cn=admin,dc=example,dc=com -f consumer_role.ldif
</source>
:Necesitaremos autorizar <u>no servidor primario (''proveedor'')</u> o acceso ao secundario, para eso creamos o ficheiro ''consumer_auth.ldif'' co seguinte contido:
<source lang='text'>
# 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
</source>
:Instalaremos o ''ldif'' co comando:
<source lang='text'>
ldapmodify -QY EXTERNAL -H ldapi:/// -f consumer_auth.ldif
</source>
:No <u>servidor secundario (''consumer'')</u> 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'':
<source lang='text'>
# 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
</source>
{{boxinfo|As '''credentials''' son a ''userPassword'' indicada no ''productor'' na autorización, pero en <u>texto claro</u>}}

: Si as actualizacións da base de datos non son moi frecuentes, unha alternativa a anterior para a configuración ''Syncreply'' sería:
<source lang='text'>
# 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
</source>
:Introducimos os cambios, paramos o servizo, eliminamos a base de datos vella, e iniciamos de novo o servizo:
<source lang='text'>
ldapmodify -QY EXTERNAL -H ldapi:/// -f ~/olc-mod1.ldif
/etc/init.d/slapd stop
rm /var/lib/ldap/*
/etc/init.d/slapd start
</source>

:Podemos comprobar o funcionamento executando no <u>servidor secundario</u> (''consumidor''):
<source lang='text'>
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

</source>

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:
<source lang='text'>
dn: ou=people,dc=iesrodeira,dc=com
ou: people
objectClass: organizationalUnit

dn: ou=groups,dc=iesrodeira,dc=com
ou: groups
objectClass: organizationalUnit
</source>

O engadiríamos mediante a orde:
<source lang='text'>
ldapadd -cxWD cn=admin,dc=iesrodeira,dc=com -f userschema.ldif
</source>

Posteriormente poderíamos ir engadindo usuarios ao sistema mediante ''ldif'' similares a ''novouser.ldif'':
<source lang='text'>
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
</source>

que incluiríamos mediante:
<source lang='text'>
ldapadd -cxWD cn=admin,dc=iesrodeira,dc=com -f novouser.ldif
</source>

== 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

=NFSv4=
[[Category:Artigos]]