Hide Forgot
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:
- 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
Upstream ticket: https://fedorahosted.org/389/ticket/48637
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.
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.
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