The basic Microsoft Windows security model focuses on two areas: authentication and access control. Authentication is usually encountered when a user attempts to log on to a network or call a process on another machine. In such cases, the system wants to be sure that the user is who she claims to be. Access control in Windows enables applications to selectively grant or deny certain users access to specific services. While any executable code presents a potential security risk, Windows mitigates this risk by limiting the access permissions of a given process, depending on the user account it is running under. To this end, Windows maintains an access token for each user logged on to the system; the access token contains information identifying the user and the user groups to which the user belongs and information about other privileges that might be available. A copy of this access token is later associated with each process launched by that user. The operating system selectively grants or denies access to system services by comparing the access token of the running process with the security information attached to the system object that the user wants to access.
Each user and user group is identified in the access token by a unique value called a security identifier (SID). Every system object—such as a thread, a mutex, a semaphore, an event, or a file—can contain a security descriptor that includes the SID of the object's owner and of the primary user group to which the owner belongs. Also stored in this security descriptor is the discretionary access control list (DACL), which controls access permissions, and the system access control list (SACL), which specifies operations on the object that should generate audit messages. Both types of access control lists (ACLs) are really linked lists of access control entries (ACEs). Each ACE in a DACL either grants or denies a certain permission to a specific user or user group. The system checks each ACE in the DACL to determine whether permission has been granted or denied. Once it makes the determination, it does not examine the remaining ACEs, as shown in Figure 18-1.
When you're learning about the COM+ security model, it is helpful to understand what resources must be secured. Here are the primary goals of the COM+ security model:
Figure 18-1. Checking an object's DACL to determine whether the client has the requisite permissions.
Activation control enforces who is permitted to launch components. Once a component has been launched, access control limits access to the component's objects. In some cases, it might be acceptable for certain users to have access to certain areas of functionality while other services of a component are restricted. For example, perhaps all users connecting over the World Wide Web are permitted to access certain areas of the component's functionality, but other services are reserved for authorized users only. Authentication control ensures that a network transmission is authentic and protects the data from unauthorized viewers. Different authentication levels can be set so that all the data is encrypted before being transmitted. Identity control determines the security credentials under which the component will execute. These credentials can be a specific user account configured for this purpose or the security credentials of the client application.
Security information for COM+ components is configured in two ways: using declarative security and using programmatic security. Declarative security settings are configured in the registry external to the component. A system administrator typically configures declarative security. Programmatic security is incorporated into a component by the developer. Activation, access, authentication, and identity security settings for a component can be configured in the declarative manner via the registry, using a utility such as the Distributed COM Configuration utility (dcomcnfg.exe). Access and authentication security can also be controlled programmatically by using several interfaces and helper functions provided by COM+. Activation and identity security cannot be controlled programmatically because these settings must be specified before a component is launched.
Perhaps you're wondering why COM+ needs a special security model. Windows is a secure operating system platform, so why can't COM+ components simply leverage that security model? The answer is that they can—but they shouldn't. As you know, the design of COM+ is not tied to the design of Windows in any way. In addition to the various flavors of Windows, COM+ components can run on many other operating systems. Most of these operating systems have their own notion of security, and certainly none support the security functions of the Win32 API. In fact, neither Windows 95 nor Windows 98 supports many of these security functions. COM+ requires a security model that can be supported on all platforms on which COM+ services are available.
COM+ defines a higher-level security model by abstracting the underlying security mechanisms of both Windows and Remote Procedure Calls (RPCs)—which explains why many of the security flags used by COM+ have been borrowed from the RPC security infrastructure. Aside from platform-independence, the COM+ security model insulates component developers from the Windows and RPC security mechanisms so that as these technologies evolve, components will be able to derive benefits from the new security services automatically. This flexible security model is built around the Security Support Provider Interface (SSPI), a standard API designed to support the security needs of applications running in a distributed environment.
The design of the SSPI can be compared with the architecture of Open Database Connectivity (ODBC). ODBC was designed to insulate database application developers from a specific back-end database server by offering numerous drivers that implement the standard ODBC API for use by client-side developers but that communicate with a specific back-end database server using the proprietary interface that the server understands. To support the varying security requirements of different applications, vendors can implement the SSPI API in a dynamic-link library (DLL) called a Security Support Provider (SSP). An application written to work with one SSP would require few or perhaps no modifications to work with another SSP. All SSPs must implement the SSPI, but internally they are free to use different mechanisms to enforce security.
The following sections provide an overview of the primary SSPs available to COM+ applications: NTLMSSP, Kerberos, and Snego. Understanding the general features of each authentication package can help you make a choice that is right for the security needs of your application. Once you choose a security package, however, COM+ insulates you from the internals of the various authentication protocols, so this chapter will focus primarily on the higher-level security model defined by COM+.
Prior to Windows 2000, only one SSPI-compliant SSP was available—the Microsoft Windows NT LAN Manager Security Support Provider (NTLMSSP). This security package is based on the NTLM authentication protocol, a challenge-response protocol that authenticates clients. In the challenge-response model, the server issues a challenge to the client that consists of some data. The client uses an encoded version of the user's password to encrypt the data provided by the server. This encrypted challenge is then sent back to the server, where it is decrypted and compared with the original data sent to the client. If the data are the same, the user is authenticated. Note that the user's password is never sent across the network by the NTLM challenge-response protocol. For this reason, the server cannot use the client's password during impersonation to access network resources for which the client might have permissions.
Windows 2000 offers both NTLMSSP and a new SSP that implements the Kerberos network authentication service version 5. Kerberos is a more sophisticated authentication protocol than NTLMSSP that supports features such as mutual authentication and the delegation of security information from one machine to another. This can allow a server process to cloak itself with the client's identity when making remote calls to another service. In Windows 2000, Kerberos is the fundamental security protocol of the operating system.
While NTLMSSP and Kerberos are real authentication packages that support the SSPI, the Snego (Simple Negotiation Mechanism) package is used to negotiate between real SSPs. This pseudo-SSP does not provide any actual authentication features of its own—its only use is to help applications select a real SSP. Currently, applications can use Snego to negotiate between the NTLMSSP and Kerberos protocols. For Snego to work properly, both the client and server must use it. Snego selects an actual authentication protocol by comparing the authentication packages available on the client machine with those available on the server machine.