In using ldapsearch to bind to a server with IPv6 address, some error pops up:
qxu@durian(pts/3):/etc$ kinit XCTEST100(a)XCIPV6.COM Password for XCTEST100(a)XCIPV6.COM:
Ticket cache: FILE:/tmp/krb5cc_20153
Default principal: XCTEST100(a)XCIPV6.COM
Valid starting Expires Service principal
06/09/09 17:35:18 06/10/09 03:34:41 krbtgt/XCIPV6.COM(a)XCIPV6.COM
renew until 06/10/09 17:35:18
qxu@durian(pts/3):/etc$ ldapsearch -Y GSSAPI -H 'ldap://3ffe:2000:0:1:e0be:1872:d4f8:6b2c' -b 'dc=xcipv6,dc=com' -s sub -LLL 'cn=XCTEST100' mail
Could not create LDAP session handle for URI=ldap://3ffe:2000:0:1:e0be:1872:d4f8:6b2c (-9): Bad parameter to an ldap routine
qxu@durian(pts/3):/etc$ ldapsearch -Y GSSAPI -H 'ldap://[3ffe:2000:0:1:e0be:1872:d4f8:6b2c]' -b 'dc=xcipv6,dc=com' -s sub -LLL 'cn=XCTEST100' mail
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)
Shall I add the brackets  around the IPv6 address? DNS server has been correctly set up, because sasl binding over IPv4 address is good.
Any possible reason for the failure of ldapsearch?
I have successfully installed cyrus-sasl-2.1.23 and openldap-2.3.27 plus
BerkeleyDB.4.3 in my RHEL5.2 server. After the installation, i used
saslpasswd2 -c to create an admin user:
saslpasswd2 -c admin
After that, I thought of doing a search on the database with the command :
ldapsearch -H ldap:///localhost -Y DIGEST-MD5 -d 2 -U admin
but it returned an error of :
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL(-13): user not found: no secret in database
When i did a check on /etc/, the sasldb2 file is there. I do not know and
understand why it cannot find this user. Did i miss out anything. Below is
excerpt from my slapd.conf file
Under rootpw, i typed the password in clear text, for eg, the password i
create for admin was root. Hence it looks like:
Did i do anything wrong? Where is the error?
Hope to receive some help. I have been trying to install openldap with cyrus
for 4 months but to no avail :(
This post is because of:
So, if you're using ppolicy-slapo in a load-balanced environment, you
pool servers never will be sync completely; at least, the ppolicy state
atributes will be not replicated. I know isn't really a slapo-ppolicy
limitation rather than RFC especification consequence.
Well... I want my load-balancing environment and I want also the ppolicy
overlay. So ¿how to make an effective workaround?
At first, I've thinked in next scenario:
* 1 provider and 2 consumers
* every 5 minutes the consumers rsync the contents of master ddbb
(/var/lib/ldap/* in my case, Debian Lenny boxes)
¿It will be enough?
I wonder if consumers slapd can accept these data change "on the fly" or
maybe restarting the service is mandatory.
Jordi Espasa Clofent
i've a heimdal (1.2) server which uses the OpenLDAP (2.4.15) directory
for data storage.
When i run the following script:
for i in `seq 1 10000`; do
kinit --password-file=passwd && echo "ok $i" || break;
At some point the kinit fails, because heimdal cannot connect to the
LDAP server. heimdal-kdc server fails at
ldap_sasl_bind_s with 'Can't contact LDAP server'.
Heimdal access the LDAP directory is using the ldapi:///.
When i 'slow-down' the LDAP server with strace or by enable debug log to
console the number of successful kinit runs increase. It seems to be a
some kind of timing problem, but i don't have a clue to find out what's
the reason for it. Maybe someone here on the list can help me.
Thanks in advance,
I'm following this:
I'm getting this error:
ldap_add: Naming violation (64)
additional info: value of naming attribute 'uid' is not present in entry
Here are the sample ldif entries:
sn: De Torre
Michael F. March
I've experienced some problems in one of my 3 OpenLDAP servers. First
glance suggests a ppolicy overlay problem, but, at the end, the problem
was resolved, simply, deleting the bbdd (BDB4) and restarting the system
(is a consumer server, so the ddbb was automatically regenerated).
So, my questions are
* ¿How I can detect a corrupt database?
* ¿Is there any tool/command to check the ddbb health (DBD4)?
* ¿What can I do if the corrupted database is the provider database?
Jordi Espasa Clofent
I have a problem to run openldap in a different directory other than
/var/lib/ldap I am using Redhat AS 4 (update 4) with selinux disabled.
Openldap version is 2.4.13 . The message written into syslog is "line 24:
invalid path: Permission denied " . Line 24 specifies
is a different directory than /var/lib/ldap and directory has the 755
permission of the user running ldap daemon.
Google search has revealed some issues on ubuntu and on redhat with selinux
enabled but I have neither of these.
If I change the directory to /var/lib/ldap everything works fine. I hope
someone could shed me light on this issue.
thanks a lot.
I created some records with phpldapadmin but now they look like this:
Is There a way to change these glue entries without reloading a complete tree?
The normal ldapmodify doesn't allow to change this and ldapsearch can't find these records.
Ldapdelete won't delete them either.
Entries loaded under this dn can be found/modifies/deleted as normal
I´m trying to remove the attribute "userCertificate;binary" from an entry, if it (attr) contains a special value (certificate). I´m trying this operation with perl ldap modules and also with Gawojar ldap browser. Both were working for me when I was using OpenLDAP 2.3.20.
Now I´m using OpenLDAP 2.4.12 and I get an error message
RESULT tag=103 err=16 text=modify/delete: userCertificate;binary: no such value
but I send the modify request by using exactly the same value as I get from the ldap server (I compared the bytes sent across the network with wireshark) when requesting it with a ldapsearch. As I already wrote the same function worked for me with the older OpenLDAP version. I also tried to modify text attributes; that´s working.
I didn´t found anything in the change log which is pointing to a fix regarding the comparison mechanism. Has anybody else had that problem ?
--On August 4, 2009 4:20:06 PM -0700 Ivan Ordonez
> Sorry Quanah, I am not following you on what you want me to do. Can you
> please elaborate?
> Thank you for all your help.
Keep replies on the list please.
I was saying, I would have kept the ldaps:// URI in your config file, and
drop the start TLS bit, and seen whether or not that works.
In either case, I would use the ldapsearch binary to test against your
server, both with ldaps:// URIs, and with ldap:// URIs using the -ZZ or
-ZZZ flags to ldapsearch. ldapsearch with ldap:/// and -ZZ(Z) will use
startTLS. ldapsearch with ldaps:// will try an SSL connection to the LDAP
server. This way, you can hopefully get more meaningful error messages.
Principal Software Engineer
Zimbra :: the leader in open source messaging and collaboration