OpenLDAP 2.4
by Howard Chu
The Admin Guide still has not been updated with all of the relevant changes,
so here are some notes on new features in the 2.4 release... I believe all of
the manpages are up to date, so you can get specifics from them.
More complete cn=config functionality:
There is a new slapd-config(5) manpage for the cn=config backend.
the original design called for auto-renaming of config entries when you
insert or delete entries with ordered names, but that was not implemented in
2.3. It is now in 2.4. This means, e.g., if you have
olcDatabase={1}bdb,cn=config
olcSuffix: dc=example,dc=com
and you want to add a new subordinate, now you can:
ldapadd olcDatabase={1}bdb,cn=config
olcSuffix: dc=foo,dc=example,dc=com
this will insert a new BDB database in slot 1 and bump all following
databases down one, so the original BDB database will now be named
olcDatabase={2}bdb,cn=config
olcSuffix: dc=example,dc=com
In 2.3 you were only able to add new schema elements, not delete or
modify existing elements. In 2.4 you can modify schema at will. (Except for
the hardcoded system schema, of course.)
More sophisticated syncrepl configurations:
the original implementation of syncrepl in OpenLDAP 2.2 was intended to
support multiple consumers within the same database, but that feature never
worked and was removed from OpenLDAP 2.3. I.e., you could only configure a
single consumer in any database.
In 2.4 you can configure multiple consumers in a single database. The
configuration possibilities here are quite complex and numerous. You can
configure consumers over arbitrary subtrees of a database (disjoint or
overlapping). Any portion of the database may in turn be provided to other
consumers using the syncprov overlay. The syncprov overlay works with any
number of consumers over a single database or over arbitrarily many glued
databases.
As a consequence of the work to support multiple consumer contexts, the
syncrepl system now supports full N-way multimaster replication with
entry-level conflict resolution. There are some important constraints, of
course: In order to maintain consistent results across all servers, you must
maintain tightly synchronized clocks across all participating servers (e.g.,
you must use NTP on all servers). The entryCSNs used for replication now
record timestamps with microsecond resolution, instead of just seconds. The
delta-syncrepl code has not been updated to support multimaster usage yet,
that will come later in the 2.4 cycle.
On a related note, syncrepl was explicitly disabled on cn=config in 2.3.
It is now fully supported in 2.4; you can use syncrepl to replicate an entire
server configuration from one server to arbitrarily many other servers. It's
possible to clone an entire running slapd using just a small (less than 10
lines) seed configuration, or you can just replicate the schema subtrees,
etc. Tests 049 and 050 in the test suite provide working examples of these
capabilities.
In 2.3 you could configure syncrepl as a full push-mode replicator by
using it in conjunction with a back-ldap pointed at the target server. But
because the back-ldap database needs to have a suffix corresponding to the
target's suffix, you could only configure one instance per slapd.
In 2.4 you can define a database to be "hidden" which means that its
suffix is ignored when checking for name collisions, and the database will
never be used to answer requests received by the frontend. Using this hidden
database feature allows you to configure multiple databases with the same
suffix, allowing you to set up multiple back-ldap instances for pushing
replication of a single database to multiple targets. There may be other uses
for hidden databases as well (e.g., using a syncrepl consumer to maintain a
*local* mirror of a database on a separate filesystem).
More extensive TLS configuration control:
In 2.3, the TLS configuration in slapd was only used by the slapd
listeners. For outbound connections used by e.g. back-ldap or syncrepl their
TLS parameters came from the system's ldap.conf file.
In 2.4 all of these sessions inherit their settings from the main slapd
configuration but settings can be individually overridden on a
per-config-item basis. This is particularly helpful if you use
certificate-based authentication and need to use a different client
certificate for different destinations.
Various performance enhancements:
Too many to list. Some notable changes - ldapadd used to be a couple of
orders of magnitude slower than "slapadd -q". It's now at worst only about
half the speed of slapadd -q. A few weeks ago I did some comparisons of all
the 2.x OpenLDAP releases; the results are in the slides from my SCALE
presentation and you can find a copy here:
http://www.highlandsun.com/hyc/scale2007.pdf
That compared 2.0.27, 2.1.30, 2.2.30, 2.3.33, and HEAD (as of a couple
weeks ago). Toward the latter end of the "Cached Search Performance" chart it
gets hard to see the difference because the runtimes are so small, but the
new code is about 25% faster than 2.3, which was about 20% faster than 2.2,
which was about 100% faster than 2.1, which was about 100% faster than 2.0,
in that particular search scenario. That test basically searched a 1.3GB DB
of 380836 entries (all in the slapd entry cache) in under 1 second. i.e., on
a 2.4GHz CPU with DDR400 ECC/Registered RAM we can search over 500 thousand
entries per second. The search was on an unindexed attribute using a filter
that would not match any entry, forcing slapd to examine every entry in the
DB, testing the filter for a match.
Essentially the slapd entry cache in back-bdb/back-hdb is so efficient
the search processing time is almost invisible; the runtime is limited only
by the memory bandwidth of the machine. (The search data rate corresponds to
about 3.5GB/sec; the memory bandwidth on the machine is only about 4GB/sec
due to ECC and register latency.)
I think it goes without saying that no other Directory Server in the world is
this fast or this efficient. Couple that with the scalability, manageability,
flexibility, and just the sheer know-how behind this software, and nothing
else is even remotely comparable.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 4 months
slapd cores
by Dmitriy Kirhlarov
Hi, list.
I'm using openldap-server-2.3.35 on FreeBSD 6.2-STABLE (Feb 19).
I have reproduceble crash of slapd on this host. But I can't reproduce
it on other server (FreeBSD 6.1-STABLE Aug 2).
Database is fine (I dump and restore it), changing thread library
doesn't help too.
Some information from core:
(gdb) bt
0x2837f537 in pthread_testcancel () from /lib/libpthread.so.2
0x2836e89a in sigaction () from /lib/libpthread.so.2
0x2836888d in pthread_kill () from /lib/libpthread.so.2
0x28368256 in raise () from /lib/libpthread.so.2
0x28442e34 in abort () from /lib/libc.so.6
0x2841f060 in __assert () from /lib/libc.so.6
0x080aad9e in entry_schema_check ()
0x286908a3 in bdb_add (op=0xcecfa0c0, rs=0xcecfa080) at add.c:63
0x080ec0b5 in overlay_init ()
0x080db272 in glue_sub_init ()
0x08080a75 in slap_req2res ()
0x080818ac in slap_send_ldap_result ()
0x08113e35 in translucent_initialize ()
0x080db309 in overlay_op_walk ()
0x080db543 in overlay_op_walk ()
0x080db650 in overlay_op_walk ()
0x0808b0c6 in fe_op_modify ()
0x0808a33e in do_modify ()
0x0806fb84 in connection_done ()
0x281b36ad in ldap_int_thread_pool_wrapper ()
from /usr/local/lib/libldap_r-2.3.so.2
0x283703a5 in pthread_create () from /lib/libpthread.so.2
0x2842e3df in _ctx_start () from /lib/libc.so.6
(gdb) info threads
6 Thread 0x818b000 (sleeping) 0x28377f9b in pthread_mutexattr_init () from /lib/libpthread.so.2
5 Thread 0x8267200 (LWP 100039) 0x2837f4f7 in pthread_testcancel () from /lib/libpthread.so.2
4 Thread 0x8267a00 (runnable) 0x2844658b in select () from /lib/libc.so.6
3 Thread 0x8267c00 (sleeping) 0x28377f9b in pthread_mutexattr_init () from /lib/libpthread.so.2
* 2 Thread 0x8267e00 (LWP 100141) 0x2837f537 in pthread_testcancel () from /lib/libpthread.so.2
1 Thread 0x8274000 (sleeping) 0x28377f9b in pthread_mutexattr_init () from /lib/libpthread.so.2
Can somebody help me?
WBR
Dmitriy
15 years, 10 months
Slapd crashing again, three different reasons?
by Daniel Henninger
Hi folk,
First off, let me say that per our last conversation about this, I
have not yet rebuild cyrus-sasl/openldap against a different Kerberos
dist. (I was going to build against 1.5.. right now I'm at 1.2.8..
we tend to steer clear of Heimdal) Anyway, on April 28th, at
12:05AM, all three of our slave servers' slapds died. All for
apparently different reasons:
First slave:
#0 0xfed592f0 in __sigprocmask () from /usr/lib/libthread.so.1
#1 0xfed4e59c in _resetsig () from /usr/lib/libthread.so.1
#2 0xfed4dd3c in _sigon () from /usr/lib/libthread.so.1
#3 0xfed50d98 in _thrp_kill () from /usr/lib/libthread.so.1
#4 0xfedcbdc4 in raise () from /usr/lib/libc.so.1
#5 0xfedb5a5c in abort () from /usr/lib/libc.so.1
#6 0xfedb5d00 in _assert () from /usr/lib/libc.so.1
#7 0xff3188b8 in ber_sockbuf_ctrl (sb=0x18d53b38, opt=1,
arg=0xd7c00e6c)
at sockbuf.c:89
#8 0x0003071c in connection_get (s=111) at connection.c:312
#9 0x00032ef8 in connection_read (s=111) at connection.c:1307
#10 0x0002f84c in slapd_daemon_task (ptr=0x14d218) at daemon.c:2353
#11 0xfed5b124 in _thread_start () from /usr/lib/libthread.so.1
#12 0xfed5b124 in _thread_start () from /usr/lib/libthread.so.1
Backtrace stopped: previous frame identical to this frame (corrupt
stack?)
Second slave:
#0 0xfee12d38 in fseek () from /usr/lib/libc.so.1
#1 0xfe343680 in krb5_ktfileint_internal_read_entry ()
from /local/kerberos/lib/libkrb5.so.3
#2 0xfe343ec8 in krb5_ktfileint_read_entry ()
from /local/kerberos/lib/libkrb5.so.3
#3 0xfe342660 in krb5_ktfile_get_entry ()
from /local/kerberos/lib/libkrb5.so.3
#4 0xfe35bc44 in krb5_rd_req_decrypt_tkt_part ()
from /local/kerberos/lib/libkrb5.so.3
#5 0xfe35bdcc in krb5_rd_req_decoded_opt ()
from /local/kerberos/lib/libkrb5.so.3
#6 0xfe35c594 in krb5_rd_req_decoded () from /local/kerberos/lib/
libkrb5.so.3
#7 0xfe35bb10 in krb5_rd_req () from /local/kerberos/lib/libkrb5.so.3
#8 0xfecd81ec in krb5_gss_accept_sec_context ()
from /local/kerberos/lib/libgssapi_krb5.so.2
#9 0xfece12c4 in gss_accept_sec_context ()
from /local/kerberos/lib/libgssapi_krb5.so.2
#10 0xfed02410 in gssapi_server_mech_step ()
from /local/lib/sasl2/libgssapiv2.so.2
#11 0xff1d95c0 in sasl_server_step () from /local/lib/libsasl2.so.2
#12 0xff1d92b4 in sasl_server_start () from /local/lib/libsasl2.so.2
#13 0x00074998 in slap_sasl_bind (op=0x516fe80, rs=0xd4c01af0) at
sasl.c:1393
#14 0x0004c4d4 in fe_op_bind (op=0x516fe80, rs=0xd4c01af0) at bind.c:276
---Type <return> to continue, or q <return> to quit---
#15 0x0004bddc in do_bind (op=0x516fe80, rs=0xd4c01af0) at bind.c:200
#16 0x00032afc in connection_operation (ctx=0x170948, arg_v=0x516fe80)
at connection.c:1132
#17 0xff33cbb4 in ldap_int_thread_pool_wrapper (xpool=0x181b08) at
tpool.c:478
#18 0xfed5b124 in _thread_start () from /usr/lib/libthread.so.1
#19 0xfed5b124 in _thread_start () from /usr/lib/libthread.so.1
Backtrace stopped: previous frame identical to this frame (corrupt
stack?)
Third slave:
#0 0xfedc1fe0 in _malloc_unlocked () from /usr/lib/libc.so.1
#1 0xfedc1db0 in malloc () from /usr/lib/libc.so.1
#2 0xff039c48 in default_malloc_ex () from /local/lib/libcrypto.so.
0.9.7
#3 0xff03a638 in CRYPTO_malloc () from /local/lib/libcrypto.so.0.9.7
#4 0xff0a52bc in EVP_DigestInit_ex () from /local/lib/libcrypto.so.
0.9.7
#5 0xff04cb90 in HMAC_Init_ex () from /local/lib/libcrypto.so.0.9.7
#6 0xff18c1dc in tls1_mac () from /local/lib/libssl.so.0.9.7
#7 0xff1877a8 in ssl3_read_bytes () from /local/lib/libssl.so.0.9.7
#8 0xff185608 in ssl3_read () from /local/lib/libssl.so.0.9.7
#9 0xff18d368 in SSL_read () from /local/lib/libssl.so.0.9.7
#10 0xff35e7f4 in sb_tls_read (sbiod=0xff8b7b0, buf=0x175d0d80, len=4)
at tls.c:589
#11 0xff319520 in sb_debug_read (sbiod=0xd02fe00, buf=0x175d0d80, len=4)
at sockbuf.c:795
#12 0xff3431e8 in sb_sasl_read (sbiod=0xfc0cd08, buf=0xccb14b3, len=8)
at cyrus.c:270
#13 0xff319520 in sb_debug_read (sbiod=0xc4f0e50, buf=0xccb14b3, len=8)
at sockbuf.c:795
#14 0xff31866c in ber_int_sb_read (sb=0xe03bc80, buf=0xccb14b3, len=8)
at sockbuf.c:409
#15 0xff3161e8 in ber_get_next (sb=0xe03bc80, len=0xd7c00ef4,
ber=0xccb14a8)
at io.c:504
#16 0x000330a8 in connection_read (s=71) at connection.c:1527
---Type <return> to continue, or q <return> to quit---
#17 0x0002f84c in slapd_daemon_task (ptr=0x14d218) at daemon.c:2353
#18 0xfed5b124 in _thread_start () from /usr/lib/libthread.so.1
#19 0xfed5b124 in _thread_start () from /usr/lib/libthread.so.1
Backtrace stopped: previous frame identical to this frame (corrupt
stack?)
Now, the second one is most likely the "recompile it against a
different Kerberos" issue. However, the last seems to be directly
SSL related and the first ... I have no idea about the first. We
have openldap built against openssl 0.9.7i.
So you might be asking yourself, what occurs at 12:05am in our
world? Nothing in particular as far as I can tell from the logs,
which is mighty odd. Also this never happens with the master server
(but then again it's not getting direct queries) The last request in
the logs seems to have been a fairly simple lookup (I X'd out the uid):
Apr 28 00:00:05 uni01ds.unity.ncsu.edu slapd[1058]: [ID 469902
local4.debug] con
n=2189346 op=115 SRCH base="ou=accounts,dc=ncsu,dc=edu" scope=2
deref=0 filter="
(&(|(objectClass=posixAccount)(objectClass=inetOrgPerson)
(objectClass=shadowAcco
unt))(|(uidNumber=XXXXX)))"
Apr 28 00:00:05 uni01ds.unity.ncsu.edu slapd[1058]: [ID 744844
local4.debug] con
n=2189346 op=115 SRCH attr=uid cn cn homeDirectory loginShell uidNumber
Looks like they really all crashed at right after midnight and were
discovered and fixed 5 minutes later.
Any suggestions? =( I know many of you are running this under
Solaris. Anyone had any particular problems doing so?
Daniel
15 years, 10 months
Problem when using 'accesslog' and 'refint' overlays in combination
by Alina Dubrovska
Hello dear list,
Please try respond to this post, because that's very important for out
project to fix described problem!
We are trying to configure access logging in my OpenLDAP server (version is
2.3.27) using slapo-accesslog overlay.
In slapd.conf I have configured accesslog database according to manual:
database bdb
suffix "cn=accesslog"
rootdn "cn=root,cn=accesslog"
rootpw accesslog
index reqStart eq
database bdb
suffix "dc=main_domain,dc=com"
checkpoint 1024 5
cachesize 10000
rootdn "cn=Administrator,dc=main_domain,dc=com"
overlay accesslog
logdb "cn=accesslog"
logops writes
logold (objectclass=person)
In previous version of slapd.conf there was also slapo-refint overlay
enabled to support 'uniqueMember' attribute update after member entry is
renamed or deleted:
overlay refint
refint_attributes uniqueMember
After turning on access logging I inspect the following problem:
I create 2 users (objectclass=person) and a group
(objectclass=groupOfUniqueNames), then I add both users to that group (add
users DN values to uniqueMember attribute). Next I'm trying to rename (or
delete) one of the member users and... LDAP hangs up with no response. When
I connect once again, then I see that action was performed (user is renamed
or deleted, but old member reference is present in group attributes).
However, I'm not able to modify directory (that is add some new entry,
modify attribute value etc) LDAP hangs up on any attempt and only OpenLDAP
restart helps.
Last note is that this problem appears only when both accesslog and refint
are enabled. Separately they are working as expected.
Does anybody have an idea about the reason of such a problem?
We tried to find some useful information in logs, but nothing is there
(maybe we just looked in wrong place)
Maybe it's possbile to configure access-log to use database on different
LDAP server? Maybe that could help?
Please help! We need to have this working together!
Thanks in advance,
Alina.
15 years, 10 months
Syncrepl-Consumer deletes entries
by Joachim Hergeth
Hello list,
I have an OpenLDAP provider/consumer installation on two SLES10 systems.
One is set up as a provider LDAP, the second is a consumer LDAP using
"refreshOnly" synrepl synchronization. The LDAP provides user
information for a Samba installation.
The initial synchronization of the consumer works as expected. All LDAP
entries are copied to the consumer directory. But after some time,
usually when users log in into the Samba running with the provider LDAP,
nearly 50% of all LDAP entries on the consumer are deleted. This happens
without any change on the provider LDAP!
Checking the logs I found, that delete-messages can be found in the
consumers system log.
I do not understand the source of the problem. No entries in the
provider LDAP are deleted, so no entries should be deleted in the consumer.
To check the installation, I set up a second consumer in a VMWare
environment. And also in this system, which had been set up from scratch
and only holds the OpenLDAP-consumer, the entries are deleted at the
same time when they are deleted in the "real" OpenLDAP consumer system.
When I change an attribute of an entry in the provider LDAP which has
been deleted from the consumer by this process, like adding a
description, this change is forwarded to th consumer and the entry
"reappears" in the LDAP of the consumer.
Any help or suggestion is appreciated.
Thanks in advance
Joachim Hergeth
The providers slapd.conf is:
#
# 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/rfc2307bis.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/yast.schema
include /etc/openldap/schema/samba3.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 /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
# Load dynamic backend modules:
modulepath /usr/lib/openldap/modules
# moduleload back_ldap.la
# moduleload back_meta.la
# moduleload back_monitor.la
# moduleload back_perl.la
# 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 to user password
# Allow anonymous users to authenticate
# Allow read access to everything else
# Directives needed to implement policy:
## Yast2 samba hack ACL
## allow the "ldap admin dn" access, but deny everyone else
access to attrs=SambaLMPassword,SambaNTPassword
by dn="cn=Administrator,dc=master-ldap,dc=gts-systems.de" write
by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write
by * none
## Yast2 samba hack ACL done
access to dn.base=""
by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write
by self write
by * auth
access to dn.base="cn=Subschema"
by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write
by * read
access to attrs=userPassword,userPKCS12
by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write
by self write
by * auth
access to attrs=shadowLastChange
by self write
by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write
by * read
access to *
by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write
by * 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!
#######################################################################
# BDB database definitions
#######################################################################
schemacheck on
idletimeout 30
loglevel 131
backend bdb
database bdb
suffix "dc=master-ldap,dc=gts-systems.de"
rootdn "cn=Administrator,dc=master-ldap,dc=gts-systems.de"
rootpw <some working password>
directory /var/lib/ldap/
checkpoint 1024 5
cachesize 10000
index objectClass,entryCSN,entryUUID,uidNumber,gidNumber eq
index member,mail eq,pres
index cn,displayname,uid,sn,givenname sub,eq,pres
index memberUID eq
index sambaSID eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq
index default sub
overlay syncprov
syncprov-checkpoint 100 1
syncprov-sessionlog 1
---------------------------------------------------------------------------
the consumers slapd.conf is:
#
# 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/rfc2307bis.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/samba3.schema
include /etc/openldap/schema/yast.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 /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
# Load dynamic backend modules:
modulepath /usr/lib/openldap/modules
# moduleload back_ldap.la
# moduleload back_meta.la
# moduleload back_monitor.la
# moduleload back_perl.la
# 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 to user password
# Allow anonymous users to authenticate
# Allow read access to everything else
# Directives needed to implement policy:
access to dn.base=""
by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write
by self write
by * auth
access to dn.base="cn=Subschema"
by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write
by * read
access to attrs=userPassword,userPKCS12
by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write
by self write
by * auth
access to attrs=shadowLastChange
by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write
by self write
by * read
access to *
by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write
# by anonymous auth
by * read
# 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!
#######################################################################
# BDB database definitions
#######################################################################
schemackeck on
idletimeout 30
loglevel 15288
# TLSCertificateFile /etc/ssl/servercerts/servercert.pem
# TLSCACertificatePath /etc/ssl/certs/
# TLSCertificateKeyFile /etc/ssl/servercerts/serverkey.pem
database bdb
suffix "dc=master-ldap,dc=gts-systems.de"
rootdn "cn=Administrator,dc=master-ldap,dc=gts-systems.de"
rootpw "<some working password>"
directory /var/lib/ldap
checkpoint 1024 5
cachesize 10000
index objectClass,uidNumber,gidNumber,entryCSN,entryUUID eq
index member,mail eq,pres
index cn,displayname,uid,sn,givenname sub,eq,pres
index memberUID eq
index sambaSID eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq
index default sub
syncrepl rid=321
provider=ldap://192.168.1.210:389
type=refreshOnly
interval=00:00:00:30
searchbase="dc=master-ldap,dc=gts-systems.de"
scope=sub
schemachecking=off
bindmethod=simple
binddn="cn=repladmin,dc=master-ldap,dc=gts-systems.de"
credentials=<another nice password>
---------------------------------------------------------------------------
15 years, 10 months
ppolicy, is a password reset the only way to unlock an account?
by Sam Tran
Hi All,
I am currently testing slapo-ppolicy in OL 2.3.35.
I have the following ppolicy:
pwdFailureCountInterval: 0
pwdGraceAuthNLimit: 0
pwdInHistory: 0
pwdLockout: TRUE
pwdLockoutDuration: 0
pwdMaxFailure: 3
pwdMustChange: FALSE
pwdSafeModify: FALSE
My question is the following:
Let's say I lock my account after 3 unsuccessful binds. Is a password
reset the only way to unlock it?
Thanks,
Sam
15 years, 10 months
LDAP Reference Works?
by Yang Sun
Hi,
I am new to LDAP world. And I am trying to design a distribute data structure for storing the user information in our project. I am not sure whether using ldap reference is the right way to do this job. Please give me some suggestion. The detailed situation is:
We manage tens of sites. And the sites are orgnized in a tree structure. The requirement is to store the information in the local site (means no central place to store the information for all the sites). It will give the system the maximum flexiblity to expand and when the site is isolated the local site still works well. Sometimes, the local site will need information stored in other sites.
I think it is a distribute database architecture. And it reminds me to use the LDAP reference function. So each local site will have a reference to its parent site and some references to its child sites. It gives a logical view of the tree with information for all the sites. I am not sure whether it is possible to do that and whether it has some difficulties to implement it using OpenLDAP.
Any suggestion?
Thanks,
Yang Sun
15 years, 10 months
rewriting compare ava with overlay rwm
by Jens Grigel
Hi,
we're using openldap 2.3.35 as ldap proxy to support anonymous binds and
searches to a restricted ldap server.
We're now trying to rewrite existing cn's with old suffix to new cn's
with new suffix of the restricted ldap server.
So far almost everything is working with rwm-suffixmassage and overlay
rwm except rewriting AVA's from ldapcompare.
I'm still not sure if this is actually possible with overlay rwm or if
i'm misunderstanding the manpage of slapo-rwm.
Rewriting the cn's in searches, searchresults, bindDN and compareDN
works, but the AVA from the compared
attribute (here: cn) is not changed from rewriteContext compareAttrDN.
"man slapo-rwm" says that the rewriteContext compareAttrDN rewrites
compare AVA, but whatever i try it's not
changing anything in the ldapcompare.
What format of the rwm-rewriteRules for rewriteContext compareAttrDN is
expected for rewriting to succeed?
Or is this actually impossible what i'm thinking of?
Here my shortened (removed a lot of rewriteRules, but still working)
slapd.conf:
# slapd.conf
loglevel -1
include /usr/local/etc/openldap/schema/core.schema
pidfile /usr/local/var/run/slapd.pid
argsfile /usr/local/var/run/slapd.args
modulepath /usr/local/libexec/openldap
moduleload rwm.la
overlay rwm
rwm-suffixmassage "o=sskm"
"ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern"
database ldap
suffix "ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern"
uri "ldap://5.1.35.254/"
network-timeout 3
chase-referrals no
idassert-bind bindmethod=simple
binddn="cn=q001ldap,ou=dienstkonten,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" credentials="secret" mode=none
idassert-authzFrom "dn.regex:.*"
overlay rwm
rwm-rewriteEngine on
rwm-rewriteContext searchFilter
rwm-rewriteRule "cn=99([0-9]{3})" "cn=s001x$1" ":@"
rwm-rewriteContext bindDN
rwm-rewriteRule "cn=99([0-9]{3}),(.+)" "cn=s001x$1,$2" ":@"
rwm-rewriteContext searchEntryDN
rwm-rewriteRule "cn=s001x([0-9]{3}),(.+)" "cn=99$1,$2" ":@"
rwm-rewriteContext compareDN
rwm-rewriteRule "cn=99([0-9]{3}),(.+)" "cn=s001x$1,$2" ":@"
rwm-rewriteContext compareAttrDN
rwm-rewriteRule "99([0-9]{3})" "s001x$1"
# end slapd.conf
The basic idea from this simple setup is to rewrite a cn=99854 to
cn=s001x854 and back whereever possible.
I'm trying with
ldapcompare -x -D "" -H ldap://testproxy cn=99854,o=sskm cn:99854
this fails and produces the following logs
slapd[9789]: do_compare
slapd[9789]: >>> dnPrettyNormal: <cn=99854,o=sskm>
slapd[9789]: <<< dnPrettyNormal: <cn=99854,o=sskm>, <cn=99854,o=sskm>
slapd[9789]: [rw] compareDN: "cn=99854,o=sskm" ->
"cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern"
slapd[9789]: >>> dnPrettyNormal:
<cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern>
slapd[9789]: <<< dnPrettyNormal:
<cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern>, <cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern>
slapd[9789]: do_compare: dn
(cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern) attr (cn) value (99854)
slapd[9789]: conn=1 op=1 CMP
dn="cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" attr="cn"
slapd[9789]: [rw] compareDN:
"cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" -> "cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern"
slapd[9789]: >>> dnPrettyNormal:
<cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern>
slapd[9789]: <<< dnPrettyNormal:
<cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern>, <cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern>
slapd[9789]: send_ldap_result: conn=1 op=1 p=3
slapd[9789]: send_ldap_result: err=5 matched="" text=""
packet capturing shows that the value is not rewritten when sent to the
ldap server.
Using the value which i was trying to rewrite to
ldapcompare -x -D "" -H ldap://testproxy cn=99854,o=sskm cn:s001x854
succeeds
slapd[9789]: do_compare
slapd[9789]: >>> dnPrettyNormal: <cn=99854,o=sskm>
slapd[9789]: <<< dnPrettyNormal: <cn=99854,o=sskm>, <cn=99854,o=sskm>
slapd[9789]: [rw] compareDN: "cn=99854,o=sskm" ->
"cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern"
slapd[9789]: >>> dnPrettyNormal:
<cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern>
slapd[9789]: <<< dnPrettyNormal:
<cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern>, <cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern>
slapd[9789]: do_compare: dn
(cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern) attr (cn) value (s001x854)
slapd[9789]: conn=10 op=1 CMP
dn="cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" attr="cn"
slapd[9789]: [rw] compareDN:
"cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" -> "cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern"
slapd[9789]: >>> dnPrettyNormal:
<cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern>
slapd[9789]: <<< dnPrettyNormal:
<cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern>, <cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern>
slapd[9789]: send_ldap_result: conn=10 op=1 p=3
slapd[9789]: send_ldap_result: err=6 matched="" text=""
--
Jens Grigel
Citysavingsbank Munich, Germany
Dept. of Network/Security
15 years, 10 months
Replication on RDBMS level?
by Martin Cizek
Hi all,
is it safe to use several slapd servers with slapd-sql backend
connected to a replicated database? Are there any drawbacks of using
RDBMS-level replication in comparison to slurpd?
Thank you,
Martin
15 years, 11 months
How long should replication take?
by Norman Gaywood
I have a server and slave setup with syncrepl, openldap 2.3.34
Here is my syncrepl stanza on the slave:
syncrepl rid=1
provider=ldap://ldap1.sample.edu.au:389
starttls=yes
type=refreshAndPersist
interval=00:00:01:00
retry=1,2,3,4,5,+
searchbase="dc=sample,dc=edu,dc=au"
filter="(objectClass=*)"
scope=sub
attrs="*"
schemachecking=off
updatedn "cn=Replica,dc=sample,dc=edu,dc=au"
bindmethod=simple
binddn="cn=SyncUser,dc=sample,dc=edu,dc=au"
credentials="secret"
If I do only a few updates, the sync seems quite fast.
If I run a script to make about 60,000 modifications on the master, this
takes about 20 minutes to run. The slave starts updating immediately,
however it soon falls behind. It takes over an hour, since the last change
to the master, for the slave to be in sync.
Is this expected behaviour?
--
Norman Gaywood, Systems Administrator
University of New England, Armidale, NSW 2351, Australia
Please avoid sending me Word or Power Point attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
15 years, 11 months
