ADSi 1026 Failure with compiled code. Runs non-compiled.

Started by dearnold, October 24, 2014, 09:05:25 AM

Previous topic - Next topic

dearnold

Hi

I'm using Winbatch 2014a and trying to perform an AD query using the ADSI extender.

It's working perfectly when running the code via the interpretter (Winbatch Studio), but when using WinBatch Compiler 32, it is failing with "WIL Extender Error: 1026: ADSi error, The network path was not found."

Here's my failing code:

;  \\\\\\\\\\\\\\\\\\\\\\\\\\\\////////////////////////////
;   \\\\\\\\\\\\\\\\\\\ Get the AD Path //////////////////
;    \\\\\\\\\\\\\\\\\\\\\\\\\\//////////////////////////

AddExtender("wwads44i.dll")

ThisADGroup = "<My_AD_Group>"

sPath = "LDAP://<MyDomain>"
; Search filter to find user account 'Slash'
sFilter = "(&(objectCategory=group)(name=":ThisADGroup:"))"
; Do the search.
lResults = dsFindPath(sPath , sFilter)
; Get the OU path (assumes only one user found.)
sOuPath = dsGetPrntPath(lResults)

Message("sOuPath", sOuPath)

;    //////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\
;   ///////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\
;  ///////////////////////////  \\\\\\\\\\\\\\\\\\\\\\\\\\\

This provides the complete AD Path to the container where my AD group resides

Any thoughts ?

Dale

dearnold

Also, to add to the mix . . .

If I copy this locally to my personal workstations hard drive, the .exe works fine.

The failure occurs when running from a network share.

This needs to run from a network share, as I need to be able to access this from any workstation or server in my network without installing or copying to all devices.

td

You have not provided enough information to determine the source of your problem but it is very unlikely that compiling the script is directly causing the error.  Generally, this error is the result of lacking proper credentials to perform the requested task but there are are other possibilities as well.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

dearnold

Here's a little more info:
I am an administrator on my workstation.
I have full rights to the network share the exe has been compiled on.  I am NOT an administrator of the file server where my network share resides.
I have read access to all objects in AD, full rights to objects in 2 separate branches of the domain.

What more is needed ?

As mentioned, running the NON-compiled script works perfectly, running the .exe from the network share (which I have full rights[READ/WRITE/CREATE/DELETE/EXECUTE]) the .exe fails.  Running from my local workstation, both non-compiled script AND .exe runs fine. 

My initial assumption is that it's some sort of a rights issue, but based on the scenarios of where it works vs does not work, that pill is just a little hard to swallow.

Question: What permissions would allow me to run my query from the non-compiled script but not allow from the .exe running from the same network share ?




Dale

td

Quote from: dearnold on October 24, 2014, 11:03:10 AM
Here's a little more info:
I am an administrator on my workstation.
I have full rights to the network share the exe has been compiled on.  I am NOT an administrator of the file server where my network share resides.
I have read access to all objects in AD, full rights to objects in 2 separate branches of the domain.

What more is needed ?

Much more.  Which version of Windows is your workstation running.  If it is Vista or newer, is UAC enabled?  Which version of WinBatch are you using?  If your Winbatch compiler has manifest options,  what are the compiled script's manifest setting? Which version of Windows Server is the directory service running on?  Are you using cached credentials to access the share?  As part of your investigation into the problem, have you tried calling dsSetCredentEx to hard code the credentials used by the compiled script?

"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

td

I neglected to mention that it may be possible that the very act of starting a process from a share may give the process a different access token than starting it from a local drive. It is very speculative but it might explain the problem.  Using hard coded credentials is one way to confirm or refute the idea.   
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

dearnold

The issue turns out that our "home" network shares are not true Windows OS servers.  They are "emulated" (per our server team leader)

When I run this from a true windows share (Windows 2008r2 Server), it works fine.

Sorry for the wild goose chase and thank you for your responses

Dale

dearnold

And just as FYI, the overall exe was working fine until I added the bit of code above.

Specifically, the line: sFilter = "(&(objectCategory=group)(name=":ThisADGroup:"))"
was the line that was failing.

Moot point for now.  The workaround I have is sufficient.