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.
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))"
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
Issue linked to Bugzilla: Bug 1532795
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.
<img alt="access" src="/freeipa/issue/raw/files/65fb485a0c4e732c15a7be70eb6c6b83ebde7d20f0e8197a605a4a39565920a5-access" /> <img alt="errors" src="/freeipa/issue/raw/files/3f551b7205e6ec991a231b55446ccdca7be4ebc6f2a2cee84458d7d4778728d1-errors" /> <img alt="access" src="/freeipa/issue/raw/files/65fb485a0c4e732c15a7be70eb6c6b83ebde7d20f0e8197a605a4a39565920a5-access" /><img alt="errors" src="/freeipa/issue/raw/files/3f551b7205e6ec991a231b55446ccdca7be4ebc6f2a2cee84458d7d4778728d1-errors" />
Metadata Update from @abbra: - Issue assigned to abbra - Issue set to the milestone: FreeIPA 4.6.5
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
See attached the logfile with full debug enable on the plugins.
error_before => log file before i started the test error_after => log after the test
<img alt="errors_before" src="/freeipa/issue/raw/files/f94543d91b308680d80384e2b07ccf050ee65283974be010e06d034c05adac8d-errors_before" /><img alt="errors_after" src="/freeipa/issue/raw/files/1af9dd704c4cbeb36a8985a6f93e79461edccc6e065633f7d97c1c47816e76c3-errors_after" />
if you need more information, let me know
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)
Login to comment on this ticket.