Неспособный способный выполнить удаленный Powershell с помощью Active Directory
CREDSSP требовался бы в этом сценарии кто-либо?
Из этой ссылки - http://social.technet.microsoft.com/Forums/en/winserverpowershell/thread/094f9dd3-669a-4bea-9f81-f2ea009384d1
Для использования AD модуля, в дополнение к наличию Сервера 2 008 R2 или машина Windows 7 с модулем AD PowerShell, если Вы не выполняете Сервер 2 008 серверов R2 AD, Вам будет нужно это:
Если Вы пойдете с сервером AD Сервера 2003 или 2008 с вышеупомянутым дополнением, то Вам все еще будет нужен Сервер 2 008 R2 или система Windows 7, чтобы смочь использовать AD модуль. Используя дистанционную работу PowerShell, Вы смогли бы использовать любую систему с PowerShell v2, установленным для вызова AD модуля cmdlets удаленно, как обрисовано в общих чертах здесь:
-
1AD модуль установлен на сервере и работах, но только при выполнении его в то время как RDP'd в поле. – Mark 17 November 2010 в 23:05
-
2, Какие Контроллеры домена Вы выполняете? Я думаю, что часть о не хождении 2008R2 более релевантна, чем просто устанавливаемый модуль. – Christopher 17 November 2010 в 23:33
-
3Контроллер домена является 2 008 R2, как сервер, мы - дистанционная работа в от поля Windows 7. – Mark 17 November 2010 в 23:48
Вы соединились с сервером с помощью IP-адреса. Таким образом, Kerberos не может использоваться для аутентификации (который является, почему необходимо было использовать учетные данные). Таким образом, когда сервер пытается пройти проверку подлинности от Вашего имени, Вы сталкиваетесь со вторым выпуском транзитного участка. Сервер не может передать учетные данные третьей стороне, таким образом Вы получаете ошибки.
Ваш сценарий требует, чтобы Вы соединили клиент через Kerberos к серверу. Это только возможно, если Ваш клиент является доменным участником, и Вы используете имя сервера и не его IP-адрес.
Tobias www.powershell.com
-
1Даже с помощью имени сервера мы все еще надеваем ту же ошибку
Import-Module ActiveDirectoryзвонить. спасибо – Mark 18 November 2010 в 00:00
Вот пример использования CredSSP для решения аналогичной проблемы. Я проверил это, и он помогает устранить ошибку веб-служб AD, которую вы указали в своем вопросе.
Подводя итоги статьи, сначала вам нужно включить CredSSP как на клиенте, так и на сервере.
На клиенте: Enable-WSManCredSSP -Role Client -DelegateComputer [имя компьютера] -Force
На сервере: Enable-WSManCredSSP -Role Server –Force
Затем вам нужно получить или создать учетные данные для подключения к другой компьютер и создайте сеанс, использующий эти учетные данные. Затем вы можете использовать Invoke-Command для запуска ваших команд / сценариев PowerShell в блоке сценария в этом новом сеансе. Вот частичный пример из статьи с использованием команд из вашего вопроса:
$credential = Get-Credential -Credential iammred\administrator
$session = New-PSSession -cn SQL1.Iammred.Net -Credential $credential -Authentication Credssp
Invoke-Command -Session $session -ScriptBlock { Import-Module ActiveDirectory; Get-ADUser 'baz' }
Однако,
У меня была такая же проблема с несколькими нашими средами, и сработало изменение брандмауэра. Очевидно, ADWS использует порт 9389 , который был запрещен сервером, который пытался удаленно управлять контроллером домена с помощью PowerShell. Как только мы разрешили порт, все работает нормально.