аномалия аутентификации Windows wcf 4 / iis / server 2008

Question

У меня есть тестовая служба WCF 4, работающая на Windows 2008 / IIS 7.5 в домене.

Я использую проверку подлинности Windows для привязки.

Когда я получаю доступ к этой услуге из клиента Windows .net:

var b = new BasicHttpBinding(BasicHttpSecurityMode.TransportCredentialOnly);
b.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows;
EndpointAddress a = new EndpointAddress("http://server/TestService.svc");
TestServiceClient tsc = new TestServiceClient(b, a);                                  

Это работает, если я использую:

 tsc.ChannelFactory.Credentials.Windows.ClientCredential = new NetworkCredential("bob.jones", "password", "DOMAIN");

Сбой, если я использую:

tsc.ChannelFactory.Credentials.Windows.ClientCredential = CredentialCache.DefaultNetworkCredentials;

Когда это не удается, я вижу 401 в Fiddler: «401 - Несанкционированный: доступ запрещен из-за неверных учетных данных.»

Когда это удастся, я вижу тот же 401, но затем 200, и я могу видеть билет kerboros в запросе и ответе.

Вот мой конфиг службы:

<system.serviceModel>

<bindings>
  <basicHttpBinding>
    <binding>
      <security mode="TransportCredentialOnly">
        <transport clientCredentialType="Windows" proxyCredentialType="Windows"/>
      </security>
    </binding>
  </basicHttpBinding>
</bindings>

<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />

Answer 1

Видя, что никто больше не заинтересован, думаю, мне придется самому ответить на этот вопрос.

В этой проблеме было много мелких деталей, но я просто дам обзор того, что нашел:

1. Мне пришлось использовать провайдера «Согласовать: Kerberos», а не «Договариваться».

2. Мне пришлось настроить основное имя сервера (spn) для учетной записи домена, которую я использовал для пула приложений:

   setspn -A HTTP / Имя_сервера: порт Домен \ Имя_пользователя

   setspn -A HTTP / FQDN: порт Домен \ Имя пользователя

3. Еще одна вещь, которую я позже заметил в другом сервисе, где клиентское приложение не указывало точные BasicHttpSecurityMode.TransportCredentialOnly и ClientCredentialType = HttpClientCredentialType.Windows, заключалась в том, что на разных клиентских компьютерах требовалось «согласовать», а другим требовалось «согласовать» : Kerberos». Я еще не понял, смогу ли я это контролировать.