[Freeipa-users] ldap_sasl_interactive_bind_s: Inappropriate authentication (48) - help debugging
Hello list.
I am trying to understand a reason for certificate-based authentication
failure to one of my directory servers.
A have 3 IPA replicas running on CentOS 7. After running yum update on
one of the nodes, PKI Tomcat failed to start. That system was not
updated for last year or so, so the problem might have existed earlier
and now was merely triggered by the update.
At first I suspected contents of /etc/pki/tomcat being wrong, however
that does not seem to be the case.
Trying to understand the issue, I decided to try to replicate the
authentication process "by hand":
I've set:
LDAPTLS_CACERTDIR="/etc/pki/pki-tomcat/alias"
LDAPTLS_CERT="NSS Certificate DB:subsystemCert cert-pki-ca"
However:
${NODE1}# ldapsearch -H ldaps://${NODE1}:636 -b "" -s base -Y EXTERNAL
-Q -LLL dn namingcontexts
ldap_sasl_interactive_bind_s: Inappropriate authentication (48)
additional info: missing client certificate
Interestingly, I _can_ authenticate this way to the other two nodes
(from the same node where authentication to a local dir server does not
work):
${NODE1}# ldapsearch -H ldaps://${NODE2}:636 -b "" -s base -Y EXTERNAL
-Q -LLL dn namingcontexts
dn:
namingcontexts: cn=changelog
namingcontexts: dc=infra,dc=linker,dc=shop
namingcontexts: o=ipaca
I don't understand what does "missing client certificate" mean in this
case, after all client configuration is identical, I am merely changing
the server to which I connect.
I've investigated the contents of /tmp/openldap-tlsmc*/*/*pem and it
seems to be correct (and same on all nodes), if I use ldapsearch -Y
EXTERNAL.
${NODE1}# openssl x509 -in /tmp/openldap-tlsmc-alias--*/cert.pem -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 228 (0xe4)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=xxx CN=Certificate Authority
Validity
Not Before: Jul 12 08:49:04 2022 GMT
Not After : Jul 1 08:49:04 2024 GMT
Subject: O=xxx, CN=CA Subsystem
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
...
I suspected that maybe replication is somehow messed up, but it seems to
be working:
${NODE1}# ipa-replica-manage list `hostname` -v
${NODE2}: replica
last update status: Error (0) Replica acquired successfully:
Incremental update succeeded
last update ended: 2023-05-30 14:21:10+00:00
${NODE3}: replica
last update status: Error (0) Replica acquired successfully:
Incremental update succeeded
last update ended: 2023-05-30 14:21:10+00:00
As I understand, the cert-pki-ca certificate and private key is shared
between the nodes and can be used to authenticate to any of directory
servers?
What can possibly be different in directory servers between these nodes,
which results in certificate authentication failing to one server, and
succeeding to another?
Any hints would be appreciated.
Best regards,
Radoslaw
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: sss_ssh_authorizedkeys vs user certificates
Hi.
On 9/23/21 15:06, Sumit Bose via FreeIPA-users wrote:
Am Thu, Sep 23, 2021 at 12:33:25PM +0200 schrieb Radoslaw Kujawa via
FreeIPA-users:
the keys are only derived form the certificate is the certificate can be
validated. Have you copied all needed CA certificates to the new machine
and made SSSD aware of it?
Indeed, it was a problem with validation. I've originally created a
symlink from /etc/sssd/pki/sssd_auth_ca_db.pem to /etc/ipa/ca.crt .
However, this resulted in SELinux denial:
time->Thu Sep 23 15:35:28 2021
type=AVC msg=audit(1632411328.296:280110): avc: denied { read } for
pid=110 comm="p11_child" name="sssd_auth_ca_db.pem" dev="nvme0n1p2"
ino=421 scontext=system_u:system_r:sssd_t:s0
tcontext=unconfined_u:object_r:sssd_conf_t:s0 tclass=lnk_file permissive=0
After copying the certificate, instead of symlinking it,
sss_ssh_authorizedkeys works correctly and reports public keys from
certificates too.
While here, I have a suggestion. Could ipa-client-install also add the
CA certificate to sssd's PKI directory?
Currently to make this useful functionality work, manual intervention is
necessary after running ipa-client-install (just having the cert in
/etc/ipa/ca.crt is not enough for p11_child to perform validation).
Best regards,
Radoslaw
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[Freeipa-users] sss_ssh_authorizedkeys vs user certificates
Hi list. I have a CentOS 8.4 machine (fully updated), where sss_ssh_authorizedkeys is successfully able to pull public keys from IPA user certificates. Recently I have installed a new Fedora 34 machine and this functionality is not working - running "sss_ssh_authorizedkeys username" only reports public keys explicitly added to the account, omitting keys from X.509 certificates. Both machines are joined to the same IPA domain. I've checked sssd configuration, and ssh_use_certificate_keys option seems to be default, as the man page states. To be extra sure, I have also manually added it sssd.conf: [ssh] ssh_use_certificate_keys = true CentOS machine has the following package versions: python3-sss-murmur-2.4.0-9.el8_4.2.x86_64 sssd-proxy-2.4.0-9.el8_4.2.x86_64 libsss_sudo-2.4.0-9.el8_4.2.x86_64 libsss_autofs-2.4.0-9.el8_4.2.x86_64 sssd-nfs-idmap-2.4.0-9.el8_4.2.x86_64 sssd-2.4.0-9.el8_4.2.x86_64 libsss_idmap-2.4.0-9.el8_4.2.x86_64 sssd-ldap-2.4.0-9.el8_4.2.x86_64 sssd-kcm-2.4.0-9.el8_4.2.x86_64 sssd-dbus-2.4.0-9.el8_4.2.x86_64 python3-cssselect-0.9.2-10.el8.noarch sssd-ipa-2.4.0-9.el8_4.2.x86_64 sssd-ad-2.4.0-9.el8_4.2.x86_64 python3-sssdconfig-2.4.0-9.el8_4.2.noarch sssd-krb5-2.4.0-9.el8_4.2.x86_64 sssd-tools-2.4.0-9.el8_4.2.x86_64 sssd-client-2.4.0-9.el8_4.2.x86_64 sssd-krb5-common-2.4.0-9.el8_4.2.x86_64 sssd-common-2.4.0-9.el8_4.2.x86_64 sssd-common-pac-2.4.0-9.el8_4.2.x86_64 libsss_certmap-2.4.0-9.el8_4.2.x86_64 libsss_nss_idmap-2.4.0-9.el8_4.2.x86_64 libsss_simpleifp-2.4.0-9.el8_4.2.x86_64 python3-sss-2.4.0-9.el8_4.2.x86_64 Fedora machine has the following package versions: libsss_idmap-2.5.2-2.fc34.aarch64 libsss_autofs-2.5.2-2.fc34.aarch64 libsss_sudo-2.5.2-2.fc34.aarch64 libsss_certmap-2.5.2-2.fc34.aarch64 sssd-nfs-idmap-2.5.2-2.fc34.aarch64 libsss_nss_idmap-2.5.2-2.fc34.aarch64 sssd-client-2.5.2-2.fc34.aarch64 sssd-common-2.5.2-2.fc34.aarch64 sssd-common-pac-2.5.2-2.fc34.aarch64 sssd-dbus-2.5.2-2.fc34.aarch64 sssd-krb5-common-2.5.2-2.fc34.aarch64 python3-sssdconfig-2.5.2-2.fc34.noarch python3-sss-2.5.2-2.fc34.aarch64 sssd-tools-2.5.2-2.fc34.aarch64 python3-sss-murmur-2.5.2-2.fc34.aarch64 sssd-ipa-2.5.2-2.fc34.aarch64 sssd-kcm-2.5.2-2.fc34.aarch64 Any hints on how to make sss_ssh_authorizedkeys pull keys from IPA user certificates on Fedora, or how to further debug this? Best regards, Radoslaw ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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/freeipa-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: Kerberos behaviour when OTP is used
Thank you for the thorough explanation! Best regards, Radoslaw On 11/7/20 8:45 PM, Alexander Bokovoy via FreeIPA-users wrote: On ke, 04 marras 2020, Radoslaw Kujawa via FreeIPA-users wrote: Hi list. I have 2FA enabled for many users in my organization, however some of these users work on their own private devices and manually run kinit to obtain the TGT. I was wondering why does kinit ask to: "Enter OTP Token Value: " This message is slightly confusing. In fact, the user is supposed to enter password+OTP here. I've attempted reading RFC 6560. If I understand correctly, OTP is not really supposed to be used as a 2nd factor with Kerberos? Let's say it is more of a design choice. There are several factors at play here. First, some of OTP methods require sharing the OTP value with the other side to perform validation. These need the value to be sent to KDC and it needs to be sent -- and bound to -- over an encrypted channel. Now, some of those encrypted channels might be subject for a MITM attack. RFC 6560 talks about one attack vector -- when using Anonymous PKINIT and not verifying the identity of the KDC. If you are able to verify identity of the KDC prior to building your encrypted channel, passing OTP value over it -- and using channel binding to the outer channel -- is fine. Consider SSSD case: it uses host keytab to establish FAST channel, verifying the KDC identity before the FAST channel is built. This is OK. You actually can use any other existing and valid ticket to create a FAST channel. It is just that there is none right now that would otherwise be used by an unprivileged client -- other than Anonymous PKINIT. In Anonymous PKINIT as your FAST case you need to verify the identity of the KDC somehow. This is hard as you either have something to trust around it or you simply have to trust. It would be great if a user process could rely on something like GSS-Proxy to involve it in acquiring a ticket to a user based on a FAST channel established by the privileged process (GSS-Proxy). This is not possible right now for a number of reasons, though: - GSS-Proxy interposes GSSAPI, not raw Kerberos, so kinit as a tool is out of question - GSSAPI doesn't have means to pass through multipile questions and answers between the client application and the mechanisms wrapped by the GSSAPI Technically, password+OTP can be given to a tool that uses GSSAPI and then interposed by GSS-Proxy to use host-based keytab as a FAST. There is, however, no way right now to enforce the use of this secret only to happen over a secure channel. Again, it is all possible to extend. We had discussed somewhat similar line of thoughts on #krbdev some time ago and sure, this all could be done. It just weren't, so far. Another minor trouble with BYOD setups is that the OTP user has to manually obtain anonymous ticket for FAST, before being able to run kinit. Interestingly, FAST is not required for Smart Card PKINIT to work. Smartcard PKINIT uses KDC certificate to build an exchange. You have to trust the certificate presented by KDC and the logic in MIT Kerberos PKINIT preauthentication module implements additional checks before it derives a session key to use. There is CA trust involved on both client and KDC sides, there is verification of the krbtgt/REALM@REALM principal SAN in the KDC-presented certificate or additional EKUs if the latter is missing. None of this is really a big problem, it's just troublesome to explain in one sentence "how does Kerberos authentication work in our organization". The 'holy grail' for solving this problem is to get multi-factor part of SPAKE preauthentication method to be finally specified and implemented. Right now we have single factor SPAKE in place, so we don't need to depend on the timestamp encryption as a pre-authentication anymore. With multi-factor SPAKE we wouldn't need to use FAST to establish an outer, encrypted, channel to pass what is essentially a plain-text data between the client and the KDC. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Kerberos behaviour when OTP is used
Hi list. I have 2FA enabled for many users in my organization, however some of these users work on their own private devices and manually run kinit to obtain the TGT. I was wondering why does kinit ask to: "Enter OTP Token Value: " This message is slightly confusing. In fact, the user is supposed to enter password+OTP here. I've attempted reading RFC 6560. If I understand correctly, OTP is not really supposed to be used as a 2nd factor with Kerberos? Another minor trouble with BYOD setups is that the OTP user has to manually obtain anonymous ticket for FAST, before being able to run kinit. Interestingly, FAST is not required for Smart Card PKINIT to work. None of this is really a big problem, it's just troublesome to explain in one sentence "how does Kerberos authentication work in our organization". Of course with Linux clients joined to the IPA domain, all of these details are abstracted by sssd and therefore a non-issue from the user's perspective. Best regards, Radoslaw ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Adding subjectAltName when the certificate is signed
Hi. On 10/12/20 3:05 AM, Fraser Tweedale via FreeIPA-users wrote: On Thu, Oct 08, 2020 at 10:03:03PM +0200, Radoslaw Kujawa via FreeIPA-users wrote: On 10/8/20 9:06 PM, Rob Crittenden via FreeIPA-users wrote: Radosław Kujawa via FreeIPA-users wrote: Is it possible to add email subjectAltName to a certificate when it is being signed by the IPA? How would the profile know what e-mail to add? These certificates are treated by IPA as "user certificates". The CN is set to IPA user's login. By some magic, IPA knows that such certificate should be added to LDAP object representing particular user. I hoped it would be possible to instruct it, to fetch the email attribute from LDAP object when signing the cert (based on the CN) and put it into subjectAltName. A modern enterprise PKI should be able to do it. But FreeIPA cannot. It's fundamentally possible but a lot of work to achieve it. I blogged about it several years ago: https://frasertweedale.github.io/blog-redhat/posts/2015-11-04-freeipa-pki-future.html For now, you must get the rfc822Name into the CSR's SAN extension, somehow. What tool are you using to generate those CSRs? Perhaps we can help find a way to do it. Long story short, the organization where I work have adopted Yubikeys as primary authentication method. This is working out well for us so far. Since we are already using IPA user certificates for PIV authentication, the thought appeared that we could use the same certs for S/MIME (at least Evolution appears to be able to successfully access the PIV cert on Yubikey to perform signing). The Yubikey "provisioning" process is currently self-service. Due to small size of organization (and the fact that currently most people work from home), it would be nice if it could stay this way. All users equipped with Yubikey have CA ACL that allows them to request certs using customized caIPAuserCert profile. Currently, from the user's perspective this is as simple as: $ yubico-piv-tool --key=$KEY -a generate -s 9a -A RSA2048 -o pub.pem $ yubico-piv-tool -a verify -a request -s 9a -P $PIN -S "/CN=$(whoami)/" -i pub.pem -o req.pem $ ipa cert-request --profile-id=caIPAuserCert --principal $(whoami) req.pem Then downloading the signed user certificate and running $ yubico-piv-tool --key=$KEY -a import-certificate -i cert.pem -s 9a Note that in this setup the private key is generated on the Yubikey and never leaves the device. The yubico-piv-tool -a request does not seem to have an option to add any kind of SAN to CSR. I know at least theoretically it is possible to generate the private key and CSR using openssl, then sign in IPA, and import the resulting private key and certificate onto Yubikey. However, from a security perspective, I see more opportunities for the user to mess up something here. One more doubt appears here. I obviously wouldn't want the user to sign a certificate with different email in CSR than appears in their own LDAP object... Best regards, Radoslaw ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Adding subjectAltName when the certificate is signed
Hi. On 10/8/20 9:06 PM, Rob Crittenden via FreeIPA-users wrote: Radosław Kujawa via FreeIPA-users wrote: Hi list. Is it possible to add email subjectAltName to a certificate when it is being signed by the IPA? How would the profile know what e-mail to add? These certificates are treated by IPA as "user certificates". The CN is set to IPA user's login. By some magic, IPA knows that such certificate should be added to LDAP object representing particular user. I hoped it would be possible to instruct it, to fetch the email attribute from LDAP object when signing the cert (based on the CN) and put it into subjectAltName. Best regards, Radoslaw ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Problem with smartcard login when otp is enabled
On 9/10/20 6:48 PM, Radoslaw Kujawa via FreeIPA-users wrote: I will coordinate with Jan to check if it is the same problem on his Ubuntu. Indeed, all of these problems boil down to a missing krb5-pkinit package. I was confused, because even though krb5-pkinit was missing, the Smart Card authentication _was_ working (when OTP was disabled). So it didn't occur to me that could be the cause. Best regards, Radoslaw ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Problem with smartcard login when otp is enabled
Hi. On 9/10/20 5:31 PM, Sumit Bose via FreeIPA-users wrote: just to be on the safe side, have you installed the krb5-pkinit package on Fedora 32? Sigh... the krb5-pkinit was somehow absent on Fedora 32. Thank you for help and sorry for the noise. Although, could SSSD somehow detect this situation? I mean, when Smart card credentials are present, but Kerberos PKINIT library is absent? An appropriate error message would save a lot of time spent on debugging this ;). I will coordinate with Jan to check if it is the same problem on his Ubuntu. Best regards, Radoslaw ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Problem with smartcard login when otp is enabled
Can you send the version of the krb5-libs package you are using on CentOS-8 and F32 as well? F32: krb5-libs-1.18.2-20.fc32.x86_64 CentOS 8: krb5-libs-1.17-18.el8.x86_64 Btw. I have downgraded SSSD to 2.2.3 on F32, but the problem persist. In my original email I have switched around SSSD versions used on CentOS and Fedora. But now I have the same version on both, so I guess my theory about it being a problem with SSSD could have been wrong: F32: sssd-2.2.3-13.fc32.x86_64 CentOS 8: sssd-2.2.3-20.el8.x86_64 Best regards, Radoslaw ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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/freeipa-users@lists.fedorahosted.org
