SQL Server Magazine

[Editor's Note: Do you have a security-related question about Windows 2000? Send it to rsmith@montereytechgroup.com, and you might see the answer in this column!]

How can I restrict the number of concurrent logons that a user can have? I want to let a user log on to only one workstation at a time. The user would have to log out of one workstation before logging on to another.

Unfortunately, Win2K and Windows NT have no built-in restriction, such as Novell NetWare has, to let you limit a user to a specific number of concurrent logons. The nearest alternative is workstation restrictions. To set workstation restrictions for a user, open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, right-click the user's account, then select Properties. In the Properties dialog box, click the Account tab, then click Log On To to display the dialog box that Figure 1 shows. As you can see in Figure 1, I've restricted the user to logging on only at the workstation named bob-ws. This restriction doesn't meet your other requirement, which is to let users move from one workstation to another. To get true concurrent logon restrictions, you need to use the Concurrent Connection Limiter (Cconnect) utility available in the Microsoft Windows 2000 Server Resource Kit.

[Editor's note: The following text is adapted from Randy Franklin Smith's Windows 2000 Magazine article "Top 10 Security Tools in the Win2K Server Resource Kit," December 2000.]

Cconnect contains two components: Cconnect Administrator lets you view current logons across your entire domain and forcibly log off users when necessary, and Cconnect Client runs on each workstation and enforces the concurrent logon restriction. You must install Cconnect Client on each workstation. When a user logs on to a workstation, Cconnect Client counts the number of currently active logons for that user in a Microsoft SQL Server database, then compares that number with the maximum number you've allowed for that user. If the user has exceeded the limit, Cconnect immediately logs the user off.

You can find detailed instructions about setting up Cconnect in cconnect.doc, which is in the resource kit CD-ROM's \apps\cconnect directory. If you're running Win2K on the desktop as well as on the domain controller (DC), you don't need to install Cconnect Client. Instead, you can modify your user's logon and logoff scripts to call cconnect.vbs and cclogoff.vbs, respectively. If you define your logon scripts in Group Policy under User Configuration, Windows Settings, Scripts, you can deploy Cconnect throughout your domain without ever touching a workstation.

You need to be aware of a few caveats regarding Cconnect. Because the SQL Server database deletes active logon records only when a user logs off in a usual manner, Cconnect sometimes improperly denies logon. For example, in cases of dirty shutdowns (e.g., during a power failure), the database doesn't delete the logon record. If the user uses the same workstation for his or her next logon, the database deletes the orphaned logon record, and the problem disappears. However, if the user tries to log on to a different workstation, Cconnect assumes that the user is exceeding the logon limit. To fix the problem, you must use Cconnect Administrator to manually delete the old logon record.

Another problem is that savvy users can defeat Cconnect. Cconnect uses SQL Server only to store current logon data. For other configuration and policy settings, the utility uses the HKEY_CURRENT_USER\Software\Microsoft\Cconnect registry subkey. Therefore, users who understand the registry can disable Cconnect simply by pointing the tool to a bogus SQL Server machine or by increasing their concurrent logon limit. To mitigate this risk, you can use Group Policy in Win2K or System Policy Editor (SPE) in NT to disable registry editors. But users who know how to use scripts to access the registry can circumvent that restriction. To limit users to Read access to the Cconnect registry subkey, you might try implementing a script that executes at logon.

Also, Cconnect Client stores SQL Server user and password data in the registry in clear text. If you follow the instructions for setting up the SQL Server user account for Cconnect, the account will have SQL Server authority similar to SQL Server's built-in administrator account (i.e., systems administrator). The account's username and password are therefore sitting dangerously in clear text on every workstation's registry. To reduce the risk of malicious users using this account to attack other databases on the same SQL Server machine, first create the Cconnect database and user account on the SQL Server machine, as cconnect.doc describes. Then, run Cconnect Client for the first time to populate the SQL Server database you just created. Now, modify the authority of the Cconnect user account so that it's restricted to the Cconnect database.

Finally, you need to be aware of special requirements when you use Cconnect in a network of NT workstations. Each workstation needs Service Pack 4 (SP4) or later with Windows Script Host (WSH), Web-Based Enterprise Management (WBEM), and Microsoft Data Access Components (MDAC) 2.0 or later. All these components are available for download at http://www.microsoft.com/ntserver/all/downloads.asp. Unfortunately, you can't use Cconnect for users with Windows 9x systems.

How can I monitor who is currently logged on to the domain?

First, let me dispel a few misconceptions about the logon process. In Win2K and NT, you don't log on to domains. You log on to computers. When you log on to your workstation with a domain account, the workstation asks the DC whether your username and password are correct. If your credentials are correct, the DC admits you to the workstation. At that point, you're logged on to the workstation. The DC forgets about you—it doesn't keep track of where you're logged on. When you connect to other servers during the session, you log on to each one of them in turn, although it isn't evident that you're logging on to the servers because you're never prompted for a username and password. Instead, your workstation remembers your credentials and reuses them for each server that you connect to.

   Prev. page   [1] 2     next page