1

In DNS domain

domain.local.

there are two machines

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.

There's an unidirectional trust between RC.DOMAIN.LOCAL and DOMAIN.LOCAL:

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

but not vice-versa.

The KDC for RC.DOMAIN.LOCAL on srv1 have been set up with an OpenLDAP- backend according to

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

with its OpenLDAP backend on host.domain.local, reachable by

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

There is also a local OpenLDAP installed (but diabled) on srv1, thus there exist local ldap.conf etc. on srv1 to be taken into consideration.


When I start the KDC on srv1 manually in a (srv1) root session

root@srv1:~# krb5kdc

everything works fine.


When I attempt to start the KDC on srv1 by the system init scripts

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

or

root@srv1:~# service krb5-kdc start

a TLS dialog between the krb5kdc on srv1 and the slapd on host fails; the combined syslog is

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

The /etc/ldap/ldap.conf on srv1 is

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  

thus that mostly refers to the srv1-local slapd, but it's, as far as applicable, on the successful manual krb5kdc start on srv1 overridden by the effective

.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

and by the dbmodules section of /etc/krb5kdc/kdc.conf on 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

yields

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

and

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

yields

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

srv1 runs with 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

The Debian-conformant point for additional KDC configuration is /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

As you can see from that, I tried to manually rebuild a propoer TLS environment for the KDC startup script, but to no avail yet.

So - why does the KDC work perfectly from an interactive root shell, but fails from the init script and what to do about the latter?

0

It appears that the OpenLDAP-backed KDC simply needs a the CA certificate located

in a valid ssl certificate directory,

where it can find its server's keys and certs as well, e.g. /etc/ssl on my srv1 box; e.g. altering the TLS_CACERT entry in

/etc/ldap/ldap.conf

to

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

made the init script working.

That's not the only measure that would work, one could e.g. also try and set

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

in /etc/krb5kdc/kdc.conf (untested) or add

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

to Debian's /etc/default/krb5-kdc (tested).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.