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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
--
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
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
