#6416 compat foo@f.q.d.n query returns duplicates
Opened 2 years ago by gpaul. Modified a year ago

When the following ldapsearch query is run against the hosted demo duplicate entries are returned. They differ only in their ipaAnchorUUID attribute. This seems to suggest that they come from different sources.

The command used to reproduce is:
ldapsearch -x -h ipa.demo1.freeipa.org -b uid=employee,cn=users,cn=compat,dc=demo1,dc=freeipa,dc=org

The following conversation ensued between myself and Alexander Bokovoy on IRC:

[18:00] <gpaul> hello - when i run ldapsearch against ipa.demo1.freeipa.net and search for the 'employee' user I receive 2 results, they differ only in their 'ipaAnchorUUID' attribute. i would like to reproduce this behaviour on my own freeipa installation, does anyone know what gives rise to this behaviour?

[18:03] <gpaul> the exact ldapsearch command is: ldapsearch -x -h ipa.demo1.freeipa.org -b uid=employee,cn=users,cn=compat,dc=demo1,dc=freeipa,dc=org

[19:06] <ab> gpaul: cn=compat subtree is a virtual one

[19:06] <ab> gpaul: handled by the slapi-nis plugin

[19:07] <ab> gpaul: cn=compat contains the same information as in the main tree but suitable for consumption by the clients that only understand RFC2307

[19:07] <ab> gpaul: not RFC2307bis as the main tree uses

[19:08] <ab> if you want to search for main tree, make sure you limit the base to the cn=accounts,$SUFFIX

[19:11] <ab> gpaul: I see what you mean by duplicate, though. I cannot reproduce it on the local install

[19:13] <ab> gpaul: looking into the ipaAnchorUUID values, I can see that these two come from different sources:

[19:13] <ab> :SID:S-1-5-21-3620654872-687157142-4050297923-1003 and :IPA:demo1.freeipa.org:0a6430d8-ebda-11e3-bc5d-fa163e91f9c8

[19:15] <ab> if you search by that ipaNTSecurityIdentifier or the ipaUniqueID, you'd get the same object

[19:16] <ab> I wonder if this is actually coming from someone searching the compat tree with fully-qualified user name, employee@demo1.freeipa.org

[19:16] <ab> we get the search routed via sssd and it returns us the data, we ask it for a SID of the user and then use it for the anchor

[19:16] <ab> looks like a slight bug

[19:17] <ab> gpaul: could you please file a ticket about it?

[19:20] <ab> gpaul: I reproduced it locally, exactly with the foo@f.q.d.n search


Slapi-nis bug should be created and this changed to a tracker.

Metadata Update from @gpaul:
- Issue assigned to someone
- Issue set to the milestone: FreeIPA 4.5

2 years ago

Metadata Update from @mbasti:
- Issue close_status updated to: None
- Issue set to the milestone: FreeIPA 4.5.1 (was: FreeIPA 4.5)

2 years ago

Metadata Update from @pvoborni:
- Issue set to the milestone: FreeIPA 4.7 (was: FreeIPA 4.5.1)

2 years ago

Metadata Update from @rcritten:
- Issue set to the milestone: FreeIPA 4.7.1 (was: FreeIPA 4.7)

a year ago

FreeIPA 4.7 has been released, moving to FreeIPA 4.7.1 milestone

Login to comment on this ticket.

Metadata