Windows hole 1 : No concurrent login control

There is no way in Windows to limit a given user account from only logging on at one computer at a time.

In terms of interactive logins at desktops and laptops, a system administrator cannot prevent a given user from going up to one computer, logging on there, letting somebody work as him or just leaving the computer unattended, and then walking up to another computer and logging on there.

And the reason is because of the architecture of Windows: there is no entity keeping track of all the places where a user is logged on, as each workstation basically handles that individually.

Workstations have to talk to the domain controller, but the domain controller is only involved in the initial authentication. Once the domain controller tells the workstation that «Yes, this user is authentic» or, «No, he is not; his credentials were not good,» then the domain controller just forgets about that logon session. It does not keep track of the fact that the user still logged on at that computer. Each computer does that on its own. That is probably why there is no concurrent login control built into Windows in the first place.

Microsoft originally tried to address this major issue with an unsupported tool called Cconnect, provided in its Windows NT/2000 Resource Kit. However, due to the complexity to implement, the limited and poor functionality, the constraints and the additional flaws(!) the application actually generated, few and far between are those known still actually using it.

With the venue of Active Directory, Microsoft has been back to the drawing board; and whereas one would have thought that they would have properly addressed the issue, they are in fact back with another unsupported tool based on logon scripts, responding only partially to requirements and equally awkward to deploy and maintain: LimitLogin.

LimitLogin is indeed cumbersome to set up and use:

• For one thing, it performs an irreversible Active Directory Schema modification (!).
• For another, it creates a new partition in Active Directory. It also requires configuring a Web server with the .NET Framework and ASP.NET and setting it up to perform delegated Kerberos authentication.

Finally, it requires distributing client packages that support communicating with the Web server via SOAP (a lightweight protocol for exchanging structured information in a distributed environment).

As an American friend of mine once told me: «LimitLogin looks like a Rube Goldberg's machine»…

Why is controlling concurrent logins so important?

• it reduces the ability of users to share their credentials, and avoid situations like this one: a manager does not want to approve purchase requisitions and so just logs one of his subordinates on as himself and then allows him to sit there and just mindlessly approve each purchase requisition. And so of course, the whole business control that was intended in that case just goes out the window.
• some application controls depend upon controlling concurrent logins. These applications are written with the assumption that the same user will not be logged on through different sessions.
• it is necessary to enforce accountability and make sure that Bob really is Bob. In fact, sometimes investigations have been hampered because a user was able to claim, or at least try to make the claim, that someone else was logged on as them at the time that something happened, because they can show that they were logged on at their own computer.

Not controlling concurrent logins creates a whole accountability and non-repudiation issue.

That is why this feature is required for an Information System to comply with major regulatory constraints, including:

• NISPOM (National Industrial Security Program Operating Manual – 8-303, 8-602 and 8-609 sections)
• DCID 6/3 (Director of Central Intelligence Issued Directive 6/3 – «Identification and Authentication» and «Enforcement of sessions controls» sections)