Active Directory Federation Services 2.0
Design Document V 1.1
Author
|
Swapnil C Nikte
|
Created
|
09/06/2014
|
Last Modified
|
10/06/2014
|
Table of Contents
Introduction:
Active
Directory Federation Services (AD FS) is a server role in Windows Server 2008
that provides Web single-sign-on (SSO) technologies to authenticate a user to
multiple Web applications over the life of a single online session.
Active Directory
Federation Services (AD FS) 2.0 helps simplify access to applications
and other systems with an open and interoperable claims-based model. The
AD FS 2.0 platform provides a fully redesigned Windows-based
Federation Service that supports the WS-Trust, WS-Federation, and Security
Assertion Markup Language (SAML) protocols.
Background: AD
FS 2.0 in a federation services provider role to seamlessly authenticate users to any Web-based services or
applications that reside in a resource partner organization, without the need
for administrators to create or maintain external trusts or forest trusts
between the networks of both organizations and without the need for the users
to log on a second time. The process of authenticating to one network while
accessing resources in another network—without the burden of repeated logon
actions by users—is known as single sign-on (SSO).
·
Existing
infrastructure for AD, DNS, Network, and SQL will be utilized.
·
Existing
hardware devise for NLB on corporate network and DMZ network will be utilized
configured in high availability to avoid single point of failure.
·
NLB
has been configured appropriately to cluster each of the federation servers in
the farm
·
Existing
SQL Infrastructure is configured appropriately
in high availability (e.g.
Failover cluster).
·
SQL
– Server is configured appropriately to
create AD FS configuration database.
·
SQL
– Server is configured for high-availability
features such as fail-over clustering or mirroring
·
All
Hardware, Software and Licenses required are ready
·
Service
Account with appropriate permissions is created.
·
Network
Infrastructure between Australia and
EMEA should allow huge ADFS service request from internal EMEA users to avoid any performance related
issue
·
Network
Infrastructure in Australia should allow huge ADFS service request from
external users worldwide to avoid any performance related issue.
Objective:
Provide users with seamless access to
Web-based resources in any federation partner organization on the Internet
without requiring employees or customers to log on more than once.
Business requirements:
o SAML artifact resolution and
SAML/WS-Federation token replay detection.
o High Availability of AD FS infrastructure.
o
Easily Scalable
o
Expected Business benefits
ADFS
|
Active Directory Federation Services (AD FS) 2.0
|
DNS
|
Domain Naming Services
|
AD
|
Active Directory
|
NLB
|
Network Load balancing
|
SAML
|
Security Assertion Markup Language
|
AD FS configuration database
|
A database used to store all configuration data that
represents a single AD FS 2.0 instance or Federation Service. This
configuration data can be stored in either a SQL Server database or using the
Windows Internal Database feature included with Windows Server 2008 and
Windows Server 2008 R2. You can create the AD FS configuration database for
SQL Server using the Fsconfig.exe command-line tool and for Windows Internal
Database using the AD FS 2.0 Federation Server Configuration Wizard.
|
Federation server
|
A computer running Windows Server 2008 or Windows
Server 2008 R2 that has been configured using the AD FS 2.0 Federation Server
Configuration Wizard to act in the federation server role. A federation
server issues tokens and serves as part of a Federation Service.
|
Architecture Diagram:
Architecture Overview:
Two Account partner ADFS servers are configured in farm
with SQL as configuration database with NLB for Service redundancy and load balancing. Two Federation
server proxies in NLB are used to proxy client requests to the federation
server farm.
All of the federation servers in the farm are configured
to use one cluster Domain Name System (DNS) name (which represents the
Federation Service name-
adfs.<name>.com.au) and one cluster
IP address as part of the Network Load Balancing (NLB) cluster configuration.
This helps the NLB host allocate client requests to the individual federation
servers.
The second NLB
host in DMZ configured with an NLB cluster that uses an Internet-accessible
cluster IP address, and it must use the same cluster DNS name setting as the
previous NLB cluster that you configured on the corporate network (adfs.<Name>.com.au).
The federation server proxies should also be configured with
Internet-accessible IP addresses.
All Users connecting from internet will get connected
from AD FS Proxy servers.
Following is the
process flow of Internal User (client) attempts to access the ADFS-enabled
external resource.
- Client attempts to access the ADFS-enabled external
resource;
- Client is redirected to the resource’s applicable
federation service;
- Client is redirected to its organization’s internal
federation service, (assuming the resource’s federation service is
configured as trusted partner);
- The ADFS server authenticates the client to active
directory;
- The ADFS server provides the client with an
authorization cookie containing the signed security token and set of
claims for the resource partner;
- The client connects to the resource partner
federation service where the token and claims are verified. If
appropriate, the resource partner provides the client with a new security
token; and
- The client presents the new authorization cookie
with included security token to the resource for access.
Following is the
process flow of Internal User (client) attempts
1.
Client attempts to
access the AD FS-enabled internal or external resource;
2.
Client is redirected
to the resource’s applicable federation service;
3.
Client is redirected
to its organization’s internal federation service, (assuming the resource’s
federation service is configured as trusted partner);
4.
The AD FS proxy server
presents the client with a customizable sign-on page;
5.
The AD FS proxy
presents the end-user credentials to the AD FS server for authentication;
6.
The AD FS server
authenticates the client to active directory;
7.
The AD FS server
provides the client, (via the AD FS proxy server) with an authorization cookie
containing the signed security token and set of claims for the resource
partner;
8.
The client connects to
the resource partner federation service where the token and claims are
verified. If appropriate, the resource partner provides the client with a new
security token; and
9.
The client presents
the new authorization cookie with included security token to the resource for
access.
This AD FS infrastructure can be span over the EMEA
region by adding more AD FS server in same farm.
Note:
·
New federation server must point to the
same SQL Server instance that is used by other federation servers in the farm
so that the new server can participate in the farm.
·
As EMEA ADFS servers need to use same SQL
database in Australia over the WAN, good network connectivity is required to
facilitates SQL queries over the WAN.
·
For diverting External EMEA users to EMEA
datacenter and Australian users to Australia datacenter, GEO aware network load
balancer is needed. Currently, such device / capability does not exist.
·
Local DNS (standalone) server is needed to
divert internal EMEA users to EMEA AD FS farm.
·
Network Infrastructure in Australia should
allow huge ADFS service request during failed over to avoid any performance
related issue.
For more reference please visit following link:
Site Redundancy:
Using SQL server, we
can setup a high-availability solution across multiple data centers. SQL server
would be mirrored from your datacenter to a different datacenter. A network
load balancer directs traffic between the two sites.
For ADFS 2.0 High
Availability and High Resiliency please visit following link:
The act of creating
two or more federation servers in the same network, configuring each of them to
use the same Federation Service, and adding the public key of each server's
token-signing certificates to the AD FS 2.0 Management snap-in creates a
federation server farm. As we want to provide fault tolerance, load-balancing,
and scalability to organization's
Federation Service Creating two server in federation server farm in Active
Directory Federation Services (AD FS) 2.0.
The act of creating
two or more federation server proxies in the same perimeter network and
configuring each of them to protect the same AD FS 2.0 Federation Service
creates a federation server proxy farm. As we want to provide fault tolerance,
load-balancing, and scalability for proxy deployment installing two additional
federation server proxies.
Before federation servers can be grouped as a
farm, they must first be clustered so that requests that arrive at a single
fully qualified domain name (FQDN) are routed to the various federation servers
in the server farm. Network Load Balancing (NLB) inside the corporate network
And DMZ Network has been placed to fulfill above requirement.
The AD FS configuration database stores all the
configuration data. It contains information that a Federation Service requires
to identify partners, certificates, attribute stores, claims, etc. You can
store this configuration data in either a Microsoft SQL Server 2005 or newer
database or the Windows Internal Database (WID) feature that is included with
Windows Server 2008, Windows Server 2008 R2 and Windows Server 2012.
WID
Advantages
|
WID
Disadvantages
|
Very easy to setup and
implement
|
Supports five
federation servers in a farm
|
Load balancing and
fault tolerance is possible if setup as a farm.
|
SAML artifact
resolution and SAML/WS-Federation token replay detection feature is not
available
|
Supports multiple
Federation Servers in a farm (limits to 5 federation server in a farm)
|
It is not supported if
there is more than 100 claim trust providers trust or more than 100 relying
party trusts.
|
SQL Advantages
|
SQL Disadvantages
|
Supports multiple
federation servers (not subject to the limitation of WID)
|
Additional setup
complexities. Require PowerShell to install it
|
Load balancing and
fault tolerance
|
SQL cluster introduces
another potential point of failure
|
Easily Scalable
|
SQL server must be
performing well to service requests
|
SAML artifact
resolution and SAML/WS-Federation token replay detection supported
|
|
As one of the business requirement to support SAML artifact resolution
and SAML/WS-Federation token replay detection and need to support adding
multiple (more than 5) servers in farm to accommodate 70000+ users in future.
SQL database option is selected for ADFS deployment as it is Easily Scalable, SAML
artifact resolution and SAML/WS-Federation token replay detection supported and
fault tolerance can be achieve using SQL cluster.
4 Machines with following configuration ( 2
For ADFS Proxy and 2 For ADFS account partner Farm servers)
·
CPU :Quad-core, 2 GHz,
·
RAM: 4GB,
·
Disk:50 GB HDD
·
SQL Server 2008
Certificate type
|
Description
|
What you need to know
before deploying
|
Service communication certificate
|
This is a standard Secure
Sockets Layer (SSL) certificate that is used for securing communications
between federation servers, clients, and federation server proxy computers.
|
Public (third-party)
certification authority (CA), for example, VeriSign.
Note: Make sure to mark the certificates private key as ‘Exportable’. This
will allow you to export the certificate and private key to the other servers
in the ADFS Farm and Proxy.
|
Token-signing
certificate
|
This is a standard X509
certificate that is used for securely signing all tokens that the federation
server issues.
|
The token-signing
certificate must contain a private key, and it should chain to a trusted root
in the Federation Service. By default, AD FS 2.0 creates a
self-signed certificate. However, you can change this later to a CA-issued
certificate by using the AD FS 2.0 Management snap-in, depending on
the needs of your organization.
|
Token-decryption
certificate
|
This is a standard SSL
certificate that is used to decrypt any incoming tokens that are encrypted by
a partner federation server. It is also published in federation metadata.
|
By default,
AD FS 2.0 creates a self-signed certificate. However, you can
change this later to a CA-issued certificate by using the AD FS 2.0
Management snap-in, depending on the needs of your organization.
|
Federation server
proxy certificates:
Server authentication
certificate
|
This is a standard Secure
Sockets Layer (SSL) certificate that is used for securing communications
between a federation server proxy and Internet client computers.
|
Public (third-party)
certification authority (CA), for example, VeriSign.
|
·
Internal and external users will need to access the
application over SSL (typically port 443)
·
The AD FS 2.0 Proxy Server will need to access the
internal AD FS server over SSL (default port 443)
·
Internal users will need to access the internal
Federation Service on its SSL port (TCP/443 by default)
·
External users will need to access the Federation Service
Proxy on its SSL port (TCP/443 by default)
·
Static IP address for 2 ADFS server in corporate network
and 2 ADFS proxy servers in DMZ
·
Two IP address for Virtual IP address of each NLB cluster
in corporate and DMZ network
·
FQDN name for Both
ADFS cluster in corporate network & DMZ
·
Load balancing need to be configured between two AD FS
Account servers in corporate network.
·
Load balancing need to be configured between two AD FS
Proxy servers in DMZ network.
Federation Servers: Domain Name System (DNS) in the corporate
network of the account partner must be configured for a new host (A) resource
record that will resolve the fully qualified domain name (FQDN) host name of
the federation server to the IP address of the federation server cluster
(NLB).
|
Need to create A record in Corp DNS for cluster Name and
IP e.g.
<Adfs.Name>.com.au
|
Federation Servers
Proxy :In Account
partner federation server proxy create an entry in its local hosts file to
resolve <Adfs.name.com.au> to the IP address of the actual cluster DNS name for the federation server
farm that is connected to the corporate network.
|
e.g.
<cluster IP of NLB in corporate Network> <Adfs.name>.com.au
|
Federation Servers
Proxy: DNS in the perimeter
network (DNZ)of the account partner must be configured so that the FQDN of
the federation server to the IP address of the account federation server
proxy on the perimeter network.
|
e.g.
Need to create A record in DMZ DNS for <Adfs.name>.com.au, pointing towards
cluster IP of federation server proxy.
|
·
Need a dedicated user/service account in the
Active Directory forest that is located in the identity provider
organization.
1. Create a dedicated
user/service account in the Active Directory forest that is located in the
identity provider organization. This account is necessary for the Kerberos
authentication protocol to work in a farm scenario and to allow pass-through
authentication on each of the federation servers. Use this account only for the
purposes of the federation server farm.
2. Edit the user account
properties, and select the Password never expires check box. This
action ensures that this service account's function is not interrupted as a
result of domain password change requirements.
3. Because the
application pool identity for the AD FS 2.0 AppPool is running as a
domain user/service account, you must configure the Service Principal Name
(SPN) for that account in the domain with the Setspn.exe command-line tool.
Setspn.exe is installed by default on computers running Windows
Server 2008. Run the following command on a computer that is joined to the
same domain where the user/service account resides:
setspn -a host/<server name> <service
account>
Changing the AD FS 2.0 Service Account Password for a SQL Server-Based
Federation Server Farm
·
Domain admin and Local Admin rights on servers for
installation and configuration of ADFS 2.0
When you choose the option
to create a New federation server farm
using the AD FS 2.0 Federation Server Configuration Wizard, the wizard will
attempt to create a container object (for sharing certificates) in Active
Directory. Therefore, it is important that you first log on to the computer,
where you are setting up the federation server role, with an account that has
sufficient permissions in Active Directory to create this container object.
We recommend the
following best practices for deploying a federation server in a production
environment:
If you will be
deploying multiple federation servers at the same time or you know that you
will be adding more servers to the farm over time, consider creating a server
image of an existing federation server in the farm and then installing from
that image when you need to create additional federation servers quickly.
Note
|
If you do decide to use the server image method for
deploying additional federation servers, you do not have to complete the
tasks in Checklist:
Setting Up a Federation Server every time that
you want to add a new server to the farm.
|
Use NLB or some
other form of clustering to allocate a single IP address for many federation
server computers.
Reserve a static
IP address for each federation server in the farm and, depending on your Domain
Name System (DNS) configuration, insert an exclusion for each IP address in
Dynamic Host Configuration Protocol (DHCP). Microsoft NLB technology requires
that each server that participates in the NLB cluster be assigned a static IP
address.
If the AD FS
configuration database will be stored in a SQL database, avoid editing the SQL
database from multiple federation servers at the same time.
Configuring
federation servers for a farm
The following
table describes the tasks that must be completed so that each federation server
can participate in a farmed environment.
Task
|
Description
|
If you are using SQL Server to store the AD FS configuration
database
|
A federation server farm consists of two or more
federation servers that share the same AD FS configuration database and
token-signing certificates. The configuration database can be stored in
either Windows Internal Database or in a SQL Server database. If you plan to
store the configuration database in a SQL database, make sure that the
configuration database is accessible so that it can be accessed by all new
federation servers that participate in the farm.
Note
|
For farm scenarios, it is important
that the configuration database be located on a computer that does not also
participate as a federation server in that farm. Microsoft NLB does not
allow any of the computers that participate in a farm to communicate with
one another.
|
Note
|
Ensure that the identity of the AD
FS 2.0 AppPool in Internet Information Services (IIS)) on every federation
server that participates in the farm has Read access to the configuration
database.
|
|
Obtain and share certificates
|
You can obtain a single server authentication certificate
from a public certification authority (CA)—for example, VeriSign. You can
then configure the certificate so that all federation servers share the same
private key portion of the certificate. For more information about how to
share the same certificate, see Checklist:
Setting Up a Federation Server.
Note
|
The AD FS 2.0 Management snap-in
refers to server authentication certificates for federation servers as
service communication certificates.
|
|
Point to the same SQL Server instance
|
If the AD FS configuration database will be stored in a
SQL database, the new federation server must point to the same SQL Server
instance that is used by other federation servers in the farm so that the new
server can participate in the farm.
|
