В настоящее время я пытаюсь включить удаленное управление Windows (в частности, Powershell Remoting) между двумя ненадежными доменами, но безуспешно.
Краткое описание моей настройки:
- domain1 - моя рабочая станция находится в этом домене
- domain2 - сервер, к которому я хочу подключиться, находится в этом домене
Между этими доменами нет доверия.
Я пытаюсь создать удаленное соединение Powershell, используя следующие команды с моей рабочей станции (присоединенной к домену 1):
парам (
[Параметр (Обязательный = $ True)]
$ сервер
)
$ username = "домен \ пользователь"
$ password = read-host "Введите пароль для $ username" -AsSecureString
$ credential = New-Object System.Management.Automation.PSCredential ($ username, $ password)
$ session = New-PSSession "$ server" -Аутентификация CredSSP -Credential $ credential -UseSSL -SessionOption (New-PSSessionOption -SkipCACheck -SkipCNCheck)
Enter-PSSession $ session
Что приводит к следующему сообщению об ошибке:
New-PSSession: [computername.domain2.com] Не удалось подключиться к удаленному серверу computername.domain2.com со следующим сообщением об ошибке: Клиент WinRM
не может обработать запрос Политика компьютера не разрешает делегирование учетных данных пользователя целевому компьютеру, поскольку компьютер не является доверенным. Личность цели
компьютер можно проверить, если вы настроите службу WSMAN для использования действительного сертификата с помощью следующей команды: winrm set winrm / config / service '@ {CertificateThumbprint = ""}' или
Вы можете проверить средство просмотра событий на наличие события, которое указывает, что следующее имя участника-службы не может быть создано: WSMAN /. Если вы найдете это событие, вы можете вручную создать имя участника-службы, используя
setspn.exe. Если SPN существует, но CredSSP не может использовать Kerberos для проверки подлинности целевого компьютера, и вы все еще хотите разрешить делегирование учетных данных пользователя целевому компьютеру.
компьютер, используйте gpedit.msc и просмотрите следующую политику: Конфигурация компьютера -> Административные шаблоны -> Система -> Делегирование полномочий -> Разрешить свежие учетные данные только с NTLM
Проверка подлинности сервера. Убедитесь, что он включен и настроен с использованием имени участника-службы, соответствующего целевому компьютеру. Например, для имени целевого компьютера «myserver.domain.com» имя участника-службы может быть
один из следующих: WSMAN / myserver.domain.com или WSMAN / *. domain.com. Повторите запрос после этих изменений. Для получения дополнительной информации см. Раздел справки about_Remote_Trou Troubleshooting.
Я пробовал / проверял следующие вещи:
- Я проверил, что SPN существует для WSMAN \ computername & WSMAN \ computername.domain2.com в домене 2.
- Убедитесь, что Конфигурация компьютера -> Административные шаблоны -> Система -> Делегирование учетных данных -> Разрешить свежие учетные данные с проверкой подлинности сервера только для NTLM установлена правильно.
- Настроил winrm на целевом компьютере для использования ssl.
- Настроил CredSSP на целевом компьютере и моей локальной рабочей станции с помощью следующих команд:
Enable-WSManCredSSP -Role Server # на целевом компьютере Enable-WSManCredSSP -Ролевый клиент -DelegateComputer * -Force
- Я проверил, что никакие правила FW, локальные для компьютеров или сети, не блокируют мой доступ.
Ничто из этого не позволило мне успешно подключиться к целевому компьютеру в домене 2 с моей рабочей станции в домене 1. Я могу успешно подключиться к другим серверам, присоединенным к домену 1, но не к серверам в домене 2. Что-нибудь еще, что я должен искать и / или попытаться заставить это работать?
ОБНОВЛЕНИЕ 06/08/2015 Я фактически смог проверить, что я могу подключиться к серверу со своей рабочей станции без использования CredSSP, что было бы хорошо; однако мне нужно иметь возможность запускать сценарии для SharePoint, и это без CredSSP приводит к ошибке с правами доступа.
источник
Enable-WSManCredSSP -Role Client -DelegateComputer WSMAN/computername.domain2.com( msdn.microsoft.com/en-us/library/ee309365(v=vs.85).aspx , пункт 3.)Ответы:
В этой статье MSDN показано, как настроить WinRM для поддержки нескольких прыжков, что также касается создания подключений, когда Kerberos не поддерживается. Краткое резюме ниже.
В частности, раздел в статье, относящийся к параметру записи реестра / групповой политики AllowFreshCredentialsWhenNTLM, решил только мою проблему. Из статьи:
источник