管理者ブローカー モデルでは、アプリケーションは 2 つのプログラムに分かれています。 プログラムの 1 つは標準ユーザーとして実行され、もう 1 つは管理者特権で実行されます。
アプリケーション マニフェストを使用して、標準ユーザー プログラムを asInvoker の 要求されたExecutionLevel マークし、管理プログラムに requireAdministrator の requestedExecutionLevelマークします。 ユーザーが最初に標準ユーザー プログラムを起動します。 ユーザーが完全な管理者アクセス トークンを必要とする操作を実行しようとすると、標準ユーザー プログラムは、ShellExecute 関数を呼び出して管理プログラムを起動します。 ShellExecute 関数は、ユーザーの完全な管理者アクセス トークンを使用してアプリケーションを実行する前に、ユーザーに承認を求めます。 管理者プログラムは、管理者特権を必要とするタスクを実行できます。
管理プログラムが標準ユーザー・プログラムから完全に分離されているわけではありません。 管理プログラムは、標準ユーザー・プログラムとのプロセス間通信を可能にすることができます。 ただし、このような通信は、既定の必須整合性ポリシーによって制限されます。 必須の整合性に関する考慮事項については、「低整合性レベルので実行するアプリケーションの設計」を参照してください。
管理者ブローカー モデルでは、次の用途が考えられます。
- ウィザードの開発。 ハードウェア ウィザードは、必要なドライバーがコンピューターにインストールされていないか、企業の承認された場所に配置されていないと判断すると、コンピューター ストアにドライバーを移動する機能を持つ昇格されたアプリケーションを呼び出します。
- Setup.exeの呼び出しを Autorun.exe します。 ユーザーが CD からソフトウェアを実行すると、標準ユーザーとして実行される Autorun.exeは、管理者として実行される Setup.exeを起動して、ソフトウェアをコンピューターにインストールします。
管理者ブローカー モデルを使用する場合の欠点を次に示します。
- アプリケーションからアプリケーションへの移行は、ユーザーに混乱を招く可能性があります。 新しいアプリケーションがモニターに表示される理由をユーザーに知らせるのは困難な場合があります。
- 2 つのアプリケーション間で状態情報を渡すことが困難な場合があります。 たとえば、このモデルを使用して、標準ユーザー コントロール パネル (CPL) とその管理者の対応する間で状態情報を渡し、同じ CPL に管理および標準のユーザー機能を付与するだけの操作は行いません。 標準ユーザー CPL は、その状態をどこかに格納する必要があります。
- 2 つのプログラム間で機能を分割すると、レプリケートされたコードが多数存在する可能性があります。
関連トピック
-
昇格されたタスク モデルの を する