Page 1 of 16

Understanding Active Directory Federation Services & Configuration

Windows Server 2008 Active Directory Federation Services

Update: 28/12/2012 by: Wichets, Consultant

E-SPACE TECHNOLOGIES CORPORATION

Page 2 of 16

What is AD FS

In general terms, AD FS is a single sign on (SSO) engine that allows users of your external web-based applications

to access and authenticate through a browser. That’s not so different from using an external AD LDS directory store

that is linked with your internal directory. However, the key feature of AD FS is that to authenticate a client, it uses

the internal authentication store of the user’s own domain and does not have a store of its own. It also uses the

original authentication the client performed in its own network and passes this authentication to all the web

applications that are AD FS–enabled.

The advantages are clear. Organizations need to manage only a single authentication store for their own users and

don’t need to manage secondary stores at all. Using an AD LDS directory for extranet authentication adds

administrative overhead because the organization needs to manage its own internal store and the external store or

stores as well. Users also often must remember several access codes and passwords to log on to each of these

stores. AD FS simplifies this because it federates the user’s internal AD DS identity and projects it to the external

world. Users need to authenticate only once: when they log on to their own network.

Using AD FS, you can form business-to-business (B2B) partnerships with very little overhead. In these B2B

partnerships, organizations fit into two categories:

Resource organization When organizations that have exposed resources such as websites—for example,

for e-commerce or collaboration—decide to use AD FS to simplify the authentication process to these

resources, they form partnerships with other organizations—suppliers, partners, and so on. The

organization that forms the partnership is deemed the resource organization because it hosts the shared

resources in its perimeter network.

Account organization When organizations enter into an AD FS relationship with resource organizations,

they are deemed the account organizations because they manage the accounts used to access the shared

resources in SSO designs.

AD FS supports one additional authentication mode. In a web SSO design, it authenticates users from anywhere on

the Internet. After users have been authenticated, AD FS examines the users’ attributes in AD DS directories to

identify which claims the users have to the application they are authenticating to.

To support this identity federation, AD FS relies on two role services:

Federation Service This service is created from the servers that share a trust policy. The federation server

routes authentication requests to the appropriate source directory to generate security tokens for the user

requesting access.

Federation Service Proxy To obtain the authentication requests from the user, the federation server relies

on a proxy server that is located in the perimeter network. The proxy collects authentication information

from the user’s browser through the WS-Federation Passive Requestor Profile (WS-F PRP), an AD FS web

service, and passes it on to the federation service.

Because it is based on a standard web service, AD FS does not need to rely on AD DS alone to support federated

identities. Any directory service that adheres to the WS-Federation standard can participate in an AD FS identity

federation.

Although Federation Services existed in Windows Server 2003 R2, AD FS has been improved significantly in

Windows Server 2008 R2 to facilitate the installation and administration processes. AD FS 2.0 also supports more

web-based applications than the original release did.

Page 3 of 16

1. Working with AD FS Designs

AD FS supports three configurations or architectural designs, depending on the type of B2B partnership you need to

establish. Each configuration includes its own particularities, and each supports a particular partnership scenario.

Federated Web SSO This model usually spans several firewalls because it links applications contained

within an extranet in a resource organization to the internal directory stores of account organizations. The

only trust that exists in this model is the federation trust, which is always a one-way trust from the resource

organization to an account organization. This is the most common AD FS configuration. (See Figure 1.)

Web SSO When some of the users for an extranet application are external and do not have accounts within

an AD DS domain, you must deploy Web SSO only. The Web SSO model allows the users to authenticate

only once to multiple web applications. This means that external users who do not have an account in your

internal AD DS and internal users who have an account within the internal AD DS both have access to your

web applications. Your internal users rely on their own accounts, and external users rely on accounts stored

either within an external AD DS or a SQL Server store. (See Figure 2.)

Federation with Cloud Services When you require access to cloud-based services such as Windows Azure

and services such as SharePoint Online or Exchange Online, you can rely on AD FS to provide single sign

on. AD FS provides SSO support for both Microsoft and non-Microsoft cloud services.

Ideally, all members of your identity federation deployment will have their own AD DS directory and act as account

organizations to simplify your deployment strategy. However, AD FS can also be used to provide individual Internet

users with access to your external web-based applications.

Page 4 of 16

Figure 1. Using a Federated Web SSO federation configuration

Figure 2. Using a Web SSO federation configuration

In fact, AD FS can be used in three deployment scenarios:

Scenario 1 Provide SSO to your internal AD DS users. In this scenario, your users log in to AD DS and rely

on their AD DS account to grant them access to your own federated applications.

Scenario 2 Provide SSO to partner applications to your own users. This scenario includes all of the features

of scenario 1 and can also support remote access over the Internet.

Scenario 3 Provide access to your web-based applications to others. This scenario allows users of either a

partner organization or the Internet to access your own web-based applications.

Each scenario is not exclusive. For example, scenario 2 includes the capabilities of scenario 1, and scenario 3 can

easily be added on to either scenario 1 or 2.

Page 5 of 16

2. Understanding AD FS Components

As you have seen, AD FS relies on a special terminology of its own. To gain a better understanding of the AD FS

components, it is important to review and understand this terminology as well as to review and understand the basic

functionality of the AD FS components.

2.1. Understanding AD FS Terminology

Table 1 outlines the most common terms used in AD FS. Many of these terms are explained more fully in the

sections that follow.

Table 1. Common AD FS Terms

TERM DESCRIPTION

Account

federation server

The federation server that is hosted in the account organization’s internal network. This server

issues security tokens to users based on prior user authentication. Basically, this server

authenticates the user, extracts federation attributes and group memberships from the attribute

store, creates a claim containing this information, and then generates and signs the security

token that is returned to the user. This token can then be used within the internal organization

or sent to a partner organization for application access.

AD FS

configuration

database

The database used to store all of the configuration data that defines an AD FS 2.0 instance or

Federation Service. This database can be stored either within SQL Server or within the

Windows Internal Database (or WID—a feature of Windows Server 2008 R2). If stored within

WID, the database is created through the AD FS 2.0 Federation Server Configuration Wizard. If

stored within SQL Server, the database must be created using the Fsconfig.exe command-line

tool.

Account partner

organization

The partner that hosts the AD DS directory that contains the accounts of the users who access

extranet applications contained within the resource organization’s web servers. This partner is

represented by a claims provider trust in the Federation Service.

Attribute store A container—either a database such as SQL Server or a directory such as AD DS—that

includes attributes about clients.

Claim The statement the federation server makes about a user or client.

Claims-aware

application A web-based application that can interpret claims to grant user access.

Claims provider The organization that provides claims to its users, usually the account partner organization.

Claims provider

trust

The one-way trust between a resource organization and the account organizations which with it

wants to partner. This trust is composed of identifiers, names, and rules that provide the

account partner organization’s identity to the Federation Service.

Federated user Any user who has been granted appropriate claims in the account organization to access

applications in the resource organization.

Federation Any two organizations that have established a federation trust.

Federation

metadata

The format used to communicate data between the members of a Federation Service. The data

format stems from Security Assertion Markup Language (SAML) 2.0 and is extended within the

WS-Federation.

Federation

server

The internal server that performs claims mapping and issues access security tokens for users

who need to work with an application.

Federation

server proxy

A server located in a perimeter network. Its purpose is to forward client requests from the

Internet to a Federation Service that is located on the internal corporate network.

Page 6 of 16

Primary

federation server

(WID

configuration

database only)

A computer running the Windows Server 2008 R2 federation server role that has read and write

access to the Federation Service configuration database contained within the Windows Internal

Database. This server is created when you first run the AD FS 2.0 Federation Server

Configuration Wizard and choose to create a new Federation Service. The primary federation

server (PFS) is the first server in a federation farm. All other servers have read-only access to

the database and must replicate changes made on the PFS to their own internal copy of the

database.

Note: A PFS exists only when you are using a WID configuration database. When you are

using a SQL Server configuration database, all federation servers have read and write access.

Identity

Metasystem

Interoperability

Protocol (IMIP)

The protocol hat outlines how to provision Information Cards. AD FS 2.0 implements version

1.1 of the protocol. IMIP is approved by the Organization for the Advancement of Structured

Information Standards (OASIS) Identity Metasystem Interoperability Technical Committee.

Information Card

Represents digital identities. Users see Information Cards as a picture of an identity card on

their computer screen. Administrators see them as containing the details of the Federation

Service to obtain claims. Information Cards can either be managed—issued by a claims

provider—or personal—issued by users themselves.

Information Card

Group Policies

AD FS 2.0 issues two Group Policy objects that outline how to provision and how to use

Information Cards within an AD DS directory.

Relying party The resource organization that processes claims sent by partners.

Relying party

trust

Composed, like the claims provider trust, of identifiers, names, and rules that provide the

partner organization’s or web application’s identity to the Federation Service. Relying party

trusts are used in two situations:

— Within account partner organizations to identify the source of the trusted accounts that a

resource organization will rely on to grant access.

— Within a resource organization to identify the trust between a web-based application and the

Federation Service.

Resource

federation server

The federation server within the resource organization. This server issues access tokens to

web-based applications when it receives valid user account tokens from the account

organization. After it receives the account security token, it verifies the signature of the token,

applies a claim rule set to the appropriate access rights within the web application, and

generates a new signed token to be sent out with the outgoing claims to both the user and the

web application.

Resource

partner

organization

The organization that hosts the federated applications in its perimeter network and accepts

access requests from account partners.

Security

Assertion

Markup

Language

(SAML)

Defines the web SSO protocol that outlines how to use HTTP web browser redirects to

exchange assertion data used to authenticate and authorize clients across firewalls.

SAML security

token

A special data format used to exchange claims between claims providers and relying parties.

Members of a Federation Service based on AD FS 2.0 can use either SAML 1.1 or 2.0 tokens.

Page 7 of 16

Web services

(WS-*)

A standards-based Internet service that forms part of an SOA. Commonly known web services

include the Simple Object Access Protocol (SOAP), Extensible Markup Language (XML), and

Universal Description, Discovery, and Integration (UDDI). Web services are language-agnostic

so they can interoperate between different IT infrastructures, such as UNIX, Linux, and

Windows.

WS-Federation The web server specification that outlines the standards to be used when implementing

federation.

2.2. Core AD FS Components

To operate, AD FS relies on several core components:

Attribute store

AD FS configuration database

Claims

Claim rules

Each of these components provides additional support to the AD FS process.

2.3. The AD FS Attribute Store

As mentioned in Table 17-1, attribute stores can be a database or a directory. They are used to store user accounts

and their associated attribute values. AD FS reads user attributes values from the store and relies on this

information to create claims. These claims are provided to web-based applications so that they can grant

appropriate authorizations to federated users.

Attribute stores can be used to provide authorization to web-based applications located either within an intranet or

the Internet. Stores can be databases running on any edition of SQL Server 2005 or 2008, directories running AD

DS, or custom attribute stores.

2.4. The AD FS Configuration Database

The configuration database determines the scope of a single instance of AD FS. The database can be contained

within the Windows Internal Database, in which case it is configured using the AD FS Federation Server

Configuration Wizard, or it can be contained within SQL Server, in which case it must be created through the

Fsconfig.exe utility.

When running the configuration database in WID, you cannot configure additional parameters through a database

user interface. Instead, you must rely on the AD FS management snap-in, FSconfig.exe, or PowerShell cmdlets.

SQL Server databases can be modified through any of these user interfaces or the SQL Server management tools.

WID configuration databases highly resemble the old Windows NT directory service in that a primary read-write

database is created on the initial federation server—the primary federation server—in an AD FS deployment; then it

is replicated as a read-only database on all other, secondary, federation servers within the same deployment.

