We have a software product that uses DCOM to communicate between our Windows application and an embedded computer running Windows NT Embedded. We’re having a problem with DCOM communications when our Windows application is run on computers running Windows XP SP2.
The security enhancements that Microsoft added to keep the hackers out is also preventing our application from communicating with the embedded computer doing the low-level data acquisition. The embedded computer (aka the “Node”) is running Windows NT Embedded and communicates with our application (aka the “Host”) running anything from Windows 2000 to Windows XP SP2. We first encountered a communication issue when our customers started running Windows XP SP1 with a firewall turned on. We were able to convince most of our customers to turn the firewall off to get around this issue, but there are customers who just cannot do this. When some customers started running Windows XP SP2, we encountered a similar communication failure. Establishing a connection from the Host to the Node for passing commands is working. Our problem is with communications in the other direction. On the initial connection, the Host passes an interface pointer to the Node. The Node uses this interface to talk back to the Host. If the Host is running on Windows 2000 or XP SP1 (with the firewall turned off) everything works fine. However, under SP2, the bar has been raised. In addition to the standard DCOM permissions controlled by DCOMCNFG, Microsoft has added a second layer of DCOM settings under Group Policy ([url removed, login to view] Computer Configuration/ Windows Settings / Security Settings / Local Policies /Security Options. There is a known workaround to this second layer (adding Anonymous Logon to the DCOM Machine Access Restrictions), but this is not acceptable to our customer’s IT people.
So we really have 2 separate problems:
1) How to get DCOM working with a firewall turned on.
2) How to get DCOM working on Windows XP SP2 (without adding Anonymous Logon to the DCOM Machine Access Restrictions).
In both cases, we’re looking for a solution that will be acceptable to IT folks that balk at heavy handed approaches that broadly disable the security provisions of XP SP2.
We can provide the successful bidder with binary copies of our programs to test candidate solutions as well as technical details on the implementation of our DCOM communications. The required deliverable is a documented procedure to configure the computers properly for Windows XP SP1 and SP2 to allow DCOM communications. As stated above, the procedure must allow DCOM communications without creating an unacceptable security hole.