No matter what you do, without using some third-party utilities, there's always going to be a way for your users to easily retrieve the admin password used if you're scripting with PSEXEC like this. This is because PSEXEC needs the password to be passed to it as a command parameter in cleartext, if you're not going to be available to enter it manually every time.
A few example scenarios:
Password is provided in link parameters:
Ridiculously easy to see the password by looking at the link properties.
Password is provided via batch script, and you point the link to the script:
Easy to find the script via the link shortcut, and find the password sitting in the script.
Password is stored as a secure string in a text file, which is read and passed to PSEXEC via a PowerShell script, and you point the link to the PowerShell script:
Password is still visible in the process properties via Task Manager.
(View->Select Columns->Command Line)
That last option above is from the first revision of an answer by Adi Inbar to another question.
The latest revision of the same answer has a better solution, which is not quite so trivially exploitable, but anyone can still get to the password if they know what they're doing. It's definitely not something I'd use for one of my own accounts or systems, but it seems like it may offer acceptable protection by your standards. The solution drops PSEXEC entirely, and does all the work in PowerShell instead. However, I think it still needs some work before it's actually functional for a multi-user implementation. (I don't know exactly how to do it just now. Will update this answer if I figure it out later.) Once successfully implemented, any user with access to the script and its supporting files can still extract and decrypt the password but it's not just a simple matter of reading it as cleartext.
If you're open to using third-party software, there are some tools which allow you to add Limited user accounts to a "sudoers"-type group and restrict their elevated privileges ability to only (directly) launching the applications you choose.
In any case, there's still one important consideration to bear in mind: Whenever you allow a user to launch an application with elevated privileges, you're giving them the ability to use elevated privileges for whatever the application is capable of doing. If this includes browsing the file system (e.g.: via an Open or Save dialog), the user can then use the elevated privileges on other programs/functions that you do not want them having access to.
Example: Say you allow me access to your system, and have my account configured so that the only application I'm allowed to run with elevated privileges is Notepad. From Notepad, I'd...
- Set the file type to "All files (.)".
- Browse wherever I want in the local file system and run/open any files/programs I want as an Administrator.
- e.g.: Navigate to
lusrmgr.msc, select "Open", use the MMC to add myself to the real Administrators group.