TLSVerifyClient => no login possible
by Sebastian Reinhardt
Hello,
I have configured an openSUSE 11.0 (x86_64) with openldap- server. Also
the TLS is activated. All clients are set to "TLS_REQCERT demand"
and is working.
Then I created client certificates by using the servers Yast2 CA-
management. I copied teh client certificates and also the servers
"cacert" into the "/etc/openldap/" directory on client computer. With
"TLSVerifyClient allow" clients can login, but if I activate the
"TLSVerifyClient demand" option in servers slapd.conf no user can
perform an login and it causes errors in /var/log/messages:
----------------/var/log/messages----------------
Feb 22 18:50:01 lmvserver slapd[7093]: slap_listener_activate(8):
Feb 22 18:50:01 lmvserver slapd[7093]: >>> slap_listener(ldap://)
Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14)
Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14): got connid=107
Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): checking for
input on id=107
Feb 22 18:50:01 lmvserver slapd[7093]: conn=107 op=0 do_extended
Feb 22 18:50:01 lmvserver slapd[7093]: do_extended:
oid=1.3.6.1.4.1.1466.20037
Feb 22 18:50:01 lmvserver slapd[7093]: send_ldap_extended: err=0 oid= len=0
Feb 22 18:50:01 lmvserver slapd[7093]: send_ldap_response: msgid=1
tag=120 err=0
Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14)
Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14): got connid=107
Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): checking for
input on id=107
Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14)
Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14): got connid=107
Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): checking for
input on id=107
Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): TLS accept
failure error=-1 id=107, closing
Feb 22 18:50:01 lmvserver slapd[7093]: connection_closing: readying
conn=107 sd=14 for close
Feb 22 18:50:01 lmvserver slapd[7093]: connection_close: conn=107 sd=14
Feb 22 18:50:01 lmvserver slapd[7093]: slap_listener_activate(8):
Feb 22 18:50:01 lmvserver slapd[7093]: >>> slap_listener(ldap://)
Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14)
Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14): got connid=108
Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): checking for
input on id=108
Feb 22 18:50:01 lmvserver slapd[7093]: conn=108 op=0 do_extended
Feb 22 18:50:01 lmvserver slapd[7093]: do_extended:
oid=1.3.6.1.4.1.1466.20037
Feb 22 18:50:01 lmvserver slapd[7093]: send_ldap_extended: err=0 oid= len=0
Feb 22 18:50:01 lmvserver slapd[7093]: send_ldap_response: msgid=1
tag=120 err=0
Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14)
Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14): got connid=108
Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): checking for
input on id=108
Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14)
Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14): got connid=108
Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): checking for
input on id=108
Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): TLS accept
failure error=-1 id=108, closing
Feb 22 18:50:01 lmvserver slapd[7093]: connection_closing: readying
conn=108 sd=14 for close
Feb 22 18:50:01 lmvserver slapd[7093]: connection_close: conn=108 sd=14
Feb 22 18:50:01 lmvserver slapd[7093]: slap_listener_activate(8):
Feb 22 18:50:01 lmvserver slapd[7093]: >>> slap_listener(ldap://)
Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14)
Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14): got connid=109
Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): checking for
input on id=109
Feb 22 18:50:01 lmvserver slapd[7093]: conn=109 op=0 do_extended
Feb 22 18:50:01 lmvserver slapd[7093]: do_extended:
oid=1.3.6.1.4.1.1466.20037
Feb 22 18:50:01 lmvserver slapd[7093]: send_ldap_extended: err=0 oid= len=0
Feb 22 18:50:01 lmvserver slapd[7093]: send_ldap_response: msgid=1
tag=120 err=0
Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14)
Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14): got connid=109
Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): checking for
input on id=109
Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14)
Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14): got connid=109
Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): checking for
input on id=109
Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): TLS accept
failure error=-1 id=109, closing
Feb 22 18:50:01 lmvserver slapd[7093]: connection_closing: readying
conn=109 sd=14 for close
Feb 22 18:50:01 lmvserver slapd[7093]: connection_close: conn=109 sd=14
----------------/var/log/messages----------------
slapd.conf:
---------------/etc/openldap/slapd.conf--------
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/yast.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/collective.schema
include /etc/openldap/schema/dnszone.schema
include /etc/openldap/schema/duaconf.schema
include /etc/openldap/schema/dyngroup.schema
include /etc/openldap/schema/samba3.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/nis.schema
# Define global ACLs to disable default read access.
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
# Directives needed to implement policy:
access to dn.base=""
by * read
access to dn.base="cn=Subschema"
by * read
access to attrs=userPassword,userPKCS12
by self write
by * auth
access to attrs=shadowLastChange
by self write
by * read
access to *
by * read
#######################################################################
# BDB database definitions
#######################################################################
loglevel 5
TLSCertificateFile /etc/openldap/servercert.pem
TLSCACertificateFile /etc/openldap/cacert.pem
TLSCertificateKeyFile /etc/openldap/serverkey.pem
TLSVerifyClient demand
database bdb
suffix "dc=lmv,dc=lmv"
rootdn "cn=ldaproot,dc=lmv,dc=lmv"
rootpw "???????"
directory /mnt/lvm/ldap/
checkpoint 1024 5
cachesize 10000
index objectClass,uidNumber,gidNumber eq
index member,mail eq,pres
index cn,displayname,uid,sn,givenname sub,eq,pres
database monitor
---------------/etc/openldap/slapd.conf--------
ldap.conf (client):
--------------/etc/openldap/slapd.conf---------
#
# LDAP Defaults
#
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
TLS_CACERT /etc/openldap/cacert.pem
TLS_CERT /etc/openldap/clientcert_205.pem
TLS_KEY /etc/openldap/clientkey_205.pem
TLS_REQCERT demand
host 192.168.0.201
base dc=lmv,dc=lmv
--------------/etc/openldap/slapd.conf---------
What is wrong? The clients certificate "common name" is set to the
clients hostname. Is this ok?
--
Mit freundlichen Grüßen
Sebastian Reinhardt
14 years, 8 months
error in modifying subordinate entries
by Rakesh Yadav
Hi,
I want to establish communication between two ldap servers at different
machines.
For this i have used "ref attribute of ldap" by using this attribute, i am
able to retrieve
entries of second ldap server. Means i can read or search entries of second
server from
first ldap server.
But the problem comes when i want to modify any attribute of an entry of
second server
from the first server.
Definitely i am having some access permissions related error.
Here i am attaching slapd.conf files of both ldap servers.
*First Server* *slapd.conf:*
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/nis.schema
include /usr/local/etc/openldap/schema/gfsUserManage.schema
include /usr/local/etc/openldap/schema/gfsFileMetaData.schema
# Define global ACLs to disable default read access.
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /usr/local/var/run/slapd.pid
argsfile /usr/local/var/run/slapd.args
# Load dynamic backend modules:
# modulepath /usr/local/libexec/openldap
# moduleload back_bdb.la
# moduleload back_ldap.la
# moduleload back_ldbm.la
# moduleload back_passwd.la
# moduleload back_shell.la
# Sample access control policy:
# Root DSE: allow anyone to write it
# Subschema (sub)entry DSE: allow anyone to write it
#Other DSEs:
allow update_anon
# Allow * write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
access to * by * write
#######################################################################
# BDB database definitions
#######################################################################
database bdb
suffix "dc=cdac,dc=in"
rootdn "cn=Manager,dc=cdac,dc=in"
rootpw secret
index objectClass eq
*access to * by * write*
--------------------------------------------------------------------------------------------------------------------------------
*Second server's slapd.conf:*
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/gfsUserManage.schema
include /usr/local/etc/openldap/schema/gfsFileMetaData.schema
# Define global ACLs to disable default read access.
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
pidfile /usr/local/var/run/slapd.pid
argsfile /usr/local/var/run/slapd.args
#######################################################################
# BDB database definitions
#######################################################################
database bdb
suffix "dc=cdac,dc=in"
rootdn "cn=Manager,dc=cdac,dc=in"
rootpw secret
directory /usr/local/var/gfsMetaData
index objectClass eq
*access to * by * write*
-----------------------------------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------------------------
*FIRST LADP SERVER DN*:
fn=test_ref,fn=bioinfo,fn=gstorage,fn=gfs,dc=cdac,dc=in
where *test_ref* is having *ref* attribute
dn: fn=test_ref,fn=bioinfo,fn=gstorage,fn=gfs,dc=cdac,dc=in
objectClass: referral
objectClass: extensibleObject
fn: test_ref
ref: ldap://192.168.5.243/fn=test_ref,dc=cdac,dc=in
*NOW SECOND LDAP SERVER is having DN*:
dn: fn=test1,fn=test_ref,dc=cdac,dc=in
Now i want to delete "*fn=test1,fn=test_ref,dc=cdac,dc=in*" this entry.
I have used ldap command line tool "*ldapdelete*" and executed this tool on
*first LDAP machine*.
Then the result of command is:
**[root@tapti LDIF]# ldapdelete -x -h "tapti" -D "cn=Manager,dc=cdac,dc=in"
\"fn=test1,fn=test_ref,fn=bioinfo,fn=gstorage,fn=gfs,dc=cdac,dc=in" -w
"secret"
ldap_delete: Referral (10)
matched DN: fn=test_ref,fn=bioinfo,fn=gstorage,fn=gfs,dc=cdac,dc=in
referrals:
ldap://
192.168.5.243/fn=test1,fn=test_ref,fn=bioinfo,fn=gstorage,fn=gfs,dc=cdac,dc=in
*And slapd debug statements:*
do_bind
ber_scanf fmt ({imt) ber:
ber_scanf fmt (m}) ber:
>>> dnPrettyNormal: <cn=Manager,dc=cdac,dc=in>
<<< dnPrettyNormal: <cn=Manager,dc=cdac,dc=in>, <cn=manager,dc=cdac,dc=in>
do_bind: version=3 dn="cn=Manager,dc=cdac,dc=in" method=128
do_bind: v3 bind: "cn=Manager,dc=cdac,dc=in" to "cn=Manager,dc=cdac,dc=in"
send_ldap_result: conn=2 op=0 p=3
send_ldap_response: msgid=1 tag=97 err=0
ber_flush: 14 bytes to sd 11
connection_get(11): got connid=2
connection_read(11): checking for input on id=2
ber_get_next
ber_get_next: tag 0x30 len 69 contents:
ber_get_next
do_delete
ber_scanf fmt (m) ber:
>>> dnPrettyNormal:
<fn=test1,fn=test_ref,fn=bioinfo,fn=gstorage,fn=gfs,dc=cdac,dc=in>
<<< dnPrettyNormal:
<fn=test1,fn=test_ref,fn=bioinfo,fn=gstorage,fn=gfs,dc=cdac,dc=in>,
<fn=test1,fn=test_ref,fn=bioinfo,fn=gstorage,fn=gfs,dc=cdac,dc=in>
bdb_dn2entry("fn=test1,fn=test_ref,fn=bioinfo,fn=gstorage,fn=gfs,dc=cdac,dc=in")
=>
bdb_dn2id("fn=test1,fn=test_ref,fn=bioinfo,fn=gstorage,fn=gfs,dc=cdac,dc=in")
<= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found
(-30990)
bdb_referrals: op=74
target="fn=test1,fn=test_ref,fn=bioinfo,fn=gstorage,fn=gfs,dc=cdac,dc=in"
matched="fn=test_ref,fn=bioinfo,fn=gstorage,fn=gfs,dc=cdac,dc=in"
ldap_url_parse_ext(ldap://192.168.5.243/fn=test_ref,dc=cdac,dc=in)
send_ldap_result: conn=2 op=1 p=3
send_ldap_response: msgid=2 tag=107 err=10
ber_flush: 160 bytes to sd 11
connection_get(11): got connid=2
connection_read(11): checking for input on id=2
ber_get_next
ber_get_next: tag 0x30 len 5 contents:
ber_get_next
do_unbind
connection_closing: readying conn=2 sd=11 for close
connection_resched: attempting closing conn=2 sd=11
connection_close: conn=2 sd=11
*
-----------------------------------------------------------------------------------------------------------------------------------------
*
Please do me a favour suggest any solution as soon as possible through which
i can update slave ldap server entries from master ldap server.
--
Rakesh Yadav
Pune.
14 years, 9 months
OpenLDAP 2.4.15 : CSN too old when using 4-way multimaster
by Adrien Futschik
Hello everyone,
I have been testing n-way multimaster replication with OpenLDAP for a while
now (from 2.4.11, to 2.4.15) and just when I though that everything was
working perfectly, I dicided to test N-way multimaster not only with 2 masters
on different servers, but with 4 !
2 OpenLDAP instances per server.
I have been configuring syncprov and syncrepl accordingly :
olcServerID: 1 ldap://163.106.38.90:9011/
olcServerID: 2 ldap://163.106.38.92:9012/
olcServerID: 3 ldap://163.106.38.90:9013/
olcServerID: 4 ldap://163.106.38.92:9014/
olcSyncrepl: {0}rid=011 provider=ldap://163.106.38.90:9011/ binddn="cn=admin,c
=fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe
rsist retry="5 5 300 12 3600 +" timeout=3
olcSyncrepl: {1}rid=012 provider=ldap://163.106.38.92:9012/ binddn="cn=admin,c
=fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe
rsist retry="5 5 300 12 3600 +" timeout=3
olcSyncrepl: {2}rid=013 provider=ldap://163.106.38.90:9013/ binddn="cn=admin,c
=fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe
rsist retry="5 5 300 12 3600 +" timeout=3
olcSyncrepl: {3}rid=014 provider=ldap://163.106.38.92:9014/ binddn="cn=admin,c
=fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe
rsist retry="5 5 300 12 3600 +" timeout=3
I am starting with all instances synced and I am trying to add entries en all
four instances (in //). If I do so, I have a few entries that are not
replicated on the others. I am getting this kind of messages :
do_syncrep2:
cookie=rid=011,sid=002,csn=20090227130003.849482Z#000000#004#000000
do_syncrep2: rid=011 CSN too old, ignoring
20090227130003.849482Z#000000#004#000000
do_syncrep2:
cookie=rid=013,sid=002,csn=20090227130003.849482Z#000000#004#000000
do_syncrep2: rid=013 CSN too old, ignoring
20090227130003.849482Z#000000#004#000000
do_syncrep2:
cookie=rid=014,sid=002,csn=20090227130003.946474Z#000000#004#000000
Did someone face the same issue ?
Here is my configuration : (I am using refreshAndPersist mode for both cn=config
and olcDatabase={1}bdb)
M1 on IP1 / PORT1 :
dn: cn=config
objectClass: olcGlobal
cn: config
structuralObjectClass: olcGlobal
creatorsName: cn=config
olcServerID: 1 ldap://163.106.38.90:9011/
olcServerID: 2 ldap://163.106.38.92:9012/
olcServerID: 3 ldap://163.106.38.90:9013/
olcServerID: 4 ldap://163.106.38.92:9014/
entryUUID: ef89c876-adb3-4dc7-aa7d-024bbc359c98
createTimestamp: 20090227085748Z
entryCSN: 20090227085749.920499Z#000000#004#000000
modifiersName: cn=config
modifyTimestamp: 20090227085749Z
contextCSN: 20090227085752.833630Z#000000#001#000000
dn: olcDatabase={1}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcDbDirectory: ./openldap-data
olcSuffix: c=fr
olcRootDN: cn=admin,c=fr
olcRootPW:: e1NTSEF9WVZNSHJtYTRvUGd4KzFoak9kYWhBcm5NVHJxU1Zmdno=
olcSizeLimit: 100
olcSyncrepl: {0}rid=011 provider=ldap://163.106.38.90:9011/ binddn="cn=admin,c
=fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe
rsist retry="5 5 300 12 3600 +" timeout=3
olcSyncrepl: {1}rid=012 provider=ldap://163.106.38.92:9012/ binddn="cn=admin,c
=fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe
rsist retry="5 5 300 12 3600 +" timeout=3
olcSyncrepl: {2}rid=013 provider=ldap://163.106.38.90:9013/ binddn="cn=admin,c
=fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe
rsist retry="5 5 300 12 3600 +" timeout=3
olcSyncrepl: {3}rid=014 provider=ldap://163.106.38.92:9014/ binddn="cn=admin,c
=fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe
rsist retry="5 5 300 12 3600 +" timeout=3
olcTimeLimit: 600
olcMirrorMode: TRUE
olcDbCacheSize: 2000
olcDbCheckpoint: 2000 10
olcDbIndex: default pres,eq
olcDbIndex: cn,sn pres,eq,sub
olcDbIndex: objectClass,entryCSN,entryUUID eq
structuralObjectClass: olcBdbConfig
entryUUID: 00c01e5d-69ee-4baa-8e5a-4ef609dfd958
creatorsName: cn=config
createTimestamp: 20090227085752Z
entryCSN: 20090227085752.729899Z#000000#001#000000
modifiersName: cn=config
modifyTimestamp: 20090227085752Z
M2 on IP2 / PORT2 :
dn: cn=config
objectClass: olcGlobal
cn: config
structuralObjectClass: olcGlobal
entryUUID: 8da75037-65e6-4375-8c21-7e5c0194a60b
creatorsName: cn=config
createTimestamp: 20090227085723Z
olcServerID: 1 ldap://163.106.38.90:9011/
olcServerID: 2 ldap://163.106.38.92:9012/
olcServerID: 3 ldap://163.106.38.90:9013/
olcServerID: 4 ldap://163.106.38.92:9014/
entryCSN: 20090227085725.003182Z#000000#002#000000
modifiersName: cn=config
modifyTimestamp: 20090227085725Z
contextCSN: 20090227085752.833630Z#000000#001#000000
dn: olcDatabase={1}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcDbDirectory: ./openldap-data
olcSuffix: c=fr
olcRootDN: cn=admin,c=fr
olcRootPW:: e1NTSEF9WVZNSHJtYTRvUGd4KzFoak9kYWhBcm5NVHJxU1Zmdno=
olcSizeLimit: 100
olcSyncrepl: {0}rid=011 provider=ldap://163.106.38.90:9011/ binddn="cn=admin,c
=fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe
rsist retry="5 5 300 12 3600 +" timeout=3
olcSyncrepl: {1}rid=012 provider=ldap://163.106.38.92:9012/ binddn="cn=admin,c
=fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe
rsist retry="5 5 300 12 3600 +" timeout=3
olcSyncrepl: {2}rid=013 provider=ldap://163.106.38.90:9013/ binddn="cn=admin,c
=fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe
rsist retry="5 5 300 12 3600 +" timeout=3
olcSyncrepl: {3}rid=014 provider=ldap://163.106.38.92:9014/ binddn="cn=admin,c
=fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe
rsist retry="5 5 300 12 3600 +" timeout=3
olcTimeLimit: 600
olcMirrorMode: TRUE
olcDbCacheSize: 2000
olcDbCheckpoint: 2000 10
olcDbIndex: default pres,eq
olcDbIndex: cn,sn pres,eq,sub
olcDbIndex: objectClass,entryCSN,entryUUID eq
structuralObjectClass: olcBdbConfig
entryUUID: 00c01e5d-69ee-4baa-8e5a-4ef609dfd958
creatorsName: cn=config
createTimestamp: 20090227085752Z
entryCSN: 20090227085752.729899Z#000000#001#000000
modifiersName: cn=config
modifyTimestamp: 20090227085752Z
M3 on IP1 / PORT3 :
dn: cn=config
objectClass: olcGlobal
cn: config
structuralObjectClass: olcGlobal
entryUUID: cf068647-318f-4848-9c72-9c7745a8a4b3
creatorsName: cn=config
createTimestamp: 20090227085742Z
olcServerID: 1 ldap://163.106.38.90:9011/
olcServerID: 2 ldap://163.106.38.92:9012/
olcServerID: 3 ldap://163.106.38.90:9013/
olcServerID: 4 ldap://163.106.38.92:9014/
entryCSN: 20090227085743.825685Z#000000#003#000000
modifiersName: cn=config
modifyTimestamp: 20090227085743Z
contextCSN: 20090227085752.833630Z#000000#001#000000
dn: olcDatabase={1}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcDbDirectory: ./openldap-data
olcSuffix: c=fr
olcRootDN: cn=admin,c=fr
olcRootPW:: e1NTSEF9WVZNSHJtYTRvUGd4KzFoak9kYWhBcm5NVHJxU1Zmdno=
olcSizeLimit: 100
olcSyncrepl: {0}rid=011 provider=ldap://163.106.38.90:9011/ binddn="cn=admin,c
=fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe
rsist retry="5 5 300 12 3600 +" timeout=3
olcSyncrepl: {1}rid=012 provider=ldap://163.106.38.92:9012/ binddn="cn=admin,c
=fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe
rsist retry="5 5 300 12 3600 +" timeout=3
olcSyncrepl: {2}rid=013 provider=ldap://163.106.38.90:9013/ binddn="cn=admin,c
=fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe
rsist retry="5 5 300 12 3600 +" timeout=3
olcSyncrepl: {3}rid=014 provider=ldap://163.106.38.92:9014/ binddn="cn=admin,c
=fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe
rsist retry="5 5 300 12 3600 +" timeout=3
olcTimeLimit: 600
olcMirrorMode: TRUE
olcDbCacheSize: 2000
olcDbCheckpoint: 2000 10
olcDbIndex: default pres,eq
olcDbIndex: cn,sn pres,eq,sub
olcDbIndex: objectClass,entryCSN,entryUUID eq
structuralObjectClass: olcBdbConfig
entryUUID: 00c01e5d-69ee-4baa-8e5a-4ef609dfd958
creatorsName: cn=config
createTimestamp: 20090227085752Z
entryCSN: 20090227085752.729899Z#000000#001#000000
modifiersName: cn=config
modifyTimestamp: 20090227085752Z
M4 on IP2 / PORT4 :
dn: cn=config
objectClass: olcGlobal
cn: config
structuralObjectClass: olcGlobal
entryUUID: ef89c876-adb3-4dc7-aa7d-024bbc359c98
creatorsName: cn=config
createTimestamp: 20090227085748Z
olcServerID: 1 ldap://163.106.38.90:9011/
olcServerID: 2 ldap://163.106.38.92:9012/
olcServerID: 3 ldap://163.106.38.90:9013/
olcServerID: 4 ldap://163.106.38.92:9014/
entryCSN: 20090227085749.920499Z#000000#004#000000
modifiersName: cn=config
modifyTimestamp: 20090227085749Z
contextCSN: 20090227085752.833630Z#000000#001#000000
dn: olcDatabase={1}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcDbDirectory: ./openldap-data
olcSuffix: c=fr
olcRootDN: cn=admin,c=fr
olcRootPW:: e1NTSEF9WVZNSHJtYTRvUGd4KzFoak9kYWhBcm5NVHJxU1Zmdno=
olcSizeLimit: 100
olcSyncrepl: {0}rid=011 provider=ldap://163.106.38.90:9011/ binddn="cn=admin,c
=fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe
rsist retry="5 5 300 12 3600 +" timeout=3
olcSyncrepl: {1}rid=012 provider=ldap://163.106.38.92:9012/ binddn="cn=admin,c
=fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe
rsist retry="5 5 300 12 3600 +" timeout=3
olcSyncrepl: {2}rid=013 provider=ldap://163.106.38.90:9013/ binddn="cn=admin,c
=fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe
rsist retry="5 5 300 12 3600 +" timeout=3
olcSyncrepl: {3}rid=014 provider=ldap://163.106.38.92:9014/ binddn="cn=admin,c
=fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe
rsist retry="5 5 300 12 3600 +" timeout=3
olcTimeLimit: 600
olcMirrorMode: TRUE
olcDbCacheSize: 2000
olcDbCheckpoint: 2000 10
olcDbIndex: default pres,eq
olcDbIndex: cn,sn pres,eq,sub
olcDbIndex: objectClass,entryCSN,entryUUID eq
structuralObjectClass: olcBdbConfig
entryUUID: 00c01e5d-69ee-4baa-8e5a-4ef609dfd958
creatorsName: cn=config
createTimestamp: 20090227085752Z
entryCSN: 20090227085752.729899Z#000000#001#000000
modifiersName: cn=config
modifyTimestamp: 20090227085752Z
I also have to say that if I stop M3 & M4 and try to add entries to M1 & M2, I
don't get the "CSN too old" messages and all entries a replicated correctly
!!!
Is this because Multimaster is limited to 2-3 instances ? The reason why I am
trying to build a 4-way master architecture is because I would like to be able
to stop one server and perform a slapcat, even if one "physical" server is
down...
Thanks very much for your consideration & time..
Adrien Futschik
14 years, 9 months
ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by Marius P.
Hello,
I am trying to change a password for ldap entry using ldappasswd -vx
-D "cn=root,dc=test,dc=com" -w foobarr
"uid=mariusp,ou=people,dc=test,dc=com" and reply I get is:
Result: Other (e.g., implementation specific) error (80)
Additional info: password hash failed
I am running openldap on Solaris 10 latest on SPARC. It is in testing
meaning there is nothing special about its configuration all defaults.
Database has two entries just to play with.
I haven't bothered to compile it myself so just downloaded openldap
2.4.11 from sunfreeware.com with required prerequisits such as
Berkeley DB, SASL, openssl etc.
Everything works fine except this weird problem which looks like a bug.
Password checking (binding) works fine if I manually change
userPassword: attribute no matter what algorithm prefix I use be it
SSHA, crypt or MD5. That tells me that it can succesfully check and
run those algorithms however something breaks when it tries to change
the password like it couldn't hash that supplied password.
Wondering if anyone exprienced similar problem and have any comments
or findings.
Regards,
/M.
14 years, 9 months
BDB Inconsistencies when configuring on RH4 vs RH5
by Mathew Rowley
When installing 2.4.11 on my RH4 box, it configures fine with db4-4.2.52
installed (with bdb support)
...
Making servers/slapd/backends.c
Add config ...
Add ldif ...
Add monitor ...
Add bdb ...
Add hdb ...
Add relay ...
Making servers/slapd/overlays/statover.c
Add seqmod ...
Add syncprov ...
Please run "make depend" to build dependencies
[root@rsa01 openldap-2.4.11]# rpm -qa | grep db4
db4-4.2.52-7.1
db4-devel-4.2.52-7.1
[root@rsa01 openldap-2.4.11]# cat /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 5)
[root@rsa01 openldap-2.4.11]#
But when trying to configure on a RH5 system, I get the BDB incompatible
error:
...
checking for Berkeley DB link (-ldb-4.3)... yes
checking for Berkeley DB version match... yes
checking for Berkeley DB thread support... yes
checking Berkeley DB version for BDB/HDB backends... no
configure: error: BDB/HDB: BerkeleyDB version incompatible
[root@kdc01 openldap-2.4.11]# rpm -qa | grep db4
db4-utils-4.3.29-9.fc6
db4-devel-4.3.29-9.fc6
db4-4.3.29-9.fc6
[root@kdc01 openldap-2.4.11]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.2 (Tikanga)
[root@kdc01 openldap-2.4.11]#
Is this an error in the configure script? Kind of confused. Thanks for any
help.
--
MAT
14 years, 9 months
Running both ldap and ldaps simultaneously
by Bryan Payne
I'm trying to run both ldap:// and ldaps:// at the same time. Reason being, I can't get phpldapadmin to use ldaps. If I execute the command: /usr/local/openldap/libexec/slapd -u ldap -h ldap:/// ldaps:///, it just listens on 389. If I run, /usr/local/openldap/libexec/slapd -u ldap -h ldaps:/// ldap:///, it just listens on 636. How can I get it to listen on both ports?
14 years, 9 months
Re: contextCSN
by Guillaume Arteta
Hello,
Sorry for my English google:)
I'm put into production 2 openldap masters, and I asked the same question
João Alfredo.
*
So, if the resultt of this search is the same on all master's this mean that
all servers are consistents, right ?*
Ok, the ldapsearch (ldapsearch-x-h Master1 ... and ldapsearch-x-h master2
...) displays the same values of contextCSN for server ID, but what it
proves that they are synchronized?
The question is, why master node, the ldapsearch ContextCSN displays of 2
servers (001 & 002)
Can be put in place a monitoring system to test the replication by
performing 2 ldapsearchs, if even then synchronized values.
Merci
------
Arteta.
14 years, 9 months
ldapmodify command line tool results in 'deferring operation: too many executing'
by Sean Burford
Hi,
During a recent ldapmodify of 1000 records, I got some "deferring operation:
too many executing" messages from OpenLDAP slapd 2.3.39.
I am surprised by this, since I thought that since ldapmodify waited for the
result of each operation nothing would be queued.
Could this be caused by there being too many operations in progress across
the entire server?
This was the ldapmodify command line:
ldapmodify -v -H "ldaps://master.example.com" -x -W -D
"uid=person,ou=people,dc=example,dc=com" -c -f file.ldif
The ldif only contained OpenLDAPaci attribute deletes that fit this
template:
dn: cn=host1000.example.com,ou=servers,dc=example,dc=com
changetype: modify
delete: OpenLDAPaci
The ldapmodify output looked normal:
delete OpenLDAPaci:
modifying entry "cn=host1000.example.com,ou=servers,dc=example,dc=com"
modify complete
delete OpenLDAPaci:
modifying entry "cn=host1001.example.com,ou=servers,dc=example,dc=com"
modify complete
But the logs show the 'deferring operation: too many executing':
Feb 24 08:27:54 server slapd[9433]: conn=19226 op=640 MOD dn="cn=
host1000.example.com,ou=servers,dc=example,dc=com"
Feb 24 08:27:54 server slapd[9433]: conn=19226 op=640 MOD attr=OpenLDAPaci
Feb 24 08:27:54 server slapd[9433]: conn=19226 op=640 RESULT tag=103 err=0
text=
Feb 24 08:27:54 server slapd[9433]: connection_input: conn=19226 deferring
operation: too many executing
Feb 24 08:27:54 server slapd[9433]: conn=19226 op=641 MOD dn="cn=
host1001.example.com,ou=servers,dc=example,dc=com"
Feb 24 08:27:54 server slapd[9433]: conn=19226 op=641 MOD attr=OpenLDAPaci
Feb 24 08:27:54 server slapd[9433]: conn=19226 op=641 RESULT tag=103 err=0
text=
--
Thanks,
Sean Burford
14 years, 9 months
How to integrated OpenLDAP proxy to web application
by Duong Pham Tung
Hi all,
I have already installed an OpenLDAP server as a LDAP proxy server. The data source backend of this server is a set of AD servers and other LDAP servers. I also have enabled SASL and Pass-through Authentication feature on this OpenLDAP server. Everything is running properly. Now, I want to deploy an Web Application which will use this OpenLDAP as a backend data source. I have deployed Pass-through authentication via SASL server, but as I understand, I must store information about user on my OpenLDAP server (such as username) and the userPassword field is set to {SASL}user@realm. But this LDAP proxy hasn’t any information about user on itself. So, which solutions can I use to solve user authentication problem without storing any user information on the LDAP Proxy.
Thanks and Best regards
Dương Phạm Tùng
14 years, 9 months
Re: Password protection of TLS key
by ghenry＠OpenLDAP.org
> No really good ideas come to mind. I have a patch for libldap to
> explicitly
> set a callback to supply the key password, it won't make it into
> 2.4.13 but
> probably will be in 2.4.14. I will probably add two options to slapd,
Hi,
Did this make it into 2.4.14? I've checked the CHANGES and can't see anything
mentioned re libldap?
Thanks.
> analogous to the back-bdb options to set the DB encryption key. (One
> option to
> set the key directly as an argument of the config option, one option
> to read
> the key from an arbitrary file.) Obviously for automated startup the
> plaintext
> of the key must be accessible to the slapd somewhere, and that means
> it is
> also accessible to potential intruders. This is just a fact of life.
> You can
> make key retrieval more tedious by hiding it behind other layers of
> encryption, but ultimately the keys to each of those layers must also
> be
> accessible, otherwise slapd itself cannot use them.
>
> There are "clever" schemes to hide startup keys, but they tend to make
>
> restarts difficult. E.g., store keys on a mountpoint that you remount
> some
> other filesystem onto after the boot sequence has completed and all
> dependent
> daemons have started. Keep a file handle open on the new filesystem,
> to
> prevent it from being dismounted without rebooting the system. It'll
> fool a
> lot of intruders, but you won't be able to restart individual daemons
> without
> rebooting the machine.
>
> > Akke Bengtsson
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
14 years, 9 months
