Checklist: Metabase Security

The following is a list of recommended steps to ensure the security of the metabase.

	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 Windows Help.
	Maintain strict access control permissions on the metabase files that are listed in File-Level Security. Only the LocalSystem account and the Administrators group should be listed in the access control lists (ACLs) as having full control of the metabase files, including the history files and backups. IIS sets this access control by default.	File-Level Security; See "Access Control" in Windows Help.
	Employ the concept of least permission 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 permission needed to run required tasks. Set IIS security on all IIS applications and virtual directories so that the fewest permissions necessary exist to allow proper clients to view your content.	See "Access Control" in Windows Help; "Security" in IIS Help, which is accessible from IIS Manager,
	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, are already encrypted. Encrypting the entire MetaBase.xml file slows down your IIS server and may cause errors.	See "Cipher" and "Encrypting File System" in Windows Help.
	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.	Editing the MetaBase.xml File While IIS Is Running
	Create backups of your metabase files using the backup/restore configuration tool 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.	Backing Up and Restoring the IIS Metabase; Rolling Back the Metabase Using History Files
	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; therefore, it does not include sensitive data, such as passwords and the keys that encrypt them. 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.	Metabase Import and Export
	Remember that backing up or exporting the metabase does not back up your content (.htm files, .asp files, components, and so on). The metabase only holds configuration data, such as where your content is stored. To back up your content, use the Windows backup and restore feature.	See "Backing up and Restoring Data" in Windows Help.
	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.	Events Reference; See "Event Viewer" in Windows Help.
	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\MetaBase.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 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 may 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 ABO 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 as auditing custom tools and script files, above.	See "To set, view, change, or remove auditing for a file or folder" in Windows Help; "Auditing" in IIS Help, which is accessible from IIS Manager.

Related Topics