Partager via

Windows NT token-based applications

  • Article

Applies To: Windows Server 2003 R2

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.