Group Administration Strategies

Now is an opportune time to explain a strategy for group administration that is often discussed in MCSE newsgroups. The tip to remembering the local versus group method is this acronym: AGLP.

A = Accounts.

G = the Global group, in which accounts are placed.

L = the Local group, where the global group is placed.

P = Permissions are set for the Local group.

Global groups are to organize the users, and local groups are to assign permissions and rights.

With that in mind, follow along with this guide to making decisions about group assignments:

Groups within Groups

When it comes to placing groups within groups, you can only place global groups within local groups. This is the only way you can use nested groups. Here is what is not accepted when it comes to nested groups:

In order to understand the nested group rule, let’s create a scenario involving two domains. One domain is your local domain called BRANCH1. This contains a group of users known as SALES_LOCAL. This group contains user accounts from your domain. Since you are a branch office, you have a corporate domain called CORPORATE. There is a global group on the CORPORATE domain called SALES_GLOBAL, which contains users from the CORPORATE domain. If members of the SALES_GLOBAL group are coming to your BRANCH1 domain to train your users, you can quickly place the SALES_GLOBAL group within your local SALES_LOCAL group, to give them access to the resources that have been given to the SALES_LOCAL group.

Creating and Managing Groups in User Manager

Here is a rundown of the options you have in User Manager for Domains concerning groups:

Local Groups

Local groups, as we have discussed, are for resource access within your domain. If you know beyond the shadow of a doubt that you will not be accessing resources in another domain, then go ahead and use local groups for everything. Place global groups and users from your domain directly into a local group. This can be helpful if you do find yourself needing to give access to groups from other domains. You will have to make new global groups for granting access to resources in other domains, if you find yourself with more than one domain.

You may not have to create many groups, because Windows NT comes equipped with built-in groups to help organize users with various tasks. Of course, it doesn’t come with built-in groups like Sales or Marketing, but it includes some groups to relieve the administrative burden. Before we discuss the built-in groups, let’s demonstrate the creation of a new group. Refer to Figure 5-9 for the New Local Group dialog box.

Exercise 5-9: Creating a Local Group

This exercise creates a local group on the domain. If you are using Windows NT Workstation, this is the only type of group you can create.

1. Open up User Manager for Domains.
2. Select New Local Group from the User pull-down menu.
3. Enter the name of the local group, and a description, if necessary. This is a good time to specify whether the group is local or global, for future reference.
4. Click the Add button to show a list of users and groups that can be placed in this local group.
5. Highlight the user you would like to add, and click the Add button.
6. Select OK twice to save the changes. You should now see your local group in the bottom portion of the dialog box.

Administrators

The Administrators local group is the most powerful of all of the groups. As you would expect, you have full control of the computer by virtue of being in this group. For this reason, only those trusted with this great responsibility should be members of this elite group. By default, the Domain Admins global group is a member of the local Administrators group. You can remove this global group if you desire.

Users

The Users local group has enough rights for users to get work done at their workstations, but not much else. Users don’t have the right even to log on at a Windows NT Server. The Domain Users global group is a member of the Users local group by default, but can be removed.

Guest

The Guest group is even more limited than the Users group. It should be used for one-time, or temporary access to resources. Users can log on using the built-in workstation Guest account, or by using the domain built-in Guest account. Either way, they are restricted in the tasks that they can perform. The Domain Guests global group is by default a member of the Guest local group, but you can remove it.

Server Operators

The Server Operators group is intended to relieve the burden on the Administrator. Members of this group can shut down servers, format server hard disks, create and modify shares, lock and unlock the server, backup and restore files, and change the system time. Although its purpose is to decrease the administrator’s workload, it may increase his paranoia. Members of this group should be well trained in Windows NT, because they have rights that can be very damaging to the network. The Server Operators group only exists on a Domain Controller.

Print Operators

Print Operators have the ability to create, delete, and modify printer shares. These will most likely be on print servers, which the members of the Print Operators group can log on to, and shut down if need be. The Print Operators group only exists on a Domain Controller.

Backup Operators

Members of the Backup Operators local group can backup and restore on the primary and backup domain controllers. Just like the Print Operators, they can log on to, and shut down the server, if needed.

Account Operators

Account Operators have permissions to add, modify, and delete most user and group accounts in User Manager for Domains. They do not have the ability to modify any of the default groups mentioned above, nor can they modify any member that belongs to any of these groups. They can also use Server Manager to add computers to the domain. The Account Operators group only exists on a domain controller. Members have the right to log on at domain controllers, and also have the right to shut them down. I once was an Account Operator at Intel, and I didn’t even work there! I was a contractor for another company.

Replicator

The Replicator group contains the Replicator user account for the replication services. This group should not be used for any other purpose. In other words, users other than your replicator service account should not be added here.

Global Groups

Global groups give users access to resources in other domains. Global groups were designed to move the people to the resource, since you can’t move the resource to all the people. This is accomplished by adding the global group to the local group where the resource is located.

You have now seen the purpose of global groups, and learned when they should be chosen over local groups. If you are using Windows NT Workstation rather than Windows NT Server, you don’t have the option of creating global groups.

Exercise 5-10: Creating a Global Group

1. Open up User Manager for Domains.
2. Select New Global Group under the User pull-down menu.
3. Enter the name of the group, and give the group a description if necessary. This may be a good time to specify whether the group is local or global for future reference.
4. Click the Add button to show a list of users that can be placed in this global group.
5. Highlight the user you would like to add and Click the Add button.
6. Select OK twice to save the changes. You should now see your global group in the bottom portion of the dialog box.

Domain Administrator

The Domain Admins global group is a member of the Administrators local group on every computer in the domain by default. (Actually, this is just for computers running Windows NT, because operating systems like Windows 95 do not use groups to administer the local machine.) Having the Domain Admins global group in the Administrators local group by default gives an administrator full control to modify computers in the domain. You can revoke this right by removing the Domain Admins group from the Administrators local group on the machine.

Domain Users

The Domain Users global group contains all subsequent accounts created in the domain. This gives users the ability to access resources in other domains. The Domain Users global group is by default a member of the Users local group on every Windows NT computer in the domain. This gives users the ability to access non-domain controller computers and workstations in the domain. If you do not wish them to have this ability, remove the Domain Users group from the Users local group on the specific machine.

Domain Guests

The Domain Guests global group is intended to provided limited and/or temporary access to the domain. By default, the Domain Guests global group is a member of the Guests local group.

System Policies

In this section we focus on the ways you can implement policies on your domain for activities such as account restrictions, desktop settings, and network settings. Using these policies you can fine-tune users’ access and abilities on the network. Although system policies are very effective in what they accomplish, they can add more work for the administrator of the network. Not only must the administrator learn the various utilities for system policy, he must decide what to restrict, verify that the restrictions work, and explain to users why they have been restricted.

Most system policy restrictions are considered optional, but one that should always be adjusted is the Account Policy found in User Manager for Domains. This feature, illustrated in Figure 5-10, contains settings for passwords and lockout features for security, and should not be ignored. You have to determine which settings are appropriate for your organization. The more policy restrictions you implement on your network, the angrier users get. For example, the password restrictions, such as expiration and password uniqueness, are sure to upset users over time. At my company, where the computer remembers an employee’s last six passwords, and passwords expire every month, not a day goes by that I don’t hear users complaining about the inconvenience of these restrictions. I have to explain that these settings apply to everyone, from the president of the company right down to the hourly employees. NT should let us differentiate account policy for groups, rather than the entire domain.

The Account Policy dialog box is reached through User Manager for Domains by selecting Account from the Policies pull-down menu.

Exercise 5-11: Changing Account Policies

In this exercise we adjust some important settings for the Account Policy.

1. Open up User Manager for Domains if you have not already.
2. Select Account from the Policies pull-down menu.
3. In the Minimum Password Age portion, have the password expire after a certain period of days. This is usually a month to three months, depending on the security needs of your organization. The less time before password changes, the more secure your network is.
4. In the Minimum Password Length portion, enter a value of five or larger. This makes it more difficult to guess passwords.
5. In the Password Uniqueness portion, have NT remember a few passwords. This prevents a user from using the same password over and over. The more the system remembers, the more upset your users get.
6. Enable the Account Lockout feature. This locks out an account temporarily or permanently after a certain number of incorrect password attempts.
7. Lock out the account after three or more password attempts. This gives the user enough chances to type the password correctly.
8. For the Lockout Duration, select a duration of thirty minutes to an hour. If you lock the account out forever, the administrator has to be called whenever a user locks himself out of the account.

Another area for adjusting policy is through the User Rights Policy, illustrated in Figure 5-11. This is also found in User Manager for Domains. Administrators don’t make adjustments to most of these rights, with the exception of two: Log on Locally, and Access This Computer From Network. We will adjust these settings in the next exercise.

Exercise 5-12: Modifying User Rights

1. Open up User Manager for Domains if you have not already.
2. Select User Rights under the Policies pull-down menu.
3. Find the Log on Locally right and select it. This setting is to specify which users are allowed to sit at this computer and log on. This is a very effective way to restrict users from logging on to certain computers.
4. If there are users you would like to remove, highlight them and click the Remove button. If there are users you would like to add, click the Add button.
5. Highlight the group you would like to add, or select the Show Users button to see available users.
6. Highlight the user and select Add.
7. Click OK to return to the User Rights Policy dialog box.
8. Find the Access This Computer From Network right and select it. This setting is to specify which users are allowed to connect to this computer from the network. This is also an effective way of restricting users from accessing a specific computer.
9. If there are users you would like to remove, highlight them and click the Remove button. If there are users you would like to add, click the Add button.
10. Highlight the group you would like to add, or select the Show Users button to see available users.
11. Highlight the user and select Add.
12. Click OK to return to the User Rights Policy dialog box.
13. Click OK again to exit.

Here are some examples of situations where you have to modify these system policies. If a user calls you and tells you he got a message saying, "the local policy of this system does not allow you to log on interactively", you know you have to adjust the Log on Locally setting for the computer. At my own company, Access This Computer From Network was once stopping our backup program from attaching to a user’s computer and backing up a folder on their hard disk.

Exercise 5-13: Enabling Auditing

In this exercise, we will enable auditing, which logs events that we specify in the Security portion of the Event Viewer. This feature lets you determine who succeeded or failed at accessing resources. The more events you log, the larger the log file grows, and the more work it is for you, the administrator, to sort through the events. It would be wise to spend some time auditing events as a trial to determine whether or not you would benefit from those events being logged. Try to find a good balance of useful information against administrative and log file overhead. Be careful, because the audit settings are used by all domain controllers in the domain. Also, auditing is only available on NTFS-formatted partitions, not FAT-formatted partitions.

1. Open up User Manager for Domains if you have not already.
2. Select Audit from the Policies pull-down menu.
3. Click Audit These Events, if it is not already.
4. For File and Object Access, select both Success and Failure.
5. Click OK to exit.
6. Open Windows Explorer.
7. Right-click a folder, and select Properties. This folder should be one that you would like to audit to see who is accessing it.
8. Click the Security tab, and then click the Auditing button.
9. Under Name, there should be nothing listed. Click Add.
10. From the list of names select Everyone. You do not have to select everyone if you would like to audit a specific user or group.
11. Under the Events to Audit, select those events you would like to audit and click OK to exit. Make sure you are at least auditing File and Object Access from User Manager for Domains for this exercise.
12. In the folder that you specified for auditing, open up a file within the folder.
13. Go to the Event Viewer in Administrative Tools.
14. Select Security from the Log pull-down menu.
15. You should see the event that we just audited. In my instance, I saw about thirty entries just from opening one file in the directory that I specified for auditing.

As you can see, there are many things you can audit, and a range to the depth at which you can audit them.

Exercise 5-14: Creating a Network Share

In this exercise we create a network share and specify who is allowed to access it. This will be a fairly common occurrence in your role as network administrator.

1. Open Windows Explorer.
2. Right-click a folder that you would like to share.
3. Select Sharing.
4. Click the Shared As radio button.
5. Select a name for the share if you do not accept the default.
6. Enter a comment to describe the share for users.
7. If the share can have an unlimited amount of users, leave the User Limit at the default. If you would like to specify a maximum number of users to attach to the share, enter it here.
8. Click the Permissions button to specify which users have permission to access the share.
9. If you do not wish to accept the default, remove the Everyone group.
10. Click Add.
11. Select a group to give permission to, or select the Show Users button to specify individual users.
12. Select the type of access this user or group receives for the share.
13. Click OK three times to return to Explorer.

Exercise 5-15: Setting File System Permissions

With Windows NT on an NTFS partition, you can restrict access on folders and even files. This will be another common occurrence in your role as network administrator. File System permissions, combined with share permissions, can greatly secure your files from unwanted guests.

1. Open the Windows Explorer.
2. Right-click a folder that you would like to restrict access to, and select Properties.
3. Click the Security tab, and then the Permissions button.
4. Select a user or group from the list, and modify the type of access. You can also remove the user or group if you wish.
5. To add a user or group, select Add.
6. Select a group to give permission to, or select the Show Users button to specify individual users.
7. Select the type of access this user or group will receive, and select OK when finished.
8. At the main Directory Permissions dialog box, check the box to Replace Permissions on Subdirectories or Existing Files.

Here is an important bit of advice: Do not check Replace Permissions on Subdirectories unless you know what you are doing! I once spent a couple of hours untangling a mess, because a user with full control over a directory checked this box after giving someone else access to the directory. This option doesn’t just give the user permissions to subdirectories underneath; it replaces the permissions on every folder under it with what you see in the dialog box. All of the custom permissions you might have made deeper in the directory are replaced.

System Policy Editor

With the System Policy Editor you can create a policy that restricts users, groups, or computers on the local domain. If you do not have the System Policy Editor icon in your Administrative Tools program group, check in your Winnt directory. If you still do not see it there, it can be found on the Windows NT Server CD-ROM, under Clients\Srvtools\Winnt\I386\Poledit.exe.

Creating a system policy is simple with the graphical System Policy Editor. Most of the settings are self-explanatory, or have a description of what the restriction implies. In order to make sure we understand the System Policy Editor, and can take advantage of its features, we will, in the next exercise, implement a policy for our user account. Refer to Figure 5-12 for and illustration of the Policies tab. Hopefully, your NT Server is set as a domain controller.

Exercise 5-16: Hiding the Network Neighborhood icon

1. Open the System Policy Editor.
2. By default no policy template should be displayed. Click the New Policy icon on the toolbar, or select New Policy from the File menu.
3. Click the Add User button on the toolbar, or select Add User from the Edit menu.
4. If you know the name of the account you are currently logged on as, go ahead and type it, or select the Browse button to locate it.
5. When you have added your current user account, it is visible in the System Policy Editor window. Double-click this icon to set the new policy.
6. Click the plus sign next to Shell to expand it.
7. Click the plus sign next to Restrictions to expand it.
8. Check the box next to Hide Network Neighborhood.
9. Click OK to accept the changes.
10. Select Save As from the File menu.
11. Open the Network Neighborhood icon, and select your computer. If your computer is a domain controller you should see the Netlogon folder. Save the policy file as Ntconfig.pol in this folder.
12. Close all programs and log back on to the system.
13. When your system is finished booting, you will notice that the Network Neighborhood icon is no longer visible.

Of course the Network Neighborhood icon is important, so you may want to uncheck the box in the System Policy Editor to retrieve the icon. Feel free to experiment with the other options available in the System Policy Editor. You may find some settings that are appropriate for members of your family, or for users on your network. One setting that I found especially useful was No Entire Network in Network Neighborhood. We had a problem with a user who browsed another domain, found some games on a remote machine, and e-mailed every user on the network with the shortcuts to the games. Needless to say, the president of the company was not impressed with that e-mail. With an adjustment to the System Policy Editor, this need never happen again.

Registry Mode

If you open the System Policy Editor in Registry mode, you can edit the Registry of the local computer by selecting the Open Registry option under the File menu. You don’t have all the options you would see with Regedit or Regedt32, since you can only edit the values that are present in the System Policy Editor. In other words, if you do not see the setting you would like to modify for the local Registry within System Policy Editor, you cannot modify it using this tool. You must use the Registry editors. Think of Registry mode as a limited graphical Registry Editor.

Policy File Mode

When you open System Policy Editor in Policy File mode, you are creating a policy that overwrites a user’s Registry values with the ones you have specified. This policy file that you create can be used for as many users as you like. If you want the policy file to be downloaded automatically when a user logs on, call the policy NTconfig.pol and place it in the Netlogon share on a domain controller. Windows NT automatically applies the appropriate information if this file is found.

Templates

A System Policy Template file (.ADM) presents you with the available categories that you can configure for your policy file. You can see which template files are in use on your computer by selecting Policy Template from the Options menu.

Policy Order

It is important to understand the order in which policies are applied to users and groups, especially those users belonging to multiple groups. The groups are listed from top to bottom in order of priority, as shown in Figure 5-13.

Restriction of Control Panel Options

When you select a user (and not a machine) in the System Policy Editor you have the option to hide display settings for the user or group. These include every tab that is visible in the Display applet, such as Background, Screen Saver, Appearance, and Settings. Hiding these settings restricts a user from changing any of the settings, and so maintains a uniform desktop throughout the organization.

Desktop Customization

With the Desktop settings (also by selecting a user and not a machine) you can select a wallpaper to appear on all users’ desktops. You can also set a color scheme that the user will not be able to modify.

Network Settings

When you select a machine rather than a user, you can modify network settings for the machine. These include the capability to create hidden drive shares for server and workstation, as well as the update method for your system policies. If you select the Automatic Update mode, the policy file should be located in the default folder, which is the Netlogon folder. If you select the Manual Update mode, you have to enter the path to the policy file that you created.

Network Logon

You can adjust a number settings for the network logon. These might include something like creating a custom logon banner to warn users that unauthorized access will not be tolerated. You also can specify whether the Shutdown button is visible during logon. It is visible by default in NT Workstation, but not for NT Server. It is too risky to enable a shutdown button on NT Server that anyone can click. You have the option of not displaying the username of the last user logged on to the system, although this option may be an annoyance to a person who uses the same machine all day. He would have to retype his username at every logon.

Start Menu Options

There are many options for restricting Start menu features and icons. These options are accessed by clicking a user, expanding the Shell tree, and then expanding the Restrictions tree. Applying most of these options can cripple a machine. For example, you can remove the Run and Find commands from the Start menu, as well as the Shut Down command. This makes it less likely that a user will shut down or restart your system.

User Profiles

User Profiles contain the preferences for each user logged on to the system. Since NT requires a user account for every user that logs on to the system, a user profile is created for every user. These profiles can be located on the local machine, or stored on a server. You can have a different user profile for each computer that you log on to. Each user retains his custom settings, even though many other users log on to the same machine. If he has not logged on to this specific computer before, the settings for the default are used to create the new user profile. While the user is logging off, the user profile is copied and saved.

User Profile Options

When you are creating a User Profile for a user or a group of users, you should know what options you have that are configurable. This allows you to create a snapshot of the environment to be applied to the default or mandatory profile. The following is a list of settings saved in the user profile:

Types of User Profiles

User profiles are how users retain their current desktop and network settings when they log off the machine. There are a number of user profile types that can be used to suit your administrative needs, including the option to let the user customize the profile.

System Default

The System Default profile is what is used when no user is currently logged on to the computer. This profile is stored in the Winnt\System32\config\default folder. You have to edit the Registry to make adjustments to this profile. You should experiment with the System default profile, because you may be asked to create a screen saver to be used when no one is logged on.

User Default

The default user profile is used as a template for any subsequent users that log on to the system. This profile does not affect users that currently have a profile on the system. To create a default user profile, log on a sample account, such as CONFIG, and configure the environment as you wish. Log on as the administrator and use the User Profile tab in the System applet to copy the account that you just created to the NETLOGON folder of the PDC. Here is an example of the path you would type:

\\myserver\netlogon\default user

When you specify the default user folder, it is created automatically, and the Ntuser.dat file is stored there.

Local

A local profile is local to the computer that is being used. Any changes to this profile are not reflected if a user logs on to another machine. The user just creates another separate local profile on the other machine. If you want the changes to be reflected on every machine you use, you must enable a server-based, or roaming, profile.

Server-based

A server-based (or roaming) profile is stored on a server, so it is available to the user regardless which machine the user logs on to. Any changes to a roaming profile are saved to the server, to be retained for the next logon.