> > > 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
signature.asc
Description: This is a digitally signed message part
-- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/[email protected]
