| Downloads |
|---|
| 20555.zip |
\[Editor's Note: Do you have a security-related question about Windows 2000? Send it to [email protected], 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.
Therefore, the real question is, How can I monitor who is currently logged on to my domain's servers? In Win2K, the only native way to monitor logons is to open the MMC Computer Management snap-in, then click System Tools, Shared Folders, Sessions. In the Sessions folder, you see all the users currently connected to the server over the network, including not only users connected to shared folders but users connected to any other Win2K resources (e.g., the event log, the registry). However, as you can see when you look in the Sessions folder, which Figure 2 shows, the Computer Management snap-in shows you only one server at a time. You have other options, however. You could create your own custom MMC that contains multiple instances of the Computer Management snap-in, with each instance focused on a different server. You could even adapt MMC to display only the Sessions portion of the Computer Management snap-in for each server. To learn more about creating custom MMCs, see "Creating a Custom Password-Reset MMC," http://www.WindowsITsecurity.com, InstantDoc 9189. You might also consider using Net Watch, a tool in the Microsoft Windows NT Server 4.0 Resource Kit. As Figure 3 shows, Net Watch displays a list of all the users currently connected to the local server. You can add as many other servers as you like.
By default, Win2K and NT display a password-expiration notification 14 days before expiration and—until you change your password—every time you log on thereafter. How can I change the 14-day notification to a 3-day notification?
You need to set the value of the PasswordExpiryWarning of type REG_DWORD entry under the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon registry subkey to 3 (for the number of days of warning). You must make the change on every computer in the domain, which can be laborious. Two options for automating the task exist, however.
One option is to use a Group Policy Object (GPO) linked to the domain's root to change the value. In the GPO, create a new template under \computer configuration\administrative templates. An administrative template is simply a set of registry settings defined in the .adm file format. Documentation about writing custom .adm files is scarce, but you can look at an .adm file that comes with Win2K and adapt it. To adapt an .adm file, edit (i.e., open) any GPO, click Computer Configuration, right-click Administrative Templates, select Add/Remove Templates, then click Add. Win2K lists the current .adm files in the \%systemroot%\inf folder. Make a copy of one of these files, then adapt it to your needs.
The other option is to use the Reg tool that comes with the Win2K Support Tools. Reg is a command-line program that lets you use a batch file to add registry values. Simply create a batch file that uses Reg to add the PasswordExpiryWarning entry, set the value to 3, then include the batch file in your users' standard logon script. Or, you can use the Startup Scripts section of a GPO. For more information about startup scripts, see "Updating Service Packs and Hotfixes with Boot Scripts," http://www.WindowsITsecurity.com, InstantDoc ID 15953.
To keep my systems up-to-date with the security patches, I want to deploy SP1 on my Win2K machines automatically with the Microsoft installer package that you describe in your article "Windows 2000 Installer Package for Service Pack 1," http://www.WindowsITsecurity.com, InstantDoc ID 16480. But I've encountered a problem because Symantec's Norton AntiVirus is on all the machines. My tests show that I must stop all the Norton AntiVirus services to install SP1 correctly. What's the best way to perform this task?
Instead of using Win2K Installer to deploy SP1, you could deploy SP1 with a startup or shutdown script in the \windows settings\scripts section of a GPO. Your startup script would disable Norton AntiVirus, install SP1, then reenable Norton AntiVirus. You can use the Net command to stop and start services. The script needs to include logic to prevent the batch file from reinstalling the service pack every time you start the system. Listing 1 shows a sample startup script you can use.
The script in Listing 1 first checks to see whether the SP1HasBeenInstalled folder exists. If the folder exists, the script terminates. If the folder doesn't exist, the script stops the Antivirus Auto-Protect service, then runs sp1network.exe, the SP1 installation program. The q and z switches cause the service pack to install without asking questions or rebooting. In your script, you need to replace \\fileserver\sp1 with the path to a folder on your network that contains sp1network.exe (which you can download from http://www.microsoft.com/windows2000/downloads/recommended/sp1). Upon successful installation, the script creates the SP1HasBeenInstalled folder and uses the Win2K resource kit's shutdown tool to reboot, which is necessary after service pack installation. For a more sophisticated example of startup scripts, see "Updating Service Packs and Hotfixes with Boot Scripts," http://www.WindowsITsecurity.com, InstantDoc ID 15953.
I want to use Win2K Installer to deploy SP1 to my Win2K machines automatically , but users who log on remotely with a VPN connection would potentially have to wait hours for the service pack to download. How can I defer installing the software until users log on with a fast local connection?
To defer processing of certain areas of Group Policy when users are communicating with a slow network connection, open the Active Directory Users and Computers snap-in, then edit a GPO to view the policies under \computer configuration\administrative templates\system\group policy. In the Software Installation policy processing Properties dialog box, which Figure 4 shows, double-click Software Installation policy processing to open the Group Policy window that Figure 5 shows. Enable the policy, then make sure that the Allow processing across a slow network connection check box is clear. Next, in the same Group Policy window, select Group Policy slow link detection and ensure that it's enabled. Make sure that the connection speed is set low enough (the default is 500Kbps) that Win2K will recognize when a user is using the VPN to log on and thus defer installing software until the user logs on from a fast local connection. If you install SP1 with a startup script (as I describe in the preceding question), you can use the Scripts policy processing policy to defer processing of startup scripts when communicating with a slow network connection.
