The following paragraph from MSFT Best Practices for 2003 PKI says Windows 2000 authenticated via RPC vs 2003 that authenticates using DCOM

A CA running Windows Server 2003, Enterprise Edition, uses DCOM and Kerberos impersonation for authenticating requesters. It compares the client token against an access control list (ACL) set on the certificate template, as well as the DCOM enrollment interface on the CA itself, when a certificate is requested. A Windows 2000 Server CA uses remote procedure call (RPC) instead of DCOM to authenticate a requester. After the user is authenticated and authorized to gain access to the requested template, the CA can immediately process the request, as long as the user has the appropriate enrollment permissions on the template and if the CAs configuration is set to autoenroll.

Q: Can anyone explain how DCOM is different than RPC, in terms of Authentication and Authorization?

Some relevant screenshots of DCOM configuration (I don't have anything similar for RPC):

DCOM overview

DCOM Security screen

Why would software implementation choose DCOM over RPC? Is DCOM a superset of RPC or is it a separate entity?

3 Answers 3


Comparing DCOM to RPC is much like comparing HTTP to TCP.

In fact, DCOM actually uses RPC as the transport mechanism, when it is necessary to send the DCOM requests over the network.
RPC, as a transport protocol, does not have any built-in authentication mechanisms; DCOM has authentication as part of the protocol.

So, for Windows 2000, when the full suite of DCOM was not already available, the CA used the existing transport protocol, RPC, but had to develop a custom application protocol on top of it, to implement things like authentication and authorization.
For Windows 2003, with the pre-developed, pre-built, pre-tested, and pre-deployed DCOM available, they could just use the authentication and authorization mechanism already there.

This is why you can have the screenshot of the configuration of DCOM permissions (its built in to the OS), but not RPC (this does not exist as part of the protocol).
Moreover, since DCOM can use Kerberos as it's authentication mechanism, you can have things like limited impersonation which allows impersonation for authenticating requesters and compares the client token against an access control list (ACL), instead of the (CA) application having to custom roll its own.

Why would software implementation choose DCOM over RPC?

Because it's available.

  • 1
    Available rather understates the advantages of DCOM...! It's cross programming language (you can interface it from C++, Python, Powershell and all sorts of other environments). Many modern Windows API elements such as VSS are exposed via COM (and therefore DCOM). The fact of the matter is if you do something other than COM, you might end up using COM anyway for certain APIs, and then you need to ensure you have a working remote object interface. SOAP is not exactly known for its simplicity...! +1 though.
    – user2213
    Oct 14, 2012 at 13:18
  • @Ninefingers thanks, I was purposely understating it, as in "of course you would use it, if you can". I was not getting in to the advantages or features of DCOM, since that was not the question, but of course you are correct - there are many other advantages to DCOM, much like you would have to roll your own custom authentication DCOM takes care of a lot of plumbing for you.
    – AviD
    Oct 14, 2012 at 13:51
  • 1
    "RPC, as a transport protocol, does not have any built-in authentication mechanisms" DCE-RPC (on which ms-rpc is based) had security from the get-go, based on gssapi. So did ms-rpc from NT 3.1 onwards. DCOM uses the RPC authentication mechanisms, it does not invent its own.
    – Ben
    Jan 16, 2014 at 13:51
  • 1
    I have no idea why you think RPC has no security and "is just a transport". RPC works over multiple transports including TCP, UDP, SMB. See documentation for RpcBindingHandleCreate which takes security attributes and RpcImpersonateClient which makes use of security at the server end msdn.microsoft.com/en-us/library/windows/desktop/…, msdn.microsoft.com/en-us/library/windows/desktop/…
    – Ben
    Jan 16, 2014 at 15:46
  • 1
    And here from the Open Group: pubs.opengroup.org/onlinepubs/9629399/chap2.htm "Executing procedures across physical machine boundaries and over a network creates additional requirements for security. The RPC API includes an interface to the underlying security services."
    – Ben
    Jan 16, 2014 at 15:48

So the first question is how DCOM is different than RPC, in terms of Authentication and Authorization.

It is not. DCOM is built on top of RPC, and uses the underlying authentication mechanisms. DCOM is just a object-oriented extension to RPC. The analogy would be going from C to C++.

(You can see this in the debugger if you break on an incoming DCOM call. Your code is called from a stub DLL usually OLEAUT32.dll which is called from DCOM code which is called from RPC code).

As far as the article you quote goes, I think they are saying two things and muddling them.

  1. The new certificate services API is exposed by a DCOM, instead of as a flat rpc api.
  2. Since it uses DCOM, you can configure the DCOM object permissions to add an additional security check.

I don't think this is a deliberate design choice, it's more a side-effect of moving to the DCOM api, which in turn I am sure was motivated by making the api easier to use and manage.

the CA can immediately process the request, as long as the user has the appropriate enrollment permissions on the template and if the CAs configuration is set to autoenroll

So in order to prevent someone from enrolling, the correct way is to not give them the enrolment permissions on the template. Otherwise they could still enrol using the RPC api which still exists and works.

  • But RPC doesn't have underlying authentication or authorization mechanisms. In fact those provided by DCOM are based around the objects and interfaces - so it is completely incompatible with RPC (which is not aware of these concepts as are used in DCOM). I'm curious what you're referring to?
    – AviD
    Jan 16, 2014 at 15:25
  • @AviD, I suggest you check the links I gave above.
    – Ben
    Jan 16, 2014 at 16:00
  • Note that the links Ben are referring to start in this comment -- AviD's answer is not necessarily "above" this one.
    – jrh
    May 8, 2017 at 17:38

I had similar question about DCOM/RPC authentication. Having studied for several days, i got conclusion:

  1. Although DCOM/RPC claim they support several authentication mechanism, but ironically, DCOM/RPC themselves have not provided any inline login dialog(such as showed when access Shared Folder of server). DCOM/RPC client infrastructure have not provided any common way to store authentication settings externally(such as Windows Credential Store), this is very inconvenient.
  2. If client user is logged in as a domain user and server is also in the domain or the client user/password are also valid in server's local account db, the identity will be used by default.
  3. When DCOM/RPC use Named Pipe as transport, it is built on top of SMB protocol(port 445), the client must first authenticate by run command "net use \\SERVER /user:USER" then input password" or enter \\SERVER in explorer to login to server, otherwise simply "Access Denied".
  4. When DCOM/RCP use TCP transport(port 135), The client must set user/password... in COAUTHINFO of DCOM's CoGetClassObject or RPC_AUTH_IDENTITY_HANDLE of RPC's RpcBindingSetAuthInfo, otherwise treated as "ANONYMOUS LOGON" in server side, but most likely, finally cause "Access Denied" due to DCOMCNFG default ACL settings.
  5. DCOM component's authentication method and ACL settings can be controlled by DCOMCNFG external utility, at machine-level or component-level, at anytime. But RPC component can not, instead, they can only be defined when create RPC component.
  6. DCOM component's ACL settings can be further strengthened by use "Set Limits" in DCOMCNFG utility, "Set Limits" let use control maximum possible permissions forcibly for each DCOM component.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .