Security

Catalog Directory Access Control
Access Control for Web Pages
Authentication
Remote Virtual Roots
Administration Over the Web
Configuration Note

This section discusses the security administration of Microsoft Index Server. In order to maintain a secure site without disclosing information to unauthorized persons, it is necessary to be aware of authentication and access control issues. Even on sites that contain only widely available public information, being aware of security issues helps to prevent compromising the server.

Catalog Directory Access Control

When Index Server is first installed, the catalog is set up with an Access Control List (ACL) that allows only system administrators and system services to access it. In part, this assures that if the catalog directory is contained within a virtual root, unauthorized users will not see the files in the catalog as part of their query. The protection on the catalog directory is also important to prevent unauthorized users (who might have access to the server by use of file-server shares) from seeing the contents of the catalog. Although the information in the catalog is in a form that would be difficult for someone without knowledge of the file formats to decipher, it is possible to read the content of files on the server by examining the catalog.

If an additional catalog directory is created manually, care should be taken to ensure that it and the files created in it have appropriate access controls. A catalog directory should allow access for administrators and for the System account. Index Server runs as a service, so System access is required.

Access Control for Web Pages

When documents are filtered, any access controls on a document are kept in the catalog and checked against client permissions when a query is processed. If a client does not have access to a document, the document will not be included in any of the client’s query results; there will be no indication that the document exists. In order to avoid the appearance of missing hits, a user should be properly authenticated before processing a query.

If a document has an ACL that triggers auditing of access attempts, an audit will be generated when the document is filtered (according to the ACL, if System access is to generate an audit record). An audit record will not usually be generated when a document is examined for possible inclusion in a query result. If a document matches a query, and the client subsequently examines the document, an audit record will be generated according to the ACL.

Authentication

In order for access control to be enforced properly, it is necessary that any client be properly authenticated prior to doing a query. The easiest way to ensure that a client is authenticated is to place some appropriate access control on the form that issues a query. An access control list could also be placed on the .idq or .htx file used in a query.

Depending upon the configuration of Internet Information Server, one or more authentication mechanisms can be used. These are:

• Anonymous logon
• Basic authentication
• Windows NT Challenge/Response authentication

If anonymous logon is allowed, it will be used by default as long as all files accessed by the client are permitted to be accessed by the anonymous logon account. Whenever an attempt is made to gain access to a document for which access is denied to the anonymous user, an authentication dialog will be presented (if some other authentication mechanism is available). The client can then provide authentication and thereby gain the rights to access files that would otherwise be denied.

Authentication of all clients accessing the server can be forced by disabling the anonymous account.

For an intranet consisting entirely of computers running Windows NT Workstation and Windows NT Server, Windows NT Challenge/Response authentication is the preferred authentication mechanism. With Windows NT Challenge/Response, the client’s password is not transmitted in clear text over the network. A user does not need to log on to access the query forms, because a single logon is maintained. Index Server uses the same credentials that Windows NT uses.

Remote Virtual Roots

In Internet Information Server and Peer Web Services, if the server is configured to access and index a remote virtual root, access to that virtual root and the documents contained on it is determined by the account configured to access the remote share. Any accessible document will be indexed, and will be available to any client that connects to the server. The access checks for query results described earlier in this chapter are explicitly disabled in this case.

Be aware that if you index remote virtual roots, the documents on that root may be unintentionally disclosed to unauthorized clients, because the user name and password supplied by the Web administrator (in the Directories property sheet of Internet Service Manager) is used for all access to that remote share.

Administration Over the Web

When administering Microsoft Index Server over the Web, you should make sure to tightly control administrative access. All administrative operations Index Server are controlled by the access control list (ACL) on the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ContentIndex

If you need to put additional controls on administrative operations, you can put ACLs on the .ida, .idq, and .htx files through which you administer your site. If you administer your site only locally rather than from a remote computer, you can put the administration forms on a local disk, which can be accessed through the following address:

file: URL references

To administer your site locally, you must make the scripts available in an executable virtual root on your Web server.

For information about security in the Scripts directory, see “Query Section” in “Internet Data Query Files.”

Configuration Note

If you want to configure different virtual roots to point to the same remote Uniform Naming Convention (UNC) path with different user IDs with varying privileges, the results returned by Microsoft Index Server are not predictable.

For example, consider the following configuration. It is highly recommended that you avoid setting up a configuration as follows:

© 1996 by Microsoft Corporation. All rights reserved.