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.
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.
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.
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. |
| 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. |
| 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:
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.
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.
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.
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.
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 deployment.
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.
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. |
| 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.
Log on to SERVER01 with the domain Administrator account.
Launch Server Manager from the Administrative Tools program group.
Expand Roles\DNS Server\DNS\SERVER01.
Right-click SERVER01 in the tree pane and select Properties.
On the Forwarders tab, click Edit.
Type the IP address of SERVER06 and click OK twice.
Repeat the procedure in reverse on SERVER06; that is, add the SERVER01 IP address as a forwarder for SERVER06.
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.
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).
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.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.
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.
Accept the License Agreement and click Next.
On the Server Role page, select Federation Server. Click Next.
The
installation warns you that it will check for and install any missing
prerequisite software. Click Next to begin the installation.
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.
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
