unpassable login prompt when accessing via SSL

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.

chrisokelly

Hi guys,

We have had Alfresco 4.0b running for a few weeks now and have successfully set up most of it (ldap-ad authentication, passthru for SSO and CIFS, Sharepoint). These are all working fine, with the minor exception that users who are not automatically logged in via SSO receive a system login prompt which does not accept their details.

Recently I set up SSL on the server, as well as a rewrite on the *:80 host to force https. This has gone down fine for windows users, however we have one or two mac's in the office which are now experiencing a new issue. When trying to access the share page, the mac users expect to see the alfresco login page (as their local mac accounts are no good for SSO of course). Since enabling SSL however, they see a system popup requesting their username and password, which does not accept any details, their own, admin or otherwise. If they click cancel on this prompt they are redirected to the share login page as per normal which accepts their details and logs them in. This issue has been particularly awkward to troubleshoot as I cannot reproduce it on my own windows setup, I am simply logged in automatically by my domain username.

Alfresco, catalina and apache logs show nothing in the time surrounding the issue, the only entry within 5 minutes of the last reproduction of this issue is a warning about a missing favicon.

our authentication chain is set up - alfrescontlm, passthru, ldap-ad and the passthru handles SSO and CIFS.
the SSL certificate is a self signed one, exceptions have been added.
I have made sure that in alfresco-global.properties the protocol for both share and alfresco is set to https

in setting up ssl a virtual host *:443 was set up in /etc/apache2/sites-available/default . I noticed that there was also a *:443 virtual host in default-ssl in the same directory, but as it had no directives specific to our setup I have tried commenting out the whole file in case there was some issue with duplicate hosts. This hasn't caused any changes that I can see.

My personal belief, based on the prompt seen on the macs, is that this has something to do with ports. I noticed in the prompt that it specified companyname.local:443 as the site requesting details, as opposed to companyname.local:8080. Could this be related? I have no previous experience with ReWriteEngine so I followed a tutorial to set up the rewrite, it is not designed specifically for our implementation and may not play well. I have included it below-

<VirtualHost *:80>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RewriteEngine on
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ReWriteCond %{SERVER_PORT} !^443$
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ReWriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L]
</VirtualHost>‍‍‍‍‍

The setup of our alfresco is still a very basic one, basically out of the box plus our authentication chain changes. We are running on Ubuntu 10.04.3 LTS with apache2, postgres and tomcat. Oh and we are running the community version (which doesn't stop me drooling over JMX Console and the prospect of making changes without a 10 minute service restart )

In the process of writing this out I have decided my next logical step is to try commenting the rewrite rule and trying to reproduce the issue again, so that's what I am going to try now but any advice would be greatly appreciated.

EDIT 2: Commenting the rewrite script wasn't the fix here, nor was changing the alfresco and share ports in alfresco-global.properties to 443. An extra bit of info I missed before is that going directly to the login page bypasses this issue, it only occurs if the user attempts to go to companyname.local/share.

ashex

What browser are your mac users using? Since this is localized try having them use Firefox and add the site to the trusted uri.