The Shutdown Event Tracker

Computer shutdowns can be sorted into either of the following categories:

• Expected shutdowns: An expected shutdown can be defined as a computer shutdown which you predict to occur. Expected shutdowns usually occur when one of the following actions are performed:
• Clicking Start, and then the Shutdown command
• Holding down Ctrl + Alt + Del, and then clicking Shutdown

Expected shutdown can be categorized into:

• Planned shutdowns: These are shutdowns which administrators have some form of control over
• Unplanned shutdowns: These are shutdowns normally initiated by applications.

Unexpected shutdowns: Unexpected shutdowns result in the system shutting down without warning, or unexpectedly.

To enable services, programs, and files to close correctly, you should only turn off the computer when the operating system informs you that it is OK to shut down the server. This is extremely important because it ensures that all configuration settings and other important information are saved and written to disk.

Since administrators need to monitor when and why servers are restarted, Windows Server 2003 includes the following tools to control shutdown events:

• Shutdown Event Tracker
• Shutdown.exe

The Shutdown Event Tracker, a new Windows Server 2003 feature, is an uncomplicated GUI application that allows administrators to monitor shutdown events on the server. The tool is enabled on Windows Server 2003 by default. The Shutdown Event Tracker collects information on the reasons why the server was shut down, and then logs this information in Event Viewer. The command-line utility equivalent to the Shutdown Event Tracker is Shutdown.exe.

The Shutdown Event Tracker requires you to provide a reason whenever a server is shut down or restarted. When a server is expectedly shut down, a dialog box or page is displayed, requesting you to specify the reason for the server being shut down. When a server is unexpectedly shut down, the following user to log on to the server has to specify the reason for the server shutting down. Shutdown events can be viewed in Event Viewer, and can be useful when you need to improve uptime.

How to configure the Shutdown Event Tracker

• Not Configured
• Enabled
• Disabled

• Always: This option is self explanatory.
• Server Only: When selected, the Shutdown Event Tracker is displayed for only Windows Server 2003 servers.
• Workstation Only: When selected, the Shutdown Event Tracker is displayed for only Windows XP Professional workstations.

1. Click Start, Run, and then enter gpedit.msc. Click OK.
2. The Group Policy Object Editor console opens.
3. In the left pane, expand Computer Configuration, and then Administrative Templates.
4. Click System
5. In the right pane, find and double-click the Display Shutdown Event Tracker.
6. When the Display Shutdown Event Tracker Properties dialog box opens, select one of the following options:
7. If you select the Enabled option, you can choose between the following options to specify when the Shutdown Event Tracker should be displayed:
8. If you want to view help information on the Shutdown Event Tracker application, click the Explain tab.
9. Click OK, and then close the Group Policy Object Editor console.

How the Shutdown Event Tracker works

• Restart
• Shut down
• Log off the current user

1. Enable the Display Shutdown Event Tracker policy so that the Shutdown Event Tracker is displayed.
2. The Shut Down Windows dialog box is displayed when the server is shut down or restarted. The Shut Down Windows dialog box requires you to record information as to why the server was shut down.
3. Using the options in the What do you want the computer to do drop-down list box, you can choose to perform the following tasks:
4. Using the Options: drop-down list box, select the reason that best describes why the server was shut down or restarted.
5. Next, either select or clear the Planned checkbox to indicate whether the shutdown was planned or unplanned.
6. In the Comment box, enter any additional useful information.
7. Click OK to close the Shut Down Windows dialog box

How to induce the Shutdown Event Tracker functionality on a remote computer

1. To bring up the Remote Shutdown Dialog page on a remote computer, use the shutdown.exe command-line utility with /i.
2. Select the appropriate option from the What do you want the computer to do drop-down list box.
3. In the Shutdown Event Tracker group box, select an option which describes why the computer is being shut down, and click the Planned checkbox.
4. Enter a comment in the Comment box.
5. Click OK.

How to use the shutdown.exe command-line utility

The shutdown.exe command-line utility can be used to enter shutdown events using the command-line. The available options for the shutdown.exe command-line utility are listed below:

• /s ServerName: /s shuts the server down, with ServerName detailing the name of the machine which should be shut down.
• /r: Restarts the shutdown computer.
• /t nnn: Specifies, in seconds, the time period for shutdown. The default is 30 seconds, and can be a value between 0 and 600.
• /d [p:xx:yy]: /d describes the reason for the shutdown; p specifies that the shutdown is planned, xx and yy are for the major and minor reason numbers. The shutdown is regarded as being unplanned when p: is missing.
• /p: Used with the /d switch, it indicates that the power of the machine is on.
• /d[p:]xx:yy: xx (major) and yy (minor) indicate the major and minor reason numbers.
• /m computername: Specifies the name of the target computer.
• /a: Cancels the shutdown

How to use the Registry to configure registry entries for the Shutdown Event Tracker

You can use the Registry Editor to configure the Shutdown Event Tracker. Through configuring registry settings, you can enable or disable the Shutdown Event Tracker.

To configure registry settings for the Shutdown Event Tracker,

1. Click Start, Run, enter regedit, and click OK.
2. The Registry Editor console opens.
3. Navigate to HKEY_LOCAL_MACHINE, Software, Microsoft, Windows, CurrentVersion, and then Reliability.
4. Select ShutdownReasonUI. If ShutdownReasonUI does not exist, create a DWORD value, and then name it ShutdownReasonUI.
5. Enter a data value of 1 in the Value data box to enable the Shutdown Event Tracker, or enter a data value of 0 in the Value data to disable the Shutdown Event Tracker.
6. Click OK.
7. Close the Registry Editor console.
8. Restart the computer.

How to add custom reasons for the Shutdown Event Tracker

• P, indicates a planned shutdown.
• C, a comment is required.
• B, a ID is required.
• S, the expected shutdown event dialog box is displayed
• D, the unexpected shutdown event dialog box is displayed

1. Click Start, Run, regedit enter, and click OK.
2. The Registry Editor console opens.
3. Navigate to HKEY_LOCAL_MACHINE, Software, Microsoft, Windows, CurrentVersion, Reliability, and then UserDefined.
4. Create a new string value using the available flags:
5. You can add additional comments using the string registry value. The format for comments is:
6. Click OK and then close the Registry Editor console.
7. Restart the computer.

How to view shutdown events

Shutdown events can be viewed in Event Viewer. Event Viewer is used to monitor events that took place on a computer. Event Viewer stores events that are logged in a system log, application log, and security log. Because the system log conains events that are associated with the operating system, shutdown events are written to the system log.

To open Event Viewer,

1. Select Start, Select Administrative Tools, and then select Event Viewer.
2. Select the event log you want to view.

Event Viewer logs list five event types:

• Information events tell you when a particular activity occurs, such as starting the system.
• Warning events point out problems that could possibly occur.
• Error events indicate an actual error that occurred.
• Success Audit events indicates an event that has been audited for success
• Success Failure events indicates an event that has been audited for failure

To view shutdown events

1. Open Event Viewer
2. Open the System log.
3. Using the Event Source drop-down list, select USER32.
4. To view the System log in a form, filtered to show only shutdown events and USER32 events, click OK.
5. When the events are displayed, you can examine a detailed description of a particular shutdown event by double-clicking the particular event.
6. The Event Properties dialog box is displayed.
7. Click OK to close the dialog box.

How to disable the Shutdown Event Tracker

1. Click Start, Run, and then enter gpedit.msc. Click OK.
2. The Group Policy Object Editor console opens.
3. In the left pane, expand Computer Configuration, and then Administrative Templates.
4. Click System
5. In the right pane, find and double-click the Display Shutdown Event Tracker.
6. When the Display Shutdown Event Tracker Properties dialog box opens, click the Disabled option to disable the Shutdown Event Tracker.
7. Click OK.
8. Close the Group Policy Editor console.

How to Delegate Administrator Privileges in Active Directory

The primary reason to create organizational units is to distribute administrative tasks across the organization by delegating administrative control to other administrators. Delegation is especially important when a decentralized administrative model is developed. Delegation of administration is the process of decentralizing the responsibility for managing organizational units from a central administrator to other administrators. The ability to establish access to individual organizational units is an important security feature in Active Directory. Users can control access to the lowest level of an organization without having to create many active directory domains.

Authority delegated at the site level will likely span domains or conversely, may not include targets in the domain. Authority delegated at the domain level will affect all objects in the domain. Authority delegated at the organizational unit level can affect that object and all of its child objects or just the object itself.

Delegation of control is the ability to assign the responsibility of managing Active Directory objects to another user, group, or organization. By delegating control, the need for multiple administrative accounts that have broad authority can be eliminated. Delegated administration in Active Directory helps ease the administrative burden of managing a network by distributing routine administrative tasks to multiple users. Basic delegated rights can be given to normal users, like create a user account or group account etc. and major domain-wide administration work can be delegated to senior/junior level administrator.

