cancel
Showing results for 
Search instead for 
Did you mean: 

Problems with SSO on Share 3.4.d

catar4
Champ in-the-making
Champ in-the-making
Greetings,

I'm having some issues with SSO connection on /share context on my community 3.4.d installation. I have searched and read many posts on the forums and the Internet at large … this has helped me advance on troubleshooting but I haven't yet succeeded in solving all issues, so here I am with a few questions.

First of all, let me start by saying we are able to connect using SSO on the /alfresco context. We can also connect using a local (ntlm) account by accessing the login page at localhost/alfresco/faces/jsp/login.jsp and this is exactly what we'd like to be also able to do on /share.

The fact that we are able to connect with SSO on /alfresco tells me my config is correct (or really close to what it should be to be able to achieve the same thing on /share). I followed the documentation at http://wiki.alfresco.com/index.php?title=Alfresco_Authentication_Subsystems&oldid=35965 since I have read here on the forums that the documentation found at http://wiki.alfresco.com/wiki/Alfresco_Authentication_Subsystems#Alfresco_Share_SSO_using_NTLM might not be exact.

Here's the relevant content of the tomcat/shared/classes/alfresco-global.properties file:


authentication.chain=passthru1:passthru,alfrescoNtlm1:alfrescoNtlm,ldap-ad1:ldap-ad,ldap-ad2:ldap-ad2,ldap-ad3:ldap-ad3,ldap-ad4:ldap-ad4,ldap-ad5:ldap-ad5,ldap-ad6:ldap-ad6,ldap-ad7:ldap-ad7,ldap-ad8:ldap-ad8,ldap-ad9:ldap-ad9,ldap-ad10:ldap-ad10,ldap-ad11:ldap-ad11,ldap-ad12:ldap-ad12,ldap13-ad13:ldap-ad13

ldap-ad.authentication.active=false
ldap-ad.synchronization.active=true
ldap.authentication.active=false
ldap.synchronization.active=true


Properties for alfrescoNtlm authentication subsystem (tomcat/shared/classes/alfresco/subsystems/Authentication/alfrescoNtlm/ntlm-filter.properties):


ntlm.authentication.sso.enabled=false
ntlm.authentication.mapUnknownUserToGuest=false
ntlm.authentication.browser.ticketLogons=true


This is so users found in the database but not in the Active Directory server can still connect (read this is how it would be done on these forums).

Properties for the passthru authentication subsystem (tomcat/shared/classes/alfresco/subsystems/Authentication/passthru/ntlm-filter.properties):


ntlm.authentication.sso.enabled=true
ntlm.authentication.mapUnknownUserToGuest=false
ntlm.authentication.browser.ticketLogons=true


Now, here's what I get in the logs when we try to connect to share by SSO:

08:29:26,221 DEBUG [app.servlet.NTLMAuthenticationFilter] New NTLM auth request from 127.0.0.1 (127.0.0.1:47849) SID:1DA58053185F21A44110DA836696E47E
08:29:26,311 DEBUG [app.servlet.NTLMAuthenticationFilter] Received type1 [Type1:0xa2088207,Domain:<NotSet>,Wks:<NotSet>]
08:29:26,313 DEBUG [app.servlet.NTLMAuthenticationFilter] Client domain null
08:29:26,519 DEBUG [app.servlet.NTLMAuthenticationFilter] Sending NTLM type2 to client - [Type2:0x80000203,Target:alfresco-test,Ch:e3df93be10a17660]
08:29:26,526 DEBUG [app.servlet.NTLMAuthenticationFilter] Received type3 [Type3:,LM:000000000000000000000000000000000000000000000000,NTLM:81a3ec8433bf84ca775cb84039371cef01010000000000000c38706b397bcf01ec59fc6e2ea5d155000000000200200061006c00660072006500730063006f002d006700650072006d00610069006e000000000000000000,DomSmiley Very HappyOMAIN,User:jade.thomassin,WksSmiley TongueGGQC122]
08:29:26,527 ERROR [app.servlet.NTLMAuthenticationFilter] Client PGGQC122 using NTLMv2 logon, not valid with passthru authentication

This *seems* to be a normal error using NTLMv2 with Alfresco SSO. After some research, I have found we could try to change Group Policies in Windows 7 to try and correct this NTLMv2 behavior, since as I understand the ERROR I get is a normal one knowing NTLMv2 doesn't like the "man in the middle like" authentication method for alfresco share. So we change Group Policies, following the procedure from this blog: http://tips.kaali.co.uk/2011/05/12/alfresco-login-ntlmv2-and-passthru-issues/, and here's what I see in the logs after we tested this:

11:35:38,939 http-80-8 DEBUG [site.servlet.SSOAuthenticationFilter] Processing request /share/page/site/domain/dashboard SID:AE55A1D5BE398B10936AEAA4EF1F732B
11:35:38,940 http-80-8 DEBUG [site.servlet.SSOAuthenticationFilter] Received type3 [Type3:,LM:af21bda735c5426ae3c466b1b8080b4ba8b6be47286d4844,NTLM:af21bda735c5426ae3c466b1b8080b4ba8b6be47286d4844,DomSmiley Very HappyOMAIN,User:charles.bureau,Wks:CACASWL0016]
11:35:38,941 User:charles.bureau DEBUG [app.servlet.NTLMAuthenticationFilter] Received type3 [Type3:,LM:af21bda735c5426ae3c466b1b8080b4ba8b6be47286d4844,NTLM:af21bda735c5426ae3c466b1b8080b4ba8b6be47286d4844,DomSmiley Very HappyOMAIN,User:charles.bureau,Wks:CACASWL0016]
11:35:39,069 User:charles.bureau DEBUG [app.servlet.NTLMAuthenticationFilter] Authentication failed, 04290002 Logon failure

The same user is able to connect SSO on /alfresco, this is when he tries to access /share.

Would anyone have any idea of what's going on here ? If the configuration is good (being able to connect to /alfresco makes me thing it is) I would expect /share to work the same way.

Thanks in advance for your help,
Carl
2 REPLIES 2

cesarista
World-Class Innovator
World-Class Innovator
Once you have the aproppiate "Send LM & NTLM and V2 if Negotiated" you need to configure your clients properly (it is going to depend on the browser - IE, Firefox - for trusting in NTLM authentication, trusted sites and so on….). Maybe you trust in /alfresco context url and not in share one ?

Regards.

–C.

catar4
Champ in-the-making
Champ in-the-making
It's been a while and I had forgotten about this post. Finally, there are issues with NTLMv2 in Alfresco Share (version 3.4) and using NTLMv1 wasn't an acceptable solution so we decided to go with Kerberos in the end. Thanks.