This sample shows a DCOM server running inside of a windows container that supports Kerberos authentication (using gMSA). The sample requires a Windows domain and container host which is properly configured for gMSA authentication, as described in the windows-containers-AD repository.
An additional proof of concept example is included in the DcomTestExe directory, which tests anonymous DCOM access between containers using the DcomTest Sample app from microsoft.
All of the examples can be built and run using the test.ps1 script in the root of the repository. The docker images may be built separately using the build.ps1 script. The tests make use of pester to build and test the client/server containers against each other.
For debugging purposes the client and server can both be run outside of docker using visual studio. Open DcomContainerSample.sln as an administrator and set DcomClientApp as the startup project, and then build and debug. The default configuration will activate the COM server in the same process as the client, as opposed to configuring and using the DcomServerApp.
-
Pester tests return
access deniedfor the DcomTestExe test that it runs. Not sure if this is a networking problem, or an installation problem. Maybe the reg file is not setting up anonymous auth correctly? Or maybe internal networking uses NAT features which don't work right for DCOM. I tried transparent networking and it fails as well (but maybe with a different error?) -
Once DcomTestExe works anonymously, continue filling out
pester.ps1to test anonymous access betweenDcomClientAppandDcomServerImplin two separate containers. -
Once that works, write
DcomServerAppand use that as the container entrypoint forDcomServerImplinstead (this is more equivalent to how our apps are intialized in production). -
Once that works, write another test that uses a gMSA for authentication between the two containers (this will require a test domain setup either locally or on azure).