Re: detecting password expiration warnings by admin

[Tyler Gates <tgates81@gmail.com>]

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.
>>>
>>>       
>>>> If
>>>> 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 in
>>>> nlogin attempts" which is preformed each time they login to their
>>>> machine.
>>>>
>>>> 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
>>> http://staff.telkomsa.net/~bgmilne/ldap/ . 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).
>>>
>>> Regards,
>>> Buchan
>>>       
>> 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 
> notified.
>
>   
>> 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).
>
> Regards,
> Buchan
>   
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. ;)