none
WshControllerオブジェクトのCreateScriptメソッドで発生するエラーについて RRS feed

 > 

  • 質問

  • Question
    サインインして投票
    0
    サインインして投票


    Windows10のFall Creators Update適用PCと未適用PCで
    以下のスクリプトを実行した際の結果に違いがあります。

    Dim objController
    Set objController = WScript.CreateObject("WshController")
    Set objRemote = objController.CreateScript("リモート実行する.wsfのフルパス", "サーバー名")

    最後の Set objRemote = の部分で以下のエラーが起こります。

    Description:書き込みできません。
    Number:70
    Source:Microsoft VBScript 実行時エラー

    サーバー側のOSはWindows7です。Fall Creators Update適用前のWindows10PCであればエラーが起きずに動作する状況から、スクリプトのリモート実行に必要な設定が足りない訳では無さそうだと考えています。

    スクリプトを実行するPCとサーバーはWORKGROUPで管理されています。

    何か考えられる原因はありますでしょうか？

    なお、スクリプト実行側とサーバー側が同じドメインに参加している場合、サーバー側がWindows7、スクリプト実行側がFall Creators Update適用後のWindows10であっても、エラーは起きていないという状況です。

    • 編集済み FJKura 2018年6月14日 12:18
    2018年6月14日 7:53
    |

回答

  • Question
    サインインして投票
    0
    サインインして投票


    DCOMのResolveOxid2の詳細はわかりませんが、本件の原因がわかりました。
    Windows10 バージョン1709でのみ、ローカルセキュリティポリシーの以下の設定を実施した際に、レジストリに登録される値に不要な文字列が追記されます。

    "DCOM: セキュリティ記述子定義言語 (SDDL) 構文でのコンピューター アクセス制限"の"ANNONYMOUS_LOGON"のリモートアクセスをON
    レジストリHKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DCOMのMachineAccessRestrinctionの文字列値の末尾に"S:"が追記される

    バージョン1607や1803で同設定を実施した場合、上記の"S:"は付与されません。
    これを削除したところ、エラーを解消することができました。
    1709のバグなのかどうかはわかりません。

    ログオンしているユーザーとは別のユーザー権限で実行した場合、システムログでANONYMOUS_LOGONのイベントが記録されていました。
    このことからCOMセキュリティか本DCOMの設定が関係していそうであると薄々感じていたのですが、1709では効果が無かった設定なので重視していませんでした。
    今思い返してみれば、GUIの設定状況だけでなく、なぜレジストリまで確認しなかったのか？という事が悔やまれます。
    でも、とても良い勉強になりました。

    チャブーン様、本件の解決に多大なるご協力を頂き大変感謝しております。
    本当にどうもありがとうございました。

    • 回答としてマーク FJKura 2018年8月27日 4:29
    2018年8月27日 4:28
    |

すべての返信

  • Question
    サインインして投票
    2
    サインインして投票

    チャブーンです。

    この件ですが、見たところ、

    Description:書き込みできません。
    Number:70
    Source:Microsoft VBScript 実行時エラー
    <略>
    スクリプトを実行するPCとサーバーはWORKGROUPで管理されています。
    <略>
    なお、スクリプト実行側とサーバー側が同じドメインに参加している場合、サーバー側がWindows7、スクリプト実行側がFall Creators Update適用後のWindows10であっても、エラーは起きていないという状況です。

    ということなので、アカウントの認証かUAC周りの問題、という風に見受けられます。

    Workgroup環境で実施している際、接続に使っているアカウントは何になりますか？ビルトインAdministratorとAdministrator相当の後付けアカウント、それ以外の一般アカウント、だとリモート時のUAC昇格状況が違うと思うので、確認が必要かと思います。

    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。


    2018年6月17日 5:38
    |
  • Question
    サインインして投票
    0
    サインインして投票

    チャブーン様

    ご返信どうもありがとうございました。
    私の力量ではどこに目星をつけて良いかもわからない状況なので、アドバイスを頂けて本当に助かります。

    接続に使っているアカウントはAdministrator相当の後付アカウントです。

    コマンドプロンプトから runas /savecred /user:後付けアカウント を実行して
    別権限で起動したプロセスでスクリプトを実行しています。

    この後付アカウントは接続先のサーバーにも管理者権限を持つアカウントとして登録されています。

    UACに関しては「通知しない」という設定になっています。試しにデフォルト設定と思われる上から2番目の
    レベルに設定してみましたが、状況は変わりませんでした。

    その他にUACに関する設定が無いか調べてみたところ、ローカルセキュリティポリシーに
    存在することと、うまくいくPCといかないPCで設定に多少の違いがある事がわかりました。

    本日は都合が悪くて検証できないのですが、また明日試してみたいと思います。
    どうもありがとうございました。

    2018年6月18日 6:56
    |
  • Question
    サインインして投票
    0
    サインインして投票

    チャブーン様

    ローカルセキュリティポリシーより、ローカルポリシーのセキュリティオプションから
    ユーザー アカウント制御に関する各項目を確認してみました。

    現在の設定状況とポリシーは以下です。

    1. 無効：UIAccess アプリケーションで、セキュリティで保護されたデスクトップを使用せずに昇格のプロンプトを表示できるようにする

    2. 有効：アプリケーションのインストールを検出し、昇格をプロンプトする

    3. 有効：ビルトイン Administrator アカウントのための管理者承認モードを使用する

    4. 有効：安全な場所にインストールされている UIAccess アプリケーションの昇格のみ

    5. 有効：各ユーザーの場所へのファイルまたはレジストリの書き込みエラーを仮想化する

    6. 有効：管理者承認モードですべての管理者を実行する

    7. Windows以外のバイナリに...：管理者承認モードでの管理者に対する昇格時のプロンプトの動作

    8. 無効：署名され検証された実行ファイルのみを昇格する

    9. 有効：昇格のプロンプト時にセキュリティで保護されたデスクトップに切り替える

    10. 資格情報を有効にする：標準ユーザーに対する昇格時のプロンプトの動作

    今回発生しているエラーの内容、後付管理者で実行している状況に関係しそうなものは何か？と
    考えてみたいのですが、私の無知さ故という事もありますが、特に無いような気がしています。

    念の為、エラーが起きないPCの設定と揃えてみましたが状況は変わりませんでした。

    困りました。次の手を考えてみます。

    2018年6月19日 7:34
    |
  • Question
    サインインして投票
    2
    サインインして投票

    チャブーンです。

    UAC権限についてですが、ローカル設定だけでなく、リモートアクセス時についても権限が制限されて、これを緩和するにはGUI設定以外のレジストリの修正が必要です。(ちなみにローカル設定でUACを完全無効化する場合も別のレジストリを設定します。ここでは紹介しませんが、検索すればすぐにわかります。

    で、リモートベースのUACを緩和するレジストリですが、LocalAccountTokenFilterPolicyというレジストリ値を設定します。詳細はしたのページをみてみてください。

    https://support.microsoft.com/ja-jp/help/951016/description-of-user-account-control-and-remote-restrictions-in-windows

    追記:今設定されている「セキュリティオプション」のUAC関連の設定は今回の内容には無関係なので、デフォルトの状態に戻しておいてください(このままの状態だと、余計な制限事項が加わっている状態なのでうまく動かないと思います)

    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。



    2018年6月19日 11:36
    |
  • Question
    サインインして投票
    0
    サインインして投票

    チャブーン様

    リモートとローカルのUAC権限について、詳細を教えて下さりどうもありがとうございました。

    まず、ローカル設定のUAC完全無効化について、仰る通り検索したらすぐにわかりました。
    レジストリも編集する必要があったのですね。また1つ勉強させて頂きました。

    リモートのUACを緩和するレジストリについて、教えて頂いたページを確認して設定してみました。
    ですが、状況は改善されませんでした。

    セキュリティオプションのUAC関連の設定についてはご指摘頂いた通り、デフォルトの状態に戻しました。


    一点、訂正させて下さい。
    今回の質問で以下の様に記述させて頂きましたが、これは誤りでした。

    > なお、スクリプト実行側とサーバー側が同じドメインに参加している場合、サーバー側がWindows7、スクリプト実行側がFall Creators Update適用後のWindows10であっても、エラーは起きていないという状況です。

    スクリプト実行側とサーバー側が同じドメインに参加している場合であってもエラーが起きていました。
    なので、ワークグループかドメインかの違いはひとまず置いておこうと思います。

    また検証を進める中で以下の状況であることがわかりました。

    ・エラーが起きる（今回、質問させて頂いた状況です）
    スクリプト実行側 Windows10(Fall Creators Update適用済)
    サーバー側　　　 Windows7

    ・エラーが起きない
    スクリプト実行側 Windows7
    サーバー側　　　 Windows10(Fall Creators Update適用済)

    ・エラーが起きる
    スクリプト実行側 Windows10(Fall Creators Update適用済)
    サーバー側　　　 Windows10(Fall Creators Update適用済)

    このことから、スクリプトを実行する側がWindows10(Fall Creators Update適用済)かどうかがポイントなのだと思います。

    だとしたらCreateScriptが実行された時に、スクリプト実行側とサーバー側でどのような通信が行われているのか？それが正しく行われているのか？を確認すべきと思いました。

    エラーが起きるケースで、サーバー側のイベントビューアからWindowsログの「セキュリティ」のイベントを確認したところ、スクリプト実行側がCreateScriptしたのとほぼ同じタイミングでサーバー側にログオンしていることがわかりました。
    ログオンしているアカウントは後付け管理者権限のもので、サーバー側にも設定されているアカウントです。エラーが起きないケースでも同じアカウントでログオンできています。

    ログオンの際、以下の特権が割り当てられていました。

    SeSecurityPrivilege
    　SeBackupPrivilege
    　SeRestorePrivilege
    　SeTakeOwnershipPrivilege
    　SeDebugPrivilege
    　SeSystemEnvironmentPrivilege
    　SeLoadDriverPrivilege
    　SeImpersonatePrivilege

    これらの特権もやはり、エラーが起きないケースと同じものでした。
    なので何か特権が不足していてエラーが起きている状況でも無さそうです。

    このことから、もしかしたらアカウントの認証は問題無いのかもしれないと思いました。
    UACについても教えて頂いた通り、リモートとローカルの権限を緩和している状況ですし、もしかしたらそちらも問題無いのかもしれません。

    だとしたら何が問題か？と考えると、セキュリティソフトが関係していそうな気がします。
    Windows DefenderとMcAfeeを使用しているので、いずれかもしくは両方を無効にした時にどうなるかを次は確認してみようと思います。

    2018年6月20日 11:52
    |
  • Question
    サインインして投票
    0
    サインインして投票

    McAfeeをアンインストールし、以下の方法でWindows Defenderを無効化してみましたが、状況は変わりませんでした。

    ・Windows Defender　リアルタイム保護：オフ

    ・Windows Defender　クラウドベースの保護：オフ

    ・ローカルグループポリシー　Windows Defenderウイルス対策を無効にします：有効

    ・レジストリ編集
    HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender
    DisableAntiSpywareに1を設定

    ・Exploit Protectionの各項目をすべてOFFに設定


    スクリプト実行側のWindows10 OSバージョンによって、CreateScriptの結果に違いがあることがわかりました。
    但し、1803は他案件の検証用環境である為、他の2バージョンと比較して良いものかはわかりません。

    1607　実行可
    1709　実行不可
    1803　実行可

    1709に限定して起きている問題という見方もできますが、少々腑に落ちません。このタイミングで追加されたセキュリティ関係の機能と言えば、やはりWindows Defenderなので、この設定をさらに確認してみたいと思います。

    併せて、さらに掘り下げてみたい点があります。

    CreateScriptメソッドが実行された時に、サーバー側にどのような情報が渡されて、サーバー側で何が起きているのかです。
    それが段階的にわかるようなログをサーバー側で取ることができれば、もう少し絞り込めそうな気がしています。
    Windowsログの「セキュリティ」以外で良い方法が無いか調べてみます。

    本問題の検証ができる環境が手元に無い状態になってしまったので少々停滞しそうです。

    また進展があったら投稿させて頂きます。

    2018年6月22日 4:38
    |
  • Question
    サインインして投票
    0
    サインインして投票

    チャブーンです。

    私の言い方が悪かったのかもしれませんが、ローカルUACを完全無効化しても、リモートUACの無効化は必要という認識です。

    つまりLocalAccountTokenFilterPolicyの設定は、きちんと行ってください。そのうえで状況を確認したほうがよい、と思っています。

    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    2018年6月22日 6:19
    |
  • Question
    サインインして投票
    0
    サインインして投票


    チャブーン様

    とんでもありません。私の理解力が不足しているだけです。
    色々と教えて頂けて本当に感謝しています。どうもありがとうございます。

    問題がどこにあるのかをぼやけさせないという意味でも、リモートとローカルの両UACを無効化すべきということですね。
    LocalAccountTokenFilterPolicyの設定はきちんと行った上で調査を継続していきます。

    あれから色々と考えてみて、１つ面白い方法を見つけました。
    Microsoft Message AnalyzerやMicrosoft Network Monitorを使用すると、サーバーとクライアント間で
    何のプロトコルを用いて、どの様な通信をしているのかを把握する事ができそうなことがわかってきました。

    これを利用すれば、うまくいく環境とそうでない環境で、通信にどのような違いがあるのかを把握する事ができそうです。
    本件のエラー箇所については、以下イベントの前後らしきことがわかりました。（厳密には違うのかもしれませんが）

    DCOM.IRemoteSCMActivator.RemoteCreateInstance

    もしかしたら今週中に検証用環境が用意できるかもしれないので、どのようなエラーが起こるのかを確認したいと思います。

    2018年6月25日 7:01
    |
  • Question
    サインインして投票
    0
    サインインして投票

    検証環境が用意できたのでMessage Analyzerでエラーが発生している箇所を確認してみました。
    結果、DCOMのResolveOxid2というメソッドで発生したエラーで処理が止まっているらしきことがわかりました。
    以下はMessage Analyzerのログを一部抜粋したものです。

    （成功）Windows7

    Module:MSRPCE Summary:RpcconnBindHdrT, NTLM, IObjectExporter (DCOM), UUID: {99fcfec4-5260-101b-bbcb-00aa0021347a}, Call: 0x00000004, AssocGrp: 0x00000000, Xmit: 0x16D0, Recv: 0x16D0
    Module:MSRPCE Summary:RpcconnBindAckHdrT, NTLM, IObjectExporter (DCOM), UUID: {99fcfec4-5260-101b-bbcb-00aa0021347a}, Call: 0x00000004, AssocGrp: 0x0000AECF, Xmit: 0x16D0, Recv: 0x16D0
    Module:MSRPCE Summary:RpcconnRpcAuth3HdrT, NTLM v1 with extended session security, User: , IObjectExporter (DCOM), UUID: {99fcfec4-5260-101b-bbcb-00aa0021347a}, Call: 0x00000004
    Module:DCOM   ResolveOxid2, pOxid: 16675456983644864249, pipidRemUnknown: 00000000-0000-288c-742d-38684e2ca3ef, pAuthnHint: RpcCAuthnLevelConnect, pComVersion: 5.7, ReturnValue: 0


    （失敗）Windows10 ver.1709

    Module:MSRPCE Summary:RpcconnBindHdrT, NTLM, IObjectExporter (DCOM), UUID: {99fcfec4-5260-101b-bbcb-00aa0021347a}, Call: 0x00000003, AssocGrp: 0x00001E0E, Xmit: 0x16D0, Recv: 0x16D0
    Module:MSRPCE Summary:RpcconnBindAckHdrT, NTLM, IObjectExporter (DCOM), UUID: {99fcfec4-5260-101b-bbcb-00aa0021347a}, Call: 0x00000003, AssocGrp: 0x00001E0E, Xmit: 0x16D0, Recv: 0x16D0
    Module:MSRPCE Summary:RpcconnRpcAuth3HdrT, NTLM v1 with extended session security, User: , IObjectExporter (DCOM), UUID: {99fcfec4-5260-101b-bbcb-00aa0021347a}, Call: 0x00000003
    Module:DCOM   Summary:ResolveOxid2, pOxid: 13745006684895730314, pipidRemUnknown: 00000000-0000-0000-0000-000000000000, pAuthnHint: RpcCAuthnLevelDefault, pComVersion: 0.0, ReturnValue: 5

    ※ここで ReturnValue: 5 でエラー（成功時は ReturnValue: 0）

    （成功）Windows10 ver.1803

    Module:MSRPCE RpcconnBindHdrT, NTLM, IObjectExporter (DCOM), UUID: {99fcfec4-5260-101b-bbcb-00aa0021347a}, Call: 0x00000002, AssocGrp: 0x00000000, Xmit: 0x16D0, Recv: 0x16D0
    Module:MSRPCE RpcconnBindAckHdrT, NTLM, IObjectExporter (DCOM), UUID: {99fcfec4-5260-101b-bbcb-00aa0021347a}, Call: 0x00000002, AssocGrp: 0x000058F8, Xmit: 0x16D0, Recv: 0x16D0
    Module:MSRPCE RpcconnRpcAuth3HdrT, NTLM v1 with extended session security, User: , IObjectExporter (DCOM), UUID: {99fcfec4-5260-101b-bbcb-00aa0021347a}, Call: 0x00000002
    Module:DCOM   ResolveOxid2, pOxid: 9224609236114277989, pipidRemUnknown: fc000000-0000-08f8-f418-2600d4eb05a3, pAuthnHint: RpcCAuthnLevelConnect, pComVersion: 5.7, ReturnValue: 0


    単純にDCOMのResolveOxid2が失敗しているのであれば、それに関する設定やレジストリは何かを調べて、総当たりするのも手かと思います。
    ただこれに至るまでのプロセスで何か不都合がある可能性も高そうです。
    そもそもこのResolveOxid2が何なのかすらまだ把握できていない状況なので、まずはそれを理解することから始めてみます。

    少し進展があり嬉しかったので投稿させて頂きました。

    2018年6月29日 8:30
    |
  • Question
    サインインして投票
    0
    サインインして投票


    DCOMのResolveOxid2の詳細はわかりませんが、本件の原因がわかりました。
    Windows10 バージョン1709でのみ、ローカルセキュリティポリシーの以下の設定を実施した際に、レジストリに登録される値に不要な文字列が追記されます。

    "DCOM: セキュリティ記述子定義言語 (SDDL) 構文でのコンピューター アクセス制限"の"ANNONYMOUS_LOGON"のリモートアクセスをON
    レジストリHKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DCOMのMachineAccessRestrinctionの文字列値の末尾に"S:"が追記される

    バージョン1607や1803で同設定を実施した場合、上記の"S:"は付与されません。
    これを削除したところ、エラーを解消することができました。
    1709のバグなのかどうかはわかりません。

    ログオンしているユーザーとは別のユーザー権限で実行した場合、システムログでANONYMOUS_LOGONのイベントが記録されていました。
    このことからCOMセキュリティか本DCOMの設定が関係していそうであると薄々感じていたのですが、1709では効果が無かった設定なので重視していませんでした。
    今思い返してみれば、GUIの設定状況だけでなく、なぜレジストリまで確認しなかったのか？という事が悔やまれます。
    でも、とても良い勉強になりました。

    チャブーン様、本件の解決に多大なるご協力を頂き大変感謝しております。
    本当にどうもありがとうございました。

    • 回答としてマーク FJKura 2018年8月27日 4:29
    2018年8月27日 4:28
    |