Jump to content

RunAsSPC alternative?


Ulaiphur

Recommended Posts

I'm looking for a way to run a program with my credentials while being able to pass-through UAC, like RunAsSPC.

I like RunAsSPC but it also hardcodes the executable name within the encypted file and that makes it hard to use.

 

I just want my username and password encypted in a file and then use that file as a reference in .cmd scripts in order to automatically run an executable as admin.

 

Thank you

 

Link to comment
Share on other sites

  • 1 month later...

So there is no other alternative to this?

Maybe there are, if only what you are asking was understandable.

You don't really pay a fee per word posted, even without being verbose you can provide some understandable description of what you actually want to do, some reference to the RunAsSPC you mention, why exactly that thingy is not suitable to your specific use, etc., etc.

jaclaz

Link to comment
Share on other sites

Sorry for not being clear on my requirements.

 

I want to be able to give someone an application, that allows that person to install it without admin privileges. For this pupose I have used RunAsSPC as follows:

pushd %~dp0RunAsSpc.exe /cryptfile:"TeamViewer.spc"

I have configured the .spc file with my admin credentials and the path to the teamviewer installer.

It works fine but it is tedious to change the password every month on it. Especially when I use about 10 of these .spc files for different applications.

 

I was thinking if there was a program that will allow me to just store the password in an encrypted file, and use that file to run any application, similar to the following example:

runasspc.exe /cryptfile:"MyAdminPassword.spc" C:\Windows\Notedpad.exerunasspc.exe /cryptfile:"MyAdminPassword.spc" .\TeamviewerSetup.exerunasspc.exe /cryptfile:"MyAdminPassword.spc" .\FirefoxSetup.exe

It would be then very easy to update the password, and credentials if necessary because it will be only 1 file and not 10 or 20.

 

Link to comment
Share on other sites

Why do you change the password every month?

Wouldn't it be easy to automate the creation of the N .spc files you *need* monthly?  :unsure:

 

You do understand the REASON why RunAsSpc uses the current approach and not the one you are suggesting, right? :dubbio:

 

jaclaz

Link to comment
Share on other sites

You do understand the REASON why RunAsSpc uses the current approach and not the one you are suggesting, right?  :dubbio:

 

Of course I know. But I need this to work as per my example. 

 

Why do you change the password every month?

 

Because I work as an admin with a windows domain. And our passwords expire every month, including admins.

 

Wouldn't it be easy to automate the creation of the N .spc files you *need* monthly?   :unsure:

 

I would but I have many applications. Even if I created the script, it'll have to update the spc scripts in multiple folders.

 

 

What about an alternate way? Isn't there some program in windows that accepts password hashes or some other easier way than this?

Link to comment
Share on other sites

You do understand the REASON why RunAsSpc uses the current approach and not the one you are suggesting, right?

:dubbio:

Of course I know. But I need this to work as per my example.
Well, unless you want to intentionally introduce a severe vulnerability to your processes, allow me to doubt that you fully understand the implications of having a "self-standing" crypted set of elevating credentials.

 

Of course, it is trivial to put together a (say) Auto-It doing what you *want* (and I believe there are several examples available), but it is not, really not a good idea[1].

 

So, you can automate via (say) batch the creation of the N .spc files but you cannot automate their distribution in "multiple folders"? 

 

jaclaz

 

[1]See the But ... then, why? in my signature.

 

BTW, this answer is wrong:

 

 

 

Why do you change the password every month?

Because I work as an admin with a windows domain. And our passwords expire every month, including admins.
You change it every month because there is such a policy, and such a policy exists in your organization due to some security concerns, which are most probably the same reasons why your users are not given the Admin password or an Admin level account on their machines and why you are currently using runasspc and why your intended modification to the way it works should not even been thought of. Edited by jaclaz
Link to comment
Share on other sites

You change it every month because there is such a policy, and such a policy exists in your organization due to some security concerns, which are most probably the same reasons why your users are not given the Admin password or an Admin level account on their machines and why you are currently using runasspc and why your intended modification to the way it works should not even been thought of.

The persons that worked on the policy did not take into account all of the requirements of the ip support team. Sometimes there are issues with the policy that block all access to the machines, including us, the company that deployed the policy. And when that happens, the stupid people that work in support must figure out ways to get out of the policy, because if you call your boss, or boss's boss, they will say figure it out, instead of actually calling up the person that deployed the security measure to fix it. This is the real world and you should stop trying to make me look like a fool.

 

 

Of course, it is trivial to put together a (say) Auto-It doing what you *want* (and I believe there are several examples available), but it is not, really not a good idea[1].

 

So, you can automate via (say) batch the creation of the N .spc files but you cannot automate their distribution in "multiple folders"?

I will try to create the scripts and see what I'll come up with.

 

 

For the time being I was wondering if you could help me on a specific error in RunAsSPC. It says

Error 5: Access is denied
Link to comment
Share on other sites

The persons that worked on the policy did not take into account all of the requirements of the ip support team. Sometimes there are issues with the policy that block all access to the machines, including us, the company that deployed the policy. And when that happens, the stupid people that work in support must figure out ways to get out of the policy, because if you call your boss, or boss's boss, they will say figure it out, instead of actually calling up the person that deployed the security measure to fix it. This is the real world and you should stop trying to make me look like a fool.

 

I am not at all trying to make you look like a fool :no:, if you had this impression I beg your pardon for this miscommunication or misunderstanding :blushing: , I was plainly stating that the idea of separating the Admin credentials from a specific program execution opens a large security hole, which in an environment where security matters is foolish. (and I stand by my statement)

 

Imagine that one of your N users finds out that he/she can use your hypothetical "MyAdminPassword.spc" to run (say) cmd.exe, or any other program impersonating the Administrator and this ends up causing a loss to the company.

 

Wouldn't your boss (or your boss's boss) be after you in no time? :dubbio::ph34r:

 

 jaclaz

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...