☰

Sincronización LDAP con autenticación Kerberos

tag-icon • tag-icon ldap replication openldap kerberos
Sincronización LDAP con autenticación Kerberos

Estoy intentando configurar un servidor de replicación para LDAP usando syncrepl. Me gustaría usar Kerberos para autenticar al consumidor, porque lo tenemos configurado y parece más seguro. Las definiciones de la base de datos para mi proveedor y consumidor se encuentran a continuación.

Cuando inicio el consumidor, aparece este error:

GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information 
(Credentials cache file '/tmp/krb5cc_55' not found)

Creo que esto significa que el consumidor no tiene un TGT válido. ¿Cómo configuro al consumidor para que obtenga un TGT válido? He leído algunas fuentes antiguas que recomiendan usar k5start o un trabajo cron. ¿Sigue siendo esta la manera de hacerlo?

Las páginas del manual de slapd.conf indican que authcidy authzidse puede usar junto con bindmethod=sasl, pero no especifica cómo se deben formatear. ¿Debería poner aquí un DN o un principal de Kerberos o tal vez algo más? ¿Necesito especificarlos?

gracias por su ayuda

Configuración del consumidor:

database        bdb
suffix          "dc=example"
rootdn          "uid=someuser,cn=realm,cn=gssapi,cn=auth"
directory       /var/lib/ldap
dirtyread
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
syncrepl rid=1
    provider=ldap://provider.realm
    type=refreshAndPersist
    starttls=yes
    searchbase="dc=example"
    schemachecking=off
    bindmethod=sasl
    saslmech=gssapi
    retry="10 +"

Configuración del proveedor

database        bdb
suffix          "dc=example"
rootdn          "uid=someuser,cn=realm,cn=gssapi,cn=auth"
directory       /var/lib/ldap
dirtyread
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100

Respuesta1

Creo que esto significa que el consumidor no tiene un TGT válido.

Sí, eso es exactamente lo que significa.

¿Cómo configuro al consumidor para que obtenga un TGT válido? He leído algunas fuentes antiguas que recomiendan usar k5start o un trabajo cron. ¿Sigue siendo esta la manera de hacerlo?

No estoy seguro acerca de cron, pero k5start sigue siendo un buen método.

Pero el reciente MIT Kerberos admite un método integrado llamadoiniciación de tabla de claves del cliente, que es mucho más sencillo de configurar: simplemente agréguelo $KRB5_CLIENT_KTNAMEal entorno de slapd y apúntelo al mismo archivo que $KRB5_KTNAME. (Esto supone que tiene una tabla de claves separada para ldap/*. Debería hacerlo).

Y finalmente puedes decirle a slapd que use gss-proxy, que es como ssh-agent para Kerberos. Establezca GSS_USE_PROXY=1y configure /etc/gssproxy para reconocer slapd como iniciador (cliente) y aceptador (servidor).

Las páginas del manual de slapd.conf indican que authcid y authzid se pueden usar junto con bindmethod=sasl, pero no especifica cómo se deben formatear. ¿Debería poner aquí un DN o un principal de Kerberos o tal vez algo más? ¿Necesito especificarlos?

No recuerdo con qué propósitoautenticidadsirve con GSSAPI (si corresponde): IIRC, este mecanismo utiliza automáticamente la identidad determinada a partir de su ticket, por lo que no es necesario especificarla manualmente.

En el lado de aceptación, slapd convertirá el principal de Kerberos recibido en un pseudo-DN como uid=foo@realm,cn=gssapi,cn=auth, y podrá usarlo directamente en las ACL o usarautenticación-regexp(también conocido comoolcAuthzRegexp) para traducirlo a un DN más agradable.

Mientras tanto,autenticidadFunciona de la misma manera independientemente del mecanismo. Es opcional, pero si lo especifica, debe ser un DN con el prefijo dn:, o un nombre de usuario con el prefijo u:. (Los nombres de usuario aquí, como authcids, se convierten en un pseudo-DN y pasan porolcAuthzRegexpy se utiliza el DN resultante).

Si las políticas lo permiten, entonces slapd le otorgará los privilegios que tiene el authzid. (Es como sudo para LDAP).

Respuesta2

Obtuve syncrepl con autenticación Kerberos trabajando con la siguiente configuración.Este sitio webacerca de nslcd.conf dice que authziddebería tener el formato "dn:<nombre distinguido>" o "u:<nombre de usuario>". También utilicé k5start para crear un archivo de caché para someuser@REALMat /tmp/krb5cc_55y lo hice chown ldap:ldap. Tenga en cuenta que 55 es el fluido ldap; sin embargo, no estoy seguro de que sea necesario nombrar el archivo con este nombre. En la configuración de mi proveedor, especifiqué someuserpara rootdnpermitirle tener acceso a toda la base de datos.

Solo quiero aclarar que esto es lo que funcionó para mí, pero tengo un conocimiento limitado de ldap, por lo que no puedo garantizar que funcione en otros lugares y no sé si todo lo que hay en esta configuración es necesario.

syncrepl rid=1
    provider=ldap://provider.realm
    type=refreshAndPersist
    starttls=yes
    searchbase="dc=realm"
    schemachecking=off
    retry="10 +"
    tls_cacert="/path/to/ca.crt"
    bindmethod=sasl
    saslmech=gssapi
    authcid="someuser@REALM"
    authzid="uid=someuser,cn=realm,cn=gssapi,cn=auth"

información relacionada