6.0.0-git
2021-01-19

[#6012] Password expiration for Sun/Fedora Directory Server
Summary Password expiration for Sun/Fedora Directory Server
Queue Horde Framework Packages
Queue Version HEAD
Type Enhancement
State Resolved
Priority 1. Low
Owners chuck (at) horde (dot) org
Requester marco (at) csita (dot) unige (dot) it
Created 2007-12-15 (4784 days ago)
Due
Updated 2007-12-20 (4779 days ago)
Assigned
Resolved 2007-12-20 (4779 days ago)
Milestone
Patch No

History
2007-12-20 23:10:27 Chuck Hagenbuch Comment #6
Assigned to Chuck Hagenbuch
State ⇒ Resolved
Reply to this comment
Committed to HEAD and FRAMEWORK_3 (soon to be Horde 3.2-RC2 and then 
Horde 3.2.0). Thanks!
2007-12-20 22:57:27 Chuck Hagenbuch Deleted Original Message
 
2007-12-20 18:22:29 marco (at) csita (dot) unige (dot) it Comment #5
New Attachment: ldap.php[1].patch Download
Reply to this comment
Does specifying the list of attributes to fetch cause any problems if
those attributes don't exist?
According to RFC 2251 if "there are attribute descriptions in the list 
which are not recognized, they are ignored by the server."

However, I test the code with OpenLDAP and Fedora DS without trouble.
Please avoid code for "shouldn't happen" situations. If a specific
potential fault is being protected against, the comment should
indicate that. Should it really be a login failure if there's bad
data in this field?
You are right. I think as LDAP administrator, for which a wrong data 
format is a serious trouble.

But final user don't care about it. Instead of raising an error, I log 
a message.
Also, please use pcre (preg_match) instead of ereg in all Horde code
- it's much faster. If you could take a quick read through
horde/docs/CODING_STANDARDS that would be wonderful, for this or
future contributions, but I can fix this patch (whitespace mostly) as
it's small.
Done.
2007-12-17 04:18:50 Chuck Hagenbuch Comment #4 Reply to this comment
Does specifying the list of attributes to fetch cause any problems if 
those attributes don't exist?



Please avoid code for "shouldn't happen" situations. If a specific 
potential fault is being protected against, the comment should 
indicate that. Should it really be a login failure if there's bad data 
in this field?



Also, please use pcre (preg_match) instead of ereg in all Horde code - 
it's much faster. If you could take a quick read through 
horde/docs/CODING_STANDARDS that would be wonderful, for this or 
future contributions, but I can fix this patch (whitespace mostly) as 
it's small.
2007-12-17 03:12:47 Chuck Hagenbuch Deleted Original Message
 
2007-12-16 13:10:55 marco (at) csita (dot) unige (dot) it Comment #3
New Attachment: ldap.php.patch
Reply to this comment
Sorry,

   I've some trouble in matching my system with your bugtrak service...



The right patch is this and it is for lib/Horde/Auth/ldap.php, not for 
the password changer driver.


2007-12-15 18:53:10 Chuck Hagenbuch Comment #2
State ⇒ Feedback
Reply to this comment
I'm not sure why this would be in the smbldap driver, instead of the 
regular one?
2007-12-15 12:36:33 marco (at) csita (dot) unige (dot) it Comment #1
Type ⇒ Enhancement
State ⇒ New
Priority ⇒ 1. Low
Summary ⇒ Password expiration for Sun/Fedora Directory Server
Queue ⇒ Horde Framework Packages
New Attachment: smbldap.php.patch
Reply to this comment
Fedora and Sun Directory Server uses a special operational attribute 
to record password expiration date.

I submit a patch to use this attribute to warn the user about password 
expiration.

This solution is not perfect, because:

- password policy shoul be read from LDAP server instead of Horde 
configuration

- Fedora/Sun Directory Server provide a grace period in which you can 
authenticate after expiration; in this time your messages present a 
negative number of remaining days.



Cheers,

   Marco.

Saved Queries