So, LDAPNOINIT, in theory, prevents it from reading ANY config files. You'll have to specify everything in a file and use LDAPRC.
BTW, LDAPRC is a basic filename that's in either the current directory or your home directory. I'd create one with a specific name, like ~/myldap.conf, then LDAPNOINIT=true LDAPRC=myldap.conf ldapsearch
See if you can tweak that myldap.conf to get it to work.
On Wed, Oct 9, 2013 at 12:30 PM, Jared list-389@legroom.net wrote:
I had tried that as well. You seem to be going down the line of thought I had last night. :-) Not sure why, but I can't get it to work at all with LDAPNOINIT=true whether the ~/.ldaprc file exists or not. Regardless of whatever other options I throw at it, I always get:
$ LDAPNOINIT=true LDAPTLS_REQCERT=allow ldapsearch -LLL -x -H ldaps://server.domain.com -D "<SNIP>" -w <SNIP> -b dc=domain,dc=com uid=user ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
I also tried this variant, with TLS_REQCERT=allow defined in a custom rc file:
$ LDAPNOINIT=true LDAPRC=.ldaprc-server ldapsearch -LLL -x -H ldaps://server.domain.com -D "<SNIP>" -w <SNIP> -b dc=domain,dc=com uid=user
but, LDAPNOINIT prevents the custom file from being sourced as well (which, in this case, is probably to be expected).
-- Jared
On 10/09/2013 02:01 PM, Chad Scott wrote:
Try:
LDAPNOINIT=true LDAPTLS_REQCERT=allow ldapsearch ...
On Wed, Oct 9, 2013 at 11:52 AM, Jared <list-389@legroom.net mailto:list-389@legroom.net> wrote:
Hi, Chad. Thanks for the suggestions. I actually did try your LDAPTLS_REQCERT=allow suggestion, but whenthe
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 <http://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 <http://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, butit
actually reads it *in addition* to ~/.ldaprc, which I discovered by examining strace output. There may be some cases where thisbehavior 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? -- Jared On 10/09/2013 01:26 PM, Chad Scott wrote: > Set environment variables. > > export LDAPTLS_REQCERT=allow > > or > > LDAPTLS_REQCERT=allow ldapsearch ... > > If neither of those work, specify a specific LDAPRC with: > > export LDAPRC=somefile.conf > > or > > LDAPRC=somefile.conf ldapsearch ... > > > On Wed, Oct 9, 2013 at 11:12 AM, Jared <list-389@legroom.net <mailto:list-389@legroom.net> > <mailto:list-389@legroom.net <mailto:list-389@legroom.net>>>wrote:
> > but I can. As I mentioned in my original post, adding this to ~/.ldaprc > or /etc/openldap/ldap.conf makes ldapsearch work perfectlyfine:
> > HOST server.domain.com <http://server.domain.com> <http://server.domain.com> > PORT 636 > TLS_REQCERT allow > > The problem is with applying this configuration to the one host while > still setting my default configuration for SASLcertificate-based
> authentication to everything else. How do I do that? > > or, to ask the question differently, forget the fact that I'm dealing > with an invalid cert. There's no need to to get hung up on that detail. > I have one ldaprc configuration that I need to define for a host, and a > default ldaprc configuration I need to define for all other hosts. How > do I make them work together? > > -- > Jared > > On 10/09/2013 01:06 PM, Michael Ströder wrote: > > Jared wrote: > >> expired and self-signed. > > > > You cannot work around expired certs. But in case ofself-signed
> certs you can > > put them into trusted CA certs file. > > > > Ciao, Michael. > > > >