Error en LDAP crear usuario "adminsudocu" - Desde Araí Usuarios

Estimados. Muy buenas.

Nos encontramos desplegando la versión completa de Expedientes SIU. Tenemos todo arriba y operativo en el SWARM (1 master y 2 worker).
El LDAP y PostgreSQL se encuentran aparte en otra VM (no dockerizado). Para LDAP lo tenemos en Debian 10 (Buster).

El error que tenemos puntual es al crear el usuaroi “adminsudocu”. Lo raro que que Araí usuarios al ingresar autentica OK con LDAP. El problema es al crear usuarios.

usuarios_idm.1.4n9ipca60dyg@sudocumgr01 [php7:notice] [pid 1942] [client 10.0.1.8:34460] [b]PHP Notice:  Undefined index: node in /usr/local/app/idm/php/operaciones/usuarios/ci_usuarios_listado.php[/b] on line 239, referer: https://expedientes.ugr.edu.ar/usuarios/aplicacion.php?ah=st6235082653efa7.99781372&ai=arai_usuarios%7C%7C31000002
usuarios_idm.1.4n9ipca60dyg@sudocumgr01 [php7:notice] [pid 1942] [client 10.0.1.8:34460] [b]No se pudo crear el objeto en el servidor LDAP: Undefined attribute type[/b], referer: https://expedientes.ugr.edu.ar/usuarios/aplicacion.php?ah=st6235082653efa7.99781372&ai=arai_usuarios%7C%7C31000002
usuarios_idm.1.4n9ipca60dyg@sudocumgr01 [php7:notice] [pid 1942] [client 10.0.1.8:34460] [b]toba_error: No se pudo crear el objeto en el servidor LDAP: Undefined attribute type \n[TRAZA]\n\t\n\tci_usuarios_listado->sincronizar_datos_relacion[/b] \nArchivo: /usr/local/app/idm/php/operaciones/usuarios/ci_usuarios_listado.php, lInea 289 \n\t\n\tci_usuarios_listado->evt__guardar \nArchivo: /usr/local/app/idm/vendor/siu-toba/framework/php/nucleo/componentes/interface/toba_ci.php, lInea 282 \nParametros: \nundefined\t\t\n\t\n\ttoba_ci->disparar_evento_propio \nArchivo: /usr/local/app/idm/vendor/siu-toba/framework/php/nucleo/componentes/interface/toba_ci.php, lInea 204 \n\t\n\ttoba_ci->disparar_eventos \nArchivo: /usr/local/app/idm/vendor/siu-toba/framework/php/nucleo/toba_solicitud_web.php, lInea 135 \n\t\n\ttoba_solicitud_web->procesar_eventos \nArchivo: /usr/local/app/idm/vendor/siu-toba/framework/php/nucleo/toba_solicitud_web.php, lInea 55 \n\t\n\ttoba_solicitud_web->procesar \nArchivo: /usr/local/app/idm/vendor/siu-toba/framework/php/nucleo/toba_nucleo.php, lInea 96 \n\t\n\ttoba_nucleo->acceso_web \nArchivo: /usr/local/app/idm/www/ap...SIGUE..

Lo raro (no sé si es común) es que veo tambien justo cuando intento “guardar” el usuario para que lo cree, produce en el servicio “usuarios_memcached” el siguiente error:

usuarios_memcached-server.1.c8ioq7b82sbs@sudocuworker01    | Failed to write, and not due to blocking: Broken pipe
usuarios_memcached-server.1.c8ioq7b82sbs@sudocuworker01    | Failed to write, and not due to blocking: Broken pipe

Agradecido por su ayuda cuanto antes, ya que estamos con tiempos muy acotados para salir.

Muchas Gracias


ERROR_CREAR_USUARIO.PNG

ERROR_CREAR_USUARIO.PNG_thumb.png

Estimados. Buen dia.

Por favor necesitamos si nos pueden ayudar con este ticket. Necesitamos largar andar sudocu en la Universidad

Gracias

Hola Diego,

El primer error que muestran, tiene un mensaje tipo “No se pudo crear el objeto en el servidor LDAP: Undefined attribute type” y parece apuntar a que la instalación de LDAP que realizaron no está 100% lista. Principalmente porque desde el ABM de usuarios deberían poder de crearlos sin inconvenientes y sin errores de LDAP.

