[sssd PR#570][comment] p11_child: add OpenSSL support
by jhrozek
URL: https://github.com/SSSD/sssd/pull/570
Title: #570: p11_child: add OpenSSL support
jhrozek commented:
"""
> On 30 May 2018, at 11:03, sumit-bose <notifications(a)github.com> wrote:
>
> Hi Jakub,
>
> the latest version fixes the softhsm2-util-p11tool issues, if one of the tools is missing the test CA and related tests are not build.
Thanks, I’ll test this.
>
> About additional files, yes there will be e.g. a file with the CRL (certificate revocation list). So you would prefer a subdirectory?
I would, but it was just an idea, do you think the flat file is eaiser or better?
> Would you like to suggest a name?
>
/etc/sssd/pki ?
> The system CA store contains a lot of public CAs from all over the world and recently there were cases where CAs had to be removed because there were evidence the they issue certificates to people which were not owner of domains or emails mentioned in the certificate. So there is a risk that someone can get a certificate from a CA in the system CA store which would map to your account be rules based mapping. Hence I prefer to have the CA certificates in a file on its own.
>
> Additionally system CA stores might not be portable to different OS or distributions, so it would be easier for documentation and bug hunting if SSSD has its own file.
>
OK, thank you for the explanation.
"""
See the full comment at https://github.com/SSSD/sssd/pull/570#issuecomment-393105818
5 years, 10 months
[sssd PR#570][comment] p11_child: add OpenSSL support
by sumit-bose
URL: https://github.com/SSSD/sssd/pull/570
Title: #570: p11_child: add OpenSSL support
sumit-bose commented:
"""
Hi Jakub,
the latest version fixes the softhsm2-util-p11tool issues, if one of the tools is missing the test CA and related tests are not build.
About additional files, yes there will be e.g. a file with the CRL (certificate revocation list). So you would prefer a subdirectory? Would you like to suggest a name?
The system CA store contains a lot of public CAs from all over the world and recently there were cases where CAs had to be removed because there were evidence the they issue certificates to people which were not owner of domains or emails mentioned in the certificate. So there is a risk that someone can get a certificate from a CA in the system CA store which would map to your account be rules based mapping. Hence I prefer to have the CA certificates in a file on its own.
Additionally system CA stores might not be portable to different OS or distributions, so it would be easier for documentation and bug hunting if SSSD has its own file.
bye,
Sumit
"""
See the full comment at https://github.com/SSSD/sssd/pull/570#issuecomment-393086519
5 years, 10 months
[sssd PR#570][comment] p11_child: add OpenSSL support
by jhrozek
URL: https://github.com/SSSD/sssd/pull/570
Title: #570: p11_child: add OpenSSL support
jhrozek commented:
"""
> On 28 May 2018, at 13:21, sumit-bose <notifications(a)github.com> wrote:
>
> Hi @jhrozek, thank you for the review.
>
> I added 'certmap: allow missing empty EKU in OpenSSL version' to fix the missing EKU issues. The patch also contains a new test certificate without EKU to make sure libcertmap can handle missing EKUs.
>
> I added default values and man page updates for the CA DB options. I choose /etc/sssd/sssd_auth_ca_db.pem as the default for the OpenSSL build.
OK, I verified that this works. The only question that popped into my mind was if it was cleaner to put the cert into a subdirectory of /etc/sssd instead of directly there (c.f. /etc/openldap/certs). But I don’t have strong feelings either way, it would only be a good idea if we anticipate more files than a single one at some point in the future.
> I'd prefer not to use system-wide CA bundles like e.g /etc/pki/tls/certs/ca-bundle.crt because if the certificate is mapped to the user not with the full certificate but only based on parts of the certificate content validating the certificate with CA certificates trusted for authentication becomes important.
>
I’m sorry, but can you explain this in more detail to me? Why would dropping the CA certificate to the system CA cert store be harmful? Or is it to make sure that not another CA cert if picked, but really the one for SSSD? As you say below, we can use tools to make this work for the IPA case, but for the local users with a smart card case, we would need the admin to configure this manually. In RHEL-7, I would have argued that authconfig could help, but in modern Fedoras authselect won’t.
> For the IPA case we can discuss with IPA developers if the ipa-advice helper script for Smartcard authentication can create this file as a link to /var/lib/ipa-client/pki/ca-bundle.pem.
>
Is there a reason not to do this by default as part of ipa-client-install? Since currently the certificate would only be used during cert auth. In general I prefer to have fewer manual steps to configure the client.
"""
See the full comment at https://github.com/SSSD/sssd/pull/570#issuecomment-393077194
5 years, 10 months
[sssd PR#570][comment] p11_child: add OpenSSL support
by jhrozek
URL: https://github.com/SSSD/sssd/pull/570
Title: #570: p11_child: add OpenSSL support
jhrozek commented:
"""
> On 29 May 2018, at 13:50, Jakub Hrozek <notifications(a)github.com> wrote:
>
> There seems to be one more glitch. If I don't have softsm-util installed, then configure says it can't be found, but then make fails with:
>
> SOFTHSM2_CONF=./softhsm2_none.conf --init-token --label "SSSD Test Token" --pin 123456 --so-pin 123456 --free
> bin/sh: --init-token: command not found
OK, I see now that both softshm and gnutls are BuildRequired, so the only reason I didn’t have them installed on my test VM is because I compile from source. It would be nice to fix the tests so that they are skipped if either is not installed, but it’s a minor issue.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, or mute the thread.
>
"""
See the full comment at https://github.com/SSSD/sssd/pull/570#issuecomment-393073321
5 years, 10 months
[sssd PR#570][comment] p11_child: add OpenSSL support
by sumit-bose
URL: https://github.com/SSSD/sssd/pull/570
Title: #570: p11_child: add OpenSSL support
sumit-bose commented:
"""
Hi @jhrozek, thank you for the review.
I added 'certmap: allow missing empty EKU in OpenSSL version' to fix the missing EKU issues. The patch also contains a new test certificate without EKU to make sure libcertmap can handle missing EKUs.
I added default values and man page updates for the CA DB options. I choose /etc/sssd/sssd_auth_ca_db.pem as the default for the OpenSSL build. I'd prefer not to use system-wide CA bundles like e.g /etc/pki/tls/certs/ca-bundle.crt because if the certificate is mapped to the user not with the full certificate but only based on parts of the certificate content validating the certificate with CA certificates trusted for authentication becomes important.
For the IPA case we can discuss with IPA developers if the ipa-advice helper script for Smartcard authentication can create this file as a link to /var/lib/ipa-client/pki/ca-bundle.pem.
"""
See the full comment at https://github.com/SSSD/sssd/pull/570#issuecomment-392500377
5 years, 10 months
[sssd PR#575][opened] DP/LDAP: Only increase the initgrTimestamp when the full initgroups DP request finishes
by jhrozek
URL: https://github.com/SSSD/sssd/pull/575
Author: jhrozek
Title: #575: DP/LDAP: Only increase the initgrTimestamp when the full initgroups DP request finishes
Action: opened
PR body:
"""
An initgroups request for an AD user consists of two parts - resolving the
AD user, which internally calls an LDAP request and adding the IPA external
group memberships. For (probably?) historical reasons from the time before
we had any notion of subdomains, the initgrTimestamp attribute is written
down at the LDAP request level when it finishes -- which means the
initgrTimestamp is written before the IPA external group membership is
evaluated.
When two requests for initgroups arrive semi-concurrently, it can happen
that the first request will trigger the whole machinery while the other one
would evaluate the initgrTimestamp attribute that was just bumped, but the
IPA group memberships were not yet written to the cache.
The result is that the second racing request only returns AD groups.
This fix removes writing the timestamp from the generic LDAP code and
instead writes the timestamp only when the Data Provider request fully
returns.
Resolves: https://pagure.io/SSSD/sssd/issue/3744
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/575/head:pr575
git checkout pr575
5 years, 10 months