Jira & Portal unable to login with

[Abi]

I am currently upgrading my atlassian environment.

My current Jira version is 9.12.15, trying to upgrade to LTS 10.3.12.
My current Confluence version is 8.9.8, im looking to upgrade to LTS 9.2.9.
My current Crowd version is 5.3.1, im looking to upgrade to 7.1.0

Currently in my dev environment i have setup a test instances for crowd, jira, and confluence. Before I attempted to upgrade crowd to 7.1.0, I had the integration with crowd between jira, and confluence working. All the apps were able recognize each other, and if i logged into one, i was able to log into the other.

Now when I upgraded crowd to 7.1.0, i ran into no issues from what i can tell in the installation log, and upon startup. Post upgrade, I am able to log into crowd, using my a crowd directory synced with entra id. So logging into crowd itself is fine, able to use my domain credentials. However, I am unable to log into jira and confluence through crowd. I can attest that the "crowd.properties" has the correct crowd url/credentials. And inside the database the crowd directory the "crowd.server.url" has the correct crowd url, along with the correct credentials.

When i attempt to login to Jira, on Crowd i can see (so my login request are reaching my crowd server):
2025-10-11 22:32:49,430 http-nio-8080-exec-13 INFO [plugin.rest.filter.BasicApplicationAuthenticationFilter] Invalid authentication for application with name 'jira-dev'

So i thought the credentials, is wrong but I can attest that I have been consistent with it (updated inside crowd, crowd.properties, and the database crowd directory). Even trying a new password, and new crowd application name. It still does not work. Same error as above.

