bypass UAC when running powershell script from 3ds Max

Hey, guys!

I’m very new to powershell scripting, but I found that I need to use it.

I solved almost everything that I need with ps1, but the problem is with UAC now.

In maxscript I use the code as follows to run ps1, and it runs the script with UAC promts:

local ShellPath = "C:\\WINDOWS\\system32\\WindowsPowerShell\\v1.0\\powershell.exe"
      			local procInfo = dotnetobject "System.Diagnostics.ProcessStartInfo" ShellPath
      			procInfo.Arguments = "-noprofile -executionpolicy bypass -File " + "\"" + ShellFile + "\""
				procInfo.Verb = "runas" -- run as administrator
				procInfo.useShellExecute = on -- run as administrator
				procInfo.CreateNoWindow = on 
				procInfo.WindowStyle = (DotNetClass "System.Diagnostics.ProcessWindowStyle").Hidden -- hide console
      			local DotNetHandle = dotnetclass "System.Diagnostics.Process"
      			local SharingProcess = undefined
      				SharingProcess = DotNetHandle.Start procInfo
      				SharingProcess.StartInfo.WindowStyle=(DotNetClass "System.Diagnostics.ProcessWindowStyle").Hidden
      				print "error launching Shell"
      				return false

I need it to use from a tool that will be installed to many computers. I don’t want to turn of UAC promts, just bypass it.

a simple run-as will bypass UAC (to call the script, not from within it).

The way UAC works is pretty simple: all it does is generate two auth-tokens when a user logs into a computer instead of one when it detects that an account is a member of a well-known security group. One token will contain all group membership SIDs, the other token will have the well-known security groups filtered out. The computer will then automatically use the “less-privileged” token until it runs into a permissions issue that can be solved with your elevated rights, then the UAC will prompt for your permission to use the elevated token.

The important thing to note here is that ONLY the local logged in user run-space uses UAC. If your script is launches with a service/runas account, or runs in the system context, then there will be no UAC pop-up. Copy the script and kick it off from within WinRM session: no UAC pop up. Basically if it runs in any space other than the local user run-space.

The UAC is basically a “separate admin account” emulator for the current logged in user to further protect credentials. There is no call I’m aware of to simply bypass it within the user context, as that would basically defeat the entire purpose of the UAC. But if you call out the run context you’re fine.

to be honest, I didn’t understand.
So what should I write to run without UAC pop up.

Basically you have two choices:

  1. Don’t push this script using a user application. Use a method that lets you create a new session.

  2. Make sure that whatever attributes/permissions this script requires are granted without the need for a well-known security group. If it’s granted directly or via a custom group (not local administrator) then the UAC will never filter the permission out.

I was trying to explain how the security function works so you could plan around it. You’re not going to have much luck brute forcing through it (if you do, submit that bug report please).

Think about that question for a moment. :slight_smile: If it were so easy to bypass UAC pop-ups, then every piece of virus / malware out there would do the same thing. (I’m pretty sure it is possible, but not by design; security / malware people find exploits to get around UAC.)

Ok, I understand the concerns. Unfortunatelly viruses and malware application give us a lot of headache.
In my case, I just share a folder for “everyone” to be seen from LAN, and rename textures that have Unicode names. Unfortunatelly, it is not possible to do it from maxscript, it sees ??? instead of Unicode letters. That’s why I’m forced to use powershell.

Is it possible to ask the user once to trust my ps1 script and permit it run anytime It needs to? And of course, I don’t want antivirus application to see it as potential risk or smth…

The scenario you’re describing shouldn’t cause a UAC pop-up. “Everyone”, while it is a well-known security group, it is NOT one of the ones that gets filtered out. That list is:

Built-In Administrators
Certificate Administrators
Domain Administrators
Enterprise Administrators
Policy Administrators
Schema Administrators
Domain Controllers
Enterprise Read-Only Domain Controllers
Read-Only Domain Controllers
Account Operators
Backup Operators
Cryptographic Operators
Network Configuration Operators
Print Operators
System Operators
RAS Servers
Power Users
Pre-Windows 2000 Compatible Access

So by the scenario you are describing, you should NOT be getting a UAC prompt. I think you may need to re-investigate what’s going on.

As for AV not blocking the script … that’s a whole different discussion :). Easiest way, IMO, is to sign the script and make sure the signing certificate is trusted. Most all AV will recognize “trusted code” when it’s properly signed.