Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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

2 Answers 2

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. –  user2213 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
    
"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 at 13:51
    
@Ben that is a surprising statement, contrary to what is otherwise known. Do you have a reference for that? –  AviD Jan 16 at 15:21
    
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 at 15:46

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.

share|improve this answer
    
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 at 15:25
    
@AviD, I suggest you check the links I gave above. –  Ben Jan 16 at 16:00

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.