unique id required
by Arpit Jain
Dear List Members,
OpenLDAP version 2.3.39 on RHEL5
I am using "OpenLDAP " to store information. This information is
retrieved by a "client" and made available to "user" via the
vfs(virtual fire system) interface in linux. The user then
reads/writes/browses the information just like in a filesystem. I can
store a 64-bit id of each entry as inode number in my client.
A "unique id" of size 64-bits is required for each entry so that once
an entry is searched by giving "dn", further searches for the entry
can be done using that unique id.
The unique id must be in some way auto-generated by openldap server.
entryUUID has been identified to fulfills all the requirements except
that it is 128-bit long.
I would like to know if there is some other operational attribute
which is unique for each entry and of size 64-bits?
of if I can extract a 64-bit unique value from entryUUID or any other attribute?
If required the operation can be shifted to some other version of OpenLDAP also.
Arpit J.
Center for Development of Advanced Computing (C-DAC)
http://www.cdac.in
13 years, 11 months
BDB and cache settings - anything wrong? userPassword field keeps getting corrupted.
by k bah
I have one LDAP master server, a test server, which no one but me has access to (at least I think). Something really strange is happening, userPassword fields (they are in MD5 format) keep getting changed every 1 or 2 days. Sometimes they change after a mass add operation, or mass delete operation. It could be someone messing with me, but that would be unusual, since they also happen after I do mass operations on the server. I rechecked my "mass operation" scripts, and they do not seem to be breaking other entries while they operate on a given entry (add/delete entry and bind with that DN).
I think maybe my BDB and cache settings may be causing it, it's just a thought, I really don't know what's going on:
I have about 15000 entries on my server, they will grown around 1000 each 6 months.
My slapd.conf ---
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/rfc2307bis.schema
include /etc/openldap/schema/yast.schema
include /etc/openldap/schema/postfix.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/acl-ldap.conf
schemacheck on
allow bind_v2
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
modulepath /usr/lib/openldap/modules
database bdb
suffix "dc=organization,dc=com,dc=tld"
cachesize 16500
rootdn "cn=donotusethisdn,dc=organization,dc=com,dc=tld"
rootpw {MD5}blablabla
checkpoint 1024 5
loglevel any
lastmod on
SIZELIMIT -1
directory /var/lib/ldap
index objectClass eq,pres # 2008-07-25
index ou,cn,mail,sn,givenname eq,pres,sub # 2008-06-31
index uid,memberUid,mailacceptinggeneralid,maildrop pres,eq
index mailroutingaddress pres,eq
TLSCertificateFile /etc/openldap/cert.crt
TLSCertificateKeyFile /etc/openldap/key.key
TLSCACertificateFile /etc/openldap/cacert.crt
replica uri=ldap://ldapslave.organization.com.tld:389
binddn=cn=slavereplicator,ou=adm,dc=organization,dc=com,dc=tld
bindmethod=simple credentials=blebleble starttls=critical
replogfile /var/lib/ldap/replog
--- slapd.conf
--- /var/lib/ldap/DB_CONFIG
set_cachesize 0 64781516 1
set_lg_regionmax 262144
set_lg_bsize 2097152
set_flags DB_LOG_AUTOREMOVE
--- /var/lib/ldap/DB_CONFIG
---------------
server: # ls -lh /var/lib/ldap/*.bdb
-rw------- 1 ldap ldap 6.2M Aug 28 08:58 /var/lib/ldap/cn.bdb
-rw------- 1 ldap ldap 3.3M Aug 28 08:58 /var/lib/ldap/dn2id.bdb
-rw------- 1 ldap ldap 4.8M Aug 28 08:58 /var/lib/ldap/givenName.bdb
-rw------- 1 ldap ldap 20M Aug 28 08:58 /var/lib/ldap/id2entry.bdb
-rw------- 1 ldap ldap 11M Aug 28 08:58 /var/lib/ldap/mail.bdb
-rw------- 1 ldap ldap 816K Aug 28 08:58 /var/lib/ldap/mailRoutingAddress.bdb
-rw------- 1 ldap ldap 8.0K Aug 22 15:55 /var/lib/ldap/memberUid.bdb
-rw------- 1 ldap ldap 2.0M Aug 28 08:58 /var/lib/ldap/objectClass.bdb
-rw------- 1 ldap ldap 8.0K Aug 22 15:55 /var/lib/ldap/ou.bdb
-rw------- 1 ldap ldap 8.7M Aug 28 08:58 /var/lib/ldap/sn.bdb
-rw------- 1 ldap ldap 804K Aug 28 08:58 /var/lib/ldap/uid.bdb
---------------
These cache settings make sense?
The "corruptions", if I can call them that, are also happening on the slave, master and slave are exactly equal (slapcat's output is exact the same), so I rule out that the replication is causing this.
Before "checkpoint 1024 5" on slapd.conf was "checkpoint 512 15".
I'm turning replication off, and I'll see what happens.
I really don't understand what's going on, an attacker messing with me would be really strange, since he does not have access to anything with these passes, and he could do a lot of other more obvious things to mess with my work, I don't know, deleting something....but at the same time, it's strange to get data corrupted and _just_ this particular field. Other fields on the entries are not altered.
=
--
Powered by Outblaze
13 years, 11 months
hdb search performance
by tamarin p
I've been running some tests with OpenLDAP 2.4.11 lately, with an existing
application that will use the LDAP as its backend for storing users and
roles.
Using bdb, performance is excellent. With hdb on the other hand, the
application is rendered unusable unless the searched entry is already
cached, as one particular search takes minutes to execute otherwise, whereas
in bdb the same search quite fast regardless. The specific search is subtree
(scope=2 deref=0) filtered on "o" and "objectclass" like so:
(&(objectClass=organization)(o=123456)).. Both attributes have equality
indexes. The whole directory has just over 4 million entries, and about
500.000 of those are in the context being searched thanks to the scope. The
strange thing is how bdb is fast from search one, while hdb with hdb it
takes minutes to complete unless the entry is already cached. I've tried
configuring caches according to the faq-o-matic. The docs mention that hdb
requires a bigger idl cache in particular, to have good search performance,
so I've tried various cache sizes, up to 1 million for idl- and 330.000 for
the entry caches, but this seems to make slapd dig so deeply into virtual
memory that I'm not sure if it actually does more harm than good.
As for DB_CONFIG, I've reused the same DB_CONFIG for both backends and
configured according to the faq-o-matic as far as I can tell, then doubled
(and then some) the size I came up with to be on the safe side with regards
to overhead and such. dn2id with pagesize 4096 and approx 9300 internal
pages, and id2entry with pagesize 16k and 300 internal pages and I've
allocated 256mb to the dbcache which should be a lot more than the ~50mb
minimum required I ended up with for internal pages and any overhead. Also
tried bumping this to 512MB but as the faq-o-matic entry suggests, this
doesn't seem to have any effect really.
Now, there's no requirement to use hdb as the application doesn't need
subtree renames and bdb works great. I just want check that my config isn't
horribly wrong, or that I'm overlooking something vital for hdb not required
for bdb..
13 years, 11 months
Lock table is out of available object entries
by Reynaldo Quezada V.
I tried the next solutions...
1.- I charge the DB with slapadd, since one backup but when I Charge other group with 1500 users the error occurs again...
ldap_modify: Internal (implementation specific) error (80)
2.- I delete the group from the backup and charge the DB withouth problems, but when I charge the group by separated, the error occurs again.
ldap_modify: Internal (implementation specific) error (80)
3.- I started the slapd in debug level 3 and charge the group by separately and this is the exit....
bdb(dc=gtk.org): Lock table is out of available object entries
=> bdb_idl_insert_key: c_get failed: Cannot allocate memory (12)
<= key_change 12
<= index_entry_add( 21187, "cn=obs.capture,ou=grupos,dc=gtk.org" ) failure
bdb_add: index_entry_add failed
send_ldap_result: conn=3 op=1 p=3
send_ldap_response: msgid=2 tag=105 err=80
ber_flush: 37 bytes to sd 13
0000: 30 23 02 01 02 69 1e 0a 01 50 04 00 04 17 69 6e 0#...i...P....in
0010: 64 65 78 20 67 65 6e 65 72 61 74 69 6f 6e 20 66 dex generation f
0020: 61 69 6c 65 64 ailed
ldap_write: want=37, written=37
0000: 30 23 02 01 02 69 1e 0a 01 50 04 00 04 17 69 6e 0#...i...P....in
0010: 64 65 78 20 67 65 6e 65 72 61 74 69 6f 6e 20 66 dex generation f
0020: 61 69 6c 65 64 ailed
connection_get(13): got connid=3
connection_read(13): checking for input on id=3
ber_get_next
ldap_read: want=8, got=7
0000: 30 05 02 01 03 42 00 0....B.
ber_get_next: tag 0x30 len 5 contents:
ber_get_next
ldap_read: want=8, got=0
ber_get_next on fd 13 failed errno=0 (Success)
connection_read(13): input error=-2 id=3, closing.
connection_closing: readying conn=3 sd=13 for close
connection_close: deferring conn=3 sd=13
do_unbind
connection_resched: attempting closing conn=3 sd=13
connection_close: deferring conn=3 sd=13
connection_resched: attempting closing conn=3 sd=13
connection_close: conn=3 sd=13
connection_get(13): connection not used
connection_read(13): no connection!
daemon: shutdown requested and initiated.
slapd shutdown: waiting for 0 threads to terminate
slapd shutdown: initiated
====> bdb_cache_release_all
slapd destroy: freeing system resources.
4.- I was learning about this error and make some tunning to the memory's parameters but the error persist
the configuration in the DB_CONFIF is...
set_cachesize 0 1610612736 1
set_lk_max_locks 1048576
# Set database flags.
# (for database loading/reindexing)
#set_flags DB_TXN_NOSYNC
# Set log values.
#
set_lg_regionmax 31457280
set_lg_max 20971520
set_lg_bsize 4194304
set_lg_dir /var/lib/ldap
Thanks a lot!
Reynaldo Quezada
L.I. UNAM
__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.yahoo.com.mx/
13 years, 11 months
bdb_idl_insert_key: c_get failed: Cannot allocate memory (12)
by Reynaldo Quezada V.
Hi to everyone!
I have a great problem, in my job I have a server with LDAP(openldap-2.3.27)
The problem is when I charge one group with around 1654 registers the next error shows:
ldap_modify: Internal (implementation specific) error (80)
I tried the next solutions...
1.- I charge the DB with slapadd, since one backup but when I Charge other group with 1500 users the error occurs again...
ldap_modify: Internal (implementation specific) error (80)
2.- I delete the group from the backup and charge the DB withouth problems, but when I charge the group by separated, the error occurs again.
ldap_modify: Internal (implementation specific) error (80)
3.- I started the slapd in debug level 3 and charge the group by separately and this is the exit....
bdb(dc=gtk.org): Lock table is out of available object entries
=> bdb_idl_insert_key: c_get failed: Cannot allocate memory (12)
<= key_change 12
<= index_entry_add( 21187, "cn=obs.capture,ou=grupos,dc=gtk.org" ) failure
bdb_add: index_entry_add failed
send_ldap_result: conn=3 op=1 p=3
send_ldap_response: msgid=2 tag=105 err=80
ber_flush: 37 bytes to sd 13
0000: 30 23 02 01 02 69 1e 0a 01 50 04 00 04 17 69 6e 0#...i...P....in
0010: 64 65 78 20 67 65 6e 65 72 61 74 69 6f 6e 20 66 dex generation f
0020: 61 69 6c 65 64 ailed
ldap_write: want=37, written=37
0000: 30 23 02 01 02 69 1e 0a 01 50 04 00 04 17 69 6e 0#...i...P....in
0010: 64 65 78 20 67 65 6e 65 72 61 74 69 6f 6e 20 66 dex generation f
0020: 61 69 6c 65 64 ailed
connection_get(13): got connid=3
connection_read(13): checking for input on id=3
ber_get_next
ldap_read: want=8, got=7
0000: 30 05 02 01 03 42 00 0....B.
ber_get_next: tag 0x30 len 5 contents:
ber_get_next
ldap_read: want=8, got=0
ber_get_next on fd 13 failed errno=0 (Success)
connection_read(13): input error=-2 id=3, closing.
connection_closing: readying conn=3 sd=13 for close
connection_close: deferring conn=3 sd=13
do_unbind
connection_resched: attempting closing conn=3 sd=13
connection_close: deferring conn=3 sd=13
connection_resched: attempting closing conn=3 sd=13
connection_close: conn=3 sd=13
connection_get(13): connection not used
connection_read(13): no connection!
daemon: shutdown requested and initiated.
slapd shutdown: waiting for 0 threads to terminate
slapd shutdown: initiated
====> bdb_cache_release_all
slapd destroy: freeing system resources.
4.- I was learning about this error and make some tunning to the memory's parameters but the error persist
the configuration in the DB_CONFIF is...
set_cachesize 0 1610612736 1
set_lk_max_locks 1048576
# Set database flags.
# (for database loading/reindexing)
#set_flags DB_TXN_NOSYNC
# Set log values.
#
set_lg_regionmax 31457280
set_lg_max 20971520
set_lg_bsize 4194304
set_lg_dir /var/lib/ldap
Thanks a lot!
Reynaldo Quezada
L.I. UNAM
__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.yahoo.com.mx/
13 years, 11 months
Re: openldap 2.4.9 dies adding uid of a single character (overlay unique uid)
by Pierangelo Masarati
Please post replies to the list.
291168(a)telefonica.net wrote:
> With 'slapd -d1 ' (I just knew "loglevel -1" ) I could see the problem, which is also reported in
>
> http://archive.netbsd.se/?ml=OpenLDAP-bugs&a=2008-05&t=7374897
If people would post OpenLDAP issues to OpenLDAP instead of other, unrelated lists, issues could be resolved faster.
Anyway, I note that since OpenLDAP 2.4.9 there were at least two fixes related to unique overlay, if this is the case. Did you
check with the latest release?
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
13 years, 11 months
openldap 2.4.9 dies adding uid of a single character (overlay unique uid)
by 291168＠telefonica.net
openldap 2.4.9
Suse 11.0
The following entries has been added successfully:
dn: o=my-org,dc=my-domain,dc=com
dn: ou=People,o=my-org,dc=my-domain,dc=com
dn: uid=rvg,ou=People,o=my-org,dc=my-domain,dc=com
dn: ou=Servers,o=my-org,dc=my-domain,dc=com
Working with he basic configuration, only adding the overlay unique which is working fine. A same uid cannot be added to the branch People and Servers.
overlay unique
unique_uri ldap:///?uid?sub
But, in adding the following entry:
dn: uid=1, ou=People, o=my-org, dc=my-domain, dc=com
userPassword: secret
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
cn: xxxxxxxxxxxxx
sn: xxxxxxxxxxx
uid: 1
openldap dies
ldapmodify -a -x -D "cn=Manager,o=my-org,dc=my-domain,dc=com" -w secret
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
The last logs are:
Aug 28 09:28:32 localhost slapd[3423]: conn=1 op=1 ADD dn="uid=1,ou=Servers,o=my-org, dc=my-domain, dc=com"
Aug 28 09:28:32 localhost slapd[3423]: bdb_dn2entry("uid=1,ou=servers,o=my-org, dc=my-domain, dc=com")
Aug 28 09:28:32 localhost slapd[3423]: => bdb_dn2id("o=my-org, dc=my-domain, dc=com")
Aug 28 09:28:32 localhost slapd[3423]: bdb_dn2id("ou=servers,o=my-org, dc=my-domain, dc=com")
Aug 28 09:28:32 localhost slapd[3423]: bdb_dn2id("uid=1,ou=servers,o=my-org, dc=my-domain, dc=com")
Aug 28 09:28:32 localhost slapd[3423]: unique_add
TERRA
-->
13 years, 11 months
simple bind with non-dn
by Moser
Hi!
We used to have a Domino server. His LDAP service was and is used by an
CMS application.
In Domino you can do a simple bind with a non-dn like
# ldapsearch -x -d "notes admin" -W -h dominoserver cn="hans*"
Where the username is in e.g. the CN attribute.
Is there a way to achieve this behavior with OpenLDAP 2.3.x somehow?
Hans
13 years, 11 months
LDAP* which calls private functions for I/O?
by Hallvard B Furuseth
I'd like to use libldap to generate and parse LDAP messages in
memory, without doing any I/O operations. Presumably by using
a Sockbuf which calls my private functions to handle messages.
Is that possible today? If not, could we add an API for it?
--
Hallvard
13 years, 11 months
/etc/ldap/slapd.conf: line 158: invalid path: Permission denied
by zhangweiwu＠realss.com
Dear all
I've had this strange problem on a new openldap (2.4.9-0ubuntu0.8.04.2)
installation:
root@emerson # slapd -d 256 -h 'ldap://0.0.0.0:636/' -f /etc/ldap/slapd.conf
@(#) $OpenLDAP: slapd 2.4.9 (Aug 5 2008 20:18:55) $
buildd@palmer:/build/buildd/openldap2.3-2.4.9/debian/build/servers/slapd
/etc/ldap/slapd.conf: line 126: rootdn is always granted unlimited privileges.
/etc/ldap/slapd.conf: line 143: rootdn is always granted unlimited privileges.
/etc/ldap/slapd.conf: line 158: invalid path: Permission denied
slapd stopped.
connections_destroy: nothing to destroy.
Where:
root@emerson # sed -n 158p /etc/ldap/slapd.conf
directory "/var/lib/ldap_jxpado"
This is rather strange because as you can see I am running slapd as
root. I also verified I have full access to /var/lib/ldap_jxpado, in
fact, I just created this directory and successfully imported the ldap
backup from a productional server without any error message. It looks
simple but when I am told 'permission denied' when I actually have the
permission I am stuck not knowing where to start to look for solution.
I've attached my slapd.conf in case you can help (rootdn password not
removed due to they are just temporary testing installation. Thanks for
hints and point me to the right direction to solve the problem.
Best regards
Zhang Weiwu
--
Real Softservice
Huateng Tower, Unit 1788
Jia 302 3rd area of Jinsong, Chao Yang
Tel: +86 (10) 8773 0650 ext 603
Mobile: 159 1111 7382
http://www.realss.com
# This is the main slapd configuration file. See slapd.conf(5) for more
# info on the configuration options.
#######################################################################
# Global Directives:
# Features to permit
#allow bind_v2
# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/qmail.schema
include /etc/ldap/schema/evolutionperson.schema
include /etc/ldap/schema/phpgwcontact.schema
include /etc/ldap/schema/phpgwaccount.schema
include /etc/ldap/schema/ppolicy.schema
include /etc/ldap/schema/dyngroup.schema
include /etc/ldap/schema/lgopOrganizationalUnit.schema
# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile /var/run/slapd/slapd.pid
# List of arguments that were passed to the server
argsfile /var/run/slapd/slapd.args
# Read slapd.conf(5) for possible values
loglevel none
# Where the dynamically loaded modules are stored
modulepath /usr/lib/ldap
moduleload back_hdb
moduleload back_bdb
moduleload ppolicy
moduleload dynlist
# The maximum number of entries that is returned for a search operation
sizelimit 500
# The tool-threads parameter sets the actual amount of cpu's that is used
# for indexing.
tool-threads 1
#######################################################################
# Specific Backend Directives for hdb:
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend hdb
#######################################################################
# Specific Backend Directives for 'other':
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
#backend <other>
#######################################################################
# Specific Directives for database #1, of type hdb:
# Database specific directives apply to this databasse until another
# 'database' directive occurs
database hdb
# The base of your directory in database #1
suffix "dc=eoa,dc=cn"
# rootdn directive for specifying a superuser on the database. This is needed
# for syncrepl.
rootdn "cn=manager,dc=eoa,dc=cn"
rootpw {MD5}KY6+x4m2j4RgjH+Oz12JBg==
index default pres,eq
index objectClass eq
index uidNumber,gidNumber,uid,phpgwAccountType,phpgwAccountStatus,associatedDomain,mailAlternateAddress,deliveryMode,userPassword,accountstatus
index mail,o,cn,st,businessCategory sub,eq,pres
index sn,givenName,title,personalTitle,category eq,pres,sub
cachesize 5000
idlcachesize 15000
# Where the database file are physically stored for database #1
directory "/var/lib/ldap"
# The dbconfig settings are used to generate a DB_CONFIG file the first
# time slapd starts. They do NOT override existing an existing DB_CONFIG
# file. You should therefore change these settings in DB_CONFIG directly
# or remove DB_CONFIG and restart slapd for changes to take effect.
# For the Debian package we use 2MB as default but be sure to update this
# value if you have plenty of RAM
dbconfig set_cachesize 0 2097152 0
# Sven Hartge reported that he had to set this value incredibly high
# to get slapd running at all. See http://bugs.debian.org/303057 for more
# information.
# Number of objects that can be locked at the same time.
dbconfig set_lk_max_objects 1500
# Number of locks (both requested and granted)
dbconfig set_lk_max_locks 1500
# Number of lockers
dbconfig set_lk_max_lockers 1500
# Save the time that the entry gets modified, for database #1
lastmod on
# Checkpoint the BerkeleyDB database periodically in case of system
# failure and to speed slapd shutdown.
checkpoint 512 30
# Where to store the replica logs for database #1
# replogfile /var/lib/ldap/replog
# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
# These access lines apply to database #1 only
access to attrs=userPassword,shadowLastChange
by dn="cn=manager,dc=eoa,dc=cn" write
by anonymous auth
by self write
by * none
# Ensure read access to the base for things like
# supportedSASLMechanisms. Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work
# happily.
access to dn.base="" by * read
# The admin dn has full write access, everyone else
# can read everything.
access to *
by dn="cn=manager,dc=eoa,dc=cn" write
by * read
#######################################################################
# Specific Directives for database #2, of type 'other' (can be hdb too):
# Database specific directives apply to this databasse until another
database hdb
suffix "st=jiangxi,o=LGOP"
rootdn "userid=admin,st=jiangxi,o=LGOP"
rootpw {SSHA}WioqVan6XWmP+j1LuGbLnYuGVC3jrdoo
overlay ppolicy
ppolicy_default "st=jiangxi,o=LGOP"
ppolicy_use_lockout
overlay dynlist
dynlist-attrset groupOfURLs memberURL
directory "/var/lib/ldap_jxpado"
dbconfig set_cachesize 0 2097152 0
# Sven Hartge reported that he had to set this value incredibly high
# to get slapd running at all. See http://bugs.debian.org/303057
# for more information.
# Number of objects that can be locked at the same time.
dbconfig set_lk_max_objects 1500
# Number of locks (both requested and granted)
dbconfig set_lk_max_locks 1500
# Number of lockers
dbconfig set_lk_max_lockers 1500
# Indexing options for database #1
index objectClass eq
# Save the time that the entry gets modified, for database #1
lastmod on
# Where to store the replica logs for database #1
# replogfile /var/lib/ldap/replog
#access to dn.regex="(.+,)?(ou=[^,]+,st=jiangxi,o=LGOP)$"
# by dn.exact,expand="$2" write
#access to dn.regex="(.+,)?(ou=[^,]+,st=jiangxi,o=LGOP)$"
# by dn.regex="$2" write
# by anonymous read
#
# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
# These access lines apply to database #1 only
access to attrs=userPassword,shadowLastChange
by dn="ou=江西省,st=jiangxi,o=LGOP" write
by anonymous auth
by self write
by * none
# Ensure read access to the base for things like
# supportedSASLMechanisms. Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work
# happily.
access to dn.base="" by * read
# The admin dn has full write access, everyone else
# can read everything.
access to *
by dn="userid=admin,st=jiangxi,o=LGOP" write
by * read
# For Netscape Roaming support, each user gets a roaming
# profile for which they have write access to
#access to dn=".*,ou=Roaming,o=morsnet"
# by dn="cn=admin,dc=ods,dc=org,dc=ods,dc=org" write
# by dnattr=owner write
13 years, 11 months
