I recently assisted a client with a very specific WMI issue which was blocking access to a specific server across a domain / forest trust.

During my investigation I found there was no suitably ranked article and so here is the issue outline and resolution.

Key error codes:-

  • Client:- KDC_ERR_S_PRINCIPAL_UNKNOWN – error 0x7
  • Client:- A security package specific error occured – error 0x80070721
  • Server:- No server error codes are returned.

Environment:-

  • A domain or forest trust exists
  • The client and server are in different domains connected by a trust.
  • For the stated example, the problem client is in the DEV domain and the target server in the LAB domain.

Symptoms:-

  • Using applications on the Client in the DEV domain fail when connecting to the TST-1 Server in LAB Domain
  • When attemting a WMI connecting from DEV to TST-1 an 0x80070721 error is recieved

1 Open WBEMTEST and attempt to connect to the root namespace of TST-1. Ensure that NTLM is used.

ntlm.1

2 Attempt to enumerate classes on TST-1

ntlm.2

3 Error 0x80070721 is returned.

ntlm.3

Issue:-

  • You perform a service principal name check using setspn RestrictedKrbHost/tst-1 in both domains and find that the SPN is registered in both domains causing an SPN error.

ntlm.4

  • The RestrictedKrbHost must be unique within the domain and this is actually checked by performing an LDAP check. That is to say an administrator can not incorrectly assign the¬†RestrictedKrbHos/ SPN without a warning. This is great but there is no uniqueness check between trusted domains! This is why this issue occured.¬† Transpires that the TST-1 server had been incorreclty joined to the DEV domain and the DEV computer account had not been deleted while TST-1 had been joined to the LAB domain.

Resolution: –

  • You remove the SPN from the identity in the DEV domain and test for duplicates.

ntlm.5

  • Rerunning the wbemtest above succeeds and you now find event 4624 logged in the target TST-1 server in the LAB domain.

ntlm.6