Eight Holes in Windows Login Controls
and how UserLock fill them in…

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)

Top

Hole #2: No logon/logoff reporting

There is no way in Windows to get a report saying «John logged on at 8:00 and he logged off at 11:00.»

The reason is again that the domain controller does not keep track of the fact that John is still logged on here at this computer.

Some of you might think that if we combine the security logs on those domain controllers and filter the events correctly, we could get a report of all of the initial logons that will also show us all of these connections to other servers.

If you have tried, you know how problematic it can be just to get a list of all the initial logons from looking at your domain controller security logs, unless you have the capability to correlate multiple events down to one row on your report.

Some others might suggest that we could just track all of the network logon and logoff events and then put together a report from that that shows all logon sessions, showing us not only when John logged on but how long he stayed logged on and then when he logged off.

Well, that does not work. When a user maps a drive to a server, opens up a file on this server and then closes it, the file server closes (within just seconds or at the most a couple of minutes) that logon session and logs a logoff event (in the security log).

The user is still sitting at his workstation and has just no idea that he just logged off from the server. When he next tries to open up a file over here on the server, the workstation notices that he has been disconnected and the workstation silently reconnects him to the server, which generates yet another logon event on the server.

And then once he closes that file and does not have any other files open on the server, the server closes that connection again, generating another logoff event in the file server.

That is why file servers usually show hundreds of logon and logoff events for the same user throughout the day.

So there is absolutely no way to piece together the user's overall logon session by looking at the domain controller logs or file server logs. And that leaves the security logs on all of your workstations. Except for some very high-security, government-related, small networks, I have never seen any company that collects all of their workstations' security logs.

That is not to say it is impossible, but you can imagine the storage and licensing costs on of trying to do that and it is therefore pretty impractical to try to use the security log to generate this important report in the first place.

Now, why is logon/logoff reporting so important?

It gives the ability to answer crucial questions when it comes to investigations following an incident. Who was really logged on? Where were they logged on? When did they log on? How long did they remain logged on? When did they log off? At any given time, which people were actually logged on at their systems?

And that is what we are not getting with Windows native Windows functionality …

This feature is nonetheless required for an Information System to comply with major regulatory constraints, including:

• Sarbanes-Oxley (section 404 and 802)
• LSF (French Financial Security Law – «control implementation» and «reporting» sections)
• Bâle II (European regulation for financial establishments – «Collect and log incidents» and «Reporting» sections)
• PCI («Surveillance» and «Tracking and archiving» sections)
• US Patriot Act («User monitoring and management» section)

Top

Hole #3: No logon session monitoring

Logon session monitoring is different than logon session reporting.

Logon session monitoring is being able to say, in real time, who is logged on at which computers and to answer two questions:

• what are all the computers that a given user is currently logged on at?
• who are the users currently logged on at this particular computer?

And for the same reasons, there is no way to do that with your native Windows functionality.

Instead, what you have to do is figure that out one server at a time. You can go to a given single server, go to Computer Management > Shared Folders > Sessions, and you can look it up that way.

Think about how difficult that is if you have to check each computer individually …

But this is even more important in some ways (for instance, with job terminations) when you need to determine immediately where is this specific user, what are all the computers where this user is potentially logged on, and you have to get him off your network.

It can also be about a resource contention issue: if a resource is currently locked by a user but that user is not at his usual workstation, a System Administrator cannot raise him on the phone or whatever to get him off.

Logon session monitoring is nevertheless required for an Information System to comply with major regulatory constraints, including:

• FISMA / NIST 800-53 / FIPS PUB 200 («Access control» domain)
• GLBA (Gramm-Leach-Bliley Act - «Access control» section)
• HIPAA (Health Insurance Portability and Accountability Act – «Medical data protection» domain)
• US Patriot Act («User monitoring and management» section)

Top

Hole #4: No remote logoff of workstation logon sessions

If a System Administrator needs to get a specific user off his computer, unless he has some kind of utility, he is going to have to walk down there to that building, to that floor, to that cubicle, and log him off that computer.

And there are many good reasons you may want to log users off their workstations:

• securing computers that are left unattended (even though hopefully they have a password-protected screensaver mandated)
• freeing up locked-down resources
• handling emergency situations

Imagine for example that an employee (let us call him Jack) is fired and knows that his dismissal is coming. Jack is logged on at 04:00 pm and at 04:05 pm a System Administrator disables and/or deletes his account. Guess what happens? Jack is still logged on to that workstation and maybe connected to some servers. All he has to do is unlock that workstation, and typically workstations do not go and check unlock requests with the domain controller. So Jack is still going to be there on that computer, even though his account has been disabled and deleted …

