I recently upgrade from source and this is my procedure. Your's will certainly be different, but it gives you the basic steps.
First check to make sure we have an LDIF backup of entire LDAP database.
1. install new openldap
cd /usr/local/src
wget ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/openldap-2.4.42.tgz
tar zxvf
cd openldap-2.4.42
./configure --enable-bdb=no --enable-hdb=no --enable-mdb --with-tls=openssl --with-cyrus-sasl --enable-spasswd --enable-syslog --enable-modules --enable-cleartext --enable-overlays --enable-accesslog --enable-auditlog --with-threads --enable-shared --enable-ldap --enable-monitor --enable-deref --enable-slapd --enable-ppolicy --enable-memberof
make depend
make
make test
make install <-- be careful after this point, as a "slapd restart" will then use the new code. Must complete step 2 before restarting slapd.
2. copy our custom schema files to new scheme directory
cd /usr/local/etc/openldap
cp custom_schema_files/* schema/
3. start new slapd
/etc/init.d/slapd stop *** to stop currently running old version***
/etc/init.d/slapd start *** new version***
Aug 17 13:23:13 slapd[3881]: slapd shutdown: waiting for 0 operations/tasks to finish
Aug 17 13:23:13 slapd[3881]: slapd stopped.
Aug 17 13:23:17 slapd[4647]: @(#) $OpenLDAP: slapd 2.4.42 (Aug 17 2015 12:47:46) $#012#011root@:/usr/local/src/openldap-2.4.42/servers/slapd
Aug 17 13:23:29 slapd[4648]: slapd starting
Aug 17 13:23:34 slapd[4648]: conn=1000 fd=10 ACCEPT from IP=192.168.1.104:33256 (IP=0.0.0.0:389)
Aug 17 13:23:34 slapd[4648]: conn=1000 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Aug 17 13:23:34 slapd[4648]: conn=1000 op=0 STARTTLS
Aug 17 13:23:34 slapd[4648]: conn=1000 op=0 RESULT oid= err=0 text=
Aug 17 13:23:34 slapd[4648]: conn=1000 fd=10 TLS established tls_ssf=256 ssf=256
Aug 17 13:23:34 slapd[4648]: conn=1000 op=1 BIND dn="uid" method=128
Aug 17 13:23:34 slapd[4648]: conn=1000 op=1 BIND dn="uid" mech=SIMPLE ssf=0
Aug 17 13:23:34 slapd[4648]: conn=1000 op=1 RESULT tag=97 err=0 text=
Aug 17 13:23:34 slapd[4648]: conn=1000 op=2 SRCH base="ou=People," scope=1 deref=0 filter="(&(objectClass=posixAccount)(uid=))"
Aug 17 13:23:34 slapd[4648]: conn=1000 op=2 SRCH attr=userPassword cn gidNumber uidNumber loginShell objectClass gecos uid homeDirectory
Aug 17 13:23:34 slapd[4648]: conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OK it appears that OpenLDAP 2.4.42 is running.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
###########################################################
#################### BACK OUT PLAN ####################
###########################################################
if things go badly revert by going to previous /usr/local/src/openldap directory and doing a
make install
/usr/local/src/openldap-2.4.xxx
check schema files and restart slapd
> On Aug 27, 2015, at 6:47 AM, mdii <mdii.alias(a)gmail.com> wrote:
>
> Hi all,
>
> I'm starting as an openLDAP administrator, and here in my company they are running the openLDAP 2.4.35.
>
> - I found this avec la commande ldapsearch -VV
>
> I want to upgrade to the letest version available (2.4.42), how should I procede ?
>
> I read that I just need to download the new package, stop the server, install the new version and then restart the server, is that all?
>
>
> Thanks in advance for your help,
> Marc
On 20/08/2009 14:39, Brian Neu wrote:
> Forgive me if pasting here is bad etiquette.
>
>
> <consumer slapd.conf>
>
> 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
> include /etc/openldap/schema/samba.schema
>
> allow bind_v2
>
> pidfile /var/run/openldap/slapd.pid
> argsfile /var/run/openldap/slapd.args
>
> TLSCACertificateFile /etc/openldap/cacerts/cavictory2.crt
> TLSCertificateFile /etc/openldap/keys/victory3cert.pem
> TLSCertificateKeyFile /etc/openldap/keys/victory3key.pem
>
> database hdb
> suffix "dc=srg,dc=com"
> checkpoint 1024 15
> rootdn "cn=Manager,dc=srg,dc=com"
>
> rootpw {MD5}blah
>
> directory /var/lib/ldap
>
> 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
>
> syncrepl rid=0
> provider=ldap://victory2.srg.com:389
> bindmethod=simple
> starttls=critical
> binddn="cn=replicator,dc=srg,dc=com"
> credentials=blah
> searchbase="dc=srg,dc=com"
> logbase="cn=accesslog"
> schemachecking=on
> type=refreshAndPersist
> retry="60 +"
> syncdata=accesslog
I don't see anything wrong with this - although I'm not very familiar
with accesslog configuration.
Does the "cn=replicator,dc=srg,dc=com" have full access on the provider
to read necessary data?
> updateref ldaps://victory2.srg.com
>
> database monitor
>
> access to *
> by dn.exact="cn=Manager,dc=srg,dc=com" write
> by * none
>
> </consumer slapd.conf>
>
>
> --- On Thu, 8/20/09, Jonathan Clarke<jonathan(a)phillipoux.net> wrote:
>
>> From: Jonathan Clarke<jonathan(a)phillipoux.net>
>> Subject: Re: top-level data entries not replicating, 2.4.15
>> To: "Brian Neu"<proclivity76(a)yahoo.com>
>> Cc: openldap-technical(a)openldap.org
>> Date: Thursday, August 20, 2009, 8:02 AM
>> On 19/08/2009 19:29, Brian Neu
>> wrote:
>>> Even with no logfilter on the consumer,
>>>
>> cn=replicator,dc=domain,dc=com&
>>>
>> sambaDomainName=SRG,dc=domain,dc=com
>>>
>>> don't replicate, even after wiping the database and
>> restarting. Everything else seems to replicate fine.
>>>
>>> How do I get top-level data entries to replicate?
>>
>> This really depends on your syncrepl configuration on the
>> consumer.
>> If you provide it here, maybe we can take a look.
>>
>> Aside from that, the latest version, 2.4.17, contains a few
>> fixes that
>> might help with this problem.
>>
>> Jonathan
>>
Quanah Gibson-Mount schrieb:
> --On Monday, October 12, 2009 11:18 AM -0700 Quanah Gibson-Mount
> <quanah(a)zimbra.com> wrote:
>
>> --On Monday, October 12, 2009 3:02 PM +0200 Iruwen <iruwen(a)gmx.net>
>> wrote:
>>
>>
>>> Seems like the ca-bundle wouldn't be used at all, does slapd expect a
>>> different format or something?
>>>
>>> Maybe someone could shed some light on this for me, thanks a lot in
>>> advance.
>>
>> You need to provide the full train of trust when using Comodo certs.
>
> s/train/chain/ :P
So... I'd have to change what exactly? ;)
I created the ca-bundle following the information this page:
https://support.comodo.com/index.php?_m=knowledgebase&_a=viewarticle&kbarti…
And the format generally seems to be correct since it works for HTTPS
(and SMTP with TLS in postfix, just tried that too).
HTTPS:
office:/etc/ssl/private# openssl s_client -connect localhost:443
CONNECTED(00000003)
depth=3 /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust
External CA Root
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=mydomain.de
i:/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA
Limited/CN=PositiveSSL CA
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA
Limited/CN=PositiveSSL CA
i:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
2 s:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust
External CA Root
3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust
External CA Root
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust
External CA Root
SMTP with TLS:
office:/etc/ssl/private# openssl s_client -connect localhost:25
-starttls smtp
CONNECTED(00000003)
depth=3 /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust
External CA Root
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=mydomain.de
i:/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA
Limited/CN=PositiveSSL CA
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA
Limited/CN=PositiveSSL CA
i:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
2 s:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust
External CA Root
3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust
External CA Root
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust
External CA Root
But LDAPS:
office:/etc/ssl/private# openssl s_client -connect localhost:636
CONNECTED(00000003)
depth=0 /OU=Domain Control Validated/OU=PositiveSSL/CN=mydomain.de
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /OU=Domain Control Validated/OU=PositiveSSL/CN=mydomain.de
verify error:num=27:certificate not trusted
verify return:1
depth=0 /OU=Domain Control Validated/OU=PositiveSSL/CN=mydomain.de
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=mydomain.de
i:/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA
Limited/CN=PositiveSSL CA
I don't get it :(
Hi i'm a newbie
doesn't succeed has change the password of the on maturity consumer of the
password
help where is my error
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.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 /usr/lib/openldap
# modules available in openldap-servers-overlays RPM package:
# moduleload accesslog.la
# moduleload auditlog.la
# moduleload denyop.la
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload lastmod.la
# moduleload pcache.la
# moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload smbk5pwd.la
# moduleload syncprov.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la
# modules available in openldap-servers-sql RPM package:
# moduleload back_sql.la
# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client
software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
TLSCACertificateFile /etc/openldap/cacerts/cacert.pem
TLSCertificateFile /etc/openldap/certs/slapdcert.pem
TLSCertificateKeyFile /etc/openldap/certs/slapdkey.pem
# 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!
#access to dn.subtree="ou=Utenti,dc=ldap=dc=inail,dc=it"
# by dn="cn=adminU,ou=Utenti,dc=ldap=dc=inail,dc=it"
# by dn="cn=anonymous,dc=ldap,dc=inail.dc=it" read
# by self write
# by anonymous auth
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
database bdb
suffix "dc=ldap,dc=inail,dc=it"
rootdn "cn=admin,dc=ldap,dc=inail,dc=it"
#rootpw {SSHA}PU4cboMpOsn7YBWDaP9xwRdP82k5O7gV
rootpw {SSHA}mcFkKPNevo77jAq0+MdWNmX7F7roGk+v
# 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
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
thank's
--
RGdC
--
RGdC
DeMoNs(a)web.de schrieb:
> Hi all,
>
> i have a problem getting openldap to run monitor backend AND syncrepl
> overlay.
> i'm running freebsd-7.2-release-p6 in combination with
> openldap-server-2.4.19 with sasl support compiled in.
>
> i use the following slapd config:
>
> include /usr/local/etc/openldap/schema/core.schema
> include /usr/local/etc/openldap/schema/cosine.schema
> include /usr/local/etc/openldap/schema/nis.schema
> include /usr/local/etc/openldap/schema/inetorgperson.schema
> include /usr/local/etc/openldap/schema/misc.schema
> include /usr/local/etc/openldap/schema/ldapns.schema
> include /usr/local/etc/openldap/schema/radius.schema
>
> pidfile /var/run/openldap/slapd.pid
> argsfile /var/run/openldap/slapd.args
> logfile /var/log/slapd.log
>
> password-hash {SSHA}
> modulepath /usr/local/libexec/openldap
> moduleload back_bdb
> moduleload back_monitor
>
> access to dn.base="" by * read
> access to dn.base="cn=Subschema" by * read
> access to *
> by ssf=128 dn="cn=admin,dc=example,dc=de" write
> by dn="cn=admin,dc=example,dc=de" peername.ip=127.0.0.1 write
> by ssf=96 dn="cn=nssadmin,dc=example,dc=de" read
> by dn="cn=nssadmin,dc=example,dc=de" peername.ip=127.0.0.1 read
> by anonymous auth
> by * none
> access to attrs=userPassword
> by self write
> by anonymous auth
> by * none
>
> database bdb
> suffix "dc=example,dc=de"
> rootdn "dc=example,dc=de"
> directory /var/db/openldap-data
> index objectClass,entryCSN,entryUUID eq
> index uid pres,eq,sub
> index memberUID eq
> index uidNumber,gidNumber eq
> index host eq
>
> database monitor
> rootdn "cn=monitoring,cn=Monitor"
> rootpw monitoring
>
> access to dn.subtree="cn=Monitor"
> by dn="cn=nssadmin,dc=example,dc=de"
> by * none
>
> syncrepl rid=041
> provider=ldap://ldap-master.example.de
> type=refreshOnly
> interval=00:00:35:00
> searchbase="dc=example,dc=de"
> schemachecking=off
> bindmethod=simple
> starttls=yes
> binddn="cn=syncuser,dc=example,dc=de"
> credentials="strongsecretpassword"
>
> TLSCertificateFile /usr/local/etc/openldap/ssl/ldap-crt.pem
> TLSCertificateKeyFile /usr/local/etc/openldap/ssl/ldap-key.pem
> TLSCACertificateFile /usr/local/etc/openldap/ssl/cacert.pem
>
> loglevel 256
>
> now, when i run slaptest i receive following error:
>
> /usr/local/etc/openldap/slapd.conf: line 59: database monitor does not
> support operations required for syncrepl
> slaptest: bad configuration file!
>
> Line 59 corresponds to the credentials option in the synrepl statement.
> i can't figure out whats wrong, so if anyone can point me in the right
> direction that would be really helpful.
>
> thanks in advance,
> david
>
Hi David,
from the slapd.conf(5) manpage:
The slapd.conf file consists of a series of global confi-
guration options that apply to slapd as a whole (including
all backends), followed by zero or more database backend
definitions that contain information specific to a backend
instance.
Which means that your syncrepl stuff is placed in the back-monitor
specific part of the configuration. Put the syncrepl part before the
monitor definition and behind the bdb definition.
Regards,
Christian Manal
DeMoNs(a)web.de wrote:
> Hi all,
>
> i have a problem getting openldap to run monitor backend AND syncrepl
> overlay.
> i'm running freebsd-7.2-release-p6 in combination with
> openldap-server-2.4.19 with sasl support compiled in.
>
> i use the following slapd config:
>
> include /usr/local/etc/openldap/schema/core.schema
> include /usr/local/etc/openldap/schema/cosine.schema
> include /usr/local/etc/openldap/schema/nis.schema
> include /usr/local/etc/openldap/schema/inetorgperson.schema
> include /usr/local/etc/openldap/schema/misc.schema
> include /usr/local/etc/openldap/schema/ldapns.schema
> include /usr/local/etc/openldap/schema/radius.schema
>
> pidfile /var/run/openldap/slapd.pid
> argsfile /var/run/openldap/slapd.args
> logfile /var/log/slapd.log
>
> password-hash {SSHA}
> modulepath /usr/local/libexec/openldap
> moduleload back_bdb
> moduleload back_monitor
>
> access to dn.base="" by * read
> access to dn.base="cn=Subschema" by * read
> access to *
> by ssf=128 dn="cn=admin,dc=example,dc=de" write
> by dn="cn=admin,dc=example,dc=de" peername.ip=127.0.0.1 write
> by ssf=96 dn="cn=nssadmin,dc=example,dc=de" read
> by dn="cn=nssadmin,dc=example,dc=de" peername.ip=127.0.0.1 read
> by anonymous auth
> by * none
> access to attrs=userPassword
> by self write
> by anonymous auth
> by * none
>
> database bdb
> suffix "dc=example,dc=de"
> rootdn "dc=example,dc=de"
> directory /var/db/openldap-data
> index objectClass,entryCSN,entryUUID eq
> index uid pres,eq,sub
> index memberUID eq
> index uidNumber,gidNumber eq
> index host eq
>
> database monitor
> rootdn "cn=monitoring,cn=Monitor"
> rootpw monitoring
>
> access to dn.subtree="cn=Monitor"
> by dn="cn=nssadmin,dc=example,dc=de"
> by * none
>
> syncrepl rid=041
> provider=ldap://ldap-master.example.de
> type=refreshOnly
> interval=00:00:35:00
> searchbase="dc=example,dc=de"
> schemachecking=off
> bindmethod=simple
> starttls=yes
> binddn="cn=syncuser,dc=example,dc=de"
> credentials="strongsecretpassword"
>
> TLSCertificateFile /usr/local/etc/openldap/ssl/ldap-crt.pem
> TLSCertificateKeyFile /usr/local/etc/openldap/ssl/ldap-key.pem
> TLSCACertificateFile /usr/local/etc/openldap/ssl/cacert.pem
>
> loglevel 256
>
> now, when i run slaptest i receive following error:
>
> /usr/local/etc/openldap/slapd.conf: line 59: database monitor does not
> support operations required for syncrepl
> slaptest: bad configuration file!
>
> Line 59 corresponds to the credentials option in the synrepl statement.
> i can't figure out whats wrong, so if anyone can point me in the right
> direction that would be really helpful.
"Line 59" means the whole statement ending at line 59, so in general the
error can be anywhere in the statement. In this case, the error is the
statement itself. As the error message is saying, back-monitor is
missing some essential function that is required by syncrepl (I bet
bi_op_add()). What's puzzling me is: back-monitor is (almost)
read-only, and contains mostly dynamically generated information on the
state of a server; what's the purpose of replicating it? Your
configuration makes no sense.
p.
--On Monday, July 20, 2009 1:37 PM +0200 Christian Manal
<moenoel(a)informatik.uni-bremen.de> wrote:
> Hi everyone,
>
> I have noticed a problem regarding the new writetimeout feature in
> OpenLDAP 2.4.17. I have a setup with one master and four replicas running
> on Solaris 10, using the hdb-backend with BDB 4.4 from the opencsw
> repository. Clients are Sun, Linux and Mac boxes in every possible
> variation.
>
> I updated my servers last Friday from version 2.4.15 and now some
> cronjobs accessing the directory were sporadically failing over the
> weekend.
>
> I monitored the server logs (log level 'stats') while running the
> involved scripts repeatedly and got something like the following results
> after fail-runs on all servers:
> (IPs and DNs altered)
>
>> Jul 20 11:42:43 ldapserver slapd[9053]: [ID 848112 local4.debug]
>> conn=12479 fd=79 ACCEPT from IP=192.168.1.1:50210 (IP=0.0.0.0:389) Jul
>> 20 11:42:43 ldapserver slapd[9053]: [ID 270379 local4.debug] conn=12479
>> op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jul 20 11:42:43 ldapserver
>> slapd[9053]: [ID 560212 local4.debug] conn=12479 op=0 STARTTLS Jul 20
>> 11:42:43 ldapserver slapd[9053]: [ID 875301 local4.debug] conn=12479
>> op=0 RESULT oid= err=0 text= Jul 20 11:42:43 ldapserver slapd[9053]: [ID
>> 105384 local4.debug] conn=12479 fd=79 TLS established tls_ssf=256 ssf=256
>> Jul 20 11:42:43 ldapserver slapd[9053]: [ID 215403 local4.debug]
>> conn=12479 op=1 BIND dn="uid=dummyuser,ou=System,dc=example,dc=com"
>> method=128 Jul 20 11:42:43 ldapserver slapd[9053]: [ID 600343
>> local4.debug] conn=12479 op=1 BIND
>> dn="uid=dummyuser,ou=System,dc=example,dc=com" mech=SIMPLE ssf=0 Jul 20
>> 11:42:43 ldapserver slapd[9053]: [ID 588225 local4.debug] conn=12479
>> op=1 RESULT tag=97 err=0 text= Jul 20 11:42:43 ldapserver slapd[9053]:
>> [ID 469902 local4.debug] conn=12479 op=2 SRCH
>> base="ou=people,dc=example,dc=com" scope=2 deref=2
>> filter="(objectClass=posixAccount)" Jul 20 11:42:43 ldapserver
>> slapd[9053]: [ID 744844 local4.debug] conn=12479 op=2 SRCH attr=uid
>> userpassword uidnumber gidnumber gecos homedirectory loginshell Jul 20
>> 11:43:00 ldapserver slapd[9053]: [ID 485650 local4.debug] conn=12479
>> fd=79 closed (writetimeout)
>
>
> I don't have the writetimeout keyword configured on any of the boxes and
> the affected script doesn't do any writes anyway. Also, the problem only
> seems to arise if the client takes a while to process a search result.
> The failing scripts are Net::LDAP based Perl scripts running on some old
> SPARC boxes, so it took them up to half a minute and more to complete.
>
> Setting writetimeout to a high enough value seems solve the problem, but
> referring to the docs, this shouldn't happen with the keyword unset or
> set to 0.
>
> Is this a bug or did I miss something? Did anyone else encounter this so
> far?
File an ITS:
<http://www.openldap.org/its/> and include your server config.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
John Cooter wrote:
> So, before I ask my question, here are my referenced objects, from a "slapcat -n 0":
> dn: olcDatabase={2}hdb,cn=config
> objectClass: olcDatabaseConfig
> objectClass: olcHdbConfig
> olcDatabase: {2}hdb
> olcDbDirectory: /var/lib/ldap
> olcDbIndex: objectClass eq,pres
> olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub
> structuralObjectClass: olcHdbConfig
> entryUUID: eb941fcc-bef3-1036-9d74-0d6e032eb747
> creatorsName: cn=config
> createTimestamp: 20170426174545Z
> olcAccess: {0}to dn.base="" by self write by dn="cn=ldapadmin,dc=XXXXXXX
> ,dc=net" write by * read
> olcAccess: {1}to * by self write by dn="cn=ldapadmin,dc=XXXXXXX,dc=net" w
> rite by * read
> olcAccess: {2}to dn.subtree="ou=mail,ou=hosting,dc=XXXXXXX,dc=net" attrs=
> userPassword,UseAppPassword,children,entry,objectClass,cn,sn,uid by self w
> rite by dn="cn=ldapadmin,dc=XXXXXXX,dc=net" write by * auth by * read
> olcSuffix: dc=XXXXXXXX,dc=net
> olcRootDN: cn=ldapadmin,dc=XXXXXXX,dc=net
> olcRootPW:: e1NTSEF9K2p6YnhXL0xQTDJKZFFIZitac3l6RzVXaEN3UEhQUkc=
> entryCSN: 20170508155547.001404Z#000000#000#000000
> modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> modifyTimestamp: 20170508155547Z
>
> dn: olcOverlay={0}ppolicy,olcDatabase={2}hdb,cn=config
> objectClass: olcOverlayConfig
> objectClass: olcPPolicyConfig
> olcOverlay: {0}ppolicy
> olcPPolicyDefault: cn=passwordDefault,ou=policies,dc=XXXXXXX,dc=net
> olcPPolicyHashCleartext: FALSE
> olcPPolicyUseLockout: FALSE
> olcPPolicyForwardUpdates: FALSE
> structuralObjectClass: olcPPolicyConfig
>
> the passwordDefaul policy exists in the correct location, and appears to apply to all user objects BUT
>
> when I change a user object to a value that either violates the base policy (say, has only 4 characters instead of 5 or more), or would not conform to the check_password.so function, as established by various outside sources, it does not give me an error of any kind, and instead, writes the password to the DB and writes the following to the log:
Reread the slapo-ppolicy(5) manpage. You're making modifications using the
rootDN, which is documented to ignore any configured policies.
> May 10 11:00:05 ldapv slapd[1984]: conn=1007 op=0 EXT oid=1.3.6.1.4.1.1466.20037
> May 10 11:00:05 ldapv slapd[1984]: conn=1007 op=0 STARTTLS
> May 10 11:00:05 ldapv slapd[1984]: conn=1007 op=0 RESULT oid= err=0 text=
> May 10 11:00:06 ldapv slapd[1984]: conn=1007 fd=11 TLS established tls_ssf=256 ssf=256
> May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=1 BIND dn="cn=ldapadmin,dc=XXXXXXX,dc=net" method=128
> May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=1 BIND dn="cn=ldapadmin,dc=XXXXXXX,dc=net" mech=SIMPLE ssf=0
> May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=1 RESULT tag=97 err=0 text=
> May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=2 MOD dn="uid=USER,cn=TESTDOMAIN.com,ou=domain,ou=mail,ou=hosting,dc=XXXXXXX,dc=net"
> May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=2 MOD attr=userPassword
> May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=2 RESULT tag=103 err=0 text=
>
> And the entry, as referenced by phpLDAPadmin, appears to correspond to the "bad" password. How can I go about confirming that the password policy is being enforced?
Bind as a regular user identity instead of the rootDN when making a change.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
On 04/12/2011 01:14 PM, Judith Flo Gaya wrote:
> Hello Quanah,
>
>
> On 4/12/11 7:28 PM, Quanah Gibson-Mount wrote:
>> --On Tuesday, April 12, 2011 7:10 PM +0200 Judith Flo
>> Gaya<jflo(a)imppc.org>
>> wrote:
>>> ( I installed a newer version of openldap in my server as the RH6
>>> uses an
>>> old one, I compiled it with tls and openssl)
>>>
>>> From the client I do :
>>> ldapsearch -x -ZZ -d1 -h curri0.imppc.local:636
>> This is a startTLS request. You are using LDAPS. This will never work.
>>
>> Try
>>
>> ldapsearch -x -H ldaps://curri0.imppc.local:636/
>
> It doesn't work either, still complains about not being able to
> contact the server.
> But now I see a different error:
>
> ldapsearch -x -H ldaps://curri0.imppc.local:636 -d1
> ldap_url_parse_ext(ldaps://curri0.imppc.local:636)
> ldap_create
> ldap_url_parse_ext(ldaps://curri0.imppc.local:636/??base)
> ldap_sasl_bind
> ldap_send_initial_request
> ldap_new_connection 1 1 0
> ldap_int_open_connection
> ldap_connect_to_host: TCP curri0.imppc.local:636
> ldap_new_socket: 3
> ldap_prepare_socket: 3
> ldap_connect_to_host: Trying 172.19.5.13:636
> ldap_pvt_connect: fd: 3 tm: -1 async: 0
> TLS: could not initialize moznss using security dir
> /etc/openldap/cacerts - error -8174:Unknown code ___f 18.
> TLS: could not add the certificate (null) - error -8192:Unknown code
> ___f 0.
> TLS: error: connect - force handshake failure -1 - error -8054:Unknown
> code ___f 138
> TLS: can't connect: .
> ldap_err2string
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
If you are using /usr/bin/ldapsearch on Fedora 14 and later, it is
linked with Mozilla NSS instead of openssl. But openldap with moznss
works the same as it does with openssl.
Do you have your CA cert on the client machine? If so, did you specify
it in /etc/openldap/ldap.conf or ~/.ldaprc? If not, you can also
specify it on the command line like this:
LDAPTLS_CACERT=/path/to/ca_cert.pem ldapsearch -x -H
ldaps://curri0.imppc.local:636/
See http://www.openldap.org/faq/data/cache/1514.html for information
about how to use Mozilla NSS.
>
>
> and this is what the server says:
> slap_listener_activate(8):
> >>> slap_listener(ldaps://curri0.imppc.local:636)
> connection_get(12): got connid=1008
> connection_read(12): checking for input on id=1008
> TLS trace: SSL_accept:before/accept initialization
> TLS trace: SSL_accept:SSLv3 read client hello A
> TLS trace: SSL_accept:SSLv3 write server hello A
> TLS trace: SSL_accept:SSLv3 write certificate A
> TLS trace: SSL_accept:SSLv3 write server done A
> TLS trace: SSL_accept:SSLv3 flush data
> TLS trace: SSL_accept:error in SSLv3 read client certificate A
> TLS trace: SSL_accept:error in SSLv3 read client certificate A
> connection_get(12): got connid=1008
> connection_read(12): checking for input on id=1008
> TLS trace: SSL3 alert read:fatal:bad certificate
> TLS trace: SSL_accept:failed in SSLv3 read client certificate A
> TLS: can't accept: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3
> alert bad certificate.
> connection_read(12): TLS accept failure error=-1 id=1008, closing
> connection_close: conn=1008 sd=12
>
> any clue? the error on the client side seems to indicate that the
> client is trying to use the nss from the mozilla but I never meant to
> this, openssl is installed.
> Thanks a lot for your help.
> j
>> instead.
>>
>> --Quanah
>>
>>
>> --
>>
>> Quanah Gibson-Mount
>> Sr. Member of Technical Staff
>> Zimbra, Inc
>> A Division of VMware, Inc.
>> --------------------
>> Zimbra :: the leader in open source messaging and collaboration
>