PowerShell Remoting дает сообщение "Отказано в доступе"
Я пытаюсь использовать 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 на целевом сервере и устанавливаю соответствующие настройки для обеспечения Basic Auth и незашифрованного соединения:
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), но это не работает с той же проблемой.
Пользователь, которого я пытаюсь использовать, является членом локальных пользователей Admins на рассматриваемом сервере, поэтому разрешения уже должны быть установлены в контейнерах PSSessionConfiguration.
Мне бы хотелось, чтобы с этим были другие указатели! Я бы просто использовал WMI, но в данный момент он не включен через брандмауэры.
Ответы
Ответ 1
У нас были подобные проблемы в последнее время. Предложите вам внимательно проверить, имеет ли пользователь, с которым вы подключаетесь, соответствующие разрешения на удаленном компьютере.
Вы можете просмотреть разрешения с помощью следующей команды.
Set-PSSessionConfiguration -ShowSecurityDescriptorUI -Name Microsoft.PowerShell
Нашел этот совет здесь:
http://blogs.technet.com/b/heyscriptingguy/archive/2010/11/17/configure-remote-security-settings-for-windows-powershell.aspx
Он исправил это для меня.
Ответ 2
Запуск командной строки или PowerShell ISE в качестве администратора исправил это для меня.