> 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

Reply via email to