This can be difficult to answer. All of these products can either manage users locally, or can connect to an external LDAP/AD directory, or both. So failed login attempts for LDAP accounts could lockout the account in LDAP for any/all of these applications. But to be clear, it's the LDAP instance that is actually locking that account. Sure the login attempt might have come from JIRA, but when the accounts are LDAP accounts it is the LDAP instance that controls whether the account is active/inactive/lockedout. Just wanted to make that distinction first.
However if you're only using the internal user directories of these applications (not for ldap accounts), then JIRA won't technically lock out an internal user account. By default, after 3 failed attempts it simply requires a CAPTCHA be completed along with the correct password to login. Not sure if this is a distinction you are concerned about or not, but JIRA won't technically lock out an account for failed login attempts, it just requires an addition captcha be completed at the time of login.
Crowd - can be configured to disable an account if failed login a certain number of times. By default this setting as a value of 0 though which disables that feature, but this can be configured in Crowd.
The other complicating factor is that Crowd can be used as a means to handle authentication for (just about) all the other server versions of the Atlassian products. So if you have configured those applications to use Crowd instead of their own user directories, it is possible.
Confluence, Fisheye/Crucible, Bitbucket server, Bamboo are all in the same league with JIRA. They don't technically lockout internal users, but they all tend to have a captcha system.
Hipchat Server - can lockout accounts after failed login attempts.
Cloud offerings - can also lockout accounts for failed login attempts
I know this is an old post, however I have a related question. Is it possible to have an LDAP/AD directory that does not lock out user accounts, yet does require a captcha after a certain number of incorrect logins? Or is this functionality dependent on the LDAP instance's lockout policy.
LDAP isn't the one requiring CAPTCHA. Jira is. So yes, it is possible that your LDAP/AD settings could be set to allow more failed login attempts before that account is locked. But you have strike a balance between allowing your users enough attempts to get their password right and not allowing brute force attempts to crack a password. If you're using Active Directory, check out this blog about configure account policy. It gives a good overview of the things to consider here.
In Jira, you can configure the maximum number of failed login attempts before a captcha is required, check on Configuring Jira Application options.
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs