I don't want to sound too alarmistic, but it seems that the LTB project has
disappeared from the 'net sometime this week. Would you happen to know what
happened, what's going on (and perhaps if some help with the infrastructure
I've been relying on project-ltb packages for a while and would be quite
unhappy to see it go; and I find the lack of information and the abrupt
disappearance a bit troubling.
While I know it's not strictly on-topic here, I know also that OpenLdap
Toolbox folks are subscribed to this list, and ltb-project.org packages are
quite widely used here – so I hope someone would be able to provide a bit
– Miroslaw Baran
» miroslaw baran » chaos monkey • pope • general nuisance » 0101010
Down with categorical imperative!
Can anybody explain when openLDAP with bdb succeeds on a filter like (reqStart>=X) on accesslog?
When I use "(reqStart>=2014080100)" I get "no match", but when I use "(reqStart>=20140801000)" I get the expected matches.
(And I don't get any match when just using "reqStart>=20140801)")
I see no log messages on the server's syslog...
It looks like the password policy overlay will do exactly what I need it
to I just can't get it to work.
I have applied the overlay my directory.
I have a default policy set that has:
pwdAttribute set to userPassword
pwdMustChange set to TRUE.
However when I change a user's password either with an ldapmodify or the
ldappassword command that user is still able to bind to the directory
just fine. I was assuming that a bind attempt would return an error
saying that the user had to change their password or is this not the
Also I have tried adding pwdReset = TRUE to my user's object but it
complains the pwdReset is not allowed in the schema. Is there a specific
objectclass that I have to add to my user entries?
I have also tried creating a schema with pwdReset and pwdPolicySubentry
but when I add that schema it complains that these are operational
I have upped the logging and when I user tries to bind I see:
Aug 3 08:57:08 devauth slapd: conn=1017 fd=17 ACCEPT from
Aug 3 08:57:08 devauth slapd: conn=1017 op=0 BIND
Aug 3 08:57:08 devauth slapd: => bdb_entry_get: found entry:
Aug 3 08:57:08 devauth slapd: => bdb_entry_get: found entry:
Aug 3 08:57:08 devauth slapd: => access_allowed: result not in
Aug 3 08:57:08 devauth slapd: => access_allowed: auth access to
Aug 3 08:57:08 devauth slapd: => acl_get:  attr userPassword
Aug 3 08:57:08 devauth slapd: => acl_mask: access to entry
Aug 3 08:57:08 devauth slapd: => acl_mask: to value by "", (=0)
Aug 3 08:57:08 devauth slapd: <= check a_dn_pat: self
Aug 3 08:57:08 devauth slapd: <= check a_dn_pat: *
Aug 3 08:57:08 devauth slapd: <= acl_mask:  applying
Aug 3 08:57:08 devauth slapd: <= acl_mask:  mask: auth(=xd)
Aug 3 08:57:08 devauth slapd: => slap_access_allowed: auth
access granted by auth(=xd)
Aug 3 08:57:08 devauth slapd: => access_allowed: auth access
granted by auth(=xd)
Aug 3 08:57:08 devauth slapd: conn=1017 op=0 BIND
So it looks to me like the default policy has been applied but nothing
happens when a password is reset by an administrator.
So I think I am missing something fundamental here. I have a few
questions that I think will help me to narrow down my problem though.
1) What is the best way to debug an overlay?
2) Is there a proper way for an administrator to change a password so
that the pwdReset flag is set on the user (or whatever is supposed to
happen so that the user needs to reset their password on their next bind)
3) Is it enough to have a password policy with just pwdAttribute and
pwdMustChange set or are there other values that need to be set to make
4) Are there any extra object classes that have to added to my user
entries for the password policies to work?
5) I would like users to have to reset their password on first bind do
I need to set something on object creation?
6) Anything else I might be missing?
Any help would be awesome.
Canadian Bank Note Co. Ltd.
I have a replication topology with providers running with MMR and a layer of
- spread across three data centers
- in two different countries (DE and foreign country)
Network traffic between the countries has higher latency so consumers are only
accessing providers within the same country.
Write operations go nearly 100% to a single provider in Germany.
All systems are using these overlays:
- slapo-ppolicy (mostly for password expiry)
- slapo-lastbind overlays
- slapo-accesslog (yes, also on consumers)
Now occasionally contextCSN values differ most times for a couple of minutes on
the consumers in the foreign country from their local providers.
I cannot tell exactly which conditions are causing this. But I observed that
most times there was a login failure on the provider in Germany which results
in 'pwdChangedTime' being set and replicated to the consumers. Most times
followed by 'authTimestamp' being correctly set.
So I wonder whether the differences of the contextCSN values could be caused by
'pwdChangedTime' and 'authTimestamp' being replicated to providers but not to
Any clue? Thanks in advance.
I have an experiment, that may have too many moving parts to tease apart.
We're exploring migrating our LDAP server from a 32-bit OS to a 64-bit OS,
and I've also explored the port to the mdb back end. My first shot at this
does not show the performance the write-ups on MDB would have me expect.
If it matters, my old environment is a Dell R610 server, with 6G of RAM.
# uname -r
# cat /etc/redhat-release
CentOS release 5.8 (Final)
# rpm -qf `which slapd`
My ldapsearch invocations on this host take ~120 seconds.
I set up two Dell R610s, each with 12G or memory.
One environment uses the RPM produced by the LTB project, here named 'ltb':
root@ltb# uname -r
root@ltb# cat /etc/redhat-release
CentOS release 6.5 (Final)
root@ltb# rpm -qf /usr/local/openldap/libexec/slapd
And the other uses the same OS, but uses CentOS's stock OpenLDAP
RPM; here named 'stock':
root@stock# rpm -qf `which slapd`
I migrated a database of ~360k DNs, and underwent the cache tuning,
following the suggestions here:
And with those tunings, my ldapsearch command does outperform our old 32-but
stock# time ldapsearch -x -w XXXXX -D "cn=manager,orgid=MyOrgID" -b orgid=MyOrgID dn | grep ^dn: | wc -l
However, my efforts to use the MDB backend yield slower responses, on the
order of 175 seconds.
How I set up the MDB backend:
I copied my old slapd.conf over, and replaced my bdb backend with mdb
- I set 'tool-threads' to 2
- I set 'maxsize' to 21474836480 [ 20G = 20 * ( 1024 * 1024 * 1024 ) ]
ltb# /usr/local/openldap/sbin/slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d
config file testing succeeded
ltb# chown -R ldap:ldap /etc/openldap/slapd.d
I was apparently able to import all 360k DNs without an error:
ltb# time setuidgid ldap /usr/local/openldap/sbin/slapadd \
-q -v -F /etc/openldap/slapd.d -b orgId=MyOrgID \
-l export_from_OLD.ldif >& log; echo $?
ltb# ls -ld data.mdb
-rw------- 1 ldap ldap 21474836480 Jul 30 20:16 data.mdb
ltb# du -c -h data.mdb
But, the same search looks worse here.
ltb# time ldapsearch -x -w XXXXX -D "cn=manager,orgid=MyOrgID" -b orgid=MyOrgID dn | grep ^dn: | wc -l
Both 64-bit hosts show no swapping, and minimal CPU load. Can
anyone point out what I've missed?
Brian Reichert <reichert(a)numachi.com>
BSD admin/developer at large
We are currently assessing changing our TLS Certificate setup.
We have been using a self-signed CA to issue certificates for our
OpenLDAP setup, which has required us to supply the CA to anyone outside
our organisation that wishes to use our OpenLDAP over TLS or SSL.
We're currently starting to migrate our certificates to AusCERT, as we
get a good deal as a University. As AusCERT is an intermediate CA, so
we need to use a chain to get this to work.
The server side works, as per the documentation, by adding the
intermediate CA with the root CA in the olcTLSCertificateCAFile.
This means that we need to install the intermediate certificate on
clients that connect to our LDAP using SSL or TLS. Admittedly this
isn't vastly different to what we need to do now in supplying our own CA.
Looking at our Linux clients in particular, we need to add an
appropriate TLS_CACERT directive to our openldap/ldap.conf. Is the
intention, then, to point the client at the appropriate CA files? Is
there a reason that OpenLDAP doesn't use the regular system CA store? Is
there any reason for us not to point to the CA store that's already
University of New England
Armidale NSW 2351
p: 02 6773 4098
Since both the password-hash and password-crypt-salt-format are Global options, is it possible to specify the password-hash on a per BDB backend basis?
For example, I have 4 BDB backends and I'd like them all to have the CRYPT and salt listed below sans one BDB backend where it needs to be CLEARTEXT.
However, when I specify this configuration in sladp.conf and bounce slapd I get the following error when trying to change a users password with the ldappasswd command. It's worth nothing that an ldapmodify to the userPassword attribute works just fine. I use security ssf=256, which is a Global option as well on a per BDB backend basis and this works just fine so I assumed this config for hashes would work as well.
"Result: Constraint violation (19)
Additional info: Password policy only allows one password value"
Relevant config below:
## GLOBAL SETTING
### BDB DATABASE SETTING
[First of all, sorry if this question has already been answered before: the
search on this mailing list does not work currently so I haven't been able
I need to write a filter so that when the user of my software introduces
any substring of the content of a field in any case (upper, lower or mixed
case), it finds the entry. It must work even if the user does not input a
complete word, but just a part of a word.
The field is called "supName" and it follows the DirectoryString syntax.
This means that the default matching rule is exact and case sensitive
("caseExactMatch"). But according to:
, this syntax should allow also "caseIgnoreMatch" and
"caseIgnoreSubstringsMatch" matching rules. I though I just needed to force
to use the last one ("caseIgnoreSubstringsMatch"), so I tried this filter:
But this does not work. I make my tests using Apache Directory Studio, and
that tool refuses to accept the above filter. It complains on the
asterisks, and I don't understand why, since I am using a Substring match
(and thus asterisks should be allowed). If I run the filter from command
line (using ldapsearch), I get this error message:
ldap_search_ext: Bad search filter (-7)
Therefore this is not an issue with Apache Directory Studio.
So my question is: What is the correct way of defining a case-insensitive
substring filter on a field that is case-sensitive by default?
Yesterday I filled a question in StackOverflow regarding this same issue.
There are more details and examples in that question:
Any help would be greatly appreciated !
Thank you very much.
I don't know if this is the best place to ask this question, but it is
probably as good as any to start.
I am a new user of OpenLDAP. I formerly, and still do use the MS Outlook
address book to store my contacts. I can duplicate most of the features of
the MS Address book, except the ability to create distribution lists. I just
cannot figure out how to accomplish this feat.
Using MS Outlook, or Claws-Mail on my FreeBSD machine, I can type in a
distribution name and all of the email addresses are filled in.
distribution list name=my-list
Some of these distribution lists are quite large.
I cannot fine out a way to create a similar list in OpenLDAP, which is a
serious buzz, not to mention deal killer in this instance.