En dominio DNS
domain.local.
hay dos maquinas
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.
Existe una confianza unidireccional entre RC.DOMAIN.LOCAL y DOMAIN.LOCAL:
RC.DOMAIN.LOCAL ===trusts===> tickets from DOMAIN.LOCAL,
pero no al revés.
El KDC para RC.DOMAIN.LOCAL en srv1 se ha configurado con un backend OpenLDAP de acuerdo con
http://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_ldap.html
con su backend OpenLDAP en host.domain.local, accesible por
ldaps://host.domain.local:636.
También hay un OpenLDAP local instalado (pero desactivado) en srv1, por lo que existe un ldap.conf local, etc. en srv1 que debe tenerse en cuenta.
Cuando inicio el KDC en srv1 manualmente en una sesión raíz (srv1)
root@srv1:~# krb5kdc
todo funciona bien.
Cuando intento iniciar el KDC en srv1 mediante los scripts de inicio del sistema
root@srv1:~# /etc/init.d/krb5-kdc start
o
root@srv1:~# service krb5-kdc start
falla un diálogo TLS entre krb5kdc en srv1 y slapd en el host; 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 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
El /etc/ldap/ldap.conf en srv1 es
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
por lo tanto, eso se refiere principalmente al slapd srv1-local, pero, en la medida de lo aplicable, el inicio manual exitoso de krb5kdc en srv1 es 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
rendimientos
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
rendimientos
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 compatible con Debian para una configuración 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 puede ver, intenté reconstruir manualmente un entorno TLS adecuado para el script de inicio de KDC, pero aún fue en vano.
Entonces, ¿por qué el KDC funciona perfectamente desde un shell raíz interactivo, pero falla desde el script de inicio y qué hacer al respecto?
Respuesta1
Parece que el KDC respaldado por OpenLDAP simplemente necesita un certificado de CA ubicado
en unválidodirectorio de certificados ssl,
donde también puede encontrar las claves y los certificados de su servidor, por ejemplo, /etc/sslen mi caja srv1; por ejemplo, alterar la entrada TLS_CACERT en
/etc/ldap/ldap.conf
a
#[...]
TLS_CACERT /etc/ssl/certs/cacert.pem
#[...]
hizo que el script de inicio funcionara.
Esta no es la única medida que funcionaría; por ejemplo, también se podría intentar establecer
[dbmodules]
LDAP = {
# [...]
ldap_cert_path = ...
# [...]
}
en /etc/krb5kdc/kdc.conf(no probado) o agregar
LDAPTLS_CACERT=/etc/ssl/certs/cacert.pem
a Debian /etc/default/krb5-kdc(probado).