I am seeing slapd crashing repeatedly when assigning empty password to a
user account. The version is 2.3.39. Is this a known problem?
Or another question is how do we disable a user account with OpenLDAP?
I'm trying to replicate (with syncrepl) the bdb database generated by the
accesslog overlay. This is with 2.3.41 on both provider and consumer. slapd
do_syncrep2: rid 002 got empty syncUUID
do_syncrepl: rid 002 retrying (29 retries left)
Sure enough, the entry for my accesslog database's suffix doesn't have an
lastmod is not explicitly enabled for this database, but slapd.conf(5) says
the default is on. I'm reasonably sure I didn't specify 'lastmod off' for
that database at the time it would have been created.
Given that my consumers are using delta-syncrepl (hence the accesslog), is
there any reason I can't/shouldn't replicate the accesslog itself, too?
John Morrissey _o /\ ---- __o
jwm(a)horde.net _-< \_ / \ ---- < \,
www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__
I hope this is the place to send such questions. I'm having problems
getting started with ppolicy.
I am trying to specify a specific ppolicy entry for users without
using the slapd.conf default policy. Our OpenLDAP deployment
environment in Red Hat uses version 2.3.33.
>From what I have read (elsewhere since the manual is missing the
ppolicy config info), I must first add a new policy of objectclass
'pwdPolicy" in the policy list. I have done that without problem. I
must then indicate for the users that use that policy, the DN of the
new policy in the field 'pwdPolicySubentry'.
My problem at this point is that I see no objectclass that contains
this field. In reading the ppolicy.schema file I see that the type
'pwdPolicySubentry' is described there, but commented out. The odd
thing though, is that even though it is commented out, I can see the
type in my LDAP browser when I look for a list of types, and I see no
description of it in the other .schema files.
I did read on someone's site that the user entry should be an
objectclass of 'pwdPolicy' and then the 'pwdPolicySubentry' field can
be entered, but in the ppolicy.schema document, 'pwdPolicySubentry' is
not described in the list of fields for objectclass 'pwdPolicy'.
Do I have to edit the ppolicy.schema to get the overlay to work this
way? I'm new to LDAP so perhaps I'm not understanding something
Any help or suggestions would be very helpful.
I tried to load a slapcat dump from OpenLDAP 2.3.27 into OpenLDAP 2.4.8,
and had problems with java entries. I narrowed down the problem with
this simple test case:
Load of this LDIF in OpenLDAP 2.3.27:
ldapadd -D"cn=Manager,dc=example,dc=com" -W -x -f /tmp/bug.ldif
Enter LDAP Password:
adding new entry "cn=REQUEST,dc=example,dc=com"
Works, but in OpenLDAP 2.4.8:
ldapadd -h sdco1cdba -p 1389 -D"cn=Manager,dc=example,dc=com" -W -x -f /tmp/bug.ldif
Enter LDAP Password:
adding new entry "cn=REQUEST,dc=example,dc=com"
ldap_add: Object class violation (65)
additional info: instanstantiation of abstract objectClass 'javaObject' not allowed
And the entry is not loaded. I tried to define the entry with the
JMSAdmin tool that comes with IBM MQ, but could not load it either in
2.4.8, it worked against 2.3.27. A wireshark dump showed that the tool
received the same error as ldapadd.
I performed a "diff" on the java.schema of 2.4.8 and 2.3.27, but the schemas
Is there any way that I could circumvent this problem?
Using openldap 2.3.38 on 2.6.24 with bdb/hdb backend.
I got about 12-13 000 entries in my directory.
Slapcat takes seconds, while slapadd takes 15 minutes or more.
Is there any way to speed it up, which I've missed?
to slapadd I do:
/etc/init.d/slapd stop &&
cd /var/lib/ldap && ls |grep -v DB_CONFIG|xargs rm &&
currently the best way to minimize downtime I found
is to replace "directory" line in slapd.conf, then
do slapadd "into" new physical location, and then
just stop slapd, change dirname, change directory line back,
and start again.
I'm afraid it's actually not slapd issue, but just
some file-reading/adding -related thing.
Is it some better workaround for this with newer release?
I'd be happy to jump to 2.4.7 series, but it still seems
a little bit unstable, segfaults sometimes with some
I wanted to test the scenario where a user had forgotten his password,
and needed to have it reset. I wanted to give this user the ability
change this temporary password if they wanted. To do this, I:
1. Executed ldappasswd, binding as the rootdn, to change the user's password
2. Used ldapvi to reset the sambaPwdCanChange and sambaPwdLastSet attributes
3. Logged in to the domain as the user
4. Hit Ctrl+Alt+Delete and selected "Change Password"
However, because my ppolicy pwdMinAge hadn't expired yet, the user was
unable to change the password. So, it seems necessary to be able to
change that value for the user so he/she can change their password. I
couldn't find an attribute called pwdMinAge, but I'm assuming that's
because it just looks at pwdChangedTime. I 'assume' because I couldn't
find explicit documentation stating this, though the man page definition
for pwdChangedTime says "[pwdChangedTime] is used by the password
expiration policy to determine whether the password is too old to be
allowed to be used for user authentication." Is this why I see a
NT_STATUS_WRONG_PASSWORD returned from LDAP when a user tries to change
a password that is being protected by pwdMinAge?
And, is executing an ldapmodify the proper thing to do in this situation
to change the pwdChangedTime and allow the user to change his/her
ldapmodify -D "cn=admin,dc=example,dc=com" -W
Thanks as always,
I am getting the below error while starting openLDAP.
bdb_db_open: alock package is unstable
backend_startup_one: bi_db_open failed! (-1)
slapd shutdown: initiated
slapd destroy: freeing system resources.
connections_destroy: nothing to destroy.
However, if I am using sudo access, I get no error and could
successfully start the server and search the DB.
Could anyone please help let me know what the cause for this error is ?
I am using Berkeley DB 4.4.20
OpenLDAP version : 2.3.39
I'd like to set up LDAP command line tools to point to a server
-- say localhost -- that has a certificate with an arbitrary
name in it -- say `my-domain.com`.
I'm not entirely sure how to my LDAP tools to do that, though
-- or if it's possible. By default, OpenLDAP is wound up pretty
I am trying to get LDAP with SASL-GSSAPI mechanism.
I have openldap-2.4.7 on RHEL 4.
I have installed Cyrus sasl-2.1.21.
I have compiled LDAP with cyrus SASL support as:
[root@as3 libexec]# env
/usr/local/BerkeleyDB.4.6/lib -L/usr/local/lib/sasl2 " LIBS=-ldl
./configure --with-tls=openssl --with-cyrus-sasl
It was fine.
SASL was compiled as:
$ ./configure --disable-cram --disable-digest --disable-krb4
--disable-otp --enable-gssapi --with-gss_impl=mit
In /usr/lib/sasl2,it has
[root@as3 sasl2]# ls libgssapi*
libgssapiv2.la libgssapiv2.so libgssapiv2.so.2 libgssapiv2.so.2.0.19
When I run :
[root@as3 libexec]# saslauthd -V
authentication mechanisms: getpwent rimap shadow
I also have a working kerberos .I am able to get tickets from kerberos.I
have added ldap host principal to kerberos database.
I have my slapd.conf as: (sasl related part)
(Also,I have added the first two lines after seing some mailing list.In
the admin guide nothing was mentioned about adding the two lines.Please
tell me whether it is correct?)
According to HOWTO doc from www.bayour.com,when we query ldap for
supportedSASLMechanisms,it should show GSSAPI(my whole purpose).But
when I give the following:
[root@as3 openldap]# /usr/bin/ldapsearch -H "ldaps://:12345" -x -b "" -s
base -LLL supportedSASLMechanisms
Does it mean that LDAP was not built with SASL support?
I have slapd.conf in /usr/lib/sasl2 as:
mech_list: plain login ntlm kerberos5
I am not able to get SASL-GSSAPI as supportedSASLMechanism.From where does
the LDAP get this list?
What should I do to add one more mechanism to supportedSASLMechanisms
What may be the problem.....?
Please guide me....I was struck at this point and not able to come out
Thanx a lot in advance.....
Thanx and Regards,
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you