#3377 Enrolling a host into IdM/IPA always takes two attempts
Closed: Fixed None Opened 11 years ago by rcritten.

https://bugzilla.redhat.com/show_bug.cgi?id=903343 (Red Hat Enterprise Linux 6)

Created attachment 686168
1st attempt = Failure

Background:
The North American Solution Architect group currently run 4 labs spread out in
the US (RDU/PHX/IAD/NYC). All have at least 2 instances of IdM running in the
lab to manage the SALAB.REDHAT.COM realm and is replicated to all labs. SA's
can be added to the realm and we configure as many serivces to auth to it as
possible (currently only sat & rhev).

Description of problem:
I've created a new Role (Build Administrator, I don't think that was there
before). But I added the Privilege 'Host Administrator' to that role.  I'm 99%
sure that priv was there in the default install. I then created a user and
added that user to this newly created role.

But in attempting to enroll a host using this new user, I always get the
following error message on the first attempt:

Joining realm failed: Operation failed! Insufficient access rights

If I unenroll the machine and attempt it again, it succeeds. I can use --force,
but no keys/certificates have been generated for the host.



Version-Release number of selected component (if applicable):

[root@idm1.rdu log]$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.3 (Santiago)
[root@idm1.rdu log]$ rpm -qa|grep ipa
python-iniparse-0.3.1-2.1.el6.noarch
ipa-pki-common-theme-9.0.3-7.el6.noarch
ipa-server-2.2.0-16.el6.x86_64
ipa-server-selinux-2.2.0-16.el6.x86_64
libipa_hbac-1.8.0-32.el6.x86_64
libipa_hbac-python-1.8.0-32.el6.x86_64
ipa-client-2.2.0-16.el6.x86_64
ipa-python-2.2.0-16.el6.x86_64
ipa-admintools-2.2.0-16.el6.x86_64
ipa-pki-ca-theme-9.0.3-7.el6.noarch


How reproducible:
Everytime.

Steps to Reproduce:
1. Create new role 'Build Administrator'
2. Add the 'host administrators' privilege to the role
3. Create a new user and add the new 'Build Administrator' role.


Additional info:

These machines are running the SA labs and are open to engineering to login and
look around. Granted they are running our 'production' SA labs, we can do some
testing if necessary.

I collected the attached logs by running the following command from /var/log on
the idm1.rdu.salab.redhat.com host.

# tail -f krb5kdc.log dirsrv/slapd-SALAB-REDHAT-COM/access
dirsrv/slapd-SALAB-REDHAT-COM/errors httpd/access_log httpd/error_log

I am 'matt' on irc if you need to chat offline (need access / etc).

So far, when I tried to reproduce this issue in the recent FreeIPA build, it worked for me - a user with 'Build Administrator' role was able to enroll a host to IPA realm during ipa-client-install.

Moving to rcritten as he was able to reproduce this bug.

This was fixed in 389-ds-base 1.2.11

Some unit tests were failing and I noticed it is because the PBAC membership isn't right. This is due to the fact that the PBAC memberof rebuild task is run before some of the membership is set.

This can be seen clearly with the IT Security Specialist role.

The member attributes are added before the role is added which is why the memberOf isn't built properly, and explains why running a memberOf task fixes it.

I wonder if we should honor the README and actually apply the tens of values at a time rather than collecting them all, then applying. It is unclear what side-effects this would have.

master: 8377f4e

This patch commits to LDAP the updates in blocks of 10.

master: 583bf43

Revert patch f7e27b5 which was a test case fix which addressed the symptom of memberof not being generated properly.

Metadata Update from @rcritten:
- Issue assigned to rcritten
- Issue set to the milestone: FreeIPA 3.2 - 2013/04-05 (GA)

7 years ago

Login to comment on this ticket.

Metadata