Usuarios externos en Alfresco y SSO passthru

[angelmartinboni]

Creo que no te he entendido Angel, el pruebas y producción están cambiados, no influye el orden?

Falla aleatoriamente en Producción que salta ese error 500. El error que nos devuelve pentaho es:

2017/08/22 10:00:25 - HTTP - ERROR (version 5.4.0.1-130, build 1 from 2015-06-14_12-34-55 by buildguy) : java.io.IOException: Server returned HTTP response code: 500 for URL: http://alfrescoexp01.chap.junta-andalucia.es/alfresco/service/api/audit/query/alfresco-access?verbos...

[cesarista]

Buenas Angel (Martin):

Alfresco intenta autenticarse en cada uno de los subsistemas de la cadena en orden y para en el momento que lo consigue. Por eso en explotación te sale esa traza, porque el userPentaho no existe en el LDAP y es el primer subsistema de la cadena. Y por eso en pruebas no falla precisamente. El error que mencionas no es exactamente "un error", es un intento de autenticación (pero no tiene una traza de ERROR). La pregunta adecuada es si userPentaho se autentica en explotación ? Si es así no pasa absolutamente nada... se autenticará a la segunda cada vez. 

En mi caso, en la pregunta original, obtenía un ERROR, y la consecuencia era que Alfresco no intentaba autenticar en el siguiente subsistema de la cadena, con lo que mi "userPentaho" no se llegaba a autenticar nunca. Por eso me vi forzado a cambiar el orden. Si te pasa lo que a mi, pues cambia el orden de la cadena. No parece lo más natural, ya cada vez que se autenticase un usuario ldap, este lo intentaría primero en la base de datos de Alfresco... pero bueno.

Comentar también que lo que suelo intentar cuando encadeno varios subsistemas de autenticación es poner el más masivo primero (como has hecho en explotación). Pero por ejemplo, en este caso tuve que cambiar el orden para atajar los problemas comentados. Quitaría el DEBUG de esa clase porque puede ser muy chillón.

También te recomendaría que mantengas los entornos (desarrollo, pruebas, producción) uniformes para evitar sorpresas como estas.

Saludos.

--C.

[angelmartinboni]

Buenas Cesar.

Mira te pongo el escenario: en nuestro entorno de Explotación primero intenta por LDAP y falla porqué no existe ese usuario y luego por Alfresco y si. Perfecto. Esto es lo que ocurre casi siempre.

Sin embargo, hay veces que cuando intenta en primera instancia autenticar por LDAP, en vez de fallar normal y pasar a la autenticación de Alfresco, pues saca el error ese de "closed socket" y se para el proceso y salta el error 500.

Disculpa Cesar mi ignorancia, pero es que llevo solo 6 meses con alfresco y estoy aprendiendo aun, a base de cabezazos.

Gracias.

[angelborroy]

¿Qué versión de Alfresco estáis empleando? Por tus comentarios entiendo que estáis utilizando servicios web SOAP, lo que me hace retrotraerme a varios años atrás...

[angelmartinboni]

Buenas Angel,

pues estamos usando Alfresco 3.4.7. Estamos en proceso de actualizaciones y migraciones.

[angelborroy]

En ese caso me inclinaría por pensar que se trata de una incidencia del producto (ni siquiera queda un registro de incidencias consultable de aquella época) y lo solucionaría de manera temporal hasta que esa actualización llegue.

[cesarista]

No te preocupes Angel Martin, esto se aprende siempre así

Si el comportamiento no es completamente reproducible y ocasional, te aconsejaría que cambies el orden de la cadena para evitar problemas, y compruebes que el job funciona correctamente (además de tener los entornos mas coherentes).

En el analisis del problema, es importante también saber cuantas veces al día falla, si falla durante el día o la noche, en determinados intervalos de tiempo (por ejemplo, durante la jornada), si podría derivar de un problema de conectividad con el LDAP, si coinciden los problemas de autenticación con tareas de mantenimiento del LDAP...  (dado que cuando se atasca en el LDAP llega a leerse un ServiceUnavailable)

Caused by: javax.naming.ServiceUnavailableException: chap.junta-andalucia.es:389; 

Por último, otra posibilidad de regatear el error o de manifestarlo es usar un usuario LDAP con los permisos adecuados para ese job. Y ver que pasa..

Saludos.

--C.

[angelmartinboni]

El caso es encontrar la solución temporal jejeje

[angelmartinboni]

Voy a intentar en nuestro entorno de desarrollo ver si cambiando el orden en el chain nos da el mismo error, a ver si así podemos regatear el error.

El intervalo en el que lanzamos ese jobs es entre las 9 y las 20 de cada día. Y en el día en cuestión del que os hablo falló 10 veces así.

[angelmartinboni]

Buenos días, he estado investigando un poco más sobre el error clave:

Caused by: javax.naming.PartialResultException [Root exception is javax.naming.ServiceUnavailableException: chap.junta-andalucia.es:389; socket closed [Root exception is com.sun.jndi.ldap.LdapReferralException: Continuation Reference; remaining name 'DC=chap,DC=junta-andalucia,DC=es']; remaining name '']

Y he encontrado estos dos enlaces, que al parecer ofrecen una solución pero la verdad es que no lo veo claro.

https://confluence.atlassian.com/jirakb/user-lookups-fail-with-partialresultexceptions-due-to-active...

https://community.jivesoftware.com/docs/DOC-26500

¿parece ser que es problema de cómo la aplicación pentaho recorre el árbol del AD no?

según el segundo enlace parece que tiene que ver con el timeout...

Os suena algo de esto y cómo solucionarlo?

Gracias de antemano, de verdad.

Saludos. Angel.