> 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.