Почему kerberos принимает значение по умолчанию к NTLM в WCF?
Получил простое демонстрационное приложение WCF, которое имеет два консольных проекта - хост и клиент. Оба работают на моей машине (выиграйте 7 полей). Я использую netTcpBinding, который использует аутентификацию Windows.
Проблема - то, что аутентификация понижает до NTLM от kerberos, и я не могу выяснить почему.
Если я использую
<clientCredentials>
<windows allowNtlm="true" />
</clientCredentials>
на стороне клиента все прохладно. Но если я изменяю это на false, Я получаю следующее исключение:
SecurityNegotiationException: удаленный сервер не удовлетворил требование взаимной аутентификации.
Это предполагает, что kerberos перестал работать и так как клиент не позволит NTLM результаты вызова в выданном исключении.
Действительно ли это - проблема с проектом, или действительно ли это - внешняя проблема, вызванная конфигурацией моей машины разработки?
Решение:
По-видимому, я должен указать идентификационные данные сервера в рамках клиентской конфигурации. В моем случае сервер работает под моими идентификационными данными, таким образом, я изменяю клиент таким образом:
<client>
<endpoint address="net.tcp://dev7.HurrDurr.com:12345/MyService"
binding="netTcpBinding"
bindingConfiguration="MyBindingConfigurationLol"
behaviorConfiguration="HurrDurrServiceEndpoint"
contract="ShaolinCore.ICommunicationService">
<!-- start changes here -->
<identity>
<userPrincipalName value="myusername@mydomain"/>
</identity>
<!-- end changes here -->
</endpoint>
</client>
Я не уверен, почему это устраняет проблему. Хорошо, теперь на стороне клиента я полностью доверительный сервер (эй, я знаю того парня!). Но так как NTLM менее безопасен, чем kerberos, почему это не наоборот? Если я не делаю полностью доверительный сервер, я использую kerberos, иначе ntlm прекрасен.
Или, OTOH, если я не делаю полностью доверительный сервер, почему он работает вообще? "SecurityException: идентификационные данные Конечной точки не набор. WCF не может доверять идентификационным данным сервера и не передаст клиентские идентификационные данные".
4 ответа
Когда я работал в командах разработчиков IIS4, 5 и 6, мы часто сталкивались с этим! Для работы Kerb необходимо, чтобы были выполнены следующие условия:
1) Обе стороны поддерживают kerb (все поддерживаемые версии Windows поддерживают Kerb сегодня)
2) Машины авторизуются в Active Directory
3) Имена Service Principal Names (SPNs) зарегистрированы для конечной точки сервера. В "старые добрые времена" вам приходилось делать это вручную с помощью SetSPN.exe. SPN - это просто конечная точка, к которой Kerb будет подключаться; эти данные нужны ему для поддержки взаимного аутентификации. Большинство приложений вызывают API approp, чтобы сделать эту работу за вас (DsWriteAccountSpn)
Если любой из шагов выше не верен, Windows обычно по умолчанию использует NTLM, что дает вам только клиентскую аутентификацию.
Надеюсь, это поможет! - Michael
Возможно, эта страница в MSDN - Отладка ошибок аутентификации Windows - помогает понять, что происходит - кажется довольно сложной относительно того, когда используется NTLM или Kerberos.
Информация из MSDN: netTcpBinding: Привязка по умолчанию использует транспортную безопасность с согласованной аутентификацией. Это согласование пытается использовать Kerberos, но если это не сработает, оно вернется и будет использовать более старый протокол NTLM. Kerberos - отличный выбор, если вы работаете в доменной среде; чтобы использовать его, вам нужно, чтобы и служба, и клиенты работали под доменными учетными записями. Вам также потребуется настроить основное имя службы (SPN) для вашей службы.
Как настроен сервер? У вас есть и в файле конфигурации?
Вы устанавливаете режим аутентификации через Тег аутентификации в файле конфигурации:
<configuration>
<system.web>
<authentication mode="Windows" />
</system.web>
</configuration>