Назад | Перейти на главную страницу

Как сохранить учетные данные в удаленном сеансе Powershell?

У меня есть файловый ресурс Azure, и я хотел бы использовать его на своих виртуальных машинах Azure - после сохранения учетных данных на виртуальных машинах с помощью cmdkey и подключения с использованием сети. Это было протестировано путем выполнения этих команд в локальном сеансе Powershell в Windows Server 2012 R2.

Но мне нужно добавить этот шаг в сценарий развертывания Azure. Сценарий Azure Powershell запускается с моего ноутбука, подключается к подписке Azure и создает виртуальные машины с нуля, используя множество переменных.

Выяснилось, что использовать Invoke-Command для передачи переменных из сценария Azure Powershell в удаленный сеанс Powershell на вновь созданной виртуальной машине.

$Session = New-PSSession -ConnectionUri $Uri -Credential $DomainCredential

$ScriptBlockContent = { 
Param ($Arg1,$Arg2,$Arg3)
cmdkey /add:$Arg1 /user:$Arg2 /pass:$Arg3}

Invoke-Command -Session $Session -ScriptBlock $ScriptBlockContent -ArgumentList ($Share,$AccountName,$Key)

И ошибка:

PS C:\> Invoke-Command -Session $Session -ScriptBlock $ScriptBlockContent -ArgumentList ($Share,$AccountName,$Key)
CMDKEY: Credentials cannot be saved from this logon session.

Заменено на cmdkey / list, чтобы проверить синтаксис, и ошибки нет.

PS C:\> Invoke-Command -Session $Session -ScriptBlock $ScriptBlockContent
Currently stored credentials:
* NONE *

Была аналогичная проблема (и не удалось ее исправить) с модулем Windows Update PowerShell (Invoke-WUInstall), который отлично работает в локальном сеансе Powershell на виртуальной машине, но не обновляется при запуске через удаленный Powershell.

Есть ли способ обойти это?

Вы можете использовать Sysinternal's PsExec.exe если вы не хотите использовать запланированную задачу. Обычно, когда вы запускаете сеанс PowerShell, он запускается в services процесс (вы можете подтвердить это, запустив query session команда на удаленном компьютере) вместо локального пользователя, который не выполняет cmdkey.

Чтобы преодолеть это, нам нужно запустить cmdkey.exe в процессе локального пользователя, что можно сделать с помощью PsExec.exe's -i флаг который

Запустите программу, чтобы она взаимодействовала с рабочим столом указанного сеанса удаленной системы. Если сеанс не указан, процесс выполняется в сеансе консоли.

Теперь задача состоит в том, чтобы получить идентификатор сеанса локального пользователя на удаленном компьютере. Я добился этого, запустив query session команда, которая дает список сеансов, активных на машине. Одно из возможных решений -

$processId = Invoke-Command $session -ScriptBlock  {
param($user)
    $sessions = query session $user;
    return $sessions[1].split(" ", [System.StringSplitOptions]::RemoveEmptyEntries)[2];

} -ArgumentList ($user)

Вот $user содержит имя локального пользователя на удаленном компьютере.

Как только вы получите идентификатор сеанса, вы можете просто выполнить 

PsExec \\<computer_name> -u <local_user_name> -p <password> -h -i $processId cmdkey.exe /generic:testtt /user:userr /pass:pass

Примечание:

  1. Могут быть лучшие способы получить идентификатор сеанса пользователя на удаленном компьютере.
  2. Прямо сейчас, когда я запускаю PsExec, я снова устанавливаю соединение с удаленной системой, чего можно избежать (я не тестировал).
  3. Пользователь, выполняющий команду, должен иметь права администратора на удаленном компьютере.

Из-за того, как Windows обрабатывает проверку подлинности, невозможно использовать CMDKEY для установки учетных данных через удаленный сеанс PowerShell, это должно выполняться в интерактивном режиме при использовании CMDKEY.

Цитировать Дон Джонс из темы, ищущей ответ, похожий на ваш:

Это ограничение команды Cmdkey, а не PowerShell. Но это связано с тем, как Remotig обрабатывает учетные данные. Удаленный сеанс фактически не получает учетные данные, он получает делегированный билет, поэтому токена для фактического сохранения нет. Это все задумано, и вы не можете изменить конфигурацию.