|
|
c58629 |
From 30e55883bd4822d4d3af061d646e7b1044880d52 Mon Sep 17 00:00:00 2001
|
|
|
c58629 |
From: Florence Blanc-Renaud <flo@redhat.com>
|
|
|
c58629 |
Date: Tue, 7 Nov 2017 09:31:19 +0100
|
|
|
c58629 |
Subject: [PATCH] ipa-getkeytab man page: add more details about the -r option
|
|
|
c58629 |
|
|
|
c58629 |
The man page does not provide enough information about replicated
|
|
|
c58629 |
environments and the use of the -r option.
|
|
|
c58629 |
This fix adds an example how to use the same keytab on 2 different
|
|
|
c58629 |
hosts, and points to ipa {service/host}-allow-retrieve-keytab.
|
|
|
c58629 |
|
|
|
c58629 |
Fixes:
|
|
|
c58629 |
https://pagure.io/freeipa/issue/7237
|
|
|
c58629 |
|
|
|
c58629 |
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
|
|
|
c58629 |
---
|
|
|
c58629 |
client/man/ipa-getkeytab.1 | 35 ++++++++++++++++++++++++++++++++++-
|
|
|
c58629 |
1 file changed, 34 insertions(+), 1 deletion(-)
|
|
|
c58629 |
|
|
|
c58629 |
diff --git a/client/man/ipa-getkeytab.1 b/client/man/ipa-getkeytab.1
|
|
|
c58629 |
index 08f6ec40d362b88a974e6ec735ed37c271e01882..39ff0d5da85b5a641328a512feeb06bc9c1ab9d7 100644
|
|
|
c58629 |
--- a/client/man/ipa-getkeytab.1
|
|
|
c58629 |
+++ b/client/man/ipa-getkeytab.1
|
|
|
c58629 |
@@ -44,10 +44,15 @@ provided, so the principal name is just the service
|
|
|
c58629 |
name and hostname (ldap/foo.example.com from the
|
|
|
c58629 |
example above).
|
|
|
c58629 |
|
|
|
c58629 |
+ipa-getkeytab is used during IPA client enrollment to retrieve a host service principal and store it in /etc/krb5.keytab. It is possible to retrieve the keytab without Kerberos credentials if the host was pre\-created with a one\-time password. The keytab can be retrieved by binding as the host and authenticating with this one\-time password. The \fB\-D|\-\-binddn\fR and \fB\-w|\-\-bindpw\fR options are used for this authentication.
|
|
|
c58629 |
+
|
|
|
c58629 |
\fBWARNING:\fR retrieving the keytab resets the secret for the Kerberos principal.
|
|
|
c58629 |
This renders all other keytabs for that principal invalid.
|
|
|
c58629 |
+When multiple hosts or services need to share the same key (for instance in high availability or load balancing clusters), the \fB\-r\fR option must be used to retrieve the existing key instead of generating a new one (please refer to the EXAMPLES section).
|
|
|
c58629 |
+
|
|
|
c58629 |
+Note that the user or host calling \fBipa-getkeytab\fR needs to be allowed to generate the key with \fBipa host\-allow\-create\-keytab\fR or \fBipa service\-allow\-create\-keytab\fR,
|
|
|
c58629 |
+and the user or host calling \fBipa-getkeytab \-r\fR needs to be allowed to retrieve the keytab for the host or service with \fBipa host\-allow\-retrieve\-keytab\fR or \fBipa service\-allow\-retrieve\-keytab\fR.
|
|
|
c58629 |
|
|
|
c58629 |
-This is used during IPA client enrollment to retrieve a host service principal and store it in /etc/krb5.keytab. It is possible to retrieve the keytab without Kerberos credentials if the host was pre\-created with a one\-time password. The keytab can be retrieved by binding as the host and authenticating with this one\-time password. The \fB\-D|\-\-binddn\fR and \fB\-w|\-\-bindpw\fR options are used for this authentication.
|
|
|
c58629 |
.SH "OPTIONS"
|
|
|
c58629 |
.TP
|
|
|
c58629 |
\fB\-p principal\-name\fR
|
|
|
c58629 |
@@ -118,16 +123,44 @@ keytab must have access to the keys for this operation to succeed.
|
|
|
c58629 |
Add and retrieve a keytab for the NFS service principal on
|
|
|
c58629 |
the host foo.example.com and save it in the file /tmp/nfs.keytab and retrieve just the des\-cbc\-crc key.
|
|
|
c58629 |
|
|
|
c58629 |
+.nf
|
|
|
c58629 |
# ipa\-getkeytab \-p nfs/foo.example.com \-k /tmp/nfs.keytab \-e des\-cbc\-crc
|
|
|
c58629 |
+.fi
|
|
|
c58629 |
|
|
|
c58629 |
Add and retrieve a keytab for the ldap service principal on
|
|
|
c58629 |
the host foo.example.com and save it in the file /tmp/ldap.keytab.
|
|
|
c58629 |
|
|
|
c58629 |
+.nf
|
|
|
c58629 |
# ipa\-getkeytab \-s ipaserver.example.com \-p ldap/foo.example.com \-k /tmp/ldap.keytab
|
|
|
c58629 |
+.fi
|
|
|
c58629 |
|
|
|
c58629 |
Retrieve a keytab using LDAP credentials (this will typically be done by \fBipa\-join(1)\fR when enrolling a client using the \fBipa\-client\-install(1)\fR command:
|
|
|
c58629 |
|
|
|
c58629 |
+.nf
|
|
|
c58629 |
# ipa\-getkeytab \-s ipaserver.example.com \-p host/foo.example.com \-k /etc/krb5.keytab \-D fqdn=foo.example.com,cn=computers,cn=accounts,dc=example,dc=com \-w password
|
|
|
c58629 |
+.fi
|
|
|
c58629 |
+
|
|
|
c58629 |
+Add and retrieve a keytab for a clustered HTTP service deployed on client1.example.com and client2.example.com (already enrolled), using the client-frontend.example.com host name:
|
|
|
c58629 |
+
|
|
|
c58629 |
+.nf
|
|
|
c58629 |
+ # ipa host-add client-frontend.example.com --ip-address 10.1.2.3
|
|
|
c58629 |
+ # ipa service-add HTTP/client-frontend.example.com
|
|
|
c58629 |
+ # ipa service-allow-retrieve-keytab HTTP/client-frontend.example.com --hosts={client1.example.com,client2.example.com}
|
|
|
c58629 |
+ # ipa server-allow-create-keytab HTTP/client-frontend.example.com --hosts=client1.example.com
|
|
|
c58629 |
+.fi
|
|
|
c58629 |
+
|
|
|
c58629 |
+ On client1, generate and retrieve a new keytab for client-frontend.example.com:
|
|
|
c58629 |
+.nf
|
|
|
c58629 |
+ # kinit -k
|
|
|
c58629 |
+ # ipa-getkeytab -p HTTP/client-frontend.example.com -k /tmp/http.keytab
|
|
|
c58629 |
+
|
|
|
c58629 |
+.fi
|
|
|
c58629 |
+ On client2, retrieve the existing keytab for client-frontend.example.com:
|
|
|
c58629 |
+.nf
|
|
|
c58629 |
+ # kinit -k
|
|
|
c58629 |
+ # ipa-getkeytab -r -p HTTP/client-frontend.example.com -k /tmp/http.keytab
|
|
|
c58629 |
+.fi
|
|
|
c58629 |
+
|
|
|
c58629 |
.SH "EXIT STATUS"
|
|
|
c58629 |
The exit status is 0 on success, nonzero on error.
|
|
|
c58629 |
|
|
|
c58629 |
--
|
|
|
c58629 |
2.13.6
|
|
|
c58629 |
|