[Fedora-directory-devel] Please Review: (184141) pwpolicy response control not sent with passwd modify extop response
by Nathan Kinder
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
15 years, 2 months
[Fedora-directory-devel] fedora ldap
by Wesam Al-Yazjeen
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...
15 years, 2 months
[Fedora-directory-devel] Please review: Bug 204966 - WinSync ignores entry if NT attributes are added later.
by Rich Megginson
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
15 years, 2 months