[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 r2r@win2000mag.com. Please include your phone number. We edit submissions for style, grammar, and length. If we print your submission, you'll get $100.]
Carefully Manage Desktop Shortcuts
In Reader to Reader: "Managing Desktop Shortcuts," August 1999, Jim Holt is partially correct when he describes the behavior Windows NT displays when creating shortcuts. However, NT uses the Uniform Naming Convention (UNC) path internally to create shortcuts only when the user who is creating the shortcut has administrator privileges. NT uses three types of shortcuts: stable machine-independent, unstable machine-independent, and machine-dependent (UNC-based).
When you first install NT, the links to the accessories that the Start menu lists are stable machine-independent shortcuts. These shortcuts have no reference to the machine on which you created them, and they won't revert to a machine-dependent state.
When a user who doesn't have local administrator privileges creates a shortcut to a location on the local hard disk, the shortcut is machine-independent and unstable. By unstable, I mean that if a user with administrative privileges attempts to modify the shortcut (e.g., double-clicks the shortcut), the shortcut will revert to a machine-dependent state. However, the system on which the user with administrative privileges modifies the shortcut doesn't change the DOS attributes on the file, so you can make shortcuts read-only by using attrib +r at a command line.
To avoid shortcut problems, create a NetApps folder on your server, assign permissions that let only a user with special permissions access the folder, use that special user ID to create and manipulate shortcuts, and carefully guard the folder's security. If you want to copy shortcuts from the desktop to another machine, copy the shortcuts from the command line and run attrib +r on the .lnk files.
—Toby Everett
teverett@alascom.att.com
MCSE Progression Track
Microsoft doesn't have a clear progression track for the company's IT certifications. I suggest that the company develop a Master MCSE and an Enterprise MCSE certification program to help distinguish an engineer's capabilities. To earn a Master MCSE, an engineer would have to pass the following exams: 70-019, 70-028, 70-029, 70-056, 70-058, 70-059, 70-067, 70-068, 70-073, 70-079, 70-081, 70-085, 70-087, 70-088, and 70-098. An Enterprise MCSE-certified engineer would have to be a Master MCSE as well as hold at least one of the following certifications: Master Certified NetWare Engineer (MCNE), Cisco Certified Internetwork Expert (CCIE), or Certified Network Expert (CNX). In addition, to earn these certifications, engineers would have to provide proof of real-world experience similar to the proof required to earn a doctorate degree.
—Frank Lyon
flyon@ibm.net
An NT Security Loophole
I have two domains, DOMAIN_A and DOMAIN_B, on Windows NT PDCs PDC_A and PDC_B, respectively. I set the Administrator password as admin on both PDCs, and I haven't created any trust relationships between the two domains. When I connect the two domains in the same subnet on the network, I can use Network Neighborhood to see one domain from the other domain's PDC, and vice versa. When I log on as Administrator, I can administer DOMAIN_B from the PDC of DOMAIN_A, and vice versa. All domain-administration utilities (e.g., Server Manager, User Manager for Domains) work perfectly.
This setup highlights two important points: First, anyone who cracks your Administrator password can administer your domain from another domain. You could never trace this activity because an intruder needn't physically log on to your domain. In fact, an intruder could cause problems at the same time that the true administrator is logged on, and the blame would fall on the administrator. The only way to discover such an intruder is to constantly run Network Monitor, then figure out from the log who is remotely accessing the PDC.
Second, NT offers a good level of network security. However, the previous scenario provides evidence that NT grants unrecognized workstations that have the same account name and password on the two domains access to both PDCs and domains.
I've read documents that state that NT grants access tokens only at logon, and that you must log on again to access a newly granted resource. For example, suppose test network share on DOMAIN_A has access permissions for test_user on only this domain. Suppose you connect to DOMAIN_B as test_user and try to access the test share. Although the access tokens that NT granted to test_user at DOMAIN_B don't reflect access to any test share (this share resides on DOMAIN_A), NT will provide the user (i.e., test_user at DOMAIN_B) free access to the shared resource.
Are these security loopholes in NT? How do you secure your network in this situation?
—Priyank Pashine
priyank.pashine@tatainfotech.com
UNIX Whence Command vs. NT For Command
I love the UNIX ksh whence command. This command searches a path for a specified filename and tells me where the command first finds the file so that I know exactly which copy (of the multiple copies of that file in the path) the system is running.
When you enable command extensions, you can use the Windows NT 4.0 For command to emulate the whence command in a batch file. The For command is helpful when you're dealing with multiple installations or versions of common DLLs.
In Listing 1, set pathold=%path% preserves the current path environment variable in a new variable called pathold. Set path=.\;%path% inserts the current working directory in front of the path variable to ensure that the system searches the current working directory first. (NT and DOS always search the current directory first, whereas UNIX searches only the path.) The for %%i in (%1) do set first=%%~$PATH:i statement uses the For command and the ~$path: variable substitution to find the first occurrence of the specified filename in the path and assign the filename to a new variable called first. The rest of Listing 1 cleans up and displays the appropriate results.
Unfortunately, this batch file doesn't work predictably when you use wildcards (i.e., filename.*). If you're searching for an executable file, you need to specify whether the file has a .com, .bat, or .exe extension.
—Terry Snyder
tsnyder@datamirror.com