One of the key management scenarios that the IIS 7.0
configuration system has in mind is configuration delegation.
Configuration delegation refers to the ability of the Web site or application
owner to specify the required IIS configuration for their application
without being an administrator on the Web server computer. To allow
this, the IIS 7.0 configuration file hierarchy supports specifying
configuration in distributed web.config files, which can be located
anywhere in the Web site’s directory structure to override the
configuration specified at the server level. This also allows Web sites
and applications to become portable by including all of the
configuration files necessary alongside their content, so they can be
deployed by simply being copied to the Web server.
If configuration delegation
was an all or nothing approach, it likely wouldn’t work, because most
Web server administrators would not want to allow the Web site or
application to be able to override all of the configuration set at the
server level, especially for configuration sections that affect
security, reliability, and performance of the Web server. Therefore, the
IIS 7.0 configuration system provides an extensive set of controls that
server administrators can use to determine which configuration
sections, and further yet, which specific configuration attributes, can
be overridden at the Web site or application level. If you manage a Web
server that allows others to publish application content, you will
likely need to review the configuration allowed for delegation, and in
some cases lock or unlock specific configuration for delegation.
Further, IIS
7.0 also provides the infrastructure for Web site and application
administrators to manage their configuration remotely through IIS
Manager, without having administrative privileges on the Web server
computer. Again, as a server administrator, you have fine-grained
control over who can manage the Web sites and applications on your
computer remotely, and what management features they can use.
Controlling Which Configuration Is Delegated
The configuration
section is the basic unit of configuration delegation. By default, each
configuration section is marked to initially allow or deny delegation
when it is first declared, by specifying the overrideModeDefault
attribute in the section declaration (this is typically determined by
the developer based on whether the section is considered sensitive and
should not be modifiable by non-Administrators by default). If the
section is marked as not delegated, any attempt to specify the
configuration for this section at any lower level in the configuration
hierarchy will lead to a configuration error when this section is
accessed.
By default, all IIS
configuration sections are declared in applicationHost.config. Each
section declaration specifies whether or not this section is available
for delegation, based on the Microsoft IIS team’s criteria for whether
or not the configuration section is sensitive. This criteria includes
considerations of whether the configuration section can be used to
weaken the
security, reduce reliability, or significantly impact the performance
of the Web server overall, or allow the Web site or application to
access information outside of its boundaries.
Note
You
can also manage the delegation of .NET configuration sections using the
IIS administration stack. Both IIS and .NET configuration use the same
mechanism for controlling delegation, including section-level locking
and fine-grained configuration locking.
|
The default delegation of IIS configuration sections is shown in Table 1.
Table 1. Default Delegation of IIS Configuration Sections
| Section | Default State | Reason |
|---|
| system.applicationHost | | |
| applicationPools | n/a | Section can be specified only in applicationHost.config |
| configHistory | n/a | Section can be specified only in applicationHost.config |
| customMetadata | n/a | Section can be specified only in applicationHost.config |
| listenerAdapters | n/a | Section can be specified only in applicationHost.config |
| log | n/a | Section can be specified only in applicationHost.config |
| sites | n/a | Section can be specified only in applicationHost.config |
| webLimits | n/a | Section can be specified only in applicationHost.config |
| system.webServer | | |
| asp | Deny | Contains security, performance, and reliability sensitive settings for ASP applications |
| caching | Allow | |
| cgi | Deny | Security sensitive: createProcessAsUser |
| defaultDocument | Allow | |
| directoryBrowse | Allow | |
| fastCgi | n/a | Section can be specified only in applicationHost.config |
| globalModules | n/a | Section can be specified only in applicationHost.config |
| handlers | Deny; Allow when .NET Extensibility is installed | For compatibility with IIS 6.0; section is effectively unlocked as soon as .NET Extensibility is installed |
| httpCompression | n/a | Section can only be specified in applicationHost.config |
| httpErrors | Deny | Security sensitive: ability to specify error pages outside of the application |
| httpLogging | Deny | Security sensitive: turning off logging can create repudiation issues |
| httpProtocol | Allow | |
| httpRedirect | Allow | |
| httpTracing | Deny | Performance sensitive: list of ETW URLs to trace |
| isapiFilters | n/a | Section can be specified only in applicationHost.config |
| modules | Deny; Allow when .NET Extensibility is installed | For compatibility with IIS 6.0; section is effectively unlocked as soon as .NET Extensibility is installed |
| odbcLogging | Deny | Security sensitive: configuring logging to external database |
| serverRuntime | Deny | Security, performance, and reliability affecting settings for the core Web server engine |
| serverSideInclude | Deny | Security sensitive: enabling server-side include can allow the application to access content outside of its boundaries |
| staticContent | Allow | |
| urlCompression | Allow | |
| validation | Allow | |
| system.webServer/security | | |
| access | Deny | Security sensitive: configure SSL requirements |
| applicationDependencies | n/a | Section can be specified only in applicationHost.config |
| authorization | Allow | |
| ipSecurity | Deny | Security sensitive: determine who can access the application |
| isapiCgiRestriction | n/a | Section can only be specified in applicationHost.config |
| requestFiltering | Allow | Caution: delegated, but application can end up removing basic protection configured at server level and lessen its security |
| system.webServer/security/authentication | | |
| anonymousAuthentication | Deny | Security sensitive: enable or disable authentication method |
| basicAuthentication | Deny | Security sensitive: enable or disable authentication method |
| clientCertificateMapping Authentication | Deny | Security sensitive: enable or disable authentication method |
| digestAuthentication | Deny | Security sensitive: enable or disable authentication method |
| iisClientCertificate MappingAuthentication | Deny | Security sensitive: enable or disable authentication method |
| windowsAuthentication | Deny | Security sensitive: enable or disable authentication method |
| system.webServer/tracing | | |
| traceFailedRequests | Allow | |
| traceProviderDefinitions | n/a | Section can only be specified in applicationHost.config |
The
default delegation state for IIS configuration sections is just that—a
default—and may not work for everyone. If you allow third parties to
publish Web site or application configuration on the server, you will
need to review the impacts of allowing each section to be delegated and
strike a balance between application requirements for delegation and the
need to protect the Web server from unintended or malicious
configuration changes. Then, you can lock or unlock configuration
sections to allow them for delegation or even use fine-grained
configuration locking to allow section delegation but lock specific
configuration attributes, elements, or collection entries.
When determining which configuration should be delegated, keep the following guidelines in mind:
Err on
the side of leaving configuration sections locked at the server level
and unlock specific sections as needed by the application. You can also
unlock specific sections for specific Web sites or applications only and
leave them locked for others. This is an effective method to avoid
unexpected configuration changes at the application level even if you do
not delegate configuration to other parties.
When
unlocking a specific section, you can still lock parts of it that
contain sensitive configuration or configuration you do not want to be
changed. Use fine-grained configuration locking to lock the attributes,
elements, or collection elements that you don’t want changed while
allowing other parts of the configuration section to be delegated.
