389-devel January 2009

389-devel@lists.fedoraproject.org

6 participants
26 discussions

[Fedora-directory-devel] Please review: Bug 480251 - rhds80 console - ssl - csr wizard really wants a country/region string
by Rich Megginson 16 Jan '09

16 Jan '09

https://bugzilla.redhat.com/show_bug.cgi?id=480251 Resolves: bug 480251 Bug Description: rhds80 console - ssl - csr wizard really wants a country/region string Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Have to make sure the string is long enough before taking the substring Platforms tested: RHEL5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=329234&action=diff

1 0

[Fedora-directory-devel] Please Review: (204626) Password syntax checking is performed also on hashed values
by Nathan Kinder 16 Jan '09

16 Jan '09

https://bugzilla.redhat.com/show_bug.cgi?id=204626 Resolves: bug 204626 Bug Description: The password syntax checking is still performed against pre-hashed passwords. In addition, we are allowing anyone to store pre-hashed passwords, which we should not do when syntax checking is enabled since it allows one to override the syntax rules. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: This patch simply checks if a password is pre-hashed in the password syntax checking code. It will reject a pre-hashed password if syntax checking is enabled, with the exception of replicated operations and those initiated by the root DN. The non-rejected cases will not be subject to syntax checking. Platforms tested: F9 Flag Day: no Doc impact: yes. A note about pre-hashed passwords not being allowed when using password syntax checking needs to be added. https://bugzilla.redhat.com/attachment.cgi?id=329221&action=diff

1 0

[Fedora-directory-devel] Please Review: (248924) should support to change the password after reset by using password modify extension
by Nathan Kinder 15 Jan '09

15 Jan '09

https://bugzilla.redhat.com/show_bug.cgi?id=248924 Resolves: bug 248924 Bug Description: When a password is expired, the password modify extended operation doesn't make the password non-expired. The server allows one to change their password, but the code assumes that the root DN is doing a reset of the password since we use an internal modify operation for the actual password update internally. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The fix is to copy a reference to the connection object from the original pblock into the pblock used for the internal modify operation. This allows the password policy code to determine who initiated the password change for an internal operation. Platforms tested: F9 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=329152&action=diff

1 0

[Fedora-directory-devel] Please Review: (184141) pwpolicy response control not sent with passwd modify extop response
by Nathan Kinder 15 Jan '09

15 Jan '09

https://bugzilla.redhat.com/show_bug.cgi?id=184141 esolves: bug 184141 Bug Description: If the password policy request control is present when performing a password modify extended operation, the associated response control is not sent back when there is a policy error or warning. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: There are numerous issues causing the password policy response control to not be returned when using the password modify extended operation. As Rich pointed out, we were not passing the controls through to the internal modify operation. I found that we were not setting the request controls in the pblock for any extended operations, which made it impossible to copy those and pass them into the internal modify. In the internal modify code, we were not setting SLAPI_PWPOLICY if the password policy control was present. This needs to be set for the password policy code to determine if the response control needs to be sent. There are also a few password policy checks that are not processed for internal operations. We need to perform these checks in the password modify extended operation code since they need to know which user is performing the operation, which is unknown when dealing with an internal operation. Platforms tested: F9 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=329114&action=diff

1 0

[Fedora-directory-devel] fedora ldap
by Wesam Al-Yazjeen 15 Jan '09

15 Jan '09

Hi all, i need help. can i bind with fedora ldap by UTF-8 user name and pass. i mean can i use Arabic characters in user name or any other characters (not just English character). can i bind to ldap using UTF-8 char-set not ASCII? -- Wesam Al-Yazjeen...

2 1

[Fedora-directory-devel] Please review: Bug 222055 - DirSync interval should be configurable
by Rich Megginson 14 Jan '09

14 Jan '09

https://bugzilla.redhat.com/show_bug.cgi?id=222055 Resolves: bug 222055 Bug Description: DirSync interval should be configurable Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Added a new config attribute - winSyncInterval - this is how often to run the dirsync search, in seconds. The default is 600 (5 minutes) which was the old hard coded value. Due to the way it's coded, the change only takes effect when the agreement is created or restarted, so the value cannot really be dynamically changed. Platforms tested: RHEL5 Flag Day: no Doc impact: yes - document the new attribute https://bugzilla.redhat.com/attachment.cgi?id=328937&action=diff

1 0

[Fedora-directory-devel] Please review: Bug 479313 - Server to Server SASL - DIGEST/MD5 - Can not Stop server
by Rich Megginson 13 Jan '09

13 Jan '09

https://bugzilla.redhat.com/show_bug.cgi?id=479313 Resolves: bug 479313 Bug Description: Server to Server SASL - DIGEST/MD5 - Can not Stop server Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Using ldap_set_option with LDAP_OPT_X_SASL_SECPROPS is not thread safe. ldap_set_option acquires the OPTION lock, but using LDAP_OPT_X_SASL_SECPROPS just calls return rather than calling break to exit the switch and unlock the lock. A mozilla bug has been filed https://bugzilla.mozilla.org/show_bug.cgi?id=473438. The fix is to use LDAP_OPT_X_SASL_SSF_MAX. Platforms tested: RHEL5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=328916&action=diff

1 0

[Fedora-directory-devel] Please review: Bug 479202 - Acceptance test: mmrepl {accept, chainonupdate} : slapd dumps core during accept_cleanup()
by Rich Megginson 13 Jan '09

13 Jan '09

https://bugzilla.redhat.com/show_bug.cgi?id=479202 Resolves: bug 479202 Bug Description: Acceptance test: mmrepl {accept,chainonupdate} : slapd dumps core during accept_cleanup() Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Have to call ldapssl_set_option(ld, SSL_NO_CACHE, PR_TRUE) after setting up the connection for client auth Platforms tested: RHEL5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=328902&action=diff

1 0

[Fedora-directory-devel] Please review: Bug 204966 - WinSync ignores entry if NT attributes are added later.
by Rich Megginson 13 Jan '09

13 Jan '09

https://bugzilla.redhat.com/show_bug.cgi?id=204966 Resolves: bug 204966 Bug Description: WinSync ignores entry if NT attributes are added later. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: If we are replaying a modify operation, we need to check if the ntUser objectclass is being added along with the other attributes that tell the sync service to sync this entry. If the objectclass is being added or replaced, we check the existing entry to see if it is still a sync-able entry. If it is, we call process_replay_add to add the entry. I changed this function to accept a Slapi_Entry to add rather than the operation structure. Finally, I had to change the way we send the Account Control flags to take into account an entry that may have been added as a result of a modify operation. I fixed a memory leak when setting the Slapi_Attr attribute type, and cleaned up a compiler warning. NOTE: There will be no clear text password to send (unless the userPassword was modified in the same modify operation). This means the account will be added to Windows, and will be enabled, but will be essentially unusable - the user cannot login - until either the user modifies the password on the directory server side, or the administrator resets the password. Platforms tested: RHEL5 Flag Day: no Doc impact: yes - we will have to document the new winsync behavior https://bugzilla.redhat.com/attachment.cgi?id=328818&action=diff

1 0

[Fedora-directory-devel] Please Review: (170461) Remove dependency on Term::ReadKey for password prompts in Perl scripts
by Nathan Kinder 10 Jan '09

10 Jan '09

https://bugzilla.redhat.com/show_bug.cgi?id=170461 esolves: bug 170461 Bug Description: A handful of our Perl scripts currently require the Term::ReadKey module for password prompting. This is not a standard module on all platforms, so one has to ensure that it is installed and modify the Perl scripts by hand to use the password prompt code. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The fix uses the same method that we use in the setup code to deal with non-echoed responses for password prompts. Platforms tested: F9 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=328607&action=diff

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-devel January 2009