Удаленное управление Windows через ненадежные домены

В настоящее время я пытаюсь включить удаленное управление 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.

Я пробовал / проверял следующие вещи:

1. Я проверил, что SPN существует для WSMAN \ computername & WSMAN \ computername.domain2.com в домене 2.
2. Убедитесь, что Конфигурация компьютера -> Административные шаблоны -> Система -> Делегирование учетных данных -> Разрешить свежие учетные данные с проверкой подлинности сервера только для NTLM установлена ​​правильно.
3. Настроил winrm на целевом компьютере для использования ssl.
4. Настроил CredSSP на целевом компьютере и моей локальной рабочей станции с помощью следующих команд:

Enable-WSManCredSSP -Role Server # на целевом компьютере
Enable-WSManCredSSP -Ролевый клиент -DelegateComputer * -Force

5. Я проверил, что никакие правила FW, локальные для компьютеров или сети, не блокируют мой доступ.

Ничто из этого не позволило мне успешно подключиться к целевому компьютеру в домене 2 с моей рабочей станции в домене 1. Я могу успешно подключиться к другим серверам, присоединенным к домену 1, но не к серверам в домене 2. Что-нибудь еще, что я должен искать и / или попытаться заставить это работать?

ОБНОВЛЕНИЕ 06/08/2015 Я фактически смог проверить, что я могу подключиться к серверу со своей рабочей станции без использования CredSSP, что было бы хорошо; однако мне нужно иметь возможность запускать сценарии для SharePoint, и это без CredSSP приводит к ошибке с правами доступа.

В этой статье MSDN показано, как настроить WinRM для поддержки нескольких прыжков, что также касается создания подключений, когда Kerberos не поддерживается. Краткое резюме ниже.

Удаленное управление Windows (WinRM) поддерживает делегирование учетных данных пользователя на несколько удаленных компьютеров. Функциональность поддержки множественного перехода теперь может использовать поставщика аутентификации безопасности учетных данных (CredSSP) для аутентификации. CredSSP позволяет приложению делегировать учетные данные пользователя с клиентского компьютера на целевой сервер.

Аутентификация CredSSP предназначена для сред, в которых нельзя использовать делегирование Kerberos. Была добавлена ​​поддержка CredSSP, чтобы пользователь мог подключиться к удаленному серверу и получить доступ к компьютеру второго перехода, например, к общей папке.

В частности, раздел в статье, относящийся к параметру записи реестра / групповой политики AllowFreshCredentialsWhenNTLM, решил только мою проблему. Из статьи:

Если ни аутентификация Kerberos, ни отпечатки сертификатов недоступны, пользователь может включить аутентификацию NTLM. Если используется проверка подлинности NTLM, должна быть включена политика «Разрешить свежие учетные данные с проверкой подлинности сервера только для NTLM (AllowFreshCredentialsWhenNTLMOnly)», а в политику необходимо добавить имя участника-службы с префиксом WSMAN. Этот параметр менее безопасен, чем проверка подлинности Kerberos и отпечатки сертификатов, поскольку учетные данные отправляются на сервер без проверки подлинности.

Дополнительные сведения о политике AllowFreshCredentialsWhenNTLMOnly см. В описании политики, предоставленном редактором групповой политики, и в KB 951608. Политика AllowFreshCredentialsWhenNTLMOnly находится по следующему пути: Конфигурация компьютера \ Административные шаблоны \ Система \ Делегирование учетных данных.