Tareas #3220

Tareas #3488: Investigación y coniguración OpenLdap

Configurar el LDAP

Added by Daniel Viñar Ulriksen about 8 years ago. Updated over 7 years ago.

Status:CerradaStart date:07/01/2014
Priority:AltaDue date:07/01/2014
Assignee:Cielito - LDAP% Done:

80%

Category:-Spent time:9.50 hours
Target version:-

Description

Estudiar las configuraciones y derechos de acceso en el servidor LDAP:

¿Cómo se definen los grupos? (Hay dos tipos: ya sea las entradas que tienen un mismo atributo, ya sea los objetos multi-valuados de DNs a entradas dle LDAP)
¿Como se atribuyen roles y derechos de accesos a diversas partes y/o a diversas funciones del contenido del LDAP?

¿Como aplicar todo esto para nuestra organización académica y en regiones?


Related issues

Related to Aprovisionamiento de Identidad - Tareas #3819: Investigar el manejo de permisos y grupos en Openldap Cerrada 12/21/2014
Follows Aprovisionamiento de Identidad - Tareas #2647: Instalar servidor LDAP Cerrada 02/18/2014 06/30/2014

History

#1 Updated by Germán Bianchi about 8 years ago

Me parece que lo mejor sería diseñar el árbol de directorios con toda la estructura universitaria del interior con OrganizationalUnits (que es mas o menos como está implementado ahora de manera muy básica). Después para cada uno de esos "nodos" se podrían crear GroupOfNames para definir los roles (por ejemplo grupos de administradores para el centro,región,superadministradores,etc) como atributos "member" de esos grupos.

Un bosquejo del DIT para esa solución seria algo así:

dc=interior,dc=udelar,dc=edu,dc=uy
--- Grupo
------ admins (Superadministradores)
--
--- RegEste (especificar Regiones?)
------ Grupo
--------- admins (Administradores Regionales)
------ CURE_Maldonado
--------- Grupo
------------ admins (Administradores por Sede)
--------- Area
------------ Personal
--------------- Usu1
--------------- Usu2
------------ Bedelía
--------------- Usu3
--------------- ...
------------ Administración
--------------- ...
------------ Informática
--------------- ...
(...)

También consideré que todos los usuarios estén en una OU "Gente" en cada Sede y se especifiquen como miembros de diferentes grupos (que serían las "Áreas"). Pero me parece mas intuitiva la opción anterior.

Después el control de acceso se puede hacer sobre los grupos creados editando las políticas de acceso en el fichero sldapd.conf.

Sobre esta idea estoy trabajando para asignarle derechos a los grupos sobre atributos y ramas...

#2 Updated by Andrés Pías about 8 years ago

En primer momento, veo lógico pensar estructurar el Directorio por servicios (CCI, CURE, Noroeste, Noreste).
Hay que ensamblar el LDAP a todos los servicios que usamos en el interior, esto tambien hay que considerarlo para la estructura.
Entonces, hacemos la gran división por servicios como comentas, donde cada uno es una unidad organizacional.

La gente se podría dar de alta y quedar todos registrados debajo de la OU Gente de raíz, aunque también se podría registrar dentro de las OU de cada región, lo único q habría que tener en cuenta que una misma persona puede ser miembro de grupos ubicados en diferentes lugares de la jerarquía y porque no dentro de diferentes OU. Entonces me parece un criterio mas uniforme registar todas las personas en la raíz, pero ambos criterios serían correctos, ya que ApacheDS permite crear grupos con miembros ubicados en diferentes lugares de la jerarquía.

Después dentro de Noroeste, por ejemplo tener otro OU para Paysandu y otra para Salto.
Dentro de Paysandu, se podría agregar un GroupOfNames (estuve creando uno para probar) Personas para referenciar a todas, agregando como vos decís atributos members para cada usuario.
También pienso en otro grupo para Nube que quedaría con el cn nube.paysandu.noroeste.udelar.edu.uy y que se emparejaría con el Owncloud a instalar en un futuro en el dominio nnube.paysandu.udelar.edu.uy.

En la raíz se podría crear otro GroupOfNames para Redmine, donde agregamos todos los usuarios en campos Members.

#3 Updated by Andrés Pías about 8 years ago

Disculpen la intromisión, en lo que tiene que ver con los dos últimos parrafos. Simplemente planteaba algunas ideas ejemplificando lo que se podría utilizar para los servicios. Con el aporte de todos llegaremos a la mejor solución.

Andrés Pías escribió:

Después dentro de Noroeste, por ejemplo tener otro OU para Paysandu y otra para Salto.
Dentro de Paysandu, se podría agregar un GroupOfNames (estuve creando uno para probar) Personas para referenciar a todas, agregando como vos decís atributos members para cada usuario.
También pienso en otro grupo para Nube que quedaría con el cn nube.paysandu.noroeste.udelar.edu.uy y que se emparejaría con el Owncloud a instalar en un futuro en el dominio nnube.paysandu.udelar.edu.uy.

En la raíz se podría crear otro GroupOfNames para Redmine, donde agregamos todos los usuarios en campos Members.

Pensando mejor en lo que dije antes:

La gente se podría dar de alta y quedar todos registrados debajo de la OU Gente de raíz, aunque también se podría registrar dentro de las OU de cada región, lo único q habría que tener en cuenta que una misma persona puede ser miembro de grupos ubicados en diferentes lugares de la jerarquía y porque no dentro de diferentes OU. Entonces me parece un criterio mas uniforme registar todas las personas en la raíz, pero ambos criterios serían correctos, ya que ApacheDS permite crear grupos con miembros ubicados en diferentes lugares de la jerarquía.

Lo mejor sería crear las cuentas de usuario como lo planteas dentro de cada Región/Sede, por el hecho de que después vamos a delegar a cada Sede la administración de las cuentas de ese subconjunto, para que ellos agreguen mas usuarios y creen grupos. Aquellos usuarios que pertenezcan a más de un Cenur, o que sean tranversales como nosotros, a esos sí los podríamos agreguegar en la OU Gente de raíz.

Ciudado con la divisón en Áreas ya que puede suceder que una misma persona esté trabajando en más de un área.

#4 Updated by Andrés Pías almost 8 years ago

  • Priority changed from Normal to Alta

Germán, pudiste avanzar con esto?. Espero que me intervención no te haya generado mas dudas.

#5 Updated by Germán Bianchi almost 8 years ago

No, lo de la estructura me quedó claro.
Ahora con lo que estoy luchando es con los permisos de los grupos sobre las distintas partes del árbol.
La idea es tener administradores por CENURES, superadministradores y derechos de los todos administradores sobre el OU Gente de la raiz (desde donde se van a distribuir los usuarios registrados).
El problema que estoy teniendo es que al crear las directivas de acceso en el slapd.conf, no impactan al reiniciar el servicio. Por lo que ví este fichero ya no se utiliza desde la versión 2.4.23-3 y ahora se hace a través del ldapmodify y es con este que estoy tratando ahora.
Igualmente, ví que en el slapd.conf se habían definido algunas configuraciones como

# Para intentar modificar el schema:
access to dn.subtree="cn=config" 
        by dn="cn=admin,dc=interior,dc=udelar,dc=edu,dc=uy" write
        by anonymous auth
        by * none

No se si esto fue una prueba o si alguna vez lo pudieron hacer funcionar (de ser así se podrían definir los permisos desde el sladp.conf)

#6 Updated by Daniel Viñar Ulriksen almost 8 years ago

Perdón, recién veo esto:

Me parece que lo mejor sería diseñar el árbol de directorios con toda la estructura universitaria del interior con OrganizationalUnits (que es mas o menos como está implementado ahora de manera muy básica). Después para cada uno de esos "nodos" se podrían crear GroupOfNames para definir los roles (por ejemplo grupos de administradores para el centro,región,superadministradores,etc) como atributos "member" de esos grupos.
Un bosquejo del DIT para esa solución seria algo así:
dc=interior,dc=udelar,dc=edu,dc=uy

De lo que sé de LDAP, me parece que no: para responder a las exigencias técnicas en muchomos casos, es necesario que el DN asociado a una cuenta (es decir a una persona) sea FIJO (eso queda registrado en bases de datos de las aplicaciones que usan la autenticación, por ejemplo). Y definitivamente, la gente dentro de la UdelaR se puede mover, cambiar de cargo.

Creo que el DIT (al menos en esta etapa) debe ser, al nivel siguiente, de tipo ou=gente, ou=groupos, ou=recursos
De todo lo que leí, es lo que se recomienda (pese a que hay mucha doc también sobre la organización jerárquica, pero es del orígen de DAP en las normas X500)

Mi solicitud inicial iba más a una exploración técnica: ver qué, en OpenLDAP (como backend) y ApacheDS (como cliente de admin) permiten organizar grupos y diferenciar roles de diferentes cuentas LDAP. (ahora todas las aplicaciones las conecté con la cuenta admin... )

#7 Updated by Daniel Viñar Ulriksen almost 8 years ago

Ahora con lo que estoy luchando es con los permisos de los grupos sobre las distintas partes del árbol.

bingo! sobre diferentes partes del arbol, y diferentes tipos de permiso (leer, escribir, autenticar, ...)

La idea es tener administradores por CENURES, superadministradores y derechos de los todos administradores sobre el OU Gente de la raiz (desde donde se van a distribuir los usuarios registrados).

como les decía, creo que no es bueno moverlos. Y, de facto, dada la forma de isncripción caen todos en el mismo ou=gente (creo que no hay otra con el pwm).

El problema que estoy teniendo es que al crear las directivas de acceso en el slapd.conf, no impactan al reiniciar el servicio. Por lo que ví este fichero ya no se utiliza desde la versión 2.4.23-3 y ahora se hace a través del ldapmodify y es con este que estoy tratando ahora.

Efectivamente, es ahí el meollo. Como construir los .ldif que permitan hacer las diferentes configuraciones que queremos, que se introducen con ese ldapmodify
No recuerdo bien hasta donde llegué con eso (poco o nada).

Igualmente, ví que en el slapd.conf se habían definido algunas configuraciones (...) No se si esto fue una prueba o si alguna vez lo pudieron hacer funcionar (de ser así se podrían definir los permisos desde el sladp.conf)

En versiones anteriores el slapd,conf solía funcionar, ahora no. Creo que esas modificaciones me confirmaron eso.

#8 Updated by Daniel Viñar Ulriksen almost 8 years ago

  • % Done changed from 0 to 10

#9 Updated by Daniel Viñar Ulriksen almost 8 years ago

  • Status changed from Nueva to En curso

#10 Updated by Andrés Pías almost 8 years ago

Daniel Viñar Ulriksen escribió:

La idea es tener administradores por CENURES, superadministradores y derechos de los todos administradores sobre el OU Gente de la raiz (desde donde se van a distribuir los usuarios registrados).

como les decía, creo que no es bueno moverlos. Y, de facto, dada la forma de inscripción caen todos en el mismo ou=gente (creo que no hay otra con el pwm).

Entonces de acuerdo a esto, estaba bien en lo que pensaba (que luego me corregí a mi mismo):

La gente se podría dar de alta y quedar todos registrados debajo de la OU Gente de raíz, ..., lo único q habría que tener en cuenta que una misma persona puede ser miembro de grupos ubicados en diferentes lugares de la jerarquía y porque no dentro de diferentes OU. Entonces me parece un criterio mas uniforme registrar todas las personas en la raíz, ya que Apache DS permite crear grupos con miembros ubicados en diferentes lugares de la jerarquía.

Cuando una persona de Tacuarembo por ejemplo se registre, luego alguien manualmente va a tener que agregarlo al grupo de personas del CUT. Este paso si tenemos que hacerlo si luego queremos delegar la administración de cuentas a los cenures. Por eso me parece que la división en servicios a través de OU aporta a la organización del directorio, pero no contendrían usuarios directamente, si no que a otras OUs o GroupOfNames.

Si una persona cambia de cargo, se puede borrar la persona de un grupo y agregarlo en otro mediante Apache Directory Studio, pero su cn nunca cambia.

Esto estructura además, lograría un emparejamiento más intuitivo de un cn (de un grupo) nube.paysandu.noroeste.udelar.edu.uy a un dominio nube.paysandu.udelar.edu.uy por ejemplo.

No tengo tanta experiencia con LDAP, no quiere generar más ruido, pero viene bien esta discusión.

#11 Updated by Germán Bianchi almost 8 years ago

Sigo intentando configurar los permisos en OpenLdap aunque sin éxito.
Por lo que pude averiguar y como lo mencioné anteriormente el fichero de configuración slapd.conf ya no está disponible (por defecto) desde la versión 2.4. Sin embargo, si se borra el directorio que genera la nueva configuración (sladp.d) debería utilizarlo pero en este caso solo evita que se vuelva a iniciar el servicio:

gbianchi@curie:/etc/ldap$ sudo service slapd start 
[FAIL] The pidfile for slapd has not been specified ... failed!

También probé crear el slapd.d a partir del archivo slapd.conf (que parece autogenerado por todas las directivas que tiene especificadas para PWM) pero también da error:

