Bug 661102 - Managed Entries: mep_mod_post_op: Unable to update mapped attributes from origin entry
Summary: Managed Entries: mep_mod_post_op: Unable to update mapped attributes from or...
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Directory Server
Version: 1.2.7
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Sankar Ramalingam
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 639035 389_1.2.8 715112
TreeView+ depends on / blocked
 
Reported: 2010-12-07 19:20 UTC by Jenny Galipeau
Modified: 2015-01-05 14:11 UTC (History)
3 users (show)

(edit)
Clone Of:
: 715112 (view as bug list)
(edit)
Last Closed: 2015-01-05 14:11:20 UTC


Attachments (Terms of Use)
Patch (12.52 KB, patch)
2011-01-07 18:34 UTC, Nathan Kinder
nkinder: review?
rmeggins: review+
Details | Diff

Description Jenny Galipeau 2010-12-07 19:20:56 UTC
Description of problem:
Example and issue was found with 389-ds-base while testing freeIPA.

Executing a modrdn on uid of user that manages a group entry results in dirsrv error - however, both entries are correctly updated.

The orginal uid of the user was "test".  Modifying the uid to test results in the following error:

[06/Dec/2010:13:49:35 -0500] managed-entries-plugin - mep_mod_post_op: Unable to update mapped attributes from origin entry "uid=new,cn=users,cn=accounts,dc=testrelm" in managed entry "cn=test,cn=groups,cn=accounts,dc=testrelm" (Operation not allowed on RDN).

USER AFTER UPDATE:

# new, users, accounts, testrelm
dn: uid=new,cn=users,cn=accounts,dc=testrelm
cn: test test
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: radiusprofile
objectClass: ipaobject
objectClass: mepOriginEntry
loginShell: /bin/sh
gecos: test
homeDirectory: /home/test
krbPwdPolicyReference: cn=global_policy,cn=TESTRELM,cn=kerberos,dc=testrelm
krbPrincipalName: new@TESTRELM
givenName: test
sn: test
uidNumber: 2097643694
gidNumber: 2097643694
ipaUniqueID: 8ecf4790-0169-11e0-832a-000c29a992d9
mepManagedEntry: cn=new,cn=groups,cn=accounts,dc=testrelm
memberOf: cn=ipausers,cn=groups,cn=accounts,dc=testrelm
uid: new

GROUP AFTER UPDATE
# new, groups, accounts, testrelm
dn: cn=new,cn=groups,cn=accounts,dc=testrelm
objectClass: posixgroup
objectClass: ipaobject
objectClass: mepManagedEntry
objectClass: top
gidNumber: 2097643694
description: User private group for new
mepManagedBy: uid=new,cn=users,cn=accounts,dc=testrelm
ipaUniqueID: 8ed20304-0169-11e0-832a-000c29a992d9
cn: new

Version-Release number of selected component (if applicable):
389-ds-base-1.2.7.1-1.fc13.i686

How reproducible:
always

Steps to Reproduce: - with ipa
1. ipa add-user --first=test --last=test test
2. ipa mod-user --setattr uid=new test
3. 
  
Actual results:
error message in dirsrv

Expected results:
no error message

Additional info:

Comment 2 Nathan Kinder 2011-01-07 18:34:10 UTC
Created attachment 472276 [details]
Patch

Comment 3 Nathan Kinder 2011-01-07 21:20:00 UTC
Pushed to master.  Thanks to Rich for his review!

Counting objects: 13, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 2.03 KiB, done.
Total 7 (delta 4), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
   3c021b2..2e35351  master -> master

Comment 4 Jenny Galipeau 2011-06-06 19:03:49 UTC
1) # ipa user-add --first=test --last=test test
-----------------
Added user "test"
-----------------
  User login: test
  First name: test
  Last name: test
  Full name: test test
  Display name: test test
  Initials: tt
  Home directory: /home/test
  GECOS field: test
  Login shell: /bin/sh
  Kerberos principal: test@TESTRELM
  UID: 754600004

2) # ipa user-mod --setattr uid=new test
--------------------
Modified user "test"
--------------------
  User login: new
  First name: test
  Last name: test
  Home directory: /home/test
  Login shell: /bin/sh
  Account disabled: False

