☰

Servidores OpenLDAP y Kerberos en Ubuntu Server 22.04; Krb5 no está creando /var/lib/krb5kdc/principal

tag-icon • tag-icon ubuntu openldap kerberos
Servidores OpenLDAP y Kerberos en Ubuntu Server 22.04; Krb5 no está creando /var/lib/krb5kdc/principal

Tengo un servidor openldap existente en Ubuntu Server 22.04 y estoy intentando configurar un servidor kerberos con él, siguiendo esta guía:https://ubuntu.com/server/docs/service-kerberos-with-openldap-backend

Las cuentas se crean y se prueban, funcionan bien (las hago referencia mediante cn, pero tienen un uid; primero las creé en Apache Directory Studio). Hice "dpkg-reconfigure krb5-config" y edité /etc/krb5.conf para agregar mi servidor y mi dominio. Una cosa que no está en ese documento pero que he visto en otros lugares es crear una sección "[domain_realm]" y agregarle mi dominio, lo cual hice pero no ayudó. Creé una sección de registro, que requiere modificar los servicios de systemd para permitir la escritura en /var/log/kerberos, pero está bien. Luego ejecuto el comando "kdb5_ldap_util" como se indica y, después de ingresar las contraseñas, parece que se completa correctamente. Guardo las contraseñas de kdc-service y kadmin-service, y se completa con éxito. Creo el archivo kadm.acl, eso está bien, luego, cuando intento iniciar el servicio, aparece esto en krb5kdc.log:

krb5kdc[712216](Error): Cannot find master key record in database - while fetching master keys list for realm SUBDOMAIN.DOMAIN.COM

Si luego ejecuto "kadmin.local", obtengo lo siguiente:

Authenticating as principal root/[email protected] with password.
kadmin.local: Cannot find master key record in database while initializing kadmin.local interface

Resulta que el archivo /var/lib/krb5kdc/principal nunca se crea. No estoy seguro de qué más solucionar aquí, pero en este punto estoy estancado y agradecería cualquier orientación. Archivos de configuración a continuación, con el dominio y el subdominio modificados:

/etc/krb5.conf:

[libdefaults]
        default_realm = SUBDOMAIN.DOMAIN.COM

# The following krb5.conf variables are only for MIT Kerberos.
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true

# The following encryption type specification will be used by MIT Kerberos
# if uncommented.  In general, the defaults in the MIT Kerberos code are
# correct and overriding these specifications only serves to disable new
# encryption types as they are added, creating interoperability problems.
#
# The only time when you might need to uncomment these lines and change
# the enctypes is if you have local software that will break on ticket
# caches containing ticket encryption types it doesn't know about (such as
# old versions of Sun Java).

#       default_tgs_enctypes = des3-hmac-sha1
#       default_tkt_enctypes = des3-hmac-sha1
#       permitted_enctypes = des3-hmac-sha1

# The following libdefaults parameters are only for Heimdal Kerberos.
        fcc-mit-ticketflags = true

[logging]
        kdc = FILE:/var/log/kerberos/krb5kdc.log
        admin_server = FILE:/var/log/kerberos/kadmin.log
        default = FILE:/var/log/kerberos/krb5lib.log

[realms]
        SUBDOMAIN.DOMAIN.COM = {
                kdc = hostname.subdomain.domain.com
                admin_server = hostname.subdomain.domain.com
                default_domain = subdomain.domain.com
                database_module = openldap_ldapconf
        }

[domain_realm]
        .subdomain.domain.com = SUBDOMAIN.DOMAIN.COM
        subdomain.domain.com = SUBDOMAIN.DOMAIN.COM

[dbdefaults]
        ldap_kerberos_container_dn = cn=krbContainer,dc=subdomain,dc=domain,dc=com

[dbmodules]
        openldap_ldapconf = {
                db_library = kldap

                # if either of these is false, then the ldap_kdc_dn needs to
                # have write access
                disable_last_success = true
                disable_lockout  = true

                # this object needs to have read rights on
                # the realm container, principal container and realm sub-trees
                ldap_kdc_dn = "cn=kdc-service,ou=accounts,dc=subdomain,dc=domain,dc=com"

                # this object needs to have read and write rights on
                # the realm container, principal container and realm sub-trees
                ldap_kadmind_dn = "cn=kadmin-service,ou=accounts,dc=subdomain,dc=domain,dc=com"

                ldap_service_password_file = /etc/krb5kdc/service.keyfile
                ldap_servers = ldapi:///
                ldap_conns_per_server = 5
        }

