dn="" and anonymous
by Thierry Lacoste
What is the difference between dn="" and anonymous?
conn=4069 op=3 BIND dn="" method=128
conn=10515 op=4 BIND anonymous mech=implicit ssf=0
Regards,
Thierry.
15 years, 8 months
syncrepl, client certificate containing subjectAltName and non UTF-8 chars
by Emmanuel Dreyfus
Hello
I'm trying to get multiple syncrepl-powered replicas available under the
same DNS name. I use OpenLDAP-2.3.32
Each replica has a certificate with
subjectAltName=DNS:ldap.example.net,DNS:host.example.net
Clients can hapily conntect to it, that part works.
syncrepl is working with the provider using a certificate, but now I'd
like the consumers to use certificate too, so that the provider does not push
sensitive data to anyone that pretend being a replica.
After two days of fight against the machine, I discovered that I could not
use a different certificate for the syncrepl consumer and the LDAP service
running on the replica. This is a bug in 2.3.x, as explained by Howard Chu:
http://www.openldap.org/lists/openldap-software/200604/msg00202.html
http://www.openldap.org/lists/openldap-software/200604/msg00201.html
So I have to use the same certificate. I could live with that, but it does
not work: I add this to the syncrepl statement on the consumers' slapd.conf
bindmethod=sasl
saslmech=EXTERNAL
And when restarting it, I get this error:
do_syncrep1: rid 217 ldap_sasl_interactive_bind_s failed (7)
I tried to use my certificate with ldapsearch. With an appropriate .ldaprc,
I can try this (the server here is the provider):
# ldapsearch -b "" -s base +
SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Authentication method not supported (7)
additional info: SASL(-4): no mechanism available:
Using a certificate that does not have subjectAltName, it works fine, so
the provider is not rejecting me.
Here are my certificates Subjects, the one without subjectAltName that works,
and the other one that breaks (obtained by openssl x509 -text, a bit
modified, but you have the point: yes there are ISO-8859-1 chars in O)
WORKS:
C=FR, ST=France, O=Exemple d'organisation accentuée, OU=foobarbuz,
CN=host.example.net/emailAddress=root@example.net
BREAKS:
C=FR, ST=France, O=Exemple d'organisation accentuée,
OU=foobarbuz/subjectAltName=DNS:ldap.example.net,DNS:host.example.net
CN=ldap.example.net/emailAddress=root@example.net
Playing with gdb shows that the server rejects the certificate in
libraries/libldap_r/utf-8.c:ldap_ucs_to_utf8s(), returning LDAP_INVALID_SYNTAX
I searched the web, and it seems that ISO-8859-1 chars in certificate
subjects are not a good idea. Changing that means also changing the
certificate authority, that's something I'd like to avoid. Do I have
another solution?
That kind of problem has been discussed already on the mailing list. It
seems Howard Chu added ldap_ucs_to_utf8s() to address non UTF-8
chars in certificates subjects:
http://www.openldap.org/lists/openldap-devel/200205/msg00037.html
ldap_ucs_to_utf8s() contains really black magic, it would require one
more day for me to understand what happens there. Is it possible that
it is smart enough to workaround non UTF-8 chars in the general case,
but fails when subjectAltName is used?
Please help! How can I get this mess working?
--
Emmanuel Dreyfus
manu(a)netbsd.org
15 years, 8 months
connection_read: no connection!
by Thierry Lacoste
I'm using OpenLDAP 2.3.24 on FreeBSD 6.1.
I'm using slurpd between one master and one slave.
I'm having these messages on the slave:
Jul 19 21:20:37 pollux slapd[13533]: conn=792 op=2 UNBIND
Jul 19 21:20:37 pollux slapd[13533]: conn=792 fd=18 closed
Jul 19 21:20:37 pollux slapd[13533]: connection_read(18): no connection!
Jul 20 01:15:37 pollux slapd[17928]: conn=182 op=2 UNBIND
Jul 20 01:15:37 pollux slapd[17928]: conn=182 fd=11 closed
Jul 20 01:15:37 pollux slapd[17928]: connection_read(11): no connection!
ul 21 15:47:17 pollux slapd[33013]: conn=1090 op=2 UNBIND
Jul 21 15:47:17 pollux slapd[33013]: conn=1090 fd=23 closed
Jul 21 15:47:17 pollux slapd[33013]: connection_read(23): no connection!
This seems to never happen on the master.
I found some infos on mailing lists archives about poorly written
clients not unbinding before closing connexion but apparently
this is not the case here.
I also found a message of Quanah telling this is a harmless error
but I'd like to understand what's happening and why only on the slave.
Best regards,
Thierry.
15 years, 8 months
ManageDSAiT
by Christophe Gudin
Hello list,
I'm having some trouble with following referrals and especially ManageDSAiT.
When I request the supported controls here's what I get:
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectClass=*)
# requesting: supportedControl
#
#
dn:
supportedControl: 1.3.6.1.4.1.4203.1.9.1.1
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 1.3.6.1.4.1.4203.1.10.1
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.2.826.0.1.334810.2.3
supportedControl: 1.2.826.0.1.3344810.2.3
supportedControl: 1.3.6.1.1.13.2
supportedControl: 1.3.6.1.1.13.1
supportedControl: 1.3.6.1.1.12
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
So the ManageDSAiT (2.16.840.1.113730.3.4.2) is meant to be supported.
However if I try any search (or add, etc) with the -M parameter (or if I use
JNDI where I believe this control is set by default) The referrals aren't
followed and I have the following logged error and no result is returned
(not even a referral record):
Jul 18 11:45:03 linuxAeL1 slapd[4163]: begin get_filter
Jul 18 11:45:03 linuxAeL1 slapd[4163]: EQUALITY
Jul 18 11:45:03 linuxAeL1 slapd[4163]: end get_filter 0
Jul 18 11:45:03 linuxAeL1 slapd[4163]: filter: (uid=jlsteiner1000f)
Jul 18 11:45:03 linuxAeL1 slapd[4163]: => get_ctrls
Jul 18 11:45:03 linuxAeL1 slapd[4163]: => get_ctrls: oid="
2.16.840.1.113730.3.4.2" (noncritical)
Jul 18 11:45:03 linuxAeL1 slapd[4163]: <= get_ctrls: n=1 rc=0 err=""
Jul 18 11:45:03 linuxAeL1 slapd[4163]: attrs:
Jul 18 11:45:03 linuxAeL1 slapd[4163]:
Jul 18 11:45:03 linuxAeL1 slapd[4163]: conn=41 op=1 SRCH
base="o=EtatGE,c=CH" scope=2 deref=3 filter="(uid=jlsteiner1000f)"
Jul 18 11:45:03 linuxAeL1 slapd[4163]: slap_global_control: unavailable
control: 2.16.840.1.113730.3.4.2
I really don't understand why this last line is coming up.
I configured openLDAP with the followings: ./configure --enable-backends
--enable-overlays --enable-tls --enable-acl
Here's my slapd.conf:
# NOTES: inetorgperson picks up attributes and objectclasses
# from all three schemas
#
# NB: RH Linux schemas in /etc/openldap
#
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/openca.schema
include /usr/local/etc/openldap/schema/ldappc.schema
include /usr/local/etc/openldap/schema/kitneduperson.schema
# DON'T bother with ARGS file unless you feel strongly
# slapd scripts stop scripts need this to work
pidfile /var/run/slapd.pid
# enable a lot of logging - we might need it
# but generates huge logs
#loglevel Conns Sync Filter
loglevel -1
# NO dynamic backend modules
# TLS-enabled connections
TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCACertificateFile /usr/local/var/openldap-data/cacert.pem
TLSCertificateFile /usr/local/var/openldap-data/ldapcrt.pem
TLSCertificateKeyFile /usr/local/var/openldap-data/ldapkey.pem
#Here I added the chaining
overlay chain
#######################################################################
# bdb database definitions
#
# replace example and com below with a suitable domain
#
# If you don't have a domain you can leave it since example.com
# is reserved for experimentation or change them to my and inc
#
#######################################################################
database monitor
access to dn.subtree=cn=monitor
by dn.exact=cn=Manager,o=example,c=ch write
by dn.subtree=o=example,c=ch read
by * write
database bdb
suffix "o=example,c=ch"
# root or superuser
rootdn "cn=Manager,o=example,c=ch"
rootpw secret
# The database directory MUST exist prior to running slapd AND
# change path as necessary
directory /usr/local/var/openldap-data
# Indices to maintain for this directory
# unique id so equality match only
index uid eq
# allows general searching on commonname, givenname and email
index cn,gn,mail eq,sub
# allows multiple variants on surname searching
#index sn eq,sub
# sub above includes subintial,subany,subfinal
# optimise department searches
#index ou eq
# if searches will include objectClass uncomment following
# index objectClass eq
# shows use of default index parameter
index default eq,sub
# other database parameters
# read more in slapd.conf reference section
cachesize 10000
checkpoint 128 15
dbconfig set_cachesize 0 30000000 0
dbconfig set_lg_bsize 3000000
dbconfig set_flags DB_LOG_AUTOREMOVE
dbcachesize 350000
Also as an aside question, I'm not sure I understand why the server is doing
the recursion referral correctly (i.e. it returns the correct record fetched
on the second server instead of the referral record) when I *don't* put the
-M option...
As I'm a little lost in those referral questions and I didn't find relevant
information I hope someone can clarify this for me.
Best,
Christophe.
15 years, 8 months
Meta configuration
by Martin Montero
Hi list,
I've a openldap as metadirectory with the following configuration
database meta
suffix "dc=example,dc=org"
rootdn "cn=admin,dc=example,dc=org"
rootpw ""
uri "ldap://ldap1.example.org/ou=ldap1,dc=example,dc=org"
suffixmassage "ou=ldap1,dc=example,dc=org" "ou=ldap1,dc=foo,dc=org"
uri "ldap://ldap1.example.org/ou=ldap2,dc=example,dc=org"
suffixmassage "ou=ldap2,dc=example,dc=org" "ou=ldap2,dc=foo,dc=org"
when one of the remote servers (ldap1.example.org or ldap2.example.org) is down and i do a ldapsearch (with base = dc=example,dc=org ) the following message appears:
" 52 server is unavailable "
and no search result return.
This behavior is normal? or i should have the search return of the other server?
thanks!
Martin
__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas
15 years, 8 months
moving ldap database and upgrading
by Maria McKinley
Hi there,
I am trying to move my ldap to a new machine to upgrade from
openldap2.2 to openldap2.3. I moved all of my config files and created
new certificates, but I am having difficulties. I am running on
Debian, and if I start slapd by /etc/init.d/slapd start, I get:
Starting OpenLDAP: slapd - failed.
The operation failed but no output was produced. For hints on what went
wrong please refer to the system's logfiles (e.g. /var/log/syslog) or
try running the daemon in Debug mode like via "slapd -d 16383" (warning:
this will create copious output).
>From syslog:
Jul 18 08:08:01 maude slapd[27079]: main: TLS init def ctx failed: -1
Jul 18 08:08:01 maude slapd[27079]: slapd stopped.
Jul 18 08:08:01 maude slapd[27079]: connections_destroy: nothing to destroy.
If I then try to start slapd using slapd -d 16383, it seems to start
up fine, but can't read the database.
maude:/etc/ldap# ldapsearch -x "uid=maria"
<output truncated to what I think is the pertinent info>
<= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30990)
send_ldap_result: conn=0 op=1 p=3
send_ldap_result: err=32 matched="" text=""
send_ldap_response: msgid=2 tag=101 err=32
ber_flush: 14 bytes to sd 12
0000: 30 0c 02 01 02 65 07 0a 01 20 04 00 04 00 0....e... ....
# search result
search: 2
result: 32 No such object
Any ideas, or any other troubleshooting to try?
thanks, maria
15 years, 8 months
Programmatic manner to determine version?
by Mark Lavi
Hello everyone,
I'm working on a build system which encompasses dependencies on
OpenLDAP. I've done a general of the web with Google, searched the
OpenLDAP FAQ, and searched the OpenLDAP mailing lists for how one can
determine the version of OpenLDAP software.
I understand that there are different version numbers for APIs, software
releases, and libraries.
However, I'm confused as to how to programmatically determine the
version of installed binaries and libraries and then reconcile them with
Perhaps this speaks to a lack of experience with the innards of OpenLDAP
or some of the build tools, so I am asking here for some insight.
All of my examples are on Novell SuSE Linux 9.2, on ia64 architecture,
with a build of OpenLDAP 2.3.36. My goal would be to validate that
OpenLDAP version 2.3.36 tools and libraries are installed.
If one tries to deduce the version of a library you would see this:
* > cd lib; ls -l libldap*
* libldap-2.3.so.0 -> libldap-2.3.so.0.2.24
* libldap-2.3.so.0.2.24
* libldap.a
* libldap.la
* At best, I can confirm this library is from OpenLDAP 2.3.X.
* Question: Is there anyway to resolve the .X = .36 for
this library?
* Reading libldap.la gives some insight, but nothing more than
what I've already asserted in the previous sentence.
* Question: What is the .0.2.24 version suffix? It doesn't seem to
relate to 2.3.36.
* > objdump -x libldap-2.3.so.0
* Yeilds a lot of information, but again - nothing seems
to relate to 2.3.36.
If one tries parse the output of bin/ldapsearch -V or libexec/slapd -V,
you can see 2.0.36 - but the output seems to go to the console. I can't
do something like:
* libexec/slapd -V | head -n 1 | awk '{print $4}'" >
/tmp/openldap_version.txt
* /tmp/openldap_version.txt is blank.
* Is there an easy way to pipe the output to STDOUT? What am I
missing?
Aha! I think I found one method: includes/ldap_features.h reveals:
* ldap_features.h:#define LDAP_VENDOR_VERSION 20336
* ldap_features.h:#define LDAP_VENDOR_VERSION_PATCH 36
Is this the only way?
Thanks for any insight anyone can offer.
..............................
Mark Lavi
Web Producer
SGI
mlavi(a)sgi.com
tel: 650.933.7707
sgi.com
15 years, 8 months
c_get lo failure
by Quanah Gibson-Mount
Anyone have any idea what would cause this error?
=> key_change(ADD,5bf)
bdb_idl_insert_key: 5bf [0096defd]
=> bdb_idl_insert_key: c_get lo failed: DB_NOTFOUND: No matching key/data
pair found (-30990)
<= key_change -30990
<= index_entry_add( 1471, "uid=btest,ou=people,dc=viz,dc=com" ) failure
bdb_add: index_entry_add failed
send_ldap_result: conn=6 op=3 p=3
send_ldap_result: err=80 matched="" text="index generation failed"
send_ldap_response: msgid=4 tag=105 err=80
At first, because of the "index generation failed" error, I thought it was
related to file permissions, but the slapd user is completely able to read
and write to files in the openldap DB directory.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 8 months
Slapd unable to bind after a while
by Chan, Siu-Ki K
Hi,
I am running openldap-2.3.32 with back-perl which responds to:
- bind upon which it binds/authenticates against another ldap server
- search upon which it returns some cooked up response
The problem is that the back-perl server runs happily accepting and
responding to bind and search requests initially.
After a couple of hours (with no activity) the server would error out
upon a bind request giving the following errors:
conn=13 fd=13 ACCEPT from IP=10.16.22.82:3402 (IP=155.108.22.200:10389)
conn=13 op=0 BIND
dn="cn=foo,ou=ldaporganizationalunit,dc=statestreet,dc=com" method=128
Perl BIND returned 0x0001
conn=13 op=0 RESULT tag=97 err=1 text=
conn=13 fd=13 closed (connection lost)
conn=14 fd=10 ACCEPT from IP=10.16.22.82:3632 (IP=155.108.22.200:10389)
conn=14 op=0 BIND
dn="cn=foo,ou=ldaporganizationalunit,dc=statestreet,dc=com" method=128
Perl BIND returned 0x0051
conn=14 op=0 RESULT tag=97 err=81 text=
conn=14 fd=10 closed (connection lost)
conn=15 fd=10 ACCEPT from IP=10.16.22.82:3633 (IP=155.108.22.200:10389)
conn=15 op=0 BIND
dn="cn=foo,ou=ldaporganizationalunit,dc=statestreet,dc=com" method=128
Perl BIND returned 0x0051
conn=15 op=0 RESULT tag=97 err=81 text=
conn=15 fd=10 closed (connection lost)
Interesting thing to note is the first unsuccessful bind always results
in error 1, while all subsequent unsuccessful binds result in error 81.
Any help is greatly appreciated.
--
Siu-Ki Chan
15 years, 8 months
ldapsearch on local attributes with slapo-translucent
by Gavin Henry
Dear All,
I'm doing some work with Asterisk and translucent, trying to overlay some
attributes to an existing remote account, locally.
These attributes have been added by entries in the local database before
being presented to me via ldapsearch, whilst searching for attributes
present in the remote directory:
objectClass: AsteriskExtension
objectClass: AsteriskSIPUser
AstAccountName: 600
AstAccountType: friend
AstAccountSecret: 600
AstAccountQualify: yes
AstAccountPort: 5060
AstAccountNAT: never
AstAccountMailbox: 600@device
AstAccountHost: dynamic
AstAccountDTMFMode: rfc2833
AstAccountContext: from-internal
AstAccountCanReinvite: no
AstAccountCallerID: Gavin <502>
Should I expect to be able to search for the above attributes and get a
result? Currently I am not.
A filter like:
"(&(objectClass=AsteriskSIPUser)(AstAccountName=600)"
returns:
ldapsearch: ldap_search_ext: Bad search filter (-7)
So I guess that answers my question.
If slapo-translucent did return results for searches against the local
attributes, would this be defeating the purpose/design of the overlay?
Thanks,
Gavin.
15 years, 8 months
