Content Security for Searching and Document Management

The server administrator and the workspace coordinator must consider the organization's security policy when planning to make content available through the dashboard site. In the past, information across an organizational structure was often secure by virtue of being difficult to find. With SharePoint Portal Server, obscurity no longer acts as a deterrent for information access. After you identify a source of content, SharePoint Portal Server includes it in an index and makes it available to users across the organization who are associated with the appropriate role.

If information is not properly secured, it could potentially be visible to an unintended audience. For example, confidential information stored on an unsecured file server within one department of a financial institution could be visible to users from a different department through the dashboard site.

SharePoint Portal Server offers several features that make searches faster and more successful for users. These features could also potentially give access to inappropriately secured content. These features include:

• A single location to search for information stored in many different places
• Keyword searches that search the full text of a document and the document's properties
• Advanced search on specific document profiles, properties, or date
• Browsing by topic (categories) to find information
• Automatic categorization of documents
• Best Bet classification for documents that are highly relevant to a search
• Subscriptions to keep you up to date on useful information

When deploying SharePoint Portal Server, you should take steps to ensure that information is available only to the intended audiences by securing content across all information sources.

SharePoint Portal Server reveals all information to the appropriate users according to Windows NT security settings. A lack of clearly defined NTFS security policy can pose a dramatic security risk.

Review your organizational security policy and identify possible security risks. Revise the security policy for each potential hazard to ensure accurate and sufficient permissions for the appropriate groups of people.

There are two sources of content to consider when configuring security: content stored in the workspace and content stored outside the workspace. You must also consider how the dashboard site displays these content sources.

Securing Content in the Workspace

Content stored in the workspace includes documents in standard and enhanced folders. There are several issues to consider when securing content in the workspace.

Security Settings Inheritance

When you create a new subfolder, it inherits security settings from its parent folder by default. If you do not want to use the security settings of the parent folder, you can customize the role settings on the subfolder. If you change the settings for a parent folder, you can specify that all subfolders use the new settings. In this case, you override any modified role settings on the subfolders.

Folders inherit only the role settings. For enhanced folders, SharePoint Portal Server copies the approvers and the approval route to the subfolder when it is created; however, subsequent changes to this setting on the parent folder are not passed to the subfolders.

Control Access with Roles

Roles can assist you in controlling how users access information in a folder hierarchy. For example, if a coordinator does not want the user to infer information based on the folder structure, she can structure the roles so that users can search for particular documents and view them, but the user cannot view parent folders.

To browse the folder hierarchy to locate a document, you must assign a user to at least one role on the parent folder. To browse to a subfolder of a parent folder, you must assign a user to at least one role on both the parent folder and the subfolder.

If a user has access to a subfolder but not the parent folder, he can access that subfolder directly through its URL, even though the parent folder is not visible in Windows Explorer. In this case, documents in the subfolder appear in search results.

Compound Documents

SharePoint Portal Server supports compound documents (the set of files and folders created when you save a document as a Web page from an Office application) only on standard folders. Only coordinators can configure security on a subfolder of a compound document. Enhanced folders do not support any structures similar to compound documents (for example, HTML files with relative links or a Microsoft Word document with a linked Microsoft Excel spreadsheet where both are stored in the workspace). If you attempt to check in a compound document to an enhanced folder, SharePoint Portal Server displays a warning message.

Using Subscription Notifications with Windows 2000 Authentication

When a user creates a subscription, the user does not receive a subscription notification if her right to read the document is assigned through a Windows 2000 Authenticated Users SID, which is inside a domain or local group. Note that the Windows 2000 Everyone group is not one of the SIDs in this category.

For example, ADVENTURE\user falls into the category of Authenticated Users in the ADVENTURE domain. The SharePoint Portal Server computer Marketing is in the same domain. ADVENTURE\user creates a subscription on Marketing to the search results for "specification." Any document that is included in the index and contains the word "specification" should generate a notification.

• ADVENTURE\user receives a notification if a document that contains the word "specification" is in the Projects folder and that folder has Everyone in the Reader role.
• ADVENTURE\user receives a notification if a document that contains the word "specification" is crawled on a Web server.
• ADVENTURE\user does not receive a notification if a document that contains the word "specification" is in the SpecialCase folder, on which the only Reader is the domain group AuthPeople and that domain group contains Authenticated Users.

A user does not receive notifications if his only access to the document is assigned through an Authenticated Users or other special SID such as:

• ANONYMOUS LOGON
• BATCH
• DIALUP
• INTERACTIVE
• NETWORK
• TERMINAL SERVER USER

If an access control list (ACL) contains a group whose members consist of both ADVENTURE\user and Authenticated Users, the user receives a notification.

Using IFS and IIS to Access Content

