openldap-bugs

openldap-bugs@openldap.org

1 participants
21063 discussions

Re: (ITS#5106) LDAPI problem on amd64
by ando＠sys-net.it 29 Aug '07

29 Aug '07

> I updated to 2.3.38 and the problem seems to have vanished. > Thanks for the hint. Thanks for the prompt feedback. I've closed this ITS. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5106) LDAPI problem on amd64
by svgmuc＠bluebottle.com 29 Aug '07

29 Aug '07

Hi, Quoting Pierangelo Masarati <ando(a)sys-net.it>: > You should be using the latest 2.3 release; there was quite a bit > of > work on ldapi between 2.3.32 and 2.3.38 (ITS#4893 and > other possibly related fixes). Having said this, I don't know if it > will solve your problem, but at least it would make sure it's not > fixed yet. No need to say that things work fine here on > Linux/amd64. I updated to 2.3.38 and the problem seems to have vanished. Thanks for the hint. Best, Sven ---------------------------------------------------------------------- Finally - A spam blocker that actually works. http://www.bluebottle.com/tag/4

1 0

Re: (ITS#5065) out of order ctxcsn from old entryCSN
by ando＠sys-net.it 29 Aug '07

29 Aug '07

> Old entryCSN values imported into the data from another server, can crash > replicas. The ITS reports that this is now fixed in HEAD. I would appreciate if you feedback using a fresh HEAD build, since the CSN syntax is now more thoroughly checked, although it is supposed to allow the old one in input. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

slapd makes very strange troubles in VServer
by Niki Hammler 29 Aug '07

29 Aug '07

Hi, Today I began to move my LDAP-Server to a Linux VServer jail. On the host and on the VServer I run Debian etch 4.0. Installing slapd was no problem (aptitude install slapd). I just copied all configuration and data files from the host which worked perfectly before and copied them 1:1 into the VServer. slapd starts without any warnings. But connecting with a client is not possible, neither inside the VServer nor outside. For security reasons, I just allow access with SSL or TLS-required (the very same file worked greatly on the host!): pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel 0 disallow bind_anon require authc security tls=1 TLSCACertificateFile /etc/ldap/ssl/cacert.crt TLSCertificateFile /etc/ldap/ssl/ldap.crt TLSCertificateKeyFile /etc/ldap/ssl/ldap.key TLSVerifyClient never All key files and database files are accessible by slapd (user=openldap, group=openldap). Connecting to ldap and ldaps works greatly from inside the VServer and also from outside: $ nc 192.168.0.2 ldap ^c $ nc 192.168.0.2 ldaps ^c $ There are no packet filters installed, debugging with tcpdump (local interface) shows the complete TCP traffic and handshake with no errors. The strange error is always the same: The clients do not want to connect, sending SSL stuff is always possible but after that, nothing is received. Let's begin with plain SSL: $ openssl s_client -connect 192.168.0.2:636 -debug CONNECTED(00000003) write to 0x80bee90 [0x80bf4e8] (118 bytes => 118 (0x76)) 0000 - 80 74 01 03 01 00 4b 00-00 00 20 00 00 39 00 00 .t....K... ..9.. 0010 - 38 00 00 35 00 00 16 00-00 13 00 00 0a 07 00 c0 8..5............ 0020 - 00 00 33 00 00 32 00 00-2f 03 00 80 00 00 05 00 ..3..2../....... 0030 - 00 04 01 00 80 00 00 15-00 00 12 00 00 09 06 00 ................ 0040 - 40 00 00 14 00 00 11 00-00 08 00 00 06 04 00 80 @............... 0050 - 00 00 03 02 00 80 f5 5d-10 d2 64 21 24 0c b1 c3 .......]..d!$... 0060 - 92 37 72 7a 4a 9c 09 88-46 b2 f8 39 ef f6 c4 c8 .7rzJ...F..9.... 0070 - 84 74 8e a6 79 e1 .t..y. read from 0x80bee90 [0x80c4a48] (7 bytes => 0 (0x0)) 20500:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188: $ I did lots of tests with many LDAP clients (ldapwhoami, ldapsearch commandline tools, PHP, Softerra LDAP Administrator and Clients in exim4, Courier etc). In this case I show connecting with SSL using ldapwhoami: $ ldapwhoami -x -H ldaps://nobaq.intern.stiftingtal.net -D "uid=nobaq,ou=users,dc=intern,dc=stiftingtal,dc=net" -w secret -v -d 999 ldap_initialize( ldaps://nobaq.intern.stiftingtal.net ) ldap_create ldap_url_parse_ext(ldaps://nobaq.intern.stiftingtal.net) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP nobaq.intern.stiftingtal.net:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.0.2:636 ldap_connect_timeout: fd: 3 tm: -1 async: 0 TLS trace: SSL_connect:before/connect initialization tls_write: want=118, written=118 0000: 80 74 01 03 01 00 4b 00 00 00 20 00 00 39 00 00 .t....K... ..9.. 0010: 38 00 00 35 00 00 16 00 00 13 00 00 0a 07 00 c0 8..5............ 0020: 00 00 33 00 00 32 00 00 2f 03 00 80 00 00 05 00 ..3..2../....... 0030: 00 04 01 00 80 00 00 15 00 00 12 00 00 09 06 00 ................ 0040: 40 00 00 14 00 00 11 00 00 08 00 00 06 04 00 80 @............... 0050: 00 00 03 02 00 80 20 25 c9 bb fe 68 e8 52 6c 87 ...... %...h.Rl. 0060: 04 ae 25 d1 8b f5 73 c8 3d ca 73 ab e3 92 3f 9f ..%...s.=.s...?. 0070: c9 9d 79 4e aa fb ..yN.. TLS trace: SSL_connect:SSLv2/v3 write client hello A tls_read: want=7, got=0 TLS: can't connect. ldap_perror ldap_start_tls: Can't contact LDAP server (-1) $ As you can see, reading fails. And now using a normal connection but with TLS: ldapwhoami -x -H ldap://192.168.0.2 -D "uid=nobaq,ou=users,dc=intern,dc=stiftingtal,dc=net" -w secret -v -d 999 -ZZ ldap_initialize( ldap://192.168.0.2 ) ldap_create ldap_url_parse_ext(ldap://192.168.0.2) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 192.168.0.2:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.0.2:389 ldap_connect_timeout: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush: 31 bytes to sd 3 0000: 30 1d 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 0....w...1.3.6.1 0010: 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .4.1.1466.20037 ldap_write: want=31, written=31 0000: 30 1d 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 0....w...1.3.6.1 0010: 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .4.1.1466.20037 ldap_result ld 0x8051088 msgid 1 ldap_chkResponseList ld 0x8051088 msgid 1 all 1 ldap_chkResponseList returns ld 0x8051088 NULL wait4msg ld 0x8051088 msgid 1 (infinite timeout) wait4msg continue ld 0x8051088 msgid 1 all 1 ** ld 0x8051088 Connections: * host: 192.168.0.2 port: 389 (default) refcnt: 2 status: Connected last used: Wed Aug 29 00:04:19 2007 ** ld 0x8051088 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ** ld 0x8051088 Response Queue: Empty ldap_chkResponseList ld 0x8051088 msgid 1 all 1 ldap_chkResponseList returns ld 0x8051088 NULL ldap_int_select read1msg: ld 0x8051088 msgid 1 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 01 78 07 0a 0....x.. ldap_read: want=6, got=6 0000: 01 00 04 00 04 00 ...... ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x8051088 msgid 1 message type extended-result ber_scanf fmt ({eaa) ber: read1msg: ld 0x8051088 0 new referrals read1msg: mark request completed, ld 0x8051088 msgid 1 request done: ld 0x8051088 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_extended_result ber_scanf fmt ({eaa) ber: ldap_parse_result ber_scanf fmt ({iaa) ber: ber_scanf fmt (}) ber: ldap_msgfree TLS trace: SSL_connect:before/connect initialization tls_write: want=118, written=118 0000: 80 74 01 03 01 00 4b 00 00 00 20 00 00 39 00 00 .t....K... ..9.. 0010: 38 00 00 35 00 00 16 00 00 13 00 00 0a 07 00 c0 8..5............ 0020: 00 00 33 00 00 32 00 00 2f 03 00 80 00 00 05 00 ..3..2../....... 0030: 00 04 01 00 80 00 00 15 00 00 12 00 00 09 06 00 ................ 0040: 40 00 00 14 00 00 11 00 00 08 00 00 06 04 00 80 @............... 0050: 00 00 03 02 00 80 83 33 38 7c c9 0a f9 0b 42 67 .......38|....Bg 0060: 76 97 03 8b e3 47 55 fe 74 ed 86 08 83 fe ed 88 v....GU.t....... 0070: 0e 40 53 97 e5 3e .@S..> TLS trace: SSL_connect:SSLv2/v3 write client hello A tls_read: want=7, got=0 TLS: can't connect. ldap_perror ldap_start_tls: Connect error (-11) $ Connecting without the '-ZZ' seems to work, I get the "confidentiality required" message: $ ldapwhoami -x -H ldap://192.168.0.2 -D "uid=nobaq,ou=users,dc=intern,dc=stiftingtal,dc=net" -w secret -v ldap_initialize( ldap://192.168.0.2 ) ldap_bind: Confidentiality required (13) additional info: TLS confidentiality required $ So I guess the problem is SSL. As said, all SSL files are accessible and there are no errors in the logs or when starting slapd with '-d'. The certificates CN is exactly the hostname. I'm very frustrated because I can't find any errors. I repeat: the very same configuration worked perfectly on the host system. Is this a bug? Thank you very much in advance for any advice, Niki

2 6

(ITS#5111) The '-W' client tool option seems to be reserved by POSIX.2
by ando＠sys-net.it 28 Aug '07

28 Aug '07

Full_Name: Pierangelo Masarati Version: all ever since OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando It seems to be reserved for getopt(3) extensions. I noticed this recently, and I couldn't find any mention of it in the mailing lists/ITS. I don't think it worth fixing, since it's always been there. Just note it somewhere. p.

1 0

Re: ldap_int_global_options not initialized (ITS#5109)
by ando＠sys-net.it 28 Aug '07

28 Aug '07

damien.doiselet(a)neolane.com wrote: > My application is multithread. :) > I've had a call to ldap_get_option(NULL, LDAP_OPT_API_INFO, &ldapi) > before spawning threads, but here the crash occurred also in > ldap_initailize but in ldap_ld_free(). The above sentence is not clear to me; what does the trace below refer to? Your original application, or the one that calls ldap_get_option before spawning threads? What does ldap_ld_free() have to do with this? It never occurs in the trace below. > I addition, I won't call ldap outside my thread. Doesn't matter. Global options are global, so multiple threads may find it uninit'ed, and try to concurrently initialize it. > The full stack trace is : > #0 0xb7e93473 in strlen () from /lib/tls/i686/cmov/libc.so.6 > #1 0xb3a191f9 in ber_strdup_x (s=0x6a626f28 <Address 0x6a626f28 out of > bounds>, ctx=0x0) at memory.c:640 > #2 0xadd2fd66 in ldap_charray_dup (a=0xb313a324) at charray.c:164 > #3 0xadd26883 in ldap_url_dup (ludp=0x8b83798) at url.c:1191 > #4 0xadd26912 in ldap_url_duplist (ludlist=0x8b83798) at url.c:1217 > #5 0xadd11b34 in ldap_create (ldp=0xb32e0dc8) at open.c:149 > #6 0xadd11de1 in ldap_initialize (ldp=0xb32e0ec0, url=0x8946d20 > "ldap://ldap:389") at open.c:225 Please make sure you're calling the desired library objects (libldap & liblber). Can you post the result of ldd for your application? > I have same thing with the 2.3.38 Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: ldap_int_global_options not initialized (ITS#5109)
by quanah＠zimbra.com 28 Aug '07

28 Aug '07

--On Tuesday, August 28, 2007 3:58 PM +0000 damien.doiselet(a)neolane.com wrote: > Thanks > > My application is multithread. > I've had a call to ldap_get_option(NULL, LDAP_OPT_API_INFO, &ldapi) > before spawning threads, but here the crash occurred also in > ldap_initailize but in ldap_ld_free(). > I addition, I won't call ldap outside my thread. Be careful of the LDAP libraries on debian. If they get loaded, you are in trouble, since they are hacked to touch Gnu TLS, and you'll get all sorts of fun. This all gets resolved once OpenLDAP 2.4 is released. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5110) back-ldap, proxy authentication fails when chasing referrals
by f.huiskens＠science-computing.de 28 Aug '07

28 Aug '07

Full_Name: Florian Huiskens Version: 2.3.30 OS: Ubuntu 7.04 URL: Submission from: (NULL) (85.216.39.101) I try to set up an environment, where a client communicates with an LDAP-Proxy. The Proxy forwards the client's query (using the ldap-backend) to an LDAP-Slave. The authentication mechanism I use (proxy - slave) is SASL (GSSAPI). The proxy has a kerberos ticket available. Proxy Authentication works in general (using PROXAUTHZ), but fails on referrals (though rebind-as-user is set). This means that if information is written and the proxy receives a referral to the master, the bind-informations gets lost. Thanks for any help, regards Florian Config-files: Master: include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel 0 # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_bdb moduleload syncprov # The maximum number of entries that is returned for a search operation sizelimit 500 # The tool-threads parameter sets the actual amount of cpu's that is used # for indexing. tool-threads 1 backend bdb checkpoint 512 30 ####################################################################### # Specific Directives for database #1, of type bdb: # Database specific directives apply to this databasse until another # 'database' directive occurs database bdb suffix "dc=idm,dc=local" # rootdn directive for specifying a superuser on the database. This is needed # for syncrepl. rootdn "dc=idm,dc=local" directory "/var/lib/ldap" dbconfig set_cachesize 0 2097152 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 index objectClass eq # Save the time that the entry gets modified, for database #1 lastmod on access to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=idm,dc=local" write by dn="uid=ldap/extubuntu.idm.local,ou=slaves,dc=idm,dc=local" read by anonymous auth by * none access to dn.base="" by * read access to * by dn="cn=admin,dc=idm,dc=local" write by * read # syncrepl config overlay syncprov syncprov-checkpoint 100 1 syncprov-sessionlog 100 # SASL setup #sasl-host ubuntu-desktop sasl-authz-policy To sasl-secprops minssf=56 sasl-realm idm.local sasl-regexp uid=(.*),cn=idm.local,cn=gssapi,cn=auth ldap:///dc=idm,dc=local??sub?(|(uid=$1)(cn=$1)) Slave: include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel 0 modulepath /usr/lib/ldap moduleload back_bdb sizelimit 500 tool-threads 1 backend bdb checkpoint 512 30 database bdb suffix "dc=idm,dc=local" #rootdn "dc=idm,dc=local" rootdn "dc=nowhere,dc=nouniverse" directory "/var/lib/ldap" dbconfig set_cachesize 0 2097152 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 index objectClass eq lastmod on access to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=idm,dc=local" write by anonymous auth by self write by * none # by dn="cn=repl-admin,dc=idm,dc=local" write access to dn.base="" by * read access to * by dn="cn=admin,dc=idm,dc=local" write by self write by * read # by dn="cn=repl-admin,dc=idm,dc=local" write # by * read syncrepl rid=1 provider=ldap://ubuntu-desktop:389 searchbase="dc=idm,dc=local" type=refreshAndPersist retry="60 10 300 +" bindmethod=sasl saslmethod=GSSAPI updateref ldap://ubuntu-desktop:389 # SASL setup sasl-authz-policy To sasl-secprops minssf=56 sasl-realm idm.local sasl-regexp uid=(.*),cn=idm.local,cn=gssapi,cn=auth ldap:///dc=idm,dc=local??sub?(|(uid=$1)(cn=$1)) Proxy (running on the same host as the Slave): include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel 1 modulepath /usr/lib/ldap moduleload back_ldap database ldap uri ldap://extubuntu.idm.local:390/ suffix "dc=idm,dc=local" chase-referrals yes rebind-as-user yes # SASL setup sasl-secprops minssf=56 sasl-realm idm.local sasl-regexp uid=(.*),cn=idm.local,cn=gssapi,cn=auth ldap:///dc=idm,dc=local??sub?(|(uid=$1)(cn=$1)) idassert-bind bindmethod=sasl mode=self authcid=ldap/extubuntu.idm.local # should come from ticket but does not. Snippets of an ldapsearch: debugging information from the proxy conn=10 fd=9 ACCEPT from IP=127.0.0.1:3380 (IP=0.0.0.0:389) conn=10 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" conn=10 op=0 SRCH attr=supportedSASLMechanisms conn=10 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=10 op=1 BIND dn="" method=163 conn=10 op=2 BIND dn="" method=163 conn=10 op=2 RESULT tag=97 err=14 text= conn=10 op=3 BIND dn="" method=163 conn=10 op=1 RESULT tag=97 err=14 text= request done: ld 0x81dd960 msgid 3 SASL [conn=10] Error: unable to open Berkeley db /etc/sasldb2: No such file or directory conn=10 op=3 BIND authcid="admin(a)idm.local" authzid="admin(a)idm.local" conn=10 op=3 BIND dn="cn=admin,dc=idm,dc=local" mech=GSSAPI ssf=56 conn=10 op=3 RESULT tag=97 err=0 text= conn=10 op=4 SRCH base="dc=idm,dc=local" scope=2 deref=0 filter="(cn=fhuisk)" request done: ld 0x8197038 msgid 1 request done: ld 0x8197038 msgid 2 request done: ld 0x8197038 msgid 3 request done: ld 0x8197038 msgid 4 request done: ld 0x8197038 msgid 5 conn=10 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=10 op=5 UNBIND conn=10 fd=9 closed debugging information from the slave conn=0 op=2 SRCH base="dc=idm,dc=local" scope=2 deref=0 filter="(|(uid=admin)(cn=admin))" conn=0 op=2 SRCH attr=1.1 <= bdb_equality_candidates: (uid) index_param failed (18) <= bdb_equality_candidates: (cn) index_param failed (18) conn=0 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=2 fd=16 ACCEPT from IP=127.0.1.1:2814 (IP=0.0.0.0:390) conn=2 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" conn=2 op=0 SRCH attr=supportedSASLMechanisms conn=2 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=2 op=1 BIND dn="" method=163 conn=2 op=2 BIND dn="" method=163 conn=2 op=2 RESULT tag=97 err=14 text= conn=2 op=3 BIND dn="" method=163 <= bdb_equality_candidates: (uid) index_param failed (18) <= bdb_equality_candidates: (cn) index_param failed (18) SASL [conn=2] Error: unable to open Berkeley db /etc/sasldb2: No such file or directory conn=2 op=3 BIND authcid="ldap/extubuntu.idm.local(a)idm.local" authzid="ldap/extubuntu.idm.local(a)idm.local" conn=2 op=3 BIND dn="uid=ldap/extubuntu.idm.local,ou=slaves,dc=idm,dc=local" mech=GSSAPI ssf=56 conn=2 op=3 RESULT tag=97 err=0 text= conn=2 op=4 PROXYAUTHZ dn="cn=admin,dc=idm,dc=local" conn=2 op=4 SRCH base="dc=idm,dc=local" scope=2 deref=0 filter="(cn=fhuisk)" <= bdb_equality_candidates: (cn) index_param failed (18) conn=2 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=2 op=1 RESULT tag=97 err=14 text= conn=2 op=5 UNBIND conn=2 fd=16 closed ldapsearch call and result root@extUbuntu:/etc/ldap# ldapsearch cn=fhuisk SASL/GSSAPI authentication started SASL username: admin(a)IDM.LOCAL SASL SSF: 56 SASL installing layers # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: cn=fhuisk # requesting: ALL # # fhuisk, users, idm.local dn: cn=fhuisk,ou=users,dc=idm,dc=local uid: fhuisk givenName:: RmxvcmlhbiA= objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson sn: Huiskens cn: fhuisk userPassword:: dGVzdA== # search result search: 5 result: 0 Success # numResponses: 2 # numEntries: 1 root@extUbuntu:/etc/ldap# fyi: ldapwhoami root@extUbuntu:/etc/ldap# ldapwhoami SASL/GSSAPI authentication started SASL username: admin(a)IDM.LOCAL SASL SSF: 56 SASL installing layers dn:cn=admin,dc=idm,dc=local Result: Success (0) root@extUbuntu:/etc/ldap# Snippets of an ldapmodify debugging information from the proxy conn=0 fd=9 ACCEPT from IP=127.0.0.1:3145 (IP=0.0.0.0:389) conn=0 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" conn=0 op=0 SRCH attr=supportedSASLMechanisms conn=0 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=0 op=1 BIND dn="" method=163 conn=0 op=2 BIND dn="" method=163 conn=0 op=2 RESULT tag=97 err=14 text= conn=0 op=3 BIND dn="" method=163 request done: ld 0x81a39f8 msgid 1 conn=0 op=1 RESULT tag=97 err=14 text= request done: ld 0x81a39f8 msgid 2 SASL [conn=0] Error: unable to open Berkeley db /etc/sasldb2: No such file or directory conn=0 op=3 BIND authcid="admin(a)idm.local" authzid="admin(a)idm.local" conn=0 op=3 BIND dn="cn=admin,dc=idm,dc=local" mech=GSSAPI ssf=56 conn=0 op=3 RESULT tag=97 err=0 text= conn=0 op=4 MOD dn="cn=fhuisk,ou=users,dc=idm,dc=local" conn=0 op=4 MOD attr=cn request done: ld 0x8192200 msgid 1 request done: ld 0x8192200 msgid 2 request done: ld 0x8192200 msgid 3 request done: ld 0x8192200 msgid 4 request done: ld 0x8192200 msgid 7 request done: ld 0x8192200 msgid 5 conn=0 op=4 RESULT tag=103 err=47 text=anonymous proxyAuthz not allowed conn=0 op=5 UNBIND conn=0 fd=9 closed debugging information from the slave conn=0 fd=13 ACCEPT from IP=127.0.1.1:2862 (IP=0.0.0.0:390) conn=0 op=0 BIND dn="" method=128 conn=0 op=0 RESULT tag=97 err=0 text= conn=0 op=1 SRCH base="dc=idm,dc=local" scope=2 deref=0 filter="(|(uid=admin)(cn=admin))" conn=0 op=1 SRCH attr=1.1 <= bdb_equality_candidates: (uid) index_param failed (18) <= bdb_equality_candidates: (cn) index_param failed (18) conn=0 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=1 fd=15 ACCEPT from IP=127.0.1.1:2863 (IP=0.0.0.0:390) conn=1 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" conn=1 op=0 SRCH attr=supportedSASLMechanisms conn=1 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=1 op=1 BIND dn="" method=163 conn=1 op=2 BIND dn="" method=163 conn=1 op=3 BIND dn="" method=163 <= bdb_equality_candidates: (uid) index_param failed (18) <= bdb_equality_candidates: (cn) index_param failed (18) SASL [conn=1] Error: unable to open Berkeley db /etc/sasldb2: No such file or directory conn=1 op=3 BIND authcid="ldap/extubuntu.idm.local(a)idm.local" authzid="ldap/extubuntu.idm.local(a)idm.local" conn=1 op=3 BIND dn="uid=ldap/extubuntu.idm.local,ou=slaves,dc=idm,dc=local" mech=GSSAPI ssf=56 conn=1 op=2 RESULT tag=97 err=14 text= conn=1 op=4 PROXYAUTHZ dn="cn=admin,dc=idm,dc=local" conn=1 op=4 MOD dn="cn=fhuisk,ou=users,dc=idm,dc=local" conn=1 op=4 MOD attr=cn conn=1 op=4 RESULT tag=103 err=10 text= conn=1 op=3 RESULT tag=97 err=0 text= conn=1 op=1 RESULT tag=97 err=14 text= conn=1 op=5 UNBIND conn=1 fd=15 closed debugging information from the master conn=1 fd=14 ACCEPT from IP=172.16.82.240:1290 (IP=0.0.0.0:389) conn=1 op=0 BIND dn="" method=128 conn=1 op=0 RESULT tag=97 err=0 text= conn=1 op=1 RESULT tag=103 err=47 text=anonymous proxyAuthz not allowed do_modify: get_ctrls failed conn=1 op=2 UNBIND conn=1 fd=14 closed ldapmodify call and result root@extUbuntu:/etc/ldap# ldapmodify SASL/GSSAPI authentication started SASL username: admin(a)IDM.LOCAL SASL SSF: 56 SASL installing layers dn: cn=fhuisk,ou=users,dc=idm,dc=local changetype: modify add: cn cn: newCN - modifying entry "cn=fhuisk,ou=users,dc=idm,dc=local" ldapmodify: Proxy Authorization Failure (47) additional info: anonymous proxyAuthz not allowed root@extUbuntu:/etc/ldap#

1 0

Re: ldap_int_global_options not initialized (ITS#5109)
by damien.doiselet＠neolane.com 28 Aug '07

28 Aug '07

Thanks My application is multithread. I've had a call to ldap_get_option(NULL, LDAP_OPT_API_INFO, &ldapi) before spawning threads, but here the crash occurred also in ldap_initailize but in ldap_ld_free(). I addition, I won't call ldap outside my thread. The full stack trace is : #0 0xb7e93473 in strlen () from /lib/tls/i686/cmov/libc.so.6 #1 0xb3a191f9 in ber_strdup_x (s=0x6a626f28 <Address 0x6a626f28 out of bounds>, ctx=0x0) at memory.c:640 #2 0xadd2fd66 in ldap_charray_dup (a=0xb313a324) at charray.c:164 #3 0xadd26883 in ldap_url_dup (ludp=0x8b83798) at url.c:1191 #4 0xadd26912 in ldap_url_duplist (ludlist=0x8b83798) at url.c:1217 #5 0xadd11b34 in ldap_create (ldp=0xb32e0dc8) at open.c:149 #6 0xadd11de1 in ldap_initialize (ldp=0xb32e0ec0, url=0x8946d20 "ldap://ldap:389") at open.c:225 I have same thing with the 2.3.38 Damien Doiselet Pierangelo Masarati a écrit : > Only issues occurring with either the latest release (now 2.3.28) or HEAD code > ought to be considered, as they might be related to already known and perhaps > solved problems. Please check with a fresh build from 2.3.28. > > In the meanwhile, it might be worth checking: > > - is your application multithread? > > - in case it is, is the first call to a libldap routine occurring __before__ > starting multiple threads, or after? If after, then fix your project by adding > a call to an LDAP routine (e.g. ldap_set_option() with an option that does not > require a LDAP* handle) __before__ spawning threads. > > - can you test your development using a libldap library containing debug > symbols, in order to provide helpful information? > > p. >

1 0

Re: Does libldap.so.2 still exist in the latest version of open-ldap,and if not, what could other applications link to instead?
by Gavin Henry 28 Aug '07

28 Aug '07

<quote who="Oliver de Peyer"> > Well, put it this way, it's not a bug with OpenLDAP but it > is a bug with PINE. This seemed like the most appropriate > list to post to though since maybe an OpenLDAP user could > suggest a workaround. Ok, but we don't provide support for 3rd Party software integration with OpenLDAP and refer users to the appropriate mailing lists. > Most people would be used to installing Linux applications > just using .rpms and will be flummoxed by dependency > problems, especially if they are home users. The problem is > that PINE needs a library, libldap.so.2, that the more > recent versions of OpenLDAP no longer supplies. If there is > any easy workaround that the OpenLDAP community can suggest > as a workaround, then PINE users would be very grateful. The work around would be to get upstream to update there lib dependancies. > But to be absolutely clear, yes, it's definitely PINE's bug > not OpenLDAP's! Of course! ;-) But please, seek help on their lists, there's nothing more we can do to help, as it's not a bug with our software. > > In answer to your second suggestion, yes, if you know what > you're doing it is quite easily to compile from the PINE > source and omit OpenLDAP - you can put NOLDAP as a suffix > on the relevant build command. That's what I did in the > end. Understood. > This doesn't help people who are used to just using .rpms > though and it doesn't help people who actually want to use > OpenLDAP with PINE. Well, we distribute in source, so we don't provide RPMs. RPMs are supplied for convience by distros, as you know. > > I would have posted this to PINE lists as you suggest, but > as far as I could make out they don't have email lists per > se but only newsgroups. And one of the things I wanted to > use PINE was to post to newsgroups... but I couldn't get > PINE to work... All things are pointing towards not using PINE then ;-) > I'll post to their newsgroup from my PC at work, but in the > meantime, if anybody on this list has any ideas about > solving this problem from and OpenLDAP perspective, then > I'd be very grateful. They look pretty active to me: http://www.washington.edu/pine/pine-info/ http://mailman1.u.washington.edu/pipermail/pine-info/ http://marc.info/?l=pine-info&w=2&r=1&s=libldap&q=b Gavin.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs