In this Chapter
Every user in an organization is an individual, with unique requirements necessary to perform his or her job. Many of those requirements involve IT resources. Part of a system administrator’s job is making the appropriate IT resources available to each of these individual users. This is an easy task in a small company where each user’s IT needs can be catered to individually. In an enterprise organization, the individual still needs IT resources, but his or her needs cannot be addressed one at a time. This is where solid directory services and efficient user management strategies play an important role. Understanding how to leverage the user management tools available in Windows Server 2003 Active Directory to manage user rights and permissions can greatly simplify the task of meeting the IT resource needs of the enterprise user community.
This chapter focuses on recommended Windows Server 2003 Active Directory administrative strategies for managing user rights and permissions. In addition to discussing such concepts as group policies, Intellimirror, and user profiles, this chapter will focus on recommendations for managing common types of users found in every organization.
The first step in developing an efficient and secure design for managing user permissions to resources is understanding groups in Windows Server 2003. The concept of groups is nothing new to system administrators. As will be emphasized in later sections, it is far easier and more efficient to assign permissions and rights to groups rather than individual users. This section will explore the various types of groups available with Windows Server 2003 Active Directory, how and when to use a particular type over another, and general best practices for designing your group structure.
When a group is created in Active Directory, there are two decisions that need to be made. One decision concerns the scope of the group, which includes domain local, global, and universal. The other decision involves the group type: either security or distribution.
Security groups are the primary types of group that administrators are used to managing. Security groups are used to assign permissions to resources for a collection of users. Like user objects in Active Directory, security group objects are each associated with a unique Security ID (SID). The uniqueness of the SID is used by Active Directory to apply security to resources in the domain. Because of this unique SID, you cannot simply delete group A, change the name of group B to A, and expect the renamed group to maintain the security settings of the original group A.
Distribution groups are group objects created so that group members can receive Simple Mail Transfer Protocol (SMTP) mail messages. Any application that can look for addresses in Active Directory (or perform LDAP lookups) can use this type of group object to send mail.
Understanding the difference between security and distribution groups is a fairly familiar concept to most administrators, especially those working with Microsoft networks. With Exchange 2000, though, comes the concept of a mail-enabled group that is a combination of the security and distribution group concepts. A mail-enabled group is essentially a security group that is referenced by an e-mail address and can receive SMTP messages sent to it. This functionality is only possible in an Exchange 2000 (or higher) environment. An Exchange 2000 implementation is directly integrated with Active Directory, and as such actually extends the attributes of AD objects to include e-mail addresses.
This tight integration with Active Directory makes Exchange 2000 an attractive mail service option to companies already benefiting from Active Directory deployments. Additionally, it greatly simplifies group management. A system administrator can now create a single group that can act as both a security principle and an e-mail address.
Additionally, once the functional level of a domain is in Windows 2000 Native or higher, distribution and security groups are interchangeable. As part of a migration path from an NT environment to Windows Server 2003, legacy distribution groups can be easily converted to security groups, thus allowing for a simpler group structure. To convert a distribution group to a security group (or visa versa), follow these steps:
Open Active Directory Users and Computers.
In the console tree, click the group that will be converted. Right-click, and then select Properties.
On the General Tab, under Group Type, select Security, as shown in Figure 5.1 Click OK to complete the change.
There are four scopes to choose from when creating a group in Active Directory. Each scope serves a unique purpose, so it is important to understand the distinctions between them. The group scopes available are
Machine local groups
Domain local groups
Global groups
Universal groups
Machine local groups are by and large the default groups built into the operating system. Local groups can be created on a local workstation or server, but for the most part, in networked environments, the only local groups are installed with the operating system. These groups can be used to apply permissions to resources, but only on the local machine. The most commonly used local groups in Windows operating systems are Administrators, Users, and Power Users. Backup Operators is also a commonly used group for granting permissions to back up local resources on a machine.
Machine Local Groups Are Not Present on Domain Controllers in Active Directory
When a member server is promoted to a domain controller, the original machine local groups and users are removed and replaced with domain groups and users. Any permissions set using local groups would have to be re-created with domain groups.
Using machine local groups to assign permissions to resources in a domain environment is not recommended, though they can be useful for assigning particular rights on individual workstations.
Domain local groups are the next step up the ladder from machine local groups. Similar to local groups in Windows NT, Domain local groups are local in the sense that they can be used to assign permissions on resources local to the domain.
Although the domain local group can assign permissions on resources within its particular domain, it can contain members from anywhere in the Active Directory forest or even outside the forest if the external domains are trusted. Depending on the functional level of the domain, domain local groups can contain any of the following:
Similar to global groups in Windows NT, Active Directory global groups can contain the following types of objects:
User accounts
Other global groups from the same domain (in AD Native mode)
When creating groups in Active Directory, global groups are the default. This group scope is useful for sorting users into easily identifiable groupings and can be used for granting permissions to resources in any domain in the forest.
Introduced with Active Directory, and enhanced in Windows Server 2003, universal groups have the widest scope of all the group scopes. Universal groups can contain objects from any trusted domain, and can be used to apply permissions to any resource in the Active Directory forest.
Universal Security Groups
Universal security groups cannot be created unless the functional level of the domain is set to Windows 2000 Native.
When universal groups were introduced in Windows 2000, Microsoft made it possible to consolidate group membership across domain boundaries. Unfortunately, this functionality was limited by the fact that when the group membership of a universal group changed, the entire group membership would have to be replicated to every domain controller in the forest. System administrators would have to make prudent choices when creating and editing universal groups so as not to negatively affect replication traffic.
Windows Server 2003 enhances the functionality of universal groups in that replication of group membership is on a member-by-member basis rather than an entire group basis. This new functionality, called incremental universal group membership, drastically improves the replication impact on the network environment.
Although using universal groups is a feasible alternative to using global groups in Windows Server 2003 environments, it is still a best practice to reserve this group scope for situations where you need to group objects across domain boundaries.
The second step in setting up an infrastructure where user rights and permissions can be managed is to properly configure the IT resources to which users will have access. Data and applications stored on the company network must be both secure and accessible to those who need it. Remember that a key role in systems administration is that of the security administrator, whose primary objective is to ensure the following:
Data confidentiality. Data internal to the company should only be accessible to users who have authorization.
Data integrity. The data available to authorized users should be accurate and free from tampering.
Data availability. Users authorized to view data should be able to view it when they need it.
In Windows Server 2003, the cornerstone of ensuring security of shared company data is using NTFS formatted volumes with Active Directory integrated file shares. This section details the use of these features.
Formatting Windows servers and workstations with the NTFS (New Technology File System) has been an industry standard for years. NTFS provides advanced features that are not found in any version of file allocation table (FAT). For example, NTFS guarantees volume consistency by using standard transaction logging and recovery techniques. If a system fails, NTFS uses its log file and checkpoint information to restore the consistency of the file system. NTFS also provides advanced features, such as file and folder encryption, disk quotas, and compression.
Most importantly, Active Directory and file and folder permissions rely on NTFS. There really is no centralized management of user rights and permissions without NTFS.
NTFS is used in Windows Server 2003 for file-level security in the operating system. Each file and folder on an NTFS formatted drive is marked by an Access Control Entry (ACE) that limits who can and cannot access the object. NTFS permissions control read, write, and several other types of access.
NTFS has been revised in Windows Server 2003 to secure, by default, critical operating system files and directories to disallow their unauthorized use. Additionally, Windows Server 2003 does not by default grant full control to the Everyone group when creating file shares.
Changing permissions on files or folders is a simple process. Remember when changing permissions to take into account that permissions on subdirectories are inherited from their parent directories. For example, to add a group to the Access Control List (ACL) of a particular folder, perform the following steps:
Right-click the folder for which the security will be applied and choose Sharing and Security.
Select the Security tab.
Check the Advanced button.
Uncheck the Allow Inheritable Permissions from the Parent to Propagate box.
Click Remove when prompted about the application of parent permissions.
In the Advanced dialog box, use the Add buttons to give access to the group who needs access to the folder.
Check the Replace Permission Entries on All Child Objects box, shown in Figure 5.2, and click OK.
When prompted about replacing security on child objects, click Yes to replace child object security and continue.
As file resources are added to the enterprise, managing permissions can become an increasing chore. The administrator’s job in securing data while providing appropriate access is simplified greatly if you adhere to the following:
Assign object permissions to groups of users rather than individual users whenever possible. Even if a group only includes one user, this will remove organizational dependence on one particular account and make alterations much simpler if a person leaves the organization.
Design group permissions so that you have a minimum of duplication. If a set of users need permissions X, Y, and Z, do not create groups with permutations of the three permissions but rather three separate groups. If all of the users need these permissions then only one group is needed. The ultimate goal is to keep the number of groups to a minimum.
Manage permissions globally from the ACL window. Right-clicking on objects will open their Security Permissions window. Use the Advanced button to allow or deny permission to one aspect of an object rather than the whole object.
Allow inheritance as much as possible. Inheritance is the default; specifying that children do not inherit specific permissions from their parents will make Active Directory harder to manage.
With Windows Server 2003, you have the capability to create, view, and manage permissions on any shared resource. A shared resource includes files, folders, printers, or any server resource made available, or published, to users.
Active Directory Shared Folders give you a tool for viewing a list of users connected over the network to a server share and the capability to disconnect one or all of them. Shared folders also give you the capability to see what shared files are opened by remote users and close one or all of the files.
To publish an Active Directory shared folder, follow these steps:
Open Active Directory Users and Computers.
In the console tree, right-click the folder into which you want to create a shared folder.
Point to New, and then click Shared Folder.
Type the name of the folder and the network path as shown in Figure 5.3
Before there were NTFS permission settings, permissions were set at the share level. Although you still have the capability to set permission at the share level, it is preferable to use NTFS-level security. Setting NTFS permissions is the best practice because it inherently secures subdirectories. Share-level security does not protect subdirectories easily.
There are some special points to consider when setting up permissions on files, folders, resources, or shares. The concept of enabling a permission is fairly self explanatory. For example, if the Read permission is Allowed for a user or group on a particular file or folder, that user or group will be able to read the contents of the file or folder. If inheritance is set, that read permission will flow down the directory structure from where it was assigned.
The Deny permission is often a trickier concept to comprehend. As a result, access problems can be caused inadvertently by the misuse or misunderstanding of how this permission setting works.
When permissions are set on a parent container, for example a parent level folder in a shared folder tree, groups or users are granted a certain level of permissions. By doing this, the Access Control Entry (ACE) for that folder restricts access to those individuals defined as members of the groups listed in the ACE. The restriction implicitly denies access to users not defined in the ACE. In this scenario, there is no need for an explicit Deny permission setting.
Deny settings are only used to override an allowed permission that is already set. This situation might occur when allowed permissions are inherited from a parent folder setting. Even this situation might not require explicitly making a Deny setting, as you can break the chain of inheritance and start a new ACE on the subfolder in question by replacing the inherited settings that exclude the group or user you want to exclude.
Explicit Permissions Take Precedence
Explicit permissions take precedence over inherited permissions, even inherited deny permissions.
Never Deny the Everyone Group Access to an Object
Never deny the Everyone group access to an object; the Everyone group also includes Administrators. Instead, exclude the Everyone group from the ACE in question.
Deny permission settings on parent level folders can also be overridden in this fashion. Inherited Deny permissions do not prevent access to a subfolder if that subfolder has an explicit Allow permission entry.
In addition to granting users permission to resources, Windows Server 2003 introduces the concept of user rights or privileges. Privileges are similar to permissions in that they involve controlling access. Where permissions involve access to objects such as files, folders, and printers, privileges grant access to operating system functionality.
The exact list of available rights that you can configure depends on the operating system to which a user will be assigned rights. Some common examples of controllable privileges in Windows Server 2003 and Windows XP are the capability to back up files and directories, log on through Terminal Services, and create a pagefile.
For a complete list of configurable user rights or privileges, open the local policy editor for the operating system on which you want to grant or restrict access. You can also view user rights and privileges through the Group Policy Editor.
Granting user rights is a fairly straightforward process. You have to choose whether rights will be granted at the workstation level via the Local Policy Editor, or at the domain level via the Group Policy Editor. Assigning rights locally will only affect users of that particular workstation. Assigning rights using a domain Group Policy will affect all users or computers in the particular Active Directory container to which the group policy object is linked. Using the Group Policy Editor will be covered in the following section, “Using Group Policy to Administer Rights and Permissions.”
To assign a particular privilege, for example to grant the ability to load device drivers to the Power Users group on a local workstation, perform the following steps:
Type secpol.msc at the Run line, and click OK.
Expand Local Policies, and then expand User Rights Assignments.
In the right pane, double-click Load and Unload Device Drivers, as shown in Figure 5.4.
Click Add User or Group.
Type Power Users in the dialog box, and click OK.
Assign User Rights to Group Accounts Rather Than Individual User Accounts
As is the case with assigning permissions, it is always a advisable to assign user rights to group accounts rather than individual user accounts.
User Privileges Override File and Directory Permissions
Whether you are troubleshooting an access control issue, or you are designing an access control solution, it is important to keep in mind that user privileges override file and directory permissions.
Some privileges can override permissions set on an object. For example, a user logged on to a domain account as a member of the Backup Operators group has the right to perform backup operations for all domain servers. However, this requires the capability to read all files on those servers, even files on which their owners have set permissions that explicitly deny access to all users, including members of the Backup Operators group. A user right—in this case, the right to perform a backup—takes precedence over all file and directory permissions.
To manage user rights and permissions on a larger scale than simply at the server or workstation level, administrators of Windows Server 2003 Active Directory networks can leverage group policies. Group policies enable directory-based change and configuration management of users and computers. This section focuses on the particular functionality of group policy for access management. For a more comprehensive approach to group policies turn to Chapter 6, “Implementing Group Policies.”
Previous sections demonstrated using the Local Policy Editor to manage user rights and privileges; you can assign these same user rights and privileges through the Group Policy Editor. The benefit of using group policies to assign user rights is that a larger scope of users or computers can be managed from a single configuration.
Assigning user rights with the Group Policy Editor is nearly identical to assigning rights with the Local Policy Editor. The exception is the process by which Group Policy Objects (GPOs) are linked to Active Directory container objects.
When you edit the local policy on a workstation or server to assign a particular user privilege, for example to grant the capability to perform backups and restores on a computer, then after the local policy is edited, the configuration is complete. When you make the same configuration at the domain level by creating or modifying a GPO, to enable the configuration, the administrator must also link that GPO to an Active Directory container, for example a particular Organizational Unit (OU). After the GPO is linked to an OU, the policy will apply to all computers contained in that OU. The process of linking a GPO to an AD container can be done in different ways. One way is to modify the properties of the target OU, and create or edit the GPO from that context.
To demonstrate this process in detail, the following example details the steps necessary to grant the capability to back up and restore files on all computers contained in the Sales OU to users contained in the local Power Users group of those computers.
In Active Directory Users and Computers, right-click on the Sales OU.
Choose Properties, and then click the Group Policy tab.
Click New, type a name for the GPO, and then click Close.
Click Edit to open the Group Policy Editor.
Navigate to Computer ConfigurationWindows SettingsSecurity SettingsLocal Policies User Rights Assignment.
Double-click Backup Files and Directories.
Check Define These Policy Settings as shown in Figure 5.5, and click Add User or Group.
Type in Power Users, and click OK to complete the configuration.
This Process Will Be Different
If the Group Policy Management Console is installed on the computer from which group policies are edited, this process will be different. See the section “Enhancing Manageability with GPMC,” in Chapter 6 for more information on this new management utility.
Assigning user rights through group policies has the added security benefit of preventing changes to the configured settings at the local level. When there are conflicting settings between the local policy and a linked group policy, the group policy settings will override the local settings. Additionally, the local policy cannot be modified, even by a local administrator, if a group policy is in force.
Manage User Rights Assignments through Group Policies
For environments where a standard security policy is enforced for all workstations (or servers), manage user rights assignments through group policies. To provide flexibility in the environment, set the policies locally and allow local administrators to customize the user settings for particular computers.
Managing permissions for files and folders through group policies is similar to the process of editing the Access Control Entries (ACEs) on NTFS file folders and shares. Again, group policies can be used to enforce domain or OU-level security standards across a larger scope of computers. In the case of files and folders, you have the capability to replace the local ACEs on computers contained within the scope of the targeted AD container with ACE settings made in a GPO.
In addition to enforcing a security standard on common folder permissions across a broad target of computers, GPO permission settings can also be used to solve access problems that were not evident when initial permission settings were deployed locally.
For example, the default local permissions set on the folder, C:Program Files, limits users to read and execute permissions on this folder and its subfolders in a standard Windows XP workstation. If at a later time a new application is installed on several workstations that create subfolders to which users will need the write permission for proper execution, there will be an access problem that could potentially span hundreds of workstations. The process of changing the local ACE of each workstation would be extremely tedious and time consuming. On the other hand, you can change the ACE through a group policy and fix the problem with just a few keystrokes.
The following example modifies permissions on a particular subfolder, C:Program FilesHRApp, for all user workstations in the Human Resources OU:
Create or modify the GPO linked to the Human Resources OU.
Navigate to Computer ConfigurationWindows SettingsSecurity SettingsFile System.
Right-click File System and choose Add File.
In the Add File or Folders screen, type C:Program FilesHRApp, as shown in Figure 5.6, and click OK.
On the Database Security screen, highlight the Users group, and then check the Write permission and click OK.
In the Add Object dialog box, choose Replace Existing Permissions and click OK.
Programs Might Require Modified Permissions
In some instances, programs might require modified permissions on only a single file in an otherwise tightly secured folder. This method of replacing permissions via group policy is granular enough to accommodate even single file ACE settings enabling you to maintain the most secure yet functional security policies.
In addition to being able to modify file and folder permissions, you have the capability to modify security settings in the Registry using group policies.
As is the case with file permissions, the functional application of setting Registry permissions with group policies are twofold: you can establish security standards across a greater scope of user permissions on workstations or servers; and you can apply fixes to computers already deployed to a vast population of users.
Just as some software requires file permission modifications to run correctly, it is not uncommon to find similar requirements for specific Registry keys. Such requirements, though, might not show up when initial testing and configuration of the software is performed. If an application is deployed to several hundred workstations only to find that a particular functionality does not work with the standard user Registry permissions, it is possible to fix the problem by targeting the workstations with a GPO that addresses the particular Registry security setting.
For example, a company might discover after deploying 400 new workstations that standard users cannot change their default JPEG viewer from Internet Explorer to Photo Editor in Windows XP (or vice versa). The workstations will require modified permissions to the following Registry key: HKLMSOFTWAREMicrosoftShared ToolsGraphic Filters. To modify these permissions through group policy, perform the following steps:
Modify or create a new GPO attached to domain.
In Group Policy Editor, navigate to Computer ConfigurationWindows SettingsSecurity SettingsRegistry.
Right-click Registry, and then choose Add key.
In the Select Registry Key dialog box, manually type the key MACHINESOFTWAREMicrosoftShared ToolsGraphic Filters, and click OK.
Highlight Users, and click Advanced.
Highlight Users again, and click Edit, as shown in Figure 5.7.
Check Allow for Set Value, and then click OK three times.
Because the most efficient way to manage access control to resources is by leveraging groups of various types, it is important to provide a means to manage group memberships across a wide scope of computer objects. To this end, group policies can be defined that limit or set the membership of groups across computer objects contained in the targeted AD container.
For example, you might want to limit the membership of the local Power Users group to the Engineering global group for computers contained in the Engineering OU of the domain. By enforcing such a policy, the local Power Users group cannot be modified at the local level to include any other members besides the Engineering global group.
To establish this restriction, perform the following steps:
Edit or create a GPO attached to the Engineering OU.
In the Group Policy Editor, navigate to the Computer ConfigurationWindows SettingsSecurity SettingsRestricted Groups.
Right-click on Restricted Groups and choose Add Group.
Type Power Users in the dialog box.
Click the Add button for Members of this Group.
Another facet of managing user rights and permissions involves user profiles. A user’s profile is a collection of settings that configure the user’s operating desktop experience. The user profile includes Internet Explorer settings, mapped drives, network printers, desktop settings, and even application-specific configurations. Managing a user’s profile is similar to managing a user’s privileges in that you can define in part what a user can and cannot do when logged in with a particular user account.
There are several types of user profiles available in Windows Server 2003 for you to manage. An understanding of the various types of profiles will enable you to better refine and manage user rights and permissions.
Local profiles exist on a particular workstation or server’s hard disk. A single user could have several local profiles, each with different configuration settings, on various machines to which the user has logged in. Local profiles are managed individually at the workstation or server on which they exist.
Roaming profiles, on the other hand, are stored on a server file share. These profiles are downloaded from the server to the local workstation or server when the user logs into the domain. When the user logs off, the profile is then pushed back up to the server.
Roaming user profiles have the advantage of providing a standard set of profile settings to users regardless of the machine at which she logs into. The disadvantage is that the time it takes to log on or log off will depend on the size of the roaming user profile in use. A best practice for implementing roaming user profiles is to also implement folder redirection. Folder redirection is detailed in Chapter 6 in the section “Increasing Fault Tolerance with Intellimirror.”
Each Windows 2000, Windows XP, and Windows Server 2003 system includes Default and All Users Profiles. These profiles are helpful in setting up a user experience that will affect any user that logs into the system.
The All Users profile folder contains settings that will apply to all users logging into that system. You can use this folder to add desktop shortcuts or start menu items to the users’ specific desktop settings in their local or roaming profile settings. The All Users profile are machine specific and will not modify a user’s local or roaming profile settings.
The Default User profile is used whenever a user logs into a system for the first time. To manage how local profiles are configured on a system, configure the default user profile. You can configure the default user profile by configuring a local user profile, and then copying that configured profile to the default profile folder.
To create a default profile, follow these steps:
Log on to a workstation with a standard local or domain user account, with the same level of access a standard user will have. For this example, use an account called test1.
Configure the profile the way you want it. Create desktop settings, Internet settings, or whatever is necessary for a standard user.
Log off the workstation. The profile is then saved to the c:documents and settings est1 directory.
Log in with an Administrator account.
Double-click the System applet in Control Panel.
Select the Advanced tab, and then click the Settings button in the User Profile section.
Select the correct profile and click the Copy To button.
In the Copy To window, enter the path to the default user directory, C:documents and settingsdefault user, and then click OK to complete the task.
A mandatory profile is the same as a roaming profile except that changes made to the profile settings are not saved to the server upon logoff. These profiles are commonly used in classrooms or publicly shared workstations to strictly manage the profile settings. To change a profile to a mandatory profile, configure the profile to the preferred specification, and then log off the account. Next, with an Administrator account, locate the profile folder and rename the corresponding Ntuser.dat file to Ntuser.man.
Temporary profiles occur when the server authenticating the login for a user with a roaming profile cannot locate the profile folder on the server. When this happens, the machine attempts to load a cached copy of the user’s profile from the local machine. If the user has never logged into the system before and no cached copy of the profile can be located, a temporary profile is created using the Default profile on the system. This temporary profile will become the user’s roaming user profile when the user logs off and the profile is copied up to the server.
Regardless of the best efforts of CEOs to create a corporate environment in which every company associate feels like an equal, system administrators know that special groups of users require special management considerations. It follows, therefore, that different strategies for managing user rights and permissions should be adopted to meet the special requirements that some users have. This section will explore some of these strategies as they apply to common user types found in every organization.
Highly managed users might be defined as users who have a very limited set of applications they must run on their workstation to perform their job function. These users typically have a lower level of computer skills than engineers and developers. As such, it is a best practice to limit these users so that it is difficult, if not impossible, for them to make configuration changes to the system that will cause it to work less efficiently or not at all. At the same time, you must be aware of any particular permissions that these users might require in order for their specific applications to run correctly in a limited environment.
Many companies have employees who either frequently travel or are located away from the typical office environment. These mobile users are unique because they usually log on to the company network through a portable computer from different locations over a slow-link dial-up modem connection. Though mobile users differ, both the slow-link connection and lack of local access should be used as the defining qualities for this type of network client.
In many companies, the administrators’ workstations have no controls in place at all. The accounts the administrators use to log on to the network give them access to control every aspect of the workstation, as well as the servers. Because these accounts have so much power over the network, it is recommended that policies be in place to protect that power.
For More Information...
about managing delegating administration, see Chapter 4, “Distributing Administration.”
The following list provides best practices for safeguarding the administrator account privileges:
Provide administrators with standard user accounts. Instead of allowing system administrators to log in with administrative access for day-to-day functions like checking e-mail and editing documentation, create an additional account that has standard security settings. This prevents administrators from making accidental systemwide configuration changes. This also prevents the account’s elevated privileges from getting into the hands of malicious users.
Use the Run As feature. The Run As feature of Windows 2000 and Windows Server 2003 can be used from an administrator workstation or any network client to elevate privileges temporarily to perform administrative functions. For example, while logged in to a workstation with a user account that has standard user privileges, you can run Active Directory Users and Computers using the Run As command to execute the utility from an administrative account.
Use password-protected screensavers. Enforce password-protected screensavers with a short timeout interval on administrator workstations. This protects the workstation from malicious users taking advantage of the administrator’s credentials should the administrator be temporarily away from the machine. This setting can be made either through the local policy of the administrator or through Group Policy. This particular setting is found by navigating to User ConfigurationAdministrative TemplatesControl PanelDisplayPassword Protect the Screen Saver.
Clearly, Windows Server 2003 provides many ways in which the permissions and rights of users can be managed. By leveraging the various group types available, you can develop efficient methods for assigning the appropriate privileges to the users who require them. Windows Server 2003 provides a simple approach to permissions assignment that allows for granular control of user access to IT resources. The powerful functionality of Group Policy extends your ability to maintain a high level of security for IT resources while at the same time deploying a variety of policies that can target the special access requirements of particular types of users.