/etc/krb5kdc/kadm5.acl:

*/[email protected] *

/etc/krb5kdc/kdc.conf:

[kdcdefaults]
    kdc_ports = 750,88

[realms]
    SUBDOMAIN.DOMAIN.COM = {
        database_name = /var/lib/krb5kdc/principal
        admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
        acl_file = /etc/krb5kdc/kadm5.acl
        key_stash_file = /etc/krb5kdc/stash
        kdc_ports = 750,88
        max_life = 10h 0m 0s
        max_renewable_life = 7d 0h 0m 0s
        master_key_type = des3-hmac-sha1
        #supported_enctypes = aes256-cts:normal aes128-cts:normal
        default_principal_flags = +preauth
    }

Editar: según el comentario del usuario1686, ahora puedo ver que tengo un posible problema de acceso a las cuentas. Estoy un poco loco con este artículo, pero al usar 'slapcat -b cn=config' tengo las siguientes reglas de olcAccess:

olcAccess: {0}to * by dn="cn=admin,dc=subdomain,dc=domain,dc=com" manage by dn="cn=surfrock66,ou=accounts,dc=subdomain,dc=domain,dc=com" manage by dn="cn=ldapbinduser,ou=accounts,dc=subdomain,dc=domain,dc=com" read by * break
olcAccess: {1}to dn.children="ou=accounts,dc=subdomain,dc=domain,dc=com" attrs=userPassword,shadowExpire,shadowInactive,shadowLastChange,shadowMax,shadowMin,shadowWarning by self write by anonymous auth
olcAccess: {2}to attrs=krbPrincipalKey by anonymous auth by dn.exact="cn=kdc-service,ou=accounts,dc=subdomain,dc=domain,dc=com" read by dn.exact="cn=kadmin-service,ou=accounts,dc=subdomain,dc=domain,dc=com" write by self write by * none
olcAccess: {3}to dn.subtree="cn=krbContainer,dc=subdomain,dc=domain,dc=com" by dn.exact="cn=kdc-service,ou=accounts,dc=subdomain,dc=domain,dc=com" read by dn.exact="cn=kadmin-service,ou=accounts,dc=subdomain,dc=domain,dc=com" write by * none
olcAccess: {4}to dn.subtree="dc=subdomain,dc=domain,dc=com" by self read

2022.12.08-08-36 PST Editar: Estoy mucho más lejos e hice lo siguiente:

addprinc ldap/[email protected]
ktadd -k /etc/ldap/kerberos.ldap.hostname.subdomain.domain.com.keytab ldap/hostname.subdomain.domain.com
chown openldap:openldap /etc/ldap/kerberos.ldap.hostname.subdomain.domain.com.keytab
chmod 640 /etc/ldap/kerberos.ldap.hostname.subdomain.domain.com.keytab

Edité /etc/default/slapd y le agregué esto:

export KRB5_KTNAME="FILE:/etc/ldap/kerberos.ldap.hostname.subdomain.domain.com.keytab"

Cuando reinicié el servicio, testsaslauthd todavía funciona, pero ldapsearch -D no. Me pregunto si hay algún cambio de configuración que deba realizar en ldap. A partir de uno de los recursos con los que estaba trabajando, construí este ldif para la configuración, pero al final no creo entender qué hará y si era correcto:

dn: cn=config
changetype: modify
add: olcSaslHost
olcSaslHost: hostname.subdomain.domain.com
-
add: olcSaslRealm
olcSaslRealm: SUBDOMAIN.DOMAIN.COM
-
add: olcAuthzRegexp
olcAuthzRegexp: {0}"cn=([^/]*),cn=subdomain.domain.com,cn=GSSAPI,cn=auth" "cn=$1,ou=accounts,dc=subdomain,dc=domain,dc=com"
-
add: olcAuthzRegexp
olcAuthzRegexp: {1}"cn=host/([^/]*).subdomain.domain.com,cn=subdomain.domain.com,cn=GSSAPI,cn=auth" "cn=$1,ou=hosts,dc=subdomain,dc=domain,dc=com"
-
add: olcAuthzRegexp
olcAuthzRegexp: {2}"uid=ldap/admin,cn=subdomain.domain.com,cn=GSSAPI,cn=auth" "cn=admin,dc=subdomain,dc=domain,dc=com"

