Hi, Chad. Thanks for the suggestions.
I actually did try your LDAPTLS_REQCERT=allow suggestion, but when the existing ~/.ldaprc is in place (with the TLS_REQCERT=demand line), that option seems to be ignored for some reason. I don't know why.
To illustrate:
$ cat ~/.ldaprc TLS_CERT /home/ldap/certs/admin.crt TLS_KEY /home/ldap/certs/admin.key TLS_REQCERT demand SASL_MECH external
$ LDAPTLS_REQCERT=allow ldapsearch -LLL -x -H ldaps://server.autozone.com -D "<SNIP>" -w <SNIP> -b dc=domain,dc=com uid=user ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
$ mv ~/.ldaprc ~/.ldaprc-old
$ LDAPTLS_REQCERT=allow ldapsearch -LLL -x -H ldaps://server.autozone.com -D "<SNIP>" -w <SNIP> -b dc=domain,dc=com uid=user dn: uid=user,ou=people,dc=domain,dc=com uid: user <SNIP>
It seems like the ~/.ldaprc file is overriding what I specify on the command line, but as I mentioned before, I *have* to have that global configuration there for all of the other LDAP server this account interacts with.
Likewise, I did try messing with the LDAPRC variable. I actually mentioned that in my original post:
* Creating a separate ~/.ldaprc-server file and exporting LDAPRC=.ldaprc-server - in this case, both ~/.ldaprc AND ~/.ldaprc-server are sourced (found using strace), so again my host-specific settings are ignored.
I'd consider that a bug in ldapsearch - if I'm explicitly defining LDAPRC, I'd expect it to ready that file *instead* of ~/.ldaprc, but it actually reads it *in addition* to ~/.ldaprc, which I discovered by examining strace output. There may be some cases where this behavior is desired, but in this case, it causes my global configuration to (apparently) again take precedence, overriding the TLS_REQCERT=allow setting.
Any other suggestions?