Является ли SPN по умолчанию для клиента WCF «host/myhostname» или «http/myhostname» и почему?

Из-за этого вопроса поведение по умолчанию, когда не указано identity, равно host/myhostname.

Однако это кажется не совсем верным.

У меня есть служба SOAP WCF (это веб-служба Dynamics NAV, но это не должно иметь значения для следующего, поскольку вопрос полностью касается точки зрения клиента), которая не работает, если я не укажу какую-либо личность.

Сервер фактически работает под учетной записью пользователя домена. host/myhostname указано, но не для этой учетной записи пользователя, а только для учетной записи компьютера. http/myhostname указан для этой учетной записи пользователя домена.

Давайте рассмотрим три сценария:

Личность не указана

Я создаю EndpointAddress со следующим кодом:

new EndpointAddress(new Uri(endpoint))

В этом сценарии происходит следующее:

  • HTTP POST без заголовка Authorization.
  • Ответ с WWW-Authenticate: Negotiate.
  • HTTP POST с заголовком Authorization: Negotiate XXX. XXX — это 1584 байта в кодировке BASE64, начиная с 96 130 6. Я не могу найти в нем читаемого ASCII.
  • Ответ с заголовком Authorization: Negotiate XXX. XXX — это 126 байтов в кодировке BASE64. Я не могу найти в нем читаемого ASCII.
  • HTTP POST с заголовком Authorization: Negotiate XXX. XXX — это 1527 байтов в кодировке BASE64. Я не могу найти в нем читаемого ASCII.
  • Ответ с заголовком WWW-Authenticate: Negotiate XXX. XXX — это 113 байтов в кодировке BASE64. Я не могу найти в нем читаемого ASCII.
  • В этот момент клиент выдает исключение. Внутреннее сообщение об исключении — The target principal name is incorrect.

Вручную установите идентификатор host/myhostname или неверную строку.

Я создаю EndpointAddress со следующим кодом:

var identity = EndpointIdentity.CreateSpnIdentity(@"host/myhostname");
var endpointAddress = new EndpointAddress(new Uri(endpoint), identity);

Если бы host/myhostname было настройкой по умолчанию, приведенный выше код просто явно указывал бы эту настройку по умолчанию. Поэтому я ожидаю такого же поведения. Но это работает. Кажется, я возвращаюсь к NTLM. Так что должна быть разница.

Вот что происходит:

  • HTTP POST без заголовка Authorization.
  • Ответ с WWW-Authenticate: Negotiate.
  • HTTP POST с Authorization: Negotiate XXX, где XXX — 40 байтов в кодировке BASE64. Первые байты — это буквы ASCII NTLMSSP.
  • Ответ с WWW-Authenticate: Negotiate XXX, где XXX — 270 байтов в кодировке BASE64. Первые байты — это буквы ASCII NTLMSSP. Также полное доменное имя, похоже, закодировано как ASCII.
  • HTTP POST с Authorization: Negotiate XXX, где XXX — 590 байтов в кодировке BASE64. На этот раз без букв ASCII.
  • Ответ с полезной нагрузкой.

Интересный факт: если я укажу идентификатор любой неправильной строки, у меня будет точно такое же поведение. Так, например, если я укажу EndpointAddress с этим кодом:

var identity = EndpointIdentity.CreateSpnIdentity(@"thisIsTotallyWrongLoremIpsum");
var endpointAddress = new EndpointAddress(new Uri(endpoint), identity);

Я также получаю описанное выше поведение с откатом к NTLM.

Я правильно установил идентификатор http/myhostname

Теперь, когда я указываю SPN на http/myhostname, который установлен и кажется правильным выбором из-за RFC 4559 это работает. Это конфигурация:

var identity = EndpointIdentity.CreateSpnIdentity(@"http/myhostname");
var endpointAddress = new EndpointAddress(new Uri(endpoint), identity);

