☰

Запустите скрипт PowerShell от имени другого пользователя с повышенными правами

tag-icon • tag-icon powershell elevated
Запустите скрипт PowerShell от имени другого пользователя с повышенными правами

Я понимаю, что это выглядит как дублирование вопроса, но я попробовал решения, и они мне не помогли.

Нам нужно запустить скрипт с нашими учетными записями домена, но также выполнить его с повышенными правами. Это не проблема на большинстве устройств, так как ярлык запускается как администратор и запрашивает у нас учетные данные. Однако, если пользователь является локальным администратором, у нас не запрашиваются учетные данные (только запрос UAC «да/нет»).

Я не понимаю, почему это не работает:

# Get identity of script user
$identity = [Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()

# Elevate the script if not already
if ($identity.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
    Write-Host -F Green 'ELEVATED'
} else {
    Start-Process PowerShell -Verb RunAs "-NoProfile -ExecutionPolicy Bypass -Command `"& '$PSCommandPath'`""
    Exit
}

# Ensure the script has domain privileges
if ($identity.IsInRole('[domain]\[admin group]')) {
    Write-Host -F Green 'DOMAIN ADMIN'
} else {
    Start-Process PowerShell -Verb RunAsUser "-NoProfile -ExecutionPolicy Bypass -Command `"& '$PSCommandPath'`""
    Pause # required, otherwise the Exit below closes the UAC prompt
    Exit
}
Pause

Когда скрипт с самоповышением прав запускается с вводом учетных данных пользователя и домена, он теряет повышение прав... т. е. когда Start-Process -Verb RunAsUser powershellон запускается из PowerShell с повышенными правами, он сам не повышается.

Я также попробовал следующее:

Start-Process powershell -verb RunAs -argumentlist "Start-Process powershell.exe -Verb RunAsUser `"& path\to\script.ps1`""

Но это не удается, поскольку у администратора домена нет доступа к каталогу скриптов... если только у него нет повышенных прав.

решение1

Вы что-то автоматизируете или просто иногда запускаете скрипт? Каталог скрипта локальный или в сети?

Как вы заметили, запуск нового экземпляра powershell с помощью runasне изменит пользователя и runasuserне повысит уровень процесса. Вам нужно будет сделать оба в обратном порядке. Если вы вошли в систему как локальный администратор, запустите Powershell с помощью RunAsUser или через:

  • Shift+щелчок правой кнопкой мыши > Запуск от имени другого пользователя > Администратор домена

Затем выполните команду runas для повышения прав оттуда (как администратор домена):

Start-Process PowerShell -Verb RunAs

Вы можете проверить, под каким пользователем вы в данный момент работаете, с помощью whoami. Результатом должна быть ваша доменная учетная запись, даже с повышенными правами.

ИЛИ

Если вы управляете ПК удаленно и уже используете PowerShell, подключитесь с помощью PowerShell, поскольку сеанс всегда будет иметь повышенные права:

Enter-PSSession MyPCName -credential (get-credential -username domain\MyAdmin)
# remote session:
[MyPCName]: PS C:\WINDOWS\system32>

Я также рекомендую никогда не использовать учетную запись локального администратора, если это возможно.

решение2

Альтернативный инструмент — бесплатный инструмент sysinternals. PsExec.

Команда будет выглядеть так:

psexec -u domain\user -h -i command [arguments]

Параметры следующие:

  • -i: Запустить программу так, чтобы она взаимодействовала с рабочим столом указанного сеанса на удаленной системе. Если сеанс не указан, процесс выполняется в сеансе консоли.
  • -h: Если целевая система — Vista или выше, процесс запускается с повышенным токеном учетной записи, если он доступен.

Небезопасной практикой также является указание пароля:

-p: Указывает необязательный пароль для имени пользователя. Если вы пропустите это, вам будет предложено ввести скрытый пароль.

решение3

Простое решение — сначала скопировать скрипт из места, требующего учетные данные домена.что вы уже вошли в систему какв локальную файловую систему машины, с которой вам нужно выполнить его с повышенными правами. Затем вместо этого выполните скрипт с повышенными правами из этой локальной копии.

Выполните Start-Process Powershellнемного иначе, чем вы это делали, чтобы он выполнил действие логики скрипта при работе с повышенными правами. Добавьте параметры ExecutionPolicy Bypass -NoProfile -Fileи запустите скрипт после этого, чтобы он заработал.

Примечание:Оба приведенных ниже примера решений PowerShell используют корень диска «C» C:\локальной файловой системы, но вы можете настроить его соответствующим образом.

PowerShell (Решение 1)

Copy-Item "path\to\script.ps1" -Destination "C:\" -Force;
Start-Process Powershell -Argumentlist '-ExecutionPolicy Bypass -NoProfile -File "C:\script.ps1"' -Verb RunAs;

Если вам необходимо выполнить аутентификацию с использованием учетных данных домена для доступа к местоположению пути скриптаПервоначально вы можете использовать invoke-commandс -credentialпараметром для выполнения операции копирования. Затем вы можете выполнить скопированный скрипт локальной файловой системы, повышенный таким образом.

PowerShell (Решение 2)

$cred = Get-Credential "domain\username";
Invoke-Command -ScriptBlock {
    Copy-Item "path\to\script.ps1" -Destination "C:\" -Force;
    } -Credential $cred;

Start-Process Powershell -Argumentlist '-ExecutionPolicy Bypass -NoProfile -File "C:\script.ps1"' -Verb RunAs;

Поддерживающие ресурсы

решение4

В моем понимании, в общем, пользователь, выполняющий процесс, и привилегии текущего процесса не могут быть изменены во время его выполнения, но они устанавливаются во время запуска процесса ядром операционной системы.
Поэтому вам следует отделить блок кода, который вы хотите запустить с повышенными правами, и запустить его с помощью RunAs (или его валидаций).
Если изменение привилегий внутри процесса возможно, это станет очень опасной дырой в безопасности операционной системы.

Кроме того, локальная привилегия ( local administrator) и привилегия домена ( [domain]\[admin group]) определяются отдельно.
Если вы хотите разрешить DomainA\User01и то local administrator, и другое DomainA\AdminGroup, вам нужно сделать и то, и другое:

  • предоставить DomainA\User01в локальную группу компьютерной безопасности local administrator, И
  • предоставить DomainA\User01в группу безопасности доменаDomainA\AdminGroup

а затем выполните скрипт с помощью RunAs.

Связанный контент