Debian

帶有 OpenLDAP 後端的 MIT Kerberos - 當 KDC 以互動方式啟動但初始化腳本失敗時，TLS 正常

  • September 29, 2015

在 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,

但反之亦然。

srv1 上 RC.DOMAIN.LOCAL 的 KDC 已根據

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

其 OpenLDAP 後端位於 host.domain.local 上，可通過

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

srv1 上還安裝了一個本地 OpenLDAP（但已禁用），因此需要考慮 srv1 上存在本地 ldap.conf 等。

當我在 (srv1) 根會話中手動啟動 srv1 上的 KDC

root@srv1:~# krb5kdc

一切正常。

當我嘗試通過系統初始化腳本在 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}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

因此，這主要是指 srv1-local slapd，但在適用的情況下，它是在 srv1 上成功的手動 krb5kdc 啟動被有效覆蓋

.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

附加 KDC 配置的 Debian 兼容點是 /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

正如你所看到的，我嘗試為 KDC 啟動腳本手動重建一個合適的 TLS 環境，但還沒有成功。

那麼 - 為什麼 KDC 可以在互動式 root shell 中完美執行，但在 init 腳本中失敗以及如何處理後者？

看來，OpenLDAP 支持的 KDC 只需要一個位於

在有效的ssl 證書目錄中，

它還可以在哪裡找到其伺服器的密鑰和證書，例如/etc/ssl在我的 srv1 盒子上；例如更改 TLS_CACERT 條目

/etc/ldap/ldap.conf

到

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

使初始化腳本工作。

這不是唯一可行的措施，例如也可以嘗試設置

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

在/etc/krb5kdc/kdc.conf（未經測試）或添加

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

到 Debian 的/etc/default/krb5-kdc（已測試）。

引用自：https://serverfault.com/questions/724984

相關問答

Debian

Postfix TLS over SMTP - RCPT TO 提示重新協商，然後 554 5.5.1 錯誤：沒有有效的收件人

  • February 10, 2022
檢視問答
Openldap

KDC 在向 OpenLDAP 進行身份驗證時不支持加密類型

  • February 10, 2022
檢視問答
Debian

關於 Debian OpenDLAP 配置的問題

  • December 13, 2021
檢視問答
Debian

Postfix STARTTLS 僅在埠 25 上

  • December 11, 2021
檢視問答
Debian

軟體包安全更新檔是否向後移植到舊版本？

  • December 2, 2021
檢視問答
Debian

OpenLDAP 複製錯誤

  • June 3, 2021
檢視問答