Summary
Following the fixes for #6 / #7 (DCOM + Kerberos object-exporter binding), I ran into a second, separate failure in the SCM activation step: IRemoteSCMActivator::RemoteCreateInstance returns E_FAIL (0x80004005) whenever the target is addressed by FQDN. The same call succeeds when the target is addressed by IP. This affects both NTLM and Kerberos — and since Kerberos requires an FQDN (for the SPN), it always hits this.
Environment
- Titanis (.NET 8), self-contained, running in a Linux (Debian 13) container.
- Targets: Windows Server 2019 (a domain member and a DC), AD domain.
- Auth: NTLM and Kerberos (domain-admin account).
Repro
Connect via DcomClient.ConnectTo and activate a COM object (e.g. the WMI Level1Login):
Host = "rsrch-dc.example.local" (FQDN) → RemoteCreateInstance → E_FAIL (0x80004005)Host = "10.0.0.103" (the same host, by IP) → OK
Stack:
System.Runtime.InteropServices.COMException (0x80004005): E_FAIL
at Titanis.Winterop.NtstatusExtensions.CheckAndThrow(Hresult hr)
at Titanis.Msrpc.Msdcom.ScmActivatorClient.CreateInstance(...) // ScmActivatorClient.cs
at Titanis.Msrpc.Msdcom.DcomClient.Activate[TInterface](...) // DcomClient.cs
at Titanis.Msrpc.Mswmi.WmiClient.ConnectTo(...)
Root cause
In DcomClient.ConnectTo, the name passed to new ScmActivatorClient(dcom, name) ends up as COSERVERINFO.pwszName in the RemoteCreateInstance request (ScmActivatorClient.CreateInstance → SecurityInfoData.pServerInfo). After #6 this is the FQDN (host).
The SCM seems to reject a non-self FQDN in pwszName:
pwszName |
result |
FQDN (rsrch-dc.example.local) |
E_FAIL (0x80004005) |
null / pServerInfo = null |
E_INVALIDARG (0x80070057) |
target IP (10.0.0.103) |
OK |
So pwszName must be a non-empty name the server recognises as "itself"; an FQDN is treated as a remote/foreign server and the activation fails.
Workaround / suggested fix
Pass the resolved IP of the target as the activation server name, while leaving the RPC bind / SPN on the FQDN endpoint (so Kerberos still works):
// DcomClient.ConnectTo, SCMActivator block
string activationName = host;
try { var a = System.Net.Dns.GetHostAddresses(host); if (a.Length > 0) activationName = a[0].ToString(); } catch { }
var scmClient = new ScmActivatorClient(dcom, activationName);With this, both NTLM and Kerberos succeed when the target is addressed by FQDN; /Wmi queries and a full software inventory return successfully against both a DC and a member server.
A cleaner fix might be to omit/normalise pwszName for self-activation, but passing null yields E_INVALIDARG, so a valid IP is the reliable value in my testing. Happy to send a PR if that's useful.
Summary
Following the fixes for #6 / #7 (DCOM + Kerberos object-exporter binding), I ran into a second, separate failure in the SCM activation step:
IRemoteSCMActivator::RemoteCreateInstancereturnsE_FAIL (0x80004005)whenever the target is addressed by FQDN. The same call succeeds when the target is addressed by IP. This affects both NTLM and Kerberos — and since Kerberos requires an FQDN (for the SPN), it always hits this.Environment
Repro
Connect via
DcomClient.ConnectToand activate a COM object (e.g. the WMILevel1Login):Host = "rsrch-dc.example.local"(FQDN) →RemoteCreateInstance→ E_FAIL (0x80004005)Host = "10.0.0.103"(the same host, by IP) → OKStack:
Root cause
In
DcomClient.ConnectTo, the name passed tonew ScmActivatorClient(dcom, name)ends up asCOSERVERINFO.pwszNamein theRemoteCreateInstancerequest (ScmActivatorClient.CreateInstance→SecurityInfoData.pServerInfo). After #6 this is the FQDN (host).The SCM seems to reject a non-self FQDN in
pwszName:pwszNamersrch-dc.example.local)E_FAIL (0x80004005)null/pServerInfo = nullE_INVALIDARG (0x80070057)10.0.0.103)So
pwszNamemust be a non-empty name the server recognises as "itself"; an FQDN is treated as a remote/foreign server and the activation fails.Workaround / suggested fix
Pass the resolved IP of the target as the activation server name, while leaving the RPC bind / SPN on the FQDN endpoint (so Kerberos still works):
With this, both NTLM and Kerberos succeed when the target is addressed by FQDN;
/Wmiqueries and a full software inventory return successfully against both a DC and a member server.A cleaner fix might be to omit/normalise
pwszNamefor self-activation, but passingnullyieldsE_INVALIDARG, so a valid IP is the reliable value in my testing. Happy to send a PR if that's useful.