Bug 507892 - Login as admin fails after an upgrade 1.0 -> 1.2.1
Summary: Login as admin fails after an upgrade 1.0 -> 1.2.1
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: freeIPA
Classification: Retired
Component: WebUI
Version: 1.2
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Rob Crittenden
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: freeipa10
TreeView+ depends on / blocked
 
Reported: 2009-06-24 16:17 UTC by Andrea Dell'Amico
Modified: 2015-01-04 23:39 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-03-28 09:33:00 UTC
Embargoed:


Attachments (Terms of Use)
nss_access.log, nss_error.log, ipa_error.log (7.52 KB, text/plain)
2009-06-24 16:17 UTC, Andrea Dell'Amico
no flags Details
ldif used to correct the admin ACI (606 bytes, application/octet-stream)
2009-12-21 13:58 UTC, Andrea Dell'Amico
no flags Details
ldif used to add the admin user to the admins group (142 bytes, application/octet-stream)
2009-12-21 13:58 UTC, Andrea Dell'Amico
no flags Details

Description Andrea Dell'Amico 2009-06-24 16:17:31 UTC
Created attachment 349270 [details]
nss_access.log, nss_error.log, ipa_error.log

Description of problem:

After an upgrade from version 1.0-x (sorry, don't remember the exact release number) to 1.2.1 on a Fedora 9 system, the login as administrator always fails.

The answer is "Permission Denied", "Kerberos login failed".

The web and ipa logs don't report any error, so after a talk with Simo Sorce our suspect are on the position of the administrator user.
On my installation is under cn=etc, instead of cn=accounts:

# admin, sysaccounts, etc, example.com
dn: uid=admin,cn=sysaccounts,cn=etc,dc=example,dc=com
uid: admin

If I log with un unprivileged user the GUI works, and if I operate as admin using the CLI, all the operations work as expected.

Comment 1 Rob Crittenden 2009-06-29 15:02:14 UTC
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?

Comment 2 Andrea Dell'Amico 2009-07-09 12:46:06 UTC
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.

Comment 3 Rob Crittenden 2009-07-09 13:30:04 UTC
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?

Comment 4 Simo Sorce 2009-07-09 14:28:49 UTC
(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.

Comment 5 Nathan Kinder 2009-07-09 19:41:20 UTC
(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.

Comment 6 Andrea Dell'Amico 2009-12-17 11:42:31 UTC
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?

Comment 7 Andrea Dell'Amico 2009-12-17 17:24:58 UTC
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.

Comment 8 Andrea Dell'Amico 2009-12-21 13:56:59 UTC
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 &lt; 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

Comment 9 Andrea Dell'Amico 2009-12-21 13:58:00 UTC
Created attachment 379618 [details]
ldif used to correct the admin ACI

Comment 10 Andrea Dell'Amico 2009-12-21 13:58:40 UTC
Created attachment 379619 [details]
ldif used to add the admin user to the admins group

Comment 11 Rob Crittenden 2010-01-04 16:17:38 UTC
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.

Comment 12 David O'Brien 2010-01-05 01:47:03 UTC
I've add a summary and link to this BZ on the freeIPA Documentation Portal


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