Installable file system (IFS) and Internet Information Services (IIS) can fully access workspace folders. SharePoint Portal Server workspaces have an associated vroot or virtual directory created in IIS under the Default Web Site. You can manage security for the dashboard site here.

Users can access the IFS by using Windows Explorer on the SharePoint Portal Server computer. SharePoint Portal Server typically maps IFS to network drive M, unless there is already a mapping that uses that drive. Although you can use IFS to view the contents of the Microsoft Web Storage System used by SharePoint Portal Server, this access is read-only.

It is not recommended to use IFS (network drive M) to create SharePoint Portal Server folders or documents, assign security to folders or documents, or edit properties on folders or documents. SharePoint Portal Server roles and configuration options are available through the supported Web folders interface. Manipulating the IFS security attributes may interfere with the roles information associated with SharePoint Portal Server, which results in data loss. Workspace management functions, such as creating document profiles, are also available through the Web folders interface only.

Do not use Microsoft ActiveX^® Data Objects (ADO) or OLE DB to configure security on SharePoint Portal Server folders or documents.

Securing Content Outside the Workspace

SharePoint Portal Server recognizes user-level security policies currently assigned to your organization's servers, file shares, and databases. SharePoint Portal Server does not enforce share-level security.

Security mapping

• SharePoint Portal Server maps the security scheme for a content source to Windows 2000 security and applies the security scheme when it crawls the content and when a user searches the content.
• If you plan to crawl content located on a server in a different domain, do not use local group accounts on the server being crawled to secure content. SharePoint Portal Server may not recognize the local group accounts, which results in the user not being able to view the crawled content.

SharePoint Portal Server can recognize universal group accounts, global group accounts, and domain local group accounts.

For example, suppose Server A is in Domain A, and you want to crawl content located on Server B in Domain B. Server B could be another SharePoint Portal Server computer, a Web server, or a file share.

• The content on Server B is secured by using a local group account.
• When Server A crawls Server B, the SIDs associated with the content are those for the local group account on Server B.
• When a reader in Domain A tries to access the crawled content on Server A, Server A is unable to recognize the security on this content because the SIDs are associated with Server B.
• The reader is unable to view the content, even if the user is an authenticated user from Domain B.

Security enforcement for types of content sources

Security for the different types of content sources works as follows:

• Web sites. SharePoint Portal Server does not enforce security at query time. SharePoint Portal Server specifies a per-path logon for crawling, but everyone has access to the results. Secure Socket Layer (SSL) shares (preceded by https://) cannot be crawled.
• File shares. SharePoint Portal Server enforces user-level security at query time. There is no share-level security on file allocation table (FAT) and other file systems that do not have user-level security. SharePoint Portal Server specifies a per-path logon for crawling, which allows access through share-level security. Encrypted documents are not crawled.
• SharePoint Portal Server computers. SharePoint Portal Server enforces user-level security at query time.
• Microsoft Exchange 2000 servers. SharePoint Portal Server enforces message-level security at query time. Encrypted messages are not crawled.
• Microsoft Exchange 5.5 servers. SharePoint Portal Server enforces message-level security at query time. Encrypted messages are not crawled.
• Lotus Notes servers. A mapping from the Lotus Notes user identification (ID) to the Windows NT user ID allows record-level security at query time.

Before you can create Exchange Server 5.5 and Lotus Notes content sources, you must configure the server to crawl Exchange Server 5.5 and Lotus Notes content sources.

SharePoint Portal Server can access a UNIX system by using the network file system (NFS) protocol. SharePoint Portal Server can also access Novell NetWare by using a NetWare client. You must install the corresponding client for the UNIX or NetWare file system on the SharePoint Portal Server computer.

SharePoint Portal Server does not understand the security descriptors on the remote file systems that are not NTFS file systems, such as UNIX, NetWare, or similar foreign file systems. Per-file security on non-NTFS file systems is lost, but SharePoint Portal Server maintains per-share security. In the absence of security mapping, SharePoint Portal Server logs on as anonymous (or guest) and does not have access to any content that is not accessible to anonymous users. In this case, SharePoint Portal Server crawls the documents and then stamps them with read access for the Windows 2000 Everyone group. This means that all crawled documents are searchable by any user. Administrators should be aware of this to avoid disclosing information that is secured in a way that is not compatible with Windows NT.

SharePoint Portal Server can send security credentials while accessing foreign file systems, such as UNIX or NetWare. You can specify that the account and password in the site path rules for the remote file system path requiring Basic authentication. A failure to get the security descriptor causes SharePoint Portal Server not to include the item in the index.

SharePoint Portal Server can include any Windows File Share (SMB) in an index, but does not have built-in support for any other network file system protocol. These file systems can be included in the index using an emulator that exposes them as a Windows File Share, but security on the file share is enforced only as well as it is exposed by the emulation software. In general, all documents included in the index from a non-NTFS file system are searchable by all readers on the SharePoint Portal workspace.