We in the rough-and-tumble small- office/home-office (SOHO) world often lack the time or expertise to worry about all-encompassing security policies and measures such as domain controllers under Windows NT. We just want to set up a new server, maybe password-protect some paths so Maude can't see the payroll data, and get back to work.
Imagine you get a new NT server to replace some ancient 386 that you've been using as a peer-to-peer "server"--a machine running Windows for Workgroups (WFW). You want few (preferably no) changes to the workstations because at last count, you had 10 of them.
So, the new NT server will be a bright and shiny new box with a tape drive. You'll just copy all the data over the network, point all the client hard drive mappings at the box instead of the Zarniwoop DT-386, and be done before Babylon 5 comes on at 9 p.m.
I'm here to say that combining NT and WFW ain't as easy as all that. If you really want to keep Maude from the payroll data, you have some security planning to do.
Workgroup Server vs. Domain Controller
When you install NT Server, you have to say how you want to set it up--as a
single server or as a domain controller. If you choose the server option, you
copy all the user files from your old DT-386 to the appropriate directories. If
you're really clever, you give your new server the same name as the old one;
ditto with the shared directory names. Copy files from your creaky old server.
To understand what's involved with either option, you need to know that NT's workgroup (and domain) security works best with group accounts. For example, users in the Administrator account have full access, the Managers group can do everything but change user permissions, and the Accounting group can see the payroll files. After you set up such groups, you create user logins, and stick them in the groups.
I recommend not letting the users log in to the server; revoke this privilege, and declare the server off limits. Set a policy for passwords: Require, for example, that they must be unique and at least five letters long. Establish a lockout time limit, such as no more than four login attempts in 30 minutes. This limit will increase the difficulty of guessing passwords. As users type in a password, a string of 14 asterisks replaces the characters.
So for the single-server approach, you install some user accounts, and set up group names with custom security settings. Oops, better put some printers on the server, too, so people can share them.
All your work with groups and users occurs with the User Manager in the Administrative Tools group on your server (or the User Manager for Domains on a domain controller). While you're there, create a user who will have security equivalent to the Administrator's, in case of emergencies. Before you walk away from the server, enter a screen-saver password so people can't fiddle with it if you're gone (use the Display applet in the Control Panel).
Most small-office managers will opt for single server; it's all they've ever needed. And 90% of the time, they're probably right. But people grow into larger systems, want to use NT's security features, and have multiple groups of people working together. Such situations call for NT's domains, which require considerably more planning than a single-server workgroup.
Annoyingly, whether you set up the computer as a server or a domain controller, you can't switch back and forth. When you change a machine from server to domain or back, you must reinstall Windows NT Server from scratch. So, if you plan to have domains in the near future, set up the new computer as a domain controller. Otherwise, resign yourself to reinstalling when you add a second server. (For information about domain controllers, see Ed Tittel and Mary Madden, "PDCs, BDCs, and Availability," page 75 and "Tricks and Traps," page 107.)
Workgroups Install Headaches
WFW and a single-server NT system is neither a pure peer-to-peer system nor
a domain. But it is a very popular way of setting up a small workgroup that
requires few changes in the workstations, and beginners to NT already know how
to administer it. A harried SOHO administrator whose office just became large
enough to require security will find this setup painful but workable.
You want to password-protect the payroll files from Maude, who's a real gossip, but still let accounting share them. So you set up groups and users and assign passwords. Then you create share paths in File Manager and copy files from your old server to those paths. When you name the share paths, make the names short and don't use spaces or WFW will return mysterious and uninformative numeric errors when you try to use the names.
From the File Manager's Security menu (it took me awhile to find it, too), you assign security for share paths. You can allow full or partial access, by individual or group: You can give the department secretary read-only access and the accountants change (read/write/delete) access. You can password-protect printers, but I've never had to.
Then, you're off to a workstation for testing. The chain from server to WFW includes three names: the directory (e.g., d:\payroll) that you're using on the server; the share name, which the server publishes and the workstation uses (\\newbrain\pay); and the drive letter through which the workstation accesses files (p). Similarity in the names can be confusing, especially if the directory and the share path are like-named.
Password Secrets
Once you set up the network, users don't need to change any settings--NT
reshares the drives at startup. The problems come when users try to change their
password (Maude is being nosy about salaries again). Two copies of the password
list exist: one at the workstation and one at the NT server. Changing the
password in WFW won't change it at the server; the passwords don't match, so the
user can't log in at all. Worse, attempting to log in with the new (and to the
server, wrong) password will probably lock the user out because one person might
use four different share paths--and that's four different logins, so they use up
all the attempts.
The surest way to resolve this problem is to make sure the user isn't locked out of the server. Delete the workstation password list, log out, and log back in to NT. The password lists have a .pwl extension (e.g., c:\windows\maude.pwl).
If you're using only WFW, a loophole lets you change both the workstation and server password at once (this trick doesn't work on Windows 95, unfortunately). In the Network Control Panel, Startup options, the Log on to Windows NT or LAN Manager Domain button is for people with domains. If this button is enabled and the user is already logged in, changing the WFW password will also change the user's server password. As a side effect, the workstation will time out trying to log in to that domain and will display an error message you can ignore.
Clearing Security Problems
If WFW or Win95 is on your clients, users sometimes can't see files in a
certain share path, are locked out from the server, or can't remember their
passwords. Here are some troubleshooting notes from the trenches.
If a user can't see files in a share path but could earlier, the security for that path is probably corrupt. Make sure no one is using files in that path, unshare it, reshare it, and reestablish the security settings for it.
Or, if Maude and other inquisitive users can see every path that's published, whether they have rights or not, remember that even if they can see a path name, they can't necessarily see the files in that path. Maude can see \\newbrain\pay and even share it, but when she double-clicks it, she'll get an error message like #3657, which means, "You don't have sufficient rights to see this directory."
If you change the security parameters for a share path while people are logged in, you can make it impossible for them to save a file later. (This situation creates one of those duh! moments I'm always having.)
The Ugly Truth
WFW isn't a full-featured network client. It has more than a few
shortcomings, such as uninformative error messages and the password system. Like
it or no, WFW is how many people will connect to NT, so you just need to be
ready for Maude's questions. Creating a 10-page how-to document with lots of
screen captures will help.
