70-640 - Windows 2008 Active Directory

Microsoft Technologies: Windows 2008 Active Directory (70-640)
Romain LACOUR, SUPINFO Certified Trainer
http://www.supinfo.com
Microsoft Technologies: Windows 2008 Active Directory (70-640)

After this course, you will be able to manage following features of Windows Server 2008 : Active Directory Users and Computers
Active Directory Sites and replications
Active
Directory
Operations
Master
Chapter 1. Introduction to Active Directory Domain Services

In this lesson, you will see the Active Directory Domain Services basis. You will understand why it is very interesting to use AD DS in your network infrastructure. You will also see the AD DS structure with both logical and physical components. Module Overview
Overview of Active Directory Domain Services
Overview of AD DS Logical Components
Overview of AD DS Physical Components
AD DS Management Tools
1. Course
1.1. Overview of Active Directory Domain Services
Windows Server 2008 Active Directory Domain Services is a Windows-based directory service which provides a centralized management and authentication service for a network.
1.1.1. What is a directory service?

A network directory service:
Provides information about user objects, computers, and other network resources and services (such as an email address).
Stores all this information in a secure database and provides the tools for managing and searching the directory.
Allows you to manage all network user accounts and resources in a single location and apply policies to the directory objects to ensure that all are managed consistently. A directory service is both the directory information source and the service that makes the information avalaible and usable. This allows the service to provide information about the objects (users, groups, computers or services) as well as provide authentication and access to network resources.
1.1.2. How Does AD DS Work?

Active Directory Domain Services stores information about users, computers and network resources and makes the resources accessible to users and applications. It provides a consistent way to name, describe, locate, access, manage, and secure the information about these resources. 1. User and computer objects are created in the directory 3
2. Groups of these objects can then be created 3. A client can use the use account to authenticate against AD DS 4. The user can try to access network resources 5. The resources will again validate the authenticated user against AD DS
1.1.3. What Is LDAP?

Active Directory Domain Services is based on Lightweight Directory Access Protocol. LDAP is a standardized client/server TCP/IP based protocol that has been in use for over 15 years and is leveraged by a large number of applications and solutions. LDAP defines consistent ways for naming and storing directory objects. It also provides methods for accessing, searching, and modifying information that is stored in a directory. A directory is a set of objects with similar attributes organized in a logical and hierarchical manner. To be able to use AD DS correctly, you will need to understand some vocabulary used by LDAP. The relative distinguished name (RDN) of an object uniquely identifies the object in its own container. It is not possible to have two objects with the same RDN in the same container. The distinguished name (DN) is a unique identifier for each object in the directory. It means that two objects can't have the same DN in the directory. It is composed of the RDN of the object and the parent's DN. For example: you have the user account "Romain Lacour" within the "MSLab" organizational unit in the "supinfo.lan" domain.
DN: CN=Romain Lacour,OU=MSLab,DC=supinfo,DC=lan
CN is tthe Common Name of the object in its container. In this case, it is also the RDN.
4
OU is the organizational unit that contains the object. You can find more than one organizational unit level.
DC means Domain Component. It is used to represent parts of the domain name. You have at least two domain components but possibly more if you have child domains.
1.1.4. Why deploy Active Directory Domain Services?

AD DS provides a centralized system for managing users, computers, and other resources on a network. AD DS provides an intuitive, hierarchical view of the network and a single point of administration for all network objects. The centralized directory simplifies network administration by allowing management of all accounts in a single location. Most organizations today have multiple servers offering different services to users. If you don't have a common directory service, you will need to create user accounts on each server to allow users to access resources or services offered by these servers. With Active Directory Domain Services, each resource of service on the network will use the common directory service to provide authentication and authorization to users. AD DS can be easily configured to add additional servers and users within the same building as well as servers and users in other buildings, regions or countries. AD DS makes the physical network topology and protocols transparent. Users don't need to know where resources are located or which protocols to use to access them. You can manage AD DS very easily by using the Microsoft Management Console that provides all the tools to manage AD DS as all other Windows Server 2008 services. The largest cost of owning computers is the cost in managing and maintaining them. If systems were maintained individually, the cost would quickly become unacceptably high. AD DS provides a way to automate computer management using centrally applied settings. This allows for the most use of IT administrative resources.
1.2. Overview of AD DS Logical Components

As an AD DS administrator, you will spend most of your time working with the logical components that make up AD DS. During the implementation of AD DS, your organization will have configured various AD DS components such as domains, sites and organizational units. You will be working with these components as you create and manage user accounts or computer accounts.
1.2.1. The AD DS Schema

The AD DS schema defines every type of object that can be created and stored in the directory. Before you can create an object in AD, it must be defined in the schema. AD DS will know how to create an object by using the object definition in the schema. The schema also enforces a number of rules regarding the creation of objects in the database. These rules define the information that can be stored with each object and the data type of that information. The schema has two types of definitions:
Object classes define what kind of objects can be created in the directory. For example: user class or computer class.
Attributes are defined separately from object classes. They define what information can be stored for each object class. For example: display name, description, telephone number...
1.2.2. Domains
As the most basic logical unit in the AD DS infrastructure, domains are used to group and manage the AD DS objects in an organization.
5
Domains provide:
An administrative boundary for applying policies to groups of objects
A replication boundary for replicating data between domain controllers
An authentication and authorization boundary that provides a way to limit the scope of access to resources.
Each domain must have at least one domain controller installed. In fact, you create a domain by installing the first domain controller in the domain, and you remove a domain by removing the last domain controller in the domain. To install a domain controller on Windows Server 2008, you have to run the following command:
Example 1.1. Domain Controller Promotion

dcpromo
1.2.3. Trusts
Trusts provide a way for users to gain access to resources in another domain. Domains can allow secure access to shared resources for users coming from others domains using authenticated connections called trusts. Trusts enable users to:
Access resources in domains other than the domain where their user account is configured.
Log on to computers that are members of domains other than the domain where their user account is configured. When you configure a trust you have two options:
Direction: The trust direction flows from trusted domain to the trusting domain.
Transitivity: The trust relationship is extended beyond a two domain trust to include other trusted domains. For example: If domain A trusts domain B, and domain B trusts domain C, so domain A trusts domain C.
6
By default, trust relationships are created between all domains in a forest. It mean all domains in a forest trust all other domains in this forest.You can create trusts for domains outside the forest.
1.2.4. Domain Trees

A domain tree is a hierarchy of domains in AD DS. The first domain created is the root domain. When you add subsequent domains to the tree, they become a child domains under the tree root domain. The domain to which the child is attached is called the parent domain. Within a domain tree, all domains share a common or contiguous namespace. It means that all domains have a part of their name in common. Domains are named using the Domain Name System (DNS), that's why DNS is a prerequisite concerning AD DS. For example, if the root domain is supinfo.lan, the child domains will use names such as paris.supinfo.lan.
All domains in the domain tree:
Have a contiguous namespace with the parent domain
Can have additional child domains added to the namespace
Child domains have a two-way transitive trust with their parent domain (called a parent/child trust)
1.2.5. Forests
A forest is a collection of one or more domain trees. All domains and domain trees can only exist within an Active Directory forest. A forest is created when you install the first domain in the forest. The first domain of a forest is called the forest root domain. Bye default the information in Active Directory is shared only between domains in the forest. This way, the forest is a security boundary for the information stored in the Active Directory instance. Some forest specifications:
Share a common schema between all domains in the forest
7
Share a common configuration partition
Share a common global catalog to enable searching
Enable trusts between all domains in the forest
Share the Enterprise Admins and Schema Admins group By default, in a forest, all domains are trusting each other. A two-way transitive trust is created between each domain tree and the forest root domain. (called the tree/root trust)
1.2.6. Organizational Units

Organizational Units (OUs) are container objects used to organize other objects in your domains. OUs can contain users, groups, computers, and others OUs. They are designed to make AD DS easier to administer. By ordering objects into organizational units, it will be easier to locate and manage these objects. We can compare OUs to folders on your hard drive. To arrange your files on your hard drive, you create folder with explicite names and like this, it is easier for you to find your files or to work on them. In your AD DS domain, you will create Organizational Units to put your user, group, or computer accounts to be able to manage them more easily. OUs are used to:
Represent your organization hierarchically and logically
Manage a collection of objects in a consistent way
Delegate permissions to administer groups of objects
Apply policies
8
1.2.7. AD DS Objects
AD DS objects are entities created on AD DS domain controllers. They represent resources (printers), services (shared folders) or users (both individuals and groups). Each object has its definition and attributes in the Active Directory schema. This makes creating and administering new instances of a particular type of object very efficient.
Table 1.1. AD DS Objects

User Enables network resource access for a user InetOrgPerson Similar to a user account
Used for compatibility with other directory services Contacts Used primarily to assign e-mail addresses to external users
Does not enable network access Groups Used to simplify the administration of access control Computers Enables authentication and auditing for computer access to resources Printers Used to simplify the process of locating and connecting to printers Shared folders Enables users to search for shared folders based on properties
1.3. Overview of AD DS Physical Components

AD DS information is stored in a single database on the domain controllers hard disk. If a domain or forest has more than one domain controller, the AD DS data is replicated regularly to each domain controller. This part describes the physical components that make up AD DS and provides an overview of how replication works. The physical structure of Active Directory Domain Services optimizes network traffic. To optimize Active
9
Directory's use of network bandwith, you need to understand the physical structure.
1.3.1. AD DS Domain Controllers

Domain Controllers are servers running Windows Server 2008, Windows Server 2003, or Windows 2000 Server with the Active Directory role installed. On Windows Server 2008, this role is called Active Directory Domain Services (AD DS). A domain controller is a server in an AD DS domain that provides directory services. In AD DS, we are in what we call a multi-master structure, it means all domains controllers (except Read-Only Domain Controllers) store a writable copy of the AD DS database. A domain controller can manage only one domain.To ensure continuous availability of the directory service, each domain should have more than one domain controller to be sure that there is always one domain controller available. Domain controllers participate in the process of authentication and authorization when users want to access network resources in the domain or when they log on a computer which is a member of the domain. They are also involved in the replication process of the AD DS database. We said that all domain controllers have a writable copy of the database, it means an administrator can perform changes on any domain controller. To be sure that all domain controllers have the same information, domain controllers will replicate changes to other domain controllers in their domain.
1.3.2. DNS and AD DS

AD DS is entirely based on the Domain Name System (DNS) to locate resources on the network. We already saw in part 1.2.4 that AD DS domain names must use DNS domain names. That's why AD DS cannot work correctly without a reliable DNS infrastructure. Without a correctly configured DNS infrastructure, domain controllers will not be able to replicate data with each other, workstations will not be able to log on to the network, and users will not be able to access network resources in the domain.
1.3.3. Global Catalog Servers

Global Catalog Servers are domain controllers, so they store a full copy of all objects in the directory of their own domain,but they also store a copy of the global catalog. The global catalog contains a copy of all objects in a forest but that includes only some of the attributes for each object in the forest. So a global catalog server has the full information on objects of its own domain, and additionally it stores a partial copy of all objects for all other domains in the forest. The global catalog is mainly used in search operations. Searches are more efficient when a domain controller stores information for other domains in the forest, it avoids performing request on other domain controllers.
10
The global catalog is also required for user logon process on to a domain and access to domain resources.
1.3.4. AD DS Data Store

All the data in AD DS is stored in a single file on domain controllers. This file is named Ntds.dit and by default it is stored in %SystemRoot%\Ntds. You can change this location during the domain controller promotion process. This folder contains the database and database log files. The AD DS data store is accessible only through the domain controller processer and protocols.
1.3.5. AD DS Replication
AD DS replication is the process used to copy all changes on the AD DS database to all other domain controllers in a domain or forest. It is used to ensure that all domain controllers have the same information, as you can perform changes on any domain controller (except Read-Only Domain Controllers). When you modify an information in the AD DS database on a domain controller, (for example: you create a new user account), automatically, this domain controller will send the modification to all other domain controllers concerned by this modification. (domain controllers of the same domain in our example) The replication topology is automatically generated as new domain controllers are added to the domain, and this topology is verified regularly. Summary of AD DS replication:
Ensures that all domain controllers have the same information
Uses a multi-master replication model (changes can be made on any domain controller, except RODCs)
Can be managed by creating AD DS sites
1.3.6. AD DS Sites
AD DS sites are used to represent your physical network. Indeed, many organizations have offices in different cities or countries and their network is divided in different geographical locations. In general, these offices are connected by WAN connections to be able to connect the different local networks. So we will use AD DS sites to represent a network segment where all domain controllers are connected by a fast and reliable network connection. AD DS sites will be connected to each other using site links. Sites are:
Associated with IP subnets
Used to manage replication traffic
Used to manage client logon traffic
Used by site aware applications such as Distributed File System (DFS) or Exchange Server 2007
11
Used to assign group policy objects to all users and computers in a company location
1.4. AD DS Management Tools

There are a lot of different tools to manage the different AD DS features. Here is a list of the main tools:
Active Directory Users and Computers: A Microsoft Management Console (MMC) that is used to manage and publish information in Active Directory. You can manage user, group, and computer accounts, organizational units, add computers to a domain, manage account policies, user rights, and audit policy.
Active Directory Sites and Services: An MMC that is used to manage the physical structure. You can create and manage sites, site links, subnets, and the replication process.
Active Directory Domains and Trusts: An MMC that is used to manage domain trusts and forest trusts, add user principal name suffixes, and change the domain and forest functional levels.
Active Directory Schema: An MMC that is used to manage the schema. It is not available by default in the Administrative Tools menu. You must register a DLL to be able to use it. You have to run "regsvr32 schmmgmt.dll" command.
Dsadd, dsmod, dsrm, dsget, dsquery, dsmove : With these command-line tools you can create, modify or delete objects such as computers, servers, users, groups, organizational units, and contacts.
Ldifde : Command-line tool used to create, modify, and delete AD DS objects. Can also extend the AD DS schema, export users and groups information to other applications or services, and populate AD DS with data from other directory services.
Csvde : Command-line tool used to import and export AD DS data by using comma-separated files.
WSH: WSH for Windows Scripts Host. Scripting environment to run Visual Basic Scripts (VBS) for example.
12
Chapter 2. Implementing Active Directory Domain Services

In this module, you will see what are the different hardware and software requirements for implementing Active Directory Domain Services, and the process of installing it. Then, you will also see what is a red-only domain controller (RODC) and how to install it. Finally, you will see the different domain controller roles. Module Overview
Installing Active Directory Domain Services
Deploying Read-Only Domain Controllers
Configuring Active Directory Domain Services Controller Roles
1. Course
1.1. Installing Active Directory Domain Services
Active Directory Domain Services is a server role in Microsoft Windows Server 2008. When you decide to install AD DS, you have several choices. You can choose to create a new domain, for a new forest or an existing one, or add a domain controller to an existing domain. You can also install AD DS on Windows Server 2008 Server Core or install a read-only domain controller. This lesson will describe the different ways to install Active Directory.
1.1.1. Requirements for Installing AD DS

Before installing AD DS, you must ensure that the server you want to promote meets some prerequisites, concerning the hardware and the software. In addition, you remember that you need a DNS infrastructure on the network, accessible by domain controllers to support integration with Active Directory. You can install AD DS only on servers running the following Windows Server 208 editions:
Windows Server 2008, Standard Edition
Windows Server 2008, Enterprise Edition
WIndows Server 2008, Datacenter Edition Here are the different requirements for installing AD DS:
Minimum disk space of 250 MB and a partition formatted with NTFS: 200 MB for the AD DS database and 50 Mb for the AD DS database log files. File size requirements depend on the number and type of objects in the domain. Additinal disk space can required if the domain controller is also a global catalog server.
TCP/IP must be configured, including DNS client settings
13
Created by XMLmind
XSL-FO Converter.
DNS Server that supports dynamic updates must be available or will be configured on the domain controller
Local Administrator permissions to install the first domain controller in a forest
Domain Administrator permissions to install additional domain controllers in a domain
Enterprise Administrator permission to install additional domains in a forest
1.1.2. What are Domain and Forest functional Levels

Depending on the AD DS installation you choose, you can have to select the domain and forest functionnal levels, that is why you need to understand what it is. Functional levels are used to keep compatibility with older versions of Active Directory. The first version of Active Directory as we know it in the present, appeared with Windows 2000. After you have the version on Windows Server 2003 that brings new features and then now, you have the version on Windows Server 2008 with its new features. To allow domain controllers running Windows 2000, Windows Server 2003 and Windows Server 2008 to work together in a domain or forest, they need to use the same features and the same language. That's why, you will use features of the Windows 2000 Active Directory version. So the different domain and forest functional levels will determine the AD DS features available in a domain or forest and it will restrict which Windows Server operating system can be promoted as a domain controller in the domain or forest.
Table 2.1. Supported functional levels

Domain Windows 2000 Native Windows Server 2008 Supported Domain Controller Operating Systems Forests Windows 2000
Windows Server 2003
Windows 2000 Windows Server 2003 Windows Server 2008 Windows Server 2003
Windows Server 2003 Windows Server 2008 Windows Server 2008 Domain functional levels enable features accros the domain. Windows Server 2008
Table 2.2. Domain functional level features

Domain functional level Windows 2000 Native Universal groups are enabled for both distribution and security groups. Enabled features All default Active Directory features and the following features:
14
Created by XMLmind
XSL-FO Converter.
Group nesting.
Group conversion is enabled. It means you can convert a security group in a distribution group and the reverse.
Secutiry Identifier (SID) History. Special attribute used to keep the old SID of an object when migrated between domains. All default Active Directory features, all Windows 2000 Native functional level features, and the following features:
The availability of the domain management tool, netdom.exe, to be able to rename domain controllers.
Update of the logon time stamp. The lastLogonTimestamp attribute will be updated with the last logon time of the user or computer.
The ability to set the userPassword attribute as the effective password on inetOrgPerson and user objects. Windows Server 2003 The ability to redirect Users and Computers container. By default, these two containers are provided to store user and computer accounts. This feature makes it possible the definition of a new location for these accounts.
Includes constrained delegation so that applications can take advantage of the secure delegation of user credentials by means of the Kerberos authentication protocol.
Supports selective authentication. It is possible to specify the users and groups from a trusted forest who are allowed to authenticate to resource servers in a trusting forest. All previous features and the following features:
Distributed File System Replication (DFSR) support for SYSVOL, which provides more reliable replication of SYSVOL contents.
Windows Server 2008
Advanced Encryption Services (AES 128 and 256) for the Kerberos protocol.
Last Interactive Logon Information. It displays the time of the last successful interfactive logon for a user, from which computer, and the number of failed logon attempts since the last logon.
Fine-grained password policies (FGPP). It allows to specify password and account lockout policies for users and global security groups in a domain. 15
Created by XMLmind
XSL-FO Converter.
With this feature, you can have multiple password policies in a domain, which was not possible by default before. Forest functional levels enable features accros all domains within the forest.
Table 2.3. Forest functional level features

Forest functional level Windows 2000 Enabled features All default Active Directory features. All default Active Directory features, and the following features:
Forest trusts. You can create a trust between two forests.
Domain renaming.
Linked-value attribute replication. For example, you modify the membership list of a group, only the values modified will be replicated instead of replicating the entire membership list. This results in lower bandwidth and processor usage during replication. Windows Server 2003 The ability to deploy a Read-Only Domain Controller (RODC) that runs Windows Server 2008.
Improved Knowledge Consistency Checker (KCC) algorithms and scalability.
Improved ISTG algorithm
The ability to convert an inetOrgPerson object instance to a User object instance, and the reverse. Windows Server 2008 No additional features but all domain controllers that are added to the forest will operate at a Windows Server 2008 domain functional level by default.
1.1.3. AD DS Installation Process

To install Active Directory Domain Services on Windows Server 2008, you have two options:
Install the AD DS role by using the Server Manager console, and run the Active Directory Installation Wizard by running DCPromo or by using Server Manager too.
Run DCPromo from the Run command or a command prompt. This automatically install the AD DS server role and then launch the Active Directory Installation Wizard. The installation process contains the following steps:
Install the Active Directory Domain Services role using Server Manager
Run the Active Directory Domain Services Installation Wizard
16
Created by XMLmind
XSL-FO Converter.
Choose the deployment configuration (new domain in new forest, new domain in existing forest, add a domain controller to an existing domain...)
Select the additional domain controllers features (DNS Server, Global Catalog Server, Read-Only Domain Controller)
Select the location for the database, log files, and SYSVOL folder
Configure the Directory Services Restore Mode Administrator Password
1.1.4. Advanced Options for Installing AD DS

For some specific options concerning the AD DS installation, you will need to use the advanced mode installation. To launch this mode you have two different options:
You can select the Use advanced mode installation check box in the Active Directory Domain Services Installation Wizard Welcome page.
You can run the DCPromo /adv command in the Run command or a Command Prompt. Here are the different options you can find in advanced mode:
Create a new domain tree
Use backup media as the source for AD DS installation
Select the source domain controller for replication during installation
Modify the default domain NetBIOS name
Define the Password Replication Policy when installing an RODC
1.1.5. Installing AD DS from Media

Before you can use backup media as the source for a domain controller promotion, you have to use Ntdsutil.exe to create the installation media. You can use Ntdsutil.exe to create installation media for additional domain controllers that you are creating in a domain. By installing from media, you can minimize the replication of directory data over the network. This helps you install additional domain controllers in remote sites more efficiently. To create installation media for a full (or writable) domain controller, you must run the ntdsutil ifm command on a writable domain controller. To create installation media for an RODC, you can run the ntdsutil ifm command on either a writable domain controller or an RODC that runs Windows Server 2008. For RODC installation media, ntdsutil removes any cached secrets, such as passwords.
Table 2.4. Installation media

