MIT Kerberos con backend de OpenLDAP – TLS ok cuando KDC comenzó interactivamente pero el script de init falla

En el dominio DNS

domain.local. 

hay dos máquinas

 host.domain.local. = 192.168.1.1 srv1.domain.local. = 192.168.1.2 host.domain.local. is KDC for Kerberos realm DOMAIN.LOCAL, srv1.domain.local. is a KDC for Kerberos realm RC.DOMAIN.LOCAL. 

Hay una confianza unidireccional entre RC.DOMAIN.LOCAL y DOMAIN.LOCAL:

 RC.DOMAIN.LOCAL ===trusts===> tickets from DOMAIN.LOCAL, 

pero no viceversa.

El KDC para RC.DOMAIN.LOCAL en srv1 se ha configurado con un OpenLDAP-backend según

http://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_ldap.html

con su backend de OpenLDAP en host.domain.local, accesible por

 ldaps://host.domain.local:636. 

También hay un OpenLDAP local instalado (pero deshabilitado) en srv1, por lo que existe ldap.conf local, etc. en srv1 para ser tomado en consideración.


Cuando inicio el KDC en srv1 manualmente en una session raíz (srv1)

 root@srv1:~# krb5kdc 

todo funciona bien.


Cuando bash iniciar el KDC en srv1 por los scripts de init del sistema

 root@srv1:~# /etc/init.d/krb5-kdc start 

o

 root@srv1:~# service krb5-kdc start 

