SOAPアダプタポートに資格情報を指定してBizTalkからWebサービスを使用しようとしています。認証資格情報を使用してBizTalkからWebサービスを使用する
WebサービスのURLを入力してから、匿名、基本、ダイジェスト、およびNTLMの認証タイプを選択できます。
私はどのように私のユーザー名、パスワード、およびドメインを提供しますか？soapUIでテストするとき、それは完全に動作します。
資格情報を提供する唯一の方法は、基本またはダイジェストですが、私が入力した内容に関係なく、「自動化されていません」というエラーが表示されます。
奇妙なことは、NTLM認証タイプを選択したときに実際に動作することですが、資格情報を入力していないときにどのようにアクセスするのですか。私のサーバーがサービスに直接アクセスできる方法はありませんか？
ご質問の内容が不足しています - ウェブサービスはどのようにセキュリティ保護されていますか？ soapUIを使用して動作すると、どのくらい正確に表示されますか？資格情報がサービスにどのように供給されたかを確認しましたか？問題のサービスに対するアクセス許可を持つユーザーの下でsoapUIが実行されていた可能性があります（NTLM認証で動作するBizTalk呼び出しに似ています）。
間違いなく、基本またはダイジェストを使用するには、送信ポートに正しい資格情報を入力するだけで、それらが正しいと仮定してウェブサービスが正しく設定されていれば、うまく動作するはずです。
これを慎重にテストするには、まずサービスを呼び出す権限のないユーザー（soapUIまたはカスタムテストコード）を実行していることを確認します（既にそうでないと仮定して）。別のクライアントから適切な資格情報を使ってサービスを正常に呼び出すと（たとえば、間違ったパスワードを入力すると失敗することも証明されます）、送信ポートで同じユーザー名とパスワードの組み合わせを使用します。ところで、プロキシ設定を確認することも便利です。要求が拒否されているプロキシであり、サービスではない場合は、いくつかの機会に私に起こったように、物事はかなり混乱することがあります。 HttpAnalyzerフィドラーのすべてのケースで
は、ワイヤ上のトラフィック
WSDLを表示したり、サービスを呼び出す際には、ドメイン、ユーザー名、パスワードの形式でADユーザーの資格情報を提供する必要があります。 soapUIを使用すると、サービスにテストコールを発信するときにこれらを簡単に提供できるようになり、うまく動作しますが、もちろん提供されたときに限ります。 SOAPアダプタのBizTalkではWSDL URLを提供し、BasicまたはDigestを使用する場合は、ADユーザーの資格情報が機能しません。しかし、NTLMモードでは私は奇妙に動作します。これは私がBizTalkソリューションにWeb参照を追加したときに提供したものですか？ – lox
NTLMモードを使用している場合、送信ホストが実行されている資格情報は使用されません –
、次の何が起こっているかを理解する上で非常に有用であることができ、それは、内部のWebサービスですか？ BizTalkアカウントにはWebサービスに対するアクセス許可があるため、WebサービスはNTLMで動作する可能性があります。 – yieldvs
サービスは内部ネットワークではなく、全く異なるネットワーク上にあります。サービス提供者は、ドメイン、ユーザー名、パスワードの形でADユーザーを私に提供しました。 WSDLと提供されるサービスは、これらの資格情報が提供されている場合にのみ呼び出すことができます。 – lox