Secondary servers poll the primary server for database changes every five minutes. This value can be adjusted

through the Get-ADFSSyncProperties and Set-ADFSSyncProperties PowerShell cmdlets.

WID databases can be used for either stand-alone or federation server farm deployments. In stand-alone

deployments, the WID database is only configured to maintain a single instance and cannot be shared with other

servers. Use this only for test deployments. In farm deployments, the WID database is configured for replication and

growth as new servers are added to the AD FS farm.

Page 8 of 16

SQL Server configuration databases are located centrally and do not need to be placed on a federation server.

Each server within the deployment has read-write access to this database. SQL Server also provides performance

enhancements to AD FS in situations of high traffic. In large deployments, the SQL Server database should be

protected either through mirroring or clustering services. SQL Server also provides support for SAML artifact

resolution and SAML/WS-Federation token replay detection. This means that your federation servers automatically

discard token replays when they are detected. Token replays occur when a user continually tries to authenticate

using the same credentials to the server by using the Back button on a web page. For example, a malicious user

could try to impersonate a valid user by using web browser history to attempt to log in. Therefore, you should rely

on SQL Server whenever security is a high concern for your web-based applications.

2.5. Claims

In their most basic form, claims are statements that each partner in an AD FS relationship makes about its users.

Claims can be based on several values—for example, user names, certificate keys, group memberships, specific

privileges, and so on. Claims are the basis of the authorization that AD FS sends to the web application. Claims can

be sourced in two ways:

The value can originate from an AD DS attribute store, such as a group membership of a user account.

The value can be transformed into another by applying a rule.

AD FS can support several types of claims:

A user principal name (UPN) representing the user’s identity in a format that resembles an email address

(username@accountdomain).

A standard email address (username@emaildomain).

Common names, which are really nothing more than arbitrary strings of characters.

The group memberships a user belongs to can also be used in a claim. Because a user can belong to

several groups, you can provide several group claim types in a claim. For example, the same user can

belong to the Tester, Developer, and User groups for an application.

Claim types also include roles, private personal identifiers (PPID), SAML name identifiers, user account or

group account SIDs, and Windows account names.

Claims are transported through the claims pipeline within the Federation Service. The claims pipeline is detailed in

the next section.

2.6. Claim Rules

Claim rules represent business logic that takes incoming claims, apply conditions to them, and generate outgoing

claims. They are actual administrative representations of how you can customize the flow of claims through a

Federation Service implementation. Claim rules are processed through the claims engine—the actual AD FS

component that applies business logic to claims. Administrators rely on rules to determine how claims within the

claims pipeline—the Federation Service implementation—will be processed and released to the relying parties

within the pipeline. Rules also support the permission or denial of access to resources within the Federation

Service.

The claims engine, together with claim rules associated to a particular federated trust, determines how claims are

processed. Claims can be processed in one of three ways:

They can be passed through as they are.

They can be filtered to meet specific conditions.

They can be transformed into completely new claims.

Page 9 of 16

Administrators rely on claim rule templates—preconfigured generic rules—to generate custom claim rules within

their Federation Service deployment. Claim rule templates also contain the claim rule language that is required to

apply a rule through the claims engine. The exception is the custom rule template: Other templates represent

common administrative tasks within an AD FS deployment and the corresponding claim rule language, but this

template does not contain any claim rule language and should be used only when you are ready to generate the

rule language syntax on your own.

Templates included with AD FS 2.0 allow for the generation of rules supporting the following tasks:

Pass through or filter an incoming claim

Transform an incoming claim

Send LDAP attributes as claims

Send group membership as claims

Send claims using a custom rule

Permit or deny users based on an incoming claim

Permit all users

Templates can be used within the AD FS management snap-in or through the New-ADFSClaimRuleSet cmdlet.

After they are generated, claim rules can be used singly or as a set (a group of one or more rules). Claim rule sets

are processed in the order specified by the administrator and generate a result based on the cumulative application

of each rule within the set. Claim rule sets are applied to specific federated trusts. A single federated trust can

