User Notification of Failed Logins and Controlling Concurrent Sess

[Guest]

I have been searching for a soultion that has been vexxing my Security
program. I work for a large company (+10,000 employees) who utilize Windows
XP on Desktops and we are in the process of moving from Server 2000 to 2003.
I'm looking for a way to do two things within our enviornment:

1) Notify Users upon login how many failed attempts there has been since
their last successful attempt and ;
2) Limit specific users to only one concurrent session.

I haven't really found a good solution for this. Because of the size of the
company, any user can log into any of a 100 DCs and this complicates finding
practical solutions for both of these items.

Thanks in advance for any ideas you folks might have.

 

[Steve Riley [MSFT]]

Don, while there are some utilities that can help you with #2 (including a
Resource Kit tool called CConnect), the architecture of SMB networking is
such that it's generally not practical to do this. Remember, users can still
use domain resources without logging on. They can power up a PC without a
network connection, then connect to the network, and directly access
resources. If the computer isn't domain-joined, then Windows will prompt
them for a user ID and password--which is used to authenticate directly to
the destination resource.

Please help me understand what potential security risks you are looking to
address with your two requirements. And for #1, how would this information
be useful to a user? What action could they take with this knowledge, other
than perhaps to be afraid of things they really can't control?

 

[Guest]

Please help me understand what potential security risks you are looking to
address with your two requirements. And for #1, how would this information
be useful to a user? What action could they take with this knowledge, other
than perhaps to be afraid of things they really can't control?

Both of these items have been categorized as potential security risks for
contractors doing business with the Federal Government (by the Government).
As to how the information itself would be useful:

Currently the standard Information Practice is to write failed attempts to a
log and to lock users after X unsuccessful attempts. If a user were told
that there was X unsuccessful attempts upon login, they could then notify our
IP department to investigate the records if it was not the user that
initiated the failed attempts.

The statement was simply: "the lack of successful and unsuccessful log-on
attempt notification after log-on increases the time to detect malicious
activity."

The Window's Enviornment really does not lend itself to either of these. I
will look into the first product though to see if there is anything that
could potentially be leveraged. In the past we had looked at the limitlogin
tool and that might be a weak solution, but I am hoping there are some other
potentials.

 

[Steve Riley [MSFT]]

Ah, I've heard about this before.

There's no plan to add this functionality to Windows. They tend to address
symptoms rather than root causes. Typically, no one pays any attention to
post-logon status messages like "There were 34,235 failed logon attempts
yesterday." I doubt that you'd get many calls from users. They've sat down
at the computer, logged in, and are ready to get to work (or play). Being
interrupted and then having to call a help desk -- not gonna happen.

Both requirements stem from a desire to address common weaknesses in
password-based authentication: using bad (easily cracked) passwords, and
sharing passwords. If this is the actual risk that you face, then a better
choice would be to implement some kind of authentication mechanism that
can't be shared and is largely infeasible to crack. Consider smartcards. If
you enable the policy that requires the smartcard to always be present in
the reader, then Alice can't share her card with Bob but still do work
herself.

--
Steve Riley
(e-mail address removed)
http://blogs.technet.com/steriley
http://www.protectyourwindowsnetwork.com