When you deploy COM objects in DLLs no security issues arise since DLLs run in the process of the caller. On the contrary, when you deploy your COM objects into an .EXE, you have to deal with such issues.

– (D)COM needs to know under what security principal (read identity) the process, where your COM objects lives in, has to be associated with.
– (D)COM wants to know other details as well, like who has the rights to launch and to access the COM objects and what’s the lowest level of security your COM objects must accept when it negotiates a connection from a caller.

These options can be set at run-time (but you have to deal with DCOM APIs) or can be configured at deployment time using the DCOMCNFG utility. If there are no security settings defined for your Component then (D)COM uses default access permission. The settings you have available in (D)COM for the Run as setting are:

– As interactive user: The process run under the identity of the user currently logged in the system. This settings is OK only during the development phase. If noone is logged in the system the object creation will fail.
– As the launching User: The process run under the identity of the caller process. This is not an advisable setting to set up a manageable security policy.
– As This User: In this case you have to specify a local or domain user. This is the best setting to go under a production environment.

If what is described above is clear, there is just one more thing to know when you come to MTS: Each MTS server package is a separate surrogate process where your DLLs run in. If you decide to deploy your dlls into an MTS Server package you have to remember that every access to the COM objects implemented in such dlls will have to deal with (D)COM security if the caller is outside the same MTS package.

This tip is taken from the FAQ list that Enrico mantains at his own home page (www.sabbasoft.com/mts_faq.htm).