USER AFTER UPDATE:

# new, users, accounts, testrelm
dn: uid=new,cn=users,cn=accounts,dc=testrelm
displayName: test test
cn: test test
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: ipaobject
objectClass: mepOriginEntry
loginShell: /bin/sh
sn: test
gecos: test
homeDirectory: /home/test
krbPwdPolicyReference: cn=global_policy,cn=TESTRELM,cn=kerberos,dc=testrelm
krbPrincipalName: new@TESTRELM
givenName: test
initials: tt
uidNumber: 754600004
gidNumber: 754600004
ipaUniqueID: c52a97f6-906e-11e0-8d32-5254002d6d83
mepManagedEntry: cn=new,cn=groups,cn=accounts,dc=testrelm
memberOf: cn=ipausers,cn=groups,cn=accounts,dc=testrelm
uid: new


GROUP AFTER UPDATE:
  Member of groups: ipausers

# new, groups, accounts, testrelm
dn: cn=new,cn=groups,cn=accounts,dc=testrelm
objectClass: posixgroup
objectClass: ipaobject
objectClass: mepManagedEntry
objectClass: top
gidNumber: 754600004
description: User private group for new
mepManagedBy: uid=test,cn=users,cn=accounts,dc=testrelm  <===============
ipaUniqueID: c530980e-906e-11e0-8d32-5254002d6d83
cn: new


errors-log:

[06/Jun/2011:14:57:21 -0400] managed-entries-plugin - mep_modrdn_post_op: Unable to update pointer to origin entry "uid=new,cn=users,cn=accounts,dc=testrelm" in managed entry "cn=test,cn=groups,cn=accounts,dc=testrelm" (No such object).


Looks like the mepManagedBy attribute for the group is not updated to the new user uid ...


version: 
389-ds-base-1.2.8.2-1.el6.x86_64
ipa-server-2.0.0-23.el6.x86_64

rhel version: 
Red Hat Enterprise Linux Server release 6.1 (Santiago)

Comment 5 Nathan Kinder 2011-06-20 22:07:58 UTC
Do the access logs show what the operations are that IPA performs when you change the uid attribute?  I attempted to reproduce this by performing a simple MODRDN operation to a posixAccount entry, but everything is updated correctly by the managed entries plug-in.

[root@localhost ~]# ldapmodify -x -D "cn=directory manager" -w password
dn: uid=foo1,ou=People,dc=example,dc=com
changetype: modrdn
newrdn: uid=foo2
deleteoldrdn: 1

The resulting entries look like this:

# foo2, People, example.com
dn: uid=foo2,ou=People,dc=example,dc=com
objectClass: posixAccount
objectClass: top
objectClass: mepOriginEntry
uidNumber: 500
gidNumber: 500
homeDirectory: /home/foo1
cn: Foo 1
mepManagedEntry: cn=foo2,ou=groups,dc=example,dc=com
uid: foo2

# foo2, Groups, example.com
dn: cn=foo2,ou=Groups,dc=example,dc=com
objectClass: posixGroup
objectClass: mepManagedEntry
objectClass: top
gidNumber: 500
description: User private group for foo2
mepManagedBy: uid=foo2,ou=people,dc=example,dc=com
cn: foo2

Comment 6 Jenny Galipeau 2011-06-21 18:28:29 UTC
verified:

# rpm -qi 389-ds-base
Name        : 389-ds-base                  Relocations: (not relocatable)
Version     : 1.2.8.4                           Vendor: Red Hat, Inc.
Release     : 3.el6                         Build Date: Tue 21 Jun 2011 12:59:22 PM EDT
Install Date: Tue 21 Jun 2011 02:21:42 PM EDT      Build Host: x86-007.build.bos.redhat.com
Group       : System Environment/Daemons    Source RPM: 389-ds-base-1.2.8.4-3.el6.src.rpm
Size        : 4243230                          License: GPLv2 with exceptions
Signature   : (none)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://port389.org/
Summary     : 389 Directory Server (base)
Description :
389 Directory Server is an LDAPv3 compliant server.  The base package includes
the LDAP server and command line utilities for server administration.



