私はかなり長い間、あることに苦労しています。上司は、プログラムのインストール ファイルを置くディレクトリをファイル サーバー内に作成したいと考えています。そのディレクトリは誰でも読み取り可能で、上司だけが変更できるようになっています。
彼は、クライアント ワークステーションに、ディレクトリを読み取り、そこに存在するファイルをユーザーに示すスクリプトを組み込むことを望んでいます。そうすれば、通常のドメイン ユーザー (何もインストールできない) は、[インストール] をクリックするだけでインストールできるようになります。
その背後にある考え方は、ユーザーのステーションにローカル管理者を配置し、スクリプトにローカル管理者のパスワードを認識させ、それらのローカル管理者の資格情報を使用してプログラムをユーザーのコンピューターにインストールすることです。
これは非常に問題のある問題です。なぜなら、スクリプト内にローカル管理者のパスワードを保存せずにセキュリティを確保する方法がわからないからです。これは非常に悪いことです。
パスワードを何らかの方法で暗号化し、スクリプトを実行可能ファイルに変換することを考えましたが、コンピューターについて少し知っているユーザーが実行可能ファイルを逆コンパイルできないようにする方法がわかりません。PowerShell 暗号化を使用する場合は、1 台のマシンと 1 人のユーザーのみに適しています。
そこで、別の方法を考えました。クライアント ワークステーションからファイラーに呼び出しを行い、ファイラーが psexec を使用してユーザーに応答するようにする方法ですが、これはあまりにも複雑になりすぎています。
次に、invoke-command を使用して、ユーザーのコンピューターからファイラーに呼び出しを行い、ファイラーからユーザーに呼び出しを戻すことを考えましたが、すべてのクライアントに WinRM を許可する必要があります。
私はこれに PowerShell を使用しています。おそらく、ここで同様のことをした人がいて、それを安全に行う方法についてアドバイスできるでしょう。
最初のオプションはうまく機能したので、可能であればそれを使い続けたいのですが、ユーザーのコンピューターにある PowerShell スクリプトに資格情報を入力するだけでなく、これをどのように保護するかを考えなければなりません。
答え1
2つのアプローチがあると思います。
- 別の上司を探してください。上司は自分が要求する仕事が実際どれほど複雑であるかまったくわかっていないのは明らかです。常に細かい点ばかりが問題で、上司が細かい点を調べたことはないと思います。Windows のインストールを細部まで習得するのは非常に難しいです。
まだ読んでいますか？ いいですよ。できますよ。
- 重要な点は、スクリプトをバックグラウンドで「スケジュールされたタスク」として実行することです。マシンごとに新しい「スケジュールされたタスク」を設定すると、このタスクで使用するユーザー名とパスワードの入力を求められます。ここで、インストール アカウントの資格情報を渡します。パスワードは後で取得できないため、安全であると考えられます。この「スケジュールされたタスク」には完全な管理者権限が与えられ、ドメイン ユーザー アカウントを使用する場合 (クライアントでは管理者権限を与え、サーバーではユーザー権限のみを与える)、スクリプトはネットワーク経由でインストール ファイルに簡単にアクセスし、インストールを開始できます。
ただし、多くのインストール プログラムはかなり愚かで、プログラムをインストールするユーザー (つまり、インストーラー ユーザー) が使用するためにプログラムをインストールし、フォアグラウンドでログインしているユーザー用にはインストールしないことに注意してください。一部のインストーラーは、「すべてのユーザー」にインストールするようにパラメーター化できます。おそらくこれで十分ですが、その他のインストーラーでは、スクリプトをよりスマートにして、ソフトウェアのインストーラーが完了した後に、フォアグラウンド ユーザーのプロファイルに「必要なすべての設定、ライセンス (!)、アイコン、プログラムが機能するために必要なもの」を追加できるようにする必要があります。
ユーザー アカウントにタスクを実行させる正当な方法はまったくありません。管理者パスワードを知らずに、または管理者から管理者権限を付与されずに、ユーザーが権限を管理者に昇格できる方法があれば、どのユーザーでもいつでも何でも実行でき、これはすべてのユーザー アカウントを常に管理者として実行しているのとほぼ同じです。
ここで、ユーザーがサーバー上のソフトウェアを選択できるようにするための追加のスクリプト、Web GUI など、何でもかまいません。おそらく、ユーザーにソフトウェアをインストールする権限があるかどうか、また、ユーザーのコンピューターがインストールを成功させるための要件 (ハードウェア? 空きディスク容量? ...) を満たしているかどうかを確認します。次に、その情報をバックグラウンド インストーラーが読み取れる場所に保存する必要があります。サーバー上の単純なリストで十分です。
最後に、バックグラウンド スクリプトが定期的にそのリストにアクセスし、インストーラーをトリガーします。
終わり。
あなたが考えているのは、自動化されたソフトウェア配布機能をプログラミングすることだと言わせてください。それを実現する商用ツールはいくつかあり、そのうちの 1 つは Windows Active Directory に組み込まれており、無料で提供されています。開発者がそれぞれのツールにどれだけの年月と費用を費やして、インストーラーがさまざまな Windows ソフトウェアで使用される多数のインストーラー バリアントの多く (ほとんど? すべて? 一部?) を習得できるようになったかはわかりません。最初はクライアントごとに高額に見えるかもしれませんが、コスト、信頼性、機能、ドキュメント、コミュニティ サポートの面で、Powershell で作成できるもので商用ソリューションに勝るものはないと思います。
答え2
これは、グループ ポリシー ソフトウェアの展開の仕事のように思えます。これにより、ユーザーに管理者権限がないという問題を回避できます。
による出版パッケージをインストールすると、コントロール パネルでユーザーがソフトウェアを利用できるようになります (単に自動的にインストールされるのではなく)。
エンドユーザーの視点から:
設定
- Microsoftのガイドを見るここ(古い記事ですが、まだ関連しています)。"パッケージを公開する「パッケージを割り当てる」ではなく「パッケージを割り当てる」セクションを参照してください。
- GPOと「ソフトウェアリポジトリ」共有に適切な権限を委任します。このために、次のようなセキュリティグループを作成することもできます。オプションのソフトウェア管理者たとえば、上司をメンバーとして追加します。
ACEが適用されることを確認するこのオブジェクトとすべての子孫オブジェクト:
付与修正するオプション ソフトウェア管理者のソフトウェア フォルダーに対する NTFS アクセス許可:
- 次の PowerShell コマンドを管理者特権で実行して、上司のマシンにグループ ポリシー管理コンソールをインストールします。
Add-WindowsCapability -Name "Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0" -オンライン
ここからは、上司はインストーラーをソフトウェア共有にコピーし、それに応じてソフトウェア展開 GPO を変更する準備が整います (ただし、最初は指示を受ける必要があります)。これはすべて、ローカル マシンまたはドメイン管理者の権限なしで実行でき、関係者全員にとって (かなり) 簡単な操作です。
必要な場所に直接ショートカットをプッシュすることで、エンド ユーザーと上司の作業をさらに簡単にすることもできます。グループ ポリシー管理コンソールのインストールは、管理ユーザーを増やす必要がある場合や、上司が複数のマシンを行き来する場合に、自動化することもできます。