1

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
  • 163
  • 1
  • 8
  • It is a bit of a battle getting ldapsearch to work with kerberos, everything has to be set just right from my experience. Have you tried using ldbsearch from the Samba ldb-tools package ? – Rowland Penny Jul 23 '23 at 09:22
  • 1
    Nice, this works much better, thanks! If you add this as an answer I can mark it answered – cqcallaw Jul 24 '23 at 01:10

2 Answers2

2

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 -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.)

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.

user1686
  • 10,162
  • 1
  • 26
  • 42
  • There's only one AD DC on this net, and its FQDN is known to me. The tip about rDNS proved useful indeed--turns out IPv4 reverse lookup was working, but IPv6 reverse lookup was not. Adding the correct reverse PTR records for the IPv6 DNS zone corrected ldapsearch's behavior – cqcallaw Jul 25 '23 at 22:29
  • @cqcallaw: I'd still recommend not relying on rDNS (for various reasons, including consistency with Windows, as well as Krb5 developers themselves recommending against it). If you know the FQDN, then just specify the FQDN in your LDAP URL. – user1686 Jul 26 '23 at 14:06
  • Yes, I was using the FQDN in my host URL already. That FQDN was somehow getting translated into the IPv6 address by ldapsearch or one of its dependencies (the later seems more likely). Fixing IPv6 reverse lookup changed the behavior. – cqcallaw Jul 27 '23 at 21:34
1

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
  • 163
  • 1
  • 8