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 simplifies 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 entitled Setting User Account Properties, later in this chapter. 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:
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 sidebar "Rules for Good Passwords." Accounts should be set to lockout when invalid passwords are entered. (Allow three to five attempts, to leave room for typographical errors.)
Rules for Good Passwords
A good password has the following characteristics:
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 making it hard for an outsider to guess.
It pays to educate your users about passwords and password privacy, and you might want to occasionally verify that the message is getting through by checking your office for passwords written on sticky notes next to monitors, under keyboards, or in desk drawers. 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 helps 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.
Of course, the ultimate in password security is use of smart cards (which combine a credit-card-like card with a PIN) or biometrics (such as fingerprint scanners, which are now fairly inexpensive).
Administrators should have three accounts on the system: one administrative account (renamed from Administrator), a fake Administrator account (as a decoy), and one normal user account (this is discussed in the section entitled Securing the Administrator Account, later in this chapter). You should use the normal user account unless you are performing administrative tasks. Because of the privileges associated with administrative accounts, they are prime targets 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 them. 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 later in this chapter entitled 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.
Domain controllers cannot have local users or groups but local security settings can be configured using Local Security Settings from the Administrative Tools folder.
The Properties dialog box for a domain user can have up to a dozen tabs, depending on the domain's setup; Table 9-6 describes these tabs. All of the information entered in the Properties dialog box 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:
Table 9-6. Tabs in the Properties dialog box 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 |
Figure 9-10. Selecting the properties for a domain user account.
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. You should test the following items:
If unexpected results occur, the time to discover them is before you've deployed a thousand users with the wrong settings.