RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1304682 - "stale" automember rule (associated to a removed group) causes discrepancies in the database
Summary: "stale" automember rule (associated to a removed group) causes discrepancies ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
Petr Bokoc
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-04 10:53 UTC by Michele Casaburo
Modified: 2020-09-13 21:40 UTC (History)
10 users (show)

Fixed In Version: 389-ds-base-1.3.5.9-1.el7
Doc Type: Bug Fix
Doc Text:
Entries rejected by multiple plug-ins no longer show up in searches Previously, when an entry was rejected by multiple back end transaction plug-ins (for example, *Auto Membership* or *Managed Entry*) at the same time, the entry cache was left in an inconsistent state. This allowed a search to return the entry even though it was not added. With this update, the entry cache which stores the Distinguished Name (DN) of the entry is properly cleaned up when an "add" operation fails, and rejected entries are no longer returned by "ldapsearch".
Clone Of:
Environment:
Last Closed: 2016-11-03 20:39:26 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 1787 0 None None None 2020-09-13 21:40:24 UTC
Red Hat Product Errata RHSA-2016:2594 0 normal SHIPPED_LIVE Moderate: 389-ds-base security, bug fix, and enhancement update 2016-11-03 12:11:08 UTC

Description Michele Casaburo 2016-02-04 10:53:22 UTC 
Description of problem:
Having a automember rule associated to a group, then removing the group, the automember rule stays in place and active.

Trying to add a user which matches the rule I get:
# ipa user-add test6_auto --first=test --last=test
ipa: ERROR: Server is unwilling to perform: Managed Entry Plugin rejected add operation (see errors log).

which is expected but if I try to add the same user again I get:
# ipa user-add test6_auto --first=test --last=test
ipa: ERROR: user with name "test6_auto" already exists

# ipa user-find | grep test6_auto
#

but:
# ipa user-show test6_auto --all --raw
  dn: uid=test6_auto,cn=users,cn=accounts,dc=example1,dc=com
  uid: test6_auto
  givenname: test
  sn: test
  cn: test test
  initials: tt
  homedirectory: /home/test6_auto
  gecos: test test
  loginshell: /bin/sh
  mail: test6_auto
  uidnumber: 1826600009
  gidnumber: 1826600009
  nsaccountlock: FALSE
  has_password: FALSE
  has_keytab: FALSE
  displayName: test test
  ipaUniqueID: 77e02950-cb26-11e5-948b-525400930e50
  krbPrincipalName: test6_auto
  mepManagedEntry: cn=test6_auto,cn=groups,cn=accounts,dc=example1,dc=com
  objectClass: ipaobject
  objectClass: person
  objectClass: top
  objectClass: ipasshuser
  objectClass: inetorgperson
  objectClass: organizationalperson
  objectClass: krbticketpolicyaux
  objectClass: krbprincipalaux
  objectClass: inetuser
  objectClass: posixaccount
  objectClass: ipaSshGroupOfPubKeys
  objectClass: mepOriginEntry

trying to delete the user gives:
# ipa user-del test6_auto
ipa: ERROR: test6_auto: user not found

If it can be of any relevance Looking at a user created _before_ the removal of the group we have 
# ipa user-find | grep test2_auto
  User login: test2_auto
  Home directory: /home/test2_auto
  Email address: test2_auto

