Windows Server 2008 Active Directory ADFS Claims-base Idm for Windows Part 2

1. 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 1 of 16

2. 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 2 of 16

3. 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 3 of 16

4. 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 4 of 16

5. 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
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
Account authenticates the user, extracts federation attributes and group memberships from the attribute
federation server 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.
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
AD FS
Windows Internal Database (or WID—a feature of Windows Server 2008 R2). If stored within
configuration
WID, the database is created through the AD FS 2.0 Federation Server Configuration Wizard. If
database
stored within SQL Server, the database must be created using the Fsconfig.exe command-line
tool.
The partner that hosts the AD DS directory that contains the accounts of the users who access
Account partner
extranet applications contained within the resource organization’s web servers. This partner is
organization
represented by a claims provider trust in the Federation Service.
A container—either a database such as SQL Server or a directory such as AD DS—that
Attribute store
includes attributes about clients.
Claim The statement the federation server makes about a user or client.
Claims-aware
A web-based application that can interpret claims to grant user access.
application
Claims provider The organization that provides claims to its users, usually the account partner organization.
The one-way trust between a resource organization and the account organizations which with it
Claims provider
wants to partner. This trust is composed of identifiers, names, and rules that provide the
trust
account partner organization’s identity to the Federation Service.
Any user who has been granted appropriate claims in the account organization to access
Federated user
applications in the resource organization.
Federation Any two organizations that have established a federation trust.
The format used to communicate data between the members of a Federation Service. The data
Federation
format stems from Security Assertion Markup Language (SAML) 2.0 and is extended within the
metadata
WS-Federation.
Federation The internal server that performs claims mapping and issues access security tokens for users
server who need to work with an application.
Federation A server located in a perimeter network. Its purpose is to forward client requests from the
server proxy Internet to a Federation Service that is located on the internal corporate network.
Page 5 of 16

6. 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
Primary Database. This server is created when you first run the AD FS 2.0 Federation Server
federation server Configuration Wizard and choose to create a new Federation Service. The primary federation
(WID server (PFS) is the first server in a federation farm. All other servers have read-only access to
configuration the database and must replicate changes made on the PFS to their own internal copy of the
database only) 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
The protocol hat outlines how to provision Information Cards. AD FS 2.0 implements version
Metasystem
1.1 of the protocol. IMIP is approved by the Organization for the Advancement of Structured
Interoperability
Information Standards (OASIS) Identity Metasystem Interoperability Technical Committee.
Protocol (IMIP)
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
Information Card
Service to obtain claims. Information Cards can either be managed—issued by a claims
provider—or personal—issued by users themselves.
Information Card AD FS 2.0 issues two Group Policy objects that outline how to provision and how to use
Group Policies Information Cards within an AD DS directory.
Relying party The resource organization that processes claims sent by partners.
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:
Relying party
— Within account partner organizations to identify the source of the trusted accounts that a
trust
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.
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
Resource organization. After it receives the account security token, it verifies the signature of the token,
federation server 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
The organization that hosts the federated applications in its perimeter network and accepts
partner
access requests from account partners.
organization
Security
Assertion
Defines the web SSO protocol that outlines how to use HTTP web browser redirects to
Markup
exchange assertion data used to authenticate and authorize clients across firewalls.
Language
(SAML)
SAML security A special data format used to exchange claims between claims providers and relying parties.
token Members of a Federation Service based on AD FS 2.0 can use either SAML 1.1 or 2.0 tokens.
Page 6 of 16

7. 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
Web services
Universal Description, Discovery, and Integration (UDDI). Web services are language-agnostic
(WS-*)
so they can interoperate between different IT infrastructures, such as UNIX, Linux, and
Windows.
The web server specification that outlines the standards to be used when implementing
WS-Federation
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 7 of 16

8. 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 8 of 16

9. 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 9 of 16

10. 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 10 of 16

11. 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
Because of the low processor, memory, and disk
1 GHz for single core, 2
CPU speed space requirements for AD FS server roles, you can
GHz for quad core
easily virtualize this role through Hyper-V.
Recommended: 4 GB. AD FS is not a memory-
RAM 1 GB intensive process, but it is always best to allocate as
much RAM as possible.
50 MB for the AD FS Recommended: a large system volume of at least 100
Hard disk space
installation GB to ensure space for growth.
Windows Server 2008 R2 The Federation Service and the Federation Service
Enterprise edition or Proxy are designed for the latest Windows Server
Operating system Datacenter edition or editions. All required hotfixes are also installed during
Windows Small Business AD FS 2.0 installation.
Server 2008
IIS with ASP.NET Use IIS 7.0 or 7.5 with the latest .NET Framework.
Web services enabled and .NET
Framework 3.5 SP1
Default location on the The federation service and Federation Service Proxy
Installation location
system drive cannot coexist on the same server.
AD DS account store At least a single domain Recommended: a minimum of two forests.
requirements forest
Rely on an external third-party commercial CA to
An SSL server obtain a trusted certificate or enterprise CAs. Use self-
Installation certificate for authentication certificate signed certificates only in testing environments. Each
TLS/SSL and token signing for each deployed AD FS of the federation servers and the Federation Service
server role Proxy needs an authentication certificate from a
trusted root chain.
IPv4 or IPv6 connectivity, Network connectivity must exist between client,
TCP/IP network connectivity ideally static address domain controller, and computers hosting the
assignments federation server and the federation server proxy.
Microsoft Internet JavaScript and at least trusted cookies must be
Explorer 7.0 or 8.0, enabled for browser to work with the federation
Web browser
Mozilla Firefox 3.0, or service.
Safari 3.1
Page 11 of 16

12. Windows XP, Windows Recommended: Windows 7.
Client operating system
Vista, or Windows 7
Federated servers must be members of the domain.
AD DS domain
Domain membership Proxies do not require AD DS membership. Do not
membership
install AD FS on a domain controller.
An AD DS attribute store is created by default at
Attribute store AD DS or SQL Server installation. You can also rely on a custom attribute
store.
Windows Identity Foundation Downloadable WIF is required to externalize user access from
(WIF) component applications via claims.
PowerShell is required to facilitate AD FS
Windows PowerShell PowerShell feature
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
The federation server for contoso.com, the account domain; must be a member of the
SERVER03
contoso.com domain
SERVER06 AD DS domain controller for woodgrovebank.com, the resource domain
The federation server for woodgrovebank.com, the resource domain; must be a
SERVER07
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 RolesDNS ServerDNSSERVER01.
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 12 of 16

13. 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 RolesDNS ServerDNSSERVER01Forward 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 13 of 16

14. Appendix ADFS with External Web Server, Load Balancer & Network Topology:
Appendix ADFS with External Web Server, Load Balancer with Perimeter Network Topology:
Page 14 of 16

15. Appendix ADFS with Office 365, Load Balancer & Network Topology:
Appendix ADFS with Smart Card Auth:
Page 15 of 16

16. Appendix ADFS with UAG / TMG:
Page 16 of 16