On Mon, Oct 28, 2019 at 01:53:51PM -0400, James Ralston wrote:
On Mon, Oct 28, 2019 at 3:21 AM Sumit Bose <sbose(a)redhat.com>
wrote:
> unfortunately there are two different ways to encode Kerberos
> principals, one is the AD way with OID 1.3.6.1.4.1.311.20.2.3 the other
> is defined in RFC 4556 with 1.3.6.1.5.2.2.
>
> To be most flexible the mapping and matching rules provide for the
> AD encoding:
>
> - <SAN:ntPrincipalName>.*@MY\.AD\.REALM
> - userPrincipalName={subject_nt_principal}
>
> for RFC 4556:
>
> - <SAN:pkinit>.*@MY\.PKINIT\.REALM
> - userPrincipalName={subject_pkinit_principal}
>
> or if you do not know which encoding is used:
>
> - <SAN:Principal>.*@MY\.REALM
> - userPrincipalName={subject_principal}
>
> which cover both encodings.
Thanks; that's exactly the information I was looking for.
> I'm sorry, currently there are some copy-and-paste errors in the
> examples of the sss-certmap man page. I'll try to fix them in one of
> the next releases.
Yes, I noticed that. If I have a chance, I'll submit a merge request
to clean up the documentation.
A related question: our AD guys are giving me no end of grief that the
RHEL7 sssd can't perform the certificate-to-user mapping
automatically. Keeping everyone's userCertificate attribute updated
in AD is going to be a maintenance nightmare. So, I think I'm going
to have to at least make an attempt to backport that feature to
ssd-1.16.4 for RHEL7.
How feasible do you think this is? E.g.:
1. You should be able to drop that feature into 1.16.4 without too
much effort.
2. It will be non-trivial, but doable.
3. That feature depends on numerous other code paths that didn't
exist in 1.16.4; it will be extremely difficult to backport that
feature to 1.16.4.
Alternatively, I could attempt to rebuild sssd-2.0.0-43.el8_0.3 for
RHEL7. I tested that already, and the only thing I had to do to get
it to build was to comment out a few test packages that exist on RHEL8
but not on RHEL7.
But the problem with just building the RHEL8 sssd package for RHEL7 is
that I will have to track updates to RHEL8. And a point release
(e.g., RHEL 8.2) could bring a newer sssd that no longer builds on
RHEL7. So patching the certificate mapping feature into sssd 1.16.4
would be more future-proof.
Hi,
I tend to agree that backporting might be the better way. As you might
have seen with RHEL8 SSSD does not use NSS anymore but OpenSSL and
p11-kit. So the NSS code paths needed on RHEL7 might not be tested as
good as the OpenSSL ones with sssd-2.x.
I didn't had a chance to look at how easy or hard backporting would be.
But most of the code-paths are still similar so that most patches should
apply. If some of the patches do not apply I would recommend to look for
the patch causing the difference between sssd-1.16.x and sssd-2.x and
apply this patch before. This helps to avoid introducing issues by
modifying patches.
(We have a support contract with Red Hat, but from past experience,
there is basically no chance Red Hat will undertake this backport for
a RHEL release that is already in maintenance support 1 phase.)
Please feel free to try anyways. The more people are asking for this
feature the stronger the justification for backporting the feature will
become.
bye,
Sumit
Thanks in advance for any advice.
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
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/sssd-users@lists.fedorahoste...