|
Posted by J.P. on July 19, 2007, 1:36 pm
Please log in for more thread options >
>
> > On a terminal server I've enabled "Audit Logon Events (Success/
> > Failure)" in the Audit Policy for the machine. On a successful logon
> > event (Event ID: 682) for the security event log it shows the user as
> > System and in the log information it shows the username that logged
> > in, the client computer name as well as the client computer IP
> > address. I'm looking for a way to show this information for failed
> > login attempts be it a wrong password or a non existent user. I would
> > like the username used, the computer name if it can be retrieved and
> > the IP address of the computer that failed a login attempt. I'm not
> > sure why this information isn't already disclosed on failed attempts
> > or maybe it is and I'm missing something along the lines. If any one
> > can provide me with information on how to customize the information
> > logged I would greatly appreciate it.
>
> I would be surprised if the event log would keep track of the names of
> non-existent accounts that had logon attempts. I strongly suspect that the
> system gets the name logged into from the SAM database or AD, rather than
> from what the user actually entered in the logon window. Also, I find I
> often enter my password in the username field when in a hurry. I wouldn't
> want *ANY* record of non-existent account names entered for a fairly obvious
> reason: if an admin found three attempts to logon to akey-breaky followed by
> a successful logon to my account, he might make a logical deduction as to
> what my actual password is. In my mind that would be a security
> vulnerability in an o/s that would allow that.
>
> Getting the name or IP address of the computer from which the failed TS or
> RDP connection originated might seem more doable, but I am not convinced
> that it is. If the user fails to authenticate, then there is no session, and
> therefore no connection to this system. If I am wrong, I would certainly be
> interested in finding this out.
>
> /Al
All above sounds correct. I was more interested in getting the
information to make sure people aren't hammering on the server in an
attempt to get in. In the case someone did breach the server through
terminal services all of the above information could be of use. At the
same time it may be of no use, but the more information available to
the administrators the better, in my opinion. The password/username
issue is a good point. If we could at least get IP addresses in the
invalid logon attempts I would be more than satisfied. But as you
said, there is no connection in a failed logon state and the logging
is taking place outside of terminal services, so it's probably not
going to happen without a Terminal Services feature to do so. Any how,
the points you made have opened my eyes to the bigger picture here.
Thanks for taking the time to comment on the situation.
J.P.
| 
XML Sitemap