I m using openldap-2.3.4 version with ppolicy enabled. I have a problem with the reset feature. If i set pwdReset and pwdMustChange attribute for a user, say testuser, I can see that it works as expected using ldapsearch command ie it never allows u to login & asks u to modify the password. Now for the problem: At the client side(say PHP), If i bind to the server using testuser and resetted password, i m allowed to log in..How is that possible...it should not work that way..right..It should emulate ldapsearch..am i right?
So the basic question is: Does ldap check the password restrictions(especially pwdreset,as my other restrictions like account locked etc....r getting checked) at bind time? If yes..then why the above problem...
Ahhh...imagining that irresistible "new car" smell?
Check outnew cars at Yahoo! Autos.
I banged my head on OpenLDAP -> SASL -> PAM for two days. The status of
the documentation is really horrible. Until someone eventually fix that,
here is for future reference what I had to do (the NetBSD system parts
are out of topic, but I added them for the sake of completeness)
OpenLDAP-2.3.27 from NetBSD's pkgsrc
Cyrus-SASL-2.1.22 from NetBSD's pkgsrc
1) Install the software
1.1 Fix pkgsrc a bug
change --with-spasswd into --enable-spasswd
1.2 Install the following packages:
Set build options for pkgsrc: in /etc/mk.conf:
1.3 Install the following packages:
1.4 Fix another pkgsrc bug:
make && make install
2) Configure PAM
Create /etc/pam.ldap and populate it with your PAM configuration
3) Configure SASL
3.1 Enable saslauthd, by adding this to /etc/rc.conf:
saslauthd=YES saslauthd_flags="-a pam
3.2 Then start it:
3.3 Configure the SASL library for slapd, by creating
/usr/pkg/lib/sasl2/slapd.conf, with the following content:
3.4 Check SASL functionnality
testsaslauthd -s ldap -u login -p password
Make sure a wrong password really fails...
4) Configure OpenLDAP (the nasty part)
4.1 Enable PLAIN mechanism (disabled by default) in
/usr/pkg/etc/openldap/slapd.conf, by adding:
You don't need sasl-regex or authz-regex.
4.2 Enable TLS:
Generate TLS certificate, and add certificate, key and CA to
4.3 Populate the directory, make sure that user
cn=jdoe,dc=example,dc=net has this:
4.4 Enable slapd, by adding to /etc/rc.conf:
4.5 Start slapd:
4.6 Check that slapd will accept PLAIN SASL authentication:
ldapsearch -x -b "" -s base supportedSASLMechanisms
You should get:
4.7 Configure the LDAP client, in /usr/pkg/etc/openldap/ldap.conf:
4.8 Check that the whole thing works:
ldapsearch -x -WZD cn=jdoe,dc=example,dc=net
Don't forget to make sure a wrong password fails...
NB1: saslauthd logs in /var/log/authlog, the error messages are useful
NB2: slapd logs in /var/log/slapd.conf, the error messages are usually
meaningless, especially for ACL and SASL troubles.
NB3: Make sure your DN is right. I spent a lot of time running tests
with an invalid DN (ie: dc=jdoe instead of cn=jdoe)
I am using the sample config from the Configuring Slapd section.
Here's what's inside.
# BDB definition for example.net
olcDbIndex: objectClass eq
olcAccess: to * by users read
Est Solaris Oth Mithas
OpenLDAP 2.3.32 (our policy is to run STABLE unless there's a bugfix we
Most of our sites replicate direct to each other (SyncRepl; you need to
know that data for a country is mastered in that country), except for one
A <-> B <-> C
A and C are masters for their data, and B is a pure slave. For political
reasons (i.e. it won't get fixed) A and C cannot replicate direct.
Because a schema change was not made on B, some updated data on A did not
get through. All well and good, we fix the schema on B, and wait for the
update (we use refreshAndPersist).
Except it never happened. Blowing away the slave on B caused it to
update (of course), except it still never reached C, until it in turn
Am I looking at a replication bug? It seems to me that once the schema
was fixed, the replication should have happened. Or am I not
understanding how SyncRepl works?
Dave Horsfall DTM VK2KFU daveh(a)ci.com.au Ph: +61 2 9552-5509 (d) -5500 (sw)
Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU
Please can someone help--I have setup password policy using ppolicy overlay and
account replication using slurpd.All is working except that when an account is
locked on the master openldap server, it does not get replicated to the slaves.
In other words, a locked account is denied access on the master sever but the
user can stll logon on the slaves.Any help would be really appreciated.
I am trying out an application with lots of directory modifcation with a
hdb backend. I have put in the directive "dirtyread" in the conf file
under the hdb database. I had the impression that this would enable me
to read and write to the directory at the same time. This doesn't seem
to be the case however. It seems that writes wait for all reads. Is this
correct? Is there something else I could do?
The occasional error or inconsistency is acceptable.
I have made a test package to see if people understanding openLDAP
better than I do can reproduce and possibly explain the strange behavior
I have been plagued by.
I run an application that updates a directory more or less continuously
and it runs at a reasonable speed. Often this can last for hours. Then
everything slows down drastically (by more than a factor 10) in one
instant (i e it doesn't slow down gradually). I think that slapd spends
long times in some kind of waiting state. I base this on the fact that I
can induce the behaviour regardless of which of a large number of
methods I have tried on the "client" side, i e the application updating
the directory. I have tried calling the ldap client tools from shell
scripts and using the API with perl bindings and so on. The WCHAN seem
to be the same most of the time that te application is slow.
Unfortunately I wasn't able to make any sense of this numerical
information (I'm not too familiar with kernels and such).
I have got this behaviour with different versions of openLDAP I have
tried (the newest being 2.3.32). Different Berkley db packages in the
range 4.3-4.5 didn't seem to matter. The instructions for the package
can be found at:
And the test package itself at:
It does a none intrusive set-up in order to set some paths but it
doesn't copy anything to outside its own directory. It starts an
instance of the local slapd on a non-standard port using its own
configuration and schema.
I would be very interested if anyone would try out this package and see
if they can explain the behavior (or reproduce it at all, as the case
Thanks in advance
Have a nice day.
I have to implement password policy in our OpenLdap. During testing futures
of ppolicy module I found that they ignore expired password when I authenticate
user by SASL DIGEST-MD5.
When I try on exprired account:
ldapwhoami -xD "cn=Kokos Velky,ou=TestUsers,ou=People,o=Ceske drahy,c=CZ"
the answer is: ldap_bind: Invalid credentials (49)
and in slapd log:
ppolicy_bind: Entry cn=Kokos Velky,ou=TestUsers,ou=People,o=Ceske
drahy,c=CZ has an expired password: 0 grace logins
But when I try
ldapwhoami -Y DIGEST-MD5 -U kokos1
the answer is
SASL/DIGEST-MD5 authentication started
SASL username: kokos1
SASL SSF: 128
SASL installing layers
dn:cn=kokos velky,ou=testusers,ou=people,o=ceske drahy,c=cz
Result: Success (0)
In slapd.conf I have
What I am doing wrong?
Many thanks for advice.
I have managed to setup the system with cn=config.
However, when I try to add in a new database, i get this error.
ldapadd -vx -D "cn=config" -W -f x.ldif
ldap_initialize( <DEFAULT> )
Enter LDAP Password:
to * by users read
adding new entry "olcDatabase=bdb,cn=config"
ldap_add: Invalid syntax (21)
additional info: olcSuffix: value #0 invalid per syntax
Anyone know what i did wrongly?
Thanks in Advance
Est Solaris Oth Mithas