Restricting Concurrent Logons


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:


  • Installed only on the domain controller
  • Limits the number of simultaneous connections under the same username on the
    entire Windows NT network.
  • Tracks the activity on the event log of PDC
  • Manages single and multi-domain networks
  • restrains simultaneous connections on all computers with Windows 3.x, 9x and
    NT.
  • Tracks the activity on the event log of PDC
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


  • User Configuration
  • Windows Settings
  • Scripts

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.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top