Hi:
I'm trying to migrate an old LDAP server (that holds an ldap tree for Open-Xchange) to a new installation of OpenLDAP 2.3.43.
A lot of users had configured their Outlook in a way that they make a base search for ou=Users,ou=OxObjects,dc=domain,dc=com in their LDAP address book. But my new LDAP tree won't have ou=OxObjects,dc=domain,dc=com entry, i'm creating a new ldap structure to be used with GOSA.
So I decide to create a referral like this:
dn: ou=Users,ou=OxObjects,dc=domain,dc=com ou: Users objectclass: referral objectclass: extensibleObject ref: ldap://HOSTNAME/ou=people,dc=domain,dc=com
This works fine, now Outlook users can find their contacts using the same base search (ou=Users,ou=OxObjects,dc=domain,dc=com) but now GOSA got in problems because it finds two administrator users (cn=System administrator,ou=people,dc=domain,dc=com) because of the referral. I just would like to GOSA doesn't follow referrals or just searches for users under ou=people,dc=domain,dc=com instead of the root dc=domain,dc=com, but it seem that GOSA isn't good enough to customize this yet.
So I think I could modify my referral to return not all attributes, just some of them (the attributes commonly used by an address book search) like this:
dn: ou=Users,ou=OxObjects,dc=domain,dc=com ou: Users objectclass: referral objectclass: extensibleObject ref: ldap://HOSTNAME/ou=people,dc=domain,dc=com?cn,sn,givenName,telephoneNumber,mail
After updating my referral and I make an ldapsearch:
# ldapsearch -xLLL "(uid=admin)"
I still get two entries (two administrators) and both of them returns all its attributes. Then I tried to modify my referral like this:
dn: ou=Users,ou=OxObjects,dc=domain,dc=com ou: Users objectclass: referral objectclass: extensibleObject ref: ldap://HOSTNAME/ou=people,dc=domain,dc=com??sub?(!(uid=admin))
And still get two entries (two administrators). So I suspect that my referral URI isn't working. Am using a wrong referral? Or maybe OpenLDAP always returns all entries ignoring attributes and filters in a URI referral (ldap://HOSTNAME/ou=people,dc=domain,dc=com?cn,sn,givenName,telephoneNumber,mail)?
I hope some one can help me because i'm stuck with this since two days ago. I just want to limit the entries returned by my referral.
Thanks
Hi:
I'm trying to migrate an old LDAP server (that holds an ldap tree for Open-Xchange) to a new installation of OpenLDAP 2.3.43.
A lot of users had configured their Outlook in a way that they make a base search for ou=Users,ou=OxObjects,dc=domain,dc=com in their LDAP address book. But my new LDAP tree won't have ou=OxObjects,dc=domain,dc=com entry, i'm creating a new ldap structure to be used with GOSA.
So I decide to create a referral like this:
dn: ou=Users,ou=OxObjects,dc=domain,dc=com ou: Users objectclass: referral objectclass: extensibleObject ref: ldap://HOSTNAME/ou=people,dc=domain,dc=com
This works fine, now Outlook users can find their contacts using the same base search (ou=Users,ou=OxObjects,dc=domain,dc=com) but now GOSA got in problems because it finds two administrator users (cn=System administrator,ou=people,dc=domain,dc=com) because of the referral. I just would like to GOSA doesn't follow referrals or just searches for users under ou=people,dc=domain,dc=com instead of the root dc=domain,dc=com, but it seem that GOSA isn't good enough to customize this yet.
So I think I could modify my referral to return not all attributes, just some of them (the attributes commonly used by an address book search) like this:
dn: ou=Users,ou=OxObjects,dc=domain,dc=com ou: Users objectclass: referral objectclass: extensibleObject ref: ldap://HOSTNAME/ou=people,dc=domain,dc=com?cn,sn,givenName,telephoneNumber,mail
After updating my referral and I make an ldapsearch:
# ldapsearch -xLLL "(uid=admin)"
I still get two entries (two administrators) and both of them returns all its attributes. Then I tried to modify my referral like this:
dn: ou=Users,ou=OxObjects,dc=domain,dc=com ou: Users objectclass: referral objectclass: extensibleObject ref: ldap://HOSTNAME/ou=people,dc=domain,dc=com??sub?(!(uid=admin))
And still get two entries (two administrators). So I suspect that my referral URI isn't working. Am using a wrong referral? Or maybe OpenLDAP always returns all entries ignoring attributes and filters in a URI referral (ldap://HOSTNAME/ou=people,dc=domain,dc=com?cn,sn,givenName,telephoneNumber,mail)?
I hope some one can help me because i'm stuck with this since two days ago. I just want to limit the entries returned by my referral.
Referrals don't work like that. Read RFC4511: the <attrs> field is not mentioned. It mentions, indeed, the <filter> field, but OpenLDAP does not handle this. The behavior you possibly expect is not strictly specified, AFAIK.
I think you have a couple of options:
1) use ACLs to hide that entry to some specific clients
2) use a dummy proxy instead of a referral; the dummy proxy could massage the request/response DNs, and the original server could use ACLs to hide that entry from the results returned to the proxy.
p.
Referrals don't work like that. Read RFC4511: the <attrs> field is not mentioned. It mentions, indeed, the <filter> field, but OpenLDAP does not handle this. The behavior you possibly expect is not strictly specified, AFAIK.
I think you have a couple of options:
use ACLs to hide that entry to some specific clients
use a dummy proxy instead of a referral; the dummy proxy could massage
the request/response DNs, and the original server could use ACLs to hide that entry from the results returned to the proxy.
I tought OpenLDAP could support that kind of referrals. Now I think the best option is the best for my scenario.
Thanks a lot
p.
Referrals don't work like that. Read RFC4511: the <attrs> field is not mentioned. It mentions, indeed, the <filter> field, but OpenLDAP does not handle this. The behavior you possibly expect is not strictly specified, AFAIK.
I think you have a couple of options:
use ACLs to hide that entry to some specific clients
use a dummy proxy instead of a referral; the dummy proxy could
massage the request/response DNs, and the original server could use ACLs to hide that entry from the results returned to the proxy.
I tought OpenLDAP could support that kind of referrals. Now I think the best option is the best for my scenario.
The <attrs> issue makes little sense. The <filter> issue may be worth, although clear semantics need to be defined. I note that rfc 3296 appears to explicitly prohibit a filter in the LDAP URL, while rfc 4511 instructs the client about using the filter in the LDAP URL if present. This is not strictly a contradiction, because the server may modify the URL stored in the Named Subordinate Reference object before returning it to the client, e.g. by adding a filter.
For example, in order to obtain what I think you mean, a <filter> field in the Named Subordinate Reference object's URL, e.g. "(!(uid=admin))", would require the server, in case of a search with scope "subtree", base "ou=Paople,dc=example,dc=com" and filter "(attr=val)", to return a referral
ldap://host/ou=People,dc=example,dc=com??sub?(&(!(uid=admin))(attr=val))
The filter should be completely removed when performing other types of operations, in compliance with rfc3296.
If you think this makes sense and you would like to see it implemented, I suggest to file an ITS as a feature request, pending technical discussion http://www.openldap.org/its/.
p.
On Jun 3, 2010, at 2:02 PM, masarati@aero.polimi.it wrote:
Referrals don't work like that. Read RFC4511: the <attrs> field is not mentioned. It mentions, indeed, the <filter> field, but OpenLDAP does not handle this. The behavior you possibly expect is not strictly specified, AFAIK.
I think you have a couple of options:
use ACLs to hide that entry to some specific clients
use a dummy proxy instead of a referral; the dummy proxy could
massage the request/response DNs, and the original server could use ACLs to hide that entry from the results returned to the proxy.
I tought OpenLDAP could support that kind of referrals. Now I think the best option is the best for my scenario.
The <attrs> issue makes little sense. The <filter> issue may be worth, although clear semantics need to be defined.
For a named subordinate referral object, a filter makes no sense. Either the DIT has been delegated from one context to another subordinate context or it hasn't been.
I note that rfc 3296 appears to explicitly prohibit a filter in the LDAP URL,
RFC 3296 language (ref SHOULD NOT have a filter, server SHOULD trim filter if present) is intended not to preclude a subsequent specification from define additional kinds of referral objects (which likely would be distinguished named subordinate referral objects by use a different object class or something).
In absence of a subsequent specification, the semantics of ref value with filters should be regarded as undefined.
I also note that RFC 3296 referral objects discussion centers on what referrals/search continuations a server should return to a client when named objects are in scope of the operation. The document doesn't discuss how a server might use referral objects in chaining between servers. One could surmise that a client which well supports chasing would basically have the same interaction with the DIT whether the server(s) chained or not and hence could fairly well derive the semantics from RFC 3296. (Of course, the set of clients which well supports chasing is near empty, one likely needs to consider a theoretical client not an actual client here. :-)
Regards, Kurt
Kurt Zeilenga wrote:
One could surmise that a client which well supports chasing would basically have the same interaction with the DIT whether the server(s) chained or not and hence could fairly well derive the semantics from RFC 3296. (Of course, the set of clients which well supports chasing is near empty, one likely needs to consider a theoretical client not an actual client here. :-)
What should a client do for well supporting referral chasing?
Ciao, Michael.
On Jun 6, 2010, at 2:58 PM, Michael Ströder wrote:
Kurt Zeilenga wrote:
One could surmise that a client which well supports chasing would basically have the same interaction with the DIT whether the server(s) chained or not and hence could fairly well derive the semantics from RFC 3296. (Of course, the set of clients which well supports chasing is near empty, one likely needs to consider a theoretical client not an actual client here. :-)
What should a client do for well supporting referral chasing?
To answer this would actually require many pages... and likely some debate.
In short, I think it most client developers should not attempt to chase referrals/search continuations as doing it well takes lots of energy and thought.
I'm a supporter of extending LDAP to actually support chaining, and then taking time to specify chaining semantics. What we have today is LDAP proxying which isn't quite the same thing (no separation of "client request" vs "chaining server provided information"). But I digress.
-- Kurt
On Jun 3, 2010, at 11:17 AM, masarati@aero.polimi.it wrote:
Or maybe OpenLDAP always returns all entries ignoring attributes and filters in a URI referral (ldap://HOSTNAME/ou=people,dc=domain,dc=com?cn,sn,givenName,telephoneNumber,mail)?
That's what I would expect given RFC 3296 says servers are to strip out such information when returning referrals to clients. If the server chases it instead, the server should do it's best to provide what the client would have gotten if it had chased it itself. The client would not have gotten the extra stuff, so the server should not be using it in chaining.
-- Kurt
Kurt Zeilenga wrote:
On Jun 3, 2010, at 11:17 AM, masarati@aero.polimi.it wrote:
Or maybe OpenLDAP always returns all entries ignoring attributes and filters in a URI referral (ldap://HOSTNAME/ou=people,dc=domain,dc=com?cn,sn,givenName,telephoneNumber,mail)?
That's what I would expect given RFC 3296 says servers are to strip out such information when returning referrals to clients. If the server chases it instead, the server should do it's best to provide what the client would have gotten if it had chased it itself. The client would not have gotten the extra stuff, so the server should not be using it in chaining.
With web2ldap I'm trying to enforce what the user interactively input as parameters for the search. So when (interactively) chasing the referral I only use the hostport and DN portion of the referral URL.
Try yourself with variations of this combined web2ldap/LDAP-URL:
http://demo.web2ldap.de:1760/web2ldap?ldap://ldap.uninett.no/dc=hio,dc=no
Ciao, Michael.
openldap-technical@openldap.org
-
Jason Voorhees -
Kurt Zeilenga -
masarati＠aero.polimi.it -
Michael Ströder