Bug#1069858: libkrb5-3: krb5.conf seems to ignore rdns = false

[Russ Allbery]

Lukas Grässlin  writes:

> It's ldapsearch in all cases with libsasl2-modules-gssapi-mit:amd64
> 2.1.28+dfsg-10 on Debian and cyrus-sasl-gssapi-2.1.27-6.el8_5.x86_64 on
> the RHEL machine.

I suspect you are being bitten by:

https://web.mit.edu/Kerberos/krb5-devel/doc/admin/princ_dns.html#openldap-ldapsearch-etc

(at the bottom of the page), which is not under the control of the
Kerberos libraries.  It's a very long-standing issue in Cyrus SASL that
some of us used to patch locally.

-- 
Russ Allbery (r...@debian.org)  

Bug#1069858: libkrb5-3: krb5.conf seems to ignore rdns = false

[Lukas Grässlin]

On 26.04.2024 10:06, Lukas Grässlin wrote:

On 25.04.2024 23:25, Sam Hartman wrote:

How are you actually triggering the GSS-API authentication?
ldapsearch in all cases?
And you are confident that libkrb5 is triggering the reverse lookup not
your application?
(I realize that you may be using the same application on Debian and RH,
but there could be differences in the application code).


It's ldapsearch in all cases with libsasl2-modules-gssapi-mit:amd64 
2.1.28+dfsg-10 on Debian and cyrus-sasl-gssapi-2.1.27-6.el8_5.x86_64 on 
the RHEL machine.


However that ldapsearch is just the way we found most convenient to test 
it quickly. The actual trigger in real-life was a failing AD join with 
adcli


As a follow-up on this I just found out that Red Hat apparently indeed 
sets the following in their /etc/openldap/ldap.conf


# Turning this off breaks GSSAPI used with krb5 when rdns = false
SASL_NOCANONon

