slurpd replication problem.
by Choi, Justin
I am seeing invalid credential error logs a lot.
Could you guys let me know how to solve this issue?
Thanks.
Server Log(slurpd -d 2)
Replicated Log (/usr/sbin/slapd -u ldap -d 2 -h ldap:///)
Slapd.conf
database bdb
suffix "dc=ijji,dc=com"
rootdn "cn=Manager,dc=ijji,dc=com"
rootpw {SSHA}EpkPadkANDlpX7yfcsa2WbA+bSssh0S4
# 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/ijji.com
# 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
#updatedn cn=Replication Manager,dc=ijji,dc=com
#updateref ldap://ca1xc115.ijji.com
access to attrs=userPassword
by self write
by anonymous auth
by dn.base="cn=Manager,dc=ijji,dc=com" write
by * none
access to *
by self write
by dn.base="cn=Manager,dc=ijji,dc=com" write
by * read
access to attrs=userPassword
by self write
by anonymous auth
by dn.base="cn=Replication Manager,dc=ijji,dc=com" write
by * none
access to *
by self write
by dn.base="cn=Replication Manager,dc=ijji,dc=com" write
by * read
# Replicas of this database
replogfile /var/lib/ldap/openldap-master-replog
replica host=ca1xc115.ijji.com:389
binddn="cn=Replication Manager,dc=ijji,dc=com"
bindmethod=simple credentials=skdltmwkq
loglevel -1
database bdb
suffix "dc=ijji,dc=com"
rootdn "cn=Manager,dc=ijji,dc=com"
rootpw {SSHA}EpkPadkANDlpX7yfcsa2WbA+bSssh0S4
# 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/ijji.com
# 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
updatedn "cn=Replication Manager,dc=ijji,dc=com"
updateref ldap://ca1xc124.ijji.com
access to attrs=userPassword
by self write
by anonymous auth
by dn.base="cn=Manager,dc=ijji,dc=com" write
by * none
access to *
by self write
by dn.base="cn=Manager,dc=ijji,dc=com" write
by * read
access to attrs=userPassword
by self write
by anonymous auth
by dn.base="cn=Replication Manager,dc=ijji,dc=com" write
by * none
access to *
by self write
by dn.base="cn=Replication Manager,dc=ijji,dc=com" write
by * read
# 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
loglevel -1
Justin Choi
Sr. Security Engineer
NHN USA, Inc.
3353 Michelson Suite 250
Irvine, CA 92612
Mobile (408) 329-8554
MSN iD: counterhacker(a)live.com <mailto:amyoh79@hotmail.com>
Office (949) 863-1292 ext 256
Fax (949) 863-9418
17 years
n-way multi master setup
by Joshua Miller
Good morning,
I am attempting to follow the admin guide in setting up n-way
multi-master replication.
re:
http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master
I'm running OpenLDAP 2.4.7, from Buchan Milne's RPMs, DB 4.6 on CentOS 5.1.
I have setup a working directory on both nodes, then removed all data to
start fresh, converting my slapd.conf to a slapd.d with slaptest.
ie,
# /etc/init.d/ldap stop
# rm -rf /var/lib/ldap/*
# slaptest -f slapd.conf -F slapd.d
# /etc/init.d/ldap start
Since I already had cn=config setup from my slapd.conf file, I skipped
that part of the admin guide's instructions. I then modified the
directory with the following LDIF, replacing the URI and credential
values with my environment specific ones:
dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 1 ldap://ldapserver1
olcServerID: 2 ldap://ldapserver2
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001 provider=ldap://ldapserver2
binddn="cn=config" bindmethod=simple
credentials=secret searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 5" timeout=1
olcSyncRepl: rid=002 provider=ldap://ldapserver1
binddn="cn=config" bindmethod=simple
credentials=secret searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 5" timeout=1
-
add: olcMirrorMode
olcMirrorMode: TRUE
I received no errors on running the modify command to add the changes
from this LDIF.
I then attempted to make a change and have it replicated, very simple to
start with, using the following LDIF:
dn: cn=config
changetype: modify
replace: olcSecurity
olcSecurity: ssf=256
Once I successfully made this change on ldapserver1, I received the
following errors in the logs of ldapserver2 (continuously repeating):
ldapserver2 slapd2.4[12172]: conn=15 op=0 EXT oid=1.3.6.1.4.1.1466.20037
ldapserver2 slapd2.4[12172]: conn=15 op=0 STARTTLS
ldapserver2 slapd2.4[12172]: conn=15 op=0 RESULT oid= err=0 text=
ldapserver2 slapd2.4[12172]: conn=15 fd=17 ACCEPT from
IP=10.12.2.25:4174 (IP=0.0.0.0:389)
ldapserver2 slapd2.4[12172]: conn=15 fd=17 TLS established tls_ssf=256
ssf=256
ldapserver2 slapd2.4[12172]: conn=15 op=1 BIND dn="cn=config" method=128
ldapserver2 slapd2.4[12172]: conn=15 op=1 BIND dn="cn=config"
mech=SIMPLE ssf=0
ldapserver2 slapd2.4[12172]: conn=15 op=1 RESULT tag=97 err=0 text=
ldapserver2 slapd2.4[12172]: conn=15 op=2 SRCH base="cn=config" scope=2
deref=0 filter="(cn=config)"
ldapserver2 slapd2.4[12172]: conn=15 op=2 SEARCH RESULT tag=101 err=0
nentries=1 text=
ldapserver2 slapd2.4[12172]: conn=15 op=3 UNBIND
ldapserver2 slapd2.4[12172]: conn=15 fd=17 closed
ldapserver2 slapd2.4[12172]: olcServerID: value #1: <olcServerID>
unknown factor <80>A<C2>
ldapserver2 slapd2.4[12172]: olcServerID: value #1: <olcServerID>
unknown factor <D0>A<C2>
ldapserver2 slapd2.4[12172]: null_callback : error code 0x50
ldapserver2 slapd2.4[12172]: syncrepl_entry: rid=002 be_modify failed (80)
ldapserver2 slapd2.4[12172]: do_syncrepl: rid=002 retrying (4 retries left)
ldapserver2 slapd2.4[12172]: olcServerID: value #1: <olcServerID>
unknown factor
ldapserver2 slapd2.4[12172]: olcServerID: value #1: <olcServerID>
unknown factor
ldapserver2 slapd2.4[12172]: null_callback : error code 0x50
Any idea what I may have done wrong here?
Thanks!
Josh Miller, RHCE
17 years, 6 months
Re: LDAP Crafted Search Request Access Allowed
by Net Warrior
Hi Andrew, I've got some updates.
1 ) Added tls_reqcert demand to the client side
2 ) Configured a user to bind instead of anonymous
binddn cn=ldapuser,Ou=Users,dc=server,dc=com
bindpwd :$6$oZ8qYohy$lU0sYJXInOO1ISO4WKgzeuDyyFh9a
3 ) Added olcTLSVerifyClient:demand to server side:
Now as I can see this is good, the TLS is established with a strong
security factor of 256.
Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 fd=252 ACCEPT from
IP=X.X.X.X:58387 (IP=0.0.0.0:389)
Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=0 STARTTLS
Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=0 RESULT oid= err=0
text=
Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 fd=252 TLS established
tls_ssf=256 ssf=256
The user configured to bind from the client side
Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=1 BIND
dn="cn=ldapuser,ou=Users,dc=server,dc=com" method=128
Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=1 BIND
dn="cn=ldapuser,ou=Users,dc=server,dc=com" mech=SIMPLE ssf=0
My user id used to login to the server:
Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=3 BIND dn="cn=My
Username,ou=Users,dc=serverdc=com" method=128
Object added to server:
dn: olcDatabase={2}bdb,cn=config
changetype:modify
add: olcTLSVerifyClient:demand
Still I did not corrected my ACL but I do not see olcTLSVerifyClient:demand
reflected on my configuration
with slapcat -n0 I only see the this:
olcTLSCACertificateFile: /etc/openldap/certs/cert.pem
olcTLSCertificateKeyFile: /etc/openldap/certs/private.key
olcTLSCertificateFile: /etc/openldap/certs/cert.pem
Did I do something wrong?
Thanks for your time and support
Regards
2014-10-29 14:51 GMT-03:00 Net Warrior <netwarrior863(a)gmail.com>:
> Ok, thank you very much, I'm gonna review the configuration and follow
> your advice.
>
> Best regards.
>
> 2014-10-29 13:43 GMT-03:00 Andrew Findlay <andrew.findlay(a)skills-1st.co.uk
> >:
>
> On Wed, Oct 29, 2014 at 08:19:03AM -0300, Net Warrior wrote:
>>
>> > 200 Servers and 20 users
>>
>> OK - that means that you will not have problems with the default
>> limits on result-set size (500 entries).
>>
>> > >I hope you don't really bind with the ROOTDN account!
>> > NO! and I have a user to test the configuration but I do not use it
>> to bind
>> > purposes, but I could if I knew how to configure it.
>>
>> As you have quite a lot of servers and a policy of hiding all data
>> from anonymous users, I would suggest having more than one LDAP-client
>> account. Either create one per client server, or one per group of similar
>> servers.
>>
>> I would suggest putting the client accounts in a dedicated part of the
>> LDAP tree, so it might look like this:
>>
>> ou=Users,dc=server,dc=com POSIX user accounts
>> ou=Groups,dc=server,dc=com POSIX groups
>> ou=Clients,dc=server,dc=com Client machine accounts
>>
>> You need to get all your client machines to bind with their account DN
>> and password before you start changing ACLs. Config file entries will look
>> something like this:
>>
>> binddn cn=server1,ou=Clients,dc=server,dc=com
>> bindpw SomeLongAndSecurePassword
>>
>> > >You should also add:
>> > >tls_reqcert demand
>> > >and you may want to consider restricting the connection to high-grade
>> ciphers
>> > e.g.:
>> > >tls_ciphers HIGH:MEDIUM:@STRENGTH
>> >
>> > Both, client and server side right?
>>
>> Yes, but the keyword for slapd.conf is TLSCipherSuite
>> and for ldap.conf it is TLS_CIPHER_SUITE
>>
>> Once you have *all* the clients using TLS and binding with their client
>> account and password, you can start on ACLs. If your logging includes
>> the 'stats' category (256) you will be able to see TLS setup and bind
>> in the logs, e.g.:
>>
>> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 fd=26 ACCEPT from
>> IP=[::1]:43386 (IP=[::]:389)
>> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 EXT
>> oid=1.3.6.1.4.1.1466.20037
>> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 STARTTLS
>> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 RESULT oid= err=0
>> text=
>> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 fd=26 TLS established
>> tls_ssf=128 ssf=128
>> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 BIND
>> dn="cn=client234,ou=Clients,dc=server,dc=com" method=128
>> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 BIND
>> dn="cn=client234,ou=Clients,dc=server,dc=com" mech=SIMPLE ssf=0
>> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 RESULT tag=97
>> err=0 text=
>>
>> After all that, the ACLs turn out to be really simple! Something like this
>> will probably be close to what you need for the main database:
>>
>> access to attrs="userPassword"
>> by self =w
>> by * auth
>>
>> access to * by users read
>>
>> access to * by * none
>>
>> If you have a replica server then you will need to add an ACL giving read
>> access
>> to all attributes. This should go right at the top of the list, and will
>> look something
>> like this:
>>
>> access to * by dn.exact="cn=replicator,ou=Clients,dc=server,dc=com" read
>>
>> If you are using the Monitor database then you should probably protect it
>> like this:
>>
>> access to dn.subtree="cn=Monitor"
>> by users read
>> by * none
>>
>> And to make sure that critical stuff like the root DSE and the schema can
>> be
>> read by everyone, add this to the global section of the config:
>>
>> access to * by * read
>>
>>
>> Andrew
>> --
>> -----------------------------------------------------------------------
>> | From Andrew Findlay, Skills 1st Ltd |
>> | Consultant in large-scale systems, networks, and directory services |
>> | http://www.skills-1st.co.uk/ +44 1628 782565 |
>> -----------------------------------------------------------------------
>>
>
>
11 years
RE: difference between /etc/ldap.conf /etc/openldap/ldap.conf
by GanGan
yes I have
On Wed, 29 Oct 2008 12:19:56 -0400, Lynn York <lyork(a)inetu.net> wrote:
> You also should check the sshd_config and make sure you have "UsePAM yes"
> in
> the config
>
> -----Original Message-----
> From: GanGan [mailto:gangan@zalteam.com]
> Sent: Wednesday, October 29, 2008 12:03 PM
> To: Lynn York
> Cc: Hallvard B Furuseth; Openldap technical
> Subject: RE: difference between /etc/ldap.conf /etc/openldap/ldap.conf
>
>
>
> I did not touch so I do not think it comes from this files
>
>
>
> On Wed, 29 Oct 2008 11:55:29 -0400, Lynn York <lyork(a)inetu.net> wrote:
>> Make sure have configured PAM properly. Here is an example of a
>> system-auth-ac file that I use that works properly:
>>
>> [ /etc/pam.d/system-auth-ac ]
>> #%PAM-1.0
>> # This file is auto-generated.
>> # User changes will be destroyed the next time authconfig is run.
>> auth required pam_env.so
>> auth sufficient pam_unix.so nullok try_first_pass
>> auth sufficient pam_ldap.so use_first_pass
>> auth required pam_deny.so
>>
>> account required pam_unix.so broken_shadow
>> account sufficient pam_localuser.so
>> account sufficient pam_succeed_if.so uid < 500 quiet
>> account [default=bad success=ok user_unknown=ignore] pam_ldap.so
>> account required pam_permit.so
>>
>> password requisite pam_cracklib.so try_first_pass retry=3
>> password sufficient pam_unix.so md5 shadow nullok try_first_pass
>> use_authtok
>> password sufficient pam_ldap.so use_authtok
>> password required pam_deny.so
>>
>> session optional pam_keyinit.so revoke
>> session required pam_limits.so
>> session [success=1 default=ignore] pam_succeed_if.so service in
> crond
>
>> quiet use_uid
>> session required pam_unix.so
>> session optional pam_ldap.so
>> [ end /etc/pam.d/system-auth-ac ]
>>
>>
>> -----Original Message-----
>> From: openldap-technical-bounces+lyork=inetu.net(a)openldap.org
>> [mailto:openldap-technical-bounces+lyork=inetu.net@openldap.org] On
> Behalf
>> Of
>> GanGan
>> Sent: Wednesday, October 29, 2008 11:28 AM
>> To: Hallvard B Furuseth
>> Cc: Openldap technical
>> Subject: Re: difference between /etc/ldap.conf /etc/openldap/ldap.conf
>>
>>
>> thank you
>>
>> I have a problem with my users authentication.
>>
>> getent passwd
>> gives me my 4 users ldap
>>
>> [...]
>>
>> videl:x:503:1000:videl:/home/videl:/bin/bash
>> azerty:x:501:1000:azerty:/home/azerty:/bin/bash
>> wizz:x:515:1000:wizz:/home/wizz:/bin/bash
>> shen:x:509:1000:shen:/home/shen:/bin/bash
>>
>> but impossible to connect.
>>
>> [root@clitest3 /]# ssh videl(a)srvtest3.test.org
>> videl(a)srvtest3.test.org's password:
>> Permission denied, please try again.
>> videl(a)srvtest3.test.org's password:
>> Permission denied, please try again.
>> videl(a)srvtest3.test.org's password:
>> Permission denied (publickey,password).
>>
>> log ldap server (srvtest3):
>>
>> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 fd=14 ACCEPT from
>> IP=127.0.0.1:40706 (IP=0.0.0.0:389)
>> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=0 STARTTLS
>> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 fd=14 TLS established
>> tls_ssf=256 ssf=256
>> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=0 RESULT oid= err=0
> text=
>> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=1 BIND dn="" method=128
>> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=1 RESULT tag=97 err=0
>> text=
>> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=2 SRCH
>> base="ou=user,dc=midian,dc=org" scope=2 deref=0
>> filter="(&(objectClass=posixAccount)(uid=videl))"
>> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=2 SRCH attr=uid
>> userPassword uidNumber gidNumber cn homeDirectory loginShell gecos
>> description objectClass
>> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=2 SEARCH RESULT tag=101
>> err=0 nentries=0 text=
>> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=19 op=3 SRCH
>> base="ou=user,dc=midian,dc=org" scope=2 deref=0
>> filter="(&(objectClass=posixAccount)(uid=videl))"
>> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=19 op=3 SRCH attr=uid
>> userPassword uidNumber gidNumber cn homeDirectory loginShell gecos
>> description objectClass
>> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=19 op=3 SEARCH RESULT tag=101
>> err=0 nentries=0 text=
>> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 fd=17 ACCEPT from
>> IP=127.0.0.1:40707 (IP=0.0.0.0:389)
>> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=0 STARTTLS
>> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=0 RESULT oid= err=0
> text=
>> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 fd=17 TLS established
>> tls_ssf=256 ssf=256
>> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=1 BIND dn="" method=128
>> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=1 RESULT tag=97 err=0
>> text=
>> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=2 SRCH
>> base="ou=user,dc=midian,dc=org" scope=2 deref=0
>> filter="(&(host=srvtest3.test.org)(uid=videl))"
>> Oct 29 16:25:45 srvtest3 slapd[1947]: <= bdb_equality_candidates: (host)
>> index_param failed (18)
>> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=2 SEARCH RESULT tag=101
>> err=0 nentries=0 text=
>>
>> I do not understand why it is not working. :(
>> any idea ?
> --
> - GanGan -
> www.system-linux.eu merci pour le clique sur la pub :p
--
- GanGan -
www.system-linux.eu merci pour le clique sur la pub :p
17 years
Re: delta-synrepl consumer randomly delete objects
by Raffael Sahli
On 20.10.2016 09:19, Raffael Sahli wrote:
> Hi
>
> What can lead a consumer to "randomly" delete ~50% of all objects in his database?
> I have this problem now for ~1-2months and on 3 different master/slave groups.
>
> The consumer starts to delete objects (but those are all present on the master):
>
> Oct 19 17:16:22 ldap-slave002.xxx slapd[8554]: do_syncrep2: rid=999 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> Oct 19 17:16:22 ldap-slave002.xxx slapd[8554]: do_syncrep2: rid=999 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 9c802b18-7c2c-1033-9f25-2d4a65066d19, dn uid=jasmin.mans,ou=none,o=dd,dc=xxx,dc=xxx
> Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 650ada00-e996-1035-80ac-a173474274df, dn uid=jasmine.suddr,ou=none,o=dd,dc=xxx,dc=xxx
> Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID ec5c9aa4-7c2c-1033-9fa4-2d4a65066d19, dn uid=jonas.beffrnn,ou=none,o=dd,dc=xxx,dc=xxx
> Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 7461d22e-e996-1035-80f6-a173474274df, dn uid=juerg.klegegeli,ou=none,o=dd,dc=xxx,dc=xxx
> Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 758c744c-e996-1035-8100-a173474274df, dn uid=julia.sxgegegea,ou=none,o=dd,dc=xxx,dc=xxx
> Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 47e4f6b4-7c2d-1033-8015-2d4a65066d19, dn uid=karin.vivwvwe,ou=none,o=dd,dc=xxx,dc=xxx
> Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 8d26a4f2-7c2d-1033-807b-2d4a65066d19, dn uid=larissa.fewfewf,ou=none,o=dd,dc=xxx,dc=xxx
> Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 98310aa4-7c2d-1033-808b-2d4a65066d19, dn uid=laura.cfwfew,ou=none,o=dd,dc=xxx,dc=xxx
>
> syncrepl config:
> olcSyncrepl: {0}rid=999 provider=ldap://ldap-master002.xxx.xxx:389 bindmethod=simple timeout=0 network-timeout=10 binddn="uid=replicator,ou=system,o=de,dc=xxx,dc=xxx"
> credentials="pass" keepalive=0:0:0 starttls=yes tls_cacert="/etc/ssl/certs/SwissSign_Silver_CA_-_G2.pem" tls_reqcert=allow filter="(objectClass=*)" searchbase="dc=xxx,dc=xxx" scope=sub attrs="*,+"
> syncdata="accesslog" logbase="cn=accesslog_xxx" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=off type=refreshOnly interval="00:00:01:00" retry="10 5 60 +"
>
>
> Misconfiguration? (We've been running this configuration for years...)
>
>
> Workaround is to remove the whole mdb database and restart slapd to let it resync.
> I've found some posts with a similar problem but those are all related to pre 2.4.21, we're running slapd 2.4.44.
>
>
> Cheers
>
Ideas?
(Most of the time slapd removes now ~99% of all objects)
--
Raffael Sahli
9 years, 1 month
Re: Syncrepl over TLS for mirrormode
by Marco Schirrmeister
To avoid all this name problems and to keep things simple I use a wildcard certificate.
This cert is also used on the real servers and on the load balancer.
The clients talk only the a load balancer. Where I have 2 ip addresses. One for ldapwrite.domain.com and one for ldapread.domain.com
The load balancer terminates the ssl connection for port 636 and creates a new session to the backend server.
The reason that I have also the wildcard cert also on the backend servers is for secure connections over 389.
The load balancer doesn't speak the ldap protocol, so if a client is doing a starttls he would get the cert from the real server.
If 389 is not needed, then I think 1 or 2 certs on a load balancer would be enough.
The replication works also with self-signed certs if configured correctly.
--
Marco
On Aug 26, 2011, at 10:35 PM, Daniel Qian wrote:
> Still not sure how you did it. Are you saying you set the same certificate in slapd and played with DNS to make it look like only one server(URL) to everyone?
>
> Thanks,
> Daniel
>
> On 11-08-26 4:03 PM, Chris Jacobs wrote:
>>
>> What I did:
>> * setup servers behind VIP
>> * obtain cert with primary name of vip DNS w/ secondary names of the servers.
>>
>> That way, the servers can sync/tryst each other via the same cert used by clients.
>>
>> Note: some clients (lookin at you Firefox) won't use the primary name if subjectaltname exists - so include primary name in the alt names JIC.
>>
>> - chris
>>
>> Chris Jacobs, Systems Administrator, Technology Services Group
>> Apollo Group | Apollo Marketing and Product Development� |� Aptimus, Inc.
>> 2001 6th Ave� |� Suite 3200� |� Seattle, WA 98121
>> direct 206.839.8245� |� cell 206.601.3256� |� fax 206.839.8106
>> email chris.jacobs(a)apollogrp.edu
>>
>> From: openldap-technical-bounces(a)OpenLDAP.org <openldap-technical-bounces(a)OpenLDAP.org>
>> To: openldap-technical(a)openldap.org <openldap-technical(a)openldap.org>
>> Sent: Fri Aug 26 12:49:04 2011
>> Subject: Syncrepl over TLS for mirrormode
>>
>> From the openldap website the two nodes have to use different URLs like below:
>>
>> syncrepl rid=001
>> provider=ldap://ldap-sid2.example.com
>> bindmethod=simple
>> binddn="cn=mirrormode,dc=example,dc=com"
>> credentials=mirrormode
>> searchbase="dc=example,dc=com"
>> schemachecking=on
>> type=refreshAndPersist
>> retry="60 +"
>> and
>> syncrepl rid=001
>> provider=ldap://ldap-sid1.example.com
>> bindmethod=simple
>> binddn="cn=mirrormode,dc=example,dc=com"
>> credentials=mirrormode
>> searchbase="dc=example,dc=com"
>> schemachecking=on
>> type=refreshAndPersist
>> retry="60 +"
>>
>> I can set two different certificates so that TLS is fine for sync between the two nodes. However we will have regular Ldap client access these two nodes behind a loadbalancer over TLS too. Obviously the client can't connect with ldap-sid2.example.com, nor with ldap-sid1.example.com. So what is the solution to this scenario? Setup a pool of consumers with same hostname?
>>
>> Thanks,
>> Daniel
>>
>> This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
>>
>
14 years, 3 months
Issue renewing my TLSCertificateFile(s)
by Olivier
Hi everyone
Question : are there some limitations (key size, encryption algorithm,
etc.) for certificates used by openldap to manage TLS connexions ?
See below why I ask :
I have used the following configuration in my slapd servers for quite a
while without any problem :
olcTLSCACertificateFile: /etc/openldap/cacerts/CA.crt
olcTLSCertificateFile: /etc/openldap/cacerts/server.crt
olcTLSCertificateKeyFile: /etc/openldap/cacerts/server.key
olcTLSCipherSuite: HIGH
olcTLSVerifyClient: allow
See for example my configuration for syncrepl (see: tls_reqcert=demand) :
olcSyncrepl: {0}rid=411 provider=ldap://ldap1.example.fr bindmethod=sasl
sizelimit=unlimited timeout=0 network-timeout=0 saslmech=external type
=refreshAndPersist retry="5 +" starttls=yes tls_cacert=/etc/openldap/cacer
ts/CA.crt tls_cert=/etc/openldap/cacerts/replicator.crt
tls_key=/etc/openldap
/cacerts/replicator.key scope=sub schemachecking=on keepalive=0:0:0 fil
ter="(objectclass=*)" searchbase="dc=example,dc=fr" tls_reqcert=demand
-> I have used this for couple of years on my multimastered ldap servers,
and until yesterday that worked perfectly : replication was working
properly and clients talked with the servers using TLS without any problem.
But I since my certicates were too weak (see this : sha1, 512 bit) :
$ openssl x509 -text -in server.crt
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 13998752034197585248 (0xc2458ece791fbd60)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=fr, ST=IDF, L=Town, O=example, OU=IT,
CN=ldap/emailAddress=ldap(a)example.fr
Validity
Not Before: Dec 29 15:41:56 2011 GMT
Not After : Jul 29 15:41:56 2021 GMT
Subject: C=fr, ST=IDF, L=Town, O=example, OU=IT,CN=
ldap1.example.fr/emailAddress=ldap(a)example.fr
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (512 bit)
I have renewed them using the same self signed authority to validate them,
and of course using exactly the same subject. My new certificate look like
this :
$ openssl x509 -text -in server.crt (see this : sha2, 4096 bit) :
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 10208063777793278590 (0x8daa53ebd7e6827e)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=fr, ST=IDF, L=Town, O=example, OU=IT,
CN=ldap/emailAddress=ldap(a)example.fr
Validity
Not Before: Jul 22 15:24:50 2015 GMT
Not After : Feb 19 15:24:50 2025 GMT
Subject: C=fr, ST=IDF, L=Town, O=example, OU=IT,CN=
ldap1.example.fr/emailAddress=ldap(a)example.fr
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
I installed my new certificate on ldap1 without changing the configuration,
and restarting the server here is what I get on ldap4 logs (loglevel =
sync ) :
$ tail -f /var/log/ldap.log
...
Jul 22 17:31:10 ldap4 slapd[53489]: slap_client_connect: URI=ldap://
ldap1.example.fr Warning, ldap_start_tls failed (-11)
Jul 22 17:31:10 ldap4 slapd[53489]: slap_client_connect: URI=ldap://
ldap1.example.fr ldap_sasl_interactive_bind_s failed (-2)
Jul 22 17:31:10 ldap4 slapd[53489]: do_syncrepl: rid=432 rc -2 retrying
Jul 22 17:31:15 ldap4 slapd[53489]: slap_client_connect:
URI=ldap://ldap1.example.fr Warning, ldap_start_tls failed (-11)
Jul 22 17:31:15 ldap4 slapd[53489]: slap_client_connect: URI=ldap://
ldap1.example.fr ldap_sasl_interactive_bind_s failed (-6)
Jul 22 17:31:15 ldap4-mrs slapd[53489]: do_syncrepl: rid=432 rc -6 retrying
When reinstalling the previous certificates and restarting ldap1 the server
I see this appearing in ldap4 logs :
...
Jul 22 17:31:20 ldap4-mrs slapd[53489]: do_syncrep2: rid=432
LDAP_RES_INTERMEDIATE - REFRESH_DELETE
Question : are there some limitations (key size, encryption algorithm,
etc.) for certificates used by openldap to manage TLS connexions ? Does
openldap tls connections work with certificates sha 256 With RSA Encryption
using a 4096 public key length ? May be I missed something ?
(note : I use openssl to manage my certificates)
Thanks for any help.
---
Olivier
10 years, 4 months
Re: LDAP Crafted Search Request Access Allowed
by Andrew Findlay
On Wed, Oct 29, 2014 at 08:19:03AM -0300, Net Warrior wrote:
> 200 Servers and 20 users
OK - that means that you will not have problems with the default
limits on result-set size (500 entries).
> >I hope you don't really bind with the ROOTDN account!
> NO! and I have a user to test the configuration but I do not use it to bind
> purposes, but I could if I knew how to configure it.
As you have quite a lot of servers and a policy of hiding all data
from anonymous users, I would suggest having more than one LDAP-client
account. Either create one per client server, or one per group of similar
servers.
I would suggest putting the client accounts in a dedicated part of the
LDAP tree, so it might look like this:
ou=Users,dc=server,dc=com POSIX user accounts
ou=Groups,dc=server,dc=com POSIX groups
ou=Clients,dc=server,dc=com Client machine accounts
You need to get all your client machines to bind with their account DN
and password before you start changing ACLs. Config file entries will look
something like this:
binddn cn=server1,ou=Clients,dc=server,dc=com
bindpw SomeLongAndSecurePassword
> >You should also add:
> >tls_reqcert demand
> >and you may want to consider restricting the connection to high-grade ciphers
> e.g.:
> >tls_ciphers HIGH:MEDIUM:@STRENGTH
>
> Both, client and server side right?
Yes, but the keyword for slapd.conf is TLSCipherSuite
and for ldap.conf it is TLS_CIPHER_SUITE
Once you have *all* the clients using TLS and binding with their client
account and password, you can start on ACLs. If your logging includes
the 'stats' category (256) you will be able to see TLS setup and bind
in the logs, e.g.:
Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 fd=26 ACCEPT from IP=[::1]:43386 (IP=[::]:389)
Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 STARTTLS
Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 RESULT oid= err=0 text=
Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 fd=26 TLS established tls_ssf=128 ssf=128
Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 BIND dn="cn=client234,ou=Clients,dc=server,dc=com" method=128
Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 BIND dn="cn=client234,ou=Clients,dc=server,dc=com" mech=SIMPLE ssf=0
Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 RESULT tag=97 err=0 text=
After all that, the ACLs turn out to be really simple! Something like this
will probably be close to what you need for the main database:
access to attrs="userPassword"
by self =w
by * auth
access to * by users read
access to * by * none
If you have a replica server then you will need to add an ACL giving read access
to all attributes. This should go right at the top of the list, and will look something
like this:
access to * by dn.exact="cn=replicator,ou=Clients,dc=server,dc=com" read
If you are using the Monitor database then you should probably protect it like this:
access to dn.subtree="cn=Monitor"
by users read
by * none
And to make sure that critical stuff like the root DSE and the schema can be
read by everyone, add this to the global section of the config:
access to * by * read
Andrew
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
11 years
Re: RE: OpenLDAP 2.3.4 TLS negotiation failure
by Tian Zhiying
Hi Chris：
I have to regenerate the CA, and make sure that the hostname and common name match(ldap.server.com), the following is the command output:
[root(a)ldap.server.com ~]# echo | openssl s_client -connect ldap.server.com: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=1 /C=CN/ST=BJ/O=TS/OU=IT/CN=ldap.server.com/emailAddress=tianzy(a)server.com
verify return:1
depth=0 /C=CN/ST=BJ/L=BJ/O=TS/OU=IT/CN=ldap.server.com/emailAddress=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
On LDAP Server run the command: "ldapsearch -x -H ldap://ldap.server.com -ZZ" is ok, I think CA is no problem now. But on my client , it also ouput "ldap_start_tls: Connect error (-11) "
LDAP Server log file output:
Oct 24 11:41:41 auth slapd[14371]: conn=49 fd=14 ACCEPT from IP=192.168.9.9:46226 (IP=0.0.0.0:389)
Oct 24 11:41:41 auth slapd[14371]: conn=49 op=0 STARTTLS
Oct 24 11:41:41 auth slapd[14371]: conn=49 op=0 RESULT oid= err=0 text=
Oct 24 11:41:41 auth slapd[14371]: conn=49 fd=14 closed (TLS negotiation failure)
Tian Zhiying
From: Chris Jacobs
Date: 2013-10-23 22:18
To: tianzy1225; DieterKlünter; openldap-technical
Subject: RE: Re: OpenLDAP 2.3.4 TLS negotiation failure
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.
12 years, 1 month
Consumer replication 0 entries fetched - CSN problem?
by Josh Nielsen
Hello all,
Last year I switched from the slapd.conf to the OLC style config for
OpenLDAP and transitionally tested it by making the OLC server a
replication slave to the older LDAP server configured with slapd.conf.
Now I've disabled replication from that old server and am making the
OLC server (LDAP01 - version 2.4.23) the new master and threw up a new
VM called LDAP02 (2.4.23) to become the new sync replication
slave/consumer. Though I'm using multiple guides of varying detail the
simplest setup steps basically followed this article:
http://gagravarr.livejournal.com/145679.html.
I followed the same steps I thought I did for LDAP01, but despite the
fact that I see LDAP02 bind and try to fetch entries for replication
nothing is being fetched. The problem description is almost identical
to this person's issue:
http://www.openldap.org/lists/openldap-software/200911/msg00017.html
(with "nentries=0" in the replication log messages, but plenty of
entries found with an ldapsearch manually).
Though I think my setup situation is different than that person's, and
they were exporting using slapcat/slapadd (which I did for converting
my existing slapd.conf config to LDAP01 last year, but this time I
merely setup LDAP02 from scratch as a cn=config OLC server to begin
with), one of the follow-up responses to that email thread said this:
"The only correct usage of -w is when you have an LDIF produced by slapcat
on a database that was not being used with replication before, and so is missing
the contextCSN. But all the other operational attributes (entryUUID and
entryCSN in particular) are present and valid."
This made me wonder if the problem I'm seeing is because LDAP02 (or
LDAP01?) is somehow missing a contextCSN. I am seeing no "cookie"
messages associated with replication in my log.
Some of my config is below as well as the log messages I am seeing on
LDAP01 (edited domain & password). I did notice off-the-bat though
that I am missing an "olcDbIndex: entryUUID pres,eq" entry on LDAP02
where I have it on LDAP01. Is that a crucial setting for replication?
Lastly, I deleted the database files in /var/lib/ldap/ on LDAP02 and
restarted slapd once I had configured "olcSyncRepl" on LDAP02 to
ensure that I was starting from scratch.
-------
LDAP01's log entry for LDAP02's attempted connection looks like this:
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 fd=359 ACCEPT from
IP=192.168.21.60:46198 (IP=0.0.0.0:389)
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=0 STARTTLS
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=0 RESULT oid= err=0 text=
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 fd=359 TLS established
tls_ssf=256 ssf=256
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=1 BIND
dn="cn=root,dc=myerslab,dc=haib,dc=org" method=128
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=1 BIND
dn="cn=root,dc=myerslab,dc=haib,dc=org" mech=SIMPLE ssf=0
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=1 RESULT tag=97 err=0 text=
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=2 SRCH
base="dc=myerslab,dc=haib,dc=org" scope=2 deref=0
filter="(objectClass=*)"
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=2 SRCH attr=* +
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=2 SEARCH RESULT
tag=101 err=0 nentries=0 text=
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=3 UNBIND
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 fd=359 closed
-------
LDAP02's /etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif:
dn: olcDatabase={1}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcSuffix: dc=mydomain,dc=org
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=admin,dc=mydomain,dc=org
olcRootPW::
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
olcDbDirectory: /var/lib/ldap
olcDbCacheSize: 50000
olcDbCheckpoint: 10240 720
olcSyncrepl: {0}rid=001 provider=ldap://ldap01.mydomain.org bindmethod=si
mple timeout=1 network-timeout=0 binddn="cn=root,dc=mydomain,dc=org"
credentials="ld4p3650" keepalive=0:0:0 starttls=yes filter="(objectclass=*)" s
earchbase="dc=mydomain,dc=org" scope=sub schemachecking=off type=refr
eshOnly interval=00:00:00:10 retry="5 5 300 5"
tls_cacert=/etc/openldap/certs/rootCA.cert
olcUpdateRef: ldap://ldap01.mydomain.org
olcMirrorMode: TRUE
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass pres,eq
olcDbIndex: cn pres,eq,sub
olcDbIndex: uid pres,eq,sub
olcDbIndex: uidNumber pres,eq
olcDbIndex: gidNumber pres,eq
olcDbIndex: mail pres,eq,sub
olcDbIndex: ou pres,eq,sub
olcDbIndex: loginShell pres,eq
olcDbIndex: sn pres,eq,sub
olcDbIndex: givenName pres,eq,sub
olcDbIndex: memberUid pres,eq,sub
olcDbIndex: nisMapName pres,eq,sub
olcDbIndex: nisMapEntry pres,eq,sub
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: 31e2c8b0-c0ec-1033-8c20-43a6f59853d5
creatorsName: cn=config
createTimestamp: 20140825214036Z
entryCSN: 20140912164223.814325Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20140912164223Z
-------
LDAP01's /etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif:
dn: olcDatabase={1}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcSuffix: dc=mydomain,dc=org
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * no
ne
olcAccess: {1}to * by anonymous read
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=admin,dc=mydomain,dc=org
olcRootPW::
olcSyncUseSubentry: FALSE
olcMirrorMode: TRUE
olcMonitoring: TRUE
olcDbDirectory: /var/lib/ldap
olcDbCacheSize: 50000
olcDbCheckpoint: 10240 720
olcDbConfig: {0}# $OpenLDAP: pkg/ldap/servers/slapd/DB_CONFIG,v 1.3.2.4 2007/1
2/18 11:53:27 ghenry Exp $
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 pres,eq
olcDbIndex: entryUUID pres,eq
olcDbIndex: entryCSN pres,eq
olcDbIndex: cn pres,eq,sub
olcDbIndex: uid pres,eq,sub
olcDbIndex: uidNumber pres,eq
olcDbIndex: gidNumber pres,eq
olcDbIndex: ou pres,eq,sub
olcDbIndex: mail pres,eq,sub
olcDbIndex: memberUid pres,eq,sub
olcDbIndex: sn pres,eq,sub
olcDbIndex: loginShell pres,eq
olcDbIndex: givenName pres,eq,sub
olcDbIndex: nisMapName pres,eq,sub
olcDbIndex: nisMapEntry pres,eq,sub
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: 727d260c-cc5c-1032-89cf-2fc7acd5ca31
creatorsName: cn=config
createTimestamp: 20131018161654Z
entryCSN: 20140915195740.431843Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20140915195740Z
------
Thanks,
Josh Nielsen
11 years, 2 months