-
Suggestion
-
Resolution: Low Engagement
-
None
-
0
-
5
-
NOTE: This suggestion is for JIRA Cloud. Using JIRA Server? See the corresponding suggestion.
We are using Jira with LDAP authentication. What happens when a user leaves is that we set his account inactive in LDAP, however Jira is not configurable to read whatever OpenLDAP field contains that info, so we and up wit a wasted user in Jira. It would be grat to have Jira reading that information from OpenLDAP and then setting the user as Inactive.
- is caused by
-
CWD-2762 Support changing active status (activating/deactivating) for users in OpenLDAP directories
-
- Long Term Backlog
-
- is related to
-
- Closed
-
- Gathering Interest
- relates to
-
- Closed
[JRACLOUD-34557] Jira should read from OpenLDAP a flag to make users inactive
Mr E
added a comment - Simple workaround is to add !(nsaccountlock=True) to the "User Object Filter" in ldap configuration. Fx
(&(objectclass=inetorgperson)(!(nsaccountlock=True)))
Mr E
added a comment - Simple workaround is to add !(nsaccountlock=True) to the "User Object Filter" in ldap configuration. Fx
(&(objectclass=inetorgperson)(!(nsaccountlock=True)))
Yuri Gorshkov
added a comment - 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 
Yuri Gorshkov
added a comment - 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.
Hi everyone,
Thank you for bringing this suggestion to our attention.
As explained in our new features policy, there are many factors that influence our product roadmaps and determine the features we implement. When making decisions about what to prioritize and work on, we combine your feedback and suggestions with insights from our support teams, product analytics, research findings, and more. This information, combined with our medium- and long-term product and platform vision, determines what we implement and its priority order.
Unfortunately, as a result of inactivity (no votes or comments for an extended period of time), this suggestion didn’t make it to the roadmap and we are closing it.
While this issue has been closed, our Product Managers continue to look at requests in https://jira.atlassian.com as they develop their roadmap, including closed ones. In addition, if you feel like this suggestion is still important to your team please let us know by commenting on this ticket.
Thank you again for providing valuable feedback to our team!