На днях мой коллега задал мне вопрос, на который я не смог ответить с ходу. Ему не удавалось подключиться, с помощью powershell remoting, к удаленному серверу, находящемуся в другом домене. При попытке сделать это он получал примерно вот такое сообщение
| Не удалось подключиться к удаленному серверу. Сообщение об ошибке: Клиенту WinRM не удается обработать запрос. Проверку подлинности по умолчанию можно использовать с IP-адресом при следующ
их условиях: транспортом является HTTPS или назначением является список TrustedHosts, кроме того, должны быть предоставлены явно указанные учетные данные. Чтобы настроить TrustedHosts, используйте winrm.
cmd. Обратите внимание, что в списке TrustedHosts могут находиться компьютеры, не прошедшие проверку подлинности. Для получения сведений о настройке TrustedHosts используйте следующую команду: winrm help
config. Дополнительные сведения см. в разделе справки, вызываемом командой about_Remote_Troubleshooting. |
Я, в свою очередь, тоже попробовал сделать это в разных окружениях и получил несколько разных результатов:
После нескольких экспериментов мой коллега сообщил, что если добавить адрес удаленного сервера в TrustedHosts на клиентской машине, то все работает. Все довольно странно и запутано. По этому – давайте подробнее разберем все эти ситуации.
Прежде всего стоит отметить, что проблема возникает, когда используются не доменные окружения. То есть, если клиент и сервер находятся не в одном домене. Наиболее часто, на мой взгляд, встречаются три ситуации:
-
компьютеры сервера и клиента расположены в разных доменах
-
компьютер сервера расположен в домене а клиент – вне домена
-
компьютеры сервера и клиента не входят в домен
Кроме того, исходя из сообщений об ошибках (да, их надо читать внимательно), и, соответственно, из методов обращения к серверу, есть две ситуации:
- при обращении к серверу, клиент указывает IP-адрес в качестве адреса назначения
- при обращении к серверу, клиент указывает имя в качестве адреса назначения
К сожалению в интернетах нет однозначного мнения по поводу того, где, на сервере или клиенте, нужно задавать параметр TrustedHosts, и нужно ли это вообще делать. На что это влияет и все такое. В целом, информация довольно скудная по этому поводу. Поэтому, после долгого забега по гуглу, я решил обратиться, куда бы вы думали – да, к первоисточнику. А именно – к спецификации на ws-management. Про параметр TrustedHosts там сказано следующее:
TrustedHosts: Contains host names to which the Web Services Management Protocol Extensions for Windows Vista clients are allowed to send requests by using an authentication scheme and transport that does not allow the client to authenticate the service, such as Basic over HTTP.
The specified host names may be either Internet host names or IP addresses. TrustedHosts
- Blank: No hosts are trusted.
- The asterisk "*" character: All hosts are trusted.
- A list of host name patterns separated by the comma "," character, in which each host name can be one of four possible values:
- String starting with the asterisk "*" character and containing at least two characters. All hosts that share the suffix are trusted.
- String ending with the asterisk "*" character and containing at least two characters. All hosts that share the prefix are trusted.
- The exact string "": All NetBIOS names are trusted (for example, strings that do not contain the period "." character).
- A string without the asterisk "*" character: The host named by the string is trusted.
The default value for the <TrustedHosts> element MUST be a blank string.
Основная идея выделена. И это означает, что параметр TrustedHosts нужно использовать на клиенте. В этом списке указываются машины, при работе с которыми невозможно использовать схемы с поддержкой взаимной аутентификации. Таким образом, если и клиент и сервер находятся в одном домене, то для подключения вы можете использовать простую команду без дополнительных параметров.
Следующий этап – два домена с доверительными отношениями. В этом случае тоже нет необходимости в TrustedHosts. Однако необходимо обеспечить корректное разрешение имен. Однако, скажете вы, ведь в домене можно обращаться не только по имени, а еще и по адресу, и все должно работать корректно. А у нас, при попытке использовать адрес, вываливается ошибка. И вот тут возникает необходимость внимательно прочитать содержимое ошибки:
Проверку подлинности по умолчанию можно использовать с IP-адресом при следующих условиях: Транспортом является HTTPS или назначением является список TrustedHosts.
Прежде всего видим, что в TrustedHosts нужно указывать именно назначение. А почему такое ограничение на использование IP-адреса? Об этом написано в блоге Ask the Directory Services Team. Вкратце, там сказано, что нельзя в качестве использовать IP-адреса в синтаксисе записи SPN. И если в windows xp/2003 это работало то в Vista и старше при использовании IP-адреса в назначении не будет даже попыток использовать kerberos . Отсюда и ошибка: раз не используется протокол с взаимной аутентификацией – используйте HTTPS или пропишите TrustedHosts. Для того чтобы убедиться в этом, вы можете воспользоваться вашим любимым сниффером. В нем вы увидите, что клиент даже не пытается установить связь с сервером, если вы указываете в качестве назначения адрес. Ошибка выдается сразу. Более подробно про SPN вы можете так же прочесть в моей статье.
И наконец – не доменное окружение. Powershell знает, что клиентская машина не в домене. Значит kerberos по определению не возможен. Следовательно либо TrustedHosts либо HTTPS.
