Jump to content

Search the Community

Showing results for tags 'Elevate'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • Announcements and Site News
    • Administration
  • AutoIt v3
    • AutoIt Help and Support
    • AutoIt Technical Discussion
    • AutoIt Example Scripts
  • Scripting and Development
    • Developer General Discussion
    • Language Specific Discussion
  • IT Administration
    • Operating System Deployment
    • Windows Client
    • Windows Server
    • Office

Categories

  • AutoIt Team
    • Beta
    • MVP
  • AutoIt
    • Automation
    • Databases and web connections
    • Data compression
    • Encryption and hash
    • Games
    • GUI Additions
    • Hardware
    • Information gathering
    • Internet protocol suite
    • Maths
    • Media
    • PDF
    • Security
    • Social Media and other Website API
    • Windows
  • Scripting and Development
  • IT Administration
    • Operating System Deployment
    • Windows Client
    • Windows Server
    • Office

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Location


WWW


Interests

Found 4 results

  1. I'm writing a set of PowerShell scripts/library for Windows 10 builds. One thing I often want to do is to browse to the location of a script that is part of a larger group of scripts and run it manually to do an install or make a one off change. So I like all my scripts to work well whether run from a task sequence or double-clicked in explorer. Most of my build scripts rely on having admin rights so I like to make them able to self-elevate if required - or at least give an error message. In PowerShell 4.0 (Windows 8.1) they added the #Requires -RunAsAdministrator statement but this won't do it for you - it just causes the script to abort if not admin. Below is a PowerShell script that does the following: Checks for admin rights using the Test-IsAdmin functionIf not admin:Get the full script path and working directory using the Get-UNCFromPath functionIf the paths are mapped drives then get the UNC version (drive mappings are lost when elevating from user to admin in most configurations)Execute PowerShell.exe with the UNC path of the script and the RunAs verb to trigger elevation. ExecutionPolicy is also set to Bypass on the command line. The working directory is also set to the UNC path version.Waits for the new process to finish, and captures its return codeExits using the same return codeScript is as follows: # Test if admin function Test-IsAdmin() { # Get the current ID and its security principal $windowsID = [System.Security.Principal.WindowsIdentity]::GetCurrent() $windowsPrincipal = new-object System.Security.Principal.WindowsPrincipal($windowsID) # Get the Admin role security principal $adminRole=[System.Security.Principal.WindowsBuiltInRole]::Administrator # Are we an admin role? if ($windowsPrincipal.IsInRole($adminRole)) { $true } else { $false } } # Get UNC path from mapped drive function Get-UNCFromPath { Param( [Parameter(Position=0, Mandatory=$true, ValueFromPipeline=$true)] [String] $Path) if ($Path.Contains([io.path]::VolumeSeparatorChar)) { $psdrive = Get-PSDrive -Name $Path.Substring(0, 1) -PSProvider 'FileSystem' # Is it a mapped drive? if ($psdrive.DisplayRoot) { $Path = $Path.Replace($psdrive.Name + [io.path]::VolumeSeparatorChar, $psdrive.DisplayRoot) } } return $Path } # Relaunch the script if not admin function Invoke-RequireAdmin { Param( [Parameter(Position=0, Mandatory=$true, ValueFromPipeline=$true)] [System.Management.Automation.InvocationInfo] $MyInvocation) if (-not (Test-IsAdmin)) { # Get the script path $scriptPath = $MyInvocation.MyCommand.Path $scriptPath = Get-UNCFromPath -Path $scriptPath # Need to quote the paths in case of spaces $scriptPath = '"' + $scriptPath + '"' # Build base arguments for powershell.exe [string[]]$argList = @('-NoLogo -NoProfile', '-ExecutionPolicy Bypass', '-File', $scriptPath) # Add $argList += $MyInvocation.BoundParameters.GetEnumerator() | Foreach {"-$($_.Key)", "$($_.Value)"} $argList += $MyInvocation.UnboundArguments try { $process = Start-Process PowerShell.exe -PassThru -Verb Runas -Wait -WorkingDirectory $pwd -ArgumentList $argList exit $process.ExitCode } catch {} # Generic failure code exit 1 } } # Relaunch if not admin Invoke-RequireAdmin $script:MyInvocation # Running as admin if here $wshell = New-Object -ComObject Wscript.Shell $wshell.Popup("Script is running as admin", 0, "Done", 0x1) | Out-Null
  2. I found a few related topics for some reference: Basically the issue has always been how to interpret and work with the results of IsAdmin() when running under UAC, and the desire for developers to not force the use of #RequireAdmin (or the AutoIt3Wrapper manifest equivalent) for all of their users. A lot of programs have that nice 'Elevate' button which is presented to you when the function is available, to selectively elevate the application and enable administrative functions. Here's my attempt at detecting this scenario. The function will return the current admin status, and the ability of the current app to elevate itself under UAC in @extended. A small example should show how it is used. The example can be run from SciTE or compiled, allowing you to test all kinds of scenarios. Something interesting I found... if an app is launched from another fully elevated app, and that new app is launched with restricted privileges by way of the SAFER api, then that app CANNOT re-elevate itself to full admin status. The other way to lower a launched app's privileges uses either CreateProcessAsUser or CreateProcessWithTokenW (there are scripts on the forum that show their usage). Apps launched with either of those functions CAN re-elevate themselves to full admin status. _IsUACAdmin #include <Security.au3> ; #FUNCTION# ==================================================================================================================== ; Name ..........: _IsUACAdmin ; Description ...: Determines if process has Admin privileges and whether running under UAC. ; Syntax ........: _IsUACAdmin() ; Parameters ....: None ; Return values .: Success - 1 - User has full Admin rights (Elevated Admin w/ UAC) ; Failure - 0 - User is not an Admin, sets @extended: ; | 0 - User cannot elevate ; | 1 - User can elevate ; Author ........: Erik Pilsits ; Modified ......: ; Remarks .......: THE GOOD STUFF: returns 0 w/ @extended = 1 > UAC Protected Admin ; Related .......: ; Link ..........: ; Example .......: No ; =============================================================================================================================== Func _IsUACAdmin() ; check elevation If StringRegExp(@OSVersion, "_(XP|20(0|3))") Or (Not _IsUACEnabled()) Then ; XP, XPe, 2000, 2003 > no UAC ; no UAC available or turned off If IsAdmin() Then Return SetExtended(0, 1) Else Return SetExtended(0, 0) EndIf Else ; check UAC elevation ; ; get process token groups information Local $hToken = _Security__OpenProcessToken(_WinAPI_GetCurrentProcess(), $TOKEN_QUERY) Local $tTI = _Security__GetTokenInformation($hToken, $TOKENGROUPS) _WinAPI_CloseHandle($hToken) ; Local $pTI = DllStructGetPtr($tTI) Local $cbSIDATTR = DllStructGetSize(DllStructCreate("ptr;dword")) Local $count = DllStructGetData(DllStructCreate("dword", $pTI), 1) Local $pGROUP1 = DllStructGetPtr(DllStructCreate("dword;STRUCT;ptr;dword;ENDSTRUCT", $pTI), 2) Local $tGROUP, $sGROUP = "" ; ; S-1-5-32-544 > BUILTINAdministrators > $SID_ADMINISTRATORS ; S-1-16-8192 > Mandatory LabelMedium Mandatory Level (Protected Admin) > $SID_MEDIUM_MANDATORY_LEVEL ; S-1-16-12288 > Mandatory LabelHigh Mandatory Level (Elevated Admin) > $SID_HIGH_MANDATORY_LEVEL ; SE_GROUP_USE_FOR_DENY_ONLY = 0x10 ; ; check SIDs Local $inAdminGrp = False, $denyAdmin = False, $elevatedAdmin = False, $sSID For $i = 0 To $count - 1 $tGROUP = DllStructCreate("ptr;dword", $pGROUP1 + ($cbSIDATTR * $i)) $sSID = _Security__SidToStringSid(DllStructGetData($tGROUP, 1)) If StringInStr($sSID, "S-1-5-32-544") Then ; member of Administrators group $inAdminGrp = True ; check for deny attribute If (BitAND(DllStructGetData($tGROUP, 2), 0x10) = 0x10) Then $denyAdmin = True ElseIf StringInStr($sSID, "S-1-16-12288") Then $elevatedAdmin = True EndIf Next ; If $inAdminGrp Then ; check elevated If $elevatedAdmin Then ; check deny status If $denyAdmin Then ; protected Admin CANNOT elevate Return SetExtended(0, 0) Else ; elevated Admin Return SetExtended(1, 1) EndIf Else ; protected Admin Return SetExtended(1, 0) EndIf Else ; not an Admin Return SetExtended(0, 0) EndIf EndIf EndFunc ;==>_IsUACAdmin Func _IsUACEnabled() Return (RegRead("HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System", "EnableLUA") = 1) EndFunc ;==>_IsUACEnabled Example #include <_IsUACAdmin.au3> #include <GuiButton.au3> #include <GuiConstantsEx.au3> $g = GUICreate("UAC Test", 200, 100) $b = GUICtrlCreateButton("Elevate", 200-72, 100-27, 70, 25) _GUICtrlButton_SetShield($b) $admin = _IsUACAdmin() $canelevate = @extended GUICtrlCreateLabel("IsAdmin (built-in): " & (IsAdmin() = 1), 4, 4) GUICtrlCreateLabel("_IsUACAdmin (full admin): " & ($admin = 1), 4, 24) GUICtrlCreateLabel("Process can elevate: " & ($canelevate = 1), 4, 44) If $admin Or (Not $canelevate) Then GUICtrlSetState($b, $GUI_DISABLE) GUISetState() While 1 Switch GUIGetMsg() Case -3 ExitLoop Case $b ; restart elevated If @Compiled Then ShellExecute(@ScriptFullPath, "", @WorkingDir, "runas") Else ShellExecute(@AutoItExe, '/AutoIt3ExecuteScript "' & @ScriptFullPath & '"', @WorkingDir, "runas") EndIf Exit EndSwitch WEnd
  3. _RunWithReducedPrivileges An odd thing about Vista+ O/S's is that, once you run a process in elevated privileges mode, you can't run other processes in lower-privileged modes. Why, you ask, would that be important? Sometimes you want - or need - to limit the privileges of a process: A very common scenario for me is drag-and-drop. Windows' Explorer does NOT allow this to occur between lower privileged processes (like Explorer itself!) and other processes. This is very frustrating for users in programs that take advantage of that. There's also some problems using certain SendMessage commands from other unelevated processes.Setting the state or properties of windows that have an elevated privilege may not work either from other unelevated processes..An install or setup program that needs to launch the installed program will more often than not want to run that program on a lower privilege level (for some of the reasons mentioned above)So, after some looking around I found a way of running processes under a lower privilege mode.Check Elmue's comment 'Here the cleaned and bugfixed code' on this CodeProject page to see where my code was ported from:'Creating a process with Medium Integration Level from the process with High Integration Level in Vista' The usage is straightforward for this one: use it like Run/RunWait, but with the command-line as the 2nd parameter. [i.e. _RunWithReducedPrivileges(@ComSpec,' /k title Non-Admin prompt') ] Anyway, hope this helps someone out! Ascend4nt's AutoIT Code License agreement: While I provide this source code freely, if you do use the code in your projects, all I ask is that: If you provide source, keep the header as I have put it, OR, if you expand it, then at least acknowledge me as the original author, and any other authors I creditIf the program is released, acknowledge me in your credits (it doesn't have to state which functions came from me, though again if the source is provided - see #1)The source on it's own (as opposed to part of a project) can not be posted unless a link to the page(s) where the code were retrieved from is provided and a message stating that the latest updates will be available on the page(s) linked to.Pieces of the code can however be discussed on the threads where Ascend4nt has posted the code without worrying about further linking.Download the ZIP from my site
  4. _ShellExecuteWithReducedPrivileges An odd thing about Vista+ O/S's is that, once you run a process in elevated privileges mode, you can't run other processes in lower-privileged modes. Why, you ask, would that be important? Sometimes you want - or need - to limit the privileges of a process: A very common scenario for me is drag-and-drop. Windows' Explorer does NOT allow this to occur between lower privileged processes (like Explorer itself!) and other processes. This is very frustrating for users in programs that take advantage of that. There's also some problems using certain SendMessage commands from other unelevated processes.Setting the state or properties of windows that have an elevated privilege may not work either from other unelevated processes.An install or setup program that needs to launch the installed program will more often than not want to run that program on a lower privilege level (for some of the reasons mentioned above)So, after some looking around I found two ways of running processes under a lower privilege mode. One is using CreateProcessWithTokenW (see ), and the other is using COM objects - specifically Windows Explorer's SHELL object to ShellExecute a command/program. This can be used just like AutoIt's built-in ShellExecute() function, but of course the program that runs will be at a reduced IL (integrity level). The code is based on Brandon @ BrandonLive's article here: 'Getting the shell to run an application for you - Part 2:How | BrandonLive' The usage is straightforward for this one: use it like ShellExecute. The $bWait parameter is only there in case ShellExecuteWait() will be called for either non-elevated processes or pre-Vista O/S's. Example: _ShellExecuteWithReducedPrivileges(@ComSpec,' /k title Non-Elevated prompt (via Shell.ShellExecute)') Anyway, hope this helps someone out! Ascend4nt's AutoIT Code License agreement: While I provide this source code freely, if you do use the code in your projects, all I ask is that: If you provide source, keep the header as I have put it, OR, if you expand it, then at least acknowledge me as the original author, and any other authors I creditIf the program is released, acknowledge me in your credits (it doesn't have to state which functions came from me, though again if the source is provided - see #1)The source on it's own (as opposed to part of a project) can not be posted unless a link to the page(s) where the code were retrieved from is provided and a message stating that the latest updates will be available on the page(s) linked to.Pieces of the code can however be discussed on the threads where Ascend4nt has posted the code without worrying about further linking.Download the ZIP from my Site
×
×
  • Create New...