Thoughts from the EPS Windows Server Performance Team
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:
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 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:
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 ...
- CC Hameed
PingBack from http://www.ditii.com/blog/2007/06/08/com-and-dcom-for-administrators/
Great thing on COM/DCOM. Would be great if you could also explain the COM+ related services, what role they play.
Waiting for your next blog!
On your next blog, it would be awesome if maybe you could go into some specifics on controlling security for both COM and DCOM.
Back in June, we published our post on Basic WMI Testing . Today we're going to go over some common issues
Sorry if I'm too harsh,
but I've never seen COM and DCOM do anything useful. They don't provide unique functionality (that actually works in practice), it's just some abstract complication of life for everyone. Bureaucracy - the Administration (in general sense - administration of Windows) keeping busy with itself instead of solving users' problems. Unnecessary overhead.
Like some old bureaucrat creating some problems and solutions in order to justify his workplace.
Windows wouldn't even function without COM\DCOM Einstein.