mobile logo

Resolving Permissions Problems for WordPress on IIS7

Solution:1

From the PHP manual on IIS7 installation (emphasis mine):

Impersonation and file system access

It is recommended to enable FastCGI impersonation in PHP when using IIS. This is controlled by the fastcgi.impersonate directive in php.ini file. When impersonation is enabled, PHP will perform all the file system operations on behalf of the user account that has been determined by IIS authentication. This ensures that even if the same PHP process is shared across different IIS web sites, the PHP scripts in those web sites will not be able to access each other’s files as long as different user accounts are used for IIS authentication on each web site.

For example IIS 7, in its default configuration, has anonymous authentication enabled with built-in user account IUSR used as a default identity. This means that in order for IIS to execute PHP scripts, it is necessary to grant IUSR account read permission on those scripts. If PHP applications need to perform write operations on certain files or write files into some folders then IUSR account should have write permission to those.

As discussed in the “Should I impersonate PHP via FastCGI?” question on ServerFault, there are security concerns if you would grant the anonymous user write access rights on your server. For instance, if you have also enabled the WebDAV module, anyone could write to your directories using this protocol!

Therefore my recommendations are:

  1. Ensure all your sites have their own unique Application Pool assigned.
  2. In the Advanced Settings under Processing Model for the application pool, set the built-in account as ApplicationPoolIdentity.
  3. Disable impersonation in php.ini with fastcgi.impersonate = 0, so PHP runs under the Application Pool Identity as set in IIS.
  4. Set read/write permissions on your folders using the automatically generated application pool user account (e.g. “IIS AppPool\MyAppPoolName”).

This way, all PHP scripts are ensured to run under a system account, tied to the Application Pool of the site (isolating it from other sites), and cannot accidentally get too public access via impersonation.

Solution:2

Correct me if I’m wrong but I believe the following configuration provides the same benefits, and also honors PHP’s desired setting of fastcgi.impersonate=1.

Steps 1,2 and 4 are the same – step 3 is different.

  1. Ensure each site has its own application pool (same as above)
  2. Under Advanced Settings > Processing Model > Application Pool Identity (same as above)
  3. IIS > Authentication > Anonymous Authentication > Application Pool Identity (not IUSR)
  4. Set read/write permissions using IIS AppPool\MyAppPoolName (same as above)

We do not grant IUSR or IIS_IUSRS access to the webroot. All permissions are assigned to IIS AppPool\MyAppPoolName