WordPress file and directory security for IIS 7.0 and greater

It seems when we setup a new WordPress site on IIS (for whatever reason) the question always arises: “What is the directory and file security again?”.  We haven’t pulled the actual metrics, but we suspect this is one of the top 100 most asked questions of all times.

To help our own rather leaky memories, we are putting together this blog entry on our own internal best practices.  Hopefully it helps you as well!

 

Our Best Practices Overview

  • Modify level security is only allowed on .\[WordPress]\wp-content\uploads
  • All other directories are read only
    Why?  This helps prevents malware from infecting your site.
  • During updates (plugin or WordPress itself), the entire WordPress site is set for Modify permissions.
    Important:  Manual updates (XCOPY) are safer but not necessarily easier.  That being said, if you are already on the box setting permissions, you are already in position for an XCOPY update!

 

Initial Setup Details

  1. At the WordPress root directory (.\[WordPress])
  1. Remove all inheritance from the parent objects
    Why?  This prevents the parent directory objects from changing your security without you knowing about it!
  2. Replace all child object permissions with inheritable permissions from your WordPress root directory
    Why?  This guarantees that all WordPress directories get your explicit permissions!
  3. Grant the user IUSR the following permissions: Read & Execute, List folder contents, Read
  4. Grant the group IIS_IUSRS the following permissions: Read & Execute, List folder contents, Read
  5. Grant the group Administrators the following permissions: Full control
  6. Recommended:  Remove the group Users (I.E. grant the Users group no rights to the WordPress directory)
  • At the WordPress upload directory (.\[WordPress]\wp-content\uploads)
    1. Remove all inheritance from the parent objects
      Why?  This configures your upload directory for specific permissions to allow publishing of content!
    2. Replace all child object permissions with inheritable permissions from your \uploads directory
    3. Grant the user IUSR the following permissions: Modify, Read & Execute, List folder contents, Read, Write
    4. Grant the group IIS_IUSRS the following permissions: Read & Execute, List folder contents, Read
    5. Grant the group Administrators the following permissions: Full control
    6. Recommended:  Remove the group Users (I.E. grant the Users group no rights to the \uploads directory)

     

    Update Time Details
    When it becomes time to update your WordPress site, perform the following steps:

    1. At the WordPress root directory (.\[WordPress])
    1. Grant the user IUSR the following permissions: Modify
      Why?  Permissions inheritance will automatically set all WordPress directories to allow modification by the IUSR account.  This will allow updates to be performed

    Important: Be sure to remove both the Modify and Write permissions from IUSR when you are done with your updates!

    Unable to logon due to SQM in the default profile

    We here at ArmgaSys have started to see a high incident rate of User Profile loading failures.  These failures have different symptoms, but exactly the same root cause.

     

    Symptom #1:  The never ending logon
    This symptom is classically described as:

    1. You sit down in front of a PC you have logged into every day since you started work
    2. You enter your user name and password
    3. You are greeted by the “Welcome” screen
    4. You watch the “Welcome” screen spinner for hours…. and hours… and hours….

    Symptom #2:  New profiles can’t be created
    This symptom is classically described as:

    1. You have called your client services folks over because of the never ending logon
    2. Your client service guy (or gal) logs onto your PC with their administrative account
    3. They receive the always entertaining “The User Profile Service service failed the logon.  User profile cannot be loaded”
      image

     

    Symptom #3: The event log
    Upon reviewing the PC’s event log (which any good Client Service team will do) reveals:

    Event 1509, User Profile General
    WIndows cannot copy file \Users\Default\AppData\Local\…\sqm-data[SEQUENCE].sql to location [A profile location goes here]
    This error may be caused by network problems or insufficient security rights.

    DETAIL – Access is denied

     

    Root Cause
    The Software Quality Metrics software instrumentation system flubbed up a file in your user’s profiles.
    We see this a lot in Visual Studio installs (VS2010 – VS 2013) but have noticed an increase in other Microsoft products.

     

    How to fix
    It is simple!  Find and delete the SQM files listed in the event log

    -OR- (The more draconian approach)

    1. Navigate to C:\Users\Default\AppData\Local\
    2. Search for *.SQM (all SQM files)
    3. Delete them!

    Good luck!

    “DirectAccess server GPO settings cannot be retrieved” received from Remote Access Management Console

    Here is the scenario:  You logon to your shiny new DirectAccess server, launch the Remote Access Management Console and click CONFIGURATION from the action pane.  A few seconds later you are greeted by the following message

     

    DirectAccess server GPO settings cannot be retrieved.  Ensure you have edit permissions for the GPO.
    GPO Remote Access Error

     

    You frantically review your group policies and find that the DirectAccess Server Settings policy is available and applied to your DirectAccess server.

    What the? (head banging start here)

    The Root Problem
    The message is misleading.  The real problem is the DirectAccess Client Settings policy!

    What is really happening (probably)
    If you have an Organizational Unit (OU) based active directory system, you have probably moved the DirectAccess Client Settings policy to the appropriate OUs so the appropriate workstations and laptops receive the policy.
    I.E. something like this (where the policy applies to the HQ/Remote OU):
    OU Layout

     

    In doing so, you very likely removed the security filtering group the policy was associated to. 
    It turns out this is a very bad thing in the world of DirectAccess.  The DirectAccess Client Settings policy must be available to the DirectAccess server… but should never be applied to the DirectAccess server .  In short, DirectAccess computers can only be identified via security filtering and *not* by assigning the policy directly to OUs.

    UGH!

    So, how do I fix this?

    1. Link the DirectAccess Client Settings policy to the top level of active directory OUs and not to individual OUs
      GPO OU Setting
    2. Filter where the DirectAccess Client Settings policy gets applied via a security group.
      (Remember, you don’t want to apply this policy to your DirectAccess server… or any other servers for that mater!)
      GPO Filtering