Bug 661102

Created attachment 472276 [details]
Patch

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

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)

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

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

sorry ... Group still has 
mepManagedBy: uid=test,cn=users,cn=accounts,dc=testrelm

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.

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.

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!

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.

Sankar, can you please mark this bug verified, if you feel it is fixed in DS?

Sure, marking the bug as Verified since the DS acceptance tests are passing for the issue reported. Please refer to the comment #12.