un dialog TLS entre el krb5kdc en srv1 y el slapd en host falla; el syslog combinado es

 14:46:44 host.domain.local slapd[1778]: daemon: activity on 1 descriptor 14:46:44 host.domain.local slapd[1778]: slap_listener_activate(6): 14:46:44 srv1 krb5kdc[3206]: krb5kdc: cannot initialize realm RC.DOMAIN.LOCAL - see log file for details 14:46:44 host.domain.local slapd[1778]: >>> slap_listener(ldaps://192.168.1.1:636/) 14:46:44 host.domain.local slapd[1778]: daemon: listen=6, new connection on 10 14:46:44 host.domain.local slapd[1778]: daemon: added 10r (active) listener=(nil) 14:46:44 host.domain.local slapd[1778]: conn=1037 fd=10 ACCEPT from IP=192.168.1.2:38664 (IP=192.168.1.1:636) 14:46:44 host.domain.local slapd[1778]: daemon: select: listen=6 active_threads=0 tvp=NULL 14:46:44 host.domain.local slapd[1778]: daemon: select: listen=7 active_threads=0 tvp=NULL 14:46:44 host.domain.local slapd[1778]: daemon: activity on 1 descriptor 14:46:44 host.domain.local slapd[1778]: daemon: waked 14:46:44 host.domain.local slapd[1778]: daemon: select: listen=6 active_threads=0 tvp=NULL 14:46:44 host.domain.local slapd[1778]: daemon: activity on 1 descriptor 14:46:44 host.domain.local slapd[1778]: daemon: activity on: 14:46:44 host.domain.local slapd[1778]: 10r 14:46:44 host.domain.local slapd[1778]: 14:46:44 host.domain.local slapd[1778]: daemon: read activity on 10 14:46:44 host.domain.local slapd[1778]: connection_get(10): got connid=1037 14:46:44 host.domain.local slapd[1778]: connection_read(10): checking for input on id=1037 14:46:44 host.domain.local slapd[1778]: connection_read(10): TLS accept failure error=-1 id=1037, closing 14:46:44 host.domain.local slapd[1778]: connection_closing: readying conn=1037 sd=10 for close 14:46:44 host.domain.local slapd[1778]: connection_close: conn=1037 sd=10 14:46:44 host.domain.local slapd[1778]: daemon: removing 10 14:46:44 host.domain.local slapd[1778]: daemon: activity on 1 descriptor 14:46:44 host.domain.local slapd[1778]: slap_listener_activate(6): 14:46:44 host.domain.local slapd[1778]: >>> slap_listener(ldaps://192.168.1.1:636/) 14:46:44 host.domain.local slapd[1778]: daemon: listen=6, new connection on 10 14:46:44 host.domain.local slapd[1778]: daemon: added 10r (active) listener=(nil) 14:46:44 host.domain.local slapd[1778]: conn=1038 fd=10 ACCEPT from IP=192.168.1.2:38666 (IP=192.168.1.1:636) 14:46:44 host.domain.local slapd[1778]: daemon: select: listen=6 active_threads=0 tvp=NULL 14:46:44 host.domain.local slapd[1778]: daemon: select: listen=7 active_threads=0 tvp=NULL 14:46:44 host.domain.local slapd[1778]: daemon: activity on 1 descriptor 14:46:44 host.domain.local slapd[1778]: daemon: waked 14:46:44 host.domain.local slapd[1778]: daemon: select: listen=6 active_threads=0 tvp=NULL 14:46:44 srv1 systemd[1]: krb5-kdc.service: control process exited, code=exited status=1 14:46:44 srv1 systemd[1]: Failed to start Kerberos 5 Key Distribution Center. 14:46:44 srv1 systemd[1]: Unit krb5-kdc.service entenetworking failed state. 14:46:44 host.domain.local slapd[1778]: daemon: activity on 1 descriptor 14:46:44 host.domain.local slapd[1778]: daemon: activity on: 14:46:44 host.domain.local slapd[1778]: 10r 14:46:44 host.domain.local slapd[1778]: 14:46:44 host.domain.local slapd[1778]: daemon: read activity on 10 14:46:44 host.domain.local slapd[1778]: connection_get(10): got connid=1038 14:46:44 host.domain.local slapd[1778]: connection_read(10): checking for input on id=1038 14:46:44 host.domain.local slapd[1778]: connection_read(10): TLS accept failure error=-1 id=1038, closing 14:46:44 host.domain.local slapd[1778]: connection_closing: readying conn=1038 sd=10 for close 14:46:44 host.domain.local slapd[1778]: connection_close: conn=1038 sd=10 14:46:44 host.domain.local slapd[1778]: daemon: removing 10 

El /etc/ldap/ldap.conf en srv1 es

 rootdn "cn=admin,cn=config" rootpw {SASL}admin@DOMAIN.LOCAL BASE dc=domain,dc=local URI ldaps://127.0.0.1:636/ ldapi:/// TLS_CACERT /etc/ldap/ssl/cacert.pem TLS_REQCERT allow SASL_MECH EXTERNAL 

por lo que se refiere principalmente a la srv1-local slapd, pero es, en la medida en que sea aplicable, en el exitoso manual krb5kdc start en srv1 anulado por el efectivo

 .ldaprc for root@srv1: URI ldaps://host.domain.local:636 TLS_REQCERT demand SASL_MECH EXTERNAL TLS_CACERT /root/secret/cacert.pem TLS_CERT /root/secret/root.srv1.domain.local-cert.pem TLS_KEY /root/secret/private/root.srv1.domain.local-key.pem 

y por la sección dbmodules de /etc/krb5kdc/kdc.conf en srv1

 [dbmodules] LDAP = { db_library = kldap ldap_kdc_sasl_mech = EXTERNAL ldap_kdc_dn = cn=krb5kdc,dc=rc,dc=domain,dc=local ldap_kadmind_dn = cn=kadmind,dc=rc,dc=domain,dc=local ldap_service_password_file = /etc/krb5kdc/ldap_stash ldap_kerberos_container_dn = cn=realm,dc=rc,dc=domain,dc=local #ldap_servers = ldap://host.domain.local:389 ldap_servers = ldaps://host.domain.local:636 } root@srv1:~# ldapwhoami 

performances

 SASL/EXTERNAL authentication started SASL username: cn=root.srv1.domain.local,ou=... SASL SSF: 0 dn:cn=admin,cn=config 

y

 root@srv1:~# ldapsearch -b "" -s base -LLL supportedSASLMechanisms 

performances

 SASL/EXTERNAL authentication started SASL username: cn=root.srv1.domain.local,ou=... SASL SSF: 0 dn: supportedSASLMechanisms: EXTERNAL 

srv1 se ejecuta con amd64 Debian 8 "jessie":

 krb5-kdc-ldap 1.12.1+dfsg-19 ldap-utils 2.4.40+dfsg-1+deb8u1 libaprutil1-ldap 1.5.4-1 libkldap4 4:4.14.2-2+b1 libldap-2.4-2 2.4.40+dfsg-1+deb8u1 

El punto conforme a Debian para la configuration adicional de KDC es / etc / default / krb5-kdc:

 # [...] DAEMON_ARGS="-r RC.DOMAIN.LOCAL" # LDAPNOINIT=1 # LDAPRC=.ldaprc # LDAPTLS_REQCERT=demand # #LDAPSASL_SECPROPS none #LDAPSASL_MECH=EXTERNAL #LDAPTLS_CACERT=/root/secret/cacert.pem #LDAPTLS_CERT=/root/secret/root.srv1.domain.local-cert.pem #LDAPTLS_KEY=/root/secret/private/root.srv1.domain.local-key.pem 

Como se puede ver a partir de eso, traté de rebuild manualmente un ambiente TLS propoer para el script de inicio de KDC, pero no sirvió todavía.

Entonces, ¿por qué el KDC funciona perfectamente desde una shell de raíz interactiva, pero falla en el script init y qué hacer con este último?

Parece que el KDC respaldado por OpenLDAP simplemente necesita un certificate de CA

en un directory válido de certificate ssl,

donde puede encontrar las keys y certificates de su server, por ejemplo, /etc/ssl en mi caja srv1; p. ej. alterando la input TLS_CACERT en

 /etc/ldap/ldap.conf 

a

 #[...] TLS_CACERT /etc/ssl/certs/cacert.pem #[...] 

hizo que el script de inicio funcionara.

Ésa no es la única medida que trabajaría, uno podría por ejemplo también intentar y fijar

 [dbmodules] LDAP = { # [...] ldap_cert_path = ... # [...] } 

en /etc/krb5kdc/kdc.conf (no probado) o agregue

 LDAPTLS_CACERT=/etc/ssl/certs/cacert.pem 

a Debian /etc/default/krb5-kdc (probado).