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: join...@linux.dr.dk
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 join...@linux.dr.dk -k /tmp/joinipa.keytab
Keytab copied to IPA client:
kinit keytab:
# kinit join...@linux.dr.dk -kt joinipa.keytab
# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: join...@linux.dr.dk
Valid starting Expires Service principal
08/11/2016 10:12:33 08/12/2016 10:12:33 krbtgt/linux.dr...@linux.dr.dk
Try to join IPA server:
# ipa-join --server ipa01tst.linux.dr.dk
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 ipa01tst.linux.dr.dk
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).
rob
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