[root@apollo dspkgs]# ipa user-add --first=test --last=test test
-----------------
Added user "test"
-----------------
  User login: test
  First name: test
  Last name: test
  Full name: test test
  Display name: test test
  Initials: tt
  Home directory: /home/test
  GECOS field: test test
  Login shell: /bin/sh
  Kerberos principal: test@TESTRELM
  UID: 1572000011
  GID: 1572000011
[root@apollo dspkgs]# ipa user-mod --setattr uid=new test
--------------------
Modified user "test"
--------------------
  User login: new
  First name: test
  Last name: test
  Home directory: /home/test
  Login shell: /bin/sh
  UID: 1572000011
  GID: 1572000011
  Account disabled: False
  Member of groups: ipausers
[root@apollo dspkgs]# history | grep ldapsearch
   96  history | grep ldapsearch
[root@apollo dspkgs]# ldapsearch -D "cn=Directory Manager" -w Secret123 -b "uid=new,cn=users,cn=accounts,dc=testrelm"
# extended LDIF
#
# LDAPv3
# base <uid=new,cn=users,cn=accounts,dc=testrelm> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# new, users, accounts, testrelm
dn: uid=new,cn=users,cn=accounts,dc=testrelm
displayName: test test
cn: test test
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: ipaobject
objectClass: mepOriginEntry
loginShell: /bin/sh
sn: test
gecos: test test
homeDirectory: /home/test
krbPwdPolicyReference: cn=global_policy,cn=TESTRELM,cn=kerberos,dc=testrelm
krbPrincipalName: new@TESTRELM
givenName: test
initials: tt
uidNumber: 1572000011
gidNumber: 1572000011
ipaUniqueID: ca32e872-9c33-11e0-a268-0015172f2b30
mepManagedEntry: cn=new,cn=groups,cn=accounts,dc=testrelm
memberOf: cn=ipausers,cn=groups,cn=accounts,dc=testrelm
uid: new

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
[root@apollo dspkgs]# ldapsearch -D "cn=Directory Manager" -w Secret123 -b "cn=new,cn=groups,cn=accounts,dc=testrelm"
# extended LDIF
#
# LDAPv3
# base <cn=new,cn=groups,cn=accounts,dc=testrelm> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# new, groups, accounts, testrelm
dn: cn=new,cn=groups,cn=accounts,dc=testrelm
objectClass: posixgroup
objectClass: ipaobject
objectClass: mepManagedEntry
objectClass: top
gidNumber: 1572000011
description: User private group for new
mepManagedBy: uid=test,cn=users,cn=accounts,dc=testrelm
ipaUniqueID: ca37c55e-9c33-11e0-a268-0015172f2b30
cn: new

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Comment 7 Jenny Galipeau 2011-06-21 18:30:17 UTC
sorry ... Group still has 
mepManagedBy: uid=test,cn=users,cn=accounts,dc=testrelm

Comment 8 Nathan Kinder 2011-06-21 21:17:10 UTC
Here is a plug-in level log-snippet for the MODRDN from my standalone DS system (where the above test works):

-----------------------------------------------------------------------------
[21/Jun/2011:14:00:14 -0700] managed-entries-plugin - mep_modrdn_post_op: Updating mepManagedBy pointer to "uid=testnew,ou=people,dc=example,dc=com" in entry "cn=testold,ou=groups,dc=example,dc=com".
[21/Jun/2011:14:00:15 -0700] managed-entries-plugin - mep_modrdn_post_op: Renaming managed entry "cn=testold,ou=groups,dc=example,dc=com" to "cn=testnew,ou=groups,dc=example,dc=com" due to rename of origin entry "uid=testold,ou=people,dc=example,dc=com".
[21/Jun/2011:14:00:15 -0700] managed-entries-plugin - mep_rename_managed_entry: Updating mepManagedEntry pointer to "cn=testnew,ou=groups,dc=example,dc=com" in entry "uid=testnew,ou=People,dc=example,dc=com".
[21/Jun/2011:14:00:15 -0700] managed-entries-plugin - mep_mod_post_op: Updating mapped attributes in entry "cn=testnew,ou=groups,dc=example,dc=com"
[21/Jun/2011:14:00:15 -0700] managed-entries-plugin - mep_modrdn_post_op: Updating mapped attributes in entry "cn=testold,ou=groups,dc=example,dc=com"
-----------------------------------------------------------------------------

Here is a snippet from Jenny's IPA system for the same operation:

-----------------------------------------------------------------------------
[21/Jun/2011:16:33:15 -0400] managed-entries-plugin - mep_mod_post_op: Updating mapped attributes in entry "cn=ngkold,cn=groups,cn=accounts,dc=testrelm"
[21/Jun/2011:16:33:17 -0400] managed-entries-plugin - mep_rename_managed_entry: Updating mepManagedEntry pointer to "cn=ngknew,cn=groups,cn=accounts,dc=testrelm" in entry "uid=ngknew,cn=users,cn=accounts,dc=testrelm"
[21/Jun/2011:16:33:17 -0400] managed-entries-plugin - mep_mod_post_op: Updating mapped attributes in entry "cn=ngknew,cn=groups,cn=accounts,dc=testrelm"
[21/Jun/2011:16:33:18 -0400] managed-entries-plugin - mep_modrdn_post_op: Updating mepManagedBy pointer to "uid=ngknew,cn=users,cn=accounts,dc=testrelm" in entry "cn=ngkold,cn=groups,cn=accounts,dc=testrelm".
[21/Jun/2011:16:33:18 -0400] managed-entries-plugin - mep_modrdn_post_op: Unable to update pointer to origin entry "uid=ngknew,cn=users,cn=accounts,dc=testrelm" in managed entry "cn=ngkold,cn=groups,cn=accounts,dc=testrelm" (No such object).
-----------------------------------------------------------------------------

The big difference between the 2 log snippets (aside from the error) is that we see the managed entries MOD callback called prior to the MODRDN callback on Jenny's system.  The access log only shows a MODRDN operation, so the MOD is an internal operation.

I believe that this internal MOD operation is the ipa-modrdn plug-in that updates the krbprincipalname attribute in the user entry when the uid changes.  This MOD is triggering the managed entries MOD callback, which sees that the managed group entry needs to be renamed since the uid of the user has changed (and is mapped as the RDN value for the group).  The rename of the managed group is carried out by this MOD callback.  The managed entries MODRDN callback is then fired off, but the rename of the group has already been done without it's knowledge.

I think this is solvable by making the ipa-modrdn plug-in execute after the managed entries plug-in.  I will test this approach.

Comment 9 Nathan Kinder 2011-06-21 21:22:20 UTC
Changing the nsslapd-pluginprecedence to 60 for the ipa-modrdn plug-in fixes this issue.  I think that this DS issue should be marked as verified and a new bug should be opened against IPA to make the config change for the plug-in execution order.

Comment 10 Jenny Galipeau 2011-07-11 13:22:24 UTC
Can you please add steps to verify this in a DS setup only?  IPA side is not fixed yet and the bug needs to be verified.  Thanks!

Comment 12 Sankar Ramalingam 2011-07-14 09:00:11 UTC
Here are the few lines from the DS9.0 acceptance tests for managedEntry(test case - mentry20). 
----------------
Successfully completed Modify the memManagedBy attribute
modifying RDN of entry uid=User_MENTRY_20,cn=Users,dc=mentry,dc=com

Successfully completed ModRDN operation to change the RDN of user
Checking whether Associated user private group is created
gidNumber: 22204
Associated Group cn=UserNewRDN_MENTRY_20 is successfully created for uid=UserNewRDN_MENTRY_20
Test result for MENTRY_20, Running ModRDN operation and checking the user private groups mepManagedBy attribute, Actual_Result=0
TestCase [mentry20] result-> [PASS]
---------------

This confirms that the above mentioned problem doesn't exist with DS.

Comment 13 Jenny Galipeau 2011-07-14 12:49:43 UTC
Sankar, can you please mark this bug verified, if you feel it is fixed in DS?

Comment 14 Sankar Ramalingam 2011-07-15 13:12:32 UTC
Sure, marking the bug as Verified since the DS acceptance tests are passing for the issue reported. Please refer to the comment #12.


Note You need to log in before you can comment on or make changes to this bug.