Autonomy is the ability of administrators in an organization to independently manage:

• All or part of service management (called service autonomy).
• All or part of the data in the active directory database or member computers that are joined to the directory (called autonomy).

Common Administrative Tasks

Administrators routinely perform the following tasks in active directory:

• Change properties on a particular container. For example, when a new software package is available, administrators may create a group policy that controls software distribution.
• Create and Delete objects of a specific type. In an organizational unit, specific types may include users, groups, and printers. When the new employee joins the organization, for example, a user account is created for the employee and then the employee is added to the appropriate organizational unit or group.
• Update specific properties on specific object types. In an organizational unit, this is perhaps the most common administrative task performed. Updating properties include tasks such as resetting passwords and changing an employee’s personal information, such as his/her home address and phone number, when he/she moves.

Delegation of Administrative Control

Use the delegation of control wizard to delegate administrative control of active directory objects such as organizational units. By using the wizard, users can delegate common administrative tasks such as creating, deleting, and managing user accounts.

To delegate common administrative tasks for an organizational unit, perform the following steps:

• Start the delegation of control wizard by performing the following steps:
  • Open Active Directory Users and Computers.
  • In the console tree, double click the domain node.
  • In the details menu, right click the organizational unit, click delegate control, and click next.
• Select the users or group to which common administrative tasks will be delegated. To do so, perform the following steps:
  • On the Users or Groups page, click Add.
  • In the select Users, computers, or Groups, write the names of the users and groups to which control of the organizational unit has to be delegated, click OK and next.
• Assign common tasks to delegate. To do so, perform the following common tasks:
  • On the tasks to delegate page, click delegate the following common tasks.
  • On the tasks to delegate page, select the tasks to be delegated and click OK.
• Click Finish.

Customizing Delegated Administrative Control

In addition to using the delegation of control wizard to delegate a custom set of administrative tasks such as the creation, deletion, and management of user accounts, use the wizard to select a set of custom tasks and delegate control of only those tasks.

For example, users can delegate control of all existing objects in an organizational unit and any new objects that are added or select the objects in the organizational unit to delegate administrative control of, such as only user objects in an organizational unit. Users can also specify that they want to delegate only the creation of the selected objects, the deletion of the object, or both.

To delegate custom administrative tasks for an organizational unit, perform the following steps:

• Start the Delegation of Control Wizard.
• Select the users or groups to which administrative tasks will be delegated.
• Assign the custom tasks to delegate. To do this, perform the following steps:
  • On the Tasks to Delegate page, click Create a custom task to delegate and click next.
  • On the Active Directory Object Type page, select one of the following tasks:
• Click This folder, existing objects in this folder, creation of new objects in this folder, and click next.
• Click Only the following objects in the folder, select the Active Directory object type that will delegate control, and click next.
  • Select the permissions to be delegated and click next.
• Click Finish.

Replication Topology in Active Directory

Replication Topology is the route by which replication data travels throughout a network. Replication occurs between two domain controllers at a time. Over time, replication synchronizes information in Active Directory for an entire forest of domain controllers. To create a replication topology active directory must determine which domain controller's replicate data with other domain controllers.

The Knowledge Consistency Checker (KCC) is a built-in process that runs on each domain controller and regenerates the replication topology for all directory partitions that are contained on that domain controller. The KCC runs at specified intervals of every 15 minutes by default and designates replication routes between domain controllers that are most favorable connections that are available at the time.

How the KCC Works

To generate a replication topology automatically, the KCC evaluates information in the configuration partition on sites, the cost sending data between these sites (cost refers to the relative value of the replication paths), any existing connection objects, and the replication protocols that the KCC can domain controller's directory partitions to other domain controllers. If replication within the site becomes impossible or has a single point of failure, the KCC automatically established new connection objects between domain controllers to domain Active Directory replication.

Global Catalog and Replication of Partitions

A global catalog server is a domain controller that stores two forest-wide partitions-the schema and configuration partitions plus a read/write copy of the partition from its own domain and a partial replica of all domain partition in the forest. These partial replicas contain a read only subset of the information in each domain partition.

When you add a new domain to a forest, the configuration partition also adds the same information about the new domain. Active Directory replicates the configuration partition to all domain controllers, including global catalog servers, though normal forest-wide replication. Each global catalog server becomes a partial replica of the new domain by contacting a domain controller for that domain and obtaining the partial replica information. The configuration partners also provide the domain controllers a list of all global catalog servers in the forest.

Global Catalog servers register special DNS records in the DNS zone that corresponds to the forest not domain. These records, which are registered only in the forest root DNS zone, helps client and servers locate global catalog servers though out the forest.

Sites and Site Links

In Active Directory, sites help define the physical structure of a network. A set of TCP/IP subset address ranges defines a site, which in turn defines a group of domain controllers that have similar speed and cost. Sites consist of server objects, which contain connection objects that enable replication.

When you create additional sites, you must select at least one site link for each site, unless a site link is in place, connections cannot be made between computers at different sites, nor can replication occur between sites. Additional site links are not created automatically; you must use active directory sites and services to create them.

When you create the first domain in a forest, active directory creates a default site link named DEFAULTSITELINK. It indicates the first site and is located in the IP container in active directory. You can rename the site link.

To use sites to manage replication between sites, you create additional sites and subnets and delegate control of sites. Creating a site involves providing a name for the new site and associating the site with a site link. To create sites, you must log on as a member of the Enterprise Admin group or the Domain Admin group in the forest root domain.

A site link bridge creates a chain of site links that domain controllers from ifferent sites in the site links can use to communicate directly. Bridging is useful to constrain the KCC to particular paths in the site link topology. By default, site link bridging is enabled and all site links are considered transitive. That is, all site links for a given transport implicitly belong to a single site link bridge for that transport. So, in a fully routed IP network, it is not necessary to configure any site link bridges. If your IP network is not fully routed, you can disable site link bridging to urn off the transitive site link feature for the IP transport, and then configure site link bridges to model the actual routing behavior of your network.

The Bridgehead server is a domain controller that you designed to send and receive replicated data at each site. The bridgehead server from the originating site collects all of the replication changes and then sends them to the receiving site's bridgehead server, which replicates the changes to all domain controllers in the site.

Intersite Topology Generator

The inter site topology generator in an active directory process that defines the replication between the sites on a network. A single domain controller in each site I automatically designated to be the inter-site topology generator. Because this action is performed by the inter-site topology, you are not required to take any action to determine the replication topology and the bridgehead server roles.

The domain controller that holds the inter-site topology generator role performs two functions:

• It automatically selects one or more domain controllers to become bridgehead servers. This way, if a bridgehead server becomes unavailable, it automatically selects another bridgehead server, if possible.
• It runs the KCC to determine the replication topology and resultant connection objects that the bridgehead servers can use to use to communicate with bridgehead server of other sites.

To refresh replication topology, first determine whether you want to refresh the replication topology between sites or the replication topology within a site

Short note on Global Catalog

The global catalog is a distributed data repository that is stored in global catalog servers and issued via multimaster replication. It basically is composed of a representation (partial) of every object in the multidomain Active Directory forest that can also be searched. The global catalog is used because searches can be made faster because they don't need to go through the hassle of involving referrals to different domain controllers.

In addition, the global catalog allows finding an object that you wish without needing to know the object's domain name. This is possible because not only does it hold a full, writable domain directory replica, but it also has a partial, read-only replica of all the domain directory partitions in the forest. Therefore, by being composed of only the most used attributes during searching, all objects in every domain in any small or big forest can be found and represented in the database of one global catalog server.

To maintain the ability to conduct a full, fast, and effective search, the global catalog is constantly updated by the Active Directory replication system. These attributes that are replicated to the catalog are known as partial attribute set (PAS). The PAS, in a Windows 2000 Server environment will cause a full synchronization of the global catalog to occur even if it may be a minor change. However, this issue was improved upon in the Windows 2003 Server environment with a change in the PAS by only updating the attributes that change.

How Does It Work?

As an example, if a user decides to search for all printers within the forest, a global catalog server will process the request submitted by the user by searching through the global catalog, and then output the results. Had it not been for the global catalog server, the user would have had to have searched separately in every forest.

When a user tries to run a certain query (an example of an interactive domain logon), the domain controller will authenticate the user by first validating the user's identity and also all groups that the user is a part of. This is because the global catalog is the hold of all memberships to all groups, which means that this access to a global catalog server is necessary to accessing all forests, and thus is a requirement for Active Directory authentications. Therefore, it is best to have at least one global catalog server in one Active Directory site. This is because then, the authenticating domain controller does not need to transmit queries over a WAN connection to source information and process tasks.

Ports Commonly Used by Global Catalog Servers

Service Name	UDP	TCP
LDAP		3268 (global catalog)
LDAP		3269 (global catalog SSL)
LDAP	389	389
LDAP		636 (SSL)
RPC/REPL		135(endpoint mapper)
Kerberos	88	88(global catalog)
DNS	53	53
SMB over IP	445	445

