On 18 Dec 2020, at 23:41, Julien Rische <julien.rische(a)cern.ch>
wrote:
Hi all,
We are working on a FreeIPA infrastructure, but we are facing an issue regarding GSSAPI
authentication against 389ds. Our infrastructure is currently moving from enabled to
disabled reverse DNS resolution on Kerberos clients. We are also using load-balanced DNS
aliases and, as a consequence, nodes of distributed services must provide keys for both a
canonical service principal and a localhost service principal.
This setup is similar to the one commonly used for HA proxies, which is described in the
389ds' documentation[1].
We configured the keytab accordingly (
ipa01.example.net is the FreeIPA node and
ldap.example.net is the load-balanced alias):
KVNO Timestamp Principal
---- ------------------- ------------------------------------------------------
1 06/30/2020 10:24:28 ldap/ipa01.example.net(a)EXAMPLE.NET
1 06/30/2020 10:24:28 ldap/ipa01.example.net(a)EXAMPLE.NET
1 06/30/2020 11:18:43 ldap/ldap.example.net(a)EXAMPLE.NET
1 06/30/2020 11:18:43 ldap/ldap.example.net(a)EXAMPLE.NET
SASL/GSSAPI authentication works when connecting to
ipa01.example.net, or
ldap.example.net but only if [libdefaults].rdns=true in /etc/kbr5.conf. When rDNS
resolution is disabled, authentication doesn't work any more:
$ ldapwhoami -QY GSSAPI -H
ldaps://ldap.example.net
ldap_sasl_interactive_bind_s: Invalid credentials (49)
Can you use:
KRB5_TRACE=/dev/stderr ldapwhoami -QY GSSAPI -H
ldaps://ldap.example.net &>
/tmp/out
And provide that output?
The ticket me@EXAMPLE.NET->ldap/ldap.example.net(a)EXAMPLE.NET is in the ccache, but
389ds rejects it even though the matching key is available in its keytab.
It seems 389ds is checking the incoming ticket against the "nsslapd-localhost"
parameter, and rejects it if they are not matching:
dn: cn=config
nsslapd-localhost:
ipa01.example.net
Setting "nsslapd-localhost" to "ldap.example.net" fixed this issue,
but it causes authentication to ldap/ipa01.example.net(a)EXAMPLE.NET to stop working. Also
it is not possible to have multiple "nsslapd-localhost" entries.
Is there a way to disable checking against "nsslapd-localhost" to allow
authentication against any key from the configured keytab (we use 389ds version 1.3.10.2)?
I'm not really sure what's going on here, but I think it's likely it's not
in 389 as much as krb. You could also do a systemd override with:
systemctl edit dirsrv(a)ipainstancename.service
And then set:
[Service]
Environment="KRB5_TRACE=/dev/stderr"
Which will then cause extended KRB5 debugging to be emitted to journald, which you can
check with:
journalctl -n 1000 -u dirsrv(a)ipainstancename.service
I think both of these outputs will probably help you understand the real cause of the krb
issues here as I wrote the original haproxy + krb guide and did confirm it's possible
to make it work, so I suspect something else is going on in krb land.
Hope that helps,
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia