Uploaded image for project: 'Crowd Data Center'
  1. Crowd Data Center
  2. CWD-1972

User authentication fails for new users when using delegated authentication directory with auto-add-to-directory enabled

      Symptoms as reported by one of the users experiencing this bug:

      New users, who have never used Confluence or JIRA before, cannot log in with their Windows account and password. They get a message saying 'Sorry, your username and password are incorrect. Please try again'. When we test the users credentials in the Application 'Authentication Test' we get a 'Successful verification', but the user cannot log in to Confluence or JIRA.

      I have found that if I update the Delegated Authentication Directory BASE DN to an invalid value and then reset the same BASE DN to the correct value the users can log in. This seems to only be valid for a short period of time. Eventually any new users attempting to log in are not allowed, getting the same 'Sorry, your username and password are incorrect. Please try again' message.

      Nothing helpful in the logs.

      Affecting both JIRA and Confluence.

      Current workaround is to manually add users to the delegated authentication directory.

            [CWD-1972] User authentication fails for new users when using delegated authentication directory with auto-add-to-directory enabled

            It's a bug in JIRA; please watch JRA-21876 for the JIRA fix.

            David O'Flynn [Atlassian] added a comment - It's a bug in JIRA; please watch JRA-21876 for the JIRA fix.

            You could:

            if (!authenticate(user, pwd))
            {
              if (!find(user))
              {
                // hmm, dodgy...
              }
            }
            

            It should give you the same logic/protection and work with Crowd.

            David O'Flynn [Atlassian] added a comment - You could: if (!authenticate(user, pwd)) { if (!find(user)) { // hmm, dodgy... } } It should give you the same logic/protection and work with Crowd.

            It is indeed because JIRA has an "optimisation" in the security check code that says "if the user does not exist" then we are not going to give them a chance at authentication.

            Obviously this does not work in the case where Crowd is "lazily" adding the user on first authentication attempt.

            We can remove this "optimisation" but we will need to think about implications from a security point of view. Off hand I cant think of too many.

            ɹǝʞɐq pɐɹq added a comment - It is indeed because JIRA has an "optimisation" in the security check code that says "if the user does not exist" then we are not going to give them a chance at authentication. Obviously this does not work in the case where Crowd is "lazily" adding the user on first authentication attempt. We can remove this "optimisation" but we will need to think about implications from a security point of view. Off hand I cant think of too many.

            sladey added a comment -

            I have asked Brad to comment on this since he was responsible for the elevated security check work.

            sladey added a comment - I have asked Brad to comment on this since he was responsible for the elevated security check work.

            Peggy added a comment - - edited

            Did some further testing/investigation into this issue and it appears that the fix needs to be done in JIRA.

            As Shihab pointed out above, in order for Crowd delegated directory to work, there needs to be a successful authentication call for the user to be cloned into Crowd to allow for successful authentication.

            The problem is the introduction of ElevatedSecurityCheck between JIRA 4.0 and 4.1. With this check, when the 'getLoginInfo/getUser' call in JIRA returns null, JIRA does not perform any further authentication calls on this user. Therefore, the user never gets cloned into Crowd, meaning they will not be able to login. The problem with this is if you attempt to login with a fake username multiple times, you will never receive a CAPTCHA (you just keep getting the 'login failed' error message)

            Confluence handles the EleveatedSecurityCheck differently. To determine if a user should be given permission to attempt authentication, Confluence checks if the number of failed login attempts is less than the maximum attempts allowed. So this means if a "non existent" user first attempts to authenticate, they will have made 0 failed attempts - so the authentication call is made. If this was a valid user, the authentication call will be successful and the user will be cloned into Crowd and all is happy. If it was an invalid user, the failed attempts count will increase and after x attempts, a CAPTCHA will be shown.

            Tested with:

            • JIRA 4.1.2
            • Confluence 3.3
            • Crowd 2.0.7

            Peggy added a comment - - edited Did some further testing/investigation into this issue and it appears that the fix needs to be done in JIRA. As Shihab pointed out above, in order for Crowd delegated directory to work, there needs to be a successful authentication call for the user to be cloned into Crowd to allow for successful authentication. The problem is the introduction of ElevatedSecurityCheck between JIRA 4.0 and 4.1. With this check, when the 'getLoginInfo/getUser' call in JIRA returns null , JIRA does not perform any further authentication calls on this user. Therefore, the user never gets cloned into Crowd, meaning they will not be able to login. The problem with this is if you attempt to login with a fake username multiple times, you will never receive a CAPTCHA (you just keep getting the 'login failed' error message) Confluence handles the EleveatedSecurityCheck differently. To determine if a user should be given permission to attempt authentication, Confluence checks if the number of failed login attempts is less than the maximum attempts allowed. So this means if a "non existent" user first attempts to authenticate, they will have made 0 failed attempts - so the authentication call is made. If this was a valid user, the authentication call will be successful and the user will be cloned into Crowd and all is happy. If it was an invalid user, the failed attempts count will increase and after x attempts, a CAPTCHA will be shown. Tested with: JIRA 4.1.2 Confluence 3.3 Crowd 2.0.7

            shihab added a comment -

            It appears that the problem is caused when a new LDAP user attempts to authenticate via JIRA 4.1 to Crowd, when Crowd is hooked up to LDAP via a delegated authentication directory.

            The delegated authentication directory should automatically clone the LDAP user into the database on successful authentication. It appears that the user is not cloned.

            Support engineers have confirmed this bug does not occur in JIRA 4.0. It also does not occur in Confluence (tested with 3.2). It has only manifested itself in JIRA 4.1.

            We will need to investigate the authentication call JIRA makes in 4.1 and how that has changed from 4.0. One possibility is that JIRA attempts to find the user before attempting to authenticate the user - the find will fail as the user would not have been cloned in until a successful authentication.

            We will post more information after further investigation.

            shihab added a comment - It appears that the problem is caused when a new LDAP user attempts to authenticate via JIRA 4.1 to Crowd, when Crowd is hooked up to LDAP via a delegated authentication directory. The delegated authentication directory should automatically clone the LDAP user into the database on successful authentication. It appears that the user is not cloned. Support engineers have confirmed this bug does not occur in JIRA 4.0. It also does not occur in Confluence (tested with 3.2). It has only manifested itself in JIRA 4.1. We will need to investigate the authentication call JIRA makes in 4.1 and how that has changed from 4.0. One possibility is that JIRA attempts to find the user before attempting to authenticate the user - the find will fail as the user would not have been cloned in until a successful authentication. We will post more information after further investigation.

              pkuo Peggy
              ganand Gurleen Anand [Atlassian]
              Affected customers:
              3 This affects my team
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: