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