On Mon, Apr 20, 2020 at 10:17:31AM -0400, James Cassell wrote: > > On Mon, Apr 20, 2020, at 10:09 AM, Andreas Hasenack wrote: > > Hi, > > > > I'm wondering why krb5_validate defaults to false in sssd-krb5, and > > apparently it's the same default in the mit kerberos libraries (via > > verify_ap_req_nofail). It should solve the KDC impersonation attack, > > at the expense of a slightly more complicated setup (create the host > > principal, extract key, create keytab). Is it because of this added > > difficulty in setting up things, or does it not work on very common > > scenarios/applications? Or just one of those hard to do transitions?
Hi, the main reason why krb5_validate is not enable by default in the krb5 auth provider is basically mentioned below, you need a keytab. Since for plain classical Kerberos authentication a host keytab is not needed and might even not be available the validation is off by default. When using the AD or IPA provider where a keytab is created while joining the domain validation is switched on by default. > > > > In my option, krb5_validate is broken. It chooses the name on first key in > the keytab to attempt validation, rather than either the newest or the one > matching ldap_sasl_authid (or an equivalent setting.) This causes issues > where a host may have previously had a service principal but it got > reassigned to another host, or due to renaming a host without removing the > old name from the keytab. (RH support considered it "not a bug.") I think the most straight forward solution here is to add a new option to give a principal which should be used for validation. ldap_sasl_authid is not strictly related, the LDAP code might even use a different keytab than libkrb5 would use for validation. In general /etc/krb5.keytab should only contain entries which are currently valid. Old entries especially with weak encryption types should be removed. E.g. sshd is using /etc/krb5.keytab for GSSAPI based authentication as well so attackers might be able to use information about the old tickets to get access to your system. bye, Sumit > > V/r, > James Cassell > _______________________________________________ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-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/sssd-users@lists.fedorahosted.org _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-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/sssd-users@lists.fedorahosted.org