On to, 17 helmi 2022, Pedro Bezunartea López via FreeIPA-users wrote:
Dear Alexander,
Thank you for your message, it's been very helpful!
I stumbled upon a very relevant thread to which you also contributed:
https://lists.fedorahosted.org/archives/list/[email protected]/thread/5IXBFOXMLFOZILHRA3KSGDGHC3LCBEHB/?sort=date
This is exactly what we need: A client Idm member (certs-server), where
ad_users can ssh and manage their certificates. In that thread you respond:
"You'd need
to create an ACL that would allow a host identity that
certmonger uses to have write rights to the userCertificate attribute of
the target user. You are already successfully passed CA ACL check
because the framework tried to see if you have rights to actually write
the resulting certificate (public cert) to the userCertficiate attribute
of the target entry, so it was not a question whether you can issue
(yes, you can) but whether you can store the cert (you cannot).
A way to create that would be by utilizing permissions/roles system of FreeIPA.
Something like this:
ipa permission-add write-user-certificate-permission \
--right=write --attrs=userCertificate --type=user
ipa privilege-add write-user-certificate-privilege
ipa privilege-add-permission write-user-certificate-privilege \
--permissions=write-user-certificate-permission
ipa role-add user-certificate-issuer
ipa role-add-privilege user-certificate-issuer \
--privileges=write-user-certificate-privilege
ipa role-add-member user-certificate-issuer \
--hosts=apex-openvpn"
In order to replicate this we'd need to:
1. Enable Certmonger on the IDM server.
2. Create an ACL that "would allow a host identity that
certmonger uses to have write rights to the userCertificate attribute of
the target user"
3. AD users log in to the client machine certs-server (ssh)
4. Using Certmonger, generate a key and CSR.
Do I understand correctly?
I think you should not use certmonger for that. If your AD users have
ability to obtain Kerberos tickets from AD, they can already request a
certificate using IPA API. What prevents this certificate request from
proper processing is a lack of logic to accept IPA API requests bound as
ID overrides from the Default Trust View.
Before AD users can talk to IPA API, IPA admins need to add ID overrides
for them. This is done with
$ kinit admin
$ ipa idoverrideuser-add 'Default Trust View' [email protected]
We don't need to set any other property in the ID override at this
point, just make sure that '[email protected]' is the normalized user
Kerberos principal in AD. E.g., the one that 'kinit [email protected]'
would return a TGT for, though it can be all low-cased.
Suppose that your AD user has a Kebreros TGT, then requesting a ticket
would be something like
$ kinit [email protected]
$ generate-a-request -o ./request.file
$ ipa cert-request ./request.file [--ca=my-ca] [--profile=my-profile] -o
cert.out
For the latter to work, we need to fix IPA API plugin cert.py
(cert_request class), to be able to do a lookup for AD users of their ID
overrides and properly use those for access control checks.
When you bound as ID override to LDAP (as would happen if you'd use your
AD Kerberos ticket to use IPA CLI), you'd be able to write to
certificate attribute in the ID override, thanks to already existing
self-service ACIs.
Please open a ticket and work on a possible design how this could look
like. You don't need to go deep to code level. Please list possible use
cases and expected workflow to allow understanding possible drawbacks of
this solution.
How is this for a first draft?
- New Feature: Allow AD users to manage their own certificates.
- Rationale: AD users can currently authenticate to IDM client
machines. There are additional services which need certificate
based-authentication on a per-user or per-group basis such as VPN, web
server.
- Workflow:
1. The Certificate Management server (certs-server) is setup to host
multiple services certificates: VPN, web-server-1, ...
2. Access is granted to AD user to the certs-server and to the relevant
services.
3. The AD user logs in to the certs-server.
4. The AD user manages certificates to available services: manage keys
and certificates' lifecycle.
The workflow above is not relevant to IPA itself. How you'd arrange the
process on your side is secondary. Please see my explanation of the flow
above for what would really matter to IPA here. E.g. presence of ID
override in the default trust view and modifications in the cert.py to
allow ID override bound Kerberos principal to ask for the certificates.
ID overrides already can be added as members of groups in IPA for the
purpose of role/permission checks, see
https://freeipa.readthedocs.io/en/latest/designs/adtrust/admin-ipa-as-trusted-user.html
for more details.
--
/ 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 on the list, report it:
https://pagure.io/fedora-infrastructure
