20

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

誰か助けてくれませんか？

4

7 に答える 7

10

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

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

これは、次の行の間を多少読んだことに基づいています。資格情報の種類の選択

于 2012-12-04T14:40:38.877 に答える
8

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

別のオプションとして、サーバーに NTLM を強制的に使用させることもできます。これは、メタベース (IIS 6) を編集し、ネゴシエート設定を削除することで実行できます。詳細については、http://support.microsoft.com/を参照してください。 kb/215383 .

IIS 7.x を使用している場合は、アプローチが少し異なります。認証プロバイダーの構成方法の詳細については、 http://www.iis.net/configreference/system.webserver/security/authentication/windowsauthentication を参照してください。

サーバー アドレスが xxx.xx.xx.xxx でブロックされていることに気付きました。これはサーバー名ではなく IP アドレスであると推測されます。これにより認証に問題が発生する可能性があるため、可能であればマシンをターゲットにしてみてください。名前。

回答ではなく、問題に近づくための指針を提供できなくて申し訳ありませんが、お役に立てば幸いです。

私はこれと同じ問題を経験しており、私の唯一の手段は NTLM ではなく Kerberos を使用することでした。このルートをたどる場合は、サービスに SPN を登録する必要があることを忘れないでください。

于 2012-12-05T17:57:57.187 に答える
6

クライアントとサービスの両方が同じマシンにインストールされていて、正しい (他の場所で試してテストした) クライアントとサービスの構成でこの問題に直面している場合は、確認する価値があるかもしれません。

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

%windir%/system32/drivers/etc/hosts

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

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

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

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

于 2016-03-24T18:13:47.877 に答える
2

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"
于 2015-03-18T15:50:54.523 に答える
1

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

Network Credentials オブジェクトを使用して、Windows のユーザー名とパスワードをサード パーティの SOAP Web サービスに解析しました。username="domainname\username"、password="password"、および domain="domainname" を設定しました。このゲームでは、NTLM エラーではなく、奇妙な Ntlm エラーが発生しました。この問題を解決するには、バックスラッシュを含むユーザー名にドメイン名が含まれている場合、NetworkCredentials オブジェクトでドメイン パラメーターを使用しないようにしてください。そのため、ユーザー名からドメイン名を削除してドメイン パラメータで解析するか、ドメイン パラメータを除外します。これで私の問題は解決しました。

于 2018-12-17T09:28:59.903 に答える