¿Creo que este es el último paso que falta? ¿Algo en la configuración apunta LDAP a sasl? ¿O estoy abordando todo esto mal?

Respuesta1

principales el archivo que contiene la base de datos KDC en formato DB2. No se crea en su sistema porque estáno usandoel db2backend: estás usando LDAP, que reemplazatodoalmacenamiento local para el KDC, por lo que un archivo de base de datos local es innecesario e irrelevante para el problema que tiene.

Si lo ha ejecutado kdb5_ldap_util createsegún las instrucciones, debería comprobar mediante LDAP si realmente ha creado las entradas necesarias; debería haber, como mínimo, una entrada para K/M@<realm>y otra para krbtgt/<realm>@<realm>. El mensaje de error se refiere a la entrada "K/M", que es un pseudoprincipal que contiene la clave m de la base de datos (que está cifrada con la contraseña de "clave maestra").

Asegúrese de verificar LDAP usando la cuenta del KDC, en caso de que no se le hayan otorgado los privilegios necesarios para leer los objetos LDAP de Kerberos. (Las cuentas nonecesidadtener un fluido; sólo se utilizan como cuentas vinculadas LDAP, no como cuentas Unix locales).

Como Ubuntu a veces usa AppArmor, asegúrese de verificar dmesgsi hay mensajes de denegación de AVC; podría ser que el KDC no pueda leer "service.keyfile" o acceder a su socket OpenLDAP.

Además, habilite el statsnivel de registro en su servidor LDAP para que registre todas las consultas; esto podría, por ejemplo, revelar que el KDC está buscando en un DN diferente (normalmente "ldap_kerberos_container_dn" se configuraría junto a otros parámetros de dbmodules).

Finalmente, si strace kadmin.localmuestra que la herramienta en realidad no se está conectando a LDAP sino que intenta acceder a un archivo db2 local, entonces es posible que tenga una configuración en kdc.conf(el archivo de configuración específico de KDC) que anule la configuración de todo el sistema en krb5. conf. Normalmente, la configuración de KDC se carga desde /var/lib/krb5kdc/kdc.confla configuración global de krb5.conf y tiene prioridad sobre ella.

(Además, si ustederanAl usar db2, la base de datos principal aún no se creará automáticamente en el primer inicio; esto debe hacerse manualmente ejecutando kdb5_util create [-s]y proporcionando la clave de cifrado maestra, tal como lo hizo para el backend LDAP usando "kdb5_ldap_util create").

Una cosa que no está en ese documento pero que he visto en otros lugares es crear una sección "[domain_realm]" y agregarle mi dominio, lo cual hice pero no ayudó.

Esto solo es necesario para los clientes Kerberos cuando obtienen tickets para un nombre de host que no se asigna 1:1 a su dominio (el ejemplo típico es mit.edu → ATHENA.MIT.EDU). No tiene relevancia para la puesta en marcha del KDC.

Creé una sección de registro, que requiere modificar los servicios de systemd para permitir la escritura en /var/log/kerberos.

No es así si inicia sesión SYSLOG, lo que probablemente fue la intención de quien escribió los servicios systemd para Ubuntu.

¿No está ahí ya que mi almacenamiento está en LDAP?

No, el archivo /etc/krb5.keytab no forma parte de la base de datos KDC, pertenece alanfitrióncomo "miembro del dominio" y almacena el equivalente a la contraseña Kerberos de la cuenta de la máquina. Cada máquina en su dominio Kerberos debe tener su propio /etc/krb5.keytab con al menos el host/<fqdn>principal.

Estoy intentando que la autenticación de paso a través de LDAP funcione para que la contraseña de Kerberos sea la real; Estoy encontrando que mucha de la documentación es más antigua. Veo que la mayoría de la gente recomienda saslauthd, que creo que configuré, pero ahora está buscando /etc/krb5.keytab

