RE: client server connection to LDAP/Kerberos
by Asmaa Ahmed
No, don't have any problem while running these commands from there!I can retrieve my data successfully.
Feb 2 11:59:49 ldap slapd[1059]: conn=1374 op=2 BIND dn="" method=163Feb 2 11:59:49 ldap slapd[1059]: conn=1374 op=2 BIND authcid="aahmed(a)DOMAIN.COM" authzid="aahmed(a)DOMAIN.COM"Feb 2 11:59:49 ldap slapd[1059]: conn=1374 op=2 BIND dn="uid=aahmed,ou=people,dc=domain,dc=com" mech=GSSAPI sasl_ssf=56 ssf=56Feb 2 11:59:49 ldap slapd[1059]: conn=1374 op=2 RESULT tag=97 err=0 text=Feb 2 11:59:49 ldap slapd[1059]: conn=1374 op=3 SRCH base="dc=domain,dc=com" scope=2 deref=0 filter="(objectClass=*)"Feb 2 11:59:49 ldap slapd[1059]: conn=1374 op=3 SEARCH RESULT tag=101 err=0 nentries=11 text=Feb 2 11:59:49 ldap slapd[1059]: conn=1374 op=4 UNBIND
Thanks.
> Date: Fri, 1 Feb 2013 13:53:29 -0600
> From: dwhite(a)olp.net
> To: asabatgirl(a)hotmail.com
> CC: openldap-technical(a)openldap.org
> Subject: Re: client server connection to LDAP/Kerberos
>
> On 02/01/13 10:08 +1100, Asmaa Ahmed wrote:
> >Hello,
> >
> >I recently added Kerberos authentication to my LDAP server, and I am trying
> >to connect the other servers to it.
> >I have a server running Davical shared calendar, and I hope to get it
> >working with my LDAP server again after Kerberos integration.
> >
> >Here is my configuration which was working before the integration and my
> >source is
> >"http://wiki.davical.org/w/Configuration/LDAP#Kerberos_Authentication"
> >
> > $c->authenticate_hook['config'] = array(
> > 'host' => 'ldap.domain.com', //host name of your LDAP Server
> > 'port' => '389', //port
> >// 'bindDN' => 'cn=admin,dc=domain,dc=com', //DN to bind request
> >// to this server (if required)
> >// 'passDN' => 'password', //Password of request bind
> > 'baseDNUsers' => 'ou=People,dc=domain,dc=com', //where to look for
> >valid user
> > 'filterUsers' => 'objectClass=*', //filter which must validate a user
> >according to RFC4515, i.e. surrounded by brackets
> > 'protocolVersion' => 3, // important for simple auth (no sasl)
> >// 'startTLS' => true, // securing your LDAP connection
> > 'i_use_mode_kerberos' => "i_know_what_i_am_doing",
> >
> >My slapd error logs:
> >Jan 31 23:40:00 ldap slapd[1059]: conn=1273 fd=43 ACCEPT from
> >IP=203.28.247.193:56887 (IP=0.0.0.0:389)
> >Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=0 BIND dn="" method=128
> >Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=0 RESULT tag=97 err=0 text=
> >Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=1 SRCH
> >base="ou=People,dc=domain,dc=com" scope=2 deref=0 filter="(objectClass=*)"
> >Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=1 SRCH attr=uid
> >modifyTimestamp cn mail
> >Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=1 SEARCH RESULT tag=101
> >err=32 nentries=0 text=
> >Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=2 UNBIND
> >
> >My OLC configuration:
> >root@ldap:/var/log# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config
> >"(|(cn=config)(olcDatabase={1}hdb))"
> >dn: cn=config
> >objectClass: olcGlobal
> >cn: config
> >olcArgsFile: /var/run/slapd/slapd.args
> >olcAuthzRegexp: {0}uid=([^,]+),cn=domain.com,cn=gssapi,cn=auth uid=$1
> > ,ou=people,dc=domain,dc=com
> >olcLogLevel: stats
> >olcPidFile: /var/run/slapd/slapd.pid
> >olcSaslRealm: DOMAIN.COM
> >olcToolThreads: 1
> >
> >dn: olcDatabase={1}hdb,cn=config
> >objectClass: olcDatabaseConfig
> >objectClass: olcHdbConfig
> >olcDatabase: {1}hdb
> >olcDbDirectory: /var/lib/ldap
> >olcSuffix: dc=domain,dc=com
> >olcAccess: {0}to attrs=userPassword,shadowLastChange by anonymous auth by *
> >no
> > ne
> >olcAccess: {1}to dn.subtree="ou=krb5,dc=domain,dc=com" by dn="c
> > n=adm-srv,ou=krb5,domain,dc=com" write by dn="cn=kdc-srv,ou
> > =krb5,domain,dc=com" read by * none
> >olcAccess: {2}to attrs=loginShell,gecos by self write by users read by *
> >none
> >olcAccess: {3}to dn.base="" by * read
> >olcAccess: {4}to * by users read by * none
> >olcLastMod: TRUE
> >olcRootDN: uid=admin,ou=people,domain,dc=com
> >
> >
> >Any suggestion to fix the binding and get my search working again with
> >kerberos authentication ?
> >
> >Thanks.
>
> Can you reproduce this problem with ldapsearch and/or ldapwhoami (-Y
> GSSAPI) on the server which is running davical?
>
> --
> Dan White
11 years, 9 months
Windows SSPI, NTLMSSP and OpenLDAP with SASL/GSSAPI
by Diego Morales
Hello,
I have a proprietary windows application trying to bind on my OpenLDAP
server using GSSAPI with NTLMSSP mechanism, instead of Kerberos. Is it
possible to support this on a (unix) OpenLDAP server?
Another option would be to make the software use GSSAPI + Kerberos
instead. Let me further explain:
I have a working samba + openldap setup with many windows
workstations. The said proprietary app has LDAP auth support, and
according to its maker it works with Active Directory and Novell NDS.
It does not support simple bind, nor LDAPS, (and probably not StartTLS
either). We don't have access to the app's source code and help from
its developers/tech-support is pretty unavailable.
Checking slapd's debug, we saw the app trying to use SASL+GSSAPI to
bind. So we went on and configured a minimal Kerberos setup and
SASL+GSSAPI support for OpenLDAP on a test ldap server. It seems to be
working perfectly. We acquire a ticket and run ldapsearch from another
machine using -Y GSSAPI bind and it works. Logs from slapd debug seem
ok.
But that evil app still fails. Here's a piece from slapd debug log:
conn=1000 op=1 do_bind
ber_scanf fmt ({imt) ber:
ber_dump: buf=0x7f73f6af8810 ptr=0x7f73f6af8813 end=0x7f73f6af8856 len=67
0000: 60 84 00 00 00 3d 02 01 03 04 00 a3 84 00 00 00 `....=..........
0010: 32 04 06 47 53 53 41 50 49 04 28 4e 54 4c 4d 53 2..GSSAPI.(NTLMS
0020: 53 50 00 01 00 00 00 97 82 08 e2 00 00 00 00 00 SP..............
0030: 00 00 00 00 00 00 00 00 00 00 00 06 01 b1 1d 00 ................
0040: 00 00 0f ...
ber_scanf fmt ({m) ber:
ber_dump: buf=0x7f73f6af8810 ptr=0x7f73f6af881e end=0x7f73f6af8856 len=56
0000: 00 84 00 00 00 32 04 06 47 53 53 41 50 49 04 28 .....2..GSSAPI.(
0010: 4e 54 4c 4d 53 53 50 00 01 00 00 00 97 82 08 e2 NTLMSSP.........
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0030: 06 01 b1 1d 00 00 00 0f ........
ber_scanf fmt (m) ber:
ber_dump: buf=0x7f73f6af8810 ptr=0x7f73f6af882c end=0x7f73f6af8856 len=42
0000: 00 28 4e 54 4c 4d 53 53 50 00 01 00 00 00 97 82 .(NTLMSSP.......
0010: 08 e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020: 00 00 06 01 b1 1d 00 00 00 0f ..........
ber_scanf fmt (}}) ber:
ber_dump: buf=0x7f73f6af8810 ptr=0x7f73f6af8856 end=0x7f73f6af8856 len=0
>>> dnPrettyNormal: <>
<<< dnPrettyNormal: <>, <>
conn=1000 op=1 BIND dn="" method=163
do_bind: dn () SASL mech GSSAPI
==> sasl_bind: dn="" mech=GSSAPI datalen=40
SASL [conn=1000] Failure: GSSAPI Error: An unsupported mechanism was
requested (Unknown error)
send_ldap_result: conn=1000 op=1 p=3
send_ldap_result: err=49 matched="" text="SASL(-13): authentication
failure: GSSAPI Failure: gss_accept_sec_context"
send_ldap_response: msgid=11 tag=97 err=49
ber_flush2: 87 bytes to sd 13
0000: 30 55 02 01 0b 61 50 0a 01 31 04 00 04 49 53 41 0U...aP..1...ISA
0010: 53 4c 28 2d 31 33 29 3a 20 61 75 74 68 65 6e 74 SL(-13): authent
0020: 69 63 61 74 69 6f 6e 20 66 61 69 6c 75 72 65 3a ication failure:
0030: 20 47 53 53 41 50 49 20 46 61 69 6c 75 72 65 3a GSSAPI Failure:
0040: 20 67 73 73 5f 61 63 63 65 70 74 5f 73 65 63 5f gss_accept_sec_
0050: 63 6f 6e 74 65 78 74 context
ldap_write: want=87, written=87
0000: 30 55 02 01 0b 61 50 0a 01 31 04 00 04 49 53 41 0U...aP..1...ISA
0010: 53 4c 28 2d 31 33 29 3a 20 61 75 74 68 65 6e 74 SL(-13): authent
0020: 69 63 61 74 69 6f 6e 20 66 61 69 6c 75 72 65 3a ication failure:
0030: 20 47 53 53 41 50 49 20 46 61 69 6c 75 72 65 3a GSSAPI Failure:
0040: 20 67 73 73 5f 61 63 63 65 70 74 5f 73 65 63 5f gss_accept_sec_
0050: 63 6f 6e 74 65 78 74 context
conn=1000 op=1 RESULT tag=97 err=49 text=SASL(-13): authentication
failure: GSSAPI Failure: gss_accept_sec_context
(btw, this is slapd 2.4.21, from a 10.04 ubuntu package)
I believe the application uses Windows SSPI, and I known SSPI supports
several GSSAPI mechanisms, including NTLMSSP and Kerberos. I'm afraid
Windows is auto selecting NTLMSSP cause its running on a pre-windows
2000 domain (non AD, in this case, Samba). Hoping to make windows use
Kerberos instead, I've also tried publishing some SRV records on DNS.
I have sniffed DNS queries from the workstation while the app tries to
login, caught only one _ldap._tcp SRV request, registered that ... and
nothing has changed.
I don't know how could I force the app to use GSSAPI + kerberos
without touching its source code. And I can't find much about a unix
NTLM(SSP)-as-a-mechanism-of-GSSAPI implementation. Maybe there's
something inside samba4 or in Likewise software, but I haven't found
it yet.
So ... does somebody have any advice or info?
Thanks in advance,
Diego Morales
+55 (51) 3024-3568
Propus Informática LTDA.
http://www.propus.com.br
12 years, 2 months
OPENLDAP SYNCREPL
by Borresen, John - 0442 - MITLL
All,
I've read and re-read (not to mentioned googled) configuring SyncRepl in
OpenLDAP dynamic configuration (cn=config)--v2.4.23. Missing something
somewhere. Current logging is set to "256" on both Provider and Consumer.
On my Master/Provider LDAP server seeing the following:
slapd shutdown: waiting for 0 operations/tasks to finish
slapd shutdown: initiated
bdb_modify: dc=group42,dc=ldap
bdb_dn2entry("dc=group42,dc=ldap")
bdb_modify_internal: 0x00000001: dc=group42,dc=ldap
bdb_modify_internal: replace contextCSN
=> entry_encode(0x00000001): dc=group42,dc=ldap
<= entry_encode(0x00000001): dc=group42,dc=ldap
bdb_modify: updated id=00000001 dn="dc=group42,dc=ldap"
send_ldap_result: conn=-1 op=0 p=0
send_ldap_result: err=0 matched="" text=""
====> bdb_cache_release_all
====> bdb_cache_release_all
slapd destroy: freeing system resources.
On my Consumer/Slave Server I am seeing the following:
slapd destroy: freeing system resources.
syncinfo_free: rid=001
slapd stopped.
tail: /var/log/slapd: file truncated
do_syncrep2: rid=001 got search entry without Sync State control
do_syncrepl: rid=001 rc -1 retrying
do_syncrep2: rid=001 got search entry without Sync State control
do_syncrepl: rid=001 rc -1 retrying
do_syncrep2: rid=001 got search entry without Sync State control
do_syncrepl: rid=001 rc -1 retrying
do_syncrep2: rid=001 got search entry without Sync State control
do_syncrepl: rid=001 rc -1 retrying
do_syncrep2: rid=001 got search entry without Sync State control
do_syncrepl: rid=001 rc -1 retrying
do_syncrep2: rid=001 got search entry without Sync State control
do_syncrepl: rid=001 rc -1 retrying
do_syncrep2: rid=001 got search entry without Sync State control
do_syncrepl: rid=001 rc -1 retrying
do_syncrep2: rid=001 got search entry without Sync State control
do_syncrepl: rid=001 rc -1 retrying
do_syncrep2: rid=001 got search entry without Sync State control
do_syncrepl: rid=001 rc -1 retrying
do_syncrep2: rid=001 got search entry without Sync State control
do_syncrepl: rid=001 rc -1 retrying
>From my readings, I understand that the "Sync State Control" error normally
indicates that my provider is not set up correctly. As far as I can tell,
my modules are correctly loaded and the overlays are loaded to the
appropriate database (my case, bdb) to be replicated.
The following is from the Provider/Master LDAP Server:
My olcDatabase-{1}bdb.ldif (truncated):
# more olcDatabase={1}bdb.ldif
dn: olcDatabase={1}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcSuffix: dc=group42,dc=ldap
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=ldapadmin,dc=group42,dc=ldap
olcRootPW:: *******
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
olcDbDirectory: /var/lib/ldap_db/openldap-data
olcDbCacheSize: 1000
...
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass eq
olcDbIndex: sn eq,sub
olcDbIndex: mail eq,sub
olcDbIndex: departmentNumber eq
olcDbIndex: cn,uid eq,sub
olcDbIndex: uidNumber eq
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcDbIndex: ipHostNumber eq
olcDbIndex: gidNumber,memberUID eq
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: 101e6d86-dd1c-4eaa-a26e-d7e201a727f8
creatorsName: cn=config
createTimestamp: 20111219143532Z
olcDbSearchStack: 32
olcAccess: {0} to attrs=userPassword,shadowLastChange by self write by
anonymo
us auth by * none
olcAccess: {1} to * by * read
olcDatabase: {1}bdb
entryCSN: 20120313143637.046410Z#000000#001#000000
modifiersName: cn=config
modifyTimestamp: 20120313143637Z
# ll olcDatabase={1}bdb
total 16
-rw------- 1 ldap ldap 453 Mar 12 10:50 olcOverlay={0}syncprov.ldif
-rw------- 1 ldap ldap 505 Feb 29 11:16 olcOverlay={1}accesslog.ldif
The olcOverlay={0}syncrpov.ldif
# more olcDatabase={1}bdb/olcOverlay={0}syncprov.ldif
dn: olcOverlay={0}syncprov
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpNoPresent: TRUE
structuralObjectClass: olcSyncProvConfig
entryUUID: 8572b589-f594-44a6-91fe-0de741afbcca
creatorsName: cn=admin,cn=config
createTimestamp: 20120224171809Z
olcSpReloadHint: TRUE
olcSpCheckpoint: 1000 60
entryCSN: 20120312145000.123929Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20120312145000Z
The olcOverlay={1}accesslog.ldif:
# more olcDatabase={1}bdb/olcOverlay={1}accesslog.ldif
dn: olcOverlay={1}accesslog
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: {1}accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogPurge: 07+00:00 01+00:00
olcAccessLogSuccess: TRUE
structuralObjectClass: olcAccessLogConfig
entryUUID: eea1e438-6385-4660-807b-bb270eb4843a
creatorsName: cn=admin,cn=config
createTimestamp: 20120229161649Z
entryCSN: 20120229161649.880441Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20120229161649Z
***The following is on the Consumer/Slave Server***
The olcDatabase={2}bdb.ldif (truncated):
# more olcDatabase={2}bdb.ldif
dn: olcDatabase={2}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcSuffix: dc=group42,dc=ldap
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=ldapadmin,dc=group42,dc=ldap
olcRootPW:: *********
olcMonitoring: TRUE
olcDbDirectory: /var/lib/ldap_db/openldap-data
olcDbCacheSize: 1000
...
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass eq
olcDbIndex: cn,uid eq,sub
olcDbIndex: sn eq,sub
olcDbIndex: mail eq,sub
olcDbIndex: departmentNumber eq
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcAccess: {0} to attrs=userPassword,shadowLastChange by self write by
anonymo
us auth by * none
olcAccess: {1} to * by * read
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: e6971058-e0f0-4160-aaca-a18b24d22008
creatorsName: cn=config
createTimestamp: 20120229205835Z
olcDatabase: {2}bdb
olcUpdateRef: ldaps://gp42-admin2.group42.ldap:636
olcMirrorMode: TRUE
olcSyncrepl: {0}rid=1 provider=ldaps://gp42-admin2.group42.ldap:636
bindmethod
=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=******* interva
l=01:00:00:00 searchbase="dc=group42,dc=ldap" logbase="cn=accesslog"
schemach
ecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)"
attrs=
"*,+" syncdata=accesslog starttls=no
tls_cacertdir=/usr/local/openldap-2.4.23
/etc/openldap/cacerts
entryCSN: 20120313150609.224840Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20120313150609Z
Not sure what I am missing, nor where I am missing it. Any assistance would
be helpful.
Dave Borresen
Solaris/Linux Systems Administrator
Surveillance Systems Group
MIT Lincoln Laboratory
244 Wood Street
Lexington, MA 02420
P: 781-981-2954
F: 781-981-5344
john.borresen(a)ll.mit.edu
12 years, 8 months
RE: Re: OpenLDAP 2.3.4 TLS negotiation failure
by Chris Jacobs
Inline...
> -----Original Message-----
> From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-
> technical-bounces(a)OpenLDAP.org] On Behalf Of Tian Zhiying
> Sent: Wednesday, October 23, 2013 2:59 AM
> To: DieterKlünter; openldap-technical
> Subject: Re: Re: OpenLDAP 2.3.4 TLS negotiation failure
>
> Hi Dieter：
>
> Thanks for your quick reply.
> I have changed 'TLS_REQCERT try' and check the commonName of the host
> certificate, the common name is LDAP Server hostname "auth.server.com",
> the following is the query results:
> [root@auth cacerts]# openssl s_client -connect localhost:636 -showcerts -
> state -CAfile /etc/openldap/cacerts/cacert.pem
> CONNECTED(00000003)
> SSL_connect:before/connect initialization
> SSL_connect:SSLv2/v3 write client hello A
> SSL_connect:SSLv3 read server hello A
> depth=0 /C=CN/ST=BJ/L=BJ/O=TS/OU=IT/CN=auth.server.com/emailAddres
> s=tianzy(a)server.com
> verify error:num=18:self signed certificate
> verify return:1
Here is your problem. The host does not trust the SSL cert.
The 'CAfile' you've pointed the openssl command (and the real clients guessing by the path) isn't the CA chain for that SSL cert.
We also use an internal CA that our hosts don't trust globally. Same command and output for me:
[root(a)ldapmaster1.[snip] ~]# echo | openssl s_client -connect ldapmaster1.[snip]:636 -showcerts -state -CAfile /etc/openldap/cacerts/cacert.pem
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=2 C = US, O = [snip], OU = PKI, CN = [snip] Internal Root CA
verify return:1
depth=1 C = US, O = [snip], OU = PKI, CN = [snip] Internal Issuing CA 01
verify return:1
depth=0 C = US, ST = WA, L = Seattle, O = [snip], CN = ldap-vip. [snip], emailAddress = [snip]
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
The command then continues to dump the cert, and the chain certs, as expected.
You must put the entire CA chain from the Root CA to the signing/subordinate CA that signed this SSL cert (if applicable) in x509/PEM format in your 'CAfile' - assuming the Root CA isn't trusted server wide already.
Then try again. Also, make sure to use the name specified in your SSL cert when connecting/testing - mess with your local hosts file if needed.
- chris
> depth=0 /C=CN/ST=BJ/L=BJ/O=TS/OU=IT/CN=auth.server.com/emailAddres
> s=tianzy(a)server.com
> verify return:1
> SSL_connect:SSLv3 read server certificate A
> SSL_connect:SSLv3 read server certificate request A
> SSL_connect:SSLv3 read server done A
> SSL_connect:SSLv3 write client certificate A
> SSL_connect:SSLv3 write client key exchange A
> SSL_connect:SSLv3 write change cipher spec A
> SSL_connect:SSLv3 write finished A
> SSL_connect:SSLv3 flush data
> SSL_connect:SSLv3 read finished A
>
> Now, the /etc/openldap/ldap.conf file:
> URI ldap://ldap.server.com/
> BASE dc=server,dc=com
> TLS_CACERT /etc/openldap/cacerts/cacert.pem
> #SSL ON
> TLS_REQCERT try
>
> But, run "#ldapsearch -x -H ldap://ldap.server.com -ZZ" , I also get the
> following error:
> [root@client cacerts]# ldapsearch -x -H ldap://ldap.server.com -ZZ
> ldap_start_tls: Connect error (-11)
>
> ________________________________________
> Tian Zhiying
>
> From: DieterKlünter
> Date: 2013-10-23 17:35
> To: openldap-technical
> CC: tianzy1225
> Subject: Re: OpenLDAP 2.3.4 TLS negotiation failure
> Am Wed, 23 Oct 2013 16:47:25 +0800
> schrieb "Tian Zhiying" <tianzy1225(a)thundersoft.com>:
>
> > Hi
> >
> > On the LDAP Server , I run following command is ok:
> > #ldapsearch -x -H ldap://ldap.server.com -ZZ
> > #ldapsearch -x -H ldap://ldap.server.com
> >
> > But on my client , I run "#ldapsearch -x -H ldap://ldap.server.com",
> > is ok; Run "#ldapsearch -x -H ldap://ldap.server.com -ZZ" , I get the
> > following error: [root@client cacerts]# ldapsearch -x -H
> > ldap://ldap.server.com -ZZ ldap_start_tls: Connect error (-11)
> >
> > On LDAP Server log file, I get the following error messages:
> > Oct 23 16:41:25 auth slapd[4213]: conn=206 fd=24 ACCEPT from
> > IP=192.168.9.9:45648 (IP=0.0.0.0:389) Oct 23 16:41:25 auth
> > slapd[4213]: conn=206 op=0 STARTTLS Oct 23 16:41:25 auth slapd[4213]:
> > conn=206 op=0 RESULT oid= err=0 text= Oct 23 16:41:25 auth
> > slapd[4213]: conn=206 fd=24 closed (TLS negotiation failure)
> >
> > My client ldap configuration:
> > /etc/openldap/ldap.conf file:
> > URI ldap://ldap.server.com/
> > BASE dc=server,dc=com
> > TLS_CACERT /etc/openldap/cacerts/ca.crt
> > SSL ON
> > TLS_REQCERT demand
>
> Set 'TLS_REQCERT try' and check the commonName of the host
> certificate.
> SSL ON is not an openldap configuration parameter.
> The /etc/ldap.conf file is not a openldap client configuration file,
> but of nss_ldap.
>
> > /etc/ldap.conf file:
> > BASE dc=server,dc=com
> > URI ldap://ldap.server.com
> > SSL ON
> > TLS_CACERT /etc/openldap/cacert/ca.crt
> > TLS_REQCERT demand
> >
> > Any suggestion what cause TLS negotiation failure?
>
> -Dieter
>
> --
> Dieter Klünter | Systemberatung
> http://dkluenter.de
> GPG Key ID:DA147B05
> 53°37'09,95"N
> 10°08'02,42"E
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
11 years
Re: Ldap simple bind problems on slaves during network outage (chaining)
by Christian Kratzer
Hi,
On Tue, 3 Dec 2013, Christian Kratzer wrote:
> Hi,
>
> we are currently chasing a strange issue at a customers site where the ldap
> slaves become unresponsive when network connectivity to master ldaps and dns
> servers is lost.
>
> They have a setup of two masters and two slaves at separate sites. There is
> a load balancer sitting in front of the slaves that performs regular health
> checks consisting of binds followed by a search of their binddn.
It seems that this is due to ldap chaining from slave to master running without a timeout and eventually blocking all of slapd.
We use referrals and chaining for slapo-ppolicy and slapo-lastbind (with replication patch from ITS#7721).
I tried to resolve this using olcDbKeepalive and olcDbKeepalive but have not been sucessfull yet.
This is how the chaining backend is configured on the slaves in our lab:
olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {1}ldap
olcDbURI: "ldap://ldaptest0.example.org"
olcDbStartTLS: start starttls=no tls_cert="/usr/local/etc/openldap/certs/server.cert" tls_key="/usr/local/etc/openldap/certs/server.key" tls_cacert="/usr/local/etc/openldap/certs/ca.cert" tls_reqcert=demand tls_crlcheck=none
olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindmethod=simple binddn="cn=chain,ou=system,dc=de,dc=telefonica,dc=com" credentials="XXXXXXXXXXX" keepalive=60:6:10 tls_cert="/usr/local/etc/openldap/certs/server.cert" tls_key="/usr/local/etc/openldap/certs/server.key" tls_cacert="/usr/local/etc/openldap/certs/ca.cert" tls_reqcert=demand tls_crlcheck=none
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: FALSE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 60:6:10
olcDbNetworkTimeout: 3
Any pointers on what we should change to allow quick detection of unreachable olcDbURI ?
Greetings
Christian
> During regular operations the load balancers health checks look as follows
> [1]
>
> Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 fd=36 ACCEPT from
> IP=192.0.2.189:33852 (IP=192.0.2.129:389)
> Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=0 BIND
> dn="cn=keepalive-check-lb,ou=system,dc=example,dc=org" method=128
> Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=0 BIND
> dn="cn=keepalive-check-lb,ou=system,dc=example,dc=org" mech=SIMPLE ssf=0
> Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=0 RESULT tag=97 err=0
> text=
> Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=1 SRCH
> base="ou=system,dc=example,dc=org" scope=1 deref=0
> filter="(cn=keepalive-check-lb)"
> Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=1 ENTRY
> dn="cn=keepalive-check-lb,ou=system,dc=example,dc=org"
> Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=1 SEARCH RESULT tag=101
> err=0 nentries=1 text=
> Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=2 UNBIND
> Dec 2 14:38:05 ldap slapd[57585]: connection_closing: readying
> conn=3924716 sd=36 for close
> Dec 2 14:38:05 ldap slapd[57585]: connection_resched: attempting closing
> conn=3924716 sd=36
> Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 fd=36 closed
>
>
> When they experience a network outage separating the slaves from the masters
> and the dns servers the load balancers are not able to bind the slaves:
>
> Dec 2 14:38:50 ldap slapd[57585]: conn=3924725 fd=44 ACCEPT from
> IP=192.0.2.188:35761 (IP=192.0.2.129:389)
> Dec 2 14:38:50 ldap slapd[57585]: connection_closing: readying
> conn=3924725 sd=44 for close
> Dec 2 14:38:50 ldap slapd[57585]: connection_close: deferring conn=3924725
> sd=44
> Dec 2 14:38:50 ldap slapd[57585]: conn=3924725 op=0 BIND
> dn="cn=keepalive-check-lb,ou=system,dc=example,dc=org" method=128
> Dec 2 14:38:50 ldap slapd[57585]: conn=3924725 op=0 BIND
> dn="cn=keepalive-check-lb,ou=system,dc=example,dc=org" mech=SIMPLE ssf=0
> Dec 2 14:38:50 ldap slapd[57585]: connection_resched: attempting closing
> conn=3924725 sd=44
> Dec 2 14:38:50 ldap slapd[57585]: conn=3924725 fd=44 closed (connection
> lost)
>
> We have not been able to reproduce this problem in a lab setup which is
> supposed to be identical to the production setup. It does not seem to be
> related to the servers not being able to perform reverse mapping on the
> client ips. We run a mixture of 2.4.35 and 2.4.38 on CentOS 6.4. In the lab
> the slaves are able to perform queries just fine without connectivity to the
> masters or to their dns servers.
>
> The servers are currently running with following loglevel:
>
> dn: cn=config
> olcLogLevel: Conns
> olcLogLevel: Stats
> olcLogLevel: Stats2
> olcLogLevel: Sync
>
> It seems we only get to the point where the bind credentials are parsed after
> which the connection is closed.
>
> This could of course be a problem with the load balancer prematurely closing
> the connection.
>
> I am trying to eliminate any causes in the ldap servers.
>
> Any ideas on how to debug this or where we could look.
>
> Greetings
> Christian
>
> [1] dns and ips obfuscated to protect the customer
>
>
--
Christian Kratzer CK Software GmbH
Email: ck(a)cksoft.de Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer
10 years, 11 months
Problem with SSL/TLS on CentOS 7 after upgrading to 2.4.59
by Nick Milas
Hello,
Our main OpenLDAP Server (running on CentOS 7) has been working fine
with 2.4.58.
Since yesterday, after a (minor, see at the end) OS upgrade which
included an update to LTB Openldap 2.4.59, SSL clients see:
# ldapwhoami -H ldaps://ldap.noa.gr:636 -x
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
In the log I see, for example:
Oct 21 17:10:58 ldap slapd[18532]: conn=1170 fd=18 ACCEPT from
IP=195.251.xxx.xxx:44016 (IP=0.0.0.0:389)
Oct 21 17:10:58 ldap slapd[18532]: conn=1170 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Oct 21 17:10:58 ldap slapd[18532]: conn=1170 op=0 STARTTLS
Oct 21 17:10:58 ldap slapd[18532]: conn=1170 op=0 RESULT oid= err=0 text=
Oct 21 17:10:58 ldap slapd[18532]: conn=1170 fd=18 closed (TLS
negotiation failure)
...
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 fd=18 ACCEPT from
IP=[2001:648:2011:xxxx::xxxx]:52018 (IP=[::]:636)
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 fd=18 TLS established
tls_ssf=256 ssf=256
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=0 BIND
dn="uid=full,ou=sys,dc=noa,dc=gr" method=128
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=0 BIND
dn="uid=Full,ou=sys,dc=noa,dc=gr" mech=SIMPLE ssf=0
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=0 RESULT tag=97 err=0 text=
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 SRCH
base="dc=noa,dc=gr" scope=2 deref=0 filter="(objectClass=*)"
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 SRCH attr=* +
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_op_search:
got a persistent search with a
cookie=rid=601,csn=20200910151806.461875Z#000000#000#000000
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_findbase:
searching
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_op_search:
registered persistent search
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_findcsn:
mode=FIND_CSN csn=20200910151806.461875Z#000000#000#000000
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_findcsn:
csn==20200910151806.461875Z#000000#000#000000 not found
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_findcsn:
csn<=20200910151806.461875Z#000000#000#000000 found
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_findcsn:
mode=FIND_PRESENT csn=
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_sendinfo:
present syncIdSet cookie=
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 INTERM
oid=1.3.6.1.4.1.4203.1.9.1.4
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_sendinfo:
present syncIdSet cookie=
...
Oct 21 17:11:34 ldap slapd[18532]: send_search_entry: conn 1172 ber
write failed.
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 fd=18 closed (connection
lost on write)
Oct 21 17:11:34 ldap slapd[18532]: connection_read(18): no connection!
Oct 21 17:11:34 ldap slapd[18532]: connection_read(18): no connection!
Oct 21 17:11:34 ldap slapd[18532]: connection_read(18): no connection!
Oct 21 17:11:34 ldap slapd[18532]: connection_read(18): no connection!
<many more entries like this>
...
Oct 21 17:11:34 ldap slapd[18532]: conn=1173 fd=18 ACCEPT from
IP=[2001:648:2011:xxxx::xxxx]:33466 (IP=[::]:636)
Oct 21 17:11:34 ldap slapd[18532]: conn=1173 fd=18 closed (TLS
negotiation failure)
Is there some settings change in 2.4.59 or something is getting wrong?
My settings:
olcTLSCertificateKeyFile: /usr/local/openldap/etc/openldap/certs/priv.crt
olcTLSCipherSuite: HIGH:MEDIUM:+SSLv2
olcTLSCRLCheck: none
olcTLSVerifyClient: never
olcTLSCertificateFile: /usr/local/openldap/etc/openldap/certs/cert.crt
olcTLSCACertificateFile: /usr/local/openldap/etc/openldap/certs/GeantCA.crt
I also tried:
olcTLSCipherSuite: ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
without success.
Interestingly, I can see random successes like:
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 fd=19 ACCEPT from
IP=[2001:648:2011:xxxx::xxxx]:47206 (IP=[::]:636)
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 fd=19 TLS established
tls_ssf=256 ssf=256
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=0 BIND
dn="uid=auth,ou=sys,dc=noa,dc=gr" method=128
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=0 BIND
dn="uid=auth,ou=sys,dc=noa,dc=gr" mech=SIMPLE ssf=0
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=0 RESULT tag=97 err=0 text=
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=1 SRCH
base="ou=people,dc=noa,dc=gr" scope=2 deref=0
filter="(&(&(objectClass=inetOrgPerson)(!(schacUserStatus=internal)))(|(mail=jackie(a)noa.g
r)))"
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=1 SRCH attr=cn sn
givenname title mail telephonenumber o ou;lang-en-us objectClass
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=1 ENTRY
dn="uid=jackie,ou=people,dc=noa,dc=gr"
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=1 SEARCH RESULT tag=101
err=0 nentries=1 text=
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=2 UNBIND
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 fd=19 close
...
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 fd=19 ACCEPT from
IP=[2001:648:2011:xxxx::xxxx]:35456 (IP=[::]:389)
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=0 STARTTLS
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=0 RESULT oid= err=0 text=
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 fd=19 TLS established
tls_ssf=256 ssf=256
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=1 BIND
dn="uid=auth,ou=sys,dc=noa,dc=gr" method=128
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=1 BIND
dn="uid=auth,ou=sys,dc=noa,dc=gr" mech=SIMPLE ssf=0
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=1 RESULT tag=97 err=0 text=
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=2 SRCH
base="ou=people,dc=noa,dc=gr" scope=2 deref=0 filter="(uid=gate)"
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=2 SRCH attr=uid
uidNumber gidNumber homeDirectory loginShell
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=2 ENTRY
dn="uid=gate,ou=webad,ou=people,dc=noa,dc=gr"
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=2 SEARCH RESULT tag=101
err=0 nentries=1 text=
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=3 UNBIND
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 fd=19 closed
then failures start again, esp. when SYNCRPOV sessions take place (we
have 4 SYNCRPOV consumers).
Latest updates (from /var/log/yum.log):
Oct 20 21:54:24 Updated: 1:grub2-common-2.02-0.87.el7.centos.7.noarch
Oct 20 21:54:24 Updated: 32:bind-license-9.11.4-26.P2.el7_9.7.noarch
Oct 20 21:54:24 Updated: 1:grub2-pc-modules-2.02-0.87.el7.centos.7.noarch
Oct 20 21:54:25 Updated: libX11-common-1.6.7-4.el7_9.noarch
Oct 20 21:54:26 Updated: kernel-headers-3.10.0-1160.45.1.el7.x86_64
Oct 20 21:54:28 Updated: ca-certificates-2021.2.50-72.el7_9.noarch
Oct 20 21:54:29 Updated: tzdata-2021c-1.el7.noarch
Oct 20 21:54:30 Updated: nss-softokn-freebl-3.67.0-3.el7_9.x86_64
Oct 20 21:54:36 Updated: glibc-common-2.17-325.el7_9.x86_64
Oct 20 21:54:38 Updated: glibc-2.17-325.el7_9.x86_64
Oct 20 21:54:39 Updated: nspr-4.32.0-1.el7_9.x86_64
Oct 20 21:54:39 Updated: nss-util-3.67.0-1.el7_9.x86_64
Oct 20 21:54:40 Updated: 1:openssl-libs-1.0.2k-22.el7_9.x86_64
Oct 20 21:54:41 Updated: 1:grub2-tools-minimal-2.02-0.87.el7.centos.7.x86_64
Oct 20 21:54:41 Updated: libX11-1.6.7-4.el7_9.x86_64
Oct 20 21:54:41 Updated: gd-last-2.3.3-2.el7.remi.x86_64
Oct 20 21:54:43 Updated: 32:bind-libs-lite-9.11.4-26.P2.el7_9.7.x86_64
Oct 20 21:54:43 Updated: nss-softokn-3.67.0-3.el7_9.x86_64
Oct 20 21:54:44 Updated: nss-sysinit-3.67.0-3.el7_9.x86_64
Oct 20 21:54:44 Updated: nss-3.67.0-3.el7_9.x86_64
Oct 20 21:54:45 Updated: rpm-4.11.3-46.el7_9.x86_64
Oct 20 21:54:45 Updated: rpm-libs-4.11.3-46.el7_9.x86_64
Oct 20 21:54:46 Updated: 1:grub2-tools-2.02-0.87.el7.centos.7.x86_64
Oct 20 21:54:47 Updated: 1:grub2-tools-extra-2.02-0.87.el7.centos.7.x86_64
Oct 20 21:54:47 Updated: 1:grub2-pc-2.02-0.87.el7.centos.7.x86_64
Oct 20 21:54:47 Updated: rpm-build-libs-4.11.3-46.el7_9.x86_64
Oct 20 21:54:47 Updated: nss-tools-3.67.0-3.el7_9.x86_64
Oct 20 21:54:48 Updated: openldap-2.4.44-24.el7_9.x86_64
Oct 20 21:54:48 Updated: 12:dhcp-libs-4.2.5-83.el7.centos.1.x86_64
Oct 20 21:54:48 Updated: 12:dhcp-common-4.2.5-83.el7.centos.1.x86_64
Oct 20 21:54:49 Updated: 32:bind-libs-9.11.4-26.P2.el7_9.7.x86_64
Oct 20 21:54:50 Updated: 32:bind-export-libs-9.11.4-26.P2.el7_9.7.x86_64
Oct 20 21:54:50 Updated: httpd-tools-2.4.6-97.el7.centos.1.x86_64
Oct 20 21:54:52 Updated: httpd-2.4.6-97.el7.centos.1.x86_64
Oct 20 21:54:54 Updated: 1:openssl-devel-1.0.2k-22.el7_9.x86_64
Oct 20 21:54:56 Updated: 1:openssl-1.0.2k-22.el7_9.x86_64
Oct 20 21:54:56 Updated: oniguruma5php-6.9.7.1-1.el7.remi.x86_64
Oct 20 21:54:56 Updated: gssproxy-0.7.0-30.el7_9.x86_64
Oct 20 21:54:57 Installed: libzstd-1.5.0-1.el7.x86_64
Oct 20 21:54:57 Updated: libzip5-1.8.0-2.el7.remi.x86_64
Oct 20 21:55:00 Updated: kernel-tools-libs-3.10.0-1160.45.1.el7.x86_64
Oct 20 21:55:01 Updated: glibc-headers-2.17-325.el7_9.x86_64
Oct 20 21:55:05 Installed: libicu69-69.1-2.el7.remi.x86_64
Oct 20 21:55:07 Updated: epel-release-7-14.noarch
Oct 20 21:55:08 Updated: remi-release-7.9-2.el7.remi.noarch
Oct 20 21:55:10 Updated: glibc-devel-2.17-325.el7_9.x86_64
Oct 20 21:55:12 Updated: kernel-tools-3.10.0-1160.45.1.el7.x86_64
Oct 20 21:55:25 Updated: 1:nfs-utils-1.3.0-0.68.el7.2.x86_64
Oct 20 21:55:26 Updated: 1:mod_ssl-2.4.6-97.el7.centos.1.x86_64
Oct 20 21:55:30 Updated: 12:dhclient-4.2.5-83.el7.centos.1.x86_64
Oct 20 21:55:33 Updated: 32:bind-utils-9.11.4-26.P2.el7_9.7.x86_64
Oct 20 21:55:36 Updated: openldap-ltb-2.4.59-1.el7.x86_64
Oct 20 21:55:37 Updated: sudo-1.8.23-10.el7_9.2.x86_64
Oct 20 21:55:38 Updated: rpm-python-4.11.3-46.el7_9.x86_64
Oct 20 21:55:39 Updated: 1:grub2-2.02-0.87.el7.centos.7.x86_64
Oct 20 21:55:40 Updated: rsyslog-8.24.0-57.el7_9.1.x86_64
Oct 20 21:55:40 Updated: kpartx-0.4.9-135.el7_9.x86_64
Oct 20 21:56:00 Updated: 2:microcode_ctl-2.1-73.11.el7_9.x86_64
Oct 20 21:56:01 Updated: kexec-tools-2.0.15-51.el7_9.3.x86_64
Oct 20 21:56:01 Updated: unzip-6.0-22.el7_9.x86_64
Oct 20 21:56:02 Updated: virt-what-1.18-4.el7_9.1.x86_64
Oct 20 21:56:04 Updated: glib2-2.56.1-9.el7_9.x86_64
Oct 20 21:56:05 Updated: python-perf-3.10.0-1160.45.1.el7.x86_64
Oct 20 21:56:30 Installed: kernel-3.10.0-1160.45.1.el7.x86_64
Oct 20 21:56:32 Updated: openldap-ltb-debuginfo-2.4.59-1.el7.x86_64
Please advise.
Would you suggest an openldap downgrade to 2.4.58 and/or to
openssl-1.0.2k-21?
Any other ideas?
Nick
3 years
Re: Security between server and client nodes.
by Raffael Sahli
On 12/01/2011 02:42 PM, Jayavant Patil wrote:
> On Wed, 30 Nov 2011 14:18:00 +0100 Raffael Sahli
> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>> wrote:
> >On 11/30/2011 01:48 PM, Jayavant Patil wrote:
> >
> >
> > >>On 11/30/2011 08:01 AM, Jayavant Patil wrote:
> > >>
> > >>
> > >> On Tue, Nov 29, 2011 at 6:26 PM, Jayavant Patil
> > >> <jayavant.patil82(a)gmail.com <mailto:jayavant.patil82@gmail.com>
> <mailto:jayavant.patil82@gmail.com <mailto:jayavant.patil82@gmail.com>>
> > <mailto:jayavant.patil82@gmail.com <mailto:jayavant.patil82@gmail.com>
> > <mailto:jayavant.patil82@gmail.com
> <mailto:jayavant.patil82@gmail.com>>>> wrote:
> > >>
> > >>
> > >> >>Mon, 28 Nov 2011 11:25:16 +0100 Raffael Sahli
> > >> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>
> <mailto:public@raffaelsahli.com <mailto:public@raffaelsahli.com>>
> > <mailto:public@raffaelsahli.com <mailto:public@raffaelsahli.com>
> <mailto:public@raffaelsahli.com <mailto:public@raffaelsahli.com>>>> wrote:
> > >> >>Hi
> > >>
> > >> >>I think you mean SSL connection or the STARTTLS Layer...?
> > >> >>Please read the manual http://www.openldap.org/doc/admin24/tls.html
> > >> >Ok.
> > >>
> > >> >>And tree security:
> > >> >>On my server, a client user can only see his own object:
> > >> >Are you using simple authentication mechanism?
> > >>
> > >> >>Maybe create a rule like this:
> > >> >>access to filter=(objectClass=
> > >> >>simpleSecurityObject)
> > >> >> by self read
> > >> >> by * none
> > >>
> > >> >I am not getting what the ACL rule specifies. Any suggestions?
> > >>
> > >>
> > >> I have two users ldap_6 and ldap_7. I want to restrict a user to
> > >> see his own data only.
> > >> In slapd.conf, I specified the rule as follows:
> > >> access to *
> > >> by self write
> > >> by * none
> > >>
> > >> But ldap_6 can see the ldap_7 user entries (or vice versa) with
> > >> $ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
> > >> "ou=People,dc=abc,dc=com" "uid=ldap_7"
> > >>
> > >> Any suggestions?
> > >>
> > >On Wed, 30 Nov 2011 08:38:32 +0100 Raffael Sahli
> > <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>
> <mailto:public@raffaelsahli.com <mailto:public@raffaelsahli.com>>> wrote:
> > >Yes, that's exactly the rule I wrote above.
> >
> > >access to filter=(objectClass=
> > >simpleSecurityObject)
> > > by self read
> > > by * none
> >
> >
> > >Maybe you have to change the objectClass to posixAccount, or both or
> > >whatever....
> >
> > >access to
> > >filter=(|(objectClass=
> simpleSecurityObject)(objectClass=posixAccount))
> > > by self read
> > > by * none
> >
> >
> > >Just add this rule before the global rule "access to *"
> >
> >
> > >>ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
> > >>"ou=People,dc=abc,dc=com" "uid=ldap_7"
> >
> > >And if you search like this with bind "admin dn", you will see every
> > >object....
> > >You have to bind with user ldap_6 and not with root
> > But anyway client user knows the admin dn and rootbindpassword. So,
> > with this he will look into all directory information to which he is
> > not supposed to do.
> > e.g. ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -w cluster
> >
> > So, how to avoid this?
> >
>
>
> >Why client user knows the admin dn and pw????????
>
> Because /etc/ldap.conf file on client contains admin dn and pw.
Why??? Thats not really secure...
You can write the password of the admin dn in a separate file with chmod
0400 (root ower)
Please read the man pages for that, its diffrent in every distr.
>
> Each user information in the directory contains the following
> entries(here, e.g. ldap_6)
>
>
> dn: uid=ldap_6,ou=People,dc=abc,dc=com
> uid: ldap_6
> cn: ldap_6
> sn: ldap_6
> mail: ldap_6(a)abc.com <mailto:ldap_6@abc.com>
> objectClass: person
> objectClass: organizationalPerson
> objectClass: inetOrgPerson
> objectClass: posixAccount
> objectClass: top
> objectClass: shadowAccount
> objectClass: hostObject
> objectClass: simpleSecurityObject
> shadowLastChange: 13998
> shadowMax: 99999
> shadowWarning: 7
> loginShell: /bin/bash
> uidNumber: 514
> gidNumber: 514
> homeDirectory: /home/ldap_6
> host: *
> userPassword:: e2NyeXB0fSQxJGRUb1p6bVp5JGY2VFF5UWMxNndSbjdLcHpnMUlsdS8=
>
>
> So, what should be the ACL rule so that each user can see his data
> only? I tried but not getting the required, even the user himself is
> unable to see his own data.
>
>
> --
>
> Thanks & Regards,
> Jayavant Ningoji Patil
> Engineer: System Software
> Computational Research Laboratories Ltd.
> Pune-411 004.
> Maharashtra, India.
> +91 9923536030.
>
--
Raffael Sahli
public(a)raffaelsahli.com
12 years, 11 months
OpenLDAP proxy to Active Directory
by Jonathan van der Wat
Greetings,
I'm new to OpenLDAP and am trying to implement the following:
User authentication (PAM + SSSD) on CentOS Linux servers via OpenLDAP
proxy to Active Directory. I am able to perform the following search
from the OpenLDAP proxy without any apparent issues:
*
[root@openldap ~]# ldapsearch -x -h /mydomaincontroller/ -LLL -b
dc=msad,dc=inet,dc=com -D cn=ldap,cn=users,dc=msad,dc=inet,dc=com -W
'(sAMAccountName=jonathanv)' cn sAMAccountName
Enter LDAP Password:
dn: CN=jonathan,CN=Users,DC=msad,DC=inet,DC=com
cn: jonathan
sAMAccountName: jonathanv
#
refldap://ForestDnsZones.msad.inet.com/DC=ForestDnsZones,DC=msad,DC=inet,DC…
#
refldap://DomainDnsZones.msad.inet.com/DC=DomainDnsZones,DC=msad,DC=inet,DC…
# refldap://msad.inet.com/CN=Configuration,DC=msad,DC=inet,DC=com*
However, when asking the OpenLDAP proxy:
*[root@openldap ~]# ldapsearch -x -h /localhost/ -LLL -b
dc=msad,dc=inet,dc=com -D cn=ldap,cn=users,dc=msad,dc=inet,dc=com -W
'(sAMAccountName=jonathanv)' cn sAMAccountName
Enter LDAP Password:
#
refldap://ForestDnsZones.msad.inet.com/DC=ForestDnsZones,DC=msad,DC=inet,DC…
#
refldap://DomainDnsZones.msad.inet.com/DC=DomainDnsZones,DC=msad,DC=inet,DC…
# refldap://msad.inet.com/CN=Configuration,DC=msad,DC=inet,DC=com*
Also, I've configured my CentOS server's using SSSD. When trying to
authenticate as user jonathanv, I receive a message that user jonathanv
is not found.
I am using OpenLDAP server version 2.4.23-20.
I am starting the OpenLDAP from the command line as follows:
*slapd -f -d 2 -f /etc/openldap/slapd.conf -g ldap -h ldap:/// -l LOCAL4
-u ldap -n slapd-ldap*
Here is the output of my slapd.conf file:
*#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/corba.schema
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/duaconf.schema
include /etc/openldap/schema/dyngroup.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/java.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/collective.schema
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules
# - modulepath is architecture dependent value (32/64-bit system)
# - back_sql.la overlay requires openldap-server-sql package
# - dyngroup.la and dynlist.la cannot be used at the same time
# modulepath /usr/lib/openldap
# modulepath /usr/lib64/openldap
# moduleload accesslog.la
# moduleload auditlog.la
# moduleload back_sql.la
# moduleload chain.la
# moduleload collect.la
# moduleload constraint.la
# moduleload dds.la
# moduleload deref.la
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload memberof.la
# moduleload pbind.la
# moduleload pcache.la
# moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
moduleload rwm.la
# moduleload seqmod.la
# moduleload smbk5pwd.la
# moduleload sssvlv.la
# moduleload syncprov.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la
# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by 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
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
# enable on-the-fly configuration (cn=config)
database config
access to *
by
dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
by * none
# enable server status monitoring (cn=monitor)
database monitor
access to *
by
dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read
by dn.exact="cn=Manager,dc=my-domain,dc=com" read
by * none
#######################################################################
# database definitions
#######################################################################
database bdb
suffix "dc=inet,dc=local"
checkpoint 1024 15
rootdn "cn=Manager,dc=inet,dc=local"
rootpw xxxxxxxxxxxxxxxx
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw secret
# rootpw {crypt}ijFYNcSNctBYg
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain for this database
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
# Our slapd-ldap back end to connect to AD
database ldap
suffix "dc=msad,dc=inet,dc=com"
#subordinate
rebind-as-user
uri "ldap://172.16.132.253/"
chase-referrals yes
overlay rwm
rwm-suffixmassage dc=msad,dc=inet,dc=com
rwm-map attribute uid sAMAccountName
rwm-map attribute cn cn
rwm-map attribute displayName displayName
rwm-map attribute givenName givenName
rwm-map attribute sn sn
rwm-map attribute mail mail
rwm-map attribute userPassword userPassword
rwm-map attribute *
rwm-map objectclass inetOrgPerson user
# 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
#*
Any ideas as to why I'm unable to authenticate my user against the AD?
Any advice or info on this topic would be greatly appreciated.
Greetings,
Jonathan
Disclaimer
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and automatically archived by Mimecast SA (Pty) Ltd, an innovator in Software as a Service (SaaS) for business. Mimecast Unified Email Management (UEM) offers email continuity, security, archiving and compliance with all current legislation. To find out more, visit http://www.mimecast.co.za/uem-ppc.
12 years, 5 months
Re: Security between server and client nodes.
by Jayavant Patil
On Thu, Dec 1, 2011 at 7:12 PM, Jayavant Patil
<jayavant.patil82(a)gmail.com>wrote:
> On Wed, 30 Nov 2011 14:18:00 +0100 Raffael Sahli <public(a)raffaelsahli.com>
> wrote:
> >On 11/30/2011 01:48 PM, Jayavant Patil wrote:
> >
> >
> > >>On 11/30/2011 08:01 AM, Jayavant Patil wrote:
> > >>
> > >>
> > >> On Tue, Nov 29, 2011 at 6:26 PM, Jayavant Patil
> > >> <jayavant.patil82(a)gmail.com <mailto:jayavant.patil82@gmail.com>
> > <mailto:jayavant.patil82@gmail.com
>
> > <mailto:jayavant.patil82@gmail.com>>> wrote:
> > >>
> > >>
> > >> >>Mon, 28 Nov 2011 11:25:16 +0100 Raffael Sahli
> > >> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>
> > <mailto:public@raffaelsahli.com <mailto:public@raffaelsahli.com>>>
> wrote:
> > >> >>Hi
> > >>
> > >> >>I think you mean SSL connection or the STARTTLS Layer...?
> > >> >>Please read the manual http://www.openldap.org/doc/admin24/tls.html
> > >> >Ok.
> > >>
> > >> >>And tree security:
> > >> >>On my server, a client user can only see his own object:
> > >> >Are you using simple authentication mechanism?
> > >>
> > >> >>Maybe create a rule like this:
> > >> >>access to filter=(objectClass=
> > >> >>simpleSecurityObject)
> > >> >> by self read
> > >> >> by * none
> > >>
> > >> >I am not getting what the ACL rule specifies. Any suggestions?
> > >>
> > >>
> > >> I have two users ldap_6 and ldap_7. I want to restrict a user to
> > >> see his own data only.
> > >> In slapd.conf, I specified the rule as follows:
> > >> access to *
> > >> by self write
> > >> by * none
> > >>
> > >> But ldap_6 can see the ldap_7 user entries (or vice versa) with
> > >> $ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
> > >> "ou=People,dc=abc,dc=com" "uid=ldap_7"
> > >>
> > >> Any suggestions?
> > >>
> > >On Wed, 30 Nov 2011 08:38:32 +0100 Raffael Sahli
> > <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>> wrote:
> > >Yes, that's exactly the rule I wrote above.
> >
> > >access to filter=(objectClass=
> > >simpleSecurityObject)
> > > by self read
> > > by * none
> >
> >
> > >Maybe you have to change the objectClass to posixAccount, or both or
> > >whatever....
> >
> > >access to
> > >filter=(|(objectClass=
> simpleSecurityObject)(objectClass=posixAccount))
> > > by self read
> > > by * none
> >
> >
> > >Just add this rule before the global rule "access to *"
> >
> >
> > >>ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
> > >>"ou=People,dc=abc,dc=com" "uid=ldap_7"
> >
> > >And if you search like this with bind "admin dn", you will see every
> > >object....
> > >You have to bind with user ldap_6 and not with root
> > But anyway client user knows the admin dn and rootbindpassword. So,
> > with this he will look into all directory information to which he is
> > not supposed to do.
> > e.g. ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -w cluster
> >
> > So, how to avoid this?
> >
>
>
> >>Why client user knows the admin dn and pw????????
>
> >Because /etc/ldap.conf file on client contains admin dn and pw.
>
> >Each user information in the directory contains the following
> entries(here, e.g. ldap_6)
>
>
> >dn: uid=ldap_6,ou=People,dc=abc,dc=com
> >uid: ldap_6
> >cn: ldap_6
> >sn: ldap_6
> >mail: ldap_6(a)abc.com
> >objectClass: person
> >objectClass: organizationalPerson
> >objectClass: inetOrgPerson
> >objectClass: posixAccount
> >objectClass: top
> >objectClass: shadowAccount
> >objectClass: hostObject
> >objectClass: simpleSecurityObject
> >shadowLastChange: 13998
> >shadowMax: 99999
> >shadowWarning: 7
> >loginShell: /bin/bash
> >uidNumber: 514
> >gidNumber: 514
> >homeDirectory: /home/ldap_6
> >host: *
> >userPassword:: e2NyeXB0fSQxJGRUb1p6bVp5JGY2VFF5UWMxNndSbjdLcHpnMUlsdS8=
>
>
> >So, what should be the ACL rule so that each user can see his data only?
> I tried but not getting the required, even the >user himself is unable to
> see his own data.
>
>
> --
>
> Thanks & Regards,
> Jayavant Ningoji Patil
> Engineer: System Software
> Computational Research Laboratories Ltd.
> Pune-411 004.
> Maharashtra, India.
> +91 9923536030.
>
>
The user itself is unable to see its own info.
[ldap_6@client]$ ldapsearch -x -v -b "dc=abc,dc=com" "(cn=ldap_6)" -h server
ldap_initialize( ldap://server )
filter: (cn=ldap_6)
requesting: All userApplication attributes
# extended LDIF
#
# LDAPv3
# base <dc=abc,dc=com> with scope subtree
# filter: (cn=ldap_6)
# requesting: ALL
#
# search result
search: 2
result: 32 No such object
# numResponses: 1
--
Thanks & Regards,
Jayavant Ningoji Patil
Engineer: System Software
Computational Research Laboratories Ltd.
Pune-411 004.
Maharashtra, India.
+91 9923536030.
12 years, 11 months
CSN Too Old potential Bug
by Burton, Kris - Acision
All,
I want to ask the list about this before I try to open an ITS to make sure that I am understanding everything correctly. We are running OpenLDAP 2.4.11. I selectively tried to back post ITS 5709 to our source, because we were losing replications. Applying this seemed to help and reduced the number of lost replications. We are running in mirror mode using refreshAndPersist, and doing a high volume of adds to the master, on the order of 100/s. We have run numerous iterations of the same test with very aggressive NTP updates that are keeping both the master and consumer within 50 microseconds of one another. Which I saw recommended as a possible solution in a previous message thread. This seemed to make little to no difference in the replication loss.
>From looking at the code I was thinking that the lost replications might be due to entries being queued on the master side in non-ascending order which I was seeing preceding the replication that would be rejected on the consumer side. What I thought was happening is that the logic that traverses the queue to mark committed CSNs and updates the contextCSN was getting out of sync because of this, and orphaning replications that were still pending, because they are too old, but in reality they have never been added to the consumer.
I just pulled the latest code from RE24 and reran the test, the latest code is better than before with just the back post of 5709 on 2.4.11, but we are still losing a small percentage of the replications with the "CSN too old" message. With the latest code I am still seeing a correlation between the out of sync queuing on the master and the replications that are rejected on the consumer.
During this run NTP was keeping the 2 systems within 10 microseconds of each other, with the most aggressive synch interval that is configurable at 16 seconds.
Below I have log snippets and some of the relevant configuration information. If more is desired then please let me know and I will provide it.
#### MASTER #####
Nov 14 14:43:05 ng04be03 slapd[7582]: slap_graduate_commit_csn: removing 0x2b4c9568b0 20081114194304.892065Z#000000#001#000000
Nov 14 14:43:05 ng04be03 slapd[7582]: slap_queue_csn: queing 0x42803100 20081114194305.078713Z#000000#001#000000
Nov 14 14:43:05 ng04be03 slapd[7582]: conn=14 op=17167 ADD dn="uniqueIdentifier=Evad_Added_tele_5450408582,ou=subscribers,ou=SINGP,o=ricuc…"
Nov 14 14:43:05 ng04be03 slapd[7582]: slap_queue_csn: queing 0x4680b100 20081114194305.078878Z#000000#001#000000
Nov 14 14:43:05 ng04be03 slapd[7582]: slap_queue_csn: queing 0x43004100 20081114194305.078653Z#000000#001#000000
Nov 14 14:43:05 ng04be03 slapd[7582]: conn=12 op=13844 RESULT tag=105 err=0 text=
Nov 14 14:43:05 ng04be03 slapd[7582]: slap_graduate_commit_csn: removing 0x2b4c87e670 20081114194305.068251Z#000000#001#000000
Nov 14 14:45:02 ng04be03 slapd[7582]: slap_queue_csn: queing 0x41000100 20081114194502.917316Z#000000#001#000000
Nov 14 14:45:02 ng04be03 slapd[7582]: conn=10 op=19719 ADD dn="uniqueIdentifier=Evad_Added_tele_5450009858,ou=subscribers,ou=SINGP,o=ricuc…"
Nov 14 14:45:02 ng04be03 slapd[7582]: slap_queue_csn: queing 0x43805100 20081114194502.917523Z#000000#001#000000
Nov 14 14:45:02 ng04be03 slapd[7582]: slap_queue_csn: queing 0x4780d100 20081114194502.917288Z#000000#001#000000
Nov 14 14:45:02 ng04be03 slapd[7582]: conn=12 op=17496 RESULT tag=105 err=0 text=
Nov 14 14:45:02 ng04be03 slapd[7582]: slap_graduate_commit_csn: removing 0x2b5a7f8340 20081114194502.917316Z#000000#001#000000
Nov 14 14:45:02 ng04be03 slapd[7582]: conn=13 op=19983 ADD dn="uniqueIdentifier=Evad_Added_tele_5450509990,ou=subscribers,ou=SINGP,o=ricuc…"
Nov 14 14:45:02 ng04be03 slapd[7582]: conn=10 op=19719 RESULT tag=105 err=0 text=
Nov 14 14:45:02 ng04be03 slapd[7582]: slap_graduate_commit_csn: removing 0x2b5ae77160 20081114194502.917523Z#000000#001#000000
Nov 14 14:45:02 ng04be03 slapd[7582]: conn=14 op=19598 ADD dn="umbillingnumber=5450409797,uniqueIdentifier=Evad_Added_tele_5450409797,ou=s…"
Nov 14 14:45:02 ng04be03 slapd[7582]: slap_queue_csn: queing 0x41000100 20081114194502.936884Z#000000#001#000000
Nov 14 14:45:02 ng04be03 slapd[7582]: conn=11 op=16763 RESULT tag=105 err=0 text=
Nov 14 14:45:02 ng04be03 slapd[7582]: slap_queue_csn: queing 0x43805100 20081114194502.947725Z#000000#001#000000
Nov 14 14:45:02 ng04be03 slapd[7582]: slap_graduate_commit_csn: removing 0x2b5ad51170 20081114194502.917288Z#000000#001#000000
### CONSUMER ###
Nov 14 14:43:36 ng04be04 slapd[24622]: syncrepl_entry: rid=002 be_add (0)
Nov 14 14:43:36 ng04be04 slapd[24622]: do_syncrep2: cookie=rid=002,sid=002,csn=20081114194305.078653Z#000000#001#000000
Nov 14 14:43:36 ng04be04 slapd[24622]: do_syncrep2: rid=002 CSN too old, ignoring 20081114194305.078653Z#000000#001#000000
Nov 14 14:43:36 ng04be04 slapd[24622]: do_syncrep2: cookie=rid=002,sid=002
Nov 14 14:43:36 ng04be04 slapd[24622]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Nov 14 14:43:36 ng04be04 slapd[24622]: syncrepl_entry: rid=002 be_search (0)
Nov 14 14:45:39 ng04be04 slapd[24622]: slap_queue_csn: queing 0x2b4737c990 20081114194502.917523Z#000000#001#000000
Nov 14 14:45:39 ng04be04 slapd[24622]: slap_graduate_commit_csn: removing 0x2b473ca890 20081114194502.917523Z#000000#001#000000
Nov 14 14:45:39 ng04be04 slapd[24622]: do_syncrep2: cookie=rid=002,sid=002,csn=20081114194502.917288Z#000000#001#000000
Nov 14 14:45:39 ng04be04 slapd[24622]: do_syncrep2: rid=002 CSN too old, ignoring 20081114194502.917288Z#000000#001#000000
Nov 14 14:45:39 ng04be04 slapd[24622]: do_syncrep2: cookie=rid=002,sid=002,csn=20081114194502.936884Z#000000#001#000000
### Replication Config ###
dn: olcDatabase={2}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
...
olcSyncrepl: {0}rid=2 provider=ldap://ldap.server.com bindmethod=si
mple timeout=0 network-timeout=0 binddn="cn=Directory Manager,o=ricuc.com" cr
edentials="secret" starttls=no filter="(objectclass=*)" searchbase="o=ricuc.com"
scope=sub schemachecking=off type=refreshandpersist retry="60 +"
olcMirrorMode: TRUE
dn: olcOverlay={0}syncprov,olcDatabase={2}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpCheckpoint: 100 600
olcSpSessionlog: 100
### Hardware ###
Dual Quad Core Xeon 2.83GHz
32GB RAM
8x15000rpm RAID10
Separate LUNS for db and txn logs
Kris Burton
Software Engineer
________________________________________
Acision. Innovation. Assured.
www.acision.com
4870 Sadler Road
Suite 200
Glen Allen, VA
23060
USA
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
15 years, 11 months