Account lockout support in Solaris 10 when authenticatingagainstKerberos

[Tim Alsop]

This is not strictly true - the statement below should say "If using the
MIT KDC, there is no way to do this at the Kerberos level". The reason
is that our commercially supported KDC (TrustBroker Security Server)
supports this functionality you are asking about. Our secondary KDC
passes failed auth attempt count to the primary KDC so that this count
can then be incrementaly propagated to other secondaries. This means,
when using our product an account is disabled after a preconfigured
number of failed auth attempts regardless of which KDC (or KDCs) they
use to authenticate.

Thanks,
Tim

-----Original Message-----
From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On
Behalf Of Yu, Ming
Sent: 11 December 2007 02:03
To: rra at stanford.edu; kerberos at mit.edu
Subject: Re: Account lockout support in Solaris 10 when
authenticatingagainstKerberos

Russ, 

   Thanks for the help.

   That is th info I am looking for.

   Ming

----- Original Message -----
From: kerberos-bounces at mit.edu <kerberos-bounces at mit.edu>
To: kerberos at mit.edu <kerberos at mit.edu>
Sent: Mon Dec 10 20:45:49 2007
Subject: Re: Account lockout support in Solaris 10 when authenticating
againstKerberos

"Yu, Ming" <Ming.Yu at ipc.com> writes:

>   But I am still not clear how to "lock out" account after n-times of
>   failed login.
>  
>   Are you saying there is no way to do it in current version of MIT
>   kerberos?

Right, there's no way to do it at a Kerberos level.  There are various
things that you can do within the service that's authenticating, but it
may require development on your part.  (For example, if you're
authenticating the user via PAM, you could store the PAM failure count
somewhere and reject logins to that user once the failures reach a
particular threshold, something you could do without modifying anything
about how Kerberos works.)

Converting a failed authentication compromise into a denial of service
attack is generally a stupid idea, IMO.  Far better to start rejecting
packets from a host that's apparently trying to do a dictionary attack.

-- 
Russ Allbery (rra at stanford.edu)
<http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           Kerberos at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos


DISCLAIMER:
Important Notice *************************************************
This e-mail may contain information that is confidential, privileged or
otherwise protected from disclosure. If you are not an intended
recipient of this e-mail, do not duplicate or redistribute it by any
means. Please delete it and any attachments and notify the sender that
you have received it in error. Unintended recipients are prohibited from
taking action on the basis of information in this e-mail.E-mail messages
may contain computer viruses or other defects, may not be accurately
replicated on other systems, or may be intercepted, deleted or
interfered with without the knowledge of the sender or the intended
recipient. If you are not comfortable with the risks associated with
e-mail messages, you may decide not to use e-mail to communicate with
IPC. IPC reserves the right, to the extent and under circumstances
permitted by applicable law, to retain, monitor and intercept e-mail
messages to and from its systems.
________________________________________________
Kerberos mailing list           Kerberos at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos