In der DNS-Domäne
domain.local.
Es gibt zwei Maschinen
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.
Es besteht eine unidirektionale Vertrauensstellung zwischen RC.DOMAIN.LOCAL und DOMAIN.LOCAL:
RC.DOMAIN.LOCAL ===trusts===> tickets from DOMAIN.LOCAL,
aber nicht umgekehrt.
Die KDC für RC.DOMAIN.LOCAL auf srv1 wurden mit einem OpenLDAP-Backend gemäß
http://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_ldap.html
mit seinem OpenLDAP-Backend auf host.domain.local, erreichbar über
ldaps://host.domain.local:636.
Auf srv1 ist auch ein lokales OpenLDAP installiert (aber deaktiviert), daher gibt es auf srv1 eine lokale ldap.conf usw., die berücksichtigt werden muss.
Wenn ich den KDC auf srv1 manuell in einer (srv1) Root-Sitzung starte
root@srv1:~# krb5kdc
alles funktioniert einwandfrei.
Wenn ich versuche, den KDC auf srv1 über die Systeminitskripte zu starten
root@srv1:~# /etc/init.d/krb5-kdc start
oder
root@srv1:~# service krb5-kdc start
ein TLS-Dialog zwischen dem krb5kdc auf srv1 und dem slapd auf dem Host schlägt fehl; das kombinierte Syslog ist
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
Die Datei /etc/ldap/ldap.conf auf srv1 lautet
rootdn "cn=admin,cn=config"
rootpw {SASL}[email protected]
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
das bezieht sich also meistens auf den srv1-lokalen slapd, aber es wird, soweit anwendbar, beim erfolgreichen manuellen krb5kdc-Start auf srv1 durch den effektiven
.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
und durch den Abschnitt dbmodules von /etc/krb5kdc/kdc.conf auf 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
Erträge
SASL/EXTERNAL authentication started
SASL username: cn=root.srv1.domain.local,ou=...
SASL SSF: 0
dn:cn=admin,cn=config
Und
root@srv1:~# ldapsearch -b "" -s base -LLL supportedSASLMechanisms
Erträge
SASL/EXTERNAL authentication started
SASL username: cn=root.srv1.domain.local,ou=...
SASL SSF: 0
dn:
supportedSASLMechanisms: EXTERNAL
srv1 läuft mit 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
Der Debian-konforme Punkt für zusätzliche KDC-Konfiguration ist /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
Wie Sie sehen, habe ich versucht, manuell eine ordnungsgemäße TLS-Umgebung für das KDC-Startskript neu zu erstellen, aber bisher ohne Erfolg.
Also: Warum funktioniert das KDC von einer interaktiven Root-Shell aus einwandfrei, schlägt aber vom Init-Skript aus fehl, und was kann man dagegen tun?
Antwort1
Es scheint, dass das OpenLDAP-gestützte KDC lediglich ein CA-Zertifikat benötigt, das sich befindet
in einemgültigSSL-Zertifikatsverzeichnis,
wo es auch die Schlüssel und Zertifikate seines Servers finden kann, z. B. /etc/sslauf meiner srv1-Box; z. B. durch Ändern des TLS_CACERT-Eintrags in
/etc/ldap/ldap.conf
Zu
#[...]
TLS_CACERT /etc/ssl/certs/cacert.pem
#[...]
hat das Init-Skript zum Laufen gebracht.
Das ist nicht die einzige Maßnahme, die funktionieren würde, man könnte beispielsweise auch versuchen,
[dbmodules]
LDAP = {
# [...]
ldap_cert_path = ...
# [...]
}
in /etc/krb5kdc/kdc.conf(ungetestet) oder hinzufügen
LDAPTLS_CACERT=/etc/ssl/certs/cacert.pem
zu Debian /etc/default/krb5-kdc(getestet).