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:

  1. 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)
  2. 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. 
  3. 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.)
  4. 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.
  5. Then Jira the verifies if the user has access to the Jira application. 
  6. The user is logged in and this is logged in the security log, 'atlassian-jira-security.log'


(lightbulb) 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)

(warning) 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! 



最終更新日 2024 年 11 月 5 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.