cancel
Showing results for 
Search instead for 
Did you mean: 

NTLM SSO Sharepoint Help Plz

102020
Champ on-the-rise
Champ on-the-rise
So Below you can see the config I am using, SSO on share page login works well, however, when trying through 'edit online', receive a login prompt - If you hit cancel on it, it will pass through SSO and load, it's just this one login prompt I can't seem to get rid of.

Here is my config (running 4.2.d):

### Authentication ###
authentication.chain=passthru1Smiley Tongueassthru,alfrescoNtlm1:alfrescoNtlm,ldap1:ldap-ad

ntlm.authentication.sso.enabled=true
ntlm.authentication.mapUnknownUserToGuest=false
ntlm.authentication.browser.ticketLogons=true
alfresco.authentication.allowGuestLogin=false
alfresco.authentication.authenticateCIFS=false
passthru.authentication.useLocalServer=false
passthru.authentication.domain=
passthru.authentication.servers=FQDNHERE\\DIRECTIPHERE
passthru.authentication.guestAccess=false
passthru.authentication.defaultAdministratorUserNames=admin
passthru.authentication.connectTimeout=5000
passthru.authentication.offlineCheckInterval=300
passthru.authentication.protocolOrder=TCPIP,NetBIOS
passthru.authentication.authenticateCIFS=true
passthru.authentication.authenticateFTP=true

### LDAP Integration ###
synchronization.authCreatePeopleOnLogin=false

ldap.authentication.active=true
ldap.synchronization.active=false
ldap.authentication.allowGuestLogin=false
ldap.authentication.java.naming.security.authentication=DIGEST-MD5
ldap.authentication.java.naming.provider.url=ldap://FQDNHERE:389
ldap.synchronization.java.naming.security.principal=administrator@FQDNHERE
ldap.synchronization.java.naming.security.credentials=MYPWDHERE
ldap.synchronization.groupSearchBase=ou\=MYGROUPHERE,dc\=FQDNHERE,dc=FQDNHERE





I have debug turned on right now for sharepoint, this is what I see:
2013-02-12 13:57:06,488  DEBUG [vti.web.VtiFilter] [194812753@qtp-1742977977-0] No authentication details found, requesting they authenticate
2013-02-12 13:57:07,814  DEBUG [vti.web.VtiFilter] [194812753@qtp-1742977977-0] Checking request for VTI
2013-02-12 13:57:07,814  DEBUG [vti.web.VtiFilter] [194812753@qtp-1742977977-0] Check authentication

When I hit cancel on the login prompt, everything goes like it should:
2013-02-12 13:57:07,970  DEBUG [vti.web.VtiFilter] [580081679@qtp-1742977977-2] Checking request for VTI
2013-02-12 13:57:07,970  DEBUG [vti.web.VtiFilter] [580081679@qtp-1742977977-2] Check authentication
2013-02-12 13:57:07,970  DEBUG [vti.web.VtiFilter] [580081679@qtp-1742977977-2] User was authenticated successfully
2013-02-12 13:57:07,970  DEBUG [vti.web.VtiFilter] [580081679@qtp-1742977977-2] Return VTI answer for HEAD request

Also have this floating around:
2013-02-12 13:57:07,908  INFO  [vti.web.VtiRequestDispatcher] [194812753@qtp-1742977977-0] Note - no handler was found for HEAD to uri='/it-handbook/documentLibrary/Disaster Recovery Plan.doc'
6 REPLIES 6

afaust
Legendary Innovator
Legendary Innovator
Hello,

in my experience, MS Office has a lot of issues dealing with non-SharePoint SharePoint-capable servers, since they apparently implemented a lot of weird workarounds for their internal problems. Have you tried disabling the Web Client service on the client hat uses MS Office to access Alfresco via SharePoint / Edit Online? I've found that the particular problem you are describing is directly related to that service and disabling it will get rid of that behavior. The core problem here is that Office for some reason will not transmit session or authentication in some specific requests on a certain Windows / Office patch level when that service is active.

Regards
Axel

102020
Champ on-the-rise
Champ on-the-rise
Well, gave your suggestion a try, with no luck. I did see a MS KB somewhere about getting a prompt exactly like this, it was directly related to a sharepoint server, I'll have to dig it up, as we ARE on a domain too. At least 1 login prompt is better than 4 like we used to get. But last issue I'm trying to sort out before we make our build go into production.

102020
Champ on-the-rise
Champ on-the-rise
So, I did manage to get it resolved, using SSL, LDAP & SSO.

The missing secret is to add your fqdn intranet site in IE so it can pass the credentials automatically - Somewhere along the line IE stopped auto detecting LAN based addresses.

102020
Champ on-the-rise
Champ on-the-rise
Anyone got an idea on this? It's my last bug really Smiley Sad

pshanahan4
Champ in-the-making
Champ in-the-making
Has anyone found a resolution to this issue?

102020
Champ on-the-rise
Champ on-the-rise
yes I did, go look at my other posts and youll find it. however now in 4.2.e sso has stopped again. trying to pin out if it's IE issue or alfresco issue at this point. I know ie11 is a huge fail.
but alfresco should fix login button, button type="button" should be type="submit" for ie11 to work properly.