Kevin Teague wrote:

I am using the "LDAP Admin” tool to update an OpenLDAP server on Windows. This works just fine.

However, when I update members of a group in LDAP with LDAP Admin, those changes are not be seen by another application which queries LDAP (Atlassian's Crowd). Clearly this application is caching results from LDAP and there is a bug in that application's caching where updates don't get detected (I can always see changes made with LDAP Admin with other LDAP).

I only know the LDAP integration of Jira in detail. Usually they have kind of an update process they run from time to time. And you can trigger this update process manually.

If I update LDAP with other clients (python-ldap, phpldapadmin), then that application has no problem seeing the updates. It’s only when modifications are made with LDAP Admin that updates aren’t seen.

Yeah, it's a super weird bug …

I don't know the tools you're using in detail.

But I doubt that there's a difference when using different LDAP clients.

Please make sure to always compare LDAP clients and their results by doing the *exactly* same operation.

Is there something on an OpenLDAP server which tells clients if an entry has been modified? And it’s possible to somehow bypass that thing which gets updated?

LDAP clients could use syncrepl to get modifications instantly. I doubt that you're using something like that.

I can modify a group with LDAP Admin and run an LDIF and see that the modifyTimestamp field is being properly updated. I'm totally stumped as to how an OpenLDAP entry can be updated in a way that another client (with possibly aggressive or buggy query result caching) is able to somehow ignore that update.

There might be some ACLs in place which restrict what Atlassian's Crowd LDAP client can see. If e.g. they are using a query with (modifyTimestamp>=foo) to detect recent changes and access to attribute 'modifyTimestamp' is prohibited to the LDAP identity doing the search there won't be any results.

Ciao, Michael.