ADSI and compiling to an EXE


I’ve got a script that needs to be run by our end users, it tests the PC they are logged into for AD Group membership info. If the PC is a member of the specified AD Group, it continues to run and do its thing, otherwise it alerts the staff that it cannot be run and exits.

The problem I’m having is that I need the script to run as an EXE and it runs just fine as a PS1 file, but as soon as I compile it to an EXE it says the PC isn’t in the AD Group.

I’m not using Get-ADGroup or similar functions because I don’t want to have to load RSAT onto all of the PCs where this will be used.

Here’s a rough outtake of the code…

$currpc = $env:ComputerName.toupper()
$adlist = [ADSI]“LDAP://cn=ADGroupToCheck,ou=AD Group OU,dc=domain,dc=com”
if ($adlist.member -like “$currpc”) {
do the things
} else {
alert not a member of AD Group

I’ve been using the PS2EXE v0.5.1.0 Karstein/Isacson to compile my PS1 files to EXEs for some time.

Any suggestions are welcome.

Thank you.

At first glance, I was thinking this should be done on the server, but you mention “do some things”. Would it be possible to do “some things” from the server as well via GPO? Having users run scripts seems to be somewhat problematic, at least from my experience.

As for PS2EXE, I gave up on that a long time ago as I has so many issues. I use a third party tool that works flawlessly converting to EXE and even allows me to support PS2.

And I assume “alert …” is pseudo Code as I am not familiar with that command. Without your real code, it may be tough for forum members to help you out.

First of all: Why?

Do you have some credentials in your code? I wouldn’t expect regular users to have the permission to add their own computer to an AD group. If they had you wouldn’t need to have credentials in your script and therefor you wouldn’t need to compile it to an exe.

Olaf, I think it just validates membership, not add. Did I miss something? It has not been stated what “do some things” really is.

So I missunderstood this. Let’s wait for the answer anyway. :wink: I do consider having users running scripts as a bit quirky procedure as well. Especiall the requirement to run it as exe.

All -
Thank you for the responses, I had continued my research into the issue and have found the source of my problem - if I run it from a share, it fails to run as an EXE, but if I run the same EXE from the C drive, it works fine. I really don’t understand that, the PC has no special software, no RSAT, nothing of that nature, etc and we run the same AV on the PC as the servers that act as our shares.

So it should work regardless of where the EXE resides… oh and I did whitelist it in our AV product.

But to answer some of your questions/concerns… the “do some things” were changes to the registry under the HKLM - there are two sets of changes based on the end user’s AD Group membership, so yes, we are using elevated credentials within the script - which is why I’m converting it to an EXE. The Computer AD Group membership check is just to make sure that the PC is part of the group on which those changes are authorized to be made. If a user were to copy tihis app to a PC where the changes were not authorized, a message box would appear alerting them to that fact.

I also prefer not to have users doing these types of things, but when upper management has agreed to allow Department X to do Stupid Thing #347…you figure out how to make it work.

Thanks again!

And why cant you do all this via GPO?

1 Like

If you are the IT expert in this case you should be brave enough to say no. :wink: I know it might be hard to convince Non-IT people in the first place but I think it will pay off for all of you in the future. Because doing stuff with such a workaround will cause increased maintanence in the future and is a security issue.

Without getting too deep into the weeds, simply put a GPO would not work, a user could be doing either Workflow #1 or Workflow #2 on the same station - these two different workflows require two different settings for the same application within the HKLM.

When installed the application hard codes into the registry what it is configured for, there is no option within the App to select the workflow

Our original solution was to have Workstation 1 for Workflow 1 and Workstation 2 for Workflow 2 in the same space, then for a while they were not doing Workflow 2. Now they are and they liked being able to have 2 stations on Workflow 1 and now they want the option of switching it back and forth.

The vendor has indicated they are “considering” adding this as an option, we could get it custom built in to the application for around $10k - but that’s not going to happen.

I have said no, I was overruled.

Again, I’ve already resolved the issue, I just moved the EXE local to the device and placed a short cut on the all users desktop.

Not ideal, but it works.

Managers … :face_with_raised_eyebrow: :roll_eyes:

OK. Anyway I’m pretty sure that there would be a better solution than saving credentials hard coded in a script.

So, does your solution mean that each time you update the script/exe you need to re-copy to the user systems? And to clarify, the EXE simply does not work from a UNC path? Just a suggestion, what happens if you sign the EXE? I know you have your solution, this is more out of curiosity as I dont have these issues with PowerShell Scripts to EXE and running from a UNC, but I use a third party tool and I sign the EXE.