(don't drop the mailing list, please)

On la, 01 loka 2022, Sami Hulkko wrote:
well,

For starters it would be quite rational and practical to provide certificates for Samba AD and it's users trough IPA Dogtag rather then having a second certificate system for it. Wouldn't it?

I would see this a completely separate task and is not relevant to IPA
itself.
You'd want to issue certificates to some entities that do not
exist in IPA. For this you are practically not required to be bound by
IPA itself, it is something that can be achieved with Dogtag services
directly. We do not hide them so if you have set up an ACL that allows
to authenticate to Dogtag and be granted certain privileges, you can
issue certificates by the Dogtag instance that runs IPA CA as well.

If you'd still want to bind a check to existence of an ID override of a
user, that would need some fixes in IPA:

 - fix cert_request.lookup_principal() to also look at the ID overrides
   in the 'Default Trust View' ID view

 - add support for 'mail' attribute into user ID overrides to be able to
   match certificate requests. This should not be writable to users
   themselves (a default state in IPA)

 - fix cert_request.execute() to consider ID overrides as 'principals'
   returned by the cert_request.lookup_or_add_principal() (which calls
   lookup_principal()). There are quite a few differences, the most
   important one is that ID overrides aren't Kerberos principals so they
   don't have krbPrincipalName/krbCanonicalName attributes at all. They
   have ipaOriginalUid attribute which can be used to match a a Kerberos
   principal.

 - fix CA ACL checks to allow use of ID override-bound principals

May be more to do. If you want to implement this, feel free to open a
ticket and submit a pull request and we can work it out there. It
certainly could be implemented so any contribution is welcomed.



SH

On 01/10/2022 13:19, Alexander Bokovoy wrote:
On la, 01 loka 2022, Sami Hulkko via FreeIPA-users wrote:
Hi,

Is it possible to provide certificate (Dogtag) for AD trusted user that has login rights to IPA trough ID override?

I'd ask a question in advance: what this certificate would be used for?

ID overrides aren't real users, so you wouldn't be able to use that for
login purposes. Users from trusted Active Directory domains get
authenticated by their own domain's domain controllers, not IPA. So you
cannot use that certificate for something on IPA side other than an SSH
public key authentication. For this, it does not matter who issued the
certificate, any user has a self-service right to update ipaSSHPubKey
attribute, including AD users who can update their own override.
They can also update their own userCertificate attribute according to
one of default access controles:

aci: (targetattr = "usercertificate")(version 3.0;acl "selfservice:Users can manage their own X.509 certificates";allow (write) userdn = "ldap:///self";;)

but where they could be using this certificate to match for?

In addition, IPA framework does check properties of the accounts that
request certificate issuance and only allows to issue certificates to
IPA users, IPA hosts, and IPA services. ID overrides aren't included,
for reasons outlined above.

For more details on how IPA certificate issuance checks done please see
my response to Sam Morris in May 2022:
https://lists.fedorahosted.org/archives/list/[email protected]/message/7NAZ2AT7FXXVBL42DTKJHCUQNOJBZB27/


--
Me worry? That's why my first CD was Peter Gabriel SO....

Sami Hulkko
[email protected]
[email protected]
[email protected]
+358 45 85693 919

BEGIN:VCARD
VERSION:4.0
EMAIL;PREF=1:[email protected]
EMAIL:[email protected]
FN:Sami Hulkko
NICKNAME:Atol
N:Hulkko;Sami;;;
TEL;VALUE=TEXT:+358458569319
X-MOZILLA-HTML;VALUE=BOOLEAN:FALSE
UID:53ad98cb-d6b2-4667-a26c-6f564a428e51
END:VCARD




--
/ 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

Reply via email to