使用OpenLDAP后端的MIT Kerberos – 当KDC以交互方式启动但初始化脚本失败时，TLS正常

在DNS域中

domain.local. 

有两台机器

 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. 

RC.DOMAIN.LOCAL和DOMAIN.LOCAL之间存在单向信任关系：

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

但反之亦然。

• 根据原始子网输出不同接口的stream量
• 在Debian Proftpd – 文件传输的麻烦
• 不能在debian wheezy中启动systemd
• 是firewalld阻止返回stream量？
• 在Debian 8上为curl / openssl连接安装中间证书。

在srv1上的RC.DOMAIN.LOCAL的KDC已经build立了一个OpenLDAP-后端根据

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

其OpenLDAP后端位于host.domain.local中，可通过

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

在srv1上也安装了一个本地的OpenLDAP（但是是diabled），因此在srv1上存在本地的ldap.conf等。

当我在（srv1）根会话中手动启动srv1上的KDC时

 root@srv1:~# krb5kdc 

一切正常。

当我尝试通过系统init脚本在srv1上启动KDC时

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

要么

 root@srv1:~# service krb5-kdc start 

srv1上的krb5kdc与主机上的slapd之间的TLS对话框失败; 组合的系统日志是

 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 

srv1上的/etc/ldap/ldap.conf是

 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 

因此，这主要是指srv1本地slapd，但它是，在适用的情况下，成功的手动krb5kdc启动srv1覆盖的有效

 .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 

并通过srv1上的/etc/krb5kdc/kdc.conf的dbmodules部分

 [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 

产量

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

和

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

产量

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

srv1运行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 

符合Debian标准的其他KDCconfiguration是/ 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 

正如你所看到的，我试图手动重buildKDC启动脚本的propoer TLS环境，但还没有结果。

所以 – 为什么KDC能够在一个交互式的根shell中完美的工作，但是在初始化脚本中却没有成功，后者又该怎么办呢？

 /etc/ldap/ldap.conf 

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

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

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