include several claim rule sets.

Basically, AD FS allows you to generate a partnership that supports access to applications through the generation

of claims. Claims can originate from within your own organization or from within partner organizations and are

transformed when processed by the claims engine through claim rule sets.

2.7. Understanding AD FS Certificates

To ensure secure communication, the AD FS implementation uses several certificate types. In fact, AD FS can rely

on your AD CS deployment to obtain the certificates it needs, especially if your AD CS deployment relies on a

trusted root. Each server role within an AD FS deployment relies on certificates. The type of certificate required by

the role depends on its purpose.

Federation servers The federation server must have both a server authentication certificate and a token-

signing certificate installed before it can perform any AD FS operations and become fully functional. In

addition, the trust policy that forms the basic tenet of the federation relationship must rely on a verification

certificate. The latter is nothing more than the public key of the token-signing certificate.

o The server authentication certificate is an SSL authentication certificate that secures web traffic

between the federation server and the Federation Service Proxy or the web clients. This certificate

must be bound to the Default Web Site in IIS. Ideally, this certificate originates from a trusted root,

which facilitates client operation with the AD FS servers. The subject name for the certificate should

reflect your Federation Service name, usually your organization’s name. Note that the server

authentication certificate is referred to as the Service Communication Certificate in the AD FS 2.0

management console.

o Each time the federation server generates a security token, it must digitally sign the token with its

token-signing certificate. Signing certificates ensures that it cannot be tampered with during transit.

The token-signing certificate is made up of a private and public key pair. AD FS issues a self-signed

certificate at installation. Replace this certificate with one from a trusted root in a production

Page 10 of 16

deployment.

o Each time a federation server must decrypt an incoming token, it must rely on a token decryption

certificate. This certificate is included with the incoming tokens as well as in the federation

metadata. AD FS issues a self-signed certificate at installation. Replace this certificate with one

from a trusted root in a production deployment.

Federation Service proxies Proxies must have a server authentication certificate to support SSL-encrypted

communication with web clients.

AD FS can easily rely on AD CS to obtain and manage these certificates. Keep in mind, however, that because

many of the AD FS roles are outward-facing, your certificates must be from a trusted certification authority;

otherwise, you must modify the Trusted CA store on each web client. In addition, remember that because

certificates are such an important part of AD FS operation, they should be backed up and protected regularly.

2.8. AD FS 2.0 vs. AD FS 1.1

The major difference between AD FS 1.1 released with Windows Server 2008 R2 and AD FS 2.0 is the reliance on

standards. AD FS 2.0 is completely built on the interoperability standards set out by the OASIS Technical

Committee and, as such, its features and its terminology have changed to match the elements outlined in this

standard.

As mentioned earlier, AD FS allows you to deploy three different scenarios, all built one upon the other. You can

provide access to web-based applications for your own AD DS users, you can add Internet user support, and you

can add partner user support. Each of these requires different configurations within your organization. In addition,

AD FS 2.0 can now be integrated with third-party attribute stores including Computer Associates’ Federation

Manager, Oracle’s Identity Federation, IBM’s Tivoli, and any other product that supports both the WS* and the

SAML standards.

Organizations already using AD FS 1.0 (from Windows Server 2003 R2) or 1.1 can migrate their installations to 2.0

or simply continue using the 1.x version along with a new deployment of 2.0. Remember that, in AD FS 2.0:

AD LDS is no longer supported as an attribute store.

The Windows NT token-based web agent is no longer supported.

The AD FS 1.x claims-aware web agent for Microsoft Office SharePoint Server 2007 is no longer supported.

Rely on SharePoint 2010 instead.

The Federated Web Single Sign On with Forest Trust deployment scenario is no longer supported.

Overall, AD FS 2.0 deployment scenarios are simpler and easier to support than AD FS 1.x deployment scenarios,

yet they provide more functionality and full support for cloud interoperability.

3. Installing Active Directory Federation Services 2.0

A complete installation of AD FS requires a series of computers. Ideally, you would have two AD DS domains, two

