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:-

• CoInitializeSecurity(…)
• CoSetProxyBlanket(…)

I chose the CoInitializeSecurity way, and so set the parameters appropriately which involves the following structs:-

• SOLE_AUTHENTICATION_LIST
• SOLE_AUTHENTICATION_INFO
• SEC_WINNT_AUTH_IDENTITY

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!