Client keytab realm mismanagement #4537
Comments
frozencemetery
added a commit
to frozencemetery/389-ds-base
that referenced
this issue
Jan 12, 2021
Bug description: set_krb5_creds() creates a principal with an empty string for a realm, and assumes this will function as a wildcard. However, this behavior is not a guarantee that krb5 provides; dependent on canonicalization settings, it could result in later failures in SASL. Fix description: Remove set_krb5_creds(). Previously, this function existed in order to treat the keytab at KRB5_KTNAME as a source of initiator credentials. However, since krb5-1.11, there is a separate environment variable KRB5_CLIENT_KTNAME that provides this functionality. In the process, remove the unused Heimdal vestiges. In 773e898 , the semantics of HAVE_KRB5 were changed to refer to specifically MIT krb5. As a result, none of the Kerberos goo has run against Heimdal since then. When Heimdal has a feature release, it will also support KRB5_CLIENT_KTNAME, and so this code will work with it too. relates: 389ds#4537 Author: Robbie Harwood <rharwood@redhat.com> Review by: @Firstyear, @mreynolds389, @droideck (Thanks!)
Merged
Firstyear
pushed a commit
that referenced
this issue
Jan 12, 2021
Bug description: set_krb5_creds() creates a principal with an empty string for a realm, and assumes this will function as a wildcard. However, this behavior is not a guarantee that krb5 provides; dependent on canonicalization settings, it could result in later failures in SASL. Fix description: Remove set_krb5_creds(). Previously, this function existed in order to treat the keytab at KRB5_KTNAME as a source of initiator credentials. However, since krb5-1.11, there is a separate environment variable KRB5_CLIENT_KTNAME that provides this functionality. In the process, remove the unused Heimdal vestiges. In 773e898 , the semantics of HAVE_KRB5 were changed to refer to specifically MIT krb5. As a result, none of the Kerberos goo has run against Heimdal since then. When Heimdal has a feature release, it will also support KRB5_CLIENT_KTNAME, and so this code will work with it too. relates: #4537 Author: Robbie Harwood <rharwood@redhat.com> Review by: @Firstyear, @mreynolds389, @droideck (Thanks!)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue Description
set_krb5_creds()creates a principal with an empty string ("") for a realm and expects this to function as a wildcard. This was not the intent of krb5, and depending on DNS canonicalization settings, it may not work.Package Version and Platform:
Steps to Reproduce
Steps to reproduce the behavior:
Expected results
Successful replica installation. Instead, replication will fail due to principal not being found.
Screenshots
N/A
Additional context
Downstream, this is https://bugzilla.redhat.com/show_bug.cgi?id=1868482
The text was updated successfully, but these errors were encountered: