On Tue, Apr 21, 2020, at 4:30 AM, Sumit Bose wrote: > 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. >
I agree having a separate option for configuration here would be useful. I'd never considered that ldap might use a different keytab than kerberos. I wonder why that might be done? > 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. > I agree in principle. Practice is harder, especially when dealing with hundreds of legacy systems... If there's a good/easy way to audit keytabs for weak encryption types, it might be worth pursuing... otherwise, I'll pray that FIPS mode saves the day :P 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
