Re: SSL handshake failure
by Rich Megginson
On 02/29/2012 01:29 PM, Bryce Powell wrote:
> I managed to get this working, mostly by following directions in:
> http://www.openldap.org/doc/admin24/tls.html
> http://www.openldap.org/faq/data/cache/1514.html
>
> Note that these steps work for my combination of OS and OpenLDAP package, as detailed in my initial posting.
>
> My server and CA certificates were in PEM format, along with a password protected private key:
>
> cso_root_ca.pem
> cso_functional_ca.pem
> cso_issuing_ca.pem
> FQHostName.cert.pem
> FQHostName.cert.keysecure.pem
>
> * Decrypt the private key:
> openssl rsa -in FQHostName.keysecure.pem -out FQHostName.key.pem
>
> When prompted, enter the pass phrase for the private key.
>
> * Convert the server cert/key pair to PKCS format:
> openssl pkcs12 -export -inkey FQHostName.key.pem -in FQHostName.cert.pem -out FQHostName.cert.p12 -nodes -name 'FQHostName'
>
> When prompted, enter a blank Export Password by hitting ENTER.
>
> * Create the certutil certificate database:
> certutil -N -d /etc/openldap/cacerts
>
> When prompted, enter a new password for the key database.
>
> * Remove the key database password:
> certutil -d /etc/openldap/cacerts -W
>
> When prompted, enter the current password for the key database.
> e.g. Enter Password or Pin for "NSS Certificate DB":
>
> When prompted, press ENTER to specify a blank new password.
> Enter new password:
> Re-enter password:
> Password changed successfully.
>
> * Import the CA chain:
> certutil -A -d /etc/openldap/cacerts -n "CSO Root CA" -t CT,, -a -i cso_root_ca.pem
> certutil -A -d /etc/openldap/cacerts -n "CSO Functional CA" -t CT,, -a -i cso_functional_ca.pem
> certutil -A -d /etc/openldap/cacerts -n "CSO Issuing CA" -t CT,, -a -i cso_issuing_ca.pem
>
> * Add the server certificate/key pair:
> pk12util -i FQHostName.cert.p12 -d /etc/openldap/cacerts
>
> When prompted, enter blank password by pressing ENTER.
>
> * list all the certificates, to confirm the imports:
> certutil -d /etc/openldap/cacerts -L
>
> Certificate Nickname Trust Attributes
> SSL,S/MIME,JAR/XPI
>
> FQHostName u,u,u
> CSO Root CA CT,,
> CSO Functional CA CT,,
> CSO Issuing CA CT,,
>
>
> * Ensure the correct permissions and ownership are set:
> ll /etc/openldap/cacerts
>
> -rw-r-----. 1 root ldap 65536 Feb 28 11:44 cert8.db
> -rw-r-----. 1 root ldap 16384 Feb 28 11:44 key3.db
> -rw-r-----. 1 root ldap 16384 Feb 24 15:46 secmod.db
>
> chmod and/or chown as necessary.
>
> * modify /etc/openldap/slapd.conf (I'm not using cn=config as defined in the slapd folder):
> TLSCACertificatePath /etc/openldap/cacerts
> TLSCertificateFile FQHostName
>
> Note that the certificate file specified above is the name of the server certificate 'Nickname' (the certificate Common Name) in the NSS certificate database.
> As a result, the following warning will be displayed after a slapd restart:
>
> $ sudo service slapd restart
> Stopping slapd: [ OK ]
> FQHostName is not readable by "ldap" [WARNING]
> Starting slapd: [ OK ]
>
> I believe this WARNING can safely be ignored. The OpenLDAP documentation for the TLSCertificateFile setting states:
> "When using Mozilla NSS, if using a cert/key database (specified with TLSCACertificatePath), this directive specifies the name of the certificate to use."
>
> I suspect there is still some code that is looking for the existence of an actual certificate file, and is not looking in the cert/key database.
Right. Just to be clear - this has nothing to do with openldap software
- it is purely a redhat/fedora thing. And you are correct, you can
ignore the warning.
>
> * Modify the ldap.conf file:
> TLS_CACERTDIR /etc/openldap/cacerts
>
> * Test connectivity using TLS:
> $ ldapsearch -x -ZZ -H ldap://FQHostName
>
> The ldap log file should contain entries that indicate a successful TLS connection:
>
> Feb 28 14:18:21 HostName slapd[18833]: conn=1016 op=0 STARTTLS
> Feb 28 14:18:21 HostName slapd[18833]: conn=1016 op=0 RESULT oid= err=0 text=
> Feb 28 14:18:21 HostName slapd[18833]: conn=1016 fd=26 TLS established tls_ssf=256 ssf=256
>
> Or,
> $ ldapwhoami -x -ZZ -H ldap://FQHostName
> anonymous
>
> Feb 28 14:31:48 HostName slapd[18833]: conn=1017 op=0 STARTTLS
> Feb 28 14:31:48 HostName slapd[18833]: conn=1017 op=0 RESULT oid= err=0 text=
> Feb 28 14:31:48 HostName slapd[18833]: conn=1017 fd=42 TLS established tls_ssf=256 ssf=256
>
>
>
>
> -----Original Message-----
> From: Rich Megginson [mailto:rich.megginson@gmail.com]
> Sent: February 23, 2012 4:12 PM
> To: Bryce Powell
> Cc: openldap-technical(a)openldap.org
> Subject: Re: SSL handshake failure
>
> On 02/23/2012 04:36 PM, Bryce Powell wrote:
>> Thanks, Howard. Would you know how I can find a suitable package that uses openssl?
>>
>> I also tried moving the CA certificate chain file to the /etc/openldap/cacerts/ folder, splitting the file into 3 separate certificates, and running c_rehash to generate the hashed links. After modifying ldap.conf to use the cacerts folder instead of the ca file:
>>
>> TLS: file cso_root_ca.pem does not end in [.0] - does not appear to be a CA certificate directory file with a properly hashed file name - skipping.
>> TLS: loaded CA certificate file /etc/openldap/cacerts/5de054ac.0 from CA certificate directory /etc/openldap/cacerts.
>> TLS: loaded CA certificate file /etc/openldap/cacerts/241dd1a5.0 from CA certificate directory /etc/openldap/cacerts.
>> TLS: loaded CA certificate file /etc/openldap/cacerts/95df54c4.0 from CA certificate directory /etc/openldap/cacerts.
>> TLS: file cso_functional_ca.pem does not end in [.0] - does not appear to be a CA certificate directory file with a properly hashed file name - skipping.
>> TLS: file cso_issuing_ca.pem does not end in [.0] - does not appear to be a CA certificate directory file with a properly hashed file name - skipping.
>> TLS: error: connect - force handshake failure: errno 0 - moznss error -5938
>> TLS: can't connect: TLS error -5938:Encountered end of file.
>> ldap_err2string
>> ldap_start_tls: Connect error (-11)
>> additional info: TLS error -5938:Encountered end of file
>>
>> So I guess I'm stuck until I compile from scratch using openssl, or find a package that doesn't use Mozilla NSS.
> If you want to try to get it working with Mozilla NSS, I'm here to help.
> Can you provide the output from running the server with the -d 1 arguments?
>> Thanks
>>
>> -----Original Message-----
>> From: Howard Chu [mailto:hyc@symas.com]
>> Sent: February 23, 2012 1:04 PM
>> To: Bryce Powell
>> Cc: openldap-technical(a)openldap.org
>> Subject: Re: SSL handshake failure
>>
>> Bryce Powell wrote:
>>> Hi,
>>> I can't get slapd to respond successfully to TLS or SSL connections using an
>>> RSA 2048-bit PEM certificate:
>> You're using Mozilla NSS, so the fact that OpenSSL tools accept your cert
>> doesn't help you.
>>
>> While a lot of good work has gone into the Mozilla NSS support, I would still
>> say the MozNSS design is braindead and is not well suited for anything besides
>> the Netscape/Mozilla browser codebase and should be avoided. Rebuild OpenLDAP
>> using OpenSSL and I suspect these problems will disappear.
>>
>>> $ ldapsearch -x -ZZ -d1 -H ldap://FQDNhostname
>>> TLS: loaded CA certificate file /etc/openldap/cacerts/FQDNhostname.cacert.pem.
>>> TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory
>>> TLS: error: connect - force handshake failure: errno 21 - moznss error -5938
>>> TLS: can't connect: TLS error -5938:Encountered end of file.
>>> ldap_err2string
>>> ldap_start_tls: Connect error (-11)
>>> additional info: TLS error -5938:Encountered end of file
>>> $ openssl s_client -connect FQDNhostname:636 -CAfile
>>> /etc/openldap/cacerts/FQDNhostname.cacert.pem
>>> CONNECTED(00000003)
>>> 140457427965768:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
>>> failure:s23_lib.c:184:
>>> ---
>>> no peer certificate available
>>> ---
>>> No client certificate CA names sent
>>> ---
>>> SSL handshake has read 0 bytes and written 113 bytes
>>> ---
>>> New, (NONE), Cipher is (NONE)
>>> Secure Renegotiation IS NOT supported
>>> Compression: NONE
>>> Expansion: NONE
>>> ---
>>> The following packages are installed on CentOS 6.2:
>>> openldap-servers-2.4.23-20.el6.x86_64
>>> openldap-2.4.23-20.el6.x86_64
>>> openldap-clients-2.4.23-20.el6.x86_64
>>> openssl-1.0.0-20.el6_2.1.x86_64
>>> openssl-devel-1.0.0-20.el6_2.1.x86_64
>>> gnutls-2.8.5-4.el6.x86_64
>>> gnutls-devel-2.8.5-4.el6.x86_64
>>> nss-pam-ldapd-0.7.5-14.el6_2.1.x86_64
>>> The /etc/openldap/ldap.conf file contains:
>>> TLS_CACERT /etc/openldap/cacerts/FQDNhostname.cacert.pem
>>> , which contains a chain of three certificates (root CA,
>>> intermediate/functional, and issuing).
>>> The /etc/openldap/slapd.conf file contains:
>>> TLSCipherSuite HIGH:+SSLv3
>>> TLSCertificateFile /etc/openldap/FQDNhostname.cert.pem
>>> TLSCertificateKeyFile /etc/openldap/FQDNhostname.key.pem
>>> The server is acting as a proxy to an Active Directory, and therefore I only
>>> have one LDAP database defined. My intention is to use LDAPS for communication
>>> between the client and LDAP proxy servers:
>>> database ldap
>>> suffix "dc=abc,dc=local"
>>> rebind-as-user
>>> uri "ldap://IPaddress1/ ldap://IPaddress2/ ldap://IPaddress3/ ldap://IPaddress4/"
>>> chase-referrals yes
>>> noundeffilter yes
>>> use-temporary-conn yes
>>> The certificate and private key are located in /etc/openldap/, with the
>>> following permissions :
>>> -r--r-----. 1 ldap ldap 2076 Feb 21 15:30 FQDNhostname.cert.pem
>>> -r--r-----. 1 ldap ldap 1675 Feb 21 15:35 FQDNhostname.sdi.key.pem
>>> The CN of the certificate matches the FQDN host name of the LDAP server.
>>> The private key is not password protected.
>>> Everything checks out OK by testing the certificate using openssl:
>>> $ openssl verify -purpose sslserver -CAfile
>>> /etc/openldap/cacerts/FQDNhostname.cacert.pem /etc/openldap/FQDNhostname.cert.pem
>>> /etc/openldap/FQDNhostname.cert.pem: OK
>>> OpenSSL client/server connections work fine too:
>>> openssl s_server -cert /etc/openldap/FQDNhostname.cert.pem -key
>>> /etc/openldap/FQDNhostname.key.pem -cipher 'HIGH:+SSLv3
>>> openssl s_client -connect FQDNhostname:4433 -CAfile
>>> /etc/openldap/cacerts/FQDNhostname.cacert.pem
>>> *Bryce Powell*
13 years, 4 months
Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Robert Heller
At Thu, 28 Sep 2017 22:21:51 -0400 Douglas Duckworth <dod2014(a)med.cornell.edu> wrote:
>
>
>
> SSSD should be configured to bind TLS with ldap:389 not ldaps:636.
> Increase SSSD log verbosity to get more information. I have also found
> that slapd logging can help determine bind issues.
Slapd is just loging a TLS negotiation failure and I don't know how to get
slapd to be more specific.
● slapd.service - OpenLDAP Server Daemon
Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled; vendor preset: disabled)
Active: active (running) since Fri 2017-09-29 10:45:02 EDT; 12min ago
Docs: man:slapd
man:slapd-config
man:slapd-hdb
man:slapd-mdb
file:///usr/share/doc/openldap-servers/guide.html
Process: 20310 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} $SLAPD_OPTIONS (code=exited, status=0/SUCCESS)
Process: 20271 ExecStartPre=/usr/libexec/openldap/check-config.sh (code=exited, status=0/SUCCESS)
Main PID: 20312 (slapd)
CGroup: /system.slice/slapd.service
└─20312 /usr/sbin/slapd -u ldap -h ldapi:/// ldap://127.0.0.1/ ldap://192.168.250.98/ ldaps:/// -s 30
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on 2 descriptors
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 busy
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: connection_closing: readying conn=1010 sd=13 for close
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: removing 13
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: conn=1010 fd=13 closed (TLS negotiation failure)
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: listen=9, new connection on 13
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: added 13r (active) listener=(nil)
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: conn=1011 fd=13 ACCEPT from IP=192.168.250.98:47692 (IP=192.168.250.98:389)
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on 2 descriptors
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: conn=1011 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: do_extended: oid=1.3.6.1.4.1.1466.20037
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: conn=1011 op=0 STARTTLS
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: conn=1011 op=0 RESULT oid= err=0 text=
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: connection_closing: readying conn=1011 sd=13 for close
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: removing 13
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: conn=1011 fd=13 closed (TLS negotiation failure)
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 busy
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: listen=9, new connection on 13
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: added 13r (active) listener=(nil)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: conn=1012 fd=13 ACCEPT from IP=192.168.250.98:47694 (IP=192.168.250.98:389)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 2 descriptors
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: conn=1012 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: do_extended: oid=1.3.6.1.4.1.1466.20037
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: conn=1012 op=0 STARTTLS
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: conn=1012 op=0 RESULT oid= err=0 text=
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 2 descriptors
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 busy
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: connection_closing: readying conn=1012 sd=13 for close
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: removing 13
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: conn=1012 fd=13 closed (TLS negotiation failure)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: listen=9, new connection on 13
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: added 13r (active) listener=(nil)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: conn=1013 fd=13 ACCEPT from IP=192.168.250.98:47696 (IP=192.168.250.98:389)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 2 descriptors
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: conn=1013 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: do_extended: oid=1.3.6.1.4.1.1466.20037
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: conn=1013 op=0 STARTTLS
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: conn=1013 op=0 RESULT oid= err=0 text=
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: connection_closing: readying conn=1013 sd=13 for close
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: removing 13
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: conn=1013 fd=13 closed (TLS negotiation failure)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 busy
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: listen=9, new connection on 13
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: added 13r (active) listener=(nil)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: conn=1014 fd=13 ACCEPT from IP=192.168.250.98:47698 (IP=192.168.250.98:389)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 2 descriptors
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: conn=1014 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: do_extended: oid=1.3.6.1.4.1.1466.20037
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: conn=1014 op=0 STARTTLS
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: conn=1014 op=0 RESULT oid= err=0 text=
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 2 descriptors
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 busy
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: connection_closing: readying conn=1014 sd=13 for close
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: removing 13
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: conn=1014 fd=13 closed (TLS negotiation failure)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: listen=9, new connection on 13
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: added 13r (active) listener=(nil)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: conn=1015 fd=13 ACCEPT from IP=192.168.250.98:47700 (IP=192.168.250.98:389)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 2 descriptors
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: conn=1015 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: do_extended: oid=1.3.6.1.4.1.1466.20037
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: conn=1015 op=0 STARTTLS
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: conn=1015 op=0 RESULT oid= err=0 text=
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: connection_closing: readying conn=1015 sd=13 for close
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: removing 13
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: conn=1015 fd=13 closed (TLS negotiation failure)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 busy
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: listen=9, new connection on 13
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: added 13r (active) listener=(nil)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: conn=1016 fd=13 ACCEPT from IP=192.168.250.98:47702 (IP=192.168.250.98:389)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 2 descriptors
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: conn=1016 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: do_extended: oid=1.3.6.1.4.1.1466.20037
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: conn=1016 op=0 STARTTLS
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: conn=1016 op=0 RESULT oid= err=0 text=
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 2 descriptors
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 busy
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: connection_closing: readying conn=1016 sd=13 for close
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: removing 13
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: conn=1016 fd=13 closed (TLS negotiation failure)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: listen=9, new connection on 13
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: added 13r (active) listener=(nil)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: conn=1017 fd=13 ACCEPT from IP=192.168.250.98:47704 (IP=192.168.250.98:389)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 2 descriptors
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: conn=1017 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: do_extended: oid=1.3.6.1.4.1.1466.20037
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: conn=1017 op=0 STARTTLS
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: conn=1017 op=0 RESULT oid= err=0 text=
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: connection_closing: readying conn=1017 sd=13 for close
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: removing 13
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: conn=1017 fd=13 closed (TLS negotiation failure)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
SSSD is just saying it is unable to get information from the provider (I'm
guessing slapd).
I am just about to give up on SSSD. As far as I can tell, it just does not
work. I don't think I really need SSSD for anything. It sounds like
nslcd/nss_pam_ldap will do what I need to do. CentOS7 / RHEL7 comes with SSSD
as the default, so somehow I need to get rid of it. I actually installed
nss_pam_ldap and it is in fact running, but I am guess it is not being used.
I guess I need to figure out the "magic" for authconfig to shove sssd out of
the way....
>
> How does one estalish their own CA that's trusted by other Root CA's?
> Perhaps try disabling verification of the chain then see if bind happens.
>
> On Sep 28, 2017 9:14 PM, "Robert Heller" <heller(a)deepsoft.com> wrote:
>
> > At Thu, 28 Sep 2017 16:08:42 -0700 Quanah Gibson-Mount <quanah(a)symas.com>
> > wrote:
> >
> > >
> > > --On Thursday, September 28, 2017 7:28 PM -0400 Robert Heller
> > > <heller(a)deepsoft.com> wrote:
> > >
> > > > At Thu, 28 Sep 2017 12:29:19 -0700 Quanah Gibson-Mount <
> > quanah(a)symas.com>
> > > > wrote:
> > > >
> > > >>
> > > >> --On Thursday, September 28, 2017 3:34 PM -0400 Robert Heller
> > > >> <heller(a)deepsoft.com> wrote:
> > > >>
> > > >>
> > > >> > Slapd is reporting TLS Negotiation failure when SSSD tries to
> > connect
> > > >> > to it. For both port 389 (ldap:///) and 636 (ldaps:///). So I
> > guess
> > > >> > something is wrong with slapd's TLS configuration -- it is failing
> > to
> > > >> > do TLS Negotiation, either it is just not doing it or it is doing
> > it
> > > >> > wrong (somehow). Unless SSSD is not configured properly.
> > > >>
> > > >> You need to start with the following:
> > > >>
> > > >> >> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w
> > > >>
> > > >> to test startTLS
> > > >>
> > > >> and
> > > >>
> > > >> ldapwhoami -x -H ldaps://myhost:636 -D binddn -w
> > > >>
> > > >> to test without startTLS
> > > >>
> > > >> If you can get those to work, then you can move on to SSSD.
> > > >
> > > > [heller@c764guest ~]$ ldapwhoami -x -ZZ -H ldap://c764guest:389 -D
> > > > cn=Manager,dc=deepsoft,dc=com -W ldap_start_tls: Connect error (-11)
> > > > additional info: TLS error -8157:Certificate extension not
> > found.
> > >
> > > This may be of help:
> > > <https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__serverfault.com_questions_640910_my-2Dcertificate-
> > 2Ddoesnt-2Dwork-2Don-2Dall-2Dmachines&d=DwIBAg&c=
> > lb62iw4YL4RFalcE2hQUQealT9-RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-
> > CbhH6xUjnRkaqPFUS2wTJ2cw&m=fNmr-KFWiEhP0yGMfSAsdSa6NOnIS_lb6cSsPujmQZ8&s=
> > h0ZJ27HydY4c7iw8uXd-1iadz94M-ZzNGL7KMfOsi2w&e=>
> > >
> > > > [heller@c764guest ~]$ ldapwhoami -x -H ldaps://c764guest:636 -D
> > > > cn=Manager,dc=deepsoft,dc=com -W Enter LDAP Password:
> > > > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
> > >
> > > This may mean slapd isn't listening on port 636 (With no -d -1 info, hard
> > > to know for sure). It may also simply be a different manifistation of
> > the
> > > error above.
> >
> > I added a -d option (picked 10), and discovered that it wanted the full
> > name
> > as specificed in the certificate. That fixed ldapwhoami and I put that in
> > ldap.conf, smb.conf, and in sssd.conf, but sssd is still not behaving
> > (samba
> > is though, mostly -- it might also be having issues since sssd is not
> > working)...
> >
> > >
> > > --Quanah
> > >
> > >
> > > --
> > >
> > > Quanah Gibson-Mount
> > > Product Architect
> > > Symas Corporation
> > > Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> > > <https://urldefense.proofpoint.com/v2/url?u=http-
> > 3A__www.symas.com&d=DwIBAg&c=lb62iw4YL4RFalcE2hQUQealT9-
> > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m=
> > fNmr-KFWiEhP0yGMfSAsdSa6NOnIS_lb6cSsPujmQZ8&s=4Jyip-
> > C583CeHTI2N1wXllUKzrjwwvY9tqyl3tZVq8w&e=>
> > >
> > >
> >
> > --
> > Robert Heller -- 978-544-6933
> > Deepwoods Software -- Custom Software Services
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.
> > deepsoft.com_&d=DwIBAg&c=lb62iw4YL4RFalcE2hQUQealT9-
> > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m=
> > fNmr-KFWiEhP0yGMfSAsdSa6NOnIS_lb6cSsPujmQZ8&s=hf9o7fTr6iLSDpsS6xK6nGDWhZo-
> > N7aXcKoRAXfrPUE&e= -- Linux Administration Services
> > heller(a)deepsoft.com -- Webhosting Services
> >
> >
> >
>
>
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller(a)deepsoft.com -- Webhosting Services
7 years, 9 months
slapd on an interface alias
by Ulrich Windl
Hi!
I had sent a request for documentation to the ITS, because I feel that something is wrong with OpenLDAP 2.4.26 (as shipped with SLES11 SP2), but I was redirected:
I wrote:
> Full_Name: Ulrich Windl
> Version: 2.4.26
> OS: Linux (SLES11 SP2)
[...]
>
>
> I was able to set up a master LDAP server and a replication consumer using the
> physical host names and TLS. However when I tried to bind slapd on a virtual IP
> address ("interface alias"), I never got slapd working (even though I fixed the
> certificates for TLS, of course). Dynamic configuration ("cn=config") seems to
> make things very difficult, because slapd ends in a state where _nobody_ can
> make configuration changes.
Use the openldap-technical mailing list to ask for configuration help.
You talk about IP addresses and yet in your quoted text below you are using
hostnames. Be consistent when you post your question to the mailing list
otherwise no one will understand what you're asking for.
--> Obviously slapd listens to ports, not to names, and names were invented so that people don't have to remember IP addresses, but you know.
--> Only with X.509 certificates the relation between names and adresses are of some inportance, but you can believe me that I understand that.
Closing this ITS.
> It seems slapd tried to use the wrong URI (using the physical host where nobody
> is listening):
> slapd[10036]: slap_client_connect: URI=ldap://phost.domain.org/ Error,
> ldap_start_tls failed (-1)
> slapd[10036]: do_syncrepl: rid=002 rc -1 retrying
>
> slapd is listening on ldap://vhost.domain.org/ however.
--> You should believe me if I say so.
>
> I read lots of procedures using Google, but could not find the solution for this
> problem. Thus I suggest to add documentation how to configure such a scenario:
>
> 1) Set up an LDAP Master server that provides service on a specific IP address
> using TLS
> 2) Set up a replication consumer that provides service on a specific IP address
> using TLS also
> 3) The replication consumer should use the address where the master server
> listens for replication
>
> It sounds like an every-day setup, but I failed multiple times, thus the request
> for documentation.
>
Still waiting for a procedure. Something seems to be non-obvious or broken.
Some details (randomly picked, with some names obfuscated):
(master server)
olcSyncrepl: {0}rid=2 provider="ldap://v07.domain.org/"
searchbase="dc=domain,dc=org" type="refreshAndPersist" retry="120 +" starttls=critical tls_reqcert=demand bindmethod="simple" binddn="uid=syncrepl,ou=system,dc=domain,dc=org" credent ials="wNkWudLd3ko8"
The process is started as "/usr/lib/openldap/slapd -h ldap://ds1.domain.org:389 ldaps://ds1.domain.org:636 ldapi:/// -F /etc/openldap/slapd.d -u ldap -g ldap -o slp=off"
And syslog message sI'm seeing over and over are like this:
Jul 5 08:23:16 v07 slapd[25914]: slap_client_connect: URI=ldap://v07.domain.org/ Error, ldap_start_tls failed (-1)
Jul 5 08:23:16 v07 slapd[25914]: do_syncrepl: rid=002 rc -1 retrying
Obviously a connection to the "v07" address is not possible, because the server listens to the "ds1" address. The interface settings look like this:
eth0 Link encap:Ethernet HWaddr 00:16:3E:5C:DD:76
inet addr:172.20.16.38 Bcast:172.20.17.255 Mask:255.255.254.0
inet6 addr: fe80::216:3eff:fe5c:4d76/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6334378 errors:0 dropped:6 overruns:0 frame:0
TX packets:237667 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:421369553 (401.8 Mb) TX bytes:49452419 (47.1 Mb)
eth0:ds1 Link encap:Ethernet HWaddr 00:16:3E:5C:DD:76
inet addr:172.20.17.200 Bcast:172.20.17.255 Mask:255.255.254.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Basically I think I have to fix the "olcSyncrepl provider" and possibly the "olcServerID", but with dynamic configuration I cannot do it:
Using ldapmodify I get:
v07:~ # ldapmodify -v -ZZ -x -W -D cn=config -H ldap://ds1.domain.org -f /tmp/fix1.ldif
ldap_initialize( ldap://ds1.domain.org:389/??base )
Enter LDAP Password:
replace olcServerID:
1 ldap://ds1.domain.org
modifying entry "cn=config"
ldap_modify: Server is unwilling to perform (53)
additional info: shadow context; no update referral
When editing the files in the slap.d directory, I get:
Jul 5 09:11:25 v07 slapd[15014]: @(#) $OpenLDAP: slapd 2.4.26 (Sep 26 2012 13:21:45) $ abuild@e71:/usr/src/packages/BUILD/openldap-2.4.26/servers/slapd
Jul 5 09:11:25 v07 slapd[15014]: ldif_read_file: checksum error on "/etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif"
Jul 5 09:11:25 v07 slapd[15014]: ldif_read_file: checksum error on "/etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif"
Jul 5 09:11:25 v07 slapd[15015]: hdb_monitor_db_open: monitoring disabled; configure monitor database to enable
Jul 5 09:11:25 v07 slapd[15015]: slapd starting
Jul 5 09:11:25 v07 slapd[15015]: slap_client_connect: URI=ldap://ds1.domain.org/ DN="uid=syncrepl,ou=system,dc=domain,dc=org" ldap_sasl_bind_s failed (49)
Jul 5 09:11:25 v07 slapd[15015]: do_syncrepl: rid=002 rc 49 retrying
Jul 5 09:11:25 v07 slapd[15015]: slap_client_connect: URI=ldap://ds1.domain.org/ DN="uid=syncrepl,ou=system,dc=domain,dc=org" ldap_sasl_bind_s failed (49)
Jul 5 09:11:25 v07 slapd[15015]: do_syncrepl: rid=001 rc 49 retrying
Jul 5 09:12:37 v07 nscd: nss-ldap: do_open: do_start_tls failed:stat=-1
(So obviously the syncrepl provider has changed, but it still won't work)
Regards,
Ulrich
12 years
additional info: objectClasses: value #0 invalid per syntax
by Jimmy Royer
Hello,
I am starting out with openldap and I don't know it that much. I got
the error mentioned in the title when trying to add an object class,
which is apparently a very common one per my google searches. I've
read that common causes are:
* extraneous white space (especially trailing white space)
* improperly encoded characters (LDAPv3 uses UTF-8 encoded Unicode)
* empty values (few syntaxes allow empty values)
This is the object class file I am trying to add, I picked it as an
example on some website, to have something minimal and make it easier
to test:
# cat exObjectClasses.ldif
dn: cn=schema
changetype: modify
add: objectClasses
objectClasses: ( 2.16.840.1.113730.3.2.2.9
NAME 'blogger'
DESC 'Someone who has a blog'
SUP inetOrgPerson STRUCTURAL
MAY blog )
I've checked if there was any trailing spaces at the end with the following:
# cat -vte exObjectClasses.ldif
dn: cn=schema$
changetype: modify$
add: objectClasses$
objectClasses: ( 2.16.840.1.113730.3.2.2.9$
NAME 'blogger'$
DESC 'Someone who has a blog'$
SUP inetOrgPerson STRUCTURAL$
MAY blog )$
I've made sure the file is UTF-8:
# iconv -f ASCII -t UTF-8 exObjectClasses.ldif > exObjectClasses.ldif.utf8
And I don't think there are any empty values defined in the LDIF file.
So when I type this command, I still have the "invalid per syntax
error:
# ldapmodify -x -W -H "ldaps://127.0.0.1" -D
cn=Manager,dc=modelsolv,dc=com -f exObjectClasses.ldif
Enter LDAP Password:
modifying entry "cn=schema"
ldap_modify: Invalid syntax (21)
additional info: objectClasses: value #0 invalid per syntax
This is the content of the /etc/openldap/slapd.conf file:
# cat slapd.conf
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/corba.schema
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/duaconf.schema
include /etc/openldap/schema/dyngroup.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/java.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/collective.schema
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules
# - modulepath is architecture dependent value (32/64-bit system)
# - back_sql.la overlay requires openldap-server-sql package
# - dyngroup.la and dynlist.la cannot be used at the same time
# modulepath /usr/lib/openldap
# modulepath /usr/lib64/openldap
# moduleload accesslog.la
# moduleload auditlog.la
# moduleload back_sql.la
# moduleload chain.la
# moduleload collect.la
# moduleload constraint.la
# moduleload dds.la
# moduleload deref.la
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload memberof.la
# moduleload pbind.la
# moduleload pcache.la
# moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload seqmod.la
# moduleload smbk5pwd.la
# moduleload sssvlv.la
# moduleload syncprov.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la
# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by running
# /usr/libexec/openldap/generate-server-cert.sh. Your client software may balk
# at self-signed certificates, however.
TLSCACertificatePath /etc/openldap/certs
TLSCertificateFile "\"OpenLDAP Server\""
TLSCertificateKeyFile /etc/openldap/certs/password
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
# enable on-the-fly configuration (cn=config)
database config
access to *
by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
manage
by * none
# enable server status monitoring (cn=monitor)
database monitor
access to *
by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
read
by dn.exact="cn=Manager,dc=my-domain,dc=com" read
by * none
#######################################################################
# database definitions
#######################################################################
database bdb
suffix "dc=modelsolv,dc=com"
checkpoint 1024 15
rootdn "cn=Manager,dc=modelsolv,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw SECRET
# rootpw {crypt}ijFYNcSNctBYg
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain for this database
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example.com(a)EXAMPLE.COM
I was able to add a few entries in LDAP so far. So I know I am able to
reach the server, the connection is fine, and LDAP is somewhat
functional. But I can't modify the schema with objectclasses.
Is there anything obvious that I am doing wrong? Do you have any
recommendation for debugging further?
Regards,
Jimmy Royer
12 years, 4 months
Re: Slapd Security based on port
by Chris Jackson
On Feb 16, 2011, at 3:46 AM, <harry.jede(a)arcor.de>
<harry.jede(a)arcor.de> wrote:
> Chris Jackson wrote:
>> On Feb 11, 2011, at 09:50 AM, Chris Jackson wrote:
>>
>> Is it possible to prevent anonymous and unauthenticated binds to
>> ldaps:// 636 but allow them on ldap:// 389?
>>
>> I want to allow staff to query my ldaps:// outside of my network
>> while requiring them to login to do so but allow anyone to bind
>> (anonymous, unauthenticated, or authenticated) internally on ldaps//:
>> 389.
>>
>> I know:
>> Anonymous bind can be disabled by "disallow bind_anon" and
>> Unauthenticated bind mechanism is disabled by default. But if I use
>> "disallow bind_anon it stops in on both ports.
> Sure, this are global directives.
>
>> I want to stop it just on ldaps://.
> You don't need ldaps:// in your local network? May be.
> I think a easier solution is to identify your Internet Gateway by IP.
>
>> Chris Jackson
>>
>>
>> On Feb 14, 2011, at 11:28 AM, Aaron Richton wrote:
>>
>> Stopping users that are "unauthenticated" makes no sense;
>> everything's unauthenticated at time=0. You might as well stop slapd
>> if you want a 100% inability to serve data.
>>
>> You can deny anonymous users that aren't plaintext, including any
>> ldaps:/// connections, with something like:
>>
>> access to *
>> by anonymous ssf=0 transport_ssf=0 tls_ssf=0 sasl_ssf=0 none break
>> by anonymous none
>>
>> early on in your ACL stanzas. I'm pretty sure this'll deny anonymous
>> StartTLS users on 389, though; not sure if that's what you want. I
>> can't think of any way to use the slapd access language to
>> differentiate based on listeners, which would probably be the most
>> elegant way to handle what you asked. To be fair, this entire
>> exercise seems really odd from where I sit -- are you positive that
>> this will have the desired effect? (If somebody out in Peru is
>> permitted to connect in unencrypted and make anonymous queries, why
>> not allow them to make those same queries encrypted? What's the
>> difference?)
>>
>> here is a scenario:
>>
>> Site has a ldap server on ldap://389. Firewall blocks access to 389
>> from internet. Everyone queries the ldap via anonymous binds. Site
>> would like to allow staff the ability to query the ldap from outside
>> the firewall. This would be done via ldaps:// 636 to users who have
>> authenticated via username/password. They do not want to allow
>> anonymous queries outside the firewall.
>>
>> Using the "disallow bind_anon" would prevent anon binds on both
>> ldap:// and ldaps://. This would break the inside machines ability
>> to query. If we dont use "disallow bind_anon" then machines outside
>> of the firewall could query the ldap.
>>
>> ---Is the only option for them to setup two separate ldap servers?
> No. You should use ACLs to solve this problem. Read man slapd.access
> an/or search the openldap archives.
>
> Assuming you have a NAT gatway as Firewall machine.
>
> Replace all "by anonymous" statements with these 6 statements:
>
> by anonymous auth continue
> by peername.ip="127.0.0.1" read continue
> by peername.ip="10.0.0.0%255.0.0.0" read continue
> by peername.ip="172.16.0.0%255.240.0.0" read continue
> by peername.ip="192.168.0.0%255.255.0.0" read continue
> by peername.ip="gateway-ip" auth
>
> One may write these statements more effective, but in general they will
> do.
>
>
> Replace "gateway-ip" with yours.
>
> Put the above statements also in every ACL just before the
> by *
> when this ACL do NOT have an "by anonymous" statement.
>
> Maybe the last line could/should be:
> by ssf=56 peername.ip="gateway-ip" auth
>
> Caveats:
> Your gateway can no longer access your LDAP Server with
> the "gateway-ip". But this is a Firewall Design Question.
>
> I've tested this only with unencrypted sessions; anoymous and
> authenticated. But TLS or SSL will not grant more rights, if you do not
> tell the ACLs to do so.
>
>
> Here the output from the two searches:
>
> # ldapsearch -x -LLL -H ldap://192.168.231.90/ dn
> Insufficient access (50)
>
> # ldapsearch -x -LLL -H ldap://192.168.231.90/ dn -D
> cn=admin,dc=kronprinz,dc=xx -W
> dn: dc=kronprinz,dc=xx
>
> dn: cn=admin,dc=kronprinz,dc=xx
>
>> One with "disallow bind_anon" and one without. Then only open the
>> firewall for port 636 to the ldap server which has "disallow
>> bind_anon".
>>
>> Chris Jackson
>
>
>
> --
>
> Harry Jede
The above example got me started in the right direction. Everything appears to be doing exactly what I wanted to do. I did notice that the anonymous bind users from ip addresses not 10, give an error 32. Anyone see any flaws in this?
The below ACL should be allowing anon binds when ip address is 10.*.*.* or allow authenticated binds from any ip address.
access to attrs=userpassword
by anonymous auth
by self read
by * none
access to *
by anonymous auth continue
by users read
by peername.ip="10.0.0.0%255.0.0.0" read
by * none
Chris
14 years, 4 months
RE: client server connection to LDAP/Kerberos
by Asmaa Ahmed
No, don't have any problem while running these commands from there!I can retrieve my data successfully.
Feb 2 11:59:49 ldap slapd[1059]: conn=1374 op=2 BIND dn="" method=163Feb 2 11:59:49 ldap slapd[1059]: conn=1374 op=2 BIND authcid="aahmed(a)DOMAIN.COM" authzid="aahmed(a)DOMAIN.COM"Feb 2 11:59:49 ldap slapd[1059]: conn=1374 op=2 BIND dn="uid=aahmed,ou=people,dc=domain,dc=com" mech=GSSAPI sasl_ssf=56 ssf=56Feb 2 11:59:49 ldap slapd[1059]: conn=1374 op=2 RESULT tag=97 err=0 text=Feb 2 11:59:49 ldap slapd[1059]: conn=1374 op=3 SRCH base="dc=domain,dc=com" scope=2 deref=0 filter="(objectClass=*)"Feb 2 11:59:49 ldap slapd[1059]: conn=1374 op=3 SEARCH RESULT tag=101 err=0 nentries=11 text=Feb 2 11:59:49 ldap slapd[1059]: conn=1374 op=4 UNBIND
Thanks.
> Date: Fri, 1 Feb 2013 13:53:29 -0600
> From: dwhite(a)olp.net
> To: asabatgirl(a)hotmail.com
> CC: openldap-technical(a)openldap.org
> Subject: Re: client server connection to LDAP/Kerberos
>
> On 02/01/13 10:08 +1100, Asmaa Ahmed wrote:
> >Hello,
> >
> >I recently added Kerberos authentication to my LDAP server, and I am trying
> >to connect the other servers to it.
> >I have a server running Davical shared calendar, and I hope to get it
> >working with my LDAP server again after Kerberos integration.
> >
> >Here is my configuration which was working before the integration and my
> >source is
> >"http://wiki.davical.org/w/Configuration/LDAP#Kerberos_Authentication"
> >
> > $c->authenticate_hook['config'] = array(
> > 'host' => 'ldap.domain.com', //host name of your LDAP Server
> > 'port' => '389', //port
> >// 'bindDN' => 'cn=admin,dc=domain,dc=com', //DN to bind request
> >// to this server (if required)
> >// 'passDN' => 'password', //Password of request bind
> > 'baseDNUsers' => 'ou=People,dc=domain,dc=com', //where to look for
> >valid user
> > 'filterUsers' => 'objectClass=*', //filter which must validate a user
> >according to RFC4515, i.e. surrounded by brackets
> > 'protocolVersion' => 3, // important for simple auth (no sasl)
> >// 'startTLS' => true, // securing your LDAP connection
> > 'i_use_mode_kerberos' => "i_know_what_i_am_doing",
> >
> >My slapd error logs:
> >Jan 31 23:40:00 ldap slapd[1059]: conn=1273 fd=43 ACCEPT from
> >IP=203.28.247.193:56887 (IP=0.0.0.0:389)
> >Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=0 BIND dn="" method=128
> >Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=0 RESULT tag=97 err=0 text=
> >Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=1 SRCH
> >base="ou=People,dc=domain,dc=com" scope=2 deref=0 filter="(objectClass=*)"
> >Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=1 SRCH attr=uid
> >modifyTimestamp cn mail
> >Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=1 SEARCH RESULT tag=101
> >err=32 nentries=0 text=
> >Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=2 UNBIND
> >
> >My OLC configuration:
> >root@ldap:/var/log# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config
> >"(|(cn=config)(olcDatabase={1}hdb))"
> >dn: cn=config
> >objectClass: olcGlobal
> >cn: config
> >olcArgsFile: /var/run/slapd/slapd.args
> >olcAuthzRegexp: {0}uid=([^,]+),cn=domain.com,cn=gssapi,cn=auth uid=$1
> > ,ou=people,dc=domain,dc=com
> >olcLogLevel: stats
> >olcPidFile: /var/run/slapd/slapd.pid
> >olcSaslRealm: DOMAIN.COM
> >olcToolThreads: 1
> >
> >dn: olcDatabase={1}hdb,cn=config
> >objectClass: olcDatabaseConfig
> >objectClass: olcHdbConfig
> >olcDatabase: {1}hdb
> >olcDbDirectory: /var/lib/ldap
> >olcSuffix: dc=domain,dc=com
> >olcAccess: {0}to attrs=userPassword,shadowLastChange by anonymous auth by *
> >no
> > ne
> >olcAccess: {1}to dn.subtree="ou=krb5,dc=domain,dc=com" by dn="c
> > n=adm-srv,ou=krb5,domain,dc=com" write by dn="cn=kdc-srv,ou
> > =krb5,domain,dc=com" read by * none
> >olcAccess: {2}to attrs=loginShell,gecos by self write by users read by *
> >none
> >olcAccess: {3}to dn.base="" by * read
> >olcAccess: {4}to * by users read by * none
> >olcLastMod: TRUE
> >olcRootDN: uid=admin,ou=people,domain,dc=com
> >
> >
> >Any suggestion to fix the binding and get my search working again with
> >kerberos authentication ?
> >
> >Thanks.
>
> Can you reproduce this problem with ldapsearch and/or ldapwhoami (-Y
> GSSAPI) on the server which is running davical?
>
> --
> Dan White
12 years, 5 months
Windows SSPI, NTLMSSP and OpenLDAP with SASL/GSSAPI
by Diego Morales
Hello,
I have a proprietary windows application trying to bind on my OpenLDAP
server using GSSAPI with NTLMSSP mechanism, instead of Kerberos. Is it
possible to support this on a (unix) OpenLDAP server?
Another option would be to make the software use GSSAPI + Kerberos
instead. Let me further explain:
I have a working samba + openldap setup with many windows
workstations. The said proprietary app has LDAP auth support, and
according to its maker it works with Active Directory and Novell NDS.
It does not support simple bind, nor LDAPS, (and probably not StartTLS
either). We don't have access to the app's source code and help from
its developers/tech-support is pretty unavailable.
Checking slapd's debug, we saw the app trying to use SASL+GSSAPI to
bind. So we went on and configured a minimal Kerberos setup and
SASL+GSSAPI support for OpenLDAP on a test ldap server. It seems to be
working perfectly. We acquire a ticket and run ldapsearch from another
machine using -Y GSSAPI bind and it works. Logs from slapd debug seem
ok.
But that evil app still fails. Here's a piece from slapd debug log:
conn=1000 op=1 do_bind
ber_scanf fmt ({imt) ber:
ber_dump: buf=0x7f73f6af8810 ptr=0x7f73f6af8813 end=0x7f73f6af8856 len=67
0000: 60 84 00 00 00 3d 02 01 03 04 00 a3 84 00 00 00 `....=..........
0010: 32 04 06 47 53 53 41 50 49 04 28 4e 54 4c 4d 53 2..GSSAPI.(NTLMS
0020: 53 50 00 01 00 00 00 97 82 08 e2 00 00 00 00 00 SP..............
0030: 00 00 00 00 00 00 00 00 00 00 00 06 01 b1 1d 00 ................
0040: 00 00 0f ...
ber_scanf fmt ({m) ber:
ber_dump: buf=0x7f73f6af8810 ptr=0x7f73f6af881e end=0x7f73f6af8856 len=56
0000: 00 84 00 00 00 32 04 06 47 53 53 41 50 49 04 28 .....2..GSSAPI.(
0010: 4e 54 4c 4d 53 53 50 00 01 00 00 00 97 82 08 e2 NTLMSSP.........
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0030: 06 01 b1 1d 00 00 00 0f ........
ber_scanf fmt (m) ber:
ber_dump: buf=0x7f73f6af8810 ptr=0x7f73f6af882c end=0x7f73f6af8856 len=42
0000: 00 28 4e 54 4c 4d 53 53 50 00 01 00 00 00 97 82 .(NTLMSSP.......
0010: 08 e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020: 00 00 06 01 b1 1d 00 00 00 0f ..........
ber_scanf fmt (}}) ber:
ber_dump: buf=0x7f73f6af8810 ptr=0x7f73f6af8856 end=0x7f73f6af8856 len=0
>>> dnPrettyNormal: <>
<<< dnPrettyNormal: <>, <>
conn=1000 op=1 BIND dn="" method=163
do_bind: dn () SASL mech GSSAPI
==> sasl_bind: dn="" mech=GSSAPI datalen=40
SASL [conn=1000] Failure: GSSAPI Error: An unsupported mechanism was
requested (Unknown error)
send_ldap_result: conn=1000 op=1 p=3
send_ldap_result: err=49 matched="" text="SASL(-13): authentication
failure: GSSAPI Failure: gss_accept_sec_context"
send_ldap_response: msgid=11 tag=97 err=49
ber_flush2: 87 bytes to sd 13
0000: 30 55 02 01 0b 61 50 0a 01 31 04 00 04 49 53 41 0U...aP..1...ISA
0010: 53 4c 28 2d 31 33 29 3a 20 61 75 74 68 65 6e 74 SL(-13): authent
0020: 69 63 61 74 69 6f 6e 20 66 61 69 6c 75 72 65 3a ication failure:
0030: 20 47 53 53 41 50 49 20 46 61 69 6c 75 72 65 3a GSSAPI Failure:
0040: 20 67 73 73 5f 61 63 63 65 70 74 5f 73 65 63 5f gss_accept_sec_
0050: 63 6f 6e 74 65 78 74 context
ldap_write: want=87, written=87
0000: 30 55 02 01 0b 61 50 0a 01 31 04 00 04 49 53 41 0U...aP..1...ISA
0010: 53 4c 28 2d 31 33 29 3a 20 61 75 74 68 65 6e 74 SL(-13): authent
0020: 69 63 61 74 69 6f 6e 20 66 61 69 6c 75 72 65 3a ication failure:
0030: 20 47 53 53 41 50 49 20 46 61 69 6c 75 72 65 3a GSSAPI Failure:
0040: 20 67 73 73 5f 61 63 63 65 70 74 5f 73 65 63 5f gss_accept_sec_
0050: 63 6f 6e 74 65 78 74 context
conn=1000 op=1 RESULT tag=97 err=49 text=SASL(-13): authentication
failure: GSSAPI Failure: gss_accept_sec_context
(btw, this is slapd 2.4.21, from a 10.04 ubuntu package)
I believe the application uses Windows SSPI, and I known SSPI supports
several GSSAPI mechanisms, including NTLMSSP and Kerberos. I'm afraid
Windows is auto selecting NTLMSSP cause its running on a pre-windows
2000 domain (non AD, in this case, Samba). Hoping to make windows use
Kerberos instead, I've also tried publishing some SRV records on DNS.
I have sniffed DNS queries from the workstation while the app tries to
login, caught only one _ldap._tcp SRV request, registered that ... and
nothing has changed.
I don't know how could I force the app to use GSSAPI + kerberos
without touching its source code. And I can't find much about a unix
NTLM(SSP)-as-a-mechanism-of-GSSAPI implementation. Maybe there's
something inside samba4 or in Likewise software, but I haven't found
it yet.
So ... does somebody have any advice or info?
Thanks in advance,
Diego Morales
+55 (51) 3024-3568
Propus Informática LTDA.
http://www.propus.com.br
12 years, 11 months
OPENLDAP SYNCREPL
by Borresen, John - 0442 - MITLL
All,
I've read and re-read (not to mentioned googled) configuring SyncRepl in
OpenLDAP dynamic configuration (cn=config)--v2.4.23. Missing something
somewhere. Current logging is set to "256" on both Provider and Consumer.
On my Master/Provider LDAP server seeing the following:
slapd shutdown: waiting for 0 operations/tasks to finish
slapd shutdown: initiated
bdb_modify: dc=group42,dc=ldap
bdb_dn2entry("dc=group42,dc=ldap")
bdb_modify_internal: 0x00000001: dc=group42,dc=ldap
bdb_modify_internal: replace contextCSN
=> entry_encode(0x00000001): dc=group42,dc=ldap
<= entry_encode(0x00000001): dc=group42,dc=ldap
bdb_modify: updated id=00000001 dn="dc=group42,dc=ldap"
send_ldap_result: conn=-1 op=0 p=0
send_ldap_result: err=0 matched="" text=""
====> bdb_cache_release_all
====> bdb_cache_release_all
slapd destroy: freeing system resources.
On my Consumer/Slave Server I am seeing the following:
slapd destroy: freeing system resources.
syncinfo_free: rid=001
slapd stopped.
tail: /var/log/slapd: file truncated
do_syncrep2: rid=001 got search entry without Sync State control
do_syncrepl: rid=001 rc -1 retrying
do_syncrep2: rid=001 got search entry without Sync State control
do_syncrepl: rid=001 rc -1 retrying
do_syncrep2: rid=001 got search entry without Sync State control
do_syncrepl: rid=001 rc -1 retrying
do_syncrep2: rid=001 got search entry without Sync State control
do_syncrepl: rid=001 rc -1 retrying
do_syncrep2: rid=001 got search entry without Sync State control
do_syncrepl: rid=001 rc -1 retrying
do_syncrep2: rid=001 got search entry without Sync State control
do_syncrepl: rid=001 rc -1 retrying
do_syncrep2: rid=001 got search entry without Sync State control
do_syncrepl: rid=001 rc -1 retrying
do_syncrep2: rid=001 got search entry without Sync State control
do_syncrepl: rid=001 rc -1 retrying
do_syncrep2: rid=001 got search entry without Sync State control
do_syncrepl: rid=001 rc -1 retrying
do_syncrep2: rid=001 got search entry without Sync State control
do_syncrepl: rid=001 rc -1 retrying
>From my readings, I understand that the "Sync State Control" error normally
indicates that my provider is not set up correctly. As far as I can tell,
my modules are correctly loaded and the overlays are loaded to the
appropriate database (my case, bdb) to be replicated.
The following is from the Provider/Master LDAP Server:
My olcDatabase-{1}bdb.ldif (truncated):
# more olcDatabase={1}bdb.ldif
dn: olcDatabase={1}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcSuffix: dc=group42,dc=ldap
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=ldapadmin,dc=group42,dc=ldap
olcRootPW:: *******
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
olcDbDirectory: /var/lib/ldap_db/openldap-data
olcDbCacheSize: 1000
...
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass eq
olcDbIndex: sn eq,sub
olcDbIndex: mail eq,sub
olcDbIndex: departmentNumber eq
olcDbIndex: cn,uid eq,sub
olcDbIndex: uidNumber eq
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcDbIndex: ipHostNumber eq
olcDbIndex: gidNumber,memberUID eq
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: 101e6d86-dd1c-4eaa-a26e-d7e201a727f8
creatorsName: cn=config
createTimestamp: 20111219143532Z
olcDbSearchStack: 32
olcAccess: {0} to attrs=userPassword,shadowLastChange by self write by
anonymo
us auth by * none
olcAccess: {1} to * by * read
olcDatabase: {1}bdb
entryCSN: 20120313143637.046410Z#000000#001#000000
modifiersName: cn=config
modifyTimestamp: 20120313143637Z
# ll olcDatabase={1}bdb
total 16
-rw------- 1 ldap ldap 453 Mar 12 10:50 olcOverlay={0}syncprov.ldif
-rw------- 1 ldap ldap 505 Feb 29 11:16 olcOverlay={1}accesslog.ldif
The olcOverlay={0}syncrpov.ldif
# more olcDatabase={1}bdb/olcOverlay={0}syncprov.ldif
dn: olcOverlay={0}syncprov
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpNoPresent: TRUE
structuralObjectClass: olcSyncProvConfig
entryUUID: 8572b589-f594-44a6-91fe-0de741afbcca
creatorsName: cn=admin,cn=config
createTimestamp: 20120224171809Z
olcSpReloadHint: TRUE
olcSpCheckpoint: 1000 60
entryCSN: 20120312145000.123929Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20120312145000Z
The olcOverlay={1}accesslog.ldif:
# more olcDatabase={1}bdb/olcOverlay={1}accesslog.ldif
dn: olcOverlay={1}accesslog
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: {1}accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogPurge: 07+00:00 01+00:00
olcAccessLogSuccess: TRUE
structuralObjectClass: olcAccessLogConfig
entryUUID: eea1e438-6385-4660-807b-bb270eb4843a
creatorsName: cn=admin,cn=config
createTimestamp: 20120229161649Z
entryCSN: 20120229161649.880441Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20120229161649Z
***The following is on the Consumer/Slave Server***
The olcDatabase={2}bdb.ldif (truncated):
# more olcDatabase={2}bdb.ldif
dn: olcDatabase={2}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcSuffix: dc=group42,dc=ldap
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=ldapadmin,dc=group42,dc=ldap
olcRootPW:: *********
olcMonitoring: TRUE
olcDbDirectory: /var/lib/ldap_db/openldap-data
olcDbCacheSize: 1000
...
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass eq
olcDbIndex: cn,uid eq,sub
olcDbIndex: sn eq,sub
olcDbIndex: mail eq,sub
olcDbIndex: departmentNumber eq
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcAccess: {0} to attrs=userPassword,shadowLastChange by self write by
anonymo
us auth by * none
olcAccess: {1} to * by * read
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: e6971058-e0f0-4160-aaca-a18b24d22008
creatorsName: cn=config
createTimestamp: 20120229205835Z
olcDatabase: {2}bdb
olcUpdateRef: ldaps://gp42-admin2.group42.ldap:636
olcMirrorMode: TRUE
olcSyncrepl: {0}rid=1 provider=ldaps://gp42-admin2.group42.ldap:636
bindmethod
=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=******* interva
l=01:00:00:00 searchbase="dc=group42,dc=ldap" logbase="cn=accesslog"
schemach
ecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)"
attrs=
"*,+" syncdata=accesslog starttls=no
tls_cacertdir=/usr/local/openldap-2.4.23
/etc/openldap/cacerts
entryCSN: 20120313150609.224840Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20120313150609Z
Not sure what I am missing, nor where I am missing it. Any assistance would
be helpful.
Dave Borresen
Solaris/Linux Systems Administrator
Surveillance Systems Group
MIT Lincoln Laboratory
244 Wood Street
Lexington, MA 02420
P: 781-981-2954
F: 781-981-5344
john.borresen(a)ll.mit.edu
13 years, 4 months
RE: Re: OpenLDAP 2.3.4 TLS negotiation failure
by Chris Jacobs
Inline...
> -----Original Message-----
> From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-
> technical-bounces(a)OpenLDAP.org] On Behalf Of Tian Zhiying
> Sent: Wednesday, October 23, 2013 2:59 AM
> To: DieterKlünter; openldap-technical
> Subject: Re: Re: OpenLDAP 2.3.4 TLS negotiation failure
>
> Hi Dieter：
>
> Thanks for your quick reply.
> I have changed 'TLS_REQCERT try' and check the commonName of the host
> certificate, the common name is LDAP Server hostname "auth.server.com",
> the following is the query results:
> [root@auth cacerts]# openssl s_client -connect localhost:636 -showcerts -
> state -CAfile /etc/openldap/cacerts/cacert.pem
> CONNECTED(00000003)
> SSL_connect:before/connect initialization
> SSL_connect:SSLv2/v3 write client hello A
> SSL_connect:SSLv3 read server hello A
> depth=0 /C=CN/ST=BJ/L=BJ/O=TS/OU=IT/CN=auth.server.com/emailAddres
> s=tianzy(a)server.com
> verify error:num=18:self signed certificate
> verify return:1
Here is your problem. The host does not trust the SSL cert.
The 'CAfile' you've pointed the openssl command (and the real clients guessing by the path) isn't the CA chain for that SSL cert.
We also use an internal CA that our hosts don't trust globally. Same command and output for me:
[root(a)ldapmaster1.[snip] ~]# echo | openssl s_client -connect ldapmaster1.[snip]:636 -showcerts -state -CAfile /etc/openldap/cacerts/cacert.pem
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=2 C = US, O = [snip], OU = PKI, CN = [snip] Internal Root CA
verify return:1
depth=1 C = US, O = [snip], OU = PKI, CN = [snip] Internal Issuing CA 01
verify return:1
depth=0 C = US, ST = WA, L = Seattle, O = [snip], CN = ldap-vip. [snip], emailAddress = [snip]
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
The command then continues to dump the cert, and the chain certs, as expected.
You must put the entire CA chain from the Root CA to the signing/subordinate CA that signed this SSL cert (if applicable) in x509/PEM format in your 'CAfile' - assuming the Root CA isn't trusted server wide already.
Then try again. Also, make sure to use the name specified in your SSL cert when connecting/testing - mess with your local hosts file if needed.
- chris
> depth=0 /C=CN/ST=BJ/L=BJ/O=TS/OU=IT/CN=auth.server.com/emailAddres
> s=tianzy(a)server.com
> verify return:1
> SSL_connect:SSLv3 read server certificate A
> SSL_connect:SSLv3 read server certificate request A
> SSL_connect:SSLv3 read server done A
> SSL_connect:SSLv3 write client certificate A
> SSL_connect:SSLv3 write client key exchange A
> SSL_connect:SSLv3 write change cipher spec A
> SSL_connect:SSLv3 write finished A
> SSL_connect:SSLv3 flush data
> SSL_connect:SSLv3 read finished A
>
> Now, the /etc/openldap/ldap.conf file:
> URI ldap://ldap.server.com/
> BASE dc=server,dc=com
> TLS_CACERT /etc/openldap/cacerts/cacert.pem
> #SSL ON
> TLS_REQCERT try
>
> But, run "#ldapsearch -x -H ldap://ldap.server.com -ZZ" , I also get the
> following error:
> [root@client cacerts]# ldapsearch -x -H ldap://ldap.server.com -ZZ
> ldap_start_tls: Connect error (-11)
>
> ________________________________________
> Tian Zhiying
>
> From: DieterKlünter
> Date: 2013-10-23 17:35
> To: openldap-technical
> CC: tianzy1225
> Subject: Re: OpenLDAP 2.3.4 TLS negotiation failure
> Am Wed, 23 Oct 2013 16:47:25 +0800
> schrieb "Tian Zhiying" <tianzy1225(a)thundersoft.com>:
>
> > Hi
> >
> > On the LDAP Server , I run following command is ok:
> > #ldapsearch -x -H ldap://ldap.server.com -ZZ
> > #ldapsearch -x -H ldap://ldap.server.com
> >
> > But on my client , I run "#ldapsearch -x -H ldap://ldap.server.com",
> > is ok; Run "#ldapsearch -x -H ldap://ldap.server.com -ZZ" , I get the
> > following error: [root@client cacerts]# ldapsearch -x -H
> > ldap://ldap.server.com -ZZ ldap_start_tls: Connect error (-11)
> >
> > On LDAP Server log file, I get the following error messages:
> > Oct 23 16:41:25 auth slapd[4213]: conn=206 fd=24 ACCEPT from
> > IP=192.168.9.9:45648 (IP=0.0.0.0:389) Oct 23 16:41:25 auth
> > slapd[4213]: conn=206 op=0 STARTTLS Oct 23 16:41:25 auth slapd[4213]:
> > conn=206 op=0 RESULT oid= err=0 text= Oct 23 16:41:25 auth
> > slapd[4213]: conn=206 fd=24 closed (TLS negotiation failure)
> >
> > My client ldap configuration:
> > /etc/openldap/ldap.conf file:
> > URI ldap://ldap.server.com/
> > BASE dc=server,dc=com
> > TLS_CACERT /etc/openldap/cacerts/ca.crt
> > SSL ON
> > TLS_REQCERT demand
>
> Set 'TLS_REQCERT try' and check the commonName of the host
> certificate.
> SSL ON is not an openldap configuration parameter.
> The /etc/ldap.conf file is not a openldap client configuration file,
> but of nss_ldap.
>
> > /etc/ldap.conf file:
> > BASE dc=server,dc=com
> > URI ldap://ldap.server.com
> > SSL ON
> > TLS_CACERT /etc/openldap/cacert/ca.crt
> > TLS_REQCERT demand
> >
> > Any suggestion what cause TLS negotiation failure?
>
> -Dieter
>
> --
> Dieter Klünter | Systemberatung
> http://dkluenter.de
> GPG Key ID:DA147B05
> 53°37'09,95"N
> 10°08'02,42"E
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
11 years, 8 months
Re: Ldap simple bind problems on slaves during network outage (chaining)
by Christian Kratzer
Hi,
On Tue, 3 Dec 2013, Christian Kratzer wrote:
> Hi,
>
> we are currently chasing a strange issue at a customers site where the ldap
> slaves become unresponsive when network connectivity to master ldaps and dns
> servers is lost.
>
> They have a setup of two masters and two slaves at separate sites. There is
> a load balancer sitting in front of the slaves that performs regular health
> checks consisting of binds followed by a search of their binddn.
It seems that this is due to ldap chaining from slave to master running without a timeout and eventually blocking all of slapd.
We use referrals and chaining for slapo-ppolicy and slapo-lastbind (with replication patch from ITS#7721).
I tried to resolve this using olcDbKeepalive and olcDbKeepalive but have not been sucessfull yet.
This is how the chaining backend is configured on the slaves in our lab:
olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {1}ldap
olcDbURI: "ldap://ldaptest0.example.org"
olcDbStartTLS: start starttls=no tls_cert="/usr/local/etc/openldap/certs/server.cert" tls_key="/usr/local/etc/openldap/certs/server.key" tls_cacert="/usr/local/etc/openldap/certs/ca.cert" tls_reqcert=demand tls_crlcheck=none
olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindmethod=simple binddn="cn=chain,ou=system,dc=de,dc=telefonica,dc=com" credentials="XXXXXXXXXXX" keepalive=60:6:10 tls_cert="/usr/local/etc/openldap/certs/server.cert" tls_key="/usr/local/etc/openldap/certs/server.key" tls_cacert="/usr/local/etc/openldap/certs/ca.cert" tls_reqcert=demand tls_crlcheck=none
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: FALSE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 60:6:10
olcDbNetworkTimeout: 3
Any pointers on what we should change to allow quick detection of unreachable olcDbURI ?
Greetings
Christian
> During regular operations the load balancers health checks look as follows
> [1]
>
> Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 fd=36 ACCEPT from
> IP=192.0.2.189:33852 (IP=192.0.2.129:389)
> Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=0 BIND
> dn="cn=keepalive-check-lb,ou=system,dc=example,dc=org" method=128
> Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=0 BIND
> dn="cn=keepalive-check-lb,ou=system,dc=example,dc=org" mech=SIMPLE ssf=0
> Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=0 RESULT tag=97 err=0
> text=
> Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=1 SRCH
> base="ou=system,dc=example,dc=org" scope=1 deref=0
> filter="(cn=keepalive-check-lb)"
> Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=1 ENTRY
> dn="cn=keepalive-check-lb,ou=system,dc=example,dc=org"
> Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=1 SEARCH RESULT tag=101
> err=0 nentries=1 text=
> Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=2 UNBIND
> Dec 2 14:38:05 ldap slapd[57585]: connection_closing: readying
> conn=3924716 sd=36 for close
> Dec 2 14:38:05 ldap slapd[57585]: connection_resched: attempting closing
> conn=3924716 sd=36
> Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 fd=36 closed
>
>
> When they experience a network outage separating the slaves from the masters
> and the dns servers the load balancers are not able to bind the slaves:
>
> Dec 2 14:38:50 ldap slapd[57585]: conn=3924725 fd=44 ACCEPT from
> IP=192.0.2.188:35761 (IP=192.0.2.129:389)
> Dec 2 14:38:50 ldap slapd[57585]: connection_closing: readying
> conn=3924725 sd=44 for close
> Dec 2 14:38:50 ldap slapd[57585]: connection_close: deferring conn=3924725
> sd=44
> Dec 2 14:38:50 ldap slapd[57585]: conn=3924725 op=0 BIND
> dn="cn=keepalive-check-lb,ou=system,dc=example,dc=org" method=128
> Dec 2 14:38:50 ldap slapd[57585]: conn=3924725 op=0 BIND
> dn="cn=keepalive-check-lb,ou=system,dc=example,dc=org" mech=SIMPLE ssf=0
> Dec 2 14:38:50 ldap slapd[57585]: connection_resched: attempting closing
> conn=3924725 sd=44
> Dec 2 14:38:50 ldap slapd[57585]: conn=3924725 fd=44 closed (connection
> lost)
>
> We have not been able to reproduce this problem in a lab setup which is
> supposed to be identical to the production setup. It does not seem to be
> related to the servers not being able to perform reverse mapping on the
> client ips. We run a mixture of 2.4.35 and 2.4.38 on CentOS 6.4. In the lab
> the slaves are able to perform queries just fine without connectivity to the
> masters or to their dns servers.
>
> The servers are currently running with following loglevel:
>
> dn: cn=config
> olcLogLevel: Conns
> olcLogLevel: Stats
> olcLogLevel: Stats2
> olcLogLevel: Sync
>
> It seems we only get to the point where the bind credentials are parsed after
> which the connection is closed.
>
> This could of course be a problem with the load balancer prematurely closing
> the connection.
>
> I am trying to eliminate any causes in the ldap servers.
>
> Any ideas on how to debug this or where we could look.
>
> Greetings
> Christian
>
> [1] dns and ips obfuscated to protect the customer
>
>
--
Christian Kratzer CK Software GmbH
Email: ck(a)cksoft.de Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer
11 years, 7 months