Traditional Windows NT Security

SharePoint Portal Server extends the traditional Windows NT security model of Windows 2000. This section reviews Windows 2000 security concepts that pertain to SharePoint Portal Server security architecture.

Although Windows 2000 is fully backward compatible with previous versions of Windows NT, Windows 95, and Windows 98, Windows 2000 enhances the security model considerably, notably by the introduction of Kerberos version 5 protocol. Windows 2000 security is easier to use than earlier versions of Windows and provides improved support for distributed applications. These changes allow much greater scalability and increased ease of administration compared with earlier versions of Windows NT. Many of the enhancements directly support the Microsoft Active Directory^™ directory service. SharePoint Portal Server adds value to the customer experience by further simplifying the administration process.

Using Access Control Lists

Windows 2000 security relies on Access Control Lists (ACLs) to control access to resources. Windows NT stores an ACL with every file and folder on an NTFS partition. The ACL contains a list of all user accounts, groups, and computers that are granted access for a file or folder and the type of access granted to them. For a user to access a file or folder, the ACL must contain an entry—called an access control entry (ACE)—for the user account, group, or computer to which the user belongs. The entry must specifically allow the type of access the user is requesting for the user to be able to gain access to the file or folder.

If no ACL exists, Windows 2000 grants all users Read access. If no ACE exists in the ACL, Windows 2000 denies the user access to the resource. If you apply an empty ACL, then Windows 2000 denies access to all users. If multiple ACEs exist for a user, Windows 2000 applies the first one. Consequently, it is recommended that you grant permissions first to an individual user, and then to any groups. This ensures that specific users are granted any appropriate permissions that might supercede their group permissions.

Figure 8.2 illustrates how access is granted based on an ACL.

Figure 8.2. Access control lists

In this figure, User2 does not have an ACE. Consequently, User2 is not granted access to the resources on the NTFS partition.

SharePoint Portal Server uses ACLs extensively to ensure secure and appropriate access to content.

Highlighting Windows 2000 Security

The Windows 2000 Distributed Security Services provides flexible solutions for building secure and scalable distributed applications. Security administration and management have richer features for delegation and detailed account control. Active Directory supports domains with a much higher number of accounts in a structured naming environment of organizational units. Inter-domain trust management is simpler, providing greater flexibility to use domains in ways that reflect the needs of the enterprise. You can use SharePoint Portal Server in an Active Directory environment.

Windows security APIs for network authentication, data privacy, digital signatures, and encryption support secure application development for the enterprise and the Internet. The Microsoft Security Support Provider Interface (SSPI) and CryptoAPI interfaces, in addition to higher-level Component Object Model (COM) and distributed version of COM (DCOM) interface abstractions, make all the integrated security features of Windows 2000 available for SharePoint Portal Server to use. SharePoint Portal Server uses the robust security architecture of Windows NT consistently across all system components and extends to support strong authentication and public-key security.

Windows 2000 Distributed Security integrates mature Internet standards for authentication while introducing new public-key security technology based on industry direction and available standards. Many of the Internet public-key security standards are still forming. Microsoft is involved in the development of these standards but recognizes that they are likely to change over time. The Windows 2000 security architecture is specifically designed to incorporate new security technology in the form of protocols, cryptographic service providers, or third-party authentication technology. Customers deploying Windows 2000 have choices about which security technology to use, how to integrate security into their application environment with minimum impact, and when to migrate to new technology as it becomes available.

Together, these factors make the Windows 2000 Distributed Security Services the best foundation for secure Internet-distributed computing. For the latest information about secure Internet-distributed computing with SharePoint Portal Server, see Chapter 12, Deploying SharePoint Portal Server in an Extranet Environment.

Honoring Windows 2000 Authentication Methods

SharePoint Portal Server honors all the various types of authentication by accepting the appropriate access token based on a user's security identifier (SID). However, there are some scenarios where you may use certificate authorities (CAs) that do not work with SharePoint Portal Server. SharePoint Portal Server security uses SIDs. A user without a valid SID does not gain access to content using SharePoint Portal Server.

