>We've recently run across a problem, and I was wondering how/if other sites
>handle it. In AFS 33 there is the new locking feature you can
>set up so that after X number of unsuccessful attempts an account is
>locked for some time or until an admin unlocks it. This works great
>on normal user accounts, but what about the privileged accounts? If you
>turn it on, then you subject your cell to denial of service attacks,
>(Joe Blow klogs to all your admin accounts with a bogus passwd until
>they're all locked and then keeps going to keep them locked) or you
>have no max # of attempts and subject the accounts to random "Crack"
>type attacks.
>
>It might be nice if klog could log some info on who and from where
>a failed klog attempt comes from.
Yes - that would be nice. We keep one priv. account around without
locking - only two people have the password - and it's very difficult
and long. All the rest have the locking feature turned on. When
we have an account that becomes locked "mysteriously", we unlock
it and sniff the ethernet traffic to authentication servers on the
appropriate port (I forgot which one it is offhand) to monitor
all auth attempts. We filter for the user id that had become locked,
so if it happens again, we have a trace of where the attempts came from.
That might not help a university with a lot of public workstations a lot,
but it helps up monitor auth attemptes from outside or corporation.
Most of our users have locked their accounts once, but after that
they learned what will happen and it almost never happens now. They
really hate the password expiration though....
-matthew
