From: Vangrunsven, Emile (EVangrunsvenFEICO.COM)
Date: Sat Apr 12 2003 - 18:41:19 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi Henk,

Thanks, I understand what you say. We use W2K. Except when you say "use a library application to do per dll authentication settings for your client dll". I am not sure if I correctly interpret this. Do you say that I can control authentication settings for my dll, regardless of the settings of the client exe in which we live? (If so, yes, this would of course solve the problem.) I was led to believe that this is not possible. They tell me since the client exe has called CoInitializeSecurity, we have to live with whatever it has set up, other than controlling security on individual interfaces in our dll (which will not help us with the connection points). I could of course (some suggest this) create a middle man exe in between the embedded system and the client dll, but would (I think) not solve the fundamental problem, which is have a NONE process call into a DEFAULT process. We can even forget events for that matter. Even if I have two servers with regular interfaces, the one configured as NONE will always fall victim to the blanket negotiation instituted by the DEFAULT server. I can therefore envision that even if the group producing the client exe changes to NONE so that my problem is solved, they will most likely have problems with other processes they deal with (third party software) where things now go wrong. We would just move the problem upstream. Unless there is some tool or software out there (is that what you say?) to control my dll security regardless of the exe I live in, I would almost ((for certain?) conclude you can not use DCOM to move some bytes in and out of an anonymous black box.

Emile

P.S. I'd like to say hello to Frank, but I'm not aware of a Frank here in the United States, there are people called Frank in our company in the Netherlands.

P.P.S. Als je tenminste Philips (Elektronen Optiek) in Acht bedoelt, ik heb daar ook nog een paar jaar gewerkt.

-----Original Message-----
From: Henk de Koning [mailto:henkkCOMPLEXIT.COM]
Sent: Sunday, April 13, 2003 3:10 AM
To: DCOMDISCUSS.MICROSOFT.COM
Subject: Re: dcom, atl, security and connectionpoints

As a matter of fact, no it cannot be done.

With the connection point, your client.exe is now the server, and (presuming
you are on NT4) since it sets it low watermark effectively to CONNECT, when
you try to change the proxy blanket on the server to set it to NONE, your
calls will come in to the client process under its low watermark, meaning
COM will fail the call without the client ever seeing it.

If you are on Win2K, use a library application to do per dll authentication
settings for your client dll. Also, on Win2K providing level default will
trigger a blanket negociation, but you will essentially be victim of the
security service provider you happen to be using.

-- Henkk

PS: say hello to Frank for me ?

----- Original Message -----
From: "Vangrunsven, Emile" <EVangrunsvenFEICO.COM>
To: <DCOMDISCUSS.MICROSOFT.COM>
Sent: Saturday, April 12, 2003 1:48 AM
Subject: dcom, atl, security and connectionpoints

> Our company has a client exe, whose security settings
(CoInitializeSecurity with authentication level RPC_C_AUTHN_LEVEL_DEFAULT )
our software group does not control (although obviously it's also written by
people in my company). We have an in-proc client dll in this client exe that
we do control. This client dll talks to an embedded system using DCOM. The
(ATL) servers run in the embedded system (and use CoInitializeSecurity with
RPC_C_AUTHN_LEVEL_NONE). We provide the embedded system, so we have full
control over servers and client dll. We have effectively turned off security
and everything is working fine. Because of CoInitializeSecurity being out of
reach, we turn of security in the client dll on a per interface basis (the
standard server proxies provide IClientSecurity support). The only thing
that we haven't managed so far is turning off security on the
connectionpoint interface between server and client dll. Has anybody ever
done this? So far, I haven't been able to find any references or hints,
other than Keith Brown eluding to the fact that yes, it can be done.
>
> Emile Vangrunsven
> FEI Company
> 2345 NW Amberbrook Drive #100
> Beaverton, OR 97006
> phone 971-327-2022
> fax 503-748-3279
> email evangrunsvenfeico.com
> web www.feicompany.com
>
> ----------------------------------------------------------------
> Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
> contains important info. Save time, search the archives at
> http://discuss.microsoft.com/archives/index.html .
> To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM
>

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]