> On 18 Dec 2020, at 23:41, Julien Rische <julien.ris...@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....@example.net > 1 06/30/2020 10:24:28 ldap/ipa01.example....@example.net > 1 06/30/2020 11:18:43 ldap/ldap.example....@example.net > 1 06/30/2020 11:18:43 ldap/ldap.example....@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 m...@example.net->ldap/ldap.example....@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....@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@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@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 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@lists.fedoraproject.org