[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Antw: problem with accessing secure ldap --- 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 target=_blank>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