Les recomiendo seguir y verificar los pasos de esta guía. Lo que tienen que lograr es poder cargar los schema OpenLDAP personalizados (creados por el SIU), sin eso no va a funcionar realmente.

Saludos!

PD: los archivos de ldap que se indica copiar están disponibles vía hub. Tengan en cuenta la versión de arai-usuarios que están usando.

Hola Sergio. Buenas.

Pero lo esquemas están ok. Los creamos tal cual y con una consulta aparecen. Además como te comento Araí Usuarios autentica ok contra LDAP.

Te paso la salida de la consulta LDAP para ver los schemas a ver si ves algo raro:

root@sudocuapps:~# sudo ldapsearch -x -W -D "cn=admin,dc=ugr,dc=edu,dc=ar" -b "dc=ugr,dc=edu,dc=ar"
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=ugr,dc=edu,dc=ar> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# ugr.edu.ar
dn: dc=ugr,dc=edu,dc=ar
objectClass: top
objectClass: dcObject
objectClass: organization
o: ugr.edu.ar
dc: ugr

# admin, ugr.edu.ar
dn: cn=admin,dc=ugr,dc=edu,dc=ar
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: e1NTSEF9ejZFRlhlZlVRRXFxdkd3Ujh6QlM3M3A4UC9LeGRwek8=

# usuarios, ugr.edu.ar
dn: ou=usuarios,dc=ugr,dc=edu,dc=ar
objectClass: top
objectClass: organizationalUnit
ou: usuarios

# usuariosCuentas, ugr.edu.ar
dn: ou=usuariosCuentas,dc=ugr,dc=edu,dc=ar
objectClass: top
objectClass: organizationalUnit
ou: usuariosCuentas

# groups, ugr.edu.ar
dn: ou=groups,dc=ugr,dc=edu,dc=ar
objectClass: top
objectClass: organizationalUnit
ou: groups

# devs, groups, ugr.edu.ar
dn: cn=devs,ou=groups,dc=ugr,dc=edu,dc=ar
objectClass: groupOfNames
member: cn=admin,dc=ugr,dc=edu,dc=ar
cn: devs
description: Grupo para desarrolladores

# a94635c7-ecb8-4f9c-a361-401067f6cc6e, usuarios, ugr.edu.ar
dn: uid=a94635c7-ecb8-4f9c-a361-401067f6cc6e,ou=usuarios,dc=ugr,dc=edu,dc=ar
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: eduPerson
objectClass: labeledURIObject
objectClass: inetOrgPersonArai
uid: a94635c7-ecb8-4f9c-a361-401067f6cc6e
cn: Usuario Administrador
sn: Admin
userPassword:: e0NSWVBUfSQyeSQxMCROYnJ1c3BZS0VxMmwvUm43TDlYT29lWmk2Z0NFVmwyQXh
 ObkpBYlBpYlpQTnZ4N0RzV2ZVRw==
givenName: Usuario Administrador
mail: admin@example.com
bloqueado: 0
login: admin
loginMethod: uniqueIdentifier
uniqueIdentifier: admin
cuentas: aid=admin|#|#|a94635c7-ecb8-4f9c-a361-401067f6cc6e|#|#|idm-core|#|#|,
 ou=usuariosCuentas,dc=ugr,dc=edu,dc=ar

# admin|#|#|a94635c7-ecb8-4f9c-a361-401067f6cc6e|#|#|idm-core|#|#|, usuariosCue
 ntas, ugr.edu.ar
dn: aid=admin|#|#|a94635c7-ecb8-4f9c-a361-401067f6cc6e|#|#|idm-core|#|#|,ou=us
 uariosCuentas,dc=ugr,dc=edu,dc=ar
objectClass: top
objectClass: account
objectClass: accountArai
aid: admin|#|#|a94635c7-ecb8-4f9c-a361-401067f6cc6e|#|#|idm-core|#|#|
uid: a94635c7-ecb8-4f9c-a361-401067f6cc6e
cuenta: admin
appUniqueId: idm-core
defecto: 1

# search result
search: 2
result: 0 Success

# numResponses: 9

