#7170 Potential for incorrect/out of date duplicate entries in compat tree
Opened 6 years ago by beanfield. Modified 2 years ago

Right now there are several cases where it seems some level of caching is happening with the Schema Compatibility plugin in the compat tree, causing duplicate or stale entries to show up. It is possible for deleted users to still be present, or group membership to be returned incorrectly. I am able to reproduce this on the demo instance.

  1. Create a new user with a User login of your choice
  2. Query the compat tree for that user (e.g., ldapsearch -H ldap://ipa.demo1.freeipa.org -x -D "uid=admin,cn=users,cn=accounts,dc=demo1,dc=freeipa,dc=org" -w Secret123 -b "cn=compat,dc=demo1,dc=freeipa,dc=org" -s sub "(&(objectClass=*)(uid=test3))"
  3. Delete the user
  4. Create a new user with the same User login as the deleted user, use different first/last name
  5. Query the compat tree for that user again

    # test3, users, compat, demo1.freeipa.org
    dn: uid=test3,cn=users,cn=compat,dc=demo1,dc=freeipa,dc=org
    objectClass: posixAccount
    objectClass: ipaOverrideTarget
    objectClass: top
    gecos: fail fail
    cn: fail fail
    uidNumber: 1198600017
    gidNumber: 1198600017
    loginShell: /bin/sh
    homeDirectory: /home/test3
    ipaAnchorUUID:: OklQQTpkZW1vMS5mcmVlaXBhLm9yZzpjOTJiMGQwMC1hMjIyLTExZTctYTczNC
    0wNjI5YzhkYTg2OTE=
    uid: test3

    # test3, users, compat, demo1.freeipa.org
    dn: uid=test3,cn=users,cn=compat,dc=demo1,dc=freeipa,dc=org
    objectClass: posixAccount
    objectClass: top
    gecos: test3 test3
    cn: test3 test3
    uidNumber: 1198600016
    gidNumber: 1198600016
    loginShell: /bin/sh
    homeDirectory: /home/test3
    uid: test3

I don't know the exact steps necessary to cause this to occur in the groups compat tree to cause memberUid list to be out dated with a duplicate entry, but I have experienced it.


I failed to reproduce the problem :(

If you are able to reproduce it systematically, would you be able to provide some debug info that would help to understand the problem ?

On Directory server enable the plugin logging and internal operation logging:

ldapmodify -x -D "cn=directory manager" -W
dn: cn=config
changetype: modify
replace: nsslapd-errorlog-level
nsslapd-errorlog-level:  65536
-
replace: nsslapd-accesslog-level
nsslapd-accesslog-level: 260

Then run the test

Then restore the standard config:

ldapmodify -x -D "cn=directory manager" -W
dn: cn=config
changetype: modify
replace: nsslapd-errorlog-level
nsslapd-errorlog-level:  0
-
replace: nsslapd-accesslog-level
nsslapd-accesslog-level: 256

The debug information are in DS access and errors log (/var/log/dirsrv/slapd-<inst>)

Metadata Update from @rcritten:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1532795

6 years ago

Ok, I always have this bug.
I have 3 IPA server with AD trust.
I use ldapsearch:

ldapsearch -x -h dc4.fs.lan -b cn=compat,dc=fs,dc=lan "uid=savelev"
# extended LDIF
#
# LDAPv3
# base <cn=compat,dc=fs,dc=lan> with scope subtree
# filter: uid=savelev
# requesting: ALL
#

# savelev, users, compat, fs.lan
dn: uid=savelev,cn=users,cn=compat,dc=fs,dc=lan
cn:: 0J3QuNC60L7Qu9Cw0Lkg
objectClass: posixAccount
objectClass: ipaOverrideTarget
objectClass: top
gidNumber: 10000
gecos:: 0J3Qu
uidNumber: 15000
ipaAnchorUUID:: OklQQT
loginShell: /bin/bash
uid: savelev

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1`

Than I open this user in webui on this server and change something.
...
An now I have 2 same users in compat tree!

ldapsearch -x -h dc4.fs.lan -b cn=compat,dc=fs,dc=lan "uid=savelev"
# extended LDIF
#
# LDAPv3
# base <cn=compat,dc=fs,dc=lan> with scope subtree
# filter: uid=savelev
# requesting: ALL
#

# savelev, users, compat, fs.lan
dn: uid=savelev,cn=users,cn=compat,dc=fs,dc=lan
cn:: 0KHQsNCy0LXQu9GM0LXQsiDQndC40LrQvtC7
objectClass: posixAccount
objectClass: top
gidNumber: 10000
gecos:: 0KHQsNCy0LXQu9GM0LXQsiDQndC40LrQvtC
uidNumber: 15000
loginShell: /bin/bash

uid: savelev

# savelev, users, compat, fs.lan
dn: uid=savelev,cn=users,cn=compat,dc=fs,dc=lan
cn:: 0J3QuNC60L7Qu9Cw0Lkg0KHQsNCy0LXQu9GM
objectClass: posixAccount
objectClass: ipaOverrideTarget
objectClass: top
gidNumber: 10000
gecos:: 0J3QuNC60L7Qu9Cw0Lkg0KHQsNCy0LXQ
uidNumber: 15000
ipaAnchorUUID:: OklQQTpmcy5sYW46ZmFkOGNlNGUtYzdmZi0xMWU2LTljMzYtOWFiMmFlNGU2Yj
 c1
loginShell: /bin/bash
homeDirectory: /home/koluzhenkov
uid: savelev

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

After restart dirsrv there is only one.
Files wits logs attached.

access
errors
accesserrors

Metadata Update from @abbra:
- Issue assigned to abbra
- Issue set to the milestone: FreeIPA 4.6.5

5 years ago

Hi there,

Update: added details and logs

Current context :
administrator@lab.local memberof test_ad_ext (externalGroup)
test_ad_ext memberOf test_ad (posixGroup)

Test :

[root@freeipa1 slapd-IPA-OFFICE-DATA-ESSENTIAL-COM] systemctl start dirsrv@IPA-OFFICE-DATA-ESSENTIAL-COM.service

# Wait until the following command return the group (ie the plugin has finished the initialization)

[root@freeipa1 slapd-IPA-OFFICE-DATA-ESSENTIAL-COM] ldapsearch -b 'cn=groups,cn=compat,dc=ipa,dc=office,dc=data-essential,dc=com' '(&(objectClass=posixGroup)(cn=test_ad))' -x 
# extended LDIF
#
# LDAPv3
# base <cn=groups,cn=compat,dc=ipa,dc=office,dc=data-essential,dc=com> with scope subtree
# filter: (&(objectClass=posixGroup)(cn=test_ad))
# requesting: ALL
#

# test_ad, groups, compat, ipa.office.data-essential.com
dn: cn=test_ad,cn=groups,cn=compat,dc=ipa,dc=office,dc=data-essential,dc=com
objectClass: posixGroup
objectClass: ipaOverrideTarget
objectClass: groupOfUniqueNames
objectClass: top
gidNumber: 5151
ipaAnchorUUID:: OklQQTppcGEub2ZmaWNlLmRhdGEtZXNzZW50aWFsLmNvbTowYTIxNmM3YS02NW
 Q5LTExZTktOTU5ZC0wMDUwNTZhOTZiNjU=
cn: test_ad

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

[root@freeipa1 slapd-IPA-OFFICE-DATA-ESSENTIAL-COM]# ldapsearch -x -b "dc=ipa,dc=office,dc=data-essential,dc=com" "(&(objectClass=posixGroup)(memberUid=administrator@lab.local))"
# extended LDIF
#
# LDAPv3
# base <dc=ipa,dc=office,dc=data-essential,dc=com> with scope subtree
# filter: (&(objectClass=posixGroup)(memberUid=administrator@lab.local))
# requesting: ALL
#
[...other groups...]
# test_ad, groups, compat, ipa.office.data-essential.com
dn: cn=test_ad,cn=groups,cn=compat,dc=ipa,dc=office,dc=data-essential,dc=com
objectClass: posixGroup
objectClass: ipaOverrideTarget
objectClass: groupOfUniqueNames
objectClass: top
gidNumber: 5151
memberUid: administrator@lab.local
ipaAnchorUUID:: OlNJRDpTLTEtNS0yMS0xMjAwNTYzMzk4LTU4NjI5MDIwNC0yNjcxNDUwODk3LT
 ExNTE=
cn: test_ad

# search result
search: 2
result: 0 Success

# numResponses: 8
# numEntries: 7

[root@freeipa1 slapd-IPA-OFFICE-DATA-ESSENTIAL-COM]# ldapsearch -b 'cn=groups,cn=compat,dc=ipa,dc=office,dc=data-essential,dc=com' '(&(objectClass=posixGroup)(cn=test_ad))' -x 
# extended LDIF
#
# LDAPv3
# base <cn=groups,cn=compat,dc=ipa,dc=office,dc=data-essential,dc=com> with scope subtree
# filter: (&(objectClass=posixGroup)(cn=test_ad))
# requesting: ALL
#

# test_ad, groups, compat, ipa.office.data-essential.com
dn: cn=test_ad,cn=groups,cn=compat,dc=ipa,dc=office,dc=data-essential,dc=com
objectClass: posixGroup
objectClass: ipaOverrideTarget
objectClass: groupOfUniqueNames
objectClass: top
gidNumber: 5151
memberUid: administrator@lab.local
ipaAnchorUUID:: OlNJRDpTLTEtNS0yMS0xMjAwNTYzMzk4LTU4NjI5MDIwNC0yNjcxNDUwODk3LT
 ExNTE=
cn: test_ad

# test_ad, groups, compat, ipa.office.data-essential.com
dn: cn=test_ad,cn=groups,cn=compat,dc=ipa,dc=office,dc=data-essential,dc=com
objectClass: posixGroup
objectClass: ipaOverrideTarget
objectClass: groupOfUniqueNames
objectClass: top
gidNumber: 5151
ipaAnchorUUID:: OklQQTppcGEub2ZmaWNlLmRhdGEtZXNzZW50aWFsLmNvbTowYTIxNmM3YS02NW
 Q5LTExZTktOTU5ZC0wMDUwNTZhOTZiNjU=
cn: test_ad

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

Any updates on this? I don't have access to see the bugzilla link. We started seeing failed logins from vcenter last week:

"InvalidPrincipalException: Duplicate entries were found"

Which cleared after restarting dirsrv. But today, the problem returned and was again cleared (for now) by restarting dirsrv.

Thanks.

Ah, I see that one of the duplicate entries doesn't have the added sn attribute for vcenter. Perhaps I didn't run the vcenter compat schema update after deploying the replica server.

...

Yes, the Schema Compatibility plugin config was different on the replica server. I added the vcenter config and wait to see if my problem is fixed.

...

No, the vcenter schema mod wasn't the problem. We're still getting a duplicate compat entry when a user is modified through the web interface. (Haven't verified with cli yet.)

Thanks again.

No real updates. A similar BZ, https://bugzilla.redhat.com/show_bug.cgi?id=2060131 , appears to provide a reproducer.

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

2 years ago

Login to comment on this ticket.

Metadata
Attachments 4
Attached 6 years ago View Comment
Attached 6 years ago View Comment
Attached 6 years ago View Comment
Attached 4 years ago View Comment