¿Cómo configuro Reverse Group Membership Maintenance en un servidor openldap? (miembro de)


18

Actualmente estoy trabajando en la integración de la autenticación LDAP en un sistema y me gustaría restringir el acceso basado en el grupo LDAP. La única forma de hacerlo es a través de un filtro de búsqueda y, por lo tanto, creo que mi única opción es utilizar el atributo "memberOf" en mi filtro de búsqueda. Entiendo que el atributo "memberOf" es un atributo operativo que el servidor puede crear para mí en cualquier momento que se cree un nuevo atributo "member" para cualquier entrada "groupOfNames" en el servidor. Mi objetivo principal es poder agregar un atributo "miembro" a una entrada existente "groupOfNames" y agregar un atributo "memberOf" coincidente al DN que proporciono.

Lo que he logrado hasta ahora:

Todavía soy bastante nuevo en la administración de LDAP, pero según lo que encontré en la guía del administrador de openldap, parece que Reverse Group Membership Maintence, también conocido como "memberof overlay", lograría exactamente el efecto que estoy buscando.

Mi servidor está ejecutando actualmente una instalación de paquete (slapd en ubuntu) de openldap 2.4.15 que utiliza la configuración de tiempo de ejecución de estilo "cn = config". La mayoría de los ejemplos que he encontrado todavía hacen referencia al antiguo método "slapd.conf" de configuración estática y he hecho todo lo posible para adaptar las configuraciones al nuevo modelo basado en directorios.

He agregado las siguientes entradas para habilitar el módulo memberof overlay:

Habilite el módulo con olcModuleLoad

cn=config/cn\=module\{0\}.ldif

dn: cn=module{0}
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb
olcModuleLoad: {1}memberof.la
structuralObjectClass: olcModuleList
entryUUID: a410ce98-3fdf-102e-82cf-59ccb6b4d60d
creatorsName: cn=config
createTimestamp: 20090927183056Z
entryCSN: 20091009174548.503911Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20091009174548Z

Habilitó la superposición para la base de datos y le permitió usar su configuración predeterminada (groupOfNames, member, memberOf, etc.)

cn=config/olcDatabase={1}hdb/olcOverlay\=\{0\}memberof

dn: olcOverlay={0}memberof
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: {0}memberof
structuralObjectClass: olcMemberOf
entryUUID: 6d599084-490c-102e-80f6-f1a5d50be388
creatorsName: cn=admin,cn=config
createTimestamp: 20091009104412Z
olcMemberOfRefInt: TRUE
entryCSN: 20091009173500.139380Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20091009173500Z

Mi resultado actual:

Al usar la configuración anterior, puedo agregar un NUEVO "groupOfNames" con cualquier número de entradas "miembro" y tener todos los DN involucrados actualizados con un atributo "memberOf". Esto es parte del comportamiento que esperaría. Si bien creo que lo siguiente debería haberse logrado con el miembro de superposición, todavía no sé cómo hacer lo siguiente y con gusto agradecería cualquier consejo:

  1. Agregue un atributo "member" a un "groupOfNames" EXISTENTE y haga que se cree automáticamente el atributo "memberOf" correspondiente.
  2. Elimine un atributo "member" y haga que el atributo "memberOf" correspondiente se elimine automáticamente.

Respuestas:


10

He estado luchando con lo mismo, la documentación de openldap es minimalista y difícilmente útil. Cuando pasaron a una base de datos de configuración (no es una mala idea en principio), todas las opciones cambiaron, por lo que cuando la gente da ejemplos de /etc/ldap/slapd.conf es inútil con una configuración moderna de slapd (como Ubuntu).

Finalmente conseguí que esto funcionara. Aquí está el resumen ... primer archivo LDIF:

dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib/ldap
olcModuleLoad: memberof

Segundo archivo LDIF:

dn: olcOverlay=memberof,olcDatabase={1}hdb,cn=config
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf

Agréguelos a la base de datos de configuración usando ldapadd (igual que el material de configuración normal).

No actualiza automáticamente los datos existentes en la base de datos, por lo que necesitaba usar slapcat para copiar todo en un archivo temporal y visitar cada grupo, eliminar el grupo y volver a agregar el mismo grupo (obliga a los atributos memberOf a actualizarse) correctamente). Si está comenzando con una base de datos vacía, actualizará correctamente los atributos a medida que se agreguen los objetos.

Además, tenga en cuenta que "olcDatabase = {1} hdb" es muy típico, pero no se garantiza que coincida con su configuración. Asegúrese de verificar eso.


