One of the Active Directory technologies included in Windows Server 2008 is Active Directory Federation Services (AD FS). This Active Directory technology is designed to extend the authority of your internal network to the outside world.
Use the buttons below to navigate through the lesson
AD FS is designed to provide similar functionality to the forest trust or the explicit trust but, this time, not through the traditional LDAP TCP/IP ports but rather through the common HTTP ports. In fact, AD FS uses port 443 because all AD FS trust communications are secured and encrypted. In this manner, it can rely on AD CS to provide certificates for each server in the AD FS implementation. AD FS can also extend your AD RMS deployment and provide federation services for intellectual property management between partners.
To extend your internal authority, AD FS provides extensions to internal forests and enables organizations to create partnerships without having to open any additional port on their firewalls.
Basically, AD FS relies on each partner’s internal AD DS directory to provide authentication for extranet or perimeter services. When a user attempts to authenticate to an application integrated to AD FS, the AD FS engine will poll the internal directory for authentication data. If the user has access provided through the internal directory, he or she will be granted access to the external application.
The major advantage of this is that each partner organization needs to manage only authentication data in the internal network. The federation services of AD FS do all the rest.
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.
Using AD FS, you can form business-to-business (B2B) partnerships with very little overhead. In these B2B partnerships, organizations fit into two categories:
When organizations that have exposed resources such as Web sites, 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.
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 will authenticate users from anywhere on the Internet. After such users have been authenticated, AD FS examines the users’ attributes in AD DS or in AD LDS directories to identify the users rights to authenticate. To support this identity federation, AD FS relies on four role services;-
- Federation Service
This service is formed by the servers that share a trust policy. The federation server will route 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.
- Claims-Aware Agent
An agent sits on the Web server and initiates queries of security token claims to the federation service. Each claim is used to grant or deny access to a given application. ASP.NET applications that can examine the various claims contained in the user’s AD FS security token are deemed to be claims-aware applications. These applications can rely on the claims to determine whether the user has access to the application. Two examples of claims-aware applications are AD RMS and Microsoft Office SharePoint Server 2007.
- Windows Token-Based Agent
This is an alternate agent that can convert the AD FS security token into an impersonation-level Windows NT access token for applications that rely on Windows authentication mechanisms instead of other Web-based authentication methods.
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 to facilitate the installation and administration processes. AD FS also supports more Web applications than the original release did.
Installing Federation Server
Right click Roles. Click Add Roles. Click Next. Select Active Directory Federation Services. Click Next. Select Federation Service. Click Add Required Role Services. Click Next. Select Create a self signed certificate for SSL encryption. Select Create a self signed certificate for SSL encryption. In a production environment you should have a certificate from a trusted CA. Click Next to continue. Select Create a self signed token signing certificate. Click Next. Select Create a new trust policy make a note of the file path; you will need this for federation relationships. Click Next. Click Next. Review web services and click Next. Click Install. Click Close. Federation Services has been installed.
Install Federation Proxy
In this exercise, you will install the federation service proxies. This involves the installation of the server role plus the required support services for the role.
Right click Roles and click Add Roles. Click Next. Select Active Directory Federation Services. And click Next. Click Next. Select Federation Service Proxy. Click Add Required Role Services. Select AD FS Web Agents and click Next. Select Create a self signed certificate for SSL encryption. Then click Next. Fill in the FQDN of the federation server and click Validate. The validation should fail because you have not yet set up the trust relationship between each computer. This is done by exporting and importing the SSL certificates for each server through IIS. You will perform this task later. Click Next. Select Create A Self-Signed Client Authentication Certificate and click Next. Click Next. Review web services and click Next. Click Install. Installation complete click Close. Federation Proxy Service has been installed.