How to find the cause of a failed user login with debug logging
プラットフォームについて: Data Center - この記事は、Data Center プラットフォームのアトラシアン製品に適用されます。
このナレッジベース記事は製品の Data Center バージョン用に作成されています。Data Center 固有ではない機能の Data Center ナレッジベースは、製品のサーバー バージョンでも動作する可能性はありますが、テストは行われていません。サーバー*製品のサポートは 2024 年 2 月 15 日に終了しました。サーバー製品を利用している場合は、アトラシアンのサーバー製品のサポート終了のお知らせページにて移行オプションをご確認ください。
*Fisheye および Crucible は除く
要約
As a Jira administrator you sometimes have to figure out why a user login unexpectedly fails. But how can you tell the difference between if the user was rejected because of a bad password, the user not being found and the user not having adequate permissions to use the application?
By using the debug logging and details described in this article you can figure out the real cause without having to resort to time consuming trial and error.
適用先
- Jira Data Center
This was tested in Jira 9.4. Newer versions from after this was written may have slight differences in the logging.
First understand the user authentication steps
To make sense of the logging, we first have to understand the main steps of the user authentication process.
These are the main steps taken in the order they happen:
- The first directory in the directory list is asked about the user. If not found in the first directory, Jira moves on to query to second directory, and so on. (see the Managing multiple directories documentation)
- Once a user is found by a directory, this directory will also validate the users credentials (i.e. password) and return the result to Jira.
- Jira then just wants an answer to the question "Was the user authenticated? Yes/No?" from the directory. It does not concern itself with the password authentication, which is handled solely by the directory. (This is the case for both external directories and the Internal Directory. Remember that the Internal Directory in Jira is also a directory server on its own; it is an embedded version of Atlassian Crowd.)
- If the answer from the directory is "No?" then Jira will reject the login attempt and log this into the security log, 'atlassian-jira-security.log', with the reason given to it from the directory and stop here. If it's "Yes" then it moves on to the next step.
- Then Jira the verifies if the user has access to the Jira application.
- The user is logged in and this is logged in the security log, 'atlassian-jira-security.log'
None of these steps will check any Jira permissions, such as project permissions. That is a separate process done later.
Then check the logs
Now you are probably wondering how you can determine at which one of the above steps the user authentication failed. With the default logging level this will be obscured and you will only see if the attempt was successful. But debug logging allows you to see the precise reason.
You will first need to set these packages to log level DEBUG:
com.atlassian.crowd
com.atlassian.seraph.auth
com.atlassian.jira.security.login
(See Change logging levels in Jira Server / Data Center for instructions)
To avoid too much logging, when you are done, do not forget to set the above packages back to the default log levels: WARN.
Ok, the debug logging is set. So which one is it?
By paying attention to these details in the logs you can then tell the difference between a user that is not found, using the wrong credentials and not having the right application permissions.
The username is 'asdf' in these log examples. The log file is '<your Jira home dir>/log/atlassian-jira.log'.
Scenario 1: User does not exist
If a user does not exist in a directory you will get this logging.
2023-12-15 04:40:14,994+1100 http-nio-8090-exec-11 url: /jira/login.jsp anonymous 280x9528x1 1k71cr6 0:0:0:0:0:0:0:1 /login.jsp login : 'asdf' and password provided - remember me : false - attempting login request
2023-12-15 04:40:14,999+1100 http-nio-8090-exec-11 url: /jira/login.jsp anonymous 280x9528x1 1k71cr6 0:0:0:0:0:0:0:1 /login.jsp runAuthentication : 'asdf' does not require elevated security check. Attempting authentication...
2023-12-15 04:40:15,010+1100 http-nio-8090-exec-11 url: /jira/login.jsp anonymous 280x9528x1 1k71cr6 0:0:0:0:0:0:0:1 /login.jsp login : 'asdf' has not been authenticated
2023-12-15 04:40:15,010+1100 http-nio-8090-exec-11 url: /jira/login.jsp anonymous 280x9528x1 1k71cr6 0:0:0:0:0:0:0:1 /login.jsp login : 'asdf' could not be authenticated with the given password
2023-12-15 04:40:15,010+1100 http-nio-8090-exec-11 url: /jira/login.jsp anonymous 280x9528x1 1k71cr6 0:0:0:0:0:0:0:1 /login.jsp login : 'asdf' tried to login but they do not have USE permission or weren't found. Deleting remember me cookie.
2023-12-15 04:40:15,010+1100 http-nio-8090-exec-11 url: /jira/login.jsp anonymous 280x9528x1 1k71cr6 0:0:0:0:0:0:0:1 /login.jsp runAuthentication : 'asdf' was UNSUCCESSFULLY authenticated
Explanation: We know that this user was not found and that it was not rejected because of the password. This is because of the absence of a "FAILED authentication" line that you do get when trying the 'asdf' user with the correct password. Because that message comes from the credentials check which is never executed if the user is not found and we will only get the "'asdf' tried to login but they do not have USE permission or weren't found." log message and nothing more.
Scenario 2: The directory rejected the password
If a user is found but the password is rejected, then you will get the "FAILED authentication" line. You will get that line if the credentials were not accepted and only then.
2023-12-12 01:14:01,755+1000 http-nio-8090-exec-22 url: /jira/rest/gadget/1.0/login anonymous 74x9273x1 z03wsd 0:0:0:0:0:0:0:1 /rest/gadget/1.0/login login : 'asdf' tried to login but they do not have USE permission or weren't found. Deleting remember me cookie.
2023-12-12 01:14:01,787+1000 http-nio-8090-exec-22 url: /jira/rest/gadget/1.0/login anonymous 74x9273x1 z03wsd 0:0:0:0:0:0:0:1 /rest/gadget/1.0/login The user 'asdf' has FAILED authentication. Failure count equals 1
Scenario 3: The user is found, the credentials were accepted, but the user is not in the 'jira-users' group
If a user has first passed through the two above checks, Jira then performs the application access check. If that fails you will get logging like this:
2023-12-12 01:14:59,653+1000 http-nio-8090-exec-18 url: /jira/rest/gadget/1.0/login anonymous 74x9274x1 z03wsd 0:0:0:0:0:0:0:1 /rest/gadget/1.0/login login : 'asdf' tried to login but they do not have USE permission or weren't found. Deleting remember me cookie.
2023-12-12 01:14:59,668+1000 http-nio-8090-exec-18 url: /jira/rest/gadget/1.0/login anonymous 74x9274x1 z03wsd 0:0:0:0:0:0:0:1 /rest/gadget/1.0/login The user 'adsf' is NOT AUTHORIZED to perform this request
Notice the difference of "NOT AUTHORIZED" versus the "FAILED authentication" in Scenario 2.
Now you can determine at which step the user login fails and can focus your efforts on the right step straight away!