5

従来の ASP サイト用の VB6 バックエンドがあります。その VB は、MSXML2.XMLHTTP を使用して、同じサーバー上の Web サービスを呼び出します。これは、1 つを除くすべてのサーバーで機能します。匿名ログインを受け入れるように Web サービス サイトを設定すると機能しますが、統合セキュリティのみを強制すると、MSXML が Access Denied エラーを返します。

ここの例のコードを使用しています。

Set objDom = CreateObject("MSXML2.DOMDocument")
Set objXmlHttp = CreateObject("MSXML2.XMLHTTP")

' Load XML
objDom.async = False
objDom.loadXML XmlBody

' Open the webservice
objXmlHttp.Open "POST", AsmxUrl, False

' Create headings
objXmlHttp.setRequestHeader "Content-Type", "text/xml; charset=utf-8"
objXmlHttp.setRequestHeader "SOAPAction", SoapActionUrl

' Send XML command
objXmlHttp.send objDom.xml

編集: AnthonyWJones のアドバイスに従って、チェックリストを確認しましたが、まだ機能していません。Fiddler を使用すると、401 応答を含む単一の要求が表示されます。認証タブには以下が表示されます。

No Proxy-Authenticate Header is present.
WWW-Authenticate Header is present: Negotiate
WWW-Authenticate Header is present: NTLM

しかし、私は奇妙な行動に気づきました。リモートデスクトップにログインしているユーザーの資格情報を使用して Web サイトを呼び出すと、機能します。交渉、挑戦、そして 200 を取得すると、うまくいきます。ユーザーがリモートデスクトップ経由でログオンしているときにこれが機能するのに、それ以外の場合は機能しない理由はありますか?

4

3 に答える 3

3

ライアンに返信するには遅すぎるかもしれませんが、他の人も同じ問題を抱えている可能性があるので、これを投稿します。で同じ問題が発生している開発者がいMSXML2.XMLHTTPます。昔からこれを行うサンプルがあるので、以前は機能していたことはわかっていますが、現在は機能していません...最近導入されたバグでしょうか？スタックによるローカルイントラネットの自動検出に依存していたためWinINET、スタックはWindowsIntegratedを実行します。サイトはプロキシバイパスリストに含まれていました。デフォルトのオプションでは、サイトはローカルイントラネットに配置されます。実際、サイトを参照して[セキュリティ設定]タブに移動すると、ローカルイントラネットが強調表示されているので、機能しているように見えます。でも、MSXML2.XMLHTTPまだWindows統合を実行することを望んでいません...[セキュリティ]タブの[サイト/詳細設定]ボタンを使用してサイトをローカルイントラネットに直接追加しない限り。

WinINETしたがって、私の結論は、自動的に検出されたローカルイントラネットサイトをサイトリストに直接追加されたサイトとは異なる方法で処理する、ある種のバグがスタックにあるということです。面白いことに、サイトを参照すると、期待どおりに機能し、Windows Integratedが自動的に使用されます（サイトに直接追加しなくても）。それを介したプログラムによるアクセスのみMSXML2.XMLHTTPが機能しません。

最後に、これは私たちがやったことではありませんMSXML2.ServerXMLHTTP.6.0。代わりに使用しました。そのスタック（WinHTTP）は問題ないようですが、注意点があります。デフォルトではIEのプロキシ設定を使用しないため、いくつかのオプションがあります。ProxyCfg（XP以前の場合）またはNETSHVista以降のインポートに使用します。WinHTTPスタック内のIEプロキシ設定。欠点は、各クライアントマシンでの追加の構成です（これはファットクライアントVBアプリでした）。代わりに、送信の直前に次のように配置することを選択しました。

HTTP.SetProxy 2, "myproxy.mydomain.com", "*.mydomain.com"

mydomainサイトにアクセスするので、代わりにプロキシをバイパスするように言うことができると思うかもしれませHTTP.SetProxy 0んが、それは機能しません。スタックには、「プロキシがありますが、ドメインではプロキシをバイパスします。ちなみに、これからアクセスするサイトはそのドメインにあります。ローカルイントラネットです」と伝える必要があります。

于 2009-12-03T21:01:57.973 に答える
3

Windows統合セキュリティを使用してサーバーからチャレンジされたときに、現在のユーザーの資格情報をサーバーに提示するために、基盤となるWinINETHTTPスタックに依存していると思います。

WinINETは、ホストサーバーがイントラネットゾーンにあると見なした場合にのみ、デフォルトでこれを実行します。それでも、ユーザーのイントラネットゾーンのセキュリティ設定がこれを許可しないように調整されている可能性があります。

VB6アプリを実行しているのと同じユーザーとしてログオンしているときに、クライアントマシンからブラウザーを使用してサイトにアクセスしてみてください。サーバーはどのゾーンにあると見なされますか？イントラネットでない場合は、ゾーンに属するサイトのリストにホストを追加する必要があります。そこにいる間に、ゾーンのセキュリティ設定を開き、[ユーザー認証]カテゴリまで下にスクロールします。ログオンは、「イントラネットゾーンでのみ自動ログオン」として構成する必要があります。

編集：あなたのコメントから、これらのものは正しく構成されています。私がするであろういくつかのこと：-

  1. サーバーがWindows統合セキュリティのみを受け入れるように厳密に構成されていることを確認してください。
  2. マシンのプロキシ設定を確認してください。プロキシサーバーの問題で権限が拒否されていますか？
  3. ProgID "MSXML2.XMLHTTP.3.0"を使用して、正しいバージョンのMSXML dllが使用されていることを確認します（他のサードパーティアプリをインストールすると、レジストリが破損し、古いバージョンのMSXMLが使用される可能性があります）。
  4. マシンにFiddlerをインストールし、VB6アプリが呼び出しを試行したときのhttp会話を監視します。単一の401応答はありますか？WinINETはユーザー資格情報を使用していませんか？3 401の応答がありますか？WinINETは現在のユーザーの資格情報を使用しようとしましたが、サーバーによって受け入れられません。

この時点で、私たちはシステム管理者の領域に入ります。たとえば、フィドラートレースで、認証の試みがNTLMを使用しておらず、Kerberos認証を使用していることが示されている場合は、サーバーとクライアントのクロックが相互に5分以内に設定されていることとドメインコントローラーが設定されていることを確認します。

サーバーのイベントログを確認してください。サーバーがドメインコントローラーに接続できません。

Windows統合セキュリティのみを備えたサーバーに単純な.htmを配置し、ブラウザーからそれをヒットしようとしますが、それは成功しますか？

于 2009-07-29T13:43:05.123 に答える
0

AnthonyWJonesが提案したすべてのことを調べた後、次のようにすることで基本認証を使用できることがわかりました。

 objXmlHttp.Open "POST", AsmxUrl, False, UserName, Password

統合セキュリティを許可した場合、ネゴシエーションを試みますが、失敗して401になりますが、基本認証のみが許可されている場合は接続されます。これは私の最初の選択ではありませんが、匿名アクセスを許可するよりも優れた回避策です。誰かが統合セキュリティを機能させる方法を説明できる場合に備えて、これをもう少し開いたままにしておきますが、AnthonyWJonesのチェックリストが素晴らしく、この他のオプションを見つけるように導いたので、受け入れられた答えを与えます。

Fiddlerは、これらすべてを見つけるのに非常に役立ちました。

于 2009-07-30T20:30:20.247 に答える