4:17 p.m.
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). 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? 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):
#####################################################################################################
#!/usr/bin/perl
use strict;
use Net::LDAP;
use Net::LDAP::Constant qw(LDAP_EXTENSION_START_TLS);
use Net::LDAP::Control::PasswordPolicy;
use Net::LDAP::Constant qw(LDAP_CONTROL_PASSWORDPOLICY);
use POSIX;
my $ldap_host = "ldap://hostname.mydomain.com";
my $ldap_port = "389";
my $ldap = Net::LDAP->new($ldap_host, port => $ldap_port);
my $seconds_in_a_day = 86400;
my $seconds_in_an_hour = 3600;
my $pp = Net::LDAP::Control::PasswordPolicy->new;
my $mesg = $ldap->bind("uid=someuser,ou=People,dc=mydomain,dc=com",
password => "secret",
control => [ $pp ] );
# Get password policy reponse
my($resp) = $mesg->control(LDAP_CONTROL_PASSWORDPOLICY);
if (defined($resp)) {
my $v = $resp->pp_error;
print "Password policy error $v\n" if defined $v;
$v = $resp->time_before_expiration;
my $days = ceil($v/$seconds_in_a_day);
my $hours = ($v/$seconds_in_an_hour);
print "Your password expires in less than $days day(s) ($hours
hour(s))\n" if defined $v;
}
####################################################################################################
4:06 a.m.
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.
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
7:45 a.m.
Hey Buchan,
find-ldap-expired.pl
on the link you posted gives an "Access forbidden" (I can get all
others).
Thanks,
John
-----Original Message-----
From:
openldap-technical-bounces+john.kane=prodeasystems.com(a)OpenLDAP.org
[mailto:openldap-technical-bounces+john.kane=prodeasystems.com@OpenLDAP.
org] On Behalf Of Buchan Milne
Sent: Monday, March 15, 2010 6:06 AM
To: openldap-technical(a)openldap.org
Cc: Tyler Gates
Subject: Re: detecting password expiration warnings by admin
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.
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
This message is confidential to Prodea Systems, Inc unless otherwise indicated
or apparent from its nature. This message is directed to the intended recipient
only, who may be readily determined by the sender of this message and its
contents. If the reader of this message is not the intended recipient, or an
employee or agent responsible for delivering this message to the intended
recipient:(a)any dissemination or copying of this message is strictly
prohibited; and(b)immediately notify the sender by return message and destroy
any copies of this message in any form(electronic, paper or otherwise) that you
have.The delivery of this message and its information is neither intended to be
nor constitutes a disclosure or waiver of any trade secrets, intellectual
property, attorney work product, or attorney-client communications. The
authority of the individual sending this message to legally bind Prodea Systems
is neither apparent nor implied,and must be independently verified.
10:50 a.m.
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) 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 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? If you are interested I'll email you a copy
once I'm done.
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.
Thanks again Buchan,
Tyler
12:42 p.m.
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).
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
3:43 p.m.
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. ;)
4753
days inactive
4755
days old
openldap-technical@openldap.org
5 comments
3 participants
participants (3)
-
Buchan Milne -
John Kane -
Tyler Gates