
Anyone who has ever worked in a IT helpdesk environment will know that probably 50% + of calls are related in some way or another to the user getting there password wrong, and locking out there account. No mater how much you educate the users, this will always happen, especially if you enforce a complex password policy (and i hope you do!)
I have seen on the odd occasion where thre is something more at work. The user could be happily logging on in the morning, working for a bit when suddenly there account is getting locked out, and as far as you (and they) can tell everything should be fine. You can unlock the account, they carry on working for a bit but then it happens again. There are a few things it could be:
- Someone is trying to use that users account, doesn’t know there password and so keeps locking it. This could be malicious or another reason
- The user has logged onto another machine, and not logged off. Then, if the user has changed their password while the other machine is logged in, it could be requesting resources using the old (and now incorrect) password. Every time it tries to get a network resource that requires authentication it will cause a bad password attempt
- Similar to the above, but the user is logged into a terminal server session an not logged out. For none console sessions on terminal servers users have access to, its always a good idea to enforce an automatic log off after a period of inactivity
- The user could have a connection to a network resource (such as a mapped drive) , that is using old credentials. Personally i’ve never seen this on XP, but it did see it on Win95/98
So, we know what can go wrong, but how the hell do we find out what machine the account lockout is occurring on?

(2 votes, average: 4.5 out of 5)


Trackback
Permalink
(1 votes, average: 4 out of 5)