In SharePoint Portal Server, workspace access is restricted to valid Windows NT users and groups, whether they are domain users or local server users. When you deploy SharePoint Portal Server within a Windows NT domain and the user logs into the domain, SharePoint Portal Server uses the domain security services for authentication. This enables a single logon for users. Where you deploy SharePoint Portal Server in non-Windows NT domains, SharePoint Portal Server collects and authenticates the user name and password. It does this by using basic authentication against accounts maintained on the server running SharePoint Portal Server.

Using Basic Authentication, Windows 2000 sends user accounts and passwords as clear text.

You must assign a user a Windows NT account in order to receive a SID. SharePoint Portal Server uses SIDs to assign roles. You must assign users a role to access content. For anonymous access, Windows 2000 security provides a specific SID for use in ACLs. Consequently, you can assign anonymous users to roles.

If you enable anonymous access to the document library, then by default, SharePoint Portal Server gives all users anonymous access. In order to allow anonymous readers access to the document library, it is recommended that you create a separate virtual server for this type of access.

For more information about creating a separate virtual server, see Chapter 12.

Windows 2000 manages the network security credentials for a user transparently after a single instance of signing on successfully. The user is not concerned about whether a connection to a network server uses NT LAN Manager (NTLM), Kerberos protocol, or a public-key-based security protocol. Users simply sign on to the system and have access to a wide variety of network services.

Within the enterprise, Windows 2000 determines access to resources by the rights granted to users' accounts or by group memberships. Across the Internet, Windows 2000 determines users' access based on their identity proven by a private-key signature operation and the corresponding public-key certificate. All the security protocols rely on some form of user credentials, which the client computer presents to a server when a connection is established. Windows 2000 manages these user credentials and automatically uses the appropriate set of credentials, based on the security protocol involved.

The Windows 2000 Active Directory service supports multiple security credentials as part of the secure portion of user account information. Windows 2000 uses these credentials for enterprise authentication services that use the domain controller for online user authentication. Advanced application servers can support integrated Windows 2000 authentication by using the Security Service Provider Interface for network authentication.

Reviewing Windows 2000 Security Group Scopes

The scope of a group determines whether you can use a group across one or more domains. The group scope affects group membership and group nesting. Nesting is adding a group to another group as a member. Windows 2000 provides three group scopes: global, domain local, and universal.

Global Group Scope

Use this group scope to organize users who share similar network access requirements. You can use a global group to grant permissions to gain access to resources that are located in any domain.

• Global groups have limited membership. Add user accounts and global groups only from the domain in which you create the global group.
• You can nest global groups within other groups. This function allows you to add a global group to another global group in the same domain or to universal and domain local groups in other domains.

Domain Local Group Scope

Use this scope to grant permissions to domain resources that are located in the same domain in which you created the domain local group. The resource does not have to reside on a domain controller.

• Domain local groups have open membership. Add user accounts, universal groups, and global groups from any domain.
• You cannot nest domain local groups within other groups. Consequently, you cannot add a domain local group to any group, even groups in the same domain.

Universal Group Scope

Grant permissions to related resources in multiple domains. Use a universal group to grant access permissions to resources that are located in any domain.

• Universal groups have open membership. All domain user accounts and groups can be members.
• You can nest universal groups within other domain groups. This capability allows you to add a universal group to domain local or universal groups in any domain.

Security groups with a universal group scope are only available when the domain is in native mode. Native mode is when all domain controllers are running Windows 2000.

In addition, you can create local groups only on member servers and on computers running Windows 2000 Professional, and you use them to assign permissions to resources only on the local computer. The membership rules for local groups include the following:

• Local groups can only contain local user accounts from the computer on which you create the local groups.
• A local group cannot be a member of any other group.

Guidelines for using local groups include:

• Define local groups only on computers that do not belong to a domain.

You can use local groups only on the computer where you create the local groups. Although you can set up local groups on domain client computers and member servers, it is not recommended. Using local groups on domain computers prevents you from centralizing group administration. Local groups do not appear in Active Directory services, and you are required to administer local groups separately for each computer.

• Use local groups to control access to resources on the local computer and to perform system tasks for the local computer.

In order to allow SharePoint Portal Server to crawl content, you must carefully plan your group strategy for securing content and domain structure.

SharePoint Portal Server limits you to 200 SIDs that you can associate with a given role on a folder. Consequently, in large deployments, strategic planning of groups allows you to grant users appropriate access to content.

