Establishing client identity for COM object activation and subsequent method calls is pretty easy right? Right, the identity used by default is that of the calling thread or process.
I had a need for a COM client to use a different identity for [remote] COM object activation and method calls than that of the host client process. There is a couple of APIs which can be used to accomplish this:-
I chose the CoInitializeSecurity way, and so set the parameters appropriately which involves the following structs:-
Having populated these structures and called CoInitializeSecurity, I kept getting E_INVALIDARG, the parameters where definitely correct, I couldn’t figure it out.
Eventually, after much head stratching, I found the problem. The SEC_WINNT_AUTH_IDENTITY structure is available in ANSI and UNICODE varieties, I happened to be using the ANSI version via the compilers macro preprocessor – since the client application was an ANSI build.
I changed my code to use the UNICODE version, SEC_WINNT_AUTH_IDENTITY_W, compiled and it worked fine.
Seems that using the ANSI version of SEC_WINNT_AUTH_IDENTITY when calling CoInitializeSecurity just doesn’t work, for some undoubtedly arcane reason, on the other hand perhaps it’s just a bug!