Thanks, I'll try this when I get a chance and report back.

On Thu, Jan 30, 2014 at 11:43 AM, Warron S French
<[email protected]>wrote:

> Low Sensitivity/Aerospace Internal Use Only
>
> Low Sensitivity/Aerospace Internal Use Only
>
> Joshua, were you able to get TLS configured and your clients were
> specifically Debian?  I ask, because my clients were CentOS which is
> downstream from Red Hat.
>
> Try using ldapmodify with -v and -d ## set along with the other arguments
> and syntax; do you still see no more verbosity?  I did, I wonder if you
> will see what I discovered.
>
> I ran the following command:
>
> *ldapmodify    -x     -D "cn=admin,cn=config" -W -d 32768 -f
> /tmp/LDAP-CONFIG-TLS.ldif*
>
> However, I was also running *slapd *with *-d 32768* as an argument as
> well.  I don't know if it makes any difference, but I was not using GnuTLS,
> but OpenSSL.
>
>
>
> *Warron French, MBA, SCSA*
>
>
>
> From:        Joshua Schaeffer <[email protected]>
> To:        c chupela <[email protected]>,
> Cc:        "[email protected]" <
> [email protected]>
> Date:        01/30/2014 12:05 PM
> Subject:        Re: Antw: problem with accessing secure ldap
> Sent by:        [email protected]
> ------------------------------
>
>
>
> I think I'm running into this right now.  I just setup ldaps a couple days
> ago, but I can't get any of my clients to connect to it.  I can see my
> openldap server listening on port 636 and I can telnet to that server and
> port from another machine successfully, but I still get this error:
>
> ldap_sasl_bin(SIMPLE): Can't contact LDAP server (-1)
>
> the verbose option doesn't give me much more useful information than that.
>  I have a hunch that it has to do with the certificates, but I'm using
> GnuTLS as I'm on Debian and the slapd package since lenny is only compiled
> against GnuTLS.  What was the command you ran to get this output?
>
>
> On Thu, Jan 30, 2014 at 9:09 AM, c chupela 
> <*[email protected]*<[email protected]>>
> wrote:
> further troubleshooting on my part with ldapsearch/debugging turned up,
> gave me the following:
>
> TLS: certdb config: configDir='/etc/openldap/certs'
> tokenDescription='ldap(0)' certPrefix=" keyPrefix=" flags=readOnly
> TLS: using moznss security dire /etc/openldap/certs prefix
> TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory
> TLS: error: connect - force handshake failure: errono 21 - moznss error
> -5938
> TLS: can't connect: TLS error -5938:Encountered end of file
> ldap_err2string
> ldap_sasl_bin(SIMPLE): Can't contact LDAP server (-1)
>
> searches I;ve done on this error seem to point to certificate/openSSL
> problems.
>
> Anyone run into this before?
>
>
>
>
>
> On Friday, January 24, 2014 5:39 PM, c chupela 
> <*[email protected]*<[email protected]>>
> wrote:
> After having some packet traces done, what was revealed is that from a
> windows client running the softerra ldap browser, we could see the
> connection be established between client and server (syn, ack synack)
> client requests sending of data, and server resets/closes the connection,
> never sending any data,  as I also saw with attempting to telnet to port
> 636 - connection is closed by remote host.
>
> Regarding the question of is TLS enabled, if I understand the doc
> correctly, the answer is yes.  With respect to the TLS_REQCERT never
> statement, I believe it was set this way because this was only intended to
> be a testing server.
>
> contents of ldap.conf:
>
> #
> # LDAP Defaults
> #
>
> # See ldap.conf(5) for details
> # This file should be world readable but not world writable.
>
> BASE    dc=plandb,dc=stuff,dc=acme,dc=com
> URI     
> ldap://*plandb-qa.stuff.acme.com*<http://plandb-qa.stuff.acme.com/>ldaps://
> *plandb-qa.stuff.acme.com:636* <http://plandb-qa.stuff.acme.com:636/>
>
> #SIZELIMIT      12
> #TIMELIMIT      15
> #DEREF          never
>
> TLS_CACERTDIR   /etc/openldap/certs
> TLS_REQCERT     never
>
>
> currently running slapd process:
>
> 1 S ldap      5603     1  0  80   0 - 111440 futex_ Jan21 ?       00:00:02
> /usr/sbin/slapd -h  ldap:/// ldaps:/// ldapi:/// -u ldap
>
>
> On Thursday, January 23, 2014 3:25 AM, Ulrich Windl <
> *[email protected]* <[email protected]>>
> wrote:
> >>> c chupela <*[email protected]* <[email protected]>> schrieb am
> 22.01.2014 um 18:43 in Nachricht
> <*[email protected]*<[email protected]>
> >:
> > I've been tasked with figuring out why a redhat 6.4 server w/openldap
> v2.4.23
> > is not accessible.
> > This server is a test server. I have a production server that is working
> > properly, and I've gone thru and compared config files, etc, but haven't
> > found any differences.
> >
> >  I'm a newbie with this, so my understanding is still somewhat limited.
> > Here's what I've done or checked so far:
> >
> > - iptables is not running
> > - if I run netstat, I can see port 389/port 636 in listening state:
> >
> > tcp        0      0 *0.0.0.0:636* <http://0.0.0.0:636/>
> 0.0.0.0:*
> > LISTEN      5603/slapd
> > tcp        0      0 *0.0.0.0:389* <http://0.0.0.0:389/>
> 0.0.0.0:*
> > LISTEN      5603/slapd
> > tcp        0      0 :::636                      :::*
>
> > LISTEN      5603/slapd
> > tcp        0      0 :::389                      :::*
>
> > LISTEN      5603/slapd
> >
> > I can telnet to port 389 on this server from another server, but not to
> port
> > 636 - putty will throw back an immediate 'connection closed by remote
> host'
> > message.
> >
> > I'm not seeing any slapd related messages in /var/log/messages.
> >
> > What else can I check on here?
>
> Syslog
>
>
> >
> > Thanks
> > Chris
>
>
>
>
>
>
>
>
>
>
>
> Low Sensitivity/Aerospace Internal Use Only
>
> Low Sensitivity/Aerospace Internal Use Only
>

Reply via email to