So today we’re going to cover the basics of COM and DCOM. The key word here is basic – if you need to get into a depth discussion about how your custom components are working (or not working in some cases!) and your code, then you should be working with Developer Support rather than Platforms Support. It’s important for administrators to understand the concepts behind COM and DCOM – even if they never write a single line of code.
So to get started, let’s quickly outline what COM & DCOM are. The Component Object Model (aka COM) is a platform-independent, object-oriented system to create software components that can interact. A COM application usually consists of an executable file and additional components such as DLL files that are used to perform various functions. The key feature of COM is that it is language-independent and promotes the reuse of components from different vendors. DCOM (Distributed COM) is an extension of COM that allows component interaction across machine boundaries – across the LAN, WAN or even over the Internet.
So what actually constitutes a component? A component is nothing more than a piece of code that exists as an executable file or DLL. A COM component can act in either a client (requesting service or functionality from another component) or server (providing service or functionality to other components) role.
COM/DCOM is dependent on the following services:
- Remote Procedure Call (RPC) Service: Provides the basic communication needed for COM+ as well as other areas of Windows to function properly.
- Distributed Transaction Coordinator (DTC) Service: Coordinates transaction between components of a distributed system.
- COM+ Event System Service: Automatically distributes COM+ events to subscriber COM+ components.
- COM+ System Application Service: Whenever a COM+ application is activated, it must register itself with the COM+ System Application.
COM architecture includes a wide range of security features for authentication and authorization of communication between components. DCOM-enabled applications can dictate their own settings for security using the CoInitializeSecurity function. Individual application security can be configured using the DCOMCNFG utility.
DCOM distinguishes between four fundamental aspects of security:
- Access security
- Launch security
- Connection policy
Access Security protects the objects against unauthorized access. Sometimes only authorized users are supposed to be able to connect to an object. In other cases, non-authenticated or unauthorized users might be allowed to connect to an object, but must be limited to certain areas of functionality.
Launch Security protects the server machine itself. Since all COM objects on a machine are potentially accessible via DCOM, it is critical to prevent unauthorized users from creating instances of these objects. This protection has to be performed without any programmatic involvement of the object itself, since the mere act of launching the server process could be considered a security breach and would open the server to denial of service attacks. The COM libraries thus perform special security validations on object activation. If a new instance of an object is to be created, COM validates that the caller has sufficient privileges to perform this operation. The privilege information is configured in the registry, external to the object.
Another aspect of distributed security is that of controlling the object. Since an object performs operations on behalf of arbitrary callers, it is often necessary to limit the capabilities of the object. One obvious approach is that of making the object assume the identity of the caller. Whatever action the object performs—a file access, network access, registry access, and so on—is limited by the caller’s privileges.
DCOM currently offers two fundamental choices with regard to data protection: integrity and privacy. Clients or objects can request that data be transferred with additional information that ensures data integrity. If any portion of the data is altered on its way between the client and the object, DCOM will detect this and automatically reject the call. Data integrity implies that each and every data packet contains authentication information.
Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1 introduces new security features with respect to COM / DCOM. These include:
- System-wide (default) settings Group Policy Object
- Setting limits to provide an extra layer of security. These limits take precedence over application-specific and default security settings.
- Access permissions to allow administrators to control which users are allowed or denied Local or Remote Access
- Launch and activation permissions to control which users are allowed or denied Local Launch Access or Remote Launch Access
And that wraps up our Overview of COM and DCOM for Administrators. In a future post, we will build on these concepts as we discuss troubleshooting COM and DCOM. Until next time …
- COM Overview on Microsoft.com
- COM Start Page
- COM+ Start Page
- DCOM Technical Overview
- MSDN Article on DCOM Architecture