Active Directory Federation Services
The fundamental purpose of Active Directory Federation Services (ADFS) is to take advantage of user single sign-on (SSO) technologies to authenticate a user to multiple, related Web applications over the life of a single online session. ADFS accomplishes this by securely sharing digital identity and entitlement rights, or "claims," across security and enterprise boundaries. The following are some of the key features of ADFS:
Classic Web SSO
Classic Web SSO scenarios involve cases where the user accessing an application are managed in an extranet directory collocated with the application. ADFS classic Web SSO features offer stronger authentication than conventional means through forms and client-side certificates, and a SSO cookie eliminates the need to re-authenticate for access to other applications in a federated application pool. This functionality, which has been provided by third parties in the past, is now integrated into the server platform with ADFS in Windows Server 2003 R2.
Federated Web SSO
With federation, the user authentication process (presenting and verifying credentials) takes place in a separate environment from the one where the application resides. ADFS enables federation of web applications, enabling customers, partners, and suppliers from different organizations to have a similar, streamlined user experience when they access another organization’s Web-based applications with their own organization’s credentials. Federation also works between business units or geographies within an organization.
Federated Authorization and .NET Integration
ADFS provides a rich model for building security tokens. The ADFS security token has the ability to carry data about users besides their identity, including user authorization/entitlement data.
These data, called authorization claims combined with the ability to transport the data securely in a security token, enables a feature called Federated Authorization. Rather than requiring the application administrator to entirely manage how users get access to specific application capabilities, Federated Authorization enables the delegated administration of users’ access rights to trusted directory administratiors.
At the application, ADFS integration with Windows Server technologies like ASP.NET Roles or Windows Authorization Manager (AzMan) provides end-to-end authentication and authorization management capabilities. Authorization Manager is a simple interface to provide application-level access to functionality through administrative mapping of incoming authorization claims to application roles and related application capabilities. Thus Authorization Manager, in combination with ADFS, help to provide a roles-based access control (RBAC) environment for Windows-based internet-facing .NET Web applications.
Extensible architecture
ADFS provides an extensible architecture that supports various security token types, including Security Assertion Markup Language (SAML) 1.1 and Kerberos (as used in Windows Integrated Authentication). ADFS also offers the ability to perform custom claims transformations — for example, adding custom business logic from a database as a variable in an access request. Organizations can use this extensibility to modify ADFS to coexist with their current security infrastructure and business policies.
Web Services interoperability
ADFS provides a solution that is proven to interoperate with other security products that support the Web Services (WS-*) architecture. ADFS does this by employing the federation specification of WS-*, called WS-Federation. WS-Federation makes it possible for environments that do not use the Windows identity model to federate with Windows environments. Many identity management and security software vendors have demonstrated two-way interoperability with ADFS and plan to deliver complementary solutions to ADFS.
The WS-Federation Passive Requestor Profile (WS-F PRP) is an implementation of WS-Federation, which proposes a standard protocol for how passive requestors (such as Web browsers that support the widely used Hypertext Transfer Protocol (HTTP)) apply the federation framework. Within this protocol, Web service requestors are expected to understand the new security mechanisms and be capable of interacting with Web service providers.
Because ADFS is based on the WS-* architecture, it supports federated communications between any WS–enabled endpoints, currently including communications between servers and passive (HTTP/S) clients, such as Web browsers. In the future, ADFS will employ the WS-* architecture to expand its reach to Simple Object Access Protocol (SOAP)–based smart clients, such as servers, mobile phones, personal digital assistants (PDAs), desktop applications, and SOAP-based Web services.
What Is ADFS: In-Depth Information
Active Directory serves as a primary identity and authentication service in many organizations. Using Windows Server 2003 Active Directory, administrators can create forest trusts between two or more Windows Server 2003 forests to provide access to resources that are located in different business units or organizations. There are, however, scenarios in which forest trusts are not a viable option, for example two distinct organizations doing business across the internet, or applications located in DMZ or perimeter networks. (For more information about forest trusts, see "How Domain and Forest Trusts Work" in the Windows Server 2003 Technical Reference on the Microsoft Web site.
By employing ADFS, organizations can extend their existing Active Directory infrastructures to provide access to resources that are offered by trusted partners across the Internet, which can include external third parties or other departments or subsidiaries in the same organization. ADFS is tightly integrated with Active Directory, retrieving user attributes and authenticating users against Active Directory, as well as using Windows Integration Authentication and security tokens that are created by Active Directory.
ADFS works with both Active Directory and Active Directory Application Mode (ADAM). Specifically, ADFS can work with both enterprise-wide deployments of Active Directory or instances of ADAM. When it interacts with ADAM, ADFS uses Lightweight Directory Access Protocol (LDAP) Bind as a means to authenticate users. When it interacts with Active Directory, ADFS can take advantage of the strong authentication technologies in Active Directory, including Kerberos, X.509 digital certificates, and smart cards.
ADFS supports distributed authentication and authorization over the Internet, and ADFS can be integrated into an organization's or department’s existing access management solution to translate the terms used within an organization into terms that are agreed on as part of a federation. ADFS can create, secure, and validate the claims moving between organizations, and it can also audit and monitor the activity between organizations and departments to ensure secure transactions.
ADFS Requirements
ADFS requires the following hardware and software components.
-
Processor speed: 133 MHz for x86-based computers or 733 MHz for x64-based computers
-
Recommended minimum RAM: 256 MB
-
Free disk space for ADFS setup: 10 MB
Software requirements
ADFS relies on server functionality that is built into the Windows Server 2003 operating system. The Federation Service, Federation Service Proxy, and ADFS Web Service Agent components cannot run on earlier operating systems. This section describes the software requirements for each ADFS component and the overall software configurations that are necessary for ADFS in a network environment.
Note that the Federation Service, Federation Service Proxy, and ADFS Web Service Agent can coexist on the same physical systems in the Release Candidate (RC) version of ADFS.
Federation Service
Computers running the Federation Service must have the following software installed:
-
Windows Server 2003 with SP1
-
Internet Information Server (IIS)
-
ASP.NET
-
Microsoft .NET Framework 2.0 Beta
-
A default Web site that is configured with Transport Layer Security and Secure Sockets Layer (TLS/SSL)
-
A certificate for the Federation Service. Note that because this certificate is used for signing tokens, it must be a digital signing X.509 certificate.
Active Directory and ADAM account store requirements
ADFS requires the presence of user accounts in Active Directory or Active Directory Application Mode (ADAM) for the account Federation Service. Active Directory domain controllers or computers hosting the account stores must have the following software installed:
-
Windows Server 2003 with SP1
Or
-
Windows 2000 with Service Pack 4 (SP4) and critical updates
Note: Local accounts and Windows NT domain accounts cannot be used for user accounts in ADFS account stores.
Federation Service Proxy
Computers running the Federation Service Proxy must have the following software installed:
-
Windows Server 2003 with SP1
-
IIS
-
ASP.NET
-
Microsoft .NET Framework 2.0 Beta
-
A default Web site configured with TLS/SSL
ADFS Web Service Agent
Computers running the ADFS Web Service Agent must have the following software installed:
-
Windows Server 2003 with SP1
-
IIS
-
ASP.NET
-
Microsoft .NET Framework 2.0 Beta
-
A default Web site configured with TLS/SSL
Note that ADFS will not enable 128-bit encryption over SSL connections during setup.
Trusted certification authorities
Because TLS/SSL relies on digital certificates, certification authorities (CAs) such as Microsoft Certificate Services are an important part of ADFS. A CA is a mutually trusted third party that confirms the identity of a certificate requestor (usually a user or computer) and then issues the requestor a certificate. The certificate binds the requestor’s identity to a public key. CAs also renew and revoke certificates as necessary.
For example, if a client is presented with a server’s certificate, the client computer might try to match the server’s CA against the client’s list of trusted CAs. If the issuing CA is trusted, the client verifies that the certificate is authentic and has not been tampered with.
For ADFS to function, TCP/IP network connectivity must exist between the client, the domain controller, and the computers hosting the Federation Service, the Federation Service Proxy, and the Web server.
DNS
The internal Domain Name System (DNS) servers on the intranet forest must be configured to return the canonical name (CNAME) of the internal server that is running the Federation Service for authenticating users that are located in the intranet. For best results, do not use Hosts files with DNS.
Web server
For The RC version of Windows Server 2003 R2, only a machine running IIS 6.0 with ASP.NET is supported as a Web server.
Web browser
Although any current Web browser with JavaScript enabled should work as an ADFS client, only Internet Explorer 6.0, Internet Explorer 5.0 or 5.5 for older operating systems, Safari on Apple Macintosh, and Mozilla are supported for the Release Candidate.
Active Directory Application Mode
Active Directory Application Mode (ADAM) is an independent mode of Active Directory, without infrastructure features, that provides directory services for applications. It provides a data store and services for accessing the data store. It uses standard application programming interfaces (APIs) for accessing the application data. ADAM operates either as a stand-alone data store, or with replication. Its independence enables local control and autonomy of directory services for specific applications. It also facilitates independent, flexible schemas and naming contexts.
ADAM Overview
For organizations that require flexible support for directory-enabled applications, Microsoft has developed ADAM. ADAM is a Lightweight Directory Access Protocol (LDAP) directory service. Administrators can run ADAM on servers running Windows Server 2003.
ADAM can also run on clients running Microsoft Windows XP Professional. To run do so, administrators must install the latest service packs and hot fixes.
ADAM provides data storage and retrieval for directory-enabled applications, without the dependencies that are required for the Active Directory directory service. ADAM provides much of the same functionality as Active Directory, but it does not require the deployment of domains or domain controllers. Administrators can run multiple instances of ADAM concurrently on a single computer, with an independently managed schema for each ADAM instance.
What's new in ADAM
The following features are new to ADAM in Windows Server 2003 R2:
-
Users can be created in the configuration partition so that ADAM users can be ADAM administrators.
-
Active Directory to ADAM Synchronizer tool. This tool synchronizes objects from Active Directory to an ADAM instance. For more information, see Synchronize Data from Active Directory to an ADAM Instance and Adaminstall.
-
ADAM users can bind to an ADAM instance by using digest authentication. This authentication method uses the default credentials of the server applications and eliminates the need to keep a plaintext version of the application's password in memory. Digest bind is supported in LDP.
-
Active Directory Schema Analyzer tool. This tool helps with migrating the Active Directory schema to ADAM.
-
Newer version of LDP tool. The updated tool includes an access control list (ACL) editor.
-
User Password Chaining. ADAM can now chain user password requests in ADAM to the user object in Active Directory so that a password is changed in both directory services. When a user in ADAM who is also a user in Active Directory attempts to change the user password in ADAM, that change is treated the same as a user password change in Active Directory. Both the old and new password must be provided (except for Active Directory administrators, who only need to supply the new password), and the new password must meet any password policies that are set in Active Directory. Active Directory performs all policy checking.
Microsoft directory technologies
With the introduction of ADAM, Microsoft provides a choice of directory services. Both ADAM and Active Directory build on the same core Microsoft directory service technologies, but they address different needs within an organization.
Active Directory. Active Directory provides directory services for both the Windows network operating system (NOS) and for directory-enabled applications. For the NOS, Active Directory stores critical information about the network infrastructure, users and groups, network services, and so on. In this role, Active Directory must adhere to a single schema throughout an entire forest.
ADAM. ADAM provides directory services specifically for directory-enabled applications. ADAM does not require or rely on Active Directory domains or forests. However, in environments where Active Directory exists, ADAM can use Active Directory for the authentication of Windows security principals.
ADAM and Active Directory can run concurrently on the same network. In addition, ADAM can support both domain and workgroup users simultaneously.
Comparing ADAM to Active Directory
The following table illustrates the functional differences and similarities between ADAM and Active Directory.
Feature
|
ADAM
|
Active Directory
|
Supports multiple schemas per server
|
Yes
|
No
|
Supports multiple directory instances per server
|
Yes
|
No
|
Runs on Windows XP Professional
|
Yes
|
No
|
Runs on member servers
|
Yes
|
No
|
Supports X.500 naming for top-level directory partitions
|
Yes
|
No
|
Supports installing, starting, and stopping without a reboot
|
Yes
|
No
|
Group Policy
|
No
|
Yes
|
Global catalog
|
No
|
Yes
|
IntelliMirror® desktop management
|
No
|
Yes
|
Automated software distribution
|
No
|
Yes
|
Domain trusts and forest trusts
|
No
|
Yes
|
Public key infrastructure (PKI)/X.509
|
No
|
Yes
|
Supports DNS service (SRV) resource records
|
No
|
Yes
|
Supports Lightweight Directory Access Protocol (LDAP) application programming interface (API)
|
Yes
|
Yes
|
Supports Active Directory Service Interfaces (ADSI) API
|
Yes
|
Yes
|
Supports Messaging API (MAPI)
|
No
|
Yes
|
Delegated administration
|
Yes
|
Yes
|
Multimaster replication
|
Yes
|
Yes
|
InetOrgPerson
|
Yes
|
Yes
|
LDAP over Secure Sockets Layer (SSL)
|
Yes
|
Yes
|
Attribute-level security
|
Yes
|
Yes
|
LDAP access control list (ACL) support
|
Yes
|
Yes
|
Microsoft Identity Integration Server 2003 compatibility
|
Yes
|
Yes
|
Extensible schema
|
Yes
|
Yes
|
Supports application directory partitions
|
Yes
|
Yes
|
Supports installation of a replica from media
|
Yes
|
Yes
|
Supports 64-bit servers
|
Yes
|
Yes
|
Supports concurrent LDAP binding
|
Yes
|
Yes
| UNIX Identity Management
Windows Server 2003 R2 provides Windows and UNIX integration with the following updated identity management solutions. These solutions help provide uninterrupted user access and efficient management of network resources across operating systems:
-
Server for NIS helps integrate Windows and UNIX-based Network Information Service (NIS) servers by enabling an Active Directory domain controller to act as a master NIS server for one or more NIS domains. Identity Management for UNIX includes an easy-to-use wizard that a Windows domain administrator can use to export NIS domain maps to Active Directory entries. Once this is done, an Active Directory domain controller running Server for NIS becomes the master server for the NIS domain.
-
Password Synchronization helps integrate Windows and UNIX servers by simplifying the process of maintaining secure passwords. With Password Synchronization, users do not need to maintain separate passwords for their Windows and UNIX accounts or remember to change the password in multiple locations. Password Synchronization automatically changes a user password on the UNIX network when the user changes his or her Windows password, and vice versa.
Identity Management for UNIX makes it easy to integrate computers running Windows into an existing UNIX enterprise. Active Directory network administrators can use Server for NIS to manage Network Information Service (NIS) domains, and Password Synchronization will automatically synchronize passwords between Windows and UNIX operating systems.
With minor differences, Identity Management for UNIX is compliant with Internet Engineering Task Force (IETF) standard Request for Comments (RFC) 2307, meaning that a network's password and NIS attributes can be resolved by the Lightweight Directory Access Protocol (LDAP).
Password Synchronization supports Sun Solaris version 8 running on x86-based computers and Scalable Processor Architecture (SPARC)–based computers; Solaris version 9 running on SPARC–based computers; Hewlett Packard HP-UX version 11i; IBM AIX version 5L 5.2; and Red Hat Linux versions 8 and 9 running on x86-based computers and 64-bit AMD-based computers. Server for NIS should work with any operating system or product that uses LDAP.
|
