Unable to login to migrated confluence using crowd server

Nicolas_Grussenmeyer May 31, 2017

We are running confluence 5.4.4 with crowd server authenticaiton. I want to upgrade it so I'm trying to setup a staging instance.

I've installed the 5.4.4 confluence server with the exe file, then created a mysql schema and imported the backup.xml to populate this staging instance.

As we are using a crowd server to authenticate I modified the crowd.properties config file to point on the crowd server and I also modified seraph-config.xml and seraph-paths.xml

As the crowd.server.url attribute was not changed in the database (according to the crowd.properties file), I updated it manually.

When I start confluence, there are no error message and the service is up and running (I even see the crowd sync successfull message)

When I try to login, I'm redirected to the confluence login page. Here is what I checked/tested:

- the crowd url is accessible from the server (works when I try to connect through web browser)

- according to this page I tried after clearing all cookies/private navigation; there are no firewall/proxy issue; I both tried to change the application path (as we are also running jira on the same server but on a different port and URL) and specified a cookie name in the web.xml file

- I activated the debug mod on the crowd server and it shows that the authentication request is handled in the same way that any other application we are currently using in production (jira, confluence, stash etc). All the authentication steps are successfull and it ends with "generating token" and "user xxx has access to the application <confluence>

Specs :

windows server 2012 r2

jira 7.4

confluence 5.4.4

java 1.7

 

I could not find any similar case on the community Q&A. Does anybody have an idea?

Thanks

 

 

1 answer

0 votes
Lars Olav Velle
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 31, 2017

Hello Nicolas,

I guess you are modifying seraph-config.xml and seraph-paths.xml because you want crowd sso? 

Why not remove SSO from the equation and make first make confluence avaliable.

 

Cheers,

Lars

Nicolas_Grussenmeyer May 31, 2017

Hello Lars,

Thank you for your answer. The thing is that I'm restoring the confluence instance with the XML backup file so the configuration items of the database are configured to use crowd sso.

I could validate that the confluence instance is running by typing the url with the username and password as options and it worked (access to the dashboard page but when you click somewhere else it asks for the login/password as it is not stored anywhere on the browser with this method).

Any other thoughts on this weird issue (crowd server validate the request but confluence server can't handle the session)?

 

* Edit : I did not understood the SSO part when I first red your answer. I deactivated it and it's working, I can log in confluence when Crowd SSO is disabled. Do you know what should I monitor to debug the SSO part?

Thanks

Lars Olav Velle
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 1, 2017

That sounds great. I guess I could have been more specific about the seraph config :)

This means that you now have only the SSO part to troubleshoot. 

I am not an expert on Crowd SSO since I am with a company that provide SSO though an add-on, but my guess is that the changes you are making to seraph-config.xml and seraph-paths.xml has some error.

Why are you altering seraph-paths.xml btw? I do not see any reference to that in the Atlasssian documentation.

https://confluence.atlassian.com/crowd/integrating-crowd-with-atlassian-confluence-198573.html

-Lars

 

Nicolas_Grussenmeyer June 1, 2017

In fact I didn't alter seraph-paths.xml, I just copied the one we had on the production server but the content of both files are the same (no modification).

I tried to configure a basic crowd.properties :

application.name confluence
application.password *********
application.login.url http://confluence.ourdomain.com:8000/

crowd.server.url https://sso.ourdomain.com/crowd/services/

session.isauthenticated session.isauthenticated
session.tokenkey session.tokenkey
session.validationinterval 2
session.lastvalidation session.lastvalidation

 

Still have the same issue. The crowd server validate the session but the confluence server says : 

ERROR [http-8000-9] [integration.seraph.v25.CrowdAuthenticator] getUser Could not find cookieToken from authenticated request

-- referer: http://confluence.ourdomain.com:8000/login.action;jsessionid=0195019009899640A83366A7J5F1288D?os_destination=%2Findex.action | url: /login.action | userName: anonymous | action: login

Lars Olav Velle
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 1, 2017

have you tried adding:

crowd.base.url= https://sso.ourdomain.com/crowd

Nicolas_Grussenmeyer June 1, 2017

Yes it was part of the original crowd.properties file. I removed it as I wanted to try with a minimal configuration during the debug.

it wasn't working either.

Nicolas_Grussenmeyer June 2, 2017

I've found the issue. It's simply because our crowd server has the "secure only" option activated. Our Confluence production instance is running on http but is redirected in https through a reverse proxy while the staging instance is not behind a proxy so it's only running in http. Unfortunately the error in the log is generic and not stating this secure only issue.

Thank you for your help Lars.

Lars Olav Velle
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 2, 2017

Great!

Sounds like there is room for some improvement in the logging!

No worries Nicolas.

Chers,

Lars

 

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events