openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Re: (ITS#7068) openldap connection issue
by sanjiv.singh＠impetus.co.in 20 Oct '11

20 Oct '11

--_000_23A2685ED8B30D46A90227113A1ECE0758F3EAA3Mail3impetuscoi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi all, adding more details for debugging..... when i fire ldapadd utility with following ldif , it repeatedly throughing = following logs.... new.ldif ------------------------------------------------------ dn: cn=3DProcessor,dc=3Dmydomain,dc=3Dcom description: some description roleType: My Admin uniqueMember: uid=3Dmyadmin,dc=3Dmydomain,dc=3Dcom tenantId: Global cn: Processor objectClass: groupOfUniqueNames objectClass: top ------------------------------------------------------ /usr/local/bin/ldapadd -d 65535 -h 10.122.215.40 -p 6070 -x -w ***** -D "cn= =3DManager,dc=3Dmydomain,dc=3Dcom" -f new.ldif ------------------------------------------------------ ** ld 0x4185ad0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x4185ad0 request count 1 (abandoned 0) ** ld 0x4185ad0 Response Queue: Empty ld 0x4185ad0 response count 0 ldap_chkResponseList ld 0x4185ad0 msgid 2 all 1 ldap_chkResponseList returns ld 0x4185ad0 NULL ldap_int_select ldap_result ld 0x4185ad0 msgid 2 wait4msg ld 0x4185ad0 msgid 2 (timeout 100000 usec) wait4msg continue ld 0x4185ad0 msgid 2 all 1 ** ld 0x4185ad0 Connections: * host: 10.122.215.40 port: 6070 (default) refcnt: 2 status: Connected last used: Thu Oct 20 08:42:30 2011 -------------------------------------------------------- Regards, Sanjiv Singh Software Engineer (iLabs) Impetus Infotech (India) Pvt. Ltd. D-40, Sector-59, Noida - 201307, UP | (M) +91-9990-447-339 | www.impetus.c= om<http://www.impetus.com/> ________________________________ New Impetus webcast on-demand 'Big Data Technologies for Social Media Analy= tics' available at http://bit.ly/nFdet0. Visit http://www.impetus.com to know more. Follow us on www.twitter.com/imp= etuscalling NOTE: This message may contain information that is confidential, proprietar= y, privileged or otherwise protected by law. The message is intended solely= for the named addressee. If received in error, please destroy and notify t= he sender. Any use of this email is prohibited when received in error. Impe= tus does not represent, warrant and/or guarantee, that the integrity of thi= s communication has been maintained nor that the communication is free of e= rrors, virus, interception or interference. --_000_23A2685ED8B30D46A90227113A1ECE0758F3EAA3Mail3impetuscoi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <style>  </style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> hi all, adding more details for debugging.....   when i fire ldapadd utility with following ldif , it= repeatedly throughing following logs....   new.ldif ----------------------------------------------------= -- dn: cn=3DProcessor,dc=3Dmydomain,dc=3Dcom description: some description roleType: My Admin uniqueMember: uid=3Dmyadmin,dc=3Dmydomain,dc=3Dcom</= p> tenantId: Global cn: Processor objectClass: groupOfUniqueNames objectClass: top ----------------------------------------------------= --   /usr/local/bin/ldapadd -d 65535 -h 10.122.215.40 -p = 6070 -x -w ***** -D "cn=3DManager,dc=3Dmydomain,dc=3Dcom" -f new.= ldif ----------------------------------------------------= -- ** ld 0x4185ad0 Outstanding Requests: * msgid 2,  origid 2, status InProgress    outstanding referrals 0, parent count 0=   ld 0x4185ad0 request count 1 (abandoned 0)</p= > ** ld 0x4185ad0 Response Queue:    Empty   ld 0x4185ad0 response count 0 ldap_chkResponseList ld 0x4185ad0 msgid 2 all 1 ldap_chkResponseList returns ld 0x4185ad0 NULL ldap_int_select ldap_result ld 0x4185ad0 msgid 2 wait4msg ld 0x4185ad0 msgid 2 (timeout 100000 usec)<= /p> wait4msg continue ld 0x4185ad0 msgid 2 all 1 ** ld 0x4185ad0 Connections: * host: 10.122.215.40  port: 6070  (defaul= t)   refcnt: 2  status: Connected   last used: Thu Oct 20 08:42:30 2011 ----------------------------------------------------= ----   Regards, Sanjiv Singh Software Engineer (iLabs)</s= pan> Impetus Infotech (India) = Pvt. Ltd. D-40, Sector-59, Noida - 201= 307, UP |  (M) +91-9990-447-339 | <a href=3D"http://www.impetus.com/" title=3D"http://www.impetus.com">www.impetus.com</a>&nb= sp;     </div> <hr> New Impetus webcast on-demand ‘Big Data Technologies for Social Media= Analytics’ available at http://bit.ly/nFdet0. Visit http://www.impetus.com to know more. Follow us on www.twitter.com/imp= etuscalling NOTE: This message may contain information that is confidential, proprietar= y, privileged or otherwise protected by law. The message is intended solely= for the named addressee. If received in error, please destroy and notify t= he sender. Any use of this email is prohibited when received in error. Impetus does not represent, warrant = and/or guarantee, that the integrity of this communication has been maintai= ned nor that the communication is free of errors, virus, interception or in= terference. </body> </html> --_000_23A2685ED8B30D46A90227113A1ECE0758F3EAA3Mail3impetuscoi_--

1 0

(ITS#7068) openldap connection issue
by sanjiv.is.on＠gmail.com 20 Oct '11

20 Oct '11

Full_Name: Sanjiv Singh Version: 2.4.20 OS: centOS 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (115.113.49.98) Hi all, I am facing openldap issue, facing problem during operation with openldap utilities. slapadd,ldapsearch and slapcat etc. I have installed & configure openldap 2.4.20 from source. enable debugging level -1(max debug level). here is my LDIF that i want to add to my ldap server. mydata.ldif ------------------------------------------------------ dn: cn=My Operator,dc=mydomain ,dc=com description: My Operator for managing job types roleType: Common tenantId: Global cn: My Operator objectClass: groupOfUniqueNames objectClass: top structuralObjectClass: groupOfUniqueNames entryUUID: 93385d1f-c9ec-4a1e-93fe-93f6cc58f759 creatorsName: cn=Manager,dc=mydomain,dc=com createTimestamp: 20110506070135Z entryCSN: 20110506070135.425379Z#000000#000#000000 modifiersName: cn=Manager,dc=mydomain,dc=com modifyTimestamp: 20110506070135Z ------------------------------------------------------- when I tried to fire slapadd ldap utility. following utility hand for infinite time. i had set max debug level( -d -1) for finding root cause. $ /usr/local/sbin/slapadd -v -d -1 -c -l mydata.ldif -f /usr/local/etc/openldap/slapd.conf -------------------------------------------------------- slapadd startup: initiated. backend_startup_one: starting "dc=mydomain,dc=com" bdb_db_open: "dc=mydomain,dc=com" bdb_db_open: database "dc=mydomain,dc=com": unclean shutdown detected; attempting recovery. bdb_db_open: database "dc=mydomain,dc=com": dbenv_open(/var/lib/ldap). bdb_monitor_db_open: monitoring disabled; configure monitor database to enable => str2entry: "dn: cn=SMGOperator,dc=mydomain,dc=com description: SMG Operator for managing job types roleType: Common tenantId: Global cn: SMGOperator objectClass: groupOfUniqueNames objectClass: top structuralObjectClass: groupOfUniqueNames entryUUID: 93385d1f-c9ec-4a1e-93fe-93f6cc58f759 creatorsName: cn=Manager,dc=mydomain,dc=com createTimestamp: 20110506070135Z entryCSN: 20110506070135.425379Z#000000#000#000000 modifiersName: cn=Manager,dc=mydomain,dc=com modifyTimestamp: 20110506070135Z " >>> dnPrettyNormal: <cn=SMGOperator,dc=mydomain,dc=com> <<< dnPrettyNormal: <cn=SMGOperator,dc=mydomain,dc=com>, <cn=smgoperator,dc=mydomain,dc=com> >>> dnPretty: <cn=Manager,dc=mydomain,dc=com> <<< dnPretty: <cn=Manager,dc=mydomain,dc=com> >>> dnNormalize: <cn=Manager,dc=mydomain,dc=com> <<< dnNormalize: <cn=manager,dc=mydomain,dc=com> >>> dnPretty: <cn=Manager,dc=mydomain,dc=com> <<< dnPretty: <cn=Manager,dc=mydomain,dc=com> >>> dnNormalize: <cn=Manager,dc=mydomain,dc=com> <<< dnNormalize: <cn=manager,dc=mydomain,dc=com> <= str2entry(cn=My Operator,dc=mydomain,dc=com) -> 0xb5e5be8 oc_check_required entry (cn=My Operator,dc=mydomain,dc=com), objectClass "groupOfUniqueNames" oc_check_allowed type "description" oc_check_allowed type "roleType" oc_check_allowed type "tenantId" oc_check_allowed type "cn" oc_check_allowed type "objectClass" oc_check_allowed type "structuralObjectClass" oc_check_allowed type "entryUUID" oc_check_allowed type "creatorsName" oc_check_allowed type "createTimestamp" oc_check_allowed type "entryCSN" oc_check_allowed type "modifiersName" oc_check_allowed type "modifyTimestamp" => bdb_tool_entry_put( -1, "cn=My Operator,dc=mydomain,dc=com" ) => bdb_dn2id("dc=mydomain,dc=com") <= bdb_dn2id: got id=0x1 => bdb_dn2id("cn=myoperator,dc=mydomain,dc=com") ------------------------------------------------------------ and even after enabling -q option , it completes but ldap server would not be able to start. (-q : enable quick [fewer integrity checks mode] Does fewer consistency checks on the input data, and no consistency checks when writing the database. Improves the load time but if any errors or interruptions occur the resulting database will be unusable.) $ /usr/local/sbin/slapadd -v -d -1 -q -c -l mydata.ldif -f /usr/local/etc/openldap/slapd.conf ------------------------------------------------------------- slapadd startup: initiated. backend_startup_one: starting "dc=dmbsso,dc=com" bdb_db_open: "dc=dmbsso,dc=com" bdb_db_open: database "dc=dmbsso,dc=com": unclean shutdown detected; attempting recovery. bdb_db_open: database "dc=dmbsso,dc=com": dbenv_open(/var/lib/ldap). bdb(dc=dmbsso,dc=com): recovery requires transaction support bdb_db_open: database "dc=dmbsso,dc=com" cannot be recovered, err 22. Restore from backup! ====> bdb_cache_release_all backend_startup_one (type=bdb, suffix="dc=dmbsso,dc=com"): bi_db_open failed! (22) slap_startup failed. -------------------------------------------------------------- even I am face with ldap utility slapcat, after firing it hanged up for infinite. It seems , there are some problem with ldif file, but this ldif file works well on other hosts (having same schema and molules and ldap configuration). We are facing this issue intermittently on some hosts, works well on some hosts(all are CentOS 5.5). is there some wrong in my understanding? Am I missing some thing in my configuration ? Is anyboby able to find root cause ? Eagerly waiting for your response. I can provide more like ldap log , ldap configuration (if that can help in debugging the issue) We are passing through very critical time. Regards, Sanjiv Singh Software Engineer (iLabs) Impetus Infotech (India) Pvt. Ltd. D-40, Sector-59, Noida - 201307, UP | (M) +91-9990-447-339 | www.impetus.com

1 0

(ITS#7067) openldap not properly starting
by sanjiv.is.on＠gmail.com 20 Oct '11

20 Oct '11

Full_Name: Sanjiv Singh Version: 2.4.20 OS: centOS 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (115.113.49.98) Hi all, I am facing openldap issue, facing problem during operation with openldap utilities. slapadd,ldapsearch and slapcat etc. I have installed & configure openldap 2.4.20 from source. enable debugginf level -1(max debug level). here is my LDIF that i want to add to my ldap server. mydata.ldif ------------------------------------------------------ dn: cn=My Operator,dc=mydomain ,dc=com description: My Operator for managing job types roleType: Common tenantId: Global cn: My Operator objectClass: groupOfUniqueNames objectClass: top structuralObjectClass: groupOfUniqueNames entryUUID: 93385d1f-c9ec-4a1e-93fe-93f6cc58f759 creatorsName: cn=Manager,dc=mydomain,dc=com createTimestamp: 20110506070135Z entryCSN: 20110506070135.425379Z#000000#000#000000 modifiersName: cn=Manager,dc=mydomain,dc=com modifyTimestamp: 20110506070135Z ------------------------------------------------------- when I tried to fire slapadd ldap utility. following utility hand for infinite time. i had set max debug level( -d -1) for finding root cause. $ /usr/local/sbin/slapadd -v -d -1 -c -l mydata.ldif -f /usr/local/etc/openldap/slapd.conf -------------------------------------------------------- slapadd startup: initiated. backend_startup_one: starting "dc=mydomain,dc=com" bdb_db_open: "dc=mydomain,dc=com" bdb_db_open: database "dc=mydomain,dc=com": unclean shutdown detected; attempting recovery. bdb_db_open: database "dc=mydomain,dc=com": dbenv_open(/var/lib/ldap). bdb_monitor_db_open: monitoring disabled; configure monitor database to enable => str2entry: "dn: cn=SMGOperator,dc=mydomain,dc=com description: SMG Operator for managing job types roleType: Common tenantId: Global cn: SMGOperator objectClass: groupOfUniqueNames objectClass: top structuralObjectClass: groupOfUniqueNames entryUUID: 93385d1f-c9ec-4a1e-93fe-93f6cc58f759 creatorsName: cn=Manager,dc=mydomain,dc=com createTimestamp: 20110506070135Z entryCSN: 20110506070135.425379Z#000000#000#000000 modifiersName: cn=Manager,dc=mydomain,dc=com modifyTimestamp: 20110506070135Z " >>> dnPrettyNormal: <cn=SMGOperator,dc=mydomain,dc=com> <<< dnPrettyNormal: <cn=SMGOperator,dc=mydomain,dc=com>, <cn=smgoperator,dc=mydomain,dc=com> >>> dnPretty: <cn=Manager,dc=mydomain,dc=com> <<< dnPretty: <cn=Manager,dc=mydomain,dc=com> >>> dnNormalize: <cn=Manager,dc=mydomain,dc=com> <<< dnNormalize: <cn=manager,dc=mydomain,dc=com> >>> dnPretty: <cn=Manager,dc=mydomain,dc=com> <<< dnPretty: <cn=Manager,dc=mydomain,dc=com> >>> dnNormalize: <cn=Manager,dc=mydomain,dc=com> <<< dnNormalize: <cn=manager,dc=mydomain,dc=com> <= str2entry(cn=My Operator,dc=mydomain,dc=com) -> 0xb5e5be8 oc_check_required entry (cn=My Operator,dc=mydomain,dc=com), objectClass "groupOfUniqueNames" oc_check_allowed type "description" oc_check_allowed type "roleType" oc_check_allowed type "tenantId" oc_check_allowed type "cn" oc_check_allowed type "objectClass" oc_check_allowed type "structuralObjectClass" oc_check_allowed type "entryUUID" oc_check_allowed type "creatorsName" oc_check_allowed type "createTimestamp" oc_check_allowed type "entryCSN" oc_check_allowed type "modifiersName" oc_check_allowed type "modifyTimestamp" => bdb_tool_entry_put( -1, "cn=My Operator,dc=mydomain,dc=com" ) => bdb_dn2id("dc=mydomain,dc=com") <= bdb_dn2id: got id=0x1 => bdb_dn2id("cn=myoperator,dc=mydomain,dc=com") ------------------------------------------------------------ and even after enabling -q option , it completes but ldap server would not be able to start. (-q : enable quick [fewer integrity checks mode] Does fewer consistency checks on the input data, and no consistency checks when writing the database. Improves the load time but if any errors or interruptions occur the resulting database will be unusable.) $ /usr/local/sbin/slapadd -v -d -1 -q -c -l mydata.ldif -f /usr/local/etc/openldap/slapd.conf ------------------------------------------------------------- slapadd startup: initiated. backend_startup_one: starting "dc=dmbsso,dc=com" bdb_db_open: "dc=dmbsso,dc=com" bdb_db_open: database "dc=dmbsso,dc=com": unclean shutdown detected; attempting recovery. bdb_db_open: database "dc=dmbsso,dc=com": dbenv_open(/var/lib/ldap). bdb(dc=dmbsso,dc=com): recovery requires transaction support bdb_db_open: database "dc=dmbsso,dc=com" cannot be recovered, err 22. Restore from backup! ====> bdb_cache_release_all backend_startup_one (type=bdb, suffix="dc=dmbsso,dc=com"): bi_db_open failed! (22) slap_startup failed. -------------------------------------------------------------- even I am face with ldap utility slapcat, after firing it hanged up for infinite. It seems , there are some problem with ldif file, but this ldif file works well on other hosts (having same schema and molules and ldap configuration). We are facing this issue intermittently on some hosts, works well on some hosts(all are CentOS 5.5). is there some wrong in my understanding? Am I missing some thing in my configuration ? Is anyboby able to find root cause ? Eagerly waiting for your response. I can provide more like ldap log , ldap configuration (if that can help in debugging the issue) We are passing through very critical time. Regards, Sanjiv Singh Software Engineer (iLabs) Impetus Infotech (India) Pvt. Ltd. D-40, Sector-59, Noida - 201307, UP | (M) +91-9990-447-339 | www.impetus.com

1 0

Re: (ITS#6987) cn=config renumbers indexes on startup without modrdn-ing them
by ondrej.kuznik＠acision.com 19 Oct '11

19 Oct '11

On 07/07/2011 03:26 PM, ondrej.kuznik(a)acision.com wrote: > ftp://ftp.openldap.org/incoming/ondrej-kuznik-20110707.c > has an example of such overlay. To try it, initialize the overlay and > add these entries: > > dn: olcTestAttrOne=zero,$OVERLAY_DN > objectclass: olcTestOne > > dn: olcTestAttrTwo=one,$OVERLAY_DN > objectclass: olcTestTwo > > dn: olcTestAttrOne=two,$OVERLAY_DN > objectclass: olcTestOne > > dn: olcTestAttrTwo=three,$OVERLAY_DN > objectclass: olcTestTwo > > After a restart compare the output of slapcat -n0 with the output of > ldapsearch -b cn=config, you should see at least one different entry. > You might also try to modify the entries before and after the restart. > For those that do not match you get "no such object" as the dn is no > longer in the ldif database. The issue is in bconfig.c:4726, the code treats all siblings as part of one ordering (contrary to what http://highlandsun.com/hyc/drafts/draft-chu-ldap-xordered-xx.html implies since cn=config seems to treat everything as X-ORDERED 'SIBLINGS'), while back-ldif orders them accordingly. Also its caller (config_ldif_resp) does not expect any reordering to be necessary, after all it should be (and is) reading a valid cn=config db, so the entry renaming then never gets propagated to back-ldif causing this desync. -- Ondrej Kuznik 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

(ITS#7066) ACL added to back-config only active after restart
by rhafer＠suse.de 18 Oct '11

18 Oct '11

Full_Name: Ralf Haferkamp Version: RE24, master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.171.158) The first ACL added to "olcDatabase={0}config,cn=config" does only get active after slapd is restarted. This is because slapd upon startup creates a hardcoded deny-everything ACL when no ACL is defined explicitly for the database. ACLs added after slapd is started will be appended to that hardcoded ACL (but never evaluated as the hardcoded one already matches everything). I am working on a fix, reworking the way how the hardcoded default ACL for olcDatabase={0}config,cn=config is applied.

1 0

(ITS#7065) changeType: modify "replace/delete" trick causes segmentation fault in cn=config
by jeffreyc＠ucsc.edu 17 Oct '11

17 Oct '11

Full_Name: Jeffrey Crawford Version: 2.4.26 OS: FreeBSD 8.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (169.233.224.28) To guarantee the removal of an attribute when I don't know if the attribute exists already or not I often employ the following LDIF: ============== dn: cn=config changeType: modify replace: attrToDelete attrToDelete: dummy - delete: attrToDelete ============== Howver every time I run the above against cn=config it causes a segmentation fault. It does not cause any problems with a hdb backends. I like to set up ldifs that i can run generically without having to know if content is there or not so I do use this. I can work around it by just separating the above out into two "dn" instructions. but if for example one wanted to remove Indexes, that intermediate update might cause some process to start then abruptly stop or not stop. The above failure is consistant, so hopefully easy to find.

1 0

(ITS#7064) moznss SEC_ERROR_BAD_SIGNATURE with a certificate trusted by OpenSSL
by massimo.gravino＠pd.infn.it 17 Oct '11

17 Oct '11

Full_Name: Massimo Gravino Version: 2.4.23-15 OS: Scientific Linux 6.1 URL: Submission from: (NULL) (192.84.143.111) We have an openldap server that uses LDAP over TLS/SSL and serves hundreds of clients. The CA used to sign the server certificate was created in 2005 with OpenSSL 0.9.7a. The CA self signed certificate and the server certificate have been used until now without any problem. In the server configuration (/etc/openldap/slapd.conf) we use TLSCertificateFile and TLSCertificateKeyFile to specify the path to the pem files of the certificate and private key of the server, and TLSCACertificateFile for the path to the pem file of the self signed certificate of the CA. In the client configuration (/etc/openldap/ldap.conf) we only define TLS_CACERT to specify the path to the pem file of the CA certificate. Now we are not able to use the the CA certificate on new Scientific Linux 6.1 clients with openldap 2.4.23-15: the problem appears with the standard openldap-2.4.23-15.el6 package that is compiled using MozNSS. If we recompile it using OpenSSL, the problem disappears (to recompile I simply edit the .spec file and omit -DHAVE_MOZNSS from the CFLAGS definition, change the --with-tls=no option to --with-tls=openssl and rebuild with rpmbuild -ba). This is the error obtained from the client with the original package when using ldapsearch: ldapsearch -x -d1 .... TLS: loaded CA certificate file /etc/openldap/cacerts/cacert.pem. TLS: certificate [CN=my.server.name,OU=Sezione di Padova,O=INFN,L=Padova,ST=Italia,C=IT] is not valid - error -8182:Unknown code ___f 10. TLS: error: connect - force handshake failure: errno 21 - moznss error -8182 TLS: can't connect: TLS error -8182:Unknown code ___f 10. ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) The problem appears to be related to our particular CA, that uses a DSA key. I've never been able to reproduce the problem creating new CA with an rsa key; however if possible I'd not change the the CA that signes my server certificate, because in this case I should change the CA certificate on a lot of clients. Nor I would manually recompile every new version of openldap packages. So I collected all the steps necessary to reproduce this problem on Scientific linux 6.1 server and client, with openldap 2.4.23-15 and openssl 1.0.0-10, hoping that the problem will be considered a bug in MozNSS. Certification Authority creation -------------------------------- mkdir CA cd CA/ mkdir certs crl newcerts private touch index.txt echo "01" > serial edit /etc/pki/tls/openssl.cnf and change the dir definition in [ CA_default ] to point to the CA/ directory openssl dsaparam -out dsaparam.pem 2048 openssl req -new -x509 -keyout private/cakey.pem -out cacert.pem -newkey dsa:dsaparam.pem -days 5000 Server certificate creation and signing --------------------------------------- openssl req -new -keyout key.pem -out req.pem -newkey rsa:2048 -nodes openssl ca -policy policy_anything -out cert.pem -in req.pem Now copy cert.pem and key.pem on the server, and cacert.pem on the server and the client (may be the same machine) and change appropriately the values of TLSCertificateFile, TLSCertificateKeyFile and TLSCACertificateFile in the server configuration, and TLS_CACERT in the client configuration. Start the server with /usr/sbin/slapd -h ldaps:/// -u ldap -d 1 Then on the client use: ldapsearch -x -d1 On the server side you should see something like this: TLS: loaded CA certificate file /etc/openldap/cacerts/cacert.pem. TLS: certificate [E=admin(a)my.domain,CN=server.fqdn,OU=Sezione di Padova,O=INFN,L=Padova ,ST=Italia,C=IT] is valid TLS: error: accept - force handshake failure: errno 21 - moznss error -12271 TLS: can't accept: TLS error -12271:Unknown code ___P 17. connection_read(11): TLS accept failure error=-1 id=1000, closing connection_close: conn=1000 sd=11 And on the client side: TLS: loaded CA certificate file /etc/openldap/cacerts/cacert.pem. TLS: certificate [E=admin(a)my.domain,CN=server.fqdn,OU=Sezione di Padova,O=INFN,L=Padova,ST=Italia,C=IT] is not valid - error -8182:Unknown code ___f 10. TLS: error: connect - force handshake failure: errno 21 - moznss error -8182 TLS: can't connect: TLS error -8182:Unknown code ___f 10. ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) Note that server says: certificate is valid but SSL peer cannot verify it (moznss error -12271: SSL_ERROR_BAD_CERT_ALERT) On the other side the client says: certificate is not valid because has an invalid signature (moznss error -8182: SEC_ERROR_BAD_SIGNATURE) As I said above, the problem disappears recompiling openldap with OpenSSL instead of MozNSS.

1 0

Re: (ITS#6900) dnattr acl statement: users can produce dangling entries
by daniel＠pluta.biz 14 Oct '11

14 Oct '11

Hi Howard, as we've discussed during LDAPCon2011's get-together the following idea is currently not supported in slapd. For demonstration purposes I've introduced a <dnattrstyle> that only supports one style-descriptor called ".strict". It restricts "dnattr=..." ACL statements the way that self is not allowed to remove her own DN from dnattr. I've tested the patch with the following simple sample ACLs: to dn.base="ou=groups,dc=foo,dc=bar" attrs=children by users write to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,@groupOfNames by dnattr.strict=owner write by users read According these two ACLs a group's owner is allowed to write the whole object (not only add, but also delete, aka in sum "write"). Nevertheless, because of the ".strict" the owner is not able to delete his own DN from the owner attribute. You can find an updated version of my patch here: ftp://ftp.openldap.org/incoming/Daniel-Pluta-111014.patch As it is still intended for demonstration purposes, the patch is highly probable suboptimal regarding its implementation, in particular regarding the chosen place within slapd's code. Instead of the <dnattrstyle> probably a new "<access>" called e.g. "writeToSelfButSelfNoDelete" or similar should be introduced instead. Unfortunately, I don't know how to code this correctly without changing/breaking the whole acl-engine and introducing various "funny" side-effects. Best regards Daniel P.S. Furthermore, and although I've no related scenario in mind, it perhaps could make sense to generalize this kind of behaviour also into direction to "writeToSelfButSelfNoAdd" etc. I'm not sure whether this would make sense, too.

1 0

(ITS#7063) OpenLDAP don't provide some schema file in ldif format
by raphael.ouazana＠linagora.com 12 Oct '11

12 Oct '11

Full_Name: Raphael Ouazana Version: 2.4.26 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.232.151) Hi, Some schema files are missing from schema/ directory: collective.ldif corba.ldif duaconf.ldif java.ldif misc.ldif pmi.ldif ppolicy.ldif Regards, Raphaël Ouazana.

1 0

(ITS#7062) writes from lost connections not increasing contextCSN
by ebackes＠symas.com 11 Oct '11

11 Oct '11

Full_Name: Emily Backes Version: 2.4.26 OS: any URL: Submission from: (NULL) (75.244.124.114) If a client connects and writes, e.g. ADDs entries, then disconnects before seeing the result, the writes are stored in the database but do not increment contextCSN. This can be seen without replicas being involved, but obviously still needs syncprov. $ ldapadd -x -D dc=example,dc=com -w secret -H ldap://localhost:1389/ -f people.ldif adding new entry "cn=1,ou=people,dc=example,dc=com" adding new entry "cn=2,ou=people,dc=example,dc=com" ... adding new entry "cn=22,ou=people,dc=example,dc=com" ^C $ ldapsearch -x -D dc=example,dc=com -w secret -H ldap://localhost:1389/ -b dc=example,dc=com -LLL '(cn=22)' entryCSN dn: cn=22,ou=people,dc=example,dc=com entryCSN: 20111011235653.469937Z#000000#001#000000 $ ldapsearch -x -D dc=example,dc=com -w secret -H ldap://localhost:1389/ -b dc=example,dc=com -LLL -s base contextCSN dn: dc=example,dc=com contextCSN: 20111011235653.380889Z#000000#001#000000 stats+sync log: conn=1000 op=21 ADD dn="cn=21,ou=people,dc=example,dc=com" slap_queue_csn: queing 0x105e00100 20111011235653.380889Z#000000#001#000000 conn=1000 op=21 RESULT tag=105 err=0 text= slap_graduate_commit_csn: removing 0x10178e0a0 20111011235653.380889Z#000000#001#000000 conn=1000 op=22 ADD dn="cn=22,ou=people,dc=example,dc=com" slap_queue_csn: queing 0x105e00100 20111011235653.469937Z#000000#001#000000 slap_graduate_commit_csn: removing 0x10178e520 20111011235653.469937Z#000000#001#000000 conn=1000 fd=10 closed (connection lost) The change isn't sent out to connected refreshAndPersist replicas either, and forcing them to reconnect doesn't help, as their contextCSNs still match across the board. This can cause persistent desynchronization of servers.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs