Ok, I've tried running ldapsearch on the host with the problem,  and rec'd the following error:

ldap_result: Can't contact LDAP server (-1)

command I used was

ldapsearch -p 636 -h localhost -b "dc=xxxxx,dc=yyyyy,dc=zzzz,dc=ccc"   "(objectclass=*)"

On Wednesday, January 22, 2014 2:14 PM, Michael Ströder michael@stroeder.com wrote:

c chupela wrote:

I've been tasked with figuring out why a redhat 6.4 server w/openldap v2.4.23 is not accessible.

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.

Why don't you try with ldapsearch command-line tool?

Ciao, Michael.

Am Wed, 22 Jan 2014 13:20:17 -0800 (PST) schrieb c chupela cnctema68@yahoo.com:

Ok, I've tried running ldapsearch on the host with the problem,  and rec'd the following error:

ldap_result: Can't contact LDAP server (-1)

command I used was

ldapsearch -p 636 -h localhost -b "dc=xxxxx,dc=yyyyy,dc=zzzz,dc=ccc"   "(objectclass=*)"

Is TLS enabled at all? Is there a propper ldap.conf or ldaprc with TLS configuration?

-Dieter

On Wednesday, January 22, 2014 2:14 PM, Michael Ströder michael@stroeder.com wrote: c chupela wrote:

...

I've been tasked with figuring out why a redhat 6.4 server w/openldap v2.4.23 is not accessible.

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.

Why don't you try with ldapsearch command-line tool?

Ciao, Michael.

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 ldaps://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 Ulrich.Windl@rz.uni-regensburg.de wrote:

...

...

c chupela cnctema68@yahoo.com schrieb am 22.01.2014 um 18:43 in Nachricht

1390412584.5499.YahooMailNeo@web140101.mail.bf1.yahoo.com:

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                0.0.0.0:*                  LISTEN      5603/slapd tcp        0      0 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

Hi C Chupela, I have and I was advised that it was code running up against and Assertion. I was suggested by Quanah to report it in an ITS to OpenLDAP,org.

I did that and according to the latest feedback, from what Quanah can tell, the patch exist, now its a matter of getting to code turned into RPMs and DEBs or whatever else is affected.

So, I guess that means the code has a patch, but I don't have the latest code because I haven't seen it released. Be aware of the fact that I was working on OpenLDAP-2.4.38 and they released OpenLDAP-2.4.39 before this patch was in created.

I hope that helps you too!

Warron French, MBA, SCSA

From: c chupela cnctema68@yahoo.com To: "openldap-technical@openldap.org" openldap-technical@openldap.org, Date: 01/30/2014 11:25 AM Subject: Re: Antw: problem with accessing secure ldap Sent by: openldap-technical-bounces@OpenLDAP.org

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 cnctema68@yahoo.com 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 ldaps://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 Ulrich.Windl@rz.uni-regensburg.de wrote:

...

...

c chupela cnctema68@yahoo.com schrieb am 22.01.2014 um 18:43 in

Nachricht 1390412584.5499.YahooMailNeo@web140101.mail.bf1.yahoo.com:

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 0.0.0.0:* LISTEN 5603/slapd tcp 0 0 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

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 jschaeffer0922@gmail.com To: c chupela cnctema68@yahoo.com, Cc: "openldap-technical@openldap.org" openldap-technical@openldap.org Date: 01/30/2014 12:05 PM Subject: Re: Antw: problem with accessing secure ldap Sent by: openldap-technical-bounces@OpenLDAP.org

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 cnctema68@yahoo.com 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 cnctema68@yahoo.com 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 ldaps:// 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 < Ulrich.Windl@rz.uni-regensburg.de> wrote:

...

...

c chupela cnctema68@yahoo.com schrieb am 22.01.2014 um 18:43 in

Nachricht 1390412584.5499.YahooMailNeo@web140101.mail.bf1.yahoo.com:

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 0.0.0.0:*

LISTEN 5603/slapd tcp 0 0 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

Low Sensitivity/Aerospace Internal Use Only

Sure thing Joshua.

See if in the verbose results you get back a result like:

