Comment 7 for bug 1777776

Thanks Andreas,

I am not an expert either on kerberos or on security - I know enough to be able to spot and verify a problem, but not enough to verify a sufficient solution, so take what I way with that caveat in mind.

The section you have written seems reasonable, and that is indeed the main attack model I had in mind, although I think that not including the krb5_validate flag in the example configurations above is dangerous. I presume (but don't have the setup to test) that AD setups have the same problem, and it is not obvious to someone doing the AD setup that this section applies to them too.

I don't think there is any scenario where someone would want to use kerberos, but would not want this flag set. One could say that it requires more setup because you have to have the keytab file, but there is no point in using kerberos in the first place if you are not going to use it for something other than local authentication (e.g. nfs), for which you will need the keytab file anyway (as far as I understand). So you remove a trivial to exploit vulnerability at basically no effort by including this flag.

Also, somewhat off-topic but probably very relavent for this sssd guide - bug 1723350 mentioned above means that the described configurations won't reliably survive rebooting the computer, so a reference to the workaround in that bug description could save people lots of time and frustration.

Also slightly off topic, in the section "SSL support is recommended, but not strictly necessary because authentication in this setup is being done via Kerberos, and not LDAP." I think ssl is needed as while user authentication is done through kerberos, group authentication is done based on what groups the user is in, which comes from LDAP, so an attacker on the local network could give themselves group permission for any group if the LDAP traffic is unencrypted. Or change the group for some other user to write as by default to some world readable group.