NT Admin Tip #331: Restricting Concurrent Logons

Hits: Failed to execute CGI : Win32 Error Code = 3


NT gives the administrator the capability to limit a user to a specific workstation by defining a workstation restriction on the user account's properties in User Manager for Domains, but this restriction limits the user to a specific workstation instead of limiting the number of concurrent logons. A fairly common question on NT newsgroups is "How can I prevent users from logging onto multiple workstations simultaneously?" This capability comes with Novell Netware. Guess who asks how to do this in NT?

The 3rd party commercial product UserLock offers this addon capability. UserLock functionality:

UserLock works in a NT4 domain to manage concurrent logons on Win9x, NT, and W2K client workstations.

Microsoft has included the Concurrent Connection Limiter (Cconnect) utility with Windows 2000 Server Resource Kit. Cconnect lets you limit concurrent logons in both Windows 2000 and NT4 domains but as you will see, it best fits a pure W2K pure environment but it can be made to work in an NT environment.

Cconnect has an administrator and client component. Cconnect Administrator lets the administrator view current logons across the domain and forcibly log off users when considered necessary. Cconnect Client is installed on each workstation and enforces the concurrent logon restriction. When a user logs on to a workstation, Cconnect Client counts the number of currently active logons for that user in a SQL Server database, then compares that number to the maximum number you've allowed for that user. If the user has exceeded the limit, Cconnect immediately logs the user off.

Note the need for a sql db. To use Cconnect, you set up a new database and user account on an SQL Server. To centrally manage all the instances of Cconnect Client, you import new Windows 2000 Group Policies or NT system policies. These policies, in the cconnect.adm file, define registry values for the HKEY_CURRENT_ USER\Software\Microsoft\Cconnect subkey. The registry entries define the connection to the sql db and set the number of allowed simultaneous connections. The Cconnect Client is found in the \apps \cconnect\client directory of the W2K Server Resource Kit. To install Cconnect Administrator, run setup.exe from the \apps\cconnect\administrator directory.

If the only Cconnect function you require is concurrent logon restrictions and you're running W2K on the desktop in a AD environment, you can add calls to cconnect.vbs and cclogoff.vbs to the user's logon and logoff scripts. You can deploy Cconnect throughout your W2K domain without ever touching a workstation if you define your logon scripts in Group Policy under

Cconnect is a Microsoft resource kit utility and has severe limitations when compared to commercial products. But of course the price is right if you own the W2K Server Resource Kit. Cconnect deletes active logon records from the sql db only when a user logs off correctly. This means that a user can be improperly denied logon. To fix the problem, you must use Cconnect Administrator to manually delete the old logon record. Since the number of simultaneous logons is a registry entry on the workstation, it can be circumvented by hacking the registry. A real problem is Cconnects lack of security considerations in its design. Cconnect Client stores SQL Server user and password data in clear text in the registry. By default, this account has sa privileges. If you understand this, the account's privileges can be restricted. This is not a realistic expectation. From a hacker's perspective, Cconnect installed with defaults, is a hacker's pathway to gaining elevated privileges to the sql server. If you are going to use it, get a dba to restrict the account used by Cconnect to only the tables required. If you use Cconnect on NT workstations, you will have to install some W2K-like requirements: windows scripting host, web-based enterprise management and mdac. OK, OK - there is no free lunch. After all it IS a utility in the W2K Server Resource Kit, not the Windows NT Server Resource Kit. If you have the cash, consider UserLock.