[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slapd makes very strange troubles in VServer



Niki Hammler wrote:
Howard Chu schrieb:
Niki Hammler wrote:
Hi,

Today I began to move my LDAP-Server to a Linux VServer jail. On the
host and on the VServer I run Debian etch 4.0. Installing slapd was no
problem (aptitude install slapd). I just copied all configuration and
data files from the host which worked perfectly before and copied them
1:1 into the VServer.

slapd starts without any warnings. But connecting with a client is not
possible, neither inside the VServer nor outside.
Please show the slapd debug logs when running with "-d -1" for these
connection attempts.

Hi,

Thank you for your quick answer!

This is the output (after startup-output) when connecting via SSL:



daemon: activity on 1 descriptor
slap_listener(ldaps:///)daemon: listen=6, new connection on 11
ldap_pvt_gethostbyname_a: host=wlan.intern.stiftingtal.net, r=0
daemon: added 11r (active) listener=(nil)
conn=0 fd=11 ACCEPT from IP=192.168.0.2:43760 (IP=0.0.0.0:636)
daemon: select: listen=6 active_threads=0 tvp=NULL
daemon: select: listen=7 active_threads=0 tvp=NULL
daemon: activity on 1 descriptor
daemon: activity on: 11r
daemon: read activity on 11
connection_get(11)
connection_get(11): got connid=0
connection_read(11): checking for input on id=0
TLS trace: SSL_accept:before/accept initialization
tls_read: want=11, got=11
  0000:  80 74 01 03 01 00 4b 00  00 00 20                  .t....K...
tls_read: want=107, got=107
  0000:  00 00 39 00 00 38 00 00  35 00 00 16 00 00 13 00   ..9..8..5.......
  0010:  00 0a 07 00 c0 00 00 33  00 00 32 00 00 2f 03 00   .......3..2../..
  0020:  80 00 00 05 00 00 04 01  00 80 00 00 15 00 00 12   ................
  0030:  00 00 09 06 00 40 00 00  14 00 00 11 00 00 08 00   .....@..........
  0040:  00 06 04 00 80 00 00 03  02 00 80 fb fb f7 a3 58   ...............X
  0050:  ee 80 3e 8d 15 ea 2b 74  23 8d 4a c6 bd 0d 27 5c   ..>...+t#.J...'\
  0060:  bc ca cb b0 d2 45 42 3d  41 21 da                  .....EB=A!.
TLS trace: SSL_accept:error in SSLv3 read client hello B
TLS trace: SSL_accept:error in SSLv3 read client hello B
TLS: can't accept.
TLS: error:140B512D:SSL routines:SSL_GET_NEW_SESSION:ssl session id
callback failed ssl_sess.c:232
connection_read(11): TLS accept failure error=-1 id=0, closing
connection_closing: readying conn=0 sd=11 for close
connection_close: conn=0 sd=11
daemon: removing 11
conn=0 fd=11 closed (TLS negotiation failure)
daemon: select: listen=6 active_threads=0 tvp=NULL
daemon: select: listen=7 active_threads=0 tvp=NULL
daemon: activity on 1 descriptor
daemon: waked
daemon: select: listen=6 active_threads=0 tvp=NULL
daemon: select: listen=7 active_threads=0 tvp=NULL

That's enough. The SSL library has obviously failed: > TLS: error:140B512D:SSL routines:SSL_GET_NEW_SESSION:ssl session id > callback failed ssl_sess.c:232

This failure indicates that the SSL library was unable to generate a session ID for the session. Generating the session ID just requires generating a single random number (and checking that the number hasn't been used before). On a freshly started server, this should never fail.

Normally, slapd is started with:

/usr/sbin/slapd -h ldaps:/// ldap:/// -g openldap -u openldap -4

(In Debian with /etc/init.d/slapd, this is from ps aux).

Now I started with

slapd -h ldaps:/// ldap:/// -g openldap -u openldap -4 -d -1


But now I noticed also one very interesting thing: Starting slapd as root makes everything work fine!

/usr/sbin/slapd -h ldaps:/// ldap:/// -4

But it would be very great if I could start slapd as "openldap" for
security reasons!

Check the permissions of /dev/random and /dev/urandom on your virtual server. Make sure they are readable by the openldap user.


No bug here, just a misconfigured system...
--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP     http://www.openldap.org/project/