例：<identity impersonate="tr" userName="AD\name" password="word"/>
需要给文件夹C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files 添加用户"AD\name"的权限
参考1：在Web.Config中有一个
<identity
>
元素，可以使其impersonate属性为tr来设置本应用程序的身份，从而达到扮演其他账号身份的目的。而具体的“扮演”有两种方式：
（1）、
<identity impersonate="tr" />
这种方式的话ASP.NET进程将扮演http/https请求者的身份。而具体是什么帐号，就跟IIS的安全性设定有关了：
如果IIS允许匿名访问，那么被扮演的将是Iuser_Machine帐号（因为默认的匿名访问账号是Iuser_Machine，当然如果修改过，那被扮演的就是修改过的帐号）。
如果IIS不允许匿名访问，那么浏览器请求者的身份肯定是一个Windows帐号，这个帐号就是被扮演的对象。
（2）、<identity impersonate="
tr
" userName="Account" password="Password"/>
这种方式就直接设置所扮演的固定用户身份
第（2）种扮演方法将把password明文的写在Web.Config里，很不安全
PS1：微软
不推荐
使用扮演，无论扮演哪个帐号，一方面是安全性问题（被扮演的帐号可能有一些程序并不需要的多余权限，可能被利用），另一方面是可伸缩性问题（Scalability），因为在访问SQL Server等资源时，无法利用连接池等手段。
PS2：在\%windows%\Microsoft.NET\Framework\Version\Config目录中找到machine.config文件，其中有一个<processModel
>
的tag:
<processModel enable="
tr
" ... userName="machine" password="AutoGenerate" ... />
其中的userName="machine"就是指定使用本机ASPNET帐号（.\ASPNET）作为ASP.NET工作进程的默认账号。
这个默认帐号是可以修改的，如果开发人员将userName修改为一个域用户帐号：
<system.web>
<processModel enable="
tr
" userName="domain\user" password="password"/>
</system.web>
那么ASP.NET工作进程的身份就变成了
domain\user
。只要这个域用户帐号拥有需要的权限，那么machine.config所在机器上所有ASP.NET程序都可以访问域中其他服务器的资源，包括存取用网络共享路径指定的文件。
如果指定userName="system"，那么ASP.NET程序将以LocalSystem身份运行，可以存取几乎所有本地资源，因此非常危险！
无论machine.config指定哪个默认帐号，这个默认帐号都可以被应用程序的web.config设置的Impersonation覆盖，即特定应用程序可以以其他身份运行。
参考2：如果你的Web服务器上有多个ASP.NET应用程序，或者你的ASP.NET应用程序需要更高的权限以执行特殊的操作，那么可以为程序设置一个单独的账户。
<?xml version="1.0"?>
<configuration>
<system.web>
<identity impersonate="
tr
"
userName="域\机器名"
password="密码"
/>
</system.web>
</configuration>
在这里，你可以用明文设置用户名和密码，对此就不做过多解释了。需要特别注意的是，你设置的账户需要对以下目录拥有权限：
· ASP.NET临时文件夹。这是ASP.NET动态编译的位置，需要有读写权限。
· 全局程序集缓存（%Windir%\assembly）。这是全局程序集缓存，需要有读取权限。
注意：如果正在运行Windows Server 2003，其中的IIS 6.0配置为运行在辅助进程隔离模式下（默认情况），则可通过将ASP.NET应用程序配置为在自定义应用程序池（在特定的域标识下运行）中运行，然后使用指定的域标识访问资源而无需使用模拟。
