Re: DCOM security in Windows Server 2003 SP1

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Thanks Kim. My comments and more questions inline.

Kim Gräsman wrote:
> Hi hshen,
>
> > I don't quite understand what is the difference between the launch
> > permission and activation permission.
>
> Launch permission is necessary to start a COM server, and activation permission
> is required to create an object in an already running server.
>
Does this mean that activation is inevitable for a client to access an
COM object?

> > Back to computerwide permission. [...]
>
> I'd just thought I'd comment here: this sounds like DCOM Limits in XP SP2,
> it's unfortunate that they chose a different name for it in the server edition
> if it's indeed the same thing.
>
You are right. In Component Service, the settings of this
"computerwide" restrinction is done through "Edit Limits..." button in
W2K3 SP1.

> > Does this default computerwide
> > restrictions imply that a remote client can somehow get a reference to
> > the interface pointer without triggering "remote activation"
> > permission check? (otherwise, most of the remote client program will
> > fail as common end users only belongs "Everyone" group). How can I get
> > around this (without calling CoCreateInstanceEx() but still get the
> > Interface pointer)?
>
> I guess if you have a reference to an interface on some COM server on the
> machine already, and that interface could give you a new instance of of an
> object implementing the interface you want, that access permissions for the
> "returned" object's server should be enough. I'm not sure, though, and you'd
> still need to be able to launch the "returning" server, so I'm not sure if
> it helps.
>
Do you mean that in my client program, I have to activate the remote
DCOM by one account (through setting CoIntializeSecurity() or set
COAUTHINFO in COSERVERINFO in CoCreateInstanceEx()) with special
activation privilege, for example, a domain account in the newly
created build-in group "Distributed DCOM user", and switch back to the
identity that runs the client program after the activation? Ugly.

> The limits are really an administrative issue, so if you need them loosened,
> you should communicate that to the admin of the box your software is running
> on.
We made the DCOM and client programs. I don't think our customer would
like to grand remote activation permission to "Everyone" in the
computerwide restrictions or DCOM limits whatever it is called, just
because our client program fails.

> We distribute a white-paper with directions on how to set it up for our software.
>
> --
> Best Regards,
> Kim Gräsman

.

Quantcast