70-640 - Windows 2008 Active Directory

http://www.supinfo.com

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

3 http://www.supinfo.com

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 e-

mail 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


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.


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.


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.


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


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


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 controller’s 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


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.


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


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.

13

Created by XMLmind XSL-FO Converter.

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

14


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 Supported Domain Controller

Operating Systems

Forests

Windows 2000 Native

Windows Server 2008

Windows Server 2003

Windows 2000

Windows 2000

Windows Server 2003

Windows Server 2008

Windows Server 2003

Windows Server 2003

Windows Server 2008

Windows Server 2008

Windows Server 2008

Domain functional levels enable features accros the domain.

Table 2.2. Domain functional level features

Domain functional level Enabled features

Windows 2000 Native

All default Active Directory features and the following features:

Universal groups are enabled for both distribution and security groups.

15


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.

Windows Server 2003

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.

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.

Windows Server 2008

All previous features and the following features:

Distributed File System Replication (DFSR) support for SYSVOL, which

provides more reliable replication of SYSVOL contents.

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.

16


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 Enabled features

Windows 2000 All default Active Directory features.

Windows Server 2003

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.

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

17


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

18


Types of installation media Parameter Description

Writable domain controller Create full %s Creates installation media for a

writable domain controller into

folder %s

Read-only domain controller Create RODC %s Create installation media for an

RODC into folder %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.

19


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.

20


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.

21


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.

22


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 Description

Schema Master

One per forest

Performs all updates to the Active Directory Schema

Domain Naming

Master One per forest

Controls the addition or removal of domains in the forest. When you add a new

23


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.

24


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:

25


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.

26


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.

27


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 DNS-

specific 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.

28


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:

29


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.

30


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.

31


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.

32


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 e-

mails 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

33


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

Domain Local

Universal groups, global groups, and other domain

local groups from its own domain

Accounts from any trusted domain

In its own domain

Global User, groups, and computers from its own domain

In any trusted domain

Universal

Users, groups, and computers from any trusted

domain

In any trusted domain

Local

Users, groups, and computers from any trusted

domain

On the local computer only where

local groups are created

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

34


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

35


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.

36


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.

37


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 "[email protected]" -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: [email protected] 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: [email protected] description: SCT for Microsoft Lab DN: CN=Jenner VERNAL,OU=SCT,OU=Martinique,DC=supinfo,DC=lan changetype: add objectClass: User

38


givenName: Jenner sn: VERNAL sAMAccountName: jvernal displayName: Jenner VERNAL userPrincipalName: [email protected] 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", "[email protected]" user, "CN=Come FERTE, OU=SCT, OU=Montreal, DC=supinfo, DC=lan", "cferte", "Come", "FERTE", "SCT for Microsoft Lab", "[email protected]" user, "CN=Arnaud BERTHIER, OU=SCT, OU=Paris, DC=supinfo, DC=lan", "aberthier", "Arnaud", "BERTHIER", "SCT for Microsoft Lab", "[email protected]"

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.

39


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","[email protected]") $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

40


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.

41


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

42


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

43


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.

44


The UPN contains two different parts that are separated by the @sign, for example, [email protected]:

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.

45


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

46


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.

47


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.

48


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

49


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

50


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

51


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.

52


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

53


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 site’s 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.

54


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.

55


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.

56


DcDiag: Command line tool that you can use to monitor replication between domain controllers.

57


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.

58


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

59


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

60


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 application-

specific 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 computer’s 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 domain’s 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

61


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.

62


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.

63


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

64


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.

65


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.

66


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.

67


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.

68


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

69


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 folder’s storage location from the local hard disk on the user’s

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

70


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 user’s 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.

71


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 registry-

based 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 computer’s 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:

72


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 organization’s 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 application’s 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

73


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 computer’s 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 user’s 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

74


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

75


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.

76


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.

77


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 Description

Password

Enforce password history : 24 password

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

78


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 ?

79


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

80


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

81


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 :

82


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

83


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 :

84


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.

85


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.

86


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

87


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

88


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 opérating 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.

89


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 Description

Ntds.dit

Active Directory database file

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

90


File Description

ebdres00002.jrs Reserved transaction log files

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

91


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

92


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

93


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 command-

line 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.

94


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

95


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

96


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

97


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

98


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

99


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 ISP’s 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 server’s

properties to verify the database is responding. As well, clear the DNS server’s cache to ensure that the cache

is not polluted, or that it has the latest zone information

Use ipconfig /flushdns to clear the client’s 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

100


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 computer’s DNS client service.

PTR records are manually configured.

SRV records are updated by the DC’s 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

101


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 Possible causes

Replication does not finish or occur

Sites not connected by site links

No bridgehead server in the site group

Replication is slow

Inefficient site topology and schedule

102


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 Testing method

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

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 :

103


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.

104


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 problem’s 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

105


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.

106


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 GPO’s 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

107


change increments the version number of the GPT and the GPC.

1.2.4. Troubleshooting Group Policy Refresh

Group Policy refresh refers to a client’s 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

108


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 category’s 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 environment’s 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

109


values during its normal processing. When a CSE reports success, it might mean only that the script’s 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)

Date post:	28-Nov-2014
Category:	Documents
Upload:	camelia-ouadghiri
View:	494 times
Download:	0 times