Active Directory Facts

Active Directory is a centralized database that contains user account and security information. In a workgroup, security and management takes place on each computer, with each computer holding information about users and resources. With Active Directory, all computers share the same central database.

The Active Directory structure is a hierarchical framework with the following components:

Component Description

Domain

A domain is an administratively-defined collection of network resources that share a common directory database and security policies. The domain is the basic administrative unit of an Active Directory structure.

Database information is replicated (shared or copied) within a domain.

Security settings are not shared between domains.

Each domain maintains its own set of relationships with other domains.

Domains are identified using DNS names. The common name is the domain name itself. The distinguished name includes the DNS context or additional portions of the name.

Depending on the network structure and requirements, the entire network might be represented by a single domain with millions of objects, or the network might require multiple domains.

Objects

Within Active Directory, each resource is identified as an object. Common objects include:

Users

Groups

Computers

Shared folders

You should know the following about objects:

Each object contains attributes (i.e. information about the object such as a user's name, phone number, and email address) which is used for locating and securing resources.

The schema identifies the object classes (the type of objects) that exist in the tree and the attributes (properties) of the object.

Active Directory uses DNS for locating and naming objects.

Container objects hold or group other objects, either other containers or leaf objects.

Organizational Unit (OU)

An organizational unit is like a folder that subdivides and organizes network resources within a domain. An organizational unit:

Is a container object.

Can be used to logically organize network resources.

Simplifies security administration.

You should know the following about OUs:

First-level OUs can be called parents.

Second-level OUs can be called children.

OUs can contain other OUs or any type of leaf object (e.g. users, computers, and printers).

Generic Containers

Like OUs, generic containers are used to organize Active Directory objects. Generic container objects:

Are created by default

Cannot be created, moved, renamed, or deleted

Have very few editable properties

Trees and Forests

Multiple domains are grouped together in the following relationship:

A tree is a group of related domains that share the same contiguous DNS name space.

A forest is a collection of related domain trees. The forest establishes the relationship between trees that have different DNS name spaces.

Trees and forests have the following characteristics:

The forest root domain is the top-level domain in the top tree. It is the first domain created in the Active Directory forest.

The tree root domain is the highest level domain in a tree.

Each domain in the tree that is connected to the tree root domain is called a child domain.

A domain tree is a group of domains based on the same name space. Domains in a tree:

o Are connected with a two-way transitive trust. o Share a common schema. o Have common global catalogs.

Domain Controller

A domain controller is a server that holds a copy of the Active Directory database that can be written to. Replication is the process of copying changes to Active Directory between the domain controllers.

Sites and Subnets

Active Directory uses the following two objects to represent the physical structure of the network.

A subnet represents a physical network segment. Each subnet possesses its own unique network address space.

A site represents a group of well-connected networks (networks that are connected with high-speed links).

You should know the following about sites and subnets:

Sites and subnets are used to manage Active Directory replication between locations.

All Active Directory sites contain servers and site links (the connection

between two sites that allows replication to occur).

Site links are used by Active Directory to build the most efficient replication topology.

A site differs from a domain in that it represents the physical structure of your network, while a domain represents the logical structure of your organization.

Clients are assigned to sites dynamically according to their Internet Protocol (IP) address and subnet mask.

Domain controllers are assigned to sites according to the location of their associated server object in Active Directory.

The Active Directory database resides in a file called NTDS.dit. It is the physical database file in which all directory data is stored. This file consists of three internal tables:

The data table contains all the information in the Active Directory data store: users, groups, application-specific data, and any other data that is stored in Active Directory after its installation.

The link table contains data that represents linked attributes, which contain values that refer to other objects in Active Directory.

The security descriptor (SD) table contains data that represents inherited security descriptors for each object.

Active Directory Features Facts

As you work with Active Directory, you should understand the following concepts:

Feature Description

Global Catalog

The Global Catalog (GC) is a database that contains a partial replica of every object from every domain within a forest. A server that holds a copy of the Global Catalog is a global catalog server. The Global Catalog facilitates faster searches because different domain controllers do not have to be referenced.

Operations Master Roles

Operations master roles, also referred to as Flexible Single-Master Operation (FSMO) roles, are specialized domain controller tasks assigned to a domain controller in the domain or forest. Operations master roles are useful because certain domain and enterprise-wide operations are not well suited for the multi-master replication performed by Active Directory to replicate objects and attributes. A domain controller that performs an operations master role is known as an operations master or operations master role owner.

The following roles are forest roles, meaning that one domain controller within the entire forest holds the role:

The schema master maintains the Active Directory schema for the forest.

The domain naming master adds new domains to and removes existing domains from the forest.

The following roles are domain roles, meaning that one domain controller in each domain holds the role:

The RID master allocates pools or blocks of numbers (called relative IDs or RIDs) that are used by the domain controller when creating new security principles (such as user, group, or computer accounts).

The PDC emulator acts like a Windows NT 4.0 Primary Domain Controller (PDC)

and performs other tasks normally associated with NT domain controllers.

The infrastructure master is responsible for updating changes made to objects.

As you install or remove domain controllers, you will need to be aware of which domain controllers hold these roles.

Time Service

The Windows time service (w32tm.exe) provides network date and time synchronization for computers in an Active Directory domain. The Windows Time service:

Is an essential component of Kerberos authentication, file timestamps, and data replication.

Is installed by default in the %Systemroot%\System32 folder during operating system setup and installation.

Uses the Network Time Protocol (NTP) to synchronize computer clocks on the network so that an accurate clock value, or time stamp, can be assigned to network validation and resource access requests.

Integrates NTP and time providers, making it reliable and scalable in an enterprise environment.

Is backwards compatible with Simple Network Time Protocol (SNTP), which is an older protocol used in some versions of Windows.

Functional Level

A functional level is a set of operation constraints that determine the functions that can be performed by an Active Directory domain or forest. A functional level defines:

Which Active Directory Domain Services (AD DS) features are available to the domain or forest.

Which Windows Server operating systems can be run on domain controllers in the domain or forest. Functional levels do not affect which operating systems you can run on workstations and servers that are joined to the domain or forest.

Windows Server 2008 or Windows Server 2008 R2 supports the following domain functional levels:

Windows 2000 Native

Windows Server 2003

Windows Server 2008

Windows Server 2008 R2 (limited to Windows Server 2008 R2)

Windows Server 2008 or Windows Server 2008 R2 supports the following forest functional levels:

Windows 2000

Windows Server 2003

Windows Server 2008

Windows Server 2008 R2 (Limited to Windows Server 2008 R2)

Note: You cannot have Windows NT domain controllers and Windows Server 2008 or Windows Server 2008 R2 domain controllers in the same forest.

Group Policy

A policy is a set of configuration settings that must be applied to users or computers. Collections of policy settings are stored in a Group Policy object (GPO). The GPO is a collection of files that includes registry settings, scripts, templates, and software-specific configuration values.

Group Policy is an important component of Active Directory because through Group Policy you can centrally manage and enforce desktop and other settings for users and computers within your organization. For example, with Group Policy you can:

Enforce a common desktop for users

Remove desktop components, such as preventing access to the Control Panel

Restricting what actions users can perform, such as preventing users from shutting down the system

Automatically installing software

Dynamically set registry settings required by applications

Active Directory Server Roles

An Active Directory server role is a logical grouping of features and services that are required to perform a specific function in the Active Directory environment. Prior to Windows Server 2008, some Active Directory server roles were not incorporated into the Active Directory, rather they were available as Microsoft downloads. Functionality and services are added to your server by adding the following:

A role is a set of software features that provides a specific server function. Examples of roles include DNS server, DHCP server, File Server, and Print Server.

Role services are specific programs that provide the functions of a role. Some roles, like DNS, have a single role service. Other roles, like Print Server, have multiple role services such as the LPD Service for Unix printing and Internet Printing. You can think of a role as a group of programs, with each role service being a sub-component of the role.

A feature is a software program not directly related to a server role but which adds functionality to the entire server. Features include management tools, communication protocols or clients, and clustering support.

The Active Directory server roles are described in the following table:

Role Description

Active Directory Domain Services (AD DS)

AD DS is a distributed database that stores and manages information about network resources, such as users, computers, and printers. The AD DS role:

Helps administrators securely manage information.

Facilitates resource sharing and collaboration between users.

Is required to be installed on the network to install directory-enabled applications such as Microsoft Exchange Server and for applying other Windows Server technologies, such as Group Policy.

Active Directory Lightweight Directory Service (AD LDS)

Active Directory Lightweight Directory Services (AD LDS), formerly known as Active Directory Application Mode (ADAM), is an LDAP directory service that you can use to create a directory store (database) for use by directory-enabled applications. AD LDS is very similar to Active Directory Domain Services (AD DS), but is customizable and can be much smaller than an AD DS database.

Active Directory Federation

AD FS is a feature which enables secure access to web applications outside of a user's home domain or forest. The AD FS role:

Services (AD FS)

Provides Web Single-Sign-On (SSO) technologies to authenticate a user to multiple Web applications using a single user account.

Securely federates (shares) user identities and access rights in the form of digital claims between partner organizations.

Active Directory Rights Management Service (AD RMS)

AD RMS is a feature which safeguards digital information from unauthorized use. The AD RMS role:

Can define exactly how a recipient can use information, specifying who can open, modify, print, forward, and/or take other actions.

Allows organizations to create custom usage rights templates (such as "Confidential - Read Only") that can be applied directly to information such as product specifications, financial reports, e-mail messages, and customer data.

Active Directory Certificate Services (AD CS)

AD CS is an identity and access control feature that creates and manages public key certificates used in software security systems. The AD CS role:

Provides customizable services for creating and managing public key certificates.

Enhances security by binding the identity of a person, device, or service to a corresponding private key.

Includes features that allow you to manage certificate enrollment and revocation in a variety of scalable environments.

AD CS supports:

Digital signatures

Encrypting File System (EFS)

Internet Protocol security (IPsec)

Secure/Multipurpose Internet Mail Extensions (S/MIME)

Secure Socket Layer/Transport Layer Security (SSL/TLS)

Secure wireless networks

Smart card logon

Virtual Private Networks (VPN)

Note: All roles except for AD FS are supported on the Standard, DataCenter, and Enterprise editions of 2008. AD FS requires the DataCenter or Enterprise editions for deployment.

Server Core Facts

Server core is a minimal server installation option which provides a low-maintenance version of Windows Server 2008 and Windows Server 2008 R2. Be aware of the following when using server core:

The server core interface has limited GUI support, with most tasks being performed only from a command prompt.

You can only perform a clean installation of server core; you cannot upgrade to or from server core.

Server core can only run a limited set of server roles:

o Active Directory o Active Directory Lightweight Directory Services (AD LDS) o Active Directory Certificate Services (AD CS) (Limited to Windows Server 2008 R2) o Dynamic Host Configuration Protocol (DHCP) Server o DNS Server o File Server o File Server Resource Manager of the File Services role (Limited to Windows Server 2008

R2) o Print Server o Media Services o Web Server (IIS): Subset of ASP.NET (Limited to Windows Server 2008 R2)

Features currently available in Windows Server 2008 R2 server core include: o .NET Framework

A subset of .NET Framework 2.0 A subset of .NET Framework 3.0 A subset of .NET Framework 3.5

o Windows PowerShell o Windows-on-Windows 64-bit (WoW64)

To manage a server core system: o Log on and use the command prompt. o Log on using Remote Desktop to gain access to the command prompt. o Use Windows Remote Shell (winrm). o Run Server Manager or another tool on another computer and connect to the server core

system. This method allows you to use a GUI interface for managing the server core system.

Run oclist to see a list of roles, role services, and features that can be installed on server core.

Run start /w ocsetup to add server roles to the server core system. Switches for the role or service must be typed exactly as they are listed, and role names are case-sensitive.

OU Facts

An Organizational Unit (OU) is similar to a folder that subdivides and organizes network resources within a domain.

An OU can contain other OUs or any type of object type, such as users, computers, and printers.

OUs can be nested to logically organize network resources. o Parent OUs are OUs that contain other OUs. o Child OUs are OUs within other OUs.

OUs are typically organized by the following: o Physical location, such as a country or city. o Organizational structure, such as the HR, Sales, and IT departments. o Object type, such as user accounts or computers. o Hybrid of location, organizational structure, and object type.

Be aware of the following considerations for managing OUs:

Feature Description

Group Policy

One of the biggest reasons to use OUs is for the application of Group Policy. Create OUs for each group of objects that need to have different Group Policy settings.

Group Policy objects (GPOs) can be linked to OUs. Policy settings apply to all objects within the OU.

Through inheritance, settings applied to the domain or parent OUs apply to all

child OUs and objects within those OUs.

Note: A generic container is not an OU and can't have group policy objects assigned to it. A good practice is to move objects out of generic containers and into an OU. For example, you can move the computers out of the Computers container and into an OU where group policy can be applied.

Preventing accidental deletion

Objects in Active Directory can be accidentally deleted through Active Directory Users and Computers and other management tools. The following types of deletions are most common:

Leaf-node deletion is when a user selects and deletes a leaf object.

Organizational Unit (OU) deletion is when a user selects and deletes an OU that has subordinate objects. Deleting the OU deletes all objects within the OU (including any child OUs and their objects).

To protect objects from accidental deletion:

In Active Directory Users and Computers or Active Directory Sites and Services, edit the properties and do one of the following:

o On the Object tab, select the Protect object from accidental deletion check box. (This option is only seen with Advanced Features selected from the View menu.)

o On the Security tab, select the Deny Delete All Child Objects advanced permission for Everyone.

When you create an organizational unit, leave the Protect container from accidental deletion check box selected. This is the default. Other types of objects do not have this default setting and must be manually configured.

To delete an object that is protected, first clear the Protect container from accidental deletion setting, then delete the object.

Delegating authority

Delegating authority is the assignment of administrative tasks, such as resetting passwords or creating new users, to appropriate users and groups. You should be aware of the following facts about delegating control:

You can delegate control of any part of an OU or object at any level with the Delegation of Control Wizard or through the Authorization Manager console.

An object-based design allows you to delegate control based on the types of objects in each OU. For example, you can delegate control over specific object types (such as user objects).

A task-based design allows you to delegate control based on the types of administrative tasks that need to be done. Some examples of administrative tasks are:

o User account management, such as creation and deletion. o Password management, such as resetting and forcing password

changes. o Group membership and permissions management

Default Containers

When you install Active Directory, several default containers and Organizational Units (OUs) are automatically created. The following table lists the default containers and their contents:

Container or OU Contents

Builtin The Builtin container holds default service administrator accounts and domain local security groups. These groups are pre-assigned permissions needed to perform domain management tasks.

Computers The Computers container holds all computers joined to the domain without a computer account. It is the default location for new computer accounts created in the domain.

Domain Controllers The Domain Controllers OU is the default location for the computer accounts for domain controllers.

ForeignSecurityPrincipals The ForeignSecurityPrincipals container holds proxy objects for security principals in NT 4.0 domains or domains outside of the forest.

LostAndFound

The LostAndFound container holds objects moved or created at the same time an Organizational Unit is deleted. Because of Active Directory replication, the parent OU can be deleted on one domain controller while administrators at other domain controllers can add or move objects to the deleted OU before the change has been replicated. During replication, new objects are placed in the LostAndFound container.

NTDS Quotas The NTDS Quotas container holds objects that contain limits on the number of objects users and groups can own.

Program Data The Program Data container holds application-specific data created by other programs. This container is empty until a program designed to store information in Active Directory uses it.

System The System container holds configuration information about the domain including security groups and permissions, the domain SYSVOL share, DFS configuration information, and IP security policies.

Users

The Users container holds additional predefined user and group accounts (besides those in the Builtin container). Users and groups are pre-assigned membership and permissions for completing domain and forest management tasks.

Be aware of the following when managing the default containers:

Default containers are automatically created and cannot be deleted.

The Domain Controllers OU is the only default organizational unit object. All other containers are just containers, not OUs. As such, you cannot apply a GPO to any default container except for the Domain Controllers OU.

To apply Group Policy specifically to objects within a default container (except for the Domain Controllers OU), move the objects into an OU that you create, then link the GPO.

The LostAndFound, NTDS Quotas, Program Data, and System containers are hidden in Active Directory Users and Computers. To view these containers, click Advanced Features from the View menu.

User Account Facts

A user account identifies a single user, such as an employee. Windows has the following types of user accounts:

Type Description

Local

A local user account is created and stored on a local system and is not distributed to any other system.

Local user accounts are created with the Computer Management console.

The local Security Accounts Manager (SAM) manages the user account information.

Only local resources are accessible with local user accounts.

Domain

A domain user account is created and centrally managed through Active Directory, and is replicated between domain controllers in the domain.

Domain user accounts are created with Active Directory Users and Computers, command line tools, and PowerShell.

Each domain user account has a unique security identifier (SID) to identify the user. A user can log on to the domain from any computer that is a member of the domain and can access resources on that computer or on other computers for which the domain user account has permissions.

Domain user accounts have a variety of properties, such as user information, group membership, user profiles, and dial-in settings.

Note: External users which need an e-mail account, can be represented through a contact object. A contact object is an account that does not have any security permissions. Users represented as contact objects cannot log on to the domain. Use contacts to add information about individuals, such as e-mail or phone number, to Active Directory. Applications, such as Exchange, can search for attributes of contact objects.

Active Directory uses the following name types to recognize each object:

Type Description

User or Logon Name

The user or logon name is the name of the user account. It is typically a combination of the given name (first name) and surname (last name) of the user. For example, Andy Waters may have the following logon name, awaters.

User Principal Name (UPN)

The User Principal Name (UPN) combines the user account name with the DNS domain name. For example, account awaters in the westsim.com domain would have awaters@westsim.com as the UPN.

The UPN format is also known as the SMTP address format.

The DNS domain name in the UPN is known as the UPN suffix.

By default, the domain that holds the user account is selected for the UPN suffix. However, you can configure different UPN suffixes to use instead of the domain name.

LDAP Distinguished Name (DN)

The LDAP Distinguished Name (DN) references the domain and related container(s) where the object resides. It has three basic attributes:

Domain Component (DC)

Organizational Unit (OU)

Common Name (CN)

An example LDAP Distinguished Name (DN) is:

CN=awaters, OU=sales, DC=westsim, DC=com

Relative Distinguished Name (RDN)

The Relative Distinguished Name (RDN) is used to identify the object within its container. The RDN needs to be unique only within the object’s container. In the example above, the RDN is CN=awaters.

User Account Management Facts

Keep in mind the following recommendations when managing user accounts:

Use Active Directory Users and Computers from a domain controller or workstation with Administrative Tools installed to configure domain accounts.

To modify properties on multiple user accounts at once, use the Shift or Ctrl keys to select all users, then edit the necessary properties. Properties such as the logon name or password cannot be modified in this way.

You can move user accounts to add them to the appropriate OUs. Grouping users within OUs allows you to apply Group Policy settings to groups of users.

When creating a new user account or resetting a forgotten password, a common practice is to reset the user account password, then select User must change password at next logon. This forces the user to reset the password immediately following logon, ensuring that the user will be the only person who knows the password.

Enable the User cannot change password option when you want to maintain control over a Guest, service, or temporary account. For example, many applications use service accounts for performing system tasks. The application must be configured with the user account name and password. If you allow changing the user account password for the service account, you would also need to change the password within every application that uses that account.

To reset the user account password, right-click the user object and select Reset Password.

An account which has been locked out because too many incorrect passwords have been entered must be unlocked. To unlock an account, go to the Account tab in the account object's Properties dialog box, and select the Unlock Account box. The Reset Password dialog also gives you the option to unlock a user account.

You can configure an expiration date for temporary user accounts. Once the account is expired, it cannot be used for logon.

If a user will be gone for an extended period of time, disable the account. This prevents the account from being used during the user's absence. Enable the account when the user returns.

Configure the logon hours for a user account to allow the account to only be used between specific hours.

o Logon attempts outside of the specified hours will not be allowed. o Users who are currently logged on will be allowed to continue working when the logon

hours expire. o To log a user off when the logon hours pass, configure Group Policy settings to log the

user off automatically.

You can configure a list of workstations that a user is allowed to log on to. When configured, logon to other workstations will not be allowed.

The user profile tracks user environment settings, such as program-specific settings, user security settings and desktop settings (including the files, folders, and shortcuts on the desktop).

o By default, the profile is stored on the local computer. A profile will be created on each computer when a user logs on.

o To make profile settings consistent across computers, use a roaming user profile (where the profile is saved on a network share). When the user logs on, profile settings are

copied from the network to the local computer. Changes made on the local computer are saved back to the network share.

o To use a roaming profile, edit the user account properties and specify the profile path. To simplify administration, use the %username% variable in the Profile Path. Active Directory replaces %username% with the user logon name.

If you accidentally delete a user account, restore it from backup rather than creating a new one with the same name. Creating a new account with the same name results in a user account with a different SID and will not automatically assume the permissions and memberships of the previously deleted account.

Deprovisioning is the process of removing access rights for users when they leave your organization.

o If the user will be replaced by another user, disable the existing account. When the new user starts, rename the account, reset the password, and enable the account. This process preserves all of the permissions and other settings associated with the user.

o If the user will not be replaced, you can delete the account. Be sure to reassign any permissions to other users, reassign ownership over files, or delete unnecessary files such as the user profile. After a user account has been deleted, all permissions and memberships that are associated with that user account are permanently deleted. All permissions and memberships must be recreated manually if you want to duplicate a deleted user account.

o Many third-party tools exist that can simplify the deprovisioning process. For example, you can delete the user account and automatically reassign permissions or file ownership with a single step. You can also create your own deprovisioning solution through a programming language to synchronize accounts between databases or applications.

To create another user account similar to an existing user, copy the existing user account. You will be prompted for a new name and password. Existing account settings and group memberships will be copied to the new account. Permissions will not be copied to the new account.

If you regularly create user accounts with the same settings, you can create a template account. The template account is a normal user account with the settings you need for subsequent accounts.

o Copy the account whenever you need to create a new one. o New accounts retain group memberships but not direct permission assignments. o Disable this account to prevent it from being used for logon.

Adding a User Principal Name (UPN) suffix to a forest allows the users who join the forest to use a friendly user-logon name that does not match the domain name. To add a UPN suffix to a forest:

1. Open Active Directory Domains and Trusts. 2. Right-click Active Directory Domains and Trusts in the Tree window pane, then select

Properties. 3. Type the new UPN suffix that you would like to add to the forest on the UPN Suffixes

tab. 4. Click Add. 5. Click OK.

You can authenticate a user who logs on with a certificate by mapping the certificates to the user account. To map a certificate to a user account:

0. Open Active Directory Users and Computers 1. Enable the Advanced view. 2. Right-click the user account, and then choose Name Mappings. 3. Add the certificate to the x.509 tab.

Use the Active Directory module for Windows PowerShell to manage user accounts (and other objects) on a computer running Windows Server 2008 R2. The Active Directory module consolidates a group of cmdlets needed to manage user accounts, including:

o New-ADUser creates a new Active Directory user. o Get-ADUser displays one or more Active Directory users' properties.

o Set-ADUser modifies an Active Directory user. o Enable-ADAccount/Disable-ADAccount enables/disables an Active Directory account. o Search-ADAccount gets Active Directory user, computer, and service accounts. o Unlock-ADAccount unlocks an Active Directory account. o Remove-ADUser removes an Active Directory user.

To use the Active Directory module for Windows PowerShell: o Run the Import-Module ActiveDirectory command at the Windows PowerShell prompt. o Launch Active Directory Module for Windows PowerShell from Start\Administrative

Tools.

To import large amounts of users from a comma-separated value (CSV) file, use the import-CSV command with the results sent (or piped) to the New-ADUser command.

Computer Account Facts

A computer account is an Active Directory object that identifies a network computer. The account in Active Directory is associated with a specific hardware device. To identify a specific computer, two processes are required:

Create a computer account in Active Directory.

Join a computer to the domain. When you join the domain, the device is associated with the Active Directory computer account.

You can perform these processes in the following ways:

Method Description

Manual join

From the computer, edit the System properties to join the domain. The computer contacts the domain controller, and a computer account is created in Active Directory. When you join a domain and create a new computer account in one step, the computer account is added to the Computers built-in folder in Active Directory.

Pre-stage accounts

Prior to the computer joining the domain, you can create a computer account for the computer in Active Directory. When the computer joins the domain, the computer is matched to the existing computer account. Use this method to control the location of the computer account in Active Directory.

Offline domain join

During the domain join process, the workstation must communicate with a domain controller. In situations where a network connection does not exist, you can use the offline domain join feature to join the computer to the domain. To perform an offline join:

1. Run Djoin.exe /provision on a computer that can communicate with a domain controller (this computer is called the provisioning computer). This process creates the computer account and generates a text file with information that the joining computer will need.

2. Copy the resulting file to the computer that you want to join to the domain. Run Djoin.exe /requestODJ to insert the file into the Windows directory. When you reboot the computer, it will be joined to the domain. You can also insert the account metadata into an Unattend.xml file and use the file during installation to join the computer to the domain during the install process.

Note: You can only run Djoin.exe on a computer running Windows Server 2008 R2 or Windows 7 (or higher). This means that only computers running this operating system can be joined to the domain offline. By default, Djoin contacts a domain controller running Windows Server 2008 R2, but you can run Djoin with the /downlevel parameter to communicate with a non-Windows 2008 R2 domain controller.

Be aware of the following facts about computer accounts and joining a domain:

Because the Computers folder is not an OU, you cannot link a GPO to this container, meaning that only Group Policy settings in the domain will apply to these computers. For more control over Group Policy settings for computers or groups of computers, move computer accounts to OUs.

To control where computer accounts are placed when the computer joins the domain, create computer accounts ahead of time before joining the domain from the workstation.

The following group members can create a computer account: o Account Operators o Domain Admins o Enterprise Admins

Members of the Authenticated Users group can join up to 10 computers to a domain from a workstation (and create the computer account automatically if it does not already exist). This ability comes from the Add workstations to a domain user right. You can also allow specific users to join specific computers to a domain by selecting The following user or group can join this computer to a domain when creating the computer account.

You can grant other users permissions to create computer accounts by giving them the Create Computer Objects right over the Active Directory OU. This permission does not have a limit on the number of accounts that can be created. Note: You must grant this right to the domain or specific OUs.

To join a computer to a domain, you must be a member of the Administrators group on the local computer or be given the necessary rights.

Use the dsadd and netdom utilities to create computer accounts from a command prompt or a script. Use netdom to rename a computer account. Use netdom join to join a computer to a domain.

After a computer account is created, you must join the computer to the domain before the computer receives Group Policy settings or before Active Directory receives workstation-specific information.

Each computer has a password that is automatically-generated when the computer joins the domain.

When the computer boots, this password is used to authenticate the computer to the domain. This password is used to establish a secure channel between the computer and the domain controller.

The password is saved on the local computer and in Active Directory. By default, the password is changed automatically every 30 days.

If the two passwords become unsynchronized, the computer will not be able to connect to the domain, and you will see an error indicating that the computer failed to authenticate. This problem will also occur if you have rebuilt the computer, or if you are replacing the computer with another one using the same computer account name.

When computer logon fails, reset the computer account. To reset the account, use one of the following methods:

o Run the netdom reset command followed by the computer account name and the domain.

o In Active Directory Users and Computers, right-click the computer account and select Reset Account.

o Create a script in Visual Basic.

After resetting the computer account, you must rejoin the computer to the domain.

Service Account Facts

A service account is a special user account that an application or service uses to interact with the operating system. Services use the service accounts to log on and make changes to the operating

system or the configuration. Through permissions, you can control the actions that the service can perform. The following table identifies categories of service accounts.

Account Type

Description

Built-in local user account

A built-in user account is a user account that is created automatically during installation. The following three built-in user accounts are used by most services:

The Local System account (also called the System account) is a member of the local Administrators group.

The Local Service account has access rights similar to members of the Users group. This account accesses network services using a null session with no credentials. For this reason, this account might not provide sufficient network access for some services.

The Network Service account has access rights similar to members of the Users group. This account accesses network resources using the credentials of the computer account.

When using built-in local user accounts:

Accounts are automatically created.

You do not need to manage or reset account passwords.

Multiple services use the same user account, making it difficult to customize security for a specific service.

Domain user account

You can create domain user accounts for use by services. With domain user accounts:

User accounts are managed centrally in Active Directory.

You can create a single user account for a single service, or share a user account for multiple services.

You can grant only the specific privileges required by the service.

You must manage account passwords. For example, you will need to periodically reset the account password on the account as well as reset the password used by the service.

Managed service account

A managed service account is a new account type available in Windows Server 2008 R2 and Windows 7. A managed service account provides the same benefits of using a domain user account with these improvements:

Passwords are managed and reset automatically.

When the domain is running at the Windows Server 2008 R2 functional level, the service principal name (SPN) doesn't need to be managed as with local accounts.

When using a managed service account:

A user account can be used on only one computer (you must create at least one account per computer).

Each account can be used by multiple services on a computer. You can also create a separate account for each service.

Virtual account

A virtual account is a new account type available in Windows Server 2008 R2 and Windows 7. Virtual accounts:

Are not created or deleted.

Use a single account for a single service. If you have multiple services that use virtual accounts, there will be a different account for each service.

To configure a service to use a virtual service account, simply edit the service properties and configure the account to use an account name of NT SERVICE\ServiceName (where ServiceName matches the name of the service).

To use managed or virtual accounts:

Computers must be running Windows Server 2008 R2 or Windows 7 for the service to use the managed or virtual account.

You must update the Active Directory schema to Windows Server 2008 R2.

Domain controllers can be Windows Server 2003, 2008, or 2008 R2. If the domain controller is below Windows Server 2008 R2, you must have the Active Directory Management Gateway Service.

If a domain controller is running Windows Server 2008 R2 (or higher), service principal names (SPN) are managed automatically. If you do not have a domain controller running at least Windows Server 2008 R2, you must manage the SPN manually. Password resets are automatically managed for any supported domain controller.

Use the Active Directory module for Windows PowerShell to manage service accounts (and other objects). Common service account cmdlets include:

o New-ADServiceAccount creates a managed service account. By default, accounts are created in the Managed Service Account container in Active Directory (you can also specify an alternate OU for the new accounts).

o Get-ADServiceAccount displays properties for managed service accounts. o Set-ADServiceAccount modifies settings. o Remove-ADServiceAccount deletes a managed service account. o Install-ADServiceAccount allows the computer to use the managed service account

(install the account). Run Uninstall-ADServiceAccount to uninstall the account.

Group Facts

A group is used to collect user accounts, computer accounts, and other group accounts into manageable units. Working with groups instead of individual user accounts helps simplify network maintenance and administration. For instance, through groups the users receive all the user rights assigned to the group and all the permissions assigned to the group on any shared resources.

Like user accounts, there are both local and domain groups.

Local groups exist only on the local computer, and control access to local resources.

Domain groups exist in Active Directory, and can be used to control access to domain and local resources. In an Enterprise environment, you will work mainly with domain groups.

Active Directory groups have a group scope. The scope defines the potential group membership and the resource access that can be controlled through the group. The following table lists the different security group scopes and their membership and use.

Group Membership Resource Access

scope

Global

Global groups can contain members within the same domain. These include:

Global groups in the same domain (in native mode only).

Users and computers within the same domain.

Use global groups to group users and computers within the domain who have similar access needs.

Global groups can be assigned permissions to resources anywhere in the forest.

Create global groups to organize users (e.g., Sales or Development).

Domain Local

Domain local groups can contain members from any domain in the forest. These include:

Domain local groups in the same domain (in native mode only).

Global groups within the forest.

Universal groups within the forest (in native mode only).

Users and computers within the forest.

Domain local groups can be assigned permissions within a domain.

Create domain local groups representative of the domain controller resources to which you want to control access, and then assign permissions on the resource to the group.

Universal

Universal groups can contain members from any domain in the forest. These include:

Universal groups within the forest.

Global groups within the forest.

Users and computers within the forest.

Universal groups can be assigned permissions to resources anywhere in the forest.

Universal group membership should be relatively stable. For this reason, you should only add global or universal groups to universal groups. Avoid adding user accounts directly to universal groups.

In addition to the group scope, there are two types of groups:

Group Type

Description

Security

A security group is one that can be used to manage rights and permissions.

Group members get the permissions that are granted to the group.

A security group represents an object with a security identifier (SID), which through the member attribute, collects other objects, such as users, computers, contacts, and other groups.

Distribution A distribution group is used to maintain a list of users and is typically used for sending e-mails to all group members. Distribution groups cannot be used for assigning permissions.

Be aware of the following when managing groups:

The basic best practices for user and group security are: o Create groups based on user access needs. o Assign user accounts to the appropriate groups. o Assign permissions to each group based on the resource needs of the users in the group

and the security needs of your network.

After creating a group, you may need to convert the group's scope and/or type. o Converting a security group to a distribution group removes permissions assigned to the

group. This could prevent or allow unwanted access. o You cannot directly convert a group from global to domain local or domain local to global.

Instead, convert the group to a universal group and apply the changes, then convert the group to the desired scope.

o If a global group is nested in another global group, the nested global group cannot be converted to a universal group because a universal group cannot be a member of a global group.

To add or remove members of a group, use one of the following methods: o On the group object, edit the Members tab and add the group members. Use this method

to efficiently add multiple members to the same group. o On the user account, edit the Members Of tab and select the group to which you want to

add the user. The Member Of tab displays all of groups to which the object is a member. Use this method to efficiently add a single user to multiple groups.

Because a group can be a member of another group, a group object also has a Member Of tab. Adding objects to the Member Of tab for a group makes the group a member of another group (it does not add members to the group).

When you delete a group, all information about the group (including any permissions assigned to the group) is deleted. User accounts, however, are not deleted. They are simply no longer associated with the group. If you delete the group, use one of the following strategies to recover it:

o Re-create the group, add all the original group members, and reassign any permissions granted to the group.

o Restore the group from a recent backup.

Default Local Groups

A local group is created and available only on a local, single computer. Windows creates default local groups automatically during installation. These groups have default rights, permissions, and group memberships. You can rename these groups, but cannot delete them. Some default groups are listed in the following table:

Group Description

Administrators

Members of the Administrators group have complete and unrestricted access to the computer, including every system right. The group contains the Administrator user account (by default) and any account designated as a computer administrator.

Backup Operators Members of the Backup Operators group can back up and restore files (regardless of permissions), log on locally, and shut down the system. However,

members cannot change security settings.

Users

Members of the Users group:

Can use the computer but cannot perform system administration tasks and might not be able to run legacy applications.

Cannot share directories or install printers if the driver is not yet installed.

Cannot view or modify system files.

You should know the following about the Users group:

Any user created with Local Users and Groups is automatically a member of this group.

User accounts designated as limited use accounts are members of this group.

Power Users

Members of the Power Users group have no more user rights or permissions than a standard user account, by default. For legacy applications requiring the same Power User rights and permissions that were present in previous versions of Windows, administrators can apply a security template that enables the Power Users group to assume the same rights and permissions present in previous versions of Windows.

Guests

Members of the Guests group have limited rights (similar to members of the Users group), such as shutting down the system. Members of the Guests group have a temporary profile created at log on, that is then deleted when the member logs off.

Note: Additional groups, such as Network Configuration Operators and Replicator, also exist. Additionally, many features or applications may create default groups. In most cases, you should not modify the membership or privileges of these groups without understanding how they are used.

Default Domain Groups

A domain group is a resource group to which permissions to access resources can be assigned on a domain-wide scale. Active Directory includes several default groups that are created automatically. These groups have default members, rights, and permissions. The following table lists some of the default groups that are created in the Builtin folder:

Builtin Group Description

Administrators

Full control over the computer, including every available right in the system (the only

built-in account that automatically has all rights), including the Take ownership of

files or other objects right.

Server Operators

Log on locally, back up and restore files and directories, change the system time,

and force a local or remote shutdown. Can also create and delete shared resources,

format the hard disk, and start and stop some services. Abilities extend to domain

controllers.

Backup Operators Back up, copy, and restore files on the computer (regardless of permissions). Log on

to and shut down the computer. Cannot change security settings.

Account Operators Create, delete, and modify domain user accounts and groups. Cannot modify the

Administrators group or any Operators groups.

Guests The domain Guest account is a member of this group. The group does not have any

default rights.

Network

Configuration

Operators

Change TCP/IP settings including changes on domain controllers.

Print Operators

Create, share, manage, and delete printers on domain controllers. Manage Active

Directory printer objects. Log on locally, add or remove device drivers, and shut

down domain controllers.

Users

Perform common tasks such as running applications, using local and remote

printers, and locking workstations. By default, all domain members are members of

this group.

Additional domain groups are also created in the Users folder in Active Directory. The following table describes some of these groups:

User Group Description

Domain Admins

Full control over the domain. This group is a member of the Administrators group on

all computers when they are joined to the domain. This means that members of the

Domain Admins group can perform all tasks on any computer in the domain (including

domain controllers).

Domain

Computers

Contains all computers that are a member of the domain. When you join a computer

to the domain, it becomes a member of this group.

Domain

Controllers

Contains all domain controllers. When a computer is made a domain controller, it is

added to this group.

Domain Guests Contains all domain guests. It does not have any default rights.

Domain Users Contains all domain users. This group can be used to give access to all users in a

domain.

Enterprise Admins

Full control over all domains in the forest. This group is a member of the

Administrators group on all computers in the forest, allowing them to perform any task

on any computer in the forest.

Schema Admins Full control over the Active Directory schema. By default, the Administrator account is

a member of this group.

Read-only Domain

Controllers

Contains all members who have administrative access to the Read-Only Domain

Controllers in the domain.

DHCP

Administrators Contains all members who have administrative access to the DHCP service.

Cert Publishers Contains all members which are permitted to publish certificates to the directory.

When working with domain networking resources, use domain groups for controlling access. However, to enable users to manage local systems, make domain user or group accounts members of the local groups.

Group Strategy Facts

To make permission assignments easier, assign permissions to a group, then add the accounts that need to use the group's resources. You can add user accounts, computers, and other groups to groups. Remember the following when assigning members to groups:

Adding a user account to a group gives that account all the permissions and rights granted to the group (the user must log off and log back on before the change takes effect).

The same user account can be included in multiple groups. (This multiple inclusion may lead to permissions conflicts, so be aware of the permissions assigned to each group.)

Nesting is the technique of making a group a member of another group. Using hierarchies of nested groups may make administration simpler--as long as you remember what permissions you have assigned at each level.

The following table shows the three basic recommended approaches to managing users, groups, and permissions.

Strategy Use Description Application

AGDLP Used in mixed mode domains and in native mode domains (does not use universal groups, which are also not available in mixed mode).

A: Place user Accounts G: Into Global groups DL: Into Domain Local groups P: Assign Permissions to domain local groups

1. Identify the users in the domain who use the same resources and perform the same tasks. Group these accounts together in global groups.

2. Create new domain local groups if necessary, or use the built-in groups to control access to resources.

3. Combine all global groups that need access to the same resources into the domain local group that controls those resources.

4. Assign permissions to the resources to the domain local group.

AGUDLP Used in native mode domains, when there is more

A: Place user Accounts

Universal groups should be used when you need to grant access to similar groups defined

than one domain, and you need to grant access to similar groups defined in multiple domains.

G: Into Global groups U: Into Universal groups DL: Into Domain Local groups P: Assign Permissions to domain local groups

in multiple domains. It is best to add global groups to universal groups, instead of placing user accounts directly in universal groups.

ALP Used on workstations and member servers.

A: Place user Accounts L: Into Local groups P: Assign Permissions to the local groups

ALP is best used in a workgroup environment, not in a domain.

To keep the number of groups to a minimum, you should not automatically use universal groups, even though they might be supported.

Use universal groups only if both the users and the resources are located in multiple domains.

You would not need universal groups in a single-domain design.

You would not need universal groups if the resources you were controlling access to were located in a single domain.

Object Management Tool Facts

Use the following tools to manage Active Directory objects:

Tool Description

Active Directory Users and Computers

Use the Active Directory Users and Computers MMC snap-in to create, organize, and delete objects in Active Directory. Active Directory Users and Computers can be started from:

Server Manager

Administrative Tools (from the Control Panel or Start menu)

Running dsa.msc

ADSI Edit

Active Directory Service Interfaces Editor (ADSI Edit) acts as a low-level GUI editor for common administrative tasks such as adding, deleting, and moving objects. It runs within the Microsoft Management Console (MMC). You can use ADSI Edit to query, view, and edit attributes that are not exposed through other MMC snap-ins (such as Active Directory Users and Computers).

Command Prompt

Use the following command prompt tools to manage Active Directory objects, either from a command prompt or within a script.

Dsadd creates a new object in Active Directory.

Dsquery finds objects that match the search criteria (allows a search through the whole forest). The command returns a list of objects that match the search criteria. Use Dsquery * to search all object types.

Dsget retrieves property information about an object. Use the -expand switch to show nested group membership for users.

Dsmod modifies or changes the properties of an object.

Dsmove moves objects from one location to another and renames an object.

Dsrm removes (deletes) objects. Use the -subtree option to delete a container object and all objects below that object.

Movetree moves an OU and its objects (it does not move computer objects).

Netdom adds computer objects, joins a computer to a domain, and moves computer objects.

Be aware of the following facts about using the Ds commands to work with Active Directory objects:

When using the command, follow the command with the type of object you want to edit (e.g. user, computer, or group). For example, to create a new user account, use the Dsadd user command, followed by the various parameters required to configure the object.

For all commands except for Dsquery, you must identify the object or objects you want to modify. For example, Dsget returns properties of a specific object, while Dsquery returns a list of objects that match the query parameters.

When moving objects, you should typically use Active Directory Users and Computers instead of Dsmove. Active Directory Users and Computers performs additional actions that Dsmove does not.

Csvde

The Csvde command imports and exports Active Directory objects using a comma-separated list file.

Csvde can read existing information from Active Directory (export) or create new objects in Active Directory (import).

You cannot use Csvde to modify existing objects in Active Directory.

Common uses for Csvde include: o Using Csvde to export objects from one Active Directory system (or

an Exchange 5.5 database) and import them into a different Active Directory database.

o Using a database program to create a CSV file, modifying the file, and importing the objects into Active Directory.

Csvde switches include: o -i to import objects o -e to export objects o -f to identify the filename

Note: When you export user accounts with Csvde, passwords are not exported. You cannot import passwords for user accounts using Csvde.

Ldifde

The Ldifde command imports, exports, modifies, and deletes objects in Active Directory using LDAP Data Interchange Format (LDIF) files.

Ldifde files include a changeType parameter that identifies the action to take using the data in the file:

o Add o Modify o Delete

Common uses for Ldifde include:

o Using Ldifde to export a set of Active Directory objects, modifying various attributes, and then re-importing the file to change the attributes.

o Exporting or importing data that exists on non-Active Directory LDAP directories.

Ldifde switches include: o -i to import objects o -e to export objects o -f to identify the filename

Note: When you export user accounts with Ldifde, passwords are not exported. You can change passwords for existing user accounts using a .ldif file, but you cannot create new user accounts with a password. To export user accounts and import them with a password, use the following process:

1. Export the user accounts. The unicodePwd field will be blank. 2. Import the user accounts to create the accounts. The user accounts will be

disabled, and the user will be forced to change the password at next logon. 3. Modify the .ldif file to change the operation to modify existing objects. Add a

password for each user account and add entries to enable the account. 4. Run Ldifde using the file with the passwords to modify the existing user

accounts.

PowerShell

Windows PowerShell is a command line environment designed for automating administration and maintenance for Windows Server 2008 and Windows Server 2008 R2. Be aware of the following:

PowerShell uses specialized commands, known as cmdlets, to create and manage Active Directory objects.

The Active Directory module for Windows PowerShell (limited to Windows Server 2008 R2) consolidates a group of common cmdlets needed to manage Active Directory user and computer accounts, groups, organizational units (OUs), domains and forests, domain controllers, and password policies.

Stringing together the actions of two or more cmdlets is known as pipelining (also called piping). Output from the first cmdlet is fed into the second cmdlet (and so on).

Using cmdlets scripts to create and manage accounts in Active Directory requires a thorough knowledge of programming.

Be aware of the following basic object management PowerShell cmdlets:

New-ADObject creates a new Active Directory object, such as a new organizational unit or new user account.

Set-ADObject modifies the properties of an Active Directory object.

Remove-ADObject removes any type of Active Directory object.

Rename-ADObject renames an Active Directory object.

Get-ADObject gets one or more Active Directory objects.

Restore-ADObject restores a deleted Active Directory object.

Move-ADObject moves an Active Directory object or a container of objects to a different container or domain.

Visual Basic Visual Basic scripts (VBscripts) can also be used to create and manage objects within

scripts (VBscripts)

the Active Directory database. Using VBscripts to create and manage accounts in Active Directory requires a thorough knowledge of programming.

Ldp

The Ldp utility allows you to search for and view the properties of multiple Active Directory objects. It is a GUI-based, Windows Explorer-like utility with a scope pane on the left that is used for navigating through the Active Directory namespace, and a details pane on the right that is used for displaying results.

Active Directory Migration Tool (ADMT)

The Active Directory Migration Tool (ADMT) is a GUI-based utility that helps you restructure your Active Directory organization or migrate objects from one domain to another.

You can move objects to different domains within the same forest (intraforest), or to domains in other forests (interforest).

Use the SID history feature to enable migrated accounts to be able to continue to access resources in the original domain. For intraforest moves, SID history is enabled automatically.

Use a SID mapping file to map security objects in one domain with security objects in another domain. For example, you can translate group membership in one domain and have users added to similar groups in the target domain.

Use the password migration DLL to migrate passwords between forests. Passwords remain protected throughout the migration process. Passwords are automatically migrated for intraforest move operations.

For interforest migration, the target forest must trust the source forest. Trusts already exist within a forest.

Active Directory Administrative Center

Active Directory Administrative Center is an Active Directory management GUI tool built on Windows PowerShell. Use Active Directory Administrative Center to perform the following Active Directory administrative tasks:

Create or manage new or existing user accounts, groups, computer accounts, organizational units (OUs) and containers

Connect to one or several domains or domain controllers in the same instance of Active Directory Administrative Center, and view or manage the directory information for those domains or domain controller

Change domain and forest functional levels

Filter Active Directory data by using queries

The Active Directory Administrative Center:

Can be installed only on computers running the Windows Server 2008 R2 operating system.

Is installed in any of the following circumstances: o When the AD DS server role is installed on a Windows Server 2008

R2 server. o When a Windows Server 2008 R2 server is made a domain controller

by running Dcpromo.exe. o When the Remote Server Administration Tools (RSAT) feature is

installed on a Windows Server 2008 R2 server.

Relies on the Active Directory Web Service (ADWS) service.

Active Directory Web Services (ADWS)

Active Directory Web Service (ADWS) is a web-based communication infrastructure that is used by the Active Directory Administrative Center or Windows PowerShell cmdlets. ADWS:

Is based on the .NET framework version 3.5.1 or higher.

Can only be used to manage a Windows Server 2008 R2 domain.

Uses TCP port 9389 on the domain controller where the ADWS service is running.

Supports Windows Integrated authentication using Kerberos or simple (i.e., plaintext user name and password) authentication.

Be aware of the following configuration parameters to determine how ADWS handles traffic:

MaxConcurrentCalls specifies the maximum number of simultaneous service requests that the ADWS service is configured to process at a given time. The default is 32.

MaxConcurrentSessions specifies the maximum number of client sessions that the ADWS service can accept at any given time. Set this parameter to a higher value if the ADWS service on your Windows Server 2008 R2 server must be able to accept more than 500 concurrent client sessions at any given time. The default is 500.

MaxReceivedMessageSize specifies the maximum message request size, in megabytes (MB), that a client computer can send to the directory service instances that the ADWS service supports. The default is 1 MB.

MaxStringContentLength specifies the maximum string size, in kilobytes (KB), of a Lightweight Directory Access Protocol (LDAP) attribute that the ADWS service is configured to process in a message request. The default is 32 KB.

Active Directory Management Gateway

The Active Directory Management Gateway Service provides the same functionality as ADWS to Windows Server 2008 or Windows Server 2003 domain controllers. Active Directory Management Gateway can only be installed on the following:

Windows Server 2003 with SP2

Windows Server 2003 R2 with SP2

Windows Server 2008 with or without SP2

Note: If the Active Directory Management Gateway Service is stopped or disabled, client applications, such as the Active Directory module for Windows PowerShell or the Active Directory Administrative Center will not be able to access or manage any directory service instances that are running on the server.

DNS Facts

The Domain Name System (DNS) is a hierarchical, distributed database that maps logical host names to IP addresses. With DNS, users reference computers using logical hostnames, and those hostnames are translated to IP addresses using DNS. A DNS server is responsible for performing this service on a TCP/IP network. You should know the following facts about DNS:

A DNS server holds a database of hostnames and their corresponding IP addresses. Clients query the DNS server to get the IP address of a given host.

Prior to using DNS servers, name resolution used a static file, called the HOSTS file, saved on each host computer. The HOSTS file is still used, but is typically only used in the absence of a DNS server.

The DNS hierarchy is made up of the following components: o . (dot) domain (also called the root domain) o Top Level Domains (TLDs) (.com, .edu, .gov) o Second-level and additional domains o Hosts

A fully qualified domain name (FQDN) includes the host name and the name of all domains back to root.

DNS is a distributed database because no one server holds all of the DNS information. Instead, multiple servers hold portions of the data.

o Each division of the database is held in a zone database file. o Zones typically contain one or more domains, although additional servers might hold

information for child domains. o DNS servers hold zone files and process name resolution requests from client systems.

A forward lookup uses the host name (or the FQDN) to find the IP address. A reverse lookup uses the IP address to find the host name (or FQDN).

Entries for hostnames, IP addresses, and other information in the zone database are stored in records.

o The A record maps a host name to an IP address and is used for forward lookups. o The PTR record maps an IP address to a host name and is used for reverse lookups. o The CNAME record provides an alternate name (an alias) for a host. o The SRV record identifies a service, such as an Active Directory domain controller.

Records in the DNS database are created manually, or dynamically using Dynamic DNS (DDNS). With DDNS, hosts automatically register and update their corresponding records with the DNS server.

When a client computer needs to find the IP address for a host name, the following process is used:

1. The client examines its HOSTS file for the IP address. 2. If the IP address is not in the HOSTS file, it examines its local DNS cache for the IP

address. 3. If the IP address is not in the cache, the client sends the request to a DNS server.

When a DNS server receives a name resolution request from a client, the following process is used:

0. The DNS server examines its local DNS cache for the IP address. Note: The DNS server cache is not the same as the client cache. A Windows 2008 server has a DNS client cache, but this cache is not used to respond to client requests.

1. If the IP address is not in the server cache, it checks its HOSTS file. 2. If the information is not in the HOSTS file, the server checks any zones for which it is

authoritative. An authoritative server is a DNS server that has a full, complete copy of all the records for a particular zone.

3. If the server does not host the zones for the requested information, it uses one of the following processes:

If configured for forwarding, the DNS server forwards the name resolution request to another DNS server. The DNS server waits for a response from the other DNS server.

If configured for recursion (also called referral), the DNS server queries root domain servers, top-level domain servers, and other DNS servers in an iterative manner until it finds the DNS server that hosts the target domain. For example, to resolve the host name www.microsoft.com:

1. The server queries a root server for the .com server. 2. It then queries the .com server for the microsoft.com server. 3. It then queries the microsoft.com DNS server for the www host

information. 4. After the information is found or received from another server, the DNS server returns the

result to the client, and places the information in its server cache.

A caching-only DNS server has no zone information; it is not authoritative for any domains. It uses information in its server cache, or forwarding or recursion, to respond to client queries.

DNS Installation Facts

You should know the following facts about DNS installation in Windows Server 2008:

To install DNS in Windows Server 2008, you must be a member of the Domain Admins group.

You can install DNS on any version of Windows Server 2008 except for the Windows Server 2008 Web Server edition.

You must assign the DNS server a static (or fixed) IP address.

To install DNS on a server, use Server Manager and add the DNS role. To add the DNS role from a command prompt (or on Server Core), run: start /w ocsetup DNS-Server-Core-Role

Run the oclist command to get a list of services (including DNS) installed on a server.

Windows secondary servers can transfer data from non-Windows master servers, and vice versa, as long as the BIND versions are compatible. In some cases, Windows adds non-standard records or information to zone databases that make them incompatible with non-Windows DNS servers, especially servers running older versions of DNS.

Use the DNS snap-in or the dnscmd command to manage DNS.

Zone Facts

The table below lists the types of DNS zones:

Zone Type Description

Primary

The primary zone is the master copy of a zone database.

The primary zone is the only writeable copy of the zone database.

Changes to the zone can only be made to the primary zone.

The server that holds the primary zone is called a primary server.

Each zone can have only a single primary zone server.

Zone data is stored in a text file.

Secondary

A secondary zone is a read-only copy of the zone database.

Changes cannot be made to the records in a secondary zone.

A server that holds a secondary zone is called a secondary server.

Secondary servers copy zone data from other servers through a process called zone transfer.

Secondary servers can copy zone data from the primary server or other secondary servers.

Zone data is stored in a text file.

Active Directory-integrated

An Active Directory-integrated zone holds zone data in Active Directory instead of a text file.

Active Directory-integrated zones are multi-master zones, meaning that

changes to the zone information can be made by multiple servers. Multiple servers hold read-write copies of the zone data.

Only DNS servers that are domain controllers can host Active Directory-integrated zones.

Storing zone data in Active Directory provides automatic replication, fault tolerance, and distributed administration of DNS data.

Replication of zone data occurs during Active Directory replication and is secured by Kerberos.

Stub

A stub zone is a zone with only a partial copy of the zone database.

The stub zone only contains information about the name servers that are authoritative for the zone; it does not contain information for other hosts.

A stub zone is not authoritative for the zone; its purpose is to identify the name servers that can be contacted for full zone information.

The stub zone is dynamic, meaning that it will keep the list of name servers for the zone updated automatically.

Use a stub zone to forward name requests based on zones while keeping name server lists updated automatically.

GlobalNames

The GlobalNames zone is a special zone in the DNS database that is used for single-label name resolution. Use the GlobalNames zone to:

Allow clients to use simple host names without domain information for name resolution. For example, to contact a server named web1.corp.us.westsim.private, users could simply enter the single-label name web1.

Allow DNS clients to contact NetBIOS-only hosts without the need for a WINS server.

Allow IPv6-only hosts to contact NetBIOS hosts (IPv6 does not support the use of WINS).

Be aware of the following when using the GlobalNames zone:

When users enter a single-label name, the client computer first tries to resolve the name using DNS and the search suffix configuration. If that process fails, the GlobalNames zone is checked (if it exists).

Using the GlobalNames zone does not require any changes to client machines.

Dynamic updates are not supported on the GlobalNames zone. You must manually create each record in the GlobalNames zone.

Use the GlobalNames zone to replace WINS servers on your network only when you have a small number of hosts that do not support DNS. For a large number of NetBIOS-only hosts, or to support dynamic registration of single-label names, continue to use a WINS server.

The zone types above describe the read-write capabilities and the storage location of zone data. In addition, zones are classified as one of two types:

A forward lookup zone provides hostname-to-IP address resolution. Clients query the DNS server with the hostname, and receive the IP address in return.

A reverse lookup zone provides IP address-to-hostname resolution. Clients query the DNS server with the IP address, and receive the hostname in return.

Zone Configuration Facts

Be aware of the following when using Active Directory-integrated zones:

Only one server can hold the primary zone file. To place zone data on multiple servers, configure secondary servers.

Windows stores standard zone data in the %windir%\System32\Dns directory. The file is a text file with .dns added to the zone name.

Use the DNS snap-in or the dnscmd command to manage zones and records. o You can also edit the zone database file directly with a text editor. However, after making

changes, you must reload the zone data. Using the snap-in or dnscmd prevents errors in the file and automatically reloads the database after each change.

o You can only manage Active Directory-integrated zones with the DNS console or dnscmd. There is no text file that you can manually edit.

Primary and Active Directory-integrated zones support dynamic updates. Use an Active Directory-integrated zone to use secure dynamic updates.

Zone information is replicated automatically with Active Directory replication. Zone data is replicated based on the replication scope:

Replication Scope

Description

All domain controllers in this domain

DNS zone data in Active Directory is replicated to all domain controllers, even those not running DNS. Use this option if you need to support Active Directory-integrated zones running on Windows 2000 domain controllers.

All DNS servers in this domain

DNS zone data in Active Directory is replicated to all DNS servers that are also domain controllers within the current domain. This is the default DNS zone replication setting for Server 2003 and 2008. It replicates zone data to the DomainDNSZones partition.

All DNS servers in this forest

DNS zone data in Active Directory is replicated to all DNS servers that are also domain controllers within the forest. This provides the broadest replication scope because it replicates zone data to the ForestDNSZones partition. Use this option when you have very important records that need to be available throughout the forest.

Application partition

Using an application partition, you select the specific domain controllers to which Active Directory-integrated zone data is replicated. To use an application partition:

1. Create the application partition using ntdsutil or dnscmd. 2. Add domain controllers to the application partition scope. 3. Configure the zone to use the configured application partition.

Use an application partition to customize which domain controllers receive the DNS data. For example, you can use this option to prevent DNS zone data from being replicated to a branch office domain controller that uses a slow WAN-link connection to the main office.

To change the replication scope for a zone using an application partition, use the dnscmd /zonechangedirectorypartition command with the following

switches:

o /forest sets the replication scope to all of the DNS servers in the forest. o /domain switch would change the replication scope to all of the DSN

servers in the domain which is already the default setting.

Note: The broader the replication scope, the greater the network traffic created by replication.

You can configure a secondary server to replicate from an Active Directory-integrated zone. You cannot use a primary zone and an Active Directory-integrated zone together.

Reverse lookup zones hold PTR (pointer) records. The PTR record maps the IP address to an A record.

A reverse lookup zone can be a primary zone, a secondary zone, or an Active Directory integrated zone.

When you create the reverse lookup zone, you specify whether the zone is an IPv4 or IPv6 zone. The zone name uses the network portion of the IP address as follows:

IP version

Reverse Zone Name Format

IPv4

For an IPv4 zone:

o Reverse the order of the decimal octets in the network ID. o Append in-addr.arpa to the zone name.

For example, the reverse lookup zone for network 216.222.14.0/24 would be: 14.222.216.in-addr.arpa

IPv6

For an IPv6 zone:

o Reverse each hexadecimal number in the prefix, separating each digit with a period.

o Append ip6.arpa to the zone name.

For example, the reverse lookup zone for network 1234:5678:ABCD:FF21::/64 becomes: 1.2.f.f.d.c.b.a.8.7.6.5.4.3.2.1.ip6.arpa

Common Resource Records

Entries for hostnames, IP addresses, and other information in the zone database are stored in records. Each host has at least one record in the DNS database that maps the hostname to the IP address. The following table lists common resource records.

Record Type Use

SOA (Start of Authority)

The first record in any DNS database file is the SOA. It defines the general parameters for the DNS zone, and it is assigned to the DNS server hosting the primary copy of a zone. There is only one SOA record, and it is the first record in the zone database file. The SOA record includes parameters such as the authoritative server and the zone file serial number.

NS (name The NS resource record identifies all name servers that can perform name resolution for

server) the zone. Typically, there is an entry for the primary server and all secondary servers for the zone (all authoritative DNS servers).

A (host address)

The A record maps an IPv4 (32-bit) DNS host name to an IP address. This is the most common resource record type.

AAAA (quad-A) The AAAA record maps an IPv6 (128-bit) DNS host name to an IP address.

MX (Mail Exchanger)

The MX record identifies servers that can be used to deliver e-mail.

CNAME (canonical name)

The CNAME record provides alternate names (or aliases) to hosts that already have a host record. Using a single A record with multiple CNAME records means that when the IP address changes, only the one A record needs to be modified.

Common uses of a CNAME record include:

Adding the alias of www for Web servers. Users typically contact the Web server using a name like www.westsim.com instead of using the actual server name.

Associating a server with the domain name itself. For example, create a CNAME record with a blank name to allow a specific host to be identified with the domain name (such as westsim.com).

DNAME (Domain Alias)

The DNAME record provides alternate names (or aliases) to domains that already have a host record.

SRV (service locator)

The SRV record is used by Windows Server 2008 to register network services. This allows clients to find services (such as domain controllers) through DNS. Windows 2008 automatically creates these records as needed and during domain controller installation.

PTR (pointer)

In a reverse lookup zone, the PTR record maps an IP address to a host name (i.e. "points" to an A record). Where IPv4 PTR records are created in the in-addr.arpa namespace, reverse lookup zones for IPv6 addresses should be created in the ip6.arpa namespace.

(Note: When you manually create an A record, you can choose to create the corresponding PTR record at the same time. Creating the PTR record will fail if the reverse lookup zone does not exist.)

WINS and WINS-R resource records

Add these records to a zone when you want to allow DNS to use WINS resolution. The WINS resource record allows DNS queries that fail to resolve to be forwarded to the WINS servers in the WINS resource record. The WINS-R resource record allows the resolution of a reverse query that is not resolvable through DNS.

Dynamic DNS Facts

With Dynamic DNS (DDNS), resource records can be created automatically on a DNS server. Without dynamic updates, all A (host) and PTR (pointer) records must be configured manually. With dynamic updates, records are created and deleted automatically. Dynamic DNS is required to support Active Directory.

A dynamic update occurs when a client modifies its corresponding resource record on the DNS server. Dynamic updates occur when:

A network connection's IP address is added, deleted, or changed.

The DHCP server changes or renews an IP address lease.

The client's DNS information is manually changed using ipconfig /registerdns.

The client boots.

A server is promoted to a domain controller.

The default configuration for dynamic DNS is as follows:

Windows clients (2000 and above) create their A records with the DNS server. Windows 9x/Me/NT clients do not support dynamic DNS.

The DHCP server registers the PTR record with the DNS server for clients capable of dynamic updates. The DHCP server updates both the A and PTR records for clients that do not support dynamic updates.

Dynamic updates must be enabled on the zone. By default: o Dynamic updates are not enabled on primary zones. You can enable dynamic updates

when you create the zone or modify the zone properties later to enable this feature. o Dynamic updates are enabled on Active Directory-integrated zones. Note: When you

convert a primary zone to an Active Directory-integrated zone, the current dynamic update setting is retained.

For Active Directory-integrated zones, you can choose to use secure dynamic updates. With secure dynamic updates, only domain members can create records, and only the original client can modify or remove records.

Zone Transfer Facts

Replication of zone data between primary and secondary zones takes place through zone transfers. You should know the following facts about zone transfers:

Each secondary server is pointed to one or more master servers. A master server is the server from which the secondary copies the zone data. The master server can be the primary server or another secondary server.

The zone serial number keeps track of changes to the zone. When you make changes to the zone, the serial number is incremented.

Zone transfers can copy all records or only changed records: o A full zone transfer (AXFR) copies all of the zone data with each zone transfer. o A partial (or incremental) zone transfer (IXFR) copies only the changed records. This is

the default method on Windows Server 2008.

By default, zone transfer in Windows Server 2008 is disabled for security reasons. To use zone transfers, manually enable the feature in the DNS settings in Server Manager.

You can restrict the servers to which zone transfers are allowed. There are two ways of doing this:

o Allow zone transfers only to servers that are listed as name servers. o Allow zone transfers only to servers you specifically identify.

Zone transfer is always initiated by a secondary server. o The secondary server contacts the master server and compares the serial number on the

master with the serial number in its copy. o If the serial number on the master is greater, the secondary initiates zone transfer. o If the serial number is the same (or lower) on the master, no zone transfer takes place.

Windows DNS servers support the use of DNS Notify. With DNS Notify, master servers are configured with a list of slave DNS servers.

o When a change takes place, the master notifies the slave servers that the zone has changed.

o The secondary server then initiates zone transfer, first checking the serial number, then requesting changes.

You can allow notification for all name servers, or only for listed servers.

You can improve DNS performance by placing multiple DNS servers on your network. For example, you can place a secondary server on the other side of a WAN link to reduce WAN traffic caused by name resolution. However, zone replication traffic must still cross the WAN link.

A caching only server runs DNS but has no zones configured. Use a caching only server to improve performance while eliminating zone transfers.

An Active Directory-integrated zone stores DNS information in Active Directory rather than in a zone file. Zone information is copied automatically when Active Directory replicates.

If a zone is Active Directory-integrated and has no secondary servers, you can disable zone transfers. Zone data will continue to be replicated through Active Directory.

Active Directory replication traffic is automatically secured. To secure zone transfers to secondary servers, use IPsec between servers.

Normally, zone transfers happen automatically at periodic intervals. You can force an update of zone data through the DNS console or by using the Dnscmd command. The following table lists some actions you can take to refresh zone data manually.

DNS Console Action

Dnscmd Option Result

Reload Dnscmd /ReloadZone

The server reloads zone data from its local copy (it reads the data back in from the zone file on the hard disk).

Transfer from Master

Dnscmd /Refresh

Initiates a normal zone transfer. The DNS server compares its version number with the version of the zone master. If the version numbers are the same, no zone transfer takes place.

Reload from Master

N/A The DNS server dumps its copy of the data and reloads the entire data from the master server.

Forwarding Facts

A forwarder is a DNS server that can be used by another DNS server to resolve queries for records that cannot be resolved through the cache, Hosts file, or from zones hosted on the DNS server. For example, if a DNS server hosts the westsim.com and eastsim.com domains, but receives a query for a host in the northsim.com domain, the DNS server can forward that request to one of the servers configured on its Forwarders list.

When using forwarders, the server sends requests for all non-authoritative zones to the listed server(s). In some cases, forwarding all queries to the same server is inefficient. You can use the following methods to control the server's use of forwarders:

Method Description

Secondary zone

Because a DNS server uses authoritative zones to respond to queries before it uses forwarders, you can eliminate the need for a forwarder for a specific zone by adding a secondary zone to the server. However, using a secondary zone means that the server must perform zone transfers of all records in the zone. In some cases, you might not want to add more zones to the server, or do not want the extra traffic caused by zone transfers.

Stub zone A stub zone is a zone with only a partial copy of the zone database. The stub zone holds only the following records:

The SOA record for the zone.

NS records for all authoritative DNS servers for the zone (primary and secondary).

A records (also called glue records) for authoritative name servers identified in the NS records.

Keep in mind the following when using stub zones:

A stub zone is not authoritative for the zone; its purpose is to identify the name servers that can be contacted for full zone information.

The stub zone is dynamic, meaning that it will keep its records synchronized with the master zone database.

Zone transfer traffic is limited in that only the SOA, NS, and glue A records must be kept up-to-date.

Use a stub zone to forward name requests based on zones while keeping name server lists updated automatically.

Conditional forwarder

A conditional forwarder is a forwarder that is used for a specific domain. While forwarders are used for all unresolvable queries, a conditional forwarder is used only for unknown hosts within a specified domain.

A conditional forwarder is used before a regular forwarder. In other words, if a query matches the domain identified by a conditional forwarder, the query is sent to the conditional forwarder DNS server. If the query does not match any conditional forwarder, the regular Forwarders list is used instead.

Conditional forwarder configuration is static. You manually identify the DNS server to which queries for that domain are forwarded. If the DNS server changes, you must manually update the conditional forwarder list.

For non-domain controllers, conditional forwarders must be configured on each DNS server. For domain controllers that are DNS servers, you can store the list of domains and forwarders in Active Directory. Configure the replication scope to identify to which domain controllers the list is replicated.

Use a conditional forwarder to eliminate all zone transfer traffic, or in conditions where you are not allowed to transfer data from a zone (for example when zone transfers are disabled on the master zone, or when the zone is outside of your administrative control).

Disable recursion

Recursion is the process by which a DNS server or host uses root name servers and subsequent servers to perform name resolution. Many DNS servers perform recursion. Most client computers do not perform recursion, rather they submit a DNS request to the DNS server and wait for a complete response.

You can disable recursion in the DNS Manager by editing the server properties. On the Advanced tab, select the Disable recursion (also disables forwarders) check box. As the setting indicates, with recursion disabled the server will not use forwarders.

Zone Delegation Facts

Zone delegation allows you to divide your DNS namespace into separate zones. You may decide to do this for the following reasons:

Ease the administrative burden by giving management responsibilities to another location or department.

Distribute DNS traffic over various servers, improving name resolution and fault tolerance at the same time.

Extend the namespace by adding subdomains.

To delegate a zone:

On the DNS server that holds the parent zone, create a new delegation. The delegation identifies the name of the subdomain, and contains the NS and A records for the DNS server that is authoritative for the zone.

On the DNS server that will hold the child domain, create a new primary or Active Directory-integrated zone. In addition, you would typically configure the DNS server with the delegated zone with a secondary zone, forwarder, or conditional forwarder for the parent zone.

GlobalNames Zone Configuration Facts

The GlobalNames zone is a special zone in the DNS database that is used for single-label name resolution. Use the GlobalNames zone to:

Allow clients to use simple host names without domain information for name resolution. For example, to contact a server named web1.corp.us.westsim.private, users could simply enter the single-label name web1.

Allow DNS clients to contact NetBIOS-only hosts without the need for a WINS server.

Allow IPv6-only hosts to contact NetBIOS hosts (IPv6 does not support the use of WINS).

Replace WINS servers on your network when you have a small number of hosts that do not support DNS. For a large number of NetBIOS-only hosts, or to support dynamic registration of single-label names, continue to use a WINS server.

Be aware of the following when managing the GlobalNames zone:

If you use the GlobalNames zone, all authoritative DNS servers must run Windows Server 2008. Servers that are not authoritative can run any operating system.

To configure the GlobalNames zone: 1. Delete any zones that are currently named GlobalNames. 2. Run the dnscmd <servername> /config /enableglobalnamessupport 1 command to

enable support for GlobalNames zones. You must run this command on every server that hosts a GlobalNames zone.

3. Create a zone on the DNS server named GlobalNames. 4. Create CNAME records in the GlobalNames zone that point to A records in other zones.

Note: Dynamic updates are not supported on the GlobalNames zone. You must manually create each record in the GlobalNames zone.

Microsoft recommends that the GlobalNames zone be an Active Directory-integrated zone.

Within the GlobalNames zone, all names must be globally unique (throughout the entire organization). The GlobalNames zone has a forest-wide replication scope to ensure that single-label names are unique across the forest.

You can extend the GlobalNames zone to multiple forests by using the SRV (service locator) resource record to publish the location of the GlobalNames zone. Active Directory-integration is required when deploying the GlobalNames zone across forests.

Using the GlobalNames zone does not require any changes to client machines.

Root Hint Facts

Root hints are pointers to top level DNS servers on the Internet.

The Cache.dns file holds the 13 root hint addresses for the Internet root servers. The Cache.dns file can be found in two locations:

o %SystemRoot%\system32\dns\Cache.dns (the copy in use) o %SystemRoot%\system32\dns\backup\Cache.dns (the copy reserved in the backup

location)

The Cache.dns file normally lists the NS (name server) and A (host name) records for the Internet root servers. You can change this file to list the records for your own internal root DNS servers if you are using DNS on a private network.

You can configure root hints through the properties of a DNS server or by configuring the DNS server's Cache.dns file. If the server is configured to load data from Active Directory, you must configure root hints using the DNS snap-in because the local Cache.dns is not used (the root hints data is stored in Active Directory).

The root zone is at the top of the DNS hierarchy, and is named . (dot).

If you have a root zone configured on a DNS server, the server will act as a root zone server. A DNS server configured as a root zone server will never use the root hints file (Cache.dns). It considers itself authoritative. Consequently, the server won't access the Internet to forward DNS queries.

If you want the DNS server to access the Internet, delete the root zone in the DNS console.

DNS Round Robin Facts

Round robin is a local balancing mechanism used by DNS servers to share and distribute network resource loads. To configure DNS round robin, do the following:

On the DNS server, edit the server properties and enable the Enable round robin option on the Advanced tab (this setting is enabled by default).

Configure two (or more) servers, each with a different IP address.

On the DNS server, create A records that map the same DNS name to each of the different server IP addresses. This allows the DNS server to respond to clients by sending them to any one of the machines while leaving the appearance that a single machine is responding to all clients.

Note: Round robin is a static method for load balancing. If one of the servers in the round robin configuration fails, DNS still sends requests to that failed server.

Application Directory Partitions Facts

An application directory partition is a portion of the directory namespace that is replicated only to specific domain controllers. You should know the following facts about application directory partitions:

Application directory partitions can be targeted to replicate to specific domain controllers, which limits and controls the scope of replication, allowing you to control domain replication traffic.

Directory partitions can reduce calls to global catalog servers.

Applications that require application directory partitions generally create the appropriate partitions themselves. However, members of the Domain Admins or Enterprise Admins group can manually create and manage application directory partitions.

To use an application directory partition, use the following process: 1. Create the application directory partition. For example, you can use one of the following

tools: dnscmd /CreateDirectoryPartition ntdsutil with the create nc command

2. Enlist domain controllers in the partition. This stores a copy of the partition data on the domain controller. Use dnscmd /EnlistDirectoryPartition to add the server to the directory partition. Note: When you create the partition, the server you use to create the partition automatically hosts the partition. Use this command to add extra domain controllers.

3. Configure the application to use the directory partition. For example, on a DNS server, you can select the replication scope for the zone to replicate only within the specified partition.

New DNS Features Facts

The table below describes new Windows Server 2008 DNS features.

Feature Description

Background zone

loading

A DNS server with large Active Directory-integrated zones can take a long time to

retrieve data from the directory service during startup. While the DNS server is

starting, it is unable to respond to queries until the zones are fully loaded. DNS

servers running Windows Server 2008 mitigate this problem by implementing

background zone loading, in which the DNS server loads zone data from AD DS

(Active Directory Domain Services) in the background while the server restarts.

Background zone loading allows the DNS server to respond to queries while loading zone data. This can occur because zone loading is done by separate threads. If a request comes in for an unloaded node, the DNS server responds by finding and updating that node's data. As the DNS server starts, it does the following:

Enumerates the zones that it needs to load.

Loads root hints (either from files or AD DS storage).

Loads zones stored in files (rather than in AD DS).

Responds to DNS queries and RPCs (Remote Procedure Calls).

Starts threads to load zones from AD DS.

Read-only Domain

Controller (RODC)

A Read-Only Domain Controller (RODC) is an additional domain controller for a

domain that hosts read-only partitions of the Active Directory database. This replica is

optimal for deployment in:

Perimeter networks.

Any location in which a domain controller is deployed primarily to support an application that requires directory access.

Branch locations in organizations that have: o Low-level security facilities for storing data related to the domain

controller. o Few users. o Poor physical security. o Relatively poor network bandwidth to a hubsite. o Little local IT knowledge.

Scenarios where local storage of all domain passwords is considered a primary threat, such as in an application-facing role or in an extranet.

IPv6 DNS Support Windows Server 2008 provides support for IPv6 and the AAAA host resource records.

Domain controller

search (DC

Locator)

Windows Vista and Server 2008 are optimized to search for domain controllers, even

when logged on. This allows them to create a better connection should the

opportunity arise.

Link-Local

Multicast Name

Resolution

(LLMNR)

LLMNR is a name resolution protocol that provides peer-to-peer name resolution

when DNS is unavailable. LLMNR uses multicast messages (also known as multicast

DNS) to create client connections. LLMNR is also supported on Windows Vista and

Server 2008 and is enabled by default. It can be disabled by adding a registry setting

to each client.

You can use LLMNR to create ad hoc networks, or to find hosts on the local subnet without the use of a DNS server. LLMNR replaces the NetBIOS broadcast capabilities, but requires LLMNR-capable hosts.

GlobalNames

Zone

The GlobalNames zone is a special zone in the DNS database that is used for single-

label name resolution. Use the GlobalNames zone to:

Allow clients to use simple host names without domain information for name resolution. For example, to contact a server named web1.corp.us.westsim.private, users could simply enter the single-label name web1.

Allow DNS clients to contact NetBIOS-only hosts without the need for a WINS server.

Allow IPv6-only hosts to contact NetBIOS hosts (IPv6 does not support the use of WINS).

Global Query

Block List

The Global Query Block List allows you to prevent malicious users from using DDNS

to register well-known domain names.

Conditional

Forwarding

Conditional forwarders have their own, separate folder in the DNS console, which

allows you to store conditional forwarder information in Active Directory. Conditional

forwarders are then replicated with Active Directory replication and available on all

DNS servers in the replication scope.

DNSSEC Support

DNSSEC stands for DNS Security Extensions. DNSSEC is designed to prevent

certain types of attacks, such as DNS cache poisoning. Following are the three

resource records used for DNSSEC support:

The SIG record stores the private key's digital signature on a resource record set (RRset). (An RRset is a group of resource records that share an owner, class, and type.)

The KEY record stores a zone's public key.

The NXT record identifies the domain name that comes after a given domain name in a secure zone. For the NXT record to be effective, you must create a canonical order to the domain names in your zone. The last NXT record in a zone points to the first record in the domain.

Aging and Scavenging Facts

Dynamic updating can cause your zones to become overloaded with unnecessary resource records. If a computer disconnects improperly from the network (as is often the case when you allow mobile users and computers on your network), the host (A) resource record it registered may not be removed. It is for reasons such as this that DNS records have a Time to Live (TTL) value. When a record exceeds its TTL, it becomes stale. Large numbers of stale records can cause long zone transfers and name resolution problems. Stale records can also degrade DNS server performance. A stale record may also prevent a computer from using a DNS domain name.

Scavenging is controlled through a combination of DNS server and zone properties.

Setting Description

Zone

properties

On the zone, enable scavenging and configure the following settings:

The no-refresh interval is the time between the record's last refresh and when it can next be refreshed. By default, this setting is 7 days. This means that for seven days, DNS ignores a record's attempt to re-register itself, keeping replication to a minimum. During this period of time, a record is considered valid and cannot be refreshed.

The refresh interval identifies a period of time when a record can be refreshed. The refresh interval begins when the no-refresh interval ends. During the refresh interval, a record can be refreshed and is not considered stale until this interval of time expires. A resource record is not scavenged until the refresh interval expires. The default refresh interval is 7 days.

You can configure zone scavenging settings for all zones by right-clicking the server and

selecting Set Aging/Scavenging for all zones.

DNS server

properties

Scavenging must be initiated to actually remove any records that have not been refreshed

since the refresh interval has expired. To initiate scavenging:

Manually initiate it by right-clicking the server and selecting Scavenge Stale Resource Records.

Enable automatic scavenging by editing the server properties. On the Advanced tab, select Enable automatic scavenging of stale records. The default is for scavenging to run once a day.

Note: Scavenging is only configured on primary zones. After you enable scavenging on a zone, the zone file cannot be used on another DNS server.

Be aware of the following when configuring scavenging:

Each DNS record has a default refresh setting. The record will attempt to refresh itself based on this interval. The default for an A record is 7 days.

The no-refresh interval for the zone should be set with a value that is equal to (or less than) the longest record refresh interval.

The refresh interval for the zone should be set to a value that is longer than the longest record refresh interval. If not, some records might be deleted before the record attempts to refresh itself.

The difference between zone scavenging and server scavenging is that zone scavenging is applied to a single zone where server scavenging is applied to an entire server.

Debug Logging Facts

Debug logging allows you to log the packets sent and received by a DNS server. Debug logging is disabled by default, and because it is resource intensive, you should only activate it temporarily when you need more specific detailed information about server performance.

To configure debug logging, use the Debug Logging tab in the DNS server properties dialog. The table below describes the debug logging options.

Option Description

Packet

direction

This option allows you to log packets that are either sent or received or both using two

options:

Use the Outgoing setting to log packets sent.

Use the Incoming setting to log packets received.

Packet

contents

This option allows you to log packets based on their contents. You have the following

options:

Use the Queries/Transfers setting to log packets that contain standard query or transfer data.

Use the Updates setting to log packets that contain dynamic updates.

Use the Notifications setting to log packets that contain notifications.

Transport

protocol

This option allows you to log packets based on the protocol used to transport the packet.

You can select UDP or TCP or both.

Packet type

This option allows you to log packets that are either Response packets (characterized by a

QR bit set to 0 in the DNS message header) or Request packets (characterized by a QR bit

set to 1 in the DNS message header).

Other

options

This option has the following settings:

Use the Details setting to log the packet contents in addition to the summary information.

Use the Filter packets by IP address to log packets sent from a specific IP address, or packets sent to a specific IP address.

File path

and name

This option allows you to specify the log file name and location. For example:

The file name dns.log saves the log file as systemroot\System32\DNS\dns.log.

The path temp\dns.log saves the log file as systemroot\temp\dns.log.

Maximum This option allows you to specify the maximum size you wish the log file to reach. When the

size (bytes) log file reaches its maximum size, the DNS server overwrites the oldest packet information

with new packet information. If you do not specify a log size, the log file can take up large

amounts of disk space.

Installation Preparation Facts

Before adding the first domain controller running Windows Server 2008 or Windows Server 2008 R2 to an existing Windows 2000 or Windows Server 2003 Active Directory environment, the forest and domain levels must be set appropriately:

The forest functional level must be set to Windows 2000 or higher.

The domain functional level where the 2008 server will be added must be set to Windows 2000 Native or higher.

Note: Because Windows NT 4.0 domain controllers require the Windows 2000 Mixed functional level, you cannot have NT 4.0 and 2008 domain controllers within the same forest or domain.

In addition to ensuring the correct functional level, the Active Directory schema must be updated to support Windows Server 2008 or Windows Server 2008 R2 domain controllers. Use the following tools to prepare forest and domain support for Windows Server 2008.

Tools Description

adprep

/forestprep

Use the adprep /forestprep command to update the Windows Server 2003 or Windows

2000 Server Active Directory schema for Windows Server 2008 or Windows Server 2008

R2.

You run this command only once in the forest.

Run this command on the domain controller that holds the schema operations master role for the forest.

You must be a member of all the following groups to run this command: o Enterprise Admins group o Schema Admins group o The Domain Admins group of the domain that hosts the schema master

adprep

/domainprep

Use the adprep /domainprep command to prepare a domain for a Windows Server 2008

or Windows Server 2008 R2 domain controller.

Run this command on the domain controller that holds the infrastructure operations master role for the domain.

Run this command after the adprep /forestprep command finishes and after the changes replicate to all the domain controllers in the forest.

Run this command in each domain where you plan to add a domain controller that runs Windows Server 2008 or Windows Server 2008 R2.

You must be a member of the Domain Admins group to run this command.

For domains at the Windows 2000 functional level, run adprep /domainprep /gpprep instead. This provides updates that are necessary to enable Resultant Set of Policy (RSOP) Planning Mode functionality. This command performs updates during off-peak hours. This minimizes replication traffic that is created in

those environments by updates to file system permissions and Active Directory permissions on existing Group Policy objects (GPOs).

adprep

/rodcprep

Use the adprep /rodcprep command if you plan on installing an RODC in any domain in

the forest.

The adprep /rodcprep command updates permissions on application directory partitions to enable replication of the partitions to read-only domain controllers (RODCs).

This operation runs remotely; it contacts the infrastructure master in each domain to update the permissions.

You need to run this command only once in the forest. However, you can rerun this command any time if it fails to complete successfully because an infrastructure master is not available.

You can run this command on any computer in the forest.

You must be a member of the Enterprise Admins group to run this command.

Note: In Windows Server 2008 R2, adprep is available in a 32-bit version and a 64-bit version. The 64-bit version runs by default. If you need to run adprep on a 32-bit computer, run the 32-bit version (adprep32.exe).

When installing Active Directory Domain Services (AD DS) for Windows Server 2008 or Windows Server 2008 R2, you face one or more of the following installation scenarios:

Installation scenario Description

Installing a new Windows Server 2008 or

Windows Server 2008 R2 Forest

When you install AD DS in a new Windows Server 2008 or

Windows Server 2008 R2 forest, be aware of the following:

The first Windows Server 2008 or Windows Server 2008 R2 domain controller in a forest must be a global catalog server and it cannot be a Read Only Domain Controller (RODC).

The default domain functional level is set to Windows 2000 for both the forest and the domain.

Installing a new Windows Server 2008 or

Windows Server 2008 R2 domain

controller to create a new domain in an

existing Windows 2000 Server or

Windows Server 2003 forest

Before you create a new domain running on a Windows

Server 2008 or Windows Server 2008 R2 domain controller in

a Windows 2000 Server or Windows Server 2003 forest:

Run the adprep /forestprep command if this is the first Windows Server 2008 or Windows Server 2008 R2 domain controller in the forest.

If you plan on installing an RODC in any domain in the forest, use the adprep /rodcprep command.

The schema must be updated before the operating system is installed if you are performing an unattended installation of AD DS with Windows Server 2008 or Windows Server 2008 R2.

For standard installations, the schema must be updated before you install AD DS on the first Windows Server 2008 or Windows Server 2008 domain controller.

Note: You only update the forest once before installing the

first Windows Server 2008 or Windows Server 2008 R2

domain controller. After the schema has been updated, you

can install additional 2008 domain controllers without running

adprep /forestprep.

Installing a new Windows Server 2008 or

Windows Server 2008 R2 domain

controller in an existing Windows 2000

Server or Windows Server 2003 domain

If you are installing a new domain controller running Windows

Server 2008 or Windows Server 2008 R2 into an existing

domain:

Run the adprep /forestprep command if this is the first Windows Server 2008 or Windows Server 2008 R2 domain controller in the forest.

Run the adprep /rodcprep command if this is the first read-only domain controller in the forest and if adprep /rodcprep has not yet been run.

Run the adprep /domainprep command if this is the first Windows Server 2008 or Windows Server 2008 R2 domain controller in the domain. If necessary, use the adprep /domainprep /gpprep command.

AD DS Installation Facts

The following list contains the requirements for installing Active Directory Domain Services (AD DS):

You must have membership in the Domain Admins, Schema Admins, and Enterprise Admins group.

You must have properly configured static IP addresses and Domain Name System (DNS) server addresses.

You must verify that a DNS infrastructure is in place on your network before you add AD DS to create a domain or forest.

Use local, fixed disks for the volumes that store the database, log files, and SYSVOL folder for AD DS.

For added security, place the database and log files on a volume with the NTFS file system.

There are four methods for Active Directory Domain Services (AD DS) installation:

Method Description

Active Directory

Domain Services

Installation

Wizard

AD DS installation using wizards requires the following actions:

In Server Manager, run the Add Roles Wizard to install the Active Directory binaries.

Run dcpromo.exe to run the Active Directory Domain Services Installation

Wizard. This wizard can be used to install new 2008 forests, domains, and domain controllers.

Command Line

At the command line, use the dcpromo command combined with unattended

installation switches and parameter values to create forests, domains, and domain

controllers. Use the following switches to customize the installation:

Use /NewDomain with the Forest, Tree, or Child switch to specify the type of new domain.

Use /DomainLevel or /ForestLevel with the following options: o 0 = Windows 2000 Server Native o 2 = Windows Server 2003 Native o 3 = Windows Server 2008

Use /databasePath:C:\Windows\ntds /logPath:C:\Windows\ntdslogs /sysvolpath:C:\Windows\sysvol to specify the location of the database file, directory service log files, and system volume (SYSVOL) folder, respectively.

Use /DNSOnNetwork to specify whether DNS service is available on the network.

Use /NewDomainDNSName to specify a fully qualified domain name (FQDN) for the new domain.

Note: For a complete list of unattended installation switches, including default values, allowed values, and descriptions, type dcpromo /?:Promotion at the command prompt.

Answer file

An answer file is a list of Active Directory configuration values in a text file which is

used to install AD DS on either a full installation of Windows Server 2008 or a Server

Core installation. To create an answer file you can:

Run the Active Directory Domain Services Installation Wizard and export your choices to a file.

Create or edit the answer file directly in a text editor.

To perform the install using the answer file, run dcpromo /unattend:C:\unattend.txt,

using the name of the answer file you created.

AD DS

installation from

media

Using media is an alternate method of AD DS installation. The media contains the

unattended installation parameters which will create additional domain controllers, as

well as the Active Directory database. During installation, the Active Directory database

is copied from the media instead of replicated from another domain controller. Use the

media installation method if you need to perform a domain controller install where the

domain controller will not be able to contact another domain controller during

installation.

Use one of the following to create the installation media:

Run ntdsutil.exe.

Run Windows Server backup in Windows Server 2008. A critical-volumes backup includes all files on the volumes that are required to recover AD DS which is significantly more space than required for AD DS installation.

To install a domain controller using media, use one of the following methods:

In the Active Directory Domain Services Installation Wizard, use the Install from Media page to refer to the location of the shared folder or removable media.

Use the /ReplicationSourcePath parameter during an unattended installation to specify the location of the shared folder or removable media.

Be aware of the following when installing a RODC:

The first Windows Server 2008 domain controller in a forest cannot be a Read Only Domain Controller (RODC). If your forest does not have a Windows Server 2008 domain controller, install a writable domain controller prior to installing the RODC.

You cannot convert an RODC to a full installation, nor can you convert a full installation to an RODC.

You cannot upgrade a Windows Server 2003 domain controller as a Windows Server 2008 read-only domain controller. To make a Windows Server 2003 domain controller an RODC, first remove AD DS, then re-install the domain controller as an RODC.

AD DS Answer File Details Below is an example of an answer file that creates a new child domain (named sales) into the

existing westsim.com forest:

[DCINSTALL]

InstallDNS=yes

ParentDomainDNSName=westsim.com

ReplicaOrNewDomain=domain

NewDomain=child

NewDomainDNSName=sales.westsim.com

ChildName=sales

DomainNetBiosName=sales

DomainLevel=2

DatabasePath=C:\Windows\ntds

LogPath=C:\Windows\ntdslogs

SYSVOLPath=C:\Windows\sysvol

SafeModeAdminPassword=w3st1m2008

RebootOnCompletion=yes

The following list describes the various parameters you can use within the answer file:

Entry Parameter Description

ChildName Specifies the single-label DNS name of the child domain. Do not include parent domain names in the name.

DatabasePath Specifies the fully qualified, non-UNC path to a directory on a fixed disk of the local computer that contains the domain database. For example, C:\Windows\ntds

DomainLevel

Specifies the domain functional level when a new domain is created in an existing forest. 0 = Windows 2000 Server Native 2 = Windows Server 2003 3 = Windows Server 2008

DomainNetBiosName Assigns a NetBIOS name to the new domain. It is the left-most label of DNS name, without parent domain names.

ForestLevel

Specifies the forest functional level when a new domain is created in a new forest. 0 = Windows 2000 Server 2 = Windows Server 2003 3 = Windows Server 2008

Note: Do not use this switch when you are installing a domain controller in an existing forest.

InstallDNS

Specifies whether DNS is configured for a new domain if Dcpromo detects that the DNS dynamic update protocol is not available, or if it detects an insufficient number of DNS servers for an existing domain.

Note: InstallDNS replaces AutoConfigDNS.

LogPath Specifies the fully qualified, non-UNC path to a directory on a fixed disk of the local computer that contains the domain log files, for example, C:\Windows\ntdslogs

NewDomain

Specifies the type of new domain: Forest = The root domain of a new forest (Default) Tree = The root domain of a new tree in an existing forest Child = A child domain in an existing forest

The type of new domain must be specified when AD DS is installed on a Windows server core installation.

NewDomainDNSName Specifies a fully qualified domain name (FQDN) for the new domain.

ParentDomainDNSName Specifies the FQDN of an existing parent domain when installing a child domain.

Password Specifies the password corresponding to the user name (account credentials) that is used to promote the domain controller. Specify * to prompt the user to enter credentials.

ReplicaDomainDNSName Specifies the FQDN of the domain in which you want to promote an additional domain controller.

ReplicaOrNewDomain

Specifies whether to install the domain controller as: Replica = An additional domain controller in an existing domain (Default) ReadOnlyReplica = An RODC in an existing domain Domain = The first domain controller in a new domain

ReplicateFromMedia Indicates whether an install from media is being performed. Possible options are Yes or No.

ReplicationSourcePath Indicates the location of the installation media that will be used to install a new domain controller.

SafeModeAdminPassword The password for the administrator account to use when starting the computer in Safe Mode or a variant of Safe Mode, such as Directory Service Restore Mode. You cannot specify a blank password.

SysVolPath Specifies the fully qualified, non-UNC path to a directory on a fixed disk of the local computer, for example, C:\Windows\SYSVOL

The following table lists key answer file settings for various installation examples:

Scenario Description

Forest

The following lines indicate you are installing a new Windows Server 2008 forest: NewDomain=forest

ReplicaOrNewDomain=domain

NewDomainDNSName=westsim.com

DomainNetBiosName=westsim

ForestLevel=2

DomainLevel=2

Child Domain

The following lines indicate you are installing a child domain into an existing domain tree: NewDomain=child

ReplicaOrNewDomain=domain

ParentDomainDNSName=westsim.com

NewDomainDNSName=sales.westsim.com

ChildName=sales

DomainNetBiosName=sales

DomainLevel=2

Domain Tree

The following lines indicate you are installing the first domain in a new domain tree: NewDomain=tree

ReplicaOrNewDomain=domain

ParentDomainDNSName=westsim.com

NewDomainDNSName=eastsim.com

ChildName=eastsim

DomainNetBiosName=eastsim

DomainLevel=2

Additional Domain Controller

The following lines indicate you are installing an additional domain controller in an existing domain: ReplicaOrNewDomain=replica

ReplicaDomainDNSName=sales.westsim.com

UserName=aWaters

UserDomain=westsim.com

Password=1q2w3e4r

ConfirmGC=yes

Note: The UserDomain indicates the domain where the user account exists, not the domain where you are installing the domain controller.

AD DS Installation Verification Facts

After installing AD DS, use the following methods to verify the installation. To perform these procedures, you must be a member of the Domain Users group.

Task Description

Determine whether a

Server object has

child objects

After Active Directory is properly installed on a domain controller, the Server object

for the domain controller will have a child NTDS-Settings object. Other applications

that are running on domain controllers can also publish child objects.

To verify that the server has child objects, in Active Directory Sites and Services, browse to the server object (located within the appropriate site) and then expand the server object to view any child objects.

Check the status of This procedure involves checking Event Viewer to make sure that the File

the shared SYSVOL Replication service is started properly and then ensuring that the SYSVOL and

NETLOGON shared folders are created. Do the following to verify the SYSVOL

status:

In Event Viewer, click File Replication Service, and look for the following events:

o Event 13508 indicates that FRS is in the process of starting the service.

o Event 13509 indicates that the service has started successfully. o Event 13516 indicates that the service is started, the folders are

shared, and the domain controller is functional. The event has a date and time stamp that corresponds with the recent restart. It can take 15 minutes or more to appear.

Run net share to display a list of the shared folders on this domain controller, including NETLOGON and SYSVOL.

Run dcdiag /test:netlogons, and look for a message that states computername passed test NetLogons where computername is the name of the domain controller. If you do not see the test passed message, replication will not function. This test verifies that the proper logon privileges are set to allow replication to occur. If this test fails, verify the permissions set on the NETLOGON and SYSVOL shared folders.

Verify domain

membership for a

new domain

controller

This test verifies that a new domain controller has successfully become a member

of the domain. To verify domain membership for a new domain controller, run

netdiag /test:member and look for the following message:

Domain membership test Passed

If you use the /v option, it will list the name of the domain controller, its role, the

name of the domain, and a number of other statistics about the new domain

controller.

Verify

communication with

other domain

controllers

This procedure verifies that domain controllers can be located. To verify

communication with other domain controllers, run the netdiag /test:dsgetdc

command.

If domain controllers are successfully located, the last line of the response is DC discovery test......: Passed. The /v option lists the specific domain controllers that are located.

If the test fails, do not attempt any additional steps until you determine and fix the problem that prevents communication with other domain controllers.

Verify replication

with other domain

controllers

The tests performed in this procedure verify that different aspects of the replication

topology are working properly. They check to see that objects are replicating and

they verify that the proper logon permissions are set to allow replication to occur.

To verify replication is functioning, run dcdiag /test:replications.

To verify that the proper permissions are set for replication, run dcdiag /test:netlogons. Messages indicate whether the connectivity and

netlogons tests passed.

AD DS Removal Facts

Similar to AD DS installation, there are three tools you can use to remove a domain controller:

The Active Directory Domain Services Installation Wizard removes domain controllers in a prompted environment in the same manner it adds domain controllers. Use dcpromo.exe to start the Active Directory Domain Services Installation Wizard.

The command line uses the dcpromo command combined with unattended installation switches and parameter values to remove domain controllers.

An answer file is called by the dcpromo command to remove domain controllers.

The following table describes what to do in specific uninstall scenarios:

Scenario Description

Remove a

domain

controller from a

domain

You should know the following about removing a domain controller from a domain:

You must be a member of the Domain Admins group in the domain to perform this procedure.

If necessary, you must first transfer the operations master roles hosted by the domain controller to other domain controllers.

If you are using the wizard to perform this task, do not choose the Delete the domain option.

If you are using the command line to perform this task, use dcpromo combined with unattended installation switches and parameter values.

If you are using an answer file to perform this task, include the removeapplicationpartitions=yes and removeDNSDelegation=yes entries.

Remove the last

domain

controller from a

domain

You should know the following about removing the last domain controller from a domain:

You must be a member of the Enterprise Admins group in the forest to perform this procedure.

You must move all forest operations master roles before you can remove the last domain controller from a domain.

If you are using the wizard to perform this task, select the Delete the domain option and proceed through the wizard prompts.

If you are using an answer file to perform this task, include the IsLastDCInDomain=yes entry.

If you are using the command line to perform this task, use the /IsLastDCInDomain:Yes and /DemoteFSMO:Yes switches.

Remove the last

domain

controller from a

forest

You should know the following about removing the last domain controller from a forest:

You must be a member of the Domain Admins group in the forest root domain or a member of the Enterprise Admins group in the forest to perform this procedure.

If you are using the wizard to perform this task, select the Delete the domain

and forest option and proceed through the wizard prompts.

If you are using the answer file and command line methods to perform this task, they are the same as if you were removing the last domain controller from a domain. Because the forest root domain is the domain that you are removing, the options for removing the domain effectively remove the forest itself.

Forced removal

of a domain

controller

Forcefully remove a domain controller only if the domain controller has no connectivity

with other domain controllers. You should know the following about forcefully removing

a domain controller from a domain:

You must be a member of the Domain Admins group in the domain to perform this procedure.

You must manually update the forest metadata after you remove the domain controller because the AD DS forest metadata is not automatically updated, as is the case when a domain controller is removed normally.

If you are using the wizard to perform this task, go to the Force the Removal of Active Directory Domain Services page and proceed through the wizard's prompts.

If you are using the command line to perform this task, use the dcpromo /ForceRemoval command. In addition, use /DemoteFSMO command to force the removal of AD DS even if an operations master role is held by the domain controller.

Note: If you cancel the Active Directory Domain Services Installation Wizard during installation, the AD DS binary files are not removed. To uninstall the binary files, use Server Manager to uninstall the AD DS role or run dcpromo /uninstallBinaries at the command line, and then restart the computer.

Functional Level Facts

A functional level is a set of operation constraints that determine the functions that can be performed by an Active Directory domain or forest. A functional level defines:

Which Active Directory Domain Services (AD DS) capabilities are available to the domain or forest.

Which Windows Server operating systems can be run on domain controllers in the domain or forest. Functional levels do not affect which operating systems you can run on workstations and servers that are joined to the domain or forest.

The following table shows the features that are available at each domain functional level:

Domain

Functional

Level

Supported

Domain

Controller

Operating

Systems

Features

2000 Native 2000 2003 2008

The following features are available in 2000 Native:

Universal groups are available for security and distribution

2008 R2 groups.

Group nesting.

Group converting (allows conversion between security and distribution groups).

Security Identifier (SID) history, allowing security principals to be migrated among domains while maintaining permissions and group memberships.

2003 2003

2008

2008 R2

Windows Server 2003 includes all of the features available in 2000

Native mode, and adds the following features:

Domain controller rename.

Update logon time stamp.

User password on InetOrgPerson object.

User and computer container redirect. The redirect feature allows the definition of a new, well-known location for the two default containers (cn=Computers <domain root> and cn=Users <domain root>) which are provided for housing computer and user accounts.

Authorization Manager can store its authorization policies in AD DS.

Constrained delegation allows applications to take advantage of the secure delegation of user credentials using Kerberos-based authentication.

Selective authentication allows you to specify the users and groups from a trusted forest who are allowed to authenticate to resource servers in a trusting forest.

2008 2008

2008 R2

Windows Server 2008 includes all of the features available in 2003

mode, and adds the following features:

Distributed File System (DFS) replication for the Windows Server 2003 System Volume (SYSVOL).

Advanced Encryption Standard (AES 128 and AES 256).

Last Interactive Logon Information, which includes: o The time of the last successful interactive logon for a

user. o The name of the workstation from which the user

logged on. o The number of failed logon attempts since the last

logon.

Fine-grained password policies that allow you to specify password and account lockout policies for users and global security groups in a domain.

2008 R2 2008 R2 Windows Server 2008 R2 includes all previous features and adds:

Authentication mechanism assurance (AMA), allowing you to control access to network resources based on the type of certificate used during logon. For example, you can allow more access when users log on using a smart card.

Automatic service principal name (SPN) management when using managed service and virtual accounts.

The following table shows the features that are available at each forest functional level:

Forest

Functional

Level

Supported

Domain

Controller

Operating

Systems

Features

2000 Native 2000

2003

2008

2008 R2

Global catalog replication improvements are available if both replication

partners are running Windows Server 2003.

2003 2003

2008

2008 R2

The following features are available in 2003:

Global catalog replication improvements

Defunct schema objects

Forest trusts

Linked value replication which allows you to change group membership to store and replicate values for individual members instead of replicating the entire membership as a single unit. Linked value replication:

o Uses less network bandwidth and fewer processor cycles during replication.

o Prevents you from losing updates when you add or remove multiple members concurrently at different domain controllers.

RODC deployment capability

Domain rename

Improved Knowledge Consistency Checker (KCC)

Improved AD replication algorithms

Dynamic auxiliary classes

InetOrgPerson objectClass change

The ability to create instances of new group types to support role-based authorization

Deactivation and redefinition of classes and attributes in the schema

2008 2008

2008 R2

No additional features have been added to 2008, but it does include all of

the features that are available at the 2003 level.

2008 R2 2008 R2 Windows Server 2008 R2 forest functional level adds support for the

Active Directory Recycle Bin to all of the features that are available at the

2003 level. The Recycle Bin allows for easy recovery of deleted Active

Directory objects (without the Recycle Bin, you must restore deleted

objects from a backup).

Note: Windows Server 2003 and Windows 2000 Server domain controllers support additional domain and forest functional levels. These levels are provided mainly for backwards compatibility with NT 4.0 domains and to prepare for migration from NT 4.0 domains. The domain and forest functional level must be at a minimum Windows Server 2000 to install a Windows Server 2008 or Windows Server 2008 R2 domain controller.

Functional Level Management Facts

You should know the following about functional level management:

To allow you to use as many Active Directory Domain Services (AD DS) features as possible, you should set the domain and forest functional levels to the highest value that your environment can support when you deploy AD DS. For example:

o Select the Windows Server 2008 R2 functional level to use all the features that are available in AD DS, including Active Directory Recycle Bin, Authentication mechanism assurance (AMA), and Automatic service principal name (SPN) management.

o Select the Windows Server 2008 functional level if you might retain or add domain controllers that run Windows Server 2008.

o Select the Windows Server 2003 functional level if you might retain or add domain controllers that run Windows Server 2003.

o Select the Windows Server 2000 functional level if you might retain or add domain controllers that run Windows Server 2000.

Note: AD DS sets the functional levels by default when you deploy the first Windows Server 2008

R2 domain controller in your forest root domain.

In most cases, you cannot reverse the operation of raising the functional level. If you have to revert to a lower functional level, you must rebuild the domain or forest, or restore it from a backup. There are two exceptions:

o If you raise the domain functional level to Windows Server 2008 R2, and if the forest level is at Windows Server 2008 (or lower), you can roll back the domain functional level to Windows Server 2008 (but not to any lower functional level).

o If you raise the forest functional level to Windows Server 2008 R2, and if you have not yet enabled the Active Directory Recycle Bin, you can roll back the forest functional level to Windows Server 2008 (but not lower). Once you enable the Active Directory Recycle Bin, you can no longer roll back the forest functional level.

Note: You should use the Set-ADDomainMode PowerShell cmdlet to roll back the domain

functional level from Windows Server 2008 R2.

The following guidelines apply to raising the domain or forest functional levels:

Type Details

Domain

Use Active Directory Users and Computers or Active Directory Domains and Trusts to raise the

domain functional level.

You must be a member of the Domain Admins group to raise the domain functional level.

The domain functional level can only be raised on the Primary Domain Controller (PDC) emulator operations master. The AD DS administrative tools which are used to raise the domain functional level, such as the Active Directory Domains and Trusts snap-in and the Active Directory Users and Computers snap-in, will automatically target the PDC emulator when the domain functional level is raised.

The functional level of a domain can only be raised if all domain controllers in the domain run the version or versions of Windows Server operating system that is supported by the new functional level. For example, before you raise the domain functional level to 2008, you must upgrade all domain controllers in that domain to Windows Server 2008.

To use the Windows Server 2008 or Windows Server 2008 R2 domain-level features without upgrading your entire Windows 2000 forest to Windows Server 2008, raise only the domain functional level to Windows Server 2008 or Windows Server 2008 R2.

It is not possible to set the domain functional level to a value that is lower than the forest functional level.

The Windows 2000 native and Windows Server 2003 domain functional level values are not available on the Set domain functional level page of the 2008 Active Directory Domain Services Installation Wizard.

Forest

Use Active Directory Domains and Trusts to raise the forest functional level.

You must be a member of the Enterprise Admins group to raise the forest functional level.

The forest functional level can only be raised on the schema operations master. The schema operations master is targeted by the Active Directory Domains and Trusts when the forest functional level is raised.

The functional level of a forest can only be raised if all domain controllers in the forest run the version or versions of Windows Server operating system that is supported by the new functional level.

The following circumstances might prevent you from raising the functional level to Windows Server 2008 or Windows Server 2008 R2:

Domain controllers that don't run the necessary operating system version

Insufficient hardware

A domain controller running an antivirus program that is incompatible with Windows Server 2008 or Windows Server 2008 R2

Use of a version-specific program that does not run on Windows Server 2008 or Windows Server 2008 R2

The need to upgrade a program with the latest service pack

Sites and Subnets Facts

Active Directory replication is the process of copying Active Directory database changes between domain controllers. Active Directory uses sites and subnets to represent the physical layout of the network and to optimize and customize replication traffic. Active Directory uses the following objects to represent the physical structure of the network and to control replication traffic.

Object Description

Subnet

A subnet represents a physical network segment.

The subnet object identifies the network address and mask. Both IPv4 and IPv6 are supported.

Domain controllers are indirectly associated with a subnet based on the domain controller IP address.

Site

A site represents a group of well-connected networks (networks that are connected with

high-speed links).

Sites are linked to one or more subnets. All subnets within the site can communicate over high-speed and reliable links.

Domain controllers are associated with a specific site. You can specify the target site during installation, or move existing domain controllers into sites.

When you install the first domain controller in a forest, a default site is created named Default-Site-First-Name.

Sites can host domain controllers from more than one domain, and a domain can be represented in more than one site.

You typically create additional sites to identify locations separated by WAN links.

Site link

A site link is an Active Directory object that represents logical paths between sites that can

be used for Active Directory replication.

Site links represent logical, not physical connections. For example, you can have all sites connected with a single site link.

In most cases, you would match the site link design to the physical network, with a site link for each WAN link.

When you install the first domain controller in a forest, a default site link named DEFAULTIPSITELINK is created.

Sites are associated with a site link. Each site link can have multiple associated sites, and each site can be associated with more than one site link. In a simple scenario, you can have all sites associated to the default site link.

The site link object controls the replication schedule between sites.

When more than one logical route exists between two sites, the site link with the lowest cost determines the preference for using a specific site link for replication. The higher the site link cost, the slower the link speed.

Site link

bridge

A site link bridge is a collection of two or more site links that can be grouped as a single

logical link. The best way to understand site link bridging is to consider three sites, linked

as follows:

SiteA-----(Site-Link-1)-----SiteB-----(Site-Link-2)-----SiteC

Without bridging, SiteA does not have a communication path to SiteC. With bridging, the

two site links in the example are transitive, allowing a connection from SiteA to SiteC.

By default, site link bridging is enabled for all sites.

If you disable site link bridging, you must manually specify site link bridges.

Bridgehead A bridgehead server is a domain controller in a site that replicates with domain controllers

server in other sites.

Replication between sites occurs only between bridgehead servers. The bridgehead server in one site contacts a bridgehead server in another site for replication information.

Replication within a site does not use bridgehead servers. All domain controllers replicate with all other domain controllers in the site.

Active Directory automatically identifies a bridgehead server in each site (typically it will be the first domain controller in the site). You can manually designate bridgehead servers to control which domain controllers participate in intersite replication.

Connection

A connection is a logical communication channel between domain controllers.

Connections are created automatically, although you can manually create connections if desired.

The connector is a property of a domain controller, and identifies one other domain controller from which replication changes will be received. Replication is always a pull configuration, meaning that the target domain controller contacts the source domain controller for replicated information.

Connections are unidirectional (one-way). For bidirectional communications, two connections must exist between the domain controllers (one configured on each domain controller).

Replication Facts

Sites and Services distinguishes between two types of replication:

Intrasite replication occurs between domain controllers within a site. Intrasite replication is not compressed and happens automatically between all domain controllers within the site. You can modify the frequency to occur up to four times per hour.

Intersite replication occurs between bridgehead servers between sites. Intersite replication is compressed, scheduled, and configured to use a specific networking protocol. Compressing replication data allows the data to be transferred over WAN links more quickly, thereby conserving network bandwidth. To customize intersite replication, configure sites and site links.

Replication uses one of following transport protocols:

Protocol Description

Directory Services

Remote Procedure

Call (DS-RPC)

Directory Services Remote Procedure Call (DS-RPC), also known as IP in Active

Directory Sites and Services, is used for intra-site and inter-site replication.

Remote Procedure Calls (RPC) runs over IP.

IP replication adheres to replication schedules by default, although you may configure Active Directory replication to ignore schedules.

IP replication does not require a Certification Authority (CA).

Note: By default, both intrasite and intersite transport for AD DS replication is

RPC over IP.

Inter-Site

Messaging—Simple

Mail Transfer Protocol

(ISM-SMTP)

Inter-Site Messaging—Simple Mail Transfer Protocol (ISM-SMTP), also known as

SMTP in Active Directory Sites and Services, allows replication within mail

messages in environments where wide area network (WAN) links are not

available. In this case, replication occurs according to the messaging schedule

and not the site link schedule. SMTP replication:

Is used for replication over site links (inter-site). Is not used for replication within a site (intra-site).

Uses 56-bit encryption.

Is used for high latency links where RPC over IP replication would probably fail.

Can replicate only the configuration and schema directory partitions and global catalog read-only replicas (not writable domain data).

Requires an enterprise CA when you use it over site links.

Replication Configuration Facts

Intrasite replication occurs between domain controllers within a site. For intrasite replication, be aware of the following:

By default, replication occurs once every hour.

To modify the replication frequency, edit the NTDS Settings for the site. For each hour, you can configure the following options for the replication frequency:

o None (replication does not take place) o Once per hour o Twice per hour o Four times per hour

Bridgehead servers, site links, or site link bridging are not used. Connections are created automatically as necessary.

Intersite replication occurs between bridgehead servers between sites. The following table describes configuration steps you can take when managing intersite replication.

Configuration Description

Preferred

bridgehead

server

A preferred bridgehead server is a domain controller in a site that has been designated

as a potential bridgehead server.

To designate preferred bridgehead servers, edit the server properties and add the transport protocol to the preferred bridgehead server list.

The preferred bridgehead server should be a global catalog server.

You can designate more than one server as a preferred bridgehead server. If multiple servers in a site are preferred bridgehead servers, the replication process automatically selects one of the servers during replication.

When at least one preferred bridgehead server exists in a site, replication will only use preferred servers for intersite replication; non-preferred servers will never be used. This means that:

o To prevent a specific server from being used for intersite replication,

configure one or more preferred bridgehead servers. o If all bridgehead servers in a site are unavailable, intersite replication will

not occur. For this reason, you should assign more than one preferred bridgehead server.

If no preferred bridgehead servers are designated, the system chooses which server to use for the bridgehead server from the list of servers in the site that are enabled for the transport protocol.

Note: In Windows Server 2008 R2, load-balancing was introduced to distribute the workload evenly among bridgehead servers. The Windows Server 2008 R2 forest or domain functional level is not required for the load balancing feature, only Windows Server 2008 R2 domain controllers.

Replication

schedule

The replication schedule identifies the hours of the day when replication is possible.

To edit the replication schedule for intersite replication, edit the properties of the site link and click the Change Schedule... button.

The schedule identifies which days and hours of the day that replication is allowed.

By blocking replication, you give priority to other traffic, but you also increase replication latency.

Domain controllers store time in Coordinated Universal Time (UTC). Time settings in site link object schedules conform to the local time of the site and computer on which the schedule is set. When a domain controller contacts a computer that is in a different site and time zone, the schedule on the domain controller displays the time setting according to the local time for the site of the computer.

It is best to synchronize your SMTP site link replication schedule with the times your network's SMTP connections are available. Do not configure site link replication availability on SMTP site links unless the following is true:

o Scheduled connections are used by the site links. o The SMTP queue is not on a schedule. o Information is being exchanged directly from one server to another. This

does not include exchanges that use intermediaries such as a network Ethernet backbone.

Replication

frequency

The replication frequency identifies how often replication occurs (if it is allowed). The

replication frequency works together with the replication schedule to control when

replication occurs.

To modify the replication frequency for intersite replication, edit the properties of the site link.

The replication frequency is scheduled in 15 minutes intervals. The default replication interval is 180 minutes (3 hours).

A small interval decreases latency but increases the amount of wide area network (WAN) traffic. To keep domain directory partitions up to date, low latency is preferred.

The replication frequency is dependent upon the times when replication over this site link is scheduled to be available. For example, if the schedule allows replication between 02:00 am and 04:00 am:

o If the replication interval is set for 30 minutes, replication can occur up to four times during the scheduled time.

o If the replication interval is set for 180 minutes, replication might occur

once, or not at all. To ensure that replication takes place, configure the replication frequency to be shorter than the scheduled time interval.

Site link cost

The site link cost is a number assigned to a site link that identifies the overall relative

cost of using that site link. The cost is used to select the optimal path between sites

when more than one path exists.

Cost is usually based not only on the total bandwidth of the link but also on the availability, latency, and monetary cost of the link.

The cost value is a relative value. The number has meaning only in relation to other site link costs.

The default link cost is 100. If you do not modify the site link cost, all site links will have an equal cost value.

To force traffic over one link, set a lower cost. For example, set a lower cost for high-speed links to force traffic over the high speed link. Configure a higher cost for dial-up links that are used as backup links.

To modify the cost, edit the properties of the site link object.

Active directory also uses the site link cost to determine which site will provide coverage in the event a domain controller cannot be located at the clients' own site, and in the event of multiple failures will try other sites according to the cost until it locates a viable domain controller. Automatic site coverage factors in the cost associated with the site links of a site without a domain controller. Use the autositecoverage setting in the HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters key in the registry to adjust the site coverage:

When set to 0, the system cannot add sites to the coverage area of the domain controller. This setting must be set to 0 on the domain controller that should not provide coverage to sites that do not have a domain controller.

When set to 1, the system can add sites to the coverage area of the domain controller.

Bridged site

replication

Site link bridging enables transitivity between site links, so that replication between sites

that are not directly connected together with a site link can still take place. Be aware of

the following when planning for bridged sites:

By default, all site links are bridged. To prevent automatic bridging, edit the properties of the transport protocol (such as IP) and deselect the Bridge all site links option. By disabling this option, you must manually create site link bridges.

To create a site link bridge, right-click the transport protocol and select New Site Link Bridge....

For replication between bridged sites to be successful, the following conditions must be met:

o Schedules set on the site links between the two bridged sites must overlap. The intersection of the replication schedules on all the relevant links determines the connection schedule between the two sites.

o The replication frequency must be sufficient for replication to occur. The replication interval is the maximum interval along the minimum-cost path of site link objects from one end of the connection to the other.

An easy way to ensure replication occurs between bridged sites is to set the

same replication schedule and frequency on all site links connecting the two

bridged sites.

Link costs are cumulative when multiple links are required between sites. If more than two paths are available (including bridged or non-bridged paths), the one with the lowest cost is used (even if this path crosses more sites and site links). Click Bridged Site Costs for an example.

Forced

replication

You can force replication to take place using one of the following methods:

To force replication between two sites, right-click the connection object and choose Replicate Now.

To force replication to or from a domain controller, right-click the NTDS Settings object below the server and choose one of the following:

o Replicate configuration from the selected domain controller o Replicate configuration to the selected domain controller

Run repadmin.exe /replicate from a command prompt to force replication between a source and a destination domain controller. List the target system first, followed by the source system. Use /syncall to force replication between all domain controllers in a site. Use /rodcpwdrepl to force replication of the passwords to read-only domain controllers (RODC).

Note: To configure sites, subnets, and replication, you must be a member of the Domain Admins group or the Enterprise Admins group.

DFS Replication Facts

The SYSVOL folder contains logon scripts, group policy templates, and other resources which are critical to the health and management of an Active Directory domain. Every domain controller should have the same contents in their respective SYSVOL folder; however, as these resources are modified and replicated to other SYSVOL folders throughout the domain, errors can occur. In previous version of Windows Server, the File Replication Service (FRS) was used to replicate the contents of the SYSVOL folder, but troubleshooting and configuring FRS is quite difficult. To overcome some of the limitations of FRS, domains with a functional level of Windows Server 2008 can use the Distributed File System (DFS) Replication engine to replicate the contents of the SYSVOL folder.

Using DFS replication instead of FRS replication offers the following benefits:

Faster replication and decreased network traffic through the use of differential replication with Remote Differential Compression (RDC). With RDC, only the changed blocks are replicated when a file is changed, not the entire file.

Flexible scheduling and bandwidth throttling to limit the quantity of data transmitted and/or accepted within a specified period of time.

Automatic self-healing for many database errors.

Improved support for read-only domain controllers.

Built in health monitoring tools.

When you install a new forest with the Windows Server 2008 or Windows Server 2008 R2 domain functional level, DFS Replication is used automatically. For domains using other domain functional levels, you can migrate from FRS replication to DFS replication as follows:

1. Upgrade all domain controllers to Windows Server 2008 or Windows Server 2008 R2. 2. Change the domain functional level to Windows Server 2008 or Windows Server 2008 R2. 3. Verify the current state of replication by running repadmin /ReplSum. Correct any problems that

are noted. 4. Run the dfsrmig command to start and control the migration. The following states indicate stable

stages in the migration process:

State Description

Not

initiated

If SYSVOL migration has not been started, the state will be Not initiated. Only FRS

is used to replicate the SYSVOL contents.

Start

Run the dfsrmig /SetGlobalState 0 command to start DFS migration. Running this

command contacts the domain controller with the PDC master and sets a migration

directive in Active Directory. This directive is replicated to all other domain controllers

through normal Active Directory replication. At this stage, DFS replication has not yet

started, and only FRS replication is still being used.

Prepared

Run the dfsrmig /SetGlobalState 1 command to instruct domain controllers to begin

DFS replication. During this stage, a copy of SYSVOL is created in a folder called

SYSVOL_DFSR and is added to a DFS replication set. DFS Replication begins to

replicate the contents of the SYSVOL_DFSR folders on all domain controllers.

However, FRS continues to replicate the original SYSVOL folders. FRS replication is

still the main replication method.

Redirected

Run the dfsrmig /SetGlobalState 2 command to shift the main responsibility for

SYSVOL replication to DFS. The SYSVOL share is changed to refer to

SYSVOL_DFS\sysvol. Clients now use the SYSVOL_DFSR folder to obtain logon

scripts and Group Policy templates. FRS continues to operate, but the DFS-

replicated folder is used as the master SYSVOL folder.

Eliminated Run the dfsrmig /SetGlobalState 3 command to stop FRS replication and rely only

on DFS replication.

Be aware of the following when managing migration:

The states listed above are stable migration states. Additional intermediary states exist during the transition from one stage to another.

By using a staged migration approach, you can start the migration to DFS Replication, and proceed to the next step after you have verified that everything is working correctly.

Run dfsrmig /GetGlobalState to view the current DFS Replication migration setting on the PDC. This command indicates the current setting, but might not reflect the current state of each domain controller. Domain controllers may not be synchronized with each other due to the time it takes to notify the domain controller of the new migration state and the time for the domain controllers to make the changes required by the state.

Run dfsrmig /GetMigrationState to view the current migration state of each domain controller in the domain.

During the Start, Prepared, and Redirected stages, you can roll back (undo) the migration.

o After the system reaches the Eliminated stage, you cannot revert back to FRS replication. For this reason, do not initiate transition to the Eliminated stage unless you are confident that DFS Replication is working correctly.

o To roll back the migration, use the dfsrmig /SetGlobalState command with the desired rollback level (0 or 1). The changes will be removed back to the indicated stage.

Global Catalog and UGMC Facts

In a multiple-domain and multiple-site design, user logon and forest-wide searches require that multiple domains be contacted to identify user accounts and to identify membership in universal groups. To improve performance in these situations, use the following features:

Feature Description

Global Catalog

The Global Catalog (GC) is a database that contains a partial replica of every

object from every domain within a forest. A server that holds a copy of the Global

Catalog is a global catalog server.

By default, all domain controllers are global catalog servers.

The Global Catalog facilitates faster searches because different domain controllers do not have to be referenced.

The Global Catalog is distributed through multimaster replication.

To designate a server as a global catalog server, use one of the following:

In Active Directory Users and Computers, edit the domain controller computer account. On the General tab, click the NTDS Settings... button.

In Active Directory Sites and Services, edit the NTDS Settings properties beneath the server object.

Promoting a domain controller to be a global catalog server commonly takes a

significant amount of time. Make sure that there is sufficient time for the account

and the schema information to replicate to the new global catalog server.

To add and store an attribute to the Global Catalog in a forest, use the Active Directory Schema snap-in to:

1. Extend the Active Directory Schema. 2. Edit the attribute's properties and select the Replicate this attribute to

the Global Catalog.

Universal Group

Membership Caching

(UGMC)

As its name implies, the Universal Group Membership Caching feature caches the

group membership of universal groups. During logon, universal group membership

is checked for the user. By caching the group membership on a local domain

controller:

The authenticating domain controller does not need to contact other domain controllers for the group membership information.

Logon will still be allowed in the event of a WAN failure that separates a

remote site from the remainder of the network.

Edit the NTDS Site Settings of the site to enable UGMC. All domain controllers in a

site must be running Windows Server 2003 or higher for universal group

membership caching to work.

Within a site, you will typically use a global catalog server or Universal Group Membership Caching (but not both). Place a global catalog server in the site if any of the following are true (use UGMC if all of the following are not true):

The site has more than 100 users.

The WAN link connecting the site to the rest of the network is reliable and fast.

The location has roaming users.

The location runs an application that requires a global catalog server.

Lightweight Directory Access Protocol (LDAP) is the primary global catalog protocol that specifies directory communications. Be aware of the following LDAP details:

LDAP runs directly over TCP/IP, and it can also run over User Datagram Protocol (UDP) connectionless transports.

Clients use LDAP to query, create, update, and delete information that is stored in a directory service over a TCP connection through the TCP default port 389. When a search request is sent to port 389, the search is conducted on a single domain directory partition.

If the object is not found in that domain or the schema or configuration directory partitions, the domain controller refers the request to a domain controller in the domain that is indicated in the distinguished name of the object.

Global catalog clients can use LDAP to query Active Directory over a TCP connection through the TCP port 3268.

o When a search request is sent to port 3268, the search includes all directory partitions in the forest (i.e. the search is processed by a global catalog server).

o Only global catalog servers receive LDAP requests through port 3268.

Active Directory supports LDAP v2 and LDAP v3. LDAP v3 is an industry standard that can be used with any directory service that implements the LDAP protocol. LDAP v3 is backward compatible with LDAP v2.

Operations Master Roles Facts

Operations master roles, also referred to as Flexible Single-Master Operation (FSMO) roles, are specialized domain controller tasks assigned to a domain controller in the domain or forest. Operations master roles are useful because certain domain and enterprise-wide operations are not well suited for the multi-master replication performed by Active Directory to replicate objects and attributes. A domain controller that performs an operations master role is known as an operations master or operations master role owner.

Having a single operations master means that the operations master role owner must be available:

When dependent activities in the enterprise or domain take place.

To make directory changes associated with that specific operations master role.

The following table lists the operation master roles at the domain and forest levels:

Forest Roles Description

Schema Master

The schema master maintains the Active Directory schema for the forest.

Schema updates are replicated from the schema master to all other domain controllers in the forest.

Regardless of the number of domains, there is only one schema master in the forest.

Only the schema master can perform write operations to the directory schema.

All other domain controllers hold read-only replicas of the schema.

Domain Naming

Master

The domain naming master adds new domains to and removes existing domains

from the forest. The domain naming master:

Ensures that domain names are unique

Must be accessible to add or remove a domain from the forest

Must also be a global catalog server if it resides in a multiple domain environment

Note: The domain naming master is not essential in a single-domain environment.

Domain Roles Description

Relative ID (RID)

Master

The RID master allocates pools or blocks of numbers (called relative IDs or RIDs)

that are used by the domain controller when creating new security principles (such as

user, group, or computer accounts). The RID is assigned to a new security principal

when it is created, and is combined with the domain ID to create a security identifier

(SID).

The RID master:

Ensures domain-wide unique relative IDs (RIDs). Because all RIDs are unique, each SID is also unique.

Allocates pools of RIDs to each domain controller.

Processes a new pool of RIDs when the domain controller has used all of the available RIDs. Note: RIDs (and therefore SIDs) are never reused. Deleting security principals on a domain controller will not free up additional RIDs for future use. Instead, the domain controller must get a new pool of RIDs when the pool is depleted.

Primary Domain

Controller (PDC)

Emulator

The PDC emulator acts like a Windows NT 4.0 Primary Domain Controller (PDC) and

performs other tasks normally associated with NT domain controllers. The PDC

emulator:

Replicates password changes within a domain

Ensures synchronized time within the domain (and between domains in the forest) with the w32tm command

Acts as the domain master browser, creating browse lists of workgroups, domains, and servers

Handles password discrepancies

Acts as a focal point for all Group Policy changes to avoid Group Policy object conflicts

Infrastructure

Master

The infrastructure master is responsible for updating changes made to objects. The

infrastructure master:

Tracks, moves, and renames objects

Updates references from objects in its domain to objects in other domains

Updates group membership changes

You should know the following about operations master roles:

Only one domain controller in the domain or forest performs each role.

A forest with one domain has five operations master roles.

Every additional domain in the forest adds three domain-wide roles. The number of operations master roles in a forest and potential operations master role owners can be determined using the formula ((Number of domains * 3) + 2).

Operations Master Roles Management Facts

As you add domain controllers to an existing forest, you can place the operations master roles load among the new and existing domain controllers. This will decrease single-point-of-failure instances, accommodate planned downtime, and increase performance. Consider the following recommendations when designing operations master roles placement on various domain controllers:

Place the schema master and domain naming master on a domain controller which is a global catalog server. If the domain naming master is not a global catalog server, certain operations that use the domain naming master, such as creating grand-child domains, will fail. The schema master and domain naming master roles are rarely used and should be tightly controlled.

With a few exceptions, the infrastructure master should not be placed on a global catalog server except in the following cases:

o In a forest that contains a single Active Directory domain, the infrastructure master may be placed on any domain controller in the domain, regardless of whether that domain controller hosts the global catalog or not.

o If every domain controller in a domain that is part of a multi-domain forest also hosts the Global Catalog, the infrastructure master may be put on any domain controller in that domain. In other words, in a multi-domain network, if the infrastructure master is placed on a global catalog server, all domain controllers in the domain must host the global catalog.

Place the RID master and PDC emulator on a single domain controller. If you must separate the two roles, ensure they are well connected to each other (in the same domain and Active Directory site) and are direct replication partners.

Place the operations masters in the site with the most users when you have multiple sites in a domain. If all sites have roughly equal numbers of users, make sure the operations master roles are in a site that can be accessed from all sites.

One design option is to create the forest root domain without any other resources (users or computers), and then put the forest-wide roles on domain controllers in the forest root domain. This allows you to separate the forest-wide masters from any other domains.

When managing operations master role placement, be aware of the following:

Before transferring a role, you must first connect to the destination domain controller.

Use the following commands to identify the operations master role owners: o netdom query fsmo o dcdiag /test:knowsofroleholders /v o dsquery server –hasfsmo

If the domain controller with the role cannot be contacted, you will need to seize the role (instead of transfer the role).

o You should only seize the role if the domain controller has failed and will not be returned to service in a reasonable period of time.

o After seizing the schema, domain naming, or RID master operations master role, you must forcefully remove AD DS from the original domain controller. The PDC emulator and infrastructure operations master roles can be transferred back to the original domain controller if desired.

It is easier to keep track of operations master roles if you cluster them on fewer machines.

When managing operations master role placement, use the following tools:

Tool Description

MMC Snap-in

Management

Tool

MMC snap-in management tools used for operations master role management include

the following:

Use Active Directory Users and Computers to transfer the RID master, PDC emulator, and infrastructure master roles.

Use Active Directory Domains and Trusts to transfer the domain naming operations master.

Use the Active Directory schema snap-in to identify or transfer the schema master role. By default, the Active Directory schema snap-in must be registered and added to the console before you can make changes to the role. To register the Dynamic Link Library (DLL) for the AD Schema snap-in, type regsvr32 schmmgmt.dll at the command prompt.

Ntdsutil.exe

Use the following Ntdsutil.exe commands to transfer any of the operations master roles:

1. At the ntdsutil prompt, type roles. 2. Connect to the domain controller which will receive the seized operations master

role. 3. At the fsmo maintenance prompt, type connections. 4. At the server connections prompt, use the DNS name of the controller and type

connect to server DNSName 5. At the server connections prompt, type quit. 6. At the fsmo maintenance prompt, use the role name and type transfer

RoleName. RoleName is one of the following: o schema master o domain naming master o RID master o PDC o infrastructure master

7. At the fsmo maintenance prompt, type quit. 8. At the ntdsutil prompt, type quit.

Note: To seize the role, repeat the steps above, using seize RoleName instead of

transfer RoleName in step 6. You cannot use a snap-in management tool to seize a role.

When you transfer a role, there might be a considerable delay as role data is transferred from one domain controller to another. When seizing a role, data loss is possible. To reduce these problems, you can designate a standby operations master. The standby operations master is configured as a direct replication partner with the primary operations master. If the primary operations master role owner needs to be taken offline, the standby operations master is as up-to-date as possible. Be aware of the following standby operations master details:

A single domain controller can be a standby operations master for multiple roles, or you can designate different standby domain controllers for each role.

Use Active Directory Sites and Services to select direct replication partners. Manually create a connection from the standby server to the master, and another connection from the master to the standby server.

Primary and standby operations master role owners should be selected on a per-domain basis.

Consider placing the standby operations master in the same site as the primary operations master for faster replication convergence consistency over a large group of computers.

Consider placing the standby operations master in a remote site in the event of a site-specific disaster at the primary location. Ensure remote site connections are configured for continuous replication over a persistent link.

Trust Facts A trust is an established relationship between different domains that allows mutual authentication,

communication, and access to resources between the domains. You should understand the following properties of trusts:

Characteristic Description

Direction of Trust

The direction of the arrow identifies the direction of trust. For example, if Domain A trusts Domain B, the arrow would point from Domain A to Domain B. Domain A is the trusting domain, and Domain B is the trusted domain. The direction can be one-way or two-way.

One-way Trust

Domain A trusts Domain B. Domain B does not trust Domain A.

Two-way Trust

Domain A trusts Domain B. Domain B trusts Domain A. Note: A two-way trust is the same as two one-way trusts in opposite directions.

Direction of Resource Access

Resource access is granted opposite of the direction of trust. For example, if Domain A trusts Domain B, users in Domain B have access to resources in Domain A (remember that users in the trusted domain have access to resources in the trusting domain).

Transitivity

Transitivity defines whether trust between domains flows or is inherited to other trusted domains.

A transitive trust allows the trust relationship to flow among domains.

Domain A trusts Domain B. Domain A trusts Domain C. Therefore, Domain B trusts Domain C.

With a non-transitive trust, trust relationships must be explicit between domains.

Domain A trusts Domain B. Domain A trusts Domain C. Domain B does not trust Domain C.

Trust Types

The following table shows the different types of trusts.

Trust Type Characteristics and Uses

Parent/child

The parent/child trust is established when a new child domain is added to an existing domain

tree. Parent/child trusts are:

Created by default

Transitive

Two-way

Authentication requests flow upward from subordinate domains through their parent to the trusting domain.

Tree root The tree root trust is a default trust type that is established when a domain tree is created in

an existing forest. Tree root trusts are:

Created by default

Transitive

Two-way

External

External trusts provide access to resources located on a Windows NT 4.0 domain or a

domain located in a separate forest that is not joined by a forest trust. External trusts are:

Created manually

Non-transitive

One-way, although you can create two one-way trusts to simulate a two-way trust

Realm

Realm trusts form a trust relationship between a non-Windows Kerberos realm and a

Windows Server 2008 domain. Realm trusts are:

Created manually

Transitive or non-transitive

Either one-way or two-way

Forest

Forest trusts share resources between forests. Forest trusts are:

Created manually

Transitive within the two forests, but non-transitive between other forests (forest A trusts forest B and forest B trusts forest C, but forests A and C don't share trust)

Either one-way or two-way

Forest trusts can only be created if both forests are at a Windows Server 2003 or higher

functional level.

Shortcut

Shortcut trusts improve user logon times between two domains within a forest by reducing

the amount of Kerberos traffic on the network caused by authentication. The shortcut trust

allows quicker response between the domains by enabling domains to pass authentication

requests directly between themselves. Shortcut trusts are:

Created manually

Transitive

Either one-way or two-way

By default, Active Directory creates two-way transitive trusts between parent and child domains in the tree or forest. These are known as Active Directory trusts or Kerberos trusts. You must manually create trusts with domains outside of the forest, or between other forests.

Trust Configuration Facts

You should know the following about configuring trusts:

Only members of the Domain Admins group or the Enterprise Admins group can manage trust relationships.

You can configure and validate a trust by using Active Directory Domains and Trusts or by using the Netdom command-line tool.

After a trust has been established, use Active Directory tools to validate the trust's connectivity, verify that it is working as designed, and ensure that communications over the trust are working.

It is possible to validate all trusts that are made between domains, but you cannot validate realm trusts.

It is possible to remove manually created trusts, but you cannot remove the default, two-way, transitive trusts between domains in a forest. When removing trusts that were created manually, it is important to verify that they are successfully removed if you are planning to re-create them.

A two-way trust is the same as two one-way trusts in opposite directions.

When creating external, shortcut, realm, or forest trusts, you have the option to create each side of the trust separately or to create both sides of a trust simultaneously.

o If you choose to create each side of the trust separately, you will need to run the New Trust Wizard twice (once for each domain) and supply the same trust password for each domain.

o If you choose to create both sides of the trust simultaneously, you will need to run the New Trust Wizard once and a strong trust password is automatically generated for you.

You should be aware of the following authentication security settings that can be applied to trusts:

Setting Description

Selective

authentication

Selective authentication is a security setting that can be enabled on trusts to provide

Active Directory administrators with more control over which groups of users in a

trusted forest can access shared resources in the trusting forest. Selective

authentication:

Allows administrators to grant access to shared resources in their organization's forest to a limited set of users in another organization's forest.

Requires each user to be explicitly granted the Allowed to Authenticate permission on the security descriptor of the computer objects (resource computers) that reside in the trusting domain or forest.

Domain-wide

authentication

The domain-wide authentication setting grants unrestricted access by all users in the

trusted domain to all available shared resources in the trusting domain. Domain-wide

authentication is the default authentication setting for external trusts.

Forest-wide

authentication

The forest-wide authentication setting grants unrestricted access by all users in the

trusted forest to all available shared resources in any of the domains in the trusting

forest. Forest-wide authentication is the default authentication setting for forest trusts.

Every time a user object moves from one domain to another, a new Security Identifier (SID) is generated and stored in the object-SID property. The old SID is stored in the SID History attribute of the Active Directory security principal. It is possible for an attacker to compromise a domain controller in a trusted domain and use the SID history attribute to associate SIDs with new user accounts, thus granting the attacker unauthorized rights. This type of attack is prevented by enabling SID filter quarantining on all external trusts created by a domain controller.

SID filter quarantining is used to: o Filter out migrated SIDs that are stored in SID history from specific domains.

o Deny one domain the right to provide credentials for another domain.

SID filters can be configured using either Active Directory Domains and Trusts or Netdom.exe.

You can enable or disable SID filtering for external trusts or forest trusts.

SID filter quarantining should not be applied to trusts within a forest that is not using the Windows Server 2003 forest functional level. Doing so removes SIDs that are required for Active Directory replication.

You should consider enabling SID filter quarantining on all existing external trusts that are created by domain controllers running Windows 2000 Server SP3 or earlier.

RODC Facts

A read-only domain controller (RODC) is an additional domain controller for a domain that hosts read-only partitions of the Active Directory database. An RODC is designed primarily to be deployed in a branch office because branch offices often have relatively few users, poor physical security, relatively poor network bandwidth to a hub site, and limited local IT resources.

The following table describes the features of RODCs.

Feature Description

Administrator

role separation

The new administrator role separation (ARS) feature allows RODCs to provide a secure

mechanism for granting non-administrative domain users the right to log on to a domain

controller without jeopardizing the security of AD DS. This allows the domain user to

perform local administrative tasks like installing drivers or security updates.

The domain user will not have any user rights for the entire domain or any other domain controllers in the domain. This is done to minimize the risk to the security of the entire domain and to prevent the domain user from accidentally modifying the Active Directory.

To initially configure the administrator role separation feature for an RODC, you must be a member of the Domain Admins group.

All local, built-in administrator accounts can also be configured through administrator role separation, including backup operators and server operators.

Unidirectional

replication

An RODC only supports unidirectional replication, meaning that it solely performs

inbound replication. The benefits of unidirectional replication are:

Writable domain controllers that are replication partners do not pull changes from the RODC.

No changes originate at the RODC because no changes are written directly by the RODC.

Any changes or corruption that a malicious user might make at branch locations cannot replicate from the RODC to the rest of the forest.

Workload reduction for bridgehead servers in the hub and the effort required to monitor replication.

Unidirectional replication causes the following limitations:

An RODC cannot act as a bridgehead server because bridgehead servers replicate changes from other sites.

RODCs cannot be a source domain controller for any other domain controller.

Read-only data

Other than account passwords, an RODC contains all of the AD DS objects and

attributes that a writeable domain controller contains. LDAP applications can be

redirected to a writeable domain controller in a hub site if changes need to be made to

Active Directory objects.

Password

replication

Password replication allows a writable domain controller to replicate user or computer

credentials to an RODC. These credentials are then cached so that the RODC can

perform authentication without contacting a writeable domain controller. To understand

how password replication and credential caching work, you should understand the

RODC authentication process, which is as follows:

1. A workstation sends a logon request to the RODC. 2. The RODC forwards the logon request to a writable Windows Server 2008

domain controller, which authenticates the request and returns the result (either positive or negative) to the RODC.

3. The RODC sends the result to the workstation. 4. The RODC asks the writable domain controller to replicate the user's credentials

to its replica of the Active Directory database. 5. The writable domain controller checks the password replication policy to see if

the RODC is permitted to cache the credentials for the user. The following occurs:

o If the user's account is on the allowed list, the writable domain controller allows replication of the account credentials to the RODC.

o At the same time that the writable domain controller sends the credentials requested by the RODC, it writes the distinguished name of the user's account to the msDS-RevealedList attribute of the RODC computer account, creating a record that the user's credentials are cached on the RODC.

6. The RODC stores the user's credentials in the appropriate attributes of the user account in the Active Directory database. The next time this user tries to log on, the RODC will not have to contact the writable domain controller because it has already cached the user account credentials. It uses the cached credentials to grant or deny authentication. Note: An RODC still performs password validation forwarding in cases when a user presents a password that does not match the credentials cached on the RODC.

If the WAN link to a writable domain controller is not available and the password for a computer account is not cached, a user in the branch office cannot log on to the computer because the workstation cannot retrieve the service ticket for that computer account. If the WAN is offline but the credentials are cached, authentication can still be granted locally.

DNS Server

service

DNS servers running Windows Server 2008 support a new type of zone on RODCs

called the primary read-only zone (or branch office zone). The primary read-only zone is

a full, read-only copy of the application directory partitions used by DNS, including the

domain partition, ForestDNSZones partition, and DomainDNSZones partition. The

primary read-only zone is created by the RODC when it is installed.

Installing DNS on an RODC allows client computers to query the RODC for

name resolution, but DNS on an RODC does not support dynamic DNS.

Name Server (NS) resource records for any Active Directory integrated zone that the RODC hosts are only referred by the RODC, they are not registered.

If a DNS client on the RODC wants to update its record (or if a new client wants to register its record), the following occurs:

o The RODC refers the client to a writeable DNS server. o The client updates the record against the writeable DNS server. o The record is replicated from the writeable DNS server to the RODC.

RODC Requirements Facts

The following requirements must be met before RODCs are installed in a domain:

The domain and forest functional level must be at the Windows Server 2003 functional level or higher. The Active Directory functional level must support:

o Linked-value replication for reduction of lost updates. This feature allows you to replicate individual values of a multi-valued attribute for a higher level of replication consistency.

o Kerberos constrained delegation. This feature allows you to forward the computer account credentials or user account credentials to all or only specific computers in the domain.

The primary domain controller (PDC) emulator must run Windows Server 2008 for the following reasons:

o A PDC emulator running Windows Server 2008 creates a special KRBTGT account for each read-only domain controller to ensure its uniqueness. This account can not be created with earlier versions of Windows Server.

o Windows 2008 allows the RODC and the PDC emulator running Windows Server to share a secure channel during communication when a password is changed against a read-only domain controller. This PDC emulator feature in Windows 2003 or earlier versions will not recognize the request and the password change action will fail.

The RODC cannot be the first domain controller in a domain. To create a new domain, install AD DS on a writable domain controller, then install the RODC.

Be aware of the following when deploying an RODC:

You can reduce Active Directory replication traffic by using RODCs because RODCs never replicate any changes.

The Windows Server 2008 writable domain controller with which the RODC replicates can run either a full installation or a Server Core installation of Windows Server 2008.

The Windows Server 2008 writable domain controller does not have to hold the Primary Domain Controller (PDC) emulator operations master role.

RODCs must replicate the domain partition from a writable domain controllers that runs Windows Server 2008 because only a writable domain controller that runs Windows Server 2008 can enforce the Password Replication Policy (PRP) for an RODC. (Note: The RODC can replicate other partitions, including application directory partitions and global catalog partitions, from any writable domain controller that runs either Windows Server 2003 or Windows Server 2008.)

Although RODCs are designed to be placed in sites that do not contain any other domain controllers, an RODC being placed in a site with another domain controller is still a supported configuration.

RODCs can only replicate updates of the domain partition from a domain controller running Windows Server 2008 from the same domain. Data can be prevented from being replicated to an RODC by setting a filter and marking it as confidential.

If an RODC was unable to satisfy a change directly, it will immediately attempt inbound replication. This happens in the following situations:

o Password changes that are created using the Security Accounts Manager (SAM) interface rather than the Lightweight Directory Access Protocol (LDAP).

o DNS updates in which a client attempted to make a DNS update, but is then referred to DNS server where the updates are registered and the RODC attempts to recover the changes.

Consider implementing drive encryption on RODCs to prevent unauthorized users from breaking Windows file and system protection in the event the RODC is lost or stolen. Tools such as Windows BitLocker encrypt all user and system files on an entire volume, including the swap and hibernation files.

Use the Windows Syskey Utility to additionally secure the RODC by moving its encryption key off the Windows-based computer. The SysKey utility can also be used to configure a start-up password that must be entered to decrypt the system key so that Windows can access the RODC.

RODC Installation Facts

Use the following general steps to install a read-only domain controller (RODC):

1. Ensure that the forest functional level is Windows Server 2003 or higher. 2. Make sure you have the PDC emulator role running on a Windows Server 2008 system. If

necessary, take the necessary steps to prepare for the installation of a Windows Server 2008 domain controller in your network (prepare the forest and the domain).

3. Copy the contents of the \sources\adprep folder on the Windows Server 2008 installation DVD to the schema master. Run the adprep /rodcprep command before you install the first RODC (you must be a member of the Enterprise Admins group to run this command). This will enable the RODC to replicate DNS partitions.

4. Create an RODC account in the Domain Controllers OU. Delegate the necessary permissions to allow non-administrative users to perform administrative tasks on the RODC as part of this step.

5. Install the Active Directory role on the RODC server. 6. Log on as a local administrator to the server that will become the RODC and run dcpromo

/UseExistingAccount:Attach. This starts the Active Directory Domain Services wizard. After you enter your administrative credentials as a step in the wizard, the wizard automatically detects the name of the server and tries to match it (attach it to) with the RODC account that you pre-created for it. Follow the steps in the wizard to complete the configuration. To install an RODC on a Server Core installation of Windows Server 2008 or Windows Server 2008 R2, perform an unattended installation using the dcpromo /Unattend <filename> command.

You should know the following about RODC installation:

To install an RODC on a full installation of Windows Server 2008 or Windows Server 2008 R2, you must be a member of the Domain Admins group.

To install an RODC on a Server Core installation of Windows Server 2008 or Windows Server 2008 R2, you must be a member of the Domain Admins group or you must have been delegated the ability to perform the installation.

Verify that the server is not joined to the domain before you start the Active Directory Domain Services wizard.

The installation source files can be replicated to the RODC from another domain controller over the network or by using the Install From Media (IFM) feature. Ntdsutil.exe can be used to create the installation media for IFM.

o Use the ntdsutil ifm command on a writable domain controller or an RODC that runs Windows Server 2008 or Windows Server 2008 R2 to create installation media for an RODC.

o Ntdsutil removes cached secrets (such as passwords) from the installation media. o Some data will be replicated over the network even if you choose to install from media.

It is possible to perform a staged installation of an RODC in which the installation is performed by two different individuals in separated stages.

The first stage: o Requires membership in the Domain Admins group. o Creates an account for the RODC in AD DS. o Records all the data about the RODC that will be stored in the distributed Active Directory

database, including the read-only domain controller account name and the site in which it will be placed.

The second stage: o Can be performed in the branch office by any user or group who was delegated the right

to complete the installation when the account was created. As such, this stage does not require any membership in built-in groups, such as the Domain Admins group, unless the user who creates the RODC account does not specify any delegate to complete the installation and administer the RODC.

o Installs AD DS on the server that will become the RODC. o Creates all AD DS data that resides locally, such as the database, log files, and so on, on

the RODC itself. o Attaches the actual server that will be the RODC in a remote location, such as a branch

office, to the account that was previously created for it.

Password Replication Policy Facts

A password replication policy determines whether or not an RODC can cache a password when the RODC receives an authenticated user or computer logon request. Password replication policies:

Must be configured on an RODC's writable domain controller replication partner when the RODC is initially deployed to allow users to be authenticated locally.

Act as Access Control Lists (ACLs) for password caching. Users whose accounts are on the list or who are members of a group on the list can have their passwords cached on the RODC.

Lists both the accounts that are permitted to be cached, and the accounts that are explicitly denied from being cached.

Make subsequent logons more efficient by allowing user and computer credentials to be cached.

Windows Server 2008 Active Directory provides two new built-in groups to support password replication.

Group Description

Allowed RODC

Password Replication

Group

This group is added to the Allowed List of each new RODC; however, by default,

it does not contain any members. The result of this is that new RODCs do not

cache user credentials.

Denied RODC

Password Replication

Group

This group is added to the Denied List of each new RODC, and by default, it

contains the following members:

Enterprise Domain Controllers

Enterprise Read-Only Domain Controllers

Group Policy Creator Owners

Domain Admins

Cert Publishers

Enterprise Admins

Schema Admins

Domain-wide krbtgt account

You should remember the following facts about password replication policies:

By default, users or groups added to the Allowed RODC Password Replication Group and Denied RODC Password Replication Group have their passwords cached or denied on all domain RODCs. You can easily allow password caching on all RODCs by adding a user or a group to the Allowed group.

To allow individual RODCs to cache user and computer credentials in specific locations, configure the Allowed and Denied Lists on the Password Replication Policy tab for the properties of each individual RODC account in the Domain Controllers OU. For example, instead of adding the users at the branch location to the Allowed RODC Password Replication Group, create a specific group for those users and add the group to the Password Replication Policy list for the appropriate RODC with the Allowed setting.

All passwords for all users and computers whose passwords are cached on an RODC should be reset if an RODC is stolen.

To allow logon when a writable domain controller is unavailable, you must cache both the user and the computer account passwords.

By default, credentials are cached only when the user or computer attempts to log on. If you want to allow logon when the writable domain controller can't be contacted, users and computers must log on at least once when the writable domain controller is available. Alternatively, you can prepopulate the RODC with the user and computer passwords. This caches the passwords for all allowed users and computers without a logon.

Because RODCs for the same domain in the same site cannot share cached credentials, having two RODCs in the same site can lead to inconsistent logon experiences for users if the WAN to the hub site is offline. Users may be allowed or denied logon depending on the RODC and where their credentials are cached.

In general, there are three administrative models to manage password replication policies:

Model Description

No accounts

cached

With the no accounts cached model, password caching is disabled, except for the RODC

computer account and its special krbtgt account.

This model provides the greatest security because no passwords are replicated to the RODC.

To allow logon, contact with a writeable domain controller is required. Because of how the RODC is typically deployed, this means that the writeable domain controller will typically be in another site, separated by a WAN link.

If the WAN link is down, users will be unable to log on. For this reason, implement this model only if the branch site is connected to the main site with reliable WAN

links.

Most

accounts

cached

With the most accounts cached model, you add users and groups to the Allowed or Denied

RODC Password Replication Groups. Password caching for all RODCs uses the same

configuration.

This model poses some security risk because passwords are replicated to the RODCs, so it is most appropriate when the physical security of the RODCs is not in question.

Password management is facilitated because most users can have their passwords cached on demand.

Users can have offline access through this model.

Few

accounts

cached

With the few accounts cached model you manually configure password caching on each

RODC based on the users within a site. Caching on each RODC is allowed only for users

within the site.

This model provides the benefit of ensuring security of passwords by restricting the number of passwords replicated to the RODC and enabling offline access for users whose passwords are cached.

The administrative overhead of this model is greater because administrators must manually add users (or preferably groups) to the Allowed List.

When managing RODC password replication with Windows PowerShell, be aware of the following cmdlets found in the Active Directory module:

Add-ADDomainControllerPasswordReplicationPolicy adds users, computers, and groups to the Allowed List or the Denied List of the RODC Password Replication Policy (PRP).

Get-ADDomainControllerPasswordReplicationPolicy displays the members of the Allowed List or the Denied List of the RODC PRP.

Remove-ADDomainControllerPasswordReplicationPolicy removes users, computers, and groups from the Allowed List or the Denied List of the RODC PRP.

Get-ADDomainControllerPasswordReplicationPolicyUsage displays the resultant password policy of the specified ADAccount on the specified RODC.

Get-ADAccountResultantPasswordReplicationPolicy displays the resultant password replication policy for an Active Directory account.

RODC Security Facts

In addition to managing password replication on a read-only domain controller (RODC), you can implement the following to increase the security of a RODC.

Consideration Description

Administrator

role separation

Use administrator role separation on an RODC to allow a user to manage the physical computer without granting permissions to Active Directory. With administrative role separation, you can grant non-administrative domain users the right to log on to a RODC, allowing them to perform local administrative tasks such as installing drivers or

security updates.

Configuring Administrator Role Separation requires you to be a member of the Domain Admins group. You can configure role separation using one of the following methods:

When you create the RODC account, specify the user or group who can manage the RODC.

Edit the RODC account and modify the setting on the Managed By tab.

From the command prompt on the RODC, 1. Run the dsmgmt.exe command. 2. Enter local roles. (You can list valid parameters at this point by

entering ?.) 3. Enter add <domain>\<user> <administrative role>.

BitLocker

A common use for a RODC is in a branch office. If the physical security in a branch

office is insufficient, the RODC could be vulnerable to tampering or theft, meaning that

an attacker might gain access to the Active Directory database saved on the server's

hard drive. To protect the data from theft, you can implement BitLocker on the hard

drive. BitLocker:

Encrypts the entire contents of the operating system partition, including operating system files, swap files, hibernation files, and all user files. A special BitLocker key is required to access the contents of the encrypted volume.

Uses integrity checking early in the boot process to ensure that the drive contents have not been altered, and that the drive is in the original computer. If any problems are found, the system will not boot, and the drive contents remain encrypted. The integrity check prevents hackers from moving the hard disk to another system in order to try to gain access to its contents.

Is not installed with Windows Server 2008 R2. o Use the Windows Server 2008 R2 Server Manager page to install

BitLocker. You must restart after installing BitLocker on a server. o Use Windows Management Instrumentation (WMI) to enable BitLocker

remotely.

You can configure Group Policy to generate recovery passwords automatically and back them up to AD DS as soon as BitLocker is enabled. The domain administrator can also choose to prevent BitLocker from encrypting a drive unless the computer is connected to the network and the AD DS backup of the recovery password is successful. You can use the Active Directory Recovery Password Viewer tool that helps you locate and view BitLocker recovery passwords that are stored in AD DS. Use the Active Directory Recovery Password Viewer tool to:

Examine a computer object's Properties dialog box to view the corresponding BitLocker recovery passwords.

Search for a BitLocker recovery password across all the domains in the Active Directory forest (within a domain container).

Note: To view recovery passwords, you must be a domain administrator, or you must have been delegated permissions by a domain administrator.

Read-only

SYSVOL The Active Directory database is stored in the SYSVOL folder on the domain controller.

During replication, changes made to writeable domain controllers is replicated to the

SYSVOL folder on the RODC, keeping the RODC synchronized with the writeable

domain controllers. SYSVOL contents can be replicated using one of two methods:

File Replication Service (FRS)

Distributed File System Replication (DFSR or DFS replication)

Depending on the configuration, it is possible to make changes to the SYSVOL folder on a read-only domain controller.

If FRS is used for replication, files can be manually added or deleted within the SYSVOL folder. Changes on the RODC are not replicated to other domain controllers, but changes are not overwritten either, meaning that the SYSVOL folder on the RODC might be inconsistent compared to the writeable domain controllers.

If DFSR is used for replication and the operating system is Windows Server 2008 (prior to R2), changes can be manually made to the SYSVOL folder. During replication, any changes are discarded (added files are removed and deleted files are added).

If DFSR is used for replication and the operating system is Windows Server 2008 R2, attempts to change the SYSVOL folder are blocked. With Windows Server 2008 R2, the SYSVOL folder is a read-only replicated folder, meaning that the only way the SYSVOL folder can be changed is through replication (manual changes are prevented).

For best security of the SYSVOL contents, run all RODCs on Windows Server 2008 R2 in domains with the Windows Server 2008 functional level. Be aware of the following conditions that affect SYSVOL replication:

If the domain function level is Windows Server 2003 or lower, FRS replication will be used.

When you create a new domain at the Windows Server 2008 functional level, DFSR will be used automatically.

If the domain functional level is Windows Server 2003 or lower, to take advantage of DFS replication:

1. Upgrade all domain controllers to Windows Server 2008. 2. Raise the domain functional level to Windows Server 2008. 3. Use the Dfsrmig utility to migrate SYSVOL replication from FRS to

DFSR.

RODC Removal Facts

If the security of a RODC has been compromised, for example if the system has been hacked or stolen, it is possible that passwords cached on the RODC could be retrieved. To protect user passwords in the event of a security breach, delete the RODC computer account in Active Directory. When you delete the computer account, you are given the following choices:

Reset user account passwords cached on the RODC. When this option is chosen, the following process must be followed to re-allow user logon:

1. An administrator must manually reset the password to a known value. A common practice is to require the user to change the password at the next logon.

2. The new password must be given to the user. Following logon, users change the password to a value they choose.

Reset computer account passwords cached on the RODC. This option disjoins the computer from the domain. Computers must be rejoined to the domain.

Export a list of accounts that were cached on the RODC. Using the file, you can get a list of accounts whose passwords were cached. You would then need to manually reset the passwords on those accounts or rejoin the domain for computer accounts.

Group Policy Facts

A policy is a set of configuration settings that must be applied to users or computers. Collections of policy settings are stored in a Group Policy object (GPO). The GPO is a collection of settings that includes registry settings, scripts, templates, and software-specific configuration values.

Each GPO has a common structure, with hundreds of configuration settings that can be enabled and configured. Settings are divided into two categories:

GPO Category Description

Computer

Configuration

Computer policies (also called machine policies) are enforced for the entire

computer. Computer policies include:

Software that should be installed on a specific computer

Scripts that should run at startup or shutdown

Password restrictions that must be met for all user accounts

Network communication security settings

Registry settings that apply to the computer (the HKEY_LOCAL_MACHINE subtree)

Computer policies are initially applied as the computer boots, and are enforced before any user logs on.

User Configuration

User policies are enforced for specific users. User policy settings include:

Software that should be installed for a specific user

Scripts that should run at logon or logoff

Internet Explorer user settings (such as favorites and security settings)

Registry settings that apply to the current user (the HKEY_CURRENT_USER subtree)

User policies are initially applied as the user logs on, and often customize Windows based on user preferences.

Windows Server 2008 offers the Group Policy functionality enhancements described in the table below.

Feature Description

ADMX and

ADML files

The XML-based file format allows multilanguage support and version control. This

means that Group Policy tools are displayed in the administrator's operating system

language and facilitates either automated or manual change management processes.

Administrators also have the option of storing all the ADMX files in a central location: a domain-wide directory created in the Sysvol. This reduces replication traffic as the number of GPOs grows, and it reduces the need for additional storage associated with large numbers of decentralized GPOs.

Network

Location

Awareness

Network Location Awareness allows clients to be aware of and respond to changing

network conditions. With Network Location Awareness, Group Policy uses the operating

system's resource detection and event notification capabilities, such as recover from

hibernation and standby, moving in and out of a wireless network, or a new VPN

connection. As an example of the latter event, Group Policy can detect when a mobile

user connects to a corporate network and detect the availability of a domain controller.

Group Policy can initiate a background refresh over the VPN connection to update user

and computer policy.

Group Policy

preferences

Group Policy preference extensions are several (more than 20) Group Policy extensions

that expand the range of configurable settings in a GPO. Preference settings differ from

policy settings in that preference settings are not enforced, allowing the end user to

change any preference setting applied through a GPO. The end user cannot, however,

change policy settings. Preference items should work as supplements to your policy

settings.

You should know the following Group Policy facts:

A local GPO is stored on a local machine. It can be used to define settings even if the computer is not connected to a network.

Group Policy objects created in Active Directory are linked to Active Directory sites, domains, or organizational units (OUs). Built-in containers (such as the Computers container) cannot have GPOs linked to them.

GPOs contain hundreds of configuration settings that can be configured.

Settings within a GPO in Active Directory apply to the users and computers beneath the object to which the GPO is linked. Through inheritance, the settings apply to users and computers in all child OUs beneath the object where the GPO is linked.

Group policy settings take precedence over user profile settings. Group policy settings in Active Directory take precedence over settings in the local GPO.

Administrative Templates and Starter GPO Facts

Administrative Templates are registry-based settings that you can configure within a Group Policy object.

Possible registry settings that can be configured are identified by ADM files. The ADM file contains the registry setting and any user-interface information required to make editing the setting within a GPO possible.

The operating system includes a default set of ADM files, with each file containing related registry settings. For example, the system.adm file contains operating system settings, and the inetres.adm file contains Internet Explorer settings.

Developers can create custom ADM files to enable configuring registry settings for custom applications through Group Policy.

Prior to Windows Vista/2008, to use Administrative Templates that were not included within the default ADM files, you were required to load the ADM file into the Group Policy object.

o After you load the ADM file in the GPO, a copy of the ADM file is saved on the SYSVOL folder.

o When you reopen the GPO, the saved ADM file is reloaded into the GPO editor. o Because the template file is replicated along with the GPO, when you edit the GPO on

another computer, the ADM file you loaded will be available to enable editing the GPO. o For each new GPO that you create, you must load any non-default ADM files.

ADM files work differently with Windows Vista/2008: o The older ADM file format has been replaced with the following formats:

.admx files are language-neutral files that store settings in XML format. .adml files are a set of language-dependent files that provide localized

information when viewing template settings in the GPO. Each .adml file represents a single language you wish to support.

o Instead of saving ADM files as a part of the GPO, ADMX files are saved on the local computer in the %systemroot%\PolicyDefinitions folder. This change decreases the size of each Group Policy object, and eliminates the need to add ADM files to each new GPO you create.

o Instead of saving .admx and .adml files on the local system, you can create a central storage location on the domain controller for these files.

Copy the necessary files to the SYSVOL\domain_name\Policies\PolicyDefinitions folder.

Only files that use the new format (.admx) can be saved in the new storage location.

Any new ADM file you add to the storage location is available immediately within any new GPO.

o Because of the change in the way ADM files are managed, you can only edit GPOs that use .admx files on Windows Vista or Windows Server 2008 systems.

In Windows Server 2008 and Windows Server 2008 R2, you can use starter GPOs to simplify management of Administrative Templates settings.

The starter GPO is a template that contains settings for the Administrative Templates portion of a Group Policy object. Software distribution and security settings are not contained in a starter GPO.

Starter GPOs are created in the Group Policy Management editor within the Starter GPO node.

To use a starter GPO: 1. Create the starter GPO. 2. Edit the starter GPO settings. 3. When you create a new GPO, specify the starter GPO to use. Administrative Template

settings in the starter GPO are copied into the new GPO.

Use permissions on the starter GPO to identify which administrators can modify the starter GPO settings.

Starter GPOs can be backed up and restored. o You can back up specific starter GPOs, or back up all starter GPOs as a group. o Starter GPOs must be backed up separately from GPOs. o Starter GPOs can only be restored to their original domain.

Save a starter GPO to save it as a file, such as when you want to import it into another domain. o Import the starter GPO to add a saved starter GPO to the domain. o Starter GPOs are saved as .cab files.

In Windows Server 2008 R2, eight starter GPOs, known as System Starter GPOs, are included by default. System Starter GPOs are read-only Starter GPOs that provide a baseline of settings for specific scenarios described in either the Windows Vista Security Guide or the Windows XP Security Guide. The baseline includes computer and user Group Policy settings that are recommended for:

o Windows Vista Enterprise Client (EC) and Windows Vista Specialized Security – Limited Functionality (SSLF) client environments.

o Windows XP SP2 Enterprise Client (EC) and Windows XP SP2 Specialized Security – Limited Functionality (SSLF) client environments.

Use the New-GPStarterGPO PowerShell cmdlet to create a Starter GPO with the specified name. Note: You must use the import-module grouppolicy command to import the Group Policy module before you use the Group Policy cmdlets.

Preferences Facts

Group Policy preferences allow you to configure, deploy, and manage operating system and application settings that you cannot manage using Group Policy settings. Group Policy preferences include the ability to configure mapped drives, scheduled tasks, and Start menu settings.

The table below compares Group Policy preferences to Group Policy settings.

Group Policy Preferences Group Policy Settings

Characteristics of Group Policy preferences include:

Preferences are not enforced

The user interface is not disabled

Preferences can be applied once or refreshed periodically

You can easily create preference items for registry settings, files, and environment settings

You can import individual registry settings or entire registry branches from a local or a remote computer

Preferences are not available in local Group Policy

Preferences support non-Group Policy-aware applications

Removing the preference item does not restore the original setting

Targeting is granular, with a user interface for each type of targeting item

Preferences provide a familiar, easy-to-use interface for configuring most settings

Characteristics of Group Policy settings include:

Settings are enforced

The user interface is disabled

Settings are refreshed periodically

You cannot create policy settings to manage objects such as files or folders

Policy settings are available in local Group Policy

Policies require Group Policy-aware applications

Removing the policy setting restores the original settings

Supports filtering at a GPO level

Filtering is based on Windows Management Instrumentation (WMI) and requires writing WMI queries

Provides an alternative user interface for most policy settings

You should know the following facts about Group Policy preferences:

The primary difference between Group Policy preferences and Group Policy settings is that preferences are applied but not enforced (users can change settings applied through preferences). Group Policy preferences do not cause the application or operating system feature to disable the user interface for the settings they configure.

Group Policy writes preferences to the locations in the registry where the application or operating system stores the setting.

Group Policy preferences support applications and operating system features that are not Group Policy-aware.

If you choose to apply Group Policy preferences only once (rather than refresh them regularly), users can customize the preference permanently on their individual machines.

You can use the Set-GPPrefRegistryValue Windows PowerShell cmdlet to configure Group Policy preferences. Note: You must use the import-module grouppolicy command to import the Group Policy module before you use Windows PowerShell to manage Group Policy preferences.

To apply Group Policy preferences, the client must have the client-side extensions (CSEs) installed. Client-side extensions are built in to Windows 7 and Windows Server 2008 R2, but must be manually installed for previous generations of Windows clients.

The following table provides an explanation to each Group Policy preference:

Preference Description

Drive maps Manages network drive mappings without writing logon scripts.

Environment Manages user and system environment variables or updates the environment path.

Files

Folders

Manages files or folders, such as copying configuration files to users' profile folders, or

regularly cleaning up temporary folders.

Ini Files Modifies and updates individual properties within a .ini file.

Network shares

Manages network shares on multiple, targeted computers. Additionally, it prevents

users from seeing subfolders for which they lack permission to access, and configures

user limits.

Registry Manages registry entries, without the need to write scripts.

Shortcuts Manages several types of shortcuts on multiple, targeted users and computers.

Devices Enables or disables devices based on a device class identifier.

Folder options Configures folder options and file extension associations.

Internet settings Configures Internet Explorer options for Windows Internet Explorer.

Local users and

groups Manages local users and groups.

Network

connections Configures VPN and dial-up connections.

Power options Configures power options and power schemes for computers.

Printers Manages shared printers, TCP/IP printers, and local printers.

Regional options Configures the user locale, including number, currency, time, and date formats.

Scheduled tasks Manages scheduled tasks on targeted users and computers.

Services

Configures services to:

Run automatically

Start if required

Disable and stop if necessary

Start menu Configures Start menu options for users.

GPO Management Facts

Be aware of the following as you manage Group Policy objects:

Group Policy objects are linked to sites, domains, and organizational units (OUs). o Settings in a GPO apply to all objects beneath the linked object. For example, settings in

a GPO linked to the domain apply to all objects in the domain. Settings in a GPO linked to an OU apply to all objects inside the OU.

o A single GPO can be linked to multiple objects. For example, you can link a GPO to two (or more) OUs.

o A single object can have multiple GPOs linked to it. For example, you can link two (or more) GPOs to the same OU.

You can disable a GPO link to prevent the settings from being applied to the linked object. Disabling the GPO link only prevents the settings from being applied to that object, and does not affect other objects to which the GPO is linked. For example, if a GPO were linked to the Accounting and Sales OUs, disabling the link to the Sales OU prevents the settings from applying to that OU. Settings would still apply to the Accounting OU.

Deleting a GPO removes the GPO and removes all links. Deleting a GPO link removes the GPO from the linked object, but does not delete the GPO nor affect other GPO links.

Within a GPO, you can enable or disable the user and/or computer settings. Disabling part of the settings prevents those settings from being applied to all linked objects. Disabling the user or computer settings speeds GPO processing because the system does not need to check or apply settings in half of the GPO.

Use the Group Policy Management Console (GPMC) or Active Directory Module for Windows PowerShell to manage GPOs and GPO links.

When you configure specific GPO settings, be aware of the following:

A GPO setting can be: o Undefined, meaning that the GPO has no value for that setting and does not change the

current setting. o Defined, meaning that the GPO identifies a new value to enforce.

To configure a setting to be enforced through a GPO, define the GPO, then configure the setting within the GPO.

Some GPO settings simply enable or disable the setting. Others might identify users or groups with the specified right, or allow you to configure additional settings.

When configuring GPO settings, pay attention to the effect of the setting. In particular, make sure you understand how negatively-worded settings will be applied. For example, if the setting removes the Control Panel from the desktop:

o If you do not define the setting, the setting will not be enforced. Whether the Control Panel is available or not will depend on what other settings might affect the system.

o If you define the setting, you must enable or disable it. Enabling the setting takes the action specified in the setting name; in this

example, the Control Panel will be removed. Disabling the setting prevents the action from taking effect; in this example, the

Control Panel will not be removed.

To configure GPO settings, within the Group Policy Management Console, edit the GPO. This opens the Group Policy Management Editor (GPME).

To view settings defined within a GPO without editing it and browsing for settings, use the report feature in the GPMC. You can save the report to document the GPO settings.

Windows refreshes (or recalculates) the effective Group Policy settings at the following intervals:

Computer policies are recalculated each time the computer boots.

User policies are recalculated each time a user logs on.

Both user and computer policies are periodically refreshed as long as the computer is running. o By default, domain member computers refresh every 90 minutes. Domain controllers

refresh every 5 minutes. o You can use Group Policy to turn off periodic refresh or modify the refresh interval. o To prevent a group of computers from refreshing at the same time, Group Policy uses a

random refresh offset (between 0 to 30 minutes). After startup, Windows waits for this random offset before refreshing.

To manually refresh group policy settings, use the Gpupdate command with the following switches:

Switch Function

No switch Refresh user and computer-related settings.

/force Ignore optimization processing and refresh both user and computer settings

immediately.

/target:user Refresh user-related group policy.

/target:computer Refresh computer-related group policy.

/boot

/logoff

A few policies (such as software installation or folder redirection) are only refreshed

during startup or logon. Use the /boot switch to reboot after refreshing. Use the /logoff

switch to log off and back on again after refreshing.

If you have a GPO with certain settings that you would like to use to create another GPO with the same settings, use the following methods:

Method Description

Copy

When you copy a GPO, a new GPO is created with the same settings.

You can copy a GPO with the same domain, to another domain within the same forest, or to a domain in a different forest.

To copy GPOs to other domains, add the target domain to the Group Policy Management Console.

When copying GPOs to domains in other forests, the source forest must have a trust with the destination forest, or you must be able to log on to the target domain using the Stored User Names and Passwords utility.

When you copy the GPO, you have the option of copying the discretionary access list (DACL) for the GPO to the target GPO.

Backup

and Import

When you back up a GPO, all GPO settings are saved to a file.

You can back up multiple GPOs at the same time into the same backup file.

To migrate GPOs from one domain to another 1. Back up all desired GPOs. 2. Copy the backup file to a computer in the target domain. 3. Create new GPOs in the target domain. 4. For each GPO, import the settings, choosing the specific GPO from the

backup. Do not restore the GPO from the backup.

Using backup and import to migrate GPOs does not copy the DACL for the GPO. You will have to manually configure GPO permissions.

Starter

GPO

Starter GPOs contain settings for the Administrative Templates portion of a Group Policy

object. You can define standard Administrative Templates settings in the starter GPO, then

use the starter GPO when creating a new GPO.

You can copy an existing starter GPO to create a new one.

To move a starter GPO to another domain, export the starter GPO as a .cab file, then import it in the other domain. You cannot use the backup feature to move a starter GPO to another domain.

Note: When moving GPOs from one domain to another, some settings are domain-specific and cannot be copied directly. If you do nothing, these settings will not be migrated. To migrate domain-specific settings, configure a migration table to map settings in one domain to similar settings in the target domain.

Use the cmdlets in the Group Policy module for Windows PowerShell to manage domain-based GPOs. The Group Policy cmdlets:

Maintain GPOs, including GPO creation, removal, backup, reporting, and import.

Associate GPOs with Active Directory Directory Services (AD DS) containers, including Group Policy link creation, update, and removal.

You must use the import-module grouppolicy command to import the Group Policy module before you use the Group Policy cmdlets. Common GPO management cmdlets include:

Cmdlet Description

New-GPO

Creates a new GPO with a specified name.

By default, the newly created GPO is not linked to a site, domain, or organizational unit (OU).

Use the -StarterGpoName parameter to create a GPO that is based on a starter GPO.

Copy-GPO Creates a GPO and copies the settings from the source GPO to the new GPO.

Get-GPO Returns one or all objects that represent the requested GPOs.

Backup-GPO Backs up a specified GPO or all the GPOs in a domain to a backup directory. The

backup directory and GPO must already exist.

Remove-GPO Removes the GPO container and data from the directory service and the system volume

folder (SYSVOL).

Rename-GPO Assigns a different, non-null display name to a GPO. This cmdlet has no effect on the

GUID of the GPO.

Restore-GPO

Restores a GPO backup to the original domain from which it was saved. If the original

domain is not available, or if the GPO no longer exists in the domain, the cmdlet fails.

You can:

Use the Guid parameter or the Name parameter to restore a GPO from its most recent backup.

Use the All parameter to restore all GPOs in the domain from their most recent backups.

Use the BackupId parameter to restore a GPO from a specific backup. This parameter enables you to restore a GPO from a backup prior to the most recent one.

Import-GPO

Imports the settings from a GPO backup into a specified target GPO.

The target GPO can be in a different domain or forest than that from which the backup was made and it does not have to exist prior to the operation.

Use the CreateIfNeeded parameter to specify that a new GPO is created from the backup if the specified target GPO does not exist.

New-GPLink

Links a GPO to a site, domain, or OU.

By default, the link is enabled.

To specify a domain to link to, use the Target parameter.

Set-GPLink Sets the properties of a GPO link. You can set the following properties:

LinkEnabled applies the settings of the GPO for the site, domain or OU.

Enforced configures the GPO so it cannot be blocked at a lower-level (in the Group Policy processing hierarchy) container.

Order specifies the precedence that the settings of the GPO take over conflicting settings in other GPOs that are linked (and enabled) to the same site, domain, or OU.

Remove-

GPLink

Deletes the link between a GPO and a specified site, domain, or OU. This cmdlet does

not delete the actual GPO or any other links between the specified GPO and other sites,

domains, or OUs.

New-

GPStarterGPO Creates a Starter GPO with the specified name.

Security Settings Facts

The following table describes common GPO security setting categories:

Security Setting

Category Description

Account Policies

Use Account Policies to control the following:

Password settings

Account lockout settings

Kerberos settings

Note: Account policies are only in effect when configured in a GPO linked to a

domain.

Local Policies/Audit

Policy

Use Audit Policy settings to configure auditing for event classes (such as logon,

account management, or privilege use).

Local Policies/User

Rights Assignment

User rights determine what actions a user can perform on a computer or domain.

User rights settings identify users or groups with the corresponding privilege.

Examples of user rights include:

Access this computer from the network (the ability to access resources on the computer through a network connection)

Allow log on locally (the ability to log on to the computer console)

Allow log on through Terminal Services (the ability to log on using a Remote Desktop connection)

Back up files and directories (does not include restoring files and directories)

Shut down the system

Remove a computer from a docking station

Local

Policies/Security

Options

Unlike user rights, security options are either enabled or disabled for everyone.

Examples of Security Options policies include:

Computer shut down when Security event log reaches capacity

Unsigned driver installation

Ctrl+Alt+Del required for log on

Event Log

Use Event Log settings to configure Application, Security, and System event logs.

Using these policies you can define:

Who can access the logs.

The maximum file size.

Log retention (i.e., the minimum number of days to keep logs or when events are overwritten or deleted).

Restricted Groups

Use Restricted Groups to limit the membership of specific security groups. You can

set two properties for groups:

Members designates who does and does not belong to the group.

Members Of designates other groups to which the group belongs.

System Services Use System Services to configure the startup type and authorization for the system

services.

Registry

Use Registry policies to configure specific registry keys and values and configure

permissions on the registry settings. For example, you can configure permissions

that allow specific users to read the registry value, set (change) the value, list

subkeys, or modify key permissions.

File System

Use File System policies to configure file and folder permissions that apply to

multiple computers. For example, you can limit access to specific files that appear

on all client computers.

Wireless Network

Use Wireless Network policies to configure the following for your wireless network:

Protection from unauthorized access by users with compatible WLAN adapters.

Protection for wireless network data transfers (based on Group Policy settings).

Use Group Policy to configure certificate-based or password-based authentication client authentication.

Public Key Policies

Use Public Key Policies to:

Enable automatic certificate enrollment.

Manage data recovery agents (DRAs).

Create certificate trust lists (CTLs).

Automatically establish trust relationships with CAs.

Software Restriction

Policies

Use Software Restriction Policies to control which software can run on domain

computers. You can use software restrictions to:

Identify allowed or blocked software.

Allow users to run only the files you specify on multi-user computers.

Determine who can add trusted publishers.

Apply restrictions to specific users or all users.

GPO Application Methods Facts

Through Group Policy inheritance, settings in a GPO are applied to all objects below the container where the GPO is linked. Be aware of the following facts about GPO inheritance:

GPOs are applied in the following order: 1. The Local Group Policy on the computer 2. GPOs linked to the site where the user's computer is located 3. GPOs linked to the domain that contains the user or computer object 4. GPOs linked to the organizational unit(s) that contain(s) the user or computer object

(from the highest-level OU to the lowest-level OU).

The effective GPO settings for any object are the total settings of all GPOs linked to all parent objects.

Individual settings within all GPOs are combined to form the effective Group Policy setting as follows:

o If a setting is defined in one GPO and undefined in another, the setting will be enforced (regardless of the position of the GPO in the application order).

o If a setting is configured in two GPOs, the setting in the last-applied GPO will be used.

If a single object (site, domain, or OU) has multiple linked GPOs, they are applied in the reverse order that they are listed (the GPO at the top takes precedence).

Use the following methods to customize how GPO settings are applied:

Method Description

Block

Inheritance

When you block inheritance, you prevent settings in GPOs linked to parent objects from being applied to child objects.

You configure inheritance blocking on the domain or an organizational unit (OU).

You cannot block inheritance on a per-GPO basis; blocking inheritance blocks all GPOs linked above the blocking object.

To prevent inheritance from being blocked for a specific GPO, select the Enforced option for the GPO link.

GPO

Permissions

Group Policy permissions control the operations that users can perform on the Group

Policy object.

For settings in a GPO to apply to a user, the user must have the Allow Read and Apply Group Policy permissions.

By default, each GPO you create grants the Authenticated Users group (basically all network users) the Allow Read and Apply Group Policy permissions. This means that by default, GPO settings apply to all users.

You can selectively control which users or groups get GPO settings by modifying the permissions:

o To prevent settings from applying to specific users, add the users or groups to the access control list and Deny the Read and Apply Group Policy permissions.

o To configure the GPO to apply only to specific group members, remove the Authenticated Users group from the access control list, then add the specific objects and grant the Allow Read and Apply Group Policy permissions.

Permissions also control who can edit Group Policy settings or manage the GPO.

WMI Filtering

WMI filters allow you to determine the scope of a GPO dynamically based on the attributes

of the target computer. When a GPO that is linked to a WMI filter is applied on the target

computer, the filter is analyzed on the target computer. If the filter evaluates to true, the

GPO is applied.

WMI filters consist of one or more queries based on data such as the following: o Hardware and software inventory o CPU o Memory o Disk space o Manufacturer o Registry data o Drivers o File system o Active Directory o Windows Installer service o Network configuration o Application data

WMI queries are written in WMI query language (WQL).

WMI filters should be applied for a well-defined purpose and limited amount of time.

WMI filters evaluate on the target computer every time a Group Policy refresh occurs.

Loopback Processing

By default, Group Policy configuration applies computer settings during startup and user

settings during logon. For this reason, user settings take precedence in the event of a

conflict. With loopback processing, computer settings are reapplied after user logon.

Following are some circumstances when you might use loopback processing:

If you want computer settings to take precedence over user settings.

If you want to prevent user settings from being applied.

If you want to apply user settings for the computer, regardless of the location of the user account in Active Directory.

Loopback processing runs in Merge or Replace mode.

Merge mode gathers the Computer Configuration GPOs and appends them to the

User Configuration GPOs when the user logs on.

Replace mode prevents the User Configuration GPOs from being applied.

Software Distribution Facts

The table below describes the steps in the software deployment lifecycle.

Step Description

Plan

Before creating a software distribution GPO:

Obtain the Windows installer package file for the application. Installer files are special installation files with a .msi extension. You can also use .zap files to point to a regular installation executable file (such as Setup.exe).

Copy the installer file to a software distribution point. The distribution point should be a network share. Make sure users have Read and Execute permissions to the installer file.

Deploy

To deploy software, you either assign it or publish it to either users or computers.

Assigned software is installed automatically when the user tries to run the program or when a document that is associated with the software is opened.

o Software can be assigned to computers or users. o Software assigned to users can also be installed automatically at logon.

Published software is made available for installation by adding it to Add/Remove Programs.

o Users must start the installation process. o Applications may be published to users, but not to computers.

Manage

(Upgrade)

After software has been deployed, you might need to update software as new releases and

service packs come out. You can update software in the following ways:

Create a new installation package with the software update files. When configuring the package, choose the Required upgrade for existing packages option. This forces the update to be installed.

Repackage the existing installation files. With slipstreaming, you run a program that adds the updates to the existing installation files and repackages the .msi file with the updates. Use the Redeploy application option to redeploy the existing package that includes the updates.

Remove

When you wish to remove a software application, you can choose the following options.

Select Immediately uninstall the software from users and computers to uninstall the software the next time the computer boots or the user logs on.

Choose Allow users to continue to use the software, but prevent new installations to prevent new installations, but to allow users to continue to use the software if it is already installed.

Choose Uninstall this application when it falls out of the scope of management

to automatically remove software when the GPO no longer applies to the user or the computer. For example, when this option is enabled for a computer, the software will be uninstalled automatically if the computer is moved to an OU where the GPO does not apply.

As you manage software distribution, be aware of the following:

When you create the package, use the UNC path to the installer file (\\servername\sharename\filename). Alternatively, you can browse to a mapped network drive and Windows will replace the mapped drive with the UNC path. Do not use the local path to the file; if you do, the installer file must exist on all client computers.

To change the distribution path for a policy, you must delete and re-create the software distribution policy.

The following table compares the configuration options you have for assigning or publishing software for both users and computers.

Feature Assign to

computers

Assign to

users

Publish to

users

Install automatically with file extension

activation Yes Yes Optional

Install automatically at logon No Optional No

Install or uninstall through Add/Remove

Programs No Optional Optional

Uninstall when out of the scope of

management Optional Optional Optional

Add/Remove Programs categories Optional Optional Optional

Use for upgrading existing installations Optional Optional Optional

Users can uninstall user-assigned applications. However, the application remains on the Start menu and will be reinstalled automatically when needed. Users cannot use Add/Remove Programs to remove computer assigned software.

Some Group Policy settings, such as user profiles or software installation packages, potentially involve large amounts of data. For example, a software installation package might require downloading the installer file that can be several megabytes in size. When the computer is separated from the software distribution point by a slow WAN link, this can negatively affect computer boot or user logon times. Group Policy includes a slow WAN link detection feature that can optimize startup times for Group Policy settings that involve large file sizes.

By default, Group Policy always checks the link speed. If the speed is determined to be slow, certain parts of the GPO are not applied. The settings that are not applied for slow links are: software installation, user profiles, scripts, and disk quotas.

By default, a link speed at or below 500 Kbps is considered slow. If the link speed is at or below this value, software installation policies will not be applied.

To modify the default value used to identify a slow link, edit the Group Policy slow link detection setting in Group Policy for either users or computers.

o For example, setting this value to 1024 means that software installation will not occur if the link is at or below 1024 Kbps.

o Set this value to 0 to disable slow link detection (i.e. to apply all policy settings regardless of the link speed).

You can configure specific setting types to be applied to computers even when a slow link is detected. Group Policy includes policy settings for various components such as disk quotas, software installation, and folder redirection. Enable the corresponding policy and select Allow processing across a slow network connection. Taking this action applies the policy setting, ignoring the link speed.

Instead of modifying the slow link detection settings, a better solution is to put a domain controller in each location so that clients always have a high-speed connection to the domain controller.

Software Restriction Policies Facts

Software restriction policies restrict the execution of specific applications, installation files, scripts, and Dynamic-Link Library (DLL) files. Software restriction policies are managed through Group Policy, and are applied in a particular order, with the more explicit rules overriding the more general rule types. The following table describes the application restriction rules (listed from more specific to least specific):

Rule Type Description

Hash

A hash rule uses a digital fingerprint or hash value of a file based on its content.

Hash rules are manually created on a per-file and version basis (i.e., the hash value of the calculator program in Windows XP is different than in Windows 7).

The hash value of the file will be the same, regardless of the file name or file location.

A Windows update or software update could change the hash, forcing you to manually recreate the hash value.

Certificate

A certificate rule uses a publisher's digital certificate to identify the application.

Certificate rules allow multiple applications to be the target of a single certificate rule, if all the applications are using the same certificate.

Before you can create a certificate rule, you must obtain the certificate of the application vendor.

Each time an application is executed, the rule checks the certificate's validity.

The rule cannot specify different restrictions for multiple applications from the same vendor. The rule restricts or allows all of the applications from a single vendor/certificate.

Path

A path rule specifies a file, folder, or registry key as the target of the restriction policy.

Wild cards may be used in path rules.

With path rules, the more specific rule takes precedence. For example, if you create an unrestricted rule for a specific executable, but then restrict applications from running in the same folder as the executable, then the specific executable permission takes precedence.

If a restricted application is renamed to match an unrestricted application that has a path rule, the application will run because the rule looks at the file's name, instead of the file's content.

Network

Zone

A network zone rule applies to the Microsoft Installer Package (MSI) obtained or downloaded

using Internet Explorer (IE).

Network zone rules allow an MSI installer to run based on the Web site from which it was downloaded.

The zones that can be used are the zones defined in Internet Explorer such as the internet zone or restricted sites zone.

Network zone rules do not apply to executable files.

Default

The default rule applies when no other software restriction policy matches that application.

The Security Levels node sets the default rule, which may be one of the following:

The disallowed rule prevents an application from executing if the application is not allowed by any rule in software restriction policies.

The basic user rule allows applications to execute that do not require administrative access rights.

The unrestricted rule allows all applications to execute, unless there is a restricted rule for the application. Note: This is the default when enabling software restrictions.

Be aware of the following:

Software restriction polices can be applied to the following: o Windows XP o Windows Vista o Windows 7 o Windows Server 2003 o Windows Server 2008 o Windows Server 2008 R2

If two conflicting rules are being applied to the same program, the more specific rule takes precedence.

Enforcement policies options include the following: o Restrictions to all software o Restrictions to all software except DLL's o Restrictions to all users o Restrictions to all users except members of the Local Administrators group

Enabling certificate rules will add unnecessary performance overhead, and should not be enabled if you are not using them.

Specific extensions are configured as an executable, and may be changed if necessary; however, standard executable extensions (i.e., .com and .exe) cannot be removed.

AppLocker Facts

AppLocker policies (also known as application control policies) are similar to Software Restriction Policies, but have the following advantages:

Polices are applied to a specific user or group, or all existing, future, or previous versions of an application.

Policy management is through a set of predefined rules, called default rules, which are created automatically. The default rules:

o Are populated in specific rule types when you manually select the Create Default Rules option.

o Are managed and maintained by an administrator to meet specific needs. o Act as a fallback block rule that restricts the execution of any application that does not

have an allow rule (i.e., once AppLocker is enabled, only applications that have an allow rule will execute).

The following table describes the AppLocker rule types:

Rule Type Description

Executable

An executable rule applies to files with .exe and .com extensions.

The default executable rules allow: o Everyone to execute all applications in the C:\Windows and C:\Program

Files directories. o Administrators to execute all applications regardless of location.

You must enable the default executable rules, otherwise Windows cannot execute system files in the C:\Windows and C:\Program Files directories.

When you create a rule, the scope of the rule is set to Everyone. If you choose to modify the rule, you can select a specific security group or user account.

Windows

Installer

The Windows installer rule applies to .msi and .msp file extensions. The default installer

rules allow:

Everyone to access digitally-signed Windows installer files and all MSI files in the %systemdriver%\windows\installer directory.

Administrators to run any MSI or MSP file.

The installation of software and software updates through Group Policy.

Script

The script rule applies to .ps1, .bat, .cmd, .vbs, and .js file extensions. The default script

rules allow:

The execution of all scripts in the C:\Windows and C:\Program Files directories.

Administrators to execute all scripts regardless of location.

DLL

The DLL rule applies to .dll (Dynamic-Link Library) and .ocx file extensions.

The DLL rule is not enabled by default. Enable DLL rules from the Advanced tab of AppLocker properties within Group Policy.

When using DLL rules, you must manually create a rule for each DLL that is used by applications installed on the Windows 7 client.

Note: DLL rules affect system performance and require considerable administrative effort.

When you create a new rule, regardless of the rule type, you must specify a condition for the rule. Conditions are properties of files that AppLocker uses to enforce rules. AppLocker rules have the following conditions:

Condition Description

Publisher

The publisher condition uses the digital signature of the application's publisher. The digital

signature contains details about the company that created the application.

There is no need to obtain the certificate from the publisher because the details of the digital signature are extracted from the application file.

If the file does not have a digital signature, it cannot be used with the publisher condition.

You can specify exactly which application version(s) can execute (an exact version, a version above or below a specific version, or any current or future version).

Path

The path condition specifies a folder, a file, or a wildcard of files to restrict or allow execution.

If you specify a folder, restrictions apply to all programs within that folder.

Path conditions are the least secure of all the AppLocker conditions.

Implement NTFS permissions to prevent users from copying executable files to other locations outside the scope of the path condition.

Hash

The hash condition uses the digital fingerprint (also known as a file hash) of the application.

A hash value of a file is based on the content of the file, not the name of the file.

You must recreate file hashes each time the software is updated or changes versions.

Be aware of the following:

AppLocker rules take precedence over software restriction policies for Windows Server 2008 R2 and Windows 7 clients.

If both software restriction policies and AppLocker policies are configured in the same policy object, only the AppLocker settings will apply. Microsoft recommends that you use AppLocker for Windows Server 2008 R2 and Windows 7.

If no rules have been defined for a specific type, then all applications of that type are allowed to run. Once you define one rule, then only software allowed by that rule (or the default rules) is allowed.

Exceptions allow specific applications to be exempt from the AppLocker rules. Exceptions of any condition can be made in any rules. For example, you can create a path condition that allows all applications in C:\Windows to execute, but restrict the calculator application from running using a hash condition.

AppLocker has a soft-enforcement (also known as auditing) mode. Soft-enforcement mode: o Uses restrictions to only monitor AppLocker events. Blocked software is still allowed to

run while in soft-enforcement mode. o Audits AppLocker functionality before full implementation in the environment. o Verifies which applications are affected without actually blocking or hard-enforcing the

applications from executing.

Note: The enforcement mode (either Enforce rules or Audit only) applies to all rules of a

specific type. You cannot selectively enforce or audit different rules within a rule type. For

example, you cannot audit one executable rule and enforce another executable rule, but you can

audit all executable rules and enforce all script rules.

Events that are generated by auditing AppLocker are written to the AppLocker event log. Each log contains the following information:

o Rule name o SID of the user or group o File and path of the restricted or permitted application o Rule type or condition used

Use the following Windows PowerShell cmdlets to manage AppLocker policies: o Test-ApplockerPolicy tests whether an AppLocker rule will block an application file on a

client computer. o Get-AppLockerPolicy displays an AppLockerPolicy object or exports an XML-formatted

string. o New-AppLockerPolicy creates a new AppLocker policy. o Set-AppLockerPolicy applies an AppLocker policy to the specified GPO.

Account Policies Facts

Account policies control passwords and login properties.

Password Policy settings control characteristics enforced for user passwords. Account Lockout Policy settings control what happens when a user enters one (or more) incorrect passwords.

Settings in the local GPO are used if the computer is a member of a workgroup. Settings in the domain GPO are used for computers that are members of a domain.

Policy settings are applied to the computer, not the user.

Although you can configure Account Policies settings in any GPO, only the settings configured in a GPO linked to the domain take effect.

To configure different account policies settings for different users, use one of the following strategies:

o Configure granular password policies, available in Windows Server 2008 domain functional level.

o Create different domains, moving objects with different password policy requirements into their respective domains.

The following table explains the Password Policy and Account Lockout Policy settings.

Setting Description

Password Policy

Enforce password

history

This setting keeps a history of user passwords (up to 24) so that users cannot reuse

passwords.

When set to 0, users are not forced to enter new passwords.

You must configure a maximum password age for this setting to take effect.

Maximum

password age Maximum password age forces the user to change the password after a given length

of time.

Setting this value to 0 means that the password never expires.

Minimum password

age

Minimum password age forces the user to keep a new password for the specified

period of time. This setting prevents users from changing passwords immediately

after they've reset their passwords, thereby circumventing the password history by

entering several passwords to get back to a preferred password.

The value must be less than the maximum age, and should be a setting greater than

0. A setting of 0 allows the user to reset the password immediately.

Minimum password

length

Minimum password length configures how many characters a valid password must

have.

Password must

meet complexity

requirements

Enforcing password complexity requires that user passwords: cannot contain the

user name, the user's name, the company name, or a complete dictionary word. The

password must also contain a minimum of three of the four types of special

characters: lower case letters, upper case letters, numbers, or !, @, #, $, %, ^, &, *.

Store passwords

using reversible

encryption

Store passwords using reversible encryption determines how passwords are stored

within Active Directory and on the local system. For best security, this policy should

be disabled, meaning that passwords are not stored with reversible encryption.

Enable this setting only if you have specific applications that require reversible

encryption so that they can verify user passwords.

Account Lockout Policy

Account lockout

duration

Account lockout duration identifies how long a locked account remains locked. When

the time period expires, the account will be unlocked automatically.

When set to 0, the account will never be unlocked automatically, and an

administrator must unlock the account.

Account lockout

threshold

Account lockout threshold configures how many incorrect passwords can be entered

before the account is locked.

Reset account

lockout after

The reset account lockout after setting specifies the amount of time (in minutes) that

passes after a failed login attempt before the counter resets to zero.

For example, if this value is set to 5 and the account lockout threshold is set to 3, the

user can enter 2 incorrect passwords within a 5 minute interval without the account

being locked. After 5 minutes has passed, the user can make additional incorrect

logon attempts.

Be aware of the following facts when managing account policies:

If an account has been locked out because the user has forgotten the password, you will need to reset (change) the password. You should also force a password change at next logon.

The user account setting of Password never expires overrides any other requirement for changing passwords configured in a GPO. Service accounts should have this option enabled and

should use strong passwords, but no other type of account should have this setting enabled (including administrators).

Granular Password Policies Facts

Granular password policies allow you to create password policies for users and global groups separate from the password policy applied to the entire domain. Using granular password policies, you could, for example, require administrators to use 14 character passwords while requiring only seven character passwords from normal users.

You should know the following facts about granular password policies:

The domain must be running at the Windows Server 2008 domain functional level or higher.

Password policies affect only user account passwords, not computer account passwords.

Only members of the Domain Admins group can set granular password policies, but you can delegate the ability to set these policies to others.

Granular password policies are saved as a Password Settings Object (PSO) in the Password Settings Container (PSC).

o There is one default PSC. It cannot be renamed, deleted, or moved. o You can create additional PSCs, but they will not take effect. o The PSC holds one or more PSOs. You can define multiple PSOs, each with unique

password policy settings.

PSOs have attributes for all of the settings that can be defined in the Default Domain Policy (except Kerberos settings).

The msDS-PSOAppliesTo property in the PSO identifies the objects to which the password policy applies.

o Policies can be applied to user accounts or global security groups. Each granular policy can be applied to multiple users and/or groups. Granular password policies affect only users within the current domain.

o Policies are not enforced when applied to OUs, the domain, or other group types. To apply a granular policy to all users within an OU, create a global security

group that contains all OU members. Apply the policy to the group. When you move a user account to a different OU, remember to also change the

group membership so that the granular password policy no longer applies.

The msDS-PasswordSettingsPrecedence property is used to resolve conflicts if multiple PSOs are applied to a group.

o If a PSO has been applied directly to a user, that PSO is in effect, regardless of the precedence value.

o If multiple PSOs are applied to global security groups of which the user is a member, the PSO with the lowest precedence value will be in effect.

o If two (or more) PSOs are applied to a user, or if two (or more) PSOs are applied to groups with the same precedence value, the PSO with the lowest identifier will be in effect.

To use ADSI Edit to create a PSO:

1. Open ADSI Edit and connect to the default naming context for the domain. 2. Navigate to System | Password Settings Container. 3. Right-click the container and select New | Object.... 4. Complete the wizard steps to create the password policy, defining the password and account

lockout parameters. 5. After you create the PSO, edit its properties to identify the users or global security groups to

which the PSO applies. 6. If you applied the PSO to groups, add user accounts to groups as necessary.

Use the Active Directory module for Windows PowerShell to manage granular (also known as fine grained) passwords on a computer running Windows Server 2008 R2. The Active Directory module consolidates a group of cmdlets needed to manage granular passwords, including the following:

New-ADFineGrainedPasswordPolicy creates a new Active Directory fine grained password policy.

Set-ADFineGrainedPasswordPolicy modifies the properties of an Active Directory fine grained password policy.

Remove-ADFineGrainedPasswordPolicy removes an Active Directory fine grained password policy.

Get-ADFineGrainedPasswordPolicy gets a fine grained password policy or performs a search to retrieve multiple fine grained password policies.

Add-ADFineGrainedPasswordPolicySubject applies a fine-grained password policy to one more users and groups.

Get-ADFineGrainedPasswordPolicySubject gets the users and groups to which a fine-grained password policy is applied.

Remove-ADFineGrainedPasswordPolicySubject removes one or more users from a fine-grained password policy.

Auditing Facts

In Windows, auditing is the recording of system events and other system changes. When you enable auditing, the system automatically makes a record when events of interest occur. Auditing is enabled by configuring audit policies, either on a local system or through Group Policy. An audit policy is either enabled or disabled. When it is enabled, you must specify what type of events to log.

Audit Success to identify who has gained access or who was able to exercise a right or privilege.

Audit Failure to identify patterns of attempted access.

The following table describes the nine audit policies configurable through Group Policy.

Audit

Category Trigger Event(s)

Account logon

Account logon auditing tracks when a user account is used to authenticate to a computer.

For account logon auditing, an audit event is generated on the system where the user

account exists.

When a local user account is used, the local computer records the logon event.

When a domain user account is used, the domain controller records the logon event.

For example, when a user authenticates to a domain, an account logon event is recorded

on the domain controller but not on the local computer. If a user logs on using a local

computer account, an account logon event is recorded on the local computer.

Account

management

Account management auditing tracks changes to user accounts, including:

Create

Rename

Disable/enable

Delete

Change the password

Directory

service access

Directory service access auditing tracks changes to Active Directory objects. The audit

directory service access policy is divided into four subcategories:

Directory Service Access

Directory Service Changes

Directory Service Replication

Detailed Directory Service Replication

Note: In addition to enabling auditing in the audit policy, you must configure auditing on

the specific objects you want to track.

Logon

Logon auditing tracks logon or log off on the local system, or when a network connection

is made to a system. For logon auditing, an audit event is recorded in the audit log of the

local system, regardless of the type of user account used. For example, when a user logs

on to a computer using a domain account, a logon event is recorded on the local

workstation, while an account logon event is recorded on the domain controller.

Object access

Object access auditing tracks access to files, folders, or printers. It can also be used to

audit actions taken by a certificate authority or access to specific registry or IIS metabase

settings. For file auditing to occur, the files must be on NTFS partitions.

Note: In addition to enabling auditing in the audit policy, you must configure auditing on the specific objects you want to track.

Policy change Policy change auditing tracks changes to user rights, trust relationships, IPsec and

Kerberos policies, or audit policies.

Privilege use

Privilege use auditing tracks the following actions:

A user exercises a user right.

An administrator takes ownership of an object.

Process

tracking

Process tracking auditing records actions taken by applications. Process tracking

auditing is used mainly for program debugging and tracking.

System System events auditing tracks system shutdown, restart, or the starting of system

services. It also tracks events that affect security or the security log.

Be aware of the following when configuring auditing:

With both Directory Service Access and Object Access auditing, configuring auditing requires two steps:

1. Enable auditing in the local security policy or Group Policy.

2. Configure auditing on the specific objects. For example, you might edit the System Access Control List (SACL) of the Active Directory object or the NTFS file or folder to identify the users or groups and the actions to track. For CA auditing, identify the specific CA actions to track in the CA properties.

New with Windows Server 2008, Directory Service Access auditing uses four subcategories. Audit Directory Service Access to record when changes occur to an object; audit Directory Service Changes to record the old and new values when a change is made to an object.

When you enable Directory Service Access auditing, auditing for all four subcategories is enabled. To enable auditing for individual categories, use the Auditpol /set /subcategory command.

View audit entries in the Event Viewer Security log.

When using Directory Service access with directory service changes, when a change is made to an Active Directory object, the following event IDs are recorded.

Event

ID

Event

Action Description

5136 Modify Logged when a successful modification is made to an attribute in the

directory

5137 Create Logged when a new object is created in the directory

5138 Undelete Logged when an object is undeleted in the directory

5139 Move Logged when an object is moved within the domain

Auditing Design Facts

To design an audit policy, complete the following steps:

1. Identify the objects that require auditing and the potential security threats. 2. Enable the audit policy that records events related to the objects, events, and threats you've

identified. Indicate whether to track success or failure (or both). 3. If necessary, configure auditing for specific files and objects. You must configure auditing on

specific objects to audit the following: o NTFS file or folder access o Printer access o Active Directory object access o Certificate Authority actions o Registry hive, key, or subkey access o IIS metabase object access

Although you might be tempted to audit everything, you should audit only those events that are necessary to ensure a secure network. Use the following guidelines when designing auditing.

Audit only what's necessary. o Audit for Success only or Failure only if either one is sufficient to give you the information

you need. o Enable auditing on only the necessary objects. For example, enable auditing on specific

files or registry keys rather than enabling auditing on an entire drive or registry hive.

Excessive auditing uses processor cycles and requires disk space for the audit log. In addition,

auditing every event increases the number of entries in the log, making it harder to find those

things you are looking for.

Make sure you have modified the audit log size and characteristics so that you are saving the data you want to save where you want it.

Archive audit logs so you can review past data if you suspect a problem.

Identify actions that should always be audited. In addition, periodically audit other actions for short periods of time to catch any unforeseen problems.

Design periodic reviews of audit logs. Auditing is useless if you do not read the logs.

For investigative and evidentiary reasons, make sure that all pertinent events are getting recorded to the Security log. In addition to tracking the necessary events, make sure your logs are properly configured to save all of the necessary information.

o Use the Event Log policies in Group Policy to configure the Security log size and retention method.

o To preserve all logged actions, configure logs to not overwrite events. When logs are not configured to clear automatically, you must periodically save and clear the logs to make room for additional events.

o Enable the Audit: Shut down system immediately if unable to log security audits security option to prevent the system from being used if the log is full (this setting is also referred to as CrashOnAuditFail).

Advanced Audit Policy Facts

In Windows Server 2008 R2, 53 new auditing capabilities have been integrated with Group Policy. Be aware of the following details about the advanced audit policy configuration:

You can configure the Advanced Audit Policy using the Group Policy Management Console by navigating to the Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration node or by using the command line utility auditpol.exe.

The 53 new settings can be used in place of the nine basic auditing settings under Local Policies\Audit Policy to specifically target the types of activities you want to audit and eliminate the unnecessary auditing activities that can make audit logs difficult to manage and decipher.

Using both the basic audit policy settings under Local Policies\Audit Policy and the advanced settings under Advanced Audit Policy Configuration can cause unexpected results; the two sets of audit policy settings should not be combined.

If you use Advanced Audit Policy Configuration settings, you should enable the Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings policy setting under Local Policies\Security Options. This will prevent conflicts between similar settings by forcing basic security auditing to be ignored.

Reason for Access auditing logs the reason, based on specific permissions, why someone had access to specific resources. The reason why someone has been granted or denied access is added to the open handle event. To enable this functionality, the handle manipulation audit policy also needs to be enabled.

Be aware of the categories of the 53 new auditing policy settings:

Category Description

Account Logon Account Logon events help document domain attempts to authenticate account data,

either to a domain controller or a local Security Accounts Manager (SAM). Unlike logon

and logoff events, which track attempts to access a particular computer, events in this

category report on the account database that is being used. Be aware of the following

settings:

Credential Validation audits events generated by validation tests on user account logon credentials.

Kerberos Service Ticket Operations audits events generated by Kerberos service ticket requests.

Other Account Logon Events audits events generated by responses to credential requests submitted for a user account logon that are not credential validation or Kerberos tickets.

Kerberos Authentication Service audits events generated by Kerberos authentication ticket-granting ticket (TGT) requests.

Account

Management

Account Management settings can monitor changes to user and computer accounts and

groups. Be aware of the following settings:

User Account Management audits changes to user accounts.

Computer Account Management audits events generated by changes to computer accounts, such as when a computer account is created, changed, or deleted.

Security Group Management audits events generated by changes to security groups.

Distribution Group Management audits events generated by changes to distribution groups. Events are logged only on domain controllers.

Application Group Management audits events generated by changes to application groups.

Other Account Management Events audits events generated by other user account changes that are not covered in this category.

Detailed

Tracking

Detailed Tracking events can be used to monitor the activities of individual applications

to understand how a computer is being used and the activities of users on that computer.

Be aware of the following settings:

Process Creation audits events generated when a process is created or starts. The name of the application or user that created the process is also audited.

Process Termination audits events generated when a process ends.

DPAPI Activity audits events generated when encryption or decryption requests are made to the Data Protection Application Interface (DPAPI). DPAPI is used to protect secret information such as stored password and key information.

RPC Events audits inbound Remote Procedure Call (RPC) connections.

DS Access

DS Access events provide a low-level audit trail of attempts to access and modify objects

in AD DS. These events are logged only on domain controllers. Be aware of the following

settings:

Directory Service Access audits events generated when an AD DS object is accessed.

o Only AD DS objects with a matching global System Access Control List (SACL) are logged.

o Events in this subcategory are similar to the Directory Service Access events available in previous versions of Windows.

Directory Service Changes audits events generated by changes to AD DS objects. Events are logged when an object is created, deleted, modified, moved, or undeleted.

Directory Service Replication audits replication between two AD DS domain controllers.

Detailed Directory Service Replication audits events generated by detailed AD DS replication between domain controllers.

Logon/Logoff

Logon/Logoff events track attempts to log on to a computer interactively or over a

network. These events are particularly useful for tracking user activity and identifying

potential attacks on network resources. Be aware of the following settings:

Logon audits events generated by user account logon attempts on a computer.

Logoff audits events generated by closing a logon session. These events occur on the computer that was accessed. For an interactive logon, the security audit event is generated on the computer that the user account logged on to.

Account Lockout audits events generated by a failed attempt to log on to an account that is locked out.

IPsec Main Mode audits events generated by Internet Key Exchange protocol (IKE) and Authenticated Internet Protocol (AuthIP) during Main Mode negotiations.

IPsec Quick Mode audits events generated by Internet Key Exchange protocol (IKE) and Authenticated Internet Protocol (AuthIP) during Quick Mode negotiations.

IPsec Extended Mode audits events generated by Internet Key Exchange protocol (IKE) and Authenticated Internet Protocol (AuthIP) during Extended Mode negotiations.

Special Logon audits events generated by special logons.

Other Logon/Logoff Events audits other events related to logon and logoff that are not included in the Logon/Logoff category.

Network Policy Server audits events generated by RADIUS (IAS) and Network Access Protection (NAP) user access requests. These requests can be Grant, Deny, Discard, Quarantine, Lock, and Unlock.

Object Access

Object Access events track attempts to access specific objects or types of objects on a

network or computer. Be aware of the following settings:

File System audits user attempts to access file system objects.

Registry audits attempts to access registry objects.

Kernel Object audits attempts to access the system kernel, which include mutexes and semaphores. Note: The Audit: audits the access of global system objects policy setting controls the default SACL of kernel objects.

SAM audits events generated by attempts to access Security Accounts Manager (SAM) objects.

Certification Services audits Active Directory Certificate Services (AD CS) operations.

Application Generated audits applications that generate events by using the Windows Auditing Application Programming Interfaces (APIs). Applications designed to use the Windows Auditing API use this subcategory to log auditing

events related to their function.

Handle Manipulation audits events generated when a handle to an object is opened or closed. Only objects with a matching SACL generate security audit events.

File Share audits attempts to access a shared folder. However, no security audit events are generated when a folder is created, deleted, or its share permissions are changed.

Detailed File Share audits attempts to access files and folders on a shared folder. Note: The Detailed File Share setting logs an event every time a file or folder is accessed, whereas the File Share setting only records one event for any connection established between a client and file share. Detailed File Share audit events include detailed information about the permissions or other criteria used to grant or deny access.

Filtering Platform Packet Drop audits packets that are dropped by Windows Filtering Platform (WFP).

Filtering Platform Connection audits connections that are allowed or blocked by WFP.

Other Object Access Events audits events generated by the management of Task Scheduler jobs or COM+ objects.

To audit a file, directory, registry key, or any other object, you must enable the Object Access category for success and failure events. For example, the File System subcategory needs to be enabled to audit file operations, and the Registry subcategory needs to be enabled to audit registry access.

Policy Change

Policy Change events track changes to important security policies on a local system or

network. Be aware of the following settings:

Audit Policy Change audits changes in security audit policy settings.

Authentication Policy Change audits events generated by changes to the authentication policy.

Authorization Policy Change audits events generated by changes to the authorization policy.

MPSSVC Rule-Level Policy Change audits events generated by changes in policy rules used by Windows Firewall.

Filtering Platform Policy Change audits events generated by changes to WFP.

Other Policy Change Events audits events generated by other security policy changes that are not audited in the Policy Change category.

Privilege Use

Privilege Use events track the use of certain privileges on one or more computers. Be

aware of the following settings:

Sensitive Privilege Use audits events generated by the use of sensitive privileges (user rights), such as acting as part of the operating system, backing up files and directories, impersonating a client computer, or generating security audits.

Non Sensitive Privilege Use audits events generated by the use of non-sensitive privileges (user rights), such as logging on locally or with a Remote Desktop connection, changing the system time, or removing a computer from a docking station.

System

System events track high-level changes to a computer that are not included in other

categories and that have potential security implications. Be aware of the following

settings:

Security State Change audits events generated by changes in the security state of the computer.

Security System Extension audits events related to security system extensions or services.

System Integrity audits events that violate the integrity of the security subsystem.

IPsec Driver audits events that are generated by the IPsec filter driver.

Other System Events audits any of the following events: o Startup and shutdown of the Windows Firewall. o Security policy processing by the Windows Firewall. o Cryptography key file and migration operations.

Global Object

Access

Auditing

The Global Object Access Auditing settings define computer SACLs per object type for

either the file system or registry. The specified SACL is then automatically applied to

every object of that type.

Auditors will be able to prove that every resource in the system is protected by an audit policy by just viewing the contents of the Global Object Access Auditing policy setting.

Resource SACLs are also useful for diagnostic scenarios. For example, setting a Global Object Access Auditing policy to log all the activity for a specific user and enabling the Access Failures audit policies in a resource (file system, registry) will help administrators quickly identify which object in a system is denying a user access.

Be aware of the following settings:

File system audits a SACL on the file system for an entire computer. Note: If both a file or folder SACL and a Global Object Access Auditing policy (or a single registry setting SACL and a Global Object Access Auditing policy) are configured on a computer, then an audit event is generated if an activity matches either the file or folder SACL or the Global Object Access Auditing policy.

Registry audits a global SACL on the file system for an entire computer.

Note: Both the File system and Registry settings must be used in combination with their corresponding security policy setting under the Object Access category.

Certificate Facts

Be aware of the following facts about encryption and certificates:

A cipher or algorithm is the process or formula used to encrypt a message.

A key is a variable in a cipher used to encrypt or decrypt a message.

Encryption uses one of the following methods:

Method Description

Symmetric

Encryption

With symmetric (secret key) encryption, a single key is used both to encrypt and

decrypt data.

o The sender and the recipient of the message must both have the key for the system to work.

o This creates a problem of key distribution. The key must be sent or shared before communication begins, making symmetric encryption an insecure encryption method.

Asymmetric

Encryption

(PKI)

Asymmetric encryption requires a pair of associated, but not identical keys (the

key pair), generated by a cryptographic service provider (CSP).

o The public key is made available to everyone. o The private key is kept secret by its owner.

With asymmetric encryption, data encrypted with one key can only be

unencrypted using the other key.

o Encrypting a message with the sender's private key means that only the corresponding public key can unencrypt the message. This proves that the message came from the sender, but does not provide data confidentiality (secrecy) because anyone with the public key can read the encrypted message.

o Encrypting a message with a recipient's public key means that only the intended recipient (who has the private key) can read the message. This provides data confidentiality because only the recipient will be able to read the message.

A certificate is a digitally-signed statement that binds the value of a public key to the identity of the person, device, or service that holds the corresponding private key. Certificates provide proof of identity and/or encryption for the following uses:

o Web user authentication o Web server authentication o Secure e-mail o IPSec o Transport layer security o Code signing o Certification hierarchy

Typical information in a certificate includes: o The subject's public key value (the subject is the entity that receives the certificate) o The subject's identifier information (name and e-mail address, for example) o The length of time for which the certificate is considered valid (i.e., the validity period) o Issuer identifier information (the issuer is the certification authority) o The issuer's digital signature (this verifies the validity of the binding between the subject's

public key and the subject's identifier information)

A Public Key Infrastructure (PKI) is a system that provides for a trusted third party to vouch for user identities and allows binding of public keys to subjects.

A PKI is made up of Certification Authorities (CAs), also called certificate authorities. A CA is an entity trusted to issue, store, and revoke certificates. A CA:

o Accepts certificate requests. o Verifies the information provided by the requester. o Creates and digitally signs the certificate. o Issues the certificate to the requester. o Revokes certificates. o Publishes a list of revoked certificates known as the certificate revocation list (CRL).

A certification hierarchy consists of a root CA and can include one or more subordinates that are in a parent-child relationship with the root. If a root authority is trusted, all the subordinate CAs are also trusted.

To issue certificates, each CA must first have its own certificate, verifying its identity. o The root CA generates its own certificate. o Subordinate CAs obtain their CA certificates from the root CA or another subordinate CA.

This authorizes the CA to issue certificates to other entities and to be trusted.

You can obtain certificates from a public CA (such as Verisign), or install your own PKI and CAs to issue certificates to users and computers in your organization. Note: If you want a certificate to be trusted by users outside of your organization, obtain a certificate from a third-party CA.

AD CS Facts

You can use Active Directory Certificate Services (AD CS) to create your own PKI. Servers running AD CS issue certificates to users and computers. When you install AD CS on a server, you choose one of the following CA types:

The enterprise root CA is the first CA in the PKI hierarchy. The enterprise CA is integrated with Active Directory, and can use information in Active Directory to issue certificates, or it can store certificates in Active Directory.

An enterprise subordinate CA gets its authority to issue certificates from a root CA. A subordinate enterprise CA can use information in Active Directory for responding to certificate requests.

A standalone root CA is the first CA in the PKI hierarchy. It is not integrated with Active Directory.

A standalone subordinate CA gets its authority from a root CA. It is not integrated with Active Directory.

When you install AD CS on a server, you choose one (or more) of the following role services:

Role Service Description

Certification Authority

Add the Certification Authority role service to configure the server as a CA that

can issue certificates to other CAs or to users and computers. When you add this

role service, you configure the server as an enterprise or standalone and a root or

subordinate CA.

Certification Authority

Web Enrollment

Add the Certification Authority Web Enrollment role service to allow users to

connect to a CA through a Web browser and perform common tasks, such as:

Requesting certificates

Requesting the CA's certificate

Submitting a certificate request

Retrieving the CA's CRL

Performing smart card certificate enrollment

Online Responder

The Microsoft Online Responder service makes it possible to configure and

manage Online Certificate Status Protocol (OCSP) validation and revocation

checking in Windows-based networks. OCSP allows a relying party (i.e., a client)

to submit a certificate status request to an online responder (also called an OCSP

responder). The OCSP responder returns to the client a definitive, digitally signed

response indicating the certificate status. Use the Online Responder service to:

Create a central location for certificate revocations. The online responder can maintain revocation lists for multiple CAs, giving clients a single location to check for the status of a certificate.

Allow clients to check the status of a single certificate. With OCSP, clients no longer need to download the entire CRL.

Shorten the time that revoked certificates are known by clients. Without OCSP, clients periodically download the CRL and will not check for an updated CRL until the current one expires. With OCSP, individual certificates are validated with the online responder server.

Network Device

Enrollment Service

(NDES)

The Network Device Enrollment Service makes it possible for software running on

network devices such as routers and switches (which cannot otherwise be

authenticated on the network) to enroll for certificates from a CA. The following

process is used to obtain certificates for non-Microsoft devices:

1. On the network device, run the device's utility to generate a certificate request.

2. Submit the certificate request to a Windows server running the Network Device Enrollment Service. This server is called a registration authority (RA).

3. The RA submits the certificate request to a CA. 4. The CA issues the certificate and returns it to the RA. 5. On the network device, import the certificate received from the RA.

The registration authority must be running the Windows Server 2008 Enterprise

or Datacenter edition.

If you are using an enterprise CA, it is recommended to install the NDES service on a server other than the CA.

If you are using a standalone CA, it is recommended to install the NDES service on the CA.

Certificate Enrollment

Web Service and

Certificate Enrollment

Policy Web Service

The Certificate Enrollment Web services are new AD CS role services in Windows Server 2008 R2. The services enable policy-based certificate enrollment over HTTP by using existing methods. The Web services:

Act as a proxy between a client computer and a CA, which makes direct communication between the client computer and CA unnecessary.

Are beneficial in the following scenarios: o In multiple-forest deployments, client computers can enroll for

certificates from CAs in a different forest. o In extranet deployments, mobile workers and business partners

can enroll over the Internet.

The Certificate Enrollment Web services have the following requirements:

An Active Directory forest with Windows Server 2008 R2 schema.

An enterprise CA running Windows Server 2008 R2, Windows Server 2008, or Windows Server 2003.

Certificate enrollment across forests requires an enterprise CA running the Enterprise or Datacenter edition of Windows Server.

Client computers running Windows 7.

Note: The Certification Authority role service is automatically selected when the AD CS role is added, but it cannot be installed at the same time as the Certificate Enrollment Web Service or Certificate Enrollment Policy Web Service. If you intend to install both the CA and the Certificate Enrollment Web Service or Certificate Enrollment Policy Web Service, complete the CA installation first.

The following table lists additional features available through Active Directory Certificate Services.

Feature Description

Certificate

templates

A certificate template identifies a certificate type and describes the rules the CA

follows when issuing a certificate based on the template. Templates also give

instructions to the user on how to create and submit a certificate request.

Autoenrollment

With autoenrollment, certificates can be requested, issued, or renewed without user

intervention. Autoenrollment automatically downloads and manages certificates from

Active Directory into the local machine registry for all users who log on to domain-

joined machines. Autoenrollment also manages certificates for user objects in Active

Directory by deleting revoked and expired certificates.

Web enrollment

Web enrollment allows users to connect to a CA via a Web browser and perform

common tasks, such as the following:

Requesting certificates

Requesting the CA's certificate

Submitting a certificate request

Retrieving the CA's CRL

Performing smart card certificate enrollment

Credential

roaming

Credential roaming allows a user to store a single set of certificates and private keys

in Active Directory. This makes the certificates and keys available on multiple

computers in a manner that is extremely secure, easy to implement and manage, and

transparent to the user.

Certificate

enrollment across

forests

Windows Server 2008 R2 CAs can issue certificates across forests that have two-way

trust relationships (with the use of LDAP referrals). Before the introduction of

enrollment across forests, CAs could issue certificates only to members of the same

forest, and each forest had its own PKI.

Preparing for multiple-forest deployments of Active Directory Certificate Services requires that you identify the account forest (the forest that contain the user accounts that will be requesting certificates) and the resource forest (the forest that will be providing certificates to the account forest). You then need to take the following steps:

1. Create a two-way forest trust between the resource forest and account forests.

2. Establish a root CA in the resource forest by deploying a new root CA or by designating an existing standalone or enterprise root CA.

3. Install or upgrade one or more enterprise CAs running on Windows Server 2008 R2 in the resource forest.

4. Enable LDAP referral support on enterprise CAs. 5. Add enterprise CA computer accounts to the Cert Publishers group in each

account forest. 6. Configure authority information access and CRL distribution point locations. 7. Publish the root CA certificate from the resource forest to the account forests

by using certutil.exe. 8. Publish enterprise CA certificates from the resource forest into the

NTAuthCertificates and AIA containers in each account forest.

High-volume CA

support

A CA supporting an environment that requires Network Access Protection (NAP) with

IPSec enforcement can expect a high volume of certificate requests. There may be

hundreds or even thousands of certificates issued every day depending on the

environment, all of which have short validation periods. By default, CAs store a

record of each certificate request and issued certificate in the CA database.

High-volume CAs may experience rapid database growth which can consume all available disk space. Enabling non-persistent certificate processing causes the CA to process certificate requests and issue certificates without storing those requests and certificates in the CA database.

Note: Many of these features require an enterprise CA.

AD CS Installation Facts

You should know the following facts about CA installation.

Before beginning the installation of your PKI, you should carefully plan the PKI structure and the rules that will be followed for issuing certificates. As part of the process, you should create a Certificate Practice Statement (CPS). The CPS is a document that logically describes how you verify identity and how you will keep your PKI secure. This helps you manage your CA, and helps other organizations understand how you operate so they can decide whether or not to trust your PKI.

When you create a PKI, you must proceed in this order: 1. Install the root CA. This CA issues its own certificate. 2. Install the intermediate subordinate CAs. These CAs receive their certificates from root

CA. 3. Install the issuing subordinate CAs. Issuing CAs can receive certificates from a

subordinate CA or the root CA.

To protect the root CA, a typical practice is to take the root CA offline. This prevents network-based attacks on the root CA.

o Because an enterprise CA requires Active Directory, you should not take an enterprise root CA offline. If you want to take the root CA offline, install a standalone root CA.

o An offline standalone root CA can have subordinate enterprise CAs.

To issue certificates, each CA must first have its own certificate, verifying its identity. During installation, you configure how the CA receives its certificate.

o The root CA generates a private key and issues its own certificate. o Subordinate CAs generate a private key and submit a certificate request to the root CA or

another subordinate CA authorized to issue CA certificates. o If the root or subordinate CA is online, you can send the certificate request directly to the

other CA. o If the root CA is offline, save the certificate request as a file. You will not be able to use

the new CA until you have submitted the request to the CA and imported the resulting certificate.

o If you are reinstalling a CA, choose an existing certificate during the installation. You must have access to both the private key and the certificate to proceed.

An enterprise CA is required if you want to use certificate templates, autoenrollment, or issue certificates for smart cards or EFS.

AD CS cannot be installed on Server Core or Itanium-based installations of Windows Server 2008.

A user with local Administrator privileges can install a standalone CA. Only an Enterprise Admin can install an enterprise CA.

Use the Add Roles wizard in Server Manager to install Certificate Services and select the CA type.

To install an enterprise CA, the server must be a member of the domain. If the server is not a member of a domain, the enterprise CA option will be disabled during install.

After installing Certificate Services, you cannot change the computer name or domain membership.

Certificate Template Facts

A certificate template identifies a certificate type and describes the rules the CA follows when issuing a certificate based on the template. Using certificate templates reduces the administrative complexity of requesting and issuing certificates. Each template includes settings for certificates that are used for specific functions. Templates also give instructions to the user on how to create and submit a certificate request.

In most cases, you will use existing certificate templates, copying and modifying them when necessary in order to customize their use. When managing certificate templates:

Certificate templates require an enterprise CA.

To create a new template, copy an existing template whose purpose and configuration closely matches your needs.

Instead of modifying the default templates, copy the template and make modifications there. This preserves the original configuration of the default templates.

On each CA, you must identify the certificate templates that the CA can issue. o Issuing a template does not create a new template, it only allows the CA to respond to

requests for certificates using that template. o Removing the template from the list of issued templates does not delete the template, it

only prevents the CA from issuing certificates using that template.

Certificate templates are stored in Active Directory and replicated with Active Directory replication. Because this replication can take up to 8 hours to complete, allow sufficient time for replication to take place before issuing templates.

Each template has a version number. The version number identifies the operating systems that the template is valid on, as well as the features available within the template.

Users and computers must have appropriate permissions to the certificate template to request a certificate of that type. Permissions also control administrative abilities. The following table describes the certificate template permissions:

Permission Description

Full Control

Allows a user to set and modify certificate template contents and permissions. By default,

Enterprise Admins and Domain Admins in the forest root receive this permission during

installation (Enterprise Admins do not receive this permission by default during an upgrade).

Read Allows a user or machine to access (see or find) the template.

Write Allows a user to modify certificate template settings, except for template permissions.

Enroll

Allows a user to request a certificate based on a template from an Enterprise CA. The

Enterprise CA must have Read permissions to list and issue certificates based on the

template.

Autoenroll

Allows a user or machine to enroll automatically for the selected certificate template.

Autoenrollment also requires the Read and Enroll permissions. Autoenroll can only be set

for version 2 and 3 templates.

Be aware of the following facts about managing certificate template permissions:

At a minimum, users need Read and Enroll permissions in order to request a certificate. For autoenrollment, users need Read, Enroll, and Autoenroll permissions.

By default, Authenticated Users have the Read permission. In most cases, you should not modify this default assignment.

Only Domain Admins in the forest root or Enterprise Admins can create new templates (you can grant others this ability by modifying Active Directory rights and permissions). The ability to create certificate templates is not controlled by template permissions.

Administrators need Read and Write permissions to modify template settings. Assign the Write and Full Control permissions only to certificate template administrators.

Assign template permissions to global or universal groups. You should not assign permissions to domain local groups. Avoid assigning permissions directly to individual computers or users.

By default, CAs are members of the Certificate Publishers group. This allows the CAs to publish information in Active Directory. Do not delete this group or modify its membership.

Certificate Template Settings Facts

For version 1 templates (Windows 2000 templates), the only settings that you can modify are template permissions. For version 2 and 3 templates, you can modify additional settings to customize the template. The following table describes other common settings that you can modify for version 2 and 3 templates.

Setting Description

Validity Period The validity period identifies the length of time since the certificate was issued that it

remains valid.

Certificates used by CAs typically have longer validity periods.

The validity period of certificates issued to users or computers should be less than the validity period of all CAs in the CA chain.

As certificate expiration approaches, certificates can be automatically renewed, thus preventing expired certificates.

Publish in Active

Directory

Publishing the certificate in Active Directory stores the certificate as an attribute of

the user or computer account in Active Directory.

Key Type

The key type identifies the allowed use or purpose of the certificate. Certificates can

be issued to enable:

Encryption

Digital signatures

Both signatures and encryption

Signatures for smartcard logon (encryption is not provided)

Cryptographic

Service Provider

(CSP)

The Cryptographic Service Provider identifies the algorithm that is used to generate

the keys in the certificate. Choose the CSP based on the providers supported on the

target systems and the desired key length (some providers support longer keys than

others).

Note: A longer key is more secure but requires more processing power than a shorter key. If you cannot increase the key size, try choosing a different CSP.

Subject Name

The subject name identifies the certificate owner (the holder of the private key).

When identity is validated, the reported identity of the certificate holder must match

the subject name included in the certificate.

The subject name can be manually created, or automatically generated based on criteria such as the Active Directory common name or the Active Directory fully-qualified domain name.

Certificates can also include secondary (alternate) names based on criteria such as e-mail address, DNS name, or UPN name.

Certificate templates used for autoenrollment must automatically generate subject name information from Active Directory.

Note: If a certificate request is generated using Active Directory properties, such as

the e-mail address, and if values for those attributes are not found for the Active

Directory object, the certificate request will be denied.

Issuance

Requirement

The issuance requirement identifies a process that must be followed to issue a

certificate. For example, the policy might require CA manager approval or multiple

authorized signatures before the certificate can be issued.

Note: Templates that require multiple signatures cannot be used for autoenrollment. The certificate request will remain in the pending state until the necessary approvals are granted.

Extensions

Extensions are additional policies that restrict the issuance or use of a certificate.

Extensions include:

Application policies, which identify the allowed use(s) of the certificate.

Issuance policies, which identify administrative policies that were followed to issue the certificate. The exact policies used for approval are unique to the issuing organization and are not standard across organizations.

Certificate templates, also called subject types, which identify the type of subject (user) allowed to use the certificate. Possible subjects are user, computer, CA, or key recovery agent. Note: Once defined, the subject type cannot be changed (create a new template to change the subject type).

Key use policies, which restricts the use of the certificate (such as for digital signatures, encryption, or CA authorization).

Extension information is stored in the certificate in the object identifier (OID). Different

portions of the OID are reserved for different extensions. By parsing the OID,

applications can identify the intended use of the certificate and allow only those

operations supported by the certificate.

Note: To configure settings for version 1 templates, duplicate the template as a version 2 (2003) or version 3 (2008) template. This adds additional settings, such as autoenrollment, and allows you to edit template settings.

Certificate Request Facts

In some cases, certificates are managed automatically by Windows Server 2008, Windows Server 2008 R2, or PKI-enabled applications. In other cases, you will receive manual certificate requests. The table below describes the methods of requesting a certificate:

Method Description

Web Enrollment Pages

To allow Web enrollment in Windows Server 2008 or Windows Server 2008

R2:

Your CA must be running at least Windows Server 2008 Certificate Services or higher and IIS 6.0 or better.

The CA must have the Certification Authority Web Enrollment role service added to the server role. This allows users to request and receive certificates from standalone and enterprise CAs.

Web-based enrollment pages are installed on the CA and are accessible

from a client through the following URL: http://servername/certsrv

Certificate Request Wizard

through the Certificates

snap-in

Users can request certificates through the Certificates snap-in, but it requires

more customization than Web-based enrollment. The Certificate Request

Wizard is also only available for use with enterprise CAs.

Autoenrollment Through autoenrollment, you can automatically request and issue certificates to users and computers in an Active Directory environment. Autoenrollment

requires you to have the following hardware:

Windows 2003, 2008, or 2008 R2 domain controllers

Windows XP/2003/Vista/7 clients

Windows 2003, 2008, or 2008 R2 Enterprise CA

Additionally, accounts must have the following certificate permissions:

Read

Enroll

Autoenroll

Command Line

Certreq.exe is a command line tool that allows you to request, retrieve, and

accept certificates.

Use Certreq.exe -submit to request a certificate.

Use Certreq.exe -retrieve to retrieve a certificate.

Use Certreq.exe -accept to accept and install a certificate.

Be aware of the following facts about certificate requests.

The Xenroll.dll enrollment control used in Windows 2000, XP, and 2003 has been replaced by CertEnroll.dll in Windows Vista and Server 2008 and 2008 R2. XEnroll.dll can continue to be used for Web enrollment on computers running Windows 2000, Windows XP, and Windows Server 2003.

Users running Internet Explorer 6.x or Netscape 8.1 can submit certificate requests directly through Web enrollment pages. Users running other Web browsers must create PKCS #10 requests before submitting certificate enrollment requests through the Web enrollment pages.

You cannot use Web enrollment for version 3 certificate templates (which are being introduced through Windows Server 2008 to support the issuance of Suite B-compliant certificates).

Users can no longer request computer certificates through Web enrollment because Internet Explorer can't run in the local computer's security context.

When a certificate request is submitted (either manually or automatically), by default: o Enterprise CAs issue the certificates automatically using information in Active Directory. o Stand-alone CAs mark all requests as pending. Administrators must manually approve

the certificate request.

To request a certificate from an offline CA: 1. Use the Web Enrollment Pages, the Certificate Request Wizard, or Certreq.exe to

prepare the request (saved as a file). 2. Import the request file into the CA. 3. Approve the request, making it a certificate. 4. Save the certificate as a file. 5. Import the certificate file into the system that requested it.

Issued certificates include a time limit or expiration data. Certificates that are reaching their expiration time can be renewed. You do not need to issue a new certificate or request a new one.

Autoenrollment Facts

With autoenrollment, certificates can be requested, issued, or renewed without user intervention. Autoenrollment automatically downloads and manages certificates from Active Directory into the local

machine registry for all users who log on to domain-joined machines. Autoenrollment also manages certificates for user objects in Active Directory by deleting revoked and expired certificates.

Autoenrollment can only be configured for version 2 certificates, which means that you also need a Windows 2003 or better CA. Configuring autoenrollment requires the following steps:

1. Edit the certificate template. If the certificate template is a version 1 template, duplicate the template to make it a version 2 or version 3 template. This allows you to configure the Autoenroll settings.

o Grant users or computers the Read, Enroll, and Autoenroll permissions. o On the Request Handling tab, make sure that the Enroll subject without requiring

any user input option is selected to allow enrollment without prompts. (This option is automatically deselected for smart cards, and the Prompt for user action option becomes the default option to allow users to input their personal identification numbers.)

o On the Subject Name tab, make sure the Build from this Active Directory information option is selected. Selecting the Supply in the request option requires the user to manually specify the certificate subject name.

o Do not require multiple signatures for certificate approval. Multiple signatures require manual approval. Certificate requests will be in a pending state until the necessary signatures are obtained.

2. Publish the certificate template on the CA (issue the certificate template). 3. Edit Group Policy and enable autoenrollment for computers, users, or both. Within either

Computer or User Configuration, browse to \Policies\Windows Settings\Security Settings\Public Key Policies and configure the Certificate Services Client - Auto-Enrollment policy. You can also configure whether certificates are automatically renewed or updated. If automatic renewal is enabled:

o You can force users to re-enroll for a certificate template by updating the templates version number. During logon, when autoenrollment queries Active Directory for required templates, the autoenrollment process examines the template version number. If the certificate number has incremented, users must re-enroll.

o To increment a template version number, right-click the template and select Reenroll all certificate holders.

CRL Facts

Certificate revocation is the process of breaking the bond of a public key pair to a specific individual. Revocation occurs when the end entity falls out of the scope of trust of the PKI system. Situations in which a digital certificate would be revoked are:

The subject (either a person or the computer) identity changes, such as changing from a maiden name to a married name.

An organization sells a division or changes its name.

The subject of the certificate leaves the company or is no longer trusted for some reason.

A compromise, such as a private key is discovered by a hacker or a laptop with a PKI-enabled application is lost or stolen.

Be aware of the following facts about certificate revocation.

In the Certification Authority console, when you revoke a certificate, it is moved to the Revoked Certificates folder.

o You must indicate a reason when you revoke the certificate.

o Certificates that have been revoked with Certificate Hold as the reason can be unrevoked (reinstated). You cannot unrevoke certificates that have been revoked for any other reason.

o The CA uses certificates in this folder to build the certificate revocation list (CRL).

Revoked certificates are published in a list called the Certificate Revocation List (CRL). The CRL contains a list of all certificates issued by the CA that have been revoked.

The CRL is published to a location known as the CRL Distribution Point (CDP). Four areas where the CRL is usually published are:

o On the issuing CA (by default in the C:\Windows\system32\Certsrv\CertEnroll directory) o On an Internet or intranet Web site (by default in the http://servername/CertEnroll virtual

directory) o To a file o In a directory service such as Active Directory

CDP locations are configured in the properties of a CA on the Extensions tab by editing the CRL Distribution Point (CDP) extension list. You can add or remove distribution points in the list.

The CA periodically publishes the CRL to include newly-revoked certificates. You can also manually publish the CRL to update it immediately.

Windows Server 2008 allows you to publish delta CRLs. o Delta CRLs list only changes made to the CRL since the CRL was published. This allows

you to publish changes frequently without having to publish the entire CRL. For example, you could configure the CA to publish the full CRL weekly while it publishes a delta CRL daily.

o Windows client systems older than XP cannot use delta CRLs.

When the CA issues a certificate, the CRL distribution points are included in the certificate.

When a client computer is presented with a new certificate, it checks the CRL to see if the certificate is still valid.

o The client uses the CDP information in the certificate to locate the CRL. o The client downloads the entire CRL and any delta CRLs. o Each CRL and delta CRL includes a property that identifies how long it is valid. This

period is based on the publishing interval configured on the CA. o When a client needs to check the validity of a certificate, it first checks its cached copy of

the CRL or delta CRLs. If the CRL is still valid, that information is used to validate the certificate. If the CRL is not valid, a new CRL or new delta CRL is downloaded.

o When a client needs to download a CRL, it tries the first location in the CDP list. If it cannot get a CRL from the location, it tries the next location, until a CRL is found or all locations are checked.

o If the client cannot get a CRL from any location, it returns a Revocation offline message.

Online Responder Facts

In addition to using CRLs for publishing a list of revoked certificates, Windows Server 2008 includes the Online Certificate Status Protocol (OCSP) service. With OCSP, a server known as an Online Responder receives and responds to requests from clients for information about the status of revoked certificates. The following process is used by a client to retrieve the certificate status information:

1. When a client receives a new certificate, it checks the certificate for information about how to verify the certificate status. When OCSP is used, CRL information normally included in the certificate is replaced with an HTTP URL for one or more online responders.

2. The client submits a certificate status request to a listed online responder. The request is for the status of a single certificate. If multiple certificates need to be validated, the client submits multiple requests.

3. The online responder checks the CRL from the issuing CA.

o The IIS web proxy service is the service that accepts client requests. As necessary, this service communicates with the OCSP service running on the system.

o If the online responder has a copy of the CRL in its cache, that CRL is used. o If the online responder does not have a copy of the CRL, one is downloaded from the CA.

Be aware that when using an online responder with Windows Server 2008, a CRL is still required.

However, the CRL is cached and checked by the online responder, not by each client.

4. The online responder replies with information about the certificate, indicating whether or not the certificate has been revoked.

o Each certificate status response includes a digital signature that validates the certificate status response.

o To sign the certificate status response, the online responder uses a certificate known as an OCSP Response Signing certificate.

o The OCSP Response Signing certificate is issued by the CA, and authorizes the online responder to respond to queries about the status of certificates issued by that CA.

o The online responder must obtain an OCSP Response Signing certificate from each CA for which it is authorized.

Using an online responder can reduce CRL processing by both the CA and client computers. CRL information is stored on a system that is dedicated to replying to status requests. In addition, network traffic to the client might be reduced due to the fact that the entire CRL is no longer downloaded by each client. However, network traffic could increase because the client must query about the status of each certificate.

Configuring the online responder requires the following process:

Process Description

Install the Online

Responder role

service

To create an online responder, install the Active Directory Certificate Services with

the Online Responder role service.

The server must be running Windows Server 2008.

IIS is required and added during the installation.

The Online Responder can be added to a server that is a CA. However, Microsoft recommends that you add the Online Responder role to a server that is not a CA.

Configure the OCSP

Response Signing

certificate

The OCSP Response Signing certificate is used by the online responder to sign

the certification status responses that it sends in reply to client queries.

If you are using an enterprise CA, duplicate the OCSP Response Signing certificate template.

Use a Windows 2008 (version 3) certificate if possible. Use a Windows 2003 (version 2) template only if you need to configure the Online Responder to respond to queries for certificates issued by Windows Server 2003 CAs

Allow the Read and Enroll permissions to the server that is the online responder. The Autoenroll permission should not be granted, and could

interfere with proper functioning of the online responder.

You can also configure a certificate for use by a standalone CA.

Configure each CA to

issue the OCSP

Response Signing

template

A single online responder can be configured to respond to certificate status

requests for multiple CAs. Configure each CA to issue the OCSP Response

Signing template. This allows the online responder to obtain an OCSP Response

Signing certificate from each CA. This certificate will be used to sign the

responses to queries about certificates issued by that CA.

Configure each CA to

include the online

responder

Each CA that will use an online responder must be configured to include the

online responder information in the certificates that it issues.

On each CA, edit the extensions list and add an HTTP URL to the Authority Information Access (AIA) extension list.

Use the format: http://servername/ocsp

After adding the entry to the list, select the following option: Include in the online certificate status protocol (OCSP) extension.

If the CA is a Windows Server 2003 server, you must also run a special certutil command to enable the server to recognize the OCSP extension.

Note: Configuring a CA to use an online responder does not eliminate the need to

configure CRL information, including specifying CRL distribution points. The CDP

list is used by the online responder to locate CRLs.

Configure revocation

configurations on the

online responder

A Revocation Configuration is a configuration entry on the online responder. The

Revocation Configuration contains:

The certificate for a CA.

The OCSP Response Signing certificate obtained from that CA.

Revocation provider information. A revocation provider is a method for obtaining information about revoked certificates. Windows Server 2008 supports only a CRL-based revocation provider. The revocation provider configuration identifies the location of CRL distribution points from which the CRL for the CA can be obtained.

Use the Online Responder Management console to create Revocation

Configurations.

Be aware of the following when configuring the online responder:

You should configure the online responder before configuring a CA to issue certificates for users or computers. This is because the online responder information is included in the issued certificates. If you configure an online responder after a certificate has been issued, hosts will use the CRL instead of the online responder to validate those certificates.

You can configure one online responder for multiple CAs. This means that clients can consult a single responder to get the status for certificates from multiple CAs.

To configure similar revocation provider information for multiple online responders, create a responder array. The array is a logical grouping of online responders, each with a common set of configuration values.

o One online responder is designated as the array controller (the master responder). Other responders are designated as array members.

o Revocation Configuration information in the controller is replicated (copied) to array members.

The following table describes additional features you can configure for the Revocation Configuration on an online responder.

Feature Description

Nonce/no-nonce

request support

Nonce stands for a number used once. Generally, it is a random number issued

in an authentication protocol to ensure that old communications cannot be

reused in replay attacks. Windows Server 2008 Online Responder supports

configuration options for nonce and no-nonce requests to prevent replay

attacks of Online Responder responses.

Advanced

cryptography

An Online Responder can be configured to use elliptic curve cryptography

(ECC) and SHA-256 cryptography for cryptographic operations.

Kerberos

protocol

integration

Online Responder requests and responses can be processed along with

Kerberos password authentication for prompt validation of server certificates at

logon.

You can configure a single CA with multiple online responders. o If you add multiple online responders to the AIA extensions for a CA, clients will attempt

to use the first online responder in the list for status queries. Additional responders in the list are used only if the first responder fails to answer.

o To provide load balancing across multiple online responders, use one of the following configurations:

Use clustering software such as Network Load Balancing (NLB) to create a cluster with multiple servers. Clients submit requests to the cluster. The cluster software distributes requests among cluster members.

Configure an ISA reverse proxy to create a server farm of online responders. The server farm identifies each online responder, and automatically distributes incoming requests to the various online responders. When using this configuration, create an online responder array to replicate the Revocation Configuration between online responders.

o Simply creating an online responder array does not guarantee load balancing; it only provides a way to manage multiple online responders, all with identical settings.

CA Management Facts

The ability to manage the CA and its configuration is controlled through the following permissions:

Permission Description

Read Allows a user or group to read the CA's configuration information.

Issue and Manage

Certificates Allows a user or group to approve, deny, or revoke certificates.

Manage CA Allows a user or group to access and modify the CA properties.

Request Certificates Allows a user or group (generally the Authenticated Users group) to request

certificates.

You can perform management tasks through the Certification Authority snap-in, or you can use the certutil.exe command line utility to perform the same tasks. The table below describes common CA management tasks.

Task Description

Certificate

Management

Delegation

By default, all users that have the Issue and Manage Certificates permission can manage all certificates for all users on the CA. Use the Certificate Managers tab to customize the certificates that a manager can manage based on the template or requesting user or computer. You can:

Restrict managers to the administration of specific certificate templates.

Control the groups for which managers can administer specific templates.

Enrollment Agent

Delegation

Use the Enrollment Agents tab to enforce the same controls for enrollment agents that

you enforce for certificate managers.

Key Archival

Use the Recovery Agents tab to configure key archival. When you activate key archival:

The CA encrypts and stores the key for a version 2 or 3 certificate template. After the client generates the key pair, it encrypts the private key and sends it back to the CA. The CA verifies the private key, reencrypts it, and archives it

You define one or more Key Recovery Agents. These are users who are able to restore the archived keys in case they are lost.

You can only implement key archival if all your clients are Windows XP/2000 or later. Key archival only works with version 2 or 3 templates and with enterprise CAs to which the Windows server 2003 schema extensions have been applied.

Certificate

Request Handling

Use the Policy Module tab in the CA properties dialog to determine how certificate requests are handled. You can configure the following behaviors:

Use manual approval by an administrator.

Use the settings in the certificate template, if appropriate; otherwise, issue the certificate automatically.

Auditing

Use the Auditing tab in the CA properties dialog to configure auditing for the following events:

Back up and restore the CA database

Change CA configuration

Change CA security settings

Issue and manage CA requests

Revoke certificates and publish CRLs

Store and retrieve archived keys

Start and stop Certificate Services

Note: To perform CA auditing, you must enable Object Access auditing in Group

Policy or in the Local Security Policy.

Backup and

Restore

The preferred method of backing up a CA is to take a system state backup using

Windows Server Backup or another backup tool. A system state backup will back up

the CA database, the CA key pair, the registry, IIS metabase, and all of the system

files. In all cases the backup media should be stored in a secure location.

You can use the Certification Authority console to back up the CA, but this does not back up IIS and other non-CA settings.

Be aware of the following certutil parameters:

-Verify verifies whether a certificate is valid.

-VerifyStore verifies a certificate in a certificate store on the computer.

-VerifyKeys verifies a public/private key set.

-RecoverKey recovers an archived private key.

-oid displays an object ID or sets a display name.

To move a CA from one server to another, back up the CA and CA-related registry settings on the source CA. On the target CA, take the following steps:

1. Install Certificate Services. 2. Stop the CA service. 3. Restore the CA settings from the backup. 4. Restore the registry settings. 5. Start the CA service. 6. Reconfigure issued templates. The certificate templates are stored in Active Directory, and the

templates that are issued by the server are not saved as part of the regular backup.

In addition, you might need to reconfigure CA permissions and CRL settings on the new CA.

Smart Card Deployment

A smart card has the ability to store and process information, giving it the ability to perform its own cryptographic operations. The storage portion of a smart card uses a file system that can be partitioned into public and private spaces, allowing you to store private keys and certificates securely. Smart cards are typically used to provide secure, multi-factor authentication. Only users with the smart card and who know the associated PIN number are allowed to authenticate. Computers that require a smart card must have a smart card reader attached.

Smart card deployment requires the following:

An enterprise certificate authority

Active Directory

A Cryptographic Service Provider (typically provided by the smart card reader manufacturer)

Microsoft recommends that you use a smart card deployment station to enroll smart card users. Specialized hardware and software on the enrollment station allows an authorized person (called the enrollment agent) to request and install the user certificate on the smart card. Smart card administration uses the following certificate template types.

Certificate

Template Description

Enrollment

Agent

A certificate issued based on the Enrollment Agent certificate allows a user to request a

certificate on behalf of another user. The enrollment agent uses the smart card

deployment station to request a certificate for another user and to save the user

certificate to the smart card.

Enrollment

Agent

(computer)

A certificate issued based on the Enrollment Agent (computer) template enables a user

to request a certificate on behalf of a computer.

Smart Card

Logon

A certificate issued based on the Smart Card Logon template can be used only for logon

(not for encryption).

Smart Card

User

A certificate issued based on the Smart Card User template can be used for logon as

well as encryption.

Note: Users must have the appropriate permissions to request a certificate of a specific type.

By default, only members of the Domain Admins group have permission to request a certificate based on the Enrollment Agent template. To designate other enrollment agents, modify the permissions on the certificate template, and have these users request an Enrollment Agent certificate.

Users must have necessary permissions to the corresponding certificate template in order to obtain a certificate. Only the intended user, not the enrollment agent, must have permissions to the user certificate templates.

With the autoenrollment permission, certificates can be renewed automatically. Generally, when a smart card has space and the CSP (Cryptographic Service Provider) allows multiple keys on a single card, autoenrollment asks the card to generate a new key for enrollment. If this is possible, autoenrollment writes the certificate to the card. If it cannot generate a new key, the old key will be used, and a certificate is forced onto the card. When this occurs an event is written to the Application log.

When multiple certificates are available on a smart card or token (e.g., a signing certificate and an encryption certificate), the signing certificate must be the default certificate.

The enrollment agent capability was removed from Web enrollment in Windows Server 2008 because Windows Vista provides its own enrollment agent capability. If you need to perform enrollment on behalf of another client with a Windows Server 2008 Web enrollment, you should use computers running Windows Vista as enrollment stations. Alternatively, you can use a

Windows Server 2003-based server with Web enrollment installed and use that server as an enrollment agent to enroll certificates through a Windows Server 2008-based CA.

You can enforce the use of smart cards for users or computers using Group Policy and Active Directory.

To require smart cards for computer logon (regardless of the user), enable the Interactive logon: Require smart card policy in the Security Options for Computer Configuration.

To require smart cards for logon for a specific user (regardless of the computer), edit the user account and select the Smart card is required for interactive logon option. When enabled, the user account will not be able to log on to a computer that does not have a smart card reader.

Use the Interactive logon: Smart card removal behavior policy to control what happens when a smart card is removed. For example, you can lock the workstation or log off the user automatically.

Authentication mechanism assurance (AMA) is an added capability in Windows Server 2008 R2 AD DS that adds an administrator-designated group membership to a user's access token when the user's credentials are authenticated during logon using a certificate-based logon method, such as a smart card. Without authentication mechanism assurance, there is no distinction in the access token of a user who logs on with certificate-based authentication and a user who logs on with a different method of authentication. Be aware of the following details:

The administrator may designate the specific group that is to be added. This group may be used in conjunction with NTFS permissions to allow access to resources.

The administrator can distinguish between different types of certificates to secure resources.

Authentication mechanism assurance requires: o A Windows Server 2008 R2 domain controller running at the Windows Server 2008 R2

domain functional level o An enterprise CA o Domain member client computers or servers running Windows Vista, Windows 7,

Windows Server 2008, or Windows Server 2008 R2

Key Archival

Key archival (also called key escrow or centralized key management) is the process of saving a copy of the private key in a central location so that it can be restored if it is destroyed or lost. On a Windows CA, you can back up private keys using the following methods:

To back up the CA's private key, use the Certification Console to perform a CA backup. For the items to back up, choose Private key and CA certificate.

To back up a user's private key, have the user run the Certificates snap-in and export the private key. Before the private key can be exported, the certificate template must have the Allow private key to be exported option set.

To back up all of the private keys for certificates issued by a CA, enable and configure key archival. Using key archival:

o The CA encrypts and stores the key for a version 2 or 3 certificate template. After the client generates the key pair, it encrypts the private key and sends it back to the CA. The CA verifies the private key, reencrypts it, and archives it

o You define one or more Key Recovery Agents. These are users who are able to restore the archived keys in case they are lost.

o You can only implement key archival if all your clients are Windows XP/2000 or later. Key archival only works with version 2 or 3 templates and with enterprise CAs to which the Windows server 2003 schema extensions have been applied.

Enabling key archival requires designating key recovery agents, and enabling archival on both certificate templates and the CA. Use the following steps to configure key archival:

1. Configure the Key Recovery Agent certificate template. Grant the key recovery agents the Read and Enroll permissions to the template. Have each enrollment agent request a Key Recovery Agent certificate.

2. For each certificate template issued by the CA whose keys you want to archive, edit the template properties. On the Request Handling tab, select the Archive subject's encryption private key option.

3. On the CA, edit the CA properties. On the Recovery Agents tab, select the Archive the key option, then add the certificate of one or more authorized recovery agents.

Network Device Enrollment Service (NDES)

The Network Device Enrollment Service (NDES) makes it possible for software running on network devices such as routers and switches (which cannot otherwise be authenticated on the network) to enroll for certificates from a CA. Certificates obtained by these devices are typically used for enabling IPsec.

NDES uses the following components:

Component Description

Network device

The network device is the router, switch, or other device that needs to obtain a

certificate. Network devices are devices that are unable to request a certificate directly

from the CA, for example non-Windows devices that are not domain members.

Device

administrator

The device administrator is the person responsible for managing the network device.

If you are using an enterprise CA, the administrator must have permissions to obtain the necessary certificates.

If you are using a standalone CA, the administrator must be a member of the CA Administrators group.

Registration

authority (RA)

The registration authority (RA) is a Windows server that is running the NDES service.

If you are using an enterprise CA, it is recommended to install the NDES service on a server other than the CA.

If you are using a standalone CA, it is recommended to install the NDES service on the CA.

The process for obtaining a certificate for the network device is as follows:

1. On the network device, the device administrator runs the software included with the device to generate a key pair.

2. The device administrator connects to the registration authority and requests a password that will be included with the certificate request.

o Use the following URL to request the password: http://servername/certsrv/mscep_admin

o The password is returned in a Web page generated by the RA.

3. On the network device, the device administrator completes the certificate request process. The certificate request is submitted to the RA and includes the password. Use the following URL to request the certificate: http://servername/certsrv/mscep

4. The RA forwards the certificate request to the CA. 5. The CA approves the certificate request and returns the certificate to the RA. 6. The RA returns the certificate to the network device.

To configure NDES:

1. Create a user account that will be used for the NDES service. This user account must be a member of the IIS_IUSRS built-in group on the local system.

2. On the RA, install the Active Directory Certificate Services role with the Network Device Enrollment Service (NDES) role service. The RA does not need to be a CA. During the installation, you will specify the NDES service user account and the CA to which certificate requests received from the RA should be submitted.

3. If you are using an enterprise CA, configure certificate template permissions to allow the necessary entities to request certificates. The following table lists the three certificate template types that are used:

Template Permissions

Exchange

Enrollment Agent

(Offline request)

This certificate template is an enrollment agent certificate that enables the

necessary components in the request process to request a certificate on

behalf of the network device. The registration authority requests this

certificate for itself. Assign the following permissions to this template:

o Allow the Enroll permission to the user responsible for managing the RA.

o Allow the Read and Enroll permissions to the RA service account you created in step 1.

o Allow the Enroll permission to the device administrator.

CEP Encryption

This certificate template is a key exchange certificate that identifies how key

information will be exchanged securely. The registration authority requests

this certificate for itself. Assign the following permissions to this template:

o Allow the Enroll permission to the user responsible for managing the RA.

o Allow the Read and Enroll permissions to the RA service account you created in step 1.

o Allow the Enroll permission to the device administrator.

IPsec (Offline

request)

By default, the RA is configured to request an IPsec certificate for network

devices. This will be the template that is used to issue a certificate to the

network device. Assign the following permissions to this template:

o Allow the Read and Enroll permissions to the RA service account you created in step 1.

o Allow the Enroll permission to the device administrator.

You can configure the RA to request a certificate based on a different

template if desired.

4. Configure the CA to issue the three required templates.

Be aware of the following when using NDES:

When you add the NDES service, IIS is installed if it does not already exist. Two virtual directories are created in IIS:

o The certsrv/mscep_admin virtual directory is used to submit password requests. o The certsrv/mscep virtual directory is used to submit certificate requests from the

network device.

By default, the RA can accept only 5 active registrations at a time. The registration status is determined by the password.

o The RA can issue only 5 passwords for certificate requests. If you need more active requests, increase the number of allowed passwords.

o After 60 minutes, the password expires and cannot be used to complete the request. You must request a new password if the password has expired.

o If you restart IIS, the password cache is cleared. This allows new password requests, but also invalidates any current passwords.

o You can configure the RA to accept requests without a password.

Instead of modifying the templates used for NDES, you should duplicate the template to create a new one. When you do this, you must modify the registry settings on the RA to identify the new template names to use.

Certificate Roles

The following table summarizes the configuration tasks required to allow users to manage various aspects of Active Directory Certificate Services:

Role Description

Certificate

template

creator

A certificate template creator has the ability to duplicate existing certificate templates to

create new ones.

By default, only Domain Admins in the forest root or Enterprise Admins can create new templates.

You can grant others this ability by modifying Active Directory rights and permissions.

The ability to create certificate templates is not controlled by template permissions.

Certificate

template

manager

A certificate template manager has the ability to edit certificate template settings.

Grant Read and Write permissions to the template to allow a user to edit properties except for the DACL.

Grant Full Control permission to the template to allow a user to edit all properties, including the DACL.

CA manager The CA manager has the ability to manage the configuration of a CA. Grant the Read and

Manage CA permissions to the CA.

CA certificate

manager

The CA certificate manager can approve and revoke certificate requests.

Grant the Issue and Manage Certificates permission to the CA to designate a CA certificate manager.

On the CA, use the Certificate Managers tab to restrict certificate management for specific managers to certain templates or subjects (user, computer, or group).

Enrollment

agent

An enrollment agent is a user who can request certificates on behalf of another subject.

Enrollment agents are typically used for smart card enrollment.

To designate an enrollment agent, issue the user an Enrollment Agent or Enrollment Agent (Computer) certificate. To allow the user to request the certificate, grant the Read and Write permissions to the template.

Enrollment agents do not need permissions to the user or computer certificates. For example, the enrollment agent does not require any permissions to the Smart Card Logon template in order to request a certificate for a user.

By default, enrollment agents can request any certificate for any user. To restrict certificates based on template or subject, edit the Enrollment Agents settings on the CA.

Recovery

agent

A recovery agent is a user who is authorized to recover the private keys associated with a

certificate. To configure a recovery agent:

1. Issue the Key Recovery Agent certificate to the designated recovery agents. To allow the user to request the certificate, grant the Read and Write permissions to the template.

2. For each certificate template issued by the CA whose keys you want to archive, edit the template properties. On the Request Handling tab, select the Archive subject's encryption private key option. Note: The recovery agent does not need permissions to the target certificate templates.

3. On the CA, edit the CA properties. On the Recovery Agents tab, select the Archive the key option, then add the certificate of one or more authorized recovery agents.

For a subject to request a certificate, configure the following:

Grant the Read and Enroll permissions to the template. To configure autoenrollment: o Grant the Read, Enroll, and Autoenroll permissions to the template. o Enable autoenrollment for computers or users through Group Policy.

Grant the Read permission to the CA.

AD LDS Facts

Active Directory Lightweight Directory Services (AD LDS), formerly known as Active Directory Application Mode (ADAM), is an LDAP directory service that you can use to create a directory store (database) for

use by directory-enabled applications. AD LDS is very similar to Active Directory Domain Services (AD DS).

AD LDS is based on the X.500 directory standard.

AD LDS uses the same database engine as AD DS. The database is stored in a file called Adamntds.nit.

DNS is not required to implement an AD LDS database.

AD LDS does not include many AD DS features such as Group Policy, Global Catalog, or Kerberos authentication.

AD LDS does not require the deployment of domains or domain controllers.

You can install an AD LDS on domain members or non-domain members with the following operating systems:

o Microsoft Windows Server 2008 with a full feature set. o Any edition of Windows Server 2003 with a full feature set. o Microsoft Windows XP Professional with limited features for a stand-alone deployment.

Stand-alone AD LDS installations require an account that has permissions to run the AD LDS service. In an environment of multiple, stand-alone AD LDS installations, create the same service account user name and password on each stand-alone AD LDS installation for replication.

Like AD DS, AD LDS uses a schema that defines the objects and attributes within the database. You can customize the schema to define your own objects or attributes.

AD LDS is compatible and consistent with traditional Active Directory in that it manages and accesses application data using the same Application Programming Interfaces (API) as Active Directory, namely:

o Active Directory API o Active Directory Service Interfaces o Lightweight Data Access Protocol o System.DirectoryServices

Active Directory and AD LDS can exist and operate concurrently in the same environment. o AD LDS can be created for specific applications without worrying about any

dependencies Active Directory may otherwise require of the application. o If desired, you can synchronize data from Active Directory into an AD LDS instance. o AD LDS can use AD DS for the authentication of Windows security principals.

An instance (also called a service instance) is a single running copy of AD LDS.

Multiple instances of AD LDS (multiple distinct databases) can run simultaneously on the same computer.

You can selectively start, stop, and restart instances running on a computer.

You can replicate an instance between servers, meaning that multiple servers have the same copy of the database. Create a configuration set to group AD LDS instances that hold copies of the same directory partition or partitions.

For instances within a configuration set, multimaster replication copies changes made from any instance to all other instances in the set. Replication does not occur outside of the configuration set.

Use configuration sets to provide for fault tolerance, load balancing, and geographic placement of an AD LDS instance.

You can configure the configuration set to exclude some partitions from replication. A single AD LDS instance can replicate all, or any subset of, the application directory partitions in its configuration set.

AD LDS Configuration Facts

Configuring AD LDS involves installing the AD LDS role through the Add Roles feature in Server Manager, and then adding one or more instances to the server. To configure a new instance, you will need to:

Specify the instance name. The instance name must be unique on the server.

Choose the LDAP and SSL port numbers used to connect to the instance. o If the server is a domain controller, or will be used as one, do not use port 389 for LDAP

or 636 for SSL. o If AD DS is detected on the system, the configuration wizard automatically selects

available ports above 50000.

For new instances, specify whether or not to create an application directory partition. o If the application creates its own partition, do not create one during the install. o To create the partition, specify the distinguished name for the partition (for example:

CN=Partition1,DC=westsim,DC=local).

Select the service user account used by AD LDS and the user account who has administrator privileges to the instance.

For new instances, select LDIF files to import. These files have predefined schema and object information.

For a replica instance, select the user account with permissions to the source configuration set.

For a replica instance, specify the source server (using its DNS or NetBIOS name), and select the partitions you want to replicate.

Use the following tools to manage AD LDS instances:

Tool Description

Active Directory

Lightweight Directory

Services console

Use the Active Directory Lightweight Directory Services console to create new

instances, start and stop instances, and launch common AD LDS

management tools.

Adaminstall.exe

Use Adaminstall.exe to create an instance using an unattended file. See the

following for two examples of answer files used with Adaminstall.exe:

Install a New Instance

Install a Replica Instance

Once your answer file has been created, type the following into a command prompt. Use quotation marks if the file name includes spaces.

c:\ADAM\adaminstall.exe /answer:C:\unattend.txt

ADSI Edit

Use ADSI Edit to query, view, and edit objects and attributes in the directory.

You must first connect and bind to the instance to use ADSI Edit to administer

an AD LDS instance. You can perform the following tasks in ADSI Edit:

Create and AD LDS group or user. To do this, you must first import the optional user classes that are provided with AD LDS into the AD LDS schema. User classes are located in importable .ldf files found in the directory %windir%\ADAM on the computer where AD LDS is installed.

Add or remove members in an AD LDS group.

Disable or enable AD LDS user accounts to control whether or not a

user can bind to the AD LDS directory.

Create a replication schedule for a configuration set.

Ldp.exe Use Ldp.exe to perform LDAP operations against the directory. For example,

you can search, modify, add, and delete objects and attributes.

Ldifde Use Ldifde.exe to import, export, modify, and delete objects using LDAP Data

Interchange Format (LDIF) files.

Active Directory Schema

snap-in

Use the Active Directory Schema snap-in to view and manage AD LDS

schema objects. By default, the AD schema snap-in must be registered and

added to the console before you can make changes to the role. To register the

Dynamic Link Library (DDL) for the AD Schema snap-in, type regsvr32

schmmgmt.dll at the command prompt.

Active Directory Sites and

Services snap-in

Use the Active Directory Sites and Services snap-in to connect to your AD

LDS instance to administer the replication of directory data among all sites in

an AD LDS configuration set. This snap-in can be used by accessing the

Active Directory Sites and Services option from Administrative Tools on the

Start menu.

ADSchemaAnalyzer

Use ADSchemaAnalyzer to:

Quickly copy the schema from AD DS and import it into AD LDS.

Help migrate the AD DS schema to AD LDS, from one AD LDS instance to another, or from any LDAP-compliant directory to an AD LDS instance.

Load a target (source) schema, mark the elements that you want to migrate, and then export them to the base AD LDS schema.

You can build your own schema using ADSchemaAnalyzer to make custom LDIF files if you are building a custom application. If you need to copy data from an existing AD DS deployment into the new AD LDS instance, it is difficult to build the schema file.

Dsacls

Use Dsacls to view, grant, or deny permissions on an object-by-object basis.

Like AD DS permissions, objects in the directory inherit the permissions

specified by the ACL that is located in the top-level object of each directory

object partition, as well as obtaining permissions assigned directly to specific

objects.

AD LDS Management Facts

You should be aware of the following methods of AD LDS instance configuration:

Method Description

Move an An AD LDS replica instance can be moved into a site object by using the Active

instance Directory Sites and Services. Membership in the Administrators group or equivalent is

required to complete this procedure.

1. Open Active Directory Sites and Services from the Administrative tools in the Start menu.

2. Click on Change Domain Controller, then specify the name and the port number of the server that holds the AD LDS instances in the configuration set for which you want to create site objects.

3. Open the Servers container by double-clicking the Sites container, then double-clicking the site that contains the AD LDS instance that you want to move, then double-clicking the Servers container.

4. In the Servers container, right-click the AD LDS instance that you want to move, then click Move.

5. In the Move Server dialog box, select the site to which you want to move the AD LDS instance, then click OK.

Import data into

an instance

Data can be imported into an AD LDS instance in the following ways:

Using the Importing LDIF Files page in the AD LDS Setup Wizard during setup of the instance.

Manually, by using the Ldifde command anytime after creation of the instance.

Prior to importing the data, use the Ldifde tool to export the data from an existing

LDAP directory.

Create a

replication

schedule

A replication schedule for an AD LDS instance can be created using ADSI edit.

Scheduling replication is optional; the AD LDS replication schedule is set to the Once per Hour option by default.

Because intrasite AD LDS replication uses update notifications to replicate data, intrasite replication is only affected by a replication frequency schedule when no update notifications occur in the specified time frame.

Synchronize

data

Use the Adamsync /sync command to synchronize data from an AD DS forest to the

configuration set of an AD LDS instance.

The AD LDS instance must have been configured by importing the MS-AdamSyncMetadata.LDF file.

You must run the command each time you want to synchronize data.

AD LDS must verify the user's credentials or bind users into the directory through successful authentication before they can request directory data. Binding to an AD LDS instance takes place in the following ways:

The user account resides directly in AD LDS. You can bind as an AD LDS security principal using Ldp.exe in Server Manager.

The user account resides on a local computer or in an Active Directory Domain Services domain. You can bind as a Windows Security principal using the ADSI Edit snap-in.

The user is bound through an AD LDS proxy object using redirection. This allows AD LDS to accept and process bind requests to an AD LDS proxy object that has the Security Identifier (SID) from an AD DS security principal as one of its attributes. A user who binds to an AD LDS instance through a proxy object receives membership in the Users group on each naming context that is held by the AD LDS instance. Bind redirection provides the following benefits:

o Binding provides AD DS users with access to both AD LDS data and AD DS data using AD DS domain credentials for Single Sign-On (SSO).

o AD LDS proxy objects can be used to store user data that is specific to a particular application in AD LDS, while using AD DS to store more widely used directory data.

o Unlike other types of binding, bind redirection enables a user to bind to AD LDS by means of a simple bind while still using AD DS credentials.

You should know the following about configuring security principles and binding:

Passwords can be set for security principals either by using ADSI Edit or by using Ldp.exe over an encrypted, non-SSL connection.

You can set or modify a password for an AD LDS security principal using the ADSI Edit snap-in.

AD LDS allows the use of Windows security principals for authentication and access control.

Windows users can be members of AD LDS groups.

A Windows user binding to an AD LDS instance receives membership only in the AD LDS groups to which that user has been explicitly added as a member.

AD FS Facts

Active Directory Federation Services (AD FS) is a secure solution that allows browser-based clients to access one or more protected Internet-facing applications regardless of whether the account and application are located in the same network or organization. AD FS:

Secures trust relationships that makes a user's digital identity and access rights available to trusted partners, thus making the need for secondary credential requests unnecessary.

Allows organizations to provide access to resources that are offered by trusted partners across the Internet.

Retrieves user attributes from Active Directory.

Uses Windows Integrated Authentication.

Uses strong authentication technologies such as Kerberos, X.509 digital certificates, and smart cards.

Uses Lightweight Directory Access Protocol (LDAP) binding to authenticate users when it is employed with AD LDS.

Enables Single Sign-On (SSO), where an end user can access resources within multiple systems or organizations without having to repeatedly supply their logon credentials.

AD FS is designed for organizations that have:

At least one implementation of either AD DS or AD LDS.

An environment in which multiple different operating systems are deployed.

Computers that are domain-joined.

One or more Web-based applications implemented.

Computers that are connected to the Internet.

To understand how AD FS works, you need to be familiar with the following terms:

Term Definition

Claim

A claim is a statement made about a digital identity. A claim includes:

Identity information, such as the user name

Group memberships

Capabilities, rights, and privileges

A claims-aware application is an application that performs authorization for objects based

on claims.

Security

token

A security token is a digitally-signed object that contains claims for a given user. Following

successful authentication, the security token is issued. A Windows NT token-based

application is an application that uses Windows NT tokens (not claims) to authenticate

users.

Security

Token

Service (STS)

A Security Token Service (STS) is a Web service that issues security tokens based on

evidence provided by trusted entities.

Federation A federation is a set of domains or realms that have been configured to trust each other. A

federated application is another name for a claims-aware application.

Federation

server

A federation server is a server running the Active Directory Federation Service role.

Federation servers:

Host a security token service that takes user credentials and issues security tokens according to the user credentials.

Collect claims for users by examining user attributes stored in AD DS or AD LDS.

Federation

trust

A federation trust is a one-way, non-transitive relationship between two organizations.

Each trust has two members:

The account partner is the member that maintains the user accounts and is trusted to provide security tokens. The account partner is responsible for:

o Storing user accounts in either an Active Directory store or an AD LDS store.

o Collecting and authenticating user's credentials. o Building up claims for users. o Packaging claims into security tokens. o Issuing security tokens to users in the account partner realm.

The resource partner is the member that holds resources that need to be accessed by users. The resource partner is responsible for:

o Validating the security tokens issued by the account partner. o Consuming (reading or interpreting) the claims that are packaged in

security tokens to make authentication decisions regarding the level of resource access allowed. Claim mapping is the process of examining an incoming claim and filtering it to extract appropriate authorizations for a user.

o Issuing security tokens for the applications.

o Issuing cookies to the user accounts. These cookies allow the user to maintain Single Sign-On (SSO) login status when the user accesses multiple applications at the resource partner.

The account partner can be compared to an Active Directory domain that contains user

accounts that need access to resources that are located in another forest. The resource

partner is like the Active Directory domain that holds the necessary resources.

Trust policy

A trust policy is the configured parameters that identifies trusted partners, certificates,

account stores, claims, and the various properties of the entities that are associated with

the federation service.

AD FS-

enabled Web

server

An AD FS-enabled Web server is a Web server that is running the necessary services to

allow it to host claims-aware applications.

AD FS 2.0 is the latest version available in Windows Server 2008 R2. With AD FS 2.0, organizations can bypass requests for secondary credentials by providing trust relationships (i.e., federation trusts) to project a user's digital identity and access rights to trusted partners. In a federated environment, each organization continues to manage its own identities, but each organization can also securely project and accept identities from other organizations. ADFS 2.0:

Reduces the need for duplicate accounts and other credential management overhead by enabling federated SSO across organizations, platforms, and applications.

Provides for identity delegation so that authorized applications can impersonate their users when they access infrastructure services, even when the original users do not have local accounts.

Enables step-up authentication so that Web sites can request smart-card authentication.

Uses the Security Assertion Markup Language (SAML) protocol to authenticate and authorize users across secure boundaries.

AD FS Configuration Facts

You should be aware of the following when implementing AD FS:

You can only install Active Directory Federation Services (AD FS) on domain members.

AD FS requires Windows Server 2003 R2 or higher. It runs on only the Enterprise or Datacenter versions. The AD FS Web Agent can be installed on Standard edition servers.

AD FS requires IIS, ASP.NET 2.0, and the .NET Framework 2.0.

AD FS requires access to user accounts in either AD DS or AD LDS. Domain controllers require Windows 2000 with Service Pack 4 or higher.

During installation, you select one of the following role services to install:

Role Service Description

Federation

Service

Installing AD FS runs the Federation Service on the server. The Federation

Service:

o Functions as a security token service. o Collects and verifies user credentials against Active Directory or ADAM

to provide security tokens. o Routes authentication requests from user accounts in other

organizations or from Internet clients. o Determines which organization will authenticate a user. o Verifies that tokens have been correctly signed by the correct partner.

Federation

Service Proxy

The Federation Service Proxy forwards requests to federation servers that are

not accessible from the Internet. The Federation Service Proxy:

o Uses WS-Federation Passive Requestor Profile (WS-F PRP) protocols: To collect user credential information from browser clients. To relay requests from Web applications to the Federation

Service. o Stores HTTP authentication, account partner, and sign-out cookies for

clients to facilitate SSO.

Note: It is not necessary to deploy a separate server to act as a federation

server proxy; federation servers perform this role automatically. However, if you

use a proxy, it cannot be installed on a server running the Federation Service.

Claims-aware

Agent

The claims-aware agent is installed on Web servers that host claims-aware

applications (Microsoft ASP.NET applications). The agent allows the claims-

aware applications to query AD FS security tokens to make authorization

decisions and personalize applications.

Windows NT

Token-based

Agent

The Windows token-based agent is installed on a Web server that hosts

Windows NT token-based applications. It converts AD FS security tokens to

impersonation-level Windows NT access tokens so they can be used by the

token-based application.

You cannot install the Federation Service and the Federation Service Proxy on the same computer. You can, however, install one or both Web agents together with either the Federation Service or the Federation Service Proxy.

AD FS requires that each server have a certificate that is used for SSL communications. For implementations within your organization, you can issue a certificate from your own CA. When used with external organizations, obtain a server certificate from a third party.

A federation server requires a certificate for issuing tokens; the token is digitally signed to verify that the token was issued by the federation server. This can be the same certificate used for SSL.

When installing the Windows NT Token-based Agent, you must specify the Federation Service Proxy or the Federation Service that the agent communicates with.

During installation, you can select an existing trust policy or create a new one.

Installing an AD FS role also installs IIS if it does not yet exist.

Following installation, use the Active Directory Federation Services console to manage AD FS. For the Federation Service, you configure the following elements of the trust policy:

Component Description

Organization Organizational claims identify the types of information about users that is understood and

Claims processed by AD FS. You can identify the following types of claims:

An identity claim is used to identify the user. Information that can be used for identity are the UPN name (such as user1@mydomain.com), an e-mail address, or a common name.

A group claim describes membership in a group or a role. For example, you list the names of groups to which the user belongs.

A custom claim is a custom attribute, such as an employee ID number, that you can define.

Account Stores

The account store identifies the database that holds the user accounts (either AD DS or

AD LDS). When you enable the account store, AD FS can use account information for

authentication.

After you select and enable the account store, you must map the organizational claims to the attributes in the account store. For example, you would map the e-mail address identity claim to the e-mail address attribute for a user account.

The UPN claim is automatically mapped.

To map the e-mail address or common name claims, edit the existing mapping and specify the attribute using the LDAP syntax.

To map group claims, create a Group Claim Extraction.

To map custom claims, create a Custom Claim Extraction.

Applications

Configure applications to identify the claims- or Windows NT-based applications. When

you configure the application, the Federation Service is authorized to issue tokens for the

application, and users from the account store and account partner are given access. To

configure the application:

Identify the application type (claims- or token-based).

Configure the URL to run the application.

Identify the types of claims that are accepted for the application. Note: To enable a claim for use by an application, the claim must first be defined in the list of organizational claims.

In addition to configuring the AD FS settings, you will need to configure application

settings in IIS.

Partner

Organizations

When you define partner organizations, you create one side of the federation trust.

You create the trust on your server; the partner organization must create a corresponding trust.

When you define the trust, you identify the partner as either an account partner (i.e. the other organization maintains the user accounts) or as a resource partner (the other organization has the resources that your accounts need to access).

If you define an account partner, the other organization must define a corresponding resource partner definition to identify your organization. If you define a resource partner, the other organization must define a corresponding account partner definition to identify your organization.

When you define the partner organization:

For an account partner, you must import the certificate of the federation server where the accounts reside.

For both partner types, select the scenario that identifies the trust relationship: o Chose Federated Web SSO with Forest Trust to establish a trust with

a target forest where an Active Directory forest trust already exists. o Choose Federated Web SSO to establish a trust with a different

organization when a forest trust does not exist.

Select the claims that will be used for the trust. o For an account partner, you identify the UPN or e-mail suffixes that you

will accept. o For a resource partner, you identify the claims you will provide. Note:

You can configure the claims to replace domain suffixes with a new value. For example, if your UPN suffix is @westsim.com, you can configure the claim to replace this with a new value, such as @partner.com.

For both partner types, export the trust policy to an .xml file which will be delivered to the other partner. The other partner will import the trust policy.

The basic process for configuring AD FS is:

1. Install the AD FS role. 2. Configure claims to specify the user account information that will be included in the claims. 3. Enable a user account store, either AD DS or AD LDS. 4. Map claims to attributes in the user account store. 5. Identify applications that will be consumed (used), configuring the claims that are accepted by the

application. 6. Define account or partner organizations.

Corresponding steps must also be performed at the partner organization to create the other side of the trust.

AD RMS Facts

Active Directory Rights Management Services (AD RMS) is an additional server role that helps safeguard digital information from unauthorized use.

Usage policies define users and the permitted actions they can perform on digital media. For example, you can prevent copying, printing, modifying, or even viewing files. Usage policies remain with the file, regardless of where it is moved. This prevents intentional or unintentional misuse of electronic documents.

Administrators can define usage policy templates that configure predefined levels of access. When a template is applied to the document, the rights assigned to that template are propagated to the document restricting user access. Rights include the following:

o Full Control: The right to exercise all rights. o View: The right to view protected content. o Edit: The right to change and then save protected content. o Save: The right to change and then save protected content. o Export: The right to use the Save As command. o Print: The right to print protected content. o Forward: The right to forward a protected email.

o Reply: The right to reply to a protected email. o Reply All: The right to reply to all recipients of a protected email. o Extract: The right to copy and paste content from a protected document. o Allow Macros: The right to allow the user to use macros in a protected document. o View Rights: The right to view the permissions assigned to the document. o Edit Rights: The right to edit the rights assigned to the document.

The ability to work with protected content is controlled through various licenses. o A client license is issued to a user, and identifies the user as the owner of the content.

Only the owner can define or modify usage rights. Usage rights and protected documents are created from within RMS-enabled

applications, such as Microsoft Office 2007 Enterprise, Professional Plus, or Ultimate (one of these versions is required to create protected content).

o A publishing license is issued for each protected document. This license contains the usage right information. Following issuance of the publishing license, the document content is encrypted by the AD RMS-enabled application.

o A use license is issued to the recipient or user after AD RMS authenticates the user and verifies the usage rights defined for that user. Authorized users can only open rights-protected files on an RMS-enabled client computer and within an RMS-enabled browser or application.

An AD RMS system has the following components:

Component Description

AD RMS

server The AD RMS server is responsible for issuing licenses.

Database

server

The database server stores configuration and policy information. The database

can be hosted by the Windows Internal Database or another database server

(such as a SQL server). Note: Using the Internal Database is not recommended

in a production environment.

AD DS

The RMS server must be able to contact a domain controller for user

authentication and other information. AD RMS uses Active Directory Domain

Services (AD DS) to regulate access to all AD RMS users in the AD DS forest

that have rights-protected content. If AD DS is not available, AD RMS cannot

grant licenses to publish and consume rights-protected content.

AD RMS-

enabled

application

The RMS-enabled application is responsible for:

o Providing the method to create digital content. o Allowing authors to set usage policies. o Encrypting content after the publishing license is obtained. o Enforcing usage policies by allowing only the defined actions to be taken

based on the publishing and the use licenses.

AD RMS client

The AD RMS client facilitates communication between the server and the

application. Windows Vista and later include the AD RMS client by default; other

client operating systems must have the AD RMS client installed.

AD RMS Add- The Windows Rights Management Add-on for Internet Explorer allows a user to

on for IE view the protected content in the Internet Explorer browser. You must install the

AD RMS client before installing the AD RMS Add-on for IE.

AD RMS can be implemented with Active Directory Federation Services (AD FS) to allow partner organizations access to controlled content.

AD RMS trust policies allow users to share rights-protected content across internal or external Active Directory Domain Services (AD DS) forests.

AD RMS supports the following trust hierarchies: o The ISV hierarchy is used for developing AD RMS-enabled applications. o The production hierarchy should be used for all production installations of AD RMS,

unless you are developing an AD RMS-enabled application.

You can add AD RMS domains to a list of trusted user domains in an AD RMS cluster. This allows Active Directory Rights Management Services to process requests from users whose RACs were issued by a different AD RMS cluster. For each trusted user domain, you must specify which e-mail domains are trusted. It is an important security step to configure e-mail domains, otherwise it may be possible for a user from a trusted user domain to impersonate an internal user.

AD RMS consists of the following services: o Logging services send logging information from each server in the AD RMS cluster to the

logging database. o Web services provide communication between computers in the AD RMS cluster.

Both Windows Mobile 6 Standard Edition and Windows Mobile 6 Professional Edition provide support for clients to use AD RMS. The requirements for the Windows Mobile 6 clients to use AD RMS are:

o The AD RMS server must be located in the same forest as the accounts of the users who will use AD RMS on their Windows Mobile Devices.

o A domain-joined computer running Windows XP, Windows Vista or Windows 7 that is able to access both the AD RMS server and the Windows Mobile device.

o A sync client must be installed on the domain-joined computer.

Support for Windows Mobile devices is disabled at the AD RMS server. You can enable the certification of mobile devices by giving the AD RMS Service Group and the user accounts Read and Read & Execute permissions to the MobileDeviceCertification.asmx file, located under %systemdrive%\Inetpub\wwwroot\_wmcs\Certification by default.

AD RMS Installation Facts

AD RMS has the following hardware and software requirements:

The AD RMS role must be installed on a Windows Server 2008 or Windows Server 2008 R2 domain member or domain controller. It cannot be deployed on a server that is part of a workgroup. Domain controllers must be running Windows Server 2000 with Service Pack 3 or higher.

Install AD RMS on a server that is a member of the same AD DS domain as the user accounts that will be consuming rights-protected content.

It is recommended that the server hosting the AD RMS role be formatted with the NTFS file system.

The server hosting the AD RMS role must have message queuing enabled.

Users who acquire licenses or publish content must have an e-mail address configured as a property of the user account.

The user account that installs AD RMS must have the ability to query the domain and create new databases on the database server. If Microsoft SQL Server 2005 is used, the user account for installing AD RMS must be a member of the System Administrators database role or equivalent.

All users and groups who use AD RMS to acquire licenses and publish content must have an e-mail address configured in Active Directory.

After the installation, you cannot change the domain membership of the AD RMS server.

The following Web services will be added automatically during installation if they do not already exist:

o Internet Information Services (IIS) o ASP.NET must be enabled

The following table describes the configuration choices to make during AD RMS installation.

Configuration

Value Description

Cluster

An AD RMS cluster is a single server or a group of servers running AD RMS that share

AD RMS publishing and licensing requests from AD RMS clients. During installation,

you can install a new cluster, or install the server into an existing cluster (if one exists).

There are two types of clusters:

The root cluster provides AD RMS services for the Active Directory Domain Services (AD DS) domain in which it was installed. The root cluster is the first server in an AD RMS installation. Joining a server to a root cluster is the best way to increase the availability and redundancy of your deployment.

Licensing-only clusters provide licensing and publishing services. Licensing-only clusters:

o Are created in addition to the root cluster. o Can be set with options such as rights templates, logging, membership

in the super users group, and exclusion policies. o Can be used to:

Isolate different departments within an organization by not establishing a trusted publishing domain between RMS clusters. This is makes it so content can only be consumed by users that have access to a given licensing server.

Support unique rights-management requirements of a department by setting up a licensing-only cluster that is dedicated to a group's needs, and configuring rights policy templates separately for that licensing-only cluster.

Support rights management for business partners that are part of an extranet.

You must be a member of the local Administrators group to join servers to a

licensing-only cluster.

Database

location

The database server stores configuration, policy, and logging information. You can use

one of the following database locations:

When you use the Windows Internal Database, the database is located on the AD RMS server and configured automatically. This option is intended for use in test environments only. When using this option, the AD RMS cluster is limited to a single server.

When you use a different database server, the database is saved on an external database such as SQL server. The database server can be running on the same computer or a different computer. You must use this option to have

more than one server in a cluster.

Service account

AD RMS requires a user account as a service account for communicating with other

services.

The service account cannot be the same as the user account used to install AD RMS.

If AD RMS is installed on a domain member, do not grant any additional rights to the service account.

If AD RMS is installed on a domain controller, add the user to the Domain Admins group. Otherwise, installation will fail with a message stating that the password cannot be verified.

Cluster key

The cluster key is used to digitally sign certificates and licenses. During setup, you need

to:

Identify where the cluster key is stored, either locally or in a CSP storage location. If you choose a CSP location, you must copy the key to each new server in the cluster.

Configure an administrator password. The password is used to encrypt the cluster key. It is required for key recovery, to join a server to the cluster, or to restore from backup.

Cluster address

The cluster address is a URL that is used by clients to publish and consume rights-

protected content. When defining the cluster address:

Choose a URL which is different from the server name. That way, if the server name changes in the future, you will not need to republish all content.

Create a separate DNS alias record for the AD RMS cluster URL and for the computer hosting the AD RMS configuration database. This is beneficial in the event that the AD RMS servers are retired, failure is experienced, or the computer's name is changed. Having two separate alias records allows you to perform updates without having to publish all rights-protected files again.

When using Identity Federation Support, you must use SSL for the cluster address. If SSL is not enabled on the Web site, you will be prompted to select a certificate for SSL during installation.

o Use a Secure Sockets Layer (SSL) certificate issued from a trusted root certification authority when you install the AD RMS cluster. Self-signed certificates should only be used in a test environment.

o The SSL certificate must exist on the new server before it can be joined to an existing AD RMS cluster.

Service

connection point

(SCP)

A Service Connection Point (SCPs) allows AD RMS-enabled clients in your organization

to find and access the AD RMS cluster. Registering an SCP places the cluster URL in

Active Directory. SCPs can be registered in two ways:

During the installation of the AD RMS role.

The cluster Properties sheet in the Active Directory Rights Management Services console. This is also where you can modify an SCP.

To register the AD RMS Service Connection Point (SCP) during installation, the installing user account must:

Have Write access to the Services container in AD DS.

Be a member of the AD DS Enterprise Admins group or equivalent.

Be aware of the following regarding AD RMS installation.

AD RMS installation adds IIS if it is not already installed.

To allow AD RMS to use the host-based firewall application that is installed and enabled by default in Windows Server 2008, the following port exceptions are created and enabled automatically when AD RMS is installed:

o Port 80 is opened for HTTP. o Port 443 is opened for HTTPS or SSL communication.

If you are using Microsoft SQL Server 2000 or later in a cluster or if the database is installed on a different server than the AD RMS server, you must make the following port exceptions on the database server that is hosting the AD RMS databases:

o Port 1433 as the default Microsoft SQL Server listening port. o Port 445 as the SQL Server Named Pipes (used for provisioning the AD RMS server).

Decommissioning is the process in which rights-protected content is decrypted when an AD RMS cluster is removed.

o Until all rights-protected content has been decrypted, servers in the AD RMS cluster should remain available on the network in decommissioning mode.

o No new content can be published as rights-protected while the AD RMS cluster is in decommissioning mode.

Three domain local groups are created by default when you install AD RMS: o AD RMS Enterprise Administrators can perform almost all AD RMS tasks. o AD RMS Templates Administrators can create and manage rights policy templates. o AD RMS Auditors can access the reports feature in the AD RMS console which can be

useful in examining error messages to determine why users are not able to obtain AD RMS licenses. Additionally, they can measure the performance of the server and check the server health.

The AD RMS server role in Windows Server 2008 R2 is also supported by two sets of Windows PowerShell cmdlets modules:

Module Description

AD RMS

deployment

The AD RMS deployment cmdlet module gives you the ability to install, upgrade, or

remove an AD RMS cluster. Before you can deploy AD RMS by using Windows

PowerShell cmdlets, you must use the Import-Module ADRMS cmdlet to import the AD

RMS Windows PowerShell deployment cmdlet module. Be aware of the following

deployment cmdlets:

Install-ADRMS installs the AD RMS server role and, if necessary, any features required by AD RMS. Before running this cmdlet, prepare the server by setting properties on containers in the deployment provider namespace.

Uninstall-ADRMS removes the AD RMS server role, and, if appropriate, requires role services that were installed with AD RMS.

Update-ADRMS upgrades the AD RMS server role following an upgrade of the

operating system to Windows Server 2008 R2.

AD RMS

administration

The AD RMS administration cmdlet module gives you the ability to administer all aspects

of an AD RMS cluster. Before you can administer AD RMS by using Windows

PowerShell cmdlets, you must use the Import-Module AdRmsAdmin cmdlet to import

the AD RMS Windows PowerShell administration cmdlet module. Be aware of the

following administration cmdlets:

Get-RmsSvcAccount gets service account credentials for an AD RMS cluster.

Set-RmsSvcAccount sets the service account for an AD RMS cluster.

Update-RmsCluster updates the cluster information including the hierarchy of content that defines the cluster.

AD RMS Certificate Facts

The following table lists the certificates and licenses that are used by AD RMS:

Certificate or

License Purpose

Server Licensor

Certificate

(SLC)

The Server Licensor Certificate (SLC) is a self-signed certificate created when the AD

RMS server role is installed and configured on the first server in the cluster. Be aware of

the following details:

The SLC generates a unique SLC for itself that establishes its identity, called self-enrollment, and has a validity time of 250 years. This enables the archiving of rights-protected data for an extended period of time.

A root cluster handles both certification, by issuing a rights account certificate (RAC), and licensing rights-protected content. Other servers added to the root cluster share an SLC.

In complex environments, licensing-only clusters can be deployed, which generate their own SLC.

With the SLC, AD RMS can operate in a network that is entirely isolated from the Internet.

The SLC contains the public key of the server.

Rights Account

Certificate

(RAC)

The Rights Account Certificate (RAC) establishes a user's identity in the AD RMS

system. It is created by the AD RMS root cluster and provided to the user when first

attempting to open rights-protected content. Be aware of the following details:

A standard RAC identifies a user by account credentials in the context of a specific computer or device and has a validity time measured in number of days. The default validity time for a standard RAC is 365 days.

A temporary RAC identifies a user based on account credentials only and has a validity time measured in number of minutes. The default validity time for a temporary RAC is 15 minutes.

The RAC contains the public key of the user and the private key of the user

encrypted with the public key of the activated computer.

Client Licensor

Certificate

(CLC)

The Client Licensor Certificate (CLC) is created by the AD RMS cluster in response to a

request from the client application. Be aware of the following details:

The CLC is sent to the client while it is connected to the organization's network and grants the user the right to publish rights-protected content when the client is not connected.

The CLC is tied to the RAC of the user, so that if the RAC is not valid or not present, the user is not able to access the AD RMS cluster.

The client licensor public key is contained in the CLC, along with the client licensor private key that is encrypted by the public key of the user who requested the certificate. It also contains the public key of the cluster that issued the certificate, which is signed by the private key of the cluster that issued the certificate.

The client licensor private key is used to sign publishing licenses.

Machine

Certificate

The machine certificate is created on the client computer the first time that an AD RMS-

enabled application is used. Be aware of the following details:

The AD RMS client in Windows Vista automatically activates and enrolls with the root cluster to create this certificate on the client computer.

This certificate identifies a lockbox on a computer or device that is correlated with the logged-on user profile.

The machine certificate contains the public key of the activated computer. The corresponding private key is contained by that computer's lockbox.

Publishing

License

The publishing license is created by the client when content is saved with rights-

protection. Be aware of the following details:

The publishing license specifies the users that can open the rights-protected content, under which conditions the content may be opened by the user, and the rights that each user will have to the rights-protected content.

The publishing license contains the symmetric content key for decrypting the content, which is encrypted with the public key of the server that issued the license.

Use License

The use license specifies the rights that apply to the rights-protected content in the

context of a specific authenticated user. Be aware of the following details:

This license is tied to the RAC. If the RAC is not valid or not present, the use license cannot be used to work with the content.

The use license contains the symmetric content key for decrypting the content, which is encrypted with the public key of the user.

Recovery and Availability Facts

You should be familiar with the following tools available for managing disaster recovery and availability.

Tool Description

Windows Server

Backup

Windows Server Backup provides backup and recovery for Windows Server 2008 and

Windows Server 2008 R2. It allows you to manage backup and recovery from either the

command line using wbadmin or the Windows Server Backup console snap-in.

Windows

Recovery

Environment

Windows Recovery Environment is a partial version of the operating system and a set of

tools that you can use to recover the operating system or the full server (you must have

a backup created earlier using Windows Server Backup). The following tools are

included in the Windows Recovery Environment:

Windows Complete PC Restore allows you to restore the operating system or full server using an existing backup.

Windows Memory Diagnostic Tool to check the computer's RAM. This tool requires you to restart the system and to run a valid version of Windows Vista and Windows Server 2008.

Command Prompt opens a command prompt window with Administrator privileges that provides full access to your file system and volumes.

To access the Windows Recovery Environment tools, use the System Recovery Options dialog in the Install Windows wizard.

Shadow Copies

Volume Shadow Copy Services (VSS, or simply Shadow Copy) automatically makes

copies of files at regular intervals. Using shadow copies, you can do the following:

Recover deleted files or folders.

Recover a previous version of a modified file.

Compare a file with a previous version of that file.

Clustering

Clustering allows you to connect a group of independent computers to increase the

availability to applications and services. Each clustered server is called a node. The

nodes are connected physically by cables and use software to monitor and maintain the

connections. If a node fails, another node begins providing the services of the failed

node (this is called failover). Failover clustering allows users to experience a minimum

of interruptions.

Network Load

Balancing

Network Load Balancing (NLB) allows you to load balance network traffic (sent to a

cluster virtual IP address) among multiple servers in an NLB cluster.

To use NLB, install NLB on a server and add two or more machines to the NLB cluster. Each machine uses two IP addresses: a unique address and the cluster address. This allows the DNS server to respond to clients by sending them to a single IP address. Each server in the cluster runs an algorithm to determine which server responds to the next request. You can have up to 32 machines in an NLB cluster.

NLB is a dynamic method for load balancing in that if a server fails (or if a server is added to the cluster), NLB recognizes the change and compensates for it through convergence, a process whereby the server is removed from (or added to) the cluster.

Windows Backup Facts

Windows Server Backup provides backup and recovery for Windows Server 2008 or Windows Server 2008 R2. Windows Server Backup allows you to manage backup and recovery from either the command line or the Windows Server Backup console snap-in.

You should know the following facts about Windows Server Backup:

Windows Server Backup uses Volume Shadow Copy Server (VSS) and block-level backup to back up and recover the system.

Full backups take less time than they did in previous Windows versions.

As you restore a specific item from an incremental backup, you do not need to run every backup on which the item was restored. You need only select the date on which you backed up the version of the item.

To install and use Windows Server Backup, you must be a member or either the Administrators group or the Backup Operators group. Alternatively, you can receive permissions to use Windows Server Backup through delegation.

You can recover the operating system to the same machine, or in the event of a hardware failure, to a new machine.

Windows Server Backup automatically manages disk usage. It will automatically reuse the space of old backups when it creates new backups.

Windows Server Backup replaces the NTbackup.exe backup utility in previous Windows versions. You cannot use Windows Server Backup to recover backups created with NTbackup.exe. To recover these backups, download the version of NTbackup.exe for Windows Server 2008. This tool can only be used to restore previously-created backups, not perform backups.

When you create a backup and save it to a storage location, the backup that you create will be saved in the WindowsImageBackup folder. In addition to the backup, this folder includes catalog files that contain information about all backups on that location up to the current backup, and a file that contains the identifier for the backup storage location. This information is required to perform a recovery.

Windows Server Backup provides three ways to run backups:

Windows Server Backup MMC snap-in. Using the snap-in, you can run wizards for scheduling backups. It also allows you to connect to other computers and manage backups. To do so, click the Action menu and select Connect to Another Computer.

Wbadmin from the command prompt. It allows you to perform the same operations as the snap-in from the command line.

PowerShell cmdlets for Windows Server Backup. The cmdlets allow you to write scripts to perform backups.

Note: To run backups for computers with a Server Core installation, you need to use the wbadmin command, the Windows PowerShell cmdlets for Windows Server Backup, or manage backups remotely from another computer.

When you create a backup, you need to specify the files, folders, or volumes that you want to include. Windows Server Backup allows you to select from the following options (Note: These volumes must be NTFS-formatted and on a locally attached disk):

Options Description

Full Server Backs up all volumes if you want to be able to recover the full server. You can use

a full server backup to perform all types of recoveries, including system state and

bare metal recoveries. Best practice dictates that you choose this option.

Critical

volumes/Bare metal

recovery

Create a backup for bare metal recovery needed to recover the operating system

(critical volumes only).

This option is a subset of a full server backup.

System state Backs up the system state needed to perform a system state recovery.

This option is a subset of a full server backup.

Individual volumes Backs up just individual volumes if you only want to be able to recover files,

applications, or data from those volumes.

Folders or files Backs up just individual folders or files if you only want to be able to recover those

items.

Windows Server Backup can save backups to the following storage types:

Storage Type Description

Internal disk

You can use the backups stored on internal disks to:

Recover files, folders, applications, and volumes.

Perform operating system (bare metal) recoveries if the backup used contains all the critical volumes.

Perform system state recoveries if the backup used contains the system state.

When you store scheduled backups on an internal disk, you have the option of dedicating that disk for storage:

When it is dedicated for backup storage, the disk will not be visible in Windows Explorer. This is the recommended option.

When you use a volume to store backups and other data, write operation performance may decrease on the volume (read operations are not affected).

External disk

Backups to external disks are much the same as backups to an internal disk.

Backups to an external disk can be used to recover the full server, critical volumes, non-critical volumes, individual files and folders, and applications and their data.

Same as internal disks, you have the option of dedicating the disk for storage.

Best practice dictates that you use USB 2.0 or IEEE 1394 disks with 2.5 more times capacity than the set of items you back up.

You can use multiple disks for automatic backup storage. o When you create the schedule, all the disks must be attached and

available. However, you do not have to leave the disks attached after the backups begin.

o Best practice dictates that you use only one connected drive at a time. When you want to use a new disk, detach the current disk and attach

another disk from the series. This allows you to rotate the disks for offsite disaster protection or other reasons.

o If you want to force the backup to go to a specific disk among several attached disks, detach or disable the other disks in the backup series.

Shared folder

Backups to a shared folder are saved to a network share.

Backups to a shared folder can be used to recover files, folders, applications, and full volumes, or to perform system state or bare metal recoveries.

Backups stored on a shared folder are not saved consecutively. Rather, each backup operation overwrites the previous backup. If a backup operation fails, you may be left without a backup. You can avoid this by storing your backups in subfolders of the shared folder.

If you enable IPSec in your domain, you must save the backup to a shared folder on an IPSec boundary computer. If not, you cannot access the shared folder when you use a Windows Setup Disk to access the Windows Recovery Environment.

DVD, other

optical, or

removable

media

Backups can be stored on DVD. However, this backup media has more limitations than

other media.

You can use backups stored on optical or removable media to perform full volume or bare metal recoveries.

You cannot recover applications, individual files, or the system state from backups stored on optical or removable media.

Backups to DVD are compressed, so it's likely that the backup size on the DVD is smaller than the actual size of the volume.

Backups to DVD can span multiple DVDs if necessary. When one DVD reaches capacity, the system prompts you to insert the next DVD.

When you create a backup to DVD, the destination has to be larger than 1 GB in size, or it is blocked from the list of available devices.

In Windows Server 2008 R2, if the free space on the media is greater than 1 GB:

o Removable media is formatted as NTFS o Optical media is formatted as Universal Disk Format (UDF)

Be aware of the following:

You cannot back up to tape. Windows Server Backup does not support backups to tape devices. However, support of tape storage drivers is still included in Windows Server 2008 and Windows Server 2008 R2.

You cannot store backups on USB flash drives or pen drives.

Backup Operations

The table below describes the types of backups you can perform:

Backup Description

Type

Automatic

backup

You can create automatic backups using the Backup Schedule Wizard in the Windows

Server Backup console, the wbadmin enable backup command, or the Windows

PowerShell cmdlets for Windows Server Backup.

By default, automatic backups run once a day. You can modify the schedule to take backups more often, but you cannot schedule automatic backups less frequently than once a day.

When you create the backup, you need to specify the files, folders, or volumes that you want to include. By default, volumes that hold operating system components (the system volumes) are included, and you cannot exclude them. However, you can include or exclude data volumes as needed.

You can only use local, external disks, or remote shares for the backup.

You can save scheduled backups to a volume when you use the wbadmin enable backup command.

Use wbadmin disable backup to stop the automatic daily backups.

Manual

backup

You can run backups manually by using the Backup Once Wizard, the wbadmin start

backup command, or the Windows PowerShell cmdlets for Windows Server Backup.

You can save backups to local disk, DVD, removable media, or a shared folder.

When backing up to shared folder or local disk, you can recover individual folders and files. When backing up to DVD or other removable media, you can only restore full volumes or bare metal recoveries.

To use a shared folder, DVD, or removable media, you must select Different options in the Backup options page. Otherwise, the settings used for automatic backups will be used (and only local disks will be supported).

Best practice dictates that you use manual backups only to supplement regularly scheduled backups.

Scheduled

backup

To run backups automatically but avoid running them on the default at-least-once-a-day

schedule, use Task Scheduler and the wbadmin start backup command. You can do this

by either running the command through a series of scheduled tasks or by launching a batch

file. However, make sure that this custom schedule doesn't conflict with any regular backup

schedule or one of the backup operations will fail.

Using the wbadmin start backup command allows you to have full control over the types of data you wish to back up. For example, when you create a comma-delimited list of volumes to back up using the -include switch, you do not have to include system volumes as you do with other types of backups. Use the -backupTarget switch to designate the storage location for the backup.

System

state backup

If you want to create a backup of the system state, use the Backup Schedule Wizard, the

Backup Once Wizard, the wbadmin start systemstatebackup command, the wbadmin

enable backup command, or the Windows PowerShell cmdlets for Windows Server

Backup.

A system state backup can only be saved to a locally attached disk (the disk can be either internal or external) or shared folder, but not to a DVD, optical media, or other removable storage media.

Be aware of the following when using Server Backup:

Configuring backups to disk using wbadmin requires you to know the disk ID. Use wbadmin get disks to view information, including the disk ID, for installed disks.

After you create the first backup, best practice dictates that you perform a test recovery.

You can monitor the status of a backup or recovery using the following sections in the snap-in: o Messages o Status o Scheduled Backup

You cannot use Windows Server Backup to back up files and folders in volumes that require more than 2040 GB.

Restore Operations

Use the backups you have created to recover your operating system, system state, volumes, applications and application data, backup catalog, and local files and folders. When restoring from backups, keep the following in mind:

When you perform a recovery to a new disk, best practice dictates that the new disk be as big as the disk on which the backups were stored. For example, if you saved your backups to a 1 TB disk, the new disk must be 1 TB even if the backed up volumes came from a 100 GB disk.

You cannot recover backups that you created with Ntbackup.exe by using Windows Server Backup (Wbadmin.exe). However, a version of Ntbackup.exe is available as a download for Windows Server 2008 or Windows Server 2008 R2 users who want to recover data from backups that were created using Ntbackup.exe.

To perform recoveries using Windows Server Backup, you must be a member of the Backup Operators or Administrators group, or you must have been delegated the appropriate authority.

To perform a system recovery, you can use the following wizards or tools:

Recovery

Type Description

Files and

folders

To recover files or folders you can use either the Recovery Wizard or wbadmin start

recovery. You should know the following about recovering files and folders:

You can't recover files and folders from DVD, removable media, or a system state backup. You can only recover files and folders from backups stored on a hard disk or in a shared folder.

When you recover files or folders, you can select Original Location or Another Location to save the objects to a different storage location.

When backup finds duplicate files, you can select from the following three options:

o Create copies so I have both versions of the file or folder o Overwrite existing files with recovered files o Don't recover those files or folders

Volumes

To recover volumes you can use either the Recovery Wizard or wbadmin start

recovery. You should know the following about recovering volumes:

You can restore a volume from a shared folder, disk, DVD, or removable media

backup.

When you restore a volume, the restore operation overwrites the data on the destination volume. Make sure the destination does not contain data that you may need later before performing the restore.

When you restore a full volume, all contents of the volume are restored; you cannot selectively restore individual files or folders by using this option.

Applications

To recover applications you can use either the Recovery Wizard or wbadmin start

recovery. You should know the following about recovering applications and their data:

To be able to recover an application, the application must have a VSS (Volume Shadow Copy Service) writer. This allows the application to register with Windows Server Backup. The VSS writer must be running when you create the backup.

You cannot recover an application from a DVD or other removable media backup.

If you are recovering from your most recent backup and the application supports "roll-forward" of the application database, the Do not perform a roll-forward recovery of the application database option appears. Select this option if you do not want Windows Server Backup to roll-forward the application database currently on the server.

When you recover an application, you can copy the application to a different location, but you cannot recover the application to a different computer of a different name.

Backup

catalog

The backup catalog stores information about the backups, such as the volumes backed

up and where those backups are located.

The backup catalog is stored in the same location as your backups.

If the catalog becomes corrupted, you receive an alert, and an Event is registered in the Event log. You cannot perform more backups until you either restore the catalog using an available backup or delete the catalog.

If you delete the catalog, you can't use Windows Server Backup to access the backups.

You can use either the Catalog Recovery Wizard or wbadmin restore catalog to recover a corrupt catalog. In fact, you only see the Catalog Recovery Wizard in Windows Server Backup if the catalog is corrupted.

Operating

system or full

server

To perform a recovery of the operating system or a full server recovery, you need to use

a Windows Setup disc and a Windows Server Backup backup.

To begin the recovery, boot the computer from the Windows Setup disc and select the Repair your computer option.

Restoring only the critical volumes restores volumes that contain operating system files, but not volumes that contain user data only.

Restoring the entire PC restores critical and non-critical volumes.

When you restore volumes, existing disks are repartitioned and reformatted, resulting in all existing data on the disks being lost. You can keep disks by excluding them from the restore process. This keeps the existing data, but does not restore those disks from the backup.

You can also use the wbadmin start sysrecovery command to recover the volumes that contain the operating system's state, but you can only use it when you also use the Windows Recovery Environment.

System state

To recover a computer's system state, you can use either the Recovery Wizard or

wbadmin start systemstaterecovery.

A system state recovery can only use a backup on a locally attached disk or shared folder, but not to a DVD, optical media, or other removable storage media.

System state recovery cannot be stopped once it is started, or the system could become unbootable.

Domain Controller Restore Facts

The first step in a recovery strategy for domain controllers is to perform the proper backups while everything is working correctly. In addition to performing regular full server backups, you should perform regular system state backups. Restoring from a system state backup, when possible, is faster than restoring from a full server backup. Be aware of the following when performing a system state backup:

Use Windows Server Backup or wbadmin start systemstatebackup to take a system state-only backup.

The backup cannot be saved to a DVD, other optical, or removable media.

The backup cannot be saved to the same drive as the system state data. While this is possible by making a registry change, doing so leads to problems under certain circumstances.

To perform system state backups on a schedule, create a Scheduled Task that runs wbadmin or use Windows Server Backup.

You might need to restore a domain controller if the Active Directory database on the domain controller is corrupt or lost, or if the entire server fails. When restoring Active Directory, there are two types of restore:

Restore type Description

Nonauthoritative

A nonauthoritative restore returns the domain controller and the Active Directory

database to its state at the time of backup. After the domain controller returns online,

Active Directory replicates the database with other domain controllers on the network.

Any changes that took place since the backup are replicated to the restored domain

controller.

Nonauthoritative restores are the default method for restoring Active Directory, and the most common use of a nonauthoritative restore is to bring an entire domain controller back from a serious failure.

Authoritative

An authoritative restore returns a designated object or container of objects to its state at

the time of the backup. For example, imagine a junior administrator accidentally deletes

an OU that contains a large number of users. If you restore the server from backup, the

default nonauthoritative process doesn't restore the deleted OU because the domain

controller is updated to the current status of its replication partners, which means that

the OU is deleted.

When you perform an authoritative restore, you prevent specific objects from the backup from being overwritten by Active Directory replication. With the authoritative restore, the Update Sequence Number (USN) is incremented so that it is higher than the existing USN of the (deleted) object in the Active Directory replication system.

Use an authoritative restore to restore specific objects in Active Directory.

The following table lists several methods for performing a domain controller restore. If possible, use the first method in the table.

Method Description

Dcpromo

If the server boots but Active Directory is corrupt, you can use dcpromo.

1. Run dcpromo to remove Active Directory from the domain controller. The server becomes a member server.

2. Run dcpromo again to install Active Directory. Active Directory data is copied from another domain controller on the network.

If you are unable to remove Active Directory, run dcpromo /forceremoval. The

disadvantage of using dcpromo is that the entire Active Directory database must be

replicated across the network from another domain controller. However, you can use the

Install from Media option to copy the database from media to reduce network traffic.

Restore

system state

If the server boots but Active Directory is corrupt, you can restore the system state data

from a recent backup. After the backup is restored, Active Directory replication copies only

the changed data to the restored domain controller. To use this method to restore a

domain controller:

1. Reboot the server in Directory Services Restore Mode (DSRM). Use one of the following methods:

o Reboot the server. Following the BIOS screen, press F8. Select Directory Services Restore Mode (DSRM) from the menu.

o At a command prompt, type: bcdedit /set safeboot dsrepair shutdown -t 0 -r

2. Run wbadmin start systemstaterecovery to restore the system state data. 3. Restart the server in normal mode. If you used bcdedit to start the server in

DSRM, type the following at a command prompt: bcdedit /deletevalue safeboot shutdown -t 0 -r Following the restart, allow time for Active Directory replication to occur.

Critical

volume or full

server restore

If you are unable to reboot the server, you will need to perform a critical volume or full

server restore. This restore rebuilds the entire server, along with the Active Directory

database.

Use the wbadmin start recovery command or Windows Server Backup to start the restore. A full server restore not only restores Active Directory, but data on all other volumes as well.

Note: To enter DSRM, you must supply the recovery mode password. You set this password during the domain controller installation. If you need to set or change the password, use the following steps:

1. Open an elevated command prompt by clicking Start, then right-clicking Command Prompt and selecting Run as administrator.

2. Type ntdsutil. 3. Type set dsrm password. 4. Type reset password on server <servername>. 5. Enter the password. 6. Confirm the password. 7. Type quit, then quit again.

To perform a restore to all replicas in the domain, the Burflags registry setting must be set at the domain controller. The Burflags registry setting only supports the following values:

D2 performs a nonauthoritative restore

D4 performs an authoritative restore. Note: You should never set more than one domain controllers Burflags registry setting to D4 when you are attempting to rebuild the SYSVOL for the entire domain.

Active Directory Recycle Bin Facts

In Windows Server 2008 R2, the Active Directory Recycle Bin allows you to recover deleted Active Directory objects without restoring them from backup. Be aware of the following:

The Active Directory Recycle Bin is supported only on domain controllers running Windows Server 2008 R2 or higher. It is available with AD DS and AD LDS.

By default, the Recycle Bin is disabled.

To enable the Recycle Bin, you must raise the forest functional level to Windows Server 2008 R2. Once you enable the Recycle Bin, you can no longer roll back the forest functional level.

Once you enable the Recycle Bin, you cannot disable it.

To enable the Recycle Bin in an existing forest:

1. Run adprep /forestprep on the schema master. 2. In each domain, run adprep /domainprep /gpprep on the infrastructure master. 3. If you have a read-only domain controller, run adprep /rodcprep. 4. Raise the forest functional level to Windows Server 2008 R2. Use one of the following methods:

o Run the Set-ADForestMode PowerShell cmdlet. o Run Ldp.exe and connect to the forest root domain. Edit the CN=Partitions container for

the configuration directory partition and set the msDS–Behavior–Version attribute to 4. 5. Enable the Active Directory Recycle Bin using one of the following methods:

o (Preferred) Run the Enable–ADOptionalFeature PowerShell cmdlet. For example, to enable the Recycle Bin for the westsim.com domain, run: Enable–ADOptionalFeature –Identity 'CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=westsim,DC=com' –Scope ForestOrConfigurationSet –Target 'westsim.com'

o Run Ldp.exe and connect to the forest root domain. Edit the CN=Partitions container for the configuration directory partition and set the enableOptionalFeature attribute to CN=Partitions,CN=Configuration,DC=westsim,DC=com:766ddcd8–acd0–445e–f3b9–a7f9b6744f2a.

Active Directory Restore Facts

If you need to restore lost Active Directory data, use the following methods:

Method Description

LostAndFound

container

When you delete an OU, all objects within the OU are also deleted. However, if you

have multiple domain controllers, objects might have been added to the OU on one

controller after that OU had been deleted on another domain controller. In this case,

following Active Directory replication, the new objects are placed in the LostAndFound

container.

Use the View menu to show the Advanced Features to see the LostAndFound container.

Move objects out of the LostAndFound container and into the necessary OUs.

Objects added to the OU before it was deleted are lost and must be restored.

Authoritative

restore

To restore Active Directory data, such as deleted objects, perform an authoritative

restore. Use the following process:

1. Restart the domain controller in Directory Services Restore Mode (DSRM). 2. Perform a nonauthoritative restore of a system state backup that holds the

deleted objects. 3. Run the Ntdsutil command. 4. At the Ntdsutil prompt, use the authoritative restore command, followed by

the LDAP name of the object you want to mark as authoritative. 5. Type quit to exit Ntdsutil, then restart the domain controller.

Active Directory replication will copy the authoritatively restore object back to other

domain controllers. It will also copy changes made on other domain controllers back to

the restored database.

Active Directory

Recycle Bin

With Windows Server 2008 R2, the Active Directory Recycle Bin allows you to recover

deleted Active Directory objects without restoring them from backup. Be aware of the

following:

Deleted objects are saved in the Deleted Objects container. o This container is not shown in Active Directory Users and Computers. o Use Ldp.exe to display the Deleted Objects container. From the

Options menu, select Controls. In the Controls box, expand Load Predefined, then choose Return deleted objects.

When you delete an object, the object is moved to the Deleted Objects container and its distinguished name is mangled. All other remaining attributes are left intact.

o You can restore the object from the Recycle Bin or restore it from a backup during the deleted object lifetime.

o After the deleted object lifetime expires, the object status is recycled and most attributes are stripped. When the recycled object lifetime expires, the object is permanently removed from Active Directory. You cannot recover or restore recycled objects.

To restore a deleted object: o Run Ldp.exe and locate the object in the Deleted Objects container. o Run the Get-ADObject and Restore-ADObject PowerShell cmdlets.

When restoring objects: o Objects must be restored to a live parent. In other words, if you delete

an OU, the objects in that OU are also deleted. To restore any of the deleted objects, you must first restore the OU.

o All attributes of an object are restored with the object (both link-valued and non-link-valued). This means that permissions and group memberships are restored when the object is restored.

o If you delete an object, you might not be able to immediately restore that object from the Recycle Bin. This occurs because the object might be locked by Active Directory as references for the object are being deleted.

o Objects deleted before the Recycle Bin is enabled cannot be restored from the Recycle Bin. Use an authoritative restore to restore these objects.

o The Recycle Bin can be used to restore Group Policy Objects and Exchange objects. However, application-specific data not stored in AD DS will not be restored.

o If you use Exchange tools to delete Exchange configuration objects, the recommended recovery method is to use the Exchange tools to re-create the objects (do not use the Recycle Bin). If you delete Exchange objects without using Exchange tools, restore them from the Recycle Bin as quickly as possible, then reapply the Exchange policies.

Database

snapshot

With Windows Server 2008, you can take snapshots of the Active Directory database.

You can use these saved snapshots to see how Active Directory looked at the time that

the snapshot was taken.

Snapshots use the Volume Shadow Copy Service (VSS).

Snapshots are read only; you cannot restore data from a snapshot. Instead, you open a snapshot and manually record object information.

To make and use snapshots:

1. Take regular snapshots of the Active Directory database. You can schedule a task to run Ntdsutil snapshot on a regular basis, or you can even take regular system state backups. Using Ntdsutil snapshot offers several advantages, so the remaining steps describe this process.

2. Run the Ntdsutil mount command to mount (make active) a database snapshot. You can mount multiple snapshots.

3. Run the Dsamain command to expose a snapshot as an LDAP server. This step allows you to connect to and view the snapshot. With Dsamain, you specify the path to the snapshot, along with a port number that will be used to connect to the snapshot.

4. Run the Ldp tool, Active Directory Users and Computers, or ADSI Edit using the specified port to view the snapshot data.

You can also use third-party tools, such as ADExplorer from Sysinternals.

Default Active To restore the default Group Policy objects to their original state (i.e., the default state

Directory

policies

after initial installation), use the dcgpofix command. Be aware of the following

switches:

/target:dc restores the Default Domain Controllers policy to its default settings.

/target:domain restores the Default Domain policy to the default settings.

/ignoreschema ignores the Active Directory schema version number. dcgpofix checks the Active Directory schema version number to ensure compatibility between the version of dcgpofix you are using and the Active Directory schema configuration.

Note: If the Policies directory on the sysvol has been deleted (%systemroot%\sysvol\domain\policies), the /target switch will be ignored and both the default domain GPO and default domain controller GPO will be rebuilt.

When you restore Active Directory objects with an authoritative restore, it is possible that group membership will not be restored, even though the group and all user accounts exist following the restore.

The problem occurs because group membership involves a link in the group object (the Member attribute, called a forward-link) and a corresponding link in the user object (the MemberOf attribute, called a back-link).

Starting with Windows Server 2003, a feature called linked-value replication (LVR) enables restoring these links. To take advantage of LVR, the forest functional level must be Windows Server 2003 or higher.

LVR allows for the replication of individual attributes instead of the entire object.

The steps you take to restore group memberships depends on the forest functional mode at the time of the backup.

Functional mode Description

Windows Server

2003, 2008, or 2008

R2

If the forest functional mode has always been in Windows Server 2003 or

2008, then LVR is enabled. Group memberships are restored

automatically, and no additional steps are required.

Windows 2000

In Windows 2000 forest functional mode, back-links are not restored. To

restore back-links:

o Manually make the necessary changes. o Run the updated version of Ntdsutil available on a Windows

Server 2003 R1 or later server to perform the authoritative restore. This version of Ntdsutil creates an LDIF file that contains back-link information. Run the Ldifde command using this file to restore the back-links.

Windows 2000

updated to Windows

Server 2003, 2008,

or 2008 R2

If the forest is at the Windows 2000 functional level, LVR is enabled when

you upgrade to Windows Server 2003, 2008, or 2008 R2 functional level.

However, doing so does not automatically update group memberships.

Only groups edited after upgrading the functional level can have their

memberships automatically restored.

o If all groups were edited following the change, no additional action

is necessary. o To restore back-links for groups whose membership has not

changed since the update to the functional level, run the Ldifde with the LDIF file to restore the back-links.

When you perform a system state backup, all Active Directory data, including Group Policy information stored on the Sysvol folder, are backed up. To simplify Group Policy management, you can back up and restore only Group Policy data using the Group Policy Management console.

You can back up a single GPO or multiple GPOs at the same time into the same backup file.

Starter GPO data is backed up separately from the GPO backup. To back up everything, you will need to back up the GPOs as well as the starter GPOs.

Restoring a GPO creates the GPO and restores its settings.

To move a GPO from one domain to another, or to copy GPO settings from one GPO to another, import the settings from the GPO backup. Using backup and import to migrate GPOs does not copy the DACL for the GPO. You will have to manually configure GPO permissions.

To move a starter GPO to another domain, export the starter GPO as a .cab file, then import it in the other domain. You cannot use the backup feature to move a starter GPO to another domain.

To restore the settings in the Default Domain Policy and the Default Domain Controller GPOs, run the Dcgpofix.exe tool.

Restartable Active Directory Facts

Restartable Active Directory is the ability to stop and restart Active Directory Domain Services without shutting down the domain controller. This allows you to apply updates to the domain controller or perform offline defragmentation of the AD DS database. It also allows services that do not depend on AD DS, such as DHCP, to continue functioning and responding to user requests. Restartable AD DS is available on all domain controllers that run Windows Server 2008, regardless of functional level.

Restartable AD DS makes it possible for a domain controller to be in any of the three states described in the table.

State Description

AD DS

Started This is the state in which Active Directory is running and fully functional.

AD DS

Stopped

This is the state in which Active Directory is stopped. A domain controller in this mode has

the following characteristics:

The Active Directory database (Ntds.dit) on the local domain controller is offline.

The domain controller cannot service domain logon requests. o Another domain controller, if available, can be contacted for logon using

domain credentials. o If another domain controller is not available, you can log on to the domain

controller in DSRM using the DSRM password.

The server is joined to a domain, allowing Group Policy and other settings to continue to be applied to the domain controller.

The domain controller cannot replicate with other domain controllers.

You can run the dcpromo /forceremoval command to remove AD DS from a

domain controller in this state.

Directory

Services

Restore

Mode

This state is almost identical to the Directory Services Restore Mode in Windows Server

2003. The one exception is that you can run the dcpromo /forceremoval command to

remove AD DS from a domain controller running in DSRM. This is the state in which you

must run the machine to restore Active Directory objects using the Ntdsutil utility.

You should know the following about restartable AD DS:

You cannot start a Windows Server 2008 DC in the AD DS Stopped state, but you can restart it into DSRM.

Services such as File Replication Service (FRS), Kerberos Key Distribution Center (KDC), and Intersite Messaging that depend on AD DS shut down before AD DS stops. If they are running when you stop AD DS, they restart when you restart AD DS.

If the domain controller is a DNS server, it cannot respond to Active Directory-integrated zone queries while AD DS is stopped. To prevent DNS lookup failures, provide redundancy by configuring member computers, application servers, and domain controllers to point to multiple DNS servers.

Offline Defragmentation Facts

Offline defragmentation is the process of taking the Active Directory database offline, reorganizing the data within the database to make it more efficient, and returning unused disk space to the operating system.

Online defragmentation occurs automatically (by default every 12 hours) when garbage collection runs. However, free space remains within the database file and is not returned to the system for use.

Over time, the size of the database can grow to be much larger than the size of the objects within the database.

The only way to return unused space from the directory database to the file system is through offline defragmentation.

To perform offline defragmentation, you run Ntdsutil to compact the database file to an alternate location, then copy the compacted file back to its original location in the %systemroot%\NTDS folder. Use the following steps:

1. Stop the AD DS service by stopping the Active Directory Domain Services service in the Services console. (Restarting the domain controller in Directory Services Restore Mode is not required.)

2. Open a command prompt as an administrator. Run Ntdsutil with the compact command. This copies the database file to a different location. As it copies, free space is removed from the database file. Use the following commands to compact the database: ntdsutil activate instance ntds files compact to <path> quit quit

3. Delete any log files saved in the %systemroot%\NTDS directory. 4. As a precaution, copy the existing Ntds.dit file to a new location. 5. Copy the compacted file you created in step 2 to the %systemroot%\NTDS directory.

6. You can verify the integrity of the new file using the following commands: ntdsutil activate instance ntds files integrity quit

7. If all checks pass, restart the Active Directory Domain Services service. If the checks fail, you can copy the Ntds.dit file back from the alternate location.

If you want to move the log or database files, use the move command with Ntdsutil. Using the move command updates the registry with the new file location. Do not simply copy the files to a different location. The following commands show an example:

Ntdsutil

activate instance ntds

files

move db to <path> or move logs to <path>

Note: Use these same commands and processes to manage database files on an AD LDS installation. To stop the AD LDS instance, stop the service that was created during the instance installation.

System Monitoring Tools Facts

The table below describes tools that you can use to view and monitor system events and information.

Component Description

Event Viewer

Use Event Viewer to view system and error messages generated by the operating system

and other programs. Through Event Viewer, you can:

View events from multiple event logs.

Save useful event filters as custom views that can be reused.

Attach a task to an existing instance of error to notify you of when a particular error occurs. This is useful if you notice an error that occurs in random intervals.

With Event Viewer you can collect and view a set of events stored in multiple logs on multiple computers through event subscriptions. When you create an event subscription, events are sent from the source (or forwarder) computer (the computer where the event is generated) to the collector computer (the computer where the events are sent).

Collector initiated subscriptions create an event subscription for all source computers, inform the source computers of the subscription, and then receive the events on the collector computer. This type is best if you know all the event source computers that will forward events. Be aware of the following before configuring the collector initiated subscription type:

1. On the source computer, run the winrm qc command to run WinRM. 2. On the source computer, add the collector computer account to the local

Administrators group. In a workgroup, you must also add a user account with administrative privileges to the Event Log Readers group.

3. On the collector computer, run the wecutil qc command to run Wecsvc. Note: You must also run winrm qc on the collector if the collector is to use delivery optimization options other than normal.

Source initiated subscriptions define an event subscription on a collector computer without identifying each source computer. This type is best for environments where the source computers are managed using Group Policy. Be aware of the following before configuring the source computer initiated subscription type:

1. On the source computer, run the winrm qc -q command to run WinRM. 2. On the source computer, configure and enable the Event Forwarding

policy through Group Policy or the local security policy, and specify the collector computer's FQDN.

3. On the collector computer, run the winrm qc -q command to run WinRM. 4. On the collector computer, run the wecutil qc /q command to run

Wecsvc. 5. In Active Directory or on the collector computer, add the source

computers to a computer group that identifies the source computers.

To manage logs and read events from the command prompt, use Wevtutil.

Network

Monitor

Network Monitor is a protocol analyzer. Use Network Monitor to capture, view, and

analyze network traffic. Network Monitor offers the following features:

Network Monitor captures packets (or packet fragments) and their contents.

You enable packet capturing on specific network interface cards. When enabled on a NIC, Network Monitor captures all traffic sent to and from that NIC.

You can use the p-mode (promiscuous mode) to capture all packets regardless of the destination MAC addresses.

Configure filters to specify packets to display or capture. o A display filter shows only the packets specified by the filter. Using a

display filter does not affect the data that is in the capture file. o A capture filter captures only the packets specified by the filter. If the

packet type you are looking for is not in the capture file after using a capture filter, you must reconfigure the filter and recapture.

Nmcap.exe is the command-line version of Network Monitor.

You must run Network Monitor as an administrator or as a member of the Netmon users group.

Task Manager

In Task Manager you can see programs, processes, and services that are currently

running on your computer. Press Ctrl + Alt + Delete to start the Task Manager. Task

Manager displays data in the following tabs:

The Applications tab allows you to view and, if needed, stop each running application.

The Processes tab displays each running process, memory resources in use, and a short description.

The Services tab displays each service needed to run active processes and applications.

The Performance tab graphs CPU and memory usage.

The Networking tab allows you to view the percentage of available network bandwidth your computer is currently using.

The Users tab displays each user that is currently logged in to the computer and their login method. You can disconnect users if needed.

Windows Windows System Resource Manager (WSRM) allows you to control how CPU and

System

Resource

Manager

memory resources are allocated to applications, services, and processes on the

computer. This prevents one application from consuming more than its allotted CPU and

memory limits and starving other applications of CPU and memory. You can run WSRM

through the Wsrm snap-in or from the command line with the wsrm command.

Performance

Monitor

Performance Monitor is a real-time visual display of a PC's overall performance. You track

performance by using objects and counters:

An object is a statistic group, often corresponding to a specific type of hardware device or software process (such as a physical disk or processor statistics).

A counter is a specific statistic you can monitor. For example, for the PhysicalDisk object, you can monitor counters such as %Disk Read Time or %Idle Time.

Be aware of the following:

Performance Monitor shows real-time statistics.

You can customize the statistics you want to view.

You can save the current statistics, but you cannot use Performance Monitor to capture data over long periods of time.

Performance Monitor displays data in the following forms: line graph, histogram, report (text).

Data Collector

Sets (DCS)

A Data Collector Set (DCS) is a group of objects and counters that can be used to

capture system performance statistics over a period of time. A Data Collector Set includes

one or more data collectors, which identify the specific objects and counters you want to

track. There are four types of data collectors, and you can also create your own.

Use a performance counter data collector to save system statistics over time in a log. Logs can be saved to different log formats:

o Use text files (comma or tab delimited) to import data into a spreadsheet program.

o Use binary files to save data that is intermittent. Select a circular file to save all data into a single file, overwriting the contents when the log is full.

o Use SQL database files to import statistics into SQL server in order to perform data comparisons or data archival.

Use an event trace data collector to capture events logged by software processes.

Use a configuration data collector to monitor the state and changes to registry keys.

Use a performance counter alert to configure triggers that take an action when a counter reaches a threshold value. When you configure an alert you specify:

o The counter you want to watch. o A threshold limit (a counter value that you want to watch for). o An action to take when the threshold value is reached. For example, you

can write an event to a log, send a message, or run a program.

Reliability

Monitor Reliability Monitor maintains historical data describing the operating system's stability.

Run perfmon /rel to open Reliability Monitor from the command prompt.

Data is stored daily and displays a Stability Index from 1 to 10 on the following events:

o Software installs/uninstalls o Application failures o Hardware failures o Windows failures o Miscellaneous failures o Operating system patches o Operating system driver installations

Details for each instance are displayed below the System Stability chart. o Warning icons indicate a failure. o Information icons indicated a successful event. o Error icons indicate a failure.

The Stability index value is calculated over the last 28 days of the system. The Stability index does not calculate days that the computer is turned off, sleeping, or hibernating.

Recent failures are weighted more heavily than past failures so that improvement over time is reflected in an increasing stability index when a reliability issue has been resolved.

Reliability Monitor is disabled by default in Windows Server 2008 R2. To enable Reliability Monitor:

1. Enable the One time trigger in the RacTask task in Task Scheduler. 2. Edit the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Reliability

Analysis\WMI\WMIEnable registry entry. 3. Restart the machine.

Resource

Monitor

The Resource Monitor displays real-time information about the resources used by the

installed hardware and software.

Use resmon.exe or perfmon /res to start the Resource Monitor.

While you can use Task Manager to view the CPU and memory used by a service or a process, use Resource Monitor to view additional details about resources and activities for those processes. You can filter results according to the processes or services that you want to monitor. Selecting a process (to filter on the process) shows only the statistics for that process on all tabs.

A process wait chain includes all of the applications which are waiting for other processes to finish. To view the process wait chain, right-click the name of the process, then click Analyze Wait Chain.

A process that is not responding appears as a red entry in the CPU table.

Resource Monitor starts with the display settings saved from the previous session. Save the display state for future sessions. Filtered selections are not saved as part of the configuration settings.

When monitoring Active Directory-related events, be aware of the following:

The Directory Services object includes multiple counters to monitor Active Directory. This object includes counters for:

o The Directory Replication Agent (DRA) to monitor replication events such as the number of inbound/outbound packets or objects, and pending replication operations.

o Directory Service (DS) events, such as reads and writes from various databases. o LDAP calls, including client sessions, connections, and searches. o Security Account Manager (SAM) operations.

The following trace collectors record information related to Active Directory: o Active Directory Domain Services: Core o Active Directory Domain Services: SAM o Active Directory: Kerberos Client o Active Directory: Kerberos KDC

You can use the preconfigured Active Directory Diagnostics data collector set to monitor common events related to Active Directory. The Active Directory Diagnostics data collector set includes the following collectors:

o NT Kernel and Active Directory trace collectors to capture events logged by these processes.

o A performance counter that monitors all counters related to the following objects: directory services, physical disk, processor, memory, network interface, TCP and UDP, IPv4 and IPv6, and others.

o AD Registry configuration collector, to monitor changes to the registry related to Active Directory.

Active Directory Monitoring Tools Facts

The table below describes tools that you can use to monitor and manage Active Directory.

Tool Description

RepAdmin

Repadmin (Replication Diagnostics Tool) is a command-line tool that you can use to

diagnose replication problems between Windows domain controllers. The following list

shows some of the common switches used with Repadmin

Use /showrepl to show the replication partners of a domain controller.

Use /replicate to force replication between two domain controllers. List the target system first, followed by the source system.

Use /syncall to force replication between all domain controllers in a site.

Use /showchanges to view unreplicated changes on a domain controller. You can export this information to text file, run the command again at a later time, and then compare the results.

Use /showconn to show connection objects.

Use /replsummary to view the replication status for all domain controllers in the forest. The output lists each domain controller with status information.

Use /showattr to see the attributes of an Active Directory object.

You can launch Repadmin from the command prompt or through its link in the Advanced

Tools section of the AD DS server role in Server Manager.

ReplMon

Replmon (short for Active Directory Replication Monitor) is a GUI-based tool that you can

use to perform tasks similar to those performed by RepAdmin. In addition, use ReplMon to

view a graphical representation of the Active Directory replication topology.

Group Policy The Group Policy Results wizard allows you to determine the current, cumulative effects of

Results Group Policy settings that apply to a specific user or computer.

When you run the wizard, you select a computer and a user.

The computer you select must be turned on. The utility contacts the destination computer and queries it for effective Group Policy settings. The destination computer must run Windows XP Professional or later.

You can only select a user account that has been used to log on to the target computer. Group Policy Results creates a report based on the answers you supply during the wizard. The report shows the resultant set of policy for the user and computer you entered in the wizard.

Gpresult.exe is the command line version of Group Policy Results.

This feature used to be referred to as Resultant Set of Policy (RSoP) logging mode.

Group Policy

Modeling

The Group Policy Modeling wizard allows you to calculate the effects that GPOs have on

your system before you deploy the GPOs.

When you run the wizard, you select a domain controller in a domain. The domain controller must be running Windows Server 2003 or later.

You can select a target OU, computer, or user account.

You can choose to include or exclude items from the analysis. For example, you can include or exclude specific WMI filters that have been applied, loopback processing, or GPOs linked to sites.

You can analyze the effects of moving a user or computer to a different OU, changing group memberships, or the application of Group Policy over slow links.

After working through the wizard, the answers you supplied are displayed in a report as if they were from a single GPO and saved as a query represented by a new item under the Group Policy Modeling node.

This feature used to be referred to as Resultant Set of Policy (RSoP) planning mode.