Read Windows Server 2008 R2 Unleashed Online
Authors: Noel Morimoto
232
CHAPTER 8
Creating Federated Forests and Lightweight Directories
FIGURE 8.4
Importing LDIF files into the AD LDS instance.
ptg
FIGURE 8.5
Connecting to the AD LDS instance.
instance can be performed. In addition, some custom applications might have their own
front end for AD LDS, allowing for eased administration of the instance.
Active Directory Federation Services
Active Directory Federation Services (AD FS) provides for Single Sign-On (SSO) capabilities
across multiple platforms, including non-Microsoft environments. By managing web-based
logon identities and tying them together, through Windows logon authentication, organi-
zations can more easily manage customer access to web-based applications without
compromising internal security infrastructure.
AD FS is managed from an MMC administrative tool, shown in Figure 8.6, which can be
installed on a Windows Server 2008 R2 Enterprise Edition or Datacenter Edition system.
Active Directory Federation Services
233
FIGURE 8.6
Viewing the AD FS MMC administrative tool.
AD FS is not a replacement for technologies such as Forefront Identity Manager (FIM), a
directory sync product introduced later in this chapter. Instead of synchronizing identities
across various directories as FIM does, AD FS manages logon attempts to web applications
made from disparate directories. It is important to understand this concept because AD FS
ptg
and FIM perform different roles in an organization’s environment.
Understanding the Key Components of AD FS
AD FS is composed of three different server components, as follows:
.
Federation server—
A federation server is the main AD FS component, which holds
the Federation Service role. These servers route authentication requests between
connected directories.
.
Federation proxy server—
A federation proxy server acts as a reverse proxy for AD
FS authentication requests. This type of server normally resides in the demilitarized
8
zone (DMZ) of a firewall, and is used to protect the back-end AD FS server from
direct exposure to the untrusted Internet.
.
AD FS Web Agents—
The Web Agents component of AD FS hosts the claims-aware
agent and the Windows token-based agent components that manage authentication
cookies sent to web server applications.
Each one of these components can be individually installed in an AD FS structure, or they
can be all installed on the same system.
Installing AD FS with Windows Server 2008 R2
Installation of the AD FS role on a server can be performed via the following process:
1. From the server, open the Server Manager Application (Start, All Programs,
Administrative Tools, Server Manager).
2. Navigate to the Roles node, and then click the Add Roles link.
234
CHAPTER 8
Creating Federated Forests and Lightweight Directories
3. On the Before You Begin page, review the notes provided, and click Next to continue.
4. From the list of server roles, choose Active Directory Federation Services by checking
the box next to it. Click Next to continue.
5. On the Introduction to Active Directory Federations Services page, review the infor-
mation provided, and click Next to continue.
6. On the Select Role Services page, select which roles to install, as shown in Figure 8.7.
By clicking on the roles, you might be prompted to install additional components to
make those roles work. For example, IIS and a few other components are required for
the Federation Service role. If necessary, click to install those items as well. After you
have selected the appropriate check boxes, click Next to continue.
ptg
FIGURE 8.7
Installing the Active Directory Federation Services role.
7. Select whether to create a server authentication certificate or to choose an existing
certificate installed on the server. Because SSL encryption is required for AD FS, a
certificate from either a trusted internal Certificate Authority or an external trusted
authority (most common scenario) must be used to install ADFS. Click Import if a
certificate is available, but it must be installed locally on the server. After making
your selection, click Next. If you are only installing AD FS for testing purposes, select
to create a self-signed certificate, and click Next to continue.
8. On the subsequent page, choose a token-signing certificate, using the same process
outlined in the previous step. This certificate can be created from an internal CA (if
available) or imported from an external certificate provider. If using AD FS for testing,
you can select to create a self-signed token-signing certificate. Click Next to continue.
Active Directory Federation Services
235
9. On the Select Trust Policy page, select to either create a new trust policy for the type
of claims used by your organization or to use an existing one, as shown in Figure
8.8. Click Next to continue.
ptg
FIGURE 8.8
Selecting a trust policy for AD FS.
10. If additional components such as IIS were selected for installation, the Add Roles
Wizard will continue with selections for those roles. Follow through the wizard for
these roles, if necessary, until the Install button becomes available in the wizard.
8
Click the Install button to begin configuration of AD FS.
11. Click Close when the Add Roles Wizard is complete.
Working with AD FS
AD FS works by inputting information about connected partners, such as AD forests or AD
LDS organizations, and inputting specific partner and application information. Each set of
information can be inputted by running the various wizards installed by AD FS, as follows:
.
Add Resource Partner Wizard—
This wizard allows for resource partners to be
manually created or automatically imported by using an Extensible Markup
Language (XML) file. Resource partners contain information about the specific web-
based applications that users can access.
.
Add Account Partner Wizard—
This wizard adds the information about specific
account partners, which are connected security token issuers, such as domain
controllers.
236
CHAPTER 8
Creating Federated Forests and Lightweight Directories
.
Add Applications Wizard—
This wizard adds specific claims-aware applications to
AD FS.
By entering in the information about the various web-based applications, and which direc-
tories and identities are to be granted access, AD FS can provide for seamless sign-on capa-
bilities between various directories. It can be a valuable asset for an organization that
wants to share corporate information with trusted partners, but without exposing their
valuable internal assets to unnecessary exposure.
Synchronizing Directory Information with Forefront
In most enterprises today, each individual application or system has its own user database
or directory to track who is permitted to use that resource. Identity and access control
data reside in different directories as well as applications such as specialized network
resource directories, mail servers, human resource, voice mail, payroll, and many other
applications.
Each has its own definition of the user’s “identity” (for example, name, title, ID numbers,
roles, membership in groups). Many have their own password and process for authenticat-
ing users. Each has its own tool for managing user accounts and, sometimes, its own dedi-
ptg
cated administrator responsible for this task. In addition, most enterprises have multiple
processes for requesting resources and for granting and changing access rights. Some of
these are automated, but many are paper-based. Many differ from business unit to busi-
ness unit, even when performing the same function.
Administration of these multiple repositories often leads to time-consuming and redun-
dant efforts in administration and provisioning. It also causes frustration for users, requir-
ing them to remember multiple IDs and passwords for different applications and systems.
The larger the organization, the greater the potential variety of these repositories and the
effort required to keep them updated.
In response to this problem, Microsoft developed Microsoft Metadirectory Services (MMS)
to provide for identity synchronization between different directories. As the product
improved, it was rereleased under the new name Microsoft Identity Integration Server
(MIIS). For a third time, the tool was renamed, this time as Identity Lifecycle Manager
(ILM) 2007. The latest and fourth rename of this tool took place shortly before the release
of Exchange Server 2010—Microsoft has now incorporated this tool into their Forefront
security line, and named it Forefront Identity Manager (FIM).
The use of FIM for Exchange Server 2010 is particularly useful because it can synchronize
information between the AD forest that contains Exchange and the other messaging
systems in use within the organization.
Synchronizing Directory Information with Forefront Identity Manager (FIM)
237
Understanding FIM
FIM is a system that manages and coordinates identity information from multiple data
sources in an organization, enabling you to combine that information into a single logical
view that represents all of the identity information for a given user or resource.
FIM enables a company to synchronize identity information across a wide variety of
heterogeneous directory and identity stores. This enables customers to automate the
process of updating identity information across heterogeneous platforms while maintain-
ing the integrity and ownership of that data across the enterprise.
Password management capabilities enable end users or help desk staff to easily reset pass-
words across multiple systems from one easy-to-use web interface. End users and help desk
staff no longer have to use multiple tools to change their passwords across multiple systems.
Understanding FIM Concepts
It is important to understand some key terms used with FIM before comprehending how it
can be used to integrate various directories. Keep in mind that the following terms are
used to describe FIM concepts but might also help give you a broader understanding of
how metadirectories function in general: