> On 18 Dec 2020, at 23:41, Julien Rische <julien.rische@xxxxxxx> 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@xxxxxxxxxxx > 1 06/30/2020 10:24:28 ldap/ipa01.example.net@xxxxxxxxxxx > 1 06/30/2020 11:18:43 ldap/ldap.example.net@xxxxxxxxxxx > 1 06/30/2020 11:18:43 ldap/ldap.example.net@xxxxxxxxxxx > > 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@xxxxxxxxxxx->ldap/ldap.example.net@xxxxxxxxxxx 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@xxxxxxxxxxx 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@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@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, > > Julien Rische > CERN > > > [1] https://directory.fedoraproject.org/docs/389ds/howto/howto-loadbalance-gssapi.html > _______________________________________________ > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