И вот что происходит:

  • HTTP POST без заголовка Authorization.
  • Ответ с WWW-Authenticate: Negotiate.
  • HTTP POST с заголовком Authorization: Negotiate XXX. XXX — это 1580 байтов в кодировке BASE64. Никаких знаков ASCI.
  • Ответ с полезной нагрузкой.

Этот вопрос не о том, чтобы заставить его работать, а о понимании. Что меня смущает, так это разница между первым и вторым примером. Мои мысли:

  1. Если идентификатор по умолчанию — host/myhostname,
  2. не должно иметь никакого значения, чтобы вручную указать идентификатор для host/myhostname,
  3. Но есть разница
  4. так что это не может быть идентификатором по умолчанию.

Итак, мои вопросы

  1. Каково фактическое поведение по умолчанию и
  2. почему http/myhostname не выбрано в качестве имени участника-службы по умолчанию, как должно быть, из-за RFC4559?

И/или я что-то совсем не так понял?


wcf kerberos spnego negotiate spn
person Lux    schedule 02.12.2016    source источник
comment
Когда я указываю SPN и устанавливаю для него host/myhostname, который не зарегистрирован, или что-то еще, я могу буквально использовать строку что угодно, кажется, что я возвращаюсь к NTLM. ДОЛЖЕН быть зарегистрированный SPN, чтобы аутентификация Kerberos могла выполняться. Работа. SPN — это то, как клиенты Kerberos находят службы, защищенные Kerberos. Отсутствие имени участника-службы означает, что аутентификация Kerberos никогда не будет работать, и вы, вероятно, вернетесь к NTLM (в зависимости от политики) в соответствии с моделью Microsoft IWA. SPN должны быть полностью квалифицированы DNS, иначе клиент рискует переключиться на NTLM. http/myhostname, если он не существует - всегда будет сбой   -  person T-Heron    schedule 03.12.2016
comment
Еще одна вещь - http/имя хоста не существует по умолчанию, в то время как хост/имя хоста существует.   -  person T-Heron    schedule 03.12.2016
comment
@THeron, конечно, должно быть зарегистрированное имя участника-службы. Но почему WCF отказывает в проверке подлинности, если я не указываю имя участника-службы, и возвращается к NTLM, когда я указываю несуществующее имя?   -  person Lux    schedule 04.12.2016
comment
Этот случай является отличным примером того, почему вы должны настроить имя участника-службы на сервере приложений, связанном с учетной записью пользователя домена AD. Без указания чего-либо заранее при настройке веб-серверов Windows имена участников-служб будут создаваться с использованием host/myhostname, и проверка подлинности Windows попытается использовать его. Это то, что вы имели в виду под поведением по умолчанию, когда идентификатор не указан, это host/myhostname. По вашему утверждению SOAP WCF Service не работает, если я не укажу никакой личности. Поэтому настройте удостоверение с помощью созданного вручную SPN, такого как HTTP/myhostname.mydomain.local, и все должно работать.   -  person T-Heron    schedule 04.12.2016
comment
@THeron, это просто неправильно. Как я показал, есть есть разница между указанием host/myhostname в качестве удостоверения и указанием отсутствия. Таким образом, host/myhostname не является поведением по умолчанию. Каково фактическое поведение по умолчанию?   -  person Lux    schedule 05.12.2016
comment
То, что я видел, это всего лишь ваша интерпретация сценария. Есть ли у вас какие-либо сохраненные захваты пакетов или сообщения журнала ошибок, подтверждающие ваши утверждения? Если вы каким-то образом сделаете захваты пакетов/фрагменты журнала доступными, скажем, в DropBox, я проанализирую их и вернусь с дополнительными комментариями. До тех пор я не хочу возвращаться к этому, пока не увижу несколько конкретных примеров предметов, подтверждающих эти утверждения. Мне интересно продолжать копаться в этом.   -  person T-Heron    schedule 05.12.2016
comment
@THeron Хм, может быть, я не совсем понял свой вопрос. Я отредактировал, чтобы прояснить ситуацию. Данные извлекаются из пакетов с fiddler2. К сожалению, я не могу раздавать бинарные пакеты, но если вы сообщите мне, какая информация может быть полезной, я буду рад их предоставить. Я благодарен за вашу помощь. Теперь вы можете следовать моему выводу, что host/myhostname не может быть идентификатором по умолчанию?   -  person Lux    schedule 05.12.2016
comment
Я видел, что вы только что открыли награду за этот вопрос. Это может привлечь внимание Майкла-О или Самсона Шарфрихтера, двух лучших людей Kerberos, которых я видел на SO с тех пор, как присоединился к ней. В противном случае я внимательно перечитаю ваш вопрос позже на этой неделе, проверю его и отвечу после этого. Я также проголосовал за ваш последний комментарий, так как открытие награды — это круто. :-)   -  person T-Heron    schedule 05.12.2016
comment
Обновление: сообщение, которое вы процитировали в начале своего вопроса .com/questions/24966779/ принадлежит пользователю с показателем репутации всего 33. Не для того, чтобы дискредитировать его только на этом основании, но ответ так и не был принят, и за него никогда не проголосовали, и он сидел уже более полутора лет. Тем не менее, он также никогда не был отклонен. Я начинаю исследования, это займет несколько дней, так как я также занят другими делами.   -  person T-Heron    schedule 06.12.2016
comment
Вопрос: В сценарии № 2, в котором вы сказали, что он работает, хотя он не должен был работать после намеренной установки неправильной строки. Итак, что происходит после перезапуска сервера приложений, очистки кеша веб-браузера клиента, а затем повторного запуска браузера и повторной попытки? В таком случае аутентификация должна ожидаемо завершиться ошибкой.   -  person T-Heron    schedule 06.12.2016
comment
@THeron У меня нет доступа через веб-браузер. Я говорю о клиенте WCF. И описанное поведение, при котором я возвращаюсь к NTLM, и оно работает, сохраняется после перезагрузки сервера. Я даже могу воспроизвести это в двух совершенно независимых средах. Также да, вероятно, процитированный ответ неверен или, по крайней мере, неполный.   -  person Lux    schedule 06.12.2016
comment
1) Каково фактическое поведение по умолчанию? Если удостоверение не указано, а тип учетных данных клиента — Windows, по умолчанию используется имя участника-службы со значением, равным части имени узла адреса конечной точки службы с префиксом узла/литерала. Этот параметр использует преимущества безопасности Windows Kerberos, если служба работает под одной из системных учетных записей или под учетной записью домена, с которой связано имя участника-службы, а компьютер является членом домена в среде Active Directory. Ссылка: msdn.microsoft.com/en-us /библиотека/ms733130(v=vs.110).aspx   -  person T-Heron    schedule 07.12.2016
comment
2) Почему http/myhostname не выбран в качестве имени участника-службы по умолчанию, как это должно быть из-за RFC4559? С веб-браузером вы должны подключиться как http/myhostname. Но с клиентом WCF по умолчанию используется подключение как host/myhostname, как указано выше. И он определенно будет подключаться к host/myhostname по вашему сценарию № 2, где вы устанавливаете идентификатор host/myhostname. Имеет смысл?   -  person T-Heron    schedule 07.12.2016
comment
Я структурировал свои последние два ответа специально для ваших вопросов. Я не помещал их в формат Ответ на тот случай, если вы хотите получить больше ясности в ответах. Дайте мне знать, если это так, и я изучу больше, или дайте мне знать, действительно ли они удовлетворительно отвечают на ваш вопрос, и я помещу их в Ответ, чтобы другие могли извлечь пользу из вашего вопрос.   -  person T-Heron    schedule 07.12.2016
comment
@THeron спасибо за ваш ответ. Там ссылка msdn действительно интересна. Я просто абсолютно не понимаю, почему у меня другое поведение между № 1 и № 2, если host/myhostname является SPN по умолчанию. Почему он возвращается к NTLM в № 2 и выдает исключения в № 1. Я бы ожидал прямо противоположного: если я укажу SPN, он никогда не должен вернуться к NTLM, но если я не укажу идентификатор, он может вернуться к NTLM. Однако; если вы напишете это как ответ, я соглашусь, если в ближайшие несколько дней не будет более подробной информации.   -  person Lux    schedule 08.12.2016
comment
Спасибо Люкс. Прежде чем я напишу это как ответ, давайте обсудим еще несколько комментариев на случай, если кто-то еще читает это и хочет присоединиться. Различия в поведении, которые вы заметили между № 1 и № 2, очень интересны. Возврат к NTLM происходит по разным причинам. Чтобы выяснить это, нужно понять, почему не удалось выполнить работу Kerberos — основной причиной являются проблемы с SPN. Kerberos на самом деле нужны полные DNS-имена (ваши примеры, такие как host/myhostname, являются короткими именами). Это будет показательно: blogs.iis.net/brian -мерфи-бут/   -  person T-Heron    schedule 08.12.2016
comment
Отмечается пункт о различном поведении между # 1 и # 2, если host/myhostname является SPN по умолчанию. В тестовой среде наверняка происходит что-то странное.   -  person T-Heron    schedule 08.12.2016
comment
@THeron Спасибо за ссылку, для меня это была недостающая часть головоломки. Порт не используется, когда имя участника-службы определяется автоматически. Таким образом, http://foo.example.com:1234 ведет к host/foo.example.com как SPN. И когда имя участника-службы не существует, оно возвращается к NTLM, а когда имя участника-службы существует, но не для нужного пользователя, оно создает исключение The target principal name is incorrect.   -  person Lux    schedule 08.12.2016
comment
Большой. Спасибо, что прокомментировали этот Lux. Я приведу решение этого вопроса в виде ответа, чтобы он мог помочь другим при поиске того же или похожего вопроса.   -  person T-Heron    schedule 08.12.2016

Ответы (1)


arrow_upward
4
arrow_downward

В конце постановки задачи были представлены два конкретных вопроса; перечислив их ниже.

Q. 1) Каково фактическое поведение по умолчанию?

A. Если удостоверение не указано, а тип учетных данных клиента — Windows, по умолчанию используется имя участника-службы со значением, заданным как часть имени хоста адреса конечной точки службы с префиксом литерала «host/». Этот параметр использует преимущества безопасности Windows Kerberos, если служба работает под одной из системных учетных записей или под учетной записью домена, с которой связано имя участника-службы, а компьютер является членом домена в среде Active Directory.

Q. 2) Почему http/myhostname не выбран в качестве имени участника-службы по умолчанию, как это должно быть из-за RFC4559?

A. С веб-браузером вы должны подключиться как http/myhostname. Но с клиентом WCF по умолчанию используется подключение как host/myhostname, как указано выше. И он определенно будет подключаться к host/myhostname по сценарию № 2, где вы устанавливаете идентификатор host/myhostname.

Ссылка на Q1 и Q2 выше: Идентификация службы и аутентификация

КОММЕНТАРИЙ. Возврат к NTLM происходит по разным причинам. Чтобы выяснить это, нужно понять, почему не удалось выполнить работу Kerberos — основной причиной являются проблемы с SPN. Отличным справочником по диагностике проблем SPN является блог Брайана Мерфи-Бут. Самая большая ошибка: ServicePrincipalName.

После просмотра блога Брайана Мерфи первоначальный задавший вопрос впоследствии обнаружил, что в сценарии проблемы использовался порт. «Порт не используется, когда имя участника-службы определяется автоматически. Итак, http://foo.example.com:1234 ведет к host/foo.example.com как имя участника-службы. И когда имя участника-службы не существует, он возвращается к NTLM, а когда имя участника-службы существует, но не для нужного пользователя, выдается исключение Целевое имя участника неверно. ."

person T-Heron    schedule 08.12.2016