# ipa user-show test2_auto --all --raw
  dn: uid=test2_auto,cn=users,cn=accounts,dc=example1,dc=com
  uid: test2_auto
  givenname: test
  sn: test
  cn: test test
  initials: tt
  homedirectory: /home/test2_auto
  gecos: test test
  loginshell: /bin/sh
  mail: test2_auto
  uidnumber: 1826600004
  gidnumber: 1826600004
  nsaccountlock: FALSE
  has_password: FALSE
  has_keytab: FALSE
  displayName: test test
  ipaUniqueID: 0bb91e2c-cb1b-11e5-9520-525400930e50
  krbPrincipalName: test2_auto
  memberof: cn=ipausers,cn=groups,cn=accounts,dc=example1,dc=com
  mepManagedEntry: cn=test2_auto,cn=groups,cn=accounts,dc=example1,dc=com
  objectClass: ipaobject
  objectClass: person
  objectClass: top
  objectClass: ipasshuser
  objectClass: inetorgperson
  objectClass: organizationalperson
  objectClass: krbticketpolicyaux
  objectClass: krbprincipalaux
  objectClass: inetuser
  objectClass: posixaccount
  objectClass: ipaSshGroupOfPubKeys
  objectClass: mepOriginEntry

the "only" apparent difference is the memberof attribute which is entirely missing for the "problematic" user

ldapsearches run agains dirsrv looks to me weird as well:

# ldapsearch -x -w redhat123 -D "cn=Directory Manager" -h localhost -b "uid=test6_auto,cn=users,cn=accounts,dc=example1,dc=com"
[...]
# test6_auto, users, accounts, example1.com
dn: uid=test6_auto,cn=users,cn=accounts,dc=example1,dc=com
displayName: test test
uid: test6_auto
[...]

no results for the below:
# ldapsearch -x -w redhat123 -D "cn=Directory Manager" -h localhost -b "cn=users,cn=accounts,dc=example1,dc=com" | grep test6_auto
#

I may be wrong, but I would not expect it

Version-Release number of selected component (if applicable):
# rpm -q  ipa-server
ipa-server-4.2.0-15.el7_2.3.x86_64

# rpm -q 389-ds-base
389-ds-base-1.3.4.0-21.el7_2.x86_64


How reproducible:
Above for verbose description

Steps to Reproduce:
1. # ipa group-add aumember_group
2. # ipa automember-add aumember_group --type group
3. # ipa automember-add-condition aumember_group --type group --inclusive-regex=.*auto
4. # ipa group-remove aumember_group
5  # ipa user-add test_auto --first=test --last=test

Actual results:

user gets partially created, but it is not usable/removable

Expected results:

no personal preference, but it would be nice to expect one of the following:

1) user creation fails completely
or
2) user creation succeeds normally


I would probably go for the second _and_ printing the warning/error from the automember rule

Additional info:
Comment 4 thierry bordaz 2016-02-04 12:01:56 UTC 
	- The following entry can be found be found with a search base or subtree
	  but only with filter 'objectclass=*'
dn: uid=test5_auto,cn=users,cn=accounts,dc=example1,dc=com
nscpentrywsi: dn: uid=test5_auto,cn=users,cn=accounts,dc=example1,dc=com
nscpentrywsi: displayName: test test
nscpentrywsi: uid: test5_auto
nscpentrywsi: objectClass: ipaobject
nscpentrywsi: objectClass: person
nscpentrywsi: objectClass: top
nscpentrywsi: objectClass: ipasshuser
nscpentrywsi: objectClass: inetorgperson
nscpentrywsi: objectClass: organizationalperson
nscpentrywsi: objectClass: krbticketpolicyaux
nscpentrywsi: objectClass: krbprincipalaux
nscpentrywsi: objectClass: inetuser
nscpentrywsi: objectClass: posixaccount
nscpentrywsi: objectClass: ipaSshGroupOfPubKeys
nscpentrywsi: objectClass: mepOriginEntry
nscpentrywsi: loginShell: /bin/sh
nscpentrywsi: initials: tt
nscpentrywsi: gecos: test test
nscpentrywsi: sn: test
nscpentrywsi: homeDirectory: /home/test5_auto
nscpentrywsi: mail: test5_auto
nscpentrywsi: krbPrincipalName: test5_auto
nscpentrywsi: givenName: test
nscpentrywsi: cn: test test
nscpentrywsi: creatorsName: uid=admin,cn=users,cn=accounts,dc=example1,dc=com
nscpentrywsi: modifiersName: cn=Managed Entries,cn=plugins,cn=config
nscpentrywsi: createTimestamp: 20160204085642Z
nscpentrywsi: modifyTimestamp: 20160204085642Z
nscpentrywsi: nsUniqueId: 2b8fc285-cb1d11e5-99a8a95a-3981a25f
nscpentrywsi: ipaUniqueID: 3645a73a-cb1d-11e5-ae9b-525400930e50
nscpentrywsi: parentid: 3
nscpentrywsi: entryid: 426
nscpentrywsi: uidNumber: 1826600008
nscpentrywsi: gidNumber: 1826600008
nscpentrywsi: entryusn: 9483
nscpentrywsi: mepManagedEntry: cn=test5_auto,cn=groups,cn=accounts,dc=example1
 ,dc=com

	- The entry does not exist in the id2entry database and none of its
	  attribute has been indexed

	- The updates that created that entry was
