Alternate credentials on Windows 8.1

[MISADMINS]

I am running PowerShell Studio 2014 (version 4.1.61), and I recently upgraded my workstation to Windows 8.1 Enterprise. I have an application that my helpdesk uses, which requires alternate credentials.

On Windows 7, I was able to add alternate credentials to the script packager, build the script, and it would run fine. Yesterday I had to update the password on the account I used, so I loaded the script in PowerShell Studio, changed the password in the script packager, and clicked Build and Run. It appeared to build the EXE fine, but when I run it, I now get an error. The error depends on what account I use for alternate credentials, and how I launch the executable.

Sometimes I get an Access Denied error, other times I get "The requested operation requires elevation", and other times I get a permissions error. But none of the errors are detailed enough to tell me what part of the script is causing the problem.

I've tried changing the alternate credentials to another account, I've tried both Run As and Impersonate, I've tried running the EXE as Administrator, as my domain admin account, and even using the account that is being used for alternate credentials. Nothing works. But if I set the credentials back to run as the current user (or if I click Debug, or click Run from the Home menu instead of the Deploy menu), it works fine. It only fails when using alternate credentials.

Incidentally, when I was using Windows 7, I had the same kind of problem when I copied the packaged executable to a 2012 server and tried to run it. Which leads me to believe that Windows 8 and Server 2012 are handling impersonation differently.

Is there anything else I can try to fix this? Or will I have to wait for an updated version of PowerShell Studio? I can build a Windows 7 VM specifically for PowerShell Studio if I need to, but I can't have that be a permanent solution, as our helpdesk will be upgraded to Windows 8 this year, and then it'll break again.

Thanks,
Sam

[Alexander Riedel]

Are the machines 64 bit and you are packaging your scripts as 32 bit?
Because we are observing that 32 bit processes can not use impersonation or alternate credentials under 64 bit.

We are not sure if that is intentional by Microsoft or accidental at the moment.

There is also a difference in how the split admin token is handled under 8.1 or Server 2012 R2.

Do you have User Access Control switched off on your Windows 7 machine?

[MISADMINS]

The machines are x64, and in the script packager the platform is set to "SAPIEN PowerShell V3 Host (Windows Forms) x64".

Yes, I had UAC turned off on Windows 7, and it is also off on Windows 8.

[Alexander Riedel]

I think you are running into the following problem:

The admin token is split since Windows Vista, meaning that even when logged on as an admin, you still have to elevate to reach full administrative privileges. Switching UAC off in Vista, 7 and 8 eliminated the split token.
Under Windows 8.1 the split token persists even when UAC is turned off.
So to get from an ordinary user to an admin you only need a runas or impersonation under Windows 7.
Under Windows 8.1 you need to to a Runas or impersonate and THEN elevate to gain full privileges.
Unfortunately as it is now you cannot do that in one process.
The elevation manifest is interpreted by Windows *before* the process is executed so you would be prompted, which you are trying to avoid.
The only current way to do that is to use a bootstrap process.
A script, packaged using alternate credential, starts and executes as an admin user. It then from there launches the final packaged script that will do the work.
The second script CANNOT use alternate credentials but it must have an elevation manifest.

Try that your environment and see if that gets you results.

[mkedaj]

Hi Sam,

I work on a similar script:
Some of our field staff use an application which needs regular updates.
The update process needs to be elevated for correct execution.
The staff has simple user account with no admin permission.

So I need a program that can be elevated without knowing the credentials of an account with administrative permission. My exe is packaged with administrative credentials. From this script I do a "start-process -verb runas 'c:\Path\to\MyUpdater.exe'" . This invokes the UAC prompt and the user has to commit - but it does not ask for credentials.


You may check at the start of your script if it is running elevated and if not let it rexecute itself with elevation and quit.

My solution works for Windows 7 with enabled UAC.
If UAC is disabled in your environment the prompt may be suppressed completely.

With the permission issues: I have had also such issues. My analysis showed up that it was caused by file and folder permissions in my case (set at profile creation by the system).
Try to place your script/package in a folder with modify permission to everyone.
If this works you know it is caused by NTFS permissions too.

Martin

[MISADMINS]

Thanks! I got it working now. I now have a script-elevator that runs as an administrative account and kicks off a script which runs as "current user", but with an elevation manifest.

I also found that I can avoid this by completely disabling UAC. Apparently in Server 2012 and Windows 8.1, just setting UAC to never prompt doesn't actually turn it off. In order to turn it off completely, set the registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA to 0. After rebooting, UAC will be off.

So now, on my laptop I have UAC completely turned off, but for the users that I want to give the script to, I just have to give them the elevator script with it. Or better yet, I can now publish it via my remote desktop farm.

Thanks alot!