DCOM access permission / authentication level with .NET client

I was hoping someone could shed some light on the following behavior I
have noticed...

We have a .NET application acting as a client to a DCOM server. Our
DCOM server is configured to run as a particular user. It's
authentication level is set to Connect, and server specific access
permissions are defined to allow "Everyone."

The .NET client will act as a server due to the fact that callbacks
are used (Connection Points). It is my understanding that .NET
components will use default DCOM security. Here is the behavior I am
seeing (with the client and server on the same PC):

DCOM Defaults:
- authentication level: none
- default access permissions: SYSTEM, SELF (my PC's defaults)

Result: This works

DCOM Defaults:
- authentcation level: connect
- default access permissions: SYSTEM, SELF, user that is configured to
run the DCOM server

Result: This works

Does setting the authentication level to none cause access permissions
to be ignored? If not, how come I am not required to add the user
that is configured to run the server back into the access permissions
list? Is the .NET client not really using the default access
permissions? Per the following article:

http://www.codeguru.com/cpp/com-tech/activex/security/article.php/c5557/

"Authentication=None means you're not concerned about security and
want to allow anonymous access to your server. (If you go this route,
remember to grant launch and access permissions to Everyone;
otherwise, no one will be able to use your COM server.)"

.

Relevant Pages

  • Re: Remote DCOM on WinCE 6.0
    ... as in the client case. ... allowing the selected user name to start the server or, at least, access the ... You have to make sure that your code to actually create the remote ... Once you have all of that, run your DCOM client application in the ...
    (microsoft.public.windowsce.embedded)
  • Re: DCOM security in Windows Server 2003 SP1
    ... it's unfortunate that they chose a different name for it in the server edition if it's indeed the same thing. ... DCOM by one account 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? ... 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. ...
    (microsoft.public.win32.programmer.ole)
  • Re: Remote DCOM on WinCE 6.0
    ... Now we're focussing on loading the server ... as in the client case. ... applet's Network ID tab to be a user name and password that the remote ... Once you have all of that, run your DCOM client application in the ...
    (microsoft.public.windowsce.embedded)
  • Re: Remote DCOM on WinCE 6.0
    ... In fact, the WinCE device will run the server, not the client. ... You have to make sure that your code to actually create the remote object ... Once you have all of that, run your DCOM client application in the debugger ...
    (microsoft.public.windowsce.embedded)
  • Re: COM question
    ... A DLL-based server with a custom interface *not* involving any weird ... This server will run on Windows CE 3 on this device and can be ... A client for above server compiled for Windows XP and connecting to the ... The CE device has the DCOM flag in the registry ...
    (microsoft.public.windowsce.platbuilder)