[04/Feb/2016:09:56:42 +0100] conn=6 op=8 ADD dn="uid=test5_auto,cn=users,cn=accounts,dc=example1,dc=com"
[04/Feb/2016:09:56:42 +0100] conn=6 op=8 RESULT err=53 tag=105 nentries=0 etime=0
	  err=53 LDAP_NO_OBJECT_CLASS_MODS

	  Along with automember/mep logs
[04/Feb/2016:09:56:42 +0100] auto-membership-plugin - automember_add_member_value: Unable to add "uid=test5_auto,cn=users,cn=accounts,dc=example1,dc=com" as a "member" value to group "cn=aumember_group,cn=groups,cn=accounts,dc=example1,dc=com" (No such object).
[04/Feb/2016:09:56:42 +0100] auto-membership-plugin - automember_add_member_value: Unable to add "uid=test5_auto,cn=users,cn=accounts,dc=example1,dc=com" as a "member" value to group "cn=aumember_group,cn=groups,cn=accounts,dc=example1,dc=com" (No such object).
[04/Feb/2016:09:56:42 +0100] managed-entries-plugin - mep_add_managed_entry: Unable to add managed entry "cn=test5_auto,cn=groups,cn=accounts,dc=example1,dc=com" for origin entry "uid=test5_auto,cn=users,cn=accounts,dc=example1,dc=com" (Already exists).



	In conclusion:
		It is looking like the entry failed to be added in the DB/index but was not flush from the entry cache.
	The possible reasons of the failure to ADD are
		- configuration issue of automember because "cn=aumember_group,cn=groups,cn=accounts,dc=example1,dc=com"
                  does not exist
                - a schema issue where automember seems to be unable to add "member" attribute
	The fact that the entry is in the entry cache but not store is a bug
Comment 8 Noriko Hosoi 2016-02-15 17:28:43 UTC 
Upstream ticket:
https://fedorahosted.org/389/ticket/48637
Comment 13 mreynolds 2016-06-22 19:13:20 UTC 
automember plugin is behaving as expected, but the issue with the entry being returned by a search after it was NOT added has been fixed upstream.
Comment 15 Simon Pichugin 2016-07-13 20:48:57 UTC 
Build tested:
389-ds-base-1.3.5.10-3.el7.x86_64

============================= test session starts =============================
platform linux2 -- Python 2.7.5, pytest-2.9.2, py-1.4.31, pluggy-0.3.1 -- /usr/bin/python
cachedir: dirsrvtests/tests/tickets/.cache
rootdir: /mnt/tests/rhds/tests/upstream/ds/dirsrvtests/tests/tickets, inifile:
plugins: html-1.9.0, cov-2.3.0
collected 1 items

dirsrvtests/tests/tickets/ticket48637_test.py::test_ticket48637 PASSED

========================== 1 passed in 25.56 seconds ==========================

Marking as verified.
Comment 17 errata-xmlrpc 2016-11-03 20:39:26 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2594.html
Note You need to log in before you can comment on or make changes to this bug.