Para OpenLDAP, sí, generalmente necesitas saslauthd.

  1. Al vincularse a un DN que tiene userPassword: {SASL}foo@BAR, slapd utilizará las funciones de "verificación de contraseña" de libsasl.
  2. Dependiendo de lo configuradométodo_pwcheck, libsasl se comunicará con saslauthd para verificar la contraseña.
  3. saslauthd utilizará el backend configurado a través de su -aopción para realizar la verificación real.
  4. Con el -a krb5backend, saslauthd intentará obtener un ticket Kerberos inicial de un KDC con el nombre de usuario y la contraseña proporcionados (equivalente a kinit).
  5. Si se adquirió exitosamente un boleto inicial, saslauthd solicitará adicionalmente unbillete de servicio para sí mismoe intentará descifrarlo utilizando la tabla de claves de la máquina.
  6. Si se pudo adquirir el ticket de servicioy descifrado,se acepta la contraseña.

El último paso es necesario para evitar ataques de suplantación de identidad del KDC. Tradicionalmente, los KDC de Kerberos emitían tickets sin validar su contraseña (una contraseña incorrecta simplemente significaba que el cliente no podía descifrar el ticket recibido) y un KDC malicioso aún puede hacerlo; la "preautorización" no es obligatoria a nivel de protocolo. Por lo tanto, saslauthd necesita hacer lo mismo que cualquier otro servicio kerberizado para verificar que el ticket es legítimo: intentar descifrarlo usando una tabla de claves de servicio. (Tanto pam_krb5 como incluso Windows hacen lo mismo durante los inicios de sesión de AD).

Creé host/hostname.fqdn@REALM y ldap/hostname.fqdn@REALM. Creé una tabla de claves para ldap; Convertí el pase de 1 usuario a "{SASL}nombre@REALM". Al usar testaslauthd en ese usuario, obtengo éxito. Al usar ldapsearch en ese usuario, créditos no válidos. ¿Creo que ldap no está hablando con saslauthd? En "Autenticación Kerberos" aquí agregué las configuraciones: help.ubuntu.com/community/OpenLDAPServer pero cuando hago "ldapsearch -Y GSSAPI" aparece "Error GSSAPI: No se admitieron credenciales...

-Y GSSAPIesdirectoAutenticación Kerberos: completamente independiente de saslauthd y paso de contraseña. Es decir, slapd ni siquiera recibe una contraseña Kerberos – sólo recibe una contraseña Kerberos.boletoy lo valida internamente con su tabla de claves de servicio.

  1. Para SASL GSSAPI, el servicio slapd en sí (no saslauthd) necesita una tabla de claves para ldap/<fqdn>. (De forma predeterminada, todos los servicios buscan sus claves en el sistema /etc/krb5.keytab, pero podría ser mejor para la seguridad mantener las cosas separadas y configurar KRB5_KTNAME de slapd en una ruta diferente; de ​​esa manera, no es necesario que lea acceso a la tabla de claves del sistema.)

  2. El cliente también necesitasaberque está destinado a solicitar un ticket para ldap/<fqdn>, por lo que conectarse a una dirección IP probablemente no funcione (a menos que tenga configurado el rDNS adecuado); debería conectarse específicamente a ldap://<fqdn>. (Es un problema muy similar a TLS SNI o nombres de host en certificados TLS).

    En caso de duda, exporte KRB5_TRACE=/dev/stderrantes de llamar al cliente para determinar para qué principal está intentando realizar un TGS-REQ (o consulte los registros de KDC o una captura de red).

  3. El cliente ya debe tener elinicialTicket Kerberos (krbtgt/REALM) presente, es decir, debes hacerlo kinitpreviamente. Si aún no tienes un TGT, los clientes Kerberosno preguntarépara su contraseña: inmediatamente no podrán autenticarse.

El paso de contraseña sólo es relevante para enlaces "simples" ( ldapsearch -D <user_dn> -W) y para enlaces SASL PLAIN. Pruebe primero el enlace "simple" (principalmente puede ignorar SASL PLAIN).

Respuesta2

Debe instalar libsasl2 en su sistema operativo y ceder la propiedad de su krb5.keytab al usuario de openldap.

en debian:

sudo apto instalar libsasl2-2 libsasl2-modules-gssapi-mit

y luego

sudo chown openldap:openldap /etc/krb5.keytab u otra tabla de claves

Editar: pero tenga cuidado con varias pestañas de claves en la misma máquina/contenedor (con múltiples servidores).

información relacionada