openldap-technical August 2010

openldap-technical@openldap.org

83 participants
85 discussions

ldapadd Naming Violation error 64
by Raymond Norton 03 Aug '10

03 Aug '10

Ubuntu server 10.0.4, ldap 2.4.21 I am getting the following error when attempting to use the ldapadd command: sudo ldapadd -Y EXTERNAL -H ldapi:/// -f db.ldif (error) adding new entry "cn=module{0},cn=config" ldap_add: Naming violation (64) db.ldif: # Load modules for database type dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb # Create directory database dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=2190-db,dc=org olcRootDN: cn=admin,dc=isd2190-db,dc=org olcRootPW: 1234 olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=isd2190-db,dc=org" write by anonymous auth by self write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by dn="cn=admin,dc=isd2190-db,dc=org" write by * read olcLastMod: TRUE olcDbCheckpoint: 512 30 olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbIndex: uid pres,eq olcDbIndex: cn,sn,mail pres,eq,approx,sub olcDbIndex: objectClass eq ################################################## ######### # DEFAULTS MODIFICATION ################################################## ######### # Some of the defaults need to be modified in order to allow # remote access to the LDAP config. Otherwise only root # will have administrative access. dn: cn=config changetype: modify delete: olcAuthzRegexp dn: olcDatabase={-1}frontend,cn=config changetype: modify delete: olcAccess dn: olcDatabase={0}config,cn=config changetype: modify add: olcRootPW olcRootPW: {CRYPT}7hzU8RaZxaGi2 dn: olcDatabase={0}config,cn=config changetype: modify delete: olcAccess

3 4

Query: simple authenticated bind request
by Vinay Kalkoti 03 Aug '10

03 Aug '10

Hi, I am trying to setup OpenLDAP client with user/password authenticated bind to authenticate against an OpenLDAP server. This is how my /etc/ldap.conf look like host xx.xx.xx.xx base dc=my_comp,dc=com bind_policy soft pam_lookup_policy yes pam_password exop nss_initgroups_ignoreusers root,ldap nss_schema rfc2307bis nss_map_attribute uniqueMember member ldap_version 3 pam_filter objectClass=posixAccount tls_checkpeer no #ssl on ssl no binddn cn=Administrator,dc=my_comp,dc=com <============ I am giving the root DN bindpw Administrator scope sub If I give the root DN, it works, But, if I give a non-root DN in binddn, I get "invalid credentials (49)" error. Does OpenLDAP server always require root DN for binding ?. Is there a way to provide non-root DN for binddn ? Thanks, Vinay

1 0

How to properly initialize the LDAP client library
by Ian Anderson 03 Aug '10

03 Aug '10

I'm using both libldap and libsasl2 in my application on Mac OS X. libldap itself uses libsasl2 internally on that platform, and it changes some of the libsasl2 globals (namely the mutex functions) during its initialization. My app uses libldap only in response to user actions, so libldap initialization happens at a fairly random time. This means the libsasl2 globals end up changing on me after I've been using libsasl2 for awhile in my app's lifecycle, and I end up getting random crashes because the mutex functions are all different from when I initially created the sasl client connection. So, my solution to this was to initialize libldap myself on app launch so that it can set up the libsasl2 environment as it wants to. I looked at the manual page for ldap(3) and ldap_initialize(3), and they seemed to suggest that I should use ldap_get_option to initialize OpenLDAP. Which option should I ask for though? I tried LDAP_OPT_API_INFO, but that ends up doing a DNS query which can really balloon my launch time depending on my network configuration. Is there a better option I could do that basically does nothing but initialize a few innocuous OpenLDAP globals without doing a significant amount of work? Ian

1 0

ldap_start_tls: Connect error (-11)
by Russell Knighton 02 Aug '10

02 Aug '10

Hi Everyone, I'm trying to set-up an new openldap service utilising TLS. At the moment, it all appears to work fine with out TLS, but unfortunately it always fails with it. The service is running on neptune.mps.lan (with a CNAME for ldap), and my client desktop box is called blacktip. The server is Ubuntu 10.04 LTS server, and the desktop is also Ubuntu 10.04; both with latest updates. I have created a Self signed CA and, after setting up the server keys, I have installed this onto the client. I then added the following line to the client /etc/ldap.conf: TLS_CACERT /etc/ssl/certs/slapd-ca-cert.pem This is the command I am running to test the connection: root@blacktip:~# ldapsearch -d 16383 -x -h ldap.mps.lan -ZZ -b dc=mps,dc=lan ldap_create ldap_url_parse_ext(ldap://ldap.mps.lan) 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 ldap.mps.lan:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.0.0.203: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=0x7f1965937630 ptr=0x7f1965937630 end=0x7f196593764f len=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 ber_scanf fmt ({) ber: ber_dump: buf=0x7f1965937630 ptr=0x7f1965937635 end=0x7f196593764f len=26 0000: 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e w...1.3.6.1.4.1. 0010: 31 34 36 36 2e 32 30 30 33 37 1466.20037 ber_flush2: 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 0x7f196592f3a0 msgid 1 wait4msg ld 0x7f196592f3a0 msgid 1 (infinite timeout) wait4msg continue ld 0x7f196592f3a0 msgid 1 all 1 ** ld 0x7f196592f3a0 Connections: * host: ldap.mps.lan port: 389 (default) refcnt: 2 status: Connected last used: Mon Aug 2 16:48:35 2010 ** ld 0x7f196592f3a0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x7f196592f3a0 request count 1 (abandoned 0) ** ld 0x7f196592f3a0 Response Queue: Empty ld 0x7f196592f3a0 response count 0 ldap_chkResponseList ld 0x7f196592f3a0 msgid 1 all 1 ldap_chkResponseList returns ld 0x7f196592f3a0 NULL ldap_int_select read1msg: ld 0x7f196592f3a0 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: ber_dump: buf=0x7f1965938e50 ptr=0x7f1965938e50 end=0x7f1965938e5c len=12 0000: 02 01 01 78 07 0a 01 00 04 00 04 00 ...x........ read1msg: ld 0x7f196592f3a0 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: ber_dump: buf=0x7f1965938e50 ptr=0x7f1965938e53 end=0x7f1965938e5c len=9 0000: 78 07 0a 01 00 04 00 04 00 x........ read1msg: ld 0x7f196592f3a0 0 new referrals read1msg: mark request completed, ld 0x7f196592f3a0 msgid 1 request done: ld 0x7f196592f3a0 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ber_dump: buf=0x7f1965938e50 ptr=0x7f1965938e53 end=0x7f1965938e5c len=9 0000: 78 07 0a 01 00 04 00 04 00 x........ ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x7f1965938e50 ptr=0x7f1965938e53 end=0x7f1965938e5c len=9 0000: 78 07 0a 01 00 04 00 04 00 x........ ber_scanf fmt (}) ber: ber_dump: buf=0x7f1965938e50 ptr=0x7f1965938e5c end=0x7f1965938e5c len=0 ldap_msgfree tls_write: want=93, written=93 0000: 16 03 02 00 58 01 00 00 54 03 02 4c 56 e8 d3 01 ....X...T..LV... 0010: 2e bb 5d b7 71 7e ec ab 4c e0 6a 32 63 85 76 88 ..].q~..L.j2c.v. 0020: b9 12 b3 fc e3 56 fe 2a db 9a 0d 00 00 24 00 33 .....V.*.....$.3 0030: 00 45 00 39 00 88 00 16 00 32 00 44 00 38 00 87 .E.9.....2.D.8.. 0040: 00 13 00 66 00 2f 00 41 00 35 00 84 00 0a 00 05 ...f./.A.5...... 0050: 00 04 01 00 00 07 00 09 00 03 02 00 01 ............. tls_read: want=5, got=0 TLS: can't connect: A TLS packet with unexpected length was received.. ldap_err2string ldap_start_tls: Connect error (-11) additional info: A TLS packet with unexpected length was received. As you can see, the TLS connection fails to negotiate. I have extensively googled this error but have not yet found a cause nor a solution. OpenLDAP server version: root@neptune:~# slapd -V @(#) $OpenLDAP: slapd 2.4.21 (Apr 26 2010 11:08:43) $ buildd@yellow:/build/buildd/openldap-2.4.21/debian/build/servers/slapd Gnutls Library Version: root@neptune:~# aptitude show libgnutls26 | grep ^Ver Version: 2.8.5-2 Many thanks in advance for any help/advice given. Kind Regards, Russell Knighton --

2 3

Replication and uniqueness overlay
by Ondrej Kuznik 02 Aug '10

02 Aug '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, is there a way to disable uniqueness checking for replicated content? Our problem is that we have a database with no uniqueness checking and when trying to replicate to an enforcing one, it rejects the first offending entry and makes both nodes trying to restart the replication again and again, eating both traffic and cpu capacity. Thanks, Ondra Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxWsI8ACgkQ9GWxeeH+cXszhQCgpKo28Yas1/LEJ8vWqFl8SzB/ VzAAn1IwVwZQdY0bommYNa2LesqkZa7N =Ing2 -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical August 2010