1
¿No es slapadd(en la base de datos detenida) la forma correcta de hacerlo?
mad_vs

11

Escribí sobre esto recientemente en mi blog, www.jordaneunson.com. Copié y pegué las partes relevantes.

Lo que tenía que hacer era detener el servicio "slapd" en mi servidor LDAP y editar mi archivo slapd.conf y agregar las siguientes dos líneas.

moduleload memberof.la
overlay memberof

Ya tenía un groupOfNames llamado vpn, así que tuve que crear un archivo LDIF con el siguiente contenido:

dn: cn=vpn,ou=Groups,dc=shop,dc=lan
objectclass: groupofnames
cn: vpn
description: Users allowed to connect on VPN
member: uid=jordan,ou=People,dc=shop,dc=lan

Y agregué esto a mi base de datos ldap

slapadd -f file.ldif

Después de esto, encendí el servidor ldap en depuración para verificar si hay errores

slapd -d 99 -f /etc/ldap/slapd.conf 

y comprobé para asegurarme de que mi membresía de grupo de "vpn" figuraba en mi entrada de usuario.

ldapsearch -h ldap -x -b "dc=shop,dc=lan" '(uid=jordan)' memberOf 

y bam! ¡éxito!

jordan, People, shop.lan
dn: uid=jordan,ou=People,dc=shop,dc=lan
memberOf: cn=vpn,ou=Groups,dc=shop,dc=lan

Así que volví a activar el servicio slapd y tuve mucho éxito desde entonces. Para una nueva herramienta de administración de GUI, estoy usando phpLDAPAdmin y no tengo problemas con el atributo memberOf asignado y sin asignar a mis usuarios.

Una última cosa a tener en cuenta es que el atributo "memberOf" no es parte del esquema básico LDAP v3 y, por lo tanto, realizar una búsqueda de ldap no revelará este atributo a menos que se lo consulte específicamente. Es por eso que en mi ejemplo anterior se declara al final de los parámetros de ldapsearch.

Espero que esto ayude.

Editar: Acabo de probar su problema con Apache Directory Studio: siempre que ingrese el valor del miembro de atributo en su conjunto como se mencionó anteriormente, funciona A-OK. Sin embargo, el atributo memberOf no aparece en la entrada del usuario. Esto se debe a que el atributo memberOf no forma parte del esquema LDAPv3. Para verificar que está allí, use la herramienta de línea de comandos ldapsearch:

ldapsearch -h ldap -x -b "dc=shop,dc=lan" '(uid=jordan)' memberOf 

1
Lamentablemente, cargar el módulo y agregar la superposición es exactamente lo que hice. Como dije, el problema no es que los atributos "memberOf" no se agreguen para las nuevas entradas groupOfNames, es que no se agregan cuando simplemente agrego un atributo "member" a un grupo existente. Actualmente estoy usando Apache Directory Studio para navegar y configurar mi LDAP para que muestre las entradas de memberOf cuando navego. No se trata de que estén ocultos.
emills

1
¿Cómo está creando el atributo de miembro en groupOfNames? ¿Está usando todo el DN? como: "uid = user, ou = People, dc = corp, dc = org" o ¿simplemente está ingresando su nombre de usuario? Para que la asignación inversa funcione, debe utilizar todo el DN para que memberOf sepa dónde colocar la asignación inversa.
Jordan Eunson el

1
Editar: Acabo de probar su problema con Apache Directory Studio, siempre que ingrese el valor del miembro de atributo en su conjunto como se mencionó anteriormente, funciona A-OK. Sin embargo, el atributo memberOf no aparece en la entrada del usuario. Esto se debe a que el atributo memberOf no forma parte del esquema LDAPv3. Para verificar que está allí, use la herramienta de línea de comandos ldapsearch. <code> ldapsearch -h ldap -x -b "dc = shop, dc = lan" '(uid = jordan)' memberOf </code>
Jordan Eunson el

1
Estoy usando el DN en la entrada de miembro. No es cuestión de no verlo, como ya dije, solo se agregan (y, por lo tanto, son visibles) con un nuevo groupOfNames, no cuando agrego un atributo de miembro a un grupo existente.
Emills

1
<quote> solo se agregan (y por lo tanto son visibles) </quote> Lo siento, pero esta afirmación es incorrecta. El atributo memberOf no está visible a menos que lo consulte específicamente. ¿Podría publicar la salida del comando ldapsearch mencionado anteriormente? Cambie el usuario a uno que debería tener un atributo memberOf pero no lo tiene.
Jordan Eunson
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.