Probleme mit der Sicherheit

[Robert Gajcy]

Habe eine Anwendung geschrieben, die einen DCOM-Server benutzt.
Nach diversen Anläufen und Problemen mit der Sicherheit habe ich das ganze zum Laufen bekommen. Ich habe auf der ClientSeite mit
<b>CoInitializeSecurity</b> die Sicherheitsregeln festgelegt.<br>Nun gibt es ein Problem, weil in der Anwendung andere Automation-Server aufgerufen werden. Speziell handelt es sich hierbei um Excel. Beim Aufruf bekomme ich eine Fehlermeldung <b>Schnittstelle wird nicht unterstützt</b>.<br>Nun habe ich schon hier in Forum nach Lösungsansätzen gesucht und die Funktion <b>CoSetProxyBlanket</b> als mögliche Lösung gefunden. Doch leider bekomme ich das ganze nicht wie gewünscht zum Laufen.Habe nun CoInitializeSecurity rausgenommen und dafür CoSetProxyBlanket für das eine Interface (vom DCOM-Server) verwendet<br><br>
<pre>
<b>const</b>
RPC_C_AUTHN_NONE = 0;
RPC_C_AUTHN_WINNT = 10;
RPC_C_AUTHZ_DEFAULT = $FFFFFFFF;
RPC_C_AUTHN_LEVEL_NONE = 1;
RPC_C_IMP_LEVEL_ANONYMOUS = 1;
RPC_C_IMP_LEVEL_IDENTIFY = 2;
EOAC_NONE = 0;
<br>
<b>procedure</b> TServerClient.setServerIPAndCreate(IP: String);
<b>var </b>
aIUnk : IUnknown;
<b>begin </b>

aIUnk:=CoObjectMappingServer_.CreateRemote(ServerI P);
<br>
OleCheck(CoSetProxyBlanket(
aIUnk,RPC_C_AUTHN_WINNT,RPC_C_AUTHZ_DEFAULT,nil,RP C_C_AUTHN_LEVEL_NONE,RPC_C_IMP_LEVEL_IDENTIFY,nil, EOAC_NONE));
<br>
FServer:= aIUnk as IObjectMappingServer;
<br>
OleCheck(CoSetProxyBlanket(
FServer,RPC_C_AUTHN_WINNT,RPC_C_AUTHZ_DEFAULT,nil, RPC_C_AUTHN_LEVEL_NONE,RPC_C_IMP_LEVEL_IDENTIFY,ni l,EOAC_NONE));
<br>
<b>end;</b>
</pre>

Excel-Anwendung startet nun wunderbar, doch die Callbacks vom Server an den Client gehen verloren....
Bitte um Hilfe!

[Andreas Kosch]

Hallo,

in der letzten Zeit hat Microsoft die Systemsicherheit von Windows immer stärker angezogen, um das Problem der zu häufigen (erfolgreichen) Attacken anzugehen. Eine Auswirkung davon betrifft den Sonderfall, wenn ein Client über DCOM auf einen Server zugreift, der <b>nicht</b> der gleichen Domain (bzw. zur Trusted Domain) gehört. Wenn der Client die DCOM-Sicherheit global zu niedrig hängt, werden nun die direkten lokalen Automation-Aufrufen zu "kritischen" Anwendungen automatisch geblockt. Erst dann, wenn die globale DCOM-Sicherheit hoch bleibt, sind lokale Aufrufe erfolgreich. Daber aber in dieser Konfiguration der Client erfolgreich auf den DCOM-Server in der fremden Domäne zugreifen kann, muss er nun <b>alle</b> Interface-Zeiger über CoSetProxyBlanket einzeln setzen.

Im Fall eines Callbacks vom Server zum Client gilt dies auch für den Server - denn bei DCOM gilt das "Wasserstands-Prinzip", bei dem der jeweils höchste Sicherheits-Wert auf einem Rechner das Verhalten der kompletten Aufrufkette festlegt