17
Created by XMLmind
XSL-FO Converter.
Types of installation media Writable domain controller
Parameter Create full %s
Description Creates installation media for a writable domain controller into folder %s Create installation media for an RODC into folder %s
Read-only domain controller
Create RODC %s
To create installation media, you must be able to log on to a domain controller interactively and be able to make a backup. Here is an example of how to create an installation media. First you have to launch a Command Prompt with the Administrator privileges.
Example 2.1. Installation Media Creation

[CODE:dos]C:\Users\Username.DomainName>ntdsutil ntdsutil: activate instance ntds ntdsutil: ifm ifm: create rodc C:\InstallationMedia
1.1.6. Upgrading to Windows Server 2008 AD DS

To install a new Windows Server 2008 domain controller in an existing Windows 2000 Server or Windows Server 2003 domain, complete the following steps:
If you install the first Windows Server 2008 domain controller in the forest, you have to extend the schema (add new attributes and classes specific to Windows Server 2008). To extend the schema, you have to run the "adprep /forestprep" from the Windows Server 2008 installation media files. You need to be Schema Administrator or Enterprise Admin to perform this operation and it is recommended to execute this command on the schema master role owner.
If you install the first WIndows Server 2008 domain controller in a Windows 2000 Server domain, you have to prepare the domain by running the "adprep /domainprep /gpprep" command.
I you install the first Windows Server 2008 domain controller in a Windows Server 2003 domain, you have to run the "adprep /domainprep" command.
To install an RODC in a Windows Server 2003/2008 forest, a writeable domain controller must be already present. But before, you have to prepare the forest by running the "adprep /rodcprep" command. If you want the RODC to be also a global catalog server, you must run the "adprep /domainprep" command in all domains in the forest to allow the RODC to replicate global catalog data from all domains in the forest.
1.1.7. Installing AD DS on a Server Core computer

A Server Core installation provides the minimal environment. Indeed, in Server Core, you have no graphical interface but only the Command Prompt and you can run only specific server roles. This allows to reduce the maintenance and management requirements and also the attack surface. Without any graphical interface, you will not be able to run the Active Directory Domain Services Installation Wizard. To install AD DS on Server Core, you will have to use the unattended mode. You have two different ways to perform this operation:
You can use answer files with the "dcpromo /answer [:filename]" where filename is the name of the answer file.
18
Created by XMLmind
XSL-FO Converter.
Or you can directly run the "dcrpomo" command with answers for the installation. Here, you can see two examples to install AD DS on Server Core.
Example 2.2. AD DS Answer File

ReplicaOrNewDomain=Domain NewDomain=Forest NewDomainDNSName=ms-lab.lan DomainNetbiosName=ms-lab InstallDNS=yes SafeModeAdminPassword=*
Example 2.3. AD DS Installation on Server Core

[CODE:dos]Dcpromo /ReplicaOrNewDomain=Domain /NewDomain=Forest /NewDomainDNSName=ms-lab.lan /DomainNetbiosName=ms-lab /InstallDNS=yes /SafeModeAdminPassword=*
1.1.8. Verifying the AD DS Installation