Using Security Groups in Windows 2000

Figure 8.3 illustrates the recommended strategy for granting users permission to resources.

Figure 8.3. Applying group strategy in a single domain

When you use groups in a single domain, you use the AGDLP strategy. You can describe the AGDLP strategy as follows: You put user accounts (A) into global groups (G), put the global groups into domain local groups (DL), and then grant permissions (P) to the domain local group.

When you create the groups, Windows 2000 recommends the following strategy:

• Identify users with common responsibilities and add the user accounts to a global group. For example, in a sales department, add user accounts for all sales employees that use the same resources to a global group called Sales.
• Determine whether you can use a built-in domain local group, or if you need to create one to provide users with access to domain resources. For example, if you want users to be able to print to a shared color printer in the domain, create a domain local group called Color Printer Users.
• Make all global groups that share the same access needs for resources members of the appropriate domain local group. For example, add the appropriate global groups, including Sales, to the domain local group Color Printer Users.
• Grant the required permissions to the domain local group on the domain controller. You grant permissions at the resource. For example, grant the necessary permissions to use color printers to the Color Printers Users domain local group.

If there are parallel groups in multiple domains, make sure that the names are parallel and that they reflect the domain names. For example, if there is a group for managers in each domain, these groups should use a similar naming scheme, such as Managers USA and Managers Australia.

Windows 2000 allows you to customize the type of access a specific user or group has to a specific resource. It also allows you to customize how a given resource inherits access rights from parent resources. Although this provides you with maximum flexibility and control, it can lead to increasingly complex security configurations.

SharePoint Portal Search secures searching across remote content sources, so that search results only include documents that users are actually allowed to view and access. In order to provide this functionality, the computer running SharePoint Portal Server must be able to resolve an ACE used to grant access.

If you use local groups to grant permissions to documents stored on remote NTFS file shares, SharePoint Portal Server cannot resolve the local group ACE. Therefore, SharePoint Portal Server does not return documents from those file shares in search results. You must grant permission through another mechanism, such as domain local groups or global groups, to allow access to the content.

You must secure content on remote NTFS file shares by using a compatible group strategy.

Applying Security Groups to SharePoint Portal Server

SharePoint Portal Server simplifies administration by allowing you to assign users and groups to a specific set of roles according to task. This approach provides more flexibility for the content owner. You can use large, natural grouping where appropriate. Some groups lend themselves to roles. For example, you may assign the Windows 2000 Users group to the role of author. Depending on your security model, you may assign smaller global groups to the role of coordinator.

With enhanced folders, SharePoint Portal Server modifies the specific access that a user has for a document according to the state of the document.

Security Groups in a Single Domain

You can apply the AGDLP strategy when deploying SharePoint Portal Server within a single domain whether operating in a native or mixed-mode environment.

In this situation, you put user accounts (A) into global groups (G), put the global groups into domain local groups (DL), and then grant permissions (P) to the domain local group.

Security Groups across Multiple Domains

When deploying SharePoint Portal Server across multiple domains in a native-mode environment, you can secure content by using universal groups as part of the group strategy. You put user accounts (A) into universal groups (U), put the universal groups into domain local groups (DL), and then grant permissions (P) to the domain local group.

When deploying SharePoint Portal Server across multiple domains in a mixed-mode environment, you must establish an appropriate trust relationship across domains. For SharePoint Portal Server to access content in another domain, you must establish a one-way trust where the other domain trusts the domain where you deploy SharePoint Portal Server. In addition, you must modify the group memberships to include the account used by SharePoint Portal Server.

In this case, SharePoint Portal Server successfully crawls content on a different domain. However, users from that domain have only limited access to content on SharePoint Portal Server. To provide these users with a different level of access, you must establish a two-way trust.

Example

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.

• In a native-mode environment, you can use universal groups to grant access permissions to resources that are located in either domain. This greatly simplifies the administration process.

  In this situation, Server A can crawl content from Server B and make it available to users from Domain A who are members of the appropriate universal group.

• In a mixed-mode environment, you want to establish a one-way trust where Domain B trusts Domain A.

  In this situation, Server A can crawl content from Server B and make it available to users from Domain A assigned to the appropriate security groups.

For information about establishing trust relationships in a Windows NT 4 environment, see Appendix B.