Share via

Metabase Security

  • Article

A default installation of Internet Information Services (IIS) ensures that the metabase is secure by setting strict access control lists (ACLs) on the metabase files, setting ACLs on metabase nodes, and by encrypting sensitive data within the files. If you take the following steps, you will protect the metabase files:

  • Maintain the default level of security

  • Enable IIS to create regular backups

  • Use a strong administrator password for the IIS server

  • Limit the number of users who have administrative credentials

Warning

Do not add the BUILTIN\IWAM_computer_name or BUILTIN\IUSR_computer_name account to the BUILTIN\Administrators group, or set the AnonymousUserName or WAMUserName properties to an administrator account. Doing so significantly reduces the security of your IIS server. You can add ACLs to the metabase to give specific accounts write access.

Access Control Lists (ACLs) Set on Metabase Nodes

If you want the application that you are developing to change metabase configuration data, you must know which ACLs are set on nodes in the in-memory metabase. Then you can configure your application to run under the correct identity.

By default, if an authenticated client is in the BUILTIN\Administrators group, the application that the client is using can change the metabase. If an authenticated user is not in the BUILTIN\Administrators group, the application that they are using can read some, but not all, metabase data. The safest way to allow a non-administrator account to change the metabase is to add a restricted write ACL to specific metabase nodes by using the Metabase Explorer tool which can be downloaded from IIS 6.0 Resource Kit Tools, or by using MetaACL.exe which can be found by searching on https://www.microsoft.com.

The following table lists metabase nodes and their default ACLs. The ACLs apply to all child keys under those nodes.

Access Control Entries (ACEs) are defined as follows:

  • R: Read

  • W: Write

  • S: Restricted write

  • U: Unsecured properties read

  • E: Enumerate keys

  • D: Write DACL permissions

Metabase Node

ACLs

Service level nodes

Identified by the locations:LM/W3SVCLM/MSFTPSVCLM/SMTPSVCLM/NNTPSVC

Identified by the admin objects:IIsWebServiceIIsFtpServiceIIsSmtpServiceIIsNntpService

NT AUTHORITY\LOCAL SERVICE: R UE

NT AUTHORITY\NETWORK SERVICE: R UE

COMPUTER\IIS_WPG: R UE

IIS 5.1 and earlier: The COMPUTER\IIS_WPG account does not exist.

BUILTIN\Administrators: RWSUED

Filter nodes

Identified by the locations:LM/W3SVC/FiltersLM/W3SVC/n/Filters

Identified by the admin object:IIsFilters

NT AUTHORITY\LOCAL SERVICE: RW UE

NT AUTHORITY\NETWORK SERVICE: RW UE

COMPUTER\IIS_WPG: RW UE

IIS 5.1 and earlier: The COMPUTER\IIS_WPG account does not exist.

BUILTIN\Administrators: RWSUED

Application pool nodes

IIS 5.1 and earlier: Application pools to not apply.

Identified by the location:LM/W3SVC/AppPools

Identified by the admin object:IIsApplicationPools

NT AUTHORITY\LOCAL SERVICE: U

NT AUTHORITY\NETWORK SERVICE: U

COMPUTER\IIS_WPG: U

BUILTIN\Administrators: RWSUED

Encrypted Properties

IIS encrypts sensitive data in the metabase so that it cannot be viewed even if an unauthorized user gains access to the file. Metabase properties are marked for encryption by the SECURE attribute that is set on the property in the metabase. IIS decrypts the properties in memory only when it loads the metabase.

IIS 6.0: Do not manually edit encrypted properties by opening the metabase.xml file in a text editor to change their values. IIS cannot read properties that have been edited manually.

To edit encrypted properties for IIS, use the Active Directory Service Interfaces (ADSI) provider or the Admin Base Objects (ABO). For IIS 6.0, you can also use the Windows Management Instrumentation (WMI) provider to edit encrypted properties. If you prefer to use command-line tools, you can use Adsutil.vbs.

The following is a list of encrypted properties in the metabase:

See Also