gbianchi@curie:/etc/ldap$ sudo slaptest -f slapd.conf -F slapd.d
53f5528a slapd.conf: line 50: bad DN "ou=gente,dc=interior,dc=udelar,dc=edu,dc=uy" in to DN clause
53f5528a <access clause> ::= access to <what> [ by <who> [ <access> ] [ <control> ] ]+ 
<what> ::= * | dn[.<dnstyle>=<DN>] [filter=<filter>] [attrs=<attrspec>]
<attrspec> ::= <attrname> [val[/<matchingRule>][.<attrstyle>]=<value>] | <attrlist>
<attrlist> ::= <attr> [ , <attrlist> ]
<attr> ::= <attrname> | @<objectClass> | !<objectClass> | entry | children
<who> ::= [ * | anonymous | users | self | dn[.<dnstyle>]=<DN> ]
    [ realanonymous | realusers | realself | realdn[.<dnstyle>]=<DN> ]
    [dnattr=<attrname>]
    [realdnattr=<attrname>]
    [group[/<objectclass>[/<attrname>]][.<style>]=<group>]
    [peername[.<peernamestyle>]=<peer>] [sockname[.<style>]=<name>]
    [domain[.<domainstyle>]=<domain>] [sockurl[.<style>]=<url>]
    [dynacl/<name>[/<options>][.<dynstyle>][=<pattern>]]
    [ssf=<n>] [transport_ssf=<n>] [tls_ssf=<n>] [sasl_ssf=<n>]
<style> ::= exact | regex | base(Object)
<dnstyle> ::= base(Object) | one(level) | sub(tree) | children | exact | regex
<attrstyle> ::= exact | regex | base(Object) | one(level) | sub(tree) | children
<peernamestyle> ::= exact | regex | ip | ipv6 | path
<domainstyle> ::= exact | regex | base(Object) | sub(tree)
<access> ::= [[real]self]{<level>|<priv>}
<level> ::= none|disclose|auth|compare|search|read|{write|add|delete}|manage
<priv> ::= {=|+|-}{0|d|x|c|s|r|{w|a|z}|m}+
<control> ::= [ stop | continue | break ]
dynacl:
    <name>=ACI    <pattern>=<attrname>

slaptest: bad configuration directory!

El DN parece correcto, sin embargo da error.
Tampoco ayuda la poca información que hay sobre la OLC de Openldap, por ahora me estoy basando en esto http://www.zytrax.com/books/ldap/ch6/slapd-config.html y lo que pueda encontrar en foros.

#12 Updated by Andrés Pías almost 8 years ago

Germán Bianchi escribió:

Sigo intentando configurar los permisos en OpenLdap aunque sin éxito.
Por lo que pude averiguar y como lo mencioné anteriormente el fichero de configuración slapd.conf ya no está disponible (por defecto) desde la versión 2.4. Sin embargo, si se borra el directorio que genera la nueva configuración (sladp.d) debería utilizarlo pero en este caso solo evita que se vuelva a iniciar el servicio:

> gbianchi@curie:/etc/ldap$ sudo service slapd start 
[FAIL] The pidfile for slapd has not been specified ... failed!

Hola Germán me parece que lo que venías haciendo era lo correcto (borrar el directorio).
El problema justamente que no encuentra el archivo pidfile. Mirando el archivo de configuración puedo ver que hay algo mal en la config:

pidfile     /var/run/slapd.pid
argsfile    /var/run/slapd.args

Me parece que se solucionaría modificando la config de esta manera:

pidfile     /var/run/slapd/slapd.pid

Lo que pasa es que sobre /var/run, openldap no tiene privilegios, si sobre el subdirectorio slapd:

apias@curie:/var/run$ ls -altr | grep openldap
drwxr-xr-x  2 openldap    openldap     100 sep 17 15:49 slapd

Fijate si con eso puede andar.
Estuve mirando por arriba otros 2 tutos interesantes, uno para Centos y otro para Debian

#13 Updated by Germán Bianchi almost 8 years ago

Gracias por los piques!!!
Lo de configurar desde el slapd.conf no lo pude hacer funcionar pero con los tutoriales que me pasaste y consultando algunos otros sitios pude modificar las ACL con OLC, ahora los usuarios pertenecientes al grupo admins tienen derechos de administrador sobre el árbol.
De la misma manera se pueden agregar los permisos para las diferentes ramas, voy a hacer pruebas con eso.

#14 Updated by Andrés Pías almost 8 years ago

  • Parent task set to #3488

#15 Updated by Germán Bianchi almost 8 years ago

  • % Done changed from 10 to 40

Se agregó en la wiki como manejar los permisos con OLC.
También pude hacer que un usuario tenga derechos de administrador sobre una rama especifica del árbol de directorios.

#16 Updated by Andrés Pías over 7 years ago

  • Status changed from En curso to Resuelta
  • Assignee changed from Germán Bianchi to Cielito - LDAP
  • % Done changed from 40 to 80

Esto está resuelto.

#17 Updated by Andrés Pías over 7 years ago

  • Status changed from Resuelta to Cerrada

Also available in: Atom PDF