Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 2 down vote favorite
1

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?

share|improve this question

1 Answer

up vote 1 down vote

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.

share|improve this answer
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. – Antony Vennard Oct 14 '12 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 '12 at 13:51

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.