Re: openLDAP upgrate
by Scott Classen
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
9 years, 2 months
Re: top-level data entries not replicating, 2.4.15
by Jonathan Clarke
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
>>
15 years, 3 months
Re: TLS CA Chain Problem
by Iruwen
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 :(
15 years, 1 month
LDAP password information update failed: Insufficient access
by Roberto Gherardi de Candei
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
15 years, 1 month
Re: Problem getting monitor backend and syncrepl overlay to work
by Christian Manal
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
14 years, 8 months
Re: Problem getting monitor backend and syncrepl overlay to work
by Pierangelo Masarati
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.
14 years, 8 months
Syncrepl and MMR
by Borresen, John - 0442 - MITLL
All,
Ok, grasping at straws here. This is the cn=config for mm-server1 as of yesterday.
mm-server1:
dn: cn=config
objectClass: olcGlobal
cn: config
olcConfigFile: /usr/local/openldap/etc/openldap/slapd.conf
olcConfigDir: /usr/local/openldap/etc/openldap/slapd.d
olcArgsFile: /var/lib/openldap/run/slapd.args
olcAttributeOptions: lang-
olcAuthzPolicy: none
olcConcurrency: 0
olcConnMaxPending: 100
olcConnMaxPendingAuth: 1000
olcGentleHUP: FALSE
olcIdleTimeout: 0
olcIndexSubstrIfMaxLen: 4
olcIndexSubstrIfMinLen: 2
olcIndexSubstrAnyLen: 4
olcIndexSubstrAnyStep: 2
olcIndexIntLen: 4
olcListenerThreads: 1
olcLocalSSF: 71
olcPidFile: /var/lib/openldap/run/slapd.pid
olcReadOnly: FALSE
olcSaslSecProps: noplain,noanonymous
olcSockbufMaxIncoming: 262143
olcSockbufMaxIncomingAuth: 16777215
olcThreads: 16
olcTLSCRLCheck: none
olcTLSVerifyClient: never
olcTLSProtocolMin: 0.0
olcToolThreads: 1
olcWriteTimeout: 0
structuralObjectClass: olcGlobal
entryUUID: 1b256f1e-2f15-4538-8a6f-5b021d015e35
creatorsName: cn=config
createTimestamp: 20140122200748Z
olcLogLevel: stats
olcSecurity: tls=0
olcServerID: 1 ldap://mm-server1.example.ldap
olcServerID: 2 ldap://mm-server2.example.ldap
entryCSN: 20140131211613.134974Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140131211613Z
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModuleLoad: {0}syncprov
olcModuleLoad: {1}accesslog
structuralObjectClass: olcModuleList
entryUUID: 1191cf8f-8d46-4f2e-8aba-e65537210029
creatorsName: cn=admin,cn=config
createTimestamp: 20140129175231Z
entryCSN: 20140129175429.232704Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129175429Z
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to * by self write by users read by anonymous auth
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 0
olcReadOnly: FALSE
olcSchemaDN: cn=Subschema
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: 77451682-9629-4753-9a80-5cc0e69a7482
creatorsName: cn=config
createTimestamp: 20140122200748Z
entryCSN: 20140122200748.381523Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20140122200748Z
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by * none
olcAddContentAcl: TRUE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=admin,cn=config
olcRootPW:: <password>
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: d7f25d3b-7ad1-4625-a577-a23a22b5494d
creatorsName: cn=config
createTimestamp: 20140122200748Z
entryCSN: 20140122200748.381523Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20140122200748Z
dn: olcDatabase={1}bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcSuffix: dc=example,dc=ldap
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=ldapadmin,dc=example,dc=ldap
olcRootPW:: <password>
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
olcDbDirectory: /var/lib/openldap/openldap-data
olcDbCacheSize: 1000
olcDbConfig: {0}# $OpenLDAP$
olcDbConfig: {1}# Example DB_CONFIG file for use with slapd(8) BDB/HDB databas
es.
olcDbConfig: {2}#
olcDbConfig: {3}# See the Oracle Berkeley DB documentation
olcDbConfig: {4}# <http://www.oracle.com/technology/documentation/berkeley-d
b/db/ref/env/db_config.html>
olcDbConfig: {5}# for detail description of DB_CONFIG syntax and semantics.
olcDbConfig: {6}#
olcDbConfig: {7}# Hints can also be found in the OpenLDAP Software FAQ
olcDbConfig:: ezh9Iwk8aHR0cDovL3d3dy5vcGVubGRhcC5vcmcvZmFxL2luZGV4LmNnaT9maWxl
PTI+
olcDbConfig: {9}# in particular:
olcDbConfig: {10}# <http://www.openldap.org/faq/index.cgi?file=1075>
olcDbConfig: {11}
olcDbConfig: {12}# Note: most DB_CONFIG settings will take effect only upon re
building
olcDbConfig: {13}# the DB environment.
olcDbConfig: {14}
olcDbConfig: {15}# one 0.25 GB cache
olcDbConfig: {16}set_cachesize 0 268435456 1
olcDbConfig: {17}
olcDbConfig: {18}# Data Directory
olcDbConfig: {19}#set_data_dir db
olcDbConfig: {20}
olcDbConfig: {21}# Transaction Log settings
olcDbConfig: {22}set_lg_regionmax 262144
olcDbConfig: {23}set_lg_bsize 2097152
olcDbConfig: {24}#set_lg_dir logs
olcDbConfig: {25}
olcDbConfig: {26}# Note: special DB_CONFIG flags are no longer needed for "qui
ck"
olcDbConfig:: ezI3fSMgc2xhcGFkZCg4KSBvciBzbGFwaW5kZXgoOCkgYWNjZXNzIChzZWUgdGhl
aXIgLXEgb3B0aW9uKS4g
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbIndex: cn eq,sub
olcDbIndex: uid eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: sn eq,sub
olcDbIndex: mail eq,sub
olcDbIndex: departmentNumber eq
olcDbIndex: automountKey eq
olcDbIndex: memberUid eq
olcDbIndex: printerURI eq
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: 5a87b5f1-c445-4e0e-ba97-6d2d63093704
creatorsName: cn=config
createTimestamp: 20140122200748Z
olcMirrorMode: TRUE
olcLimits: {0}dn.exact="cn=ldapadmin,dc=example,dc=ldap" size=unlimited time=u
nlimited
olcSyncrepl: {0}rid=002 provider=ldap://mm-server2.example.ldap bindmethod=simple binddn="uid=replicator,ou=Admins,dc=example,dc=ldap" credentials=<password>
interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs="*,+" syncdata=accesslog starttls=no
olcSyncrepl: {1}rid=001 provider=ldap://mm-server1.example.ldap bindmethod=simple binddn="uid=replicator,ou=Admins,dc=example,dc=ldap" credentials=<password>
interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs="*,+" syncdata=accesslog starttls=no
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn.exact="cn=ldapadmin,dc=example,dc=ldap" write by dn.exact="uid=replicator,ou=Admins,dc=example,dc=ldap" read by * none
olcAccess: {1}to * by * read
entryCSN: 20140203200931.503493Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140203200931Z
dn: olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpNoPresent: TRUE
structuralObjectClass: olcSyncProvConfig
entryUUID: 04afe1bf-40c7-425a-8b25-74f8687323fc
creatorsName: cn=admin,cn=config
createTimestamp: 20140129180447Z
entryCSN: 20140129180447.701059Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129180447Z
dn: olcOverlay={1}accesslog,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: {1}accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogPurge: 07+00:00 01+00:00
olcAccessLogSuccess: TRUE
structuralObjectClass: olcAccessLogConfig
entryUUID: 54b5fa00-8244-41d3-923d-0743a10bf192
creatorsName: cn=admin,cn=config
createTimestamp: 20140129180903Z
entryCSN: 20140129180903.479192Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129180903Z
dn: olcDatabase={2}bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {2}bdb
olcDbDirectory: /var/lib/openldap/accesslog
olcSuffix: cn=accesslog
olcDbIndex: default eq
olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart
structuralObjectClass: olcBdbConfig
entryUUID: ff63820b-fbe4-4a65-8c00-99e2cc28fca5
creatorsName: cn=admin,cn=config
createTimestamp: 20140129175923Z
olcAccess: {0}to * by dn.exact="uid=replicator,ou=Admins,dc=example,dc=ldap" w
rite by * none
olcLimits: {0}dn.exact="uid=replicator,ou=Admins,dc=example,dc=ldap" time.soft
=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
olcRootDN: uid=replicator,ou=Admins,dc=example,dc=ldap
entryCSN: 20140203190415.581904Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140203190415Z
dn: olcOverlay={0}syncprov,olcDatabase={2}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpNoPresent: TRUE
olcSpReloadHint: TRUE
structuralObjectClass: olcSyncProvConfig
entryUUID: 9246709d-7a9b-41f3-bca8-f665add4e4f2
creatorsName: cn=admin,cn=config
createTimestamp: 20140129180331Z
entryCSN: 20140129180331.702641Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129180331Z
mm-server2:
dn: cn=config
objectClass: olcGlobal
cn: config
olcConfigFile: /usr/local/openldap/etc/openldap/slapd.conf
olcConfigDir: /usr/local/openldap/etc/openldap/slapd.d
olcArgsFile: /var/lib/openldap/run/slapd.args
olcAttributeOptions: lang-
olcAuthzPolicy: none
olcConcurrency: 0
olcConnMaxPending: 100
olcConnMaxPendingAuth: 1000
olcGentleHUP: FALSE
olcIdleTimeout: 0
olcIndexSubstrIfMaxLen: 4
olcIndexSubstrIfMinLen: 2
olcIndexSubstrAnyLen: 4
olcIndexSubstrAnyStep: 2
olcIndexIntLen: 4
olcListenerThreads: 1
olcLocalSSF: 71
olcPidFile: /var/lib/openldap/run/slapd.pid
olcReadOnly: FALSE
olcSaslSecProps: noplain,noanonymous
olcSockbufMaxIncoming: 262143
olcSockbufMaxIncomingAuth: 16777215
olcThreads: 16
olcTLSCRLCheck: none
olcTLSVerifyClient: never
olcTLSProtocolMin: 0.0
olcToolThreads: 1
olcWriteTimeout: 0
structuralObjectClass: olcGlobal
entryUUID: 84a58742-a1ce-4714-a743-14daf3f40c75
creatorsName: cn=config
createTimestamp: 20131218155313Z
olcLogLevel: stats
olcSecurity: tls=0
olcServerID: 1 ldap://mm-server1.example.ldap
olcServerID: 2 ldap://mm-server2.example.ldap
entryCSN: 20140131211906.564734Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140131211906Z
contextCSN: 20140206183618.370299Z#000000#002#000000
contextCSN: 20140121211615.993780Z#000000#004#000000
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModuleLoad: {0}syncprov
olcModuleLoad: {1}accesslog
structuralObjectClass: olcModuleList
entryUUID: ab2c7f52-e10f-4233-aa17-ac8b051defcf
creatorsName: cn=admin,cn=config
createTimestamp: 20140129182320Z
entryCSN: 20140129182642.147840Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129182642Z
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to * by self write by users read by anonymous auth
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 0
olcReadOnly: FALSE
olcSchemaDN: cn=Subschema
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: 46ec808c-285f-442f-8c70-d5bb8c2d39de
creatorsName: cn=config
createTimestamp: 20131218155313Z
entryCSN: 20131218155313.477459Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20131218155313Z
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by * none
olcAddContentAcl: TRUE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=admin,cn=config
olcRootPW:: <password>
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: 4354a8b6-8a36-4804-81f8-14a8550aef74
creatorsName: cn=config
createTimestamp: 20131218155313Z
entryCSN: 20131218155313.477459Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20131218155313Z
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
structuralObjectClass: olcSyncProvConfig
entryUUID: 644d3984-d125-446e-aae2-1ddc541f4661
creatorsName: cn=admin,cn=config
createTimestamp: 20140121191314Z
entryCSN: 20140121191314.076259Z#000000#004#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140121191314Z
dn: olcDatabase={1}bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcSuffix: dc=example,dc=ldap
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=ldapadmin,dc=example,dc=ldap
olcRootPW:: <password>
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
olcDbDirectory: /var/lib/openldap/openldap-data
olcDbCacheSize: 1000
olcDbConfig: {0}# $OpenLDAP$
olcDbConfig: {1}# Example DB_CONFIG file for use with slapd(8) BDB/HDB databas
es.
olcDbConfig: {2}#
olcDbConfig: {3}# See the Oracle Berkeley DB documentation
olcDbConfig: {4}# <http://www.oracle.com/technology/documentation/berkeley-d
b/db/ref/env/db_config.html>
olcDbConfig: {5}# for detail description of DB_CONFIG syntax and semantics.
olcDbConfig: {6}#
olcDbConfig: {7}# Hints can also be found in the OpenLDAP Software FAQ
olcDbConfig:: ezh9Iwk8aHR0cDovL3d3dy5vcGVubGRhcC5vcmcvZmFxL2luZGV4LmNnaT9maWxl
PTI+
olcDbConfig: {9}# in particular:
olcDbConfig: {10}# <http://www.openldap.org/faq/index.cgi?file=1075>
olcDbConfig: {11}
olcDbConfig: {12}# Note: most DB_CONFIG settings will take effect only upon re
building
olcDbConfig: {13}# the DB environment.
olcDbConfig: {14}
olcDbConfig: {15}# one 0.25 GB cache
olcDbConfig: {16}#set_cachesize 0 268435456 1
olcDbConfig: {17}set_cachesize 0 2147483648 1
olcDbConfig: {18}
olcDbConfig: {19}# Data Directory
olcDbConfig: {20}#set_data_dir db
olcDbConfig: {21}
olcDbConfig: {22}# Archive/deletion
olcDbConfig: {23}set_flags DB_LOG_AUTOREMOVE
olcDbConfig: {24}
olcDbConfig: {25}# Transaction Log settings
olcDbConfig: {26}set_lg_regionmax 262144
olcDbConfig: {27}set_lg_bsize 2097152
olcDbConfig: {28}#set_lg_dir logs
olcDbConfig: {29}
olcDbConfig: {30}# Note: special DB_CONFIG flags are no longer needed for "qui
ck"
olcDbConfig:: ezMxfSMgc2xhcGFkZCg4KSBvciBzbGFwaW5kZXgoOCkgYWNjZXNzIChzZWUgdGhl
aXIgLXEgb3B0aW9uKS4g
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbIndex: cn eq,sub
olcDbIndex: uid eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: sn eq,sub
olcDbIndex: departmentNumber eq
olcDbIndex: mail eq,sub
olcDbIndex: automountKey eq
olcDbIndex: memberUid eq
olcDbIndex: printerURI eq
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: 94ff450b-aa70-4507-9ca6-51cdd740ea3e
creatorsName: cn=config
createTimestamp: 20131218155313Z
olcMirrorMode: TRUE
olcLimits: {0}dn.exact="cn=ldapadmin,dc=example,dc=ldap" size=unlimited time=u
nlimited
olcSyncrepl: {0}rid=001 provider=ldap://mm-server1.example.ldap bindmethod=si
mple binddn="uid=replicator,ou=Admins,dc=example,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs="*,+" syncdata=accesslog starttls=no
olcSyncrepl: {1}rid=002 provider=ldap://mm-server2.example.ldap bindmethod=si
mple binddn="uid=replicator,ou=Admins,dc=example,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs="*,+" syncdata=accesslog starttls=no
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou
s auth by dn.exact="cn=ldapadmin,dc=example,dc=ldap" write by dn.exact="uid=r
eplicator,ou=Admins,dc=example,dc=ldap" read
olcAccess: {1}to * by * read
entryCSN: 20140206183618.370299Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140206183618Z
dn: olcOverlay={0}accesslog,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: {0}accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogPurge: 07+00:00 01+00:00
olcAccessLogSuccess: TRUE
structuralObjectClass: olcAccessLogConfig
entryUUID: 6e4e1508-5eb9-4372-bbd1-813f859b0acc
creatorsName: cn=admin,cn=config
createTimestamp: 20140129182321Z
entryCSN: 20140129182321.004272Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129182321Z
dn: olcOverlay={1}syncprov,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {1}syncprov
olcSpNoPresent: TRUE
structuralObjectClass: olcSyncProvConfig
entryUUID: 9108e0db-ba9e-4b40-b743-4016c61582bc
creatorsName: cn=admin,cn=config
createTimestamp: 20140129183014Z
entryCSN: 20140129183014.073365Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129183014Z
dn: olcDatabase={2}bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {2}bdb
olcDbDirectory: /var/lib/openldap/accesslog
olcSuffix: cn=accesslog
olcDbIndex: default eq
olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart
structuralObjectClass: olcBdbConfig
entryUUID: 9b42a346-de9b-42d5-8a3b-3167f80d4b01
creatorsName: cn=admin,cn=config
createTimestamp: 20140129182320Z
olcAccess: {0}to * by dn.exact="uid=replicator,ou=Admins,dc=example,dc=ldap" w
rite by * none
olcLimits: {0}dn.exact="uid=replicator,ou=Admins,dc=example,dc=ldap" time.soft
=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
olcRootDN: uid=replicator,ou=Admins,dc=example,dc=ldap
entryCSN: 20140203190210.968231Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140203190210Z
dn: olcOverlay={0}syncprov,olcDatabase={2}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpNoPresent: TRUE
olcSpReloadHint: TRUE
structuralObjectClass: olcSyncProvConfig
entryUUID: 0366206b-4295-4463-952c-0b233646c24d
creatorsName: cn=admin,cn=config
createTimestamp: 20140129182831Z
entryCSN: 20140129182831.866738Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129182831Z
dn: olcDatabase={3}monitor,cn=config
objectClass: olcDatabaseConfig
olcAccess: {0}to dn.children="cn=monitor" by dn.children="cn=admin,cn=config"
read
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=config
olcMonitoring: TRUE
structuralObjectClass: olcDatabaseConfig
entryUUID: 691d6dfc-82af-4e12-8f03-be93d5d5436b
creatorsName: cn=admin,cn=config
createTimestamp: 20140114170424Z
entryCSN: 20140114170424.436842Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140114170424Z
olcDatabase: {3}monitor
An attempt IS being made between mm-server1 and mm-server2:
Log output from mm-server1:
<= ldap_dn2bv(cn=accesslog)=0
52fb7a31 SRCH "cn=accesslog" 2 052fb7a31 0 0 0
52fb7a31 filter: (objectClass=*)
52fb7a31 attrs:52fb7a31 reqDN52fb7a31 reqType52fb7a31 reqMod52fb7a31 reqNewRDN52fb7a31 reqDeleteOldRDN52fb7a31 reqNewSuperior52fb7a31 entryCSN52fb7a31
52fb7a31 base_candidates: base: "cn=accesslog" (0x00000001)
52fb7a31 send_ldap_result: err=0 matched="" text=""
52fb7a31 send_ldap_result: err=0 matched="" text=""
52fb7a31 connection_get(36)
52fb7a6d connection_get(36)
=> ldap_bv2dn(cn=ldapadmin,dc=example,dc=ldap,0)
<= ldap_bv2dn(cn=ldapadmin,dc=example,dc=ldap)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=ldapadmin,dc=example,dc=ldap)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=ldapadmin,dc=example,dc=ldap)=0
Log output from mm-server2:
52fb7a0f attrs:52fb7a0f *52fb7a0f
52fb7a0f base_candidates: base: "cn=role2,ou=sudoers,dc=example,dc=ldap" (0x00000271)
52fb7a0f send_ldap_result: err=0 matched="" text=""
ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
52fb7a31 do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
52fb7a31 do_syncrepl: rid=001 rc -1 retrying
ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
52fb7a6d do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
52fb7a6d do_syncrepl: rid=001 rc -1 retrying
ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
52fb7aa9 do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
52fb7aa9 do_syncrepl: rid=001 rc -1 retrying
ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
52fb7ae5 do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
52fb7ae5 do_syncrepl: rid=001 rc -1 retrying
Thanks in advance...
John D. Borresen (Dave)
Linux/Unix Systems Administrator
MIT Lincoln Laboratory
Surveillance Systems Group
244 Wood St
Lexington, MA 02420
Email: john.borresen(a)ll.mit.edu<mailto:john.borresen@ll.mit.edu>
10 years, 9 months
Re: Problem with new writetimeout
by Quanah Gibson-Mount
--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
15 years, 4 months
Re: ppolicy overlay - not seeming to function?
by Howard Chu
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/
7 years, 6 months
Re: fedora and openldap
by Rich Megginson
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
>
13 years, 7 months