The current password policy module can lock folks out after some
configurable number of failed attempts. The module currently does not
differentiate between a user failing with the same wrong password a
bunch of times versus a crack attempt where someone tries multiple
different wrong passwords. Are there any modules that take into
account if the same password is being used a bunch of times or if
multiple different passwords are failing? Could this be a useful
feature worth requesting (if it doesn't exist already)?
I'm currently doing a review to see how OpenLDAP compares, *feature
wise* ATM, to other directory servers and specifically to the Sun DS -
i.e. to get a definitive list of features it's missing that Sun has and
what it has that Sun doesn't have, etc. For brevity, I haven't included
all the potentially useful features of OpenLDAP, but have just focused
on those associated with 1) RFC compliance (of which Sun may or may not
meet) and 2) features to match the Sun DS (which it would be replacing).
So far, here's what I have for OpenLDAP:
RFC 4510 (which includes 4511-4519). There was recent discussion on the
list around this, such that in some cases, not everything that changed
from 3377 (which includes 2251-2256, 2829, and 2830) to 4510 has been
updated in OpenLDAP, but I think those issues are fairly minor.
The following additional RFC's are supported in OpenLDAP:
- RFC 2247 and RFC 3088
- RFC 2696 simple paged results
- RFC 2849 ldif
- RFC 3062 password mod op
- RFC 3296 named referals, manageDSAit
- RFC 3673 All Op attrs + feature
- RFC 3687 Component matching rules
- RFC 3866 Languange tag and range
- RFC 3876 matched values control
- RFC 4370 proxy auth
- RFC 4522 binary encoding
- RFC 4523 x.509 cert schema
- RFC 4524 COSINE schema
- RFC 4525 Mod-increment
- RFC 4526 Absolute true/false filters
- RFC 4527 pre/post read control
- RFC 4528 assertion control
- RFC 4529 request attrs by objectclass
- RFC 4530 entryUUID
- RFC 4532 whoamI
- RFC 4533 Content Sync op (replication)
RFC's NOT supported are:
- RFC 2589 dds Seems with 2.4, this has gone from experimental to
- RFC 2891 server side sorting
- RFC 3671 collective attributes
- RFC 3928 LCUP mainly for updating cached addressbooks, etc - not
replication between servers
- RFC 3384 looks like just reqs for replication, not an actual
replication protocol - RFC 4533 is used instead
- RFC 3672 (subentries)
- RFC 3698 and 3727 (additional matching rules)
- RFC 3909 LDAP Cancel operation
- RFC 5020 entryDN operational attribute
(There are some other, often obscure, LDAP related RFC's that I didn't
include, but this seems to be the major/useful ones)
Other features not supported:
- VLV browse indexes (per
http://tools.ietf.org/html/draft-ietf-ldapext-ldapv3-vlv-09). Not an
RFC, but supported by Sun and MS directories, and used by things like
Outlook and Solaris.
Other supported features:
- dyngroup/dynlist/memberof overlay (A much more useful feature than
Sun's groupOfURLs "dynamic" group and "roles" mechanism)
- ppolicy overlay (matches Sun DS 5.x reasonably close, but is account
lockout replicated to all servers? Sun DS 6.x claims to)
- refint overlay (similar to Sun's referential integrity plugin)
- unique overlay (similar to Sun's uniqueness plugin)
- audit and accesslog overlays, syslog logging - much more
useful/complete than Sun's access/audit/error logs.
- live acl changes via LDAP
- Per user resource limits (sizelimit, timelimit, idletimeout, etc). I
think Howard Chu said OpenLDAP has some of this, but I haven't seen any
reference to it or how to use it in the docs (does this functionality
exist, and if so, is there any documentation?)
- Tracking of last login (i.e. last successful ldap authentication)
Is this still fairly accurate?
The ones that are really problematic are the lack of:
- VLV Browse indexes
- RFC 2891 (server side sorting)
- per user/entry resources limits (if they don't exist)
Are there any unofficial updates/patches/overlays/plans for any of this
Since a recent upgrade 2.4.12 -> 2.4.13, I'm facing recurrent slapd hanging.
On client side, ldapsearch requests receive this error:
error.c:272: ldap_parse_result: Assertion `r != ((void
I'd expect in this case an automatic switch to slave server, but it
doesn't work. Here is my ldap libraries configuration:
URI ldap://ldap1.msr-inria.inria.fr ldap://ldap2.msr-inria.inria.fr
On server side, slapd usually shows eating 100, 200 or 300% cpu, which
make me think some specific repeated query trigger the issue, making the
problem worse when several of them accumulates.
strace on running slapd process shows it's waiting on a futex:
[root@etoile main]# strace -p 2769
Process 2769 attached - interrupt to quit
futex(0xb6bb4bd8, FUTEX_WAIT, 2774, NULL <unfinished ...>
And gdb shows it waiting in __kernel_vsyscall
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d385c6 in pthread_join () from /lib/i686/libpthread.so.0
#2 0xb7f23d3f in ldap_pvt_thread_join () from /usr/lib/libldap_r-2.4.so.2
#3 0x0806e1b4 in slapd_daemon ()
#4 0x0805a507 in main ()
In both case, I think the lack of relevant information is caused by the
multithreading nature of slapd, I don't know how to access the exact
thread where the problem occurs.
I already tried to regenerate indexes, without results. I dropped the
base, and reconstructed it from latest backup, it made the problem
temporarily disapear. I didn't found anything in the logs, even with
debug level set to 'trace'.
I'm using a bdb backend, with this configuration in slapd.conf:
checkpoint 256 5
And this one in DB_CONFIG:
set_cachesize 0 1048576 0
The full slapd.conf is accessible at http://pastebin.mandriva.com/5801
db_stat -m output is accessible at http://pastebin.mandriva.com/5799
The main database itself is quite small, the ldiff backup is 1.4 only. I
also have a log database for syncrepl purpose.
I'm using openldap 2.4.13, with db 4.6.21, on mandriva linux 2008.1, 32
bits system. I'd be happy to provide additional informations if needed.
Service des Moyens Informatiques
INRIA Saclay - Île-de-France
Parc Orsay Université, 4 rue J. Monod
91893 Orsay Cedex France
Tel: 01 69 35 69 62
I am running OpenLDAP 2.3.39 (locally built) on Red Hat Enterprise Linux
4 servers with several replicas. We use delta-syncrepl to keep the
replicas in sync with the master server.
We also use nagios and monitor the contextcsn value on the replica and
alert if it gets too far out of sync with the master server.
The issue we have now experienced a few times is that if there are a LOT
of updates in the nightly batch update process, that not all of the
updates make it to the replicas but the contextcsn stays in sync, so we
see strange errors that eventually lead us to see that the replicas are
not current even though they think they are.
Is this a known issue? I haven't found a syslog entry on the server or
the replicas that makes me think it is the flag of the root cause.
I have downloaded and built the 2.3.43 release, having installed it on
one replica. That replica is just as out of date this morning as the
others -- so, if there was a solution between 2.3.39 and 2.3.43 -- it
must have been on the provider side not the consumer side.
Thanks for any insight.
Frank Swasey | http://www.uvm.edu/~fcs
Sr Systems Administrator | Always remember: You are UNIQUE,
University of Vermont | just like everyone else.
"I am not young enough to know everything." - Oscar Wilde (1854-1900)
I'm a bit new to the openldap package - my experience really dates back
to the X500 QUIPU days in the early 90's so while I understand the
priciples, it's the details of the software package that are something
of a mystery.
We're implementing LDAP for a variety of applications and we're going to
use boolean attributes in the schema to determine whether a service
should be enabled or disabled for a particular user.
So, for example, we have an attribute of "kdiremail" which is true if
the user is allowed to use the email service and false if their not.
This works well with tools like dovecot because we can set up the search
filter to only authenticate users who have that attribute set to true.
However, some applications are born into an Active Directory world where
such things seem to be unknown.
I'm battling the Blackboard WebCT Vista product which allows me to
specify attributes to look up for the username, but does not allow me to
specifically define the search filter.
My plan is to use the rewrite/remap overlay to create a fake hierarchy
within our exisiting DIT where the search filter values are re-written
to include a check to see if kdirvle is true. So then any searches on
that DN will only return users who are allowed to use the VLE, I can
then point our WebCT service to that basedn.
I think this overlay will do the job I want, but I can see that there
are many overlays in the openldap package and I wanted to check with
someone more experienced that I am that the rewrite/remap overlay is the
right choice for this kind of job.
I have the following in my slapd.conf:
access to dn.subtree="cn=log"
by group/groupOfNames/Member="cn=ldap-admins,ou=Group,dc=soe,dc=ucsc,dc=edu" read
However, anyone (even unbound anonymous users) can access cn=log without any problems. I don't want anyone but ldap-admins to be able to access this subtree.
I'm thinking that I must be missing something really simple here. Am I doing something wrong? Any help is greatly appreciated.
UC Santa Cruz
I use the ppolicy overlay and it works fine for all the features I've
tested but one:
I've added the ppolicy_use_lockout parameter in my slapd.conf, but I
still get the err=49
invalid credentials error message after 5 unsuccessfull authentification
attempts (a few
seconds elapse between each attempt)
I operate slapd 2.4.13 over OpenSuse 10.2
I can for example expire passwords, reset them or use the password
but I can't figure out how to get an "account locked" message instead of
when a user fails to log in more than 5 times.
I've tested with different ldapsearch versions as well as with Apache
LDAP Studio which seems
to use at least some LDAP controls, so I don't think it's a client side
I've tried to set "ppolicy_use_lockout" to 1 or true or on as well as
let it without value, but it's
doesn't change anything, excepted that unauthorized values prevent slapd
Here's what I see in "-d -1 mode"
<= acl_access_allowed: granted to database root
bdb_modify_internal: replace pwdAccountLockedTime
bdb_modify_internal: add pwdFailureTime
bdb_modify_internal: 20 modify/add: pwdFailureTime: value #0 already exists
bdb_modify: modify failed (20)
send_ldap_result: conn=7 op=0 p=3
send_ldap_result: err=20 matched="" text="modify/add: pwdFailureTime:
value #0 already exists"
send_ldap_response: msgid=1 tag=97 err=49
ber_flush2: 14 bytes to sd 25
0000: 30 0c 02 01 01 61 07 0a 01 31 04 00 04 00 0....a...1....
ldap_write: want=14, written=14
0000: 30 0c 02 01 01 61 07 0a 01 31 04 00 04 00 0....a...1....
conn=7 op=0 RESULT tag=97 err=49 text=
daemon: activity on:
My config is as follows:
And my policy is as follows:
Any clue ?
I just set up an OpenLDAP server on Centos5.2 and have some questions.
and find there home dirs, I have a problem were if I add a new
and try to ldapmodify using a foo.ldif file with thos attributes, I get;
additional info: attribute 'mail' not allowed
Is this because I need more schemas?
My current setup supports these attributes;
The schemas loaded in my slapd file are;
I'm obviously very very shamefully new to OpenLDAP.
My O'Reilly book lists those attributes as standard so I am at a loss.
--On Friday, January 30, 2009 3:17 PM -0700 Serge Dubrouski
> On Fri, Jan 30, 2009 at 2:55 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>
>> --On Friday, January 30, 2009 1:55 PM -0500 Francis Swasey
>> <Frank.Swasey(a)uvm.edu> wrote:
>>> Yes, one of my co-workers calls reloading a fresh dump from the master:
>>> "nuke and repave" -- and (sadly) we're getting good at it. Which
>>> brings up another question. Back in the days of slurpd, we could force
>>> a replica to accept a change by using the correct DN to send the change
>>> it had missed. Is there any way to do something similar using syncrepl
>>> (or delta-syncrepl)? I think the answer is no -- but as long as I'm
>>> making a nuisance of myself, I figure I might as well ask.
>> I'd think you could use the -c option to slapd to give the replica a
>> really old cookie and force it to fall back to doing a fully syncrepl
>> refresh, but that's going to take a lot lot longer than slapcat/slapadd.
> Do you really have to use slapcat/slapadd? Can't you just use a backup
> copy of the database from the master service? I mean one created with
Keep replies on the list.
It depends, if the architecture is the same on all of them, you could shut
down the master, run db_recover to force all the checkpoints out, and then
copy the DB & its log files over, yes. I've done that before. But what's
guaranteed to be portable is slapcat/slapadd, so that's why I reference it.
Principal Software Engineer
Zimbra :: the leader in open source messaging and collaboration