The ability to perform remote logoffs is nonetheless required for an Information System to comply with major regulatory constraints, including:

• FISMA / NIST 800-53 / FIPS PUB 200 («Access control» domain)
• GLBA (Gramm-Leach-Bliley Act - («Access control» section)

Top

Hole #5: logon time restrictions by group

Windows does provide logon time restriction functionality on a user-by-user basis.

A System Administrator can go into a user's account and restrict him to only being able to log on at certain times of the day and days of the week.

But there is no way to do it by group. The best thing that can be done in Windows is selecting multiple users at the same time but I am sure you see the reasons why that is still nowhere near as manageable or as practical to use as on a group-by-group basis, especially on large and very large networks.

Enforcing time restrictions is nonetheless part of Information System requirements for compliance with major regulatory constraints, including:

• Sarbanes-Oxley (section 409)
• LSF (French Financial Security Law – «surveillance» section)
• PCI («Surveillance» section)
• FISMA / NIST 800-53 / FIPS PUB 200 («Access control» domain)
• GLBA (Gramm-Leach-Bliley Act - («Access control» section)
• HIPAA (Health Insurance Portability and Accountability Act – «Medical data protection» domain)
• US Patriot Act («User monitoring and management» section)

Top

Hole #6: No workstation restrictions by group

Here again, Windows does provide logon workstation restriction functionality on a user-by-user basis.
A System Administrator can go into a user's account and restrict him to only being able to log on from specific computers, but there is no way to do it by group and this is a real deterrent to implement and enforce an efficient access security policy.

It is indeed very relevant to reduce the number of computers on which an account could be attacked or exploited if someone guesses the password or gets it using social engineering techniques and therefore reduce your Windows network attack surface.
This feature is nonetheless and logically required for an Information System to comply with major regulatory constraints, including:

• FISMA / NIST 800-53 / FIPS PUB 200 («System and information integrity» domain)
• GLBA (Gramm-Leach-Bliley Act - («Protection against menaces» section)
• HIPAA (Health Insurance Portability and Accountability Act – «Medical data protection» domain)

Top

Hole #7: No forcible logoff when allowed logon time expires

Using Active Directory functionality, a System Administrator can define that a user (let us call her Carol this time) is limited to only being able to work from 07:00 am to 05:00 pm. What really happens if Carol logs on at about 01:00 and remains logged on past 05:00? Windows will not log her off of his workstation at this time, because there is no native control in Windows to perform that.

There is a setting (Local Policies > Security Options) though that might make you think that it would work that way: «Automatically logoff users when logon time expires.»
But this setting only applies to file and print servers (SMB component).

Carol logs on at her workstation and accesses a file server. If she remains logged on and accessing this file server past 05:00 pm (provided she has no files open on that file server), when 05:00 pm rolls around, the file server will disconnect her and prevent her from reconnecting to the file server itself.
But there is absolutely nothing in Windows that will log her off of her workstation where she is interactively logged on at the console.

This feature is nonetheless required for an Information System to comply with major regulatory constraints, including:

• FISMA / NIST 800-53 / FIPS PUB 200 («System and information integrity» domain)
• HIPAA (Health Insurance Portability and Accountability Act – «Medical data protection» domain)
• US Patriot Act («User monitoring and management» section)

Top

Hole #8: No previous logon time and computer display when user logs on

Imagine the following scenario: a user is coming up to his workstation and after he correctly entered his username and password, the computer prompts a dialog box saying: «Hello John Smith, you have been authenticated. The last time that your account was successfully logged on was at 2 a.m., from computer such-and-such.» What if this user recognizes that he had not logged on at that time? That would indicate that someone else had successfully logged on as him and impersonated him.
This is one of the most effective ways to detect people impersonating other user accounts, providing your users are reasonably security aware.
That does not exist in Windows although this feature is required for an Information System to comply with major regulatory constraints, including:

• NISPOM (National Industrial Security Program Operating Manual – 8-609 b3 section)
• DCID 6/3 (Director of Central Intelligence Issued Directive 6/3 – 4.B.4.a section)

Top

So Windows does lack the mandatory session controls that would empower System Administrators to efficiently mitigate insider threats and to introduce, develop and maintain IT compliance programs in their organization.

The current economic background makes the implementation of such features even more crucial. As Mark Raskino (Vice President – Gartner) recently said "An economic downturn and recovery create massive churn. The processes and tools for managing and disabling access [to IT networks] are going to be critical."
That leaves knowledgeable ITpros with no choice but to look at appropriate third-party solutions…