Simple workaround is to add !(nsaccountlock=True) to the "User Object Filter" in ldap configuration. Fx

(&(objectclass=inetorgperson)(!(nsaccountlock=True)))

Hi,

We're using FreeIPA here, which is based on 389 Directory Server, which is in turn based on Netscape Directory Server.

I contacted the FreeIPA developers with this issue and they told me you should also implement relying on nsAccountLock attribute for user lockouts, because it is widely supported by NS-derived LDAP servers.
Shouldn't be that hard, I think?
< ab> nsaccountlock is operational attribute OID 2.16.840.1.113730.3.1.610 that exists for more than 10 years (if not more)
<ab> all Netscape DIrectory-derived servers support it

So, one way of doing this is setting nsAccountLock=TRUE

The other way is described in this comment.
I would really appreciate if we could roll out a solution for this problem, basically because it makes our directory unusable with JIRA

... however Jira is not configurable to read whatever OpenLDAP field contains that info ...

The problem is that there seems to be no standard way to disable users in OpenLDAP (let alone in LDAP in general).
Searching the internet shows that people are employing all sorts of weird and wonderful approaches to disabling users in Open LDAP.
These include

• Set shadowExpire=0 on shadow account
  http://www.openldap.org/lists/openldap-technical/200810/msg00106.html
  http://www.bluelightav.org/display/BLUE/LDAP+Password+Policy+with+shadowAccount
• Setting pwdAccountLockedTime in OpenLDAP ppolicy overlay
  pwdAccountLockedTime looks like "20081021135537Z"
  http://www.openldap.org/lists/openldap-technical/200810/msg00107.html
• Set an Access Control List (ACL) on the user object that denies the user the right to bind.
  http://www.openldap.org/lists/openldap-technical/200810/msg00118.html
• hacking the user password to something that cannot hash
  http://www.openldap.org/lists/openldap-technical/201111/msg00166.html

So it looks to me that such a field does not exist, certainly not a single well-known standard field.
We could make the field name configurable of course (we do that for all the LDAP fields), but even so, it seems that different fields will have different value formats that need to be interpreted in custom ways.
To make matters more interesting, we would hope for a solution that would also be applicable in other LDAP types not just Open LDAP.

Now, I am not a sys admin, and I have a very shallow understanding of LDAP, so perhaps someone with more LDAP experience can suggest an acceptable solution?
cova perhaps you can get your LDAP admins to chime in here?
How do you guys disable users and can this be considered "standard"? How would you suggest JIRA detects disabled accounts?

JIRA uses "embedded crowd" as a library for its user management, and hence this will be fixed in JIRA once CWD-2762 is fixed.