Every person who will have access to the network requires a user account. A user account makes it possible to
Windows 2000 creates only two predefined accounts: the Administrator account, giving the user all rights and permissions, and the Guest account, which has limited rights. All other accounts are created by an administrator and are either domain accounts (valid throughout the domain by default) or local accounts (usable only on the machine where they are created).
In Active Directory, each user account has a principal name. The name consists of two parts, the security principal name and the principal name suffix. For existing Windows NT user accounts, the security principal name is by default the same as the name used to log on to the Windows NT domain. For new Windows 2000 user accounts, an administrator assigns the security principal name. The default principal name suffix is the DNS name of the root domain in the domain tree. So a user identified as EduardoP in a Windows NT domain would have a principal name such as EduardoP@scribes.com.
Planning account options for users will simplify the process of creating accounts. The account options to consider include the following:
Other options—many other options—can be set in user accounts and are detailed in the section "Setting User Account Properties." The three options just listed are the most likely to be applied across large numbers of users.
REAL WORLD Establishing a Naming Convention
The security principal name should be assigned using a consistent naming convention, so that you and your users can remember user names and find them in lists. Some options for user names include the following:
- First name plus last initial Examples are MichaelG and SusanM. In the case of duplicate first names, you can add numbers (MichaelG1 and MichaelG2) or enough letters to provide identification (IngridMat and IngridMur).
- First name plus a number Examples are Dave112 and Dave113. This approach can be a problem especially for people with first names that appear frequently in the population. It makes it hard to remember your own user name and even harder to identify those of others.
- First initial plus last name An example would be MSmith. If you have both a Linda Smith and a Louise Smith, you could use LiSmith and LoSmith or LSmith1 and LSmith2.
- Last name plus an initial This convention is useful in a large network. When you have multiple users with the same last name, add a few letters as in SmithLi or SmithLo.
No matter which approach you choose, you must not only accommodate the existing users on your network but you must also be able to integrate future users. Then, even if the company's next hire is U Ti or Chomondely St. J. Montgomery-Glossup, your user-name convention will still be able to handle it.
All of your users should have well-chosen passwords and should be required to change them periodically. Passwords should be chosen according to the guidelines in the Real World sidebar "Rules for Good Passwords." Accounts should be set to lockout when invalid passwords are entered. (Allow three attempts, to leave room for typographical errors.)
REAL WORLD Rules for Good Passwords
A good password has the following characteristics:
- It is not a rotation of the characters in a logon name. (How many brain cells would it take to figure this one out?)
- It contains at least two alphabetic characters and one nonalphabetic character.
- It is at least six characters long.
- It isn't the user's name or initials, the initials of his or her children or significant other, or any of these items combined with other commonly available personal data such as a birthdate, telephone number, or license plate number.
Among the best passwords are alphanumeric acronyms of phrases that have a meaning to the user but are not likely to be known to others. This makes the password easy for the user to remember while at the same time making it hard for an outsider to guess.
It pays to educate your users about passwords and password privacy, but most of all, it pays to heed your own advice: make sure that the password you have selected for administration is a good password, and change it frequently. Doing so will help you avoid the consequences of having somebody break into your system and wreak havoc in your very own kingdom. If users will be dialing into the network from home or other remote sites, you might want to include more security than domain-level password authorization.
Administrators should have two accounts on the system: one administrative account and one normal user account. You should use the normal user account unless you are performing administrative tasks. Because of the privileges associated with administrative accounts, they are a prime target for intruders. Chapter 10 includes information on using the secondary logon to keep the administrative account safe.
Domain user accounts can be created in the default Users OU, or you can make another OU to hold domain user accounts. To add a domain user account, follow these steps:
Figure 9-8. Creating a new domain user account.
At this point, the new user account is added to the OU with default settings. It's unlikely that the default settings are exactly what you want, so you'll need to adjust the properties of the new account, as described in the section "Setting User Account Properties."
A local account cannot access the domain and therefore has access only to the resources on the computer where it's created and used. To create a local user account, follow these steps:
Figure 9-9. Creating a local user account.
The Properties window for a domain user can have a dozen or more tabs, depending on the domain's setup; Table 9-6 describes these tabs. All of the information entered in the Properties window can be used as the basis for a search in Active Directory. For example, you can find a user's telephone number or department by searching for the user's last name. To set the properties for a domain user account, follow these steps:
Figure 9-10. Selecting the properties for a domain user account.
Table 9-6. Tabs in the Properties window for a domain user account
Tab | Description |
---|---|
General | Documents the user's name, description, office location, telephone number, e-mail address, and Web page address |
Address | Documents the user's physical address |
Account | Documents the logon name, logon restrictions, password options, and whether the account expires |
Profile | Shows the user's profile path, the path of any script that runs at logon, the path to a home folder, and any automatic drive connections |
Telephones | Lists additional telephone numbers such as for a pager, cellular phone, or Internet phone |
Organization | Documents the user's title, department, company, manager, and direct reports |
Member Of | Lists the user's group memberships |
Dial-In | Documents the user's dial-in access |
Terminal Services, Environment, Sessions, Remote Control | Documents the user's Terminal Services profile |
As you develop different types of user accounts, it's advisable to test them. Create a dummy account with the memberships and restrictions you're planning on using. Then log on to a client machine and see whether the account produces the results you expect.
If unexpected results occur, the time to discover them is before you've deployed a thousand users with the wrong settings.