- openldap-bugs - openldap.org

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by hyc＠symas.com 06 Apr '12

06 Apr '12

quanah(a)zimbra.com wrote: > --On Thursday, April 05, 2012 7:38 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > >> On Thu, 5 Apr 2012 13:12:31 GMT, michael(a)stroeder.com wrote: >>> hyc(a)symas.com wrote: >>>> michael(a)stroeder.com wrote: >>>>> 2. add an equality matching rule. >>>> >>>> My approach with config attrs has been to skip the equality rule for >>>> single-valued attrs. Since they are single-valued, there's obviously >>>> no need >>>> to allow for comparing multiple values. >> >> Users always find more ways to use a feature than its creator imagined. >> >> I wish people would give attributes all matching rules they can. >> Equality, ordering, substring. Except when: >> - flexibility would be a misfeature, e.g. SUBSTR for userPassword, >> - or it's unclear which rules to choose, e.g. caseIgnore vs caseExact. > > I agree. I think defining matching rules where possible is extremely > useful. Patch welcome. This is a pretty trivial patch to write, but I have more urgent things to attend to. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6656) logging "reqEntryUUID" in accesslog
by michael＠stroeder.com 06 Apr '12

06 Apr '12

This is a cryptographically signed message in MIME format. --------------ms030508030008000509010204 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please revisit this ITS. I'd like to implement something like "svn revert= " based on accesslog entries. Having the entry's UUID in an indexable attri= bute would make this more robust. This could also be handy for delta-replication if "conflicting" modrdn requests were sent by a client which result in same reqDN. Ciao, Michael. --------------ms030508030008000509010204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQwNjA5NDgyNVowIwYJKoZIhvcNAQkEMRYE FEygunV2ggv0vvJFXsDT6osh9+aiMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAd3aWU7Cwit2Su125+MLAv0K6Ar9XJF9Uhm+X68eeerTXodk1MKIG9JX7PsdFrQyAX3KE R1PjeWVfQvUnVMlutKSem29k6q6pd+iATl+bSB3PgJXWyPKk2K3S2gAGPmL8vubRwEfoCCqt OJBAxseomsPbO1310vSt1KsJYxnLYIQIsBuY0mGWmNcwYCnLitW3erW1ipvancsxwVI4Uy4D EiwtVrP75c1f20VRdiUA5dCeBfi2f18bsyUyaLTccC7vHCMkwSx4VXJk8rEyYB74UpHM/Zbv a5tNipz5K3YDkSJbRhB+Qma2+hMSzvFhbq1XwI6HBladZ8hDmqOYZqGBhwAAAAAAAA== --------------ms030508030008000509010204--

1 0

Re: (ITS#7227) Problem to add new entry
by rai.abhishek＠yahoo.com 06 Apr '12

06 Apr '12

--1454997657-1528916171-1333689558=:73347 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi All=0A=0AI am using OpenLDAP server and use .net application as a client= but face issue regarding add new entry like (Country and Organization etc)= . the error message are =0A=0AAn error occurred while creating entry.=0AThe= server is not willing to handle directory requests.=0A=0Abut with the same= setting and access rights=A0i am able to create some entry like (Person,Gr= oup,Organizational Unit) i am new for OpenLDAP but as per my understanding = it's a access problem in slapd.conf file.=0A=0Afor safe point i am modifyed= the slapd.conf file and provide below access slapd.conf =0Aaccess to * by= * write=0A=A0=0Ato achieve this operation.=0A=A0=0APlease suggest what acc= ess rights need to provide or what changes need to done to resolve this pro= blem.=0A=A0=0AI am waiting for your replay.=0A=0A=0A=0A=0AThanks & Regards= =0AAbhishek Rai=0AHCL Technolog=0A =0A=0A________________________________= =0A From: Quanah Gibson-Mount <quanah(a)zimbra.com>=0ATo: rai.abhishek(a)yahoo.= com; openldap-its(a)openldap.org =0ASent: Friday, April 6, 2012 12:54 AM=0ASu= bject: Re: (ITS#7227) Problem to add new entry=0A =0A--On Thursday, April = 05, 2012 12:38 PM +0000 rai.abhishek(a)yahoo.com wrote:=0A=0A> Full_Name: Abh= ishek Rai=0A> Version: 3=0A> OS: Windows Server 2008 R2=0A> URL: ftp://ftp.= openldap.org/incoming/=0A> Submission from: (NULL) (207.46.55.29)=0A=0ATHe = ITS system is for reporting bugs, not asking usage questions.=A0 I suggest = you subscribe to the openldap-technical(a)openldap.org list, and ask your usa= ge questions there.=0A=0AThis ITS will be closed.=0A=0A--Quanah=0A=0A=0A--= =0A=0AQuanah Gibson-Mount=0ASr. Member of Technical Staff=0AZimbra, Inc=0AA= Division of VMware, Inc.=0A--------------------=0AZimbra ::=A0 the leader = in open source messaging and collaboration --1454997657-1528916171-1333689558=:73347 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:ve= rdana, helvetica, sans-serif;font-size:12pt"><div><span>Hi All<br><br>I am = using OpenLDAP server and use .net application as a client but face issue r= egarding add new entry like (Country and Organization etc). the error messa= ge are <br><br>An error occurred while creating entry.<br>The server is not= willing to handle directory requests.<br><br>but with the same setting and= access rights i am able to create some entry like (Person,Group,Organ= izational Unit) i am new for OpenLDAP but as per my understanding it's a ac= cess problem in slapd.conf file.<br><br>for safe point i am modifyed the sl= apd.conf file and provide below access slapd.conf <br>access to * by * wri= te</span></div><div><span></span> </div><div><span>to achieve this ope= ration.</span></div><div><span></span> </div><div><span>Please suggest= what access rights need to provide or what changes need to done to resolve this problem.</span></div><div><span></span> </div><div><span= >I am waiting for your replay.</div><div><br><br><br></div></span><div></di= v><div> </div><div>Thanks & Regards<br>Abhishek Rai<br>HCL Technol= og<br></div> <div style=3D"font-family: verdana, helvetica, sans-serif; fo= nt-size: 12pt;"> <div style=3D"font-family: times new roman, new york, time= s, serif; font-size: 12pt;"> <div dir=3D"ltr"> <font size=3D"2" face=3D"Ari= al"> <div style=3D"margin: 5px 0px; padding: 0px; border: 1px solid rgb(204= , 204, 204); height: 0px; line-height: 0; font-size: 0px;" class=3D"hr" con= tentEditable=3D"false" readonly=3D"true"></div> <b><span style=3D"font-wei= ght: bold;">From:</span></b> Quanah Gibson-Mount <quanah(a)zimbra.com><= br> <b><span style=3D"font-weight: bold;">To:</span></b> rai.abhishek@yahoo= .com; openldap-its(a)openldap.org <br> <b><span style=3D"font-weight: bold;">= Sent:</span></b> Friday, April 6, 2012 12:54 AM<br> <b><span style=3D"font-= weight: bold;">Subject:</span></b> Re: (ITS#7227) Problem to add new entry<br> </f= ont> </div> <br>=0A--On Thursday, April 05, 2012 12:38 PM +0000 <a href=3D"= mailto:rai.abhishek@yahoo.com" ymailto=3D"mailto:rai.abhishek@yahoo.com">ra= i.abhishek(a)yahoo.com</a> wrote:<br><br>> Full_Name: Abhishek Rai<br>>= Version: 3<br>> OS: Windows Server 2008 R2<br>> URL: <a href=3D"ftp:= //ftp.openldap.org/incoming/" target=3D"_blank">ftp://ftp.openldap.org/inco= ming/</a><br>> Submission from: (NULL) (207.46.55.29)<br><br>THe ITS sys= tem is for reporting bugs, not asking usage questions.  I suggest you = subscribe to the <a href=3D"mailto:openldap-technical@openldap.org" ymailto= =3D"mailto:openldap-technical@openldap.org">openldap-technical(a)openldap.org= </a> list, and ask your usage questions there.<br><br>This ITS will be clos= ed.<br><br>--Quanah<br><br><br>--<br><br>Quanah Gibson-Mount<br>Sr. Member = of Technical Staff<br>Zimbra, Inc<br>A Division of VMware, Inc.<br>--------= ------------<br>Zimbra ::  the leader in open source messaging and col= laboration<br><br><br> </div> </div> </div></body></html> --1454997657-1528916171-1333689558=:73347--

1 0

(ITS#7231) back0hdb search results disappear depending on search base
by hume-ol＠bofh.ca 06 Apr '12

06 Apr '12

Full_Name: Brandon Hume Version: -OPENLDAP_REL_ENG_2_4-0e03b13 OS: Redhat AS6 URL: http://den.bofh.ca/~hume/ldap_missing_results.tar.gz Submission from: (NULL) (2610:170:2c00:7:224:1ff:fed4:b4ff) Firstly, using RE24 built with the following ./configure: #!/bin/sh env CC=gcc CFLAGS="-m64 -ggdb" LDFLAGS="-Wl,-rpath -Wl,/appl/ldap/lib -L/appl/ldap/lib" CPPFLAGS="-I/appl/ldap/include" \ ./configure --prefix=/appl/ldap \ --libexecdir=/appl/ldap/sbin --localstatedir=/var/run --datadir=/appl/ldap/data \ --sysconfdir=/appl/ldap/etc --mandir=/appl/ldap/man --with-subdir=no \ --disable-rlookups --with-tls=openssl \ --enable-slapd --enable-crypt --with-cyrus-sasl=no --enable-debug \ --enable-dynamic --enable-modules \ --enable-backends=mod --enable-overlays=mod --enable-sql=no \ --enable-perl=no --enable-ndb=no --enable-shell=no Paired with BerkeleyDB built with the following: #!/bin/sh env CC=gcc CFLAGS="-m64 -ggdb" LDFLAGS="-Wl,-rpath -Wl,/appl/ldap/lib -L/appl/ldap/lib" CPPFLAGS="-I/appl/ldap/include" \ ../dist/configure --prefix=/appl/ldap DIT has 131207 entries. Search results will come and go as you shorten the search base. For example, when searching for "maillocaladdress=vbroken(a)dal.ca", which has the full DN of "cn=broken129251,cn=dal,cn=Mailmaps,cn=Services,dc=DAL,dc=CA", the following will occur: Searching with base=cn=dal,cn=Mailmaps,cn=services,dc=dal,dc=ca: Found. Searching with base=cn=Mailmaps,cn=services,dc=dal,dc=ca: NOT found. Searching with base=cn=services,dc=dal,dc=ca: NOT found. Searching with base=dc=dal,dc=ca: Found. cn=dal has 123312 children, which is very high. However, breaking the branch up into subcontainers, none of which had more than 10k entries, did not cure the problem. With olcLogLevel=any, the following is notable: Successful search: Apr 5 21:09:01 kil-ds-3 slapd[17628]: => hdb_dn2idl("cn=dal,cn=mailmaps,cn=services,dc=dal,dc=ca") Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:09:03 kil-ds-3 slapd[17628]: #011AND Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_list_candidates 0xa0 Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:09:03 kil-ds-3 slapd[17628]: #011OR Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_list_candidates 0xa1 Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:09:03 kil-ds-3 slapd[17628]: #011EQUALITY Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_equality_candidates (objectClass) Apr 5 21:09:03 kil-ds-3 slapd[17628]: => key_read Apr 5 21:09:03 kil-ds-3 slapd[17628]: bdb_idl_fetch_key: [b49d1940] Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_index_read: failed (-30988) Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_equality_candidates: id=0, first=0, last=0 Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=0 first=0 last=0 Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:09:03 kil-ds-3 slapd[17628]: #011EQUALITY Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_equality_candidates (mailLocalAddress) Apr 5 21:09:03 kil-ds-3 slapd[17628]: => key_read Apr 5 21:09:03 kil-ds-3 slapd[17628]: bdb_idl_fetch_key: [217e141f] Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_index_read 1 candidates Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_equality_candidates: id=1, first=129301, last=129301 Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=1 first=129301 last=129301 Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_list_candidates: id=1 first=129301 last=129301 Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=1 first=129301 last=129301 Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_list_candidates: id=1 first=129301 last=129301 Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=1 first=129301 last=129301 Apr 5 21:09:03 kil-ds-3 slapd[17628]: bdb_search_candidates: id=1 first=129301 last=129301 Apr 5 21:09:03 kil-ds-3 slapd[17628]: entry_decode: "" Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= entry_decode() Apr 5 21:09:03 kil-ds-3 slapd[17628]: => test_filter Unsuccessful search: Apr 5 21:10:34 kil-ds-3 slapd[17628]: => hdb_dn2idl("cn=mailmaps,cn=services,dc=dal,dc=ca") Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:10:34 kil-ds-3 slapd[17628]: #011AND Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_list_candidates 0xa0 Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:10:34 kil-ds-3 slapd[17628]: #011OR Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_list_candidates 0xa1 Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:10:34 kil-ds-3 slapd[17628]: #011EQUALITY Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_equality_candidates (objectClass) Apr 5 21:10:34 kil-ds-3 slapd[17628]: => key_read Apr 5 21:10:34 kil-ds-3 slapd[17628]: bdb_idl_fetch_key: [b49d1940] Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_index_read: failed (-30988) Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_equality_candidates: id=0, first=0, last=0 Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=0 first=0 last=0 Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:10:34 kil-ds-3 slapd[17628]: #011EQUALITY Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_equality_candidates (mailLocalAddress) Apr 5 21:10:34 kil-ds-3 slapd[17628]: => key_read Apr 5 21:10:34 kil-ds-3 slapd[17628]: bdb_idl_fetch_key: [217e141f] Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_index_read 1 candidates Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_equality_candidates: id=1, first=129301, last=129301 Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=1 first=129301 last=129301 Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_list_candidates: id=1 first=129301 last=129301 Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=1 first=129301 last=129301 Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_list_candidates: id=0 first=3 last=0 Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=0 first=3 last=0 Apr 5 21:10:34 kil-ds-3 slapd[17628]: bdb_search_candidates: id=0 first=3 last=0 Apr 5 21:10:34 kil-ds-3 slapd[17628]: hdb_search: no candidates Apr 5 21:10:34 kil-ds-3 slapd[17628]: send_ldap_result: conn=1001 op=1 p=3 Apr 5 21:10:34 kil-ds-3 slapd[17628]: send_ldap_result: err=0 matched="" text="" Apr 5 21:10:34 kil-ds-3 slapd[17628]: send_ldap_response: msgid=2 tag=101 err=0 Apr 5 21:10:34 kil-ds-3 slapd[17628]: conn=1001 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= I'm including a link to a tarball that contains: - My (simplified) config, that still produces the problem. I'm managed to remove locally-created schemas. - My test LDIF, containing the entries that can produce the problem. They've been anonymized, but it doesn't affect the problem. A server loaded with the above config and this DIT will be consistently unable to find the "maillocaladdress=vbroken(a)dal.ca" entry at cn=services,dc=dal,dc=ca search base. - My test script, test_ldap.sh, that searches for the above entry at the levels in between it and the base naming context (dc=dal,dc=ca). I can provide more if needed, up to and including the compiled binaries.

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by quanah＠zimbra.com 05 Apr '12

05 Apr '12

--On Thursday, April 05, 2012 7:38 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > On Thu, 5 Apr 2012 13:12:31 GMT, michael(a)stroeder.com wrote: >> hyc(a)symas.com wrote: >>> michael(a)stroeder.com wrote: >>>> 2. add an equality matching rule. >>> >>> My approach with config attrs has been to skip the equality rule for >>> single-valued attrs. Since they are single-valued, there's obviously >>> no need >>> to allow for comparing multiple values. > > Users always find more ways to use a feature than its creator imagined. > > I wish people would give attributes all matching rules they can. > Equality, ordering, substring. Except when: > - flexibility would be a misfeature, e.g. SUBSTR for userPassword, > - or it's unclear which rules to choose, e.g. caseIgnore vs caseExact. I agree. I think defining matching rules where possible is extremely useful. --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#7226) olcAuditlogFile At dos not accept multiple values
by h.b.furuseth＠usit.uio.no 05 Apr '12

05 Apr '12

On Thu, 5 Apr 2012 13:12:31 GMT, michael(a)stroeder.com wrote: >hyc(a)symas.com wrote: >>michael(a)stroeder.com wrote: >>> 2. add an equality matching rule. >> >> My approach with config attrs has been to skip the equality rule for >> single-valued attrs. Since they are single-valued, there's obviously >> no need >> to allow for comparing multiple values. Users always find more ways to use a feature than its creator imagined. I wish people would give attributes all matching rules they can. Equality, ordering, substring. Except when: - flexibility would be a misfeature, e.g. SUBSTR for userPassword, - or it's unclear which rules to choose, e.g. caseIgnore vs caseExact. > They are not searchable either then. Does it add too much overhead to > add an > equality matching rule? > > Personally I currently can't imagine a use-case for searching an > entry using > attribute olcAuditlogFile but one never knows... "Which database gets logged to file /whatever"? Also, as you mention, an EQUALITY rule allows sanity checking, like an atomic "verify old value and then change to new value" operation. -- Hallvard

1 0

Re: (ITS#7227) Problem to add new entry
by quanah＠zimbra.com 05 Apr '12

05 Apr '12

--On Thursday, April 05, 2012 12:38 PM +0000 rai.abhishek(a)yahoo.com wrote: > Full_Name: Abhishek Rai > Version: 3 > OS: Windows Server 2008 R2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (207.46.55.29) THe ITS system is for reporting bugs, not asking usage questions. I suggest you subscribe to the openldap-technical(a)openldap.org list, and ask your usage questions there. 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#7230) back-mdb: slapadd fails when not run in quickmode
by quanah＠OpenLDAP.org 05 Apr '12

05 Apr '12

Full_Name: Quanah Gibson-Mount Version: RE24 4/4/2012 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) Running slapadd without quickmode quickly results in failure: zimbra@zre-ldap001:~$ time /opt/zimbra/openldap/sbin/slapadd -b "" -l /tmp/ldap.bak -F /opt/zimbra/data/ldap/config * 0.63% eta 01h08m elapsed 26s spd 1.1 M/s slapadd: ./../../../libraries/libmdb/mdb.c:3459: mdb_page_search: Assertion `root > 1' failed. Aborted

1 0

(ITS#7229) back-mdb: unable to load large databases
by quanah＠OpenLDAP.org 05 Apr '12

05 Apr '12

Full_Name: Quanah Gibson-Mount Version: RE24 4/4/2012 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) When loading a large database via slapadd -q, back-mdb fails: zimbra@zre-ldap001:~$ time /opt/zimbra/openldap/sbin/slapadd -q -b "" -l /tmp/ldap.bak -F /opt/zimbra/data/ldap/config -## 13.49% eta 51m39s elapsed 08m03s spd 1.2 M/s 4f7dee09 mdb_id2entry_put: mdb_put failed: No space left on device(28) "uid=yyyyyyy,ou=people,dc=xxxxxx,dc=com" 4f7dee09 => mdb_tool_entry_put: id2entry_add failed: err=80 4f7dee09 => mdb_tool_entry_put: txn_aborted! Internal error (80) slapadd: could not add entry dn="uid=yyyyyy,ou=people,dc=xxxxx,dc=com" (line=17539364): txn_aborted! Internal error (80) .## 13.50% eta 51m39s elapsed 08m03s spd 1.5 M/s Closing DB...Error, entries missing! entry 20241: uid=zzzzzz,ou=people,dc=xxx,dc=com entry 83243: uid=zzzzzzzz,ou=people,dc=xxxxxx,dc=com entry 85232: uid=zzzzzzzzzzzz,ou=people,dc=xxxxx,dc=com entry 93399: uid=zzzzzzzzzzzzz,ou=people,dc=xxxxx,dc=com entry 113549: uid=zzzzzzzzz,ou=people,dc=xxxxx,dc=com entry 138089: uid=zzzzzzzzzz,ou=people,dc=xxxxxx,dc=com entry 140319: uid=zzzzzzzz,ou=people,dc=xxxxx,dc=com entry 152722: uid=zzzzzzzz,ou=people,dc=xxxxxx,dc=com entry 154989: uid=zzzzzzzzz,ou=people,dc=xxxxxx,dc=com entry 164912: uid=zzzzzzzzz,ou=people,dc=xxxxx,dc=net entry 166738: uid=zzzzzzzzzz,ou=people,dc=xxxxxx,dc=com entry 167049: uid=zzzzzzzzzzz,ou=people,dc=xxxxxxxxxx,dc=com entry 177778: uid=zzzzzzzz,ou=people,dc=xxxxxx,dc=com entry 195907: uid=zzz,ou=people,dc=xxxxxx,dc=com (etc)

1 0

RE: (ITS#7228) Authentication Problem When Using PPolicy and Chaining
by Jong.Limb＠dss.virginia.gov 05 Apr '12

05 Apr '12

I have built and tested 2.4.30, and it works as expected. I now get invalid credentials when I hit the consumer with an incorrect password. However, I believe that the script should still be modified to check the return code from the first ldapsearch in order to prevent something like this developing in the future. You can close this ITS. Thanks. Jong Limb Division of Information Systems Virginia Department of Social Services 804-726-7823 -----Original Message----- From: Limb, Jong (VDSS) Sent: Thursday, April 05, 2012 11:31 AM To: 'Howard Chu' Cc: openldap-its(a)OpenLDAP.org Subject: RE: (ITS#7228) Authentication Problem When Using PPolicy and Chaining I believe the test is incorrect. Near the bottom of the script, there is this section of code: $LDAPSEARCH -H $URI2 -D "$USER" -w wrongpw >$SEARCHOUT 2>&1 $LDAPSEARCH -H $URI1 -D "$MANAGERDN" -w $PASSWD -b "$USER" \* \+ >> $SEARCHOUT 2>&1 COUNT=`grep "pwdFailureTime" $SEARCHOUT | wc -l` echo "jkl 13" if test $COUNT != 1 ; then echo "Policy state forwarding failed" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit 1 fi The first LDAPSEARCH should have its return code checked, and for an incorrect password, it should be 49. If the script is modified to check for 49 and fail otherwise, it will fail. Unfortunately, I am not in a position to use a newer version of OpenLDAP, but I will build it and run the tests to see if the problem exists there as well. I will report back with my findings. Jong Limb Division of Information Systems Virginia Department of Social Services 804-726-7823 -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Thursday, April 05, 2012 10:17 AM To: Limb, Jong (VDSS) Cc: openldap-its(a)OpenLDAP.org Subject: Re: (ITS#7228) Authentication Problem When Using PPolicy and Chaining jong.limb(a)dss.virginia.gov wrote: > Full_Name: Jong K. Limb > Version: 2.4.23 > OS: RHEL 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (166.67.66.5) > > > I have the following setup: > - Provider LDAP server used only by those applications that change passwords > - Consumer LDAP servers used by all applications that want to authenticate > users > - The provider and consumers have password policy configured so that the > accounts lock after 3 failed attempts > - In order to maintain synchronization of failed login attempts across all > consumers, I also enabled chaining from the consumers to the master > > If an attempt is made to authenticate against the consumer with an invalid > password (for example, using ldapsearch), the pwdFailureTime attribute is > added/updated on the provider and eventually synced to the consumer, but the > operation succeeds when it should not have. > > If I remove the password policy overlay (leaving all other configuration the > same) and run ldapsearch with an invalid password against a consumer, the > operation will fail with invalid credentials as it should. > > I have done a little debugging, and it looks like the response that gets > returned to the client is the response to the modify operation that the consumer > makes to the provider to add/update the pwdFailureTime attribute, and not the > response to the bind operation. The modify operation is successful here, so the > client continues on with the search or other operation. Unable to confirm this. Note that this is tested explicitly in test022 of the test suite, and no such behavior occurs there. You're running a pretty old release, perhaps you should update. Regardless, unless you can provide more details to reproduce this situation, this ITS will be closed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

RE: (ITS#7228) Authentication Problem When Using PPolicy and Chaining
by Jong.Limb＠dss.virginia.gov 05 Apr '12

05 Apr '12

I believe the test is incorrect. Near the bottom of the script, there is this section of code: $LDAPSEARCH -H $URI2 -D "$USER" -w wrongpw >$SEARCHOUT 2>&1 $LDAPSEARCH -H $URI1 -D "$MANAGERDN" -w $PASSWD -b "$USER" \* \+ >> $SEARCHOUT 2>&1 COUNT=`grep "pwdFailureTime" $SEARCHOUT | wc -l` echo "jkl 13" if test $COUNT != 1 ; then echo "Policy state forwarding failed" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit 1 fi The first LDAPSEARCH should have its return code checked, and for an incorrect password, it should be 49. If the script is modified to check for 49 and fail otherwise, it will fail. Unfortunately, I am not in a position to use a newer version of OpenLDAP, but I will build it and run the tests to see if the problem exists there as well. I will report back with my findings. Jong Limb Division of Information Systems Virginia Department of Social Services 804-726-7823 -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Thursday, April 05, 2012 10:17 AM To: Limb, Jong (VDSS) Cc: openldap-its(a)OpenLDAP.org Subject: Re: (ITS#7228) Authentication Problem When Using PPolicy and Chaining jong.limb(a)dss.virginia.gov wrote: > Full_Name: Jong K. Limb > Version: 2.4.23 > OS: RHEL 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (166.67.66.5) > > > I have the following setup: > - Provider LDAP server used only by those applications that change passwords > - Consumer LDAP servers used by all applications that want to authenticate > users > - The provider and consumers have password policy configured so that the > accounts lock after 3 failed attempts > - In order to maintain synchronization of failed login attempts across all > consumers, I also enabled chaining from the consumers to the master > > If an attempt is made to authenticate against the consumer with an invalid > password (for example, using ldapsearch), the pwdFailureTime attribute is > added/updated on the provider and eventually synced to the consumer, but the > operation succeeds when it should not have. > > If I remove the password policy overlay (leaving all other configuration the > same) and run ldapsearch with an invalid password against a consumer, the > operation will fail with invalid credentials as it should. > > I have done a little debugging, and it looks like the response that gets > returned to the client is the response to the modify operation that the consumer > makes to the provider to add/update the pwdFailureTime attribute, and not the > response to the bind operation. The modify operation is successful here, so the > client continues on with the search or other operation. Unable to confirm this. Note that this is tested explicitly in test022 of the test suite, and no such behavior occurs there. You're running a pretty old release, perhaps you should update. Regardless, unless you can provide more details to reproduce this situation, this ITS will be closed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by michael＠stroeder.com 05 Apr '12

05 Apr '12

This is a cryptographically signed message in MIME format. --------------ms000601060706020001090605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hyc(a)symas.com wrote: > Michael Str=F6der wrote: >> hyc(a)symas.com wrote: >>> michael(a)stroeder.com wrote: >>>> 2. add an equality matching rule. >>> >>> My approach with config attrs has been to skip the equality rule for >>> single-valued attrs. Since they are single-valued, there's obviously = no need >>> to allow for comparing multiple values. >> >> They are not searchable either then. Does it add too much overhead to = add an >> equality matching rule? >> >> Personally I currently can't imagine a use-case for searching an entry= using >> attribute olcAuditlogFile but one never knows... >=20 > True, depends on the syntax and whether it requires a normalizer, and I= =20 > couldn't think of a use-case for searching either. Overall if there's n= o=20 > obvious use for it, I choose to omit it. Hmm, I come to the opposite conclusion. Why? When generating the diff between old and new entry my web2ldap looks whet= her an EQUALITY matching rule is defined for a certain attribute type and it'= s also published in attributes matchingRules in the subschema subentry. In = that case old attribute values are explicitly deleted (not just the whole attr= ibute). This is done to provoke collisions on the server's side during processing= the modify request to be more on the safe side in case different users alter = the same entries. This has also been discussed some time ago on the OpenLDAP = lists. (Additionally the assertion control with appopriate filter is sent along with the modify request for that purpose. But not if the server is OpenLDAP because of ITS#6916 which renders assertion control completely u= nusable.) =3D> If there's no objection against an equality rule (e.g. because of overhead) *every* attribute type which uses a LDAP syntax for which an equality rule exists should have one. Ciao, Michael. --------------ms000601060706020001090605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQwNTE0MjAyOVowIwYJKoZIhvcNAQkEMRYE FFzAsG3+dnjGgCIuHe9WJ6JWCSCgMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEA2W9KZ+2wjxLM0svAhmhXXcOJGksGQI+N0u4ta2/ddnRZwYmlX2ff0OeC0XRom5x6dmIV SzO9Hiw2syv7FRq7dIEI+lz0XWC1OttnG5QQTxyLR52EW/0kXt+eP+HEIcNqMbeZAC8JPKmr XEnpOC1ZwhxZYx2Gq72V379rkohDiW8hWuJdnqKcxFnlpzYd/XtmOhhnOLhOUKF7mYiqnTuz dhPETknUf+0rLjGCBMXVuZ94kWbU3Ia4gxtwVbRfruhadNBO61Dx3zccWqIdmBjzdNkFmIpo i4pjcwfRzgyagZxcazpOihioFxEu8bA3PQN8PUgAlvMdbU9RHrmwICrUPwAAAAAAAA== --------------ms000601060706020001090605--

1 0

Re: (ITS#7228) Authentication Problem When Using PPolicy and Chaining
by hyc＠symas.com 05 Apr '12

05 Apr '12

jong.limb(a)dss.virginia.gov wrote: > Full_Name: Jong K. Limb > Version: 2.4.23 > OS: RHEL 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (166.67.66.5) > > > I have the following setup: > - Provider LDAP server used only by those applications that change passwords > - Consumer LDAP servers used by all applications that want to authenticate > users > - The provider and consumers have password policy configured so that the > accounts lock after 3 failed attempts > - In order to maintain synchronization of failed login attempts across all > consumers, I also enabled chaining from the consumers to the master > > If an attempt is made to authenticate against the consumer with an invalid > password (for example, using ldapsearch), the pwdFailureTime attribute is > added/updated on the provider and eventually synced to the consumer, but the > operation succeeds when it should not have. > > If I remove the password policy overlay (leaving all other configuration the > same) and run ldapsearch with an invalid password against a consumer, the > operation will fail with invalid credentials as it should. > > I have done a little debugging, and it looks like the response that gets > returned to the client is the response to the modify operation that the consumer > makes to the provider to add/update the pwdFailureTime attribute, and not the > response to the bind operation. The modify operation is successful here, so the > client continues on with the search or other operation. Unable to confirm this. Note that this is tested explicitly in test022 of the test suite, and no such behavior occurs there. You're running a pretty old release, perhaps you should update. Regardless, unless you can provide more details to reproduce this situation, this ITS will be closed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7228) Authentication Problem When Using PPolicy and Chaining
by jong.limb＠dss.virginia.gov 05 Apr '12

05 Apr '12

Full_Name: Jong K. Limb Version: 2.4.23 OS: RHEL 5.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (166.67.66.5) I have the following setup: - Provider LDAP server used only by those applications that change passwords - Consumer LDAP servers used by all applications that want to authenticate users - The provider and consumers have password policy configured so that the accounts lock after 3 failed attempts - In order to maintain synchronization of failed login attempts across all consumers, I also enabled chaining from the consumers to the master If an attempt is made to authenticate against the consumer with an invalid password (for example, using ldapsearch), the pwdFailureTime attribute is added/updated on the provider and eventually synced to the consumer, but the operation succeeds when it should not have. If I remove the password policy overlay (leaving all other configuration the same) and run ldapsearch with an invalid password against a consumer, the operation will fail with invalid credentials as it should. I have done a little debugging, and it looks like the response that gets returned to the client is the response to the modify operation that the consumer makes to the provider to add/update the pwdFailureTime attribute, and not the response to the bind operation. The modify operation is successful here, so the client continues on with the search or other operation.

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by hyc＠symas.com 05 Apr '12

05 Apr '12

Michael Ströder wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >>> 2. add an equality matching rule. >> >> My approach with config attrs has been to skip the equality rule for >> single-valued attrs. Since they are single-valued, there's obviously no need >> to allow for comparing multiple values. > > They are not searchable either then. Does it add too much overhead to add an > equality matching rule? > > Personally I currently can't imagine a use-case for searching an entry using > attribute olcAuditlogFile but one never knows... True, depends on the syntax and whether it requires a normalizer, and I couldn't think of a use-case for searching either. Overall if there's no obvious use for it, I choose to omit it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by michael＠stroeder.com 05 Apr '12

05 Apr '12

This is a cryptographically signed message in MIME format. --------------ms030905050806080408090400 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> 2. add an equality matching rule. >=20 > My approach with config attrs has been to skip the equality rule for=20 > single-valued attrs. Since they are single-valued, there's obviously no= need=20 > to allow for comparing multiple values. They are not searchable either then. Does it add too much overhead to add= an equality matching rule? Personally I currently can't imagine a use-case for searching an entry us= ing attribute olcAuditlogFile but one never knows... Ciao, Michael. --------------ms030905050806080408090400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQwNTEzMTE1MlowIwYJKoZIhvcNAQkEMRYE FKSAdbqqyHLXa1gjxrZTVmU3u7tyMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEA19nxcp9VtMesBkigrXCwA3bb5d6mDGvRHxlHY98mpA/uVI5tjiEgya9H2Eby+z34Ws7o UtaSyQ4WbDT2SmtuGt7SKd9+DqpBRQnsOu52rXo31vBoQ+RCASOfix72v8geh3Cn6Ft5ZDX4 lZ2qYc8UmEYiY04nLkW4cIvCChd5eREiPBECxHhcrAXt/Rv4JNUhqOsQ90uFZvy6d90ZMHMZ kRtBF7O36gV9Wu/K6Oa3yWrOIdDyXeWIpIeIh2UrU3ZPDjeiRvtB0iHgmbhnOLEeWMMtA9bU XmQdTqL977WN4Ga3xY952sNExcEmoHMcvgqFeFoLvp0hfrCEbGFTVmmH0wAAAAAAAA== --------------ms030905050806080408090400--

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by hyc＠symas.com 05 Apr '12

05 Apr '12

michael(a)stroeder.com wrote: > Emmanuel Lécharny wrote: >> One more question : why is this AT multi-valued ? Does it make sense ? (Just >> curious) > > I tried this static configuration: > > overlay auditlog > auditlog /tmp/auditlog1.ldif > auditlog /tmp/auditlog2.ldif > > Only file /tmp/auditlog2.ldif is created and changes get writte to this single > file. > > So yes, I support to > 1. set SINGLE-VALUE for this attribute type and Probably a good idea. > 2. add an equality matching rule. My approach with config attrs has been to skip the equality rule for single-valued attrs. Since they are single-valued, there's obviously no need to allow for comparing multiple values. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7227) Problem to add new entry
by rai.abhishek＠yahoo.com 05 Apr '12

05 Apr '12

Full_Name: Abhishek Rai Version: 3 OS: Windows Server 2008 R2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.46.55.29) Hi All I am using OPENLDAP on windows server 2008 R2 but i face some issue regarding add new entry like (Country and Organization etc). the error message are An error occurred while creating entry. The server is not willing to handle directory requests. but with the same setting i am able to create some entry like (Person,GrouoofNames,Organizational Unit) i am new for LDAP but as per my understanding it's a access problem in slapd.conf file. for safe point i am modifyed the config file and provide below access slapd.conf access to * by * write Please suggest what need to do to perform add new entry operation for all objects. thanks in advance. Abhishek Rai

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by michael＠stroeder.com 05 Apr '12

05 Apr '12

Emmanuel Lécharny wrote: > One more question : why is this AT multi-valued ? Does it make sense ? (Just > curious) I tried this static configuration: overlay auditlog auditlog /tmp/auditlog1.ldif auditlog /tmp/auditlog2.ldif Only file /tmp/auditlog2.ldif is created and changes get writte to this single file. So yes, I support to 1. set SINGLE-VALUE for this attribute type and 2. add an equality matching rule. Ciao, Michael.

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by michael＠stroeder.com 05 Apr '12

05 Apr '12

This is a cryptographically signed message in MIME format. --------------ms010606090903000904060909 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable (Re-added Cc: openldap-its(a)openldap.org) Emmanuel L=C3=A9charny wrote: > Le 4/5/12 1:55 PM, Michael Str=C3=B6der a =C3=A9crit : >> elecharny(a)apache.org wrote: >>> When trying to inject more than one value into the olcAuditlogFile AT= , we get >>> the following error : >>> >>> LDAP: error code 18 - modify/add: olcAuditlogFile: no equality matchi= ng rule >> How did the modification list look like in your modify request? >> >> This LDAP error code is typically returned if you try to add or remove= >> specific value(s) to an existing multi-valued attribute which does not= have an >> equality matching rule defined for it. In this case the server is not = capable >> to check whether the value exists or not. > The olcAuditlogFile does have a Syntax (DirectoryString) thus an equali= ty MR. No it does not have an equality matching rule. And the diagnosticMessage returned by the server is pretty clear on that. Look at the subschema. > The error is really not associated with the value we are trying to inje= ct : It is because... > Second value : > #!RESULT ERROR > #!CONNECTION ldap://10.211.55.4:10389 > #!DATE 2012-04-05T11:32:50.776 > #!ERROR [LDAP: error code 18 - modify/add: olcAuditlogFile: no equality= > matching rule] > dn: olcOverlay=3D{0}auditlog,olcDatabase=3D{1}bdb,cn=3Dconfig > changetype: modify > add: olcAuditlogFile > olcAuditlogFile: /ldap/file2.log > - =2E..with such a modify request the server wants to check whether the new= value '/ldap/file2.log' is already present in the attribute value set. An equal= ity matching rule has to be defined for the attribute type to make this work.= >> =3D> Your client should never do that if it's meant to be generally u= sable. > Really, it seems to be something the server is not handling correctly. Nope. >> Safest approach is to send a MOD_DEL without value and MOD_ADD with al= l values. > That would be totally overkilling if you have thousands of values in yo= ur AT. It's the only valid approach in case there's no equality matching rule de= fined for the attribute type. > Plus that forces the client to first fetch the values from the server, = to > compute locally the differences Yes. > (what if the value we try to add is already > present ?), It depends... ;-) > which means we have a way to do the comparison locally, which > means we have some knowledge about the MR locally. Yes. In practice it turned out to be sufficient to compare the byte buffers. := -) And that's why my web2ldap looks for equality matching rule definition in= the schema and generates different attribute value diffs accordingly. Tested = with many different LDAP servers... Ciao, Michael. --------------ms010606090903000904060909 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQwNTEyMTYwNVowIwYJKoZIhvcNAQkEMRYE FM+iAFFRy97LDfUOWFNxFPhbfyYoMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAuMqNcfc7oloFkZwyG6NM8IbEbOenwM9VV9eeNGRgcz3RdhUBt47RCErfi5y8Kae0yI1L 9PMksGezPPCZbtKoTbknMRRrigzpVBRjiKF8MLWF0ny0VzUj8j2uljQWy7xTHE+5yx0e61P7 airHwIQS8u63y50kvg3PT6POJB0TyRQqvZ8UUFBK6JEqXkY7DVrS9VxS6SelbOuJUtiNKkRD AkEbrE5ug8rTafR+onCa1gNlUNHLomc+0zLKb+8VRr4etfVOyLDhdYLPhJ/u5qePh3PHpX8B i3/I2bRD72ktlZYL48mwFKEma7LrUPf9Ky0EVYLCk9FR8/w4kCvxEOfmPQAAAAAAAA== --------------ms010606090903000904060909--

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by michael＠stroeder.com 05 Apr '12

05 Apr '12

This is a cryptographically signed message in MIME format. --------------ms000508090704090002020303 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable elecharny(a)apache.org wrote: > When trying to inject more than one value into the olcAuditlogFile AT, = we get > the following error : >=20 > LDAP: error code 18 - modify/add: olcAuditlogFile: no equality matching= rule How did the modification list look like in your modify request? This LDAP error code is typically returned if you try to add or remove specific value(s) to an existing multi-valued attribute which does not ha= ve an equality matching rule defined for it. In this case the server is not cap= able to check whether the value exists or not. =3D> Your client should never do that if it's meant to be generally usabl= e. Safest approach is to send a MOD_DEL without value and MOD_ADD with all v= alues. I do not comment on whether this particular attribute could/should be multi-valued or not though. Ciao, Michael. --------------ms000508090704090002020303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQwNTExNTU0M1owIwYJKoZIhvcNAQkEMRYE FFTBFviMbNYD5i9VnOyiqWgQXXQ/MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEARQ6sifL1/BiD13CFPOFaEYCvpCq3ap4S8Yo3NUi3RhU9kG2dME2iUKUF98327sLNX+B2 b0czRaFeWckhCg+sKi7N810mMHpatZpdzQMTryYLQf8a7GlWW7tdk5sqyE8CcXFx3AOD7kll l+VIGaSdUjo9ao+RnP0m2HTO/lzCyy0KdVqUvOT0FvoIRIvUStcALrETOH8q+5kjM2kB9+c/ JBsbAti5xwomP+DuXdogRuTx1ondqSzny9h44sctok3ojmNtXO5IC9NeMwwWmYp94nYyTXOf 6UWi9Nfop98Z+O+SjaC2pFY3z7dYS/vLIl9gya+aX7IMf52ToTGf/pm1NQAAAAAAAA== --------------ms000508090704090002020303--

1 0

(ITS#7226) olcAuditlogFile At dos not accept multiple values
by elecharny＠apache.org 05 Apr '12

05 Apr '12

Full_Name: Emmanuel Lecharny Version: 2.4.24 OS: Mac OSX URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.226.4.211) When trying to inject more than one value into the olcAuditlogFile AT, we get the following error : LDAP: error code 18 - modify/add: olcAuditlogFile: no equality matching rule We assume that this AT should be SINGLE-VALUE, and this is why we get this error, even if the description states it's not single valued : ( 1.3.6.1.4.1.4203.1.12.2.3.3.15.1 NAME 'olcAuditlogFile' DESC 'Filename for auditlogging' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) Also note that the error message is quite strange, as the DirectoryString syntax as an equality MR.

1 0

Re: (ITS#7197) olcTLSVerifyClient missing options
by quanah＠zimbra.com 04 Apr '12

04 Apr '12

--On Sunday, March 04, 2012 8:40 PM +0000 quanah(a)OpenLDAP.org wrote: see also <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658749> --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#7224) Core dump while trying to run slapd
by ashish＠sendmail.com 04 Apr '12

04 Apr '12

(gdb) p oc $1 = (ObjectClass *) 0x7b91460 (gdb) p *oc $2 = {soc_oclass = {oc_oid = 0x7b910e0 "1.3.6.1.4.1.6152.10.3.2.16", oc_names = 0x0, oc_desc = 0x0, oc_obsolete = 0, oc_sup_oids = 0x0, oc_kind = 1, oc_at_oids_must = 0x0, oc_at_oids_may = 0x0, oc_extensions = 0x0}, soc_cname = {bv_len = 26, bv_val = 0x7b910e0 "1.3.6.1.4.1.6152.10.3.2.16"}, soc_sups = 0x7b91110, soc_required = 0x7b91130, soc_allowed = 0x0, soc_check = 0, soc_oidmacro = 0x0, soc_flags = 0, soc_next = {stqe_next = 0x7b92d40}} (gdb) p names $3 = (char **) 0x0 (gdb) p *names Cannot access memory at address 0x0

1 0

Re: (ITS#7222) Slapd hangs on high load
by hrvoje.habjanic＠zg.t-com.hr 04 Apr '12

04 Apr '12

On 03.04.2012 17:41, Howard Chu wrote: > > You may be able to avoid this bug by using an alternate malloc > library, such as Google tcmalloc. > Hi. I did try - using tcmalloc. And this time, i got SIGSEGV. Odd thing is that this happened in "pthread_mutex_lock" which is in libpthread.so ...? Another bug in centos libs? I would appreciate if you could take a look. Thx. H. p.s. url -> http://free-zg.t-com.hr/HrvojeHabjanic/hang3.log

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs