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 <[email protected]> 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 <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> >     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 <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, 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?
> >
> >     --
> >     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 <[email protected]
> >     <mailto:[email protected]>
> >     > <mailto:[email protected] <mailto:[email protected]>>>
> wrote:
> >     >
> >     >     but I can.  As I mentioned in my original post, adding this to
> >     ~/.ldaprc
> >     >     or /etc/openldap/ldap.conf makes ldapsearch work perfectly
> fine:
> >     >
> >     >     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 SASL
> certificate-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 of
> self-signed
> >     >     certs you can
> >     >     > put them into trusted CA certs file.
> >     >     >
> >     >     > Ciao, Michael.
> >     >     >
> >     >
> >     >
> >
> >
>
>

Reply via email to