Global Catalog in Active Directory

Domains and Forests can also share resources available in active directory. These resources are searched by Global Catalog across domains and forests and this search is transparent to user. For example, if you make a search for all of the printers in a forest, this search goes to global catalog server for its query and then global catalog returns the results. Without a global catalog server this query needs to go to every domain in the forest of its result.

It is important to have a global catalog on at least one domain controller because many applications use port 3268 for searching. For example, if you do not have any global catalog servers in your network, the Search command on the Start menu of Windows 2000/2003 cannot locate objects in Active Directory.

The global catalog is a domain controller that contains attributes for every object in the Active Directory. By default, only the members of the Schema Admins group have rights to change which attributes stored in the global catalog, according to organization's requirements.

The global catalog contains:

• The commonly used attributes need in queries, such as a user's first and last name, and logon name.
• All the information or records which are important to determine the location of any object in the directory.
• A default subset of attributes for each object type.
• All the access related permissions for every object and attribute that is stored in the global catalog. Say, without permission you can't access or view the objects. If you are searching for an object where you do not have the appropriate permissions to view, the object will not appear in the search results. These access permissions ensure that users can find only objects to which they have been assigned access.

A global catalog server is a domain controller that contains full and writable replica of its domain directory, and a partial, read-only replica of all other domain directory partitions in the forest. Let's take an example of a user object; by default user objects have lot of attributes such as first name, last name, address, phone number, and many more. The Global Catalog will store only the main attributes of user objects in search operations like a user's first name and last name, or login name. This partial attributes of that user object which is stored would be enough to allow a search for that object to be able to locate the full replica of the object in active directory. If a search comes to locate objects, then first it goes to local global catalog and reduces network traffic over the WAN.

Domain Controllers always contain the full attribute list for objects belonging to their domain. If the Domain Controller is also a GC, it will also contain a partial replica of objects from all other domains in the forest.

It is always recommended to have a global catalog server for every active directory site in an enterprise network.

Active Directory Operations Masters

When a change is made to a domain, the change is replicated across all of the domain controllers in the domain. Some changes, such as those made to the schema, are replicated across all of the domains in the forest. This replication is called multimaster replication. But few changes are practically not possible to perform with multimaster replication, so a domain controller known as Operations Master takes such type of changes to perform. Five Operations Master Roles are given to one or more domain controllers in each forest.

Operations Master Roles

The operations master roles are also called as flexible single master operations (FSMO) roles.

Forest-Wide Roles: Unique to a forest

• Schema Master: Controls all modifications and updates to the schema. The schema contains the master list of objects classes and attributes that are used to create all Active Directory objects, such as users, computers and printers. One needs to have access to update the schema of a forest. There is only one schema master in the entire forest.
• Domain Naming Master: Controls the additions or removal of domains in the forest. When you add a new domain to the forest, only the domain controller that holds the domain naming master role can add the new domain. There can be only one domain naming master in the entire forest.
  The role of domain naming master can be hold by any Windows Server 2000/2003. Domain naming master should be configured as a global catalog server.

There is only one schema master and one domain-naming master in the entire forest.

Domain-Wide Roles: Unique to each domain in a forest

• Primary Domain Controller (PDC) Emulator: If your networks has one or more Windows NT, there it act as Windows NT PDC to support any backup domain controller (BDCs) running Windows NT within a mixed mode domain. This type of domain has domain controllers that run Windows NT. The PDC Emulator role is maintained in the first domain controller that you create in a domain. By default, for time synchronization throughout the domain for all domain controllers, PDC emulator master is also responsible. Using "net time" one can synchronize the time of PDC Emulator with external server. Syntax is:

  net time ServerName/setsntp:TimeSource
  

  After executing this statement, all computers in the entire forest run within seconds of each other. PDC emulator role supports two authentication protocols: Kerberos V5 protocol and NTLM protocol
• Relative Identifier Master: When you create a new user, computer or object, the domain controller creates a new security principal for that object and assigns that object a unique security identifier (SID). This SID consists of domain ID and a relative identifier (RID). The RID master allocates blocks of RIDs to each domain controller in the domain. Domain controller use these allocated block of RIDs to assigns a RID to objects.
  Using Movetree.exe you can move an object between domains. But before this you need to initiate the move on the Relative Identifier (RID) master domain which contains the object.
• Infrastructure Master: Infrastructure master updates objects references when objects are moved from one domain to another. The object references contain GUID (Global Unique Identifier), a Security Identifier (SID), and distinguished name. The infrastructure master always replicates its data with global catalog.
  Global catalogs always receive the regular updates from other domain through replication; therefore global catalog data is always up to date. For regular updates it will always ask the global catalog. Then infrastructure master replicates its updated data to all domain controllers in the domain. Infrastructure master and global catalog should never be on the same domain controller because infrastructure master will not function.

An Overview of Auditing

Auditing enables you to determine which activities are occurring on your system. Through auditing, you can track access to objects, files and folders; as well as any modifications made to the objects, files and folders. Auditing therefore enables you to collect information associated with resource access and usage on your system by allowing you to audit system logon, file access, object access, as well as any configuration changes. An audit trail can be defined as a list of audit entries which portray the life span of an object, or file and folder. When an event or action takes place that's configured for auditing, the action or event is written to the security log. Security auditing events are thus written to the security log of the system, and can be accessed from Event Viewer.

Audit entries in the security log can be one of the following:

• Success event
  
• Failure event
  

The main types of events which you should audit are listed below:

• Computer logons and computer logoffs
  
• Access to objects, and files and folders
  
• System events, such as when the following occurs:
  
  • Computer reboots and computer shutdowns.
    
  • System time is modified
    
  • Audit logs are cleared.
    
• Performance of user and computer account management activities, such as:
  
  • Creating new accounts
    
  • Changing permissions
    
  • Modifying account statuses
    

One of the primary steps in implementing auditing is to create an audit plan which would define the objectives of implementing auditing on your system. The aspects which should be included in your audit plan are:

• List the type of access and information which should be audited.
  
• Determine whether success events, failure events, or both success and failure events should be audited.
  
• Determine the resources which are available for auditing purposes. Resources in this case refers to disk space, and memory and processor usage
  
• Plan the scope of auditing according to the resources which are available for auditing purposes. A wide auditing scope with auditing of both success and failure events can cause a large quantity of data to be collected. This in turn could prevent you from easily finding the information considered important.
  
• Define the quantity of time which would be required to view and analyze audit logs.
  

Auditing of security event categories are disabled by default. In order to track access to objects, and files and folders, you have to define and configure an audit policy. You have to determine the types of events which you want to audit, and include the security requirements of the organization when you configure audit policies. Another step in defining audit policies is to determine the particular event categories which should be audited.

The event categories which you can audit are

• Account logon events: This policy is typically enabled on domain controllers, to track users which are logging on to the computer.
  
• Account management: This policy tracks account management tasks performed on the computer, including creating, changing, and deleting user objects; and changing account passwords.
  
• Directory service access: For domain controllers, the policy tracks when users access Active Directory objects which have system access control lists (SACLs).
  
• Logon events: This audit policy tracks when the user logons and logoffs.
  
• Object access: Tracks when a user accesses operating system components such as files, folders or registry keys.
  
• Policy change: This policy tacks when changes are made to the security configuration settings of the computer, and includes changes made to:
  
  • Audit policies
    
  • Trust policies
    
  • User rights
    
• Privilege use: Tracks when a user effects a user right. The user rights excluded from auditing because of the volume of log entries which they generate are:
  
  • Back Up Files And Directories
    
  • Bypass Traverse Checking
    
  • Create A Token Object
    
  • Debug Programs
    
  • Generate Security Audits
    
  • Replace Process Level Token
    
  • Restore Files And Directories
    
• Process tracking: This audit policy tracks when certain events take place on the computer, such as when a program starts, or a process ends.
  
• System events: This policy tracks the following events:
  
  • The computer restarts, or shuts down.
    
  • Any events that impact the security log or the security of the system.
    

For each of the above mentioned event categories, you can choose between three values when you enable auditing. These values in turn determine the condition for which an audit entry would be created:

• Successes only; an audit entry will be created when a particular event or action successfully finalizes.
  
• Failure only; an audit entry will be created when a particular event or action fails.
  
• Successes and Failures; an entry will be created when the particular event or action successfully finalizes or fails.
  

You can define audit polices for:

• The local computer
  
• A domain controller
  
• A domain
  
• An organization unit (OU)
  

Audit policies can be configured through Group Policy for the entire site, or a domain and OU. You can also configure audit policies for servers and workstations.

You can enable the Security Options policies to secure certain server components from a number of threats and accidents:

• Accounts: Administrator Account Status; enables/disables the local Administrator account of the computer.
  
• Accounts: Guest Account Status; enables/disables the local Guest account of the computer.
  
• Accounts: Rename Administrator Account; defines the alternative name for the security identifier (SID) of the local Administrator account
  
• Accounts: Rename Guest Account; defines the alternative name for the security identifier (SID) of the local Guest account
  
• Audit: Audit The Use Of Backup And Restore Privilege; when the Audit Privilege Use policy is enabled, it configures the computer to audit user privileges.
  
• Audit: Shut Down System Immediately If Unable To Log Security Audits; results in the computer shutting down when no further auditing entries can be written to the security log due to the log reaching its maximum size limit.
  
• Devices: Allowed To Format And Eject Removable Media; defines those local groups which are allowed to format and eject removable NTFS file system media.
  
• Devices: Restrict CD-ROM Access To Locally Logged-on User Only; stops users from accessing the CD-ROM drives of the computer.
  
• Devices: Restrict Floppy Access To Locally Logged-on User Only; stops users from accessing the floppy disk drive of the computer.
  
• Domain Member: Maximum Machine Account Password Age; sets the frequency at which the computer account password of the system is modified.
  
• Interactive Logon: Do Not Require CTRL+ALT+DEL; specifies the Disable option so that users are secured from Trojan horse attacks.
  
• Interactive Logon: Require Domain Controller Authentication To Unlock Workstation; stops the computer from being unlocked through cached credentials.
  
• Microsoft Network Client: Digitally Sign Communications (Always); sets the computer to require packet signatures for Server Message Block client communications.
  
• Microsoft Network Server: Digitally Sign Communications (Always); sets the computer to require packet signatures for Server Message Block server communications.
  
• Network Access: Do Not Allow Anonymous Enumeration Of SAM Accounts And Shares; stops anonymous users from gathering information on the names of local user accounts and shares.
  
• Network Access: Remotely Accessible Registry Paths And Sub-paths; defines the registry paths and sub-paths which certain users can access.
  
• Network Access: Shares That Can Be Accessed Anonymously; defines the shares which can be accessed by anonymous users.
  
• Network Security: Force Logoff When Logon Hours Expire; configures the computer to end any current local user connections that have used up their defined logon hours or time.
  
• Shutdown: Allow System To Be Shut Down Without Having To Log On; enables the Shut Down button in the Log On To Windows dialog box.
  

The information recorded on an event in a security event log is listed below:

• The type of event logged: Error, Warning, or Information, and Success Audit or Failure Audit
  
• The date on which the event occurred
  
• The software or program that logged or recorded the event.
  
• The user that performed the action which resulted in an event being logged.
  
• The computer name on which this action was performed
  
• The event identity number
  
• The event description
  

A few recommendations for auditing security events are summarized below:

• Define an audit plan which details what you want to audit
  
• Configure the security event log size so that it is suitable for the security requirements of the organization
  
• Archive security logs on a regular basis.
  
• Audit both success events and failure events in the System Events category
  

How to define an audit policy on the local computer

1. Click Start, Programs, Administrative Tools, and then click Local Security Policy.
   
2. Expand the Local Policies in the left pane.
   
3. Click Audit Policy.
   
4. The options which you can define audit policy for are listed in the right pane.
   
5. Proceed to select and double-click the desired option.
   
6. When the Properties dialog box for the policy which you have selected opens, enable success audit, failure audit, or both success and failure audits.
   
7. Click OK.
   

How to define an audit policy on the domain controller

1. Click Start, Programs, Administrative Tools, and then click Domain Controller Security Policy.
   
2. Expand the appropriate nodes in the left pane to move to Computer Configuration, Windows Settings, Security Settings, Local Policies, and then Audit Policy.
   
3. Click Audit Policy.
   
4. Proceed to select and double-click the desired option.
   
5. When the Properties dialog box for the policy which you have selected opens, enable success audit, or failure audit, or both success and failure audits.
   
6. Click OK.
   

How to define the event categories to audit for a site, domain, or OU

1. Click Start, Administrative Tools, and then click Active Directory Users And Computers
   
2. In the left console pane, right-click the site, domain, or OU; and then select Properties from the shortcut menu.
   
3. Click the Group Policy tab, add a new policy, and click Edit
   
4. In the Group Policy Object Editor console, in the left console tree, expand Computer Configuration, Windows Settings, Security Settings, Local Policies and then expand Audit Policy
   
5. In the details pane, right-click the particular event category which you want to audit; and then select Properties from the shortcut menu.
   
6. When the Properties dialog box of the event category opens, select one or both of the following options: Success, Failure
   
7. Click OK.
   

How to enable auditing for Active Directory objects.

1. Open the Active Directory Users And Computers console
   
2. Ensure that Advanced Features are enabled on the View menu
   
3. Select the Active Directory object which you want to configure auditing for, and then select Properties on Action menu.
   
4. When the Properties dialog box of the object opens, click the Security tab.
   
5. Click Advanced to move to the Advanced Security Settings For dialog box for the Active Directory object.
   
6. Click the Auditing tab.
   
7. Click Add, and then specify the users or groups for which you want to audit object access.
   
8. Click OK.
   
9. When the Auditing Entry For dialog box for the object appears, choose the event(s) that you want to audit by choosing either one of, or both of the following options: Successful, Failed; alongside the particular event(s).
   
10. Use the Apply Onto list box to set where the auditing should take place. The default setting is This Object And All Child Objects.
    
11. Click OK.
    

How to enable auditing for files and folders

1. Open Windows Explorer.
   
2. Right-click the file or folder which you want to configure auditing for, and then select Properties from the shortcut menu.
   
3. On the Security tab, click Advanced.
   
4. Click the Auditing tab on the Advanced Security Settings For dialog box of the file or folder.
   
5. Click Add, and then choose the users/groups for which you want to audit file or folder access. Click OK.
   
6. In the Auditing Entry For dialog box for the file/folder, select the events that you want to audit by checking either the Successful option, Failed option, or both of these options alongside the particular event(s). You can choose to audit the following events:
   
   • Full Control
     
   • Traverse Folder/Execute File
     
   • List Folder/Read Data
     
   • Read Attributes
     
   • Read Extended Attributes
     
   • Create Files/Write Data
     
   • Create Folders/Append Data
     
   • Write Attributes
     
   • Write Extended Attributes
     
   • Delete Subfolders and Files
     
   • Delete
     
   • Read Permissions
     
   • Change Permissions
     
   • Take Ownership
     
7. Use the Apply Onto list box to specify the location where auditing should occur. The default setting is This Folder, Subfolders And Files.
   
8. Click OK.
   

How to apply an audit policy to Active Directory users and OUs using Group Policy

1. Click Start, Run, enter mmc in the Run dialog box, and click OK.
   
2. Using the File menu, click Add Snap in, and then click Add.
   
3. Select the Group Policy Object Editor management tool and then click Add.
   
4. When the Select Group Policy Object dialog box opens, click Browse to choose the proper GPO for the specific domain or OU.
   
5. In the left pane, expand Computer Configuration, Windows Settings, Security Settings, and then expand File System to set a audit policy for the file system
   
6. Right-click the File System node to add audit settings for a file/folder.
   
7. Using the browse interface, locate the file/folder for which you want to configure auditing.
   
8. Click Edit Security to specify the auditing settings.
   

How to access Event Viewer to view security log information

1. Click Start, Programs, Administrative Tools, and then click Event Viewer
   

How to view information in the security log through Event Viewer

1. Open Event Viewer
   
2. In the console tree in the left pane, click Security
   
3. The details pane is populated with all events that exist in the security log, together with summary information such as Date, Time, Category, Event ID, and User; on each entry.
   
   • A key icon is displayed alongside successful audit events.
     
   • A lock icon is displayed alongside unsuccessful audit events.
     
4. You can double-click on an event entry to view its properties.
   

How to filter events in the security log

1. Open Event Viewer
   
2. In the console tree in the left pane, click Security
   
3. On the View menu, click the Filter option.
   
4. On the Filter tab, specify the filter criteria that you want to use to display a specific event(s) in the security log.
   
5. In the Event Types section of the dialog box, specify the types of events tht you want to display in the security log.
   
6. In the Event Source list, choose the source that logged the event(s) which you want to display.
   
7. In the Category list, choose the event category.
   
8. In the Event ID box, enter the event identity number
   
9. In the User box, enter the user name
   
10. In the Computer box, enter the computer name.
    
11. Use the From list boxes to enter the start parameters for the events which should be filtered.
    
12. Use To list boxes to enter the end parameters for the events which should be filtered.
    
13. Click OK to display the filtered events in the security log.
    
14. Clicking the Restore Defaults button on the Filter tab removes the security log filter.
    

How to configure the size of the security event log

1. Open Event Viewer
   
2. In the console tree in the left pane, right-click Security and then select Properties on the shortcut menu.
   
3. When the Security Properties dialog box opens, on the General tab, enter the maximum log file size. The default setting is 512 KB. You can set the maximum log file size to any size from 64 KB to 4,194,240 KB.
   
4. Choose one of the following options listed beneath the When Maximum Log File Size Is Reached section of the dialog box:
   
   • Overwrite Events As Needed: When selected, the oldest events in the security log are replaced when new events need to be logged.
     
   • Overwrite Events Older Than _ Days: Enter the number of days after which the system can overwrite an event.
     
   • Do Not Overwrite Events (Clear Log Manually): When selected, you have chosen to manually clear the security log. The system does not overwrite or replace any events in the security log when the maximum log file size is reached. If the security log is not manually cleared, all new events are dropped, and are therefore not recorded in the security log.
     

How to clear the security log

1. Open Event Viewer
   
2. In the console tree in the left pane, right-click Security and then select Clear All Events on the shortcut menu.
   
3. When the Event Viewer message box appears, click Yes to archive the existing entries in the security log prior to it being cleared; or click No to simply delete the existing entries in the log.
   
4. If you chose to archive the entries in the security log, enter a name and a file format for the log file.
   
5. Click Save.
   

How to archive a security log

1. Open Event Viewer.
   
2. In the console tree in the left pane, right-click Security and then select Save Log File on the shortcut menu.
   
3. Enter a name for the file and then enter a file format for the file.
   
4. Click Save.
   

Auditing Overview

Auditing enables you to determine which activities are occurring on your system and allows you to track access to objects, files and folders; and modifications made to the objects, files and folders. Auditing also enables you to collect information associated with resource access and usage on your system by allowing you to audit system logon, file access, and object access. Security auditing events are written to the Security log of the system and can be accessed from the Event Viewer tool. Because event logs grow over time and typically consume valuable disk space, you have to regularly delete event log entries contained in the Security log.

The types of events which you should audit are listed below:

• Computer logons and computer logoffs
  
• Access to objects, and files and folders
  
• System events.
  
• Performance of user and computer account management activities.
  

To prevent auditing from consuming valuable system resources, you should only audit events which are necessary, and audit access to confidential data. This is mainly due to the following characteristics of auditing:

• When auditing is enabled, auditing uses memory resources and processor resources.
  
• The audit log utilizes hard disk space.
  
• Sorting through huge amounts of logged audited entries can be a cumbersome and time-consuming task.
  

As mentioned previously, events that are audited are written to the Security log. You can use the Event Viewer tool to view information on these events.

An audit entry in Event Viewer contains the following information

• Event Type: Error, Warning, or Information, and Success Audit or Failure Audit
  
• Date and time when the event occurred.
  
• Software or program which logged the event.
  
• User which carried out the activity which caused the event being logged.
  
• Computer on which the activity was done
  
• Event ID
  
• Event Description
  

Event Viewer allows you to perform the following actions on the Security log entries which it stores:

• View events
  
• Sort events by type and time.
  
• Filter events
  
• View and analyze advanced event log information.
  
• Connect to the Event Viewer tool of a remote computer.
  
• Export the file to a .TXT, .CSV, or .EVT file
  

The activities which you need to perform to implement auditing are listed here:

• You need to determine and enable the event categories that you want to audit. The different event categories that you can audit are listed here:
  
  • Account logon events
    
  • Account management
    
  • Directory service access
    
  • Logon events
    
  • Object access
    
  • Policy change
    
  • Privilege use
    
  • Process tracking
    
  • System events
    
• You need to define the objects that should be audited.
  
• You need to specify the actions which should be logged in the audit log. You can audit:
  
  • Successes only
    
  • Failure only
    
  • Successes and Failures
    
• You need to configure the size for the audit log.
  
• You need to determine whether auditing will be implemented for the following:
  
  • Local computer
    
  • Domain controller
    
  • Active Directory domain
    
  • Organization unit (OU)
    

How to enable auditing for the local computer

1. Click Start, Administrative Tools, and then click Local Security Policy.
   
2. In the left pane, in Security Settings, expand Local Polices.
   
3. Click Audit Policy.
   
4. In the details pane, right-click the particular event category which you want to audit and then select Properties from the shortcut menu.
   
5. The Properties dialog box of the event category opens.
   
6. Select one or both of the following options: Success, Failure.
   
7. Click OK.
   

How to enable auditing for a domain controller

1. Click Start, Administrative Tools, and then click Active Directory Users And Computers.
   
2. In the left console pane, right-click the Domain Controllers OU, and then select Properties from the shortcut menu.
   
3. Click the Group Policy tab.
   
4. You can add a new policy, or choose an existing policy. Click Edit.
   
5. In the Group Policy Object Editor console, in the left console tree, expand Computer Configuration, Windows Settings, Security Settings, Local Policies and then expand Audit Policy.
   
6. In the details pane, right-click the particular event category which you want to audit; and then select Properties from the shortcut menu.
   
7. When the Properties dialog box of the event category opens, select one or both of the following options: Success, Failure
   
8. Click OK.
   

How to enable auditing for an Active Directory domain or organizational unit

1. Click Start, Administrative Tools, and then click Active Directory Users And Computers.
   
2. Right-click the domain or OU for which you want to configure auditing and then select Properties from the shortcut menu.
   
3. Click the Group Policy tab, add a new policy, and click Edit
   
4. In the Group Policy Object Editor expand Computer Configuration, Windows Settings, Security Settings, Local Policies and then expand Audit Policy
   
5. Right-click the particular event category which you want to audit; and then select Properties from the shortcut menu.
   
6. Select one or both of the following options: Success, Failure
   
7. Click OK.
   

How to enable auditing for objects stored in Active Directory

Before you can implement auditing for Active Directory objects, you have to first enable the Audit Directory Service Access option

1. Click Start, Administrative Tools, and then click Active Directory Users And Computers.
   
2. Click the View menu item and verify that Advanced features are enabled.
   
3. Select the Active Directory object which you want to configure auditing for.
   
4. Click the Action menu and then select Properties.
   
5. Click the Security tab when the Properties dialog box of the object opens.
   
6. Click Advanced
   
7. The Advanced Security Settings dialog box for the Active Directory object opens.
   
8. Click the Auditing tab.
   
9. Click Add
   
10. Specify the users or groups for which you want to audit object access.
    
11. Click OK.
    
12. When the Auditing Entry For dialog box opens, select the event(s) that you want to audit by choosing either one of, or both of the following options: Successful, Failed; alongside the particular event(s).
    
13. Use the Apply Onto list box to specify where the auditing should occur.
    
14. Click OK.
    

How to enable auditing for files and folders

1. Open Windows Explorer.
   
2. Right-click the file or folder which you want to configure auditing for, and then select Properties from the shortcut menu.
   
3. Click the Security tab.
   
4. Click the Advanced button.
   
5. Click the Auditing tab on the Advanced Security Settings dialog box.
   
6. Click Add.
   
7. Specify the users or groups for which you want to audit file or folder access. Click OK.
   
8. Select the events that you want to audit by checking either the Successful option, Failed option, or both of these options alongside the particular event(s).
   
9. Click OK.
   

How to enable auditing for printers

1. Click Start, and then select Printers And Faxes.
   
2. When the Printers And Faxes system folder opens, right-click the printer which you want to configure auditing for, and then select Properties from the shortcut menu.
   
3. Click the Security tab
   
4. Click the Advanced button
   
5. Click the Auditing tab on the Advanced Security Settings dialog box of the printer.
   
6. Click Add.
   
7. Specify the users or groups for which you want to audit printer access. Click OK.
   
8. Select the events that you want to audit by checking either the Successful option, Failed option, or both of these options alongside the particular event(s).
   
9. Use the Apply Onto list box to specify the location where auditing should occur.
   
10. Click OK.
    

How to view Security log information in Event Viewer

1. Open Event Viewer.
   
2. In the left pane, click Security.
   
3. The details pane is populated with all events that exist in the Security log.
   
4. You can double-click on an event entry to view its properties.
   

How to configure the size of the Security log

1. Open Event Viewer.
   
2. In the left pane, right-click Security and then select Properties on the shortcut menu.
   
3. The Security Properties dialog box opens.
   
4. On the General tab, enter the maximum log file size in the Maximum Log Size field. You can specify a value from 64 KB to 4,194,240 KB for the maximum log file size.
   
5. In the When Maximum Log File Size Is Reached area, there are a number of options which you can choose.
   
6. Select the Overwrite Events As Needed option if you want the oldest events in the Security log replaced by newer events which are logged.
   
7. Select the Overwrite Events Older Than _ Days option if you want to specify the time duration after which events should be removed.
   
8. Select the Do Not Overwrite Events (Clear Log Manually) option if you want to manually clear events.
   
9. Click OK.
   

How to find specific audited events in the Security log

1. Open Event Viewer.
   
2. In the left pane, click Security.
   
3. Click the View menu, and then click the Find option.
   
4. The Find In dialog box for the Security log opens.
   
5. In the Event Types area of the Find In dialog box, specify the types of the event which you want to find.
   
6. In the Event Source list, select the source that logged the event(s) which you want to find.
   
7. In the Category list, select the event category.
   
8. In the Event ID box, provide the event identity number.
   
9. In the User box, provide the user name.
   
10. In the Computer box, provide the computer name.
    
11. In the Description box, provide an event description.
    
12. In the Search Direction section of the Find In dialog box, set how the security log should be searched. The search can be performed from bottom to top or from top to bottom.
    
13. Click the Find Next button
    
14. The security log is searched, based on the search criteria that were defined.
    
15. All events that are matched are highlighted.
    
16. You can click Find Next to continue searching the security log for events which match your search criteria.
    
17. Click the Close button to stop the search.
    

How to manually remove entries from the Security log

1. Open Event Viewer.
   
2. In the left pane, right-click Security and then select the Clear All Events command on the shortcut menu.
   
3. The Event Viewer message box opens.
   
4. Click Yes if you want to archive the existing entries in the Security log before it is deleted. You have to specify a name and a file format.
   
5. Click No to delete the existing entries in the log.
   

What is Group Policy

Group Policy is an Active Directory feature that provides the means for you to effectively and efficiently manage large numbers of computers. You can manage both user and computer configuration settings centrally, from one position of administration. You can define group policies as being a collection of user and computer configuration settings which you can link to the following components:

• Computers
  
• Sites
  
• Domains
  
• Organizational Units (OUs)
  

Once linked, Group Policy defines the manner in which the operating system, network resources, and applications and programs operate for users within the organization. In other words, group policies define the behaviour of the desktops of users.

You can use Group Policy for the following administrative operations:

• Through group policies, you can define and configure scripts that run at:
  
  • Computer startup
    
  • Computer shutdown
    
  • User logon
    
  • User logoff
    
• To change Registry settings
  
• To deploy and manage programs and applications
  
• To establish domain password and account policies
  
• To redirect system folders
  
• To enforce software distribution and installation
  

You can define policies that behave differently for a computer, and a user:

• You can define group policies that affect a computer, irrespective of the particular user logging on to the computer. For instance, you can through a policy, configure the proxy server settings for a computer.
  
• You can define group policies that affect a user, irrespective of the computer which the user utilizes to log on to the system. For instance, you can use group policies to specify the applications or programs which are available to the user, and the programs which should exist on the user's desktop.
  Group Policy settings can therefore apply to the following types of Active Directory objects:
  
• User objects
  
• Computer objects
  

Because users and computers in Active Directory can be located in groups, and categorized in Organizational Units (OUs), using group policies can simplify the management of thousands of computers.

You can also define policies that affects resources connected to a particular computer (local policy), or you can define policies that affect the Active Directory directory (non-local policies).

You need to be familiar with, and understand the concepts that affect Group Policy operations, the different components of Group Policy, and the terminology used with Group Policy in order to implement it within your organization. The remainder of this Article focuses on this.

Understanding Group Policy Objects (GPOs)

A group policy object (GPO) is an Active Directory object which contains one or more Group Policy settings which affect the configuration settings for users or computers. A GPO acts as a container for the settings configured in Group Policy files. The Active Directory components that can be linked to a GPO are computers, sites, domains, organizational units (OUs). By linking a GPO to sites, domains, and OU actually applies the GPO settings to any user or computer objects within that particular container.

As already mentioned, a GPO can be thought of as being a container that contains Group Policy settings. The GPO identifies the following components of Group Policy:

• Group Policy Template (GPT): A GPT contains a set of instructions which implements a group of policies. GPTs are located in policy folders, and stored in the SYSVOL of domain controllers.
  
• Group Policy Container (GPC): This is an Active Directory object that contains the names of the Group Policy Templates (GPTs) connected to a specific GPO.
  

An important Group Policy concept is that Group Policy settings are hierarchical. What this means is that it can be lined and applied at different levels, as illustrated below:

• Sites: You can define GPOs, and link it to an entire site in Active Directory. The GPOs would then apply to each domain and server that belongs to the particular site. If the site contains multiple domains, the GPOs are applied to all the domains within the site.
  
• Domains: When you define GPOs, and link it to a particular domain in Active Directory, it is applied to all Computer objects and User objects that belong to, or are stored within that particular domain.
  
• Organizational Units (OUs): As is the case with the other two levels at which you can link and apply GPOs, you can define and link GPOs to a specific OU in Active Directory. The GPOs are then applied to all Active Directory objects stored within the particular OU.
  

When determining the manner in which Group Policy settings are hierarchically applied, remember the following: All computers and users located beneath the container that the GPO is linked to, is automatically within the scope of the particular GPO. They will therefore be affected by each and every Group Policy setting specified in the GPO.

This makes it possible for a user or computer to fall within the scope of numerous GPOs linked to a site, domains, and OUs. The concept, Resultant Set of Policies (RSoP), refers to the total impact of the policies in the GPOs on the user or computer.

GPOs can be grouped into the categories listed below. The category into which a GPO falls is determined by the location at which the Group Policy settings originated.

• Local GPOs: A local GPO is stored on a computer, whether it is a member server, or a workstation. Each computer running Windows Server 2003 has a local GPO. A local GPO applies only to the particular computer, and relates to activities on that particular computer. For computers that are part of Active Directory, the local GPO is lower-ranking than nonlocal GPOs. This basically means that in cases where the computer belongs to Active Directory, the local GPO settings can be overridden by nonlocal GPO settings. The local GPO is located in the Systemroot%System32GroupPolicy folder. Nodes that are located beneath Security Settings can be configured for local GPOs.
  
• Nonlocal GPOs: In addition to a computer running Windows Server 2003 having one local GPO, the computer can fall within the scope of numerous nonlocal GPOs. Nonlocal GPOs are also called Active Directory based GPOs. All nonlocal GPOs are defined in Active Directory and have to be linked to a site, domain or OU. Once linked, it is applied to User objects and Computer objects. Nonlocal GPOs therefore affect Active Directory objects, and are executed or carried out whenever the particular object is active. Nonlocal GPOs are located under %Systemroot%SysvolDomain NamePoliciesGPO GUIDAdm. The GPO GUID represents the Global Unique Identifier (GUID) of the GPO. Because nonlocal GPOs are created in Active Directory, are linked to sites, domains, or OUs; and are applied to User objects or Computer objects, a Windows 2000 or Windows Server 2003 domain controller has to be installed before you can use nonlocal GPOs. When the Active Directory directory service is installed, the following Nonlocal GPOs are automatically created:
  
  • Default Domain Policy: The Default Domain Policy is linked to the domain. This GPO impacts users and computers that are part of the domain using Group Policy inheritance.
    
  • Default Domain Controllers Policy: The Default Domain Controllers Policy is linked to the Domain Controllers OU. The GPO only impacts domain controllers.
    

You define one of the following policy types:

• User policies, which are applied when the user logs on. These policies determine the manner in which User objects operate within the network.
  
• Computer policies, which are applied to computers running in Active Directory. These policies determine the manner in which Computer objects operates within the network.
  

Group Policy settings in the GPO are regarded as being cumulative and hierarchical in nature. When a GPO is applied to a site, the GPO is applied to all computers within the site. This is because Active Directory directory information is replicated as follows:

• To all domain controllers in the site.
  
• To all domain controllers in sites where a site link has been created.
  

Where a domain level GPO, and OU level GPO applies to the same users, the settings of both GPOs are applied to the user. GPOs are by default cumulative and inherited. You can though configure the following options which either blocks inheritance or forces inheritance, at the different levels to which the GPO is linked:

• Force Policy Inheritance: This option is used to set inheritance properties on parent objects. Any child objects located beneath the parent object, automatically inherit Group Policy settings linked to the parent object.
  
• Block Policy Inheritance: This option can be used to explicitly define that the Group Policy settings of an object are not inherited from its associated parent object(s).
  

To configure and manage policy settings in GPOs, and link GPOs to computers, sites, domains and organizational units (OUs), Windows Server 2003 provides the following set of management tools:

• The Active Directory Users And Computers (ADUC) console
  
• The Group Policy Management console
  
• The Group Policy Object Editor
  
• The Resultant Set Of Policy snap-in
  

The Group Policy Object Editor is the tool used to manage and define the Group Policy settings in each GPO. You can use the Group Policy Object Editor to examine the Group Policy settings for a GPO.

You can use the steps below to open the Microsoft Management Console (MMC) for the local GPO.

1. Proceed to open the Microsoft Management Console.
   
2. On the Menu bar, click File and select Add/Remove Snap-In.
   
3. When the Add/Remove Snap-In dialog box opens, click the Add button on the Standalone tab.
   
4. On the Add Standalone Snap-In dialog box, select Group Policy Object Editor. Click Add.
   
5. On the Select Group Policy Object dialog box, in the Group Policy Object box, verify that Local Computer is listed.
   
6. Click Finish.
   
7. Click Close on the Add Standalone Snap-In dialog box.
   
8. Click OK on the Add/Remove Snap-In dialog box.
   

You can perform the following management tasks for GPOs:

• Create a GPO: You would use the Active Directory Sites And Services console to create a GPO and link it to a site. You would use the Active Directory Users And Computers console to create a GPO and link the GPO to a domain or OU. You can also use the Group Policy Management console to create GPOs and link them to sites, domains, or OUs.
  
• Link GPOs to a site, domain or OU: You can view and manage GPO links on the Group Policy tab of the Properties dialog box of the particular site, domain, or OU. Computer policies affect computers in the particular site, domain, or OU to which the GPO is linked. User policies affect users in the particular site, domain, or OU to which the GPO is linked. You can also use the Group Policy Management console to manage GPO links.
  
• Edit existing GPOs: To edit existing GPOs, you have to actually open the Group Policy Object Editor with the existing GPO as the focal point. To do this:
  
  • For sites, use the Active Directory Sites And Services console, open the Properties of the particular site, click the Group Policy tab and then click the Edit.
    
  • For domains and OU, use the Active Directory Users and Computers console, open the Properties of the particular domain or OU, click the Group Policy tab and then click Edit.
    
  • If you are using the Group Policy Management console, right-click the existing GPO which you want to edit, and then select Edit on the shortcut menu.
    

Group Policy Settings

In Active Directory, Group Policy settings are held within a Group Policy object (GPO). A GPO has a globally unique identifier (GUID) attribute that identifies it within Active Directory. As mentioned previously, you can use the Group Policy Object Editor to examine the Group Policy settings for a GPO. The types of Group Policy settings that exist are categorized into user configuration settings and computer configuration settings. The computer configuration settings are stored in the Computer Configuration node and user configuration settings are stored in the User Configuration.

• Computer Configuration node: This node contains configuration settings which are applied to the computer when the operating system starts. The user logging on to the computer does not affect the execution of these group policies.
  
• User Configuration node: This node contains configuration settings which are applied when the user logs on to the computer. The computer being logged on to by the user does not affect the execution of these group policies.
  

Both the Computer Configuration and the User Configuration nodes contain the following nodes:

• Software Settings node, includes policy settings for installing, removing, or updating software on computers running in the network.
  

• Windows Settings node, includes policy settings for installing and connecting to the Windows operating system.
  

• Administrative Templates node, includes policy settings for the Registry.
  

Software Settings

By default, the Software Settings node under the Computer Configuration node and under the User Configuration node contains the Software Installation extension. This extension is for assisting with the configuration of software policy settings that define how software and applications are installed on computers. You can use software settings to deploy new applications to end users, and define a computer as the location for an application. Software settings defined under the User Configuration node can be used to make a specific application available to only a particular user, irrespective of the actual computer the user logs on to. Only the designated user would be able to view and execute the application. You can also use software policies to deploy new applications in the network, and make them accessible to users. You can control the default configuration for these applications as well.

Windows Settings

The Windows Settings node in the Computer Configuration node and in the User Configuration node contains the following:

• Scripts extension: You can define the following types of scripts:
  
  • In Computer Configuration: Startup and shutdown scripts execute when the computer starts, or shuts down
    
  • In User Configuration: Logon and logoff scripts execute when the user logs on or logs off the particular computer.
    
  When more than one script exists for a user or computer, logoff scripts are processed before shutdown scripts.
  
• Security Settings node: You can define the security levels assigned to a local GPO or nonlocal GPO.
  

The policy settings which you can define are determined by whether they are applied in the Computer Configuration node, or the User Configuration node.

• Account:
  
  • Location = Computer ConfigurationSecurity Settings node, includes policy settings for password settings and account lockout settings.
    
• Folder redirection:
  
  • Location = User ConfigurationSecurity Settings node, includes policy settings for redirecting particular user folders to other locations.
    
• Internet Explorer maintenance:
  
  • Location = User ConfigurationSecurity Settings node, includes connection settings user interface settings, and security zone settings; for changing the settings for Internet Explorer.
    
• Public Key policies:
  
  • Location = User Configuration Security Settings node, includes policy settings which are associated with the public key activities of users.
    
• Public Key policies:
  
  • Location = Computer ConfigurationSecurity Settings node, includes policy settings which are associated the public key activities of the system.
    

Administrative Templates

The policy settings that are contained in the Administrative Templates node of the Computer Configuration node and the User Configuration node are Registry based settings. Group Policy settings for user configuration are stored in the HKEY_CURRENT_USER (HKCU) registry key. Group Policy settings for computer configuration are stored in the HKEY_LOCAL_MACHINE (HKLM) registry key.

The Administrative templates node contains Group Policy settings for:

• Windows components, including Terminal Services, Windows Media Player, Internet Explorer, Windows update, and many more.
  
• User profiles
  
• Group policy
  
• Scripts
  
• Dial-up connections
  
• And many more different Group Policy settings for computer configuration and user configuration.
  

In fact, more than 500 Registry based Group Policy settings can be set under User Configuration. A few examples are Start Menu settings, Shared folder settings, Control Panel settings, and Desktop settings. The locations which contain a description on these Group Policy settings are listed below:

• The Administrative Templates Help feature is new in Windows Server 2003.
  
• Another new Windows Server 2003 feature, the Extended tab in the Group Policy Object Editor, offers information on each selected setting.
  
• The Explain tab in the Properties dialog box for the particular setting.
  

The Administrative templates node of both the User Configuration node and Computer Configuration node have the following nodes:

• Windows Components node: Includes Group Policy settings which can be used to manage Internet Explorer, Microsoft Windows Messenger, Terminal Services, Task Scheduler, and other Windows components.
  
• System node: Includes Group Policy settings for user profiles, Group Policy, scripts, and more Group Policy settings which are specific to either user configuration, or to computer configuration.
  
• Network node: Includes Group Policy settings for dial-up connections, and offline files, and other Group Policy settings which are specific to computer configuration.
  

Only the Administrative templates node located beneath the Computer Configuration node has a Printers node which contains Group Policy settings that can be set for printers. Only the Administrative templates node located beneath the User Configuration node has Start menu and task bar, desktop, Control Panel and shared folders nodes.

A Group Policy setting in the Administrative Templates node has one of the following states or settings:

• Not Configured
  
• Enabled
  
• Disabled
  

As previously mentioned, Group Policy settings for user configuration are stored in the HKEY_CURRENT_USER (HKCU) registry key, and Group Policy settings for computer configuration are stored in HKEY_LOCAL_MACHINE (HKLM) registry key. Each in turn stores Group Policy specific registry information in one of the following reserved trees:

• HKEY_CURRENT_USERSoftwarePolicies, for user policy settings.
  
• HKEY_LOCAL_MACHINESoftwarePolicies, for computer policy settings.
  
• HKEY_CURRENT_USERSoftwareMicrosoft WindowsCurrentVersionPolicies, for user settings.
  
• HKEY_LOCAL_MACHINESoftwareMicrosoft WindowsCurrentVersionPolicies; for computer settings.
  

What are Administrative Templates?

Administrative templates in Wndows 2000 and Windows Server 2003 are Unicode based text files that have a .adm file name extension. An administrative template can be defined as the text file which creates the user interface for the Group Policy settings which you can configure using the Group Policy Object Editor.

The three types of administrative templates which exist are:

• Default administrative templates: These are the administrative templates which are included in Windows Server 2003, and includes the following set of default administrative templates:
  
  • Conf.adm administrative template, includes NetMeeting settings for both Windows 2000 and Windows Server 2003 clients.
    
  • Inetres.adm administrative template, includes Internet Explorer settings for both Windows 2000, and Windows Server 2003 clients.
    
  • System.adm administrative template, includes system settings for Windows 2000 and Windows Server 2003 clients.
    
  • Wmplayer.adm administrative template, includes Windows Media Player settings for both Windows 2000 and Windows Server 2003 clients.
    
  • Wuau.adm administrative template, includes Windows Update settings for Windows 2000 and Windows Server 2003 clients.
    
• Vendor supplied administrative templates: These are administrative templates which are provided with software applications that can run on Windows Server 2003. These administrative templates usually need to be downloaded from a Web site, and then installed.
  
• Custom administrative templates: These types of administrative templates are usually created by application developers, using the .adm language, to exercise controller over user configuration and computer configuration.
  

Understanding the Group Policy Processing Sequence

The process listed below is executed when computer configuration settings and user configuration settings are applied at computer startup, and user log on.

1. When the network starts, the Remote Procedure Call System Service (RPCSS) and Multiple Universal Naming Convention Provider (MUP) are started.
   
2. Next, the list of GPOs is acquired for the computer.
   
3. The content of the GPO list is determined by whether the computer belongs to a Windows 2000 domain or Windows Server 2003 domain; and where in Active Directory the computer is actually located.
   
4. The computer configuration settings are processed first, and in this order:
   
   1. local GPO
      
   2. site GPOs
      
   3. domain GPOs
      
   4. OU GPOs
      
5. The startup scripts execute next, and in a particular sequence as well. This basically being that each script has to complete or alternatively timeout before the following script can be executed.
   
6. When the user finally logs on to the computer, and is authenticated, the user profile for the particular user is loaded. This is controlled by the Group Policy settings in use.
   
7. Next, the list of GPOs is acquired for the particular user logging on to the computer.
   
8. The content of the GPO list is determined by whether the user belongs to a Windows 2000 domain or Windows 2003 domain, whether loopback is enabled and the mode of this policy setting, where in Active Directory the user is actually located, and whether the list of GPOs that should be applied to the user has changed or not. The default configuration is that if the list has not since changed, no processing is performed. You can however change this.
   
9. The user configuration settings are processed next, and in this order:
   
   1. local GPO
      
   2. site GPOs
      
   3. domain GPOs
      
   4. OU GPOs
      
10. The logon scripts execute after this.
    
11. The user is displayed the user interface as defined by Group Policy.
    

Understanding the order in which Group Policy settings are processed

Nonlocal GPOs or Active Directory based GPOs are applied in a hierarchical manner. The end configuration of the user or compute is actually the result of the GPOs which are linked to a particular site, domain and OU.

Group policy settings are processed in the order specified below:

1. Local GPO: Recall from an earlier discussion, that each computer running Windows 2000 or Windows Server 2003 contains one GPO which is stored locally. Because the local GPO is applied first, it means that policies defined at the local computer have the least priority.
   
2. Site GPO: Site GPOs are GPOs which are linked to sites. The order of the different site GPOs are determined and defined by the Administrator.
   
3. Domain GPOs: Domain GPOs are applied next. These are GPOs which are linked to domains. Once again, when different domain GPOs are linked to the particular domain, their order is determined and defined by the Administrator. It is evident now that GPOs linked to a domain enjoy priority or precedence over site GPOs and local GPOs.
   
4. OU GPOs linked to the OU highest in the Active Directory hierarchy are applied before any other OUs.
   
5. OU GPOs linked to child OUs are applied next.
   
6. OU GPOs linked to the OU closest to the user or computer are then applied.
   
7. When the OU that contains the user or computer has a GPO linked to it; that GPO is applied last. You can see that OUs closest to, or which includes the user/computer have precedence over GPOs linked to OUs higher up the tree.
   

The order specified above is affected by the a few exceptions, which are noted below:

• If the computer is a member of a workgroup, only the local GPO is applied to the user or computer.
  
• When the No Override setting is enabled for a GPO which is linked to a site, domain or OU, no Group Policy settings contained in the particular GPO is overridden by other GPOs. Because of the hierarchical manner in which GPOs are applied, and there happens to be more than one GPO which has the No Override setting enabled, the GPO highest in the tree has precedence.
  
• Block Policy Inheritance can be explicitly specified for a site, domain or OU, and is not applied to any GPOs or GPO links. When enabled for a site, domain or OU; it prevents any Group Policy settings from passing down from higher up in the tree, to the particular site, domain or OU for which it is enabled. The only exception is that any GPO links which have the No Override settings enabled are not blocked, but are applied.
  
• The loopback setting: Loopback is a Group Policy setting which is useful for lab computers and terminal servers. Loopback enables you to configure alternatives to the default method of obtaining the list of GPOs for a user. You can configure the system to apply the User Configuration settings from GPOs which are linked to containers containing computer objects. The following states or settings can be enabled for Loopback:
  
  • Not Configured, Enabled, Disabled.
    
• Loopback can be enabled in the following modes:
  
  • Replace Mode: In this mode, the list of GPOs for a user is replaced by the GPO list acquired at computer startup.
    
  • Merge Mode: In this mode, the GPO list acquired when the computer started is added to the GPO list acquired at user log on. The GPO list acquired at computer startup is processed last.
    

Understanding Group Policy Inheritance

When discussing Group Policy, the concept of Inheritance signifies that Group Policy settings which affect user configuration and computer configuration are the resultant set of policies inherited from parent containers. Policies are usually passed down from a parent container to its associated child containers. The exception being that a Group Policy setting defined for a child OU overrides the same setting which it inherited from its parent OU.

A child OU does not inherit its parent OU policy settings in the following instances:

• When the policy settings of a parent OU are set to the Not Configured setting, no child OUs would inherit those settings. Policy settings that are Disabled are inherited as Disabled by child OUs.
  
• When a policy setting specified for a parent OU happens to be with the identical policy setting defined for the child OU, the child OU setting overrides the policy setting which it inherited from the parent OU.
  
• When the policy setting specified for a parent OU happens to be incompatible with the same policy configured for the child OU, the policy is not inherited by the child OU.
  

The ways in which Group Policy settings can be inherited are listed below:

• When the policy setting for a parent OU is set to Enabled or Disabled; and the child OU does not have the same policy setting configured, the child OUs inherits the policy setting of its parent OU.
  
• When a policy setting specified for a parent OU and a policy setting specified for a child OU are compatible, inheritance can take place. In this case, the child OU inherits the policy setting of the parent, and the policy setting configured for the child OU is applied as well.
  

Delegating Administrative Control of GPOs

Configuring the appropriate security settings on GPOs is important for the following reasons:

• When the security settings on the actual GPOs are not set correctly, both Administrators and users would be able to override them.
  
• When numerous Administrators create GPOs and edit existing GPOs, the management of GPOs can be intricate.
  

To simplify the management of Group Policy, you can delegate administrative control of the following administrative tasks:

• Creating GPOs: To delegate administrative control for creating GPOs, you have to include the specified user as a member of the Group Policy Creator Owners group. You would then delegate authority to the user to manage GPO linking to the site, domain or OU in which the user will be creating GPOs.
  
• Linking GPO: To delegate administrative control for linking GPOs, you need to specify the Manage Group Policy Links option which is made available through the Delegation Of Control Wizard for the particular domain or OU.
  
• Editing GPOs: To delegate administrative control for editing existing GPOs, you have to grant the Read and Write permission for the selected user.
  

Filtering Group Policies

As mentioned on numerous occasions throughout this Article, group policies are linked to sites, domains and OUs, and are then applied to user and computer objects, based on where they are located within Active Directory. Group policies are therefore never directly linked to security groups.

An option does though exist, whereby which you can apply a GPO to a designated security group(s) through a process known as filtering the GPO. When filtering the GPO, you can specify that it is only applicable when a user or computer is a member of the security group. You can define filtering as being the process by which certain security groups are either included or excluded from the Group Policy settings of the GPOs. This allows you to filter Group Policy to affect those computers and users which you set for being influenced by Group Policy. Because the Group Policy settings in a nonlocal or Active Directory based GPO is only relevant to users that have the Read (Allow) permission and Apply (Allow) permission for the GPO, you can set the necessary permissions for security groups to include only certain computers and users. When filtering Group Policy remember that the filter would only apply if the users in the security group are in the scope of the GPO.

Windows Management Instrumentation (WMI) is a management tool which Windows Server 2003 utilizes in a number of ways to monitor and manage network objects. WMI can be used to filter a GPO based on the results of a WQL query. This is a new Windows Server 2003 Group Policy feature. You cannot howeer filter individual elements of a GPO. You can also only choose one WMI filter for any specified GPO. When a WMI query is utilized to filter the scope of a GPO, the GPO is applied based on properties available in WMI that are located in the WMI query.

The WMI components are listed below:

• Managed Objects: The WMI technology gathers information from devices and applications such as hard drives, CPUs and network adapters.
  
• Common Information Model (CIM): WMI holds the information it gathered in the Common Information Model repository.
  
• Common Information Model Object Manager (CIMOM): The CIMOM processes this information, and interacts with any applications which need to have information stored in the CIM repository.
  
• WMI Query Language (WQL): The WMI query language (WQL) is used to compile WMI queries. The number of attributes which can be used in WMI queries are numerous.
  
• Event triggers: Group policies do not utilize WMI events
  

Resultant Set of Policies (RSoP)

Because, GPOs can be linked, blocked, filtered and its settings inherited; it can be quite a time consuming and complex task to determine which Group Policy settings are applied to a user or computer. Windows Server 2003 however includes the Resultant Set of Policy (RSoP) tool which simplifies group policy management. You can use the Resultant Set of Policy (RSoP) tool to determine what occurs with group policies when a particular user logs on to the computer.

Through RSoP, you can determine the following:

• Which GPOs are applied
  
• The level (site, domain, OU) at which they are applied
  
• Which GPOs are blocked
  

The tool can also be used to assist in the planning of a Group Policy implementation, and to troubleshoot Group Policy settings.