Удаленное взаимодействие PowerShell, выдающее ошибку «Отказано в доступе»

Я пытаюсь использовать PowerShell Remoting для проверки некоторых размеров дисков с сервера в удаленном домене, но команды, которые я запускаю, не работают.

Ситуация такая:

  • Исходный сервер находится в домене A
  • Целевой сервер находится в домене B
  • Между этими доменами нет доверия

Сервер в домене B работает под управлением Exchange 2010, и я могу запускать специальные команды Exchange 2010 для него с сервера A, используя эту команду:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange –ConnectionUri $ConnectionURI -Credential $Credentials -Authentication Basic
Import-PSSession $Session

Проблема в том, что я не могу запустить какие-либо команды, отличные от Exchange, на этом сервере, используя этот сеанс, если я попытаюсь, он скажет, что не может понять команды. Я проверил и запустил Get-Command с Invoke-Command, а переменная -Session, установленная для моего установленного сеанса, возвращает только команды Exchange.

Поэтому я подумал, что попытаюсь использовать Invoke-Command и соответствующее имя компьютера, тип аутентификации и учетные данные, но это не удается:

Invoke-Command -ScriptBlock {Get-Service} -ComputerName "Servername.destination.com" -Credential $Credentials -Authentication "Basic"

Это ошибка:

[servername.destination.com] Connecting to remote server failed with the following error message : The WinRM client can
not process the request. The authentication mechanism requested by the client is not supported by the server or unencry
pted traffic is disabled in the service configuration. Verify the unencrypted traffic setting in the service configurat
ion or specify one of the authentication mechanisms supported by the server.  To use Kerberos, specify the computer nam
e as the remote destination. Also verify that the client computer and the destination computer are joined to a domain.
To use Basic, specify the computer name as the remote destination, specify Basic authentication and provide user name a
nd password. Possible authentication mechanisms reported by server:     Negotiate Kerberos For more information, see th
e about_Remote_Troubleshooting Help topic.
    + CategoryInfo          : OpenError: (:) [], PSRemotingTransportException
    + FullyQualifiedErrorId : PSSessionStateBroken

Поэтому я захожу в конфигурацию WSMAN на целевом сервере и устанавливаю соответствующие параметры для разрешения базовой аутентификации и незашифрованного соединения:

cd WSMan:\localhost\Service
Set-Item AllowUnencrypted $True
cd .\Auth
Set-Item Basic $True

Я также добавил целевой сервер в список доверенных хостов исходного сервера домена:

cd WSMan:\localhost\Client
Set-Item TrustedHosts servername.destination.com

После этого ошибка меняется, но это не очень полезно:

PS WSMan:\localhost\Client> Invoke-Command -ScriptBlock {Get-Service} -ComputerName "servername.destination.com" -Creden
tial $Credentials -Authentication "Basic"
[servername.destination.com] Connecting to remote server failed with the following error message : Access is denied. Fo
r more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo          : OpenError: (:) [], PSRemotingTransportException
+ FullyQualifiedErrorId : PSSessionStateBroken

Я также пытался использовать учетные данные администратора домена через -Credential (Get-Credential), но это не помогло с той же проблемой.

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

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


person HungryHippos    schedule 02.01.2013    source источник
comment
Вы можете попробовать ввести-PSsession с набором параметров computerName, который принимает PScredential. Не знаю, будет ли это работать лучше, но, возможно, вы получите другую ошибку.   -  person noam    schedule 03.01.2013
comment
Enter-PSSession вчера выдавал ту же ошибку, когда я пробовал. Интересно, есть ли какие-либо журналы или что-нибудь, что я могу проверить для более подробной информации?   -  person HungryHippos    schedule 03.01.2013
comment
FWIW, удаленное взаимодействие работало для меня в ненадежных доменах от сервера 2003 до цели 2008R2. На цели запустил enable-psRemoting и по какой-то причине должен был нажать A для всех, когда Y для да продолжал выдавать одно и то же приглашение. В источнике запустил enter-psSession -comp target.domain.tld -credential (get-credential) ... и при появлении запроса ввел учетные данные в формате домен\имя пользователя. JIC помогает.   -  person noam    schedule 04.01.2013
comment
Как бы странно это ни звучало, он работал нормально после того, как я полностью отключил переключатель -Authentication, ему совсем не нравился Basic, но просто позволить ему делать свое дело для меня работает.   -  person HungryHippos    schedule 07.01.2013


Ответы (2)


Недавно были похожие проблемы. Рекомендую вам тщательно проверить, имеет ли пользователь, с которым вы подключаетесь, надлежащие права доступа на удаленном компьютере.

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

Set-PSSessionConfiguration -ShowSecurityDescriptorUI -Name Microsoft.PowerShell

Нашел этот совет здесь (обновленная ссылка, спасибо "unbob"):

https://devblogs.microsoft.com/scripting/configure-remote-security-settings-for-windows-powershell/

Это исправило это для меня.

person Olivier Boudry    schedule 02.04.2014
comment
Выполнить Set-PSSessionConfiguration на сервере, клиенте или обоих? - person Kiquenet; 07.04.2014
comment
На целевой машине, чтобы убедиться, что пользователь, с которым вы подключаетесь, авторизован. - person Olivier Boudry; 14.04.2014
comment
обновленная ссылка: devblogs.microsoft.com/scripting/ - person unbob; 15.01.2020

Запуск командной строки или Powershell ISE в качестве администратора исправил это для меня.

person Cirem    schedule 13.06.2014
comment
Это исправило мои проблемы, когда я запускал Invoke-Command и ссылался на localhost. Был весьма удивлен. Спасибо! - person James Ruskin; 10.11.2014
comment
Я решил это, добавив пользователя в группу пользователей удаленного управления. - person Der_Meister; 24.03.2017
comment
Der_Meister Спасибо, сработало. Возможно, только встроенная учетная запись Administrator может обойти барьер UAC в настройках политики безопасности по умолчанию. Другие Administrators учетные записи вынуждены получать токен ограниченного доступа ( имея Users вместо Administrators). Их учетные записи являются обычными Users до тех пор, пока не произойдет повышение привилегий. Поэтому сначала нам нужно поместить их обычную учетную запись Users в группу Remote Management Users. - person kenjiuno; 01.06.2020