\[Editor's Note: Share your Windows 2000 and Windows NT discoveries, comments, problems, solutions, and experiences with products and reach out to other Windows 2000 Magazine readers (including Microsoft). Email your contributions (400 words or less) to [email protected] Please include your phone number. We edit submissions for style, grammar, and length. If we print your submission, you'll get $100.\]
Network Engineer Certifications
I'm getting more than a little tired of big companies retiring my network engineer certifications. If Microsoft is going to retire my Windows NT 4.0 MCSE, the company should stop collecting the OS's licensing fees. A neutral, third-party organization should develop a network engineer certification program that isn't dictated by the marketing departments of large software vendors.
Maintain Documentation of Your Network
You can use many Microsoft Windows NT Server 4.0 Resource Kit utilities to maintain documentation about the computers in your network. You can run some of these utilities from any computer on the network; others require you to run them from the PDC. I combined many of the resource kit utilities that you can run from any network computer into a batch file, which Listing 1 shows, that I run from my workstation. This script lets me collect the utilities' information in one pass. I schedule the batch file to run once a month so that I have current network information whenever I need it. To keep the Schedule service running under the context of the System account, I created a hidden share for this batch file (i.e., CC$ in Listing 1) and granted the System account full access to the hidden share. You can use the default administrative shares, but in this case, you need to be sure to run the Schedule service under an administrative-level account.
Windows 2000 Network Security
In a Windows 2000 network that contains one domain controller running Win2K Advanced Server, we installed Win2K Server on a new machine. When setup asked whether the server is part of a domain or workgroup, I selected workgroup but entered the domain name as the system's workgroup name. When setup asked for the server's administrator password, I used the same password that we use for the domain administrator.
After we finished the installation, I logged on to the server as administrator, navigated to My Network Places, and saw that the window listed the network's domain controller. I clicked the domain controller, and to my surprise, I was able to access resources that only the domain administrator should be able to access. After I changed the server's administrator password, when I attempted to access the resources on the domain controller, the system prompted me for a password.
Through this experiment, I came to the following conclusion. Suppose you're the employee of a bank that has a Win2K network. You have a Win2K Server laptop that is a member of a workgroup that has the same name as the bank's network domain. By some coincidence, your administrator password is the same as the domain's administrator password. (This coincidence isn't impossible when you consider the quality of most people's passwords.) You can access the resources on the bank's domain controllers and servers without bothering to get permission from the domain administrator. Apparently, Win2K networks are less secure than Windows NT 4.0 networks.
A Helpful Cloning Tool
In Reader to Reader: "Adding a BDC to an Existing Domain" (April 2000), Craig Rhinehart describes his experience trying to join a new BDC to his domain. He found that reinstalling Windows NT Server was his only option.
I discovered a useful, and free, utility that you can use for this purpose. You can use Systems Internals' NewSID utility to use disk-image cloning to create a fully installed and configured NT installation. Image cloning usually creates duplicate account SIDs on cloned systems. You can use NewSID to change the cloned system's SID.
After many long hours of installing OSs and destroying partitions, I now successfully triple-boot Windows 2000, Windows NT 4.0, and Windows 98 on one physical disk. To accomplish this difficult task, I used the following process to configure the disk and install the OSs.
- Create three separate FAT partitions.
- Install NT 4.0 on one of the partitions.
- From NT, run the Win2K installation and select the option to install a fresh copy. Specify a clean partition for the Win2K installation.
- Create a Win2K Emergency Repair Disk (ERD).
- Boot from a DOS 3.5" disk or from the Win98 CD-ROM, and install Win98 on the last clean partition.
- When you reboot, you'll discover that the Win98 installation corrupted the Win2K installation. To repair the Win2K installation, boot from the Win2K installation CD-ROM and select the option to repair the installation from a rescue disk.
- Select Inspect boot files from the rescue disk menu.
After this step, the boot menu will show all three OS boot options.
Answers to This Month's Reader Challenge
You can find this month's Reader Challenge on page 24. The correct answers to the questions are as follows:
- Selection B is false. The computers invent and exchange new passwords periodically, and user intervention isn't available. In Windows 2000, the default interval for changing a password is 30 days; in Windows NT 4.0, the default interval is 14 days. If the computer that logs on has been down and has missed the password-change date, the domain controller stores a cached copy of the previous password for the default interval. If the computer is offline long enough to pass the expiration for the cached copy, the computer can't join the domain. The Registry has several value items that control this feature, such as value items that let administrators change the default interval.
- Selection A is the successful remedy, though other remedies are available (e.g., the Netdom commandline utility is effective). And there's no such thing as a Change Machine Password dialog box. Running the Net Use command produces an error message because the machines haven't connected.
- Selection B states the events in the correct order. You can set computer-based Group Policies that affect the exchange of computer passwords, including whether those passwords are encrypted. Therefore, the OS applies Group Policies before sending the password. The Logon to Windows dialog box doesn't appear until the computer has successfully joined the domain. You can find several Group Policies for computer passwords in the Group Policy Editor at Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options.