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.