Bug 245623 - infinite growth of krb5cc while requesting data from trusted domain
Summary: infinite growth of krb5cc while requesting data from trusted domain
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 11.3-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-14 19:46 UTC by bugs.freebsd.org
Modified: 2020-06-20 05:28 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bugs.freebsd.org 2020-04-14 19:46:30 UTC
I have 2 AD domains with mutual trust relationship, 'main.local' & 'trusted.local'.

There is keytab issued for server@main.local.

> kinit -t "${keytab_file}" "server@main.local"

> klist
Credentials cache: FILE:/ram-disk/krb5cc
        Principal: SERVER@MAIN.LOCAL

  Issued                Expires               Principal
Apr 14 19:24:10 2020  Apr 15 05:24:10 2020  krbtgt/MAIN.LOCAL@MAIN.LOCAL


Now repeat command below several times:
> ldapsearch -o ldif-wrap=no -LLL -h main.local -Q -Y GSSAPI -b "dc=main,dc=local" "(cn=guest)" cn

dn: CN=Guest,CN=Users,DC=main,DC=local
cn: Guest

# refldap://ForestDnsZones.main.local/DC=ForestDnsZones,DC=main,DC=local

# refldap://DomainDnsZones.main.local/DC=DomainDnsZones,DC=main,DC=local

# refldap://main.local/CN=Configuration,DC=main,DC=local



> klist
Credentials cache: FILE:/ram-disk/krb5cc
        Principal: SERVER@MAIN.LOCAL

  Issued                Expires               Principal
Apr 14 19:24:10 2020  Apr 15 05:24:10 2020  krbtgt/MAIN.LOCAL@MAIN.LOCAL
Apr 14 19:25:49 2020  Apr 15 05:24:10 2020  ldap/dc.MAIN.local@MAIN.LOCAL

It's ok.



And now repeat same command, but for trusted domain:
> ldapsearch -o ldif-wrap=no -LLL -h trusted.local -Q -Y GSSAPI -b "dc=trusted,dc=local" "(cn=guest)" cn
dn: CN=Guest,CN=Users,DC=trusted,DC=local
cn: Guest

# refldap://ForestDnsZones.trusted.local/DC=ForestDnsZones,DC=trusted,DC=local

# refldap://DomainDnsZones.trusted.local/DC=DomainDnsZones,DC=trusted,DC=local

# refldap://trusted.local/CN=Configuration,DC=trusted,DC=local

> klist
Credentials cache: FILE:/ram-disk/krb5cc
        Principal: SERVER@MAIN.LOCAL

  Issued                Expires               Principal
Apr 14 19:24:10 2020  Apr 15 05:24:10 2020  krbtgt/MAIN.LOCAL@MAIN.LOCAL
Apr 14 19:25:49 2020  Apr 15 05:24:10 2020  ldap/dc.MAIN.local@MAIN.LOCAL
Apr 14 19:30:41 2020  Apr 15 05:24:10 2020  krbtgt/TRUSTED.LOCAL@MAIN.LOCAL
Apr 14 19:30:42 2020  Apr 15 05:24:10 2020  ldap/dc.TRUSTED.local@TRUSTED.LOCAL
Apr 14 19:30:43 2020  Apr 15 05:24:10 2020  krbtgt/TRUSTED.LOCAL@MAIN.LOCAL
Apr 14 19:30:42 2020  Apr 15 05:24:10 2020  ldap/dc.TRUSTED.local@TRUSTED.LOCAL
Apr 14 19:30:43 2020  Apr 15 05:24:10 2020  krbtgt/TRUSTED.LOCAL@MAIN.LOCAL
Apr 14 19:30:42 2020  Apr 15 05:24:10 2020  ldap/dc.TRUSTED.local@TRUSTED.LOCAL
Apr 14 19:30:44 2020  Apr 15 05:24:10 2020  krbtgt/TRUSTED.LOCAL@MAIN.LOCAL
Apr 14 19:30:42 2020  Apr 15 05:24:10 2020  ldap/dc.TRUSTED.local@TRUSTED.LOCAL
Apr 14 19:30:44 2020  Apr 15 05:24:10 2020  krbtgt/TRUSTED.LOCAL@MAIN.LOCAL
Apr 14 19:30:42 2020  Apr 15 05:24:10 2020  ldap/dc.TRUSTED.local@TRUSTED.LOCAL

Every time command run, new two records in cache add. This causes more and more slowly operation.
Comment 1 Benjamin Kaduk freebsd_committer 2020-06-08 02:42:36 UTC
What krb5 implementation is ldapsearch linked to?  MIT krb5 from ports, heimdal from base, or heimdal from ports?
E.g., `ldd $(which ldapsearch)` would be enough to tell.
Comment 2 bugs.freebsd.org 2020-06-08 05:50:39 UTC
There is no Kerberos packages or ports installed, so use heimdal from base.


sh -c 'ldd $(which ldapsearch)'
/usr/local/bin/ldapsearch:
        libldap-2.4.so.2 => /usr/local/lib/libldap-2.4.so.2 (0x800836000)
        liblber-2.4.so.2 => /usr/local/lib/liblber-2.4.so.2 (0x800a83000)
        libsasl2.so.3 => /usr/local/lib/libsasl2.so.3 (0x800c92000)
        libssl.so.8 => /usr/lib/libssl.so.8 (0x800eb0000)
        libcrypto.so.8 => /lib/libcrypto.so.8 (0x801200000)
        libfetch.so.6 => /usr/lib/libfetch.so.6 (0x801676000)
        libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x801889000)
        libc.so.7 => /lib/libc.so.7 (0x801a8b000)
        libdl.so.1 => /usr/lib/libdl.so.1 (0x801e46000)
Comment 3 Benjamin Kaduk freebsd_committer 2020-06-13 19:40:50 UTC
The heimdal in base is pretty old, and I wouldn't be surprised if the behavior was different with a newer heimdal.  Are you in a position to try using heimdal from ports (security/cyrus-sasl2-gssapi with GSSAPI_HEIMDAL) or MIT krb5?
Comment 4 bugs.freebsd.org 2020-06-17 17:02:31 UTC
Possibly this is right.

I've tried ldapsearch with MIT KRB5 on FreeBSD12 and there is no such issue.
Comment 5 Benjamin Kaduk freebsd_committer 2020-06-20 05:28:48 UTC
I created https://github.com/heimdal/heimdal/issues/732 on upstream heimdal's bugtracker to ask if anyone remember something in this area having already been fixed.