Now a odd thing is that, when i log into crowd. And then i open up jira url. I am able to access jira, and see my issues. But when i go to admin settings and login again, it doesnt let me. (I am an admin). I know this can happen if the crowd.server.url is not matching your crowd server, but in this case it is :(. 

I did go through the upgrade notes and didnt see anything that might affect authentication/login process up to 7.1.0. I did see stuff about OAuth2.0 being added, but it seemed like it didnt mess with the crowd login integration . In "Authentication Methods" i do have have "Allow basic authentication on API calls" enabled. If i disabled, i get this error inside jira logs,
2025-10-11 23:53:59,789+0000 http-nio-8080-exec-23 ERROR anonymous 1433x1518x1 x5svmq /rest/tsv/1.0/authenticate [c.a.c.manager.application.ApplicationServiceGeneric] Directory 'Crowd Server (id)' is not functional during authentication of '<myusername>'. Skipped.


Some notes:

- for my crowd installation, the url "https://<crowd_base_url>/crowd/services/" returns a dead link. Is that supposed to be the case? 

tldr; unable to login to jira/confluence with crowd integration post upgrade to 7.1.0

[Kai Krause]

Hi and Welcome,

Crowd 7.0 Release Notes | Crowd Data Center 7.1 | Atlassian Documentation 

in Crwod 7.0 the authentication Api has breaking changes so. So i assume your old Jira and confluence Versions are try to talk with the old api to crowd.

What Changed in Crowd 7.0+

Deprecated/Removed:

• com.atlassian.crowd.manager.authentication.TokenAuthenticationManager (the old authentication API)
• Legacy SOAP-based authentication methods
• The /services/ endpoint you mentioned is likely part of the deprecated SOAP API

New Requirement:

• Applications must now use com.atlassian.crowd.service.authentication.CrowdApplicationAuthenticationService
• REST API-based authentication (introduced in earlier versions, now mandatory)
• Enhanced OAuth 2.0 support for application links

Why You're Seeing "Invalid authentication for application"

The error Invalid authentication for application with name 'jira-dev' occurs because:

1. Jira 9.12.15 and Confluence 8.9.8 were built to work with Crowd's older authentication API
2. Crowd 7.1.0 has deprecated/changed the authentication mechanism
3. Your applications are still trying to authenticate using the old method, which Crowd 7.1.0 either rejects or handles differently
   
   

About the /services/ Endpoint

The /services/ endpoint returning a dead link is expected behavior in Crowd 7.0+. This was part of the old SOAP-based services that have been removed or deprecated.

I think that as a first step it could help , to recreate the application in Crowd 7.1.0: 

• Delete jira-dev application
• Create new application with exact same credentials
• Verify IP address matches your Jira server
  
  

Hopefully it helps and you can go to the new Versions of jira and confluence.  ....

BR
Kai 

[Abi]

Thank you, will try this.

[Abi]

Okay, so I was able to solve this issue.

If anyone in the future encounters this issue, you need to change to what it was before the password inside the Crowd's Jira application. Once i did that, the authentication invalid errors went away. Very weird. 

[Rilwan Ahmed]

Hi @Abi ,

Here are the top suspects:

crowd.server.url mismatch due to port, context path, or protocol. Even a subtle difference.
Example:. http://localhost:8095/ crowd vs http://127.0.0.1:8095/crowd , or https vs http can break the REST call Jira uses for admin re-authentication.

application.name or application.password mismatch
Crowd validates these when Jira tries to authenticate back. If the password was reset in Crowd or the app definition got duplicated after the upgrade, re-auth will fail.

Crowd cookie domain or SameSite configuration
If crowd.sso.domain or the SameSite=None; Secure attribute is misaligned, cookies work for initial login but fail for re-auth contexts (which Jira treats as separate sessions).

Crowd 7.1 tightened REST API behavior
Crowd 7+ enforces stricter URL validation and may reject old client versions or requests without proper HTTPS or base URL match.

Things to re-check:

Check the crowd.properties file in Jira
Usually in:

$JIRA_INSTALL/atlassian-jira/WEB-INF/classes/crowd.properties

Make sure these match exactly what’s configured in Crowd → Applications → Jira:

application.name = jira
application.password = <matches password in Crowd>
crowd.server.url = http://<exact Crowd base URL>/crowd
crowd.base.url = http://<exact Crowd base URL>/crowd
session.validationinterval = 0
crowd.application.url = http://<exact Jira base URL>

Pay special attention to the protocol (http/https) and hostname. Even “localhost” vs “127.0.0.1” will break re-auth.

Test Crowd’s application connection manually
In Jira:

Go to Administration → User Management → Crowd Integration → Test Connection.

Does it say “Connection successful”? If not, that’s your smoking gun.

Check the Jira log right after failing admin re-auth
Look for lines like:

Failed to authenticate application 'jira' to Crowd

or

Application failed to authenticate to Crowd server

These indicate mismatch in app credentials or URL.

Verify Crowd application settings
In Crowd:

Applications → Jira → Remote addresses: make sure it includes Jira’s actual IP/hostname.

Ensure “Active” is checked.

Verify SSO is enabled for that application.

If using HTTPS, check crowd.properties and Java keystore trust — Crowd 7.1 may reject connections without a trusted SSL cert.

Suggested fix :

1. If everything looks correct but still fails, In Crowd, reset the Jira application password (in the Applications tab).
2. Update crowd.properties in Jira with the new password.
3. Restart Jira.
4. Re-test the “Test Connection” and then the admin login.

[Abi]

Thank you for responding. I tried what you had suggested above- except the "Java keystore trust" part on the Jira app. 

I looked through the logs again and i saw this stand out to me: 

"2025-10-12 23:37:49,739 http-nio-8080-exec-2 INFO [applinks.core.manifest.AppLinksManifestDownloader] Authenticator com.atlassian.applinks.api.auth.types.TrustedAppsAuthenticationProvider specified by remote application bb3b7f0a-4819-37b9-b251-2c444cad9e51 is not installed locally, and will not be used.
2025-10-12 23:37:49,739 http-nio-8080-exec-2 INFO [applinks.core.manifest.AppLinksManifestDownloader] Authenticator com.atlassian.applinks.api.auth.types.BasicAuthenticationProvider specified by remote application bb3b7f0a-4819-37b9-b251-2c444cad9e51 is not installed locally, and will not be used.
2025-10-12 23:37:49,739 http-nio-8080-exec-2 INFO [applinks.core.manifest.AppLinksManifestDownloader] Authenticator placeholder.to.ensure.backwards.compatibility specified by remote application bb3b7f0a-4819-37b9-b251-2c444cad9e51 is not installed locally, and will not be used."

Do you happen to know what this is referring to? It seems like I'm missing some .jar files for the old authentication ways

I did disable the UPM, in this current crowd upgrade. Do you think that is related to this?