Steven
Mon Aug 23 21:47:31 CDT 2004
Some of those are kerberos related which can result from downlevel clients on the
domain such as NT/W9X. I would be mostly concerned if you see multiple failed events
for the same user in a short period of time, particularly the built in administrator
account which is the top account that hackers try to access. I suggest also that if
you have not done such, enable account lockout on your domain with a lockout
threshold of no less than ten bad attempts keeping in mind that the built in
administrator account can not be locked out. If you don't want the overhead of having
to reset accounts, set the time threshold for five minutes or so. That would be
enough to deter brute force attacks. If you audit account management events in the
Domain Controller Security Policy, you wall see events generated when an account has
been locked out which should be investigated. -- Steve
http://www.microsoft.com/technet/security/guidance/secmod144.mspx --- auditing and
intrusion detection.
"Wayner" <anonymous@discussions.microsoft.com> wrote in message
news:b83801c48941$289ffe30$a501280a@phx.gbl...
> Hi,
> What is a "best practice" method of auditing failed logon
> attemtps? I have a small AD - 50 users, and am auditing
> failed logon attempts but there are always a bunch of
> events that do not look that important - 675, 677, 617
> with --, 627...how does one sift through all of the events
> and pick out real "attempted logons"? What else should I
> be looking for?
> Thanks - Wayner