(https://bugzilla.redhat.com/show_bug.cgi?id=949864)

That's apparently that difference that still makes it fail on 
Debian/Ubuntu despite having "rdns = false" in Kerberos.


We might have to re-check the original issue with adcli, I guess that 
should not depend on ldapsearch but it's good to know now how to fix 
ldapsearch as well as we depend at other places on it as well.


So with these new infos it looks like it's not librb5 that ignores that 
option after all. I will do some re-checks but I have to thank you for 
the rubberducking, we were kinda stuck in a debugging tunnelvision there 
unfortunately.


Cheers
Lukas


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069858: libkrb5-3: krb5.conf seems to ignore rdns = false

[Lukas Grässlin]

On 25.04.2024 23:25, Sam Hartman wrote:

How are you actually triggering the GSS-API authentication?
ldapsearch in all cases?
And you are confident that libkrb5 is triggering the reverse lookup not
your application?
(I realize that you may be using the same application on Debian and RH,
but there could be differences in the application code).


It's ldapsearch in all cases with libsasl2-modules-gssapi-mit:amd64 
2.1.28+dfsg-10 on Debian and cyrus-sasl-gssapi-2.1.27-6.el8_5.x86_64 on 
the RHEL machine.


However that ldapsearch is just the way we found most convenient to test 
it quickly. The actual trigger in real-life was a failing AD join with adcli


I can't 100% confidently say the reverse lookup is actually made by 
libkrb5 itself. It very well may from somewhere else, it's just the only 
pointer I got from looking at the behaviour.


We actually found out the customer has some other AD DCs which do NOT 
have that second PTR record to emea.example.com. If we explicitely use 
one of those everything is working as expected. Also same effect if we 
just force-override the DC hostname in /etc/hosts. That at least kinda 
confirmed to me it is probably reverse DNS related.


Cheers
Lukas


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069858: libkrb5-3: krb5.conf seems to ignore rdns = false

[Sam Hartman]

> "Lukas" == Lukas Grässlin  writes:

Lukas> We have a scenario where we need to disable reverse lookups for 
Lukas> canonicalization in Kerberos as the customer's PTR records are not 
Lukas> consistent and lead to wrongly requested SPNs otherwise (see 
Lukas> 
https://web.mit.edu/kerberos/krb5-latest/doc/admin/princ_dns.html#reverse-dns-mismatches)

How are you actually triggering the GSS-API authentication?
ldapsearch in all cases?
And you are confident that libkrb5 is triggering the reverse lookup not
your application?
(I realize that you may be using the same application on Debian and RH,
but there could be differences in the application code).

Bug#1069858: libkrb5-3: krb5.conf seems to ignore rdns = false

[Lukas Grässlin]

Package: libkrb5-3 


Version: 1.20.1-2+deb12u1
Severity: normal
X-Debbugs-Cc: lukas.graess...@adfinis.com

We have a scenario where we need to disable reverse lookups for 
canonicalization in Kerberos as the customer's PTR records are not 
consistent and lead to wrongly requested SPNs otherwise (see 
https://web.mit.edu/kerberos/krb5-latest/doc/admin/princ_dns.html#reverse-dns-mismatches)


Therefore we have set "rdns = false" in /etc/krb5.conf as follows:

# cat /etc/krb5.conf

[libdefaults]
udp_preference_limit = 0
default_realm = EMEA.EXAMPLE.COM
rdns = false

However this setting seems to get ignored for some reason. I tried to do 
some debugging and comparisons as we don't have the same issue for 
example on a RHEL8 (using krb5-libs-1.18.2-26.el8_9.x86_64) machine.


On those RHEL machines the setting seems to do exactly what it's 
supposed to, in fact I can reproduce the issue we have on Ubuntu on RHEL 
as well if I remove the "rdns = false" line from the configuration.


Kerberos authentication (in our test we use a simple ldapsearch with 
GSSAPI auth) fails then randomly as it sometimes gets a wrong SPN due to 
using a wrong PTR for canonicalization.


On our Ubuntu 22.04 LTS (with libkrb5-3:amd64 1.19.2-2ubuntu0.3) however 
the setting does not seem to have any effect. I then re-did the same 
test with Debian oldstable, stable and sid as well, all with the exact 
same result.


I actually ran a tcpdump while trying to do a Kerberos auth with the 
"rdns = false" setting in place and I can still see the reverse lookup 
being performed in the tcpdump (I anonymized some things so don't get 
confused about the IPs):


10:47:58.382684 IP 1.2.3.4.55001 > 123.123.123.123.53: 12962+ [1au] A? 
domaincontroller01.emea.example.com. (55)
10:47:58.382809 IP 1.2.3.4.37669 > 123.123.123.123.53: 38376+ [1au] 
? domaincontroller01.emea.example.com. (55)

10:47:58.412041 IP 123.123.123.123.53 > 1.2.3.4.37669: 38376* 0/1/1 (143)
10:47:58.412564 IP 123.123.123.123.53 > 1.2.3.4.55001: 12962* 1/9/10 A 
5.6.7.8 (602)
10:47:58.442326 IP 1.2.3.4.51232 > 123.123.123.123.53: 16995+ [1au] PTR? 
8.7.6.5.in-addr.arpa. (55)
10:47:58.471669 IP 123.123.123.123.53 > 1.2.3.4.51232: 16995 2/2/3 PTR 
emea.example.com., PTR DOMAINCONTROLLER.emea.example.com. (238)


As you see there it does the PTR lookup and retrieves two entries 
(emea.example.com and DOMAINCONTROLLER.emea.example.com)


If I do the same test on the RHEL8 machine I can actually see in tcpdump 
that with the "rdns = false" setting the reverse lookup is correctly NOT 
performed.


I am a bit puzzled why this is the case as I have not seen other people 
reporting it (maybe everyone else has their reverse DNS under control 
;)) even though as said in a quick test I was also able to get the same 
wrong result with multiple Debian releases and the mentioned Ubuntu release.


The only thing I've found in the past where this exact issue was 
mentioned was many years ago: 
https://mailman.mit.edu/pipermail/krb5-bugs/2011-June/008684.html


However this has been fixed ever since. I have not done yet any actual 
code comparison with the version that RHEL uses, also I'm not sure if 
the issue actually really exists in libkrb5 itself or if it might be a 
sideeffect from some other lib.


How to reproduce on your own:
Even if you don't have erroneous reverse DNS entries you could still try 
to reproduce it by just looking at tcpdump and checking if you see 
reverse lookups performed with and without the option.


-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-15-generic (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash

Versions of packages libkrb5-3 depends on:
ii  libc62.36-9+deb12u6
ii  libcom-err2  1.47.0-2
ii  libk5crypto3 1.20.1-2+deb12u1
ii  libkeyutils1 1.6.3-2
ii  libkrb5support0  1.20.1-2+deb12u1
ii  libssl3  3.0.11-1~deb12u2

Versions of packages libkrb5-3 recommends:
ii  krb5-locales  1.20.1-2+deb12u1

Versions of packages libkrb5-3 suggests:
pn  krb5-doc   
ii  krb5-user  1.20.1-2+deb12u1

-- no debconf information


OpenPGP_signature.asc
Description: OpenPGP digital signature