On Fri, 2003-03-28 at 23:55, Jianliang Lu wrote:
Now the users of admin users will not be locked.
admin users not the appropriate choice here. Better would be the
members of the 'domain admins' group. The interesting bit is finding
this out at the right point in time...
Yes, I agree
Now the users of Domain Admins will not be locked. But until we have not
the right provilege for Domain Admins, I will continue to use the admin
users for administrator's use (like add machine, user manager for domain...).
In attach is the new patch.
Jianliang Lu
TieSse s.p.a.
Via Jervis, 60.
On Fri, 2003-03-28 at 23:55, Jianliang Lu wrote:
Now the users of admin users will not be locked.
admin users not the appropriate choice here. Better would be the
members of the 'domain admins' group. The interesting bit is finding
this out at the right point in time...
In attach is the new
I have implemented the bad password attempt lockout policy. If an user
attempt with the bad password more than the count setted in the policy, then
his account will be auto-locked, like what did NT. The implementation is only
for LDAP passdb backend.
To do this, I have to introduce a new
Remember, this opens up a new vulnerability, to denial
of service attacks. See, for example
http://www.uksecurityonline.com/threat/password.php
If you're implementing this, implement the approved strategy,
also use by NT, of locking it for a settable period, and
not locking out priveledged
On Fri, 2003-03-28 at 06:58, David Collier-Brown -- Customer Engineering
wrote:
Remember, this opens up a new vulnerability, to denial
of service attacks. See, for example
http://www.uksecurityonline.com/threat/password.php
If you're implementing this, implement the approved strategy,
You can already do that through pam_tally, what does your approach add ?
Simo.
On Thu, 2003-03-27 at 15:34, Jianliang Lu wrote:
I have implemented the bad password attempt lockout policy. If an user
attempt with the bad password more than the count setted in the policy, then
his account
On Fri, 2003-03-28 at 07:40, Simo wrote:
You can already do that through pam_tally, what does your approach add ?
We can't correctly trigger pam_tally from the encrypted password check.
Also, the pam_tally is dodgy - it doesn't correctly handle 'oh, they got
it right'. (It makes assumptions
