Update: The original question was for Windows Server 2008, but the solution is easier for Windows Server 2008 R2 and Windows Server 2012 (and Windows 7 and 8). You can add the user through the NTFS UI by typing it in directly. The name is in the format of IIS APPPOOL\{app pool name}. For example: IIS APPPOOL\DefaultAppPool.
IIS APPPOOL\{app pool name}
Note: Per comments below, there are two things to be aware of:
- Enter the string directly into the "Select User or Group" and not in the search field.
- In a domain environment you need to set the Location to your local computer first.
Reference to Microsoft Docs article: Application Pool Identities > Securing Resources
Original response: (for Windows Server 2008) This is a great feature, but as you mentioned it's not fully implemented yet. You can add the app pool identity from the command prompt with something like icacls, then you can manage it from the GUI. For example, run something like this from the command prompt:
icacls c:\inetpub\wwwroot /grant "IIS APPPOOL\DefaultAppPool":(OI)(CI)(RX)
Then, in Windows Explorer, go to the wwwroot folder and edit the security permissions. You will see what looks like a group (the group icon) called DefaultAppPool. You can now edit the permissions.
However, you don't need to use this at all. It's a bonus that you can use if you want. You can use the old way of creating a custom user per app pool and assigning the custom user to disk. That has full UI support.
This SID injection method is nice because it allows you to use a single user but fully isolate each site from each other without having to create unique users for each app pool. Pretty impressive, and it will be even better with UI support.
Note: If you are unable to find the application pool user, check to see if the Windows service called Application Host Helper Service is running. It's the service that maps application pool users to Windows accounts.
The standard behaviour in an AD domain is to automatically add the domain group "Domain Users" to the local group "Users" on each computer that is joined to the domain; this allows all members of "Domain Users" (which by default contains all user accounts in the domain) to log on to any computer in the domain.
If you have a non-standard setup which doesn't allow all users to log on to all computers, this can be due to two reasons: either your AD user accounts were removed from the "Domain Users" domain group, or that group is not member of the local "Users" group con your computers. You should check these two settings and fix them if they are not right.
Best Answer
You can configure autologon on a computer by computer basis by setting the following registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultUserName(E.g. DOMAIN\USERNAME)HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultPasswordPassword in plain textYou could configure this using Group Policy Preferences. However, there are two clear security risks - firstly, the plain text password and secondly, as have an automatic login you may aswell just let everyone have the passwords.
There are a couple of technical issues with sharing user accounts, such as user customisations, profiles etc. However, the biggest problem will be accountability.
To me, this feels like a classic case of using technology to solve a social issue. You need to go up your chain of command and design an Acceptable Use Policy that stipulates:
Every other company manages to get people to use their own user account and password, and you should be no different.