Security issues when authenticating from multiple sites
by Einar S. Ids�
Hello,
We have a number of different community sites that will use a
single central OpenLDAP-server for authentication. We want
each site to provide its users with a logon-box for that site, just
as any forum or portal you can find out there. Each site has its
own admins with full access to everything related to their specific
site. This makes it possible for them to edit their own logon
mechanism to capture passwords for users that log on to their
site. Thus an admin on one site can capture the password of an
admin on another site, which is an obvious security issue.
We can of course redirect logons to a common secure webpage,
or monitor files in the respective sites' webroot to detect
modifications to logon procedures, but we'd really prefer a
cleaner solution if at all possible. Do any mechanisms exist
to avoid this problem?
Cheers,
Einar S. Idsø
Norsk eSport DA
12 years, 6 months
can't change password with ldappaswd on Solaris 10 SPARC
by Marius Paulauskas
Hello,
Is anyone successfully running openldap 2.4.15 on Solaris 10 SPARC?
I cannot make it change passwords using ldappasswd if hash is set to
smd5, ssha or crypt.
Using latest Sun Studio 12.
Same problem reveals if compiling with gcc 3.4.3 or 3.4.6.
Somebody suggested it is due to flawed old gcc compiler version. I
installed Sun Studio 12 but problem just wouldn't go away.
Compiles without any problem both 32 or 64 bit memory models.
I just can't believe that Sun Studio is flawed too. I must be missing
some kind of setting or option or flag but seem to run out of ideas.
any input greatly appreciated.
/Marius
12 years, 6 months
Can not modify cn=conf - openldap 2.4.15
by Mathew Rowley
I am trying to configure an n-way multi master following the tutorial in the
admin guide (18.3.3 in
http://www.openldap.org/doc/admin24/replication.html). When trying to
add/modify anything in the cn=config, I get the following error:
atlantis:~/comcast/authentication/ldif $ ldapadd -v -x -W -h 10.252.152.78
-D 'cn=Manager,dc=comcast,dc=com'
ldap_initialize( ldap://10.252.152.78 )
Enter LDAP Password:
dn: cn=config
objectClass: olcGlobal
cn: config
olcServerID: 1
add objectClass:
olcGlobal
add cn:
config
add olcServerID:
1
adding new entry "cn=config"
modify complete
ldap_add: Insufficient access (50)
After looking through the test050 script, I see that this is done using the
slapd Ta instead of a slapadd. I tried doing this, and get this error:
[root@kdc01 scripts]# slapd -Ta
bdb_db_open: warning - no DB_CONFIG file found in directory
/usr/var/openldap-data: (2).
Expect poor performance for suffix "dc=comcast,dc=com".
bdb_monitor_db_open: monitoring disabled; configure monitor database to
enable
dn: cn=config
objectClass: olcGlobal
cn: config
olcServerID: 1
slapadd: line 1: database (dc=comcast,dc=com) not configured to hold
"cn=config"
slapadd: line 1: database (dc=comcast,dc=com) not configured to hold
"cn=config"
I am using 2.4.15 built from source, with the only config option of changing
the prefix directory. Any ideas on whats going on? Thanks.
--
MAT
12 years, 6 months
slapadd thank you!
by William Jojo
Thanks to all for the meter recently added to slapadd!
Yeah, I know it's a small detail, but it really is the little things that matter sometimes. :-)
Cheers,
Bill
12 years, 6 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.
12 years, 6 months
limits in openldap 2.3
by Oliver Henriot
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear list members,
Is there a mechanism to control acces limits in openldap 2.3 similar to
what can be achieved with the openldap 2.4 limits directive
(http://www.openldap.org/doc/admin24/limits.html)?
Appart from sizelimit and timelimit, which are not dn specific and
therefore do not allow the same fine tuning as the limits directive, I
haven't found anything. Maybe I missed it?
Thanks,
- --
Oliver Henriot B.Sc. Ph.D. | Technicien de Maintenance
Moyens Informatiques et Multimédia | UMS MI2S | http://mi2s.imag.fr/
Domaine universitaire BP53 | 38041 Grenoble cedex 9 | France
tel.: +33 4 76 51 43 48 | fax: +33 4 76 51 47 15
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmr+a4ACgkQSWuBJnHIHdJYLQCgr2G31lT6KUAF8VsJDj56Jqdy
OMQAnRZzU69ff3o94cGfJSgV0PlpGW0F
=TEBl
-----END PGP SIGNATURE-----
12 years, 6 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
12 years, 6 months
Is there disadvantage using a single dc?
by AlexanDER Franca
Hi everyone.
Is there any disadvantage using a single dc?
I mean, I work at a small company and I'm setting up a small ldap repository, for me is enough to use just a "dc=my_company".
But slapd says something about less performance.
I think this warning is just about large repositories using just a single dc, what seems to be a bad setup, but I'm not sure.
[]'s
Alexander
12 years, 6 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.
12 years, 6 months
