HTTP-запрос не авторизован с помощью схемы аутентификации клиента 'Ntlm' - PullRequest
Новая
       17

HTTP-запрос не авторизован с помощью схемы аутентификации клиента 'Ntlm'

13 голосов
/ 07 февраля 2011

При вызове веб-службы я получаю следующую ошибку:

HTTP-запрос не авторизован по схеме проверки подлинности клиента «NTLM».Заголовок аутентификации, полученный от сервера, был «NTLM».HTTP-запрос не авторизован с помощью схемы аутентификации клиента NTLM.Заголовок аутентификации, полученный от сервера, был 'NTLM'.

У меня есть приложение Silverlight 4, которое вызывает веб-службу WCF, обе на моем IIS (7).мой веб-сервис WCF вызывает другую веб-службу ASMX, установленную на другом веб-сервере, с использованием NTLM (проверка подлинности Windows).Оба сервера, мой и тот, на котором размещена веб-служба ASMX, находятся в одном домене.

Когда клиент Silverlight открывает приложение с сервера с помощью http://localhost/MySiteName, все работает нормально.Но когда клиент Silverlight открывает приложение с другого клиента, который не является сервером, но все еще находится в том же домене, используя http://MyServerName/MySiteName, я получаю сообщение об ошибке.

Проверка подлинности Windows включена в моем IIS.Анонимная аутентификация отключена в моем IIS.

Конфигурация привязки для вызова моей веб-службы WCF: 

    <binding name="winAuthBasicHttpBinding">
      <security mode="TransportCredentialOnly">
        <transport clientCredentialType="Windows" />
      </security>
    </binding>

Конфигурация привязки для вызова веб-службы ASMX: 

    <binding name="ClNtlmBinding">
      <security mode="TransportCredentialOnly">
        <transport clientCredentialType="Ntlm" />
      </security>
    </binding>

Ответы [ 6 ]

18 голосов
/ 07 февраля 2011

ОК, вот что приходит на ум:

  • Ваша служба WCF, предположительно работающая на IIS, должна работать в контексте безопасности, который имеет привилегию, которая вызывает веб-службу. В пуле приложений необходимо убедиться, что пользователь, являющийся пользователем домена, в идеале выделенный пользователь.
  • Вы не можете использовать олицетворение, чтобы использовать маркер безопасности пользователя для передачи обратно в ASMX, используя олицетворение, начиная с my WCF web service calls another ASMX web service, installed on a **different** web server
  • Попробуйте изменить Ntlm на Windows и повторите тест.

Хорошо, несколько слов о подражании. По сути, это известная проблема, заключающаяся в том, что вы не можете использовать токены олицетворения, полученные на одном сервере, для передачи на другой сервер. Причина, по-видимому, заключается в том, что токен является своего рода хэшем, использующим пароль пользователя и действительным для компьютера, сгенерированного на нем, поэтому его нельзя использовать со среднего сервера. UPDATE Делегирование возможно в рамках WCF (то есть перенаправление олицетворения с сервера на другой сервер). Посмотрите на эту тему здесь .

7 голосов
/ 19 января 2012

Прошло много времени с того момента, как вопрос был опубликован, но я столкнулся с той же проблемой в аналогичном сценарии.У меня есть консольное приложение, и я использовал веб-службу, и на нашем сервере IIS, на котором размещен веб-сервис, включена проверка подлинности Windows (NTLM).

Я перешел по этой ссылке , и это решило мою проблему,Вот пример кода для App.config: 

<system.serviceModel>
    <bindings>
        <basicHttpBinding>
            <binding name="Service1Soap">
                <security mode="TransportCredentialOnly">
                    <transport clientCredentialType="Ntlm" proxyCredentialType="None"
                        realm=""/>
                    <message clientCredentialType="UserName" algorithmSuite="Default"/>
                </security>
            </binding>
        </basicHttpBinding>
    </bindings>
    <client>
        <endpoint address="http://localhost/servicename/service1.asmx" 
            binding="basicHttpBinding" bindingConfiguration="ListsSoap"/>
    </client>
</system.serviceModel>
4 голосов
/ 29 июня 2016

Для меня решение было помимо использования "Ntlm" в качестве типа учетных данных, аналогичного решению Jeroen K.Если бы у меня был уровень разрешений, я бы добавил к его сообщению плюс, но позвольте мне опубликовать здесь весь мой код, который будет поддерживать как Windows, так и другие типы учетных данных, такие как базовая аутентификация: 

    XxxSoapClient xxxClient = new XxxSoapClient();
    ApplyCredentials(userName, password, xxxClient.ClientCredentials);

    private static void ApplyCredentials(string userName, string password, ClientCredentials clientCredentials)
    {
        clientCredentials.UserName.UserName = userName;
        clientCredentials.UserName.Password = password;
        clientCredentials.Windows.ClientCredential.UserName = userName;
        clientCredentials.Windows.ClientCredential.Password = password;
        clientCredentials.Windows.AllowNtlm = true;
        clientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;
    }
3 голосов
/ 01 марта 2016

Мне пришлось перенести домен, имя пользователя, пароль с

client.ClientCredentials.UserName.UserName = домен + "\\" + имя пользователя; client.ClientCredentials.UserName.Password = пароль

до

client.ClientCredentials.Windows.ClientCredential.UserName = имя пользователя; client.ClientCredentials.Windows.ClientCredential.Password = пароль; client.ClientCredentials.Windows.ClientCredential.Domain = домен;

0 голосов
/ 09 января 2013

Может быть, вы можете обратиться к: http://msdn.microsoft.com/en-us/library/ms731364.aspx Мое решение состоит в том, чтобы изменить 2 свойства authenticationScheme и proxyAuthenticationScheme для «Ntlm», а затем он работает.

PS: Моя среда выглядит следующим образом - Серверная сторона: .net 2.0 ASMX - Клиентская сторона: .net 4

0 голосов
/ 10 августа 2012

1) Мне пришлось сделать следующее с моей конфигурацией: (Добавить BackConnectionHostNames или Отключить проверку по шлейфу) http://support.microsoft.com/kb/896861

2) Я работал с системой dev в изолированной сети dev. Я работал, используя имя компьютера системы разработчика в URL-адресе веб-службы, но когда я изменил URL-адрес на URL-адрес, который будет использоваться в производственной среде (а не на имя компьютера), я начал получать ошибку NTLM.

3) Я заметил, что журнал безопасности показал, что учетная запись службы не может войти в систему с ошибкой, аналогичной той, которая описана в статье MSDN.

4) Добавление BackConnectionHostNames позволило мне войти на сервер через браузер, работающий на сервере, но при попытке аутентификации для веб-сервисов в учетной записи службы все еще были ошибки NTLM. Я отключил проверку обратной связи, и это исправило ее для меня.

...