Is an SPN required when using Kerberos with DCOM?

Question

I'm using DCOM to provide various application services on a Windows network, using Kerberos to handle authentication. The system normally works fine, but I'm running into issues accessing the service from a separate (trusted) domain. Particularly, the service is unable to make callbacks to the client application, receiving the error "A security package specific error occurred". Also, if I tweak the service to specifically require Kerberos authentication (rather than using SNEGO/negotiate), the client can't even call into the server (again receiving "A security package specific error occurred").

The confusing thing is that things have been working for years without issue. However, a few things are different here, as compared to what we've done before. For one, the servers involved are running Windows 2008, which I have not previously used. Also, as noted above, the errors are only occurring when the service is accessed from an account from a separate domain, and previous usage has never attempted this.

Now to the question: I'm not using an SPN (service principal name) for this DCOM service, but some of the errors and event logs makes me think that might be the problem. However, all the docs I've found are unclear on whether this is correct, or how I would set up the SPN if I do need it. Does anybody know for sure whether an SPN is what I'm missing here? If so, can you point me to how this should be done?

Additional details:

For the scenario where the server is set to force Kerberos authentication, turning on Extended RPC Debugging gives some additional clues. The client can successfully connect using CoCreateInstanceEx, but calls on the service interface fail as noted above. The RPC error records show an error at location 140, and the error code is 0x80090303 ("The specified target is unknown or unreachable"), and the third parameter for that record is an empty string. This points to a missing SPN as the culprit.

Answer 1

Edit: It looks like I may be somewhat mistaken about this. At least one website I found states that DCOM handles SPNs automatically for you (see the bottom of the page), and I confirmed that clients can successfully connect if they demand Kerberos authentication and use "host/[computername]" as the SPN.

---

It does look like an SPN is required for the service, if you explicitly require Kerberos authentication when calling CoInitializeSecurity in the DCOM server process. For me, the call looked like this:

Warning: Please do not copy this code directly without ensuring that the values are proper for your security needs.

SOLE_AUTHENTICATION_SERVICE sas;
sas.dwAuthnSvc = RPC_C_AUTHN_GSS_KERBEROS;
sas.dwAuthzSvc = RPC_C_AUTHZ_NONE;
sas.pPrincipalName = L"myservice/mymachine";
sas.hr = S_OK;
CoInitializeSecurity( 0, 1, &sas, 0, RPC_C_AUTHN_LEVEL_DEFAULT,
    RPC_C_IMP_LEVEL_DEFAULT, 0, EOAC_NONE, 0 );

The SPN can be configured using setspn, as demonstrated below:

setspn -A myservice/mymachine serviceusername

(see the setspn docs for details).

Unfortunately this still didn't solve my problem, but I think the remaining issue is related to some specific problem with the test machines.

Answer 2

For what its worth, Kerberos by definition requires SPNs. You might be able to utilize the built-in SPNS (host/) and the various flavors that host implies (This alias translation is stored in the AD, but for the life of me, I can't seem to find the article listing where this is found).

I'd start by looking at the cross-domain authentication - It can be tricky with kerberos. I'd first turn on full kerberos logging on both the client and server and see if that turns up anything.