The easiest way to find out is just to try it :-)
ldapsearch -LLL -o ldif-wrap=no -h localhost -p 38901 -x -D
"cn=directory manager" -w ... -b "dc=example,dc=com" uid=kwinters
objectclass description uid
dn: uid=kwinters,ou=People,dc=example,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: kwinters
ldapsearch -LLL -o ldif-wrap=no -h localhost -p 38901 -x -D
"cn=directory manager" -w ... -b "dc=example,dc=com" uid=trigden
objectclass description uid
dn: uid=trigden,ou=People,dc=example,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
description: used for deref
uid: trigden
dn: cn=PD Managers,ou=Groups,dc=example,dc=com
ldapsearch -LLL -o ldif-wrap=no -h localhost -p 38901 -x -D
"cn=directory manager" -w ... -b "dc=example,dc=com" -E
'deref=uniquemember:objectClass,description,uid' 'cn=PD Managers'
# uniquemember:
<objectClass=top>;<objectClass=person>;<objectClass=organizationalPerson>;<objectClass=inetOrgPerson>;<uid=kwinters>;uid=kwinters,ou=People,dc=example,dc=com
# uniquemember:
<objectClass=top>;<objectClass=person>;<objectClass=organizationalPerson>;<objectClass=inetOrgPerson>;<description=used
for deref>;<uid=trigden>;uid=trigden,ou=People,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: PD Managers
ou: groups
uniqueMember: uid=kwinters,ou=People,dc=example,dc=com
uniqueMember: uid=trigden,ou=People,dc=example,dc=com
description: People who can manage engineer entries
So the answer is, if an attribute, like description in the example does
not exist in the derefed entry it is just not there, like in a normal
search where it was requested. In addition 389-ds also checks if the
user requesting the deref attrs also has access rights to the attr in
the derefed entry
Ludwig
On 11/08/2018 12:25 AM, William Brown wrote:
On Thu, 2018-11-08 at 00:12 +0100, Michael Ströder wrote:
> On 11/7/18 11:22 PM, William Brown wrote:
>> On Sat, 2018-11-03 at 21:46 +0100, Michael Ströder wrote:
>>> I vaguely remember that 389-DS also implements deref search
>>> control
>>> [1].
>>>
>>> My question as a client developer:
>>> How does 389-DS deal with reference attributes being absent?
>> I am assuming that you mean a request for dereference where no
>> attributeList is requested?
> No, I meant the attributes holding the reference are not present in
> the
> entry.
To be clear that I understand the problem, can you send an example case
of what is occuring? Thanks,
>> Off the top of my head, I do not know, but
>> this is something we should check to see if our behaviour is
>> correct
>> according to the provided RFC. Reading the RFC it doesn't seem to
>> specify how an empty attributeList should be handled, but in my
>> view,
>> it should "do nothing" since no attributes were requested.
> The I-D does not say much about error conditions.
>
> But I also think if anything's missing the server should simply
> return
> what's present and can be returned but not error out.
>
>>> [1]
https://tools.ietf.org/html/draft-masarati-ldap-deref-00
> Ciao, Michael.
>
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
--
Red Hat GmbH,
http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric
Shander