On 03/15/2010 03:42 PM, Buchan Milne wrote:
On Monday, 15 March 2010 18:50:10 Tyler Gates wrote:
> On 03/15/2010 07:06 AM, Buchan Milne wrote:
>> On Saturday, 13 March 2010 01:17:19 Tyler Gates wrote:
>>> Hi Guys,
>>> We are currently looking into implementing password expirations
>>> (pwdMaxAge) along with password expiration warnings (pwdExpireWarning)
>>> so that email notifications may be sent to those offending entries via a
>>> cronjob run as the admin (or some other ACL user).
>> You're not clear here on whether you already have a cron job for this, or
>> whether you are attempting to write one.
> I'm attempting to write one.
>>> The problem is, if I
>>> understand it correctly, these warning messages are only relayed (via
>>> password policy controls ?) when the USER itself binds to the tree. Is
>>> there some other way for a privileged user to obtain these messages or
>>> at least some other set attribute before pwdMaxAge has been reached?
>> As far as I can see, no, the only way is to interpret the state values in
>> the DN along with the applicable password policy.
>>> you are thinking of increasing the pwdAuthGraceNLimit that wont work
>>> because the user could login and try binding several other times through
>>> the course of the day before receiving a "password is about to expire
>>> nlogin attempts" which is preformed each time they login to their
>>> Below is an example of what works to get the info I need, binding as a
>>> user (again not what I want):
>> I have implemented as follows:
>> 1)A script that can operate either as command-line passwd replacement, or
>> CGI, which allows the user to check their password and be prompted to
>> change it if it has expired, as well as handling any ppolicy errors
>> during password change.
>> 2)A perl script to search the directory for DN's whose passwords are
>> about to expire, sending them a mail notifying them when the password
>> will expire, with a link to the URL where (1) runs as a CGI
>> 3)A script for the admin to unlock accounts that have been locked out,
>> reset their password, and send them a notification.
>> I would like to merge (2) and (3), but I was in quite a hurry to get this
>> working as I had a number of users who were locked out at the time.
>> The scripts (1) and (2) in their present state are available at
. I am still trying to resolve
>> one or two issues, but they should be of use to you.
>> If (3) would be useful to you, I will make that available as (or, an
>> updated (2) which has the functionality).
> Thanks Buchan. I was hoping to not have to resort to parsing LDAP values
> but it appears to be the only way.
> You're second script (find-ldap-expired.pl.old)
BTW, I corrected the permissions on the current version of it.
> IS what I'm looking for.
> I am however having to change a few snippets to get it to work for me
> and I think your pwdSubPolicyEntry parsing logic
Let me know if I missed any scenarios where users should or should not be
> may not be quite right
> -perhaps find dn's with pwdPolicySubPolicyEntry's store in a hash and
> run through each valid policy, then those without any specified as being
> assumed the $defaultpolicy?
I prefer to let the LDAP server do the heavy lifting, by creating an
appropriate filter based on the policy (and whether or not it is the default
policy). In this way, only the required entries are returned, instead of
pulling all the users and evaluating them on the client side. I haven't done
any profiling, but I am quite sure in most real deployments, this is the more
efficient method (assuming the attributes used in the search are indexed).
Yes you are right, I misunderstood how you were running through the loop
with your filters -it does cover all bases.
I think the whole 'work backwards from the current time' approach can be
a bit confusing to follow. Just curious, was there a reason you didn't
just take the pwdChangeTime, add it by the approriate pwdExpireWarning
and pwdMaxAge and compare those values with the current time?
> If you are interested I'll email you a copy
> once I'm done.
Please look at the newer version first, there were substantial changes.
> Also, I can use the cgi password change script too. Currently our users
> are blocked a login with a GTK password change tool if their password
> has expired but for those pesky macbooks I'll need a web interface tool
> to do the job.
For users logging in to Unix desktops, the display manager should handle
password changes (at least kdm does), but it's often necessary to provide a
fall-back (e.g. if people can access services from outside the network, and
need a means to change passwords from outside the network).
Correct but in our environment GDM is too outdated (we are halted with
Fedora 7) to be able handle such as task.
Your CGI script is exactly what I had in mind to write next. ;)