Hi,  
  
A remote DCOM gives access denied error in our program after the server  
  
is upgraded to the SP1. The article "DCOM Security Enhancements" seems  
  
to address this issue  
  
(http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/BookofSP1/4c9a2873-2010-4dbb-b9dd-6a7d1e275f0f.mspx).  
  
But I am quite confused. Here are my questions:  
  
1. Is the "Computerwide restriction" the same thing as "machine-wide"  
  
restriction used before but with different semantics?  
  
2. If I am so desperate to change the "computerwide" settings, should I  
  
do it the same way as change "machine-wide" settings? (through  
  
Component Service, properties of the interested machine)  
  
3. What is the difference between launch permission and activation  
  
permission? To me, both are the permissions that allow a client to  
  
create a server object on the server machine.  
  
4. Most confusing part is here. If a remote client does not have the  
  
remote launch/activation permission, how could s/he possibly access a  
  
remote DCOM object? The default setting is that Everyone does not have  
  
the remote launch and activation permission but has the remote access  
  
permission. And the doc mentions that:  
  
"By default, the Everyone and Anonymous groups are granted remote  
  
access permissions. This enables most COM client scenarios, including  
  
the common case where a COM client passes a local reference to a remote  
  
server, in effect turning the client into a server."  
  
What does this paragraph really mean? Is it in some language other than  
  
English?  
  
Thanks for your help  
  
hshen

I will take a try at your questions, but do not take these  
  
as the final word . . .  
  
<hshen.ca@gmail.com> wrote in message  
  
news:1137379643.986369.318610@f14g2000cwb.googlegroups.com...  
  
I take computer-wide and machine-wide as stating the same.  
  
However, I am not familiar with what you refer to as "used before".  
  
The service pack added a new layer that did not exist before.  
  
Previously there was (and there still is) a set of default permissions  
  
for launch and access.  Previously (and still) components could have  
  
set their own component unique permissons for these, or could not  
  
and so default.  The new layer controls use of defaulted components.  
  
The Component services UI was enhanced for the new settings  
  
I take activation and launch to be the same, i.e. to spin up a server obj.  
  
some other security principal launched the factory, and then, with it  
  
running the account with only access does just that  
  
That a reasonable question.  
  
I take it to mean, we are controlling how a COM factory gets spun up,  
  
but are not controlling what happens to it at that point.  
  
Again, this is for components with their security defaulted.

Hi Roger,  
  
Thanks for your quick response. My comments and questions are inline  
  
Thanks!  
  
hshen  
  
Roger Abell [MVP] wrote:  
  
"Before" means before SP1. I knew that the machine-wide default  
  
settings are there before SP1. But the semantics are different before  
  
and after, that is the source of trouble (or benefit) of SP1. Before  
  
SP1, the default settings take effect only when the components do not  
  
customize their own settings. In SP1, the default settings play the  
  
role as bottom line - means that if the default settings denies the  
  
request, the request will fail no matter what is set in the component  
  
customized settings.  
  
Then, why does Microsoft bother to have two separate permissions for  
  
launch and activation (for Windows Server 2003 SP1 as well as Windows  
  
XP SP2)?  
  
Still not clear to me. Do you mean that the client program uses one  
  
account with high privilege to launch/activate the remote object and  
  
then fallbacks to common user account to access the object? I don't  
  
think that this scheme provides any security benefit. Where does the  
  
client program get the high privilege security credential? If the  
  
client program can get it without human involved, a malicious user can  
  
get it either (at least in theory).  
  
Another possible scenario is that somebody launches the factory in  
  
remote server, and somehow let the remote access the factory object. I  
  
am puzzled how to do it?

Thanks!  
  
Roger Abell [MVP] wrote:

Thanks for the clarification.  
  
On your last point, it is not the client application that needs to do  
  
everything  
  
(launch and then access).  The component can be instanciated by other code  
  
in different security context, perhaps not ever remote.  
  
Access controls access - which implies component has been spun up.  
  
Remote client does not have to do it all.  Consider case of a service that  
  
makes its remote methods available by instancing components.  You do  
  
not want the remote client to cause the instancing, but only the use.  
  
On the Launch vs Activation you are right, things really are clouded in  
  
the docs, are they not.  I notice in current MSDN on-line lib one finds  
  
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/c9f6d06c-da24-48ea-908a-2462c33f7ee3.asp  
  
<quote>  
  
Activation security (also called launch security) helps control who can  
  
launch a server. Activation security is automatically applied by the Service  
  
Control Manager (SCM) of a particular machine.   . . .  
  
</quote>  
  
but one can also find  
  
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/3474f8ad-f041-4886-ad39-ff0603c5c69e.asp  
  
<quote>  
  
If the client does not specify an explicit COAUTHINFO structure and  
  
instead sets the pointer to NULL, COM will attempt to authenticate the  
  
client. If it cannot authenticate the client, COM checks the launch  
  
permission  
  
security descriptor to see whether there is a NULL DACL or an ACL that  
  
allows access to Everyone. If this check succeeds, the server is launched.  
  
Therefore, even if the client does not specify a COAUTHINFO structure,  
  
unsecure activation may take place when the server allows it.  
  
</quote>  
  
Roughly speaking (as a non-Com-programmer) it seems to be saying that  
  
to use a component there are two things involved.  Getting use of the  
  
methods  
  
of the component and the other getting the RPC transport established for  
  
this.  
  
It is sounding like activation is a function of the last.  If it is not in  
  
use then only  
  
the prior call based security governs what does or does not happen, while if  
  
it is in use it functions much like share level permissions do for remote  
  
access  
  
to NTFS storage in that one must first pass that check and it sets limit of  
  
what  
  
call-level can allow.  
  
You might want to check the notes for the coserverinfo structure,  and  
  
notice  
  
how it may be used to alter the credentials or auth methods used by RPC and  
  
hence subsequent COM calls  
  
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/88c94a7f-5cf0-4d61-833f-91cba45d8624.asp  
  
Again, I am not a COM programmer.  
  
<hshen.ca@gmail.com> wrote in message  
  
news:1137422967.874150.287990@o13g2000cwo.googlegroups.com...