perimeter networks, and AD FS servers distributed within each environment. The account organization or claims

provider should host AD DS and at least one federation server internally as well as a federation server proxy (FSP)

in its perimeter network. Note that the FSP is required only if you intend to allow users to work with the Federation

Service from the Internet. The resource organization or relying party should host AD DS and at least one internal

federation server. Its perimeter network should include at least one AD FS–enabled web server and one FSP.

However, the full deployment you design should be based on considerations such as the number of partner

organizations, the type of applications to share, the requirement for high availability and load balancing, and other

considerations of this type.

Page 11 of 16

Test environments can be set up with as few as four computers: one client, one AD FS–enabled web server, and

two federation servers to participate in AD FS federation between two organizations. Because of the nature of AD

FS, computer clocks should be synchronized to the same time or should never have more than five minutes of

difference between one and the other; otherwise, the process will not work because the token time stamps will be

invalid. Because many of the computers are not part of an AD DS domain, you cannot rely on the PDC Emulator

Operations Master for clock synchronization. The best way to ensure time synchronization is to use the Network

Time Protocol (NTP) to link each server to an external clock server.

3.1. AD FS Installation Requirements

To prepare for an AD FS deployment, you must begin with its prerequisites. Table 2 lists requirements for AD FS

2.0 for both the Web SSO and the Federated Web SSO designs.

Table 2. AD FS Deployment Requirements

HARDWARE/SOFTWARE REQUIREMENT NOTE

CPU speed 1 GHz for single core, 2

GHz for quad core

Because of the low processor, memory, and disk

space requirements for AD FS server roles, you can

easily virtualize this role through Hyper-V.

RAM 1 GB

Recommended: 4 GB. AD FS is not a memory-

intensive process, but it is always best to allocate as

much RAM as possible.

Hard disk space 50 MB for the AD FS

installation

Recommended: a large system volume of at least 100

GB to ensure space for growth.

Operating system

Windows Server 2008 R2

Enterprise edition or

Datacenter edition or

Windows Small Business

Server 2008

The Federation Service and the Federation Service

Proxy are designed for the latest Windows Server

editions. All required hotfixes are also installed during

AD FS 2.0 installation.

Web services

IIS with ASP.NET

enabled and .NET

Framework 3.5 SP1

Use IIS 7.0 or 7.5 with the latest .NET Framework.

Installation location Default location on the

system drive

The federation service and Federation Service Proxy

cannot coexist on the same server.

AD DS account store

requirements

At least a single domain

forest

Recommended: a minimum of two forests.

Installation certificate for

TLS/SSL and token signing

An SSL server

authentication certificate

for each deployed AD FS

server role

Rely on an external third-party commercial CA to

obtain a trusted certificate or enterprise CAs. Use self-

signed certificates only in testing environments. Each

of the federation servers and the Federation Service

Proxy needs an authentication certificate from a

trusted root chain.

TCP/IP network connectivity

IPv4 or IPv6 connectivity,

ideally static address

assignments

Network connectivity must exist between client,

domain controller, and computers hosting the

federation server and the federation server proxy.

Web browser

Microsoft Internet

Explorer 7.0 or 8.0,

Mozilla Firefox 3.0, or

Safari 3.1

JavaScript and at least trusted cookies must be

enabled for browser to work with the federation

service.

Page 12 of 16

Client operating system Windows XP, Windows

Vista, or Windows 7

Recommended: Windows 7.

Domain membership AD DS domain

membership

Federated servers must be members of the domain.

Proxies do not require AD DS membership. Do not

install AD FS on a domain controller.

Attribute store AD DS or SQL Server

An AD DS attribute store is created by default at

installation. You can also rely on a custom attribute

store.

Windows Identity Foundation

(WIF)

Downloadable

component

WIF is required to externalize user access from

applications via claims.

Windows PowerShell PowerShell feature PowerShell is required to facilitate AD FS

management.

3.1.1. Practice Prepare an AD FS Deployment

