Проверка подлинности Kerberos в автономной службе данных WCF

У нас есть служба данных WCF, которая размещается на собственном хостинге в службе Windows (без использования IIS), которую мы в настоящее время работаем над обеспечением безопасности с помощью SSL и проверки подлинности Windows.

После некоторого времени, поигравшего с netsh и сертификатами сервера, теперь у нас есть служба, защищенная с помощью SSL, и мы также включили аутентификацию Windows в привязке webHttpBinding в нашем app.config - однако теперь мы наблюдаем некоторое странное поведение при попытке аутентификации определенных пользователей - некоторые могут войти в систему нормально, учетные данные других отклоняются, и им выводятся сообщения об ошибках HTTP 400.

После некоторого тестирования и поиска может показаться, что мы можем столкнуться с этой проблемой, где аутентификация заголовок, используемый Kerberos, может быть больше, чем максимально разрешенная длина заголовка (которая, как я полагаю, составляет 16 КБ) для определенных пользователей - и, хотя существует документированный обходной путь для IIS, похоже, нет эквивалентной настройки, которую мы могли бы использовать для самостоятельной размещенная служба или в нашем app.config - если я чего-то не упускаю? Мы попытались установить для полей maxReceivedMessageSize и maxBufferSize их максимальные значения, чтобы увидеть, будет ли это иметь какое-либо значение, но, по-видимому, нет.

Конфигурация привязки:

  <webHttpBinding>
    <binding name="DataServicesBinding"
             maxReceivedMessageSize="2147483647"
             maxBufferSize="2147483647">
      <security mode="Transport">
        <transport clientCredentialType="Windows" />
      </security>
    </binding>
  </webHttpBinding>

Нам удалось временно обойти эту проблему, установив clientCredentialType в нашей привязке для использования вместо этого Ntlm, но мы хотели бы, чтобы Kerberos работал, если это возможно, по очевидным причинам.


person Sam    schedule 13.08.2013    source источник


Ответы (2)


Итак, как оказалось, это было вызвано тем, что наша служба не была настроена с SPN (имя участника-службы). Это можно сделать с помощью инструмента setspn с Windows Server. (См. эту статью MSDN для получения дополнительной информации.)

После применения SPN проверка подлинности Kerberos начала работать должным образом.

person Sam    schedule 11.09.2013

Используйте wirehark, чтобы увидеть, что отправляет клиент. Убедитесь, что это правильный ввод, а затем вернитесь.

person Michael-O    schedule 14.08.2013