MCTS Guide to Configuring Microsoft Windows Server 2008 Active Directory

MCTS Guide to Configuring Microsoft Windows Server 2008

Active Directory

Chapter 12: Additional Active Directory Server Roles

MCTS Windows Server 2008 Active Directory 2

Objectives

2

• Describe and configure Active Directory Lightweight Directory Services

• Describe Active Directory Federation Services

• Describe Active Directory Rights Management Services

• Implement a read only domain controller


Active Directory Lightweight Directory Services

• Perfect for when you don’t want directory-enabled applications altering the schema throughout your forest

• A directory-enabled application uses a directory service to store program data or configuration information and user information


Active Directory LDS Overview

• AD LDS, based on LDAP, was formerly known as Active Directory Application Mode (ADAM)

• The primary purpose of AD LDS is to support directory-enabled applications with flexibility that AD DS can’t match

• AD LDS does not rely on AD DS but can use AD DS services if necessary

• AD LDS vs AD DS differences– No global catalog– No support for group policy– No computer objects– No integration with AD CS– No trust relationships– No support for Windows security principals


When to Use AD LDS

• AD LDS is an ideal solution when a directory-enabled application isn’t needed by the entire enterprise

• Some other purposes– Authentication for Web applications– Directory consolidation– Development environment for AD DS applications– Migration of legacy X.500 applications


Installing and Configuring AD LDS

• AD LDS is installed on a Windows Server 2008 server by adding the Active Directory Lightweight Directory Service server role

• After install, one or more instances of AD LDS are created

• Each LDS instance has its own data store and communication ports and a unique service name

• When you create an AD LDS instance, you can choose:– A unique instance– A replica of an existing instance


AD LDS Management Tools

• You can administer AD LDS with these tools:– ADSI Edit– LDP.exe– Server Manager

• By default, an AD LDS instance’s schema doesn’t include user object definitions

• Schema can be extended by importing user classes with LDIFDE

• Can extend schema when creating instance by importing preconfigured LDIF files


AD LDS Management Tools (cont.)


AD LDS Management Tools (cont.)


Configuring AD LDS Replication

• If your AD LDS application requires fault tolerance or load balancing, you can create replicas of an AD LDS instance and configure replication between the instances

• Instances containing replicas of directory partitions are referred to as configuration sets

• AD LDS uses multimaster replication, and intrasite replication is configured automatically

• Frequency of intrasite replication can be configured


Synchronizing AD LDS with AD DS

• Manual user creation or importing users with LDIFDE works well when only a few users must authenticate to the AD LDS application or if the users aren’t part of a Windows domain

• If LDS is installed on a member server, you can synchronize AD DS user account information with an AD LDS instance

• Adamsync synchronizes Active Directory information with an AD LDS instance


Active Directory Federation Services

• Active Directory Federation Services (AD FS) allows single sign-on access to Web-based resources, even when resources are located in a different network belonging to another organization

• If many users must be maintained or users must communicate with many external companies, single sign-on reduces the number of times a user will need to re-enter his or her credentials


AD FS Overview

• AD FS provides functionality similar to a one-way forest trust, without requiring direct communication

• AD FS is designed to work over the Internet with a Web browser interface

• Main purpose of AD FS is to allow secure business-to-business transactions over the Internet


Federation Trusts

• A federation trust involves a trusting party and a trusted party; however, the term “partner” is used instead of “party”

• Federation trust is a one-way trust but can easily be made into a two-way trust

• The trusting partner is referred to as the resource partner, and the trusted partner is referred to as the account partner


Federation Trusts (cont.)


Account Partners and Resource Partners

• User accounts in the account partner can be AD or AD LDS user accounts

• When a user in the account partner organization accesses these resources, a federation server presents a security token for the user to the Web resources in the resource partner network

• The federation server in the resource partner’s network then grants or denies access based on this token


Claims-Aware Applications

• A claim is an agreed-on set of user attributes that both parties in a federation trust use to determine a user’s credentials, which specify the user’s permissions to resources in the partner’s network

• Claims typically include a user’s logon name and group members but can include other attributes


Windows NT Token Applications

• Applications that aren’t claims aware can still participate in AD FS

• These applications rely on Windows NT-style access tokens

• Tokens contain traditional user and group security principal SIDs

• Access control lists are used to determine user permissions to a resource


AD FS Role Services

• AD FS role consists of four role services that can be installed on one or more services

• Role services installed depend on whether you’re installing AD FS in an account partner’s or a resource partner’s network– Federation Service– Federation Service Proxy– AD FS Web agents

• Claims-aware agent

• Windows token-based agent


AD FS Design Concepts

• Web SSO– Simplest design, provides single sign-on access to multiple

Web applications for users who are external to the corporate network; no federation trust is used because there is only one federation server

• Federated Web SSO– Uses a federation trust relationship, with a federation server

running on both networks

• Federated Web SSO with Forest Trust– Involves a network with two AD forests, with one forest located

in the perimeter network and the other located in the internal network


AD FS Design Concepts (cont.)


AD FS Design Concepts (cont.)


Prepare to Deploy AD FS

• Some requirements for AD FS– AD FS is supported by Windows Server 2003 R2 Enterprise

and Datacenter editions and Windows Server 2008 Enterprise and Datacenter editions

– Federation servers, federation proxy servers, and Web servers hosting AD FS Web agents must be configured with TLS/SSL

– One or more account stores, such as AD DS or AD LDS, must be running on the network

– Certificates are required by federation servers, federation server proxies, and ADFS-enabled Web servers


Active Directory Rights Management Service

• Active Directory Rights Management Service (AD RMS) helps administrators secure data by controlling how a document can be used

• Actions such as copying, saving, forwarding, and even printing documents can be restricted

• To be effective, AD RMS requires AD RMS-enabled client or server applications


AD RMS Key Features

• AD RMS requires a client access license for each AD RMS client

• Some key features– AD FS integration– AD RMS Server self-enrollment– Administrator Role Delegation’s three roles

• AD RMS Enterprise Administrator

• AD RMS Auditor

• AD RMS Template Administrator


AD RMS Components

• AD RMS environment consists of several components, usually implemented as separate servers– An AD RMS server– An AD RMS database server– An Active Directory domain controller– An AD RMS-enabled client computer

• AD RMS process consists of two distinct actions: publication of AD RMS-protected documents and access of these documents by an AD RMS client


AD RMS Deployment

• AD RMS role has some requirements– A domain member server must be prepared for the AD RMS

role– Create a regular domain user account to be used as the AD

RMS service account– Make sure the user account for installing AD RMS has the right

to create new databases on the SQL server if you use an external database

– If an external database is used, install the database server before installing AD RMS

– Create a DNS CNAME record for the AD RMS cluster URL

• Once ready to install AD RMS, install the role and the required role services in Server Manager


AD RMS Deployment (cont.)








Read Only Domain Controllers

• The RODC was developed to address the need to have a domain controller in areas where expertise and security are often lacking

• An RODC performs many of the same tasks as a regular domain controller, but changes to Active Directory objects can’t be made on an RODC

• RODC maintains a current copy of AD information through replication


RODC Installation

• Before you can install an RODC, you must address these prerequisites:– A writeable Windows Server 2008 DC that the RODC can

replicate with must be operating in the domain– The forest functional level must be at least Windows Server

2003– If the forest functional level is not set at Windows Server 2008,

you must run the adprep /rodcprep command before install

• Installation of an RODC can be delegated


RODC Installation (cont.)


RODC Replication

• Replication on an RODC is unidirectional, meaning that data is replicated to the RODC, but never from the RODC to another DC

• If an RODC is compromised, any changes made won’t be replicated to the DCs in the rest of the network

• Administrators can also configure a filtered attribute set to prevent domain objects from being replicated to an RODC


Credential Caching

• If RODC caches no passwords, each user and computer authentication must be referred to a writeable DC, most likely across a WAN link

• Credential caching, when enabled, will cache the user’s password after it is retrieved from a writeable DC the first time a user logs on

• Credential caching can be controlled by the Password Replication Policy (PRP), accessed in the Properties dialog box of the RODC computer account


Credential Caching (cont.)


Credential Caching (cont.)


Administrator Role Separation

• A user is still required to perform maintenance operations on an RODC

• A writeable DC doesn’t have local users and requires a domain account to log on

• An RODC maintains a local user database instead, which allows users to log on to perform administrative tasks

• A user logging on with a local user account has administrative capabilities only on the RODC, a feature that is called administrator role separation and is configured with the dsmgmt command-line program


Read-Only DNS

• Installing DNS on an RODC will have all Active Directory integrated DNS zones, but they will be read only

• Zone information is replicated from other DNS servers, but zone changes can’t be made on the RODC

• Workstations using Dynamic DNS can’t create or update their DNS records on the RODC and instead must be referred to a DNS server that can handle the update

• The only DNS zones that can be created on an RODC are standard primary, secondary, or stub zones


Chapter Summary

• AD LDS is based on LDAP and provides the functionality of AD DS without some of the structural requirements, such as forests and domains

• AD LDS can be used for directory-enabled applications, directory consolidation, Web application authentication, AD DS application development environments, and migration of legacy X.500 applications

• AD FS allows single sign-on access to Web-based resources between business partners and in other situations when a single sign-on to diverse Web-based resources is needed


Chapter Summary (cont.)

• An AD FS installation involves four role services: Federation Service, Federation Service Proxy, and two AD FS Web agents, Claims-aware and Windows token-based

• AD RMS extends document security beyond file system permissions; it can restrict not only who can access a document, but also what users can do with a document after accessing it

• AD RMS consists of two distinct actions: publication of AD RMS-protected documents and access of these documents by AD RMS-enabled clients


Chapter Summary (cont.)

• RODCs were developed to provide secure Active Directory support in branch office installations where physical server security is lax and there are no on-site server administrators

• Replication on an RODC is unidirectional, and user passwords aren’t stored on the RODC by default

• If the DNS server role is installed on an RODC, Active Directory-integrated zones stored on the RODC are read only, but client computers can use the DNS server for DNS queries

Date post:	03-Jan-2016
Category:	Documents
Upload:	matthew-thornton
View:	41 times
Download:	7 times

MCTS Guide to Configuring Microsoft Windows Server 2008 Active Directory

Documents