In this practice, you create a complex AD FS environment that consists of several computers. Table 3 outlines the

roles that each domain and computer plays in your AD FS deployment.

Table 3. AD FS Computer Roles

DOMAIN NAME ROLE

contoso.com Account domain

woodgrovebank.com Resource domain

COMPUTER NAME ROLE

SERVER01 AD DS domain controller for contoso.com, the account domain

SERVER03 The federation server for contoso.com, the account domain; must be a member of the

contoso.com domain

SERVER06 AD DS domain controller for woodgrovebank.com, the resource domain

SERVER07 The federation server for woodgrovebank.com, the resource domain; must be a

member of the woodgrovebank.com domain

You begin by preparing the DNS in each forest in the first exercise, and then install the federation servers in each

forest in the second exercise.

EXERCISE 1 Configure Cross-DNS References

In this exercise, you configure the DNS servers in both forests to refer to the servers in the other forest. Because

each forest is independent of the other, their DNS servers do not know about the other. To exchange information

between one forest and the other, you must implement cross-DNS references in both forests. The easiest way to do

this is to use forwarders from one domain to the other and vice versa. Make sure SERVER01 and SERVER06 are

running.

1. Log on to SERVER01 with the domain Administrator account.

2. Launch Server Manager from the Administrative Tools program group.

3. Expand Roles\DNS Server\DNS\SERVER01.

4. Right-click SERVER01 in the tree pane and select Properties.

5. On the Forwarders tab, click Edit.

6. Type the IP address of SERVER06 and click OK twice.

7. Repeat the procedure in reverse on SERVER06; that is, add the SERVER01 IP address as a forwarder for

Page 13 of 16

SERVER06.

8. Test the operation by pinging each server from the other. For example, use the following command to ping

SERVER01 from SERVER06:

ping server01.contoso.com

You should receive a response stating the IP address of SERVER01. If you experience problems, try

restarting SERVER06.

9. Finally, add a host (A) resource record for the federation servers and the federation proxy servers within

both domains. On SERVER01, expand Roles\DNS Server\DNS\SERVER01\Forward Lookup Zones and

select contoso.com. Right-click the details pane and click New Host (A Or AAAA).

10. Add FS (for SERVER03) and its corresponding IP address. Click Add Host, click OK, and then click Done.

Repeat steps 9 and 10 on SERVER06 for woodgrovebank.com to add FS (for SERVER07) and its

corresponding IP address.

EXECISE 2 Install the Federation Servers

In this exercise, you install the federation servers. This involves the installation of the server role plus the required

support services for the role. Make sure SERVER01, SERVER03, SERVER06, and SERVER07 are running.

Log on to SERVER07 with the domain Administrator account.

1. Your privileges need not be as high as the domain administrator to install and work with AD FS, but using

these credentials here facilitates the exercise. Only local administrative privileges are required to work with

AD FS.

2. Locate the ADFSSetup.exe file that you downloaded, and launch the AD FS setup process. Click Run in the

Open File – Security Warning dialog box. Click Next in the Welcome screen.

3. Accept the License Agreement and click Next.

4. On the Server Role page, select Federation Server. Click Next.

5. The installation warns you that it will check for and install any missing prerequisite software. Click Next to

begin the installation.

6. When the installation is complete, make sure the Start the AD FS 2.0 Management Snap-in When This

Wizard Closes check box is selected, and click Finish to close the installation wizard.

7. Repeat the same procedure for SERVER03.

This process can take considerable time if the prerequisites were not installed prior to the installation of AD

FS.

You can also install the federation server role through the command line with the following command:

adfssetup.exe /quiet

Page 14 of 16

Appendix ADFS with External Web Server, Load Balancer & Network Topology:

Appendix ADFS with External Web Server, Load Balancer with Perimeter Network Topology:

Page 15 of 16

Appendix ADFS with Office 365, Load Balancer & Network Topology:

Appendix ADFS with Smart Card Auth:

Page 16 of 16

Appendix ADFS with UAG / TMG: