HTTP請求未經授權使用客戶端身份驗證方案'Ntlm'。 從服務器收到的身份驗證標頭是“Negotiate，NTLM”

Question

我查看了大量的SO文章，甚至是其他網站，但似乎無法使這項服務正常運行。 我有一個我想要點擊的SOAP服務，它的配置如下：

<system.serviceModel>
    <bindings>
        <basicHttpBinding>
        <binding name="PROVIDERSSoapBinding">
            <security mode="TransportCredentialOnly">
            <transport clientCredentialType="Ntlm" proxyCredentialType="None" realm="" />
            </security>
        </binding>
        </basicHttpBinding>
    </bindings>
    <client>
        <endpoint address="http://xxx.xx.xx.xxx:9011/provider/services/PROVIDERS"
            binding="basicHttpBinding" bindingConfiguration="PROVIDERSSoapBinding"
            contract="ServiceReference1.ProviderRemote" name="PROVIDERS" />
    </client>
</system.serviceModel>

但是，從我的控制台應用程序中點擊它時出現以下錯誤：

HTTP請求未經授權使用客戶端身份驗證方案'Ntlm'。 從服務器收到的身份驗證標頭是“Negotiate，NTLM”。

有人可以幫幫我嗎？

Answer 1

嘗試將'clientCredentialType'設置為'Windows'而不是'Ntlm'。

我認為這是服務器所期望的 - 即當它說服務器期望“Negotiate，NTLM”時，實際上意味着Windows Auth，它將嘗試使用Kerberos（如果可用），或者如果沒有則返回NTLM（因此'談判'）

我的基礎是在以下幾行之間進行閱讀： 選擇憑證類型

Answer 2

您可以使用wftech消除客戶端問題，這是一個舊工具，但我發現它在診斷身份驗證問題時很有用。 wfetch允許您指定NTLM，Negotiate和kerberos，這可能會幫助您更好地理解您的問題。 當您嘗試調用服務並且wfetch對WCF一無所知時，我建議將端點綁定（PROVIDERSSoapBinding）應用於serviceMetadata，然后您可以使用相同的安全設置對服務執行WSDL的HTTP GET。

您可以使用的另一個選項是強制服務器使用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。

Answer 3

我們遇到了這個問題，發現在使用（在我們的情況下是IE）瀏覽器作為進程帳戶登錄時，然后通過應用程序（SharePoint）更改會話登錄時，會拋出錯誤。 我相信這種情況通過兩種認證方案：

1. 談判
2. NTLM

該應用程序托管了一個* .asmx Web服務，該服務在負載平衡服務器上調用，使用類似WCF的.NET3.5綁定啟動對自身的Web服務調用。

用於調用Web服務的代碼：

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”。

最后，我相當確定其中一種身份驗證方案將通過身份驗證而另一種身份驗證方案不會，因為它未被授予適當的訪問權限。

Answer 4

如果您的客戶端和服務都安裝在同一台計算機上 ，並且您在使用正確的（讀取：在其他地方嘗試過並嘗試過）客戶端和服務配置時遇到此問題，那么這可能值得檢查。

檢查主機文件中的主機條目

％WINDIR％/ SYSTEM32 /司機/ etc / hosts文件

檢查您是否使用主機名訪問Web服務，並且該主機名與上述hosts文件中的IP地址相關聯。 如果是，則NTLM / Windows憑據將不會從客戶端傳遞到服務，因為對該主機名的任何請求將在計算機級別再次路由。

請嘗試以下任一操作

• 從hosts文件中刪除該主機名的主機條目
要么
• 如果無法刪除主機條目，請嘗試使用其他主機名訪問您的服務。 您也可以嘗試使用IP地址而不是主機名

編輯：不知何故，上述情況與負載均衡的情況有關。 但是，如果無法刪除主機條目，則禁用機器上的環回檢查將有所幫助。 請參閱文章https://support.microsoft.com/en-us/kb/896861中的方法2

Answer 5

您需要將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"

Answer 6

我知道這個問題很老，但我的應用程序的解決方案與已經提出的答案不同。 如果像我這樣的其他人仍然有這個問題，並且上述答案都不起作用，這可能是問題所在：

我使用Network Credentials對象將Windows用戶名+密碼解析為第三方SOAP Web服務。 我設置了username =“domainname \\ username”，password =“password”和domain =“domainname”。 現在這個游戲我奇怪的Ntlm而不是NTLM錯誤。 要解決這些問題，請確保如果域名包含在帶有反斜杠的用戶名中，則不要在NetworkCredentials對象上使用domain參數。 因此，要么從用戶名中刪除域名，要么在域參數中解析，要么省略域參數。 這解決了我的問題。