Boswell's Q&A

Keeping Users At Bay

A feature that's been available for decades on NetWare, here's a new Windows utility can be used to limit number of concurrent user logins.

• By Bill Boswell
• 03/29/2005

Readers: Every week or so, I get an irate letter from an administrator who wants to limit the number of concurrent logons available to users. These administrators cite security concerns based on this argument: If users are logged on at multiple locations, they are much more likely to leave one of these locations open for compromise. The administrators also usually point out that NetWare has been able to do this since the 1980s. They often include an exclamation point or two. "The 1980's!!"

In the past, I've pointed these admins at a Windows 2000 Resource Kit utility called Cconnect but warned them that it's a fairly limited solution and urged them to spend time looking for third-party utilities that can give them the necessary functionality.

Well, that situation has changed. Microsoft Product Support Services released a utility called LimitLogin, which you can download by clicking here. I ran across the utility while reading John Howard's excellent Microsoft blog at http://blogs.msdn.com/jhoward/archive/2005/03/14/395135.aspx. (John's blog is always a great source of news; be sure to add his link to your RSS subscriptions.)

Get Help from Bill Got a Windows or Exchange question or need troubleshooting help? Or maybe you want a better explanation than provided in the manuals? Describe your dilemma in an e-mail to Bill at mailto:[email protected]; the best questions get answered in this column. When you send your questions, please include your full first and last name, location, certifications (if any) with your message. (If you prefer to remain anonymous, specify this in your message but submit the requested information for verification purposes.)

LimitLogin requires a bit of effort to deploy. For one thing, it performs a 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 do 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).

Whoa. Don't stop reading. It's complicated, but not impossible. Really.

If you're put off by the need to do a Schema modification, take heart.

Yes, yes...I know you can't remove objects from the Schema once they've been added, but LimitLogin only adds five objects, which isn't exactly going to cause the galaxy to shift its orbit. Absolutely no changes are made to classes or attributes. You'll need Schema Admin permissions in the root domain of the forest to do the Schema modifications.

Because LimitLogin uses this assortment of fairly advanced technologies, it will only control interactive (console-based) logins from clients running the following operating systems:

• Windows 2000 Professional Service Pack 4 and newer
• Windows 2000 Server Service Pack 4 and newer (Including Terminal Server sessions)
• Windows XP Professional Service Pack 1 and newer
• Windows Server 2003 (Including Terminal Server sessions)

You'll need an Active Directory domain with at least one Windows Server 2003 domain controller. This domain controller must own the Domain Naming Master FSMO role, because LimitLogin creates an Application naming context (also called an Application Directory Partition). If you aren't familiar with this feature, click here to read a Microsoft white paper that explains it. or http://snipurl.com/9tdf.

You'll also need a Windows Server 2003 server with version 1.1 or newer of the .NET Framework where you can run IIS with ASP.NET. The security configuration for the ASP.NET extension needs to be set to Allow (see Figure 1).

Figure 1. Set security for the ASP.NET extension to Allow from this dialog. (Click image to view larger version.)

Installing LimitLogin
LimitLogin consists of three MSI packages plus a Help file:

• LimitLoginIISSetup.msi
• LimitLoginADSetup.msi
• LimitLoginClientSetup.msi
• LimitLogin.chm

Start the installation by running the LimitLoginIISSetup package at the Web server. This adds a new virtual folder to the default Web site and installs a variety of files (see Figure 2).

Figure 2. Running LimitLoginIISSetup spawns a new folder on the default Web site, with some files.

Now run the LimitLoginADSetup package. This package does three things. First, it extends the Schema to add four new attributes and a new Structural class called LimitLoginUser (see Figure 3).

Figure 3. See the new Schema additions with ADSIEdit. (Click image to view larger version.)

Second, it adds a new naming context to the forest root namespace. The container for this naming context is called LimitLogin.

Third, it adds an extension to Active Directory Users and Computers (ADUC) to expose a new property menu item called LimitLogin Tasks. Selecting this option for a user opens a Properties interface for configuring LimitLogin settings (see Figure 4).

Figure 4. Now you can configure LimitLogin.

During this portion of LimitLogin setup, you'll have to do some hacking. After all, this is a 1.0 release of a Resource Kit-style utility.

LimitLogin comes with two scripts, one each for logon and logoff, and a wsdl file for XML formatting. You'll need to create a share to hold these files and create a Group Policy Object configured to run the scripts (see Figure 5).

Figure 5. Logon script that runs the llogin.vbs script. You're just about done with the installation and configuration.

That pretty much takes care of the initial setup and configuration. When you use the ADUC extension to limit a user's concurrent logins, the extension creates a new object in the LimitLogin naming context. Figure 6 shows the Microsoft LDAP Browser, depicting the LimitLogin naming context after it has been populated with an msLimitLoginUser object that represents a user in the Domain naming context. Note that this object is only linked to the User object in the domain via a name. No changes are made to the Schema that associates the msLimitLoginUser class or its attributes with the User class.

Figure 6. What limiting logins looks like from the LDAP Browser. (Click image to view larger version.)

The final steps involve configuring the clients. You then need to run LimitLoginClientSetup.msi on any desktop or terminal server where you want to limit users' concurrent logins. This client installs the required plumbing so that the logon and logoff scripts can generate the required SOAP requests when communicating with the Web server. In other words, the script uses an XML class that isn't present until you install the client piece.

The client comes in an MSI so you can deploy it using GPOs. It requires local admin rights, so assign the package to the Software settings on the Computer side of a GPO that is linked to the OUs that contain your desktops and terminal servers. You'll need to wait for the computers to restart to apply this setting and install the package.

With all this in place, here's what happens when a user logs in at a configured client.

Let's say you configure a user to have a login limit of 1. This value is written to the msLimitLogin object in Active Directory.

The user reports for work in the morning and logs on at a desktop. The Login.vbs logon script communicates with the Web server. The Web server does a lookup in Active Directory to determine if the user has been configured with a login limit and, if so, has the user already logged in somewhere else.

In this case, the user has no other concurrent logons, so the Web server records the identity of the machine where the user has logged on and then the login process continues as normal. The user has no indication that the llogin.vbs logon script has executed.

When the user attempts to log in at a second workstation or a terminal server session, the logon script communicates with the Web server. The Web server checks Active Directory and discovers that the user is already logged in somewhere else. It compares the number of current logins with the user's limit. In this case, the limit is 1 so the Web server informs the client that the user has met or exceeded the limit and the user is logged off. In the default configuration, there are no errors messages; the limitlogin client simply forces a logoff and puts the user back at a logon window.

There is an additional feature in LimitLogin that runs a small executable to show the user the location of the other logins. This is handy information and you should include this feature in any production deployment of LimitLogin.

Because LimitLogin uses logon and logoff scripts, it is not effective in stopping VPN connections or command-line connections. But it's a step in the right direction. If your organization has been looking for a way to restrict concurrent logins, then you should certainly download and test the LimitLogin utility. Like other Resource Kit style utilities, LimitLogin is not directly supported by Microsoft PSS.

If you try the utility, be sure to write and let me know how you like it.

Until next week!