modifying entry "cn=config" 52e68423 connection_input: conn=1000 deferring operation: binding slapd: result.c:813: slap_send_ldap_result: Assertion `!((rs->sr_err)<0)' failed. ldap_result: Can't contact LDAP server (-1)

This is what I received.

Warron French, MBA, SCSA The Aerospace Corporation Sr. UNIX SA & Storage Admin Mailstop: CH1-230 Desk: 571-307-5311 Cell: 703-967-8936

From: Joshua Schaeffer jschaeffer0922@gmail.com To: Warron S French Warron.S.French@aero.org, Cc: "openldap-technical@openldap.org" openldap-technical@openldap.org Date: 01/30/2014 01:55 PM Subject: Re: Antw: problem with accessing secure ldap --- Low Sensitivity/Aerospace Internal Use Only

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 < Warron.S.French@aero.org> 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 jschaeffer0922@gmail.com To: c chupela cnctema68@yahoo.com, Cc: "openldap-technical@openldap.org" < openldap-technical@openldap.org> Date: 01/30/2014 12:05 PM Subject: Re: Antw: problem with accessing secure ldap Sent by: openldap-technical-bounces@OpenLDAP.org

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 cnctema68@yahoo.com 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 cnctema68@yahoo.com 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 ldaps:// 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 < Ulrich.Windl@rz.uni-regensburg.de> wrote:

...

...

c chupela cnctema68@yahoo.com schrieb am 22.01.2014 um 18:43 in

Nachricht 1390412584.5499.YahooMailNeo@web140101.mail.bf1.yahoo.com:

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 0.0.0.0:*

LISTEN 5603/slapd tcp 0 0 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

Low Sensitivity/Aerospace Internal Use Only

Low Sensitivity/Aerospace Internal Use Only

Ah! OK, so you were using GnuTLS, whereas I was using OpenSSL.

Warron French, MBA, SCSA

From: Joshua Schaeffer jschaeffer0922@gmail.com To: Warron.S.French@aero.org, Cc: openldap-technical@openldap.org Date: 02/01/2014 08:32 PM Subject: Re: Antw: problem with accessing secure ldap --- Low Sensitivity/Aerospace Internal Use Only

Just getting back to this. I recreated my certificate and key and now my ldaps connections work. I think it had to do with the fact that I answered no to two questions from the gnutls certtool when I created my certificate. It asked if:

1. Whether this certificate will be used for a TLS server, and 2. Whether this certificate will be used to encrypt data

I recreated my certificate and key and answered yes to those two questions and now ldaps connections are working.

On 01/30/2014 11:43 AM, Warron S French 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 jschaeffer0922@gmail.com To: c chupela cnctema68@yahoo.com, Cc: "openldap-technical@openldap.org" openldap-technical@openldap.org Date: 01/30/2014 12:05 PM Subject: Re: Antw: problem with accessing secure ldap Sent by: openldap-technical-bounces@OpenLDAP.org

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 cnctema68@yahoo.com 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 cnctema68@yahoo.com 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 ldaps:// 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 < Ulrich.Windl@rz.uni-regensburg.de> wrote:

...

...

c chupela cnctema68@yahoo.com schrieb am 22.01.2014 um 18:43 in

Nachricht 1390412584.5499.YahooMailNeo@web140101.mail.bf1.yahoo.com:

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 0.0.0.0:* LISTEN 5603/slapd tcp 0 0 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

Low Sensitivity/Aerospace Internal Use Only

after reading thru the replies, my read of it was an alternate build was probably a better choice. Thanks for the feedback.

On Thursday, January 30, 2014 2:21 PM, Aaron Richton richton@nbcs.rutgers.edu wrote:

On Thu, 30 Jan 2014, c chupela 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?

Sure, others have. For example, http://www.openldap.org/lists/openldap-technical/201202/msg00460.html shows somebody working through their certificate configuration.

Your original message mentioned that this was a test server. The debugging output indicates that you're using MozNSS, not OpenSSL. Personally, I'd give a long and sober thought to deploying a server with MozNSS as the crypto provider. You may be able to get your tests working after spending some quality time with certutil(1), but those efforts may be better spent researching alternate builds that utilize OpenSSL.

On Friday, January 24, 2014 5:39 PM, c chupela cnctema68@yahoo.com 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 ldaps://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 Ulrich.Windl@rz.uni-regensburg.de wrote:

...

...

...

c chupela cnctema68@yahoo.com schrieb am 22.01.2014 um 18:43 in Nachricht

1390412584.5499.YahooMailNeo@web140101.mail.bf1.yahoo.com:

...

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                0.0.0.0:*                  LISTEN      5603/slapd tcp        0      0 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