You confused, you are mixing thing.
Let's state, that you are building a web application, that involves at lest two parties: a client, that is a web browser and a web server - let's assume you are using IIS. As I understood, you have a third party: a file server.
Now, you can set up IIS, to impersonate the user running the client browser (using NTLM or basic authentication - the exact scenario depends on the windows network you are in). But impersonation allows the working thread to access only local resources on the web server, but does not allow it to access resources (files) on the third party server (file server). To do that you need delegation (see the differences in detail:
http://msdn.microsoft.com/en-us/library/ff647248.aspx[
^]). But NTLM is not supporting this, neither is Basic authentication capable of giving you this by default.
You have several to get a token (
http://msdn.microsoft.com/en-us/library/ff647404.aspx#paght000023_delegation[
^]):
- Use Kerberos authentication and delegation. If you use Kerberos to authenticate your users, you can impersonate the original caller by using the techniques described in the sections "Impersonating the Original Caller" and "Impersonating the Original Caller Temporarily" and use Kerberos delegation to gain access to network resources. To do so:
If your application runs under the Network Service account, you need to configure your computer account in Active Directory to be trusted for delegation.
If your application runs under a custom domain account, you need to configure your domain account in Active Directory to be trusted for delegation. You must also register a service principal name in Active Directory to associate the domain account with the HTTP service on your Web server.
If you use domain accounts to run your Web application or the downstream service that you are accessing, you must also ensure that appropriate service principal names (SPNs) are created in Active Directory for those accounts. - Call LogonUser and request an Interactive logon session. An interactive logon session has network credentials that allow you to authenticate against network servers. Use this approach when you cannot use Kerberos authentication to authenticate your users, and when you cannot use protocol transition.
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. - Use protocol transition. With this approach, you use a non-Kerberos authentication mechanism to authenticate your users, and then use the new WindowsIdentity constructor to obtain a Windows token for the user on the server. Use this approach when you cannot use Kerberos authentication to authenticate your users, for example because they connect to your application over the Internet, but your users do have Windows domain accounts. 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.
- Use basic authentication and impersonation. With basic authentication, the user name and password of the user are available in clear text on the server. When IIS authenticates a caller by using basic authentication, it creates a token that contains these credentials. The token can be used for network access. As result, if you configure your application to impersonate the original caller by using the <identity> element or impersonate programmatically by using WindowsIdentity.Impersonate, you can access network resources while impersonating.
Use basic authentication if you cannot use Kerberos authentication and delegation, and you cannot use LogonUser or 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 authenticationwhich does not allow access to network resources with an impersonated identity. If you cannot use the new WindowsIdentity constructor because you are not running on a Windows Server 2003 in a Windows 2003 domain, and you do not have access to the users password to call LogonUser, then basic authentication provides a solution. However, with basic authentication, the user's credentials pass through the network in clear text. Therefore, you should be sure that all network connections are secured with SSL or IPSEC.