Checklist: Metabase Security

Article
10/08/2009

Applies To: Windows Server 2003, Windows Server 2003 with SP1

Table 4.5 is a list of recommended steps to ensure the security of the metabase.

Table 4.5 Steps to ensure metabase security

Complete	Step	Reference
	Make sure that the passwords for all accounts on your computer are strong and not written anywhere near the computer or within view.	See "Passwords" in Help and Support Center for Windows Server 2003.
	Maintain strict access control permissions on the metabase files that are listed in Table 4.4. Only the LocalSystem account and the Administrators group should be listed in the ACLs as having full control of the metabase files, including the history files and backups. IIS sets this access control by default.	See "Access control" in Help and Support Center for Windows Server 2003.
	Employ the concept of least privilege on your computer. Allow only one person to know the Administrator password, and limit the number of people whose accounts are in the Administrators group. Set ACLs on all folders and files so that the fewest users have the lowest-level privileges needed to run required tasks. Set IIS security on all IIS applications and virtual directories so that the least permission necessary exists to allow the appropriate clients to view your content.	See "Access control" and "Security" in Help and Support Center for Windows Server 2003.
	Do not run the cipher command or use Encrypting File System (EFS) on the metabase files. Sensitive data, such as passwords that are stored in MetaBase.xml, is already encrypted. Encrypting the entire MetaBase.xml file slows the performance of your IIS server and might cause errors.	See the "Cipher" and "Encrypting File System" topics in Help and Support Center for Windows Server 2003.
	When you edit the MetaBase.xml file manually, copy the MetaBase.xml file first, and then work on the copy. When you have checked your changes, replace MetaBase.xml with your copy.	See Editing the MetaBase.xml File While IIS Is Running.
	Create backups of your metabase files using Backup/Restore Configuration whenever you make a significant change in the metabase. If you allow other people to configure the metabase, make it a policy that they create a backup with their name in the title whenever they make a change. IIS periodically makes its own backup files, called history files, but history files might not be created for every change to the metabase.	See Backing Up the Metabase
	Do not use the metabase import and export feature to create regular backup files. This feature is meant to transport sections of the metabase to other computers. However, it is recommended that you create an export file for your entire metabase periodically in the event that your computer hardware fails and you must move your Web sites to another computer.	See Metabase Import and Export.
	Remember that backing up or exporting the metabase does not back up your content (for example, .htm files, .asp files, and components). The metabase holds only configuration data, such as the location where your content is stored. To back up your content, use Windows Backup.	See "Backing up and restoring data" in Help and Support Center for Windows Server 2003.
	Monitor your event log for IIS event messages. For example, if you attempt to make changes to the metabase when there is a write-lock on the in-memory database, a metabase history file is created and an error is written to the event log. If you successfully create an FTP virtual directory, but IIS cannot enumerate the physical directory, an error is written to the event log.	See "Event Viewer" in Help and Support Center for Windows Server 2003.
	Set up file auditing on the various files that affect the metabase. This way, if the metabase becomes corrupted, you can identify the account of the last user who made a change. Select your auditing choices carefully for the files listed below, and monitor the audit logs for a period of time to determine if the settings are meeting your needs. `Systemroot\System32\Inetsrv\MetaBas.xml….` If you choose to audit the MetaBase.xml file, only users who edit the metabase manually are identified in the audit logs by their own account name. Users who edit the metabase by using IIS Manager or other tools are logged as accessing the metabase under the LocalSystem account. Because IIS itself is constantly accessing the metabase, audit logs can grow very quickly unless you limit auditing to specific users, such as the local Administrators group, and specific access attempts, such as writing to a file. Auditing MetaBase.xml is still valuable for determining when changes were made, but you might have to audit the other files listed here to find the exact identity of the user. Custom tools and script files that use WMI, ADSI, or ABOs to edit the metabase: Auditing should be set on these tools to identify who executes them. If you audit MetaBase.xml and want to find out who made a change at 3:01 P.M. on a certain day, you can look in the audit logs for your scripts and tools to see if someone ran one of them at 3:01 P.M. `Systemroot\System32\Inetsrv\Inetmgr.exe….` Audit this file for the same reason you audit custom tools and script files, above.	See "Auditing overview" in Help and Support Center for Windows Server 2003.