On Mon, Oct 28, 2019 at 01:53:51PM -0400, James Ralston wrote: > On Mon, Oct 28, 2019 at 3:21 AM Sumit Bose <[email protected]> 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 -- [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] _______________________________________________ sssd-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]
