Subject: When delegation is possible?
Author: SteveHB
In response to: What's difference between delegation and impersonation anyway?
Posted on: 06/09/2006 01:47:30 AM
For delegation to work, an entity must be able to authenticate against the remote server using the credentials of the client you wish to delegate. However, there are numerous factors that determine if delegation can occur, such as Internet Information Services (IIS) authentication schemes, network authentication protocol, and the operating systems of the machines involved.
Misuse of delegation could make the network vulnerable to sophisticated attacks using Trojan horse programs that impersonate incoming clients and use their credentials to gain access to network resources.
Authentication Schemes
On Windows 2000 or later version, the following authentication schemes impact delegation of impersonated clients as follows:
Anonymous -- NO
When using impersonation with an anonymous client, IIS impersonates the account specified by IIS for anonymous access. By default, this is a predifined service account named IUSR_<machinename> with a password controlled by IIS, which cannot be delegated.
Basic -- YES
When using Basic authentication, delegation is possible since IIS is able to get the client's username and password as well. Since the password is transmitted across the internet as a clear plain text. It is recommended the communication be made through a secure channel like SSL/TSL to prevent the client's credential from being exposed to the public.
Digest -- NO
Digest authentication does not permit delegation since IIS does not posses any credentials for the client with which to authenticate against the remote machine.
Integrated Windows Authentication -- YES/NO
When Internet Explorer attempts to access a protected resource, IIS sends two WWW-Authenticate headers to the browser, Negotiate and NTLM. The Negotiate header is only sent by IIS running on Windows 2000 or later. This header indicates that IIS supports the Negotiate protocol, which enables a negotiation to occur between Internet Explorer and IIS on whether to use Kerberos or NTLM authentication. IIS uses Kerberos if both the client (Internet Explorer 5.0 and later) and server (IIS 5.0 and later) are running Windows 2000 or later, and both are members of the same domain or trusted domains. Otherwise, the server defaults to using NTLM.
Since NTLM authenticates the user for IIS without providing the user's credentials to IIS, IIS cannot delegate that user's credentials to a remote machine.
When used in conjunction with Kerberos v5 authentication, IIS can delegate security credentials among computers running Windows 2000 or later that are trusted and configured for delegation.
Client Certificate Mapping -- YES/NO
Client Certificate Mapping supports delegation in some instances. That is, if you use IIS mapping (many-to-one) and the mapped account is identical (including password) to a local account on the remote machine, delegation is possible. In addition, delegation is possible if IIS maps the certificate to a domain account that has access to the remote machine. In both cases IIS stores credentials for the account in question.
However, if using Active Directory mapping (one-to-one), delegation is not possible. This is because Active Directory holds the certificate for each account, not IIS.
>
> On 06/09/2006 01:43:14 AM SteveHB wrote:
Impersonation enables an entity or subject to execute code and access resources in the context of an authenticated and authorized user, but only on the computer where subject is running. To access resources located on another computer on behalf of an impersonated user requires authentication delegation (or delegation for short). Delegation can be considered as a more powerful form of impersonation in that sense, as it enables impersonation across a network.
References:
