• “Delegation allows you to use an impersonation token to access network resources.”

This official statement directly links delegation and impersonation and implies that you cannot use IIS to serve resources that are not on the same machine as IIS without delegation.

• “By default, ASP.NET does not use impersonation, and your code runs using the ASP.NET application’s process identity. On the Microsoft® Windows Server™ 2003 operating system, ASP.NET applications run in an Internet Information Services (IIS) 6.0 application pool by default.”

This is this first of many statements that distinguish Windows Server 2003 from previous platforms capable of running IIS.

• “If you need to impersonate at the method level to perform specific operations or access particular resources, then you can use programmatic impersonation by using the WindowsIdentity.Impersonate method.”

This statement introduces WindowsIdentity.Impersonate and later it will compared to the Win32 API call, LogonUser().

• “If your application authenticates callers by using custom authentication, such as forms authentication, then you cannot impersonate the original caller through ASP.NET configuration. Instead you must call the Impersonate method of a WindowsIdentity object that you create for the original caller.”

This statement is a rare example of documenting the advantage WindowsIdentity.Impersonate() has over declaring <identity /> in web.config.

• “If you are impersonating a local account, you must use LogonUser.”

The LogonUser API apparently is only available on Windows 2000 Server or Windows Server 2003.

• “If your application has access to the user name and password of the caller (perhaps through a logon Web page) and needs to access local resources, you should use the Win32 LogonUser API. This is preferable to using the WindowsIdentity constructor because you do not need to grant the ASP.NET process account the ‘Act as part of the operating system’ privilege.”

This shows the advantage LogonUser has over the WindowsIdentity object and reading carefully to this point should clearly sketch out a relationship among the <identity /> declaration, WindowsIdentity and LogonUser. This relationship is very complex and should be studied carefully.

• “In ASP.NET 2.0 applications, you can now change the default behavior to flow the impersonation token to newly created threads…”

This may be an indirect reference to the <alwaysFlowImpersonationPolicy /> element in addition to the AspCompat="true" setting referred to later in the prose hyperlink.

• “The token can represent the authenticated user, if IIS is configured for Integrated Windows authentication, or another form of authentication such as basic, digest, or client certificate authentication. The token represents the anonymous user identity (IUSR_MACHINENAME) if IIS is configured to enable anonymous access.”

This describes IIS behavior when <authentication mode="Windows" /> and <identity impersonate="true" /> is declared in web.config.

• “Whether you can access local resources or network resources depends on the logon session type that you request (you specify the logon session type in the third argument of LogonUser).”

When LogonSessionType.Interactive (=2) is sent to LogonUser, IIS can, “…access remote resources, request an interactive logon session. This results in a logon session that has network credentials. The user account passed to logon user must be granted the Log on locally user right.”

• “When you request an interactive logon, LogonUser returns a primary token that allows you to create processes while impersonating. When you request a network logon, LogonUser returns an impersonation token that can be used to access local resources, but not to create processes.”

The LogonSessionType enum is defined in the subsequent code sample.

• “When you use the LogonUser API for impersonation on Windows Server 2003, you do not need to grant your application's process identity the Act as part of the operating system user right.”

*“…if you are running on Windows Server 2003 with IIS 6.0 configured to run in worker isolation mode (the default), you can avoid impersonation by configuring your ASP.NET application to run in a custom application pool that runs under a specific domain identity.”

• “To obtain an impersonation token so that you can access network resources, you have a number of options.”

The options: Kerberos authentication and delegation, LogonUser and an Interactive logon session, protocol transition and basic authentication and impersonation.

• “Note that you must have access to both the user name and password to call LogonUser. You can only use the token to access network resources over a single hop, whereas Kerberos delegation allows the impersonated identity to flow across multiple tiers.”

• For protocol transition: “To get a delegate-level token with this approach, you must be running on a Windows Server 2003 in a Windows 2003 domain and you need to configure your computer or process account in Active Directory as trusted for delegation and protocol transition.”

• “…For example, if you configure IIS to use integrated Windows authentication, it will use Kerberos authentication if possible, but otherwise default to NTLM authentication—which does not allow access to network resources with an impersonated identity.”

• “Windows Server 2003 introduces constrained delegation. …With constrained delegation on Windows Server 2003, administrators can specify exactly which services on which servers a computer can access by using the impersonated user's security context.”