Я пытаюсь удаленно администрировать машину с Windows 7. Я включил WinRM и могу использовать Enter-PsSession для подключения к удаленной машине.
Однако я замечаю разницу между запуском конкретной команды локально и удаленным запуском, даже если я подключаюсь к одной и той же учетной записи (которая является администратором домена).
Результат удаленного сеанса:
> enter-pssession -computername REMOTEHOST
[REMOTEHOST} > Get-WURebootStatus
New-Object : Creating an instance of the COM component with CLSID {C01B9BA0-BEA7-41BA-B604-D0A36F469133} from the IClassFactory failed due to the following error: 80070005.
At C:\Windows\system32\WindowsPowerShell\v1.0\Modules\pswindowsupdate\Get-WURebootStatus.ps1:52 char:33
+ $objSystemInfo= New-Object <<<< -ComObject "Microsoft.Update.SystemInfo"
+ CategoryInfo : NotSpecified: (:) [New-Object], UnauthorizedAccessException
+ FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.PowerShell.Commands.NewObjectCommand
ExecutionPolicy имеет значение «Unrestricted», и эта команда отлично работает, когда я использую локальный сеанс PowerShell на удаленном компьютере.
Есть ли другой контекст безопасности для удаленных сеансов PowerShell?
редактировать: конкретная строка, в которой он не работает, это одна:
$objSystemInfo= New-Object -ComObject "Microsoft.Update.SystemInfo"
API Центра обновления Windows особенный. Он специально проверяет и запрещает удаленный доступ, проверяя, помечен ли ваш токен как удаленный. Не знаю, почему так написано.
Я закончил тем, что создал запланированную задачу и вызвал внутри нее API обновления Windows - довольно неприятно.
В зависимости от того, как именно командлет Get-WURebootStatus получает доступ к информации, я думаю, это может быть связано с проблемой «второго прыжка» в PowerShell.
Когда вы входите в удаленный сеанс PowerShell, вы просите WinRM создать сеанс на удаленном узле, используя ваши учетные данные. Если из того же сеанса вы попытаетесь получить доступ к другой (удаленной) системе или службе, для которой требуются эти учетные данные, запрос завершится ошибкой, потому что удаленный компьютер не авторизован на использование ваших учетных данных для проверки подлинности для чего-либо еще. «Эй, сценарист!» блог это хорошо объясняет:
Вы столкнетесь с этой же (или подобной) проблемой, когда после удаленного подключения к машине и затем попытаетесь получить доступ к другому удаленному пути общего доступа к машине с помощью Test-Path по той же причине.
Решение (как представлено в статье блога) состоит в том, чтобы включить и использовать CredSSP в качестве механизма аутентификации при создании сеанса PSSession.
Вы также можете заключить команду в запланированную задачу и сразу же запустить ее, но это большая дополнительная работа, которая может быть ненужной.
Попробуйте использовать Get-WURebootStatus -ComputerName <your remote computer> -Silent.