2

An answer exists for querying AD with password auth, which is working fine locally. What about Kerberos auth? Running ldapsearch with GSSAPI auth yields the following error:

$ ldapsearch -ZZ -Y GSSAPI -H ldap://ad.server.fqdn/ -b "CN=Caleb,CN=Users,DC=samdom,DC=example,DC=com" cn
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind: Local error (-2)
    additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Server not found in Kerberos database)
$

On the Samba AD DC, this shows in the log file:

...
Kerberos: TGS-REQ caleb@SAMDOM.EXAMPLE.COM from ipv4:<client IP address>:48092 for ldap/<server IP>@SAMDOM.EXAMPLE.COM [canonicalize, renewable]
...

The ticket request is for the DC's IP instead of the server's FQDN, which is clearly incorrect; the server's FQDN is shown in the SPN entries, as it should be. But how do I correct it?

I see this issue even with a minimal krb5.conf

[libdefaults]
    default_realm = SAMDOM.EXAMPLE.COM
cqcallaw
  • 183

2 Answers2

3

You won't be able to retrieve Kerberos tickets for the shared ad.server.fqdn alias – only the individual DC FQDNs are known to the Kerberos KDC, and they are not interchangeable (each has its own Kerberos keys). So normally you'd need a two-step process: first look up the DC names via DNS SRV records, then tell ldapsearch to query a specific DC by its name.

For example:

  1. dig +short -t srv _ldap._tcp.ad.example.com
  2. ldapsearch -H ldaps://dc01.ad.example.com -N -Y GSS-SPNEGO

(...I admit that I don't exactly remember whether Active Directory creates _ldap._tcp SRV records by default – though I do have them here with Samba – or whether you have to look at _kerberos._udp instead.)

Using the shared alias may sometimes happen to work due to Unix Kerberos performing canonicalization via reverse-DNS, but it's not something to rely on – when you have more than one DC behind the alias, it may often happen that libldap connects to server A, yet requests tickets for server B. (Whenever that happens, you get mysterious "KRB_AP_ERR_MODIFIED" errors, which really just means "key mismatch" in this case.)

[Edit: Added the -N option to disable the forced rDNS canonicalization in ldapsearch.]

Besides that, Windows doesn't do rDNS-based canonicalization at all, and Linux distros have started disabling it as well (although libldap forcefully re-enables it...), and the IP-based TGS-REQ in your logs indicates that you don't have working rDNS anyway.

Note that in most distributions, the system-wide Kerberos library is provided by MIT Kerberos whereas Samba's tools such as 'ldbsearch' are built against [its vendored copy of] Heimdal Kerberos, so the two may have slightly different behavior regarding name canonicalization.

grawity
  • 17,092
2

For completeness, aggregating solutions here. Thanks to Rowland Penny and user1686 for their help!

  1. Use ldbsearch. Example invocation:
ldbsearch -H dap://ad.server.fqdn/ -b "CN=Caleb,CN=Users,DC=samdom,DC=example,DC=com" cn
  1. Fix reverse DNS lookup (in my case IPv6 rDNS) and continue using ldapsearch. Don't require TLS or SASL will complain:
ldapsearch -Y GSSAPI -H ldap://ad.server.fqdn/ -b "CN=Caleb,CN=Users,DC=samdom,DC=example,DC=com" cn
cqcallaw
  • 183