ワークステーションをロックダウンし、ローカル管理者権限を必要とするレガシーアプリケーションを引き続きサポートするにはどうすればよいですか？
ユーザーのワークステーションをロックダウンしたまま使用できるようにすることのバランスを取るのに苦労していることはわかっています。ユーザーがツールバー、ゲーム、マルウェアなどを絶えずインストールしている1つのクライアントに深刻な問題があります。ローカルの管理者権限を奪うことができるようにしたいと思っています（管理もそうです）。問題は、適切に実行するためにローカル管理者権限を必要とする、不十分に記述された少数のアプリケーションに依存していることです。誰かがそれを提案する前に、これらのアプリケーションを取り除くことは不可能です。
Runasコマンドを使用し、ローカル管理者の資格情報を保存して、これらのアプリケーションへのカスタムショートカットを作成できることに気付きました。このソリューションの問題は次のとおりです。
- 各ユーザーのローカル管理者の資格情報を手動で指定する必要があります。
- 一部のプログラムは、ローカルユーザープロファイルのデータに依存しており、ComputerName\Administratorプロファイルで実行されていると「だまされて」いると、正しく機能しません。
私が気に入っているのは、アプリケーションをインストールするか、ローカルプロファイルのアクセス許可を昇格することを許可する必要があるアプリケーションを指定できるグループポリシーを適用することです。このような解決策はありますか？
他の誰もがワークステーションのロックダウンをどのように処理し、レガシー/不十分に書かれたソフトウェアをサポートしていますか？
ソフトウェアパッケージが実際に管理者権限を必要とすることはまれですが、管理者が通常アクセスでき、他のユーザーがアクセスできないレジストリまたはハードディスクの領域に書き込んでいます。それはちょっとした選択のように聞こえるかもしれませんが、この問題を解決するための基本です。
プロセスmonitoredit：Microsoftのthanks grawityツールを使用して、アプリケーションの動作を監視できます。 、およびそれらの領域への権限をユーザーに割り当てます。 http://technet.Microsoft.com/en-us/sysinternals/bb896653.aspx
次に、グループポリシーを使用して、ファイルとフォルダーの両方、およびレジストリの一部にセキュリティACLを適用できます。この問題の一般的な原因は、c：\ programファイル内のインストールフォルダ、またはHKey LocalMachineの下のマシンレジストリのグローバル設定へのプログラムの書き込みです。
このテーマに関する他のスレッドからいくつかの役立つヒントを得るかもしれません： XPの管理者権限を必要とするレガシーアプリ
これで、GPOを使用して必要なファイルシステムとレジストリのアクセス許可を設定できるようになります。
管理者権限のないユーザーをサポートするための2つの優れた方法を開発しました。
1。 「[user] -adm」アカウントでグループを作成し、アクセスが必要な可能性のあるパワーユーザー用に作成します。次に、アカウントが権利を必要としていると電話したときに、アカウントを数時間アクティブにします。右クリックして「RUN AS」を使用すると、昇格された権限でインストールできます。
2。起動時にバッチファイルをロードするスケジュールされたタスクを作成しました。ユーザーがデスクトップでショートカットを開くと、バッチファイルが実行され（open-txtパスワードを回避するために既にメモリ内で実行されています）、ユーザーがlocal-adminグループに追加されました。電子メールがヘルプデスクに自動的に送信され、タイマーが開始されて1時間だけアクティブになります。ヘルプデスクチケットは使用状況を追跡するため、不正使用はすべてログに記録されます。これはかなりうまく機能しましたが、上記の最初のオプションの方がサポートしやすくなっています。
プロセスモニター およびMicrosoft アプリケーション互換性ツールキット を取得しようとすると便利です 愚か者レガシーアプリケーションは機能します。 LUA Buglight もありますが、私は試していません。
ロックダウンに関しては、自分が何をしているかを知っていて、「偶然に」物事を破壊するつもりのないユーザーにローカル管理者権限を与えます。 （これは私の意見です）
ローカル管理者にアクセス権を与えないことに非常に同意しません。その慣習を採用した場合、私は膨大な時間を無駄にするでしょう。ただし、組織が大きくなるほど、ローカル管理者の信頼を評価することは困難です。ローカル管理者に署名済みのフォームを付与するための「焦土作戦」ポリシーの採用を検討してください。このポリシーは、「自分で壊した場合は、数分かけて調べてから、ワイプしてリロードする」というものです。
これらのアプリケーションが機能するために管理者が必要であると本当に考えているのなら、アプリケーションがどのように機能するかを本当に知っているとは思いません。製品ベンダーは、簡単に取り除けるのでこれを教えてくれますが、実際にはほとんどの場合真実ではありません。私はDOD環境で働いていますが、システムには常に回避策があるため、システムに管理者権限を与えることはありませんでした。私は通常、多くの人が言及している Process Monito rを使用することになりますが、 AaronMargosisの "Non-Admin" WebLog を読むことも検討する必要があります。これらの問題を克服し、常に最小特権のアカウントを使用します。また、Aaron Margosisでこのトピックに触れたので、 Microsoft Technet RadioのLeastUser Access（LUA）ポッドキャスト を聞くことをお勧めします。アーロンは LUA Buglight 2. という新しいツールを持っているようです。これは、アプリケーション要件を克服するプロセスに役立つはずですが、正直なところ、私はそれを使用したことがありません。
最小ユーザーアクセス（LUA）
VMwareのThinApp（以前のThinstall）も検討してください。
これでこの特定の問題を回避できるかどうかはわかりませんが、回避できる可能性があります。
標準ユーザーとして実行できないアプリケーションの大部分は、拒否されているアクセスがfileまたはregistryであるために失敗します。
WindowsではXP次のことができます[〜＃〜] acl [〜＃〜]プログラムがアクセスする必要のあるさまざまなフォルダとレジストリの場所。 標準ユーザーはそれらにアクセスできます。
つまり、全員フルコントロールを
c:\Program Files\World of Warcraft
HLKM\Software\Green Planet\Project Quantum
COMオブジェクトまたはファイル拡張子を登録しようとしている場合は、一度登録したことを確認してから、そのHiveブランチを完全に制御することができます。例えば。：
HKLM\Software\Classes\GreenPlanet.ProjectQuantum.1
HKLM\Software\Classes\CLSID\{9785B48F-520D-4179-8DEE-A4C7DDEBAB4F}
従業員がWindowsVistaを実行している場合、標準ユーザーとして正常に実行される可能性が高くなります。 Microsoftは、Windows XPで失敗したはずのアプリを標準ユーザーとして実行するために、後戻りしました。
そのファイルとレジストリの仮想化は非常に便利で、マシン全体の場所に書き込む必要があると考えるアプリケーションを回避します。
本当の答えは、アプリケーションを修正することです。マシン共通の場所に書き込む必要のあるアプリケーションは、地球上にはほとんどありません。これらのアプリケーションは、作成者が修正する必要があります。
共通の場所に書き込む正当な理由がある地球上の1つまたは2つのアプリを見つけることができ、ユーザーを管理者として実行させたくない場合は、ユーザーがそれらにアクセスできるように場所をACLします。
状況によっては、VirtualPCまたはVMWareが解決策になる場合があります。