2

I have written a Powershell module that contains cmdlets that utilize IIS's WebAdministration Powershell module. However, this module requires that it be loaded into an admin Powershell session, otherwise an exception is thrown. As you might know or guess, my custom module fails to load when Powershell is not first run as an admin.

This behavior is acceptable and expected. My question is whether or not there is a way to elevate the shell's permissions (and obey UAC settings) when this module is loaded?

Example: (Assume in this particular case, Import-Module WebAdministration is found in my powershell profile)

  1. I click the powershell shortcut on my task bar.
  2. A powershell shell with standard user permissions opens, and attempts to import module.
  3. Encounters fact the module needs elevated permissions.
  4. User is prompted to do so and powershell restarts.
cskwrd
  • 2,803
  • 8
  • 38
  • 51
  • I think a module that could elevate it's own permissions would probably be exposing a bit of a major security hole in PowerShell. You could maybe look at using JEA though to create a role/user to be used when executing your script that has the finite permissions needed for it to succeed: https://msdn.microsoft.com/en-us/library/dn896648.aspx – Mark Wragg Mar 28 '17 at 15:06
  • 1
    A PowerShell script can check and self-elevate (with `Start-Process -Verb RunAs`), but it would be bad form for a *module* to do this. There is no method, in any case, that will relaunch the session while preserving all changes made so far (which is really what you would need to do this safely from a module). – Jeroen Mostert Mar 28 '17 at 15:17

1 Answers1

2

My question is whether or not there is a way to elevate the shell's permissions when this module is loaded?

It would be a security hole if it were possible to elevate silently without a prompt. But you can use code like this to ensure the module will throw an error (and not load) if you're not running elevated:

$Elevated = ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
if ( -not $Elevated ) {
  throw "This module requires elevation."
}
Bill_Stewart
  • 22,916
  • 4
  • 51
  • 62
  • It wouldn't be an obvious security hole. Elevation is an existing feature in Windows, and it requires entering administrative credentials to do. The `#Requires` clause you mention only causes a script to error out when executed. It can't be used in a module ([even a script module](https://stackoverflow.com/q/42283014/1394393)), and it doesn't accomplish the task the OP specified. At a bare minimum, you should be explaining what it does and how the OP might find it helpful in spite of the fact it doesn't do what was asked. My downvote is based on lack of information and a bad judgement. – jpmc26 Dec 05 '17 at 17:33
  • @jpmc26 Thank you; I thought I tested that `#requires -RunAsAdministrator` works in a script module; evidently I didn't. Updated my answer with code that programmatically determines elevation and throws an error if not elevated. – Bill_Stewart Dec 05 '17 at 17:50