- PR -

ActiveXコントロールをログインユーザーとは別のユーザーでブラウザにインストールする方法

投稿者投稿内容
nanbu
大ベテラン
会議室デビュー日: 2004/08/19
投稿数: 178
投稿日時: 2006-05-14 02:40
引用:

ちゃっぴさんの書き込み (2006-05-13 19:18) より:
wbemImpersonationLevelDelegate が本当に必要なのか?疑問に思っていましたが・・・

実験してみたところ、やっぱり必要ないですね。
wbemImpersonationLevelImpersonate で十分でしょう。

ただし、その場合事前に msi を install する computer 上に copy しておくことが必要になりますが。Network 越しは例の制限に引っかかるので無理です。
# そっか、Windows Installer を利用する場合、この方法が使えますね。

ちなみに毎回 install を避けるため、Win32_Product に対象の version が存在するか調べたほうがいいですね。



実験ありがとうございました。
私の方でも同じ認識です>コピー&インストール

あくまで条件が整えばの話なので、
対象のマシンのインストール後の確認を行える簡単な初期導入時
くらいかなぁ、、と。
ちゃっぴ
ぬし
会議室デビュー日: 2004/12/10
投稿数: 873
投稿日時: 2006-05-14 13:30
引用:

toiryさんの書き込み (2006-05-12 13:39) より:

その際に、クライアントのブラウザに帳票表示用のビュアー(ActiveXコントロール)をインストールする必要があります。

しかし、今回導入するクライアント様ではPCにログインしたユーザーにはActiveXコントロールをインストール権限が付与されていません。



引用:

ただ、今回のWebアプリケーションは閉じられたネットワーク内で使用され(イントラ)る為、特定の方のみが使用されます。
また、使用するクライアント数がそれなりにある為、ブラウザからインストール出来ればと思っております。



引用:

Jittaさんの書き込み (2006-05-13 17:05) より:
 ここの、仕様が矛盾していることに対して、顧客はなんと言っているのでしょう?
 ActiveX Object を勝手にインストールさせないが、イントラネット仕様だからインストールしても良いって、なんか変。



これに関しては、どういう規約なのかはっきりさせる必要がありますね。

1. ActiveX control を全く install させない
2. LAN 内のみ ActiveX control の install は許可する

1. ならば、ActiveX control を install させるような設計にしたのがそもそも間違いでしょうし、2. であるならば client の構成が間違っていますね。

これをまず確認されたほうがいいんじゃないでしょうかね?

ちなみに 2 の方法で client を構成することは一応可能です。
具体的には、基本的に ActiveX control を install できるように ACL 等を構成しておいて、IE の zone 制御および group policy を使って LAN 内以外を制限することになります。

もし、1 であるならば、ActiveX control に代わる application の配布方法を顧客に聞いていたほうがいいでしょうね。もし、顧客がそこら辺を理解されていないのであれば、この際ちゃんとどのような方法があるかまで説明しておいたほうがいいでしょうね。

引用:

 こういう矛盾するところは、きっちりと「なぜこうなった」というところを文書として残しておかないと、後々の火種になります。
# 何月何日、どう決まった。。。ではなく、何月何日、誰が、どういって、どういうやりとりがあった結果、こう決まった、、、と残す。



もちろんこれは絶対にやるべきですね。
toto
常連さん
会議室デビュー日: 2005/10/18
投稿数: 46
お住まい・勤務地: 岡山
投稿日時: 2006-05-15 11:01
ちゃっぴ様 ue様 渋木宏明(ひどり)様
nanbu様 Jitta様

この様な矛盾した仕様にも関わらず、貴重なご意見をいただき本当にありがとうございます。
現状はまだ、システムの内容を提案している段階である為、仕様変更も視野に入れて提案したいと考えております。

何分、私がまだまだ経験も知識も不足しているため、スレの返信内容が十分に理解できていないところもありますが、しっかりと調べて知識を増やしたいと思います。

ありがとうございました。
こばさん
大ベテラン
会議室デビュー日: 2004/03/17
投稿数: 147
投稿日時: 2006-05-15 11:34
 全く同じことを実際にやったことあります。
 ActiveX インストール用の管理者ユーザーを新設し、グループポリシーで Activex を勝手にインストールする設定にし、そのユーザー/パスを埋め込んだ runas.exe(フリーソフト版) を作り、ログオンスクリプトに runas 経由で IE を立ち上げて・・・という感じで。

 厄介だったのが、その ActiveX に署名をつけれなかったので、どうあがいても警告ダイヤログが出てしまう(別ユーザーで実行しているため表示はされないが)。


 で、自前の証明書サーバーを立ち上げて、ルート証明としてクライアントに登録させ(グループポリシーで)、その証明書サーバーを使って ActiveX に署名して、ようやく最終目的までたどり着きました。

 IE7 の世代になると、こういう偽装でも駄目になるかもしれないですね。


 これにより一応目的の、管理者権限を有さないユーザーに全く知られることなく、また事前に告知することなく自動的に自前 ActiveX をインストールする、ということは実現できました。
 1000台近い端末への自動展開でした。

[ メッセージ編集済み 編集者: こばさん 編集日時 2006-05-15 11:38 ]
渋木宏明(ひどり)
ぬし
会議室デビュー日: 2004/01/14
投稿数: 1155
お住まい・勤務地: 東京
投稿日時: 2006-05-15 12:47
引用:

そのユーザー/パスを埋め込んだ runas.exe(フリーソフト版) を作り、



は、パスワード流出につながる恐れがありますね。
こばさん
大ベテラン
会議室デビュー日: 2004/03/17
投稿数: 147
投稿日時: 2006-05-15 13:45
引用:

渋木宏明(ひどり)さんの書き込み (2006-05-15 12:47) より:
引用:

そのユーザー/パスを埋め込んだ runas.exe(フリーソフト版) を作り、



は、パスワード流出につながる恐れがありますね。




・ユーザーに展開の事前告知をしない
・ログオン時にrunasa.exeが動作しても気がつかない
・runasa.exeに埋め込むユーザーは展開期間中の一時的なもの
・同ユーザーの行動は監視ログで記録(端末≒使用者を特定)

 可能性でいえばゼロじゃないですがね。
 そこまで疑わないといけないような人を組織内に存在させておくことの方が問題です(笑)
渋木宏明(ひどり)
ぬし
会議室デビュー日: 2004/01/14
投稿数: 1155
お住まい・勤務地: 東京
投稿日時: 2006-05-15 15:03
引用:

 可能性でいえばゼロじゃないですがね。



そこが重要なところです。

可能性がゼロで無い以上、いくつもの拠点に対して、長期的に配布を行うなど、機会が累積すればアカウント情報流出の危険も増大してしまいます。

「埋め込み」をしないで要件を実現する技術が存在する以上、「埋め込み」を行う方向への誘導は出来れば避けたいところです。

引用:

 そこまで疑わないといけないような人を組織内に存在させておくことの方が問題です(笑)



論じるべきは「必要とされるセキュリティレベルがどれだけか」でしょう。

各拠点に、一時的に端末の管理者権限のあるアカウントを発行してアプリケーションの配布を実行し、配布が終わったらアカウントを停止するような、運用的な解決もあり得るわけですし。


[ メッセージ編集済み 編集者: 渋木宏明(ひどり) 編集日時 2006-05-15 16:02 ]
minminnana
大ベテラン
会議室デビュー日: 2004/02/05
投稿数: 246
お住まい・勤務地: 盛岡
投稿日時: 2006-05-15 15:21
グループポリシーを使うのが前提(ActiveDirectoryが前提)であれば、ソフトウエアの割り当てをすれば良いのではないでしょうか。

スキルアップ/キャリアアップ(JOB@IT)