The Active Directory Domain Services installation process creates a number of default objects in the AD DS database. It also creates the shared system folder and the database and log files.
Verify that the SYSVOL folder structure was created, and then verify that the necessary shared folders were created. By default, the SYSVOL folder path is %SystemRoot%\SYSVOL (if you didn't change it during installation)
Verify that the Active Directory database and log files were created. By default, AD DS database and log files are stored in %SystemRoot%\NTDS (if you didn't change during installation)
Verify the creation of the default Active Directory structure. Launch the Active Directory Users and Computers and verify the domain structure.
Verify that the domain controllers records are created in the DNS zone for this domain. Check on the DNS Server.
Analyse the event logs for errors.
1.2. Deploying Read-Only Domain Controllers

1.2.1. Introduction to Read-Only Domain Controllers
The Read-Only Domain Controller is one of the major new features in Windows Server 2008. Actually, lots of organizations encounter some security issues by deploying writeable domain controllers in branch offices because they cannot assure a sufficient physical security to these servers and the AD DS database information might be compromised. To solve this problem, Microsoft decided to add the RODC option in the AD DS infrastructure. Indeed, an RODC stores read-only partitions of the AD DS database, which means that you can't write or modify information on the database stored on an RODC, and AD DS uses unidirectional replication from a writeable domain controller to the RODC. We will see that you can also manage which user account passwords will be cached on the server and delegate administrative permissions for the RODC.
19
Created by XMLmind
XSL-FO Converter.
An RODC only accepts replicated changes and never initiate replication because no changes can be made on it. RODCs cannot hold operation master roles or be configured as replication bridgehead servers. If you want to maximize security, you can deploy RODCs on servers running Windows Server 2008 Server Core.
1.2.2. Read-Only Domain Controller Features

Here are the different features of Read-Only Domain Controllers:
Read-only AD DS database: Except for account passwordsan RODC stores all the Active Directory objects and attributes that a writeable domain controller stores but changes cannot be made to the database that is stored on the RODC. You have to perform changes on a writeable domain controller and then wait for replication on the RODC.
Unidirectional replication: AD DS uses a one-way connection to replicate data from a writeable domain controller to the RODC. Like this, the RODC only receive changes on the AD DS database and never initiate replication.
Credential caching: by default, no credential caching is done on RODCs but you can configure which credentials will be cached with password replication policies.
Administrative role separation: You can delegate local administrative permissions for an RODC to any domain user without granting that user any user rights for the domain or other domain controllers.
Read-only DNS: You can install the DNS service on an RODC. An RODC can replicate all application partitions that DNS uses, including ForestDNSZones and DomainDNSZones. However, the DNS Server on an RODC is read-only and does not support client updates directly.
RODC filtered attribute set: Some applications that use AD DS as a data store can have some credential-like data (passwords, credentials, or encryption keys) that you do not want to be replicated on an RODC. You can configure a set of attributes in the schema for domain objects that will not replicate to an RODC. This set of attributes is called the RODC filtered attribute set.
1.2.3. RODC Installation

Before installing an RODC, you must prepare the AD DS environment by completing the following steps:
Configure the domain and forest functional level: the domain and forest must be at least at a Windows Server 2003 functional level.
A Windows Server 2008 writeable domain controller must be available to replicate the domain partition to the RODC.
Prepare the forest and domain by running some commands:
Run "ADPrep /domainprep" to enable the RODC to replicate DNS partitions.
Run "ADPrep /domainprep" in all domains if the RODC will be configured as a global catalog server.
20
Created by XMLmind
XSL-FO Converter.
You can find the "ADprep" tool on the Windows Server 2008 installation media. The RODC installation is almost the same as the installation of AD DS on a writeable domain controller.First, in the AD DS Installation Wizard, you have to choose the option to install an additional domain controller in an existing domain. Next, you can choose to install an RODC. Then, if you have used the advanced installation mode, you can configure the password replication policy. If you plan to install an RODC on a Server Core, you can use answer files with "ReplicaOrNewDomain=ReadOnlyReplica" value. See part 1.1.7 for information on unattended installation.
1.2.4. Delegating the RODC Installation

The interesting part of RODCs deployment is that you can delegate the installation of an RODC to a user or group by pre-staging the installation. First, you have to pre-create the RODC computer account in the Domain Controllers container in Active Directory Users and computer, then you can assign on this computer account a user or group with permission to install the RODC. To perform the delegated installation, run "DCPromo /UseExistingAccount:Attach".
1.2.5. Password Replication Policies

You can configure a Password Replication Policy for the RODC when you install it with the AD DS Installation Wizard in the advanced installation mode. You can also configure it later. The password replication policy is used to determine how the RODC will perform credential caching for authenticated users. You remember that by default, RODCs do not cache any user or computer credentials. The Password Replication Policy acts as an access control list (ACL) that determines if an RODC is allowed to cache a password. After an account successfully authenticated on an RODC, the RODC will contact a writeable domain controller and request a copy of the account credentials. The writeable domain controller recognizes that the request is coming from an RODC and consult the Password Replication Policy in effect for that RODC. If the Password Replication Policy allows it, the writeable domain controller replicates the credentials to the RODC, and the RODC caches them. After the credentials are cached on the RODC, the RODC can directly answer that user's logon and resource requests until the credentials change. You have three options for configuring password replication policies:
No credentials cached (by default)
Enable credential caching on an RODC for specified accounts
Add users or groups to the Domain RODC Password Allowed group so credentials for members of this group are cached on all RODCs in the domain
1.3. Configuring Active Directory Domain Services Controller Roles

In Active Directory, we are in a multimaster structure, which means that all domains controllers are equal, they have all the same data and provide and the same services. You can perform changes on the AD DS database on any domain controller but this structure can bring some issues concerning some very specific tasks. Indeed, sometimes in Active Directory, to avoid conflicts between the domain controllers, you have to ensure that only one domain controller will perform a task or provide a service at any given time. To do that, Microsoft decided to implement what we call Operations Master Roles or Flexible Single Master Operations (FSMO) roles. 21
Created by XMLmind
XSL-FO Converter.
1.3.1. What Are Global Catalog Servers?

A global catalog server is a domain controller that stores a copy of the global catalog. The global catalog is a repository that contains a partial, read-only replica of all domain partitions in a forest. The global catalog is partial because it only contains a limited set of attributes for all objects in a forest. By default, the global catalog contains only attributes that are the most used for searching, this way, the database of a global catalog server can represent every object in every domain of the forest. A global catalog server is a domain controller, so it stores the full information for the domain in which it is a member, and additionaly it stores the global catalog so the partial replica for the information of all other domains in the forest. By default, AD DS configures the first domain controller in the forest as a global catalog server. You can configure other domain controllers to store the global catalog or change the default location of the global catalog to another domain controller. To configure the global catalog functionality on a domain controller, you can use the Active Directory Sites and Services console. A global catalog server performs the following key functions:
It enables network logon by providing universal group membership information to a domain controller when a logon process is initiated. It is also used when a network resource access is initiated.
It finds directory information regardless of which domain in the forest actually contains the data.
1.3.2. How to Modify the Global Catalog?

As we said, the global catalog contains a set of common attributes for every objects in the forest, but may want to customize the global catalog by including additional attributes to it. By default, for example you can find a user by first name, last name, e-mail address, or other common properties. To replicate new attributes to the global catalog, you can use the Active Directory Schema console. By default, this MMC is not accessible. To be able to use it, you have to register a DLL. To do it, run the "regsvr32 schmmgmt.dll" command in the Run command or in a Command Prompt.
1.3.3. Operations Master Roles

Active Directory is designed as multimaster replication system, but for certain critical directory operations, AD DS must ensure that only a single authoritative server will perform the modification and replication. The domain controllers that perform such roles are called operations masters. This role repartition ensures consistency and eliminate potential conflicts in the Active Directory database.
Table 2.5. Operations Master Roles

Roles Schema Master One per forest Description
Performs all updates to the Active Directory Schema Domain Master Naming One per forest
Controls the addition or removal of domains in the forest. When you add a new
22
Created by XMLmind
XSL-FO Converter.
domain to the forest, only the domain controller that holds the domain naming master role can add the new domain. RID Master One per domain
When a new object is created, the domain controller creates a new security principal that represents the object and assigns a unique security identifier (SID) to the object. This SID consists of a domain SID, which is the same for all security principals created in the domain, and a relative identifier (RID), which is unique for each security principal created in the domain. The RID master allocates blocks of RIDs to each domain controller in the domain. The domain controller then assigns a RID to objects that are created from its allocated block of RIDs. PDC Emulator One per domain
Minimizes replication latency for password changes. When a password is changed on a domain controller, the domain controllers directly informs the PDC Emulator of this change and after perform replication with other domain controllers. Like this, if the user affected by the password change tries to log on on another domain controller where replication has not occured, the domain controller can ask the PDC Emulator to know if the password has changed.
Synchronizes time on all domain controllers in the domain. Time synchronization is very important for the Kerberos protocol Infrastructure Master One per domain
When objects are moved from one domain to another, the infrastructure master updates object references in its domain that point to the object in the other domain.
23
Created by XMLmind
XSL-FO Converter.
Chapter 3. Configuring Domain Name Service for Active Directory Domain Services
In this lesson, we will see that Active Directory is completely linked to DNS (Domain Name System). We will see the relationship between these two applications to be able to provide the best service as possible to clients. Module Overview
Overview of Active Directory Domain Services and DNS Integration.
Configuring Active Directory Integrated Zones.
Configuring Read-Only DNS.
1. Course
1.1. Overview of Active Directory Domain Services and DNS Integration
Active Directory Domain Services requires that a DNS infrastructure is in place before installing it. Understanding how DNS and Active Directory are connected, and how client computers use DNS during logon, will help you resolve manye Active Directory issues related to DNS, such as client logon issues.
1.1.1. Active Directory Domain Services and DNS Namespace Integration

Active Directory domains names must use DNS names. It allows AD DS to store resources records in the DNS namespace to represent Active Directory objects in the Active Directory namespace. All AD DS domains must have corresponding DNS domains with identical domain names. Clients will use DNS to resolve computer host names to IP addresses in order to locate domain controllers and other computers that provide Active Directory and other network services. This will allow clients to log on and access network resources. Without this DNS integration, clients cannot use the Active Directory service because they cannot locate domain controllers. Clients will locate domain controllers and services by using A and SRV resource records in the DNS namespace. The A resource record contains the FQDN (Fully Qualified Domain Name) and IP address of a domain controller (or computer). The SRV record contains the FQDN and the service name that the domain controllers provides. Active Directory requires DNS, but not any particular type of DNS server. Therefore, there may be multiple DNS servers of different types.
1.1.2. What are Service (SRV) Resource Records?

For Active Directory to function properly, client computers must be able to locate servers that provide specific services, such as authenticating logon requests and searching for information in Active Directory. Active Directory stores information about the location of the computers that provide these services in DNS records known as SRV resource records. Active Directory clients and domain controllers use Service (SRV) resource records to determine the IP adresses of computers that provide those services. SRV resource records allows DNS clients to locate TCP/IP based services. SRV resource records are used when:
24
Created by XMLmind
XSL-FO Converter.
A domain controller needs to replicate changes on the AD DS database
A client computer logs on to Active Directory
A user attempts to change his or her password
An administrator modifies Active Directory
Example 3.1. SRV record syntax:

protocol.service.name TTL class type priority weight port target
Example 3.2. Example of an SRV record

_ldap._tcp.ms-lab.lan 600 IN SRV 0 100 389 paris-dc1.ms-lab.lan
1.1.3. How SRV Records Are Used

Domain client computers use the locator application programming interface (API) to locate a domain controller by querying DNS. If SRV resource records are not available to identify domain controllers, logons may fail. All computers, including both workstations such as Windows XP Professional or Windows Vista, and servers such as Windows Server 2003 or Windows Server 2008, use the s ame process to locate domain controllers.
Locator initiates a call to Net Logon service
Locator collects information about the client
Net Logon uses the information and queries DNS for SRV resource records
Net Logon tests connectivity to target servers
Domain controllers respond, indicating that they are operational
Net Logon returns the information to clients
1.1.4. Integration of SRV Records and Active Directory Sites

When searching for a domain controller, the Locator attempts to find a domain controller in the site closest to the client. The domain controller uses the information stored in Active Directory (sites and subnets) to determine the closest site. In most cases, the domain controller that first responds to the client will be in the same site as the client. But sometimes, when a computer has physically moved or the domain controller in the local site is unavailable, There is a process to find another domain controller.
25
Created by XMLmind
XSL-FO Converter.
During Net Logon startup, the Net Logon service on each domain controller enumerates the site objects in the Configuration partition of Active Directory. Net Logon uses the site information to map IP addresses (coming from subnets configured in Active Directory) to site names. The domain controller uses the IP address of the client and this mapping to know in which site is the client computer.
1.2. Configuring Active Directory Integrated Zones

Integrating DNS zones into Active Directory can simplify the administration of DNS zones. We will see that this integration will bring some benefits concerning replication or security for example.
1.2.1. Active Directory Integrated Zones

By default, on a Microsoft DNS Server, DNS information concerning zones, portion of the DNS namespace, is stored in what we call zone files. When you choose to integrate DNS zones into Active Directory, they will be stored directly in the AD DS Database. You can choose to store this DNS information in application partitions or in the domain partition. If zone data is stored in application partitions, only domain controllers that subscribed to this application partition will replicate the zone information. However, if the zone is stored in an AD DS domain partition, it will be replicated on all domain controllers of this domain. Active Directory integrated zones offer the following benefits:
Replication: Replicates DNS zone information using Active Directory replication instead of zone transfers.
Multimaster model: By default, in a DNS infrastructure, you have a primary DNS server, which stores a writeable copy of the zone, and secondary DNS servers which store read-only copies of the primary zone. It means you can only perform changes on the primary zone and changes are transferred to seconday zones using zone transfers. So if the primary source for the zone is unavailable, you can't perform any changes on your zone, until the primary zone is available again. By integrating zones into Active Directory, you will take advantage of the multimaster replication model used by AD DS. It means, you will be able to perform changes on every domain controller that store this zone. So even if a primary source for the zone becomes unavailable, you will still be able to perform changes on another domain controller which is available. It is a fault tolerance mechanism.
Secure Dynamic Updates: By default, DNS Servers accept both secure and non-secure dynamic updates. When you integrate DNS zones into Active Directory, you can choose to accept only secure dynamic updates for more security.
Supports record aging and scavenging
1.2.2. AD DS Application Partitions

The Active Directory database is divided into directory partitions, with each directory partition replicated to specific domain controllers and containing specific information. 26
Created by XMLmind
XSL-FO Converter.
By default, there are three major partitions in the Active Directory database:
The schema partition, which contains and replicates schema information to the entire forest.
The configuration partition, which contains and replicates information about the AD DS structure to the entire forest.
The domain partition, which contains and replicates domain information (objects) to all domain controllers in a given domain. You can choose to store a DNS zone in the domain partition or in an application partition. By default, there are two application partitions, named DomainDNSZones and ForestDNSZones, that are created to store DNSspecific data. Administrators can create additional application partitions and define the replication scope for those application partitions. You can choose on which domain controller the application partition will be replicated. You can configure where you want to store DNS zones in the DNS console. You have four different choices:
To all DNS servers in the forest: The DNS zone will be stored in the ForestDNSZones application partition.
To all DNS servers in this domain: The DNS zone will be stored in the DomainDNSZones application partition.
To all domain controllers in this domain (for Windows 2000 compatibility): The DNS zone will be stored in the domain partition.
To all domain controllers in the scope of this directory partition: The DNS zone will be stored in a custom application partition you configured. 27
Created by XMLmind
XSL-FO Converter.
You can see the content of directory partitions by using the ADSI Edit tool which is installed by default on each Windows Server 2008 domain controller.
1.2.3. What Are Dynamic Updates

Dynamic updates enable DNS client computers to register and dynamically update their resource records with a DNS server whenever changes occur. This reduces the need to administer zone records manually, especially for clients that frequently move or change locations and that use Dynamic Host Configuration Protocol (DHCP) to obtain an IP address.
6. Clients send a SOA query to get the name of the DNS server which is hosting the primary zone 7. DNS server sends zone name and server IP address 8. Client verifies existing registration 9. DNS Server reponds by stating that registration does not exit 10. Client sends dynamic update to DNS server to register its name and IP address in a A record. (PTR if reverse lookup zone exists)
1.2.4. What Are Secure Dynamic Updates

Secure dynamic updates work like dynamic updates, with the following exception: the authoritative name server accepts updates only from clients and servers that are authenticated and joined to the Active Directory domain in which the DNS server is located. To allow only secure dynamic updates, you have to integrate the DNS zones into Active Directory. Actually, as DNS records are stored as objects in the Active Directory database, you can specify permissions on these records, and like this, you can limit which computers can update the records. The client will first attempt a non-secure update. If that attempt fails, the client will then attempt to negotiate a secure update. If the client has been authenticated to Active Directory, the update will succeed.
1.2.5. How Background Zone Loading Works

A DNS server running Windows Server 2008 loads zone data from Active Directory in the background while it restarts so that it can respond to data requests concerning other zones. When a domin controller with Active Directory integrated DNS zones starts, it:
28
Created by XMLmind
XSL-FO Converter.
Enumerates all zones to be loaded
Loads root hints from files or AD DS servers
Loads all zones that are stored in files rather than in AD DS
Begins responding to queries and RPCs (Remote Procedure Calls)
Starts one or more threads to load the zones that are stored in AD DS
1.3. Configuring Read-Only DNS

For more security, the Read-Only DNS is a feature available on RODCs. It allows to store a read-only copy of DNS zones in the RODC to avoid unauthorized users to alter records on the read-only domain controller.
1.3.1. What is Read-Only DNS?

When installing a Windows Server 2008 Read-Only Domain Controller, you are prompted with DNS Server installation options. The default option is to install a primary read-only DNS Server locally on the RODC, which replicates the existing AD-integrated zone for the domain specified and add the local IP address as the preferred DNS server in the local TCP/IP settings. This ensures that the DNS server running on the RODC has a full read-only copy of any DNS zones. It's a feature supported on Read-Only Domain Controllers where all application partitions containing DNS information are replicated to the RODC. The benefits oh having Read-Only DNS zones:i
DNS information required for Active Directory name resolution is available for clients in the same site as the RODC, as RODCs are designed to provide a secure Directory service in branch offices where physical security cannot be ensured.
Changes are not allowed on the read-only DNS zone, which increases security.
1.3.2. How Read-Only DNS Works

The Read-Only DNS feature is installed on an RODC when you install AD DS and that you choose the DNS option during installation of the RODC. The read-only DNS zones data can be viewed, but cannot be updated. If clients are configured to perform dynamic DNS updates on the RODC, they will refer to a DNS server with a writeable copy of the zones. You cannot add records manually on a read-only zone. When a computer becomes an RODC, it replicates a full read-only copy of all application directory partitions that DNS uses, including the domain partition, ForestDNSZones, and DomainDNSZones. This ensures that the DNS server running on the RODC has a full read-only copy of any DNS zones stored on a centrally located domain controller in those directory partitions. The administrator of an RODC can view the contents of a primary read-only zone. However, the administrator can change the contents only by changing the zone on a DNS server with a writeable copy of the DNS database.
29
Created by XMLmind
XSL-FO Converter.
Chapter 4. Configuring Active Directory Objects and Trusts

In this lesson, we will see how to manage the different AD DS objects, such as user, group or computer accounts, and organizational units. It is very important to know how to perform administrative tasks on these objects and how to manage them because they will be the structure of your directory service. At the end of this lesson, you will be able to perform administrative tasks on AD DS objects and the options for delegating administrative permissions and automating these tasks. You will see also how to configure and manage AD DS trusts. Module Overview
Configuring Active Directory Objects
Strategies for Using Groups
Automating AD DS Object Management
Delegating Administrative Access to AD DS Objects
Configuring AD DS Trusts
1. Course
After you have deployed Active Directory Domain Services on your network, you will have to create and manage AD DS objects. It is the most common task for an AD DS administrator. Generally, in organizations, each employee has a user account created in Active Directory and most of the computers have a computer account in AD DS. Then, these accounts can be grouped with AD DS groups which will be used to give permissions to access network resources. So we will see how to manage user, computer and group accounts to make the management of network access easier, depending on the organization.
1.1. Configuring Active Directory Objects

In this part, we will see the different AD DS objects that are mainly used in Active Directory Domain Services, how to create these objects and how configure and manage these objects. As an AD DS administrator, it will be your primary task to manage these objects and to be sure they are configured correctly. By default, only AD DS administrators have the permissions to create and modify AD DS objects but we will see in a later part how to delegate permissions to other users.
1.1.1. AD DS Objects
In AD DS, you can create several types of objects that will represent your network resources. Here are the common objects you can use:
User accounts: They are used to represent a user on your network. It will provide single sign-on for this user and access to network resources. Single sign-on means that the user will be able to use the same credentials (username and password) to access all the different resources on the network.
30
Created by XMLmind
XSL-FO Converter.
Computer accounts: They provide authentication and auditing of computer access to network resources. They are used to represent the physical computers that are members of your AD DS domain.
Group account: Groups are used to group objects, such as user account, and to give permissions on network resources for example. Imagine you have 100 user accounts and you want to give them the permissions to access a shared folder on the network. Instead of giving one hundred times the same permission to each user account on the shared folder, you can use a group. You put all the user accounts in this group, and you give the permission on the shared folder to this group. Automatically, all the members of this group will inherit the permissions granted to the group they are member of.
InetOrgPerson: This object type is similar to a standard user account but is used for compatibility with other directory services.
Organizational Units: Container objects used to organize the other objects in your domain. We can compare organizational units to folder on your hard drive. You create folders to organize your files and to make the management of them easier. It's the same in AD DS, you create organizational units in domains to organize the different objects of this domain, user, computer and group accounts for example. Like this, it will be easier to manage these objects and to deploy group policies or delegate administrative permissions.
Printers: They are used to represent the printers on your network, and simplify the process of locating and connecting to printers. Users don't need to know on which server the printer is connected and how to access it.
Shared folders: They are used to simplify the process of locating and connecting to shared folders on the network.
1.1.2. Tools to Manage AD DS Objects

There are different tools you can use to create and manage AD DS objects.
Active Directory Users and Computers: It is the main tool to create and manage AD DS objects. With this MMC, you can create organizational units, users, computers, groups, printers, shared folders... This console is very useful and will be the mostly used tool by AD DS administrators.
31
Created by XMLmind
XSL-FO Converter.
Directory Service command-line tools: A set of command line tools to create and manage AD DS objects. The DS tools include: dsadd, dsmod, dsrm, dsmove, dsget, dsquery. With this tools you can write scripts or batch files to perform tasks on AD DS objects.
Example 4.1. Creating a new organizational unit using DS command-line tools

[CODE:dos]dsadd ou "OU=Paris,DC=supinfo,DC=lan"
LDIFDE: Lightweight Directory Access Protocol Data Interchange Format Directory Exchange is a command line tool thet you can use to create AD DS objects in a batch processing, it means a lot of objects at the same time. LDIFDE uses an input file that contains information about the objects to add, modify, or delete. This file must respect the LDIF format. The information is stored as a series of records that are separated by a blank line in an input file
Example 4.2. Creating a new organizational unit using LDIFDE

DN: OU=London,DC=supinfo,DC=lan changetype: add objectClass: OrganizationalUnit
CSVDE: Coma-Separated Value Directory Exchange is a command line tool used to import or export data in Active Directory Domain Services by using CSV formatted files.
Example 4.3. Creating a new organizational unit using CSVDE

objectClass,dn organizationalUnit,"OU=San Francisco,DC=supinfo,DC=lan"
WSH: Windows Script Host is a script executing environment. WSH can run scripts written in JScript or VBScript natively. So you will be able to manage AD DS using WSH.
Example 4.4. Creating a new organizational unit using VBScript

[CODE:vb]Option Explicit Dim objRoot, objDomain, myOU Set objRoot = GetObject("LDAP://rootDSE") objDomain = objRoot.Get("defaultNamingContext") Set objDomain = GetObject("LDAP://" & objDomain) Set myOU = objDomain.Create("organizationalUnit", "OU=Casablanca") myOU.SetInfo
1.1.3. AD DS Group Types

Groups are used to simplify administration of multiple users and computers. A group is a collection of multiple users, computers, or groups. We use groups to grant permissions to network resources for example, or to send emails to a group of users. It makes it easier to manage because you can assign permission for shared resources only once on the group rather than on each user account. AD DS supports two different group types:
Security groups: They are used to assign rights or permissions to groups of users and computers. Rights determine which functions members of a security group can perform in a domain or forest. Permissions determine which resources a member of a group can access on the network. One way to use security groups effectively is to use nesting, that is, to add a group to another group. The nested group inherits the permissions of the group that it is a member of, which simplifies the assigning of permissions to several 32
Created by XMLmind
XSL-FO Converter.
groups at once and reduces the traffic that replication of group membership changes causes.
Distribution groups: They are used only with e-mail applications, such as Microsoft Exchange, to send messages to collections of users. Distribution groups are not security-enabled, that is, they cannot be listed in discretionary access control lists (DACLs). To control access to shared resources, create a security group.
1.1.4. AD DS Group Scopes

Group scopes will determine the visibility of each group you create and what objects you will be able to put in it. Here is a table recapitulating the different scope and their features.
Table 4.1. Group Scopes

Group scope Group members can include Can be used to assign permissions In its own domain Universal groups, global groups, and other domain local groups from its own domain
Domain Local
Accounts from any trusted domain In any trusted domain Global User, groups, and computers from its own domain In any trusted domain Universal Users, groups, and computers from any trusted domain On the local computer only where local groups are created Users, groups, and computers from any trusted domain
Local
1.1.5. Default AD DS Groups

Windows Server 2008 creates automatically many built-in groups when Active Directory is installed. These groups are designed to manage shared resources and delegate some specific roles in the domain. He is the list of the different built-in groups you can find in an AD Domain:
Account Operators
Administrators
Backup Operators
Incoming Forest Trust Builders
Network Configuration Operators
Performance Log Users
33
Created by XMLmind
XSL-FO Converter.
Performance Monitor Users
Pre-Windows 2000 Compatible Access
Print Operators
Remote Desktop Users
Replicator
Server Operators
Users You can use these groups to give specific roles to users. For example, you can put a user account in the Account Operators group to allow this user to create and manage user accounts and groups in the domain. But be carefull, because this user will have permissions to manage all user accounts in the domain. We will see in a later part that it is more appropriate to delegate administrative control on AD DS objects to be able to give permissions only on some AD DS objects and not on the entire domain.
1.1.6. AD DS Special Identities

On Windows Servers 2008 servers, you have several special identities in addition to the groups in the Users and Built-in containers in Active Directory. These identities can be used to provide access to resources but you cannot manage them. It means you do not control to what they refer, you cannot even see it. You cannot delete or modify these identities, you can only use them to provide access. These special identities are managed by the system and they refer to specific persons dynamically. For example, the Authenticated Users is a goup that contain all users and computers that have correctly authenticated against the system. The Anonymous Logon is a group that contains users and computers that have connected anonymously on the system and the Everyone group contains both Authenticated Users and Anonymous Logon groups. Here is a list of the different special identities: Anonymous Logon Authenticated Users Batch Creator Group Creator Owner Dialup Everyone Interactive Local System Network Self Service Terminal Server Users Other Organization This Organization
1.2. Strategies for Using Groups

As we already said, AD DS groups are used to simplify management when you assign permissions to access network resources. Rather than assigning permissions to each user account, it is more efficient to add the user 34
Created by XMLmind
XSL-FO Converter.
accounts to groups and then assign permissions to the group. This way, all the members of the group inherit permissions assigned to this group.So, in this part, we will see how to use groups depending on your AD DS deployment.
1.2.1. Options for Assigning Access to Resources

There are different ways to assign access to resources. You can:
Add user accounts directly to the ACL (Access Control List) on the resource. This is the worst solution because you have to do it for each user account. If you have hundreds of user accounts, it will become very difficult to manage quickly.
Add user accounts to groups, and adding the groups to the ACL on the resource. This is the basic solution using groups. It is better than adding user accounts directly to the ACL but in some cases, it might not provide enough flexibility and scalability.
Add user accounts to account groups (groups only used to put user accounts together), add the account groups to resource groups (groups used only to assign access to resource), and then add the resource group to the ACL on the resource. This is the most flexible solution and the one that will provide the best evolution possibilities. In AD DS, we create users and groups to provide access to network resources, such as shared folders, printers, or applications. When you assign access to resources, you need to:
Plan for the lowest level of permissions. You always have to give the minimum permissions to a user. Only the permissions the user needs to perform its tasks, not more, not less.
Keep the plan as simple as possible. You have to keep in mind that the goal is to simplify access to resources.
Document what you have done. If you are choosing for a particular structure concerning groups and access to resources, document your plan. Like this it is easier to maintain and you can follow the same rules all the time.
1.2.2. Using Account Groups to Assign Access to Resources

Account groups are a collection of user accounts. It is simply a way of naming groups that contain only accounts. It can be domain local, global or universal groups. When you use account groups to assign access to resources, you add all user accounts to the groups, and then you assign the group permissions on a resource. For example you want to give the write permission on a shared folder to all the Accounting department users of your company. You can create a new global security group, named "GS Accountants", and you put all the user accounts of the Accounting department in this group. Then, on the shared folder, you assign the write permission to the "GS Accountants" permission. It is a simple solution, but imagine you want to give the write permission on the shared folder to another account group. You will have to configure again the permissions for this other group. So this solution is not very flexible and scalable in large networks.
35
Created by XMLmind
XSL-FO Converter.
1.2.3. Using Account Groups and Resource Groups

Resource groups will be in general domain local groups and you will grant specific resource-access permissions on them. When you use account groups and resource groups, you add users with similar access requirements into account groups, in general global security groups, and then add the account groups as members to a resource group to which you granted specific resource-access permissions. For example, you want to grant the Read and Write permissions on a shared folder named "Financial Documents" to all the Accouting department users of your company. You create a new global security group, named "GS Accountants", and you put all the user accounts of the Accounting department in this group. Now, you create a domain local security group, named "DLS FinDocs RW" and you assign the read and write permissions to this group on the "Financial Documents" shared folder. Then you add the account group named "GS Accountants" to the resource group named "DLS FinDocs RW". Automatically, all the users in the "GS Accoutants" group will inherit the permissions assigned to the "DLS FinDocs RW" group. This strategy provides the most flexibility while reducing the complexity of assigning access permissions to the network. In this case, if you want to give the read and write permissions on the "Financial Documents" shared folder to other groups, you just need to put the other account groups in the "DLS FinDocs RW" resource group. You don't need to modify the ACL on the shared folder. This method is used most commonly by large organizations for controlling access to resources.
1.3. Automating AD DS Object Management

Most of the time, you will need to create and configure AD DS objects individually and in theses cases, the most appropriate tools are the graphical ones like Active Directory Users and Computers. However, sometimes, you may need to create or modify the configuration for many objects at the same time. For example, your company hires a large group of new employees, it can be very long to create each user account manually with the Active Directory Users and Computers console. So we will see in this part how to manage multiple AD DS objects at the same time. 36
Created by XMLmind
XSL-FO Converter.
1.3.1. Tools for automating AD DS Object Management

You have severals tools you can use to manage multiple AD DS Objects in Active Directory.
Active Directory Users and Computers: With this tool you cannot create multiple user accounts at the same time for example, but you can select multiple AD DS objects to modify some of their properties that they can have in common. For exemple you can change the location of multiple user accounts, or the membership to groups.
Directory Service tools: You can create a batch script to perform operations on multiple AD DS Objects at the same time.
Csvde and Ldifde
Windows PowerShell
1.3.2. Configuring AD DS Objects Using Command-Line Tools

You can use the dsadd, dsmod, dsmove, dsrm, dsget, net user, net group, net computer commands in a batch file to perform multiple tasks on AD DS objects at the same time.
Example 4.5. Batch Script Using DS Tools

[CODE:batch]dsadd user "CN=Romain LACOUR,OU=SCT,OU=Grenoble,DC=supinfo,DC=lan" -fn "Romain" -ln "LACOUR" -display "Romain LACOUR" -upn "romain.lacour@supinfo.lan" -pwd * dsmod user "CN=Romain LACOUR,OU=SCT,OU=Grenoble,DC=supinfo,DC=lan" -desc "SCT for Microsoft Laboratory" -company "SUPINFO Institute of Information Technology" dsmove "CN=Romain LACOUR,OU=SCT,OU=Grenoble,DC=supinfo,DC=lan" -newparent "OU=SCT,OU=San Francisco,DC=supinfo,DC=lan"
1.3.3. Managing User Objects with LDIFDE

Ldifde is a command line tool that can perform tasks on AD DS objects using a file in the LDIF format. It can be interesting to use Ldifde to import data from another directory using LDAP and Lightweight Directory Access Protocol Data Interchange Format (LDIF).
Example 4.6. Example of LDIF File to Create Multiple User Accounts

DN: CN=Stephane HENNEQUIN,OU=SCT,OU=Strasbourg,DC=supinfo,DC=lan changetype: add objectClass: User givenName: Stephane sn: HENNEQUIN sAMAccountName: shennequin displayName: Stephane HENNEQUIN userPrincipalName: stephane.hennequin@supinfo.lan description: SCT for Microsoft Lab DN: CN=Alexandre VILLOING,OU=SCT,OU=Nice,DC=supinfo,DC=lan changetype: add objectClass: User givenName: Alexandre sn: VILLOING sAMAccountName: avilloing displayName: Alexandre VILLOING userPrincipalName: alexandre.villoing@supinfo.lan description: SCT for Microsoft Lab DN: CN=Jenner VERNAL,OU=SCT,OU=Martinique,DC=supinfo,DC=lan changetype: add objectClass: User
37
Created by XMLmind
XSL-FO Converter.
givenName: Jenner sn: VERNAL sAMAccountName: jvernal displayName: Jenner VERNAL userPrincipalName: jenner.vernal@supinfo.lan description: SCT for Microsoft Lab
After you just need to run the following command to execute the modifications: ldifde -i -f filename.ldf
1.3.4. Managing User Objects with CSVDE

Csvde is a command-line tool that you can use to create multiple objects in Active Directory using a file in the CSV format. The real interest of this tool, is that you can generate CSV files from Microsoft Excel files. So if all new hired employees are written in a Excel file, it is very simple to create their user account automatically using a CSV file.
Example 4.7. Example of CSV File to Create Multiple User Accounts

objectClass, DN, sAMAccountName, givenName, sn, description, userPrincipalName user, "CN=Romain LACOUR, OU=SCT, OU=San Francisco, DC=supinfo, DC=lan", "rlacour", "Romain", "LACOUR", "SCT for Microsoft Lab", "romain.lacour@supinfo.lan" user, "CN=Come FERTE, OU=SCT, OU=Montreal, DC=supinfo, DC=lan", "cferte", "Come", "FERTE", "SCT for Microsoft Lab", "come.ferte@supinfo.lan" user, "CN=Arnaud BERTHIER, OU=SCT, OU=Paris, DC=supinfo, DC=lan", "aberthier", "Arnaud", "BERTHIER", "SCT for Microsoft Lab", "arnaud.berthier@supinfo.lan"
After you just have to run the following command to import the data from the CSV file: csvde -i -f filename.csv
1.3.5. What Is Windows PowerShell

Windows PowerShell is an extensible scripting and command-line technology that developers and system administrators can use to automate tasks in a Windows environment. Windows PowerShell uses a set of small command, called cmdlets, that each perform a specific task, but you can also combine multiple commands to perform complex administrative tasks. You can use Windows PowerShell to manage Active Directory. Here is a list of Windows PowerShell features:
Powerful single line cmdlets: You have cmdlets to perform most of the tasks on a Windows Environment and it is extensible so you can have more cmdlets added to the basic ones for specific products. For example when you install Exchange Server 2007, it provides the Exchange Management Shell which is Windows PowerShell with specific cmdlets to manage Exchange Server objects.
Aliases
Variables
Pipelining: You can use pipelines (the caracter "|") to combine multiple cmdlets. Actually, the result of the first cmdlet on the left side of the pipe is sent to the cmdlet on the right side of the pipe.
Scripting support: You can write PowerShell scripts with the extension ".ps1" and execute them to perform multiple tasks in one time.
Access to all cmd.exe commands In Windows Server 2008, Windows PowerShell is a feature that you can install from the Server Manager. 38
Created by XMLmind
XSL-FO Converter.
1.3.6. Windows PowerShell Cmdlets

All the Windows PowerShell cmdlets use the same syntax so it's very simple to use. Each cmdlet uses a syntax containing a verb, a noun, and different parameters. The verb-noun combination describes the action that the cmdlet will realize and parameters determine which objects and/or which attributes will be modified by the cmdlet execution. Verb-Noun -Parameter Value [-Parameter2 Value2 -Parameter3 Value3....] Some examples:
Get-Date : Gets the system date.
Get-Service | Sort-Object name : Lists all the services on the computer and then sort the object by their name. If you want to get the list of all cmdlets available: Get-Command If you want to get help on a specific cmdlet: get-help <cmdlet>
1.3.7. Managing AD DS Objects using Windows PowerShell

You can write Windows PowerShell scripts to manage AD DS objects. A PowerShell script is a simple text file with the extension ".ps1". Be careful, by default Windows PowerShell does not allow to run scripts that are not digitally signed. So to be able to run unsigned scripts you have to run the following cmdlet in the Windows PowerShell prompt: Set-ExecutionPolicy RemoteSigned
Example 4.8. Creating a User Account with a Windows PowerShell Script

[CODE:powershell]# Connecting to the domain $domain = [ADSI] "LDAP://srv-paris-dc1.supinfo.lan:389/DC=supinfo,DC=lan" # Displays all objects in the root of the domain $domain.psbase.get_children() # binding to the "SCT" OU contained in the "Montreal" OU $userOU = [ADSI] "LDAP://OU=SCT,OU=Montreal,DC=supinfo,DC=lan" # Displaying all objects in the "SCT" OU contained in the "Montreal" OU $userOU.psbase.get_children() # Creating the user account $newUser = $userOU.Create("user","CN=Romain LACOUR") $newUser.put("sAMAccountName","rlacour") $newUser.put("givenName","Romain") $newUser.put("sn","LACOUR") $newUser.put("displayName","Romain LACOUR") $newUser.put("userPrincipalName","romain.lacour@supinfo.lan") $newUser.put("description","SCT for Microsoft Laboratory") $newUser.SetInfo()
1.4. Delegating Administrative Access to AD DS Objects

Many of the aministration tasks that you will perform on AD DS as an administrator are quite easy but they are often repetitive. AD DS is a secure directory service, it means that you need specific administrative permissions 39
Created by XMLmind
XSL-FO Converter.
to be able to perform administration tasks on AD DS objects. In Windows Server 2008 AD DS, you will be able to delegate some of those administrative tasks to other users. It is what we call the decentralized management. By delegating administrative control, you allow other users to perform specific AD DS management tasks and you can grant only permissions that they need and not more. For example, you want to give the permission to manage user accounts in a specific organizational unit. Rather than putting the user account you want to delegate permissions to in the Account Operators group, what will give him permissions to manage accounts in the entire domain, you will be able to delegate control on the specific organizational unit and specify that this user can only manage user accounts in this organizational unit.
1.4.1. Active Directory Object Permissions

Active Directory object permissions secure the access to objects. You can specify which administrators or users can access objects or objects attributes. In general, we use permissions to assign administrative privileges for an organizational unit and objects that it contains or a hierarchy of organizational units. It avoids to repeat the permissions for each object within an organizational unit and it simplifies delegation. You have two types of permissions:
Standard permissions which are the basic permissions and the most frequently used because it is easier to maintain.
Special permissions which provide a finer degree of control for assigning permissions on objects. Actually, standard permissions are just a set of special permissions. To access special permissions, you just need to click on Advanced in the Security tab of the organizational unit Properties dialog box.
When you configure permissions you have two options:
Allow: Gives the corresponding permission to the user or group.
Deny: Denies explicitly the corresponding permission. It means the user or group affected by the Deny will not be able to perform this task. The explicit deny is stronger than any other permission. It means it will replace an Allow or an implicit deny If nothing is checked, it is an implicit deny. It is denied by default if no other permission specifies the contrary. Permissions are cumulative. It means a user account can receive permissions from multiple groups or levels. 40
Created by XMLmind
XSL-FO Converter.
You can set permissions at the object level or they can be inherited from the parent object. If you configure a specific permission on an organizational unit, you can specify to apply the permission to all child organizational units or only on this organizational unit.
1.4.2. What Are Effective Permissions

Effective Permissions is a tool that you can use to know the actual permissions that are granted to a specific user or group on a specific object. As permissions are cumulative, can be inherited from parent objects, can be denied, explicitly, implicitly, or allowed, it can be difficult to know exactly what permissions a user or group has. This tool automatically calculates the permissions that are in effect for the user or group you specify. To access the Effective Permissions tool, you have to click on the Advanced button in the Security tab of the object properties, and then you go in the Effective Permissions tab.
1.4.3. What Is Delegation of Control

The delegation of control is when you give responsibility on Active Directory objects to another user or group. It makes the management of your network easier because in most cases, it is not possible to administer Active Directory alone. With delegation of control, you can assign routine administrative tasks to different users. And you choose very specific permissions to assign to users so that you give only the permissions that they need to perform the tasks they are responsible for. For example, you can give team managers in your company the permission to modify group membership on the AD DS group object that contains their team members. Moreover, in companies located in different geographical sites, you can give more control to local users so that they can manage correctly their local network resources. It is also a good way to limit the number of domain or enterprise administrators. Rather than giving permissions to a user on the entire domain or forest, you can grant permissions for a specific organizational unit or object. To delegate control on an organizational unit, you can use the Delegation of Control Wizard in the Active Directory Users and Computers console, by right-clicking on an organizational unit and selecting Delegate Control...
You can also configure permissions directly in the Security tab of the organizational unit Properties dialog box as seen in part 1.4.1.
1.5. Configuring AD DS Trusts

By default in Active Directory, a user can only access resources in its own domain and that's why trust relationships exist. Trusts allow users to have access to resources in another domain. When there is a trust between two domains, a user can authenticate itself in its own domain and it can use its credentials to access 41
Created by XMLmind
XSL-FO Converter.
resources in the other domain, if it has permissions to do so, of course. In this part, we will see the different trusts that exist in AD DS, how they work and how to configure them.
1.5.1. AD DS Trusts
Trusts have different characteristics:
Transitivity: If domain A trusts domain B, domain B trusts domain C and both trusts are transitive, then domain A trusts domain C implicitly.
Direction: the trust direction defines the account domain and the resource domain. There are three different options: one-way incoming, one-way outgoing or two-way.
One-way incoming: If in domain A, you configure a one-way incoming trust from domain B, users from domain A will be able to access resources in domain B.
One-way outgoing: If in domain A, you configure a one-way outgoing trust to domain B, users from domain B will be able to access resources in domain A.
Two-way: If you configure a two-way trust between domain A and domain B, users from domain A will be able to access resources in domain B and the reverse.
1.5.2. Trust Types
42
Created by XMLmind
XSL-FO Converter.
Here are the different trust types you can find in Active Directory Domain Services:
Tree/Root Trust: By default, two-way and transitive. The tree/root trust is created automatically when a new tree is added to the forest. A tree/root trust is created between each tree root domain and the forest root domain. A tree/root trust cannot be deleted.
Parent/Child Trust: Bye default, two-way and transitive. The Parent/Child trust is created automatically when you add a child domain to an existing domain. A parent/child trust cannot be deleted.
Shortcut Trust: You can create a shortcut trust to improve user access between two domain in two different trees within the same forest. In the picture above, if a user from domain A want to access a resource in domain E, it will need to authenticate on the forest root domain, on domain D and then on domain E. To avoid these kerberos authentication steps, you can create a shortcut trust.
External Trust: External trusts are non-transitive and can be created between Active Directory domains in different forests or between an Active Directory domain and a Windows NT 4.0 domain.
Realm Trust: A realm trust can be established between any non-Windows-based operating system Kerberos version 5 realm and a Windows 2000 Server, Windows Server 2003, or Windows Server 2008 domain. This trust relationship allows cross-platform interoperability with security services based on other Kerberos version 5 implementations, such as that from the Massachusetts Institute of Technology (MIT).
Forest Trust: You can link two different forests by creating a one-way or two-way transitive trust relationship. A two-way forest trust is used to form a trust relationship between every domain in both forests. Forest trusts can be created only between two forests at a Windows Server 2003 functional level. You need to configure DNS correctly so that domain controllers from each forest can contact domain controllers in the other forest. Generally, we use DNS Forwarding to ensure this configuration but configuring Stub zones can be another option.
1.5.3. User Principal Names and Name Suffix Routing

A User Principal Name (UPN) is a logon name that can be used to log on to a Windows Server 2008 network. 43
Created by XMLmind
XSL-FO Converter.
The UPN contains two different parts that are separated by the @sign, for example, romain.lacour@supinfo.lan:
The user principal name prefix, also called user logon name, which in this example is romain.lacour.
The user principal name suffix, which is in this example supinfo.lan. By default, the UPN suffix is the name of the domain where the user account was created. You can use other domain names in the forest or you can create additional suffixes for the forest, to configure other suffixes for users. What can be done, is to create an UPN suffix that matches users' e-mail adresses. It's easier for users because they just have to remember their e-mail address and they can log on to the network using their e-mail adress. A UPN must be unique in the forest. To create additional UPN suffixes, you have to use the Active Directory Domains and Trusts console. There is a mechanism called UPN suffix routing used for routing authentication requests between trusted forests. With this mechanism, user from one forest can use its UPN to log on to the other forest and automatically authentication requests are routed to the target source. UPN suffix routing is automatically disabled if the same UPN suffix is used in both forests. You can manually enable or disable name suffix routing accross trusts. You just have to go in the Properties of a forest trust in the Active Directory Domains and Trusts console.
1.5.4. Selective Authentication Settings

The selective authentication is a process that allows you to limit which computers can be accessed by users coming from a trusted domain, and which users in the trusted domain can access the computer. It is another option for restricting authentication accross trusts in a Windows Server 2008 forest. To configure selective authentication:
Configure the forest or external trust to use selective authentication rather than domain wide authentication.
Configure the computer accounts for selective authentication.
44
Created by XMLmind
XSL-FO Converter.
Chapter 5. Configuring Active Directory Sites and Replication

Replication is a very important part of the Active Directory Domain Services structure. By understanding the replication process and the physical structure of AD DS, you will be able to ensure that your AD DS infrastructure is working properly. After completing this lesson, you will be able to:
Understand what is the Active Directory Domain Services Replication
Understand how the replication process works
Manage AD DS sites, site links and subnets
Understand how replication works within sites and between sites
Manage and monitor AD DS replication process
1. Course
1.1. Overview of Active Directory Domain Services Replication
In Active Directory Domain Services, you can deploy multiple domain controllers in the s ame domain or in other domain in the forest. When changes are made to one of those domain controllers, AD DS must ensure that all other domain controllers update their information so that they have all the same information. This process is called replication. By understanding how AD DS replication works, you will be able to manage replication network traffic and ensure the consistency of AD DS data accross domain controllers in your network.
1.1.1. Introduction to Active Directory Replication

When a user or an administrator performs a change on AD DS, the database on one domain controller is modified. That update is then replicated to all other domain controllers in the domain, and depending on the modification, on all domain controllers in the forest. You remember that AD DS uses a multimaster replication model, which means that you can perform most changes on any domain controller and the change will be replicated to all concerned domain controllers automatically to ensure consistency between accross the domain and forest. Replication is the process of updating information in Active Directory from one domain controller to other domain controllers on the network. The replication process synchronizes updated information between domain controllers. Synchronization ensures that all information in Active Directory is available to all domain controllers and client computers across the network. Here are the changes that initiate replication:
Addition of an object to Active Directory
Modification of an object's attribute values
45
Created by XMLmind
XSL-FO Converter.
Modification of an object's container name
Deletion of an object from the directory Within a single site, the domain controller on which the change is made sends a notification to replication partners, other domain controllers in the same site, to initiate the replication process. This notification is used to inform the replication partner that changes are available. Then, the replication partner pulls the changes from the domain controller where update has been made using a remote procedure call (RPC) connection. When replication is complete with the first replication partner, the original domain controller waits three seconds and then notifies another replication partner, which also pulls the changes. For normal updates, a domain controller will wait for 15 seconds after a change is made and then send a notification to initiate the replication process to other domain controllers in the same site. For some critical changes, as a password modification, the change notification is triggered immediatly and the domain controller does not wait 15 seconds. In that case, we talk about urgent replication. Active Directory replication uses loose consistency with convergence. It means, when a change is made on a domain controller database and during all the replication process, the system looses consistency because the information is not the same on all domain controllers. After some time, that we call replication latency, when the replication process is finished and that all domain controllers have replicated the changes, we say that the system has reached the convergence. There are two types of write operations that Active Directory replication needs to track. The first type is originating writes, which is when a particular change was performed directly on a particular DC. For instance, if you connect to DC1 and change a user's description, that change is considered as an originating write on DC1. The second type is replicated writes, this means that a particular change has replicated in from another domain controller. The change that was considered as an originating write on DC1 will be considered a replicated write when that change is replicated to DC2, DC3, and any other domain controller in the domain. To manage the transmission of directory information, domain controllers use replication metadata. This means that, in addition to sending the actual data that has been changed from one DC to another (Romain Lacour's description was changed to "SCT for Microsoft Lab"), Active Directory also transmits additional information about that change to allow domain controllers to manage replication in the most efficient way, such as the domain controller that the change originated from , the time at which the change was made, and some other information. The first piece of metadata is the Update Sequence Number (USN). Each domain controller maintains its own USN and it is incremented by 1 everytime a change is made to Active Directory. So if a DC has a USN of 1000 at 2:00 p.m., and 1005 at 2:30 p.m., you know that 5 changes have been made to this DC database. USNs are internal to a specific domain controller only, and don't have any relevance when compared with other DCs. Furthermore, the USN is incremented by both originating and replicated write operations. So each DC needs a way to keep a track of wich changes have already been replicated, otherwise each DC would be sending the entire database accross the network at every replication. To prevent this, the second piece of replication metadata is the high watermark vector (HWMV). It is maintained by each domain controller for other domain controllers that it is replicating with. The high watermark vector is the GUID (Global Unique identifier) of remote DCs associated with the USN. With only USNs and high watermark vectors, it creates an endless replication cycle that uses more and more bandwith. That's why there is a third piece of replication metadata used by domain controllers to manage replication, which is called the up-to-dateness vector (UTD Vector, or UTDV). It used to prevent the same change to be replicated over and over again between domain controllers.
1.1.2. Resolving Replication Conflicts

As you can perform changes on any domain controllers and that there can be some time for changes to be replicated on all domain controllers, there can be some conflicts during replication concerning modifications that are made at the same time on different domain controllers. Replication conflicts may appear more often when changes are made on domain controllers in different sites, because we will see later that replication between sites does not occur immediatly, contrary to replication in the same single site. 46
Created by XMLmind
XSL-FO Converter.
AD DS have different mechanisms to resolve these conflicts automatically. To resolve those conflicts, there are two more pieces of replication metadata. the versionID value is assigned to each individual attribute on an object, with a starting value of 1 when the object is first created. The versionID is incremented by 1 whenever an individual attribute is modified from any DC. For instance, if the description attribute of a particular user gets updated from its default value to "SCT for Microsoft Lab", the description attribute will have a versionID of 2. If the description is later modified to "Microsoft Lab Manager", the description attribute will have a versionID of 3. The second piece of metadata used to resolve replication conflicts is a timestamp. It is the time indicating when the modification was made. There are three different conflict types:
Attribute value:This conflict occurs when the same attribute on an object is modified on two domain controllers at the same time. To solve this conflict, AD DS look at the versionID of each modification and keeps the modification with the highest versionID. If both modifications have the same versionID, the change that has the later timestamp will be kept. Then if both records have the same versionID and timestamp, the record originated by the DC with the lower-numbered GUID is kept.
Adding an object or modifying an object on one domain controller at the same time that the container for this object is deleted on another domain controller. In this case, AD DS will put the object in the LostAndFound container in the domain. To see this container, you have to enable the Advanced Features view in the Active Directory Users and Computers console.
RDN conflict: Adding objects with the same relative distinguished name in the same container on different domain controllers. AD DS will rename duplicated objects so that the different objects can exist in the same container. To determine which object will be renamed, AD DS uses the versionID, timestamp and originating DC GUID as for the attribute value conflict.
1.1.3. Directory Partitions

The Active Directory database is logically separated into directory partitions, a schema partition, a configuration partition, domain partitions, and application partitions. Each partition is a unit of replication, and each partition has its own replication topology. Replication is performed between directory partition replicas. All domain controllers in the same forest have at least two directory partitions in common: the schema and configuration partitions. All domain controllers in the same domain, in addition, share a common domain partition.
47
Created by XMLmind
XSL-FO Converter.
Schema partition: Only one schema partition exists per forest. The schema partition is stored on all domain controllers in a forest. The schema partition contains definitions of all objects and attributes that you can create in the directory, and the rules for creating and manipulating them. Schema information is replicated to all domain controllers in the forest. Therefore, all objects must use the schema object and attribute definitions.
Configuration partition: There is only one configuration partition per forest. Stored on all domain controllers in a forest, the configuration partition contains information about the forest-wide Active Directory structure, including which domains and sites exist, which domain controllers exist in each forest, and which services are available. Configuration information is replicated to all domain controllers in a forest.
Domain partition: There are as many domain partitions in a forest than the number of domains in this forest. But a domain controller stores only the domain partition concerning its own domain. A domain partition contains information about all domain-specific objects that were created in that domain, including users, groups, computers, and organizational units. The domain partition is replicated to all domain controllers of that domain. All objects in every domain partition in a forest are stored in the global catalog with only a subset of their attribute values.
Application partitions: Application partitions are used to store information of some applications into the Active Directory database. For example, DNS stores information about integrated DNS zones in two application partitions: ForestDNSZones and DomainDNSZones. You can create additional application partition and you can configure on which domain controllers this application partition will be replicated.
1.1.4. Replication Topology
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 all domain controllers in the forest. To create a replication topology, Active Directory must determine which domain controllers replicate data with other domain controllers. Active Directory creates a replication topology based on the information that is stored in Active Directory. A replication topology can be different for schema, configuration, domain, and application partitions. Because all domain controllers within a forest share the same schema and configuration partitions, Active Directory replicates schema and configuration partitions to all domain controllers in the forest, they have the same replication topology. Domain controllers in the same domain also replicate the domain partition. Every 48
Created by XMLmind
XSL-FO Converter.
domain partition in a forest have a different replication topology, because a domain partition is only replicated between domain controllers of the same domain. In addition, domain controllers that host an application partition replicate the application partition. To optimize replication traffic, a domain controller may have several replication partners for different partitions. Active Directory replicates updates to the directory across domain controllers that contain the updated partition in the forest.
1.1.5. Generation of Replication Topology

The KCC (Knowledge Consistency Checker) is a built-in process that runs on all domain controllers. The KCC generates and maintains the replication topology for replication within sites and between sites. The KCC has two major functions:
Configures replication connections (connection objects) between domain controllers. Each connection object defines incoming replication from a replication partner. Within a site, each KCC generates its own connections. For replication between sites, a single KCC per site generates all connections between sites.
Converts the connection objects that represent inbound replication to the local domain controller into the replication agreements that are actually used by the replication engine. By default, the KCC reviews and makes modifications to the Active Directory replication topology every 15 minutes to ensure propagation of data, either directly or transitively, by creating and deleting connection objects as needed. The KCC recognizes changes that occur in the environment and ensures that domain controllers are not orphaned in the replication topology. When the KCC builds the topology, it must determine which servers that are present in each site in order to construct an efficient topology. The following objects provide the information required by the KCC to create the topology:
Server object: All domain controllers are identified as server objects in the configuration directory partition, broken down by site.
The NTDS Settings object: Each server object that represents a domain controller has a child NTDS Settings object, which identifies the domain controller as having Active Directory installed. The NTDS Settings object must be present for the server to be considered as part of the replication topology. The presence of these objects also determines the site in which the domain controller is to be located. For example, the distinguished name of the NTDS Settings object contains the site to which that domain controller belongs. If the server is physically located in one site but is configured for another site in Active Directory, the KCC uses the information in Active Directory to construct the topology. Therefore, the improper configuration of servers in sites can affect network bandwidth. Within a site, all KCCs generate connection objects for replication within the site. When there is more than one site, a single KCC in each site generates all connection objects for replication between sites.
1.2. Overview of AD DS Sites and Replication

Within a single site, replication happens quickly and automatically. Every time a change is made, it is automatically replicated after waiting 15 seconds by default. In this configuration, AD DS does not care of the network utilization because we are in Local Area Networks (LANs). However, some organizations have multiple locations that are connected by slow network connections. With AD DS sites, we will be able to control replication and network traffic between these different locations, in general branch offices.
1.2.1. AD DS Sites and Site Links

These sites are groups of well-connected computers. When you establish sites, domain controllers within a 49
Created by XMLmind
XSL-FO Converter.
single site communicate frequently. This communication minimizes the latency within the site; that is, the time required for a change that is made on one domain controller to be replicated to other domain controllers. You create sites to optimize the use of bandwidth between domain controllers that are in different locations. You use sites to control replication traffic, logon traffic, and client computer requests to the global catalog server. In Active Directory, sites help define the physical structure of a network. A set of TCP/IP subnet 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. Subnet objects identify the network addresses that are used to map computers to sites. A subnet is a segment of a TCP/IP network to which a set of logical IP addresses are assigned. Because the subnet objects map to the physical network, so do the sites. For example, if three subnets are located at three campuses in a city, and these campuses are connected by high-speed, highly available connections, you could associate each of those subnets with one site. A site can consist of one or more subnets. For example, on a network that has three subnets in Redmond and two in Paris, you can create a site in Redmond, a site in Paris, and then add the subnets to the respective sites. Active Directory creates a default site when you install the first domain controller in a forest. By default, this site is called Default-First-Site-Name. You can rename this site to a more descriptive name of your choice. When you create your first domain in a forest, Active Directory automatically places it in the default site. Site links are used to represent the wide area network connections between sites. They are used by AD DS to know when replication occurs between sites and the best path to use to replicate directory partitions between sites. You have several parameters to configure on a site link:
Cost: The cost is a value that you configure on site links to represent the bandwith of the connection between sites. If you have multiple paths between two sites, AD DS will select the path with the lowest cost.
Replication frequency: Determine the frequency basis for replication on this site link. If you put the value 60, it means replication will occur every hour on this site link.
Schedule: Determines when the replication can occur. You can specify time ranges during when replication is 50
Created by XMLmind
XSL-FO Converter.
possible on this site link and when it is not.
To manage sites, site links and subnets, you have to use the Active Directory Sites and Services console.
1.2.2. Comparing Replication Within Sites and Between Sites

Replication within sites:
The network connections within a site are both reliable and have sufficient available bandwidth.
Replication traffic within a site is not compressed because a site assumes fast, highly reliable network links. Not compressing replication traffic helps reduce the processing load on the domain controllers. However, uncompressed traffic may increase the network bandwidth that replication messages require.
A change notification process initiates replication within a site. Replication between sites:
The network links between sites have limited available bandwidth and may not be reliable.
Replication traffic between sites is designed to optimize bandwidth by compressing all replication traffic between sites. Replication traffic is compressed to 10 - 15 percent of its original size before it is transmitted. Although compression optimizes network bandwidth, it imposes an additional processing load on domain controllers, both when it compresses and decompresses replication data.
Replication between sites happens automatically after you define configurable values, such as a schedule or a replication interval. You can schedule replication for inexpensive or off-peak hours. By default, changes are replicated between sites according to a schedule that you define manually, not according to when changes occur. The schedule determines when replication can occur. The interval specifies how often domain controllers check for changes during the time that replication can occur.
1.2.3. Inter-Site Topology Generator

One domain controller per site assumes the role of the intersite topology generator. The KCC on this domain controller is reponsible for creating the connections between the domain controllers in its site and the domain controllers in other sites, which includes specifically the inbound connection objects for all bridgehead servers in the site in which the domain controller is located.
51
Created by XMLmind
XSL-FO Converter.
If the intersite topology generator determines that its own site is the only site, it performs no further processing because no connections between sites are possible for the current configuration. The current owner of the intersite topology generator role is communcated through the normal Active Directory replication process. Initially, the first domain controller in the site becomes the ISTG for the site. The role does not change as additional domain controllers are added to the site until the current intersite topology generator becomes unavailable. To determine the ISTG role owner for a site, use the Active Directory Sites and Services console, access the NTDS Site Settings Properties for the site you want. The current role owner appears in the Server box under Inter-Site Topology generator.
1.2.4. Transport Protocols

A transport protocol is a common language that computers share in order to communicate during replication. Active Directory uses only one protocol for replication within a site. When you create a site link, you must choose to use one of the following transport protocols:
Remote Procedure Call (RPC) over IP. RPC is the default protocol. An industry standard protocol for client/server communications, RPC over IP provides reliable, high-speed connectivity within sites. Between sites, RPC over IP enables replication of all Active Directory partitions. RPC over IP is the best transport protocol for replication between sites.
Simple mail transfer protocol (SMTP). SMTP supports replication of the schema, configuration, and global catalog between sites and between domains. You cannot use this protocol for replication of the domain partition, because some domain operations -for example, Group Policy - require the support of the File Replication service (FRS), which does not support an asynchronous transport for replication. If you use SMTP, you must install and configure a certificate authority to sign the SMTP messages and ensure the authenticity of directory updates. Additionally, SMTP does not provide the same level of data compression as RPC over IP.
1.2.5. Unidirectional Replication

Unidirectional replication is a fundamental change from the multimaster replication model which is normally 52
Created by XMLmind
XSL-FO Converter.
applied in Active Directory Domain Services. This feature is used by Read-Only Domain Controllers. Because no changes are written directly to the RODC, no changes originate at the RODC. Accordingly, writable domain controllers that are replication partners do not have to pull changes from the RODC. This means that any changes or corruption that a malicious user might make at branch locations cannot replicate from the RODC to the rest of the forest. This also reduces the workload of bridgehead servers in the hub and the effort required to monitor replication. The RODC will only have an inbound connection object to other Windows Server 2008 writeable domain controllers in the domain. There is not outbound connection. This means the RODC cannot initiate replication and cannot notify other domain controllers of changes. This is a new layer of security. RODC unidirectional replication applies to both AD DS and Distributed File System (DFS) Replication of SYSVOL. The RODC performs normal inbound replication for AD DS and SYSVOL changes.
1.3. Configuring and Monitoring AD DS Replication

Once you have configured the sites and site links for your AD DS environment, you can configure AD DS replication. AD DS in Windows Server 2008 provides several options that you can use to manage how replication will flow between sites. Because AD DS replication is so critical to your environment, you also need to know how to monitor AD DS replication.
1.3.1. Bridgehead Servers

The bridgehead server is a domain controller that you designate 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 sites bridgehead server, which replicates the changes to all domain controllers in the site. You must designate a bridgehead server for each partition in the site. For example, a domain controller can be the bridgehead server for the forest-wide schema and configuration partitions, as well as the domain partition for the domain that it represents. If there are other domains in the site, you must assign a bridgehead server for each domain. The bridgehead server at each site is automatically selected, or you can specify a list of preferred bridgehead servers. To ensure efficient updates to the directory, a preferred bridgehead server must have the processing power and bandwidth to efficiently compress, send, receive, and decompress replication data. Active Directory uses only one bridgehead server at any time. If the first preferred server becomes unavailable, another one on the preferred list is used. If your deployment uses a firewall to protect a site, you must designate the firewall proxy server as the preferred bridgehead server, which makes it the contact point for exchanging information with other sites. If you do not do this step, Active Directory may not replicate the directory information successfully.
53
Created by XMLmind
XSL-FO Converter.
1.3.2. Site Link Bridging

By default, all AD DS site links are transitive or bridged. That means that if site A has a common site link with site B, site B also has a common site link with site C, and the two site links are bridged. Domain controllers in site A can replicate directly with domain controllers in site C, even though there is no site link between sites A and C. When site links are bridged, replication is transitive between sites and the costs that are assigned to site links are cumulative; the lowest-cost route between sites that have more than one site link is the route that replication takes. By default, site link costs are equal, with a cost of 100 on each new site link. For this reason, with no changes to the default site link cost, a hub-and-spoke topology favors the replication route between the hub site and each branch site, rather than between branch sites. The cost to replicate to and from two branch sites is always higher than the cost to replicate to and from the hub site. Therefore, replication between branch sites occurs only if no domain controller for the domain is available in the hub site. You can modify the default site link bridging configuration by disabling site-link bridging and then configuring site link bridging only for those site links that should be transitive.
In this picture, only connections that are used to replicate Schema and Configuration partitions are shown.
54
Created by XMLmind
XSL-FO Converter.
1.3.3. Effects of Disabling Site Link Bridging

You can disable the default site link bridging by desabling the Bridge all site link setting in the properties of the IP container in the Active Directory Sites and Services console. If you disable site link bridging on all site links by default, no replication will occur between San Francisco and London if domain controllers from Paris are unavailable, in our example. You can create site link bridges manually if you want in the Active Directory Sites and Services console.
1.3.4. Universal Group membership Caching

One of the issues that you may need to address when configuring AD DS replication is whether to deploy global catalog servers in each site. Because global catalog servers are required when users log on to the domain, deploying a global catalog server in each site optimizes the user experience. However, deploying a global catalog server in a site results in additional replication traffic, which may be an issue if the network connection between AD DS sites has limited bandwidth. In these scenarios, you can deploy domain controllers running Windows Server 2008 and then enable universal group membership caching for the site. Information is stored locally once this option is enabled and a user attempts to log on for the first time. The domain controller obtains the universal group membership for that user from a global catalog. Once the universal group membership information is obtained, it is cached on the domain controller for that site indefinitely and is periodically refreshed. The next time that user attempts to log on, the authenticating domain controller running Windows Server 2008 will obtain the universal group membership information from its local cache without the need to contact a global catalog. By default, the universal group membership information contained in the cache of each domain controller will be refreshed every 8 hours. To refresh the cache, domain controllers running Windows Server 2003 will send a universal group membership confirmation request to a designated global catalog. Up to 500 universal group memberships can be updated at once. Universal group membership caching can be enabled using Active Directory Sites and Services. The following list summarizes potential benefits for caching universal group memberships in branch office locations:
Faster logon times since authenticating domain controllers no longer need to access a global catalog to obtain universal group membership information.
No need to upgrade hardware of existing domain controllers to handle the extra system requirements necessary for hosting a global catalog.
Minimized network bandwidth usage since a domain controller will not have to handle replication for all of the objects located in the forest.
1.3.5. Tools for Monitoring and Managing Replication

To manage and monitor replication, you have different tools you can use:
Active Directory Sites and Services: MMC used to manage the physical structure (sites, site links, subnets) and replication in your forest. Most of the common tasks concerning replication can be performed from this console
Repadmin: Command-line used to administer replication. You can perform all the replication configuration from this tool.
55
Created by XMLmind
XSL-FO Converter.
DcDiag: Command line tool that you can use to monitor replication between domain controllers.
56
Created by XMLmind
XSL-FO Converter.
Chapter 6. Creating and Configuring Group Policies

Group Policies and Active Directory infrastructure in Windows Server 2008 enable IT administrators to automate management of users and computers in the network environment, which simplifies administrative tasks and reduces IT costs. With Group Policies, administrators can implement security settings, environment settings, enforce IT policies and distribute software accross a range of user or computer accounts. After completing this lesson, you will be able to:
Understand what are Group Policies
Configure the Scope of Group Policy Objects
Understand how Group Policy Objects are applied
Manage Group Policy Objects
Delegate administrative control of Group Policies
1. Course
1.1. Overview of Group Policies
This lesson introduces you how you can use Group Policies to simplify the management of users and computers in an Active Directory infrastructure. You will learn how Group Policies are structured and applied.
1.1.1. Introduction to Group Policies

Group Policy is an infrastructure used to deliver and apply one or more desired configurations or policy settings to a set of targeted users and computers within an Active Directory environment. This infrastructure consists of a Group Policy engine and multiple client-side extensions (CSEs) responsible for writing specific policy settings on target client computers. Group Policies are very useful to apply specific configurationparameters to user and computers centrally. It means you will not need to move on every computer and modify every user account manually. You just need to edit Group Policy Objects (GPOs) policy settings in Active Directory and to target the GPO at the intended computers or users. In this way, you can manage potentially thousands of computers or users at the same time by modifying the settings of a single GPO. Group Policies are mainly used to:
Apply standard configurations for computers or users
Deploy software
Enforce security settings, for example password policies.
57
Created by XMLmind
XSL-FO Converter.
Enforce a consistent desktop environment. For example, you can configure the desktop wallpaper or prohibit access to some Windows components like the Control Panel... By default, in each domain, you have two Group Policy Objects created and configured.
Default Domain Controller Policy: This GPO enforces some settings for all domain controllers in the domain. It is linked on the Domain Controllers OU.
Default Domain Policy: This GPO enforces some settings for all computer and user accounts in the domain. For example, in this GPO, you have a default password policy that applies on all computers in the domain, like password complexity, password length, age, etc... Group Policy settings are contained in Group Policy objects (GPOs), which live in the domain and can be linked to the following Active Directory containers: sites, domains, or organizational units (OUs).
1.1.2. Group Policy Settings

A Group Policy Object contains different settings for computers and users, that's why when you configure a GPO, you will find two different parts wether you want to configure settings for user accounts or computers accounts. There are thousands of configurable settings (approximately 2,400). With all these settings, you can configure most of the areas of the target environment. However, some settings cannot be applied to all versions of Windows operating systems. For example, some settings came with Windows 2000 or Windows XP or Windows Vista and they can only be applied on those versions or newer. With Windows Server 2008 AD DS, a lot of new settings are applicable only on Windows Vista or Windows Server 2008. If a target computer cannot process a setting which is applied, it simply ignores it.
1.1.3. Application of Group Policies

Clients get Group Policy settings from Active Directory. When the computer starts:
Computer settings are applied
58
Created by XMLmind
XSL-FO Converter.
Startup scripts run For client computers and member servers, group policies are also refreshed every 90 minutes and a random time between 0 and 30 minutes to avoid that every computer refresh group policies at the same time. You can configure this refresh interval. When the user logs on:
User settings are applied
Logon scripts run User settings are also refreshed every 90 minutes and a random time between 0 and 30 minutes. For domain controllers, Group Policies are refreshed every 5 minutes to ensure that settings for domain controllers are applied as soon as possible.
1.1.4. Exceptions to Normal Group Policy Processing

Some factors can change the normal Group Policy processing behavior, for example when logging on using a slow connection. On slow links:
500 Kbps by default
Certain client side extensions are not processed
Prior to Vista, ICMP is used to detect slow link
Vista uses Network Location Awareness Cached credentials:
Windows XP and Vista use cached credential for faster logons
Many GPO settings take two logons to take effect Additional exceptions:
Remote access connections
Moving a user or computer object in Active Directory
1.1.5. Group Policy Components

The content of a GPO is stored in two locations: the Group Policy container (GPC) and the Group Policy template (GPT).
The Group Policy Container (GPC) is stored in Active Directory under the CN=Policies, CN=System 59
Created by XMLmind
XSL-FO Converter.
container within each domain. It contains GPO status, version information, WMI filter information, and a list of components that have settings in the GPO. Computers can access the GPC to locate Group Policy templates, and domain controllers can access the GPC to obtain version information. If the domain controller does not have the most recent version of the GPO, replication occurs to obtain the latest version of the GPO.
The Group Policy Template (GPT) is a folder hierarchy in the SYSVOL shared folder, under Policies folder, on a domain controller. When you create a GPO, Windows Server 2003 creates the corresponding GPT, which contains all Group Policy settings and information, including administrative templates, security, software installation, scripts, and folder redirection settings. Computers connect to the SYSVOL folder using SMB (Server Message Block) to obtain the settings. The name of the GPT folder is the globally unique identifier (GUID) of the GPO that you created. It is identical to the GUID that Active Directory uses to identify the GPO in the GPC. The path to the GPT on a domain controller is %systemroot%\SYSVOL\sysvol.
1.1.6. ADM and ADMX Files

Administrative Template (ADM) files are used to populate user interface settings in the Group Policy Object Editor, enabling administrators to manage registry-based policy settings. Each successive Windows operating system and service pack includes a newer version of these .adm files. . ADM files use their own markup language. Because of this, it is difficult to customize ADM files. The ADM templates are located in the %SystemRoot%\Inf folder. Windows Vista and Windows Server 2008 introduce a new format for displaying registry-based policy settings. Registry-based policy settings are defined using a standards-based XML file format known as ADMX files. These new files replace ADM files. Group Policy tools on Windows Vista and Windows Server 2008 will continue to recognize custom ADM files you have in your existing environment, but will ignore any ADM file that ADMX files have superseded. It can be useful interesting to create custom administrative template files to be able to manage applicationspecific registry settings. For example, you have an intern application and you want to be able to manage registry settings for this application using Group Policies.
1.1.7. The Central Store

For domain-based enterprises, administrators can create a central store location of ADMX files that is accessible by anyone with permission to create or edit GPOs. The Group Policy Object Editor on Windows Vista and Windows Server 2008 automatically reads and displays Administrative Template policy settings from ADMX files that the central store caches and ignores the ones stored locally. If the domain controller is not available, then the local store is used. You must create the central store, and update it manually, on a domain controller. The use of ADMX files is dependant on the computers operating system where you are creating or editing the GPO. Therefore, the domain controller can be a server with Windows Server 2000, 2003, or 2008. The File Replication Service (FRS) will replicate it to that domains other controllers. To create the central store, you have to create the following folder on a domain controller: %systemroot%\sysvol\domain\policies\PolicyDefinitions Create a subfolder of %systemroot%\sysvol\domain\policies\PolicyDefinitions for each language your Group Policy administrators will use. Each subfolder is named after the appropriate ISO-style Language/Culture Name. For example, to create a subfolder for United States English, create the subfolder: %systemroot%\sysvol\domain\policies\PolicyDefinitions\EN-US For France French, it will be: %systemroot%\sysvol\domain\policies\PolicyDefinitions\FR-FR
1.2. Configuring the Scope of Group Policy Objects

There are many different ways to change how Group Policies are applied. You can control the default
60
Created by XMLmind
XSL-FO Converter.
processing order through enforcement, blocking inheritance, security filtering, and Windows Management Instrumentation (WMI) filters or using the loopback processing mode. In this part, you will learn about these possibilities.
1.2.1. Group Policy Processing Order

Group Policies are applied in a particular order. First Local Group Policies are processed, then GPOs linked at the site level, then at the domain level, and finally at the OU level. This order means that settings that are processed first may be overwritten by settings that are processed later. For example, a policy that changes the Desktop Wallpaper applied at the domain level could be replaced by a policy applied at the OU level for that particular OU.
1.2.2. Multiple Local Group Policies

In Microsoft operating systems prior to Windows Vista, there was only one user configuration available in the local Group Policy. That configuration was applied to all users logged on from the local computer. This is still true, but Windows Vista and Windows Server 2008 have an added feature. In Windows Vista and Windows Server 2008, it now is possible to have different user settings for different local users, although there remains only one computer configuration available that affects all users.
1.2.3. Options for Modifying Group Policy Processing

Sometimes, you might want to modify the default processing order. For example, you want to apply restrictive Group Policies to certain users or groups. Often, you don't want to apply restricting Group Policies to the IT administrators. Maybe, you don't want an OU to inherit Group Policies applied on higher levels or Group Policies should be applied only to computers with specific hardware or software characteristics. By default, all Group Policies apply to the Authenticated Users group in a given container, but you can modify that behavior through different methods.
Block inheritance: If you don't want an OU to inherit Group Policies applied on a higher level, you can block inheritance on this OU. To block inheritance, in the Group Policy Management console, right click on the concerned OU and then select Block inheritance.
61
Created by XMLmind
XSL-FO Converter.
Enforcement: You can enforce the application of a Group Policy to ensure that the settings configured on this Group Policy will be applied even if there are conflicts with Group Policy settings applied on a lower level, or even if inheritance is blocked somewhere. To enforce the application of a GPO, in the Group Policy Management console, select the link concerned, right click and select Enforce.
Filtering using security groups or WMI filters : By default, all Group Policies are applied to the Authenticated Users group on each container. By filtering using security groups, you can specify on which groups this GPO will be applied. WMI filters allow you to specify hardware or software characteristics to filter dynamically on which computer the GPO will apply. A common example is when you deploy a software with Group Policies. You want to ensure that this software will be deployed only if the target computer has at least 1GB of free disk space. You can do it using WMI filters.
62
Created by XMLmind
XSL-FO Converter.
Disabling GPOs: You can disable a GPO. When you perform this action, the GPO is still created and linked to the different containers you linked it before, but the settings from this GPO will not apply anymore, until it is enabled again.
Loopback processing mode
1.2.4. Loopback Processing Mode

Loopback is an advanced Group Policy setting that is useful on computers in certain closely managed environments, such as servers, kiosks, laboratories, classrooms, and reception areas. Setting loopback causes the User Configuration settings in GPOs that apply to the computer to be applied to every user logging on to that computer, instead of, or in addition to, the User Configuration settings of the user. This allows you to ensure that a consistent set of policies is applied to any user logging on to a particular computer, regardless of their location in Active Directory. Loopback is controlled by the setting, User Group Policy loopback processing mode, which is located in Computer Configuration\Policies\Administrative Templates\System\Group Policy. Loopback only works when both the user account and the computer account are in a Windows 2000 or later domain. Loopback does not work for computers joined to a workgroup. Loopback is not enabled if the computer or user is not in an Active Directory domain. Normally, user policy settings are derived entirely from the GPOs associated with the user account based on it's location in the Active Directory. Loopback processing directs the system to apply an alternate set of user settings for the computer to any user who logs on to a computer affected by this policy. This policy is intended for special-use computers where you must modify the user policy based on the computer that is being used, for example, computers in public areas or classrooms. When loopback is applied, it will affect all users, except local users. Loopback operates using the following two modes:
Merge mode : Merges the user settings configured on GPOs that apply to the user account with user settings configured on GPOs that apply to the computer account. If there are conflicts, user settings from GPOs applying on the computer account are applied.
Replace mode: Applies only the user settings coming from GPOs that apply on the computer account.
1.3. Evaluating the Application of Group Policy Objects

63
Created by XMLmind
XSL-FO Converter.
System administrators need to know how policy settings affect computers and users in a managed environment. This information is essential when planning policy for a network and when debugging existing policy. Obtaining the information can be a complex task when you consider the many combinations of sites, domains, and organizational units that are possible, and the many types of Group Policy settings that can exist. Further complicating the task are securitygroup filtering and the inheritance, blocking, and enforcement of Group Policies. The GPResult command-line tool and the Group Policy Management Console (GPMC) provide reporting features to simplify these tasks.
1.3.1. Group Policy Reporting

Group Policy reporting is a feature that makes implementation and troubleshooting easier. There are two main tools for Group Policy Reporting, the GPResult.exe command-line tool and the Group Policy Results wizard in the Group Policy Management Console. They allow administrators to determine the settings that were applied to a given computer and/or user that logged on to that computer. To be able to perform reporting, the target computer must be running.
Both tools are similar but they each provide different information.
64
Created by XMLmind
XSL-FO Converter.
To get help on the GPResult.exe command-line tool, you can run the gpresult /? command.
1.3.2. Group Policy Modeling

Another method for testing Group Policy is to use the Group Policy Modeling Wizard in the GPMC to model environment changes before you actually make them. The Group Policy Modeling Wizard calculates the simulated net effect of GPOs. Group Policy Modeling also simulates such things as security group membership, WMI filter evaluation, and the effects of moving user or computer objects to a different OU or site. You also can specify slow-link detection, loopback processing, or both when using the Group Policy Modeling Wizard. The Group Policy Modeling process actually runs on a domain controller in your Active Directory domain. Because the wizard never queries the client computer, it cannot take local policies into account.
1.4. Managing Group Policy Objects

1.4.1. Copying GPOs
A copy of a GPO transfers only the settings in the GPO. The newly created GPO has a new GUID and the default discretional access control list (DACL) for the GPO. The new GPO is created unlinked because links are a property of the object that defined the GPO, rather than a property of the GPO. When you copy a GPO from one domain to another, you must specify the mapping behavior of the security principals for the copy operation. Group Policy Management provides two basic mapping techniques for copying GPOs:
Copy them identically from the source
Use a migration table to map them to new values in the new GPO
1.4.2. Backup and Restore GPOs

When Group Policy Management backs up a GPO, it exports the data to a file that you choose and saves all Group Policy template (GPT) files. You can send the backed-up GPO to a folder by using a restore or import operation. You can only restore a backed-up GPO to another domain by using an import operation. You can back up one or more GPOs to a previously specified backup location, or you can specify a new backup location. The restore operation returns the content of the GPO to the same state it was when the backup was performed. This operation is only valid in the domain where the GPO was created.
1.4.3. Import GPOs

An import operation copies all of the GPO settings from the source GPO to the destination GPO. You specify a migration table to ensure that the UNC path in the source GPO maps correctly to the UNC path of the destination GPO. You provide the path to the appropriate migration table when you import GPO settings from one domain to another. If you specify a migration table, you must specify the UNC path mapping behavior. If you do not select the Use migration table exclusively check box, you must specify the mapping behavior for security principals that are not contained in the migration table. If you do not specify a migration table, all security principals are mapped according to the behavior that you specify.
1.4.4. Starter GPOs

Starter GPOs store a collection of Administrative Template policy settings in a single object. Starter GPOs only contain Administrative Templates. You can import and export Starter GPOs to distribute them to other areas of your enterprise. 65
Created by XMLmind
XSL-FO Converter.
1.5. Delegating Administrative Control of Group Policies

In important IT infrastructures, there are multiple administrators and sometimes they can be dedicated to specific administrative tasks. By delegating control of GPOs, you will be able to allow other user or groups to modify specific GPOs. The goal is always to give the minimum amount of permissions.
1.5.1. Options for Delegating Control of GPOs

Delegation allows the administrative workload to be distributed across the enterprise. One group could be tasked with creating and editing GPOs, while another group performs reporting and analysis duties. A separate group might be in charge of WMI filters. The following Group Policy tasks can be independently delegated:
Creating Group Policy objects: You can put user or group accounts in the Group Policy Creator Owners group or you can explicitly assign permissions on the Group Policy Objects container in the GMPC.
Editing Group Policy objects: You can assign edit permissions on individual policies to specific users or groups.
Managing Group Policy links for a site, domain, or OU: You can assign the right to link GPOs on a site, domain, or OU using the GPMC.
Perform Group Policy Modeling analyses on a given domain or OU
Read Group Policy Results data for objects in a given domain or OU
Create WMI filters in a domain: You can assign the right to create WMI filters on the WMI Filters container using the GPMC.
66
Created by XMLmind
XSL-FO Converter.
Chapter 7. Configuring User Environments Using Group Policies

This lesson introduces how to configure the user environment using Group Policy. You will learn how to configure scripts or folder redirection, how to configure administrative templates and how to deploy software using Group Policy. After this lesson, you will be able to:
Configure user environment using Group Policy
Configure scripts and folder redirection
Configure administrative templates
Deploy software
1. Course
1.1. Configuring Group Policy Settings
We have seen in the previous lesson that there are a lot of different Group Policy settings. Some settings are very simple and you can only choose to enable or disable them, but some others are more complex and can require more configuration. In this part, we will see how to configure various settings.
1.1.1. Options for COnfiguring Group Policy Settings

Generally, Group Policy settings have only three states that you can configure:
Enabled: it means the setting will be applied. For example if the setting is "Prohibit access to the Control Panel", users affected by this setting will not beto remove and prevent access able to access the Control Panel except if a lower Group Policy specifies the contrary.
Disabled: It means this setting will not be applied. In our example, if a domain level policy prohibits access to the Control Panel and you want users in the Admin OU to have access to the Control Panel. You can configure a new Group Policy at the Admin OU level wi th setting "Prohibit access to the Control Panel" set to Disabled.
Not configured: It means the setting is not configured so clients will ignore it. Be careful of the sense of a setting when you configure it. If you want to remove and prevent access to the Shut Down, Restart, Slepp, and Hibernate commands in the Start menu, you have to enable the "Remove and prevent acces to the Shut Down, Restart, Sleep, and Hibernate commands" setting and not disable it.
67
Created by XMLmind
XSL-FO Converter.
But you have settings that require a more complex configuration with multiple values. If there is a conflict between two values in 2 different GPOs, all the values from the wiining GPO are applied.
1.2. Configuring Scripts and Folder Redirection using Group Policies

With Active Directory Domain Services, it is possible to configure scripts for users or computers. A script is a file containing multiple commands that you can execute to perform some administrative tasks. With Group Policies, you can also redirect folders contained in the user's profile from the user local hard disk to a central server, a shared folder.
1.2.1. What Are Group Policy Scripts

You can use scripts to perform any number of tasks. There may be actions that you need performed every time a computer starts or shuts down, or when users log off or on. For example, you can use scripts to clean up desktops when users log off and shut down computers, or delete the contents of temporary directories or clear 68
Created by XMLmind
XSL-FO Converter.
the pagefile to make the environment more secure. You can use Group Policies to assign different kind of scripts. In Computer Configuration\Policies\Windows Settings\Scripts (Startup/Shutdown):
Startup scripts: scripts that are executed when the computer starts.
Shutdown scripts: scripts that are executed when the computer shuts down. By default, startup scripts run synchronously. It means that the system wait for each script to complete before it runs the next startup script. You can change this behaviour with Group Policy by enabling the setting you can find in: Computer Configuration\Policies\Administrative Templates\System\Scripts\ Run startup scripts asynchronously In UserConfiguration\Policies\Windows Settings\Scripts (Logon/Logoff):
Logon scripts: scripts that are executed when the user logs on to a computer.
Logoff scripts: scripts that are executed when the user logs off. By default, logon scripts run asynchronously. It means all configured scripts run at the same time when the user logs on. You can change this behaviour on computers with Group Policy by enabling the setting that you can find in: Computer Configuration\Policies\Administrative Templates\System\Scripts\ Run logon scripts synchronously Here is an example of logon script used to map a network drive automatically when users log on to a computer. In this example, we map the Accounting shared folder to the Z: drive on the computer. We configure this script in a Group Policy linked to the Accounting organizational unit. As a result, everytime a user account from the Accounting OU is used to log on to a computer, the network drive will be created on this computer.
Example 7.1. Logon Script to Map a Network Drive

[CODE:vb]Set objNetwork = Wscript.CreateObject("WScript.Network") objNetwork.MapNetworkDrive "G:","\\dc1-paris.supinfo.lan\Accounting" msgbox Accounting share was successfully mapped!
1.2.2. What Is Folder Redirection

When you redirect folders, you change the folders storage location from the local hard disk on the users computer to a shared folder on a network file server. After you redirect a folder to a file server, it still appears to the user as if it is stored on the local hard disk. Folder Redirection makes it easier for you to manage and back up data. By redirecting folders, you can ensure user access to data regardless of the computers to which they log on. Here is the list of the default folders you can redirect:
My Documents (Documents in Windows Vista)
Application Data (AppData in Windows Vista)
Desktop
69
Created by XMLmind
XSL-FO Converter.
Start Menu In Windows Vista, you can redirect some extra folders:
Contacts
Downloads
Favorites
Searches
Links It can be interesting when you want users to share the same content for some of these folders, or when you want to give access to the content of this folders regardless of the computers to which the users log on to. It means, if you redirect the Documents folder on a file server, the users will be able to access their documents on every computer and not only on the computer where they created their documents. Folder redirection works with the Offline Files feature, so you have a synchronization between files on the server and files on the client computer. You have also a local cached copy on the client computer to let them access their files even when they can't connect to the server. (mobile users, network problem....)
1.2.3. Folder Redirection Configuration Options

There are three available settings for Folder Redirection: none, basic, and advanced. Basic folder redirection is for users who must redirect their folders to a common area or users who need their data to be private. Advanced redirection allows you to specify different network locations for different Active Directory security groups. You have different options concerning the target folder location:
Redirect to the users home directory
Create a folder for each user under the root path
Redirect to the following location
Redirect to the local userprofile location
1.2.4. Options for Securing Redirected Folders

You must create a shared network folder manually to store the redirected folders. Folder Redirection can create the users redirected folders for you. When you use this option, the correct permissions are set automatically. If you manually create folders, you must know the correct permissions.
70
Created by XMLmind
XSL-FO Converter.
1.3. Configuring Administrative Templates

The Administrative Template files provide the majority of available policy settings, which are designed to modify specific registry keys. This is known as registry-based policy. For many applications, the use of registrybased policy that the Administrative Template files deliver is the simplest and best way to support centralized management of policy settings. In this lesson, you will learn how to configure Administrative Templates.
1.3.1. What Are Administrative Templates

Administrative Templates allow you to control the environment of the operating system and user experience. There are two sets of Administrative Templates: one for users and one for computers. Administrative Templates are the primary means of configuring the client computers registry settings through Group Policy. Administrative Templates are a repository of registry-based changes. By using the Administrative Template sections of the GPO, you can deploy hundreds of modifications to the computer (the HKEY_LOCAL_MACHINE hive in the registry) and user (the HKEY_CURRENT_USER hive in the registry) portions of the Registry. Administrative Templates sections for computers:
Windows Components
System
Network
Printers Administrative Templates sections for users:
71
Created by XMLmind
XSL-FO Converter.
Windows Components
Start menu and taskbar
Desktop
Control panel
Shared folders
Network
System
1.4. Deploying Software Using Group Policy

Windows Server 2008 includes a feature called Software Installation and Maintenance that uses Active Directory Domain Services (AD DS) and Group Policy and the Microsoft Windows Installer service to install, maintain, and remove software on your organizations computers.
1.4.1. Software Installation and Maintenance Process

The software life cycle consists of four phases: preparation, deployment, maintenance, and removal. You can apply Group Policy settings to users or computers in a site, domain, or an organizational unit to install, upgrade, or remove software automatically. By applying Group Policy settings to software, you can manage the various phases of software deployment without deploying software on each computer individually. 11. Preparation. You must first determine if you can deploy the software by using the current Group Policy object (GPO) structure. You also must identify risks in using the current infrastructure that may prevent software installation. You prepare the files that enable an application to be deployed with Group Policy by copying the Windows Installer package files for an application to a software distribution point, which can be a shared folder on a server. You can acquire a Windows Installer package file from the applications vendor, or you can create a package file by using a third-party utility. 12. Deployment. You create a GPO that installs the software on the computer and links the GPO to an appropriate Active Directory container. The software is installed when the computer starts or when a user starts the application. 13. Maintenance. You upgrade software with a new version or redeploy software with a service pack or software update. The software is then automatically upgraded or redeployed when the computer starts or when a user starts the application. 14. Removal. To eliminate software that is no longer required, you remove the software package setting from the GPO that originally deployed the software. The software is then automatically removed when the computer starts or when a user logs on.
1.4.2. Software Distribution Components

To enable Group Policy to deploy and manage software, Windows Server 2008 uses the Windows Installer service. This component automates the installation and removal of applications by applying a set of centrally 72
Created by XMLmind
XSL-FO Converter.
defined setup rules during the installation process. Windows Installer contains two components:
Windows Installer service. This client-side service fully automates the software installation and configuration process. The Windows Installer service can also modify or repair an existing installed application. It installs an application either directly from the CD-ROM or by using Group Policy. To install an application, the Windows Installer service requires a Windows Installer package.
Windows Installer package. This package file contains all of the information that the Windows Installer service requires to install or uninstall software. A package file contains:
A Windows Installer file with an .msi extension.
Any external source files that are required to install or uninstall the software.
Standard summary information about the software and the package.
The product files or a reference to an installation point where the product files reside.
1.4.3. Options for Installing Software

There are two deployment types available for delivering software to clients. Administrators can either install software for users or computers in advance or give users the option to install the software when they require it. Users do not share deployed applications, meaning an application you install for one user through Group Policy will not be available to that computers other users. Each user needs his or her own instance of the application.
1.4.4. Assigning Software

By assigning software, you ensure that the software is always available to the user. Start menu shortcuts, and desktop icons for the application, appear when the user logs on. For example, if the user opens a file that uses Microsoft Excel on a computer that does not have Excel, but Excel has been assigned to the user, Windows Installer installs Excel on that computer when the user opens the file. In addition, assigning software makes the software resilient. If for any reason the user deletes the software, Windows Installer reinstalls it the next time the user logs on and starts the application. You can't assign software to a domain controller.
1.4.5. Publishing Software

By publishing software, you ensure that the software becomes available for users to install on their computers. Windows Installer adds no shortcuts to the users desktop or Start menu, and no local registry entries are made. Because users must install the published software, you can publish software only to users, not to computers.
1.4.6. Software Modification

Deploying several configurations of one application enables different groups in your organization to use a software package in different ways. You can use software modifications, or .mst files (also called transform files), to deploy several configurations of one application. An .mst file is a custom software package that modifies how Windows Installer installs the associated .msi package. Windows Installer applies modifications to packages in the order that you specify. To save modifications to an .mst file, you run the custom installation 73
Created by XMLmind
XSL-FO Converter.
wizard, and then choose the .msi file on which to base transforms. You must determine the order in which to apply transform files before assigning or publishing the application.
1.4.7. Software Categories

You can create software categories to arrange different applications under a specific heading. Instead of relying on a single alphabetical list of applications that is available by default, you can organize software into categories, such as Graphics, Microsoft Office, and Accounting categories. Users can then choose which applications from the categories to install in Add or Remove Programs.
1.4.8. Software Association

A client computer maintains a list of extensions and registered applications that use those extensions. When a user double-clicks an unknown file type, Windows Installer uses this list to install an application. Administrators cannot dictate the contents of this list, but they can determine the priority for installing or starting applications upon document activation.
1.4.9. Software Upgrades

There are three types of upgrades:
Mandatory upgrades: These upgrades automatically replace an old version of software with an upgraded version. For example, if users currently use software version 1.0, this version is removed, and software version 2.0 is installed the next time that the computer starts or the user logs on.
Optional upgrades: These upgrades allow users to decide when to upgrade to the new version. For example, users can determine if they want to upgrade to version 2.0 of the software or continue using version 1.0.
Selective upgrades: If some users require an upgrade but not others, you can create multiple GPOs that apply to the users who require the upgrade and create the appropriate software packages in them.
1.4.10. Software Redeployment

When you mark a package file for redeployment, the software is advertised to everyone who has been granted access to the application, either through assigning or publishing. Then, depending on how the original package was deployed, one of the three scenarios occurs:
When you assign software to a user, the Start menu, desktop shortcuts, and registry settings that are relevant to the software are updated the next time the user logs on. The next time the user starts the software, the service pack or software update is automatically applied.
When you assign software to a computer, the service pack or software upgrade is automatically applied the next time the computer starts.
When you publish and install software, the Start menu, desktop shortcuts, and registry settings that are relevant to the software are updated the next time the user logs on. The next time the user starts the software, the service pack or software upgrade is automatically applied.
1.4.11. Removing Deployed Software

There are two removal methods:
Forced removal: You can force the removal of the software, which automatically deletes it from a computer 74
Created by XMLmind
XSL-FO Converter.
the next time the computer starts or the next time a user logs on.
Optional removal: You can remove the software from Software Installation without forcing the physical removal of the software. Software is not actually removed from computers. The software no longer appears in Add or Remove Programs, but users can still use it. If users manually delete the software, they cannot reinstall it.
75
Created by XMLmind
XSL-FO Converter.
Chapter 8. Implementing Security Using Group Policies

Module Overview Configuring Security Policies
Implementing Fine -Grained Password Policies
Restricting Group Membership and Access to Software
Managing Security Using Security Templates
1. Course
It's very important for an organization to have a well designed security policy, if the organization don't have the adequate policy, it can lead to many risks. A well designed policy helps to protect investments in business information and internal resources, like hardware and software. For this you can use Group Policies, it provides an security standardization to control the environment. In fact, having a security policy is not enough, to be effective this policy has to be implemented.
1.1. Configuring Security Policies

Group Policy can be used to implement security with the settings that it provide. For example, these settings can be used to secure passwords, startup and permissions for system services.
1.1.1. What are Security Policies?

Security policies are rules which helps you to protect resources on computers and networks. There are many security policies which are configured as Group Policy settings and are part of Group Policies. For example you can configure password policies as part of Group Policy. With Group Policies you can configure security for both users and computers thanks to its large security section. Through this, you can apply security consistently on organizational units (OUs) in Active Directory by defining security settings in a Group Policy Object (GPOs) that is associated with a site, domain or OU.
1.1.2. What is the Default Domain Security Policy?

The default domain policy affects all objects in the domain because it is linked to the entire domain, and this unless a Group Policy Object (GPO) that you applied at a lower level blockes or overrides these settings. This policy has very few settings configured by default. The default domain policy has all settings and capabilities of any other GPO but it is recommended to use it only to deliver Account Policies. To deliver other settings you just have to create other GPOs.
1.1.3. What are the Account Policies?

Account policies can be used to protect accounts and data againts brute force guessing of account passwords by reducing the threat. The most common method to authenticate a user's identity is to use a secret password, this method is used in Windows operating systems and in many other operating systems.
76
Created by XMLmind
XSL-FO Converter.
If you want to secure your network environment all users have to utilize strong passwords. With Password policy settings control you are able to control the complexity and lifetime of passwords. Password policy settings can be configured through Group Policy.
Table 8.1. Account policies contain :

Policies Password Enforce password history : 24 password Description
Max password age : 42 days
Min password age : 1day
Min password length : 7 characters
Complex Password : enabled
Store password using reversible encryption : disabled Account lockout Lockout duration : not defined
Lockout threshold : 0 invalid logon attempts
Reset account lockout after : not defined Kerberos Can only be applied at the domain level
1.1.4. What are Local Policies?

A Local Group Policy Object (LGPO) exists on every computer since Windows 2000, and by default each computer has a local security policy that is part of local Group Policy. In this object, Group Policy settings are stored on individual computers, if they are or not in an Active Directory environment. Local Policies determine the security options for a user or service account, with these security options you can control many different aspects of a computer's security. For example with Local Group Policies you can assign local rights. Note : If your computer is in a workgroup, you have to configure local security policies to provide security. Note : If your computer is in a Domain, Domain policy will override the local policies if there is a conflict. The LGPO is stored in a hidden folder named %windir%\system32\Group Policy and it has the followinf permissions set through DACLs :
Administrators : full control
Operating system : full control 77

Created by XMLmind
XSL-FO Converter.
User : read This folder does not exist until you configure an LGPO. If read permission is withdrawn from the Local Administrator group, Group Policy does not apply. By this way you can exempt Local Administrators from a Group Policy object even though they have the Apply Group Policy permissions set to allow.
1.1.5. What are Network Security Policies

The automation of client computer configuration settings is an essential step which provides the reduction of cost concerning the deployement of networking security and minimize support issues that result from incorrectly configured settings. Network Security Policies can be used for that. They define the available networks and authentication methods for wireless connections for Windows Vista and Windows XP clients, and LAN authentication for Windows Vista and Windows Server 2008 clients. Since Windows Server 2003 it was possible to automate client wireless configuration using the Wireless Networking Policies settings in Group Policy. Windows Server 2008 and Vista support 802.1X authentication settings for wired and wireless connections thanks to new features for network policies and Group Policy. Wireless policies for Windows XP and Windows Vista are separate. Windows Vista policies contain more options for wireless, and with these wireless policies you can deny acces to wireless networks. Note : 802.1X authentication an be configured via Group Policy Note : Only Vista and later can receive wired network policies
1.1.6. What is Windows Firewall With Advanced Security

Windows Vista and Windows Server 2008 include a new and enhanced version of Windows Firewall. This new firewall is a stateful host-based firewall with which you can allow or block network traffic according to its configuration. This new Windows Firewall provides some new features comparing to the older version :
Supports filtering for both incoming and outgoing traffic
New Microsoft Management Console (MMC) snap-in for graphical user interface (GUI) configuration
Firewall filtering and Internet Protocol security (IPsec) protection settings are integrated
Rules (exceptions) can be configured for Active Directory service accounts and groups, source and destination IP addresses, IP protocol number, source and destination TCP and UDP ports, all or multiple TCP or UDP ports, specific types of interfaces, ICMP and ICMPv6 traffic by Type and Code, and for services
1.2. Implementing Fine-Grained Password Policies

In Windows Server 2008, it's possible to allow different password requirement and account lockout policies for different Active Directory users or groups with the use of fine-grained policies.
1.2.1. What are Fine-Grained Password Policies ?
78
Created by XMLmind
XSL-FO Converter.
In previous Active Directory domains, it was possible to apply only one password and account lockout policy to all users in the domain. With fine-grained password policies you're now able to have different password requirements and account lockout policies for different Active Directory users or groups. This can be very useful when you want different users to have different password requirements, but do not want separate domains. For example, te Domain Admins group may need strict password requirements that you don't want to apply to ordinary users. If you don't implement fine-grained passwords, then the normal default domain account policies applies to all users.
1.2.2. How Fine-Grained Password Policies are implemented

Windows Server 2008 includes two new object classes in the Active Directory schema to store fine-grained password policies, these objects are :
Password Settings Container (PSC)
Password Settings Object (PSO) The System container in the domain is where the PSC object class is created by default. And the PSC is the container that contains the domain's PSOs. It's not possible to rename, move or delete this container. A PSO has attributes for all the settings that can be defined in the Default Domain Policy (except Kerberos settings). These settings include attributes for the following password settings :
Enforce password history
Maximum password age
Minimum password age
Minimum password length
Passwords must meet complexity requirements
Store passwords using reversible encryption 79

Created by XMLmind
XSL-FO Converter.
These settings also include attributes for the following account lockout settings:
Account lockout duration
Account lockout threshold
Reset account lockout counter after In addition, a PSO has the following two new attributes:
PSO link, this is a multivalued attribute that is linked to users and group objects.
Precedence, this is an integer value that is used to resolve conflicts if multiple PSOs are applied to a user or group object. All attributes except msDS-PSOAppliesTo are mustHave attributes. This means that you must define a value for each one. Settings from multiple PSOs cannot be merged. Note : PSOs can be created through ADSI Edit or LDIFDE Note : PSOs can only be applied to users or global groups
1.2.3. Implementing Fine-Grained Password Policies

A PSO can be linked to a user (or inetOrgPerson) or a group object that is in the same domain as the PSO:
A PSO has an attribute named msDS-PSOAppliesTo that contains a forward link to only user or group objects. The msDS-PSOAppliesTo attribute is multivalued, which means that you can apply a PSO to multiple users or groups. You can create one password policy and apply it to different sets of users or groups.
A new attribute named msDS-PSOApplied has been added to the user and group objects in Windows Server 2008. The msDS-PSOApplied attribute contains a back-link to the PSO. Because the msDS-PSOApplied attribute has a back-link, a user or group can have multiple PSOs applied to it. In this case, the Resultant Set of Policy (RSOP), represented by the new msDS-ResultantPSO attribute, must be calculated for that user. There are three major steps involved in implementing fine-grained passwords :
Create necessary groups, and add the appropriate users
Create PSOs for all defined password policies
Apply PSOs to the appropriate users or global security groups You can link a PSO to other types of groups in addition to global security groups, such as shadow groups with which you can apply a PSO to all users that do not already share a global group membership. However, when the RSOP for a user object is being determined, only those PSOs that are directly linked to the user object or to the global security groups that the user is a member of are considered. PSOs that are linked to distribution groups or other types of security groups are ignored. A user or group object can have multiple PSOs linked to it, only one PSO can be applied as the effective password policy. Only the settings from that PSO can affect the user or group. The settings from other PSOs 80
Created by XMLmind
XSL-FO Converter.
that are linked to the user or group cannot be merged in any way. RSOP can be calculated only for a user object. The PSO can be applied to a user object in either of the following two ways:
Directly: The PSO is linked to the user.
Indirectly: The PSO is linked to groups that the user is a member of. Each PSO has an additional attribute that assists in the calculation of RSOP, it's the precedence. A lower value for the precedence attribute indicates that the PSO has a higher rank, or a higher priority, than other PSOs. If multiple PSOs are linked to a user or group, the resultant PSO that is applied is determined as follows:
A PSO that is linked directly to the user object is the resultant PSO. If there is no PSO linked directly, it's the PSO with the lowest value for the precedence attribute that will be applied.
If no PSO is obtained from the preceding conditions, the Default Domain Policy is applied.
1.3. Restricting Group Membership and Access to Software

The control of the membership of built-in groups in the directory and on workstations is one of the challenges of network security in a large network environment.
1.3.1. What is Restricted Group Membership

It is possible that you want to control the membership of some groups in a domain to prevent other users to be added to those groups, such as the local admininstrators group. For that, you can use the Restricted Groups policy to control group membership. If you want to specify what members are placed in a group you can use the policy. If you define a Group policy and refresh Group Policy, any current member of a group that is not on the Restricted Groups policy members list is removed. This can be applied to default members such as domain administrators. Although it's possible to control domain groups by assigning Restricted Groups policies to domain controllers, you should use this setting at first when you want to configure membership of critical groups like Enterprise Admins and Schema Admins. With this setting you can also control the membership of built-in local groups on workstations and member servers. For example, you can place the helpdesk group into the local Administrators group on all workstations. So it's important that you remember that with Group Policy you can control group membership :
For any group on a local computer by applying a GPO to the OU that holds the computer account
For any group in Active Directory by applying a GPO to the domain controller
1.3.2. What is a Software Restriction Policy

To prevent users from running some applications or types of application like VBscripts, it is possible to restrict access to software. Software restriction policy can be used for that, this policy provides administrators with a policy-driven mechanism to identify software and control its ability to run on a client computer. The software restriction policy can be very useful to restrict the running of hostile code such as viruses. So Software restriction policies can help you in the way you respond to unknown code by : 81
Created by XMLmind
XSL-FO Converter.
Providing a way to define a list of which code is trusted and which not.
Providing a flexible, policy-based appraoach for regulating scripts, executables and ActiveX controls
Enforcing the policy automatically There are three steps to create and apply a Software Restriction policy : 15. You create the policy with the Group Policy MMC snap-in for a particular Active directory container such as a site, domain or organizational unit. 16. After the policy is created, it's downloaded and applied to a machine. User policies apply the next time a user logs on. Machine policies apply when a machine starts up. 17. When a user starts a program or script, the operating system or scripting host checks the policy and enforces it. Unrestricted or Disallowed You can create a Software Restriction policy with the MMC Group Policy snap-in. A policy consists of a default rule which determines if programs are allowed to run, and exceptions to that rule. The default rule can be set to Unrestricted or Disallowed (run or don't run). When you set the default rule to Unrestricted, you can allow to define exceptions, for example programs you don't want to allow to run. But there is a more secure approach to configure this rule, it's to set it to Disallowed and then specify only those programs which should be able to run so these which are known and trusted. Default Security level There are two ways to use software restriction policies :
If you know all of the software that should run, then you can apply a software restriction policy to let run only the software you trust.
If all the applictations that users might run are not known then you can step in and disallow undesired applications or file types as needed.
1.3.3. Options for configuring Software Restriction Policies

Like you've seen before Software Restriction policies use rules to determine whether an application is allowed to run. When you create a rule, you first identify the application. Then you identify it as an exception to the default policy setting of Unrestricted or Disallowed. The Enforcement engine queries the rules in the software restriction policy before it allows a program to run. A software restriction policy supports four ways to identify software :
Hash - a cryptographic fingerprint of the file.
Certificate - a software publisher certificate used to digitally sign a file
82
Created by XMLmind
XSL-FO Converter.
Path - the local or universal naming convention (UNC) path of where the file is stored
Zone - Internet Zone Hash Rules A hash rule is a cryptographic fingerprint that is used to identify a file regardless of where it is accessed or its name. You may not want users to run a certain version of a program which can have security or privacy bugs, or compromises system stability. With a hash rule, it will always match the rule because this kind of rule is based on a cryptographic calcuation involving file contents although when you move or rename the program. A hash rule consists of three pieces of data, separated by colons :
MD5 or SHA-1 hash value
File length
Hash algorithm ID Certificate Rules A certificate rule specifices a code-signing, software publisher certificate. Certificates used in a certificate rule can be distributed from a commercial certificate authority (CA) such as VeriSign, a Windows Server PKI or a self-signed certificate. This kind of rule is a strong way to identify software because it uses signed hashes contained in the signature of the signed file to match files regardless of name or location. So if you want to make an exceptions to a certificate rule, you can use a hash rule to identify the exceptions. Path Rules A path rule can specify a folder or fully qualified path to a program. When a path rule specifies a folder, each program contained in this folder and its sub-folder will be matched. Note : Both local and UNC paths are supported
1.4. Managing Security Using Security Templates

A security policy is a group of security settings that affect a computer's security. If you want to establish account and local policies on your local computer and in Active Directory you can use a security policy. Security templates can be created to help you with creating security policies to meet the security you want to establish. When you have security templates, you can use them to configure security settings to computers manually or through Group Policy.
1.4.1. What are Security Templates?

A security template is a collection of configured security settings. There are predefined security templates that you use as a base to create security policies which you can then customize as you want, but you can also create your own template. To create or customize a template there is a snap-in you can use called "Security Templates". For example, you can create security templates based on server roles. After you create a template or customize a predefined security template, you can apply it to an individual computer or multiple computers to configure their security, it is also possible to apply automatically via Group Policy. Security templates contain security settings for all security areas, these areas are : 83
Created by XMLmind
XSL-FO Converter.
Account Policies
Local Policies
Event Log
Restricted Groups
System Services
Registry
File System
1.4.2. What is the Security Configuration Wizard?

The Security Configuration Wizard (SCW) appeared with Windows Server 2003 with Service Pack 1 (SP1), an this tool can be used to reduce the attack-surface. These attack surface reductions are provided by SCW :
Disabling unnecessary services and IIS Web extensions
Blocking unused ports and secure ports that are left open using IPSec
Reducing protocol exposure
Configuring audit settings SCW helps you to create correctly the security policy you need, and it determines functionalities required by a server's role and disables all functionalities that are not necessary. 84
Created by XMLmind
XSL-FO Converter.
With SCW you create your policy in five steps, in each step you will configure security for these sections :
Role-Base Service Configuration
Network Security
Registry Settings
Audit Policy
Internet Information Services Once a policy is created, it can be edited or applied to one or more similarly configured servers. Applied policies can be rolled back in order to undo changes that have caused problems. To edit, apply, or roll back a security policy, the policy must have been created with SCW. The security policies that you create with SCW are XML files, and when you apply them, they will configure sevices, network security, specific registry values, audit policy, and if applicable, Internet Information Services (IIS). Note: these security policies can be integrated in Active Directory Note : it is possible to configure a security policy on a remote server with SCW SCW also includes an command-line tool Scwcmd.exe, which you can use for the following tasks :
Configure one or many servers with an SCW-generated policy
Analyze one or many servers with an SCW-generated policy
View analysis results in HTML format
Roll back SCW policies
Transform an SCW-generated policy into files supported by Group Policy
Register a Security Configuration Database extension with SCW
1.4.3. Options for integrating the Security Configuration Wizard and Security Templates
When you create a security policy with SCW you can include custom security templates. Some settings from SCW partially overlap the settings from security templates alone. Neither set of configuration changes totally includes the other. For example, the SCW includes IIS settings that are not installed in any security template. Conversely, security templates can include such items as Software Restriction policies, which it is not possible to configure through SCW.
85
Created by XMLmind
XSL-FO Converter.
Chapter 9. Implementing an Active Directory Domain Services Monitoring Plan

Objectives: Learn How to Monitor Active Directory Domain Services Using Event Viewer
Learn How to Monitor Active Directory Domain Servers Using Reliability and Performance Monitor
Learn How to Configure Active Directory Domain Services Auditing Required knowleges:
Monitoring Basis.
The use of Event Viewer, Performance and Reliability Monitor.
Auditing Basis.
1. Course
To manage and administer an organizantion's system,it's important to understand the tools that you can use to monitor the system's health. By Using tools like Event Viewer, Reliability and Performance Monitor, and auditing policies, you will be better able to anticipates issues and manage everyday events.
1.1. Monitoring Active Directory Domain Services Using Event Viewer

1.1.1. Overview of the Event Viewer
Monitoring server performance is an important part of maintaining and administratering an operation system. The Event Viewer is an application that enables you to browse, manage and monitor events recorded in events logs. One of the first places you should turn when troubleshooting problems in Microsft Windows Server 2008, is the Event Viewer. A number of new features are built into the Event Viewer for Windows Server 2008. Event Viewer is rewritten completely with Windows Server 2008 with a new interface that makes it easier to filter and sort events and control which events are logged. Additionally, you now can perform some basic diagnostics tasks from within Event Viewer. Event Viewer also Provides many new log files.
Events Viewer enable you to view events on a single remote computer. However, troubleshooting and issues might require you to examine a set of events stored in multiple logs on multiple remote conputers. Event Viewer provides the ability to collect copies of events from multiple remote computers and store the locally. To specify which events to collect, you create an event subscription? Once a subscription is active and events are being collected, you can view and manipulate these forwarded events as you would any other locally stored events. You can use the event viewer to create Custom views.Custom Views are filters the are named and saved. After 86
Created by XMLmind
XSL-FO Converter.
creating and saving a custom View, you are able to reuse it whithout re-creating its underlying filter. To reuse a custom view, navigate to the Custom View category in the console tree and select the custom view's name. By selecting the custom view, you apply the underlying filter and the result are displayed. You can import and export custom views, enabing you to share them between users and computers. The System and Application logs still provide general information and log events from many areas, but the Event Viewer now provide granular information about Active Directory and other services, like Group policy, Offline files, Windows Update client and many others.
1.2. Monitoring Active Directory Domain Servers using Reliability and Performance Monitor
1.2.1. Overview of Performance and Reliability monitoring
In general, performance is the measure of how quickly a computer completes application and system tasks. Use preformance monitoring to track a range of processes and display the results. You can use performance monitoring to assist you whith upgrade planning, tracking precesses that need to be optimized, and understanding a workload and it's effect on ressource usage to identify bottlenecks. Overall system performance might be limited by the access speed of the physical hard disk, the amount of available memory, the processor speed or the throughput of new network interfaces.
Windows Reliability and Performance Monitor enables you to track the performance impact of applications and services, and to generate alerts or take action when user-defined tresholds for optimum performance are exeeded. Windows Reliability and Performance Monitor provides the features outlined below :
Resource View
Reliability Monitor
Data Collector Sets
Track Performance of Applications and services
Wizards and Templates For Creating logs
Generate alerts and take action when tresholds are reached
Generate Reports
1.2.2. Monitoring Active Directory Domain Services using Performance Monitor

Monitoring the distributed Active Directory Service and Services that relies upon helps maintain consistent directory data and the necessary level of service throughout the forest. You can monitor important indicators to discover and resolve minor problems before they develop into potentially lengthy service outage. In addition to the normal baseline counters that you monitor for all servers, there are objects and dozens of counters that are specific to Active Directory. 1.2.2.1. Active Directory baseline A baseline represents service level needs as performance data. By setting thresholds to indicate when the baseline boundaries are exceeded, your monitoring solution can generate alerts to inform the administrator of 87
Created by XMLmind
XSL-FO Converter.
degraded performance and jeopardized service levels. For example, you can use performance indicators to set a baseline and monitor for low disk space on the disk drives that contain the Active Directory database and log files, and you can monitor CPU usage of a domain controller. You can also monitor critical services running on a domain controller. Monitoring these indicators allows the administrator to ensure adequate performance. To determine an accurate baseline, monitor and collect data for a time period that is long enough to represent peak and low usage. For example, monitor during the time in the morning when the greatest number of users log on. Monitor for an interval that is long enough to span your password change policy and any month-end or other periodic processing that you perform. Also, collect data when network demands are low to determine this minimal level. Be sure to collect data when your environment is functioning properly. To accurately assess what is acceptable for your environment, remove data caused by network outages or other failures when you establish your baseline. The baseline that you establish for your environment can change over time as you add new applications, users, hardware, and domain infrastructure to the environment, and as the expectations of users change. 1.2.2.2. Monitoring Service Availability With the Reliability Monitor A system's reliability is the measure of how often it deviates from configured, expected behavior. The reliability monitor calculate a system stability index that reflects whether unexpected problems reduced the system's reliability. A graph of the stability intex over time quickly identifies dates when problems began to occur. The accompanying System Stability Report provides details to hels troubleshoot the root cause reduced reliability. The Reliability Monitor begins to collect datas at the time of system installation and must run for at least 24 hours before the data is displayed in the system stability chart.By viewing changes to the system (installation or removal of applications, updates to the oprating system, or addition or modification of drivers) side by side with failures (application failures, operating system crashes, or hardware failures), you can develop a strategy for addressing the issues quickly. On your Domain controller, the reliability Monitor helps you to find problems which can happends, by using this monitor, you'll be able to identify the problem source, and it will be easier for you to find the remediation method in order to provide and maintain the high availability of your domain controller . With the Windows server 2008 new features, the performance monitor is now able to collect datas using Data Collector Sets, which groups datas collectors into reusable elements for use with different performance monitoring scenarios.
1.3. Active Directory Domain Services Auditing

1.3.1. Overview of AD DS Auditing
In any secure environement, you should actively monitor the active directory; As a part of your overall security strategy, you should determine the level of auditing appropriate for your environment. Auditing should identify actions either successful or not, that have modified or attempted to modify Active Directory Objects. An audit log records an entry whenever users perform certain specified actions. For examle, he modification of an object or a policy can trigger an audit entry that shows the action that was performed, the associated user account, and the date and time of the action. You can audit both succesful and failed attempts at actions. The Directory Service Acess category still provides information about the events that occur in the directory, and is enabled by default. More detailed information ca be delivered from the subcategories.
88
Created by XMLmind
XSL-FO Converter.
Chapter 10. Implementing an Active Directory Domain Services Maintenance Plan

Module Overview Maintaining the AD DS Domain Controllers
Backing Up Active Directory Domain Services
Restoring Active Directory Domain Services
1. Course
1.1. Maintaining the AD DS Domain Controllers
Maintaining the AD DS database is an important administrative task to repair the Active Directory database and recover lost or corrupted data in case of problems, to ensure that you have to schedule it regularly. You should know that Active Directory has its own database engine, the Extensible Storage Engine (ESE). The usage of ESE is to manage the storage of all Active Directory objects in an Active Directory database.
1.1.1. The Active Directory Domain Services Database and Log Files Table 10.1. AD DS database and log files
File Ntds.dit Active Directory database file Description
Contains all Active Directory objects on domain controller
Default location systemroot\NTDSfolder Edb*.log Transaction log file
Uses the default transaction log file edb.log Edb.chk Checkpoint file
Tracks data not yet written to Active Directory database file ebdres00001.jrs
89
Created by XMLmind
XSL-FO Converter.
File Reserved transaction log files ebdres00002.jrs
Description
The Active Directory database engine is called ESE (Extensible Storage Engine).
1.1.2. How the AD DS database is modified
What is a transaction ? A transaction is a set of changes made to the AD DS Database and the corresponding Metadata The data is modified in six steps : 18. The write request initiate a transaction 19. Active Directory writes the transaction to the transaction buffer in memory 20. Active Directory writes the transaction in the transaction log called Edb.log 21. Active Directory writes the transaction from the memory buffer to the database which is NTDS.dit 22. Active Directory compares the database and log files to ensure that the transaction was committed to the database 23. Active Directory updates the checkpoint file called Edb.chk
1.1.3. Managing the Active Directory Database Using NTDSUtil Tool

You can use Ntdsutil.exe to manage AD DS, it is a command-line tool. Ntdsuti.exe can be used to perform many maintenance tasks that it is impossible to perform in the graphical user interface such as :
Offline database defragmentation
Moving the database and its transaction log
90
Created by XMLmind
XSL-FO Converter.
Removing and restoring deleted objects from Active Directory
Seizing operations master (also known as Flexible Single Master Operations or FSMO) roles
Manage database snapshots
Note : you can include these commands in a batch file
1.1.4. What is an AD DS Database Defragmentation

Why should we defragment the AD DS Database? Fragmentation occurs over time when records are added, expanded or deleted in the Active Directory database. When records becom fragmented, the computer must search the disk to find and reassemble all pieces each time the database is opened. When many changes are made to the database, the fragmentation will increase and it could slow the performance of it, therefore it is necessary to defragment the AD DS database. There are 2 types of AD DS database defragmentation : offline and online defragmentation Offline defragmentation The offline defragmentation creates a new, compacted version of the database file, the new file may be considerably smaller, depending on how fragmented the original database file was. You can perform an offline defragmentation on a dismounted database with the Ntdsutil command-line tool. Online defragmentation The online defragmentation optimizes data storage in the database and reclaims space in the directory for new 91
Created by XMLmind
XSL-FO Converter.
objects, but does not reduce the size of the database file. An online defragmentation is performed every 12 hours automatically by Active Directory.
1.1.5. What are Restartable Active Directory Domain Services ?

In previous versions of Windows Server (Windows Server 2003 for example) if you wanted to perform offline maintenance tasks or start a domain controller without loading Active Directory, you needed to reboot the machine into Active Directory Restore Mode. This would start the server as a member server, without Active Directory. Now, with Windows Server 2008, the directory service can be taken offline while the machine is running, with minimal disruption to other services, this means that only services required for AD DS to function will be stopped (DNS for example). For that you just have to stop the Active Directory Domain Services without stopping any other services because it will stop depending services either. You can use the restartable AD DS services when you want to :
Apply updates that modifiy Active Directory file on a domain controller
Perform tasks such as offline defragmentation of the Active Directory database Note : if you want to restore the Active Directory database you have to use the Directory Services Restore mode.
1.1.6. Locking Down Services on AD DS Domain Controllers

If you want to increase the security on a domain controller, you can remove all unnecessary services and features. This reduces both the attack surface and improves performance. To increase the security of your domain controller you can :
Minimize the number of server roles and applications installed on your domain controller
Use the Security Configuration Wizard to lock down the services on a domain controller It's important that you know services required for AD DS to function correctly, there are six services require by AD DS :
Distributed File System
DNS Server
File Replication Service
Kerberos Key Distribution Center
Intersite Messaging
Remote Procedure Call (RPC) Locator
92
Created by XMLmind
XSL-FO Converter.
1.2. Backing up Active Directory Domain Services

For most organizations AD DS is very important, so it is very important that you know how to restore AD DS functionality in the event of database failure, server failure, or a more serious disaster, such as the failure of a data center that contains multiple servers. You must implementa consistent policy of backing up the AD DS information on domain controllers to be prepared for disaster recovery.
1.2.1. Introduction to backing up AD DS

To back up Active Directory, you have to back up all critical volumes. These critical volumes include :
The system volume: the volume that hosts the boot files
The boot volume: this volume contains the Windows operating system and the Registry
The volume that hosts the SYSVOL tree
The volume containing the Active Directory database (NTDS.dit)
The volume containing the Active Directory database log files These files can be stored in a single volume or placed in multiple volumes. To backup Active Directory, you can use the feature called Windows Server Backup, it's not installed by default. To install it you have to use Add features in Server Manager before you can use the Wbadmin.exe commandline tool or Backup tool in Administrative Tools.
1.2.2. Windows Server Backup Features

What is Windows Server Backup? Windows Server Backup is the new backup utility provided by Windows Server 2008, it can be used to back up and recover the operating system and data. If you want to use it, you will have to install it as a feature. If you want to use the Windows Server Backup command-line tools, you also must install the Windows Powershell feature. With Windows Server Backup, you can :
Recover the server without using third-party backup and recovery tools
Backup an entire server or selected volumes
Perform manual or automatic backups
Recover items or entire volumes
Use DVDs or CDs as backup media Note : with Windwos Server Backup you cannot backup individual files or directories, only entire volumes.
93
Created by XMLmind
XSL-FO Converter.
1.3. Restoring Active Directory Domain Services

After you implemented an AD DS backup system, you can move to planning and implementing AD DS restores. To restore AD DS information, Windows Server 2008 provides several options. You will now learn how to use each option.
1.3.1. Overview of Restoring AD DS

In Windows Server 2008, you have several options for restoring AD DS. You can choose the option you need depending on the disaster-recovery scenario you need to address. The four options you can use for restoring Active Directory Domain Services are :
Normal Restore
Authoritative Restore
Full Server Restore
Alternate Location Restore
1.3.2. What is a Nonauthoritative AD DS Restore?

You can use a backup to perform a nonauthoritative restore of a domain controller. A nonauthoritative restore brings back the directory serivec to its stat at the time the backup was created. After you completed an nonauthoritative restore, AD DS replication updates the domain controller with changes that have occured since the time that the backup was created so that the domain controller is recovered to a current state. To do a nonauthoritative restore you have to :
Press F8 at the start of your sever and then choose Directory Services Restore Mode or you can also type the command "bcedit /set safeboot dsrepair" and then restart the server.
Provide the Directory Services Restore Mode password
1.3.3. What is an Authoritative AD DS Restore?

