When a user requests information in a web page from a browser, more than one application or server may be involved. It may not be possible for the first server receiving the request to provide all details for the page requested. That first server, for example, may have to seek some information from a database on a second server.
Any dependency pattern of this kind then has implications for the process of Kerberos authentication. A Kerberos requirement is that at each stage of the requesting process, the parties involved have to be able to authenticate with each other. In practical terms, without use of a “shortcut” such as delegation, this could be very difficult to achieve.
For example, the original client may have no knowledge at all of any secondary stages in the request process: it just knows that it is supposed to get information from the first server it approaches, and relies on a single request (for example, for a web page).
Theoretically, one approach might be for the client to have to directly and separately authenticate with every information source: but that approach is clearly impractical and may be impossible.
In order to deal with the problems involved when multiple points of authentication of this kind may be needed, Active Directory allows you to establish a form of trust between clients and services. What this means is that a client may be prepared to permit one or more services to act on its behalf to establish authentication. There are configuration options on each account which handle permissions of this kind, and which can allow for a form of “delegated identity”.
A client can specify that other services can act on its behalf, as its “delegate” in establishing authentication. It may do this in a general sense with a setting saying the client’s identity may be delegated -- that is, generally, other services may “impersonate” it for authentication purposes. This is known as “unconstrained” delegation.
In some circumstances, however, the client can set more refined limits on delegation, and can specify a list of those services that it allows to act on its behalf in the course of authentication processes, thereby establishing that those not specified are not given such permission.
The limits that can be configured for delegation now involve two or three basic configuration options, varying with the domain functional level:
For Windows Server 2003 and higher domain functional levels:
For the last of these, further configuration permits a selection of Service Principal Names (SPNs) for the services for which delegation is allowed.
In this form of delegation, known as Unconstrained delegation, a client which has established its identity can transmit that identity to other entities, asking them to act on its behalf in the authentication process.
As far as the Active Directory domain controller is concerned, each server which has received such a delegation from a client is assumed to be the client, because it can present the client’s Ticket Granting Ticket, or TGT. At the authentication level, the server is indistinguishable from the client itself.
Unconstrained delegation of this kind can imply multiple security risks and the possibility of unlimited “spoofing” of the client if a server which acts as a delegate and holds a TGT falls vulnerable to a security attack.
Kerberos Delegation extensions introduced with Windows Server 2003 and higher now make it feasible to avoid these risks, by choosing the appropriate domain functional level and Single Sign-on for Java supports the new “Constrained” form of delegation as an additional option, known as the S4U2Proxy extension.
© ALL RIGHTS RESERVED. Feedback 이용 약관 개인정보 보호정책 Cookie Preference Center
