On Thursday, February 18, 2016 10:27:07 AM William Brown wrote: > > 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. Great! Thanks a lot again! -) cheers, Frank -- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx
