Troels Hansen wrote:
I can see this have been discussed a lot here, but I still can't seem to
find the correct answer, so bare with me if i'm asking a question
already answered.

I'm trying to create a user that can be used for (headless) joining out
RHEL clients to IPA

Here is what have been done:
/etc/krb5.conf and /etc/ipa/ca.crt copied to the client.

a user created on IPA:

# ipa user-show joinipa
User login: joinipa
First name: Host
Last name: Adder
Home directory: /home/joinipa
Login shell: /bin/sh
Email address:
UID: 10006
GID: 10006
Account disabled: False
Password: False
Member of groups: ipausers
Roles: joinipa
Kerberos keys available: True

has role joinipa

# ipa role-show "joinipa"
Role name: joinipa
Member users: joinipa
Privileges: Host Enrollment

Host Enrollemnt provilege also has the 'System: Add Hosts' permission:

# ipa privilege-show "Host Enrollment"
Privilege name: Host Enrollment
Description: Host Enrollment
Permissions: System: Add Hosts, System: Add krbPrincipalName to a Host,
System: Enroll a Host, System: Manage Host Certificates,
System: Manage Host Enrollment Password, System: Manage Host Keytab
Granting privilege to roles: joinipa

Get the keytab from IPA server (run on IPA server):
# ipa-getkeytab -s  `hostname` -p -k /tmp/joinipa.keytab

Keytab copied to IPA client:

kinit keytab:
# kinit -kt joinipa.keytab

# klist
Ticket cache: KEYRING:persistent:0:0
Default principal:

Valid starting Expires Service principal
08/11/2016 10:12:33 08/12/2016 10:12:33 krbtgt/

Try to join IPA server:
# ipa-join --server
Failed to parse result: Insufficient access rights

Retrying with pre-4.0 keytab retrieval method...
Keytab successfully retrieved and stored in: /etc/krb5.keytab
Certificate subject base is: O=LINUX.DR.DK

Host gets created on IPA server, but what makes it fail?

If I try to join again I also get told its already joined:

# ipa-join --server
Host is already joined.

Hard to say since you don't include what version of IPA this is, but I think you're misinterpreting this. The join is successful (check the rval).

I think it failed trying to read the existing keytab (and it doesn't matter that there isn't one yet) in LDAP. This fails so it then creates one using another method. That permission is separate (but probably not too important in this use case).


Manage your subscription for the Freeipa-users mailing list:
Go to for more info on the project

Reply via email to