Mysterious Application pool identity resolution (Program pool account) _win server in IIS 7.5

IIS7.5 (win7,win2008 sp2,win2008 R2 only), the running account for the application pool, in addition to the three basic types specified as Localservice,localsystem,networkservice, There is also a new type of applicationpoolidentify

Win7 's official help says so: applicationpoolidentity– By default, the application pool identity account is selected. The application pool identity account is dynamically created when the application pool is started, so this account is the safest for your application.
That is to say, "applicationpoolidentity" account is the system dynamically created "virtual" account (said it is virtual, because in the user management can not see the user or user group, the command line to enter net user can not be displayed, but the account is also true)
How do I verify that the account does exist? Open Task Manager and observe:

W3wp.exe is the IIS process, highlighted in the figure above indicates that the IIS process is running with an account luckty (note that here Luckty is the name of the application pool in the diagram above)
Well, what's the use of this?

Let's do a test, like we create a new site in IIS, the home directory is set to C:\2\, the application pool specifies the luckty in the diagram
Suppose we write this line of code in the Default.aspx.cs of the site:

File.appendalltext ("C:\\testdir\\1.txt", DateTime.Now.ToString ());

The premise is that C disk must first build a directory TestDir, and in addition to Administrator,system retain full Control, other account permissions are deleted
After running, an exception is prompted: Access to the path "C:\TestDir\1.txt" is denied.

The reason for this is obvious: the site runs with a virtual account that corresponds to the application pool (luckty), and the virtual account does not have C:\TestDir access rights
This situation is very common in the Web server (IIS6) security configuration, such as we upload the image directory, often placed outside the home directory, while in the form of a virtual directory under the site, in addition to IIS6 in the directory do not specify any execution rights, so even if someone illegally uploaded the Asp/aspx trojan up, It's not going to work. Back to the point, to let that line of test code normal operation, the solution is very simple, the virtual account permissions to join the folder security permissions can, but the problem is: This virtual account we are not visible, if you directly add a user named Luckty to the folder security account, It doesn't make sense. (prompted not to find the Luckty user), that the virtual account name is not "Luckty"

Key: Manually Enter the IIS Apppool\luckty (that is, the IIS apppool\ application pool name), and make sure that this time OK.

Of course, in addition to using the "IIS apppool\ application pool name", there is a special user group authenticated users within Windows, which can also be added to the TestDir security account, but no one feels "IIS Apppool\ Application pool name "comes in precise.

Conclusion: IIS7.5 Virtual account design is really good, think of the traditional IIS6, in order to the same server on each site separate permissions (to prevent Trojan trouble), had to create a pile of iuser_xxx,iwam_xxx account number and specify the password, and then a site distribution past, exhausted people! Virtual account design makes this kind of management much easier, do not worry about passwords too simple or outdated problems. So, still waiting for what, hurriedly upgrade to win7/win2008 R2 bar!