openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Start a nNew thread

(ITS#7162)
by michael＠stroeder.com 12 Feb '12

12 Feb '12

Same problem with master branch 8e7af6331ec2d0edaeb203b1c52d4016bc2bbcbf

1 0

Re: (ITS#7163) ./scripts/test054-syncreplication-parallel-load: test failed - provider and consumer databases differ
by michael＠stroeder.com 12 Feb '12

12 Feb '12

Uuumpf! Please close this dup of ITS#7162 caused by browser reload.

1 0

Re: (ITS#7162) ./scripts/test054-syncreplication-parallel-load: test failed - provider and consumer databases differ
by michael＠stroeder.com 12 Feb '12

12 Feb '12

See also: http://www.stroeder.com/temp/openldap-its-7162-testrun.tar.gz

1 0

(ITS#7163) ./scripts/test054-syncreplication-parallel-load: test failed - provider and consumer databases differ
by michael＠stroeder.com 12 Feb '12

12 Feb '12

Full_Name: Version: RE24 git 80b64f93e85f8e8705cb154d2a1630672b8fb30d OS: openSUSE 11.4 x86_64 URL: Submission from: (NULL) (84.163.58.63) test054 fails occassionally with latest RE24 git 80b64f93e85f8e8705cb154d2a1630672b8fb30d: $ ./run -l 100 -b bdb test054 Cleaning up test run directory leftover from previous run. Running ./scripts/test054-syncreplication-parallel-load for bdb... Running 1 of 100 iterations running defines.sh Starting provider slapd on TCP/IP port 9011... Using ldapsearch to check that provider slapd is running... Using ldapadd to create the context prefix entry in the provider... Starting consumer slapd on TCP/IP port 9014... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the provider directory... Waiting 7 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... Using ldapsearch to check that provider slapd is running... Waiting 10 seconds to let the system catch up Using ldapmodify to modify provider directory... Using ldappasswd to change some passwords... Waiting 7 seconds for syncrepl to receive changes... Stopping consumer to test recovery... Modifying more entries on the provider... Restarting consumer... Waiting 7 seconds for syncrepl to receive changes... Try updating the consumer slapd... Trying to change some passwords on the consumer... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the provider... Using ldapsearch to read all the entries from the consumer... Filtering provider results... Filtering consumer results... Comparing retrieved entries from provider and consumer... test failed - provider and consumer databases differ Failed after 1 of 100 iterations

1 0

(ITS#7162) ./scripts/test054-syncreplication-parallel-load: test failed - provider and consumer databases differ
by michael＠stroeder.com 12 Feb '12

12 Feb '12

1 0

Re: (ITS#7157) UTF-8 support for "mail" attribute
by michael＠stroeder.com 11 Feb '12

11 Feb '12

Kurt Zeilenga wrote: > > On Feb 10, 2012, at 8:44 AM, Michael Ströder wrote: > >> Kurt(a)OpenLDAP.org wrote: >>> On Feb 7, 2012, at 1:03 PM, alfiej(a)opera.com wrote: >>> >>>> When searching for Chinese names in the "to:" field under Thunderbird, I see >>>> asserted_value_validate_normalize() not returning LDAP_SUCCESS in filter.c. This >>>> is because the "mail" attribute in core.schema is of type "IA5 String" but the >>>> Chinese name falls outside the character set. >>> >>> No, it's because Thunderbird failed to convert the email address to form >>> expected. It should have applied the "To Ascii" conversion as defined in >>> the EIA and IDNA specs. >> >> Do you mean RFC 3490 to 3492? > > I mean whatever the spec are. I don't follow the either the DNS or email > spaces closely, so I don't know off hand what the specs are... > But I do know enough that international of both rely on applications > encoding UTF-8 into ASCII for use in DNS and Email protocols, and by > extension LDAP. Please give a reference for this statement. Especially how the "To Ascii" conversion should be made. You know that I'm always eager to get things right in web2ldap. It was easy to add the methods sanitizeInput() and formValue() to the relevant plugin class which encodes and decodes to IDNA for domain attributes. Relevant here seems RFCs 5890-5895. Strictly speaking I simply assume here that the LDAP string format is IDNA encoding because the attributes (e.g. 'associatedDomain' etc.) are of LDAP syntax IA5String and so there's no other way to do it. But AFAIK there's no formal spec saying so. Dealing with attribute 'mail' seems to me somewhat more complicated. Yesterday I tried to find relevant RFCs in rfc-index.txt which define the "To Ascii" conversion you mentioned. So far I came up with this for e-mail headers (and in turn e-mail addresses) which uses UTF-8: 5335 Internationalized Email Headers. A. Yang, Ed.. September 2008. (Format: TXT=27945 bytes) (Updates RFC2045, RFC2822) (Status: EXPERIMENTAL) 5336 SMTP Extension for Internationalized Email Addresses. J. Yao, Ed., W. Mao, Ed.. September 2008. (Format: TXT=48110 bytes) (Updates RFC2821, RFC2822, RFC4952) (Status: EXPERIMENTAL) 5337 Internationalized Delivery Status and Disposition Notifications. C. Newman, A. Melnikov, Ed.. September 2008. (Format: TXT=36324 bytes) (Updates RFC3461, RFC3462, RFC3464, RFC3798) (Status: EXPERIMENTAL) Maybe I'm misreading http://tools.ietf.org/html/rfc5335#section-4.1 but I think they use UTF-8. Coming back on-topic for this ITS I agree that the LDAP syntax for 'mail' should not be changed because it would open a can of worms and the OpenLDAP ITS is definitely the wrong place to define the LDAP string format for Internationalized Email Addresses. Ciao, Michael.

1 0

(ITS#7161) ppolicy pwdFailureTime resolution should be better than 1 second
by jeffreyc＠ucsc.edu 10 Feb '12

10 Feb '12

Full_Name: Jeffrey Crawford Version: 2.4.26 OS: FreeBSD 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (169.233.231.78) Note: The following was copied from my mailing list question and it was suggested that it be made an enhancement request: Hello Everyone, I'm having trouble enforcing our password policy for login attempts within a particular time frame. After looking into the issue a little further it seems to stem from the fact that the operational attribute pwdFailureTime can only resolve time down to the second. so if there are three Bind attempts within a single second we only get a single pwdFailureTime entry for that time. Our policy is geared more to try and prevent brute force attacks since this instance of the ldap server will be available publicly. However someone can continuously try to bind and not lock the account for as many seconds as is defined in the pwdMaxFailure attribute in the policy definition. For example: if the following account locking configs are set pwdMaxFailure: 10 pwdFailureCountInterval: 3600 pwdLockout: TRUE pwdLockoutDuration: 30 If I try to lock my account by providing the incorrect credentials 11 times, it didn't lock if my 11 attempts were shorter than 10 seconds, I then tried 100 in a for loop which finished in 7 seconds, it still didn't lock. I looked at the account and counted the number of pwdFailureTime's and found 7. I then place a one second sleep between each bad bind attempt and low an behold it would lock as expected. Therefore there seems to be a limitation of pwdFailureTime to only resolve down to the second and its inability to store the same time multiple times. I'm not sure if this is expected behavior, but it makes locking policies against brute force attacks more difficult to fend against. I did a quick look to see if there was a way of delaying a incorrect credential bind so it wouldn't return for at least a second, but didn't see one. If such a config exists it might help if someone can point me to it. Thanks Jeffrey Crawford

1 0

Re: (ITS#7157) UTF-8 support for "mail" attribute
by Kurt＠OpenLDAP.org 10 Feb '12

10 Feb '12

On Feb 10, 2012, at 8:44 AM, Michael Ströder wrote: > Kurt(a)OpenLDAP.org wrote: >> On Feb 7, 2012, at 1:03 PM, alfiej(a)opera.com wrote: >> >>> When searching for Chinese names in the "to:" field under Thunderbird, I see >>> asserted_value_validate_normalize() not returning LDAP_SUCCESS in filter.c. This >>> is because the "mail" attribute in core.schema is of type "IA5 String" but the >>> Chinese name falls outside the character set. >> >> No, it's because Thunderbird failed to convert the email address to form >> expected. It should have applied the "To Ascii" conversion as defined in >> the EIA and IDNA specs. > > Do you mean RFC 3490 to 3492? I mean whatever the spec are. I don't follow the either the DNS or email spaces closely, so I don't know off hand what the specs are... But I do know enough that international of both rely on applications encoding UTF-8 into ASCII for use in DNS and Email protocols, and by extension LDAP. -- Kurt

1 0

Re: (ITS#7157) UTF-8 support for "mail" attribute
by michael＠stroeder.com 10 Feb '12

10 Feb '12

Kurt(a)OpenLDAP.org wrote: > On Feb 7, 2012, at 1:03 PM, alfiej(a)opera.com wrote: > >> When searching for Chinese names in the "to:" field under Thunderbird, I see >> asserted_value_validate_normalize() not returning LDAP_SUCCESS in filter.c. This >> is because the "mail" attribute in core.schema is of type "IA5 String" but the >> Chinese name falls outside the character set. > > No, it's because Thunderbird failed to convert the email address to form > expected. It should have applied the "To Ascii" conversion as defined in > the EIA and IDNA specs. Do you mean RFC 3490 to 3492? Could you please give an exact reference to a spec which says something about the local part of e-mail addresses? Ciao, Michael.

1 0

Re: (ITS#7157) UTF-8 support for "mail" attribute
by michael＠stroeder.com 10 Feb '12

10 Feb '12

Kurt(a)OpenLDAP.org wrote: > On Feb 7, 2012, at 1:03 PM, alfiej(a)opera.com wrote: > >> When searching for Chinese names in the "to:" field under Thunderbird, I see >> asserted_value_validate_normalize() not returning LDAP_SUCCESS in filter.c. This >> is because the "mail" attribute in core.schema is of type "IA5 String" but the >> Chinese name falls outside the character set. > > No, it's because Thunderbird failed to convert the email address to form > expected. It should have applied the "To Ascii" conversion as defined in > the EIA and IDNA specs. Glancing over RFC 5335 and RFC 5336 the situation is not so clear since there are UTF-8 headers introduced therein. Also both RFCs have status EXPERIMENTAL. Any other specs I should read? Ciao, Michael.

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