nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Usuarios externos en Alfresco y SSO passthru

cesarista

Hola:

Tengo una cadena de autenticacion del tipo:

<pre>
authentication.chain=alfrescoNtlm1:alfrescoNtlm,passthru1

assthru,ldap1:ldap-ad
</pre>

y dos conjuntos de usuarios, uno en Alfresco y otro en el directorio activo (AD), que sincronizo via LDAP. Hasta ahi va todo bien.

Me puedo loguear sin problema con los usuarios correspondientes y puedo administrar los usuarios "externos" con Alfresco desde su interfaz.

Cuando activo el SSO para los usuarios internos (AD) del AD veo que:
- Necesito que passthru sea el primero en la cadena autenticacion (mutable) –> y el SSO de usuarios internos funciona.
- El otro conjunto de usuarios "externos" no se autentica (?).
- Ademas no puedo administrarlos porque ya no es el subsistema mutable.

¿ Tiene esto sentido ? ¿ Puedo tener un conjunto de usuarios externos gestionados y administrados en Alfresco, y tener SSO de red contra el AD ?

Un saludo.

–C.

Find more posts tagged with

Comments

venzia

Hola Cesar .. no hace mucho (con lo cual aun lo tengo frequito) llevamos a cabo una instalación de alfresco con la siguiente cadena de autenticacion "authentication.chain=passthru1

assthru,ldap-ad1:ldap-ad,ldap1:ldap".
En nuestro caso los usuarios "extenos" vienen de otro ldap, en el tuyo de AlfrescoNtlm .. comprueba si con este orden te deja autenticar, aunque supongo que ya lo habras probado.
En caso que no des con la tecla dime y exprimo la docu que tengo al respecto.
Saludos y suerte!

cesarista

Gracias Javier,

La verdad es que no se si me he expresado muy bien arriba pero va en linea con tu respuesta. Cuando tengo esto, si me funciona el SSO de AD:

<pre>
authentication.chain=passthru1

assthru,ldap1:ldap-ad,alfrescoNtlm1:alfrescoNtlm
</pre>

pero no me funciona la autenticación con los usuarios externos en alfrescoNtlm1:alfrescoNtlm

Me da la sensación que el SSO activo hace que dos cadenas potenciales de usuarios compitan por el mismo (passthru1, alfrescoNtlm1) y solo tiene SSO la primera de ellas en la cadena. Además de esta manera la cadena mutable (en la que se pueden crear usuarios es passthru AD y no alfresco), lo cual no me sirve para gestionar/administrar los usuarios externos desde Alfresco. Pero no es mala saber que con otro ldap me puedo arreglar el problema la verdad.

Un saludo.

–C.

venzia

Me alegro que al menos ahora tengas otra "variante" ..
Y teniendo en cuenta q

Además de esta manera la cadena mutable (en la que se pueden crear usuarios es passthru AD y no alfresco), lo cual no me sirve para gestionar/administrar los usuarios externos desde Alfresco

obviamente de poco vale el caso en el que se pueda dejar funcionando si dichos usuarios "externos" no son gestionables desde Alfresco.
Ya por simple curiosidad voy a bucear en mi archivo por si veo algo al respecto.
Saludos!

cesarista

Hola de nuevo:

Al final lo oriente como comentabas pero sigo teniendo problemas con el SSO cuando tengo varios subsistemas de autenticacion (para la auth). Y aqui mi pregunta. ¿ Es posible configurar (lo habeis hecho alguna vez?) para Share un sistema de SSO con passthru y con otras cadenas de autenticacion disponibles (otros ldaps o lo que sea…) ?

Un saludo.

–C.

cesarista

Por cierto Javier:

En el orden que me mencionabas la cadena, con el passthru delante tenia problemas para autenticarme con los usuarios del ldap, de manera análoga a lo que me sucedía con alfrescoNtml (curioso este patron). Tuve que cambiar la cadena y poner el ldap primero.

Un saludo.

–C.

angelmartinboni

Buenas,

he leído este hilo porque tengo un problema parecido.

Resulta que en mi empresa tengo creado un usuario en Alfresco, que obviamente no está en LDAP porque es impersonal, digamos que es de pruebas. Lo usamos para lanzar webservices, pero falla cuando hace la autenticación contra LDAP y no contra Alfresco:

17:00:11,115 DEBUG [org.alfresco.repo.security.authentication.AuthenticationComponentImpl] Authenticating user "userPentaho"
17:00:11,119 DEBUG [org.alfresco.repo.security.authentication.AuthenticationComponentImpl] Setting the current user to "userPentaho"
17:00:11,120 DEBUG [org.alfresco.repo.security.authentication.AuthenticationComponentImpl] User "userPentaho" authenticated successfully
17:00:13,453 DEBUG [org.alfresco.repo.security.authentication.ldap.LDAPAuthenticationComponentImpl] Authenticating user "userPentaho"
17:00:13,479 DEBUG [org.alfresco.repo.security.authentication.ldap.LDAPAuthenticationComponentImpl] Failed to authenticate user "userPentaho"
org.alfresco.repo.security.authentication.AuthenticationException: 0722396591 Failed to resolve user: userPentaho

También salta un error de "closed socket"... y creo que por eso nos salta un error 500, por cierto.

¿Debería seguir hacia delante no? es decir, ve que en LDAP no está pero en Alfresco sí y listo ¿no?

En una instancia de Desarrollo, donde no salta ese error, no se se hace la autenticación contra LDAP y está así:

authentication.chain=alfrescoNtlm1:alfrescoNtlm,ldap-ad1:ldap-ad

...

#20161202 - Hemos desactivado la autenticaci\u00f3n con passthru
#ntlm.authentication.sso.enabled=true
ntlm.authentication.sso.enabled=false

...

ldap.authentication.defaultAdministratorUserNames=admin

No tengo muy claro en qué afecta el orden en el chain...

¿por qué intenta autenticarlo en LDAP y falla? cuando sabemos que no está y debería ignorarlo ¿no?

Gracias de antemano.

Saludos. Angel.

angelborroy

No entiendo muy bien la pregunta.

Si en tu cadena de autenticación aparece

authentication.chain=alfrescoNtlm1:alfrescoNtlm,ldap-ad1:ldap-ad

Alfresco intenta autenticar al usuario por id de usuario y contraseña contra su propia base de datos en primer lugar y después contra LDAP. En caso de que tengáis además un sistema SSO configurado, quizá estéis afectados por este problema:

https://github.com/keensoft/alf-21757-repo

cristinamr

Podrías hacer una prueba rápida para ver si está creado ese usuario en tu alfresco: Pon en el authentication.chain solo ntlm, reinicia alfresco y prueba tu a mano logarte con ese usuario a ver si existe. Existen otras formas de comprobarlo como consultarlo desde el explorador de nodos o en base de datos directamente.

cesarista

Angel Borroy‌ Este problema al que haces referencia, sabes si es aplicable también al SSO de AlfrescoNtlm, además del de Kerberos ? Basicamente lo que me ha ocurrido alguna vez es que si activas el SSO de AlfrescoNtlm, no funciona webdav (reto NTML), ni el cliente móvil o la capa de servicios.

Saludos.

--C.

angelborroy

‌ es aplicable a cualquier subsistema de autenticación SSO.

Si te fijas, el parche consiste básicamente en comentar los filtros de autenticación en WebDAV y en API.

cesarista

Gracias ‌

Saludos.

--C.

angelmartinboni

Gracias Angel y a los demás por vuestras respuestas tan tempranas.

Voy a intentar verificar si en mi instancia de explotación está igual configurado el authetication.chain...

De todas formas, no entiendo porqué a veces salta un error 500, creemos que es por la parte de la traza donde me dice "socket closed" que no sé a que es debido... ¿se os ocurre algo?

Gracias.

angelborroy

Pueden producirse errores 500 cuando el usuario cancela una petición en Share.

angelmartinboni

Entiendo Angel, pero la terea en la que nosotros estamos teniendo problema es a la hora de ejecutar unos webservices en modo autmático, se van generando solos como jobs...

Te dejo un trozo del log, en el penúltimo "caused by" sale lo del closed socket:

19:00:31,785 DEBUG [security.authentication.AuthenticationComponentImpl] Authenticating user "userPentaho"
19:00:31,790 DEBUG [security.authentication.AuthenticationComponentImpl] Setting the current user to "userPentaho"
19:00:31,791 DEBUG [security.authentication.AuthenticationComponentImpl] User "userPentaho" authenticated successfully
20:00:11,062 DEBUG [authentication.ldap.LDAPAuthenticationComponentImpl] Authenticating user "userPentaho"
20:00:41,094 DEBUG [authentication.ldap.LDAPAuthenticationComponentImpl] Failed to authenticate user "userPentaho"
org.alfresco.error.AlfrescoRuntimeException: 0722397392 Failed to resolve user ID: userPentaho
   at org.alfresco.repo.security.sync.ldap.LDAPUserRegistry.resolveDistinguishedName(LDAPUserRegistry.java:921)
   at org.alfresco.repo.security.authentication.ldap.LDAPAuthenticationComponentImpl.authenticateImpl(LDAPAuthenticationComponentImpl.java:113)
   at org.alfresco.repo.security.authentication.AbstractAuthenticationComponent.authenticate(AbstractAuthenticationComponent.java:158)
   at org.alfresco.repo.security.authentication.AuthenticationServiceImpl.authenticate(AuthenticationServiceImpl.java:65)
   at org.alfresco.repo.security.authentication.AbstractChainingAuthenticationService.authenticate(AbstractChainingAuthenticationService.java:180)
   at sun.reflect.GeneratedMethodAccessor777.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
   at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
   at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
   at net.sf.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor.invoke(MethodSecurityInterceptor.java:80)
   at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
   at org.alfresco.repo.security.permissions.impl.ExceptionTranslatorMethodInterceptor.invoke(ExceptionTranslatorMethodInterceptor.java:44)
   at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
   at org.alfresco.repo.audit.AuditMethodInterceptor.proceedWithAudit(AuditMethodInterceptor.java:232)
   at org.alfresco.repo.audit.AuditMethodInterceptor.proceed(AuditMethodInterceptor.java:199)
   at org.alfresco.repo.audit.AuditMethodInterceptor.invoke(AuditMethodInterceptor.java:152)
   at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
   at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:107)
   at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
   at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
   at $Proxy56.authenticate(Unknown Source)
   at org.alfresco.repo.web.scripts.servlet.BasicHttpAuthenticatorFactory$BasicHttpAuthenticator.authenticate(BasicHttpAuthenticatorFactory.java:176)
   at org.alfresco.repo.web.scripts.RepositoryContainer.executeScript(RepositoryContainer.java:302)
   at org.springframework.extensions.webscripts.AbstractRuntime.executeScript(AbstractRuntime.java:352)
   at org.springframework.extensions.webscripts.AbstractRuntime.executeScript(AbstractRuntime.java:189)
   at org.springframework.extensions.webscripts.servlet.WebScriptServlet.service(WebScriptServlet.java:118)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
   at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
   at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
   at org.alfresco.web.app.servlet.GlobalLocalizationFilter.doFilter(GlobalLocalizationFilter.java:58)
   at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
   at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
   at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
   at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
   at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
   at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
   at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
   at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
   at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
   at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
   at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
   at java.lang.Thread.run(Thread.java:662)
Caused by: javax.naming.PartialResultException [Root exception is javax.naming.ServiceUnavailableException: chap.junta-andalucia.es:389; socket closed; remaining name '']
   at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:224)
   at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreReferrals(LdapNamingEnumeration.java:362)
   at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:208)
   at com.sun.jndi.ldap.LdapNamingEnumeration.hasMore(LdapNamingEnumeration.java:171)
   at org.alfresco.repo.security.sync.ldap.LDAPUserRegistry.resolveDistinguishedName(LDAPUserRegistry.java:913)
   ... 43 more
Caused by: javax.naming.ServiceUnavailableException: chap.junta-andalucia.es:389; socket closed; remaining name ''
   at com.sun.jndi.ldap.Connection.readReply(Connection.java:419)
   at com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:611)
   at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:534)
   at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1962)
   at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1824)
   at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1749)
   at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:368)
   at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:338)
   at com.sun.jndi.ldap.LdapReferralContext.search(LdapReferralContext.java:639)
   at com.sun.jndi.ldap.LdapSearchEnumeration.getReferredResults(LdapSearchEnumeration.java:169)
   at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreReferrals(LdapNamingEnumeration.java:345)
   at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:208)
   ... 47 more

Gracias de antemano.

Saludos. Angel.

ceeliro

Hola quizás no tenga nada que ver pero por si acaso. Recuerdo haber tenido alguna vez un problema similar. Que SO utilizas? Windows 2008? Si es así, creo que existía un bug con su respectivo hotfix el cual Windows una vez alcanzado un determinado número de conexiones a sockets empezaba a rechazar cualquier otra.

Saludos.

angelmartinboni

Buenas Cristina. Si, el usuario está creado en Alfresco. El problema es que salta un error 500 cuando se registro un socket closed en el log cuando se lanza el webservice.

angelmartinboni

Buenas Carlos, pues voy a preguntarlo y te comento.

Gracias.

angelmartinboni

Buenas, pues voy a preguntarlo, a ver que me dicen.

Gracias.

2017-08-26 16:24 GMT+02:00 ceeliro <kristen.gastaldo@alfresco.com>:

Alfresco Community
<https://community.alfresco.com/?et=watches.email.thread>
Re: Usuarios externos en Alfresco y SSO passthru
reply from Carlos Liró
<https://community.alfresco.com/people/ceeliro?et=watches.email.thread>
in Spanish User Group - View the full discussion
<https://community.alfresco.com/message/820233-re-usuarios-externos-en-alfresco-y-sso-passthru?commentID=820233&et=watches.email.thread#comment-820233>

angelmartinboni

Me han confirmado que efectivamente tenemos LDAP en 2008, pero ¿cómo lo llegasteis a solucionar Carlos?

Saludos. Angel

cristinamr

Angel Martín, releyendo toda la conversación creo que deberías intentar auditar la conexión entre el ldap y Alfresco con alguna utilidad tipo Wireshark te va a dar mucho más detalle a ese error. Estamos en un punto en el que realmente debemos ver si el problema es el SO, es Alfresco o es otro componente.

En una ocasión tuve un cliente con un error muy muy muy raro y gracias a esta utilidad pude sacar en claro cual era el problema (de hecho, le di solución). ¿Podrías utilizar una utilidad parecida en tu trabajo?

angelmartinboni

Buenas Cristina, pues la verdad es que es buena idea, alguna vez he usado esa herramienta en la facultad y recuerdo que venía bastante información de bajo nivel que podría ser útil.

El problema es que las máquinas donde se realiza la conexión y autenticación entre Alfresco y LDAP están en nuestro cliente y yo no tengo acceso. Como es un probmema que surge muy de vez en cuando pues es más engorroso estar pendiente...

ceeliro

Ángel voy a mirar en mis apuntes del pasado a ver si encuentro el número de

hotfix. Si ya lo has solucionado o descartado que fuese esto házmelo

saber...

Saludos

On 28 Aug 2017 1:44 PM, "angelmartinbonilla" <kristen.gastaldo@alfresco.com>

angelmartinboni

BuenasCarlos, te lo agradezco, porque la verdad que no lo hemos solucionado.

A la máquina ala que yo tengo acceso tengo que ejecutarlo a mano, y al ser una cosaque falla muy esporádicamente es prácticamente imposible saber si lo que falla es el orden de los valor del chain.

Gracias. Saludos.

douglascrp

Creo ser esto https://support.microsoft.com/pt-br/help/2577795/kernel-sockets-leak-on-a-multiprocessor-computer-that-is-running-windo

angelmartinboni

Por cierto, me he dado cuenta qel código del error es diferente cuando falla y salta error que paraliza todo a el arror cuando no encuentra el usuario por ldap y sigue por alfresco.

El error en cuestión es este:

org.alfresco.repo.security.authentication.AuthenticationException: 0722397127 Failed to resolve user: userPentaho

He buscado ese error por internet pero no he encontrado nada, ¿os suena?

Gracias. Saludos.