root@sudocuapps:~# sudo ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=schema,cn=config "(objectClass=olcSchemaConfig)" | grep memberOf
olcAttributeTypes: ( 1.2.840.113556.1.2.102 NAME 'memberOf' DESC 'Group that t

Espero tu ayuda. Gracias.-

Estimados. Buen dia.

Por favor reiteramos la urgencia del caso. Si podrían ayudarnos con una respuesta agradecidos respecto a la salida anterior que enviamos, agradecido

Por otor lado, tenemos la versión de LDAP 2.4.47 sobre Debian 10. ¿Que verisón corresponde para importar los ldif de la documentación?
Están las versiones → idm/templates/ldap/2.0 | 2.2 | 3.0 o 3.1

Gracias

Hola Diego,

las versiones que constan en dicho directorio se corresponden a las ramas principales de Arai-Usuarios, el ldiff a cargar dependera entonces de la version de Arai-Usuarios que tengas en uso.
Por ejemplo para toda version 3.1.x se usa el directorio “idm/templates/ldap/3.1”.

Si tienen EEI en docker, pueden hacer uso de un stack definido explicitamente para chequear la estructura de las bds entre otras cosas.
Lo pueden desplegar de esta forma, si algo esta mal lo deberian poder ver ahi.

Saludos

Buenas Richard, Entiendo lo que comentas con las versiones

¿Respecto del error nos pueden ayudar?

Undefined index: node
No se pudo crear el objeto en el servidor LDAP: Undefined attribute ty
pe

¿Ese error no les dice nada o tal vez ya pasó en otro caso?

Saludos

Hola Diego,

Para iniciar descartando inconvenientes en como están levantando LDAP y los esquemas, les sugiero que hagamos lo siguiente:

  1. en otra VM, instalen docker, levanten (sin swarm claro) una instancia de LDAP para docker (tal cual acá está documentado)

  2. como usarán ese LDAP en docker por defecto, cambien las credenciales de conexión LDAP en el despliegue de arai-usuarios a las que por defecto funcionan con nuestros ejemplos (solo para evitar mayores inconvenietes):

    LDAP_ORGANIZATION: CIN
    LDAP_DOMAIN: “siu.cin.edu”
    LDAP_REMOVE_CONFIG_AFTER_SETUP: “false”
    LDAP_ADMIN_PASSWORD: admin
    LDAP_CONFIG_PASSWORD: admin

  3. en arai-usuarios, a lo sumo tendrán que volver a ejecutar el paso de bootstrap que les vuelve a generar el admin (intenten usar otra passwd para que no falle porque ya fué utilizada).

  4. ejecuten el paso de verificación que Richard les sugirió previamente (tener en cuenta, no corran el “docker rm” sin antes revisar los logs del contenedor)

  5. ingresan a arai-usuarios vía login centralizado, e intenten dar de alta un nuevo usuario.

Saludos!

Sergio Gracias por responder, Logré resolverlo. Cuento por acá por si le pasa a otros. Como ya se vio los esquemas y estructura estaba bien conformada, sin embargo, volví a re-hacerlo.

  1. Bajé LDAP → systemctl stop slapd
  2. Borre base de datos de ldap y config entera
rm -rf /var/lib/ldap/*
rm -rf /etc/ldap/slapd.d/*

(El servicio LDAP no va a levantar, hay que correr un dpkg reconfigure)

  1. Corres "sudo dpkg-reconfigure slapd " (Seguis los pasos y seteas de nuevo tu domain.) Ej–> universidad.edu.ar

  2. Volves a cargar la configuración de schema y estructura, tal como están los pasos en la doc → https://documentacion.siu.edu.ar/usuarios/docs/cache/instalacion-bases-ldap/#despliegue-manual

  3. Ya lo comentó Sergio, pero hay que volver a ejecutar el paso que crea el la password del usuario “admin” de Araí-Usuarios.

ADMIN_PASS=toba1234 docker stack deploy \
    --with-registry-auth \
    -c util/usuarios_crear_admin.yml \
    boot

IMPORTANTE: Tal como comentan los chicos, desplegar el stack de verificación es fundamental, ya que te chequea la estructura de LDAP, así como también la conexión.

Saludos!

Diego!

Excelente el aporte, compartiendolo.

Saludos!