Trying to setup SSO with Crowd and Confluence

[Steve Boucher]

I have Crowd version 2.12 and Confluence version 6.7.0 installed on different RHEL servers.

Crowd SSO already works good for JIRA, BitBucket and Bamboo.

But, it doesn't work for Confluence. I have a username/password error.

If I setup Crowd authentication in Confluence *without* SSO. It works.

I've setup crowd.properties and commented/uncommented the lines in seraph-config.xml. 

The logs don't tell me much. Any idea where to look for more troubleshooting?

[AnnWorley]

Quick follow-up after the Inquisition:

Examining the crowd.properties file from Confluence and the base URL used in the user directory setup, we discovered that the base URL line in the crowd.properties file contained the hostname without the SSO domain. Once Steve changed it, users were able to log in as expected.

[AnnWorley]

I understand that you can log into Confluence with an account from the Crowd user directory if you do not enable SSO but with SSO enabled, you cannot log into Confluence through Crowd, with a bad username or password message .

By commenting out the default authenticator in Confluence's seraph-config.xml you force authentication to go through the Crowd user directory in Confluence. Usually SSO issues revolve around logging in and then not being logged in automatically to other apps. It is unusual to be unable to log in at all.

In this case, I wonder if the user who logs in via Crowd without SSO is really from the Crowd directory. Please verify by checking to make sure that when you log in with Crowd the users that can log in are really in the Crowd user directory, and not the internal directory as shown below:

[Steve Boucher]

The user is from the crowd directory as I have only one user (the administrator) in the internal directory and I'm not using this one for testing.

When I try to login using SSO, it fails, but I see no logs anywhere. Not in crowd, not in confluence. Is there a way to see logs of all the login process in confluence?

[AnnWorley]

In Confluence, when a user login fails due to a bad password, the <confluence_home>/logs/atlassian-confluence log will have an entry such as:

2018-02-02 09:10:50,342 WARN [http-nio-8090-exec-1] [atlassian.seraph.auth.DefaultAuthenticator] login login : 'admin' tried to login but they do not have USE permission or weren't found. Deleting remember me cookie.

It's a pretty useful message in that it says which authenticator is being used but it is vague as to why the user couldn't log in. In fact it is misleading because the user does exist and have use permission.

However, if we turn on DEBUG logging for the com.atlassian.crowd.embedded and com.atlassian.crowd.directory classes we can see more details as to why the user cannot authenticate, for example;

2018-02-02 09:13:44,581 DEBUG [http-nio-8090-exec-1] [crowd.embedded.atlassianuser.EmbeddedCrowdAuthenticator] authenticate Authenticating user 'admin' by password
2018-02-02 09:13:44,603 DEBUG [http-nio-8090-exec-1] [crowd.embedded.atlassianuser.EmbeddedCrowdAuthenticator] authenticate Authentication failed for username 'admin' because the password was incorrect.

To turn on DEBUG logging please go to Confluence Admin>Logging and Profiling, locate the classes com.atlassian.crowd.embedded and com.atlassian.crowd.directory on the list and set them to DEBUG level to gather more information. The DEBUG logging can quickly fill the logs so I recommend turning it off after you are finished gathering information.

On the Crowd log side, are you  checking the atlassian-crowd.log in <Crowd_Home>/logs? Sometimes people don't find that log because there is another set of logs in the install directory.

[Steve Boucher]

I found the logs and was able to find

 [http-nio-8091-exec-21] [atlassian.seraph.auth.DefaultAuthenticator] login login : 'adm_sboucher' tried to login but they do not have USE permission or weren't found. Deleting remember me cookie.

 but, I don’t see any DEBUG logs even after turning on debug logs for com.atlassian.crowd.embedded and com.atlassian.crowd.directory 

 Crowds logs mentioned nothing. It’s like if there wasn’t any attempts at all on the server.

 The only errors I see are these

 2018-02-02 15:26:32,946 WARN [ListenableFutureAdapter-thread-1] [plugins.synchrony.bootstrap.DefaultSynchronyProxyMonitor] pollHealthcheck Could not ping the synchrony-proxy [http://127.0.0.1:8090/synchrony-proxy/healthcheck]: {}

java.net.SocketTimeoutException: Read timed out

…

I have no idea if this is related.

[AnnWorley]

Hey there, Steve. Rather than conducting the Spanish Inquisition over the public forum (I have a lot of questions) I have created a support request on your behalf. Please expect an email from me shortly requesting logs and other materials.

[Steve Boucher]

Good.

As far as the Spanish Inquisition is concerned, I have not sinned in the last day. lol

Thanks.