How do I perform LDAP queries from remotely executed script?

[vbssimon]

I have a VB Script which creates a VBS file and populates this file with VB Script. The file is then copied to a remote server and executed on that remote server using the Win32_Process object. The remote script runs fine for all the tasks apart from when I ask it to perform an LDAP query. This returns a 'Table not found' type of error. The LDAP query itself is correctly formatted and, in fact, When I remote on to the server and manually execute this generated script there is no error. The crux is that the following code does not seem to be allowed when running as a result of a remotely executed process.

Example remote code:

  Set objRootDSE = GetObject("LDAP://RootDSE")
  strFQDN = objRootDSE.Get("defaultNamingContext")
  Set objADCon = CreateObject("ADODB.Connection")
  Set objADCom = CreateObject("ADODB.Command")
  objADCon.Open "Provider=ADsDSOObject;"
  objADCom.ActiveConnection = objADCon
  objADCom.CommandText = "<LDAP://OU=Users,OU=Accounts," & strFQDN & ">;(name=*);givenName,sn;subtree"
  Set objADRS = objADCom.Execute

This is copied to server and executed using:

    Set Startup = c_SWbemServices.Get("Win32_ProcessStartup").SpawnInstance_()
    Set Process = c_SWbemServices.Get("Win32_Process")
    RunProgram = Process.Create(c_Command, c_startIn, Startup, c_ProcID)

There is plenty more code setting this up and feeding in stuff here and there but i did not want to past the entire thing as this post is large enough already - Just wondering if what I want is even possible.

Thanks folks.

 

[Rambeaux007]

I believe I am experiencing the same issue. What account are you running the script on the remote machine as? If it is the system account you probably cannot enumerate Domain information with that account.

 

[vbssimon]

I am using on of our 'management accounts' with membership of the security group granting local admin rights to the server in question as well as a whole bunch of other admin rights. I use the same account in both cases the only differance being that the remote execuition impersonates the account (impersonation level 3) to start the remote process.

Is there something in the WMI impersonation which prevents a scriptlet (which has been remotely started using a cscript Win32_Process) from accessing the wider domain environment?

It seems as if the remote process is granted permission to only access local objects despite the impersonated account's rights.

Quite odd.