The script worked fine in most cases, but we occasionally got errors like these:
Error 462 on GetObject()
"The remote server machine does not exist or is unavailable"
Error 70 on GetObject()
"Permission denied"
The line of code in question was:
Set objReg = GetObject("winmgmts:{impersonationLevel=impersonate,authenticationLevel=Pkt}!//" & strComputer & sDNS & "/root/default:StdRegProv")
To cut a long story short, we used WireShark to capture the conversation between the source and target PC's.
Here is a RPC packet sent from the source to the target PC.
The target PC is "PC-ONE-LAP".
DCE RPC Bind, Fragment: Single, FragLen: 1440, Call: 2
Version: 5
Version (minor): 0
Packet type: Bind (11)
Packet Flags: 0x03
Data Representation: 10000000
Frag Length: 1440
Auth Length: 1360
Call ID: 2
Max Xmit Frag: 5840
Max Recv Frag: 5840
Assoc Group: 0x0000b254
Num Ctx Items: 1
Ctx Item[1]: ID:1
Context ID: 1
Num Trans Items: 1
Abstract Syntax: ISystemActivator V0.0
Interface: ISystemActivator UUID: 000001a0-0000-0000-c000-000000000046
Interface Ver: 0
Interface Ver Minor: 0
Transfer Syntax[1]: 8a885d04-1ceb-11c9-9fe8-08002b104860 V2
Auth type: SPNEGO (9)
Auth level: Connect (2)
Auth pad len: 0
Auth Rsrvd: 0
Auth Context ID: 1277840
GSS-API Generic Security Service Application Program Interface
OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
SPNEGO
negTokenInit
mechTypes: 3 items
Item: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5)
Item: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
Item: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP - Microsoft NTLM Security Support Provider)
mechToken: 6E82050A30820506A003020105A10302010EA20703050020...
krb5_blob: 6E82050A30820506A003020105A10302010EA20703050020...
Kerberos AP-REQ
Pvno: 5
MSG Type: AP-REQ (14)
Padding: 0
APOptions: 20000000 (Mutual required)
Ticket
Tkt-vno: 5
Realm: COMPANY.NET
Server Name (Service and Instance): RPCSS/PC-ONE-LAP.company.net
enc-part rc4-hmac
Authenticator rc4-hmac
You can see it is using kerberos to authenticate.
Here is the response from the target PC:
DCE RPC Bind_ack, Fragment: Single, FragLen: 199, Call: 2
Version: 5
Version (minor): 0
Packet type: Bind_ack (12)
Packet Flags: 0x03
Data Representation: 10000000
Frag Length: 199
Auth Length: 131
Call ID: 2
Max Xmit Frag: 5840
Max Recv Frag: 5840
Assoc Group: 0x0000b254
Scndry Addr len: 4
Scndry Addr: 135
Num results: 1
Context ID[1]
Auth type: SPNEGO (9)
Auth level: Connect (2)
Auth pad len: 0
Auth Rsrvd: 0
Auth Context ID: 1277840
GSS-API Generic Security Service Application Program Interface
SPNEGO
negTokenTarg
negResult: accept-incomplete (1)
supportedMech: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5)
responseToken: 606606092A864886F71201020203007E573055A003020105...
krb5_blob: 606606092A864886F71201020203007E573055A003020105...
KRB5 OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
krb5_tok_id: KRB5_ERROR (0x0003)
Kerberos KRB-ERROR
Pvno: 5
MSG Type: KRB-ERROR (30)
stime: 2007-08-30 10:19:06 (Z)
susec: 851504
error_code: KRB5KRB_AP_ERR_MODIFIED (41)
Realm: COMPANY.NET
Server Name (Principal): PC-TWO-LAP$
The response show an Kerberos error "KRB5KRB_AP_ERR_MODIFIED", as it is basically saying - hold on, my name is "PC-TWO-LAP" and not "PC-ONE-LAP".
In the System Event Log for the source PC, you will see the following:
Event Type: Error
Event Source: DCOM
Event Category: None
Event ID: 10009
Date: 30/08/2007
Time: 10:22:52
User: COMPANY\USER
Computer: SOURCEPC
Description:
DCOM was unable to communicate with the computer PC-ONE-LAP.company.net
using any of the configured protocols.
Event Type: Error
Event Source: Kerberos
Event Category: None
Event ID: 4
Date: 30/08/2007
Time: 10:22:52
User: N/A
Computer: SOURCEPC
Description:
The kerberos client received a KRB_AP_ERR_MODIFIED error from the
server PC-TWO-LAP$. This indicates that the password used to encrypt
the kerberos service ticket is different than that on the target server.
Commonly, this is due to identically named machine accounts in the
target realm (COMPANY.NET), and the client realm.
The explanation is that the DNS server was returning the same IP address for both "PC-ONE-LAP" and "PC-TWO-LAP". Only "PC-TWO-LAP" was actually connected to the network, but when we tried "PC-ONE-LAP", it was actually "PC-TWO-LAP" that responded.
Kerberos authenticates both the User and the Computer, so that is why we got the error. If you get this error, then check your DNS records.
For other similar problems you may find this link useful:
Failed to get remote resources: Remote server is unavailable. The RPC server is unavailable.
