openldap-technical

openldap-technical@openldap.org

18 participants
9801 discussions

Bug ? ldap_start_tls_s successful even after removing ca certificate from ca cert dir
by SOMA SEKHAR 26 Aug '14

26 Aug '14

link to question on stackoverflow <http://stackoverflow.com/questions/25457034/starttls-succesful-even-after-d…> I'm having trouble verifying the correct behavior of my software. Here are the steps I am performing to verify correct operation: 1. I have sample code that uses openldap library and doing a start tls to a ldap server. 2. I have set the global option for ca cert directory and tlx context for the first time. 3. After that I did ldap init and ldap start tls to a server. This is succesful as expected. 4. I did an ldap_unbind_s 5. I deleted the CA cert that signed the ldap server's certificate from the ca cert directory of the client. 6. Again did ldap_init and ldap_start_tls_s . 7. I expected this call to fail , as I have removed the ca cert. But what I observe is that , server sends the certificate but start_tls is returning success. I am using openldap 2.4 with libssl.0.9.8 LDAP *ld;int desired_version=3; if ((ld = ldap_init(<hostname>, <server_port>)) == NULL ) { printf("ldap_init failed\n"); exit(0);} ldap_set_option(ld, LDAP_OPT_PROTOCOL_VERSION, &desired_version); ldap_set_option(NULL, LDAP_OPT_X_TLS_CTX, NULL); ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTDIR,"<ca dir>"); if(ldap_start_tls_s(ld, NULL, NULL) != LDAP_SUCCESS){ printf("start tls failed.\n"); exit(0);} ...... <do bind and search>... ldap_unbind_s(ld); ... // DELETE the CA certificate from the ca dir. // Try to do start tls again if ((ld = ldap_init(hostname, server_port)) == NULL ) { printf("ldap_init failed , after deleting CA\n"); exit(0);} // This goes fine even after deleting the CAif (ldap_start_tls_s(ld, NULL, NULL) != LDAP_SUCCESS){ printf("start tls failed after deleting CA.\n"); exit(0);} -- Thanks&Regards, SomaSekhar.

1 1

ldapi:/// without TLS; ldap:// with TLS?
by Tom 26 Aug '14

26 Aug '14

I'm running OpenLDAP 2.4 on CentOS. I'm trying to set it up so clients can use the ldapi:/// socket without TLS, but any clients using ldap:// must use TLS. I believe that the relevant olc variables are olcLocalSSF and olcSecurity. I can't get it to work - either TLS is required no matter which URI I use, or clients can connect without TLS at all. According to the docs, if I set olcLocalSSF to 128, and olcSecurity to ssf=128, it should work, but it's not. I can only connect without TLS if I delete the olcSecurity attribute, which allows anyone to connect without TLS. What am I dong wrong?

2 3

a lot of dnMatch msgs after do_syncrep2
by Daniel Jung 26 Aug '14

26 Aug '14

openldap-2.4.39 with lmdb backend running on centos 6.4. This occurred on one of the consumers and other consumers didnt have any issue. I was running args,stats and sync loglevel, and I see the following in the log. Each do_syncrep2 shows dnMatch. The contextcsn got out of sync and I used slapd -c to resync it and it looks ok now. Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_delete_keys: 226c [7a441664] Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_delete_keys: 226c Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_delete_keys: 226c Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_insert_keys: 226c [eebf38e5] Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_insert_keys: 226c Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_insert_keys: 226c Aug 25 03:45:02 servernameslapd[16312]: send_ldap_result: err=0 matched="" text="" Aug 25 03:45:02 servernameslapd[16312]: mdb_modify: dc=server,dc=com Aug 25 03:45:02 servernameslapd[16312]: mdb_modify_internal: replace contextCSN Aug 25 03:45:02 servernameslapd[16312]: send_ldap_result: err=0 matched="" text="" Aug 25 03:45:02 servernameslapd[16312]: slap_graduate_commit_csn: removing 0x7fc0185aa630 20140825014502.251709Z#000000#001#000000 Aug 25 03:45:02 servernameslapd[16312]: syncrepl_entry: rid=703 be_modify cn=cname,ou=Group,dc=server,dc=com (0) Aug 25 03:45:02 servernameslapd[16312]: slap_queue_csn: queing 0x7fc01859e320 20140825014502.251709Z#000000#001#000000 Aug 25 03:45:02 servernameslapd[16312]: mdb_modify: dc=server,dc=com Aug 25 03:45:02 servernameslapd[16312]: mdb_modify_internal: replace contextCSN Aug 25 03:45:02 servernameslapd[16312]: send_ldap_result: err=0 matched="" text="" Aug 25 03:45:02 servernameslapd[16312]: slap_graduate_commit_csn: removing 0x7fc01850f060 20140825014502.251709Z#000000#001#000000 Aug 25 03:45:02 servernameslapd[16312]: connection_get(12) Aug 25 03:45:02 servernameslapd[16312]: do_syncrep2: rid=703 cookie=rid=703,sid=001,csn=20140825014502.428281Z#000000#001#000000 Aug 25 03:45:02 servernameslapd[16312]: syncrepl_message_to_entry: rid=703 DN: cn=development,ou=somegroup,dc=server,dc=com, UUID: a06de85e-b545-102d-9482-cde2fff247a7 Aug 25 03:45:02 servernameslapd[16312]: dnMatch -3 Aug 25 03:45:02 servernameslapd[16312]: dnMatch 1 Aug 25 03:45:02 servernameslapd[16312]: dnMatch -3 Aug 25 03:45:02 servernameslapd[16312]: dnMatch -2 <snip>

