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

Ответ 1

Вы можете устранить клиента из проблемы, используя wftech, это старый инструмент, но я нашел его полезным при диагностике проблем с проверкой подлинности. wfetch позволяет указать NTLM, Negotiate и kerberos, это может помочь вам лучше понять вашу проблему. Поскольку вы пытаетесь вызвать службу, а wfetch ничего не знает о WCF, я бы предложил применить привязку вашей конечной точки (PROVIDERSSoapBinding) к serviceMetadata, после чего вы можете выполнить HTTP GET WSDL для службы с теми же настройками безопасности.

Другой вариант, который может быть вам доступен, - заставить сервер использовать NTLM, вы можете сделать это, отредактировав метабазу (IIS 6) и удалив параметр Negotiate, более подробно на http://support.microsoft.com/kb/215383.

Если вы используете IIS 7.x, то подход немного отличается, подробности о настройке поставщиков проверки подлинности приведены здесь http://www.iis.net/configreference/system.webserver/security/authentication/windowsauthentication.

Я заметил, что вы заблокировали адрес сервера с помощью xxx.xx.xx.xxx, поэтому я предполагаю, что это IP-адрес, а не имя сервера, это может вызвать проблемы с аутентификацией, поэтому, если возможно, попробуйте таргетинг на имя машины.

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

Я закончу, сказав, что у меня возникла одна и та же проблема, и единственным моим правом было использовать Kerberos, а не NTLM, не забывайте, что вам нужно будет зарегистрировать SPN для этой услуги, если вы поедете по этому маршруту,

Ответ 2

Попробуйте установить 'clientCredentialType' в 'Windows' вместо 'Ntlm'.

Я думаю, что это то, что ожидает сервер, то есть когда он говорит, что сервер ожидает "Negotiate, NTLM", это на самом деле означает Windows Auth, где он попытается использовать Kerberos, если он доступен, или вернуться в NTLM, если нет (следовательно, "переговоры" )

Я основываю это на несколько чтения между строками: Выбор типа учетных данных

Ответ 3

Мы столкнулись с этой проблемой и обнаружили, что при использовании (в нашем случае IE) ошибка была запущена браузером в качестве учетной записи процесса, а затем изменение журнала сеанса через приложение (SharePoint). Я считаю, что этот сценарий проходит две схемы аутентификации:

• Обсуди
• NTLM

В приложении размещен веб-сервис *.asmx, который вызывается на сервере с балансировкой нагрузки, инициируя вызов веб-службы самому себе, используя привязку к WCF-подобному .NET3.5.

Код, который использовался для вызова веб-службы:

public class WebServiceClient<T> : IDisposable
{
    private readonly T _channel;
    private readonly IClientChannel _clientChannel;

    public WebServiceClient(string url)
        : this(url, null)
    {
    }
    /// <summary>
    /// Use action to change some of the connection properties before creating the channel
    /// </summary>
    public WebServiceClient(string url,
         Action<CustomBinding, HttpTransportBindingElement, EndpointAddress, ChannelFactory> init)
    {
        var binding = new CustomBinding();
        binding.Elements.Add(
            new TextMessageEncodingBindingElement(MessageVersion.Soap12, Encoding.UTF8));
        var transport = url.StartsWith("https", StringComparison.InvariantCultureIgnoreCase)
                            ? new HttpsTransportBindingElement()
                            : new HttpTransportBindingElement();
        transport.AuthenticationScheme = System.Net.AuthenticationSchemes.Ntlm;
        binding.Elements.Add(transport);

        var address = new EndpointAddress(url);

        var factory = new ChannelFactory<T>(binding, address);
        factory.Credentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;

        if (init != null)
        {
            init(binding, transport, address, factory);
        }

        this._clientChannel = (IClientChannel)factory.CreateChannel();
        this._channel = (T)this._clientChannel;
    }

    /// <summary>
    /// Use this property to call service methods
    /// </summary>
    public T Channel
    {
        get { return this._channel; }
    }
    /// <summary>
    /// Use this porperty when working with
    /// Session or Cookies
    /// </summary>
    public IClientChannel ClientChannel
    {
        get { return this._clientChannel; }
    }

    public void Dispose()
    {
        this._clientChannel.Dispose();
    }
}

Мы обнаружили, что если учетные данные сеанса совпадают с учетной записью процесса браузера, то использовался только NTLM, и вызов был успешным. В противном случае это приведет к этому исключенному исключению:

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

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

Ответ 4

Вам нужно установить NTAuthenticationProviders в NTLM

Статья MSDN: https://msdn.microsoft.com/en-us/library/ee248703(VS.90).aspx

Командная строка IIS (http://msdn.microsoft.com/en-us/library/ms525006(v=vs.90).aspx):

 cscript adsutil.vbs set w3svc/WebSiteValueData/root/NTAuthenticationProviders "NTLM"

Ответ 5

Если оба клиента и служба установлены на одном компьютере, и вы столкнулись с этой проблемой с помощью правильной (прочитанной: проверенной и проверенной в другом месте) конфигурации клиентов и сервисов, тогда это может стоить проверить.

Проверьте записи хоста в файле хоста

% Windir%/system32/драйверы/и т.д./хосты

Убедитесь, что вы получаете доступ к веб-службе с именем хоста, и то же имя хоста было связано с IP-адресом в файле hosts, упомянутом выше. Если да, учетные данные NTLM/Windows НЕ будут переданы от клиента к службе, так как любой запрос на это имя хоста будет перенаправлен снова на уровне машины.

Попробуйте выполнить одно из следующих действий:

• Удалите запись хоста этого имени хоста из файла hosts ИЛИ
• Если удаление записи хоста невозможно, попробуйте обратиться к своей службе с другим именем хоста. Вы также можете попробовать с IP-адресом вместо имени хоста

Изменить: Каким-то образом вышеуказанная ситуация имеет отношение к сценарию с балансировкой нагрузки. Тем не менее, если удаление записей хоста невозможно, отключите проверку цикла на машине. Обратитесь к методу 2 в статье https://support.microsoft.com/en-us/kb/896861

Ответ 6

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

Я использовал объект Network Credentials для анализа имени пользователя Windows и пароля для стороннего веб-сервиса SOAP. Я установил имя пользователя = "имя домена\имя пользователя", пароль = "пароль" и домен = "имя домена". Теперь эта игра мне та странная нтлм а не ошибка НТЛМ. Чтобы решить проблемы, не используйте параметр домена в объекте NetworkCredentials, если имя домена включено в имя пользователя с обратной косой чертой. Поэтому либо удалите имя домена из имени пользователя и проанализируйте параметр домена, либо не указывайте параметр домена. Это решило мою проблему.