Конечная точка клиента WCF: исключение SecurityNegotiationException без <dns> - PullRequest
Новая
       20

Конечная точка клиента WCF: исключение SecurityNegotiationException без <dns>

19 голосов
/ 06 мая 2010

У меня странная ситуация здесь. Я получил это работает, но я не понимаю почему. Ситуация выглядит следующим образом:

Существует служба WCF, которую мое приложение (веб-сайт) должно вызывать. Служба WCF предоставляет доступ к netTcpBinding и требует Transport Security (Windows). Клиент и сервер находятся в одном домене, но на разных серверах.
Генерация клиента приводит к следующему конфигу (в основном по умолчанию) 

<system.serviceModel>
    <bindings>
      <netTcpBinding>
         <binding name="MyTcpEndpoint" ...>          
              <reliableSession ordered="true" inactivityTimeout="00:10:00"
                              enabled="false" />
             <security mode="Transport">
                <transport clientCredentialType="Windows" protectionLevel="EncryptAndSign"/>
                <message clientCredentialType="Windows" />
            </security>
        </binding>
      </netTcpBinding>
    </bindings>
    <client> 
        <endpoint address="net.tcp://localhost:xxxxx/xxxx/xxx/1.0" 
                   binding="netTcpBinding" bindingConfiguration="MyTcpEndpoint" 
                   contract="Service.IMyService" name="TcpEndpoint"/>
    </client>
</system.serviceModel>

Когда я запускаю сайт и звоню в сервис, я получаю следующую ошибку: 

System.ServiceModel.Security.SecurityNegotiationException: Either the target name is incorrect or the server has rejected the client credentials. ---> System.Security.Authentication.InvalidCredentialException: Either the target name is incorrect or the server has rejected the client credentials. ---> System.ComponentModel.Win32Exception: The logon attempt failed
    --- End of inner exception stack trace ---
    at System.Net.Security.NegoState.EndProcessAuthentication(IAsyncResult result)
    at System.Net.Security.NegotiateStream.EndAuthenticateAsClient(IAsyncResult asyncResult)
    at System.ServiceModel.Channels.WindowsStreamSecurityUpgradeProvider.WindowsStreamSecurityUpgradeInitiator.InitiateUpgradeAsyncResult.OnCompleteAuthenticateAsClient(IAsyncResult result)
    at System.ServiceModel.Channels.StreamSecurityUpgradeInitiatorAsyncResult.CompleteAuthenticateAsClient(IAsyncResult result)
    --- End of inner exception stack trace ---

Server stack trace: 
    at System.ServiceModel.AsyncResult.End[TAsyncResult](IAsyncResult result)
    at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.End(SendAsyncResult result)
    at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)
....

Теперь, если я просто изменю конфигурацию клиента следующим образом: 

    <endpoint address="net.tcp://localhost:xxxxx/xxxx/xxx/1.0" 
               binding="netTcpBinding" bindingConfiguration="MyTcpEndpoint" 
               contract="Service.IMyService" name="TcpEndpoint">
        <identity>
            <dns />
        </identity> 
  </endpoint>

все работает, и мой сервер с радостью сообщает, что он вызван учетной записью службы, на которой размещен AppPool для моего веб-сайта. Все хорошо.

Мой вопрос сейчас: почему это работает? Что это делает? Я пришел к этому решению просто методом проб и ошибок. Мне кажется, что все, что делает тег <dns />, - это говорит клиенту использовать DNS по умолчанию для аутентификации, но разве это не так?

UPDATE
Поэтому после еще нескольких исследований и проб и ошибок я так и не нашел ответа на эту проблему. В некоторых случаях, если я не предоставляю <dns />, я получаю ошибку Credentials rejected, но если я предоставляю конфигурацию <dns value="whatever"/>, она работает. Почему?

Ответы [ 3 ]

16 голосов
/ 06 мая 2010
Тег

<dns/> позволяет клиенту проверить подлинность сервера. Например, если вы сказали <dns value="google.com"/>, это подтвердило бы, что сервер WCF предоставляет идентификацию google.com. Поскольку вы говорите <dns/>, это, вероятно, просто позволяет всем служить вам.

Больше информации на Идентификация и аутентификация сервиса

7 голосов
/ 29 февраля 2012

MSDN «Идентификация службы и аутентификация» объясняет, что раздел идентификации конечной точки обеспечивает меры безопасности на стороне клиента против фишинговых схем.

Из MSDN:

После того, как клиент инициирует связь с конечной точкой и служба аутентифицирует себя клиенту, клиент сравнивает значение идентификатора конечной точки с фактическим значением конечной точки процесс аутентификации возвращен. Если они совпадают, клиент уверен он связался с ожидаемой конечной точкой обслуживания. Это функционирует как защита от фишинга путем предотвращения клиента перенаправлен на конечную точку, размещенную вредоносной службой.

Также см. MSDN «Образец идентификатора службы» .

0 голосов
/ 25 октября 2017

Не ответ, но тот же «трюк» работает, если вы создаете EndpointAddress через код: 

// does fail on some machines for some users 
// (I have no explanation here - just crazy)
var address = new EndpointAddress(new Uri(url));

// will work and the dns entry doesn't matter
address = new EndpointAddress(new Uri(url), UpnEndpointIdentity.CreateDnsIdentity(""));

Это странно, и я не знаю, почему это работает, но, похоже, это помогает.

...