openldap-technical

openldap-technical@openldap.org

3 participants
9937 discussions

back-sql configuration
by Chris Card 30 May '11

30 May '11

I am trying to set up openldap to use back-sql and mysql (currently on Fedora 14 with packages openldap-servers-sql-2.4.23-4.fc14.x86_64, openldap-2.4.23-4.fc14.x86_64, openldap-clients-2.4.23-4.fc14.x86_64, openldap-servers-2.4.23-4.fc14.x86_64). Is it true that to do this openldap must use the old slapd.conf method rather than the newer dynamic configuration method using slapd.d? I can get back-sql working using config from /etc/openldap/slapd.conf, but when I try to create the equivalent config under slapd.d I can't see any where to put the equivalent of dbname, subtree_cond etc., and I see a warning "No dynamic config support for database sql". If it *is* true that slapd.conf must be used for back-sql config, can openldap use slapd.conf and slapd.d config at the same time, or must all the openldap config come from slapd.conf? Chris

3 3

How to write an overlay that perform search from within an overlay?
by hptf 30 May '11

30 May '11

Hello all, I am trying to write an overlay that is able to get the previous/old values of an Entity, before it is updated by a modify/delete. For that purpose, my first tries were to use a search from within the overlay, or pre-read. I try many method, (inspired by existing overlay), but none seems to work for now: - use of pre-read seems to be very complicated; moreover, pre-read ctrl seems to be returned as already ber-encoded, meaning that I need to re-decode the ber to get the value ... this is (too) expensive - use of search from within overlay raise, for now, some problems: * if using translucent like call to 'be_entry_get_rw' I got deadlock on hdb * if using rc = nop->o_bd->be_search(nop,&nrs); from within overlay, it seems that response is sent also to remote client socket, and not stay confined to overlay call ( and, btw, I fail to get the result: rs->sr_un.sru_search.r_entry is NULL ) I, for sure, miss something. Do you have any clue, example, advice that may help me to continue ? Thanks in advance for your help. hp tf PS: This is a repost in the good mailing list, initial message post in openldap-devel(a)openldap.org, sorry for the inconvenience.

2 1

Fail to test uid of OpenLDAP with TLS...
by Nguyen, Quoc Khanh 29 May '11

29 May '11

Hi all, Please help me about this problem... I want to use testsaslauthd to test uid of OpenLDAP with TLS, but it fail... Here is my config: /usr/local/etc/saslauthd.conf: ldap_servers: ldap://localhost ldap_bind_dn: cn=admin,dc=abc,dc=com ldap_bind_pw: 123456789 ldap_search_base: dc=abc,dc=com ldap_start_tls: yes ldap_tls_cacert_dir: /var/myCA ldap_tls_cacert_file: /var/myCA/cacert.crt ldap_debug: -1 start LDAP: root@ldap:~# /usr/local/openldap/libexec/slapd -h 'ldap:///' start saslauthd: root@ldap:~# /usr/local/sasl2/sbin/saslauthd -a ldap -O /usr/local/etc/saslauthd.conf -d saslauthd[765] :main : num_procs : 5 saslauthd[765] :main : mech_option: /usr/local/etc/saslauthd.conf saslauthd[765] :main : run_path : /var/run saslauthd[765] :main : auth_mech : ldap saslauthd[765] :ipc_init : using accept lock file: /var/run/mux.accept saslauthd[765] :detach_tty : master pid is: 0 saslauthd[765] :ipc_init : listening on socket: /var/run/mux saslauthd[765] :main : using process model saslauthd[765] :have_baby : forked child: 766 saslauthd[765] :have_baby : forked child: 767 saslauthd[765] :have_baby : forked child: 768 saslauthd[765] :have_baby : forked child: 769 saslauthd[765] :get_accept_lock : acquired accept lock test uid: root@ldap:~# /usr/local/sasl2/sbin/testsaslauthd -u khanhnq -p 123456 0: NO "authentication failed" I have a debug result: saslauthd[765] :rel_accept_lock : released accept lock saslauthd[767] :get_accept_lock : acquired accept lock 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 localhost:389 ldap_new_socket: 10 ldap_prepare_socket: 10 ldap_connect_to_host: Trying ::1 389 ldap_pvt_connect: fd: 10 tm: 5 async: 0 ldap_ndelay_on: 10 ldap_int_poll: fd: 10 tm: 5 ldap_is_sock_ready: 10 ldap_ndelay_off: 10 ldap_pvt_connect: 0 ldap_open_defconn: successful ldap_send_server_request ldap_result ld 0x9cef220 msgid 1 wait4msg ld 0x9cef220 msgid 1 (infinite timeout) wait4msg continue ld 0x9cef220 msgid 1 all 1 ** ld 0x9cef220 Connections: * host: localhost port: 389 (default) refcnt: 2 status: Connected last used: Fri May 27 16:40:05 2011 ** ld 0x9cef220 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x9cef220 request count 1 (abandoned 0) ** ld 0x9cef220 Response Queue: Empty ld 0x9cef220 response count 0 ldap_chkResponseList ld 0x9cef220 msgid 1 all 1 ldap_chkResponseList returns ld 0x9cef220 NULL ldap_int_select read1msg: ld 0x9cef220 msgid 1 all 1 read1msg: ld 0x9cef220 msgid 1 message type extended-result read1msg: ld 0x9cef220 0 new referrals read1msg: mark request completed, ld 0x9cef220 msgid 1 request done: ld 0x9cef220 msgid 1 res_errno: 0, res_error: , res_matched: ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ldap_parse_result ldap_msgfree TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 0, subject: /CN=abc.com/ST=HCM/C=VN/emailAddress=root(a)abc.com/O=SGT/OU=NW Department, issuer: /CN=abc.com/ST=HCM/C=VN/emailAddress=root(a)abc.com/O=SGT/OU=NW Department TLS certificate verification: depth: 0, err: 7, subject: /CN=abc.com/ST=HCM/C=VN/emailAddress=root(a)abc.com/O=SGT/OU=NW, issuer: /CN=abc.com/ST=HCM/C=VN/emailAddress=root(a)abc.com/O=SGT/OU=NW Department TLS certificate verification: Error, certificate signature failure TLS trace: SSL3 alert write:fatal:decrypt error TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect: error:14090086:SSL routines:func(144):reason(134) (certificate signature failure). ldap_err2string ldap_unbind ldap_free_connection 1 1 ldap_send_unbind ldap_free_connection: actually freed saslauthd[765] :do_auth : auth failure: [user=khanhnq] [service=imap] [realm=] [mech=ldap] [reason=Unknown] saslauthd[765] :do_request : response: NO What i'm doing wrong? I think my TLS is OK... Here is my ldapsearch result: root@ldap:/usr/local/openldap/bin# ./ldapsearch -xLL -b dc=abc,dc=com uid=khanhnq -d -1 ldap_create ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP abc.com:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying ::1 389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x9023e88 ptr=0x9023e88 end=0x9023e96 len=14 0000: 30 0c 02 01 01 60 07 02 01 03 04 00 80 00 0....`........ ber_scanf fmt ({i) ber: ber_dump: buf=0x9023e88 ptr=0x9023e8d end=0x9023e96 len=9 0000: 60 07 02 01 03 04 00 80 00 `........ ber_flush2: 14 bytes to sd 3 0000: 30 0c 02 01 01 60 07 02 01 03 04 00 80 00 0....`........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 60 07 02 01 03 04 00 80 00 0....`........ ldap_result ld 0x901b540 msgid 1 wait4msg ld 0x901b540 msgid 1 (infinite timeout) wait4msg continue ld 0x901b540 msgid 1 all 1 ** ld 0x901b540 Connections: * host: abc.com port: 389 (default) refcnt: 2 status: Connected last used: Fri May 27 16:42:21 2011 ** ld 0x901b540 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x901b540 request count 1 (abandoned 0) ** ld 0x901b540 Response Queue: Empty ld 0x901b540 response count 0 ldap_chkResponseList ld 0x901b540 msgid 1 all 1 ldap_chkResponseList returns ld 0x901b540 NULL ldap_int_select read1msg: ld 0x901b540 msgid 1 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 01 61 07 0a 0....a.. ldap_read: want=6, got=6 0000: 01 00 04 00 04 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0x9025488 ptr=0x9025488 end=0x9025494 len=12 0000: 02 01 01 61 07 0a 01 00 04 00 04 00 ...a........ read1msg: ld 0x901b540 msgid 1 message type bind ber_scanf fmt ({eAA) ber: ber_dump: buf=0x9025488 ptr=0x902548b end=0x9025494 len=9 0000: 61 07 0a 01 00 04 00 04 00 a........ read1msg: ld 0x901b540 0 new referrals read1msg: mark request completed, ld 0x901b540 msgid 1 request done: ld 0x901b540 msgid 1 res_errno: 0, res_error: , res_matched: ldap_free_request (origid 1, msgid 1) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x9025488 ptr=0x902548b end=0x9025494 len=9 0000: 61 07 0a 01 00 04 00 04 00 a........ ber_scanf fmt (}) ber: ber_dump: buf=0x9025488 ptr=0x9025494 end=0x9025494 len=0 ldap_msgfree version: 1 ldap_search_ext put_filter: "uid=khanhnq" put_filter: default put_simple_filter: "uid=khanhnq" ldap_build_search_req ATTRS: * ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x9023e88 ptr=0x9023e88 end=0x9023ebf len=55 0000: 30 35 02 01 02 63 30 04 0d 64 63 3d 61 62 63 2c 05...c0..dc=abc, 0010: 64 63 3d 63 6f 6d 0a 01 02 0a 01 00 02 01 00 02 dc=com.......... 0020: 01 00 01 01 00 a3 0e 04 03 75 69 64 04 07 6b 68 .........uid..kh 0030: 61 6e 68 6e 71 30 00 anhnq0. ber_scanf fmt ({) ber: ber_dump: buf=0x9023e88 ptr=0x9023e8d end=0x9023ebf len=50 0000: 63 30 04 0d 64 63 3d 61 62 63 2c 64 63 3d 63 6f c0..dc=abc,dc=co 0010: 6d 0a 01 02 0a 01 00 02 01 00 02 01 00 01 01 00 m............... 0020: a3 0e 04 03 75 69 64 04 07 6b 68 61 6e 68 6e 71 ....uid..khanhnq 0030: 30 00 0. ber_flush2: 55 bytes to sd 3 0000: 30 35 02 01 02 63 30 04 0d 64 63 3d 61 62 63 2c 05...c0..dc=abc, 0010: 64 63 3d 63 6f 6d 0a 01 02 0a 01 00 02 01 00 02 dc=com.......... 0020: 01 00 01 01 00 a3 0e 04 03 75 69 64 04 07 6b 68 .........uid..kh 0030: 61 6e 68 6e 71 30 00 anhnq0. ldap_write: want=55, written=55 0000: 30 35 02 01 02 63 30 04 0d 64 63 3d 61 62 63 2c 05...c0..dc=abc, 0010: 64 63 3d 63 6f 6d 0a 01 02 0a 01 00 02 01 00 02 dc=com.......... 0020: 01 00 01 01 00 a3 0e 04 03 75 69 64 04 07 6b 68 .........uid..kh 0030: 61 6e 68 6e 71 30 00 anhnq0. ldap_result ld 0x901b540 msgid -1 wait4msg ld 0x901b540 msgid -1 (infinite timeout) wait4msg continue ld 0x901b540 msgid -1 all 0 ** ld 0x901b540 Connections: * host: abc.com port: 389 (default) refcnt: 2 status: Connected last used: Fri May 27 16:42:21 2011 ** ld 0x901b540 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x901b540 request count 1 (abandoned 0) ** ld 0x901b540 Response Queue: Empty ld 0x901b540 response count 0 ldap_chkResponseList ld 0x901b540 msgid -1 all 0 ldap_chkResponseList returns ld 0x901b540 NULL ldap_int_select read1msg: ld 0x901b540 msgid -1 all 0 ber_get_next ldap_read: want=8, got=8 0000: 30 82 01 13 02 01 02 64 0......d ldap_read: want=271, got=271 0000: 82 01 0c 04 28 63 6e 3d 4b 68 61 6e 68 20 4e 67 ....(cn=Khanh Ng 0010: 75 79 65 6e 2c 6f 75 3d 6e 65 74 77 6f 72 6b 2c uyen,ou=network, 0020: 64 63 3d 61 62 63 2c 64 63 3d 63 6f 6d 30 81 df dc=abc,dc=com0.. 0030: 30 1e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0...objectClass1 0040: 0f 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e ...inetOrgPerson 0050: 30 27 04 02 63 6e 31 21 04 0c 4b 68 61 6e 68 20 0'..cn1!..Khanh 0060: 4e 67 75 79 65 6e 04 11 4b 68 61 6e 68 20 4e 67 Nguyen..Khanh Ng 0070: 75 79 65 6e 20 51 75 6f 63 30 0d 04 02 73 6e 31 uyen Quoc0...sn1 0080: 07 04 05 4b 68 61 6e 68 30 10 04 03 75 69 64 31 ...Khanh0...uid1 0090: 09 04 07 6b 68 61 6e 68 6e 71 30 18 04 0c 75 73 ...khanhnq0...us 00a0: 65 72 50 61 73 73 77 6f 72 64 31 08 04 06 31 32 erPassword1...12 00b0: 33 34 35 36 30 48 04 04 6d 61 69 6c 31 40 04 0f 34560H..mail1@.. 00c0: 6b 68 61 6e 68 6e 71 40 61 62 63 2e 63 6f 6d 04 khanhnq(a)abc.com [1]. 00d0: 12 6e 71 6b 32 38 37 30 33 40 79 61 68 6f 6f 2e .nqk28703@yahoo. 00e0: 63 6f 6d 04 19 6b 68 61 6e 68 6e 71 40 73 61 69 com..khanhnq@sai 00f0: 67 6f 6e 74 65 63 68 2e 65 64 75 2e 76 6e 30 0f gontech.edu.vn0. 0100: 04 02 6f 75 31 09 04 07 6e 65 74 77 6f 72 6b ..ou1...network ber_get_next: tag 0x30 len 275 contents: ber_dump: buf=0x90255f0 ptr=0x90255f0 end=0x9025703 len=275 0000: 02 01 02 64 82 01 0c 04 28 63 6e 3d 4b 68 61 6e ...d....(cn=Khan 0010: 68 20 4e 67 75 79 65 6e 2c 6f 75 3d 6e 65 74 77 h Nguyen,ou=netw 0020: 6f 72 6b 2c 64 63 3d 61 62 63 2c 64 63 3d 63 6f ork,dc=abc,dc=co 0030: 6d 30 81 df 30 1e 04 0b 6f 62 6a 65 63 74 43 6c m0..0...objectCl 0040: 61 73 73 31 0f 04 0d 69 6e 65 74 4f 72 67 50 65 ass1...inetOrgPe 0050: 72 73 6f 6e 30 27 04 02 63 6e 31 21 04 0c 4b 68 rson0'..cn1!..Kh 0060: 61 6e 68 20 4e 67 75 79 65 6e 04 11 4b 68 61 6e anh Nguyen..Khan 0070: 68 20 4e 67 75 79 65 6e 20 51 75 6f 63 30 0d 04 h Nguyen Quoc0.. 0080: 02 73 6e 31 07 04 05 4b 68 61 6e 68 30 10 04 03 .sn1...Khanh0... 0090: 75 69 64 31 09 04 07 6b 68 61 6e 68 6e 71 30 18 uid1...khanhnq0. 00a0: 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 31 08 ..userPassword1. 00b0: 04 06 31 32 33 34 35 36 30 48 04 04 6d 61 69 6c ..1234560H..mail 00c0: 31 40 04 0f 6b 68 61 6e 68 6e 71 40 61 62 63 2e 1@..khanhn [2]q@abc. 00d0: 63 6f 6d 04 12 6e 71 6b 32 38 37 30 33 40 79 61 com..nqk28703@ya 00e0: 68 6f 6f 2e 63 6f 6d 04 19 6b 68 61 6e 68 6e 71 hoo.com..khanhnq 00f0: 40 73 61 69 67 6f 6e 74 65 63 68 2e 65 64 75 2e @saigontech.edu. 0100: 76 6e 30 0f 04 02 6f 75 31 09 04 07 6e 65 74 77 vn0...ou1...netw 0110: 6f 72 6b ork read1msg: ld 0x901b540 msgid 2 message type search-entry ldap_get_dn_ber ber_scanf fmt ({ml{) ber: ber_dump: buf=0x90255f0 ptr=0x90255f3 end=0x9025703 len=272 0000: 64 82 01 0c 04 28 63 6e 3d 4b 68 61 6e 68 20 4e d....(cn=Khanh N 0010: 67 75 79 65 6e 2c 6f 75 3d 6e 65 74 77 6f 72 6b guyen,ou=network 0020: 2c 64 63 3d 61 62 63 2c 64 63 3d 63 6f 6d 30 81 ,dc=abc,dc=com0. 0030: df 30 1e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 .0...objectClass 0040: 31 0f 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 1...inetOrgPerso 0050: 6e 30 27 04 02 63 6e 31 21 04 0c 4b 68 61 6e 68 n0'..cn1!..Khanh 0060: 20 4e 67 75 79 65 6e 04 11 4b 68 61 6e 68 20 4e Nguyen..Khanh N 0070: 67 75 79 65 6e 20 51 75 6f 63 30 0d 04 02 73 6e guyen Quoc0...sn 0080: 31 07 04 05 4b 68 61 6e 68 30 10 04 03 75 69 64 1...Khanh0...uid 0090: 31 09 04 07 6b 68 61 6e 68 6e 71 30 18 04 0c 75 1...khanhnq0...u 00a0: 73 65 72 50 61 73 73 77 6f 72 64 31 08 04 06 31 serPassword1...1 00b0: 32 33 34 35 36 30 48 04 04 6d 61 69 6c 31 40 04 234560H..mail1@. 00c0: 0f 6b 68 61 6e 68 6e 71 40 61 62 63 2e 63 6f 6d .khanhnq(a)abc.com 00d0: 04 12 6e 71 6b 32 38 37 30 33 40 79 61 68 6f 6f ..nqk28703@yahoo 00e0: 2e 63 6f 6d 04 19 6b 68 61 6e 68 6e 71 40 73 61 .com..khanhnq@sa 00f0: 69 67 6f 6e 74 65 63 68 2e 65 64 75 2e 76 6e 30 igontech.edu.vn0 0100: 0f 04 02 6f 75 31 09 04 07 6e 65 74 77 6f 72 6b ...ou1...network dn: cn=Khanh Nguyen,ou=network,dc=abc,dc=com ber_scanf fmt ({xx) ber: ber_dump: buf=0x90255f0 ptr=0x90255f3 end=0x9025703 len=272 0000: 64 82 01 0c 04 28 63 6e 3d 4b 68 61 6e 68 20 4e d....(cn=Khanh N 0010: 67 75 79 65 6e 2c 6f 75 3d 6e 65 74 77 6f 72 6b guyen,ou=network 0020: 2c 64 63 3d 61 62 63 2c 64 63 3d 63 6f 6d 00 81 ,dc=abc,dc=com.. 0030: df 30 1e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 .0...objectClass 0040: 31 0f 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 1...inetOrgPerso 0050: 6e 30 27 04 02 63 6e 31 21 04 0c 4b 68 61 6e 68 n0'..cn1!..Khanh 0060: 20 4e 67 75 79 65 6e 04 11 4b 68 61 6e 68 20 4e Nguyen..Khanh N 0070: 67 75 79 65 6e 20 51 75 6f 63 30 0d 04 02 73 6e guyen Quoc0...sn 0080: 31 07 04 05 4b 68 61 6e 68 30 10 04 03 75 69 64 1...Khanh0...uid 0090: 31 09 04 07 6b 68 61 6e 68 6e 71 30 18 04 0c 75 1...khanhnq0...u 00a0: 73 65 72 50 61 73 73 77 6f 72 64 31 08 04 06 31 serPassword1...1 00b0: 32 33 34 35 36 30 48 04 04 6d 61 69 6c 31 40 04 234560H..mail1@. 00c0: 0f 6b 68 61 6e 68 6e 71 40 61 62 63 2e 63 6f 6d .khanhnq(a)abc.com 00d0: 04 12 6e 71 6b 32 38 37 30 33 40 79 61 68 6f 6f ..nqk28703@yahoo 00e0: 2e 63 6f 6d 04 19 6b 68 61 6e 68 6e 71 40 73 61 .com..khanhnq@sa 00f0: 69 67 6f 6e 74 65 63 68 2e 65 64 75 2e 76 6e 30 igontech.edu.vn0 0100: 0f 04 02 6f 75 31 09 04 07 6e 65 74 77 6f 72 6b ...ou1...network ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x90255f0 ptr=0x9025624 end=0x9025703 len=223 0000: 30 1e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0...objectClass1 0010: 0f 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e ...inetOrgPerson 0020: 30 27 04 02 63 6e 31 21 04 0c 4b 68 61 6e 68 20 0'..cn1!..Khanh 0030: 4e 67 75 79 65 6e 04 11 4b 68 61 6e 68 20 4e 67 Nguyen..Khanh Ng 0040: 75 79 65 6e 20 51 75 6f 63 30 0d 04 02 73 6e 31 uyen Quoc0...sn1 0050: 07 04 05 4b 68 61 6e 68 30 10 04 03 75 69 64 31 ...Khanh0...uid1 0060: 09 04 07 6b 68 61 6e 68 6e 71 30 18 04 0c 75 73 ...khanhnq0...us 0070: 65 72 50 61 73 73 77 6f 72 64 31 08 04 06 31 32 erPassword1...12 0080: 33 34 35 36 30 48 04 04 6d 61 69 6c 31 40 04 0f 34560H..mail1@.. 0090: 6b 68 61 6e 68 6e 71 40 61 62 63 2e 63 6f 6d 04 khanhnq(a)abc.com [3]. 00a0: 12 6e 71 6b 32 38 37 30 33 40 79 61 68 6f 6f 2e .nqk28703@yahoo. 00b0: 63 6f 6d 04 19 6b 68 61 6e 68 6e 71 40 73 61 69 com..khanhnq@sai 00c0: 67 6f 6e 74 65 63 68 2e 65 64 75 2e 76 6e 30 0f gontech.edu.vn0. 00d0: 04 02 6f 75 31 09 04 07 6e 65 74 77 6f 72 6b ..ou1...network objectClass: inetOrgPerson ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x90255f0 ptr=0x9025644 end=0x9025703 len=191 0000: 00 27 04 02 63 6e 31 21 04 0c 4b 68 61 6e 68 20 .'..cn1!..Khanh 0010: 4e 67 75 79 65 6e 04 11 4b 68 61 6e 68 20 4e 67 Nguyen..Khanh Ng 0020: 75 79 65 6e 20 51 75 6f 63 30 0d 04 02 73 6e 31 uyen Quoc0...sn1 0030: 07 04 05 4b 68 61 6e 68 30 10 04 03 75 69 64 31 ...Khanh0...uid1 0040: 09 04 07 6b 68 61 6e 68 6e 71 30 18 04 0c 75 73 ...khanhnq0...us 0050: 65 72 50 61 73 73 77 6f 72 64 31 08 04 06 31 32 erPassword1...12 0060: 33 34 35 36 30 48 04 04 6d 61 69 6c 31 40 04 0f 34560H..mail1@.. 0070: 6b 68 61 6e 68 6e 71 40 61 62 63 2e 63 6f 6d 04 khanhnq(a)abc.com [4]. 0080: 12 6e 71 6b 32 38 37 30 33 40 79 61 68 6f 6f 2e .nqk28703@yahoo. 0090: 63 6f 6d 04 19 6b 68 61 6e 68 6e 71 40 73 61 69 com..khanhnq@sai 00a0: 67 6f 6e 74 65 63 68 2e 65 64 75 2e 76 6e 30 0f gontech.edu.vn0. 00b0: 04 02 6f 75 31 09 04 07 6e 65 74 77 6f 72 6b ..ou1...network cn: Khanh Nguyen cn: Khanh Nguyen Quoc ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x90255f0 ptr=0x902566d end=0x9025703 len=150 0000: 00 0d 04 02 73 6e 31 07 04 05 4b 68 61 6e 68 30 ....sn1...Khanh0 0010: 10 04 03 75 69 64 31 09 04 07 6b 68 61 6e 68 6e ...uid1...khanhn 0020: 71 30 18 04 0c 75 73 65 72 50 61 73 73 77 6f 72 q0...userPasswor 0030: 64 31 08 04 06 31 32 33 34 35 36 30 48 04 04 6d d1...1234560H..m 0040: 61 69 6c 31 40 04 0f 6b 68 61 6e 68 6e 71 40 61 ail1@..khanhn [5]q@a 0050: 62 63 2e 63 6f 6d 04 12 6e 71 6b 32 38 37 30 33 bc.com..nqk28703 0060: 40 79 61 68 6f 6f 2e 63 6f 6d 04 19 6b 68 61 6e @yahoo.com..khan 0070: 68 6e 71 40 73 61 69 67 6f 6e 74 65 63 68 2e 65 hnq(a)saigontech.e 0080: 64 75 2e 76 6e 30 0f 04 02 6f 75 31 09 04 07 6e du.vn0...ou1...n 0090: 65 74 77 6f 72 6b etwork sn: Khanh ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x90255f0 ptr=0x902567c end=0x9025703 len=135 0000: 00 10 04 03 75 69 64 31 09 04 07 6b 68 61 6e 68 ....uid1...khanh 0010: 6e 71 30 18 04 0c 75 73 65 72 50 61 73 73 77 6f nq0...userPasswo 0020: 72 64 31 08 04 06 31 32 33 34 35 36 30 48 04 04 rd1...1234560H.. 0030: 6d 61 69 6c 31 40 04 0f 6b 68 61 6e 68 6e 71 40 mail1@..khanhn [6]q@ 0040: 61 62 63 2e 63 6f 6d 04 12 6e 71 6b 32 38 37 30 abc.com..nqk2870 0050: 33 40 79 61 68 6f 6f 2e 63 6f 6d 04 19 6b 68 61 3@yahoo.com..kha [7] 0060: 6e 68 6e 71 40 73 61 69 67 6f 6e 74 65 63 68 2e nhnq@saigontech. 0070: 65 64 75 2e 76 6e 30 0f 04 02 6f 75 31 09 04 07 edu.vn0...ou1... 0080: 6e 65 74 77 6f 72 6b network uid: khanhnq ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x90255f0 ptr=0x902568e end=0x9025703 len=117 0000: 00 18 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 ....userPassword 0010: 31 08 04 06 31 32 33 34 35 36 30 48 04 04 6d 61 1...1234560H..ma 0020: 69 6c 31 40 04 0f 6b 68 61 6e 68 6e 71 40 61 62 il1@..khanhn [8]q@ab 0030: 63 2e 63 6f 6d 04 12 6e 71 6b 32 38 37 30 33 40 c.com..nqk28703@ 0040: 79 61 68 6f 6f 2e 63 6f 6d 04 19 6b 68 61 6e 68 yahoo.com..khanh 0050: 6e 71 40 73 61 69 67 6f 6e 74 65 63 68 2e 65 64 nq(a)saigontech.ed [9] 0060: 75 2e 76 6e 30 0f 04 02 6f 75 31 09 04 07 6e 65 u.vn0...ou1...ne 0070: 74 77 6f 72 6b twork userPassword:: MTIzNDU2 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x90255f0 ptr=0x90256a8 end=0x9025703 len=91 0000: 00 48 04 04 6d 61 69 6c 31 40 04 0f 6b 68 61 6e .H..mail1@..khan 0010: 68 6e 71 40 61 62 63 2e 63 6f 6d 04 12 6e 71 6b hnq@abc.com..nqk [10] 0020: 32 38 37 30 33 40 79 61 68 6f 6f 2e 63 6f 6d 04 28703(a)yahoo.com [11]. 0030: 19 6b 68 61 6e 68 6e 71 40 73 61 69 67 6f 6e 74 .khanhnq@saigont 0040: 65 63 68 2e 65 64 75 2e 76 6e 30 0f 04 02 6f 75 ech.edu.vn0...ou 0050: 31 09 04 07 6e 65 74 77 6f 72 6b 1...network mail: khanhnq(a)abc.com [12] mail: nqk28703(a)yahoo.com [13] mail: khanhnq(a)saigontech.edu.vn [14] ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x90255f0 ptr=0x90256f2 end=0x9025703 len=17 0000: 00 0f 04 02 6f 75 31 09 04 07 6e 65 74 77 6f 72 ....ou1...networ 0010: 6b k ou: network ldap_get_attribute_ber ldap_msgfree ldap_result ld 0x901b540 msgid -1 wait4msg ld 0x901b540 msgid -1 (infinite timeout) wait4msg continue ld 0x901b540 msgid -1 all 0 ** ld 0x901b540 Connections: * host: abc.com port: 389 (default) refcnt: 2 status: Connected last used: Fri May 27 16:42:21 2011 ** ld 0x901b540 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x901b540 request count 1 (abandoned 0) ** ld 0x901b540 Response Queue: Empty ld 0x901b540 response count 0 ldap_chkResponseList ld 0x901b540 msgid -1 all 0 ldap_chkResponseList returns ld 0x901b540 NULL ldap_int_select read1msg: ld 0x901b540 msgid -1 all 0 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 02 65 07 0a 0....e.. ldap_read: want=6, got=6 0000: 01 00 04 00 04 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0x90252d8 ptr=0x90252d8 end=0x90252e4 len=12 0000: 02 01 02 65 07 0a 01 00 04 00 04 00 ...e........ read1msg: ld 0x901b540 msgid 2 message type search-result ber_scanf fmt ({eAA) ber: ber_dump: buf=0x90252d8 ptr=0x90252db end=0x90252e4 len=9 0000: 65 07 0a 01 00 04 00 04 00 e........ read1msg: ld 0x901b540 0 new referrals read1msg: mark request completed, ld 0x901b540 msgid 2 request done: ld 0x901b540 msgid 2 res_errno: 0, res_error: , res_matched: ldap_free_request (origid 2, msgid 2) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x90252d8 ptr=0x90252db end=0x90252e4 len=9 0000: 65 07 0a 01 00 04 00 04 00 e........ ber_scanf fmt (}) ber: ber_dump: buf=0x90252d8 ptr=0x90252e4 end=0x90252e4 len=0 ldap_msgfree ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 0000: 30 05 02 01 03 42 00 0....B. ldap_write: want=7, written=7 0000: 30 05 02 01 03 42 00 0....B. ldap_free_connection: actually freed Please help, Best Regards, -- *********************************** EVERYTHING HAS JUST BEGUN... Links: ------ [1] mailto:khanhnq@abc.com [2] mailto:1@..khanhn [3] mailto:khanhnq@abc.com [4] mailto:khanhnq@abc.com [5] mailto:ail1@..khanhn [6] mailto:mail1@..khanhn [7] mailto:3@yahoo.com..kha [8] mailto:il1@..khanhn [9] mailto:nq@saigontech.ed [10] mailto:hnq@abc.com..nqk [11] mailto:28703@yahoo.com [12] mailto:khanhnq@abc.com [13] mailto:nqk28703@yahoo.com [14] mailto:khanhnq@saigontech.edu.vn

2 1

Should multiple cn entries in a dn be accepted?
by Ian Collins 27 May '11

27 May '11

I am trying to import data from another server into OpenLDAP and I've hit a snag with some dns which contain multiple cn entries: cn=Services_PM_Champions,cn=Services_PM_Team,ou=groups,o=staff,dc=client ADD is failing with error 32 (No such object): conn=1005 op=1236 ADD dn="cn=Service.Admin,ou=groups,o=staff,dc=client" conn=1005 op=1236 RESULT tag=105 err=0 text= conn=1005 op=1237 ADD dn="cn=Services_PM_Champions,cn=Services_PM_Team,ou=groups,o=staff,dc=client" conn=1005 op=1237 RESULT tag=105 err=32 text= Should this be accepted? -- Ian.

3 4

New consumer replication issues
by Christopher Strider Cook 26 May '11

26 May '11

I've got a mirrormode cluster of 2.4.25 running and using test059 as an example I had setup a script that would create new consumers of this cluster. It worked fine.. until now. Now when I run it I seem to run into, what I can only describe as, an ordering problem with the initial replication. The server is replicating parts of cn=config over but seems to complain because of an syntax check. Am I missing some flag in the sync or do entyCSNs need to be in a particular order...or am I missing something else altogether? Hear are some logs and configs In this case it looks like a needed schema wasn't synced first: May 26 15:02:49 ramones slapd[10377]: syncrepl_message_to_entry: rid=001 mods check (olcSuffix: value #0 invalid per syntax) May 26 15:02:49 ramones slapd[10377]: do_syncrepl: rid=001 rc 21 retrying And here I tried to sync the schema specifically and it errors on not understanding the creatorsName, because the database that contains it hasn't been synced yet: May 26 14:58:10 ramones slapd[7260]: syncrepl_message_to_entry: rid=001 mods check (creatorsName: value #0 invalid per syntax) May 26 14:58:10 ramones slapd[7260]: do_syncrepl: rid=001 rc 21 retrying Here is a debug: ==> rewrite_context_apply [depth=1] string='olcDatabase={1}hdb,cn=config,cn=slave' ==> rewrite_rule_apply rule='(.*)cn=config,cn=slave$' string='olcDatabase={1}hdb,cn=config,cn=slave' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'olcDatabase={1}hdb,cn=config'} ber_scanf fmt ({mW}) ber: ber_dump: buf=0xb155b0 ptr=0xb16005 end=0xb16046 len=65 0000: 30 23 04 11 73 75 62 73 63 68 65 6d 61 53 75 62 0#..subschemaSub 0010: 65 6e 74 72 79 31 0e 04 0c 63 6e 3d 53 75 62 73 entry1...cn=Subs 0020: 63 68 65 6d 61 30 1a 04 0f 68 61 73 53 75 62 6f chema0...hasSubo 0030: 72 64 69 6e 61 74 65 73 31 07 04 05 46 41 4c 53 rdinates1...FALS 0040: 45 E ==> rewrite_context_apply [depth=1] string='cn=Subschema' ==> rewrite_rule_apply rule='(.*)cn=config,cn=slave$' string='cn=Subschema' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'cn=Subschema'} ber_scanf fmt ({mW}) ber: ber_dump: buf=0xb155b0 ptr=0xb1602a end=0xb16046 len=28 0000: 30 1a 04 0f 68 61 73 53 75 62 6f 72 64 69 6e 61 0...hasSubordina 0010: 74 65 73 31 07 04 05 46 41 4c 53 45 tes1...FALSE >>> dnPretty: <dc=savagebeast,dc=com> => ldap_bv2dn(dc=savagebeast,dc=com,0) <= ldap_bv2dn(dc=savagebeast,dc=com)=0 syncrepl_message_to_entry: rid=001 mods check (olcSuffix: value #0 invalid per syntax) ldap_msgfree And here is the consumer's olcDatabase={0}config.ldif before the sync starts-- dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config structuralObjectClass: olcDatabaseConfig entryUUID: 3ff5aef4-ff02-102f-8945-2f8fc203546c creatorsName: cn=admin,cn=config createTimestamp: 20110419185450Z olcRootDN: cn=admin,cn=config olcRootPW:: xxx olcSyncrepl: {0}rid=001 provider=ldaps://ldap.savagebeast.com binddn="cn= admin,cn=config,cn=slave" bindmethod=simple credentials=xxx searchbase="cn= config,cn=slave" type=refreshAndPersist retry="60 +" timeout=3 suffixmassage= "cn=config" schemachecking=off entryCSN: 20110420231921.726316Z#000000#001#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20110420231921Z And here is the consumer's olcDatabase={0}config.ldif at the point it fails. dn: olcDatabase={0}config objectClass: olcDatabaseConfig olcDatabase: {0}config structuralObjectClass: olcDatabaseConfig entryUUID: 3ff5aef4-ff02-102f-8945-2f8fc203546c creatorsName: cn=admin,cn=config createTimestamp: 20110419185450Z olcRootDN: cn=admin,cn=config olcRootPW:: xxx olcUpdateRef: ldaps://ldap.savagebeast.com olcSyncrepl: {0}rid=001 provider=ldaps://guess-who.savagebeast.com binddn="cn= admin,cn=config,cn=slave" bindmethod=simple credentials=xxx searchbase="cn= config,cn=slave" schemachecking=off type=refreshAndPersist retry="60 +" timeo ut=3 suffixmassage="cn=config" entryCSN: 20110526212623.826014Z#000000#001#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20110526212623Z -- and here it is on the provider dn: olcDatabase={0}config,cn=config,cn=slave objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootDN: cn=admin,cn=config olcRootPW: {SHA}/xxx olcSyncrepl: {0}rid=001 provider=ldaps://guess-who.savagebeast.com binddn="c n=admin,cn=config,cn=slave" bindmethod=simple credentials=xxx searchbase= "cn=config,cn=slave" schemachecking=off type=refreshAndPersist retry="60 +" timeout=3 suffixmassage="cn=config" olcUpdateRef: ldaps://ldap.savagebeast.com createTimestamp: 20110419185450Z creatorsName: cn=admin,cn=config entryCSN: 20110526212623.826014Z#000000#001#000000 entryDN: olcDatabase={0}config,cn=config,cn=slave entryUUID:: M2ZmNWFlZjQtZmYwMi0xMDJmLTg5NDUtMmY4ZmMyMDM1NDZj hasSubordinates: FALSE modifiersName: cn=admin,cn=config modifyTimestamp: 20110526212623Z structuralObjectClass: olcDatabaseConfig subschemaSubentry: cn=Subschema Thanks for reading this far down!

1 0

Syncrep size limit exceeded
by Darouichi, Aziz 26 May '11

26 May '11

Hi, After configuring Openldap -2.4.23 Multi-master Syncrep with TLS. Replication never completes, log shows slapd[13578]: do_syncrep2: rid=003 (4) Size limit exceeded. This is slapd.conf syncrepl rid=002 provider=ldap://xxx.xxx.xxx tls_cert=/etc/pki/tls/certs/ldapcert.pem tls_key=/etc/pki/tls/private/ldapkey.pem tls_cacert=/etc/pki/tls/certs/ldapcert.pem tls_reqcert=demand searchbase="dc=establishment,dc=edu" schemachecking=on timelimit=unlimited sizelimit=unlimited type=refreshAndPersist retry="60 +" Thanks,

3 2

OpenLdap Proxy for testing network behaviour
by Echedey Lorenzo 26 May '11

26 May '11

Hi, I need to simulate 3 OpenLdaps instances. I was thinking about using a proxy that could listen to 3 different ports and route all the packets to the the standard 389 in which OpenLdap is listening. The proxy should be capable of open/close these ports dinamically and also throw custom error codes. I would like someone to point me in the right direction to start working. Thanks a lot

2 2

Schemas design
by jm.rodriguez＠andaluciajunta.es 25 May '11

25 May '11

Hi, I have doubts when designing new schemes. What advantages and drawbacks exist when creating a new structural objectclass with attributes that inherit from other basic attributes or define auxiliary objectclass with attributes completely new ? Is it harmful to define new attributes or objectclass assigning oids? Thanks. -- Jose Manuel Rodriguez Caro jm.rodriguez(a)andaluciajunta.es

1 0

Openldap ssl with translucent proxy
by joaosf 24 May '11

24 May '11

Hi all, I'm trying to configure a ldap server proxy with overlay translucent, in this way I can add group's to users on the default Ldap Server. Everything is ok until I try to use the SSL: Ldap Server (solaris)<----(389 ldap)---> My Openladap proxy <------(389 ldap)---> Client (everything ok) When I try to use certificates and secure Ldap, I have a problem: Ldap Server (solaris)<----(389 ldap)---> My Openladap proxy <------(636 ldaps)---> Client (still ok) But I have no success when I try to configure the 636 ldaps between main Ldap server (on solaris) and my openldap proxy :( the answer is "No such user". My slapd.conf on my openldap proxy: database bdb suffix "dc=mycompany,dc=pt" rootdn "cn=Admin,dc=mycompany,dc=pt" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. # rootpw secret # rootpw {crypt}ijFYNcSNctBYg rootpw {SSHA}blablabla overlay translucent #uri ldaps://solaris_ldap_server02:636 uri ldaps://solaris_ldap_server01:636 #uri ldap://solaris_ldap_server01 #uri ldap://solaris_ldap_server02 So, if I use the "uri ldap://solaris_ldap_server01" everything is ok and wonderful but if I want something more secure like "uri ldaps://solaris_ldap_server01:636" I got a "No such user" grrrrrr. The beautifull part is that I have all certificates and I can use wiht success the ldapsearch (636 ldaps) against the solaris_ldap_server from my openldap proxy and/or from my linux client, like: ldapsearch -H ldaps://solaris_ldap_server01:636 -x -b "dc=mycompany,dc=pt" And if I configure a Linux client to connect directly to Solaris Server on port 636 ldaps (without my proxy), everything is ok and no problem. When I put a tcpdump running on my Ldap Proxy the Solaris server answer with a "TLSv1 Record Layer: Alert (Level: Fatal, Description: Unknown CA)" but this is bull sheet, I have the correct certificate other way I was not able to do search querys. The big question is, why the "overlay translucent" (proxy) does not work on secure mode? what I'm doing wrong?

1 0

Re: (ITS#6666) Feature Request: Triggers implementation
by Buchan Milne 24 May '11

24 May '11

On Thursday, 7 October 2010 20:32:49 Nick Milas wrote: > It all started for me when I wanted to watch a serial number value from > an ldap-stored SOArecord (using powerdns with openldap backend) and when > it changes to fire a bash script. I reached the conclusion it was not > easy to be done with higher-level means within openldap and I created a > bash script which scans (using ldapsearch and other linux tools) the > SOArecords regularly (using cron) to find out if any change has happend > and do whatever is required. It would be much more elegant if I could > get a trigger from openldap when the SOArecord changes. Maybe you need this: http://memberwebs.com/stef/software/slapi-dnsnotify/ A more generic solution would be nice, but as far as I can tell, this software satisfies your current need. Regards, Buchan

7 18

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical