web-dev-qa-db-ja.com

HTTP要求は、クライアント認証スキーム「Ntlm」で許可されていません。サーバーから受信した認証ヘッダーは「Negotiate、NTLM」でした

私はたくさんの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」でした。

誰か助けてくれますか？

c#.netwcfsoap
19
Mike Perrenoud

wftech を使用すると、クライアントを問題から排除できます。これは古いツールですが、認証の問題の診断に役立つことがわかりました。 wfetchを使用すると、NTLM、Negotiate、およびkerberosを指定できます。これにより、問題をよりよく理解することができます。サービスを呼び出そうとしてwfetchがWCFについて何も知らないので、エンドポイントバインディング（PROVIDERSSoapBinding）を serviceMetadata に適用することをお勧めします。その後、サービスのWSDLのHTTP GETを同じセキュリティ設定。

サーバーでNTLMを使用するように強制することもできます。メタベース（IIS 6）を編集し、ネゴシエート設定を削除してください。詳細は http：// support。 Microsoft.com/kb/21538 。

IIS 7.xを使用している場合、アプローチはわずかに異なります。認証プロバイダーの構成方法の詳細はこちら http://www.iis.net/configreference/ system.webserver/security/authentication/windowsauthentication 。

Xxx.xx.xx.xxxでサーバーアドレスをブロックしていることに気づいたので、これはサーバー名ではなくIPアドレスであると推測しています。名。

答えはお伝えできませんでしたが、問題に近づくための指針は提供していませんが、お役に立てば幸いです。

私はこの同じ問題を経験したと言って終わりますが、私の唯一の頼みはNTLMではなくKerberosを使用することでした。

8
David Martin

「clientCredentialType」を「Ntlm」ではなく「Windows」に設定してみてください。

これはサーバーが期待していることだと思います-つまり、サーバーが「Negotiate、NTLM」を期待していると言う場合、実際にはWindows Authを意味し、利用可能な場合はKerberosを使用し、そうでない場合はNTLMにフォールバックします（したがって「交渉」）

私はこれを以下の行の間の多少の読み取りに基づいています： Selecting a Credential Type

10
Chamila Chulatunga

この問題が発生し、プロセスアカウントとしてログインしたブラウザー（この場合はIE）を使用し、アプリケーション（SharePoint）を介してセッションログインを変更すると、エラーがスローされることがわかりました。このシナリオは2つの認証スキームに合格すると信じています。

  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」でした。

最終的に、適切なアクセスが許可されなかったため、認証スキームの1つは認証をパスし、もう1つはパスしないと確信しています。

4
ISZ

クライアントとサービスの両方が同じマシンにインストールされている場合、正しい（読む：他で試してテストした）クライアントとサービスの構成、これはチェックする価値があるかもしれません。

ホストファイルのホストエントリを確認する

％windir％/ system32/drivers/etc/hosts

ホスト名を使用してWebサービスにアクセスしているかどうか、およびその同じホスト名が上記のhostsファイル内のIPアドレスに関連付けられているかどうかを確認します。はいの場合、そのホスト名に対する要求はマシンレベルで再度ルーティングされるため、NTLM/Windows資格情報はクライアントからサービスに渡されません。

次のいずれかを試してください

  • そのホスト名のホストエントリをホストファイルから削除します
    • または
  • ホストエントリを削除できない場合は、別のホスト名でサービスにアクセスしてみてください。ホスト名の代わりにIPアドレスを試すこともできます

編集：どういうわけか、上記の状況は負荷分散シナリオに関連しています。ただし、ホストエントリを削除できない場合は、マシンのループバックチェックを無効にすると役立ちます。記事の方法2を参照してください https://support.Microsoft.com/en-us/kb/896861

3
ash

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"
2
mistrykam

私はこの質問が古いことを知っていますが、私のアプリケーションの解決策は、すでに提案された答えとは異なっていました。私のような他の誰かがまだこの問題を抱えていて、上記の答えがどれも機能しない場合、これが問題である可能性があります。

Network Credentialsオブジェクトを使用して、サードパーティへのWindowsユーザー名+パスワードを解析しましたSOAP webservice。username = "domainname\username"、password = "password"およびdomain = "このゲームは、NTLMエラーではなく、奇妙なNtlmです。問題を解決するには、ドメイン名がバックスラッシュ付きのユーザー名に含まれている場合、NetworkCredentialsオブジェクトのドメインパラメータを使用しないようにしてください。ユーザー名から解析し、ドメインパラメータで解析するか、ドメインパラメータを省略して、問題を解決しました。

1
nivs1978