Here's a question that a SearchWindowsSecurity.com reader sent in. It represents a common headache faced by security...
Can you limit how many times a user can log on to the network?
Solutions to this type of problem have been around for a while. The problem is that not many people are aware of them.
For starters, you can use Microsoft's LimitLogin tool. This tool, which can be downloaded for free, snaps right into your Active Directory implementation. It runs on the Windows Server 2003 system on your network that owns the domain naming master fsmo role and supports Windows 2000 SP4+ clients. It extends the Active Directory schema and requires IIS for a back-end Web service component and client-side installation -- all of which some folks would frown upon. That said, it adds an extension to the Active Directory Users and Computers MMC and is relatively simple to manage.
The only downside I can see is that LimitLogin is not supported by Microsoft. However, once you work your way through the included help file (LimitLogin.chm) and get it installed and configured, you should find it to be a relatively low-maintenance application.
Outside of enforcing the number of concurrent logins, you can also use LimitLogin as a login auditing tool to see how and when users are logging into the network. It's not groundbreaking, but certainly a nicety if you can't justify spending good money on a commercial network audit logging system.
Last year, I came across a commercial alternative to LimitLogin (that's also well-liked by many Windows admins) called UserLock by IS Decisions. UserLock works in a similar fashion to LimitLogin but offers more enterprise features that you'd expect to find in a commercial product, like real-time alerting and reporting.
Finally, if you're on a limited budget and have time to tinker around with Windows, you could build your own homegrown solution. For example, you could create a Windows login script component that maps a drive to the user's home directory share. If it's unable to create the mapping, then error out and log off. On each user's home directory share, you would set the maximum number of connections to 1. When the user logs in once, all's well. However, doing so twice would generate a net use error level of 1. This error could be captured in the login script to redirect to the logoff command and exit.
You could also set the workstation that each user must use to log in to the network. In Active Directory Users and Computers, under User/Account/Log On To, you could set the specific workstation(s) the user is allowed to log on to. Unlike LimitLogin and UserLock it's a rather limited workaround, but it may be all you need.
These homegrown solutions should work fine for small networks, but they could easily turn into a real pain -- if not a liability -- in larger environments. I see it all too often -- where network admins thrive on their own custom applications to keep the network up and running. The problem is that these custom apps can be a single point of failure if something happens to the administrator and they don't play well in environments where separation of duties is needed. Plus, ongoing auditing, reporting and overall change management is much more difficult if not impossible.
With one of these login limiting techniques, you'll improve user accountability, network security and -- as a nice side benefit -- you'll be compliant with X policy or Y regulation all at the same time.
Windows network security management
About the author: Kevin Beaver is an independent information security consultant, keynote speaker, and expert witness with Atlanta-based Principle Logic, LLC where he specializes in performing independent security assessments. Kevin has authored/co-authored seven books on information security including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). He's also the creator and author of the Security On Wheels blog and information security audio programs providing security learning for IT professionals on the go. Kevin can be reached at kbeaver --at- principlelogic.com.