Re: Dovecot can't connect to openldap over starttls
by info＠gwarband.de
Am 2017-03-20 14:29, schrieb Dan White:
> On 03/19/17 09:07 +0100, info(a)gwarband.de wrote:
>> Am 2017-03-19 01:09, schrieb Dan White:
>>>>>>>> On 03/17/2017 04:27 PM, info(a)gwarband.de wrote:
>>>>>>>>> https://gwarband.de/openldap/dovecot.log
>>>
>>> Mar 11 11:18:26 s1 dovecot: auth: Debug: Read auth token secret from
>>> /var/run/dovecot/auth-token-secret.dat
>>> Mar 11 11:18:26 s1 dovecot: auth: Error: LDAP: ldap_start_tls_s()
>>> failed: Connect error
>>> Mar 11 11:18:26 s1 dovecot: auth: Error: LDAP: ldap_start_tls_s()
>>> failed: Connect error
>>> Mar 11 11:18:26 s1 dovecot: auth: Debug: auth client connected
>>> (pid=27177)
>>> Mar 11 11:18:33 s1 dovecot: imap-login: Disconnected (no auth
>>> attempts in 7 secs): user=<>, rip=149.172.171.148, lip=188.68.37.50,
>>> session=<gcDtzHFKbwCVrKuU>
>>>
>>>>>>>>> https://gwarband.de/openldap/dovecot-ldap.conf
>>>
>>> uris = ldap://ldap.gwarband.de
>>> dn = cn=T000000002,ou=tech,dc=gwarband,dc=de
>>> dnpass = secret
>>> tls = yes
>>> tls_ca_cert_file = /etc/ssl/certs/LetsEncrypt.pem
>>> auth_bind = yes
>>> ldap_version = 3
>>> base = dc=gwarband,dc=de
>>> scope = subtree
>>> user_attrs =
>>> mail=maildir:/var/vmail/%{ldap:mailbox},uid=vmail,gid=vmail
>>> user_filter =
>>> (&(email=%u)(memberOf=cn=mailbox,ou=application,ou=groups,dc=gwarband,dc=de))
>>> pass_attrs = email=user
>>> pass_filter =
>>> (&(email=%u)(memberOf=cn=mailbox,ou=application,ou=groups,dc=gwarband,dc=de))
>>>
>>>>>>> https://gwarband.de/openldap/openldap.conf
>>>
>>> # Certificate
>>> TLSCACertificateFile /etc/ssl/certs/LetsEncrypt.pem
>>> TLSCertificateFile /etc/ssl/certs/gwarbandDE_LDAP.pem
>>> TLSCertificateKeyFile /etc/ssl/certs/gwarbandDE_LDAP.key
>>> TLSCipherSuite
>>> SECURE128:-ARCFOUR-128:-CAMELLIA-128-CBC:-3DES-CBC:-CAMELLIA-128-GCM
>>> TLSProtocolMin 3.1
>>> TLSVerifyClient never
>
> # Read slapd.conf(5) for possible values
> loglevel 256
>
> There are more verbose options.
>
> # Include ACLs
> include /etc/ldap/acl.conf
>
>>> What are the contents of /etc/ldap/ldap.conf?
>>
>> The ldap.conf has no difference to the dovecot-ldap.conf.
>> See: https://gwarband.de/openldap/ldap.conf
>> The point "TLS_REQCERT" is in both confs "demand". I've changed it
>> after that.
>>
>> The ldapsearch command works also under the user "dovecot"
>> See: https://gwarband.de/openldap/ldapsearch-dovecot.log
>>
>> ~$ ldapsearch -x -ZZ -D "cn=admin,dc=gwarband,dc=de" -W "cn=mailbox"
>
> There is a difference in your binding DN.
>
> Debug Dovecot's implementation of ldap_start_tls_s().
The loglevel was manually edited to -1 ("any") and the log shows the
output of this loglevel.
Yes the binding DN is diffrent, but I have also tried the
"cn=T000000002,ou=tech,dc=gwarband,dc=de" with no success.
I don't have any idea how to set a higher debug level to dovecot. In my
opinion I have the highest. So I can't deliver a greater log.
7 years, 8 months
Re: Slapd Security based on port
by harry.jede＠arcor.de
Chris Jackson wrote:
> On Feb 11, 2011, at 09:50 AM, Chris Jackson wrote:
>
> Is it possible to prevent anonymous and unauthenticated binds to
> ldaps:// 636 but allow them on ldap:// 389?
>
> I want to allow staff to query my ldaps:// outside of my network
> while requiring them to login to do so but allow anyone to bind
> (anonymous, unauthenticated, or authenticated) internally on ldaps//:
> 389.
>
> I know:
> Anonymous bind can be disabled by "disallow bind_anon" and
> Unauthenticated bind mechanism is disabled by default. But if I use
> "disallow bind_anon it stops in on both ports.
Sure, this are global directives.
> I want to stop it just on ldaps://.
You don't need ldaps:// in your local network? May be.
I think a easier solution is to identify your Internet Gateway by IP.
> Chris Jackson
>
>
> On Feb 14, 2011, at 11:28 AM, Aaron Richton wrote:
>
> Stopping users that are "unauthenticated" makes no sense;
> everything's unauthenticated at time=0. You might as well stop slapd
> if you want a 100% inability to serve data.
>
> You can deny anonymous users that aren't plaintext, including any
> ldaps:/// connections, with something like:
>
> access to *
> by anonymous ssf=0 transport_ssf=0 tls_ssf=0 sasl_ssf=0 none break
> by anonymous none
>
> early on in your ACL stanzas. I'm pretty sure this'll deny anonymous
> StartTLS users on 389, though; not sure if that's what you want. I
> can't think of any way to use the slapd access language to
> differentiate based on listeners, which would probably be the most
> elegant way to handle what you asked. To be fair, this entire
> exercise seems really odd from where I sit -- are you positive that
> this will have the desired effect? (If somebody out in Peru is
> permitted to connect in unencrypted and make anonymous queries, why
> not allow them to make those same queries encrypted? What's the
> difference?)
>
> here is a scenario:
>
> Site has a ldap server on ldap://389. Firewall blocks access to 389
> from internet. Everyone queries the ldap via anonymous binds. Site
> would like to allow staff the ability to query the ldap from outside
> the firewall. This would be done via ldaps:// 636 to users who have
> authenticated via username/password. They do not want to allow
> anonymous queries outside the firewall.
>
> Using the "disallow bind_anon" would prevent anon binds on both
> ldap:// and ldaps://. This would break the inside machines ability
> to query. If we dont use "disallow bind_anon" then machines outside
> of the firewall could query the ldap.
>
> ---Is the only option for them to setup two separate ldap servers?
No. You should use ACLs to solve this problem. Read man slapd.access
an/or search the openldap archives.
Assuming you have a NAT gatway as Firewall machine.
Replace all "by anonymous" statements with these 6 statements:
by anonymous auth continue
by peername.ip="127.0.0.1" read continue
by peername.ip="10.0.0.0%255.0.0.0" read continue
by peername.ip="172.16.0.0%255.240.0.0" read continue
by peername.ip="192.168.0.0%255.255.0.0" read continue
by peername.ip="gateway-ip" auth
One may write these statements more effective, but in general they will
do.
Replace "gateway-ip" with yours.
Put the above statements also in every ACL just before the
by *
when this ACL do NOT have an "by anonymous" statement.
Maybe the last line could/should be:
by ssf=56 peername.ip="gateway-ip" auth
Caveats:
Your gateway can no longer access your LDAP Server with
the "gateway-ip". But this is a Firewall Design Question.
I've tested this only with unencrypted sessions; anoymous and
authenticated. But TLS or SSL will not grant more rights, if you do not
tell the ACLs to do so.
Here the output from the two searches:
# ldapsearch -x -LLL -H ldap://192.168.231.90/ dn
Insufficient access (50)
# ldapsearch -x -LLL -H ldap://192.168.231.90/ dn -D
cn=admin,dc=kronprinz,dc=xx -W
dn: dc=kronprinz,dc=xx
dn: cn=admin,dc=kronprinz,dc=xx
> One with "disallow bind_anon" and one without. Then only open the
> firewall for port 636 to the ldap server which has "disallow
> bind_anon".
>
> Chris Jackson
--
Harry Jede
13 years, 9 months
Antw: Problem with N-Way multimaster replication after an node fail and restore
by Ulrich Windl
>>> David Tello <david.tello.wbsgo(a)gmail.com> schrieb am 09.05.2019 um 10:21
in
Nachricht
<CADC8=Wxww4kTHyRS3_j+93VXRzc45fDrVLJxFwFTRjcH8QD_gQ(a)mail.gmail.com>:
> I have a problem with the N-Way replication multimaster. My enviroiment is
> debian Stretch and slapd (2.4.47+dfsg-3~bpo9+1) from Stretch backports.
>
> I have configured a cluster with 3 nodes. I have configured to replicate
> the config database and a normal data mdb database. I followed the
> documentation and the cluster sync work correctly when all nodes are
> started.
>
> If i made a change in any node, this change is replicated to the others. My
> problem appears when i make a change whe one node is down. In this case,
> the other two nodes repli correctly, and when the downed node start this
> get all pending changes correctly. And in this point occurs the problem.
> After the start of downed node, the changes mades in this node are not send
> to the other two nodes. For other way, the changes mades in the other two
> nodes (no shutdowned) are sended to all nodes correctly.
>
> I tried this config with a two nodes cluster and the behavior was the same,
> after reboot slapd do not send more updates.
>
>
> I have checked the olcServerId because i know that a mistake here can
> produce similar problems. I really think that it is correct.
>
> The cmdlines of the proccess are:
>
> /usr/sbin/slapd -h ldapi:/// ldap://wbsvisionNode1/ ldap://127.0.0.1/
> ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d
> /usr/sbin/slapd -h ldapi:/// ldap://wbsvisionNode2/ ldap://127.0.0.1/
> ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d
> /usr/sbin/slapd -h ldapi:/// ldap://wbsvisionNode3/ ldap://127.0.0.1/
> ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d
>
>
> The config database configuración is below:
>
> *DN: cn=config*
> .....
> olcServerID: 1 ldap://wbsvisionNode1/
> olcServerID: 2 ldap://wbsvisionNode2/
> olcServerID: 3 ldap://wbsvisionNode3/
Are you sure your server IDs are assigned as intended? It is logged like
"slapd[1493]: olcServerID: value " on start.
>
> *dn: olcDatabase={0}config,cn=config*
> .......
> olcMirrorMode: TRUE
>
> olcSyncUseSubentry: FALSE
>
> olcSyncrepl:
>
> {0}rid=001
> provider=ldap://wbsvisionNode1
> bindmethod=simple
> binddn="cn=admin,cn=config"
> credentials="TuoDqAG7UbCJx8H8gfMO"
> starttls=no
> tls_cert=/etc/pki/certs/wbsagnitio.local.es.pem
> tls_key=/etc/pki/private/wbsagnitio.local.es.key
> tls_cacert=/etc/pki/certs/wbsagnitio-ca.pem
> tls_reqcert=never
> searchbase="cn=config"
> scope=sub
> type=refreshAndPersist
> retry="5 5 300 +"
> {1}rid=002
> provider=ldap://wbsvisionNode2
> bindmethod=simple
> binddn="cn=admin,cn=config"
> credentials="TuoDqAG7UbCJx8H8gfMO"
> starttls=no
> tls_cert=/etc/pki/certs/wbsagnitio.local.es.pem
> tls_key=/etc/pki/private/wbsagnitio.local.es.key
> tls_cacert=/etc/pki/certs/wbsagnitio-ca.pem
> tls_reqcert=never
> searchbase="cn=config"
> scope=sub
> type=refreshAndPersist
> retry="5 5 300 +"
> {2}rid=003
> provider=ldap://wbsvisionNode3
> bindmethod=simple
> binddn="cn=admin,cn=config"
> credentials="TuoDqAG7UbCJx8H8gfMO"
> starttls=no
> tls_cert=/etc/pki/certs/wbsagnitio.local.es.pem
> tls_key=/etc/pki/private/wbsagnitio.local.es.key
> tls_cacert=/etc/pki/certs/wbsagnitio-ca.pem
> tls_reqcert=never
> searchbase="cn=config"
> scope=sub
> type=refreshAndPersist
> retry="5 5 300 +"
> FALSE
>
> ------
>
> *dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config*
> objectClass: olcSyncProvConfig
> objectClass: olcOverlayConfig
> olcOverlay: {0}syncprov
> olcSpCheckpoint: 1000 1
>
>
> The data database configuración is below:
>
>
>
> *dn: olcDatabase={1}mdb,cn=config*
> objectClass: olcMdbConfig
> objectClass: olcDatabaseConfig
> olcDatabase: {1}mdb
> ...
> olcDbIndex: objectClass eq
> olcDbIndex: entryCSN eq
> ...
> olcLastMod: TRUE
>
> olcSuffix: dc=local,dc=es
> .........
> olcMirrorMode: TRUE
>
> olcSyncrepl: {0}rid=004
> provider=ldap://wbsvisionNode1
> bindmethod=simple
> binddn="cn=manager,dc=local,dc=es"
> credentials="test"
> starttls=no
> searchbase="dc=local,dc=es"
> scope=sub
> type=refreshAndPersist
> retry="5 5 300 +"
>
> olcSyncrepl: {1}rid=005
> provider=ldap://wbsvisionNode2
> bindmethod=simple
> binddn="cn=manager,dc=local,dc=es"
> credentials="test"
> starttls=no
> searchbase="dc=local,dc=es"
> scope=sub
> type=refreshAndPersist
> retry="5 5 300 +"
>
> olcSyncrepl: {2}rid=006
> provider=ldap://wbsvisionNode3
> bindmethod=simple
> binddn="cn=manager,dc=local,dc=es"
> credentials="test"
> starttls=no
> searchbase="dc=local,dc=es"
> scope=sub
> type=refreshAndPersist
> retry="5 5 300 +"
>
> olcSyncUseSubentry: FALSE
>
> dn: olcOverlay={0}dynlist,olcDatabase={1}mdb,cn=config
> objectClass: olcDynamicList
> objectClass: olcOverlayConfig
> olcOverlay: {0}dynlist
> olcDlAttrSet: {0}virtualGroup memberDnURL uniqueMember
> olcDlAttrSet: {1}virtualGroup memberUidURL memberUid:uid
> olcDlAttrSet: {2}virtualGroup memberSidURL sambaSIDList:sambaSID
>
> dn: olcOverlay={1}lastbind,olcDatabase={1}mdb,cn=config
> objectClass: olcLastBindConfig
> objectClass: olcOverlayConfig
> olcOverlay: {1}lastbind
> olcLastBindPrecision: 30
>
> dn: olcOverlay={2}unique,olcDatabase={1}mdb,cn=config
> objectClass: olcUniqueConfig
> objectClass: olcOverlayConfig
> olcOverlay: {2}unique
> olcUniqueAttribute: uid
> olcUniqueAttribute: uidNumber
> olcUniqueAttribute: employeeNumber
> olcUniqueBase: dc=local,dc=es
>
> dn: olcOverlay={3}memberof,olcDatabase={1}mdb,cn=config
> objectClass: olcMemberOf
> objectClass: olcOverlayConfig
> olcOverlay: {3}memberof
> olcMemberOfDangling: ignore
> olcMemberOfGroupOC: groupOfUniqueNames
> olcMemberOfMemberAD: uniqueMember
> olcMemberOfMemberOfAD: memberOf
> olcMemberOfRefInt: TRUE
>
> dn: olcOverlay={4}accesslog,olcDatabase={1}mdb,cn=config
> objectClass: olcAccessLogConfig
> objectClass: olcOverlayConfig
> olcAccessLogDB: cn=accesslog
> olcOverlay: {4}accesslog
> olcAccessLogOld:
(|(objectClass=wbsagnitioGroup)(objectClass=wbsagnitioAccou
> nt))
> olcAccessLogOldAttr: roles
> olcAccessLogOldAttr: objectClass
> olcAccessLogOps: writes
> olcAccessLogOps: bind
> olcAccessLogPurge: 7+00:00 1+00:00
>
> dn: olcOverlay={5}ppolicy,olcDatabase={1}mdb,cn=config
> objectClass: olcPPolicyConfig
> objectClass: olcOverlayConfig
> olcOverlay: {5}ppolicy
> olcPPolicyDefault:
cn=0-default,ou=passwordpolicies,ou=configuration,dc=loca
> l,dc=es
> olcPPolicyForwardUpdates: FALSE
> olcPPolicyHashCleartext: FALSE
> olcPPolicyUseLockout: FALSE
>
> dn: olcOverlay={6}syncprov,olcDatabase={1}mdb,cn=config
> objectClass: olcSyncProvConfig
> objectClass: olcOverlayConfig
> olcOverlay: {6}syncprov
> olcSpCheckpoint: 1000 1
>
> Below i show the sync log of some operations to show the behavior of my
> cluster:
> TEST 1: 3 Nodes up. Update in node 1 (correct):Log Node1:
>
> May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> 0x7fc7e0100a90 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> 0x7fc7e0108b40 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> removing 0x7fc7e0108b40 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=002,
> cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=003,
> cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> removing 0x7fc7e0100a90 20190507150322.383471Z#000000#001#000000
> Log Node2:
>
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: do_syncrep2: rid=004
> cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_message_to_entry:
> rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004
> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid 23fff700
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004
> be_search (0)
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004
> cn=Usuarios,ou=grupos,dc=local,dc=es
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
> 0x7f80081057c0 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncprov_matchops: skipping
> original sid 001
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
> 0x7f8008107700 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
> removing 0x7f8008107700 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncprov_matchops: skipping
> original sid 001
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncprov_sendresp: to=003,
> cookie=rid=005,sid=002,csn=20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
> removing 0x7f80081057c0 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004
> be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
> 0x7f8008105ea0 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
> removing 0x7f8008105ea0 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: do_syncrep2: rid=006
> cookie=rid=006,sid=003,csn=20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: do_syncrep2: rid=006 CSN too
> old, ignoring 20190507150322.383471Z#000000#001#000000
> (cn=Usuarios,ou=grupos,dc=local,dc=es)
> Log Node3:
>
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004
> cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_message_to_entry:
> rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid adbb2700
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> be_search (0)
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> cn=Usuarios,ou=grupos,dc=local,dc=es
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> 0x7f428c1045c0 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> original sid 001
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> 0x7f428c1069e0 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> removing 0x7f428c1069e0 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> original sid 001
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> removing 0x7f428c1045c0 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncprov_sendresp: to=002,
> cookie=rid=006,sid=003,csn=20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> 0x7f428c104c90 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> removing 0x7f428c104c90 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=005
> cookie=rid=005,sid=002,csn=20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=005 CSN too
> old, ignoring 20190507150322.383471Z#000000#001#000000
> (cn=Usuarios,ou=grupos,dc=local,dc=es)
>
>
> TEST 2: 3 Nodes up. Update in node 2 (correct) (later this will be the down
> node):Log Node1:
>
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: do_syncrep2: rid=005
> cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_message_to_entry:
> rid=005 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005
> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid eaffd700
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005
> be_search (0)
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005
> cn=Usuarios,ou=grupos,dc=local,dc=es
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> 0x7fc7d411fdd0 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncprov_matchops: skipping
> original sid 002
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> 0x7fc7d4105fa0 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> removing 0x7fc7d4105fa0 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncprov_matchops: skipping
> original sid 002
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> removing 0x7fc7d411fdd0 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005
> be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> 0x7fc7d4121830 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=003,
> cookie=rid=004,sid=001,csn=20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> removing 0x7fc7d4121830 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: do_syncrep2: rid=006
> cookie=rid=006,sid=003,csn=20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: do_syncrep2: rid=006 CSN too
> old, ignoring 20190507150531.748816Z#000000#002#000000
> (cn=Usuarios,ou=grupos,dc=local,dc=es)
>
> Log Node2:
>
> May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
> 0x7f8008106ed0 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
> 0x7f80081050e0 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
> removing 0x7f80081050e0 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode2 slapd[1263]: syncprov_sendresp: to=003,
> cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
> removing 0x7f8008106ed0 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode2 slapd[1263]: syncprov_sendresp: to=001,
> cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000
>
> Log Node3:
>
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=005
> cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_message_to_entry:
> rid=005 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005
> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid acbb0700
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005
> be_search (0)
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005
> cn=Usuarios,ou=grupos,dc=local,dc=es
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> 0x7f4288107310 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> original sid 002
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> 0x7f4288109c60 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> removing 0x7f4288109c60 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> original sid 002
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> removing 0x7f4288107310 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncprov_sendresp: to=001,
> cookie=rid=006,sid=003,csn=20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005
> be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> 0x7f42881079f0 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> removing 0x7f42881079f0 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004
> cookie=rid=004,sid=001,csn=20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004 CSN too
> old, ignoring 20190507150531.748816Z#000000#002#000000
> (cn=Usuarios,ou=grupos,dc=local,dc=es)
>
>
> TEST 3: 2 Nodes up. The node 2 is down. Update in node 1:Log Node1:
>
> May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> 0x7fc7dc125e50 20190507151016.178467Z#000000#001#000000
> May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> 0x7fc7dc126f40 20190507151016.178467Z#000000#001#000000
> May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> removing 0x7fc7dc126f40 20190507151016.178467Z#000000#001#000000
> May 7 17:10:16 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=002,
> cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000
> May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> removing 0x7fc7dc125e50 20190507151016.178467Z#000000#001#000000
> May 7 17:10:16 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=003,
> cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000
> Log Node3:
>
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004
> cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_message_to_entry:
> rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid a6ffd700
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> be_search (0)
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> cn=Usuarios,ou=grupos,dc=local,dc=es
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> 0x7f42a0124640 20190507151016.178467Z#000000#001#000000
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> original sid 001
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> 0x7f42a01261a0 20190507151016.178467Z#000000#001#000000
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> removing 0x7f42a01261a0 20190507151016.178467Z#000000#001#000000
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> original sid 001
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> removing 0x7f42a0124640 20190507151016.178467Z#000000#001#000000
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncprov_sendresp: to=002,
> cookie=rid=006,sid=003,csn=20190507151016.178467Z#000000#001#000000
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> 0x7f42a0124810 20190507151016.178467Z#000000#001#000000
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> removing 0x7f42a0124810 20190507151016.178467Z#000000#001#000000
>
>
> TEST 4: 3 Nodes up. Logs of the sync produced by the Node2 start. The node2
> resync correctly the change made in TEST3 (when this node was down).
> Log Node1:
>
> May 7 17:13:52 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> 0x7fc7dc122780 20190507151352.582436Z#000000#001#000000
> May 7 17:13:52 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> removing 0x7fc7dc122780 20190507151352.582436Z#000000#001#000000
> May 7 17:13:52 wbsvisionNode1 slapd[14058]: syncprov_search_response:
>
cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000;20190507
> 150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000
> Log Node2:
>
> May 7 17:13:52 wbsvisionNode2 slapd[591]: slapd starting
> May 7 17:13:52 wbsvisionNode2 slapd[435]: Starting OpenLDAP: slapd.
> May 7 17:13:52 wbsvisionNode2 systemd[1]: Started LSB: OpenLDAP standalone
> server (Lightweight Directory Access Protocol).
> May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=001
> LDAP_RES_INTERMEDIATE - REFRESH_DELETE
> May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=003
> LDAP_RES_INTERMEDIATE - REFRESH_DELETE
> May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=004
> LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=006
> LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_message_to_entry:
> rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004
> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) tid f6021700
> May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004
> be_search (0)
> May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004
> cn=Usuarios,ou=grupos,dc=local,dc=es
> May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_message_to_entry:
> rid=006 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006
> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) tid f501f700
> May 7 17:13:52 wbsvisionNode2 slapd[591]: dn_callback : entries have
> identical CSN cn=Usuarios,ou=grupos,dc=local,dc=es
> 20190507151016.178467Z#000000#001#000000
> May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006
> be_search (0)
> May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006
> cn=Usuarios,ou=grupos,dc=local,dc=es
> May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006 entry
> unchanged, ignored (cn=Usuarios,ou=grupos,dc=local,dc=es)
> May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=006
> LDAP_RES_INTERMEDIATE - REFRESH_PRESENT
> May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=006
>
cookie=rid=006,sid=003,csn=20190507151016.178467Z#000000#001#000000;20190507
> 150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> present UUID d6b883e0-00ff-1039-898f-b1c1eec8fb13, dn dc=local,dc=es
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> present UUID d6b88520-00ff-1039-8990-b1c1eec8fb13, dn
> ou=personas,dc=local,dc=es
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> present UUID d6b8e51a-00ff-1039-8991-b1c1eec8fb13, dn
> ou=grupos,dc=local,dc=es
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> present UUID d6b9494c-00ff-1039-8992-b1c1eec8fb13, dn
> ou=dominios,dc=local,dc=es
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> present UUID d6b9b18e-00ff-1039-8993-b1c1eec8fb13, dn ou=dns,dc=local,dc=es
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> present UUID d6b9eaaa-00ff-1039-8994-b1c1eec8fb13, dn
> ou=forward,ou=dns,dc=local,dc=es
> .................................
>
> Similar lines with other entries.
>
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> present UUID d6c282a0-00ff-1039-89ae-b1c1eec8fb13, dn
> cn=Usuarios,ou=grupos,dc=local,dc=es
> ...............................
> May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing
> 0x7f63d0123740 20190507151016.178467Z#000000#001#000000
> May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004
> be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=004
> LDAP_RES_INTERMEDIATE - REFRESH_PRESENT
> May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=004
>
cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000;20190507
> 150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> present UUID d6b883e0-00ff-1039-898f-b1c1eec8fb13, dn dc=local,dc=es
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> present UUID d6b88520-00ff-1039-8990-b1c1eec8fb13, dn
> ou=personas,dc=local,dc=es
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> present UUID d6b8e51a-00ff-1039-8991-b1c1eec8fb13, dn
> ou=grupos,dc=local,dc=es
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> present UUID d6b9494c-00ff-1039-8992-b1c1eec8fb13, dn
> ou=dominios,dc=local,dc=es
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> present UUID d6b9b18e-00ff-1039-8993-b1c1eec8fb13, dn ou=dns,dc=local,dc=es
>
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> present UUID d6c282a0-00ff-1039-89ae-b1c1eec8fb13, dn
> cn=Usuarios,ou=grupos,dc=local,dc=es
> .............................
>
> Similar lines with other entries.
>
> May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing
> 0x7f63d0121400 20190507151016.178467Z#000000#001#000000
> May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn:
> removing 0x7f63d0121400 20190507151016.178467Z#000000#001#000000
> May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn:
> removing 0x7f63d0123740 20190507151016.178467Z#000000#001#000000
>
> Log Node3:
>
> May 7 17:13:52 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> 0x7f428c103b00 20190507151352.329505Z#000000#003#000000
> May 7 17:13:52 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> removing 0x7f428c103b00 20190507151352.329505Z#000000#003#000000
> May 7 17:13:52 wbsvisionNode3 slapd[1100]: syncprov_search_response:
>
cookie=rid=006,sid=003,csn=20190507151016.178467Z#000000#001#000000;20190507
> 150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000
>
>
> TEST 5: 3 Nodes up. Change is made in Node2 after resync and this is not
> sended to the other nodes in the cluster.Log Node1:
>
> Empty.
> Log Node2:
>
> May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing
> 0x7f63cc121370 20190507152835.873382Z#000000#002#000000
> May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing
> 0x7f63cc125120 20190507152835.873382Z#000000#002#000000
> May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn:
> removing 0x7f63cc125120 20190507152835.873382Z#000000#002#000000
> May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn:
> removing 0x7f63cc121370 20190507152835.873382Z#000000#002#000000
> Log Node3:
>
> Empty.
5 years, 6 months
Replication Failing with TLS ... Sneaky Little Config Error
by Daniel Howard
I have set up OpenLDAP per the nice tutorial at
https://help.ubuntu.com/lts/serverguide/openldap-server.html and on my
previous run-throughs, I succeeded at setting up replication via TLS. But
now that I'm implementing on the dedicated hardware, I am not able to
replicate via TLS.
SOLUTION: It turns out the solution was to add a space to an LDIF file ...
On PROVIDER I will see, for example:
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 fd=49 ACCEPT from IP=
10.10.3.117:60277 (IP=0.0.0.0:389)
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=0 BIND dn="" method=128
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=0 RESULT tag=97 err=0 text=
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=1 SRCH
base="dc=qxxxxxxxxd,dc=com" scope=2 deref=0
filter="(&(objectClass=posixAccount)(uidNumber=2043))"
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=1 SRCH attr=uid
userPassword uidNumber gidNumber cn homeDirectory loginShell gecos
description objectClass
Mar 14 16:13:15 ldap0 slapd[1536]: <= bdb_equality_candidates: (uidNumber)
not indexed
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=1 SEARCH RESULT tag=101
err=0 nentries=1 text=
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=2 SRCH
base="dc=qxxxxxxxxd,dc=com"
scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=djh))"
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=2 SRCH attr=uid
userPassword uidNumber gidNumber cn homeDirectory loginShell gecos
description objectClass
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=2 SEARCH RESULT tag=101
err=0 nentries=1 text=
Mar 14 16:13:16 ldap0 slapd[1536]: conn=1392 op=3 UNBIND
While on CONSUMER:
Mar 14 16:13:15 ldap1 slapd[3672]: @(#) $OpenLDAP: slapd (Ubuntu) (Sep 15
2015 18:19:13) $#012#011buildd@lgw01-53
:/build/openldap-2QUgtL/openldap-2.4.31/debian/build/servers/slapd
Mar 14 16:13:16 ldap1 slapd[3673]: slapd starting
Mar 14 16:13:16 ldap1 slapd[3673]: do_syncrepl: rid=317 rc -1 retrying
Mar 14 16:13:16 ldap1 sudo: pam_unix(sudo:session): session closed for user
root
Mar 14 16:13:23 ldap1 slapd[3673]: conn=1000 fd=13 ACCEPT from IP=
10.10.5.3:15197 (IP=0.0.0.0:389)
Mar 14 16:13:23 ldap1 slapd[3673]: conn=1000 fd=13 closed (connection lost)
I *CAN* to TLS from consumer to master:
0-16:18 djh@ldap1 ~$ *ldapsearch -LLL -x -ZZ -H
ldap://ldap0.mtv.**qxxxxxxxxd.com
uid=djh cn*
dn: uid=djh,ou=People,dc=qxxxxxxxxd,dc=com
cn: djh
So, I increase olcLogLevel to add sync:
Mar 14 16:22:09 ldap1 slapd[4133]: @(#) $OpenLDAP: slapd (Ubuntu) (Sep 15
2015 18:19:13) $#012#011buildd@lgw01-53
:/build/openldap-2QUgtL/openldap-2.4.31/debian/build/servers/slapd
Mar 14 16:22:10 ldap1 slapd[4134]: slapd starting
Mar 14 16:22:10 ldap1 sudo: pam_unix(sudo:session): session closed for user
root
Mar 14 16:22:10 ldap1 slapd[4134]: do_syncrep2: rid=317
cookie=rid=317,csn=20160314224255.836334Z#000000#000#000000
Mar 14 16:22:10 ldap1 slapd[4134]: slap_queue_csn: queing 0x7f0c5c114995
20160314224255.836334Z#000000#000#000000
Mar 14 16:22:10 ldap1 slapd[4134]: slap_graduate_commit_csn: removing
0x7f0c5c114d10 20160314224255.836334Z#000000#000#000000
Mar 14 16:22:10 ldap1 slapd[4134]: do_syncrepl: rid=317 rc -1 retrying
THAT is the contextCSN on the provider!
0-16:24 djh@ldap0 ~$ *ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base
-b dc=qxxxxxxxxd,dc=com contextCSN # provider*
dn: dc=qxxxxxxxxd,dc=com
contextCSN: 20160314224255.836334Z#000000#000#000000
0-16:22 djh@ldap1 ~$ *ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base
-b dc=qxxxxxxxxd,dc=com contextCSN # consumer*
dn: dc=qxxxxxxxxd,dc=com
contextCSN: 20160314224152.708568Z#000000#000#000000
As best I can tell, the connection works, the replication works, but the
consumer is not asking for TLS.
0-16:29 djh@ldap1 ~$
*sudo ldapsearch -Q -Y EXTERNAL -H ldapi:/// -LLL -b cn=config
olcDatabase={1}hdb olcSyncRepldn: olcDatabase={1}hdb,cn=config*
olcSyncrepl: {0}rid=317 provider=ldap://ldap0.mtv.qxxxxxxxxd.com
bindmethod=si
mple binddn="cn=admin,dc=qxxxxxxxxd,dc=com" credentials=secret searchbase
="dc=qxxxxxxxxd,dc=com" logbase="cn=accesslog"
logfilter="(&(objectClass=audi
tWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist
retry="
60 +" syncdata=accesslogstarttls=critical tls_reqcert=demand
If I rip out starttls=critical tls_reqcert=demand then sync works no
problem.
If I enable logging on the PROVIDER I see:
Mar 14 16:35:46 ldap0 slapd[6838]: @(#) $OpenLDAP: slapd (Ubuntu) (Sep 15
2015 18:19:13) $#012#011buildd@lgw01-53
:/build/openldap-2QUgtL/openldap-2.4.31/debian/build/servers/slapd
Mar 14 16:35:46 ldap0 slapd[6839]: slapd starting
Mar 14 16:35:46 ldap0 sudo: pam_unix(sudo:session): session closed for user
root
Mar 14 16:35:49 ldap0 slapd[6839]: conn=1000 fd=27 ACCEPT from IP=
10.10.5.3:17876 (IP=0.0.0.0:389)
Mar 14 16:35:49 ldap0 slapd[6839]: conn=1000 fd=27 closed (connection lost)
Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 fd=27 ACCEPT from IP=
10.10.3.117:60312 (IP=0.0.0.0:389)
Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 op=0 BIND dn="cn=admin,dc=
*qxxxxxxxxd*,dc=com" method=128
Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 op=0 BIND dn="cn=admin,dc=
*qxxxxxxxxd*,dc=com" mech=SIMPLE ssf=0
Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 op=0 RESULT tag=97 err=0 text=
Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 op=1 SRCH base="cn=accesslog"
scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))"
Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 op=1 SRCH attr=targetDN
changeType changes newRDN deleteOldRDN newSuperior entryCSN
Mar 14 16:35:55 ldap0 slapd[6839]: Entry
reqStart=20160314224152.000005Z,cn=accesslog CSN
20160314224152.708568Z#000000#000#000000 older or equal to ctx
20160314224152.708568Z#000000#000#000000
Mar 14 16:35:55 ldap0 slapd[6839]: syncprov_search_response:
cookie=rid=317,csn=20160314224255.836334Z#000000#000#000000
Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 op=2 UNBIND
Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 fd=27 closed
So .......... it looks like ... sync works until it doesn't because ...
we're not binding consumer to provider TLS because .. ?
WAIT A GOSH DARN SECOND HERE ....
0-16:41 djh@ldap1 ~$
*sudo ldapsearch -Q -Y EXTERNAL -H ldapi:/// -LLL -b cn=config
olcDatabase={1}hdb olcSyncRepldn: olcDatabase={1}hdb,cn=config*
olcSyncrepl: {0}rid=317 provider=ldap://ldap0.mtv.qxxxxxxxxd.com
bindmethod=si
mple binddn="cn=admin,dc=qxxxxxxxxd,dc=com" credentials=secret searchbase
="dc=qxxxxxxxxd,dc=com" logbase="cn=accesslog"
logfilter="(&(objectClass=audi
tWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist
retry="
60 +" *syncdata=accesslogstarttls=critical* tls_reqcert=demand
Yeah ...
0-16:43 djh@ldap1 ~$ *cat consumer_sync_tls.ldif*
dn: olcDatabase={1}hdb,cn=config
replace: olcSyncRepl
olcSyncRepl: rid=317 provider=ldap://ldap0.mtv.qxxxxxxxxd.com
bindmethod=simple binddn="cn=admin,dc=qxxxxxxxxd,dc=com"
credentials=secret searchbase="dc=qxxxxxxxxd,dc=com"
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
schemachecking=on
type=refreshAndPersist retry="60 +" syncdata=accesslog
starttls=critical tls_reqcert=demand
0-16:43 djh@ldap1 ~$
*sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f
consumer_sync_tls.ldifSASL/EXTERNAL authentication started*
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={1}hdb,cn=config"
No errors ...
**edit consumer_sync_tls.ldif, add a space to the end of the line ending in
syncdata=accesslog**
0-16:45 djh@ldap1 ~$
*sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f
consumer_sync_tls.ldifSASL/EXTERNAL authentication started*
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={1}hdb,cn=config"
Same result, no errors, aaand:
0-16:46 djh@ldap1 ~$ *ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base
-b dc=**qxxxxxxxxd,dc=com contextCSN # consumer*
dn: dc=qxxxxxxxxd,dc=com
contextCSN: 20160314224255.836334Z#000000#000#000000
Well, I just paid some dues.
I want to add olcLogLevel config perhaps? Would that have helped me here?
Thanks ...
-danny
--
http://dannyman.toldme.com
8 years, 8 months
RE: Multi Master OpenLdap.
by arun.sasi1＠wipro.com
And also I could see below message
nonpresent_callback: rid=003 present UUI
Thanks,
-Arun
From: Arun Sasi V (WI01 - Manage IT)
Sent: Monday, July 11, 2011 1:36 PM
To: 'E.S. Rosenberg'
Cc: openldap-technical(a)openldap.org
Subject: RE: Multi Master OpenLdap.
Thank you very much Eli for concidering my issue. Here is my scenario...
I couldn’t find any abnormality in log files and also I never seen any deletion logs in the server. Slapd will go for hang and some ID`s will get disappear same will be replicate to slaves too. Mainly Groups and Computer accounts
I can see some UNBIND and connection lost logs from one server and another multimaster server from
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138411 op=24 SEARCH RESULT tag=101 err=32 nentries=0 text=
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138424 op=12 SRCH base="ou=Groups,dc=emb,dc=slb,dc=com" scope=2 deref=0 filter="(&(objectClass=sambaGroupMapping)(gidNumber=65534))"
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138424 op=12 SRCH attr=gidNumber sambaSID sambaGroupType sambaSIDList description displayName cn objectClass
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138424 op=12 SEARCH RESULT tag=101 err=0 nentries=0 text=
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138415 op=21 SRCH base="sambaDomainName=EMB,sambaDomainName=emb,dc=emb,dc=slb,dc=com" scope=2 deref=0 filter="(&(objectClass=sambaTrustedDomainPassword)(sambaDomainName=emb))"
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138415 op=21 SEARCH RESULT tag=101 err=32 nentries=0 text=
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138385 op=46 SRCH base="ou=Groups,dc=emb,dc=slb,dc=com" scope=2 deref=0 filter="(&(objectClass=sambaGroupMapping)(|(displayName=test)(cn=test)))"
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138385 op=46 SRCH attr=gidNumber sambaSID sambaGroupType sambaSIDList description displayName cn objectClass
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: <= bdb_equality_candidates: (displayName) not indexed
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: <= bdb_equality_candidates: (cn) not indexed
Jul 11 04:07:53 gb0135embldap01 slapd[21335]: @(#) $OpenLDAP: slapd 2.4.15 (Mar 19 2009 10:07:59) $ ^Ibuildd@yellow:/build/buildd/openldap-2.4.15/debian/build/servers/slapd
Jul 11 04:07:54 gb0135embldap01 slapd[21337]: slapd starting
Jul 11 04:07:54 gb0135embldap01 slapd[21337]: conn=0 fd=23 ACCEPT from IP=[::1]:57016 (IP=[::]:389)
Jul 11 04:07:54 gb0135embldap01 slapd[21337]: conn=1 fd=24 ACCEPT from IP=134.32.44.37:40763 (IP=0.0.0.0:389)
OLCDATABSE
dn: olcDatabase={1}hdb
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=emb,dc=slb,dc=com
olcAccess: {0}to attrs=userPassword,shadowLastChange,sambaLMPassword,sambaNTPassword
by dn="cn=admin,dc=emb,dc=slb,dc=com" write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=136.250.9.48 write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=163.185.18.238 write
by anonymous auth by self write
by * none
olcAccess: {1}to dn.base="" by * read
#Enable Local Admin to add users in the Group and also SunOne to add users to country groups
olcAccess: {2}to dn.subtree="ou=groups,dc=emb,dc=slb,dc=com"
by set="user/uid & [cn=group-admin,ou=SuperGroups,dc=emb,dc=slb,dc=com]/memberuid" write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=136.250.9.48 write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=163.185.18.238 write
by * read
#Enable Local Admin to add computers
olcAccess: {3}to dn.subtree="ou=Computers,dc=emb,dc=slb,dc=com"
by set="user/uid & [cn=group-admin,ou=SuperGroups,dc=emb,dc=slb,dc=com]/memberuid" write
by * read
#Enable shell-admin to set up local user access
olcAccess: {4}to attrs=loginShell,homeDirectory
by set="user/uid & [cn=shell-admin,ou=SuperGroups,dc=emb,dc=slb,dc=com]/memberuid" write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=136.250.9.48 write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=163.185.18.238 write
by * read
#Enable write access to account sun-one-replication for sun ldap replication.
olcAccess: {5}to *
by dn="cn=admin,dc=emb,dc=slb,dc=com" write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=136.250.9.48 write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=163.185.18.238 write
by * read
olcLastMod: TRUE
olcDbCheckpoint: 512 30
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: loginShell eq
olcDbIndex: uid eq,pres,sub
olcDbIndex: memberUid eq,pres,sub
olcDbIndex: uniqueMember eq,pres
olcDbIndex: sambaSID eq
olcDbIndex: sambaPrimaryGroupSID eq
olcDbIndex: sambaGroupType eq
olcDbIndex: sambaSIDList eq
olcDbIndex: sambaDomainName eq
olcDbIndex: default sub
structuralObjectClass: olcHdbConfig
entryUUID: f479600a-5f34-102f-8ddd-3ff046e70702
creatorsName: cn=admin,cn=config
createTimestamp: 20100928101442Z
olcRootDN: cn=admin,dc=emb,dc=slb,dc=com
olcSyncrepl: {0}rid=003 provider=ldap://gb0135embldap01.emb.slb.com binddn="cn
=admin,dc=emb,dc=slb,dc=com" bindmethod=simple credentials=Bsl@121z searchbas
e="dc=emb,dc=slb,dc=com" type=refreshOnly interval=00:00:00:10 retry="5 5 300
5" timeout=1 starttls=yes
olcSyncrepl: {1}rid=004 provider=ldap://ae0042embldap01.emb.slb.com binddn="cn
=admin,dc=emb,dc=slb,dc=com" bindmethod=simple credentials=Bsl@121z searchbas
e="dc=emb,dc=slb,dc=com" type=refreshOnly interval=00:00:00:10 retry="5 5 300
5" timeout=1 starttls=yes
olcMirrorMode: TRUE
entryCSN: 20100928191927.932499Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20100928191927Z
Ldap Version
@(#) $OpenLDAP: slapd 2.4.15 (Mar 19 2009 10:07:59) $
Operating system
Distributor ID: Ubuntu
Description: Ubuntu 9.04
Release: 9.04
Codename: jaunty
Thanks,
-Arun
-----Original Message-----
From: E.S. Rosenberg [mailto:esr@g.jct.ac.il]
Sent: Monday, July 11, 2011 12:58 PM
To: Arun Sasi V (WI01 - Manage IT)
Cc: openldap-technical(a)openldap.org
Subject: Re: Multi Master OpenLdap.
Have you tried raising the loglevel?
Are the schemas the same between the servers?
Is time in sync between the servers?
What versions are you dealing with?
You don't provide a lot of info and most of us are not clairvoyant....
Regards,
Eli
2011/7/11 <arun.sasi1(a)wipro.com>:
>
>
>
>
> Thanks,
>
> -Arun
>
>
>
> From: Arun Sasi V (WI01 - Manage IT)
> Sent: Wednesday, July 06, 2011 5:46 PM
> To: 'openldap-technical(a)openldap.org'
> Subject: Multi Master OpenLdap.
>
>
>
> Hello Team,
>
>
>
> I have configured Multi-master Mirror mode replica setup in our environment.
> We have 3 regions slave Ldap server which is read only and two location we
> have configured as mirror mode replica Ldap. My problem here is…
>
>
>
> Master Ldap is going hang some times and some ID`s are disappearing from the
> master server. I couldn’t find any logs over there for why ID`s are
> disappearing and also why Ldap is going hung state.
>
>
>
> Thanks & Regards,
>
> Arun Sasi V
>
> Please do not print this email unless it is absolutely necessary.
>
> The information contained in this electronic message and any attachments to
> this message are intended for the exclusive use of the addressee(s) and may
> contain proprietary, confidential or privileged information. If you are not
> the intended recipient, you should not disseminate, distribute or copy this
> e-mail. Please notify the sender immediately and destroy all copies of this
> message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient should
> check this email and any attachments for the presence of viruses. The
> company accepts no liability for any damage caused by any virus transmitted
> by this email.
>
> www.wipro.com
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
13 years, 4 months
Re: Multi-master replication (ldap_sasl_bind_s failed)
by Artur Nike
I run slap2 for:
/usr/sbin/slapd -h ldap://slap2:389 -d 16383 -u openldap -g openldap
52aef96c =>do_syncrepl rid=004
ldap_create
ldap_url_parse_ext(ldap://ldap1:389)
ldap_sasl_bind_s
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap1:389
52aef96c =>do_syncrepl rid=005
ldap_create
ldap_url_parse_ext(ldap://ldap2:389)
ldap_sasl_bind_s
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap2:389
52aef971 daemon: epoll: listen=7 active_threads=0 tvp=zero
52aef971 daemon: epoll: listen=8 active_threads=0 tvp=zero
*ldap_connect_to_host: getaddrinfo failed: Name or service not known*
52aef976 slap_client_connect: *URI=ldap://ldap1:389
*DN="cn=admin,dc=example,dc=com"
ldap_sasl_bind_s failed (-1)
52aef976 do_syncrepl: rid=004 rc -1 retrying (4 retries left)
52aef976 daemon: activity on 1 descriptor
52aef976 daemon: activity on:52aef976
52aef976 daemon: epoll: listen=7 active_threads=0 tvp=zero
52aef976 daemon: epoll: listen=8 active_threads=0 tvp=zero
*ldap_connect_to_host: getaddrinfo failed: Name or service not known*
52aef976 slap_client_connect: *URI=ldap://ldap2:389
*DN="cn=admin,dc=example,dc=com"
ldap_sasl_bind_s failed (-1)
52aef976 do_syncrepl: rid=005 rc -1 retrying (4 retries left)
52aef976 daemon: activity on 1 descriptor
52aef976 daemon: activity on:52aef976
52aef976 daemon: epoll: listen=7 active_threads=0 tvp=zero
52aef976 daemon: epoll: listen=8 active_threads=0 tvp=zero
ldap1 --> slap1
ldap2 --> slap2
...and every working.
I'm blind and so the topic !!!
Thread is closed
2013/12/16 Artur Nike <opalsie(a)gmail.com>
> Hi all,
>
> My adventure with LDAP lasts a few months, and I came to the topic of
> replication,
> namely multiple-master replication.
> cn = config is replicated perfectly, but the schema, say, dc = example, dc
> = com does not want to: (.
>
> I have two servers slap1 and slap2
>
> I have a standard installation
> ##Server slap1
> whezzy debian 64bit
> apt-get install-y slapd ldap-utils
> added my scheme
> ldapadd-Y EXTERNAL-H ldapi :///-f $ CURRENT / memberof.ldif
> ldapadd-Y EXTERNAL-H ldapi :///-f $ CURRENT / refint.ldif
> # Add "ldap :/ / ldap1 / in /etc/default/slapd
> sed-i "/^
> SLAPD_SERVICES/s/=[^]*/=\"ldap:\/\/slap1\//'/etc/default/slapd
> ldapmodify-Y EXTERNAL-H ldapi :/ / /-f replica1.ldif
>
> where replica1.ldif (replication configuration)::
> dn: cn=config
> changetype: modify
> add: olcServerID
> olcServerID: 1
>
> dn: cn=module{0},cn=config
> changetype: modify
> add: olcModuleLoad
> olcModuleLoad: {1}syncprov.la
>
> dn: olcDatabase={0}config,cn=config
> changetype: modify
> add: olcRootPW
> #only for tests
> olcRootPW: 123
>
> dn: cn=config
> changetype: modify
> replace: olcServerID
> olcServerID: 1 ldap://slap1/
> olcServerID: 2 ldap://slap2/
>
> 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://slap1/
> binddn="cn=admin,cn=config"
> bindmethod=simple credentials=123
> searchbase="cn=config" type=refreshAndPersist
> retry="5 5 300 5" timeout=1
> olcSyncRepl: rid=002 provider=ldap://slap2/
> binddn="cn=admin,cn=config"
> bindmethod=simple credentials=123
> searchbase="cn=config" type=refreshAndPersist
> retry="5 5 300 5" timeout=1
> -
> add: olcMirrorMode
> olcMirrorMode: TRUE
>
> This same scenario takes on a server slap2 (the name change slap1 -> slap2)
>
> where replica2.ldif (replication configuration only servers slap2) :
> dn: cn=config
> changetype: modify
> add: olcServerID
> olcServerID: 2
>
> dn: cn=module{0},cn=config
> changetype: modify
> add: olcModuleLoad
> olcModuleLoad: {1}syncprov.la
>
> dn: olcDatabase={0}config,cn=config
> changetype: modify
> #only for tests
> add: olcRootPW
> olcRootPW: 123
>
> dn: cn=config
> changetype: modify
> replace: olcServerID
> olcServerID: 1 ldap://slap1/
> olcServerID: 2 ldap://slap2/
>
> 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://slap1/
> binddn="cn=admin,cn=config"
> bindmethod=simple credentials=123
> searchbase="cn=config" type=refreshAndPersist
> retry="5 5 300 5" timeout=1
> olcSyncRepl: rid=002 provider=ldap://slap2/
> binddn="cn=admin,cn=config"
> bindmethod=simple credentials=123
> searchbase="cn=config" type=refreshAndPersist
> retry="5 5 300 5" timeout=1
> -
> add: olcMirrorMode
> olcMirrorMode: TRUE
>
>
> and it works , the whole configuration is replicated .
>
> Now I want ( I'm trying to add a replication scheme . )
> Adds only one server , eg slap2 :
> ldapmodify - Y EXTERNAL -H ldapi :/ / / -f rep_schema.ldif
>
> where rep_schema.ldif :
>
> # add replica schema
> dn: olcDatabase={1}hdb,cn=config
> changetype: modify
> replace: olcRootPW
> olcRootPW: 123
> -
> replace: olcRootDN
> olcRootDN: cn=admin,dc=example,dc=com
>
> dn: olcDatabase={1}hdb,cn=config
> changetype: modify
> add: olcLimits
> olcLimits: dn.exact="cn=admin,dc=example,dc=com"
> time.soft=unlimited
> time.hard=unlimited size.soft=unlimited size.hard=unlimited
> -
> add: olcSyncRepl
> olcSyncRepl: rid=004 provider=ldap://ldap1/
> binddn="cn=admin,dc=example,dc=com"
> bindmethod=simple credentials="123"
> searchbase="dc=example,dc=com"
> starttls=no
> filter="(objectclass=*)"
> attrs="*,+" scope=sub
> schemachecking=of
> type=refreshAndPersist interval=00:00:00:10 retry="5 5 10 5"
> timeout=1
> olcSyncRepl: rid=005 provider=ldap://ldap2/
> binddn="cn=admin,dc=example,dc=com"
> bindmethod=simple credentials="123"
> searchbase="dc=example,dc=com"
> starttls=no
> filter="(objectclass=*)"
> attrs="*,+" scope=sub
> schemachecking=off
> type=refreshAndPersist interval=00:00:00:10 retry="5 5 10 5"
> timeout=1
> -
> add: olcDbIndex
> olcDbIndex: entryUUID eq
> -
> add: olcDbIndex
> olcDbIndex: entryCSN eq
> -
> add: olcMirrorMode
> olcMirrorMode: TRUE
>
> dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config
> changetype: add
> objectClass: olcOverlayConfig
> objectClass: olcSyncProvConfig
> olcOverlay: syncprov
>
> Configuration replicates and the end, schema does not replicate.
> If you try to replicate one of the servers are in the logs I see:
>
>
> Dec 15 23:44:48 slap1 slapd[4496]: do_syncrepl: rid=004 rc -1 quitting
> Dec 15 23:44:48 slap1 slapd[4496]: slap_client_connect: URI=ldap://ldap2/
> DN="cn=admin,dc=example,dc=com" ldap_sasl_bind_s failed (-1)
> Dec 15 23:44:48 slap1 slapd[4496]: do_syncrepl: rid=005 rc -1 retrying
> Dec 15 23:44:58 slap1 slapd[4496]: =>do_syncrepl rid=005
> Dec 15 23:44:58 slap1 slapd[4496]: slap_client_connect: URI=ldap://ldap2/
> DN="cn=admin,dc=example,dc=com" ldap_sasl_bind_s failed (-1)
>
> Dec 15 23:44:50 slap2 slapd[4456]: do_syncrepl: rid=004 rc -1 retrying
> Dec 15 23:44:54 slap2 slapd[4456]: =>do_syncrepl rid=005
> Dec 15 23:44:54 slap2 slapd[4456]: slap_client_connect: URI=ldap://ldap2/
> DN="cn=admin,dc=example,dc=com" ldap_sasl_bind_s failed (-1)
> Dec 15 23:44:54 slap2 slapd[4456]: do_syncrepl: rid=005 rc -1 quitting
> Dec 15 23:45:00 slap2 slapd[4456]: =>do_syncrepl rid=004
> Dec 15 23:45:00 slap2 slapd[4456]: slap_client_connect: URI=ldap://ldap1/
> DN="cn=admin,dc=example,dc=com" ldap_sasl_bind_s failed (-1)
>
>
> from server slap2 to search slap1:
> ldapsearch -x -D cn=admin,dc=example,dc=com-H ldap://slap1/ -b
> dc=example,dc=com -w 123 (working)
>
> from server slap1 to search slap2:
> ldapsearch -x -D cn=admin,dc=example,dc=com-H ldap://slap2/ -b
> dc=example,dc=com -w 123 (working)
>
> I'm out of ideas...
> user : DN="cn=admin,dc=example,dc=com" is created automatically when I
> install slapd
>
> Can anyone have any suggestions or experience with this problem.
> For all, thank you in advance.
>
> Muniek
>
10 years, 11 months
Re: N-way multi master configuration issue
by Brett Maxfield
You have not added the syncrepl overlay to the syncrepl provider(s). You should probably re-read the available documentation on syncrepl replication, you have missed several things which are clearly documented there.
Perhaps you should start with the simple example in the openldap documentation, get that working locally, and then compare differences to your problematic setup.
Poorly understood / configured multimaster replication is probably worse than not having any multimaster replication at all.
On 30/08/2011, at 4:03 PM, Naga Chaitanya Palle <Naga.Chaitanya(a)aricent.com> wrote:
> Any inputs please?
> ________________________________________
> From: Naga Chaitanya Palle
> Sent: Monday, August 29, 2011 1:37 PM
> To: Buchan Milne
> Cc: openldap-technical(a)openldap.org
> Subject: RE: N-way multi master configuration issue
>
> Hi Buchan,
>
> After making the changes are per your suggestions, I am still not able to read data between the servers.
>
> Also, I deleted DI data on server 2 and restarted to import data from server1 , but no use.
> Can you please check the slapd.conf files and suggest.
>
>
> Server 1 slapd.conf file
> #
> # See slapd.conf(5) for details on configuration options.
> # This file should NOT be world readable.
> #
> include /usr/share/openldap2.4/schema/sudo.schema
> include /usr/share/openldap2.4/schema/core.schema
> include /usr/share/openldap2.4/schema/cosine.schema
> include /usr/share/openldap2.4/schema/inetorgperson.schema
> include /usr/share/openldap2.4/schema/nis.schema
> include /usr/share/openldap2.4/schema/misc.schema
> include /usr/share/openldap2.4/schema/openldap.schema
> include /usr/share/openldap2.4/schema/ppolicy.schema
> include /usr/share/openldap2.4/schema/corba.schema
>
> loglevel 296
>
>
> # 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/ldap2.4/slapd.pid
> argsfile /var/run/ldap2.4/slapd.args
>
>
> access to attrs=userPassword
> by self write
> by users read
> by anonymous auth
>
>
> #access to attrs=shadowLastChange
> # by self write
> # by * auth
>
> access to *
> by * read
>
> access to *
> by dn.base="cn=Manager,dc=comverse-in,dc=com" read
> by * break
>
> # Load dynamic backend modules:
> # modulepath /usr/lib/openldap
>
> # 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
>
> #TLSCipherSuite HIGH:MEDIUM:+SSLv2
> #TLSCACertificateFile /etc/openldap2.4/cacerts/cacert.pem
> #TLSCertificateFile /etc/openldap2.4/cacerts/slapd-cert.pem
> #TLSCertificateKeyFile /etc/openldap2.4/cacerts/slapd-key.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!
>
> #######################################################################
> # ldbm and/or bdb database definitions
> #######################################################################
> serverId 001
>
> database bdb
> suffix "dc=comverse-in,dc=com"
> rootdn "cn=Manager,dc=comverse-in,dc=com"
> rootpw {SSHA}9tKeVZfgKFCfgIFQxXt5esH0HhQk1dIS
>
> # 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/ldap2.4
>
>
> # 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 sudoUser eq
>
> index sudoUser eq
> index member eq
> index ou,cn,mail,surname,givenname eq,pres,sub
> index uidNumber,gidNumber,loginShell eq,pres
> index uid,memberUid eq,pres,sub
> #index objectclass,entryCSN,entryUUID eq
>
> # Load dynamic backend modules:
> # modulepath /usr/lib/openldap
>
> modulepath /usr/lib/openldap2.4
>
>
> # 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
> syncrepl rid=123
> provider=ldap://devonly144.comverse-in.com
> type=refreshAndPersist
> interval=00:00:01:00
> searchbase="dc=comverse-in,dc=com"
> filter="(objectClass=*)"
> scope=sub
> attrs="*"
> schemachecking=off
> bindmethod=simple
> binddn="cn=Manager,dc=comverse-in,dc=com"
> credentials=sonora
>
>
> index objectClass,entryCSN,entryUUID eq
> mirrormode true
>
>
> overlay syncprov
> syncprov-checkpoint 100 10
>
> overlay ppolicy
> ppolicy_default "cn=DefaultPassword,ou=pwpolicies,dc=comverse-in,dc=com"
> ppolicy_hash_cleartext
> ppolicy_use_lockout
>
> #SUDOERS_BASE=ou=SUDOers,dc=comverse-in,dc=com
>
> # 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
>
> #replogfile /var/lib/ldap/openldap-master-replog
> #replica uri=ldaps://rht144.comverse-in.com:389 starttls=critical
>
>
> Server2 slapd.conf file
> #
> # See slapd.conf(5) for details on configuration options.
> # This file should NOT be world readable.
> #
> include /usr/share/openldap2.4/schema/sudo.schema
> include /usr/share/openldap2.4/schema/core.schema
> include /usr/share/openldap2.4/schema/cosine.schema
> include /usr/share/openldap2.4/schema/inetorgperson.schema
> include /usr/share/openldap2.4/schema/nis.schema
> include /usr/share/openldap2.4/schema/misc.schema
> include /usr/share/openldap2.4/schema/openldap.schema
> include /usr/share/openldap2.4/schema/ppolicy.schema
> include /usr/share/openldap2.4/schema/corba.schema
>
> loglevel 296
>
>
> # 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/ldap2.4/slapd.pid
> argsfile /var/run/ldap2.4/slapd.args
>
>
> access to attrs=userPassword
> by self write
> by users read
> by anonymous auth
>
>
> #access to attrs=shadowLastChange
> # by self write
> # by * auth
>
> access to *
> by * read
>
> access to *
> by dn.base="cn=Manager,dc=comverse-in,dc=com" read
> by * break
>
>
> # Load dynamic backend modules:
> # modulepath /usr/lib/openldap
>
> # 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
>
> #TLSCipherSuite HIGH:MEDIUM:+SSLv2
> #TLSCACertificateFile /etc/openldap2.4/cacerts/cacert.pem
> #TLSCertificateFile /etc/openldap2.4/cacerts/slapd-cert.pem
> #TLSCertificateKeyFile /etc/openldap2.4/cacerts/slapd-key.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!
>
> #######################################################################
> # ldbm and/or bdb database definitions
> #######################################################################
> serverId 002
>
> #database bdb
> database bdb
> #suffix "dc=comverse-in,dc=com"
> suffix "dc=comverse-in,dc=com"
> #rootdn "cn=Manager,dc=comverse-in,dc=com"
> rootdn "cn=Manager,dc=comverse-in,dc=com"
> rootpw {SSHA}4qLml3DcOyfwiKlN/garIms4a8fmsNkx
> #rootpw sonora
>
> # 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/ldap2.4
>
>
> # 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 sudoUser eq
>
> index sudoUser eq
> index member eq
> index ou,cn,mail,surname,givenname eq,pres,sub
> index uidNumber,gidNumber,loginShell eq,pres
> index uid,memberUid eq,pres,sub
> #index objectclass,entryCSN,entryUUID eq
>
> # Load dynamic backend modules:
> # modulepath /usr/lib/openldap
>
> modulepath /usr/lib/openldap2.4
>
>
> # 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
>
>
> overlay ppolicy
> ppolicy_default "cn=DefaultPassword,ou=pwpolicies,dc=comverse-in,dc=com"
> ppolicy_hash_cleartext
> ppolicy_use_lockout
>
> #SUDOERS_BASE=ou=SUDOers,dc=comverse-in,dc=com
>
> # 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
>
> #replogfile /var/lib/ldap/openldap-master-replog
> #replica uri=ldaps://rht144.comverse-in.com:389 starttls=critical binddn="cn=Manager,dc=comverse-in,dc=com" bindmethod=simple credentials=sonora
> #serverId 2
> syncrepl rid=124
> provider=ldap://uplite98.comverse-in.com
> type=refreshAndPersist
> interval=00:00:01:00
> searchbase="dc=comverse-in,dc=com"
> filter="(objectClass=*)"
> scope=sub
> attrs="*"
> schemachecking=off
> bindmethod=simple
> binddn="cn=Manager,dc=comverse-in,dc=com"
> credentials=sonora
> #updateref ldap://uplite98.comverse-in.com
>
> index objectClass,entryCSN,entryUUID eq
>
> mirrormode true
>
> overlay syncprov
> syncprov-checkpoint 100 10
>
> Thanks and Regards,
> Naga Chaitanya
>
>
>
> -----Original Message-----
> From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net]
> Sent: Friday, August 26, 2011 7:15 PM
> To: Naga Chaitanya Palle
> Cc: openldap-technical(a)openldap.org
> Subject: Re: N-way multi master configuration issue
>
> On Friday, 26 August 2011 15:28:13 Naga Chaitanya Palle wrote:
>> Hi buchan,
>>
>> My server 1 is uplite98.comverse-in.com. In its slapd.conf, I have syncrepl
>> pointing to server 2 devonly144.comverse-in.com and vice versa for
>> server2.
>
> Then your serverid (and, it should actually be serverId) is wrong:
>
>>> serverid 124 ldap://devonly144.comverse-in.com
>>> syncrepl rid=124
>>>
>>> provider=ldap://devonly144.comverse-in.com:389
>
> The URI form of serverId is useful if you have the same configuration on all
> your masters, in which case the listening address of your server must match
> one of the URIs. You may want to use this form for now:
>
> serverId 1
>
> If your serverId's weren't correct (check the contextCSNs), you should
> probably re-import an export of one server on the other one.
>
>> I did not exactly understand what you indicated.
>> Can you please be more specific about what changes needs to be done in the
>> slapd.conf file?
>
> In a multi-master setup, each server should be replicating off *all* servers,
> including itself.
>
>
>
>> Thanks and Regards,
>> Naga Chaitanya
>>
>> -----Original Message-----
>> From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net]
>> Sent: Friday, August 26, 2011 6:56 PM
>> To: openldap-technical(a)openldap.org
>> Cc: Naga Chaitanya Palle
>> Subject: Re: N-way multi master configuration issue
>>
>> On Friday, 26 August 2011 12:56:38 Naga Chaitanya Palle wrote:
>>> Hi,
>>>
>>> I am trying to set up N-way multimaster configuration using syncrepl on
>>> openldap2.4 for RHEL 5.4
>>>
>>> Currently I am using two masters for testing.
>>>
>>> The slapd.conf on server1 is
>>> moduleload syncprov.la
>>> serverid 124 ldap://devonly144.comverse-in.com
>>> syncrepl rid=124
>>>
>>> provider=ldap://devonly144.comverse-in.com:389
>>> type=refreshAndPersist
>>> interval=00:00:01:00
>>> searchbase="dc=comverse-in,dc=com"
>>> filter="(objectClass=*)"
>>> scope=sub
>>> attrs="*"
>>> schemachecking=off
>>> bindmethod=simple
>>> binddn="cn=Manager,dc=comverse-in,dc=com"
>>> credentials=sonora
>>>
>>> index objectClass,entryCSN,entryUUID eq
>>> mirrormode true
>>>
>>> overlay syncprov
>>> syncprov-checkpoint 100 10
>>>
>>>
>>> The slapd.conf on server2 is
>>> moduleload syncprov.la
>>> serverid 123 ldap://uplite98.comverse-in.com
>>> syncrepl rid=123
>>>
>>> provider=ldap://uplite98.comverse-in.com:389
>>> type=refreshAndPersist
>>> interval=00:00:01:00
>>> searchbase="dc=comverse-in,dc=com"
>>> filter="(objectClass=*)"
>>> scope=sub
>>> attrs="*"
>>> schemachecking=off
>>> bindmethod=simple
>>> binddn="cn=Manager,dc=comverse-in,dc=com"
>>> credentials=sonora
>>>
>>> index objectClass,entryCSN,entryUUID eq
>>> mirrormode true
>>>
>>> overlay syncprov
>>> syncprov-checkpoint 100 10
>>>
>>> But there is no data synchronization happening between the severs.
>>
>> Of course not, you have configured each server only to replicate from
>> itself.
>>
>>> When I added test3 user on server1, it is not reflecting on server 2.
>>> Same way when I added test4 user on server2 it is not reflecting on
>>> server1.
>>>
>>> Please let me know what is missing in this configuration.
>>
>> syncrepl statements pointing to the other master.
>>
>> Regards,
>> Buchan
>>
>>
>>
>>
>> ===========================================================================
>> ==== Please refer to http://www.aricent.com/legal/email_disclaimer.html for
>> important disclosures regarding this electronic communication.
>> ==========================================================================
>> =====
>
>
>
>
> ===============================================================================
> Please refer to http://www.aricent.com/legal/email_disclaimer.html
> for important disclosures regarding this electronic communication.
> ===============================================================================
>
13 years, 2 months
Re: OpenLDAP TLS server authority verification
by Daniel Pocock
On 03/03/12 15:17, Michael Ströder wrote:
> Daniel Pocock wrote:
>> On 03/03/12 12:46, Michael Ströder wrote:
>>> Using DNS SRV is simply not specified regarding SSL/TLS. There's no way
>>> to map a naming context to a server cert despite your local security
>>> policy says your DNS is trusted by some other means.
>>>
>>>> A hostname can be a reference identity
>>>>
>>>> But a reference identity is not always a hostname. It depends on the
>>>> client configuration.
>>>
>>> The naming context (aka search root) cannot be a reference identity in
>>> the context of SSL/TLS. Period.
>>
>> The RFC does not say that.
>
> It does not have to say that.
>
>> Neither does it state that an implementation
>> should support the concept. It appears to leave the implementor some
>> discretion about their choice of reference identity.
>
> Yes.
>
>>> Feel free to write an Internet draft updating TLS-RFCs and RFC 2782.
>>> This could specify how a naming context is compared to some information
>>> in a subjectAltName extension since there's no standard saying something
>>> about this yet. A suitable GeneralName choice would be directoryName.
>>
>> It is already in RFC 6125:
>>
>> http://tools.ietf.org/html/rfc6125#section-6.2
>
> I can't see any language which clearly defines rules how to derive the
> reference identity from a LDAP naming context. Just poiting out that it
> is no problem with SIP is not sufficient.
>
>> Many a mini-RFC about best practice for RFC 6125 in the LDAP world would
>> be useful though
>
> You would have to clearly define what a client has to do to derive and
> check the reference identity if its configuration simply contains
> ldaps:///dc=example,dc=com
>
> Frankly I don't like RFC 6125. IIRC I gave up reviewing the I-Ds when
> the authors insisted on adding support for wildcard certs.
The concepts proposed in RFC 6125 may not be ideal, but it does provide
a stronger solution than we have now when using DNS SRV + TLS together
The current implementation of the client code uses the hostname derived
from a DNS SRV lookup as a reference identity
Also, whatever is implemented, it may not please everyone: so just as
you can choose whether you want TLSv1 or SSLv2 support in the client
code, I think it is reasonable that an administrator should be able to
choose the policy they prefer for server validation: I'm not proposing
that a single solution should be imposed for everyone.
> If I understood you correctly you propose that if a server's cert
> contains subjectAltname::dNSName:example.com this cert should be
> accepted for any application protocol having something like
> dc=example,dc=com, @example.com etc.
> I don't like that approach. It broadens the semantics in such a way that
> you cannot have distinct server certs for different services. Mainly I
> think that untyped GeneralName::dNSName was defined before we had
> several types of SRV RRs (except MX RRs) and no-one ever clearly
> specified its semantics.
I agree it is not perfect: however, it is stronger than what we have now.
Some sites will find that level of security is quite sufficient (just
checking that the subjectAltname::dNSName = base DN). Bigger sites will
want something more, as you correctly point out ...
> Same problem like looking up MX RR for a domain and then connecting to
> the MX servers with StartTLS.
>
> For a naming context ldaps:///dc=example,dc=com one could specify that
> subjectAltname MUST contain dNSName:_ldaps._tcp.example.com to at least
> express the connection to the SRV RR for the LDAP service. Or other
> approaches with other types of GeneralName.
XMPP tried using otherName, but also support dNSName like SIP, here is
an example openssl.cnf fragment:
http://wiki.xmpp.org/web/XMPP_Server_Certificates
I believe adding the Extended Key Usage (EKU) extension to the
certificate provides the service-specific validation that you are aiming
for (e.g. to ensure that someone who has a cert for the mailserver of
example.org can't set up an unauthorised LDAP server for example.org)
Here is how they do it for SIP using EKU, maybe this RFC could even be
adapted as a model for LDAP:
http://tools.ietf.org/html/rfc5924#section-4
OpenSSL can generate such certs without too much trouble:
http://www.openssl.org/docs/apps/x509v3_config.html#Extended_Key_Usage_
12 years, 8 months
Re: slapd segfault in openldap 2.4.45
by Scott Koch
Correction, my openldap version is 2.4.45(typo'ed in previous post).
On Wed, Dec 13, 2017 at 11:23 AM Scott Koch <scottkoch(a)gmail.com> wrote:
> This is an RPM of openldap I built from the latest upstream source. This
> slapd server is running on RHEL 7.4 x86_64.
>
> Error message:
> 2017-12-13T00:13:34.944152-05:00 ldap1.example.com kernel: slapd[983]:
> segfault at 766f6730 ip 00007f0272e2549b sp 00007f02017f55b8 error 4 in
> libc-2.17.so[7f0272ce8000+1b8000]
>
> We have seen 15 or so instances of this issue and in all cases the last
> LDAP operations follow the same pattern where there is an ABANDON and
> UNBIND, then there is a SRCH operation. See log output below of full
> connection for the client that performs the last operation.
>
> Let me know if there is any other information I can provide to help
> troubleshoot this problem.
>
> Thanks in advance for the help!
> -Scott
>
> 2017-12-13T00:13:03.560693-05:00 ldap1.example.com slapd[26514]:
> conn=873638 fd=105 ACCEPT from IP=10.0.4.37:48520 (IP=0.0.0.0:389)
>
> 2017-12-13T00:13:03.560869-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=0 EXT oid=1.3.6.1.4.1.1466.20037
>
> 2017-12-13T00:13:03.561012-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=0 STARTTLS
>
> 2017-12-13T00:13:03.561211-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=0 RESULT oid= err=0 text=
>
> 2017-12-13T00:13:03.569367-05:00 ldap1.example.com slapd[26514]:
> conn=873638 fd=105 TLS established tls_ssf=256 ssf=256
>
> 2017-12-13T00:13:03.569853-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
>
> 2017-12-13T00:13:03.570014-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=1 SRCH attr=* altServer namingContexts supportedControl
> supportedExtension supportedFeatures supportedLDAPVersion
> supportedSASLMechanisms domainControllerFunctionality defaultNamingContext
> lastUSN highestCommittedUSN
>
> 2017-12-13T00:13:03.570215-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
>
> 2017-12-13T00:13:03.571953-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=2 SRCH base="dc=example,dc=com" scope=2 deref=0
> filter="(&(?objectClass=sudoRole)(|(!(?sudoHost=*))(?sudoHost=ALL)(?sudoHost=
> node1713.example.com)(?sudoHost=node1713)(?sudoHost=10.0.4.37)(?sudoHost=
> 10.134.0.0/18)(?sudoHost=ffff::ffff:ffff:fff:ffff)(?sudoHost=fe80::/64)(?sudoHost=+*)(|(?sudoHost=*\5C*)(?sudoHost=*?*)(?sudoHost=*\2A*)(?sudoHost=*[*]*)))
> <http://10.134.0.0/18)(?sudoHost=ffff::ffff:ffff:fff:ffff)(?sudoHost=fe80::/…>
> )"
>
> 2017-12-13T00:13:03.572214-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=2 SRCH attr=objectClass cn sudoCommand sudoHost sudoUser
> sudoOption sudoRunAs sudoRunAsUser sudoRunAsGroup sudoNotBefore
> sudoNotAfter sudoOrder modifyTimestamp
>
> 2017-12-13T00:13:03.573488-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text=
>
> 2017-12-13T00:13:34.943439-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=4 ABANDON msg=4
>
> 2017-12-13T00:13:34.943694-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=3 SRCH base="dc=example,dc=com" scope=2 deref=0
> filter="(&(uid=ntp)(objectClass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))"
>
> 2017-12-13T00:13:34.943885-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=5 UNBIND
>
> 2017-12-13T00:13:34.944092-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=3 SRCH attr=objectClass uid userPassword uidNumber gidNumber
> gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp
> modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning
> shadowInactive shadowExpire shadowFlag krbLastPwdChange
> krbPasswordExpiration pwdAttribute authorizedService accountExpires
> userAccountControl nsAccountLock host loginDisabled loginExpirationTime
> loginAllowedTimeMap sshPublicKey mail
>
6 years, 11 months
Re: Syncrepl on glued databases only replicates the superior and the first subordinate
by Robert Minsk
After some more testing f I turn off syncprov on all of my subordinates
and leave syncprov on on my superior it works. So it seems to be a
problem with having syncprov on subordinates.
On 12/18/2013 03:34 PM, Robert Minsk wrote:
> Openldap version 2.4.35
>
> Our global ldap server has the following naming contexts:
>
> namingContexts: o=global,ou=studios,dc=methodstudios,dc=net
> namingContexts: o=chi01,ou=studios,dc=methodstudios,dc=net
> namingContexts: o=det01,ou=studios,dc=methodstudios,dc=net
> namingContexts: o=la01,ou=studios,dc=methodstudios,dc=net
> namingContexts: o=ny01,ou=studios,dc=methodstudios,dc=net
> namingContexts: o=lon01,ou=studios,dc=methodstudios,dc=net
> namingContexts: o=van01,ou=studios,dc=methodstudios,dc=net
> namingContexts: ou=studios,dc=methodstudios,dc=net
> namingContexts: ou=login,dc=methodstudios,dc=net
>
> ou=studio,dc=methodstudios,dc=net is the superior database and global,
> chi01, det01, la01, ny01, lon01, van01 are all have "subordinate
> advertise" and are all sync providers.
>
> The sync provider:
>
> database mdb
> suffix "ou=studios,dc=methodstudios,dc=net"
> rootdn ...
> rootpw ...
> directory /var/lib/ldap/studios.methodstudios.net
> maxsize 17179869184
> serverID 201
>
> overlay glue
> overlay syncprov
> syncprov-reloadhint TRUE
> syncprov-checkpoint 100 5
> sync_use_subentry true
>
> ...
>
> The sync consumer only has a database for
> ou=studios,dc=methodstudios,dc=net.
>
> database mdb
> suffix "ou=studios,dc=methodstudios,dc=net"
> rootdn ...
> rootpw ...
> directory /var/lib/ldap/studios.methodstudios.net
> maxsize 17179869184
> serverID 202
>
> syncrepl rid=201 provider=ldap://<providor host name>
> type=refreshAndPersist retry="60 10 300 +"
> searchbase="ou=studios,dc=methodstudios,dc=net"
> bindmethod=simple starttls=yes
> binddn="..."
> credentials=... schemachecking=off
> sizelimit=unlimited timelimit=unlimited
> updateref ldap://<providor host name>
>
> It seems to be only syncing ou=studios,dc=methodstudios,dc=net and
> o=global,ou=studios,dc=methodstudios,dc=net. If I change the order of
> the provider server so that chi01 comes before global then only
> syncing ou=studios,dc=methodstudios,dc=net and
> o=chi01,ou=studios,dc=methodstudios,dc=net get sync.
>
> Am I doing anything obviously wrong?
>
> --
> Robert Minsk
> Systems and Software Engineer
>
> WWW.METHODSTUDIOS.COM <http://www.methodstudios.com>
> 730 Arizona Ave, Santa Monica, CA 90401
> O:+1 310 434 6500 <tel:+13104346500> // F:+1 310 434 6501
> <tel:+13104346501>
>
> Los Angeles
> <http://www.methodstudios.com/signature/url/los-angeles><http://www.methodstudios.com/signature/url/los-angeles>
>
>
> This e-mail and any attachments are intended only for use by the
> addressee(s) named herein and may contain confidential information. If
> you are not the intended recipient of this e-mail, you are hereby
> notified any dissemination, distribution or copying of this email and
> any attachments is strictly prohibited. If you receive this email in
> error, please immediately notify the sender by return email and
> permanently delete the original, any copy and any printout thereof.
> The integrity and security of e-mail cannot be guaranteed.
--
Robert Minsk
Systems and Software Engineer
WWW.METHODSTUDIOS.COM <http://www.methodstudios.com>
730 Arizona Ave, Santa Monica, CA 90401
O:+1 310 434 6500 <tel:+13104346500> // F:+1 310 434 6501
<tel:+13104346501>
Los Angeles
<http://www.methodstudios.com/signature/url/los-angeles><http://www.methodstudios.com/signature/url/los-angeles>
This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email and any attachments is strictly prohibited. If you receive this email in error, please immediately notify the sender by return email and permanently delete the original, any copy and any printout thereof. The integrity and security of e-mail cannot be guaranteed.
10 years, 11 months