+++ This bug was initially created as a clone of Bug #1112702 +++

+++ This bug was initially created as a clone of Bug #1112698 +++

This bug is created as a clone of upstream ticket:
https://fedorahosted.org/freeipa/ticket/4389

I've been triaging a login error issue mkosek had today and I believe the problem is actually on the server side. I'm not sure if it's in IPA (due to the new ACIs maybe) or 389DS.

With the latest F20 IPA + 389DS combination I've been unable to use the OpenLDAP dereference control:
{{{
ldapsearch -Y GSSAPI -h vm-236.idm.lab.eng.brq.redhat.com -b fqdn=vm-086.idm.lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com -E 'deref=managedBy:objectClass'
}}}

Normally, what the result should be is a tuple of dereferenced DN and the requested attribute (objectClass in this case). I'm only seeing the DN, though.

What I expect to see in the result is:
{{{
# vm-067.idm.lab.bos.redhat.com, computers, accounts, idm.lab.bos.redhat.com
dn: fqdn=vm-067.idm.lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,
 dc=bos,dc=redhat,dc=com
control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAAEeMIQAAAEYBAltYW5hZ2VkQnkEYWZxZ
 G49dm0tMDY3LmlkbS5sYWIuYm9zLnJlZGhhdC5jb20sY249Y29tcHV0ZXJzLGNuPWFjY291bnRzLG
 RjPWlkbSxkYz1sYWIsZGM9Ym9zLGRjPXJlZGhhdCxkYz1jb22ghAAAAKQwhAAAAJ4EC29iamVjdEN
 sYXNzMYQAAACLBAN0b3AECWlwYW9iamVjdAQGbnNob3N0BAdpcGFob3N0BAppcGFzZXJ2aWNlBAdw
 a2l1c2VyBA9rcmJwcmluY2lwYWxhdXgEDGtyYnByaW5jaXBhbAQSa3JidGlja2V0cG9saWN5YXV4B
 AppcGFzc2hob3N0BBRpcGFTc2hHcm91cE9mUHViS2V5cw==
# managedBy: <objectClass=top>;<objectClass=ipaobject>;<objectClass=nshost>;<
 objectClass=ipahost>;<objectClass=ipaservice>;<objectClass=pkiuser>;<objectC
 lass=krbprincipalaux>;<objectClass=krbprincipal>;<objectClass=krbticketpolic
 yaux>;<objectClass=ipasshhost>;<objectClass=ipaSshGroupOfPubKeys>;fqdn=vm-06
 7.idm.lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=re
 dhat,dc=com
}}}

That works with ipa-server-3.3.3-28.el7.x86_64 and 389-ds-base-1.3.1.6-25.el7.x86_64.

What I'm seeing with freeipa-server-3.3.90GITfaf8f1e-0.fc20.x86_64 and 389-ds-base-1.3.2.16-1.fc20.x86_64 is
{{{
# vm-086.idm.lab.bos.redhat.com, computers, accounts, idm.lab.eng.brq.redhat.
 com
dn: fqdn=vm-086.idm.lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,
 dc=eng,dc=brq,dc=redhat,dc=com
control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAAB7MIQAAAB1BAltYW5hZ2VkQnkEaGZxZ
 G49dm0tMDg2LmlkbS5sYWIuYm9zLnJlZGhhdC5jb20sY249Y29tcHV0ZXJzLGNuPWFjY291bnRzLG
 RjPWlkbSxkYz1sYWIsZGM9ZW5nLGRjPWJycSxkYz1yZWRoYXQsZGM9Y29t
# managedBy: fqdn=vm-086.idm.lab.bos.redhat.com,cn=computers,cn=accounts,dc=i
 dm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com
}}}

--- Additional comment from Martin Kosek on 2014-06-24 09:59:57 EDT ---

This bug is a high priority for IPA as without it, users would have an outage  when migrating from RHEL-6 to RHEL-7.1 and still having clients connected to RHEL-6.6 IPA master.

--- Additional comment from Noriko Hosoi on 2014-06-24 12:27:52 EDT ---

Upstream ticket:
https://fedorahosted.org/389/ticket/47825

--- Additional comment from Noriko Hosoi on 2014-06-24 12:32:06 EDT ---

Hi Martin,

The problem is in RHEL-6.x (389-ds-base-1.2.11.X) or RHEL-7.0 (389-ds-base-1.3.1.X)?

It'd affect the target flag of this bug...
Flags: 	
mkosek: 	rhel-6.6.0 		

Thanks,
--noriko

--- Additional comment from Noriko Hosoi on 2014-06-24 14:22:56 EDT ---

(In reply to Noriko Hosoi from comment #3)
> Hi Martin,
> 
> The problem is in RHEL-6.x (389-ds-base-1.2.11.X) or RHEL-7.0
> (389-ds-base-1.3.1.X)?
> 
> It'd affect the target flag of this bug...
> Flags: 	
> mkosek: 	rhel-6.6.0 		
> 
> Thanks,
> --noriko

Never mind.  Nathan gave me a clear explanation.  We need to have this fix on all the supported version (1.2.11 and up)  And Ludwig is already working on this issue.