Problem: Our engineering team is looking to just lock down an EXE in Windows XP.

We have a special calibrated windows XP machine that runs a pretty intense operation. The program is calibrated and setup perfectly until unauthorized employees who do not have the latest training run this program and change settings.

This machine has a shared network login and that login has admin rights on the machine. Engineering wants to require a password to run the program. They would like to allow multiple password with unique user names to run the program - to avoid people just saying "hey the password this week is ABC" - some sort of access list with time stamps would be ideal for the EXE if anything.

I told them pretty much this isn't an IT problem and they should fire their employees but alas this is the real world and that won't happen...my solution was maybe some type of usb fingerprint scanner tied to an EXE launch script...


[Edited on June 4, 2013 at 7:39 PM. Reason : ss]

6/4/2013 7:39:19 PM

remove the shared login. remove execute permissions on the .exe for everyone except for an ad group that contains the domain users who should have permission to run it.

6/4/2013 7:54:24 PM

^That sounds about right to me.

6/4/2013 9:25:46 PM

put a vm on the machine with local credentials (assuming no domain) give the credentials to the people that need them. run the app inside the vm

6/4/2013 9:35:58 PM

Both above solutions would work well. In a nutshell, you're going to have a much easier time controlling this by login than by trying to actually secure the .exe in a shared-login environment. It's possible but it'd be a pain in the ass.

6/5/2013 12:01:38 AM

That shared login with admin rights is going to be the biggest problem. People WILL figure out whatever scheme you come up with and with admin rights figure out how to circumvent it.
Shaggy's solution works nicely if you can get rid of the shared login.

If you can't get rid of the shared login, put the program on a shared network drive that requires different credentials to mount. Instruct the "real" users to always mount the drive as the same drive letter, run the program, and unmount when they are done.

6/5/2013 7:39:20 PM

the shared login will have to stay as admin rights are done in the enterprise by an exception form that auto adds the login as the admin once approved. Admin rights are required to run this program and some system variables are modified.

The user base can easily be tricked. Something as simple as click this shortcut to run the program. They wouldn't search through the C:\ looking for it or right click and debug some VBS script i could write.

[Edited on June 5, 2013 at 8:33 PM. Reason : ss]

6/5/2013 8:30:55 PM

I don't know, dude, it sounds like your engineering team doesn't know how to Windows. Shared logins are basically always a bad idea.

6/6/2013 8:50:50 AM

Im going to write something in visual basic.

6/6/2013 9:20:08 AM

a gui interface plz

6/7/2013 11:01:06 PM

If you have to have the shared logins, which is something you should never do, then just tell all the users that the next person who fucks up the settings will be fired, and then fire the next moron who fucks up the settings. No one will touch it after that. Problem solved.

6/9/2013 5:25:08 PM

better have them digital forensics tools so you can match up the time the settings were changed with the times your employees were at the computer

6/9/2013 6:35:55 PM

Are the settings in a different config file? You could put a script to restore the settings on log in

Ice startup script that copies settings.INI from a network location to overwrite the potentially modified file

[Edited on June 13, 2013 at 9:43 PM. Reason : dd]

You could also use deny rights for the shared account in NTFS...as long as they don't take ownership

Ice allow read and execute and list deny modify

[Edited on June 13, 2013 at 9:46 PM. Reason : dd]

6/13/2013 9:41:42 PM

Why not just encrypt the config file of the executable, so it cannot be changed even via the GUI?

[Edited on June 14, 2013 at 10:33 AM. Reason : -]

6/14/2013 10:31:11 AM

how would the application be able to read the encrypted file? if the application could, what's preventing the users?

[Edited on June 14, 2013 at 11:03 AM. Reason : encryption also has nothing to do with permissions]

6/14/2013 11:03:22 AM

I like AntecK7's idea to restore the settings on login, unless the settings are dynamically changed by the operation as it runs.

If the user base is as easily tricked as you imply, you could hide the shortcut somewhere and only give the locataion to authorized users. That is assuming they wouldn't give the location away, navigate to it, or leave the folder open in the presence of an unauthorized user. It's not at all secure and it's not particularly elegant but it's near-zero effort to try.

6/14/2013 11:14:58 AM