openldap-software

openldap-software@openldap.org

2719 discussions

syncrepl, client certificate containing subjectAltName and non UTF-8 chars
by Emmanuel Dreyfus 21 Jul '07

21 Jul '07

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

4 6

connection_read: no connection!
by Thierry Lacoste 21 Jul '07

21 Jul '07

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.

1 0

ManageDSAiT
by Christophe Gudin 21 Jul '07

21 Jul '07

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.

3 2

Meta configuration
by Martin Montero 21 Jul '07

21 Jul '07

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

2 1

moving ldap database and upgrading
by Maria McKinley 21 Jul '07

21 Jul '07

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

7 14

Programmatic manner to determine version?
by Mark Lavi 20 Jul '07

20 Jul '07

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

4 3

c_get lo failure
by Quanah Gibson-Mount 20 Jul '07

20 Jul '07

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

2 3

Slapd unable to bind after a while
by Chan, Siu-Ki K 20 Jul '07

20 Jul '07

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

1 0

ldapsearch on local attributes with slapo-translucent
by Gavin Henry 20 Jul '07

20 Jul '07

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.

3 3

"descriptor table size" errors?
by Gregory K. Ruiz-Ade 20 Jul '07

20 Jul '07

We seem to be getting errors every night a couple minutes after logrotate rotates our logs and sends a SIGHUP to syslog-ng (to force a reload): Jul 11 04:02:46 csenet slapd[8823]: daemon: 1024 beyond descriptor table size 1024 Nothing is touching our slapd process (i.e., same process over several days.) This seems only to happen on our master LDAP server. We're using slurpd for replication to our two slave servers. This morning, something apparently corrupted our directory, which apparently got replicated to our slaves; we restored the db from the nightly dump (made from slapcat on another replica) and LDAP seems happy again. We can't see anything in the logs that would lend a clue as to what might be going on. Any suggestions as to where I should start looking? We're running RHEL 4 with all updates applied, using RH's openldap packages (2.2.13). Looking back in the logs, it seems that the syslog message above occurs for a couple minutes after syslog-ng is restarted, and then stops occurring until the next time syslog-ng is restarted, but it's apparently been happening for quite a while. Today is the first time we've had corruption (or otherwise total failure) of the LDAP directory, though. Any suggestions or help will be greatly appreciated. Gregory -- Gregory K. Ruiz-Ade Sr. Systems Administrator Computer Science and Engineering University of California, San Diego Office: EBU3b 1216 Phone: (858) 822-2625 E-mail: gkra(a)cs.ucsd.edu

6 14

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software