We want to be able to destroy/recreate IPA enrolled hosts without using admin credentials.
ipa-client-install with a keytab seems like a good option except it generates a new keytab. And there is no non-hacky way of passing this new keytab back to terraform. Can we tell it not to generate a new keytab on re-enrollment?
Alternatively, we could create a user that has just enough permissions to enroll host X but nothing else. What is the minimum set of permissions for this?
Or is there a better way?
Cheers, Yuriy
On Няд, 10 сак 2024, Yuriy Halytskyy via FreeIPA-users wrote:
We want to be able to destroy/recreate IPA enrolled hosts without using admin credentials.
ipa-client-install with a keytab seems like a good option except it generates a new keytab. And there is no non-hacky way of passing this new keytab back to terraform. Can we tell it not to generate a new keytab on re-enrollment?
This option (--keytab) was supposed to be used as a re-enrollment tool for existing host. Thus, it forces use of a previously known keytab and forcibly regenerates it because of the commonly used policy in IPA that password must only be known to the end-user entity.
You should not be using it to automate enrollments.
Alternatively, we could create a user that has just enough permissions to enroll host X but nothing else. What is the minimum set of permissions for this?
The enrollment process is split into two parts:
- adding host object - enrolling actual host: configuring the system and requesting its keys
There are two separate permissions for this already:
- 'System: Add Hosts' - 'System: Enroll a Host'
If you have a system already added to IPA, then only the second permission for enrollemnt user. Depending on the options you are using during enrollment, more permissions might be needed. See a link to ipa-hcc below for details of some of those.
Or is there a better way?
Another option is in newer (as of RHEL 8.4 or RHEL 9.2, I think) IPA version: use PKINIT authentication to enroll hosts. This allows to map a certificate to the principal that can enroll the host. You can either use a certificate that is mapped on the IPA KDC side to this host identity (e.g. a certificate that has host/<hostname> Kebreros principal in it) or use it to replace a password-based authentication of an enrollment user who has 'System: Enroll a Host' permission.
See 'PKINIT Options' in ipa-client-install(1) man page and https://freeipa.readthedocs.io/en/latest/designs/client-install-pkinit.html design page for more details.
This method is used by the Podengo project's ipa-hcc plugin, for example, where a host-associated RHEL subscription manager certificate is used to authenticate against IPA during domain enrollment. See https://github.com/podengo-project/ipa-hcc for details.
Awesome, pkinit is exactly what we need, thank you.
Is the `--principal` option for ipa cert-request needed with a matching rule? e.g. if we have
ipa certmaprule-add pkinit-host --matchrule '<ISSUER>xxxx' --maprule='(fqdn={subject_dns_name})'
Do I also need to
ipa cert-request example.csr --principal=host/example.com --certificate-out=example.pem
for pkinit to work?
Cheers, Yuriy
On Mon, Mar 11, 2024 at 4:08 AM Alexander Bokovoy abokovoy@redhat.com wrote:
On Няд, 10 сак 2024, Yuriy Halytskyy via FreeIPA-users wrote:
We want to be able to destroy/recreate IPA enrolled hosts without using admin credentials.
ipa-client-install with a keytab seems like a good option except it generates a new keytab. And there is no non-hacky way of passing this new keytab back to terraform. Can we tell it not to generate a new keytab on re-enrollment?
This option (--keytab) was supposed to be used as a re-enrollment tool for existing host. Thus, it forces use of a previously known keytab and forcibly regenerates it because of the commonly used policy in IPA that password must only be known to the end-user entity.
You should not be using it to automate enrollments.
Alternatively, we could create a user that has just enough permissions to enroll host X but nothing else. What is the minimum set of permissions for this?
The enrollment process is split into two parts:
- adding host object
- enrolling actual host: configuring the system and requesting its keys
There are two separate permissions for this already:
- 'System: Add Hosts'
- 'System: Enroll a Host'
If you have a system already added to IPA, then only the second permission for enrollemnt user. Depending on the options you are using during enrollment, more permissions might be needed. See a link to ipa-hcc below for details of some of those.
Or is there a better way?
Another option is in newer (as of RHEL 8.4 or RHEL 9.2, I think) IPA version: use PKINIT authentication to enroll hosts. This allows to map a certificate to the principal that can enroll the host. You can either use a certificate that is mapped on the IPA KDC side to this host identity (e.g. a certificate that has host/<hostname> Kebreros principal in it) or use it to replace a password-based authentication of an enrollment user who has 'System: Enroll a Host' permission.
See 'PKINIT Options' in ipa-client-install(1) man page and https://freeipa.readthedocs.io/en/latest/designs/client-install-pkinit.html design page for more details.
This method is used by the Podengo project's ipa-hcc plugin, for example, where a host-associated RHEL subscription manager certificate is used to authenticate against IPA during domain enrollment. See https://github.com/podengo-project/ipa-hcc for details.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
On Аўт, 12 сак 2024, Yuriy Halytskyy wrote:
Awesome, pkinit is exactly what we need, thank you.
Is the `--principal` option for ipa cert-request needed with a matching rule? e.g. if we have
ipa certmaprule-add pkinit-host --matchrule '<ISSUER>xxxx' --maprule='(fqdn={subject_dns_name})'
With an explicit mapping rule you don't specifically need a principal in the certificate. The point of a mapping rule is provide an alternative mapping mechanism to use of the Kerberos principal name in the certificate. If you have Kerberos principal recorded in the certificate, use of that is already covered without explicit mapping rule.
Do I also need to
ipa cert-request example.csr --principal=host/example.com --certificate-out=example.pem
for pkinit to work?
You can but you don't need to.
Cheers, Yuriy
On Mon, Mar 11, 2024 at 4:08 AM Alexander Bokovoy abokovoy@redhat.com wrote:
On Няд, 10 сак 2024, Yuriy Halytskyy via FreeIPA-users wrote:
We want to be able to destroy/recreate IPA enrolled hosts without using admin credentials.
ipa-client-install with a keytab seems like a good option except it generates a new keytab. And there is no non-hacky way of passing this new keytab back to terraform. Can we tell it not to generate a new keytab on re-enrollment?
This option (--keytab) was supposed to be used as a re-enrollment tool for existing host. Thus, it forces use of a previously known keytab and forcibly regenerates it because of the commonly used policy in IPA that password must only be known to the end-user entity.
You should not be using it to automate enrollments.
Alternatively, we could create a user that has just enough permissions to enroll host X but nothing else. What is the minimum set of permissions for this?
The enrollment process is split into two parts:
- adding host object
- enrolling actual host: configuring the system and requesting its keys
There are two separate permissions for this already:
- 'System: Add Hosts'
- 'System: Enroll a Host'
If you have a system already added to IPA, then only the second permission for enrollemnt user. Depending on the options you are using during enrollment, more permissions might be needed. See a link to ipa-hcc below for details of some of those.
Or is there a better way?
Another option is in newer (as of RHEL 8.4 or RHEL 9.2, I think) IPA version: use PKINIT authentication to enroll hosts. This allows to map a certificate to the principal that can enroll the host. You can either use a certificate that is mapped on the IPA KDC side to this host identity (e.g. a certificate that has host/<hostname> Kebreros principal in it) or use it to replace a password-based authentication of an enrollment user who has 'System: Enroll a Host' permission.
See 'PKINIT Options' in ipa-client-install(1) man page and https://freeipa.readthedocs.io/en/latest/designs/client-install-pkinit.html design page for more details.
This method is used by the Podengo project's ipa-hcc plugin, for example, where a host-associated RHEL subscription manager certificate is used to authenticate against IPA during domain enrollment. See https://github.com/podengo-project/ipa-hcc for details.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Yuriy Halytskyy