May 24, 2016 at 2:25 pm #39959
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 try ( SharingProcess = DotNetHandle.Start procInfo SharingProcess.StartInfo.WindowStyle=(DotNetClass "System.Diagnostics.ProcessWindowStyle").Hidden ) catch ( 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.
May 24, 2016 at 2:35 pm #39983
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.
May 24, 2016 at 2:40 pm #39986
to be honest, I didn't understand.
So what should I write to run without UAC pop up.
May 24, 2016 at 2:54 pm #39991
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).
May 24, 2016 at 2:55 pm #39993
Think about that question for a moment. 🙂 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.)
May 24, 2016 at 3:12 pm #39998
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...
May 24, 2016 at 7:43 pm #40025
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:
Enterprise Read-Only Domain Controllers
Read-Only Domain Controllers
Network Configuration Operators
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.
You must be logged in to reply to this topic.