Hi William,
thank you for the explanation. Does this mean, whenever an application
accesses the dynamic group, the memberURL attribute(s) will be sent back to
the app? After this, it's on the application to create a new ldap operation
using the parts of the memberURL ?
But if so, the host part of the url would not be correct, or? ldap:///
refers to the local directory server itself. Means, to get it working, there
must be the name of the directory server included as like
ldap://ldap1.example.org/ ?
I've not got a huge amount of experience with the memberUrl functionality. As I
understand it, the client application is responsible as you say (unless we had
the plugin)
I think in this case, the client application sees the ldap:/// and just parses
out the filter / base / scope, and uses that information only against the current
connected DS. So no, you don't need
ldap://ldap.example.com in your Url.
I think this is up to the client application though, so it would be well worth
you testing this in a staging environment.
I have created a ticket for the addition of a memberUrl expansion plugin, so that
sometime in the future we can address your needs.
https://fedorahosted.org/389/ticket/48664
*if* we create this plugin, then your client application does *not* need to be
memberUrl aware, as DS would return a set of member/memberUid attrs dynamically
generated from that list.
I hope this helps you.
--
Sincerely,
William Brown
Software Engineer
Red Hat, Brisbane