1 1

How can I add ldap user from linux shell command line?
by Tian Zhiying 26 Aug '14

26 Aug '14

Hi All How can I add ldap user from linux shell command line? And how can I batch add ldap user from linux shell command line? Tian Zhiying

3 2

Getting the memberof overlay to work
by Karel Vervaeke 26 Aug '14

26 Aug '14

Hi. I've followed a number of memberof tutorials/howto guides, but I can't get it to work. I've tried to document my best attempt yet in this github repository: https://github.com/karel1980/openldap-memberof There is an installation script which: - installs slapd - sets up a new database - configures memberof and refint overlays - restarts slapd - adds groups and users There's also a sample query which should return memberOf attributes, but it does not. If you can spot the error of my ways, please enlighten me. Regards, Karel

1 1

Converting BDB database from 4.8 to 4.5.
by Markus Moeller 25 Aug '14

25 Aug '14

I have an openldap server using libdb-4.5, but somehow my OS had db-utils for 4.8 and I guess I run the wrong commands as I now get the following error when starting the server. Is there a way to "downgrade" to 4.5 ? Unacceptable log file /var/lib/ldap/log.0000000001: unsupported log version 16 Thank you Markus

4 4

(no subject)
by Meunier, Antonin 25 Aug '14

25 Aug '14

Hello, In my openldap with mdb I imported a ldif that made add and modify (1000 objects). 95% of the file is processed in 2 minutes without problems. 5% of the rest of file is porcessed in more than 1 hour. The problem is on the groupOfName with lots of member (more than 1000 members). Each modify can take between 3 and 10 minutes. My Openldap is MMR with 2 servers. The problem appears only on one of the two ldap server. On the second one, each modification take 2 seconds. I've tried a reindex of the member attribute but nothing change. I've tried a delete and reimport (ldif file from the second server) the ldap and the problem persist. The configurations are the same on the 2 servers. What can explain this huge time to modify a group ? Exemple of a modification in my ldif file : dn: cn=522495,ou=groupes,ou=XXXXXX,dc=xxxxx,dc=fr changetype: modify add: member member: uid=2142279020,ou=personnes,ou= XXXXXX,dc= xxxxx,dc=fr dn: cn=522813, ou=groupes,ou=XXXXXX,dc=xxxxx,dc=fr changetype: modify add: member member: uid=1021253020,ou=personnes,ou= XXXXXX,dc= xxxxx,dc=fr Thanks a lot by advance Antonin Meunier

3 3

idassert-authzFrom ignored
by Charles Bueche 22 Aug '14

22 Aug '14

Hi, I have an OpenLDAP proxy using back_meta to talk to two back-ends Microsoft AD servers. My goal is to provide a single view of both AD trees. Basically, it works, as long as I use a bind account which exists in one of the back-end AD's. However, to first search where an AD account is, I would like to use a local account on the LDAP proxy. To my understanding, I need to use database meta suffix dc=proxy,dc=stuff,dc=ch rootdn "cn=root,dc=proxy,dc=stuff,dc=ch" rootpw "secret" subordinate ... idassert-bind bindmethod=simple binddn="CN=srvLDAP,..." credentials="..." mode=none flags=non-prescriptive idassert-authzFrom "dn.exact:cn=root,dc=proxy,dc=stuff,dc=ch" The DN "cn=root,dc=proxy,dc=stuff,dc=ch" does exist in the proxy and can do local searches. However, the account defined in the idassert is never used, and the connections to the back-ends AD's fail. Respectively, I think they are contacted using anonymous instead of the account I specify (not sure about the anonymous part, the debug log isn't very clear about it). Hints welcome. Below is a part of the relevant log if it helps. Charles .......... tls_read: want=64, got=64 0000: 65 87 ac 08 7e 49 8d 7f 95 3c d0 1f 09 57 b7 ce e...~I...<...W.. 0010: d4 13 2e ac 57 c9 27 6b 58 f7 76 70 a1 95 10 3e ....W.'kX.vp...> 0020: e2 96 0d cf a1 d3 13 ff e7 0b b1 2f c0 6f dc 19 .........../.o.. 0030: 93 38 07 b9 f7 e4 81 a8 e0 45 0e 97 ec 7f 21 a6 .8.......E....!. TLS trace: SSL_connect:SSLv3 read finished A ldap_int_poll: fd: -1 tm: 0 53679e3b conn=1000 op=1 <<< meta_search_dobind_init[0]=4 53679e3b conn=1000 op=1 <<< meta_back_search_start[0]=4 53679e3b conn=1000 op=1 meta_back_search: ncandidates=1 cnd="*" 53679e3b conn=1000 op=1 >>> meta_search_dobind_init[0] ldap_sasl_bind ldap_send_initial_request ldap_int_poll: fd: 12 tm: 0 ldap_is_sock_ready: 12 ldap_ndelay_off: 12 TLS trace: SSL_connect:before/connect initialization tls_write: want=225, written=225 0000: 16 03 01 00 dc 01 00 00 d8 03 02 53 67 9e 3b 55 ...........Sg.;U 0010: 4b 2f ee 53 01 81 ee ca 6a 3f a0 ea 85 3a c9 7e K/.S....j?...:.~ 0020: e3 01 d7 e6 d1 09 65 14 21 05 ef 00 00 66 c0 14 ......e.!....f.. 0030: c0 0a c0 22 c0 21 00 39 00 38 00 88 00 87 c0 0f ...".!.9.8...... 0040: c0 05 00 35 00 84 c0 12 c0 08 c0 1c c0 1b 00 16 ...5............ 0050: 00 13 c0 0d c0 03 00 0a c0 13 c0 09 c0 1f c0 1e ................ 0060: 00 33 00 32 00 9a 00 99 00 45 00 44 c0 0e c0 04 .3.2.....E.D.... 0070: 00 2f 00 96 00 41 c0 11 c0 07 c0 0c c0 02 00 05 ./...A.......... 0080: 00 04 00 15 00 12 00 09 00 14 00 11 00 08 00 06 ................ 0090: 00 03 00 ff 01 00 00 49 00 0b 00 04 03 00 01 02 .......I........ 00a0: 00 0a 00 34 00 32 00 0e 00 0d 00 19 00 0b 00 0c ...4.2.......... 00b0: 00 18 00 09 00 0a 00 16 00 17 00 08 00 06 00 07 ................ 00c0: 00 14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 ................ 00d0: 00 03 00 0f 00 10 00 11 00 23 00 00 00 0f 00 01 .........#...... 00e0: 01 . TLS trace: SSL_connect:SSLv3 write client hello A tls_read: want=5 error=Connection reset by peer TLS trace: SSL_connect:error in SSLv3 read server hello A TLS: can't connect: . ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 12 0000: 30 05 02 01 03 42 00 0....B. ldap_write: want=7 error=Broken pipe ldap_free_connection: actually freed 53679e3b conn=1000 op=1 <<< meta_search_dobind_init[0]=0 53679e3b send_ldap_result: conn=1000 op=1 p=3 53679e3b send_ldap_result: err=0 matched="" text="" 53679e3b send_ldap_result: conn=1000 op=1 p=3 53679e3b send_ldap_result: err=0 matched="" text="" 53679e3b send_ldap_response: msgid=2 tag=101 err=0 ber_flush2: 14 bytes to sd 11 0000: 30 0c 02 01 02 65 07 0a 01 00 04 00 04 00 0....e........ tls_write: want=69, written=69

1 1

Re : RE24 testing call (2.4.40)
by "POISSON Frédéric" 22 Aug '14

22 Aug '14

Hello, I have tested with success the rev 55eddb0 on an RHEL 5.3 x86_64. I also copy a small test file (starting from a copy of the 051) in order to check if the new code correct the ITS#7822 "Segmentation fault while modifying olcDbMaxSize". The test file (see attachment) succeed like this : # ./run -b mdb test065-config-update Cleaning up test run directory leftover from previous run. Running ./scripts/test065-config-update for mdb... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Check the olcDbMaxSize dn: olcDatabase={1}mdb,cn=config olcDbMaxSize: 10485760 Dynamically updating the olcDbMaxSize Re-check the olcDbMaxSize dn: olcDatabase={1}mdb,cn=config olcDbMaxSize: 123456789 >>>>> Test succeeded While if i run the same test on release 2.4.39 and older it fail with a seg fault. I'm not sure that this is a good test for future release of openldap but if you agree, the ITS#7822 could be closed if release 2.4.40 of openldap has the same behavior :-). Thanks a lot, Regards, Le 11/08/14 20:58, Quanah Gibson-Mount <quanah(a)zimbra.com> a écrit : > > If you know how to build OpenLDAP manually, and would like to participate in testing the next set of code for the 2.4.39 release, please do so. > > Generally, get the code for RE24: > > <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> > > Configure & build. > > Execute the test suite (via make test) after it is built. > > Thanks! > > --Quanah > > > -- > Quanah Gibson-Mount > Server Architect > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > > -- Frederic Poisson

1 0

Accesslog: Excluding attributes from logging
by Oriol Rosa Ramoneda 22 Aug '14

22 Aug '14

4 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical