Bug 507892

Yes, that is exactly the problem. The function get_dn_from_principal() looks under cn=accounts for users.

The tricky part will be moving the user, particularly the uidNumber. It is currently set to 999 which is also our DNA magic number. The uid of the admin user doesn't really matter as long as the user doesn't own any files.

I wonder if the best route would be to get the current admin entry bound as Directory Manager so we get the password attributes, then delete the old entry and add a new one under cn=accounts using the old entry as a template.

Simo, what do you think?

If it can help, now that I moved the primary master, I have a box where I can test a possible solution.
It's going to be available from now to tomorrow in the late morning (CEST), than it will be wiped out and reinstalled.

Ok, need some confirmation from the 389 guys to be sure that the ref. integrity plugin will take care of cleaning things up, but I think the procedure will broadly look like this. In other words, DON'T DO THIS YET :-)

You'll want to start this process with a TGT of a user in the admins group.

1. Fetch the existing entry

ldapsearch -x -D "cn=directory manager" -W -b "dc=example,dc=com" uid=admin > admin.ldif

2. Determine current group membership

ldapsearch -x -b "dc=example,dc=com" member="uid=admin,cn=etc,cn=sysaccounts,dc=example,dc=com" dn

3. Delete the current entry

ldapdelete -x -D "cn=directory manager" -W uid=admin,cn=etc,cn=sysaccounts,dc=example,dc=com

4. Modify admin.ldif to change the DN to:

uid=admin,cn=users,cn=accounts,dc=example,dc=com

5. Add the new entry

ldapadd -x -D "cn=directory manager" -W -a < admin.ldif

6. Fix group membership

For each group the admin user was in, do something like this:

ipa-group-mod --add admin admins

Rich, Nathan, does this look reasonable to you? Are there any gotchas, things we need to remove from admin.ldif before trying to add it?

(In reply to comment #3)
> Ok, need some confirmation from the 389 guys to be sure that the ref. integrity
> plugin will take care of cleaning things up, but I think the procedure will
> broadly look like this. In other words, DON'T DO THIS YET :-)
> 
> You'll want to start this process with a TGT of a user in the admins group.
> 
> 1. Fetch the existing entry
> 
> ldapsearch -x -D "cn=directory manager" -W -b "dc=example,dc=com" uid=admin >
> admin.ldif
> 
> 2. Determine current group membership
> 
> ldapsearch -x -b "dc=example,dc=com"
> member="uid=admin,cn=etc,cn=sysaccounts,dc=example,dc=com" dn
> 
> 3. Delete the current entry
> 
> ldapdelete -x -D "cn=directory manager" -W
> uid=admin,cn=etc,cn=sysaccounts,dc=example,dc=com
> 
> 4. Modify admin.ldif to change the DN to:
> 
> uid=admin,cn=users,cn=accounts,dc=example,dc=com

Here you will also have to remove memberof from the ldif, as that attribute is managed, and can't be set.

> 5. Add the new entry
> 
> ldapadd -x -D "cn=directory manager" -W -a < admin.ldif
> 
> 6. Fix group membership
> 
> For each group the admin user was in, do something like this:
> 
> ipa-group-mod --add admin admins

The other option is to also use ldapmodify on each group with Dir MGr credentials.

> Rich, Nathan, does this look reasonable to you? Are there any gotchas, things
> we need to remove from admin.ldif before trying to add it?  

memberof for sure.

Simo.

(In reply to comment #3)
> Rich, Nathan, does this look reasonable to you? Are there any gotchas, things
> we need to remove from admin.ldif before trying to add it?  

I can't think of anything you need to remove aside from the memberOf attribute as Simo mentioned.

I'm not sure that I understand the issue with the uidNumber?  Is the admin user supposed to have the uidNumber that is used as the magic value?  If so, you'll need to do something like temporarily change the magic value to allow you to set uidNumber properly, then change it back.

Sorry for the late feedback.

I just tried the procedure.
I'm not able to set uidNumber back to 999, and if I try to use any of the ipa commands (ipa-modgroup, for example), I get the following error:

A database error occurred: Insufficient access: Insufficient 'write' privilege to the 'member' attribute of entry 'cn=groups,cn=accounts,dc=example,dc=org'.

Same error if I try ldapadd or ldapmodify with GSSAPI authentication, while if I use the standard authentication ( -x -W ), I can operate correctly.

Any ideas?

Thanks to Simo, it's now working correctly.
An ACI had to be changed, and admin had to be manually added to the admins group.

Here is the revised procedure. replace-aci.ldif and add-admin-to-admins.ldif are attached. Thanks again to all.

1. Fetch the existing entry

ldapsearch -x -D "cn=directory manager" -W -b "dc=example,dc=com" uid=admin > admin.ldif

2. Determine current group membership

ldapsearch -x -b "dc=example,dc=com" member="uid=admin,cn=etc,cn=sysaccounts,dc=example,dc=com" dn

3. Delete the current entry

ldapdelete -x -D "cn=directory manager" -W uid=admin,cn=etc,cn=sysaccounts,dc=example,dc=com

4. Modify admin.ldif to change the DN to:

uid=admin,cn=users,cn=accounts,dc=example,dc=com

Also remove the lines: memberOf, userPassword, krbPrincipalKey

5. Add the new entry

ldapadd -x -D "cn=directory manager" -W -a < admin.ldif

6. Replace the global ACI for the admin user

ldapmodify -x -W -D "cn=Directory Manager" -f ./replace-aci.ldif

7. Fix the admins group membership

Manually add the admin user to the admins group:

ldapmodify -x -W -D "cn=Directory Manager" -f ./add-admin-to-admins.ldif


8. Fix group membership

For each group the admin user was in, do something like this:

ipa-modgroup --add admin groups

Created attachment 379618 [details]
ldif used to correct the admin ACI

Created attachment 379619 [details]
ldif used to add the admin user to the admins group

Great, glad this worked for you.

I'm going to close this bug since you are up and running now.

I'm not sure if this is something we want to document somewhere other than this BZ or not, I'll leave that up to David.

I've add a summary and link to this BZ on the freeIPA Documentation Portal