воскресенье, 23 января 2011 г.

Непонятный TrustedHosts

На днях мой коллега задал мне вопрос, на который я не смог ответить с ходу. Ему не удавалось подключиться, с помощью powershell remoting, к удаленному серверу, находящемуся в другом домене. При попытке сделать это он получал примерно вот такое сообщение

Не удалось подключиться к удаленному серверу. Сообщение об ошибке: Клиенту WinRM не удается обработать запрос. Проверку подлинности по умолчанию можно использовать с IP-адресом при следующ
их условиях: транспортом является HTTPS или назначением является список TrustedHosts, кроме того, должны быть предоставлены явно указанные учетные данные. Чтобы настроить TrustedHosts, используйте winrm.
cmd. Обратите внимание, что в списке TrustedHosts могут находиться компьютеры, не прошедшие проверку подлинности. Для получения сведений о настройке TrustedHosts используйте следующую команду: winrm help
config. Дополнительные сведения см. в разделе справки, вызываемом командой about_Remote_Troubleshooting.

Я, в свою очередь, тоже попробовал сделать это в разных окружениях и получил несколько разных результатов:

Если клиент не входит в домен

IP Address

После нескольких экспериментов мой коллега сообщил, что если добавить адрес удаленного сервера в 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.

6 комментариев:

Unknown комментирует...

>Вкратце, там сказано, что нельзя в качестве использовать IP-адреса в качестве SPN. И если в windows xp/2003 это работало то в Vista и старше при использовании IP-адреса в назначении не будет даже попыток использовать kerberos.
Не совсем так. Kerberos никогда не работал по IP-адресам. Просто при использовании IP происходит fallback на менее надежный протокол - NTLM2. В Vista+ политики безопасности были несколько подкручены чтобы сократить такие ситуации, но очень рекомендуется это сделать и на более старых ОС.

ЗЫ: "в качестве" два раза в предложении.
ЗЗЫ: Отличный пост!

Unknown комментирует...

В виста и тд это действительно так. А вот в xp/2003 там можно было создать SPN запись типа CIFS/10.10.10.10 и такое работало. Теперь работать не будет.Я это имел ввиду.
Спасибо за комментарий.

Unknown комментирует...

Поправил это самое "в качестве" :)

Unknown комментирует...

Решил немного пояснить свою точку зрения тут по поводу kerberos. Идея в чем. Если вы пытаетесь обратиься к ресурсу будь то из командной строки или из приложения то в любом случае задаете или имя или адрес. из этих параметров (имени или адреса) клиент/сервер строит SPN. При этом, при работе по сети той же gethostbyname, которая вероятнее всего будет использоваться для разрешения имени, абсолютно все равно имя вы указали или адрес. В конечном итоге на старых системах. можно было зарегистрировать SPN вида CIFS/10.10.10.10, клиент или сервер строили такую же строку и все работало. На новых системах ,если я правильно понимаю, проверка производится на этапе построения строки, и если в ней усматривается IP-адрес - генерируется исключение. Скорее всего это даже не вопрос безопасности а скорее вопрос удобства, поскольку перерегистрацию SPN при смене IP пришлось бы делать вручную, что не всегда очевидно. Вот так мне кажется.

Unknown комментирует...

Спасибо, мне помогло подключится server manager после ввода в trusted hosts именно имени сервера а не ip. Кстати в других ситуациях помогало прописать имя к ip в файле hosts.

Unknown комментирует...

файл hosts - это файл, используемый для разрешения имен в IP адреса. ТО есть, если используя стандартные механизмы, как -то DNS или WINS имя в адрес разрешить не удается. Ну или по каким-то причинам нельзя использовать эти механизмы - используется этот файл. В нм указано соответствие имени адресу. В итоге, прописав в него искомое имя и указав в строке скрипта это имя оно корректно разрешится и все будет работать.