Delegated Authentication and Trust Relationships
Updated: April 11, 2013
Applies To: Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Vista
This reference topic describes the role of trust relationships in the authentication process.
Delegated authentication occurs when a network service accepts a request from a user and assumes that user’s identity in order to initiate a new connection to a second network service. To enable delegated authentication, you must establish front-end or first-tier servers, such as web servers, that are responsible for handling client requests, and back-end or n-tier servers, such as large databases, that are responsible for storing information. You can delegate the right to enable delegated authentication to users in your organization to reduce the administrative load on your administrators.
By establishing a service or computer as trusted for delegation, you enable that service or computer to complete delegated authentication, receive a ticket for the user who is making the request, and then access information for that user. This model restricts data access on back-end servers just to those users or services that present credentials with the proper access control tokens. In addition, it allows for access auditing of those back-end resources. By requiring that all data be accessed by means of credentials that are delegated to the server for use on the client’s behalf, you ensure that the server cannot be compromised and then used to gain access to sensitive information stored on other servers.
Delegated authentication is useful for multitier applications that are designed to use single sign-on capabilities across multiple computers. For example, domain controllers are automatically trusted for delegation. If this property is disabled on a domain controller, the Message Queuing service cannot run. Also, if you enable the Encrypting File System on a file server, the server must be trusted for delegation in order to store encrypted files on behalf of users. Delegated authentication is also useful on applications where Internet Information Services (IIS) supports a web interface to a database running on another computer, such as Outlook Web Access in Exchange, or Web Enrollment Support pages for an enterprise certification authority, if the pages are installed on a separate web server.
Authentication in trust relationships
Most organizations that have more than one domain have a legitimate need for users to access shared resources located in a different domain. Controlling this access requires that users in one domain can also be authenticated and authorized to use resources in another domain. To provide authentication and authorization capabilities between clients and servers in different domains, there must be a trust between the two domains. Trusts are the underlying technology by which secured Active Directory communications occur and are an integral security component of the Windows Server network architecture.
Trusts depend on the NTLM and Kerberos authentication protocols and on Windows-based authorization and access control mechanisms to help provide a secured communications infrastructure across Active Directory domains and forests.
When a trust exists between two domains, the authentication mechanisms for each domain trust the authentications coming from the other domain. Trusts help provide for controlled access to shared resources in a resource domain (the trusting domain) by verifying that incoming authentication requests come from a trusted authority (the trusted domain). In this way, trusts act as bridges that allow only validated authentication requests to travel between domains.
How a specific trust passes authentication requests depends on how it is configured; trust relationships can be one-way, providing access from the trusted domain to resources in the trusting domain, or two-way, providing access from each domain to resources in the other domain. Trusts are also either nontransitive, in which case trust exists only between the two trust partner domains, or transitive, in which case trust automatically extends to any other domains that either of the partners trusts.
In some cases, trust relationships are automatically established when domains are created; in other cases, administrators must choose a type of trust and explicitly establish the appropriate relationships. The specific types of trusts used and the structure of the resulting trust relationships in a given trust implementation depend on such factors as how Active Directory is organized, and whether different versions of Windows coexist on the network.
Groups with universal scope can consolidate a number of accounts and groups that span domains. Members of Universal groups can have the following as their members:
Accounts from any domain within the forest in which this Universal group resides.
Global groups from any domain within the forest in which this Universal group resides.
Universal groups from any domain within the forest in which this Universal group resides.
For information about understanding this group scope, see Understanding Groups.
For information about how a trust works, see How Domain and Forest Trusts Work.
Protocol transition
Protocol transition assists application designers by enabling applications to support different authentication mechanisms at the user authentication tier and by switching to the Kerberos protocol for security features, such as mutual authentication and constrained delegation, in the subsequent application tiers.
The protocol transition extension in Windows allows a service that uses the Kerberos protocol to obtain a Kerberos service ticket on behalf of a Kerberos principal to the service without requiring the principal to initially authenticate to the Kerberos Key Distribution Center (KDC) with a credential.
For more information about protocol transition, see Kerberos Protocol Transition and Constrained Delegation.
Constrained delegation
Constrained delegation gives administrators the ability to specify and enforce application trust boundaries by limiting the scope where application services can act on a user’s behalf. You can specify particular services from which a computer that is trusted for delegation can request resources. The flexibility to constrain authorization rights for services helps improve application security design by reducing the opportunities for compromise by untrusted services.
The constrained delegation extension in Windows allows a service to obtain service tickets (under the delegated user’s identity) to a subset of other services after it has been presented with a service ticket that is obtained either through the TGS_REQ protocol, as defined in IETF RFC 4120, or in the protocol transition extension.
You can also specify that the computer trusted for delegation can request resources for all services. This full delegation might not fit into your security model because by permitting all services for delegated authentication you run the risk of including untrusted services.
For more information about constrained delegation, see Kerberos Protocol Transition and Constrained Delegation.