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 <[email protected]> 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
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
