Share via

Thoughts on Delegating IIS Configuration and Administration

  • Article

Question

I am running IIS 6.0 on Windows 2003 Server. our web developers needed to create or edit websites, for security reasons I cannot simply give them admin rights or the password to the admin account.

I have created an account for them to logon remotely to the webserver, however, they do not have the proper rights to use the IIS management console. Is there a way to provide users without admin rights the ability to use IIS to create, edit and manage websites from a remote desktop connection?

Any help would be appreciated.

Best Regards

One Answer:

You must be a member of the Local administrators group to administer IIS 6 and below.

IIS 7 (when released) will remove such restrictions.

My Answer:

IIS6 does not come with such delegated administration capabilities, but various Control Panel Applets supplement that market.

Also... IIS7 does not exactly remove such restrictions. ;-)

On IIS7 Configuration

The security model of IIS7 configuration derives from NTFS ACLs on the distributed .config configuration files as well as Allow/Deny/Inherit logic of the configuration properties within the distributed .config hierarchy. I know I know, it sounds more complicated than it actually works. Without getting hung up on the details, here is how I rationalize it:

  • NTFS ACLs control whether a user can modify the .config files and hence potentially configure IIS behavior by adding/changing configuration properties.
  • Allow/Deny/Inherit logic within the IIS configuration subsystem determines whether the parent's or child's setting of any given configuration property within the distributed .config hierarchy "wins" and takes effect.
  • IIS server core (and its modules) merely read from the IIS configuration subsystem to get a merged view of the distributed configuration and then perform specified actions.
  • applicationHost.config is the root of the IIS configuration hierarchy.

All the pieces have to align for distributed administration to work properly. For example, you may have NTFS ACLs to write configuration values into a web.config file, but if the web.config file is not considered part of the .config hierarchy or whose property configuration was not delegated to that part of the hierarchy, the IIS configuration subsystem simply ignores your changes and IIS server core never sees nor acts on it (well, right now it just fails fast, so IIS7 is finicky about broken configuration, but you get the idea). Likewise, if you have no NTFS ACLs to change web.config files, you have no way to configure IIS even if the configuration properties are all delegated.

Thus, IIS7 restricts non-administrators from performing the following tasks via NTFS ACLs on the applicationHost.config file. This list merely illustrates our logical design and not necessarily exhaustive nor complete.

  1. Create/Manage Application Pools
  2. Create Websites and associate IP:Port:Host Bindings
  3. Create Applications and associate Application Pools
  4. Add Global Modules

Non-administrators can change any other IIS configuration as long as it is delegated to their portion of the .config hierarchy, and they have NTFS ACLs to modify web.config files.

Security, Security, Security...

Security is the reason why non-administrators cannot perform those tasks by default. Why? Well... non-administrators can easily elevate privileges via those tasks, which sorta destroys the purpose of delegating privileges...

  1. If non-administrator can manage Application Pools, then they can elevate privileges by simply changing the Application Pool running their code into LocalSystem.
  2. If non-administrator can Create/Manage Websites, then they can control what Application Pool runs their Application in the Website and hence can run code in Application Pools of elevated privileges.
  3. If non-administrator can manage Global Modules, then they control the code that loads in all Application Pools and can possibly run code in Application Pools of elevated privileges.

You control all of this by controlling who can associate websites, applications and global modules, and application pools... which means that you simply cannot maintain security AND give non-administrators the ability to Create and Edit websites AND publish code into it. And no, we are not going to build hierarchies of inheritance simply to support the ability to only change Application Pool identity at one level but not another. Just too complicated a feature - you need to re-think your developer sandbox.

Conclusion

I understand that your desires are logical and reasonable, but logical/reasonable != secure. I hope I have explained why your requirements are actually contrary to your security desires.

Prior to IIS7, IIS did not have a configuration subsystem which allowed rich definition and delegation, so IIS control panel applets all run with Administrator/LocalSystem privileges and provide a proprietary/individual delegation view.

IIS7 comes with a rich and delegation friendly configuration subsystem that should be customizable to fit many requirements without needing control panel applets. Of course, IIS7 is totally extensible, from the server core to its configuration and administration via the UI, Commandline, and Scripting, so you can always implement your own logic on top of our primitives. You have the choice.

//David

Comments

  • Anonymous
    May 10, 2006
    I was sure there was an "Operators" tab in IIS for delegating administration once. Can't see it in XP or 2003 - was I imagining it? What was that used for?
  • Anonymous
    May 10, 2006
    The comment has been removed
  • Anonymous
    May 11, 2006
    My take is and has always been that developers should stay on a development server and not develop with admin credentials.  There is much that has been said about this from MS and elsewhere.

    When it comes to deploying to a production server then the admin of teh server should be the only one to create or modify a site or virtual folder.  This is the best and only way to prevent disasters.

    The problem comesup that a developer needs to debug an application when it fails on the production server.  This is best handled with "trace" tools or Response.Write statements.  Once a production servere is put into debug mode all kinds of bad things can happen.

    Thge other common scenario is a secured and managed development/test server.  In this case it would be helpful for developers to be able to create and mange subwebs.  It looks like IIS 7 will mve us in that direction.

    Another method I have seen used is for developers to submit a request through a secure web page that causes a create script to be run.  This limits the capabilities of the developer to what the script designer has allowed.

  • Anonymous
    May 11, 2006
    My take is and has always been that developers should stay on a development server and not develop with admin credentials.  There is much that has been said about this from MS and elsewhere.

    When it comes to deploying to a production server then the admin of teh server should be the only one to create or modify a site or virtual folder.  This is the best and only way to prevent disasters.

    The problem comesup that a developer needs to debug an application when it fails on the production server.  This is best handled with "trace" tools or Response.Write statements.  Once a production servere is put into debug mode all kinds of bad things can happen.

    Thge other common scenario is a secured and managed development/test server.  In this case it would be helpful for developers to be able to create and mange subwebs.  It looks like IIS 7 will mve us in that direction.

    Another method I have seen used is for developers to submit a request through a secure web page that causes a create script to be run.  This limits the capabilities of the developer to what the script designer has allowed.

  • Anonymous
    May 11, 2006
    DuncanS - "Operators" was an ill-conceived attempt at delegating a fixed set of actions to a special group of users who do not need to be system administrators.

    Since it is a server-feature, it never existed in XP, and we removed it in Windows Server 2003 due to the security problems it introduced. We rather not have delegation than to have insecure delegation.

    //David
  • Anonymous
    May 11, 2006
    Jeff - I think you are in a more controlled and orderly environment. :-)

    In general, I cannot think of a situation where you simultaneously:
    1. Value security to not allow developers have admin rights
    2. Yet allow developers access to configuration that gives them admin rights

    The requirements contradict, so to me, the requirements are not valid.

    //David
  • Anonymous
    May 11, 2006
    jvierra - Yes, IIS7 will allow a secured and managed development/test server.

    However, the right to create the initial website/application pool still belongs to a privileged server administrator. This privilege can be abstracted to making users submit a request to a secure/tracked website, etc.

    The developer will be able to party in an isolated fashion within their website on IIS7:
    - Delegated configuration can be modified at-will.
    - Native code, either in the form of a CGI/ISAPI or native code module, require server administrator approval and configuration in applicationHost.config to load/run.
    - Managed code in the form of managed modules and handlers, can be uploaded and run at-will.
    - All of this can be done by directly modifying delegated .config files as well as the new IIS7 UI.

    //David
  • Anonymous
    May 31, 2006
    We are going through this issue with our developers right now. We are pushing for tighter change control management on the infrastructure side of the house. Part of this is removing full admin rigths on production servers from developers and web admins.

    I found the following link for how to do this....

    HowTo manage IIS via MMC SnapIn without admin-rights...

    http://www.winserverkb.com/Uwe/Forum.aspx/iis-security/2147/HowTo-manage-IIS-via-MMC-SnapIn-without-admin-rights
  • Anonymous
    June 08, 2006
    emillsco - Interesting link. But just remember, it is not by design nor supported by Microsoft, so you are on your own if you encounter issues with it...

    //David
  • Anonymous
    September 19, 2006
    Can someone tell me why we would not allow developers to have admin access to there own developer server?  It seems to me that we should have a who cares attitude for the development region.  I mean really who cares if they mess up there own environment as long as they do not have access to UAT and production and code is being migrated to the next region by change control.

    It just seems to me that if I slow down development my company will be less market driven.  Please help me with why I would and why I would not do this?

    JIm
  • Anonymous
    January 18, 2008
    Reasons for developer admin rights: 1> The reason for admin rights for developers can be in emergency cases. Depending on senario, you may want the guy you understands what is going wrong to have the ability to see what is going on. 2> He paid for it. (If I purchased server and was paying for hosting it in your server room, you bet I would go to another company if the requirement I not be an admin was in the lease/contract.) 3>Limited Lan Kiosks: Not all networks have the ability to reach the internet. Without any internet traffic, then security from internet hacking is not a threat.