Active Directory Federation Services (ADFS)

Active Directory Federation Services (ADFS) is based on the emerging, industry-supported Web Services Architecture, which is defined in WS-* specifications. ADFS helps you use single sign-on (SS0) to authenticate users to multiple, related Web applications over the life of a single online session. ADFS accomplishes this by securely sharing digital identity and entitlement rights across security and enterprise boundaries.

  • For help with specific tasks, see ADFS How To.

  • For general background information, see ADFS Concepts.

  • For problem-solving instructions, see ADFS troubleshooting.


ADFS How To

  • Deploy ADFS

  • Complete the Add Resource Partner Wizard

  • Complete the Add Account Partner Wizard

  • Complete the Add Account Store Wizard

  • Complete the Add Applications Wizard

  • Configure the Account Store Priority

  • Manage ADFS


Deploy ADFS

For information about how to deploy Active Directory Federation Services (ADFS), look for ADFS planning and deployment content on the Windows Server 2003 R2 Roadmap page (http://go.microsoft.com/fwlink/?LinkId=45560) of the Microsoft Windows Server 2003 TechCenter Web site.


Complete the Add Resource Partner Wizard

You can use the Add Resource Partner Wizard to add a new resource partner manually or by importing a policy file. Use this wizard to add a resource partner that will provide a Web application to users who have accounts in your account store (Active Directory or Active Directory Application Mode (ADAM)).

Add a resource partner manually

You can use the following procedure to add a resource partner manually.

To add a resource partner manually

  1. Click Start, point to Administrative Tools, and then click Active Directory Federation Services.

  2. In the console tree, double-click Federation Service, Trust Policy, and Partner Organizations.

  3. In the console tree, right-click Resource Partners, point to New, and then click Resource Partner.

  4. On the Welcome to the Add Resource Partner Wizard page, click Next.

  5. On the Import Policy File page, ensure that No is selected, and then click Next.

  6. On the Resource Partner Details page, do the following, and then click Next:

    • In Display name, type the name of the resource partner.

    • In Federation Service URI, type the Uniform Resource Identifier (URI) for the resource partner.

    • In Federation Service endpoint URL, type the Uniform Resource Locator (URL) of the Federation Service.

  7. On the Federation Scenario page, do one of the following, and then click Next:

    • If you are establishing a federated trust with another organization or you do not want to use an existing forest trust, click Federated Web SSO.

    • If you are establishing a federated trust within the same organization when both sides already share a forest trust, click Federated Web SSO with Forest Trust.

  8. On the Resource Partner Identity Claims page, select one or more identity claims to share with the resource partner, and then click Next:

    • If the resource partner requires user principal name (UPN) claims to make authorization decisions, select the UPN Claim check box.

    Note

    If you selected the Federated Web SSO with Forest Trust scenario, the UPN Claim option is selected and not configurable. This is because UPN claims are required for this scenario.

    • If the resource partner requires e-mail claims to make authorization decisions, select the E-mail Claim check box.

    • If the resource partner requires common name claims to make authorization decisions, select the Common Name Claim check box.

  9. If you selected UPN Claim as an identity claim, on the Select UPN Suffix page, do one of the following, and then click Next:

    • To pass all UPN suffixes through without replacing them, click Pass all UPN suffixes through unchanged.

    • To replace all UPN suffixes with a different suffix, click Replace all UPN suffixes with the following, and then type the suffix that you want to use to replace all UPN suffixes.

  10. If you selected E-mail Claim as an identity claim, on the Select E-mail Suffix page, do one of the following, and then click Next:

    • To pass all e-mail suffixes without replacing them, click Pass all E-mail suffixes through unchanged.

    • To replace all e-mail suffixes with a different suffix, click Replace all E-mail suffixes with, and then type the suffix that you want to use to replace all e-mail suffixes.

    Note

    Common name claims require no additional information.

  11. On the Enable this Resource Partner page, if you do not want to enable the resource partner now, clear the Enable this resource partner check box, and then click Next.

  12. To add the new resource partner and close the wizard, click Finish.

Add a resource partner by importing a policy file

You can use the following procedure to add a resource partner by importing a policy file.

To add a resource partner by importing a policy file

  1. Click Start, point to Administrative Tools, and then click Active Directory Federation Services.

  2. In the console tree, double-click Federation Service, Trust Policy, and Partner Organizations.

  3. Right-click Resource Partners, point to New, and then click Resource Partner.

  4. On the Welcome to the Add Resource Partner Wizard page, click Next.

  5. On the Import Policy File page, do the following, and then click Next:

    • Click Yes.

    • In Partner interoperability policy file, browse to or type the location of the resource partner policy file.

  6. On the Federation Scenario page, do one of the following, and then click Next:

    • If you are establishing a federated trust with another organization or you do not want to use an existing forest trust, click Federated Web SSO.

    • If you are establishing a federated trust within the same organization when both sides already share a forest trust, click Federated Web SSO with Forest Trust.

  7. On the Resource Partner Identity Claims page, select one or more identity claims that the account partner will provide to the resource partner, and then click Next:

    • If the resource partner requires UPN claims to make authorization decisions, select the UPN Claim check box.

    Note

    If you selected the Federated Web SSO with Forest Trust scenario, the UPN Claim option is selected and not configurable. This is because UPN claims are required for this scenario.

    • If the resource partner requires e-mail claims to make authorization decisions, select the E-mail Claim check box.

    • If the resource partner requires common name claims to make authorization decisions, select the Common Name Claim check box.

  8. If you selected UPN Claim as an identity claim, on the Select UPN Suffix page, select one of the following, and then click Next.

    • To pass all UPN suffixes through without replacing them, click Pass all UPN suffixes through unchanged.

    • To replace all UPN suffixes with a different suffix, click Replace all UPN domain suffixes with the following, type the suffix that you want to use to replace all UPN suffixes, and then click Add.

  9. If you selected E-mail Claim as an identity claim, on the Select E-mail Suffix page, do one of the following, and then click Next:

    • To pass all e-mail suffixes without replacing them, click Pass all e-mail suffixes through unchanged.

    • To replace all UPN suffixes with a different suffix, click Replace all E-mail suffixes with, and then type the suffix that you want to use to replace all e-mail suffixes.

    Note

    Common name claims require no additional information.

  10. On the Enable this Resource Partner page, if you do not want to enable the resource partner now, clear the Enable this resource partner check box, and then click Next.

  11. To add the new resource partner and close the wizard, click Finish.

Related Information

  • Partner organizations

  • Federation scenarios

  • Federation trusts

  • Federation Service

  • Claims


Complete the Add Account Partner Wizard

You can use the Add Account Partner Wizard to add a new account partner manually or by importing a policy file. This will allow user accounts in the account partner to access Web applications that are protected by this Federation Service.

Add an account partner manually

You can use the following procedure to add an account partner manually.

To add an account partner manually

  1. Click Start, point to Administrative Tools, and then click Active Directory Federation Services.

  2. In the console tree, double-click Federation Service, Trust Policy, and Partner Organizations.

  3. Right-click Account Partners, point to New, and then click Account Partner.

  4. On the Welcome to the Add Account Partner Wizard page, click Next.

  5. On the Import Policy File page, click No, and then click Next.

  6. On the Account Partner Details page, do the following, and then click Next

    • In Display name, type the display name of the account partner.

    • In Federation Service URI, type the Uniform Resource Identifier (URI) of the Federation Service.

    • In Federation Service endpoint URL, type the Uniform Resource Locator (URL) of the Federation Service.

  7. On the Account Partner Verification Certificate page, type the path to the verification certificate, or browse to it, and then click Next.

  8. On the Federation Scenario page, do one of the following, and then click Next:

    • If you are establishing a federated trust with another organization or you do not want to use an existing forest trust, click Federated Web SSO, and then go to step 10.

    • If you are establishing a federated trust within the same organization when both sides already share a forest trust, click Federated Web SSO with Forest Trust.

  9. On the Federated Web SSO with Forest Trust page, do one of the following, and then click Next:

    • To accept users in all domains that are trusted by the account partner, click All Active Directory domains and forests. Any user that can authenticate to the account partner will be accepted.

    • To accept user accounts that are located in some of the domains that are trusted by the account partner, click The following Active Directory domains and forests. Then, in New, trusted Active Directory domain or forest, type the name of a domain or forest, and then click Add. Only users from the specified domains will be accepted.

  10. On the Account Partner Identity Claims page, select one or more identity claims to share with the resource partner, and then click Next:

    • If the resource partner requires user principal name (UPN) claims to make authorization decisions, select the UPN Claim check box.

    Important

    When UPN claims or e-mail claims are used to make authorization decisions, it is essential that each account partner use a unique UPN suffix or e-mail suffix. If two account partners use the same UPN suffix or e-mail suffix, it may not be possible to uniquely identify users. This condition might allow a user from one account partner to receive the permissions that are intended for a user in another account partner. This condition might also introduce a significant security weakness because an administrator could intentionally create user accounts to impersonate users from one of your other account partners.

    Note

    If you selected the Federated Web SSO with Forest Trust scenario, the UPN Claim option is selected and not configurable. This is because UPN claims are required for this scenario.

    • If the resource partner requires e-mail claims to make authorization decisions, select the E-mail Claim check box.

    • If the resource partner requires common name claims to make authorization decisions, select the Common Name Claim check box.

  11. If you selected UPN Claim as an identity claim, on the Accepted UPN Suffixes page, click All UPN suffixes (this option is available only if you selected the Federation Web SSO with Forest Trust option), or type the accepted suffix, click Add, and then click Next.

  12. If you selected E-mail Claim as an identity claim, on the Accepted E-mail Suffixes page, click All E-mail suffixes (this option is available only if you selected the Federation Web SSO with Forest Trust option), or type the accepted suffix, click Add, and then click Next.

    Note

    Common name claims require no additional information.

  13. On the Enable this Account Partner page, if you do not want to enable the account partner now, clear the Enable this account partner check box, and then click Next.

  14. To add the new account partner and close the wizard, click Finish.

Add an account partner by importing a policy file

You can use the following procedure to add an account partner by importing a policy file.

To add an account partner by importing a policy file

  1. Click Start, point to Administrative Tools, and then click Active Directory Federation Services.

  2. In the console tree, double-click Federation Service, Trust Policy, and Partner Organizations.

  3. Right-click Account Partners, point to New, and then click Account Partner.

  4. On the Welcome to the Add Account Partner Wizard page, click Next.

  5. On the Import Policy File page, do the following, and then click Next:

    • Click Yes.

    • In Partner interoperability policy file, browse to or type the location of the account partner policy file.

  6. On the Federation Scenario page, do one of the following, and then click Next:

    • If you are establishing a federated trust with another organization or you do not want to use an existing forest trust, click Federated Web SSO, and then go to step 8.

    • If you are establishing a federated trust within the same organization when both sides already share a forest trust, click Federated Web SSO with Forest Trust.

  7. On the Federation Web SSO with Forest Trust page, do one of the following, and then click Next:

    • To accept users in all domains that are trusted by the account partner, click All Active Directory domains and forests. Any user that can authenticate to the account partner will be accepted.

    • To accept user accounts that are located in some of the domains that are trusted by the account partner, click The following Active Directory domains and forests. Then, in New, trusted Active Directory domain or forest, type the name of the domain or forest, and then click Add. Only users from the specified domains will be accepted.

  8. On the Account Partner Identity Claims page, select one or more identity claims that this partner will provide, and then click Next:

    • If the resource partner requires UPN claims to make authorization decisions, select the UPN Claim check box.

    Important

    When UPN claims or e-mail claims are used to make authorization decisions, it is essential that each account partner use a unique UPN suffix or e-mail suffix. If two account partners use the same UPN suffix or e-mail suffix, it may not be possible to uniquely identify users. This condition might allow a user from one account partner to receive the permissions that are intended for a user in another account partner. This condition might also introduce a significant security weakness because an administrator could intentionally create user accounts to impersonate users from one of your other account partners.

    Note

    If you selected the Federated Web SSO with Forest Trust scenario, the UPN Claim option is selected and not configurable. This is because UPN claims are required for this scenario.

    • If the resource partner requires e-mail claims to make authorization decisions, select the E-mail Claim check box.

    • If the resource partner requires common name claims to make authorization decisions, select the Common Name Claim check box.

  9. If you selected UPN Claim as an identity claim, on the Accepted UPN Suffixes page, click All UPN suffixes (this option is available only if you selected the Federation Web SSO with Forest Trust option), or type the accepted suffixes, click Add, and then click Next.

  10. If you selected E-mail Claim as an identity claim, on the Accepted E-mail Suffixes page, click All E-mail suffixes (this option is available only if you selected the Federation Web SSO with Forest Trust option), or type the accepted suffix, click Add, and then click Next.

    Note

    Common name claims require no additional information.

  11. On the Enable this Account Partner page, if you do not want to enable the account partner now, clear the Enable this account partner check box, and then click Next.

  12. To add the new account partner and close the wizard, click Finish.

Rename an imported account partner

You can use the following procedure to rename an imported account partner.

To rename an imported account partner

  1. Click Start, point to Administrative Tools, and then click Active Directory Federation Services.

  2. In the console tree, double-click Federation Service, Trust Policy, Partner Organizations, and Account Partners.

  3. Right-click the account partner, and then click Rename.

  4. Type a new name for account partner.

Related Information

  • Partner organizations

  • Federation scenarios

  • Federation trusts

  • Federation Service

  • Claims


Complete the Add Account Store Wizard

You can use the Add Account Store Wizard to add new Active Directory account stores and Active Directory Application Mode (ADAM) account stores to a Federation Service trust policy. New account stores are added to the end of the account store lists by default. Account stores are used to authenticate users and provide user identity information to Active Directory Federation Services.

Create an Active Directory account store

You can use the following procedure to create an Active Directory account store.

To create an Active Directory account store

  1. Click Start, point to Administrative Tools, and then click Active Directory Federation Services.

  2. In the console tree, double-click Federation Service, Trust Policy, and My Organization.

  3. Right-click Account Stores, point to New, and then click Account Store.

  4. On the Welcome to the Add Account Store Wizard page, click Next.

  5. On the Account Store Type page, click Active Directory, and then click Next.

    Note

    You can have only one Active Directory store that is associated with a Federation Service. If the Active Directory option is not available, it is because an Active Directory store has already been created for this Federation Service.

  6. If you do not want to enable this account store now, on the Enable this Account Store page, clear the Enable this account store check box, and then click Next.

  7. To add the new account store and close the wizard, click Finish.

Create an ADAM account store

You can use the following procedure to create an ADAM account store.

To create an ADAM account store

  1. Click Start, point to Administrative Tools, and then click Active Directory Federation Services.

  2. In the console tree, double-click Federation Service, Trust Policy, and My Organization.

  3. Right-click Account Stores, point to New, and then click Account Store.

  4. On the Welcome to the Add Account Store Wizard page, click Next.

  5. On the Account Store Type page, click Active Directory Application Mode (ADAM), and then click Next.

  6. On the ADAM Store Details page, do the following, and then click Next:

    • In Account store display name, type the friendly name of the account store.

    • In Account store URI, type the Uniform Resource Identifier (URI) for the ADAM account store.

  7. On the ADAM Server Settings page, do the following, and then click Next:

    • In ADAM server name or IP address, type the name or Internet Protocol (IP) address of the ADAM server.

    • In Port number, type the TCP/IP port number for the account service.

    • In LDAP search base distinguished name, type the distinguished name, for example, DC=adatum,DC=com.

    • In User name LDAP attribute, type the name of the user name attribute, for example, userPrincipalName.

  8. On the Identity Claims page , select one or more identity claims that will be provided by the account store, and then click Next:

    • If the account store provides UPN identity claims, select the User Principal Name (UPN) check box, and then type the Lightweight Directory Access Protocol (LDAP) attribute name.

    • If the account store provides e-mail identity claims, select the E-mail check box, and then type the LDAP attribute name.

    • If the account store provides common name identity claims, select the Common name check box, and then type the LDAP attribute name.

  9. If you do not want to enable this account store now, on the Enable this Account Store page, clear the Enable this account store check box, and then click Next.

  10. To add the new account store and close the wizard, click Finish.

Related Information

  • Account stores

  • Federation Service

  • Claims


Complete the Add Applications Wizard

You can use the Add Application Wizard to add either a claims-aware application or a Windows NT token–based application to the Federation Service trust policy.

Add a claims-aware application

You can use the following procedure to add a claims-aware application to the Federation Service trust policy.

To add a claims-aware application

  1. Click Start, point to Administrative Tools, and then click Active Directory Federation Services.

  2. In the console tree, double-click Federation Service, Trust Policy, and My Organization.

  3. Right-click Applications, point to New, and then click Application.

  4. On the Welcome to the Add Application Wizard page, click Next.

  5. On the Application Type page, click Claims-aware application, and then click Next.

  6. On the Application Details page, do the following, and then click Next:

    • In Application display name, type the name of the application.

    • In Application URL, type the Uniform Resource Locator (URL) of the application.

    Important

    This URL must match the return URL that is configured on the ADFS Web Agent for this application.

  7. On the Accepted Identity Claims page, select each identity claim type that the application will use to make authorization decisions, and then click Next:

    • If the application requires user principal name (UPN) identity claims to make authorization decisions, select the User principal name (UPN) check box.

    • If the application requires e-mail identity claims to make authorization decisions, select the E-mail check box.

    • If the application requires common name identity claims to make authorization decisions, select the Common name check box.

  8. If you do not want to enable the claims-aware application now, on the Enable this Application page, clear the Enable this application check box, and then click Next.

  9. To add the new claims-aware application and close the wizard, click Finish.

Add a Windows NT token–based application

You can use the following procedure to add a Windows NT token–based application to the Federation Service trust policy.

To add a Windows NT token–based application

  1. Click Start, point to Administrative Tools, and then click Active Directory Federation Services.

  2. In the console tree, double-click Federation Service, Trust Policy, and My Organization.

  3. Right-click Applications, point to New, and then click Application.

  4. On the Welcome to the Add Application Wizard page, click Next.

  5. On the Application Type page, click Windows NT token–based application, and then click Next.

  6. On the Application Details page, do the following, and then click Next:

    • In Application display name, type the name of the application.

    • In Application URL, type the Uniform Resource Locator (URL) of the application.

    Important

    This URL must match the return URL that is configured on the ADFS Web Agent for this application.

  7. On the Accepted Identity Claim page, select each identity claim type that the application will use to make authorization decisions, and then click Next:

    • If the application requires user principal name (UPN) identity claims to make authorization decisions, click User principal name (UPN).

    • If the application requires e-mail identity claims to make authorization decisions, click E-mail.

  8. If you do not want to enable the Windows NT token–based application now, on the Enable this Application page, clear the Enable this application check box, and then click Next.

  9. To add the new Windows NT token–based application and close the wizard, click Finish.

Related Information

  • Claims-aware applications

  • Windows NT token-based applications

  • Federation Service

  • Claims


Configure the Account Store Priority

When you add more than one account store, account store priority determines the order in which account stores will be used by Active Directory Federation Services (ADFS). ADFS will attempt to authenticate users beginning with the first account store. Only if authentication fails for a user will ADFS attempt to authenticate the user with the next account store in the list. ADFS will attempt to authenticate a user until the user is successfully authenticated or until all account stores have been attempted. ADFS will stop attempting additional account stores as soon as one account store successfully authenticates a user.

User identity attributes that are provided by account stores are not cumulative. ADFS is aware only of user identity attributes that are provided by the account store that is used to authenticate the user.

Configure the account store priority

You can use the following procedure to configure the account store priority.

To configure the account store priority

  1. Click Start, point to Administrative Tools, and then click Active Directory Federation Services.

  2. In the console tree, double-click Federation Service, Trust Policy, and My Organization.

  3. Right-click Account Stores, and then click Store Priority.

  4. In the Account Store Prioritization dialog box, select an account store, use the Up and Down buttons to move the account store in the priority list, and then click OK.

See Also

  • Account stores
  • Federation Service


Manage ADFS

Manage ADFS

For information about how to manage Active Directory Federation Services (ADFS) after you deploy it, look for ADFS operations content on the Windows Server 2003 R2 page (http://go.microsoft.com/fwlink/?LinkId=45560) of the Microsoft Windows Server 2003 TechCenter Web site.


ADFS Concepts

ADFS Concepts

  • ADFS Overview

  • Understanding ADFS Components

  • Understanding ADFS Authentication and Authorization

  • Understanding Certificates Used by ADFS

  • ADFS resources


ADFS Overview

ADFS Overview

  • Introduction to ADFS

  • ADFS server roles

  • Federation scenarios

  • Partner organizations

  • Federation trusts

  • ADFS requirements

  • Terminology used in ADFS


Introduction to ADFS

ADFS is a component in Microsoft® Windows Server™ 2003 R2 that provides Web single-sign-on (SSO) technologies to authenticate a user to multiple 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.

ADFS is not:

  • .NET Passport.

  • A database or repository for employee or customer identity data.

  • An extension of the Active Directory™ directory service schema.

  • A type of Windows domain or forest trust.

ADFS in Windows Server 2003 R2 supports the WS-Federation Passive Requestor Profile (WS-F PRP).

Key features of ADFS

The following are some of the key features of ADFS in Windows Server 2003 R2:

  • Federation and Web SSO

    When an organization uses the Active Directory™ directory service, it currently experiences the benefit of SSO functionality through Windows-integrated authentication within the organization's security or enterprise boundaries. ADFS extends this functionality to Internet-facing applications, which enables customers, partners, and suppliers to have a similar, streamlined, Web SSO user experience when they access the organization’s Web-based applications. Furthermore, federation servers can be deployed in multiple organizations to facilitate business-to-business (B2B) federated transactions between partner organizations. For more information about ADFS federation, see Federation scenarios.

  • Web Services (WS)-* interoperability

    ADFS provides a federated identity management solution that interoperates with other security products that support the WS-* Web Services Architecture. ADFS does this by employing the federation specification of WS-*, called WS-Federation. The WS-Federation specification makes it possible for environments that do not use the Windows identity model to federate with Windows environments. For more information about WS-* specifications, see ADFS resources.

  • Extensible architecture

    ADFS provides an extensible architecture that supports the Security Assertion Markup Language (SAML) token type and Kerberos authentication (in the Federated Web SSO with Forest Trust scenario). ADFS can also perform claim mapping, for example, modifying claims using custom business logic 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. For more information about modifying claims, see Claim mapping.

Extending Active Directory to the Internet

Active Directory serves as a primary identity and authentication service in many organizations. With Windows Server 2003 Active Directory, forest trusts can be created between two or more Windows Server 2003 forests to provide access to resources that are located in different business units or organizations. For more information about forest trusts, see How Domain and Forest Trusts Work on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=35356).

However, there are scenarios in which forest trusts are not a viable option. For example, access across organizations may need to be limited to only a small subset of individuals, not every member of a forest.

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. These trusted partners can include external third parties or other departments or subsidiaries in the same organization.

ADFS is tightly integrated with Active Directory. ADFS retrieves user attributes from Active Directory, and it authenticates users against Active Directory. ADFS also uses Windows Integrated Authentication.

ADFS works with both Active Directory and Active Directory Application Mode (ADAM). Specifically, ADFS works with both enterprise-wide deployments of Active Directory or instances of ADAM. When it works with Active Directory, ADFS can take advantage of the strong authentication technologies in Active Directory, including Kerberos, X.509 digital certificates, and smart cards. When it works with ADAM, ADFS uses Lightweight Directory Access Protocol (LDAP) Bind as a means to authenticate users. For more information about how ADFS works with Active Directory and ADAM, see Account stores.

ADFS supports distributed authentication and authorization over the Internet. ADFS can be integrated into an organization's or department’s existing access management solution to translate the terms that are used in the organization into claims that are agreed on as part of a federation. ADFS can create, secure, and verify the claims that move between organizations. It can also audit and monitor the activity between organizations and departments to help ensure secure transactions.


ADFS server roles

Active Directory Federation Services (ADFS) can operate only when the servers running Windows Server 2003 R2 are configured appropriately. Depending on the environment in your organization, specific ADFS server roles must be deployed. The following sections describe the server roles that can be used to provide an ADFS federated identity management solution.

Federation server

Federation servers host the Federation Service component of ADFS. They are used to route authentication requests that are made from user accounts in other organizations (in Federated Web Single-Sign-On (SSO) scenarios) or from clients that can be located anywhere on the Internet (in the Web SSO scenario). For more information about the different ADFS scenarios, see Federation scenarios.

Federation servers also host a security token service that issues tokens that are based on the credentials (for example, user name and password) that are presented to it. After the credentials are verified (by the user logging on), Claims for the user are collected through examination of the attributes for the user that are stored in Active Directory or Active Directory Application Mode (ADAM).

In Federated Web SSO scenarios, claims can then be modified by claim mappings for a specific resource partner. The claims are built into a token that is sent to a federation server in the resource partner. After a federation server in the resource partner receives the claims as incoming claims, it maps them into their organization claims. The organization claims are then built into a new token that is sent to the ADFS Web Agent.

The role that a federation server plays in either of the Federated Web SSO scenarios (Federated Web SSO or Federated Web SSO with Forest Trust) can depend on whether your organization is designated as the account partner or the resource partner:

  • Federation servers in the account partner are used to log on local user accounts in either an Active Directory store or an Active Directory Application Mode (ADAM) store. Federation servers also issue initial security tokens that the local user accounts can use to access Web-based applications that are hosted in the resource partner. In addition, federation servers in the account partner issue cookies to users to maintain login status. These cookies include claims for those users. These cookies enable SSO capabilities so that users do not have to enter credentials each time that they visit different Web-based applications in the resource partner.

  • Federation servers at the resource partner validate the security tokens that are issued by the federation servers at the account partner. Federation servers at the resource partner also issue security tokens that are meant for the Web-based applications in the resource partner. In addition, federation servers in the resource partner issue cookies to the user accounts, which come from the account partner. These cookies enable SSO capabilities so that users do not have to log in again at their federation servers in the account partner when users attempt to access different Web-based applications at the resource partner.

For more information about the account and resource partners, see Partner organizations.

Federation server proxy

Federation server proxies host the Federation Service Proxy component of ADFS. Federation server proxies can be deployed in an organization's perimeter network (also known as a demilitarized zone (DMZ) or a screened subnet) to forward requests to federation servers that are not accessible from the Internet.

Note

Although you can deploy separate servers to host the Federation Service Proxy component, it is not necessary to deploy a separate server to act as a federation server proxy in the intranet forest of either the account partner or the resource partner. A federation server performs this role automatically.

The role that a federation server proxy plays in your organization can depend on whether your organization is the account partner or the resource partner:

  • Federation server proxies at the account partner act as proxies for user logons to federation servers that are located in the intranet. Federation server proxies also act as proxies for security tokens that are issued by the account partner federation server for both its own tokens and those tokens that are destined for resource partners.

  • Federation service proxies in the resource partner act as proxies for user security tokens, which are issued from federation servers in both the account partner and the resource partner, to Web-based applications in the resource partner.

Web server

In ADFS, Web servers in the resource forest host the ADFS Web Agent component to provide secure access to the Web applications that are hosted on those Web servers. The ADFS Web Agent manages security tokens and authentication cookies that are sent to a Web server. The Web server requires a relationship with a Federation Service so that all authentication tokens come from that Federation Service.

The ADFS Web Agent supports two types of applications: claims-aware applications and Windows NT token–based applications. For information about these types of applications, see Controlling Access to Web-based Applications.


Federation scenarios

Active Directory Federation Services (ADFS) supports federated identity scenarios that use Web Services Federation (WS-Federation), WS-Federation Passive Requestor Profile (WS-F PRP), and WS-Federation Passive Requestor Interoperability Profile specifications. The ADFS solution helps administrators deal with federated identity management challenges by making it possible for organizations to securely share a user's identity information over Federation trusts. The following three descriptions of deployment scenarios illustrate how you can use ADFS server roles to federate identities, depending on the needs of your organization.

Federated Web SSO

The ADFS Federated Web Single-Sign-On (SSO) scenario involves secure communication that often spans multiple firewalls, perimeter networks, and name resolution servers, in addition to the entire Internet routing infrastructure. Communication over a federated Web SSO environment can help foster more efficient and secure online transactions between organizations that are joined by federation trust relationships.

As shown in the following illustration, a federation trust relationship can be established between two businesses. In this scenario, federation servers route authentication requests from user accounts in Tailspin Toys to Web-based applications that are located in the network of Online Retailer.

Federated Web SSO scenario

Federation servers authenticate requests from trusted partners based on the credentials of the partners. Representations of the credentials are exchanged in the form of security tokens.

For enhanced security, federation server proxies can be used to relay requests to federation servers that are not directly accessible from the Internet.

Federated Web SSO with Forest Trust

The ADFS Federated Web SSO with Forest Trust scenario involves two Active Directory forests in a single organization, as shown in the following illustration. One of the forests is located in the organization's perimeter network (also known as a demilitarized zone (DMZ) or a screened subnet). The other forest is located in the internal network. A one-way, forest trust is established so that the forest in the perimeter network trusts the forest in the internal network. Federation servers are deployed in both networks. A federation trust is established so that accounts in the internal forest can be used to access a Web-based application in the perimeter network, whether the accounts access the site from the intranet forest or from the Internet.

Federated Web SSO with Forest Trust scenario

In this scenario, external users, such as customers, can access the Web application by authenticating to the external account federation server, which is located in the perimeter network. External users have user accounts in the perimeter-network Active Directory forest. Internal users, such as employees, can also access the Web application by authenticating to the internal account federation server, which is located in the internal network. Internal users have accounts in the internal Active Directory forest.

If the Web-based application is a Windows NT token-based application, the ADFS Web Agent that is running on the Web application server intercepts requests and creates Windows NT security tokens, which are required by the Web application to make authorization decisions. For external users, this is possible because the Web server that hosts the Windows NT token-based application is joined to the domain in the external forest. For internal users, this is enabled through the forest trust relationship that exists between the perimeter forest and the internal forest.

If the Web-based application is a claims-aware application, the ADFS Web Agent that is running on the Web application server does not have to create Windows NT security tokens for the user. The ADFS Web agent can expose the claims that come across, which allows the application to make authorization decisions based on the contents of the security token that is provided by the account federation server. As a result when it deploys claims-aware applications, the Web server does not have to be joined to the domain, and the external-forest-to-internal-forest trust is not required.

Web SSO

In the ADFS Web SSO scenario, users must authenticate only once to access multiple Web-based applications. In this scenario all users are external, and no federation trust exists. Because the Web servers must be Internet accessible and also joined to the Active Directory domain, they are connected to two networks; that is, they are multihomed. The first network is Internet facing (the perimeter network) to provide the needed connectivity. The second network contains the Active Directory forest (the protected network), which is not directly Internet accessible. The federation server proxy is also multihomed to provide the necessary connectivity to the federation server and the Internet. In this scenario, placing the federation server on a network that is not directly accessible from the Internet greatly reduces the risk to the federation server.

Web SSO scenario


Partner organizations

When you plan for cross-organizational (federation-based) collaboration using Active Directory Federation Services (ADFS), you first determine whether your organization will host a Web resource to be accessed by other organizations across the Internet — or the reverse. This determination affects how you deploy ADFS, and it is fundamental in the planning of your ADFS infrastructure.

For Federation scenarios such as Federated Web Single Sign-On (SSO) and Federated Web SSO with Forest Trust (but not the Web SSO scenario), ADFS uses terms such as "account partner" and "resource partner" to help differentiate the organization that hosts the accounts (the account partner) from the organization that hosts the Web-based resources (the resource partner). The term "Federation trusts" is used in ADFS to characterize the one-way, nontransitive relationship that is established between the account partner and the resource partner.

The following sections explain some of the concepts that are related to account partners and resource partners.

Account partner

An account partner represents the organization in the federation trust relationship that physically stores user accounts in either an Active Directory store or an Active Directory Application Mode (ADAM) store. The account partner is responsible for collecting and authenticating a user's credentials, building up claims for that user, and packaging the claims into security tokens. These tokens can then be presented across a federation trust to access Web-based resources that are located in the resource partner organization.

In other words, an account partner represents the organization for whose users the account-side Federation Service issues security tokens. The Federation Service in the account partner organization authenticates local users and creates security tokens that are used by the resource partner in making authorization decisions.

In relation to Active Directory, the account partner in ADFS is conceptually equivalent to a single Active Directory forest whose accounts need access to resources that are physically located in another forest. Accounts in this example forest can access resources in the resource forest only when an external trust or forest trust relationship exists between the two forests and the resources to which the users are trying to gain access have been set with the proper authorization permissions.

Note

This analogy is meant strictly to emphasize how the relationship between account and partner organizations in ADFS is similar, in concept, to the relationship between an account forest and a resource forest in Active Directory. External trusts and forest trusts are not required for ADFS to function.

Producing claims that go to the resource partner

A claim is a statement that a server makes (for example, name, identity, key, group, privilege, or capability) about a client. An account partner produces claims that the resource partner Federation Service consumes. The following list describes the different types of claims that can be configured in the account partner:

  • UPN claim

    When you configure the account partner, you can specify a list of user principal name (UPN) domains and suffixes that may be accepted from the account partner. If a UPN identity is received whose domain part is not in the list, the request is rejected.

  • E-mail claim

    When you configure the account partner, you can specify a list of e-mail domains and suffixes that may be accepted from the account partner. As with the UPN claim, if an e-mail identity is received whose domain part is not in the list, the request is rejected.

  • Common name claim

    When you configure the account partner, you can specify whether common name claims can be received from the account partner. This type of claim may not be mapped; it is simply passed through if it is enabled.

  • Group claims

    When you configure the account partner, you can specify a set of incoming group claims that may be accepted from the partner. You can then associate each possible incoming group with an organization group claim. Note that this creates a group mapping. If an incoming group is encountered that has no mapping, it is discarded.

  • Custom claims

    When you configure the account partner, you can specify a set of incoming names of custom claims that are accepted from the partner. You can then map each possible incoming name to an organization custom claim. Note that this creates a name mapping. If an incoming custom claim is encountered that has no mapping, it is discarded.

Resource partner

A resource partner is the second organizational partner in the federation trust relationship. A resource partner is where the Web servers that host one or more Web-based applications (the resources) reside. The resource partner trusts the account partner to authenticate users. Therefore, to make authorization decisions, the resource partner consumes the claims that are packaged in security tokens coming from users in the account partner.

In other words, a resource partner represents the organization whose Web servers are protected by the resource-side Federation Service. The Federation Service at the resource partner uses the security tokens that are produced by the account partner to make authorization decisions for Web servers that are located in the resource partner.

To function as an ADFS resource, Web servers in the resource partner organization must have the ADFS Web Agent component of ADFS installed. Web servers that function as an ADFS resource can host either claims-aware applications or Windows NT token-based applications. For more information about the two types of applications, see Controlling Access to Web-based Applications.

Note

If the application that is hosted on the Web server is a Windows NT token–based application, a resource account may be required for the Active Directory forest in the resource partner organization.

In relation to Active Directory, the resource partner is conceptually equivalent to a single forest whose resources are made available over an external trust or forest trust relationship to accounts that are physically stored in another forest.

Note

This analogy is meant strictly to emphasize how the relationship between account and partner organizations in ADFS is similar, in concept, to the relationship between an account forest and a resource forest in Active Directory. External trusts and forest trusts are not required for ADFS to function.

Consuming claims that come from the account partner

A resource partner consumes claims that the account partner Federation Service produces and packages in security tokens. The following list describes how claims can be sent to the resource partner:

  • UPN claim

    When you configure the resource partner, you can specify whether a UPN claim is to be sent to the resource partner. You can also specify a suffix mapping so that any suffix is mapped into a specified outgoing suffix. For example, julianp@sales.tailspintoys.com can be mapped to julianp@tailspintoys.com. Note that only one outgoing suffix may be specified.

  • E-mail claim

    When you configure the resource partner, you can specify whether an e-mail claim is to be sent to the resource partner. You can also specify a suffix mapping so that any suffix is mapped into a specified suffix. For example, vernettep@sales.tailspintoys.com can be mapped to vernettep@tailspintoys.com. Note that only one outgoing suffix may be specified.

  • Common name claim

    When you configure the resource partner, you can specify whether common name claims can be sent to the resource partner. This type of claim may not be mapped; it is simply passed through to the resource partner if it is enabled.

  • Group claims

    When you configure the resource partner, you can specify a set of outgoing group claims that will be accepted by the resource partner. You can then associate each possible outgoing group claim to organization group claims. Note that this creates a set of group mappings. Organization group claims that do not match an outgoing group claim are not created.

  • Custom claims

    When you configure the resource partner, you can specify a set of outgoing custom claims that are accepted by the resource partner. You can map each possible outgoing custom claim to a custom claim. Note that this creates a set of name mappings. Organization custom claims that do not match an outgoing custom claim are not created.

Enhanced identity privacy

Enhanced identity privacy is an optional setting that can be configured on a resource partner in the trust policy. If the Enhanced identity privacy option is enabled, this setting hashes the user-name portion of outgoing UPN claims and e-mail claims. It substitutes the common name with a random value.

The purpose of this feature is to prevent:

  • The resource partner from correlating identity claims to personally identifiable user information.

  • Collusion between partners in correlating identity claims to personally identifiable user information. This setting creates a unique hash per partner so that identity claim values are different across different trusting realm partners but consistent across sessions for a single partner.

  • Simple dictionary attacks against the hash by salting the user value with data that is in the trust policy — data that is not known by the resource partners.

How enhanced identity privacy works

If the Enable enhanced identity privacy setting is enabled, the user’s identity is transformed by the account Federation Service before it is sent to the resource realm. The account Federation Service does this by hashing a combination of the privacy key (for salting), the resource partner Uniform Resource Identifier (URI), and the identity claim itself. Therefore, the resulting transformed identity will be the same when the following values are the same:

  • Privacy key

  • Resource partner URI

  • Identity claim (UPN or e-mail)

The hashing algorithm is case sensitive. Therefore, the hashed results are different if the case of the URI or the user-name portion of the UPN claim or e-mail claim is different.


Federation trusts

You can use Active Directory Federation Services (ADFS) to enable efficient and secure online transactions between Partner organizations that are joined by federation trust relationships. In other words, a federation trust is the embodiment of a business-level agreement or partnership between two organizations.

As shown in the following illustration, you can establish federation trust relationships between two partner organizations when both of the organizations deploy at least one ADFS federation server and they configure their Federation Service settings appropriately. The one-way arrow signifies the direction of the trust, which — like the direction of Windows trusts — always points to the account side of the forest. This means that authentication flows from the account partner organization to the resource partner organization.

Federation trust linking partner organizations
Note

No communication occurs over the network between the account Federation Service and the resource Federation Service.

After you create the federation trust, users who are located in the account partner organization can send authentication requests successfully through the federation trust to the Web server in the resource partner organization. A federation trust is created when the account partner organization and the resource partner organization both install the Federation Service component of ADFS and they both use the Active Directory Federation Services snap-in to configure the account partner and resource partner appropriately.

If one side of a federation trust (either the account partner or the resource partner) is not configured or if it is configured incorrectly by the administrator for either organization, the federation trust will not be created successfully. For detailed guidance about how to create federation trusts, look for ADFS step-by-step or deployment content on the Windows Server 2003 R2 page (http://go.microsoft.com/fwlink/?LinkId=45560) of the Microsoft Windows Server 2003 TechCenter Web site.

Note

Federation trusts are not used in the Web Single-Sign-On (SSO) scenario. For more information about the Web SSO scenario, see Federation scenarios.


ADFS requirements

Active Directory Federation Services (ADFS) has the following hardware and software requirements.

Hardware requirements

  • Processor speed: 133 MHz for x86-based computers

  • Recommended minimum RAM: 256 MB

  • Free disk space for setup: 10 MB

Software requirements

ADFS relies on server functionality that is built into the Windows Server 2003 R2 operating system. The Federation Service, Federation Service Proxy, and ADFS Web Agent components cannot run on earlier operating systems. This section describes the software requirements for each ADFS component. It also describes the overall software configurations that are necessary for ADFS in your network environment.

Note

The Federation Service and Federation Service Proxy components cannot coexist on the same computer, and they can be installed only on computers running Windows Server 2003 R2, Enterprise Edition, or Windows Server 2003 R2, Datacenter Edition.

Federation Service

Computers running the Federation Service must have the following software installed:

  • Windows Server 2003 R2, Enterprise Edition, or Windows Server 2003 R2, Datacenter Edition

  • Internet Information Services (IIS)

  • Microsoft ASP.NET 2.0

  • Microsoft .NET Framework 2.0

  • A default Web site that is configured with Transport Layer Security and Secure Sockets Layer (TLS/SSL)

  • A certificate for the Federation Service

    Note

    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

Or

  • Windows Server 2003 R2

Or

  • Windows 2000 with Service Pack 4 (SP4) with critical updates

ADFS does not require schema changes or functional-level modifications to Active Directory. To ensure that ADAM works with ADFS, install the version of ADAM that comes with Windows Server 2003 R2.

Federation Service Proxy

Computers running the Federation Service Proxy must have the following software installed:

  • Windows Server 2003 R2, Enterprise Edition, or Windows Server 2003 R2, Datacenter Edition

  • IIS

  • ASP.NET 2.0

  • Microsoft .NET Framework 2.0

  • A default Web site configured with TLS/SSL

ADFS Web Agent

Computers running the ADFS Web Agent must have the following software installed:

  • Windows Server 2003 R2, Standard Edition; Windows Server 2003 R2, Enterprise Edition; or Windows Server 2003 R2, Datacenter Edition

  • IIS

  • ASP.NET 2.0

  • Microsoft .NET Framework 2.0

  • After the ADFS Web Agent installation is complete, at least one Web site in IIS must be configured with TLS/SSL so that federated users can access Web-based applications that are hosted on the Web server.

Trusted certification authorities

Because both TLS/SSL and token signing rely on digital certificates, certification authorities (CAs) are an important part of ADFS. Public CAs, such as VeriSign, Inc., represent a mutually trusted third party that allows the identity of the bearer of a certificate to be identified. You can use enterprise CAs, such as Microsoft Certificate Services, for providing token signing and other internal certificate services.

If a client is presented with a server’s authentication certificate, the client computer verifies that the CA that issued the certificate is in the client’s list of trusted CAs and that the CA has not revoked that certificate. This verification ensures that the client has reached the intended server. When a certificate is used for verifying signed tokens, the client uses the certificate to verify that the token was issued by the correct federation server and that the token has not been tampered with.

TCP/IP network connectivity

For ADFS to function, TCP/IP network connectivity must exist between the client; a domain controller; and the computers that host the Federation Service, the Federation Service Proxy (when it is used), and the ADFS Web Agent.

DNS

For the purpose of authenticating users in the intranet, internal Domain Name System (DNS) servers in the intranet forest must be configured to return the canonical name (CNAME) of the internal server that is running the Federation Service. For best results, do not use Hosts files with DNS.

Web browser

Although any current Web browser with JScript enabled should work as an ADFS client, only Internet Explorer 6, Internet Explorer 5 or 5.5, Mozilla Firefox, and Safari on Apple Macintosh have been tested by Microsoft. For performance reasons, it is highly recommended that JScript be enabled. Cookies must be enabled, or at least trusted, for the federation servers and Web applications that are being accessed.


Terminology used in ADFS

Active Directory Federation Services (ADFS) uses terminology from several different technologies, including certificate services, Internet Information Services (IIS), Active Directory, Active Directory Application Mode (ADAM), and Web Services (WS-*). The following table describes these terms.

Term Description

account partner

A federation partner that is trusted by the Federation Service to provide security tokens. The account partner issues these tokens to its users (that is, users in the account partner realm) so that they can access Web-based applications in the resource partner.

Active Directory Federation Services (ADFS)

A Windows Server 2003 R2 component that provides Web single-sign-on (SSO) technologies to authenticate a user to multiple Web applications over the life of a single online session. ADFS accomplishes this by securely sharing digital identity and entitlement rights across security and enterprise boundaries. ADFS in Windows Server 2003 R2 supports the WS-Federation Passive Requestor Profile (WS-F PRP).

claim

A statement that a server makes (for example, name, identity, key, group, privilege, or capability) about a client.

claim mapping

The act of mapping, removing or filtering, or passing claims between various claim sets.

claims-aware application

A Microsoft ASP.NET application that performs authorization based on the claims that are present in an ADFS security token.

client account partner discovery Web page

The Web page that is used to interact with the user to determine which account partner the user belongs to when ADFS cannot automatically determine which of the account partners should authenticate the user.

client logoff Web page

When ADFS performs a logoff operation, a Web page that is executed to provide visual feedback to the user that the logoff has occurred.

client logon Web page

When ADFS collects client credentials, a Web page that is executed to perform the user interaction. The client logon Web page may use any necessary business logic to determine the type of credentials to collect.

federation

A pair of realms or domains that have established a federation trust.

Federation Service

A security token service that is built into Windows Server 2003 R2. The Federation Service provides tokens in response to requests for security tokens.

Federation Service Proxy

A proxy to the Federation Service in the perimeter network (also known as demilitarized zone (DMZ) and screened subnet). The Federation Service Proxy uses WS-F PRP protocols to collect user credential information from browser clients and Web applications and send the information to the Federation Service on their behalf.

organization claims

Claims in intermediate or normalized form within an organization's namespace.

passive client

A Hypertext Transfer Protocol (HTTP) browser, capable of broadly supported HTTP, that can make use of cookies. ADFS in Windows Server 2003 R2 supports only passive clients, and it adheres to the WS-F PRP specification.

resource partner

A federation partner that trusts the Federation Service to issue claims-based security tokens. The resource partner contains published Web-based applications that users in the account partner can access.

security token

A cryptographically signed data unit that expresses one or more claims.

security token service (STS)

A Web service that issues security tokens. An STS makes assertions based on evidence that it trusts, to whoever trusts it (or to specific recipients). To communicate trust, a service requires proof, such as a signature to prove knowledge of a security token or set of security tokens. A service itself can generate tokens or it can rely on a separate STS to issue a security token with its own trust statement. This forms the basis of trust brokering. In ADFS, the Federation Service is an STS.

server farm

In ADFS, a collection of load-balanced federation servers, federation server proxies, or Web servers hosting the ADFS Web Agent.

single sign-on (SSO)

An optimization of the authentication sequence to remove the burden of repeated logon actions by an end user.

token-signing certificate

An X509 certificate whose associated public/private key pair is used to provide integrity for security tokens.

Uniform Resource Identifier (URI)

A compact string of characters that identifies an abstract resource or physical resource. URIs are explained in RFC 2396 (http://go.microsoft.com/fwlink/?LinkId=48289). In ADFS, URIs are used to uniquely identify partners and account stores.

Web Services (WS-*)

The specifications for a Web Services Architecture that is based on industry standards such as Simple Object Access Protocol (SOAP); XML; Web Service Description Language (WSDL); and Universal Description, Discovery, and Integration (UDDI). WS-* provides a foundation for delivering complete, interoperable business solutions for the extended enterprise, including the ability to manage federated identity and security.

The Web services model is based on the idea that enterprise systems are written in different languages, with different programming models, which run on and are accessed from many different types of devices. Web services are a means of building distributed systems that can connect and interact with one another easily and efficiently across the Internet, regardless of what language they are written in or what platform they run on.

Web Services Security (WS-Security)

A series of specifications that describes how to attach signature and encryption headers to SOAP messages. In addition, WS-Security describes how to attach security tokens, including binary security tokens such as X.509 certificates and Kerberos tickets, to messages. In ADFS, WS-Security is used when Kerberos signs security tokens.

Windows NT token–based application

A Windows application that relies on a Windows NT token to perform authorization of users.

WS-Federation

A specification that defines a model and set of messages for brokering trust and the federation of identity and authentication information across different trust realms.

The WS-Federation specification identifies two sources of identity and authentication requests across trust realms: active requestors, such as SOAP-enabled applications, and passive requestors, which are defined as HTTP browsers capable of supporting broadly supported HTTP, for example, HTTP 1.1.

WS-Federation Passive Requestor Profile (WS-F PRP)

An implementation of the WS-Federation specification that proposes a standard protocol for how passive clients (such as Web browsers) 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.


Understanding ADFS Components

Understanding ADFS Components

  • Federation Service

  • Federation Service Proxy

  • ADFS Web Agent

  • Active Directory Federation Services snap-in

  • Active Directory Federation Services Proxy snap-in


Federation Service

The Federation Service is a component of Active Directory Federation Services (ADFS) that can be installed independently from other ADFS components. The Federation Service functions as a security token service. The act of installing the Federation Service component on a computer makes that computer a federation server. It also makes the Active Directory Federation Services snap-in available in the Administrative Tools menu on that computer.

The Federation Service is designed to use Active Directory to provide tokens in response to requests for security tokens. This enables Active Directory domains and forests to function as:

  • Identity providers that can federate with compliant account partners and resource partners. As an identity provider, the Federation Service can project Active Directory identities across the Internet to interact with applications at compliant service providers.

  • Service providers that can federate with compliant account partners and resource partners. As a service provider, the Federation Service can allow identities from other organizations to access a partner's Windows-based and ASP.NET-based applications.

  • Security token providers for applications that are compliant with the WS-Federation Passive Requestor Profile (WS-F PRP) specification.

As an account partner, the Federation Service allows Active Directory users to access resources at partner organizations. In response to a request from a resource partner, the Federation Service collects and verifies user credentials against Active Directory or Active Directory Application Mode (ADAM). The Federation Service can then populate a set of organization claims based on the Lightweight Directory Access Protocol (LDAP) attributes of the user account. The organization claims are then mapped to appropriate claims for the resource partner and packaged into a security token that is signed by the Federation Service’s token-signing certificate. The resultant security token is posted as the response to the resource partner’s original request. The resource partner then uses the token to allow access for the user.

As a resource partner, the Federation Service plays the opposite role. When a user attempts to access an ADFS-protected application, the Federation Service determines which account partner should authenticate the user. It then sends an authentication request to that partner. When the user returns with a security token, the Federation Service verifies that the token has been correctly signed by the partner. It then extracts the claims from the token. The claims are mapped to organization claims, and the filtering policy for the specific application is applied. The filtered organization claims are packaged into a security token that is either signed by the Federation Service’s token-signing certificate or protected by a Kerberos session key for the Web application. The resultant security token is posted back to the original application Uniform Resource Locator (URL). The application then uses the token to allow access for the user.

ADFS uses the WS-F PRP protocol to carry Claims in security tokens that are issued by the Federation Service to the Web application. For more information about the WS-F PRP specification, see ADFS resources.

These claims are populated initially from Account stores, either Active Directory or ADAM account stores. The Federation Service issues tokens based on the credentials that are presented. After the credentials are verified using the account store, the claims for the user are generated according to the rules of the trust policy. The obtained inbound claims are mapped into outbound claims that are appropriate for a resource partner. The resulting claim mappings are added to a security token that is issued to the resource partner. For more information, see Claim mapping.

After the token is verified, an authentication cookie is issued and written to the client browser. Each time that the client needs to be authenticated, this cookie is used by the Federation Service so that the client does not have to enter credentials again, thereby enabling single sign-on (SSO). For more information, see Cookies used by ADFS.

Federation Service Web pages

The Federation Service provides a Web page that prompts the user to select an appropriate account partner to which the user can authenticate. The Federation Service also provides a Web page that prompts for the user’s credentials, such as a user name and password for forms-based authentication. A Web page is also provided that supports Windows Integrated Authentication.

Behind the Web pages, the Federation Service provides a Microsoft ASP.NET Web service that processes requests from the client or the federation server proxy. The federation server proxy is located in the perimeter network. It acts as an intermediary between an Internet client and a Federation Service in the intranet. For more information about the role of the federation server proxy, see ADFS server roles.

There are two basic types of requests to which the Federation Service responds:

  • Requests to issue security tokens

  • Requests to retrieve trust policy data

Account partner discovery

Account partner discovery is the process by which a client can identify what account partner it prefers for authentication in the event that more than a single account partner is configured. The Federation Server presents this choice to the client browser as a drop box containing the account partner names as they are configured in the trust policy.

One mechanism that you can use to avoid account partner discovery is to include the whr parameter in the query string for the resource being accessed, for example,

https://webserver/testapp/testpage.aspx?whr=urn:federation:< accountpartner>, where <accountpartner> indicates the account partner realm of the client.

When the whr parameter is used, the Web server removes the parameter and writes a cookie to the client browser to remember this setting for future requests. Then, the request proceeds in the same way as if it had not been provided.


Federation Service Proxy

The Federation Service Proxy is a component of Active Directory Federation Services (ADFS) in Windows Server 2003 R2 that can be installed independently from other ADFS components. The Federation Service Proxy functions as a proxy in a perimeter network (also known as demilitarized zone (DMZ) and screened subnet) for the Federation Service. The act of installing the Federation Service Proxy component on a computer makes that computer a federation server proxy. It also makes the Active Directory Federation Services Proxy snap-in available on that computer in the Administrative Tools menu.

A federation server proxy participates in the WS-Federation Passive Requestor Profile (WS-F PRP) protocol by communicating with a protected Federation Service on the client’s behalf. When the federation server proxy is protecting an account partner, it collects user credential information from browser clients. When the federation server proxy is protecting a resource partner, it relays requests by and for Web applications to the Federation Service.

The federation server proxy also stores Hypertext Transfer Protocol (HTTP) cookies on clients when necessary to facilitate single sign-on (SSO). For more information, see Cookies used by ADFS. The federation server proxy writes all three types of cookies: authentication cookies, account partner cookies, and sign-out cookies. For more information about the federation server proxy role, see ADFS server roles.


ADFS Web Agent

The Active Directory Federation Services (ADFS) Web Agent is a component of ADFS. It is used to consume security tokens and either allow or deny a user access to a Web application. To accomplish this, the Web server requires a relationship with a resource Federation Service so that it can direct the user to the Federation Service as needed.

The ADFS Web Agent can be used for two different types of applications:

  • Claims-aware applications: A Microsoft ASP.NET application that is written to published ADFS objects that allow the querying of ADFS security token Claims. The application makes authorization decisions based on these claims. Security token failures for this type of application result in the client seeing an "Access Denied" message and events in the Federation Service event log. For more information, see Claims-aware applications.

  • Windows NT token–based applications: An application that uses Windows-based authorization mechanisms. The ADFS Web Agent supports conversion from an ADFS security token to an impersonation-level Windows NT access token. For more information, see Windows NT token-based applications.

The Web server also stores Hypertext Transfer Protocol (HTTP) cookies on clients where necessary to facilitate single sign-on (SSO). The ADFS Web Agent comprises two separate components:

  • ADFS Web Agent ISAPI Extension

  • ADFS Web Agent Authentication Service

ADFS Web Agent ISAPI Extension

The ADFS Web Agent ISAPI Extension is an Internet Server Application Programming Interface (ISAPI) extension that you can use to configure information in the Internet Information Services (IIS) metabase. In IIS Manager you can use the ADFS Web Agent tabs on the Web Sites and Default Web Sites property pages to administer policy and certificates that verify the ADFS security token and cookies.

The ADFS Web Agent properties in the following table are inheritable. These properties are required on an IIS resource if the ISAPI extension is going to support the WS-Federation Passive Requestor Profile (WS-F PRP) protocol.

Properties | Description
Federation Service URL | The Uniform Resource Locator (URL) of the Federation Service. This URL is required so that it may be queried for trust information.
Cookie path | The path that is specified when the authentication cookie is written. The cookie path property may also be used to indicate to the ISAPI extension that ADFS authentication should not be used for the particular file or virtual directory. To indicate this, set the property value to EXCLUDE.
Cookie domain | The domain for which the cookie is valid.
Return URL | The URL that the token from the Federation Service comes back to after authentication at the Federation Service. This URL should match the Audience element of the token. The checking against the Audience element is performed by the Windows service.

Optional debug trace logging configuration

Optional debug trace logging is configured for the ISAPI extension through the registry DWORD value in the following path: HKLM\Software\Microsoft\ADFS\WebServerAgent\DebugPrintLevel. If the value is present, a log in the directory that is specified at HKLM\Software\Microsoft\ADFS\LogFilesPath with the name ifsext_<ApplicationPoolName>.log is produced. A notification on the registry key HKLM\Software\Microsoft\ADFS\WebServerAgent is registered by the extension so that a change in the debug level may be made without restarting the IIS worker process. The following flag values are used to control the verbosity of the log file:

  • Error – 0x1

  • Warning – 0x2

  • Trace - 0x4

ADFS Web Agent Authentication Service

The ADFS Web Agent Authentication Service validates incoming tokens and cookies. It runs as Local System to generate a token by using either Service-for-User (S4U) or the ADFS authentication package. However, the IIS application pool is not required to run as Local System.

The ADFS Web Agent Authentication Service has interfaces that may be called only with local remote procedure call (LRPC), not RPC. This service returns an impersonation Windows NT access token if it is given an ADFS security token or an ADFS cookie.


Active Directory Federation Services snap-in

The Active Directory Federation Services (ADFS) Microsoft Management Console (MMC) snap-in is installed when you install the Federation Service component in Add or Remove Programs in Windows Server 2003 R2, Enterprise Edition. You can use the ADFS snap-in to:

  • Configure the Federation Service or federation server farm.

  • Manage the trust policy that is associated with your Federation Service:

    • Administer Active Directory or Active Directory Application Mode (ADAM) Account stores.

    • Manage account partners and resource partners that will trust your Partner organizations.

    • Manage the applications that are going to be protected by ADFS.

    • Manage Claims, Certificates used by federation servers, and ADFS-protected Web applications.

Settings that you configure in the ADFS snap-in are stored partly in the Web.config file, which is located in the Federation Service virtual directory, and partly in the trust policy file. You can edit the Web.config file directly and push it out to different servers, or you can use the ADFS snap-in to modify the settings.

The trust policy file should not be edited manually. Instead, edit the trust policy file by using the ADFS snap-in, or edit it programmatically by using the ADFS object model.

Note

Scripting support is provided in the ADFS object model.

When you open the ADFS snap-in, the snap-in reads the Web.config file from the Federation Service virtual directory and notes the location of the trust policy file. The snap-in then presents a console tree hierarchy representing the Federation Service and all aspects of the trust policy, including organization claims, partners, account stores, and applications. Each item in this console tree hierarchy has context-menu options that you can use to view, modify, add, and delete trust policy entities.

Federation Service node

The Federation Service node in the console tree of the ADFS snap-in represents the local Federation Service that is assigned to the federation server on which you are viewing the snap-in. You control the local federation server configuration through this node in the ADFS snap-in. The local federation server configuration is different from the trust policy configuration in that the trust policy configuration is shared among all the federation servers in the federation server farm. The local configuration is stored in the Web.config file, and it includes the following items:

  • The friendly name for the Federation Service

  • The path to the trust policy file

  • The local certificate to be used for signing tokens

  • The Microsoft ASP.NET Web pages

  • The debug logging level


Active Directory Federation Services Proxy snap-in

The Active Directory Federation Services (ADFS) Proxy Microsoft Management Console (MMC) snap-in is installed when you install the Federation Service Proxy component in Add or Remove Programs in Windows Server 2003 R2, Enterprise Edition. You can use the ADFS Proxy snap-in to:

  • Configure the Federation Service that this Federation Service Proxy is acting as a proxy for.

  • Determine how to collect user credential information from browser clients and Web applications.

The settings in the ADFS Proxy snap-in are stored in the Web.config file in the Federation Service Proxy virtual directory.

Federation Service Proxy node

The Federation Service Proxy node in the snap-in's console tree hierarchy represents the current Federation Service Proxy settings. You control the local federation server proxy configuration through this node in the ADFS Proxy snap-in. The actual client authentication certificate with the private key is present in the local computer personal certificate store.

ADFS distinguishes between the local configuration for a federation server proxy and the trust policy configuration that is shared among all servers in the federation server farm. The local proxy configuration is stored in the Web.config file, and it includes the following items:

  • The Federation Service Uniform Resource Locator (URL)

  • The client authentication certificate to be used by the federation server proxy for Transport Layer Security and Secure Sockets Layer (TLS/SSL) communication with the Federation Service

  • Microsoft ASP.NET Web pages


Understanding ADFS Authentication and Authorization

Understanding ADFS Authentication and Authorization

  • Account stores

  • Cookies used by ADFS

  • Controlling Access to Web-based Applications

  • Understanding Claims


Account stores

Active Directory Federation Services (ADFS) uses account stores to log on users and extract security claims for those users. You can configure multiple account stores for a single Federation Service and define their priority. The Federation Service uses Lightweight Directory Access Protocol (LDAP) to communicate with account stores.

ADFS supports two types of account stores: Active Directory account stores and Active Directory Application Mode (ADAM) account stores.

Active Directory account stores

ADFS is tightly integrated with Active Directory. ADFS retrieves user attributes and authenticates users against Active Directory. ADFS also uses Windows Integrated Authentication and security tokens that Active Directory creates.

For a user to log on to Active Directory, a user name must be in the user principal name (UPN) format (user@adatum.com) or in the Security Accounts Manager (SAM) account name format (adatum\user). After the user is logged on and impersonated, user security IDs (SIDs) are enumerated from the access token. The SIDs are then mapped to organization group Claims.

E-mail claims, common name claims, and custom claims can be extracted from user object attributes that are defined in Active Directory when the Federation Service account is used to perform an LDAP search of an object.

The Federation Service account must have access to the user object. If the user object resides in a domain different from the domain where the Federation Service account resides, the former domain must have an Active Directory domain trust in place to the latter domain.

There is no direct way of determining whether any given user name exists in Active Directory and in all directories that are trusted (either directly or transitively) by Active Directory. Active Directory returns an authoritative failure only if the logon attempt fails as a result of policy restrictions. Examples of policy restriction failures include the following:

  • The account is disabled.

  • The account password has expired.

  • The account is not allowed to log on to this computer.

  • The account has logon time restrictions and is not allowed to log on at this time.

Otherwise, Active Directory account store logon failures are always nonauthoritative, and the next-priority account store is tried. For more information about account store logon failures, see ADFS troubleshooting.

The following is the list of configuration items for the Active Directory account store:

  • A setting indicating whether this entry is enabled

  • The display name for the trusted Active Directory account store

  • Optional: A list of SIDs that map to particular organization group claims

  • Optional: Configuration defining how to extract organization claims from user object attributes in Active Directory:

    • E-mail identity claim or common name identity claim

    • Custom organization claim

The name of a user object attribute defines the claim name when a custom claim is built.

ADAM account stores

ADAM provides data storage and retrieval for directory-enabled applications, without the dependencies that are required for Active Directory. ADAM provides much of the same functionality as Active Directory, but it does not require the deployment of domains or domain controllers. Similar to the way in which ADFS uses Active Directory account store information, ADFS also retrieves user attributes and authenticates users with ADAM.

Note

ADFS cannot authenticate ADAM accounts that use parentheses as part of the account name. Accounts that have an open parenthesis in the user name will cause an LDAP search failure as a result of the user name forming an invalid LDAP filter.

Security claims are obtained when the Federation Service account is used to perform an LDAP search of the object. This is a two-step process:

  • First, the user object is found by means of a search for the object whose configured attribute is equal to the supplied user name. The Federation Service account uses Kerberos or NTLM encryption to protect this communication.

    Note

    This process requires the ADAM server to be joined to a domain that trusts the domain that the Federation Service is a member of.

  • Next, the user credentials are validated by binding to the found user object with the supplied password using LDAP. If Transport Layer Security and Secure Sockets Layer (TLS/SSL) are configured for the ADAM account store properties in the trust policy, the user credentials are protected.

    Important

    It is strongly recommended that the traffic between the ADAM server and the federation server be protected by TLS/SSL or other means, such as Internet Protocol security (IPsec).

If more than one object is returned from the LDAP query with the supplied user name, this is considered an authentication failure. For more information about authentication failures, see ADFS troubleshooting.

Because the presence of the user object is always determined, if the user account exists in the ADAM store, the ADAM store logon is authoritative. Therefore, no additional account stores are attempted. The following is the list of configuration items for the ADAM store:

  • A setting indicating whether this entry is enabled

  • The display name for the trusted ADAM account store

  • The ADAM server name

  • An LDAP user object attribute containing the user name

  • Optional: Port number. If the port number is not specified, it defaults to 389.

  • Optional: Search base. If a subtree is specified, searches are performed on the specified subtree. Otherwise, the entire directory tree is searched.

  • Optional: Client timeout: the maximum time that Federation Service waits for a response from the ADAM server before timing out the connection. The default is five seconds.

  • Optional: Configuration defining how to extract organization claims:

    • UPN/e-mail/common name identity claim: The name of a defined user object attribute whose value is extracted as the UPN/e-mail/common name claim value

    • Group organization claim: The name of a user object attribute and its value that, if present, results in the particular group claim

    • Custom organization claim: The name of a defined user object attribute whose value is extracted as the particular custom claim value

If this configuration is absent, the directory is used only to log on the user — without extracting claims.

Determining the priority order of user logon requests

When a logon request is made to either Active Directory or ADAM through an ADFS client, it is passed immediately to the specified account store. However, if the account store Uniform Resource Identifier (URI) is not specified, each of the stores is tried in priority order to log on the user. The authentication result is returned if:

  • There is only one store configured, and credential verification information is returned.

  • The store URI was specified in the logon request, and credential verification information is returned.

  • The result of authentication by one of the stores was authoritative.

  • Authentication by one of the stores was successful.

Disabling account stores

Each account store can be marked as enabled or disabled. If an account store is disabled, it does not participate in any account-store-related operations. Cookies with claims that originate from an account store that is currently disabled are discarded or deleted, and the client is directed to the logon page.


Cookies used by ADFS

Active Directory Federation Services (ADFS) uses the following three types of cookies:

  • Authentication cookie

  • Account partner cookie

  • Sign-out cookie

Authentication cookie

Authentication cookies can be issued by both the Federation Service and the ADFS Web Agent. The ADFS Web Agent takes the ADFS security token that it receives and uses that token as the cookie value. The benefit at the Web server is that it does not need keying material. The Federation Service publishes all the information that is necessary to validate its tokens.

At the Federation Service, the security token in a cookie holds the organization Claims for the client. The organization claims may be mapped to outgoing claims for a particular resource. The ADFS Web Agent can also authenticate and use cookies that are issued by the Federation Service. The Web server receives a cookie when the client comes to the Web server. Then, the ADFS Web Agent can authenticate this cookie and use the claims that it contains. For more information about how the Federation Service uses tokens, claims, and authentication cookies, see Federation Service.

The authentication cookie facilitates single sign-on (SSO). After the Federation Service validates the client once, the authentication cookie is written to the client. The Federation Service produces and consumes the contents of the authentication cookie, and they are opaque to federation server proxies. Further authentication takes place through use of the cookie rather than through repeated collection of the client credentials. For more information about the federation server proxies, see ADFS server roles.

The following illustration shows the contents of an authentication cookie and the ADFS components that use the authentication cookie. The ADFS Web Agent comprises both the ADFS Web Agent Authentication Service and the ADFS Web Agent ISAPI Extension.

The contents of the authentication cookie

The authentication cookie is always a session cookie. The authentication cookie is signed but not encrypted, which is one reason why use of Transport Layer Security and Secure Sockets Layer (TLS/SSL) in ADFS is mandatory.

Account partner cookie

The account partner cookie facilitates SSO. After interactive account partner membership discovery occurs, if the account partner cookie has a valid token, the cookie is written to the client. Further interactions use the information in this cookie rather than prompting the client for account partner membership information again. The account partner cookie is set as a result of the account partner discovery process. For more information about account partner discovery, see Federation Service.

The account partner cookie is a long-lived, persistent cookie. It is neither signed nor encrypted.

Sign-out cookie

The sign-out cookie facilitates sign-off. Whenever the Federation Service issues a token, the token’s resource partner or target server is added to the sign-out cookie. When it receives a sign-off request, the Federation Service or Federation Service Proxy sends requests to each of the token target servers asking them to clean up any authentication artifacts, such as cached cookies, that the resource partner or Web server may have written to the client. In the case of a resource partner, it sends a cleanup request to any application Web servers that the client has used.

The sign-out cookie is always a session cookie. It is neither signed nor encrypted.


Controlling Access to Web-based Applications

Controlling Access to Web-based Applications

  • Claims-aware applications

  • Windows NT token-based applications


Claims-aware applications

Claims are statements (for example, name, identity, key, group, privilege, or capability) made about users — and understood by both partners in an Active Directory Federation Services (ADFS) federation — that are used for authorization purposes in an application. A claims-aware application is a Microsoft ASP.NET application that has been written using the ADFS library. This type of application is fully capable of using ADFS Claims to make authorization decisions directly. A claims-aware application accepts claims that the Federation Service sends in ADFS security tokens. For more information about how the Federation Service uses security tokens and claims, see Federation Service.

Claim mapping is the act of mapping, removing or filtering, or passing inbound claims into outbound claims. Claim mapping does not occur when claims are sent to an application. Instead, only the organization claims that are specified by the Federation Service administrator are sent to the application. (Organization claims are claims in intermediate or normalized form within an organization's namespace.)

By default, no organization claims that are marked as auditable are sent. All nonauditable claims are sent. Therefore, the Federation Service administrator will opt in for auditable claims to be sent to the application and will opt out for nonauditable claims.

The following list describes the organization claims that can be used by claims-aware applications:

  • Identity claims (UPN/e-mail/common name)

    When you configure the application, you specify which of these identity claims will be sent to the application. No mapping or filtering is performed.

  • Group claims

    When you configure the application, you specify the organization group claims that will be sent to the application. Organization group claims that are not designated to be sent to the application will be discarded.

  • Custom claims

    When you configure the application, you specify the organization custom claims that will be sent to the application. Organization custom claims that are not designated to be sent to the application will be discarded.

Claims-aware authorization

Claims-aware authorization consists of a Hypertext Transfer Protocol (HTTP) module and objects for querying the claims that are carried in the ADFS security token. Claims-aware authorization is supported only for Microsoft ASP.NET applications.

The HTTP module processes ADFS protocol messages based on configuration settings in the Web application's Web.config file. The Web pages perform authentication and authorization tasks. The HTTP module also authenticates cookies and obtains claims from the cookies.


Windows NT token-based applications

A Windows NT token–based application is an Internet Information Services (IIS) application that has been written to use traditional Windows native authorization mechanisms. This type of application is not prepared to consume Active Directory Federation Services (ADFS) Claims.

Windows NT token–based applications may be used only by Windows users from the local realm or any realm that is trusted by the local realm — that is, only by users who can log on to the computer with Windows NT token–based authentication techniques.

Note

In federation scenarios, this means that resource accounts may be required.

The ADFS security token that is sent to Windows NT token–based applications contains an e-mail claim for the user. It may also contain custom claims with the security IDs (SIDs) of the user account. The Web server generates a Windows impersonation-level access token. An impersonation-level access token captures the security information for a client process, thereby allowing a service to "impersonate" the client process in security operations.

For Windows NT token–based Web applications, the following process order determines how a Windows NT token is created:

  1. If the Security Assertion Markup Language (SAML) token contains SIDs in the SAML advice element, the SIDs are used to generate the Windows NT token.

  2. If the SAML token does not contain SIDs and instead contains a user principal name (UPN) identity claim, the UPN claim is used to generate the Windows NT token.

  3. If the SAML token does not contain SIDs and the UPN identity claim in the e-mail identity claim is present, it is interpreted as a UPN and it is used to generate the Windows NT token.

This behavior is irrespective of whether the UPN or e-mail identity claim is specified as the identity claim that is used to generate the Windows NT token when the trust policy entry for the Web application is created in the Federation Service.

Traditional Windows-based authorization

Support for converting an ADFS security token into an impersonation-level Windows NT access token requires a number of components:

  • Internet Server Application Programming Interface (ISAPI) extension: This component checks for ADFS cookies, checks for ADFS security tokens from the Federation Service, performs the appropriate protocol redirects, and writes the necessary Cookies used by ADFS to make ADFS work.

  • ADFS authentication package: The ADFS authentication package generates an impersonation-level access token, given a UPN for a domain account. The package requires that the caller have the Trusted Computing Base (TCB) privilege.

  • ADFS Web Agent tabs in IIS Manager: You can use the ADFS Web Agent tabs to administer policy and certificates for verifying the ADFS security token and cookies.

  • ADFS Web Agent Authentication Service: The ADFS Web Agent Authentication Service runs as Local System to generate a token by either using Service-for-User (S4U) or using the ADFS authentication package. However, the IIS application pool is not required to run as Local System. The ADFS Web Agent Authentication Service has interfaces that may be called only with local remote procedure call (LRPC), not remote procedure call (RPC). The service returns an impersonation-level Windows NT access token if it is given an ADFS security token or ADFS cookie.

  • ADFS Web Agent ISAPI Filter: Certain traditional IIS Web applications use an ISAPI filter that may modify incoming data, such as Uniform Resource Locators (URLs). If this is the case, the ADFS Web Agent ISAPI Filter must be enabled and configured as the highest priority filter. This filter is not enabled by default.


This content might have been updated. For the most recent version, see the Windows Server 2003 R2 TechCenter Web site

Understanding Claims

Understanding Claims

  • Claims

  • Claim mapping


Claims

Claims are statements (for example, name, identity, key, group, privilege, or capability) made about users — and understood by both partners in an Active Directory Federation Service (ADFS) federation — that are used for authorization purposes in an application.

The Federation Service brokers trust between many disparate entities. It is designed to allow the trusted exchange of arbitrary claims containing arbitrary values. These claims are then used by the receiving party to make authorization decisions.

There are three ways that claims flow through the Federation Service:

  • From the account store to the account Federation Service to the resource partner

  • From the account partner to the resource Federation Service to the application resource

  • From the account store to a Federation Service to the application resource

The Federation Service can be configured to act in all three of these roles. Therefore, one single Federation Service may facilitate all three communication flows.

There are three types of claims that are supported by the Federation Service: identity claims, group claims, and custom claims. The following table describes each of these claim types in more detail.

Claim type Description

Identity

UPN, e-mail, and common name in ADFS are referred to as identity claim types.

  • UPN — Indicates a Kerberos-style user principal name (UPN), for example: user@realm. Only one claim may be the UPN type. Even if multiple UPN values must be communicated, only one may be of the UPN type. Additional UPNs may be configured as custom claim types.

  • E-mail — Indicates RFC 2822–style e-mail names of the form user@domain. Only one claim may be the e-mail type. Even if multiple e-mail values must be communicated, only one may be of e-mail type. Additional e-mails may be configured as custom claim types.

  • Common name — Indicates an arbitrary string that is used for personalization. Examples include John Smith or Tailspin Toys Employee. Only one claim may have the common name type. It is important to note that there is no mechanism for guaranteeing the uniqueness of the common name claim. Therefore, use caution when using this claim type for authorization decisions.

Group

Indicates membership in a group or role. Administrators define individual claims that have the group type “Group claims.” For example, you might define the following set of group claims: [Developer, Tester, Program Manager]. Each group claim is a separate unit of administration for claim population and mapping. It is useful to think of the value of a group claim as a Boolean value indicating membership.

Custom

Indicates a claim that contains custom information about a user, for example, an employee ID number.

If more than one of the three identity claim types is present in a token, the identity claims are prioritized in the following order:

  1. UPN

  2. E-mail

  3. Common name

At least one of these identity claim types must be present for a token to be issued.

Auditing claims

Some group claims and custom claims may be designated as auditable. When auditing is enabled, the audit allows the name of the claim to be exposed in the security event log, but the value of the claim is omitted. An example of an auditable claim is Social Security Number. The claim name Social Security Number is exposed, but the actual number value that is stored in that claim is not exposed. The claim value is not audited when the claim is produced or mapped.

Note

Identity claim types are always auditable.

Claim producers and consumers

The way claims are used depends on the claim producer or consumer. Claims are either inbound or outbound. ADFS supports the following claim producers and consumers:

  • Active Directory account stores

  • ADAM account stores

  • Account partners

  • Resource partners

  • Claims-aware applications

  • Windows NT token–based applications

Active Directory account store

The Active Directory account store is a claim producer that represents authentication for the Federation Service. Specifically, the Federation Service may log on users from its domain, from domains that are directly trusted by its domain, from domains in the same forest as its domain, and from domains in forests that have forest trusts with the domain’s forest.

The Active Directory account store is available only if the Federation Service is joined to a domain.

ADAM account store

The ADAM account store is a claim producer that represents authentication for the Federation Service.

  • UPN claim: When you configure the ADAM account store, you can specify the LDAP user attribute, if any, containing the user’s UPN.

  • E-mail claim: When you configure the ADAM account store, you can specify the LDAP user attribute, if any, containing the user’s e-mail address.

  • Common name claim: When you configure the ADAM account store, you can specify the LDAP user attribute, if any, containing the user’s common name.

You must assign at least one identity claim type to the ADAM account store for the Federation Service to allow that store to be enabled.

  • Group claims: When you configure the ADAM account store, you can specify the LDAP user attribute containing the user’s LDAP groups or any other attribute that could function as a group, such as Title (if groups are based on job role), and then assign each possible LDAP group to an organization group.

  • Custom claims: When you configure the ADAM account store, you can specify the LDAP user attributes containing claim values. You then assign each attribute name to an organization custom claim.


Claim mapping

Active Directory Federation Services (ADFS) uses the WS-Federation Passive Requestor Protocol (WS-F PRP) that carries Claims in security tokens that are issued by the Federation Service. The claims are populated initially from Account stores, either Active Directory account stores or Active Directory Application Mode (ADAM) account stores.

In addition, the Federation Service can map those claims when they go out to a federation partner or when they come in from a federation partner. Claim mapping is the act of mapping, removing or filtering, or passing inbound claims into outbound claims. Claim mapping may be different for each federation partner. Defining the population and mapping of these claims is important for the configuration of the federation. Claim mappings use string comparisons that are case sensitive. The following illustration shows the claim mapping process.

The claim mapping process

Organization claim sets

All incoming claims are mapped into organization claims. Organization claims are claims in intermediate or normalized form within an organization's namespace. All internal Federation Service actions are performed on the organization claim set. Organizational claims are consumed by resource applications.

With organization claims, mappings do not have to be administered individually between any two organizations that need to communicate. Each organization defines a single mapping either to or from its organization claims. This reduces the administrative complexity of ADFS. For example, if the federation has:

  • x account partners

  • y resource applications

The federation has x + y claim mappings. This is reduced from a potential x × y claim mappings. As a concrete example, if a Federation Service has:

  • 3 account partners

  • 7 resource applications

The federation needs only 10 claim mappings, as compared to 21 claim mappings, when mapping occurs directly from the incoming claims to the outgoing claims.

E-mail

E-mail claim types always map to e-mail claim types. As part of this mapping, on the account Federation Service, the domain suffix may be mapped to a constant value. On the resource Federation Service, the domain suffix may be filtered against a list of constant values.

The following example describes an ADFS federation between two organizations, Tailspin Toys and Adventure Works. In this example, Tailspin Toys is the account partner, and Adventure Works is the resource partner.

  • Tailspin Toys, acting as an account Federation Service, maps the e-mail organization claim to the outgoing e-mail claim for Adventure Works. As part of that mapping, it maps all e-mail suffixes to tailspintoys.com. Given the organization e-mail claim (e-mail=jsmith@sales.tailspintoys.com), the outgoing e-mail claim is (e-mail=jsmith@tailspintoys.com).

  • Adventure Works, acting as a resource Federation Service, maps the incoming Tailspin Toys e-mail claim to the e-mail organization claim, and, as part of that mapping, it filters the suffix list against tailspintoys.com. Therefore, an incoming Tailspin Toys e-mail claim (email=jsmith@tailspintoys.com) is accepted, but an incoming Tailspin Toys e-mail claim (e-mail=jsmith@adventure-works.com) is rejected.

UPN

User principal name (UPN) claim types always map to UPN claim types. They are subject to suffix mappings and filtering in the same way that e-mail claims are. However, because Active Directory allows UPNs without the @ symbol, the account Federation Service attaches the @ symbol, followed by the suffix if there is a UPN suffix mapping defined. Otherwise, if any suffix is passed through, the Federation Service passes the UPN as is, without the @ symbol. On the resource side, if any UPN suffix is allowed, the UPN without the @ symbol is accepted. Otherwise, if a specific UPN suffix is allowed, the UPN without the @ symbol is rejected.

Common name

Common name claim types always map to common name claim types. They are subject to no additional rules.

Custom

Custom claim types always map to other custom claim types. For example, given an incoming claim set of (UPN, Custom=[EmployeeNumber, TaxPayerID]) and an organization claim set of (UPN, Custom=[Employee, SSN]), you can create mappings from EmployeeNumber to Employee and from TaxPayerID to SSN.

Group

Group claim types always map to other group claim types. For example, given an incoming claim set of (UPN, Group=[One, Two, Three]) and an organization claim set of (UPN, Group=[X,Y,Z]), you can create mappings from One to Y, from Two to X, and from Three to Z.

Group-to-UPN mapping

In addition to the standard mappings described in the previous sections, you may also use a special group-to-UPN claim mapping. The group-to-UPN claim mapping is supported only on the resource Federation Service when claims are incoming from an account partner. In this case, UPN claim types do not map to UPN claim types. Instead, you provide an ordered list of group-to-UPN claim mappings.

For example, the group-to-UPN list might be:

  1. Dev to developers@internal.tailspintoys.com

  2. Test to testers@internal.tailspintoys.com

  3. PM to progmgrs@internal.tailspintoys.com

Given an incoming claim set of (Common name=John Smith, Group=[Dev]) the organization claim set contains (Common name=John Smith, UPN=developers@internal.tailspintoys.com). Remember that the list is ordered. Therefore, a claim set of (Common name=John Smith, Group=[Dev,PM]) results in (Common name=John Smith, UPN=developers@internal.tailspintoys.com). Also, if the incoming claim has a UPN, the UPN is overwritten. This special mapping rule specifically supports group-based resource accounts that access legacy resources. The order of the group-to-UPN mappings is specified in the trust policy for the Federation Service.


Understanding Certificates Used by ADFS

Understanding Certificates Used by ADFS

  • Certificates used by federation servers

  • Certificates used by federation server proxies

  • Certificates used by Web servers


Certificates used by federation servers

Token-signing certificates

Each federation server uses a token-signing certificate to digitally sign all security tokens that it produces. Because each security token is digitally signed by the account partner, the resource partner can verify that the security token was in fact issued by the account partner and that it was not modified. This helps prevent attackers from forging or modifying security tokens to gain unauthorized access to resources.

Digital signatures on security tokens are also used within the account partner when more than one federation server is used. In this situation the digital signatures verify the origin and integrity of security tokens that are issued by other federation servers within the account partner. The digital signatures are verified with verification certificates.

Note

Each token-signing certificate contains a private key that is associated with the certificate.

Verification certificates

Verification certificates are used to verify that a security token was issued by a valid federation server and that it was not modified. Verification certificates are actually the token-signing certificates of other federation servers.

To verify that a security token was issued by a given federation server and not modified, the federation server must have a verification certificate for the federation server that issued the security token. For example, if federation server A issues a security token and sends the security token to federation server B, federation server B must have a verification certificate (federation server A's token-signing certificate) for federation server A.

Note

Unlike a token-signing certificate, a verification certificate does not contain the private key that is associated with the certificate.

SSL server authentication certificates

The federation server uses Secure Sockets Layer (SSL) server authentication certificates to secure Web services traffic for communication with Web clients or the federation server proxy. These certificates are requested and installed through the Internet Information Services (IIS) snap-in.

For more information about certificates, see Public Key Infrastructure for Windows Server 2003 on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=19936).


Certificates used by federation server proxies

SSL client authentication certificates

Each federation server proxy uses a Secure Sockets Layer (SSL) client authentication certificate to authenticate to the Federation Service. Any certificate with client authentication extended key usage (EKU) can be used as a federation server proxy client authentication certificate. A copy of the federation server proxy client authentication certificate is stored on both the federation server proxy and in the trust policy of the federation server. However, only the federation server proxy stores the private key that is associated with the federation server proxy client authentication certificate.

SSL server authentication certificates

The federation server proxy uses SSL server authentication certificates to secure Web services traffic for communication with Web clients. These certificates are requested and installed through the Internet Information Services (IIS) snap-in.

For more information about certificates, see Public Key Infrastructure for Windows Server 2003 on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=19936).


Certificates used by Web servers

Each Web server that hosts the ADFS Web Agent uses Secure Sockets Layer (SSL) server authentication certificates to securely communicate with Web clients. These certificates are requested and installed through the Internet Information Services (IIS) snap-in.

For more information about certificates, see Public Key Infrastructure for Windows Server 2003 on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=19936).


ADFS resources

You can find detailed documentation about Active Directory Federation Services (ADFS) on the Windows Server 2003 R2 TechCenter Web SiteWindows Server 2003 R2 TechCenter Web Site (http://go.microsoft.com/fwlink/?LinkId=45560).

For more information about ADFS or other ADFS-related information, see the following Web resources:

  • Automate Information Access with Identity Management on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=44188)

  • Web Services and Other Distributed Technologies Developer Center on the MSDN Web site (http://go.microsoft.com/fwlink/?LinkId=44189)

  • Web Services Protocol Workshops on the MSDN Web site (http://go.microsoft.com/fwlink/?LinkId=44190)

  • Web Services Specifications on the MSDN Web site (http://go.microsoft.com/fwlink/?LinkId=44191)

  • Web Services Interoperability Organization (WS-I) (http://go.microsoft.com/fwlink/?LinkId=34328)


ADFS troubleshooting

Setup issues

You receive an Internet Explorer error page with the message “This page cannot be displayed” “Cannot find server or DNS Error.”

There are a few things that can cause this problem:

  • Verify that Windows Firewall is turned off.

  • Verify that all the Federation Services and application Web servers have a server authentication certificate issued to the default Web site.

  • If there is an external account partner Federation Service Proxy involved, verify that the correct Federation Service host name was used during installation.

  • If you are using a Windows NT token-based application, verify that the Federation Service Uniform Resource Locator (URL) on the ADFS Web Agent tab of Web Sites Properties is configured correctly.

When you try to connect to the application, you get an Internet Explorer error page with the message “This page cannot be found” “HTTP Error 404 – File or directory not found.”

This issue might be caused by the following configuration problems:

  • Verify that the Web application is properly configured in Internet Information Services (IIS).

  • Verify that the Web application URL is properly named in the Active Directory Federation Services Snap-in.

  • Verify that Microsoft ASP.NET is installed on the application Web server and in the Federation Service.

  • If you are connecting to a Windows NT token–based application that uses ASP and you receive the 404 error after supplying your credentials, in the IIS Manager console tree, click the local computer, click Web Service Extensions, and then verify that Active Server Pages is set to Allowed.

After setting up a Windows NT token–based application, you attempt to connect to it but you are not prompted to choose a host realm and login credentials.

Verify that the virtual directory of the Windows NT token–based application is set up to use the Ifsext.dll Internet Server Application Programming Interface (ISAPI) extension.

Where are the ADFSSetup.log, ADFSOCM.log, and ADFSMSI.log files located?

They are located in %SYSTEMROOT%\.

Enable logging

Registry settings to enable logging on the account federation server

The account federation server uses an authentication package for mapping client certificates. To enable logging for the account federation server authentication package, perform the following tasks in order:

  1. If it is not already installed, install the Federation Service component of Active Directory Federation Services (ADFS).

  2. Set the following registry key: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\WebSso\Parameters]

    "DebugLevel"=dword:ffffffff

Registry settings to enable logging on the Web server for the:

ADFS Web Agent Authentication Package

The ADFS Web Agent authentication package is used by Windows NT token-based applications for generating tokens when Service-for-User (S4U) is not available.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\WebSso\Parameters]

"DebugLevel"=dword:ffffffff

ADFS Web Agent ISAPI Extension

The ADFS Web Agent ISAPI Extension handles the protocols that are used by ADFS to authenticate requests.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ADFS\WebServerAgent]

"DebugPrintLevel"=dword:ffffffff

ADFS Web Agent Authentication Service

The ADFS Web Agent Authentication Service validates incoming tokens and cookies.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IFSSVC\Parameters]

"DebugPrintLevel"=dword:ffffffff

Where are these logs located?

They are located in %SYSTEMDRIVE%\ADFS\logs.

Configuration issues

The following section covers some of the known issues with ADFS configuration.

Condition: server error

Error: The token request for application with URL https://... cannot be fulfilled because the URL does not identify any known trusting application

Solution: This error is returned by the resource Federation Service when the application URL does not identify any known application. Make sure that the application has been added to the trust policy for the Federation Service. For more information about how to do this, see Complete the Add Applications Wizard.

For a claims-aware application, verify that the return URL is typed correctly in the application’s web.config file and that it matches the application URL that is specified in the trust policy of the Federation Service.

For a Windows NT token-based application, verify that the return URL is typed correctly on the ADFS Web Agent tab of IIS and that it matches the application URL in the trust policy of the Federation Service.

Condition: validation error

Error: Validation of viewstate MAC failed. If this application is hosted by a Web farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm.

AutoGenerate cannot be used in a cluster. An unhandled exception occurred during the execution of the current Web request. Review the stack trace for more information about the error and where it originated in the code.

Or

Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Solution: Using a text editor, add the following setting to the Web.config file on the computer hosting either the Federation Service, Federation Service Proxy, or ADFS Web Agent that will be farmed:

<system.web>

<machineKey>

<machineKey validationKey="specify key for the appropriate algorithm"

decryptionKey="specify key"

validation="SHA1|MD5|3DES"/>

Or

Solution: Add the following element in the <system.web> section of the Web.config file on the computers hosting the Federation Service, Federation Service Proxy, or ADFS Web Agent that are set up in the farm:

<pages enableViewStateMac="false"/>

Condition: The account Federation Service is configured with the wrong cookie path.

Behavior: The Federation Service tries to authenticate the user each time, and no sign-on occurs. The event logs on the federation server show that the user has been authenticated successfully. However, the user never sees the login succeed.

Solution: To resolve this issue, correct the cookie path that is specified in the trust policy.

The cookie path must match a prefix of the request Uniform Resource Identifier (URI). It is important to note that some browsers treat "/path" or "/path1/samp" as a prefix match of "/path1/sample" while others do not allow matches that consume only parts of the individual words. These strict implementations accept only a subset of those matches that are allowed by the first implementation, for example, "/path1" or "/path1/sample".

Condition: A Windows NT token–based application cannot create a Windows access token for the user using the security token from the resource Federation Service as a result of one of the following conditions:

  • The only identity claim is the common name claim.

  • Services-for-User (S4U) fails because there is no resource account corresponding to the user principal name (UPN).

Behavior: The Web application returns an anonymous user token.

Condition: The UPN name for forms authentication with the user@domain NetBIOS name can be different from the UPN for integrated authentication and Transport Layer Security / Secure Sockets Layer (TLS/SSL) client authentication.

Behavior: In the case of integrated and TLS/SSL client authentication, the UPN is always the explicit UPN that is configured in Active Directory for the user object. However, for forms authentication, the UPN can be whatever the user enters in the user name field. Therefore, the UPN can be in the form:

username@netbiosname of domain or username@domaindnsname

Condition: The Web server application should not be configured with any URLs that are not Secure Hypertext Transfer Protocol (HTTPS).

Behavior: If the application contains links that are not HTTPS, the browser will not send the browser authentication cookies for those URLs. Single sign-on (SSO) is not possible because the ADFS cookies are secure cookies. In cases where the Web server is hosting only Windows NT token–based applications, the Web server will redirect to the HTTPS URL. Therefore, this behavior may not be noticed in most cases.

Condition: If the Federation Service or Web server is running on a domain controller, APPIDENTITY should be provided with the Write permission to the Temporary ASP.NET files directory.

(%windir%\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET files)

APPIDENTITY refers to the identity of the application pool with which the Federation Service or Federation Service Proxy is configured to run.

Condition: The Federation Service log file gets filled, and the Federation Service starts to fail all requests.

Solution: Increase the log size of the Federation Service log to something large, such as 16 megabytes (MB).

Condition: A forest trust is created between an extranet forest and an intranet forest, and a user has successfully authenticated as an intranet domain user to the extranet forest. However, the user cannot authenticate as a user from a domain that is a child domain of the intranet forest.

Cause: The Federation Service maintains a cache of forest trust information that is refreshed every eight hours.

Solution: Recycle the Federation Service application pool. This ensures that no authentication requests are dropped.

Duplicate group or custom claim names

As a best practice, do not create duplicate group or custom claims using case-insensitive names. For example, do not create an organization group claim using the names “Smith” and “smith”. If similar claim names are typed but they have case-sensitive differences, ADFS will treat those claims differently.

Active Directory node in the ADFS snap-in:

Extracting multiple Active Directory users to a single organizational group claim displays ‘*’ under the account store data field in the details pane.

Solution: This is by design. To verify the list of added Active Directory users, open the properties dialog box for the organizational group claim.

Account Partners node in the ADFS snap-in:

Object picker under the Groups tab in the UPN claim mapping dialog box returns a selected user’s UPN as NULL in the UPN edit field.

Solution: This is expected behavior. If the selected user is not assigned with a UPN explicitly, the object picker returns NULL, and the UPN field shows a blank value. Type the UPN manually in the field.

Applications node in the ADFS snap-in:

A common name claim for a Windows NT token-based application cannot be enabled in the Add Applications Wizard.

Solution: The user cannot enable a common name identity claim for a Windows NT token–based application in the Add Applications Wizard. This can be fixed in the properties dialog box for the common name identity claim in the Added Applications details pane.

ADAM issues

After user accounts are created in Active Directory Application Mode (ADAM) and the trust policy is configured with information about the ADAM store, the Federation Service is not able to validate users in the ADAM store.

Solution: Use caution while creating user accounts using the ADAM ADSI Edit snap-in. Always create a user account with a password. If you create a user account without a password, use ADSI Edit to reset the password for the user account. Most importantly, check the value of the msDS-UserAccountDisabled property of the user account. This property should not have the value True. The value should be either False or Not set. If the value of msDS-UserAccountDisabled property is True, it means that the user account is disabled and the Federation Service cannot validate credentials for this ADAM user account.

You have enabled an ADAM account store, but the Federation Service is not able to retrieve any claims.

If the Federation Service is running as Local System, you must add the machine account of the computer hosting the Federation Service to the Readers group in the ADAM store.

If the Federation Service is running as Network Service, you must add the domain account to the Readers group in the ADAM store.


Group Claim - General

Claim name — Provides a space for you to type the name of the organization group claim.

Use the Claim name field to communicate any authorization information that is not one of the other claim types. You must specify a fixed set of custom subtypes. For example, you can extend the Claim name by specifying details such as Employee Number, first name, and last name. Each custom subtype is a separate unit of administration for claim population and mapping. The value of a specific custom subtype claim is an arbitrary string that is exposed to the end application.

Limit the auditing of this claim — Specifies whether the claim name is to be audited or shared when the claim is produced or mapped. The audit indicates the name of the claim, but the value of the claim is omitted.

See Also

  • Claims
  • Claim mapping
  • Federation Service


Trust Policy - Advanced

Token lifetime (minutes) — Provides a space for you to type a new Security Assertion Markup Language (SAML) token lifetime setting. This is the lifetime for a Logon Accelerator token (LAT), also known as a cookie. You can click the up or down arrows to select a new setting. The Federation Service builds SAML tokens that are valid only for a certain period. The SAML token lifetime defines how long a security token is valid after it is created. The minimum value for this field is one minute. The default value is 600 minutes.

Trust policy refresh period (minutes) — Provides a space for you to type a new setting for the trust policy refresh period. You can also click the up or down arrows to select a new setting. The trust policy refresh period specifies how often the Federation Service checks whether the trust policy has changed and loads the trust policy if it is new. The minimum value for this field is five minutes. The default value is 60 minutes.

Windows domain trust cache refresh period (minutes) — Provides a space for you to type a new setting for the Windows domain trust cache refresh period. You can also click the up or down arrows to select a new setting. The refresh period of the security ID (SID) filtering cache specifies how often the Federation Service refreshes Windows trust information. The default value is 60 minutes.

See Also

  • Trust Policy
  • Federation Service


Trust Policy - General

Federation Service URI — Provides a space for you to type the Federation Service Uniform Resource Identifier (URI). A URI is a compact string of characters that is used to identify an abstract resource or physical resource. You can type any URI, including http URLs. Specifically, the URI that you configure here is the unique name or location for the realm that is hosted by this Federation Service (farm). A URI consists of a scheme name, followed by a colon, followed by some scheme-specific data. Uniform Resource Names (URNs) such as the one in the example on this property page, are valid URIs. All Uniform Resource Locators (URLs), such as http, ldap, gopher, and ftp, are also valid URIs. You can also use your own custom URI format, for example, fed://identity-sts.

Federation Service endpoint URL — Provides a space for you to type the endpoint URL of the Federation Service that partner organizations and applications will send requests and responses to.

Trust policy version — Displays the trust policy version number that uniquely identifies this trust policy. When notification of a trust policy file change is received, a newer version number tells other servers in the federation server farm that a new version of the trust policy must be loaded. The trust policy version number is incremented each time that the trust policy is updated.

See Also

  • Federation Service
  • Terminology used in ADFS
  • Trust Policy


ADAM - Settings

Server name or IP address — Provides a space for you to type the name or Internet Protocol (IP) address of the Active Directory Application Mode (ADAM) server.

Port number — Provides a space for you to type the TCP/IP port number for the account service. You can also click the up or down arrows to select a new setting. The default port number is 389.

Search base distinguished name (DN) — Provides a space for you to type the base distinguished name for the search. If you specify the base distinguished name, searches are performed on the specified subtree. Otherwise, the entire directory tree is searched.

Search timeout (in seconds) — Indicates the maximum time that the Federation Service waits for a response from the ADAM server before timing out the connection. The default search time-out period is five seconds.

User name attribute — Provides a space for you to log on the user to the ADAM store. Clients log onto the client logon Web page by providing a user name and password. Active Directory Federation Services (ADFS) attempts to search and bind to the object whose username attribute value matches the value that is provided by the user.

Enable Transport Layer Security (TLS) and Secure Socket Layer (SSL) protocols — Specifies whether TLS/SSL protocols are enabled or disabled. Select the check box to enable these protocols. Clear the check box to disable these protocols.

If TLS/SSL is enabled for the ADAM account store properties in the trust policy, the user credentials are protected.

Note

It is strongly recommended that the traffic between the Web server and federation server be protected by TLS/SSL or by other means, such as Internet Protocol security (IPsec).

See Also

  • Account stores
  • Trust Policy
  • Federation Service


Incoming Custom Claim Mapping - General

Incoming custom claim name — Provides a space for you to type the friendly name of the incoming custom claim.

Organization custom claim — Lists the available custom claims.

See Also

  • Claims
  • Claim mapping


Trust Policy - Transform Module

DLL file — Provides a space for you to type the name of the dynamic-link library (DLL) that implements the claim transform module. This must be a managed code assembly.

Browse — Click to find the location of the DLL of the claim transform module.

Class name — Provides a space for you to type the namespace-qualified class name that implements the claim transform interface.

See Also

  • Trust Policy


Application - General

Enabled — Specifies that the Windows NT token-based application is enabled. Clear the check box to disable the Windows NT token-based application.

Display name — Provides a space for you to type the friendly name of the Windows NT token-based application.

Application URL — Provides a space for you to type the Uniform Resource Locator (URL) for the application. The application URL is generally the root of the tree of Active Directory Federation Services (ADFS)–protected content. The configured value must match the return URL, which is configured in the ADFS Web Agent.

Public Key Infrastructure (PKI) — When this option is selected, the Federation Service uses its token-signing certificate to protect security tokens for this application.

Domain service account — When this option is selected, the Federation Service uses a Kerberos request to protect security tokens for this application. If you select this option, you must specify a service principal name (SPN) for the target service account.

For the ADFS Web Agent for claims-aware applications, the SPN must be registered for the application pool identity for the protected application, for example, “www/sales.treyresearch.net”.

For the ADFS Web Agent for Windows NT token–based applications, the SPN must be registered for the service account of the ADFS Web Agent Authentication Service (typically, the machine account, except in farmed scenarios), for example, “host/sales”.

See Also

  • Claims
  • Controlling Access to Web-based Applications
  • Federation Service


Common Name Claim Filtering - General

Enabled — Specifies whether this common name claim is enabled. Select the check box to enable the common name claim. Clear the check box to disable the common name claim.

Claim name — The friendly name of this claim.

Claim type —A common name is an arbitrary string that is used to personalize a claim. A security token may contain only one common name claim. It is important to note that there is no mechanism to guarantee the uniqueness of the common name claim or a particular partner’s authority for asserting a given common name. Therefore, use caution when using this claim type in authorization decisions.

Identity claim types include e-mail, user principal name (UPN), and common name. If more than one of these identity claim types are present in a token, the identity claims are populated in the following order:

  1. UPN

  2. E-mail

  3. Common name

Limit auditing — Specifies whether the claim value is audited or shared when the claim is produced or mapped.

See Also

  • Claims
  • Federation Service


Incoming UPN Claim Mapping - Groups

From incoming group — Provides a space for you to type the name of an incoming group to map to a single user principal name (UPN) value.

To user UPN — Provides a space for you to type the name of a single UPN value.

... button — Click to find a new group to map to a UPN.

Add — Click to add a new group to map to a UPN.

Move Up — Click to change the order of a group-to-UPN mapping. Select the group-to-UPN mapping to highlight it, and then click Move Up or Move Down.

Move Down — Click to change the order of a group-to-UPN map. Select the group-to-UPN mapping to highlight it, and then click Move Up or Move Down.

Remove — Click to delete a group-to-UPN mapping.

See Also

  • Claims
  • Claim mapping
  • Federation Service


Federation Service - Web Pages

Client logon page — Provides a space for you to type the name of the client logon Web page .aspx file. The default client logon page, Clientlogon.aspx, collects user name and password credentials, but it can be customized.

Account partner discovery page — Provides a space for you to type the name of the account partner discovery Web page .aspx file. The client account partner discovery page field interacts with a client to determine the client’s account partner membership. This page may be necessary in federation scenarios in which the Federation Service and the Federation Service Proxy are enabled as a resource Federation Service Proxy. The default client account partner discovery page is in the Federation Service Proxy. This can be customized to add branding or modify the Web page with a look and feel that is familiar to users. The default client account partner discovery page is Discoverclientrealm.aspx.

Client logoff page — Provides a space for you to type the name of the client logoff Web page .aspx file. The client logoff Web page presents a user interface (UI) when the local and foreign authentication states are deleted. The default Web page uses iframes so that resource partners can clean up state for their services. Your customers can customize this page and put their own branding and style on this page. The default client logoff Web page is Signout.aspx. The Signout.aspx Web page deletes the client's cached session cookies from the servers for single sign-off.

See Also

  • Federation Service
  • Federation Service Proxy
  • Federation scenarios
  • Cookies used by ADFS


Incoming Common Name Claim Mapping - General

Enabled — Specifies whether the incoming common name claim is enabled. Select the check box to enable the incoming common name claim. Clear the check box to disable the incoming common name claim.

See Also

  • Claims
  • Claim mapping


Federation Service - General

Trust policy file — Provides a space for you to type or browse to the path of the trust policy file for this Federation Service.

View — Click to view information about the token-signing certificate that is used with this Federation Service.

Select — Click to select the token-signing certificate that you want to use with this Federation Service.

See Also

  • Federation Service
  • Trust Policy
  • Certificates used by federation servers


Claim Extraction - General

Enabled — Specifies whether this identity claim is enabled. Select the check box to enable the identity claim. Clear the check box to disable the identity claim.

LDAP attribute — Provides a space for you to type the name of the Lightweight Directory Access Protocol (LDAP) from which you can populate this identity claim for users.

LDAP is an open network protocol standard that is designed to provide access to distributed directories. LDAP provides a mechanism for querying and modifying information that resides in a directory information tree.

See Also

  • Claims
  • Federation Service


Incoming E-Mail Claim Mapping - General

Enabled — Specifies whether the incoming e-mail claim is enabled. Select the check box to enable the incoming e-mail claim. Clear the check box to disable the incoming e-mail claim.

The e-mail claim type indicates RFC 2822–style e-mail names in the format user@domain. Only one claim can have the e-mail type. If multiple e-mail values must be communicated, only one claim can be of the e-mail type; additional e-mails can be configured as custom claim types.

Accept all domain suffixes — Specifies that all domains are accepted for mapping to the e-mail claim.

Accept some domain suffixes — Specifies that some domains are accepted for mapping to the e-mail claim. To add more domains to this list, type the appropriate domain suffixes.

See Also

  • Claims
  • Claim mapping
  • Federation Service


UPN Claim Filtering - General

Enabled — Specifies whether this user principal name (UPN) claim is enabled. Select the check box to enable the UPN name claim. Clear the check box to disable the UPN name claim.

Claim name — The friendly name of this claim.

Claim type —E-mail, UPN, and common name are referred to as identity claim types. If more than one of these claim types are present in a token, the identity claims are populated in the following order:

  1. UPN

  2. E-mail

  3. Common name

Limit auditing — Specifies whether the claim value is audited or shared when the claim is produced or mapped.

See Also

  • Claims
  • Claim mapping
  • Federation Service


Account Partner - Verification Certificates

Add — Click to add an account partner verification certificate.

Note

Your account partner must send you the verification certificate.

View — Click to view a description of the highlighted certificate in the list of verification certificates.

Remove — Click to delete the highlighted certificate from the list of verification certificates.

Note

You cannot delete the last certificate because at least one certificate must be present.

See Also

  • Claims
  • Certificates used by federation servers
  • Federation Service


Group Claim Filtering - General

Enabled — Specifies whether this group claim is enabled. Select the check box to enable the group claim. Clear the check box to disable the group claim.

Claim name — Displays the name of the group claim.

Claim type — Displays the name of the organization claim type.

Limit auditing — Displays whether the claim value is audited or shared when the claim is produced or mapped.

See Also

  • Claims
  • Claim mapping
  • Federation Service


Resource Partner - General

Enable this partner — Select this check box to enable the resource partner. Clear this check box to disable the resource partner. A resource partner uses security tokens that are produced by the account partner to make authorization decisions.

Display name — Provides a space for you to type the friendly name of the resource partner.

Federation Service URI — Provides a space for you to type the Uniform Resource Identifier (URI) of your resource partner, for example, urn:federation:northwindtraders. A URI is a compact string of characters that is used to identify an abstract resource or physical resource.

Federation Service endpoint URL — Provides a space for you to type the endpoint Uniform Resource Locator (URL) of the Federation Service that partner organizations and applications will send requests and responses to.

Use Windows trust relationship for this partner — Specifies whether or not the resource partner and the Federation Service are separated by a firewall and whether or not they need Windows security identifiers (SIDs).

Clear the check box if the resource partner does not require native Windows SIDs or it has an unfiltered network connection. An unfiltered network connection exists between you and your resource partner if devices such as firewalls are not filtering network traffic between you and your resource partner.

Select the check box if your resource partner requires native Windows SIDs or if it has a filtered network connection. A filtered network connection exists between your organization and your resource partner if devices such as firewalls are filtering network traffic between your organization and your resource partner.

Enable enhanced identity privacy — Specifies whether identity privacy is enabled or disabled. Select this check box to enable the discovery of the user portion of the identity claim that Active Directory Federation Services (ADFS) sends in security tokens.

See Also

  • Claims
  • Federation Service
  • Partner organizations


Account Partner - Windows Trust

Use Windows trust relationship — Specifies whether or not the account partner can use a Windows trust relationship.

Clear the check box if the account partner does not have a Windows trust relationship with this organization.

Note

Selecting this check box enables the Federated Web SSO with Forest Trust scenario.

All Active Directory domains and forests — Specifies that the users can belong to any Active Directory domain or forest that is trusted by this account partner.

Specified Active Directory domains and forests — Specifies that you want to choose which Active Directory domains or forests that are trusted by this account partner are allowed. Use the Add and Remove buttons to add or remove the name of a domain or forest that is trusted by this account partner.

See Also

  • Claims
  • Federation Service
  • Federation scenarios


Outgoing Custom Claim Mapping - General

Organization custom claims — Lists the available custom claims.

Outgoing custom claim name — Provides a space for you to type the friendly name of the outgoing custom claim.

See Also

  • Claims
  • Claim mapping


Custom Claim Filtering - General

Enabled — Specifies whether this custom claim is enabled. Select the check box to enable the custom claim. Clear the check box to disable the custom claim.

Claim name — The friendly name of this claim.

  1. Claim type —Displays the name of the organization claim type.

  2. Limit auditing — Specifies whether the claim value is audited or shared when the claim is produced or mapped.

See Also

  • Claims
  • Claim mapping
  • Federation Service


My Organization

The My Organization node in the console tree of the Active Directory Federation Services snap-in provides a user interface (UI) that you can use to configure trust policy settings in the Federation Service for which your organization has administrative control.

For more detailed information about each of the folders under My Organization, see the following topics:

  • Claims

  • Account stores

  • Controlling Access to Web-based Applications


Active Directory - General

Enable this account store — Select the check box to enable the Active Directory account store. Clear the check box to disable the Active Directory account store.

Account stores are used to log on a user with credentials and to extract claims for the user. A single Federation Service may have multiple account stores configured.

Display name: — Provides a space for you to type the friendly name of the Active Directory account store.

See Also

  • Account stores
  • Claims
  • Federation Service


Account Partner - Resource Accounts

In Active Directory Federation Services (ADFS), a resource account is a user account that is stored in one Active Directory forest (the resource partner forest) for the sole purpose of impersonating a user account that is actively used by an employee and stored in another Active Directory forest (the account partner forest).

Resource accounts must be created in the resource partner forest so that the employee, whose user account is located in the account partner forest, can access Web-based, Windows NT token-based applications through ADFS.

The Web resource on the resource side is protected with access control lists (ACLs) of user accounts or groups on the resource partner forest. The administrator has to create the resource accounts and add ACLs for any of the resource accounts to the resource.

To reduce administrative overhead, the resource-side administrator may configure one or more security groups, which are created in Active Directory, that will be used to map to incoming group claims from their account partners. A security group that is mapped to an incoming group claim that is used by ADFS is called a resource group.

You can configure resource groups using the following procedure.

To configure a resource group

  1. In the Active Directory Users and Computers snap-in on a domain controller in the resource partner forest, create a new security group.

  2. Assign the appropriate access to this security group from the Web resource that is protected by ADFS.

  3. In the ADFS snap-in, create a new group claim, and in the newly created claim's properties page, click the Resource Group tab. Click the … button to map the new security group in Active Directory to the new group claim. At this point the new security group is referred to as a "resource group."

  4. Under Federation Service\Trust Policy\Partner Organizations\Account Partners\<accountpartnername>\, create a new incoming group claim mapping to map the new group claim and its associated resource group to any incoming group claims coming from the account partner forest.

When you map an incoming group claim to a resource group, it is no longer necessary for an administrator in the resource partner forest to create a resource account for each user in the account partner forest who needs access to the Windows NT token–based application that is protected by ADFS.

By default, ADFS configures account partner properties so that a resource partner administrator can map incoming group claims to one or more resource groups. However, you can change this default behavior by selecting one of the following resource account options:

Resource accounts exist for all users — Specifies that a resource account is configured for each user from the account partner that needs access to the resource. In this case, incoming group claims are not mapped to resource groups even if resource groups are configured.

Resource accounts exist for some users (prefer resource account) — Specifies whether or not resource groups should be used for some user accounts. This means that some users may have individual resource accounts created, while others may have been configured to use resource groups. When this option is selected, ADFS first looks for resource accounts that match the UPN/E-mail claim that is specified in the incoming token. ADFS uses those resource accounts if they are found. Otherwise, if the token has a group claim that is mapped to a resource group, it uses the resource group.

Resource accounts exist for some users (prefer groups in token) —

This is the default setting. Specifies that ADFS can use its logic to determine if each incoming token should map to a resource group or if it should look for a resource account. When this option is selected, ADFS first looks in the token for incoming group claims that can be mapped to a resource group. If they are found, ADFS uses the resource group. If no such incoming group claim exists, ADFS looks for a resource account to use.

No resource accounts exist for this account partner — Specifies that one or more resource groups will be used for all users in this account partner. This means that every token that is issued from this account partner will be required to contain one or more group claims that map to one or more resource groups in the resource partner forest.

See Also

  • Partner organizations
  • Account stores


Trust Policy

The Trust Policy node in the Active Directory Federation Services snap-in represents the trust policy configuration information that is stored in the trust policy file. The trust policy file is stored in an .xml file format. It is created during setup of the first federation server in the federation server farm. The trust policy file path is configured in the local Web.config file. When possible, store the trust policy file on a network share so that it can be accessed by all of the computers in the federation server farm.

Note

It is strongly recommended that you use the Trust Policy node to edit trust policy configuration information. You cannot edit the policy information in the file manually.

See Also

  • Federation Service
  • ADFS server roles


Resource Partner - Advanced

Token lifetime (minutes) — Provides a space for you to type a new Security Assertion Markup Language (SAML) token lifetime setting. You can also click the up or down arrows to select a new setting. The Federation Service builds SAML tokens that are valid for only a certain period, the SAML token lifetime. The SAML token lifetime defines how long a security token is valid after it is created.

See Also

  • Federation Service


Trust Policy - FSP Certificates

Add — Click to add a certificate file to the list of Federation Service Proxy certificates. The Federation Service uses these certificates (using this trust policy) for authenticating federation server proxies.

View — Click to view the details of the highlighted certificate in the list of Federation Service Proxy certificates.

Remove — Click to delete the highlighted certificate from the list of Federation Service Proxy certificates.

See Also

  • Federation Service Proxy
  • Trust Policy
  • Certificates used by federation server proxies


Application - Advanced

Token lifetime (minutes) — Provides a space for you to type a new token lifetime setting. You can also click the up or down arrows to select a new setting. The Federation Service builds tokens that are valid only for a certain period, the token lifetime. The token lifetime defines how long a security token is valid after it is created.

See Also

  • Federation Service
  • Controlling Access to Web-based Applications


Account Partner - General

Enable this partner — Specifies whether the account partner is enabled or disabled.

An account partner is a federation partner that is trusted by the Federation Service to provide claims-based security tokens.

Display name — Provides a space for you to type the friendly name of the account partner.

Federation Service URI — Provides a space for you to type the Uniform Resource Identifier (URI) for the account partner. A URI is a compact string of characters used to identify an abstract or physical resource.

Federation Service endpoint URL — Provides a space for you to type the endpoint Uniform Resource Locator (URL) of the Federation Service that partner organizations and applications will send requests and responses to.

See Also

  • Claims
  • Federation Service
  • Partner organizations


Incoming Group Claim Mapping - General

Incoming group claim name — Provides a space for you to type the friendly name of the incoming group claim.

Organization group claim — Lists the available organization group claims.

See Also

  • Claims
  • Claim mapping
  • Federation Service


ADAM - General

Enable this account store — Specifies whether the Active Directory Application Mode (ADAM) account store is enabled or disabled. Select the check box to enable the ADAM account store. Clear the check box to disable the ADAM account store.

Account stores are used to log on a user with credentials and to extract security claims for the user.

Display name — Provides a space for you to type the friendly name of the ADAM account store.

URI — Provides a space for you to type the Uniform Resource Identifier (URI) for the ADAM account store. A URI is a compact string of characters that is used to identify an abstract resource or physical resource. A URI consists of a scheme name, followed by a colon, followed by some scheme-specific data. URLs such as http, ldap, gopher, and ftp are valid URIs, and Uniform Resource Names (URNs) such as urn:fed:companyname are also valid. You can also use your own custom URI format, for example, fed://identity-sts.

See Also

  • Account stores
  • Federation Service


Federation Service Proxy - Web Pages

Client logon page — Provides a space for you to type the name of the client logon Web page .aspx file. The default client logon page, Clientlogon.aspx, collects user name and password credentials, but it can be customized.

Account partner discovery page — Provides a space for you to type the name of the account partner discovery Web page .aspx file. The account partner discovery page interacts with clients to determine the client’s home realm. This page may be necessary for federation scenarios in which the Federation Service Proxy is enabled.

Client logoff page — Provides a space for you to type the name of the client account partner membership discovery Web page .aspx file. The default client logoff page uses iframes for foreign realms. This client logoff Web page is also used to present a user interface (UI) when local and foreign authentication states are deleted. Your customers can put their own branding and style on this page. The default client logoff Web page is Signout.aspx. The Web page deletes the client's cached cookies from the servers.

See Also

  • Federation Service
  • Federation Service Proxy


Outgoing Group Claim Mapping - General

Organization group claims: — Lists the available organization group claims.

Outgoing group claim name: — Provides a space for you to type the friendly name of the outgoing group claim.

See Also

  • Claims
  • Claim mapping
  • Federation Service


Default Web Site - ADFS Web Agent

Enable Active Directory Federation Services Web Agent — Specifies whether the Active Directory Federation Services (ADFS) Web Agent for Windows NT token-based applications is enabled. Select the check box to enable the ADFS Web Agent. Clear the check box to disable the ADFS Web Agent.

Cookie path — Provides a space for you to type a path to the location where the cookie is stored for Windows NT token–based application resources. If this information is not provided, the cookie path defaults to a path for the site: “/”.

Note

An incorrect cookie path can result in the browser going into an infinite redirection loop. This applies to both claims-based applications and Windows NT token–based applications.

Cookie domain — Provides a space for you to type the domain for which the cookie is valid.

Return Uniform Resource Locator (URL) — Provides a space for you to type the URL to which the client is to be returned after authentication is complete. Typically, this is the same page that the client originally tried to retrieve. In addition, this URL must match the Audience element of the token. Windows service checks for the Audience element.

See Also

  • ADFS Web Agent
  • Federation Service
  • Cookies used by ADFS
  • Windows NT token-based applications


Custom Claim - General

Claim name — Provides a space for you to type the name of the custom claim.

Use the Claim name field to communicate any authorization information that is not one of the other claim types. You must specify a fixed set of custom subtypes. For example, you can extend the Claim name by specifying details such as Employee Number, first name, and last name. Each custom subtype is a separate unit of administration for claim population and mapping. The value of a specific custom subtype claim is an arbitrary string that is exposed to the end application.

Limit the auditing of this claim — Specifies whether the claim name is to be audited or shared when the claim is produced or mapped. The audit indicates the name of the claim, but the value of the claim is omitted.

See Also

  • Claims
  • Claim mapping
  • Federation Service


Outgoing E-Mail Claim Mapping - General

Enabled — Specifies whether the outgoing e-mail claim is enabled. Select the check box to enable the claim. Clear the check box to disable the claim.

Send all domain suffixes — Specifies that all domain suffixes of e-mails will pass through without any modifications.

Replace all domain suffixes with — Specifies that all domain suffixes of e-mails will be replaced, and provides a space for you to type the replacement domain suffix.

See Also

  • Claims
  • Claim mapping
  • Federation Service


Trust Policy - Event Log

Error — Specifies whether to record events that are logged by significant problems to the event log.

Warning — Specifies whether to record events, which are not necessarily significant but that may cause future problems, to the event log.

Informational — Specifies whether to record informational events that are logged, such as redirects with protocol Uniform Resource Locators (URLs), token validations, or claim mappings.

Success audit — Specifies whether a security audit will be recorded for every successful authentication or trust policy change that is made to this Federation Service. All success records will be logged to the event log. In addition to this setting, the system auditing policy must be configured appropriately to accept the audits into the Security log.

Failure audit — Specifies whether a security audit will be recorded for every unsuccessful attempt to change the trust policy for this Federation Service. All audit failure records will be logged to the Security log.

Detailed success — Specifies whether a detailed security audit will be recorded for successful authentications.

Detailed failure — Specifies whether a detailed security audit will be recorded for failed authentications.

See Also

  • Trust Policy
  • Federation Service
  • Claim mapping
  • ADFS troubleshooting


E-mail Claim Filtering - General

Enabled — Specifies whether this e-mail claim is enabled. Select the check box to enable the e-mail claim. Clear the check box to disable the e-mail claim.

Claim name — The friendly name of this claim.

Claim type —E-mail, User Principal Name (UPN) and common name are referred to as identity claim types. If more than one of these claim types are present in a token, the identity claims are populated in the following order:

  1. UPN

  2. E-mail

  3. Common name

Limit auditing — Specifies whether the claim value is audited or shared when the claim is produced or mapped.

See Also

  • Claims
  • Claim mapping
  • Federation Service


Outgoing Common Name Claim Mapping - General

Enabled — Specifies whether the outgoing common name claim is enabled. Select the check box to enable the claim. Clear the check box to disable the claim.

See Also

  • Claims
  • Claim mapping


Application - Authentication Methods

Any - Specifies whether to accept all forms of authentication methods that are provided to this application.

Windows integrated authentication — Specifies whether to accept Windows-integrated authentication.

User name and password authentication — Specifies whether to accept the user name and password for authentication.

Certificate or TLS/SSL client authentication — Specifies whether to accept TLS/SSL client authentication.

See Also

  • Federation Service
  • Account stores


Create a New Organization Claim

Claim name — Provides a space for you to type the name of the new organization claim.

Use the Claim name field to communicate any authorization information that is not one of the other claim types. You must specify a fixed set of custom subtypes; for example, you can extend Claim name by specifying details such as employee number, first name, and last name. Each custom subtype is a separate unit of administration for claim population and mapping. The value of a specific custom subtype claim is an arbitrary string that is exposed to the end application.

Limit the auditing of this claim — Specifies whether the claim value is audited or shared when the claim is produced or mapped. The audit indicates the name of the claim, but the value of the claim is omitted. An example of a limited claim is Social Security Number.

Group claim - Select this option if you want this organization claim to be a group claim type.

Custom claim - Select this option if you want this organization claim to be a custom claim type.

See Also

  • Claims
  • Claim mapping
  • Federation Service


Outgoing UPN Claim Mapping - General

Enabled — Specifies whether the outgoing user principal name (UPN) claim is enabled. Select the check box to enable the claim. Clear the check box to disable the claim.

Send all domain suffixes — Specifies that all domain suffixes will pass through.

Replace all domain suffixes with — Specifies that all domain suffixes will be replaced, and provides a space for you to type the replacement domain suffix.

See Also

  • Claims
  • Claim mapping
  • Federation Service


Federation Service Proxy - General

Federation Service URL — Provides a space for you to type the Uniform Resource Locator (URL) for the Federation Service.

View — Click to view a list of certificates that are already configured. The local certificate should be used for Transport Layer Security / Secure Sockets Layer (TLS/SSL) client authentication.

Select — Click to select the certificate from a list of Federation Service Proxy certificates.

See Also

  • Federation Service
  • Federation Service Proxy
  • Certificates used by federation server proxies


Web Sites - ADFS Web Agent

Federation Service URL — Provides a space for you to type the Federation Service Uniform Resource Locator (URL). All Web sites and Web applications on this computer using Active Directory Federation Services (ADFS) use this URL. The URL of the Federation Service is needed so that you can query trust information. You can use Internet Information Services (IIS) Manager to manage settings and edit the Federation Service URL.

See Also

  • ADFS Web Agent
  • Federation Service


Outgoing E-Mail Claim Mapping - Settings

Enabled — Specifies whether the outgoing e-mail claim is enabled. Select the check box to enable the claim. Clear the check box to disable the claim.

Send all domain suffixes — Specifies that all domain suffixes will pass through.

Replace all domain suffixes with — Specifies that all domain suffixes will be replaced, and provides a space for you to type the replacement domain suffix.

See Also

  • Claims
  • Claim mapping
  • Identity claims


Trust Policy - Display Name

Display name for this trust policy — Provides a space for you to type the friendly name that is stored in the trust policy file.

Additional display names — Provides a space for you to add or remove additional display names that will be associated with this trust policy.

Add — Click to add the value that is typed in Additional display names to the list of display names that will be associated with this trust policy. These names will be used for functions such as account partner discovery.

Remove — Click to remove the highlighted display name that appears in the list.

See Also

  • Trust Policy


Incoming UPN Claim Mapping - General

Enabled — Specifies whether the account partner provides incoming user principal names (UPNs). Select the check box if the account partner provides UPNs. Clear the check box if the account partner does not provide UPNs.

Accept all domain suffixes — Specifies that all domain suffixes are accepted for mapping to the UPN claim.

Reject all domain suffixes — Specifies that all domain suffixes are rejected for mapping to the UPN claim.

Accept some domain suffixes — Specifies that some domains are accepted for mapping to the UPN claim. To add more domains to this list, type the appropriate domain suffixes.

See Also

  • Claims
  • Claim mapping
  • Federation Service


Federation Service - Troubleshooting

Error — Specifies whether to record events for significant problems to the debug log. Running the dbmon command outputs the debug log to the command prompt.

Warning — Specifies whether to record events, which are not necessarily significant but that may cause future problems, to the debug log.

Informational — Specifies whether to record informational events, such as redirects with protocol Uniform Resource Locators (URLs), token validations, or claim mappings, to the debug log.

Verbose — Specifies whether to record detailed information about events, such as sign-in requests, responses, token contents, Web method calls, and security identifier (SID) information to the debug log.

Audit success — Specifies whether a security audit is recorded for every successful user authentication or trust policy change that is made to this Federation Service. All success records are logged to the debug log file that is identified in the Log files directory box.

Audit failure — Specifies whether a security audit is recorded for every unsuccessful attempt to change the trust policy for this Federation Service. All audit failure records are logged to the debug log file that is identified in the Log files directory field.

Event log entries — Specifies whether to record all Active Directory Federation Services (ADFS) events to the debug log.

Cookie — Specifies whether to record cookies to the debug log.

Log files directory — Provides a space for you to type or browse to the location of the log file that is used to view all information that is generated by the selections that you make on this page.

See Also

  • Federation Service
  • Cookies used by ADFS
  • Claim mapping
  • Trust Policy
  • ADFS troubleshooting


Group Claim - Local Group

Map this claim to the following local resource group — Specifies that this group claim will map to the Active Directory group that is specified in the Group field.

Group — Provides a space for you to type or locate, using the … button, the Active Directory group that will map to this group claim.

See Also

  • Claims
  • Claim mapping


Trust Policy - Verification Certificates

Add — Click to add a certificate file to the list of certificates that are used to verify security tokens that are issued by the account partner. Select a DER-encoded, binary, X509 certificate file (.cer); a PKCS #7 certificate file (.p7b); or a Certificate store file (.sst) whose contents are of one of the following types:

  • A self-signed certificate. (A self-signed certificate is a root CA certificate.)

  • All the certificates in the certification path up to the root. (In this case, the end certificate is automatically detected.)

View — Click to view the details of the highlighted certificate in the list of verification certificates.

Remove — Click to delete the highlighted certificate from the list of verification certificates.

Note

The last certificate cannot be deleted because at least one certificate must be present for this Federation Service to validate tokens that are issued by the Federation Service itself.

See Also

  • Federation Service
  • Trust Policy
  • Certificates used by federation servers