An authoritative restore can be used to recover objects and containers that have been deleted from AD DS. When an object is marked for authoritative restore, the version number of this object will be changed so that the new version number is higher than the existing version number in the Active Directory replication system. This change is made to ensure that any data restored with an authoritative restore is replicated from the restored domain controller to the other domain controllers in the forest. There are four steps to make an authoritative restore :
Start the domain controller in DSRM (Directory Services Restore Mode)
Restore the desired backup, which is typically the most recent backup
94
Created by XMLmind
XSL-FO Converter.
Use Ntdsutil.exe to mark desired objects, containers, or partitions as authoritative
Restart the domain in normal mode to replicate the changes Note : to mark an object as authoritative, use a command like : restore subtree "OU=SCT, DC=Labo-Microsoft, DC=Supinfo, DC=com"
1.3.4. What is the Database Mounting Tool?

With the Database Mounting Tool (Dsamain.exe) you can view and compare data in database snapshots (backups) without having to restore those backups, which saves on downtime and speeds the domain-recovery process. For that you can use this tool to :
Create and view snapshots of data stored in AD DS
Compare data in snapshots taken at different time which improves the recovery process
Suppress the need to restore multiple backups to compare the Active Directory data contained by these backups
View without restoring deleted objects and containers
1.3.5. Reanimating Tombstoned AD DS Objects

A tombstoned object is an object marked as deleted in Active Directory. When an object is deleted, it is converted into a tombstone. The tombstone stays in the Active Directory database for 180 days (default tombstone lifetime) and this in a deactivated state. To keep the Active Directory database updated, the tombstone is replicated to all domain controllers from the entire domain and then deleted on each domain controller when the tombstone's lifetime expires. To mark and object as a tombstone, the isDeleted attribute on the object is set to True and most of the other attributes are deleted. But not all other attributes are deleted, some few critical attributes are kept :
SID
ObjectGUID
LastKnownParent
SAMAccountName All other attributes are deleted so if you want to reanimate the object, you have to provide all the information it once had, therefore you have to recreate the missing attribute values manually. You should reanimate a deleted object in AD DS when :
Accounts or security groups were deleted and you don't have the current AD DS backups for the 95
Created by XMLmind
XSL-FO Converter.
corresponding domain
The deleted object has not yet been scavenged from the Active Directory database
The object was deleted in domains with only Windows Server 2003 or later domain controllers. If you want to reanimate tombstoned AD DS objects you can :
Use LDP.exe to locate the deleted object
Change isDeleted attribute and then provide a distinguished name
Enable the object and reconfigure the object attributes Note : If you want to view the attributes for the deleted object and so simplify the recovery of the deleted object, you can use the Database Mounting Tool to view the attributes you need in a snapshot made before the object was deleted
96
Created by XMLmind
XSL-FO Converter.
Chapter 11. Troubleshooting Active Directory, DNS, and Replication Issues

In this lesson, we will see that informations to troubleshoot Active Directory, Domain Name System (DNS), and replication issues. Module Overview
Troubleshooting Active Directory Domain Services
Troubleshooting DNS Integration with AD DS
Troubleshooting AD DS Replication
1. Course
1.1. Troubleshooting Active Directory Domain Services
1.1.1. Introduction to AD DS Troubleshooting
Active Directory Domain Services is a distributed system that is comprised of many different services and depends on all of the services to function properly. The methodology presented can ease the difficulties inherent in identifying the computers and services involved in problems you might be having, and help you isolate a problem to the core component. In most cases, troubleshooting begins when you detect one of the following:
Users report authentication or authorization errors
Active Directory related events appear in the Event Viewer
Domain controller performance is degraded
An alert generated by a monitoring system, such as Microsoft Operations Manager (MOM).
Data is not being replicated between domain controllers
1.1.2. Troubleshooting User Access Errors

There are many possible reasons why a user cannot access network resources. These can be divided up into three basic categories.
Network access errors
97
Created by XMLmind
XSL-FO Converter.
Authentication errors
Authorization errors To address user access errors, verify:
Network connectivity
Time synchronization
Domain controller availability
User account and user lockout settings
Group memberships
1.1.3. Troubleshooting Domain Controller Performance Issues

As a distributed service, AD DS depends on many interdependent services that are distributed across many devices and in many remote locations. As you increase the size of your network to take advantage of the scalability of AD DS, domain controller performance could become an issue. Most common performance issues include:
High CPU utilization
High network utilization To resolve performance issues:
Identify the processes with high CPU utilization
Monitor application specific network traffic
Move applications or services to another server
Distribute Active Directory and DNS roles across multiple servers
Review and modify the replication topology
Deploy domain controllers with 64 bit hardware
1.2. Troubleshooting DNS Integration with AD DS
98
Created by XMLmind
XSL-FO Converter.
1.2.1. Overview of DNS and AD DS Troubleshooting

One of the most common reasons for AD DS issues is problems with the DNS infrastructure
Users cannot log on to Active Directory
Active Directory replication is failing
Active Directory installation fails In particular, you should begin DNS troubleshooting when you see the issues listed:
DNS client and server configurations
DNS name registration
DNS zone replication
1.2.2. Troubleshooting DNS Name Resolution

DNS name resolution may fail due to:
Verify network connectivity on all computers.
Use ipconfig to make sure all computers, including clients, member servers, domain controllers, and DNS servers are using a DNS server that is authoritative for the Active Directory domain. Sometimes computers are manually misconfigured to use the wrong DNS server, such as an Internet caching server or an ISPs DNS server.
Use netdiag to test DNS connectivity. Ensure that the DNS server is working correctly. You can perform the Simple self-test in the DNS servers properties to verify the database is responding. As well, clear the DNS servers cache to ensure that the cache is not polluted, or that it has the latest zone information Use ipconfig /flushdns to clear the clients DNS resolver cache.
If the zone seems to be corrupt, restore from backup. If necessary, clear any dynamic registrations from the DNS zone and rebuild the database.
Check the DNS Server log in Event Viewer for errors.
Use nslookup to see what results are returned by the DNS server. The following DNS records are required for proper Active Directory functionality.
1.2.3. Troubleshooting DNS Name Registration

99
Created by XMLmind
XSL-FO Converter.
DNS name registration may fail due to:
Client configuration errors
DNS server availability
DNS zone configuration To troubleshoot DNS name registration:
Verify that the client is configured to register in DNS
Test DNS server availability
Verify that the DNS zone is configured fordynamic updates
Test DNS by using the DCDiag /Test:DNS command
Register the SRV records by restarting the Netlogon service All servers must have at least A (host) and possibly PTR (reverse lookup) records in DNS. In addition, all domain controllers must have their SRV (Resource Locator) records updated in DNS. The following lists which service is responsible for dynamically updating DNS: A records are updated by the computers DNS client service.
PTR records are manually configured. SRV records are updated by the DCs netlogon service.
1.2.4. Troubleshooting DNS Zone Replication

Whenever a DNS record is updated, either in a traditional Primary (Master) zone or an Active-Directory Integrated zone, that update must be replicated in a zone transfer to all DNS servers that are authoritative for that zone. An administrator may choose to favor conserving bandwidth during heavy network usage hours by delaying replication to less busy times. Even so, the record will have to be replicated at some point for the DNS database to be consistent. Investigate DNS zone replication issues when:
DNS-related issues are specific to certain DNS server clients
Zone information is not consistent on different DNS servers
DNS server availability
100
Created by XMLmind
XSL-FO Converter.
Name registration or DNS replication issues To troubleshoot standard zone transfer issues:
Verify network connectivity
Verify primary server and secondary server configuration
Verify Start of Authority record
Verify zone transfer configuration
1.3. Troubleshooting AD DS Replication

1.3.1. AD DS Replication Requirements
Active Directory replication requires:
Routable IP infrastructure
DNS name resolution
RPC or SMTP connectivity between domain controllers
Kerberos v5 authentication
LDAP connectivity to install new domain controllers
File Replication Service or Distributed File System Replication
1.3.2. Tools and Identifying the Cause of Replication Errors

When you encounter replication problems in Active Directory, your first step is to identify the symptoms and possible causes.
Table 11.1. Common Replication Issues

Symptom Replication does not finish or occur Sites not connected by site links Possible causes
No bridgehead server in the site group Replication is slow Inefficient site topology and schedule
101
Created by XMLmind
XSL-FO Converter.
Client computers receive a slow response No domain controller online in client site
Not enough domain controllers Replication greatly increases network traffic Insufficient bandwidth
Incorrect site topology You use the Repadmin.exe command-line tool to view the replication topology from the perspective of each domain controller. You can also use Repadmin.exe to manually create the replication topology, force replication events between domain controllers, and view the replication metadata, which is information about the data, and up-to-date state of vectors. You use the Dcdiag.exe command-line tool to analyze the state of a domain controller and report any problems. The Dcdiag.exe tool performs a series of tests to verify different aspects of the system. These tests include connectivity, replication, topology integrity, and intersite health.
Table 11.2. Identifying the Cause of Replication Errors

Possible causes Sites are notconnected bysite links Dcdiag /test:Topology No bridgehead server in the site Repadmin /bridgeheads Inefficient site topology and schedule Repadmin /latency No domain controlleronline in the site Dcdiag /test:Replication Testing method
Dcdiag /test:Connectivity Not enough domain controllers System monitor NTDS counters Incorrect site topology Active Directory Sites and Services
Repadmin /latency
V Dcdiag /test:Intersite
1.3.3. AD DS Replication Requirements

Troubleshooting Distributed File Replication Issues :
102
Created by XMLmind
XSL-FO Converter.
Windows Server 2008 uses FRS or DFSR to replicate the SYSVOL directory between domain controllers
Both FRS and DFRS require LDAP and RPC connectivity between domain controllers
Use Ntfrsutl and FRSDiag to troubleshoot FRS replication
Use DFSRAdmin to troubleshoot DFRS replication The contents of SYSVOL folder are replicated to every domain controller in a domain. If the domain is at Windows Server 2003 or lower functional level, the File Replication Service (FRS), is responsible for replicating the contents of the SYSVOL folder between domain controllers. When you upgrade the functional level to Windows Server 2008, Distributed File System Replication (DFSR) is used to replicate the contents of the SYSVOL folder. In both cases, the connection object topology and schedule that the Knowledge Consistency Checker (KCC) creates for Active Directory replication is used to manage replication between domain controllers.
103
Created by XMLmind
XSL-FO Converter.
Chapter 12. Troubleshooting Group Policy Issues

In this lesson, we will see that informations to troubleshoot Group Policy issues. Module Overview
Introduction to Group Policy Troubleshooting
Troubleshooting Group Policy Application
Troubleshooting Group Policy Settings
1. Course
1.1. Introduction to Group Policy Troubleshooting
1.1.1. Scenarios for Group Policy Troubleshooting
Common scenarios that require troubleshooting:
Polices not applied
Policies are applied but settings are inconsistent Core Group Policy processing. When a client begins to process Group Policy, it must determine whether it can reach a domain controller, whether any GPOs have changed, and what policy settings (based on client side extension) must be processed. The core Group Policy engine performs the processing of this in the initial phase. Client side extension (CSE) processing. Policy settings are grouped into different categories, such as Administrative Templates, Security Settings, Folder Redirection, Disk Quota, and Software Installation. The settings in each category require a specific CSE to process them, and each CSE has its own rules for processing settings. The core Group Policy engine calls the CSEs that are required to process the settings that apply to the client.
1.1.2. Preparing to Troubleshoot Group Policies

The first step in troubleshooting Group Policy is to determine the problems source. Group Policy problems may be a symptom of other, unrelated issues such as network connectivity, authentication problems, domain controller availability, or Domain Name Service (DNS) configuration errors. For example, the failure of a router or DNS server could prevent clients contacting a domain controller. Basic troubleshooting steps:
Check Event Viewer entries
Perform basic checks to test network connectivity: use diagnostic tools like netdiag, ping
104
Created by XMLmind
XSL-FO Converter.
Ensure that DNS is functioning: use NSlookup
Check that the domain controller is functioning and reachable: use diagnostic tools like dcdiag, the set command, Kerbtray
1.1.3. Tools for Troubleshooting Group Policies

There are a number of diagnostic tools and logs that you can use to verify whether you can trace a problem to core Group Policy. Group Policy reporting RSoP Much like the command line tool Gpresult, RSoP provides a graphical interface for looking at the settings that have been applied by all of the GPOs. RSoP tool provides you with a result of all applied policy settings in a format similar to that of the Group Policy Object Editor.
GPResult This tool can only be run locally on the target computer, but it provides information about the Resultant Set of Policies (RSoP), blocked GPOs, permissions on GPOs, and much more. Using the command with the /v switch will show a great deal of information about the GPOs that are affecting the computer and about user accounts associated with the current logon session.
Gpotool Since GPOs are replicated from the domain controller where the GPO changes initially occur to all other domain controllers, there is a chance of replication failing or not converging efficiently. The result of this is inconsistency or failure of the changes to be properly applied to the target computers. Tools such as Gpresult and RSOP can help determine what GPOs have applied, but this tool, Gpotool, can help you determine if the GPOs on each domain controller are consistent
Gpupdate If you are implementing new GPO settings or trying to ensure that all GPO processing has occurred, you can use the Gpupdate tool. This is a command-line tool that ships with the operating system . When you run it, it will trigger a background refresh which will apply all GPO settings that adhere to this type of refresh. If you add the /force switch, it will reapply all GPO settings, even if there have been no changes to the GPO since the last refresh. Running this command before running the Gpresult command is a very powerful method for tracking GPO issues.
Dcgpofix There might be a time when you have an issue with one of the two default GPOs: Default Domain Policy and Default Domain Controllers Policy. If one or both of the GPOs becomes corrupted, too far out of configuration where you can't fix it, or some other unknown issue, you can use the dcgpofix tool to revert them to the default state.
GPOLogView The Event Viewer has a wealth of information regarding Group Policy. Unfortunately, it requires you to look at all of the different log files to find entries for Group Policy. There you'll find entries related to policy application, policy replication, and policy refresh, all of which can be useful when trying to track down a problem. There is not always a lot of information on specific Group Policy errors in the event logs, but remember that you can always search TechNet if you find errors you can't identify. 105
Created by XMLmind
XSL-FO Converter.
Group Policy log files If other tools do not provide the information you need to identify the problems affecting Group Policy application, you can enable verbose logging and examine the resulting log files. Verbose logging can reduce performance and consume significant disk space, so as a best practice enable verbose logging only when necessary.
Group Policy Management Scripts Scripting of Group Policy related tasks not scripting of settings within a GPO. Fixes customer-reported bugs found in GPMC sample scripts.
1.2. Troubleshooting Group Policy Application

1.2.1. Troubleshooting Group Policy Inheritance
Blocking inheritance will prevent all higher-level settings from affecting the organizational units (OUs) and their child OUs where inheritance has been blocked. You can block inheritance only for entire OUs, not for individual objects, and it can complicate troubleshooting because it counteracts the usual inheritance rules.
1.2.2. Troubleshooting Group Policy Filtering

Group Policy filtering determines which users and computers will receive the GPOs settings. Filtering of a Group Policy object (GPO) is based on two factors:
The security filtering on the GPO
Any Windows Management Instrumentation (WMI) filters on the GPO
1.2.3. Troubleshooting Group Policy Replication

In a domain that contains more than one domain controller, Group Policy information takes time to propagate, or replicate, from one domain controller to another. A GPO consists of two parts; the Group Policy template (GPT) and the Group Policy container (GPC). Changes to GPOs are tracked using version numbers. Every 106
Created by XMLmind
XSL-FO Converter.
change increments the version number of the GPT and the GPC.
1.2.4. Troubleshooting Group Policy Refresh

Group Policy refresh refers to a clients periodic retrieval of GPOs. During Group Policy refresh, the client contacts an available domain controller. If any GPOs changed, the domain controller provides a list of all the appropriate GPOs. By default, GPOs are processed at the computer only if the version number of at least one GPO has changed on the domain controller that the computer is accessing. If the Group Policy is not refreshing as expected:
Check refresh intervals for users and computers
Verify that the user has logged off and on, or that the computer has been restarted
Check if there are cached credentials because they may delay the effect of Group Policy
Check to see if the Loopback policy is enabled Use gpupdate to:
Manually refresh updated Group Policy settings
Force the refresh of all Group Policy settings
Force a reboot or logoff, if required, to refresh the settings
1.3. Troubleshooting Group Policy Settings

107
Created by XMLmind
XSL-FO Converter.
1.3.1. How Client Side Extension Processing Works

CSEs are dynamic-link libraries (DLLs) that perform the actual processing of Group Policy settings. Policy settings are grouped into different categories, such as Administrative Templates, Security Settings, Folder Redirection, Disk Quota, and Software Installation. Each categorys settings require a specific CSE to process them, and each CSE has its own rules for processing settings. The core Group Policy process calls the appropriate CSEs to process those settings. Some CSEs behave differently under different circumstances. For example, a number of CSEs do not process if a slow link is detected. Security settings and Administrative Templates always are applied and you cannot turn them off. You can control the behavior of other CSEs across slow links. As Group Policy is processed, the Winlogon process passes the list of GPOs that must be processed to each Group Policy client-side extension. The extension uses the list to process the appropriate policy when applicable.
1.3.2. Troubleshooting Administrative Template Policy Settings

Some Administrative Template settings may be preferences, rather than policies that you cannot remove easily, while older operating systems might not accept other administrative settings. When troubleshooting security policy settings, consider that:
Administrative Templates are either true polices or preferences
Settings that are true policies are reversed when the policy no longer applies
Settings that are preferences will tattoo the registry and remain in effect until they are specifically reversed
The operating system and service pack level determine if the computer can accept a policy setting
1.3.3. Troubleshooting Security Policy Settings

Security policies protect the computing environments integrity by controlling many aspects of it, like password policies, security options, restricted groups, network policies, services, public key policies, and so on. When troubleshooting security policy settings, consider that:
Account policies are passed to clients from the domain controller
The domain controller receives account policies from a domain level policy
Security settings come from the GPO that have the highest priority Characteristics of Security Policies :
Security policies are refreshed every 16 hours even if they have not changed.
Security policies are always processed, even across slow connections.
1.3.4. Troubleshooting Script Policy Settings

The Scripts CSE updates the registry with the location of script files so that the UserInit process can find those 108
Created by XMLmind
XSL-FO Converter.
values during its normal processing. When a CSE reports success, it might mean only that the scripts location is placed in the registry. Even though the setting is in the registry, there could be problems preventing the setting from being applied to the client. For example, if a script specified in a Script setting has an error that prevents it from completing, the CSE does not detect an error When troubleshooting script policy settings, consider the following:
Validate the script
Ensure that users and computer have access to the script
Ensure that Group Policy is configured correctly
Ensure the script is replicating properly
Use the Group Policy tools to ensure that Group Policy is applied correctly Group Policy processes a GPO and stores the script information in the registry, in these locations:
HKCU\Software\Policies\Microsoft\Windows\System\Scripts (User Scripts)
HKLM\Software\Policies\Microsoft\Windows\System\Scripts (Machine Scripts)
109
Created by XMLmind
XSL-FO Converter.

70-640 - Windows 2008 Active Directory

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

70-640 - Windows 2008 Active Directory

Încărcat de

Drepturi de autor:

Formate disponibile

Microsoft Technologies: Windows 2008 Active Directory (70-640)

Romain LACOUR, SUPINFO Certified Trainer

Microsoft Technologies: Windows 2008 Active Directory (70-640)

Active Directory Sites and replications

Chapter 1. Introduction to Active Directory Domain Services

Overview of Active Directory Domain Services

Overview of AD DS Logical Components

Overview of AD DS Physical Components

1.1.1. What is a directory service?

1.1.2. How Does AD DS Work?

1.1.3. What Is LDAP?

DN: CN=Romain Lacour,OU=MSLab,DC=supinfo,DC=lan

1.1.4. Why deploy Active Directory Domain Services?

1.2. Overview of AD DS Logical Components

1.2.1. The AD DS Schema

An administrative boundary for applying policies to groups of objects

A replication boundary for replicating data between domain controllers

Example 1.1. Domain Controller Promotion

1.2.4. Domain Trees

All domains in the domain tree:

Have a contiguous namespace with the parent domain

Can have additional child domains added to the namespace

Share a common schema between all domains in the forest

Share a common configuration partition

Share a common global catalog to enable searching

Enable trusts between all domains in the forest

1.2.6. Organizational Units

Represent your organization hierarchically and logically

Manage a collection of objects in a consistent way

Delegate permissions to administer groups of objects

Table 1.1. AD DS Objects

1.3. Overview of AD DS Physical Components

1.3.1. AD DS Domain Controllers

1.3.2. DNS and AD DS

1.3.3. Global Catalog Servers

1.3.4. AD DS Data Store

Ensures that all domain controllers have the same information

Can be managed by creating AD DS sites

Associated with IP subnets

Used to manage replication traffic

Used to manage client logon traffic

1.4. AD DS Management Tools

Chapter 2. Implementing Active Directory Domain Services

Installing Active Directory Domain Services

Deploying Read-Only Domain Controllers

Configuring Active Directory Domain Services Controller Roles

1.1.1. Requirements for Installing AD DS

Windows Server 2008, Standard Edition

Windows Server 2008, Enterprise Edition

TCP/IP must be configured, including DNS client settings

Local Administrator permissions to install the first domain controller in a forest

Domain Administrator permissions to install additional domain controllers in a domain

Enterprise Administrator permission to install additional domains in a forest

1.1.2. What are Domain and Forest functional Levels

Table 2.1. Supported functional levels

Windows Server 2003

Table 2.2. Domain functional level features

Windows Server 2008

Table 2.3. Forest functional level features

Forest trusts. You can create a trust between two forests.

Improved Knowledge Consistency Checker (KCC) algorithms and scalability.

Improved ISTG algorithm

1.1.3. AD DS Installation Process