- openldap-bugs - openldap.org

(ITS#7443) Data range of index_intlen
by tixu＠cs.ucsd.edu 17 Nov '12

17 Nov '12

Full_Name: Tianyin Xu Version: 2.4.33 OS: Ubuntu 12.04 (actually doesn't matter) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2607:f720:1300:1241:590b:49c:889f:7b21) Hi, all, I suggest to make the verbosity upon changing users' configuration settings, especially some of the configuration specifications are not written in the manpage. It's too strong to assume that all the users carefully read the source code. This can save users' time to diagnose why slapd does not behave as their expectation. This ITS is for the "index_intlen" directive. ---------- What the manpage says ---------- index_intlen <integer> Specify the key length for ordered integer indices. The most significant bytes of the binary integer will be used for index keys. The default value is 4, which provides exact indexing for 31 bit values. A floating point representation is used to index too large values. ------------------------------------------------------ Actually, 4 is not only the default value but also the minimum value. From the source code, I knew the index_intlen is with the data range [4, 255]. Any out-of-range value will be converted to the boundaries without notifying users. Here's the patch I proposed: --- ../openldap-2.4.33/servers/slapd/bconfig.c 2012-10-10 05:18:49.000000000 -0700 +++ servers/slapd/bconfig.c 2012-11-16 14:10:40.111362005 -0800 @@ -1754,10 +1754,16 @@ break; case CFG_IX_INTLEN: - if ( c->value_int < SLAP_INDEX_INTLEN_DEFAULT ) + if ( c->value_int < SLAP_INDEX_INTLEN_DEFAULT ) { + snprintf( c->cr_msg, sizeof(c->cr_msg), "index_intlen=%d smaller than minimum value %d --> auto convert to the minimum.", c->value_int, SLAP_INDEX_INTLEN_DEFAULT); + Debug(LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->cr_msg, 0); c->value_int = SLAP_INDEX_INTLEN_DEFAULT; - else if ( c->value_int > 255 ) + } + else if ( c->value_int > 255 ) { + snprintf( c->cr_msg, sizeof(c->cr_msg), "index_intlen=%d larger than maximum value 255 --> auto convert to the maximum.", c->value_int); + Debug(LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->cr_msg, 0); c->value_int = 255; + } index_intlen = c->value_int; index_intlen_strlen = SLAP_INDEX_INTLEN_STRLEN( index_intlen );

1 0

(ITS#7442) Data range of index_intlen
by tixu＠cs.ucsd.edu 17 Nov '12

17 Nov '12

Full_Name: Tianyin Xu Version: 2.4.33 OS: Ubuntu 12.04 (actually doesn't matter) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2607:f720:1300:1241:590b:49c:889f:7b21) Hi, all, I suggest to make the verbosity upon changing users' configuration settings, especially some of the configuration specifications are not written in the manpage. It's too strong to assume that all the users carefully read the source code. This can save users' time to diagnose why slapd does not behave as their expectation. This ITS is for the "index_intlen" directive. ---------- What the manpage says ---------- index_intlen <integer> Specify the key length for ordered integer indices. The most significant bytes of the binary integer will be used for index keys. The default value is 4, which provides exact indexing for 31 bit values. A floating point representation is used to index too large values. ------------------------------------------------------ Actually, 4 is not only the default value but also the minimum value. From the source code, I knew the index_intlen is with the data range [4, 255]. Any out-of-range value will be converted to the boundaries without notifying users. Here's the patch I proposed: --- ../openldap-2.4.33/servers/slapd/bconfig.c 2012-10-10 05:18:49.000000000 -0700 +++ servers/slapd/bconfig.c 2012-11-16 14:10:40.111362005 -0800 @@ -1754,10 +1754,16 @@ break; case CFG_IX_INTLEN: - if ( c->value_int < SLAP_INDEX_INTLEN_DEFAULT ) + if ( c->value_int < SLAP_INDEX_INTLEN_DEFAULT ) { + snprintf( c->cr_msg, sizeof(c->cr_msg), "index_intlen=%d smaller than minimum value %d --> auto convert to the minimum.", c->value_int, SLAP_INDEX_INTLEN_DEFAULT); + Debug(LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->cr_msg, 0); c->value_int = SLAP_INDEX_INTLEN_DEFAULT; - else if ( c->value_int > 255 ) + } + else if ( c->value_int > 255 ) { + snprintf( c->cr_msg, sizeof(c->cr_msg), "index_intlen=%d larger than maximum value 255 --> auto convert to the maximum.", c->value_int); + Debug(LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->cr_msg, 0); c->value_int = 255; + } index_intlen = c->value_int; index_intlen_strlen = SLAP_INDEX_INTLEN_STRLEN( index_intlen );

1 0

(ITS#7441) cn=config filters ignore {number}
by h.b.furuseth＠usit.uio.no 16 Nov '12

16 Nov '12

Full_Name: Hallvard B Furuseth Version: 2.4.33 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:700:100:556::233) Submitted by: hallvard cn=config ignores the {number} prefix in filters: "(olcDatabase={2}hdb)" -> matches all HDB databases "(olcdatabase={2})" -> none ldapcompare does the opposite: "olcdatabase:{2}hdb" -> TRUE (at DN olcdatabase={2}hdb,cn=config) "olcdatabase:{2} -> FALSE "olcdatabase:hdb" -> FALSE

1 0

Re: (ITS#7428) libldap: use non-blocking IO during TLS handshake
by rhafer＠suse.de 16 Nov '12

16 Nov '12

I just uploaded a slightly updated patch to: ftp://ftp.openldap.org/incoming/rhafer-20121116-Use-non-blocking-IO-during-… The code is now only enabled when LDAP_USE_NON_BLOCKING_TLS is defined. Mainly because NSS and GNUTLS show some issues with not-blocking sockets. See my mail on -devel. Additionally the non-blocking handshake is only done if LDAP_OPT_TIMEOUT is set. Previously I used LDAP_OPT_NETWORK_TIMEOUT but IMO LDAP_OPT_TIMEOUT is the better choice. On Thu, Nov 01, 2012 at 05:36:54PM +0000, rhafer(a)suse.de wrote: > I've just uploaded: > > ftp://ftp.openldap.org/incoming/rhafer-Use-non-blocking-IO-during-SSL-Hands… > [..] Ralf

1 0

Re: (ITS#7440) ssl/tls replication not working
by quanah＠zimbra.com 16 Nov '12

16 Nov '12

--On Friday, November 16, 2012 12:17 AM +0000 beni.anil(a)gmail.com wrote: > Please let me know if i am going wrong. As I already told you. Use the openldap-technical mailing list. This ITS will be closed, again. <http://www.openldap.org/lists/mm/listinfo/openldap-technical> --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7440) ssl/tls replication not working
by beni.anil＠gmail.com 16 Nov '12

16 Nov '12

Full_Name: Version: 2.4.20 OS: RHEL 6.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (121.245.72.156) Hi List While configuring openldap replication with ssl. I am getting below log messages TLS: can't accept: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol. conn=1069 fd=15 closed (TLS negotiation failure) slap_client_connect: URI=ldap://10.242.151.17:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.242.151.17:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=777 rc -1 retrying slap_client_connect: URI=ldap://10.243.129.6:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.243.129.6:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=444 rc -1 retrying conn=1070 fd=15 ACCEPT from IP=10.242.151.17:44531 (IP=0.0.0.0:636) TLS: can't accept: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol. conn=1070 fd=15 closed (TLS negotiation failure) slap_client_connect: URI=ldap://10.242.151.17:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.242.151.17:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=777 rc -1 retrying slap_client_connect: URI=ldap://10.243.129.6:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.243.129.6:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=444 rc -1 retrying conn=1071 fd=15 ACCEPT from IP=10.242.151.17:44533 (IP=0.0.0.0:636) TLS: can't accept: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol. conn=1071 fd=15 closed (TLS negotiation failure) slap_client_connect: URI=ldap://10.242.151.17:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.242.151.17:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=777 rc -1 retrying slap_client_connect: URI=ldap://10.243.129.6:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.243.129.6:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=444 rc -1 retrying i am using self singed certificates. when i do search # ldapsearch -d 1 -x -b "dc=ibm,dc=com" -H 'ldaps://10.xx.xx.x' -ZZ ldap_url_parse_ext(ldaps://10.xx.xx.x) ldap_create ldap_url_parse_ext(ldaps://10.xx.xx.x:636/??base) 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 10.xx.xx.x:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.xx.xx.x:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 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: 0, err: 18, subject: /C=IN/ST=HR/L=GGN/O=SAPIENT/OU=ISST/CN=localhost/emailAddress=akumar178(a)sapient.com, issuer: /C=IN/ST=HR/L=GGN/O=SAPIENT/OU=ISST/CN=localhost/emailAddress=akumar178(a)sapient.com TLS certificate verification: Error, self signed certificate TLS certificate verification: depth: 0, err: 18, subject: /C=IN/ST=HR/L=GGN/O=SAP/OU=ISST/CN=localhost/emailAddress=akumar178(a)sapient.com, issuer: /C=IN/ST=HR/L=GGN/O=SAP/OU=ISST/CN=localhost/emailAddress=akumar(a)sap.com TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A TLS trace: SSL_connect:SSLv3 flush data TLS trace: SSL_connect:SSLv3 read server session ticket A TLS trace: SSL_connect:SSLv3 read finished A TLS: unable to get peer certificate. ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x1942aa0 msgid 1 wait4msg ld 0x1942aa0 msgid 1 (infinite timeout) wait4msg continue ld 0x1942aa0 msgid 1 all 1 ** ld 0x1942aa0 Connections: * host: 10.243.129.6 port: 636 (default) refcnt: 2 status: Connected last used: Thu Nov 15 11:58:52 2012 ** ld 0x1942aa0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x1942aa0 request count 1 (abandoned 0) ** ld 0x1942aa0 Response Queue: Empty ld 0x1942aa0 response count 0 ldap_chkResponseList ld 0x1942aa0 msgid 1 all 1 ldap_chkResponseList returns ld 0x1942aa0 NULL ldap_int_select read1msg: ld 0x1942aa0 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 31 contents: read1msg: ld 0x1942aa0 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x1942aa0 0 new referrals read1msg: mark request completed, ld 0x1942aa0 msgid 1 request done: ld 0x1942aa0 msgid 1 res_errno: 1, res_error: <TLS already started>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_err2string ldap_start_tls: Operations error (1) additional info: TLS already started ]# ldapsearch -d 1 -x -b "dc=ibm,dc=com" -H 'ldaps://localhost' -ZZ ldap_url_parse_ext(ldaps://localhost) ldap_create ldap_url_parse_ext(ldaps://localhost:636/??base) 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:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying ::1 636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 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: 0, err: 18, subject: /C=IN/ST=HR/L=GGN/O=SAP/OU=ISST/CN=localhost/emailAddress=akumar(a)sap.com, issuer: /C=IN/ST=HR/L=GGN/O=SAPIENT/OU=ISST/CN=localhost/emailAddress=akumar(a)sap.com TLS certificate verification: Error, self signed certificate TLS certificate verification: depth: 0, err: 18, subject: /C=IN/ST=HR/L=GGN/O=SAP/OU=ISST/CN=localhost/emailAddress=akumar(a)sap.com, issuer: /C=IN/ST=HR/L=GGN/O=SAP/OU=ISST/CN=localhost/emailAddress=akumar(a)sap.com TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A TLS trace: SSL_connect:SSLv3 flush data TLS trace: SSL_connect:SSLv3 read server session ticket A TLS trace: SSL_connect:SSLv3 read finished A TLS: unable to get peer certificate. ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x2172aa0 msgid 1 wait4msg ld 0x2172aa0 msgid 1 (infinite timeout) wait4msg continue ld 0x2172aa0 msgid 1 all 1 ** ld 0x2172aa0 Connections: * host: localhost port: 636 (default) refcnt: 2 status: Connected last used: Thu Nov 15 12:14:16 2012 ** ld 0x2172aa0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x2172aa0 request count 1 (abandoned 0) ** ld 0x2172aa0 Response Queue: Empty ld 0x2172aa0 response count 0 ldap_chkResponseList ld 0x2172aa0 msgid 1 all 1 ldap_chkResponseList returns ld 0x2172aa0 NULL ldap_int_select read1msg: ld 0x2172aa0 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 31 contents: read1msg: ld 0x2172aa0 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x2172aa0 0 new referrals read1msg: mark request completed, ld 0x2172aa0 msgid 1 request done: ld 0x2172aa0 msgid 1 res_errno: 1, res_error: <TLS already started>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_err2string ldap_start_tls: Operations error (1) additional info: TLS already started slapd.conf # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /apps/openldap/var/run/slapd.pid argsfile /apps/openldap/var/run/slapd.args # Load dynamic backend modules: # modulepath /app/openldap/libexec/openldap # moduleload back_bdb.la # moduleload back_hdb.la # moduleload back_ldap.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read #access to * #by self write #by users read #by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ### logging ### logfile /apps/logs/ldap loglevel 16640 ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=ibm,dc=com" # Restrict userPassword to be used for authentication only, but allow users to modify # their own passwords. access to attrs=userPassword by self write by * auth # Simple ACL granting read access to the world access to * by * read rootdn "cn=Manager,dc=ibm,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {SSHA}dXDFS3TAzYf8DrDSYWY ################## SSL ########################################## # TLSCipherSuite HIGH:MEDIUM:+SSLv3 TLSCACertificateFile /apps/openldap/etc/openldap/certs/mmprodadm04.pem TLSCertificateFile /apps/openldap/etc/openldap/certs/mmprodadm04.pem TLSCertificateKeyFile /apps/openldap/etc/openldap/certs/mmprodadm04.pem # #################################################################### #Replication Configuration overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 index entryCSN,entryUUID eq serverid 2 ## DR ldap server replication syncrepl rid=444 provider=ldap://10.x.x.x:636 binddn="cn=Manager,dc=ibm,dc=com" bindmethod=simple credentials=xxxxxxxx starttls=yes tls_reqcert=never searchbase="dc=ibm,dc=com" type=refreshAndPersist retry="5 5 300 +" interval=00:00:00:10 syncrepl rid=777 provider=ldap://10.x.x.x:636 binddn="cn=Manager,dc=ibm,dc=com" bindmethod=simple credentials=xxxxxxxxx starttls=yes tls_reqcert=never searchbase="dc=ibm,dc=com" type=refreshAndPersist retry="5 5 300 +" interval=00:00:00:10 #### mirrormode true ####ache Entries ##### cachesize 3000000 lastmod on checkpoint 128 15 concurrency 100 #database monitor # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /apps/openldap/var/openldap-data # Indices to maintain #index objectClass eq index mail,uid,postalCode,smail,channelType,channelValue,answer,behavName,objectclass,tokenID,type eq index givenName,sn,city,question,behavValue,cn,extName sub index displayName approx my ldap.conf file URI ldaps://localhost BASE dc=ibm,dc=com ssl start_tls ssl on tls_checkpeer no TLS_REQCERT allow tls_cacertfile /apps/openldap/etc/openldap/certs/mmprodam04.pem tls_cacertdir /apps/openldap/etc/openldap/certs I am using self signed certificate, Please let me know if i am going wrong.

1 0

(ITS#7439) crash in rwm when tree is syncrepl synced and database ldap with rwm inside same tree
by glen＠delfi.ee 15 Nov '12

15 Nov '12

Full_Name: Elan Ruusamäe Version: 2.4.33 OS: PLD Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.131.56.149) i'm setting up my tree so that People has one subtree via database ldap as ou=something,ou=People,dc=example (subordinate), and and i have also whole dc=example setup replica as syncrepl. and if i have both (syncrepl and the database ldap) enabled slapd crashes also the database ldap is rwm rewritten to match tree it's linked into --- slapd.conf ---: include /usr/share/openldap/schema/core.schema include /usr/share/openldap/schema/cosine.schema include /usr/share/openldap/schema/inetorgperson.schema include /usr/share/openldap/schema/nis.schema include /usr/share/openldap/schema/misc.schema include /usr/share/openldap/schema/rfc2739.schema include /usr/share/openldap/schema/courier.schema include /usr/share/openldap/schema/horde.schema include /usr/share/openldap/schema/openssh-lpk.schema include /usr/share/openldap/schema/samba.schema include /usr/share/openldap/schema/sudo.schema include /etc/openldap/schema/local.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args allow bind_v2 loglevel -1 modulepath /usr/lib64/openldap moduleload back_bdb.la moduleload back_ldap.la moduleload back_monitor.la moduleload back_relay.la moduleload rwm.la moduleload syncprov.la moduleload translucent.la include /etc/openldap/slapd-ad.conf include /etc/openldap/slapd-db.conf --- slapd-ad.conf ---: database ldap suffix "ou=Basement,ou=People,dc=example,dc=net" uri "ldap://a.b.c.d/" idassert-bind bindmethod=simple binddn=CN=glen,OU=Serviceaccounts,OU=Technical,DC=example,DC=org credentials=OBFUSCATED idle-timeout 1800 subordinate chase-referrals no rebind-as-user yes overlay rwm rwm-suffixmassage "ou=Basement,ou=People,dc=example,dc=net" "ou=Technical,dc=example,dc=org" rwm-map objectclass account user rwm-map attribute uidNumber employeeID rwm-map attribute gidNumber primaryGroupID rwm-map attribute uid sAMAccountName rwm-map attribute physicalDeliveryOfficeName rwm-map attribute cn name rwm-map attribute sn sn rwm-map attribute mail mail rwm-map attribute company company rwm-map attribute entry entry rwm-map attribute title title rwm-map attribute givenName givenName rwm-map attribute homeDirectory homeDirectory rwm-map attribute displayName displayName rwm-map attribute dn distinguishedName rwm-map attribute userPassword unicodePassword rwm-map attribute departmentNumber department rwm-map attribute member member rwm-map attribute manager managedby rwm-map attribute sambaProfilePath profilePath rwm-map attribute * --- slapd-db.conf ---: database bdb suffix "dc=example,dc=net" rootdn "cn=Manager,dc=example,dc=net" rootpw OBFUSCATED directory /var/lib/openldap-data index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub index entryCSN,entryUUID eq dbconfig set_cachesize 0 268435456 1 dbconfig set_lg_bsize 2097152 include /etc/openldap/slapd-syncrepl.conf --- slapd-syncrepl.conf ---: overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 sizelimit 10000 syncrepl rid=7 provider=ldap://ldap searchbase="dc=example,dc=net" type=refreshOnly interval=00:00:01:00 retry="120 +" scope=sub attrs="*" bindmethod=simple binddn="cn=replica,ou=Service Users,dc=example,dc=net" credentials=OBFUSCATED trace obtained as (altho glibc MALLOC_CHECK_ kicks in and gdb has no chance): # gdb --args slapd -u slapd -g slapd -h "ldap:/// ldapi:///" -d -1 (gdb) r ... 50a55ca9 => access_allowed: search access to "uid=user1,ou=People,dc=example,dc=net" "entryUUID" requested 50a55ca9 <= root access granted 50a55ca9 => access_allowed: search access granted by manage(=mwrscxd) 50a55ca9 <= test_filter 6 50a55ca9 => bdb_dn2id_children("uid=user1,ou=people,dc=example,dc=net") 50a55ca9 <= bdb_dn2id_children("uid=user1,ou=people,dc=example,dc=net"): no (-30989) 50a55ca9 send_ldap_result: conn=-1 op=0 p=3 50a55ca9 send_ldap_result: err=0 matched="" text="" 50a55ca9 ==> rewrite_context_apply [depth=1] string='ou=Basement,ou=People,dc=example,dc=net' 50a55ca9 ==> rewrite_rule_apply rule='((.+),)?ou=Basement,[ ]?ou=People,[ ]?dc=delfi,[ ]?dc=net$' string='ou=Basement,ou=People,dc=example,dc=net' [1 pass(es)] 50a55ca9 ==> rewrite_context_apply [depth=1] res={0,'ou=Serviceaccounts,ou=Technical,dc=example,dc=org'} 50a55ca9 [rw] searchDN: "ou=Basement,ou=People,dc=example,dc=net" -> "ou=Serviceaccounts,ou=Technical,dc=example,dc=org" 50a55ca9 >>> dnPrettyNormal: <ou=Serviceaccounts,ou=Technical,dc=example,dc=org> => ldap_bv2dn(ou=Serviceaccounts,ou=Technical,dc=example,dc=org,0) <= ldap_bv2dn(ou=Serviceaccounts,ou=Technical,dc=example,dc=org)=0 => ldap_dn2bv(272) <= ldap_dn2bv(ou=Serviceaccounts,ou=Technical,dc=example,dc=org)=0 => ldap_dn2bv(272) <= ldap_dn2bv(ou=serviceaccounts,ou=technical,dc=example,dc=org)=0 50a55ca9 <<< dnPrettyNormal: <ou=Serviceaccounts,ou=Technical,dc=example,dc=org>, <ou=serviceaccounts,ou=technical,dc=example,dc=org> *** glibc detected *** /usr/sbin/slapd: free(): invalid pointer: 0x00007fffd011c037 *** 50a55ca9 daemon: epoll: listen=11 active_threads=0 tvp=zero 50a55ca9 daemon: epoll: listen=12 active_threads=0 tvp=zero 50a55ca9 daemon: epoll: listen=13 active_threads=0 tvp=zero ======= Backtrace: ========= /lib64/libc.so.6(+0x79df6)[0x7ffff61d8df6] /usr/sbin/slapd(ava_free+0x2e)[0x5555555ac43e] /usr/sbin/slapd(filter_free_x+0x13a)[0x55555559317a] /usr/lib64/openldap/rwm-2.4.so.2(+0x9c6d)[0x7ffff1d82c6d] /usr/lib64/openldap/rwm-2.4.so.2(rwm_filter_map_rewrite+0x26)[0x7ffff1d839c6] /usr/lib64/openldap/rwm-2.4.so.2(+0x5461)[0x7ffff1d7e461] /usr/sbin/slapd(overlay_op_walk+0x4a)[0x5555555fc23a] /usr/sbin/slapd(+0xa83cb)[0x5555555fc3cb] /usr/sbin/slapd(+0xa6812)[0x5555555fa812] /usr/sbin/slapd(overlay_op_walk+0x4a)[0x5555555fc23a] /usr/sbin/slapd(+0xa83cb)[0x5555555fc3cb] /usr/sbin/slapd(+0x9d253)[0x5555555f1253] /usr/sbin/slapd(+0xa11b8)[0x5555555f51b8] /usr/lib64/libldap_r-2.4.so.2(+0x119b3)[0x7ffff7b9a9b3] /lib64/libpthread.so.0(+0x8034)[0x7ffff6512034] /lib64/libc.so.6(clone+0x6d)[0x7ffff62477ad] ======= Memory map: ======== 555555554000-55555567c000 r-xp 00000000 fd:00 20850901 /usr/sbin/slapd 55555587c000-55555587f000 r--p 00128000 fd:00 20850901 /usr/sbin/slapd 55555587f000-555555886000 rw-p 0012b000 fd:00 20850901 /usr/sbin/slapd 555555886000-555555c3f000 rw-p 00000000 00:00 0 [heap] 7fffd0000000-7fffd015e000 rw-p 00000000 00:00 0 7fffd015e000-7fffd4000000 ---p 00000000 00:00 0 7fffd67fe000-7fffd77ff000 rw-p 00000000 00:00 0 7fffd77ff000-7fffd7800000 ---p 00000000 00:00 0 7fffd7800000-7fffd8000000 rw-p 00000000 00:00 0 7fffd8000000-7fffd8021000 rw-p 00000000 00:00 0 7fffd8021000-7fffdc000000 ---p 00000000 00:00 0 7fffdc3a7000-7fffdc3bc000 r-xp 00000000 fd:00 21096302 /lib64/libgcc_s.so.1 7fffdc3bc000-7fffdc5bb000 ---p 00015000 fd:00 21096302 /lib64/libgcc_s.so.1 7fffdc5bb000-7fffdc5bc000 rw-p 00014000 fd:00 21096302 /lib64/libgcc_s.so.1 7fffdc5bc000-7fffdc5bd000 ---p 00000000 00:00 0 7fffdc5bd000-7fffdcdbd000 rw-p 00000000 00:00 0 7fffdcdbd000-7fffdcdc5000 rw-s 00000000 fd:00 33596447 /var/lib/openldap-data/__db.006 7fffdcdc5000-7fffdce77000 rw-s 00000000 fd:00 33596446 /var/lib/openldap-data/__db.005 7fffdce77000-7fffdd0b7000 rw-s 00000000 fd:00 38665430 /var/lib/openldap-data/__db.004 7fffdd0b7000-7ffff10b9000 rw-s 00000000 fd:00 38665429 /var/lib/openldap-data/__db.003 7ffff10b9000-7ffff1965000 rw-s 00000000 fd:00 33952840 /var/lib/openldap-data/__db.002 7ffff1965000-7ffff196b000 r-xp 00000000 fd:00 36390022 /usr/lib64/openldap/translucent-2.4.so.2.8.5 7ffff196b000-7ffff1b6a000 ---p 00006000 fd:00 36390022 /usr/lib64/openldap/translucent-2.4.so.2.8.5 7ffff1b6a000-7ffff1b6b000 r--p 00005000 fd:00 36390022 /usr/lib64/openldap/translucent-2.4.so.2.8.5 7ffff1b6b000-7ffff1b6c000 rw-p 00006000 fd:00 36390022 /usr/lib64/openldap/translucent-2.4.so.2.8.5 7ffff1b6c000-7ffff1b78000 r-xp 00000000 fd:00 36390017 /usr/lib64/openldap/syncprov-2.4.so.2.8.5 7ffff1b78000-7ffff1d77000 ---p 0000c000 fd:00 36390017 /usr/lib64/openldap/syncprov-2.4.so.2.8.5 7ffff1d77000-7ffff1d78000 r--p 0000b000 fd:00 36390017 /usr/lib64/openldap/syncprov-2.4.so.2.8.5 7ffff1d78000-7ffff1d79000 rw-p 0000c000 fd:00 36390017 /usr/lib64/openldap/syncprov-2.4.so.2.8.5 7ffff1d79000-7ffff1d87000 r-xp 00000000 fd:00 36389997 /usr/lib64/openldap/rwm-2.4.so.2.8.5 7ffff1d87000-7ffff1f86000 ---p 0000e000 fd:00 36389997 /usr/lib64/openldap/rwm-2.4.so.2.8.5 7ffff1f86000-7ffff1f87000 r--p 0000d000 fd:00 36389997 /usr/lib64/openldap/rwm-2.4.so.2.8.5 7ffff1f87000-7ffff1f88000 rw-p 0000e000 fd:00 36389997 /usr/lib64/openldap/rwm-2.4.so.2.8.5 7ffff1f88000-7ffff1f8b000 r-xp 00000000 fd:00 36390027 /usr/lib64/openldap/back_relay-2.4.so.2.8.5 7ffff1f8b000-7ffff218a000 ---p 00003000 fd:00 36390027 /usr/lib64/openldap/back_relay-2.4.so.2.8.5 7ffff218a000-7ffff218b000 r--p 00002000 fd:00 36390027 /usr/lib64/openldap/back_relay-2.4.so.2.8.5 7ffff218b000-7ffff218c000 rw-p 00003000 fd:00 36390027 /usr/lib64/openldap/back_relay-2.4.so.2.8.5 7ffff218c000-7ffff21a4000 r-xp 00000000 fd:00 36390012 /usr/lib64/openldap/back_monitor-2.4.so.2.8.5 7ffff21a4000-7ffff23a4000 ---p 00018000 fd:00 36390012 /usr/lib64/openldap/back_monitor-2.4.so.2.8.5 7ffff23a4000-7ffff23a5000 r--p 00018000 fd:00 36390012 /usr/lib64/openldap/back_monitor-2.4.so.2.8.5 7ffff23a5000-7ffff23a7000 rw-p 00019000 fd:00 36390012 /usr/lib64/openldap/back_monitor-2.4.so.2.8.5 7ffff23a7000-7ffff23ab000 rw-p 00000000 00:00 0 7ffff23ab000-7ffff23cf000 r-xp 00000000 fd:00 36390007 /usr/lib64/openldap/back_ldap-2.4.so.2.8.5 7ffff23cf000-7ffff25ce000 ---p 00024000 fd:00 36390007 /usr/lib64/openldap/back_ldap-2.4.so.2.8.5 7ffff25ce000-7ffff25cf000 r--p 00023000 fd:00 36390007 /usr/lib64/openldap/back_ldap-2.4.so.2.8.5 7ffff25cf000-7ffff25d1000 rw-p 00024000 fd:00 36390007 /usr/lib64/openldap/back_ldap-2.4.so.2.8.5 7ffff25d1000-7ffff25d2000 rw-p 00000000 00:00 0 7ffff25d2000-7ffff26ff000 r-xp 00000000 fd:00 36389991 /usr/lib64/libslapd_db-4.6.so 7ffff26ff000-7ffff28ff000 ---p 0012d000 fd:00 36389991 /usr/lib64/libslapd_db-4.6.so 7ffff28ff000-7ffff2901000 r--p 0012d000 fd:00 36389991 /usr/lib64/libslapd_db-4.6.so 7ffff2901000-7ffff2904000 rw-p 0012f000 fd:00 36389991 /usr/lib64/libslapd_db-4.6.so 7ffff2904000-7ffff292f000 r-xp 00000000 fd:00 36390002 /usr/lib64/openldap/back_bdb-2.4.so.2.8.5 7ffff292f000-7ffff2b2f000 ---p 0002b000 fd:00 36390002 /usr/lib64/openldap/back_bdb-2.4.so.2.8.5 7ffff2b2f000-7ffff2b30000 r--p 0002b000 fd:00 36390002 /usr/lib64/openldap/back_bdb-2.4.so.2.8.5 7ffff2b30000-7ffff2b31000 rw-p 0002c000 fd:00 36390002 /usr/lib64/openldap/back_bdb-2.4.so.2.8.5 7ffff2b31000-7ffff2b4a000 rw-p 00000000 00:00 0 7ffff2b4a000-7ffff2b4e000 r-xp 00000000 fd:00 38016672 /usr/lib64/sasl2/libplain.so.2.0.25 7ffff2b4e000-7ffff2d4d000 ---p 00004000 fd:00 38016672 /usr/lib64/sasl2/libplain.so.2.0.25 7ffff2d4d000-7ffff2d4e000 rw-p 00003000 fd:00 38016672 /usr/lib64/sasl2/libplain.so.2.0.25 7ffff2d4e000-7ffff2d52000 r-xp 00000000 fd:00 37882936 /usr/lib64/sasl2/liblogin.so.2.0.25 7ffff2d52000-7ffff2f51000 ---p 00004000 fd:00 37882936 /usr/lib64/sasl2/liblogin.so.2.0.25 7ffff2f51000-7ffff2f52000 rw-p 00003000 fd:00 37882936 /usr/lib64/sasl2/liblogin.so.2.0.25 Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffd7fff700 (LWP 15473)] 0x00007ffff6194395 in raise () from /lib64/libc.so.6 (gdb)

1 0

Re: (ITS#7438) ssl/tls replication not working
by quanah＠zimbra.com 15 Nov '12

15 Nov '12

--On Thursday, November 15, 2012 5:27 PM +0000 beni.anil(a)gmail.com wrote: > Full_Name: > Version: 2.4.20 > OS: RHEL 6.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (14.140.116.135) The ITS system is for filing bug reports. For configuration issues such as yours, please use the openldap-technical mailing list. I will note that your reported version of OpenLDAP is extremely old. Although this may be unrelated to the issue you are facing, you would be well served to use something current. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7438) ssl/tls replication not working
by beni.anil＠gmail.com 15 Nov '12

15 Nov '12

Full_Name: Version: 2.4.20 OS: RHEL 6.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (14.140.116.135) Hi List While configuring openldap replication with ssl. I am getting below log messages TLS: can't accept: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol. conn=1069 fd=15 closed (TLS negotiation failure) slap_client_connect: URI=ldap://10.242.151.17:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.242.151.17:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=777 rc -1 retrying slap_client_connect: URI=ldap://10.243.129.6:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.243.129.6:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=444 rc -1 retrying conn=1070 fd=15 ACCEPT from IP=10.242.151.17:44531 (IP=0.0.0.0:636) TLS: can't accept: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol. conn=1070 fd=15 closed (TLS negotiation failure) slap_client_connect: URI=ldap://10.242.151.17:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.242.151.17:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=777 rc -1 retrying slap_client_connect: URI=ldap://10.243.129.6:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.243.129.6:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=444 rc -1 retrying conn=1071 fd=15 ACCEPT from IP=10.242.151.17:44533 (IP=0.0.0.0:636) TLS: can't accept: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol. conn=1071 fd=15 closed (TLS negotiation failure) slap_client_connect: URI=ldap://10.242.151.17:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.242.151.17:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=777 rc -1 retrying slap_client_connect: URI=ldap://10.243.129.6:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.243.129.6:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=444 rc -1 retrying i am using self singed certificates. when i do search # ldapsearch -d 1 -x -b "dc=ibm,dc=com" -H 'ldaps://10.xx.xx.x' -ZZ ldap_url_parse_ext(ldaps://10.xx.xx.x) ldap_create ldap_url_parse_ext(ldaps://10.xx.xx.x:636/??base) 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 10.xx.xx.x:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.xx.xx.x:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 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: 0, err: 18, subject: /C=IN/ST=HR/L=GGN/O=SAPIENT/OU=ISST/CN=localhost/emailAddress=akumar178(a)sapient.com, issuer: /C=IN/ST=HR/L=GGN/O=SAPIENT/OU=ISST/CN=localhost/emailAddress=akumar178(a)sapient.com TLS certificate verification: Error, self signed certificate TLS certificate verification: depth: 0, err: 18, subject: /C=IN/ST=HR/L=GGN/O=SAP/OU=ISST/CN=localhost/emailAddress=akumar178(a)sapient.com, issuer: /C=IN/ST=HR/L=GGN/O=SAP/OU=ISST/CN=localhost/emailAddress=akumar(a)sap.com TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A TLS trace: SSL_connect:SSLv3 flush data TLS trace: SSL_connect:SSLv3 read server session ticket A TLS trace: SSL_connect:SSLv3 read finished A TLS: unable to get peer certificate. ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x1942aa0 msgid 1 wait4msg ld 0x1942aa0 msgid 1 (infinite timeout) wait4msg continue ld 0x1942aa0 msgid 1 all 1 ** ld 0x1942aa0 Connections: * host: 10.243.129.6 port: 636 (default) refcnt: 2 status: Connected last used: Thu Nov 15 11:58:52 2012 ** ld 0x1942aa0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x1942aa0 request count 1 (abandoned 0) ** ld 0x1942aa0 Response Queue: Empty ld 0x1942aa0 response count 0 ldap_chkResponseList ld 0x1942aa0 msgid 1 all 1 ldap_chkResponseList returns ld 0x1942aa0 NULL ldap_int_select read1msg: ld 0x1942aa0 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 31 contents: read1msg: ld 0x1942aa0 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x1942aa0 0 new referrals read1msg: mark request completed, ld 0x1942aa0 msgid 1 request done: ld 0x1942aa0 msgid 1 res_errno: 1, res_error: <TLS already started>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_err2string ldap_start_tls: Operations error (1) additional info: TLS already started ]# ldapsearch -d 1 -x -b "dc=ibm,dc=com" -H 'ldaps://localhost' -ZZ ldap_url_parse_ext(ldaps://localhost) ldap_create ldap_url_parse_ext(ldaps://localhost:636/??base) 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:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying ::1 636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 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: 0, err: 18, subject: /C=IN/ST=HR/L=GGN/O=SAP/OU=ISST/CN=localhost/emailAddress=akumar(a)sap.com, issuer: /C=IN/ST=HR/L=GGN/O=SAPIENT/OU=ISST/CN=localhost/emailAddress=akumar(a)sap.com TLS certificate verification: Error, self signed certificate TLS certificate verification: depth: 0, err: 18, subject: /C=IN/ST=HR/L=GGN/O=SAP/OU=ISST/CN=localhost/emailAddress=akumar(a)sap.com, issuer: /C=IN/ST=HR/L=GGN/O=SAP/OU=ISST/CN=localhost/emailAddress=akumar(a)sap.com TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A TLS trace: SSL_connect:SSLv3 flush data TLS trace: SSL_connect:SSLv3 read server session ticket A TLS trace: SSL_connect:SSLv3 read finished A TLS: unable to get peer certificate. ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x2172aa0 msgid 1 wait4msg ld 0x2172aa0 msgid 1 (infinite timeout) wait4msg continue ld 0x2172aa0 msgid 1 all 1 ** ld 0x2172aa0 Connections: * host: localhost port: 636 (default) refcnt: 2 status: Connected last used: Thu Nov 15 12:14:16 2012 ** ld 0x2172aa0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x2172aa0 request count 1 (abandoned 0) ** ld 0x2172aa0 Response Queue: Empty ld 0x2172aa0 response count 0 ldap_chkResponseList ld 0x2172aa0 msgid 1 all 1 ldap_chkResponseList returns ld 0x2172aa0 NULL ldap_int_select read1msg: ld 0x2172aa0 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 31 contents: read1msg: ld 0x2172aa0 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x2172aa0 0 new referrals read1msg: mark request completed, ld 0x2172aa0 msgid 1 request done: ld 0x2172aa0 msgid 1 res_errno: 1, res_error: <TLS already started>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_err2string ldap_start_tls: Operations error (1) additional info: TLS already started slapd.conf # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /apps/openldap/var/run/slapd.pid argsfile /apps/openldap/var/run/slapd.args # Load dynamic backend modules: # modulepath /app/openldap/libexec/openldap # moduleload back_bdb.la # moduleload back_hdb.la # moduleload back_ldap.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read #access to * #by self write #by users read #by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ### logging ### logfile /apps/logs/ldap loglevel 16640 ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=ibm,dc=com" # Restrict userPassword to be used for authentication only, but allow users to modify # their own passwords. access to attrs=userPassword by self write by * auth # Simple ACL granting read access to the world access to * by * read rootdn "cn=Manager,dc=ibm,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {SSHA}dXDFS3TAzYf8DrDSYWY ################## SSL ########################################## # TLSCipherSuite HIGH:MEDIUM:+SSLv3 TLSCACertificateFile /apps/openldap/etc/openldap/certs/mmprodadm04.pem TLSCertificateFile /apps/openldap/etc/openldap/certs/mmprodadm04.pem TLSCertificateKeyFile /apps/openldap/etc/openldap/certs/mmprodadm04.pem # #################################################################### #Replication Configuration overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 index entryCSN,entryUUID eq serverid 2 ## DR ldap server replication syncrepl rid=444 provider=ldap://10.x.x.x:636 binddn="cn=Manager,dc=ibm,dc=com" bindmethod=simple credentials=xxxxxxxx starttls=yes tls_reqcert=never searchbase="dc=ibm,dc=com" type=refreshAndPersist retry="5 5 300 +" interval=00:00:00:10 syncrepl rid=777 provider=ldap://10.x.x.x:636 binddn="cn=Manager,dc=ibm,dc=com" bindmethod=simple credentials=xxxxxxxxx starttls=yes tls_reqcert=never searchbase="dc=ibm,dc=com" type=refreshAndPersist retry="5 5 300 +" interval=00:00:00:10 #### mirrormode true ####ache Entries ##### cachesize 3000000 lastmod on checkpoint 128 15 concurrency 100 #database monitor # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /apps/openldap/var/openldap-data # Indices to maintain #index objectClass eq index mail,uid,postalCode,smail,channelType,channelValue,answer,behavName,objectclass,tokenID,type eq index givenName,sn,city,question,behavValue,cn,extName sub index displayName approx my ldap.conf file URI ldaps://localhost BASE dc=ibm,dc=com ssl start_tls ssl on tls_checkpeer no TLS_REQCERT allow tls_cacertfile /apps/openldap/etc/openldap/certs/mmprodam04.pem tls_cacertdir /apps/openldap/etc/openldap/certs I am using self signed certificate, Please let me know if i am going wrong.

1 0

Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by michael＠stroeder.com 14 Nov '12

14 Nov '12

Michael Ströder wrote: > Jan Synacek wrote: >> On 11/08/2012 08:14 AM, michael(a)stroeder.com wrote: >>> FYI: I sent output of bt full to Jan with some data stripped because of >>> privacy concerns. >>> >>> Note that the entry for which constraint checking is done is added to the >>> database. So something might be wrong *after* the check. >> >> Can you please try the attached patch? > > It seems to work. But I will test it during the next days more thoroughly. No more seg faults so far in my setup which uses slapo-constraints quite heavily. So I'd appreciate if Jan's patch lands in RE24 branch. Ciao, Michael.

1 0

Re: (ITS#7436) slapo-deref not working
by rhafer＠suse.de 14 Nov '12

14 Nov '12

On Fri, Nov 09, 2012 at 02:51:59PM +0000, rhafer(a)suse.de wrote: > pcache still missing I was wrong, pcache isn't affected by this problem.

1 0

(ITS#7437) Request to submit EnMasse project to OpenLDAP
by shawn.mckinney＠joshuatreesoftware.us 10 Nov '12

10 Nov '12

Full_Name: Shawn McKinney Version: all OS: all URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (99.34.196.221) Hello, We have created a new application, called EnMasse. EnMasse is a web application that implements RESTful Web services to interface with Fortress/OpenLDAP. EnMasse was built using established Open Source technologies including Apache CXF (web services stack), Spring Framework (glue), Maven (dependencies) and JAXB (data binding layer) and runs inside any reasonably compliant Java Servlets container. EnMasses service access decisions are made using declarative Java EE and Spring security policy hooks that are wired to connect back to the Fortress RBAC component itself. This product has not been published and we would like to release it as one of the products under OpenLDAP family of products. What we would like from OpenLDAP foundation is the following: 1. Separate GIT project called EnMasse. 2. Mailing list for developers and users to communicate with project team. 3. Issue tracking for EnMasse project. 4. Project page for overview and how to find out more information. I have uploaded one package, entitled enmasse-openldap-submission.zip to our FTP server that contains the source, documentation and other items for you to look at. host: joshuatreesoftware.us user: jtreeguest pw: Guest123 Everything under the /target folder contain generated project artifacts including deployable web archive (war) and javadoc. These artifacts will not be checked into GIT. The source is located /src folder in the package. Statement of origin for submitted works: The contributed EnMasse works described above were provided by JoshuaTree Software, LLC and referenced in this ITS were created by JoshuaTree Software, LLC, who is the exclusive owner of the contributed works. The contributed works are made available as indicated in the copyright and license statements attached to the work. Sincerely, Shawn McKinney Principal, JoshuaTree Software, LLC

1 0

Re: (ITS#7435) telexNumber
by quanah＠zimbra.com 09 Nov '12

09 Nov '12

--On Friday, November 09, 2012 6:59 AM +0000 masarati(a)aero.polimi.it wrote: > >> Full_Name: Roy Luckow >> Version: 2.4.30 >> OS: Win Server 2003 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.4.225.4) >> >> >> LDAP Search for attribute "telexNumber" doesn't work. >> If I do a search filter "(telexNumber=*)" --> Then I get my results >> (total of >> 4600 hits). If I set the search as "(telexNumber=*1*)" --> Then I get the >> Message "No entries matched" > > This is by design: "telexNumber" has no matching rule. This ITS will be > closed. I would note that you can force matching rules to apply to a particular attribute during a search. You might try the matching rules for telephoneNumber. Hope this helps, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7436) slapo-deref not working
by rhafer＠suse.de 09 Nov '12

09 Nov '12

Fixed slapo-deref. pcache still missing.

1 0

Re: (ITS#7436) slapo-deref not working
by rhafer＠suse.de 09 Nov '12

09 Nov '12

On Fri, Nov 09, 2012 at 02:04:13PM +0000, ralf(a)OpenLDAP.org wrote: > Independ of whether the slapo-deref beign configured or not it always returns > "Critical extension is unavailable" to the client. > > This is because it doesn't call overlay_register_control anywhere in its code. > Fix is underway. The PCACHE_CONTROL_PRIVDB control defined in slapo-pcache seems to suffer the same problem. (though that's still hidden behind LDAP_DEVEL)

1 0

(ITS#7436) slapo-deref not working
by ralf＠OpenLDAP.org 09 Nov '12

09 Nov '12

Full_Name: Ralf Haferkamp Version: RE24, HEAD OS: SLES11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.118.144.197) Submitted by: ralf Independ of whether the slapo-deref beign configured or not it always returns "Critical extension is unavailable" to the client. This is because it doesn't call overlay_register_control anywhere in its code. Fix is underway.

1 0

Re: (ITS#7435) telexNumber
by masarati＠aero.polimi.it 09 Nov '12

09 Nov '12

> Full_Name: Roy Luckow > Version: 2.4.30 > OS: Win Server 2003 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.4.225.4) > > > LDAP Search for attribute "telexNumber" doesn't work. > If I do a search filter "(telexNumber=*)" --> Then I get my results (total > of > 4600 hits). If I set the search as "(telexNumber=*1*)" --> Then I get the > Message "No entries matched" This is by design: "telexNumber" has no matching rule. This ITS will be closed. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7435) telexNumber
by Roy.Luckow＠swmh.de 09 Nov '12

09 Nov '12

Full_Name: Roy Luckow Version: 2.4.30 OS: Win Server 2003 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.4.225.4) LDAP Search for attribute "telexNumber" doesn't work. If I do a search filter "(telexNumber=*)" --> Then I get my results (total of 4600 hits). If I set the search as "(telexNumber=*1*)" --> Then I get the Message "No entries matched"

1 0

Re: (ITS#7434) idassert-bind fails after restarting slapd
by quanah＠zimbra.com 09 Nov '12

09 Nov '12

--On Friday, November 09, 2012 2:10 AM +0000 quanah(a)zimbra.com wrote: > --On Friday, November 09, 2012 1:55 AM +0000 blance3459(a)hotmail.com wrote: > >> Full_Name: Barry Lance >> Version: 2.4.28 >> OS: Ubuntu 12.04 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (70.226.37.226) >> > > Hi Barry, Hi Barry, Are you sure you aren't hitting: Fixed slapd-ldap idassert bind handling (ITS#7403) Fixed in OpenLDAP 2.4.33? --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7434) idassert-bind fails after restarting slapd
by quanah＠zimbra.com 09 Nov '12

09 Nov '12

--On Friday, November 09, 2012 1:55 AM +0000 blance3459(a)hotmail.com wrote: > Full_Name: Barry Lance > Version: 2.4.28 > OS: Ubuntu 12.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (70.226.37.226) > Hi Barry, Thanks for the report. I would note that OpenLDAP 2.4.28 is 5 releases old at this point. I don't see anything specific in the CHANGES file between 2.4.28 and 2.4.33 for this issue, but it may be fixed and not logged in there. Confirming that the behavior persists with 2.4.33 would be helpful. Also, don't confuse encoding with encryption. ;) It is standard in LDIF for data to be base64 encoded if the attribute value requires it based on the characters in the data. You can use various tools to decode the attribute value back out. Regards, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7434) idassert-bind fails after restarting slapd
by blance3459＠hotmail.com 09 Nov '12

09 Nov '12

Full_Name: Barry Lance Version: 2.4.28 OS: Ubuntu 12.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (70.226.37.226) Two servers: Master (192.168.1.1) and Replica (192.168.1.2) both running slap 2.4.28 and ubuntu 12.04. Replica is a replication partner of Master using syncrepl. Replication is working fine. When I attempt to add a chain overlay to Replica to send all writes over to the master, it works exactly as expected allowing both normal users and the rootdn to make appropriate changes. However, once I either reboot the replica server or restart slapd, the chain overlay fails to allow any changes on the master. Looking at syslog shows that before the reboot/restart the requesting users' dn is proxied over as expected. After the restarting slapd or rebooting Replica, all changes are proxied anonymously (dn=""). I am using simple binds at this point in the project, but it doesn't seems to matter if I proxy in the clear, ldaps, or TLS the result is the same. All three methods can successfully negotiate a connection. I've even tried switching between using the rootdn and a different user as the binddn in my overlay, but the result is still the same no matter what I use for the binddn. When I look at my config, I notice that "chain-idassert-bind" appears to be hashed or encrypted in thew config. Is that normal? Just seems really odd that my config would work immediately when added, but fail after the the daemon has been restarted. Am I missing something really silly? Hopefully, someone can assist me on this. I've been driving myself crazy trying to figure out why this behavior is occurring. Disclaimer: I am using openldap as part of my capstone project for graduation. I'm not asking for anyone to do my "homework" for me, I'm just stuck on this one issue that I would love to resolve so I can move on to the Kerberos phase of my project (and maybe even study for an exam coming up in my algorithms class next week). Here is my overlay config using the rootDN and TLS (on Replica): dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend, cn=config changetype: add objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: "ldap://master.example.net/" olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=simple binddn="cn=admin,dc=example,dc=net" credentials=(secret) mode=self starttls=critical tls_cacert=/etc/ssl/certs/cacert.pem tls_reqcert=demand And without TLS (also on Replica): dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend, cn=config changetype: add objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: "ldap://master.example.net/" olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=simple binddn="cn=admin,dc=example,dc=net" credentials=(secret) mode=self

1 0

Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by michael＠stroeder.com 08 Nov '12

08 Nov '12

Jan Synacek wrote: > On 11/08/2012 08:14 AM, michael(a)stroeder.com wrote: >> FYI: I sent output of bt full to Jan with some data stripped because of >> privacy concerns. >> >> Note that the entry for which constraint checking is done is added to the >> database. So something might be wrong *after* the check. > > Can you please try the attached patch? It seems to work. But I will test it during the next days more thoroughly. Ciao, Michael.

1 0

Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by jsynacek＠redhat.com 08 Nov '12

08 Nov '12

This is a multi-part message in MIME format. --------------000604070905040801090708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/08/2012 08:14 AM, michael(a)stroeder.com wrote: > FYI: I sent output of bt full to Jan with some data stripped because of > privacy concerns. > > Note that the entry for which constraint checking is done is added to the > database. So something might be wrong *after* the check. > > Ciao, Michael. > > Can you please try the attached patch? If it doesn't fix the issue (or breaks something else that I'm not aware of) I will need a reproducer config and data. Thank you, -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat --------------000604070905040801090708 Content-Type: text/x-patch; name="tmp.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tmp.patch" diff --git a/servers/slapd/overlays/constraint.c b/servers/slapd/overlays/constraint.c index ee8911b..f2c645c 100644 --- a/servers/slapd/overlays/constraint.c +++ b/servers/slapd/overlays/constraint.c @@ -935,10 +935,6 @@ constraint_update( Operation *op, SlapReply *rs ) /* Do we need to count attributes? */ for(cp = c; cp; cp = cp->ap_next) { - if (cp->restrict_lud && constraint_check_restrict(op, cp, target_entry) == 0) { - continue; - } - if (cp->count != 0) { if (rc != 0 || target_entry == NULL) { Debug(LDAP_DEBUG_TRACE, @@ -950,6 +946,10 @@ constraint_update( Operation *op, SlapReply *rs ) goto mod_violation; } + if (cp->restrict_lud && constraint_check_restrict(op, cp, target_entry) == 0) { + continue; + } + is_v = constraint_check_count_violation(m, target_entry, cp); Debug(LDAP_DEBUG_TRACE, --------------000604070905040801090708--

1 0

Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by michael＠stroeder.com 08 Nov '12

08 Nov '12

FYI: I sent output of bt full to Jan with some data stripped because of privacy concerns. Note that the entry for which constraint checking is done is added to the database. So something might be wrong *after* the check. Ciao, Michael.

1 0

Re: (ITS#7433) OpenLDAP 2.4.32 - possible memory leak at high load
by quanah＠zimbra.com 06 Nov '12

06 Nov '12

--On Tuesday, November 06, 2012 5:36 PM +0000 vb4607(a)att.com wrote: > Full_Name: Venkatesh Baglodi > Version: 2.4.32 > OS: Red Hat Enterprise Linux Server release 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (139.76.64.65) > > > We have been facing frequent memory utilization issues with OpenLDAP > 2.4.32 in our production environment (multi-master mode, 6 servers), > which requires OpenLDAP server instances to be restarted almost every > week. Utilization starts at a lower percentage to start with (2-3%), but > then gradually moves up and never comes down. We have been using OpenLDAP > 2.4.32 with hdb backend (BerkelyDB v5.3.21) on Red Hat Enterprise Linux > Server release 5.5 (Tikanga). Are there any known issues with this > version? Are you using the default glibc malloc, instead of tcmalloc? That would be a common mistake that results in this sort of behavior. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs