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