NT provides access to enterprise-wide resources with a single logon. As a result, managing users is a relatively easy task, if you establish all the accounts and domains properly and understand the concepts of local and global groups.
Groups
A group is an account that contains user accounts. Accounts contained within a group are members of that group. Grouping accounts lets you give users permission to access resources, such as files, directories, and printers, or to perform specific system tasks, such as backing up and restoring files and changing the system time.
Group accounts simplify administration by organizing user accounts into a single administrative unit. They provide a convenient method of controlling access for several users who will be performing similar tasks. By placing multiple users in a group and assigning rights and/or permissions to the group, you can assign the same abilities and/or restrictions to all the users at the same time. Without groups, you would have to assign user rights and access permissions to the individual users’ accounts. Even if a user account is a member of one or more groups, you can also modify that account individually.
Ideally, you categorize users based on their functions or some other common denominator (for example, managers, engineers, developers). Then, for each function, you create a template account — an account that gives users appropriate rights to access system resources, group memberships, etc. Once template accounts are created, you can create new user accounts for users who fall into these various categories simply by copying the template account. We return to the specifics of account creation later in this chapter.
You can create local groups on NT Workstations and NT Servers. You can create global groups on an NT Server installed as a domain controller. However, on an NT Server installed as a standalone server, you can create only local groups.
When it comes to authenticating users, an NT Server that is a member of a workgroup behaves like an NT Workstation because in the workgroup, the NT Server is installed as a standalone server. As a result, you can create local groups in either a workgroup or a domain; however, you can create global groups only in an NT domain.
Local Groups
Usually, local groups are used to control resources, with a specific group controlling a specific resource. Members of the local group that controls a resource have access to the resource. Local groups can include any user accounts created in the local account database on an NT Workstation or Server. If the NT Workstation has joined an NT Server domain, a local group can also contain any global accounts from the NT Server domain.
It may be tempting to install every NT Server computer that you have as a BDC in a domain. Typically, the motivation is that BDCs and the PDC share the same user account database. If you install every NT server as a BDC, you can have identical local groups on all BDCs without doing any additional work. However, this setup is not good. First, the number of BDCs you can have in a domain is limited. For example, if you want to use WINS for easier name registration and resolution, you are limited to 25 or fewer BDCs.
Also, some users may want to have Administrator privileges on a specific server computer so they can install services and control applications. If that specific server computer is installed as a domain controller, it doesn’t have a “local” security database; it uses the domain security database. For users to be able to support a specific application, you would have to give the users domain administrator privileges. However, these privileges give the user the power to manage the entire domain, which may not be desirable.
The rule of thumb, therefore, is to install only the minimum number of domain controllers that you need for user authentication, and always remember that managing users and managing resources are two separate tasks in NT.
Global Groups
Global groups are visible through a domain; they are also visible in domains that trust that domain. In general, global groups contain accounts outside the local computer. They are assigned user rights and permissions to access resources on the local computer where the global group resides, or from any NT Workstation that has joined the domain.
Global groups provide a way to create groups of users from the domain. Global groups can contain only users. Global groups can’t contain local groups.
If your NT Workstation is a member of a domain, it is possible to grant permissions to any global groups that have been created in the domain.
User Manager for Domains
Figure 4.1 shows User Manager for Domains, the user interface for managing domains.
The top pane shows the groups set up in a particular domain. The bottom pane lists the predefined local and global groups, along with a brief description. We discuss the predefined groups in more detail in the next section. The icon for the local groups is two heads and a computer; for example, Account Operators is a local group. The icon for the global groups is two heads and a globe; Domain Users is an example of a global group. You may have to look closely to notice the difference between the icons.
Double-clicking any group, local or global, shows the properties of that group, including the members of the group. Figure 4.2 shows the Local Group Properties dialog box; Figure 4.3 shows the Global Group Properties dialog box.
As you can see from Figure 4.2, the Administrator user account and all members of the Domain Admins global group belong to the Administrators local group. This setup gives all the domain administrators administrative privileges on this system.
When creating user accounts in your domain, you may want to follow the procedure outlined below.
Create global groups that identify groups of users who need to access specific resources.
Create local groups that control specific resources on computers that manage those resources.
Include the appropriate global groups inside the local group.
Create template accounts for major categories of users, with appropriate permissions and access rights.
Copy the template accounts when you add new users.
This approach has a number of advantages:
After you create local groups on various server computers and include appropriate global groups in the local groups, you need to add new users only to the global groups. Thus, servers distributed across the network need no further configuration once local groups are set up.
Because you create new user accounts by copying template accounts, you don’t need to add users to specific global groups manually. Using template accounts minimizes the probability of making mistakes as you add more and more users.
It’s easy to add more domains to your enterprise networks or when you eventually migrate to Windows 2000 Server.
You can use the graphical tools more efficiently — the Properties and Select Users menu items under the Users menu will be easier to use.
Predefined Groups
NT computers contain several predefined account groups. Table 4.1 shows the predefined local groups. Table 4.2 shows the predefined global groups.
By default, the Guest account is disabled in NT domains. If you double-click the Guest account, you should see a dialog box similar to the one in Figure 4.4. Notice the check in the box next to Account Disabled.
You may also notice that the Account Locked Out check box is grayed out. Both the User Manager in NT Workstation and the User Manager for Domains on NT domain controllers gray out this checkbox. You can lock out accounts only at the Account Policy dialog box.
To view account policies, click the Policies menu and select Account. The Account Policy dialog box (Figure 4.5) appears.
Here, you set lockout parameters for accounts. According to the settings shown in Figure 4.5, after five bad logon attempts in a 30-minute period, user accounts are locked out. The lockout duration is 30 minutes; after that time, the counter is reset. You can also choose the Forever option under Lockout Duration, which means that the Administrator must unlock any locked accounts.
Special Note:Figure 4.5 prescribes a rather strict policy. Here, passwords expire every 30 days. The Minimum Password Age setting allows changes only in six days — that is, once you change to a specific password, you must use it for at least six days. The Password Uniqueness setting keeps the previous five passwords. Taken together, these two settings mean that you can’t reuse a password within a 30-day time period.
The exception to the strict policy is the setting for Minimum Password length. In the figure, it lets users specify a blank password — that is, no password. Although using them is not a great idea, blank passwords are sometimes convenient for some users. In general, passwords should have at least six characters.
NT 4.0 Service Pack 2 supports the use of strong passwords. Strong passwords force users to specify at least three of the following types of characters — capital letters, small letters, numbers, and special characters like punctuation symbols — in a password; strong passwords must also have at least six characters.
To set up strong passwords on your system, enable the passfilt.dll that comes with NT Service Pack 2 and later by carefully modifying the Notification Packages value in the following Registry key:
If you see a value called FPNWCLNT in Notification Packages, add PASSFILT right below FPNWCLNT. Please note that the strong password support is available only across the network. As an administrator, you will be able to specify weak passwords for users, if you choose.
Strictly speaking, passfilt.dll has to be set up only on the PDC because the BDCs copy the database from the PDC. But it’s a good practice to enable it on all domain controllers because you may end up promoting one of the BDCs to a PDC at some point. If passfilt.dll is not enabled on a BDC and if that BDC is promoted to a PDC, strong password enforcement is no longer performed.
According to TechNet Article Q166992, you should establish the following standard security policies regarding users and groups:
You should give Administrator privileges and physical access to domain controllers to only trusted individuals.
You should use Administrator accounts only for managing users, networks, and systems. Consider using other accounts to manage application services. Don’t use the Administrator account arbitrarily to run any program on your network.
To reiterate, always consider local groups as a mechanism to control resources and global groups as a way to manage users.
Although the predefined groups don’t follow a consistent naming convention, you may find it useful to be more consistent. For example, you may want to have local groups such as Color Printers, SQL Databases, and Office Applications, and global groups such as Color Printer Users, Database Users, and Office Users. Then you set permissions for all Color Printers (the local group), for example, allowing members of this group to print to all printers. By adding Color Printer Users (the global group) to Color Printers (the local group), you ensure that Color Printer Users have the right to print.
Order Your SQL Fundamentals CD Today! Learn how to use SQL Server, understand Office integration techniques and dive into the essentials of SQL Express and Visual Basic with this free SQL Fundamentals CD.
You've Deployed SharePoint...Now What? This one-day free online conference delivers the technical knowledge needed to kick MOSS up a notch. In one information-packed day, independent SharePoint experts will present practical, real-world information and provide take-away, ready-to-use solutions
What Would You Do If You Ran Microsoft? ITTV's 2008 inaugural video contest, "If I Ran Microsoft..." is your chance to tell it like it is. Be goofy or be serious, but don"t miss this chance to have fun, win prizes, and go viral in a major way.
Maximize Your SharePoint Investment This web seminar discusses how true bi-directional replication of SharePoint content from one server to another enables branch offices to maintain access to current SharePoint content.
Windows IT Pro
Register
