ユーザー アカウント制御の互換性に関する Windows Vista アプリケーション開発要件

 

Jennifer Allen

更新日: 2007 年 6 月

概要： このホワイト ペーパーは、ユーザー アカウント制御に準拠した Windows Vista 対応アプリケーションを設計するアプリケーション開発者を支援することを目的としています。 設計プロセスに関する詳細な手順と、コード サンプル、要件、ベスト プラクティスが含まれています。 このペーパーでは、Windows Vista のユーザー エクスペリエンスに対する技術的な更新と変更についても詳しく説明します。 (71 ページ印刷)

内容

ユーザー アカウント制御の理由
Windows Vista 更新
Windows Vista の新しいテクノロジ
UAC のアーキテクチャ
UAC はアプリケーションに影響しますか?
Windows Vista 用アプリケーションの設計
標準ユーザー向けのアプリケーションのデプロイと修正プログラムの適用
一般的な問題のトラブルシューティング
リファレンス

ユーザー アカウント制御の理由

アプリケーション開発者は、過剰なユーザー権限と Windows 特権を必要とする Windows アプリケーションを一貫して作成してきました。多くの場合、実行中のユーザーを管理者にする必要があります。 その結果、必要最小限のユーザー権限と Windows 特権で実行される Windows ユーザーは少なくなります。 多くの企業は、展開の容易さと使いやすさとセキュリティのバランスを取るために、多くの場合、標準のユーザー アプリケーションの互換性の問題により、デスクトップを管理者として展開することに頼っています。

次の一覧では、Microsoft Windows Vista より前のコンピューターで標準ユーザーとして実行するのが困難なその他の理由について詳しく説明します。

1. 多くの Windows アプリケーションでは、ログオンしているユーザーが管理者である必要がありますが、実際には管理者レベルのアクセスは必要ありません。 これらのアプリケーションは、実行を許可される前に、次のようなさまざまな管理者アクセス チェックを実行します。
   • 管理者アクセス トークンのチェック。
   • システムで保護された場所での "すべてのアクセス" アクセス要求。
   • %ProgramFiles%、%WinDir%、HKLM\Software など、保護された場所にデータを書き込みます。
2. 多くの Windows アプリケーションは、最小特権の概念を使用して設計されておらず、ユーザーと管理者の機能を 2 つの個別のプロセスに分離しません。
3. Windows 2000 および Windows XP では、既定で管理者として新しいユーザー アカウントが作成されます。そのため、日付と時刻、Power Management コントロール パネルなどの主要な Windows コンポーネントは、標準ユーザーには適していません
4. Windows 2000 管理者と Windows XP 管理者は、管理タスク用と日常的なタスクを実行するための標準ユーザー アカウントの 2 つの個別のユーザー アカウントを作成する必要があります。 そのため、ユーザーは標準ユーザー アカウントからログオフし、管理者としてログインし直すか、実行を使用して管理タスクを実行する必要があります。

Microsoft は、ユーザー アカウント制御 (UAC) を使用して、標準のユーザー デスクトップを企業内および自宅に簡単に展開するためのテクノロジを提供しています。

Microsoft Windows NT 3.1 オペレーティング システムで最初に設計された Windows セキュリティ アーキテクチャから構築された UAC チームは、柔軟性と安全性の両方を備えた標準ユーザー モデルを実装しようとしました。 以前のバージョンの Windows では、ログオン プロセス中に管理者用に 1 つのアクセス トークンが作成されます。 管理者のアクセス トークンには、ほとんどの Windows 特権とほとんどの管理セキュリティ識別子 (SID) が含まれています。 このアクセス トークンにより、管理者はアプリケーションのインストール、オペレーティング システムの構成、リソースへのアクセスを確実に行うことができます。

UAC チームは、Windows Vista のアクセス トークン作成プロセスに対して大幅に異なるアプローチを取りました。 管理者ユーザーが Windows Vista コンピューターにログオンすると、フィルター処理された標準ユーザー アクセス トークンと完全な管理者アクセス トークンの 2 つのアクセス トークンが作成されます。 管理者のアクセス トークンを使用してデスクトップ (Explorer.exe) を起動する代わりに、標準のユーザー アクセス トークンが使用されます。 すべての子プロセスは、このデスクトップの最初の起動 (explorer.exe プロセス) を継承します。これは、Windows Vistas の攻撃対象領域を制限するのに役立ちます。 既定では、管理者を含むすべてのユーザーが標準ユーザーとして Windows Vista コンピューターにログオンします。

メモ 上記のステートメントには 1 つの例外があります。ゲストは、標準ユーザーよりも少ないユーザー権限と特権でコンピューターにログオンします。

管理者がアプリケーションのインストールなどの管理タスクを実行しようとすると、UAC はユーザーにアクションの承認を求めます。 ユーザーがアクションを承認すると、管理者の完全な管理者アクセス トークンを使用してタスクが起動されます。 これは既定の管理者プロンプト動作であり、ローカルのセキュリティ ポリシー マネージャー スナップイン (secpol.msc) と グループ ポリシー (gpedit.msc) で構成できます。

メモUAC が有効になっている Windows Vista コンピューターの管理者アカウントは、管理承認モードの管理者アカウントとも呼ばれます。 管理承認モードでは、管理者の既定のユーザー エクスペリエンスが識別されます。

各管理昇格もプロセス固有であるため、他のプロセスがユーザーに承認を求めることなくアクセス トークンを使用できなくなります。 その結果、管理者ユーザーは、インストールするアプリケーションをより詳細に制御しながら、ログオンしているユーザーが完全な管理者アクセス トークンで実行されることを期待する悪意のあるソフトウェアに大きな影響を与えます。

標準ユーザーは、UAC インフラストラクチャを使用してフローを昇格させ、管理タスクを実行する機会もあります。 標準ユーザーが管理タスクを実行しようとすると、UAC はユーザーに管理者アカウントの有効な資格情報を入力するように求めます。 これは既定の標準的なユーザー プロンプト動作であり、ローカルのセキュリティ ポリシー マネージャー スナップイン (secpol.msc) と グループ ポリシー (gpedit.msc) で構成できます。

Windows Vista 更新

次の更新プログラムは、Windows Vista で発生した機能の累積的なコア変更を反映しています。

UAC は既定で有効になっています

その結果、Windows Vista UAC コンポーネント用にまだ更新されていないさまざまなアプリケーションで互換性の問題が発生する可能性があります。 アプリケーションに管理者アクセス トークンが必要な場合 (これは、アプリケーションの実行時に "アクセス拒否" エラーが返されたことを示します)、コンテキスト メニューの [管理者として実行] オプション (右クリック) を使用して、管理者としてプログラムを実行できます。 これを行う方法については、このドキュメントの「管理者としてプログラムを実行する」セクションで後述します。

後続のすべてのユーザー アカウントが標準ユーザーとして作成されます

標準ユーザー アカウントと管理者ユーザー アカウントの両方で、UAC の強化されたセキュリティを利用できます。 新しいインストールでは、既定では、最初に作成されたユーザー アカウントは、管理承認モード (UAC が有効) のローカル管理者アカウントです。 その後、後続のすべてのアカウントが標準ユーザーとして作成されます。

セキュリティで保護されたデスクトップに既定で昇格プロンプトが表示される

同意と資格情報のプロンプトは、Windows Vista の既定でセキュリティで保護されたデスクトップに表示されます。

バックグラウンド アプリケーションの昇格プロンプトがタスク バーに最小化される

バックグラウンド アプリケーションは、セキュリティで保護されたデスクトップに自動的に昇格するのではなく、タスク バーに昇格するようにユーザーに自動的に求めます。 昇格プロンプトがタスク バーに最小化されて表示され、アプリケーションが昇格を要求したことをユーザーに通知するために点滅します。 背景の昇格の例は、ユーザーが Web サイトを参照し、インストール ファイルのダウンロードを開始するときに発生します。 その後、インストールがバックグラウンドでダウンロードされている間、ユーザーは電子メールをチェックに移動します。 ダウンロードがバックグラウンドで完了し、インストールが開始されると、昇格はフォアグラウンド タスクではなくバックグラウンド タスクとして検出されます。 この検出により、ユーザーが別のタスク (電子メールの読み取り) を実行している間に、インストールによってユーザーの画面のフォーカスが突然盗まれるのを防ぐことができます。 この動作により、昇格プロンプトのユーザー エクスペリエンスが向上します。 アプリケーション開発者が昇格を要求したときにアプリケーションがタスク バーに最小化されないようにする方法については、このドキュメントの後半で説明します。

ユーザーのログオン パスで昇格がブロックされる

ユーザーがログオンしたときに起動し、昇格が必要なアプリケーションが、ログオン パスでブロックされるようになりました。 アプリケーションがユーザーのログオン パスで昇格を求めるメッセージをブロックしない場合、標準ユーザーと管理者の両方が、ログオンするたびに [ユーザー アカウント制御] ダイアログ ボックスに応答する必要があります。 Windows Vista は、システム トレイにアイコンを配置することで、アプリケーションがブロックされた場合にユーザーに通知します。 ユーザーは、このアイコンを右クリックして、ユーザーのログオン時に昇格を求めるメッセージがブロックされたアプリケーションを実行できます。 ユーザーは、トレイ アイコンをダブルクリックして、この一覧から無効または削除されるスタートアップ アプリケーションを管理できます。

組み込みの管理者アカウントは、新しいインストール時に既定で無効になっています

Windows Vista では、組み込みの管理者アカウントは既定で無効になっています。 Windows VISTA が Windows XP からのアップグレード中に、組み込みの管理者が唯一のアクティブなローカル管理者アカウントであると判断した場合、Windows Vista はアカウントを有効のままにして、管理承認モードにします。 既定では、組み込みの管理者アカウントは、セーフ モードでコンピューターにログオンできません。 詳細については、次のセクションを参照してください。 組み込みの管理者アカウントは、セットアップ中にユーザー名 Administrator を使用して作成されます。

ドメインに参加していない

有効なローカル管理者アカウントが少なくとも 1 つある場合、セーフ モードでは、無効な組み込み管理者アカウントを使用したログオンは許可されません。 代わりに、ローカル管理者アカウントを使用してログオンできます。 最後のローカル管理者アカウントが誤って降格、無効化、または削除された場合、セーフ モードでは、無効になっている組み込みの管理者アカウントがディザスター リカバリーのためにログオンできるようになります。

ドメイン参加済み

すべてのケースで無効になっている組み込み管理者アカウントは、セーフ モードでログオンできません。 Domain Admins グループのメンバーであるユーザー アカウントは、コンピューターにログオンして、ローカル管理者が存在しない場合は作成できます。

メモ ドメイン管理者アカウントが以前にログオンしたことがない場合は、資格情報がキャッシュされていないため、コンピューターをネットワークを使用してセーフ モードで起動する必要があります。

メモ マシンが不整合になると、前に示したドメインに参加していない動作に戻ります。

ユーザー アカウント制御とリモート シナリオ

管理者がリモートで Windows Vista コンピューターにログオンすると、たとえばリモート デスクトップを使用して、ユーザーは既定で標準ユーザーとしてコンピューターにログオンします。 リモート管理は、ネットワーク上で制限されるように変更されました。 これにより、ユーザーが管理上の可能性を持って実行している場合に、悪意のあるソフトウェアがアプリケーション "ループバック" を実行するのを防ぐことができます。

ローカル ユーザー アカウント

Windows Vista コンピューターのローカル セキュリティ アカウント マネージャー (SAM) データベースの管理者アカウントを持つユーザーが Windows Vista コンピューターにリモート接続する場合、ユーザーはリモート コンピューターで昇格の可能性がなく、管理タスクを実行できません。 ユーザーが SAM アカウントを使用してワークステーションを管理する場合、ユーザーは対話形式でコンピューターにログオンして管理する必要があります。

ドメイン ユーザー アカウント

ドメイン ユーザー アカウントを持つユーザーが、ユーザーが Administrators グループのメンバーである Windows Vista コンピューターにリモートでログオンすると、ドメイン ユーザーはリモート コンピューターで完全な管理者アクセス トークンを使用して実行され、UAC は有効になりません。

新しい既定のAccess Controlリスト (ACL) 設定

特定の Windows ディレクトリの ACL が変更され、データ ディレクトリおよびユーザーの保護されたディレクトリの外部でのデータ共有とコラボレーションが可能になります。 ユーザーの保護されたディレクトリはユーザー プロファイル (例: C:\Users\Denise\Pictures\) ですが、データ ディレクトリの例は、データ ドライブ上のオペレーティング システム パーティション外の場所 (例: D:\Pictures\) です。 このインスタンスのルート ディレクトリ C は、より制限の厳しい ACL によって保護されているため、ユーザーは Windows Vista の初期バージョンでデータ ディレクトリを使用できませんでした。

これらの ACL の変更により、ユーザーは [ユーザー アカウント制御] ダイアログ ボックスに承認を提供しなくても、ファイルを共有および編集できます。 さらに、ユーザーはフォルダーをプライベートにできるようになりました。 この変更により、ユーザーはデータ ドライブのデータの機密性と整合性を簡単に維持できます。 これらのプライベート フォルダーは、他の管理者が昇格した場合でも読み取り可能であり、標準ユーザーからデータを非公開にするために使用する必要があります。

%systemroot% の既定の ACL 設定と Windows XP のデータ ドライブを次に示します。

Windows XP %systemroot% とデータ ドライブ ACL の設定

ユーザーまたはグループ	アクセス制御エントリ
BUILTIN\Administrators (BUILTIN\Administrators)	フル コントロール
NT AUTHORITY\SYSTEM	フル コントロール
CREATOR OWNER	フル コントロール
BUILTIN\Users	Read 特別なアクセス: FILE_APPEND_DATA 特別なアクセス: FILE_WRITE_DATA
Everyone	Read

次の表では、format.exeで作成されたデータ ドライブの新しい Windows Vista データ ドライブ ACL 設定について詳しく説明します。

Windows Vista データ ドライブ ACL の設定

ユーザーまたはグループ	アクセス制御エントリ
BUILTIN\Administrators (BUILTIN\Administrators)	フル コントロール
NT AUTHORITY\SYSTEM	フル コントロール
NT AUTHORITY\Authenticated Users	変更
BUILTIN\Users	読み取りと実行 ジェネリック読み取り、ジェネリック実行

次の表では、新しい Windows Vista オペレーティング システム ルート (%systemroot%) ACL 設定について詳しく説明します。

Windows Vista %systemroot% ACL 設定

ユーザーまたはグループ	アクセス制御エントリ
BUILTIN\Administrators (BUILTIN\Administrators)	フル コントロール
NT AUTHORITY\SYSTEM	フル コントロール
BUILTIN\Users	読み取りと実行
NT AUTHORITY\Authenticated Users	変更 データを追加する
必須ラベル\高い必須レベル	書き込みなし

新しい UAC セキュリティ設定とセキュリティ設定の名前の変更

新しいセキュリティ設定とセキュリティ設定の名前の更新については、このドキュメントの「参照」セクションを参照してください。

Windows Vista の新しいテクノロジ

以降のセクションでは、インストーラーの検出、Windows インストーラー 4.0 での標準ユーザーの修正プログラムの適用、ユーザー インターフェイス特権の分離、仮想化など、Windows Vista の新しいテクノロジについて詳しく説明します。

ActiveX Installer Service

ActiveX インストーラー サービスを使用すると、企業は標準ユーザーに ActiveX コントロールのインストールを委任できます。 このサービスにより、ActiveX コントロールのインストールと更新の失敗によって、日常的なビジネス タスクが妨げられないことが保証されます。 Windows Vista には、標準ユーザーが ActiveX コントロールをインストールできるホスト URL を IT プロフェッショナルが定義できるようにするグループ ポリシー設定も含まれています。 ActiveX インストーラー サービスは、Windows サービス、グループ ポリシー管理用テンプレート、およびインターネット エクスプローラーの一部の変更で構成され、インストールされているクライアントでのみ有効になるオプション コンポーネントです。

インストーラーの検出

インストール プログラムは、ソフトウェアを展開するように設計されたアプリケーションであり、ほとんどの場合、システム ディレクトリとレジストリ キーに書き込まれます。 これらの保護されたシステムの場所は、通常、管理者ユーザーのみが書き込み可能です。これは、標準ユーザーがプログラムをインストールするための十分なアクセス権を持っていないことを意味します。 Windows Vista は、インストール プログラムをヒューリスティックに検出し、アクセス特権で実行するために管理者の資格情報または承認を管理者ユーザーに要求します。 Windows Vista では、アップデータープログラムとインストール解除プログラムもヒューリスティックに検出されます。 UAC の設計目標は、ユーザーがファイル システムとレジストリの保護された領域に書き込むため、ユーザーの知識と同意なしにインストールが実行されないようにすることです。

大事な Windows Vista 用プログラムの開発と同様に、新しいインストール プログラムを開発する場合は、適切な requestedExecutionLevel 要素を使用してアプリケーション マニフェストを埋め込んでください (「手順 6: アプリケーションを使用してアプリケーション マニフェストを作成して埋め込む」セクションを参照してください)。 requestedExecutionLevel が埋め込みアプリケーション マニフェストに存在すると、インストーラーの検出がオーバーライドされます。

インストーラーの検出は、次の場合にのみ適用されます。

• 32 ビット実行可能ファイル
• requestedExecutionLevel を使用しないアプリケーション
• LUA が有効になっている標準ユーザーとして実行されている対話型プロセス

32 ビット プロセスが作成される前に、インストーラーであるかどうかを判断するために、次の属性がチェックされます。

• ファイル名には、"install"、"setup"、"update"などのキーワードが含まれます。
• [バージョン管理リソース] フィールドのキーワード: ベンダー、会社名、製品名、ファイルの説明、元のファイル名、内部名、エクスポート名。
• 実行可能ファイルに埋め込まれたサイド バイ サイド マニフェスト内のキーワード。
• 実行可能ファイルにリンクされている特定の StringTable エントリ内のキーワード。
• 実行可能ファイルにリンクされている RC データの主な属性。
• 実行可能ファイル内のバイトのターゲット シーケンス。

メモ キーワードとバイト シーケンスは、さまざまなインストーラー テクノロジから観察される一般的な特性から派生しました。

「手順 6: アプリケーション マニフェストを作成してアプリケーションに埋め込む」セクションを含め、このドキュメント全体を十分に確認してください。

メモユーザー アカウント制御: アプリケーションのインストールを検出し、インストール プログラムを検出するには、インストーラーの検出に関する設定を有効にする必要があります。 この設定は既定で有効になっており、セキュリティ ポリシー マネージャー スナップイン (secpol.msc) または グループ ポリシー (gpedit.msc) を使用して構成できます。

Microsoft Windows インストーラー の一般的な情報と概要については、MSDN ライブラリを参照してください。

UAC 環境でのアプリケーションの修正プログラムの適用

Microsoft Windows インストーラー 4.0 は、アプリケーションのインストールと修正プログラムの適用を容易にするために、UAC を念頭に置いて設計されています。 Windows インストーラー 4.0 の導入により、新しいバージョンのアプリケーションを再インストールしなくても、アプリケーションにパッチを適用できます。 この方法は、アプリケーションがコンピューターごとのインストールに展開され、ユーザーが管理アクセス トークンを必要とせずにパッチを展開する必要がある場合に最適です。 アプリケーションにパッチを作成して適用する方法については、「 マネージド アプリケーションPer-Userパッチ適用」を参照してください。

Security Center の統合

Windows Vista コンピューターで UAC が無効になっている場合、Security Center によってアラートが作成され、UAC を再度有効にするようにユーザーに求められます。 UAC 設定の変更後にコンピューターが再起動されると、Security Center にこのアラートが表示されます。

ユーザー インターフェイスの特権の分離

ユーザー インターフェイス特権分離 (UIPI) は、完全な管理者として実行されているアプリケーションを、同じ対話型デスクトップ上の管理者よりも低いアカウントとして実行されているプロセスから分離するのに役立つメカニズムの 1 つです。 UIPI は、ウィンドウおよびユーザー インターフェイス コントロールをサポートする USER と呼ばれるウィンドウおよびグラフィックス サブシステムに固有です。 UIPI を使用すると、低い特権アプリケーションで Windows メッセージを使用して、1 つのプロセスからより高い特権プロセスに入力を送信できなくなります。 あるプロセスから別のプロセスに入力を送信すると、ユーザーがキーボードやマウスの操作を行わなくても、プロセスが別のプロセスに入力を挿入できます。

UIPI の背後にある概念は単純です。 Windows Vista では、階層的な方法で一連のユーザー インターフェイス特権レベルが定義されます。 レベルの性質は、特権レベルが高いほど、より低いレベルで実行されているアプリケーションにウィンドウ メッセージを送信できることです。 ただし、下位レベルでは、より高いレベルのアプリケーション ウィンドウにウィンドウ メッセージを送信することはできません。

ユーザー インターフェイスの特権レベルはプロセス レベルです。 プロセスが初期化されると、ユーザー サブシステムはセキュリティ サブシステムを呼び出して、プロセスのセキュリティ アクセス トークンに割り当てられたデスクトップの整合性レベルを決定します。 デスクトップの整合性レベルは、プロセスの作成時にセキュリティ サブシステムによって設定され、変更されません。 したがって、ユーザー・インターフェース特権レベルは、プロセスの作成時にユーザー・サブシステムによっても設定され、変更されません。

標準ユーザーによって実行されるすべてのアプリケーションは、同じユーザー インターフェイス特権レベルを持ちます。 標準ユーザーとして、アプリケーションは 1 つの特権レベルで実行されます。 UIPI は、同じ特権レベルのアプリケーション間のウィンドウ メッセージングの動作を妨げたり変更したりしません。 UIPI は、管理者グループのメンバーであり、標準ユーザーとしてアプリケーションを実行している可能性があるユーザー (フィルター処理されたアクセス トークンを持つプロセスとも呼ばれます) と、同じデスクトップで完全な管理者アクセス トークンで実行されているプロセスに対して有効になります。 UIPI では、次の動作をブロックすることで、低い特権プロセスが高い特権プロセスにアクセスできないようにします。

低い特権プロセスでは、次のことはできません。

• より高いプロセス特権のウィンドウ ハンドル検証を実行します。
• SendMessage または PostMessage を高い特権のアプリケーション ウィンドウに送信します。 これらのアプリケーション プログラミング インターフェイス (API) は成功を返しますが、ウィンドウ メッセージは自動的に削除します。
• スレッド フックを使用して、より高い特権プロセスにアタッチします。
• ジャーナル フックを使用して、より高い特権プロセスを監視します。
• より高い特権プロセスへのダイナミック リンク ライブラリ (DLL) インジェクションを実行します。

UIPI を有効にすると、次の共有ユーザー リソースは引き続き異なる特権レベルのプロセス間で共有されます。

• 実際に画面画面を所有しているデスクトップ ウィンドウ
• デスクトップ ヒープの読み取り専用共有メモリ
• グローバル atom テーブル
• クリップボードのトピック

画面への描画は、UIPI によってブロックされない別のアクションです。 画面への描画とは、Paint メソッドを使用して外部出力 (モニターなど) にコンテンツを表示するプロセスを指します。 ユーザー/グラフィックス デバイス インターフェイス (GDI) モデルでは、描画サーフェスを制御できません。そのため、特権の低いアプリケーションを、より高い特権のアプリケーション ウィンドウのサーフェス領域に描画できます。

メモWindows シェル (エクスプローラー) は標準のユーザー プロセスとして実行されているため、標準ユーザーとして実行されている他のプロセスでもキーストロークを送信できます。 これは、Setup.exeをダブルクリックしたり、昇格シールド アイコンをクリックしたりするなどの管理アクションを開始するときに、管理承認モードの管理者アカウントが昇格の同意を求められる主な理由です。

仮想化

大事な 仮想化は、Windows Vista で標準ユーザーとして実行されているアプリケーションのアプリケーション互換性の問題を改善するために実装されています。 開発者は、後続のバージョンの Windows に存在する仮想化に依存してはなりません。

Windows Vista より前では、多くのアプリケーションは通常、管理者によって実行されていました。 その結果、アプリケーションはシステム ファイルとレジストリ キーを自由に読み書きできます。 これらのアプリケーションが標準ユーザーによって実行された場合、アクセスが不十分なため失敗します。 Windows Vista では、書き込み (および後続のファイルまたはレジストリ操作) をユーザーのプロファイル内のユーザーごとの場所にリダイレクトすることで、これらのユーザーのアプリケーション互換性が向上します。 たとえば、アプリケーションが C:\Program Files\Contoso\Settings.iniに書き込もうとしたときに、そのディレクトリに書き込むアクセス許可がない場合、書き込みは C:\Users\<user name>\AppData\Local\VirtualStore\Program Files\contoso\settings.iniにリダイレクトされます。 レジストリの場合、アプリケーションが HKEY_LOCAL_MACHINE\Software\Contoso\ に書き込もうとすると、自動的に HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software\Contoso または HKEY_USERS\< User SID >_Classes\VirtualStore\Machine\Software\Contoso にリダイレクトされます。

次の図は、Windows Vista の仮想化プロセスの詳細を示しています。 この例では、Denise は管理承認モードの管理者であり、Brian は標準ユーザーです。 仮想化は、ファイル仮想化とレジストリ仮想化の 2 つのコンポーネントで構成されます。

図 1. 仮想化プロセス

大事な Windows Vista プログラムの開発時に、仮想化されたファイルとレジストリ キーの複雑さを軽減するために、ファイルとレジストリの仮想化をオフにするために、適切な requestedExecutionLevel を使用してアプリケーション マニフェストを埋め込む必要があります。

仮想化は、次の場合にのみ有効になります。

• 32 ビット対話型プロセス
• 管理者が書き込み可能なファイル/フォルダーとレジストリ キー

仮想化は、次の場合に無効になっています。

• 64 ビット プロセス
• 非対話型プロセス
• 偽装するプロセス
• カーネル モードの呼び出し元
• requestedExecutionLevel を持つ実行可能ファイル

仮想化とローミング:

• 仮想化ファイル/フォルダーとレジストリ キーがローミングしない (「ローミング プロファイル」を参照)
• ローミングしないグローバル オブジェクトに関連付けられている

ファイルの仮想化

ファイル仮想化は、アプリケーションが、通常は管理者のみが書き込み可能なシステムの場所にファイル (構成ファイルなど) を格納する機能に依存している状況に対処します。 このような状況で標準ユーザーとしてプログラムを実行すると、アクセス レベルが不十分なため、プログラムのエラーが発生する可能性があります。

アプリケーションが管理者のみが書き込み可能なシステムの場所に書き込む場合、Windows は、それ以降のすべてのファイル操作を、%LOCALAPPDATA%\VirtualStore にある仮想ストア ディレクトリの下のユーザー固有のパスに書き込みます。 その後、アプリケーションがこのファイルを読み取り戻すと、システムは仮想ストア内のファイルを提供します。 Windows セキュリティ インフラストラクチャはアプリケーションの支援を受けずに仮想化を処理するため、アプリケーションは Program Files への直接の読み取りと書き込みに成功したと考えています。 ファイル仮想化の透明性により、アプリケーションは、仮想化されたバージョンに実際にアクセスするときに、保護されたリソースから書き込みと読み取りを行っているという認識をアプリケーションに与えます。

メモ フォルダーとレジストリ内のリソースを列挙すると、Windows Vista はグローバル ファイル/フォルダーとレジストリ キーを 1 つのリストにマージします。 このマージされたビューでは、グローバル (保護された) リソースが仮想化リソースと共に一覧表示されます。

大事な 仮想コピーは、常に最初にアプリケーションに存在します。 たとえば、config.iniは \PF\App\config.ini と %LOCALAPPDATA%\VirtualStore\config.iniで使用でき、\PF\App\config.iniが更新された場合でも、仮想ストア内のconfig.iniは常に読み取られます。

次の図では、仮想化されたリソースのグローバル ビューとマージされたビューをさまざまなユーザーに表示する方法について詳しく説明します。

図 2. 仮想化されたリソースとビュー

ファイル仮想化プロセスの例を次に示します。

Woodgrove Bank の営業担当者である Syed Abbas は、他の営業担当者と共有しているコンピューター上の標準ユーザー アカウントで実行されています。 Syed は、多くの場合、スプレッドシート アプリケーションを使用して Program Files\SalesV1\ ディレクトリの下にファイルを更新して保存します: \Program Files\SalesV1\SalesData.txt。 Program Files\SalesV1\ は保護されていますが、Windows Vista ファイルの仮想化により、スプレッドシート アプリケーションの観点からファイルが正常に保存されます。 これを実現するために、ファイルの書き込みは Users\username\appdata\Virtual Store\Program Files\SalesV1\SalesData.txtにリダイレクトされます。 Syed が Windows エクスプローラーを開き、Program Files ディレクトリを参照すると、SalesData.txt ファイルのグローバル ビューが表示されます。

メモSyed が仮想化されたファイルを検出するには、エクスプローラー ツール バーの [互換性ファイル] ボタンを使用して仮想ストアに移動する必要があります。

ただし、別の営業担当者である Stuart Munson がワークステーションにログインすると、Program Files\SalesV1\ ディレクトリにSalesData.txtファイルは表示されません。 別のユーザーがコンピューターを使用し、\Program files\SalesV1\SalesData.txt ファイルを書き込む場合、その書き込みもそのユーザーの仮想ストアに仮想化されます。 ファイル Syed の更新と保存は、システム上の他の仮想化ファイルとは無関係です。

レジストリ仮想化

レジストリ仮想化はファイル仮想化に似ていますが、HKEY_LOCAL_MACHINE\SOFTWAREのレジストリ キーに適用されます。 この機能を使用すると、構成情報をHKEY_LOCAL_MACHINE\SOFTWAREに保存する機能に依存するアプリケーションは、標準ユーザー アカウントで実行するときに続行できます。 キーとデータは、HKEY_CLASSES_ROOT\VirtualStore\SOFTWAREにリダイレクトされます。 ファイル仮想化の場合と同様に、各ユーザーには、アプリケーションが HKLM に格納されている値の仮想化されたコピーがあります。

レジストリ仮想化の詳細

• ソフトウェア ハイブの個々のキーでオン/オフを切り替えることができます
• キー レベルの仮想化制御のreg.exeの新しい FLAGS オプション: 仮想化の再帰的な有効化/無効化と "オープン アクセス権ポリシー" の制御を許可します
• ZwQueryKey: キーの仮想化フラグをプログラムで照会します。
• 仮想化は、WoW64 リダイレクトの上で行われます
• 64 ビットと 32 ビットの両方のレジストリ ビューで有効にしました:HKU\{SID}_Classes\VirtualStore\Machine\Software と HKU\{SID}_Classes\VirtualStore\Machine\Software\SYSWOW3264
• ほとんどのレガシ 32 ビット アプリでは、32 ビット ビューが使用されます

仮想化は、既存のプログラムとのアプリケーションの互換性を支援することのみを目的としています。 Windows Vista 用に設計されたアプリケーションでは、機密性の高いシステム領域への書き込みを実行しないでください。また、アプリケーションの誤った動作を修正するために仮想化に依存する必要もありません。 Windows Vista で実行するように既存のコードを更新する場合、開発者は実行時に、アクセス制御リスト (ACL) 設定が適切に設定されている %alluserprofile% (CSIDL_COMMON_APPDATA) 内のユーザーごとの場所またはコンピューターの場所にのみデータを格納するようにする必要があります。

大事な Microsoft では、Windows Vista に移行されるアプリケーションが増えるにつれて、今後のバージョンの Windows オペレーティング システムから仮想化を削除する予定です。 たとえば、64 ビット アプリケーションでは仮想化が無効になっています。

仮想化に関する推奨事項

仮想化は、既存のプログラムとのアプリケーションの互換性を支援することのみを目的としています。 Windows Vista 用に設計されたアプリケーションでは、機密性の高いシステム領域への書き込みを実行しないでください。また、アプリケーションの誤った動作を修正するために仮想化に依存する必要もありません。 Windows Vista で実行するように既存のコードを更新する場合、開発者は実行時に、アクセス制御リスト (ACL) 設定が適切に設定されている %alluserprofile% 内のユーザーごとの場所またはコンピューターの場所にのみデータを格納するようにする必要があります。

大事な Microsoft では、Windows Vista に移行されるアプリケーションが増えるにつれて、今後のバージョンの Windows オペレーティング システムから仮想化を削除する予定です。 たとえば、64 ビット アプリケーションでは仮想化が無効になっています。

• 対話型アプリケーションに適切な requestedExecutionLevel を含むアプリケーション マニフェストを追加します。 これにより、マニフェスト アプリケーションの仮想化がオフになります。
• プロセス間通信メカニズムとしてレジストリを使用しないでください。 サービスとユーザー アプリケーションでは、キーのビューが異なります。
• Windows Vista でアプリケーションをテストする: 標準ユーザーとして実行されているプロセスが、%systemroot% などのグローバル名前空間に書き込まれていないことを確認します。
• フィルター ドライバー開発者向け: 高度の範囲を確認します。 「ファイル システム フィルター」を参照してください。 これらは FSFilter 仮想化よりも高い必要があります。
• 仮想化されたリソースは、グローバル リソースのユーザーごとのコピーです。

アクセス トークンの変更

ユーザーが Windows Vista コンピューターにログオンすると、Windows は、ユーザー アカウントが持っている管理 Windows 特権と相対 ID (RID) を調べて、ユーザーが 2 つのアクセス トークン (フィルター処理されたアクセス トークンとフル アクセス トークン) を受け取る必要があるかどうかを判断します。 次のいずれかに該当する場合、Windows はユーザーに対して 2 つのアクセス トークンを作成します。

1. ユーザーのアカウントには、次のいずれかの RID が含まれています。
   • DOMAIN_GROUP_RID_ADMINS
   • DOMAIN_GROUP_RID_CONTROLLERS
   • DOMAIN_GROUP_RID_CERT_ADMINS
   • DOMAIN_GROUP_RID_SCHEMA_ADMINS
   • DOMAIN_GROUP_RID_ENTERPRISE_ADMINS
   • DOMAIN_GROUP_RID_POLICY_ADMINS
   • DOMAIN_ALIAS_RID_ADMINS
   • DOMAIN_ALIAS_RID_POWER_USERS
   • DOMAIN_ALIAS_RID_ACCOUNT_OPS
   • DOMAIN_ALIAS_RID_SYSTEM_OPS
   • DOMAIN_ALIAS_RID_PRINT_OPS
   • DOMAIN_ALIAS_RID_BACKUP_OPS
   • DOMAIN_ALIAS_RID_RAS_SERVERS
   • DOMAIN_ALIAS_RID_PREW2KCOMPACCESS
   • DOMAIN_ALIAS_RID_NETWORK_CONFIGURATION_OPS
   • DOMAIN_ALIAS_RID_CRYPTO_OPERATORS
2. ユーザーのアカウントには、標準ユーザー アカウント以外の特権が含まれています。 標準ユーザー アカウントには、次の特権のみが含まれます。
   • SeChangeNotifyPrivilege
   • SeShutdownPrivilege
   • SeUndockPrivilege
   • SeIncreaseWorkingSetPrivilege
   • SeTimeZonePrivilege

フィルター処理されたトークンに含まれる特権は、元のトークンに上記の制限付き RID が含まれているかどうかに基づいています。 制限付き RID のいずれかがトークンに含まれている場合は、次を除くすべての特権が削除されます。

• SeChangeNotifyPrivilege
• SeShutdownPrivilege
• SeUndockPrivilege
• SeReserveProcessorPrivilege
• SeTimeZonePrivilege

トークンに制限付き RID がない場合は、次の特権のみが削除されます。

• SeCreateTokenPrivilege
• SeTcbPrivilege
• SeTakeOwnershipPrivilege
• SeBackupPrivilege
• SeRestorePrivilege
• SeDebugPrivilege
• SeImpersonatePrivilege
• SeRelabelPrivilege

フィルター処理されたアクセス トークンと呼ばれる最初のアクセス トークンには、以前の RID (存在する場合) がアクセス トークンにUSE_FOR_DENY_ONLYとしてマークされ、以前にリストされていない管理 Windows 特権が削除されます。 フィルター処理されたアクセス トークンは、ユーザーがアプリケーションを起動するときに既定で使用されます。 変更されていないフル アクセス トークン (リンクされたアクセス トークンと呼ばれます) は、フィルター処理されたアクセス トークンにアタッチされ、完全な管理アクセス トークンを使用してアプリケーションを起動するための要求が行われるときに使用されます。

RID の詳細については、MSDN ライブラリの記事 SID 文字列 [セキュリティ] を参照してください。

Windows 特権の詳細については、MSDN ライブラリの「 承認定数 [セキュリティ]」を参照してください。

UAC のアーキテクチャ

次の図は、Windows Vista での実行可能な起動のプロセス フローを示しています。

図 3: UAC アーキテクチャ

UAC アーキテクチャ図に表示されるプロセス フローと、実行可能ファイルの起動時に UAC を実装する方法を次に示します。

標準ユーザー起動パス

Windows Vista 標準のユーザー起動パスは、Windows XP の起動パスに似ていますが、いくつかの変更が含まれています。

• ShellExecute() は CreateProcess() を呼び出します。
• CreateProcess() は AppCompat、Fusion、インストーラー検出を呼び出して、アプリケーションに昇格が必要かどうかを評価します。 その後、実行可能ファイルが検査され、実行可能ファイルのアプリケーション マニフェストに格納されている要求されたExecutionLevel が決定されます。 AppCompat データベースには、アプリケーションのアプリケーション互換性修正エントリの情報が格納されます。 インストーラー検出では、セットアップ実行可能ファイルが検出されます。
• CreateProcess() は、ERROR_ELEVATION_REQUIREDを示す Win32 エラー コードを返します。
• ShellExecute() は特にこの新しいエラーを検索し、受信すると、アプリケーション情報サービス (AIS) を呼び出して昇格された起動を試みます。

昇格された起動パス

Windows Vista の昇格された起動パスは、新しい Windows 起動パスです。

• AIS は ShellExecute() から呼び出しを受け取り、要求された実行レベルとグループ ポリシーを再評価して、昇格が許可されているかどうかを判断し、昇格ユーザー エクスペリエンスを定義します。
• 要求された実行レベルに昇格が必要な場合、サービスは、ShellExecute() から渡された HWND を使用して、呼び出し元の対話型デスクトップで (グループ ポリシーに基づいて) 昇格プロンプトを起動します。
• ユーザーが同意または有効な資格情報を与えると、AIS は、必要に応じて、適切なユーザーに関連付けられている対応するアクセス トークンを取得します。 たとえば、highestAvailable の requestedExecutionLevel を要求するアプリケーションでは、Backup Operators グループのメンバーのみのユーザーに対して、ローカル Administrators グループのメンバーとは異なるアクセス トークンを取得します。
• AIS は CreateProcessAsUser() 呼び出しを再発行し、管理者アクセス トークンを指定し、呼び出し元の対話型デスクトップを指定します。

UAC はアプリケーションに影響しますか?

アプリケーションが UAC の影響を受けるかどうかは、アプリケーションの現在の状態によって異なります。 多くの場合、Microsoft Windows セキュリティの要件に準拠するために変更は必要ありません。 ただし、基幹業務 (LOB) アプリケーションを含む一部のアプリケーションでは、Windows Vista UAC 環境で適切に動作するために、インストール、機能、および更新プロセスの変更が必要になる場合があります。

メモ アプリケーションが Windows XP の標準ユーザーと同様に機能する場合は、Windows Vista の標準ユーザーと同様に動作します。

アプリケーションの管理依存関係を削除する必要がある理由

コンピューティング環境全体のセキュリティを強化するための基本的な手順の 1 つは、ユーザーが管理アクセス トークンを使用せずに実行できるようにすることです。 ユーザーが管理者の場合にのみアプリケーションが動作またはインストールされる場合、ユーザーは不要な昇格されたアクセス権を持つアプリケーションの実行を強制されます。 基本的な問題は、ユーザーが常に昇格されたアクセス トークンを使用してアプリケーションを実行することを強制される場合、詐欺的または悪意のあるコードがオペレーティング システムを簡単に変更したり、他のユーザーに影響を与えたりする可能性があるということです。

Microsoft の目標は、お客様がアプリケーションを不必要に管理者として実行してはならないことを理解し、管理者として実行するアプリケーションの要求を承認するように求められたらいつでも質問することです。 UAC は、この目標を達成するための基本的なコンポーネントであり、すべてのユーザーにとってより安全なコンピューティング環境の復元に向けて長い道のりを進めます。

アプリケーションの総保有コストの削減

標準的なユーザー アカウントは、総保有コスト (TCO) を削減しながら、マネージド マシンのセキュリティと制御を強化することに関心がある IT 管理者にとって非常に魅力的です。 標準ユーザー アカウントではシステムを変更できないため、TCO の削減と直接の関係があり、アプリケーションのインストールとシステム全体の変更をより適切に制御できます。 標準ユーザー アカウントは、親がコンピューターを子供と共有する家庭ユーザーにも魅力的です。 Microsoft Windows Vista には、子のユーザー アカウントを標準ユーザーとして作成することによってのみ正常に実装される、統合されたペアレンタル コントロールが含まれています。 標準ユーザー アカウントでは、他のユーザーによって作成されたファイルを変更または削除することもできません。 他のユーザーのプロファイル内のファイルを読み取ったり、システム ファイルに感染したり、システム共有の実行可能ファイルを誤ってまたは意図的に変更したりすることはできません。 標準のユーザー アカウントを使用すると、コンピューターのセキュリティと保護者による制御が全体的に向上します。

既定でセキュリティ保護

Microsoft では、Microsoft の信頼できるコンピューティング イニシアチブのテネトがソフトウェア開発に取り組んでいます。 そのため、セキュリティの強化は、Windows Vista 開発プロセスの不可欠な部分となっています。

信頼できるコンピューティングのセキュリティの柱には、設計によるセキュリティ保護、既定でのセキュリティ保護、デプロイでのセキュリティの 3 つの基礎が含まれています。 あなたと他の ISV がオペレーティング システムの全体的なセキュリティに貢献するためにアプリケーションを開発する方法は、Windows Vista で信頼できるコンピューティングを実現するための重要な成功要因になります。

このガイドの残りの部分の目標は、開発者に次の方法を教えるのに役立ちます。

• ユーザーが日常的なタスクを実行するために管理者である必要のないアプリケーションを作成する
• Windows® インストーラー 4.0 UAC パッチ適用テクノロジを使用してインストール パッケージを作成します。このテクノロジは、企業の標準ユーザー デスクトップに適切に展開され、家庭でも正しく更新されます。
• UAC の互換性のために、標準のユーザーと管理機能を特定し、管理タスクを外挿する
• UAC 機能を利用するアプリケーション ユーザー インターフェイスを作成する

UAC を成功させるには、アプリケーション開発者が最小限の特権の哲学を受け入れ、標準ユーザー アカウントで実行するときにアプリケーションが正しく機能するように設計することが不可欠です。

Windows Vista リリースの目標の 1 つは、管理承認モードの標準ユーザーと管理者向けの設計の原則をすべての開発者に伝え、奨励することです。 この目標を達成することは、個々のアプリケーションに対するさまざまな攻撃の防止に役立ち、そのような攻撃がシステムのセキュリティを侵害する可能性を軽減します。 これらの目標は、管理者に 2 つのアカウントの使用を要求することで、現在ある程度達成できますが、次の理由で失敗する傾向があります。

• 完全な管理者アクセス トークンを持つユーザーを制御することはほとんど不可能です。 管理者は、アプリケーションをインストールし、任意のアプリケーションまたはスクリプトを実行できます。 IT マネージャーは、ユーザーが標準ユーザーとしてログオンする "標準デスクトップ" を作成する方法を常に模索しています。 標準デスクトップは、ヘルプ デスクのコストを大幅に削減し、IT オーバーヘッドを削減します。
• ユーザーが管理操作を実行しようとするたびにアカウントを切り替えると、大幅なオーバーヘッドが発生します。
• 管理操作を実行した後、ユーザーは標準ユーザー アカウントに切り替えるのを忘れたり、切り替える手間が多すぎると判断したりする場合があります。

その結果、ユーザーは常に自分の管理アカウントにログインすることを決定し、セキュリティ対策を破る可能性があります。 これを軽減するために、UAC では管理承認モードの概念が導入されています。 管理承認モードのユーザー アカウントは、UAC が有効になっているシステムのローカル管理者グループのメンバーであるユーザー アカウントです。

企業では、管理承認モードは、Windows Vista への移行のブリッジ テクノロジとして使用されます。 企業では、すべてのユーザーを標準ユーザーとして実行し、標準ユーザーの昇格プロンプトを無効にするのが理想的です。 このセットアップにより、Microsoft Systems Management Server (SMS) などのソフトウェア展開テクノロジを使用してインストールが展開されるマネージド標準デスクトップが有効になります。

大事な 引き続き、Domain Admins グループのメンバーは、Windows Vista で 2 つの個別のユーザー アカウント (標準ユーザー アカウントとドメイン管理者ユーザー アカウント) を維持することをお勧めします。 すべてのドメイン管理は、ドメイン管理者アカウントで行う必要があります。 セキュリティをさらに強化するには、ドメイン環境にスマート カード ソリューションをデプロイすることを検討してください。 詳細については 、「スマート カードを使用したセキュア アクセスの計画ガイド 」を参照してください。

管理承認モードの Windows Vista の設計目標を次に示します。

• 管理者グループのメンバーであるユーザーに対して 2 つの個別アカウントが不要になります。この目標は、ユーザーが完全な管理アクセス トークンの使用を承認しない限り、標準のユーザー アクセス トークンでのみプログラムを実行することで実現されます。
• 完全な管理アクセス トークンを使用して実行されているプロセスが、標準ユーザーとして実行されているプロセスによってアクセスまたは変更されないように保護します。
• 管理者と標準のユーザー ワークスペースのシームレスな切り替えを提供します。

現在、ほとんどの Windows アプリケーションは管理者として実行する必要がありますが、実際には管理操作を実行しません。 これらのアプリケーションは、Microsoft Windows 9x オペレーティング システムの哲学の副産物です。"すべてのユーザーは管理者です"。

問題のあるアプリケーションの例を次に示します。

• HKEY_LOCAL_MACHINE (HKLM) またはファイル・システム内のシステム・ファイルに不必要に書き込むアプリケーション。
• Web インターフェイスを使用して基幹業務アプリケーションを容易にする ActiveX インストール。
• 完全な管理アクセス トークンを必要とするリソースへのアクセスを不必要に要求するアプリケーション。

次のセクションでは、ISV に影響を与える Windows Vista の新しいテクノロジについて説明します。

アプリケーションに管理上の依存関係があるかどうかを確認するにはどうすればよいですか?

開発者、ISV、および組織がアプリケーションを評価するのを支援するために、Microsoft は Microsoft Standard User Analyzer を提供しています。 Standard User Analyzer を使用すると、アプリケーションの UAC に準拠していない動作を識別できます。 Microsoft では、開発者がこのツールを実行して、標準ユーザー アカウントでアプリケーションを実行する際の問題を特定することをお勧めします。 これらのテストは、アプリケーションが既にインストールされ、Windows XP の標準ユーザー アカウントで適切に実行されている場合でも実行する必要があります。 アプリケーションは、システム レジストリの場所への書き込みを試みるなどの操作を実行し、エラー応答の検索など、システムの動作に基づいて決定を行う場合があります。 新しいアプリケーション互換性サポートが追加されたため、Windows Vista の動作は以前のバージョンの Windows オペレーティング システムとは異なる場合があります。 そのため、すべてのアプリケーションを新しいバージョンの Standard User Analyzer でテストすることをお勧めします。

Standard User Analyzer は、レジストリ/ファイル システム アクセスや昇格された API 呼び出しなど、アプリケーションによって検出されたすべての管理操作を記録します。 このデータはログ ファイルに格納され、ツール内に表示されます。 Standard User Analyzer は、他の多くの依存関係に加えて、次の一般的な依存関係を識別します。

• 要求されたアクセスを信頼されたユーザーのみに制限するオブジェクトへの依存関係。

  たとえば、HKEY_LOCAL_MACHINEは管理者と SYSTEM にのみKEY_WRITEを付与します。HKEY_LOCAL_MACHINEへのKEY_WRITEを要求するアプリケーションは、UAC を有効にして動作しません。

• SE_DEBUG_PRIVILEGEなどのセキュリティ上の影響を受ける Windows 特権を使用します。これにより、他のユーザーのプロセスのデバッグが可能になり、管理者にのみ付与されます。

正当な管理者アプリケーションがある場合の要件は何ですか?

設計上、正当な管理操作を実行するアプリケーションの場合、Microsoft は現在の Windows XP アプリケーション マニフェスト スキーマの trustInfo セクションの拡張機能を実装しています。 これらの新しい属性を使用して、正当な管理アプリケーションがあることをシステムに示すことができます。システムは、完全な管理アクセス トークンを使用してアプリケーションを起動するための承認をユーザーに自動的に要求します。 アプリケーション マニフェストを拡張する方法については、このドキュメントの「アプリケーション マニフェストを作成してアプリケーションに埋め込む」セクションを参照してください。

Windows Vista 用アプリケーションの設計

次の一覧は、Windows Vista 用のアプリケーションを設計するためのワークフローを表しています。

1. Windows Vista アプリケーションの互換性についてアプリケーションをテストする
2. アプリケーションを標準ユーザー、管理者、または混合ユーザー アプリケーションとして分類する
3. UAC 互換性のためにアプリケーションの機能を再設計する
4. アプリケーションのユーザー インターフェイスを再設計する
5. アプリケーションのインストーラーを再設計する
6. アプリケーション マニフェストを作成して管理アプリケーションに埋め込む
7. アプリケーションのテスト
8. アプリケーションに署名する
9. Windows Vista ロゴ プログラムを実行するかどうかを決定する

1. アプリケーションの互換性をテストする

UAC とのアプリケーション互換性のテストは、Standard User Analyzer をインストールすることで簡単に実行できます。

Standard User Analyzer のグラフィカル ログ表示を利用するには、Microsoft アプリケーション検証ツールをインストールする必要があります。 アプリケーション検証ツール は、Microsoft Web サイトで無料でダウンロードできます。

次の手順は、標準ユーザー アナライザーを使用して、Windows Vista で正しく実行されない Windows Vista 管理アプリケーションを識別する方法を示しています。

Standard User Analyzer を利用するには、次の 2 つの方法があります。標準ユーザーとしてアプリケーションを起動するか、管理者として昇格してアプリケーションを起動します。

標準ユーザーとしてアプリケーションを起動します。

このインスタンスでは、Standard User Analyzer が診断モードで実行されています。 アプリケーションは最初に発生したエラーで失敗し、Standard User Analyzer は失敗した理由を報告します。

管理者として昇格したアプリケーションを起動します。

このインスタンスでは、Standard User Analyzer が予測モードで実行されています。 アプリケーションはコースを通じて実行でき、Standard User Analyzer は、アプリケーションが標準ユーザーとして実行された場合に発生する可能性があるエラーを予測して概要を示します。

バグを修正して解決したら、標準ユーザー アナライザーを使用せずに標準ユーザーとしてもう一度この手順を実行して、アプリケーションが Windows Vista で期待どおりに動作していることを確認します。

Windows Vista 以前のアプリケーションのアプリケーション互換性の問題を特定するには

1. 管理承認モードで管理者として Windows Vista コンピューターにログオンします。
2. [ スタート] をクリックし、[ すべてのプログラム] をクリックし、[ Standard User Analyzer] をクリックします。
3. Standard User Analyzer の [ターゲット アプリケーション] で、テストするアプリケーションの完全なディレクトリ パスを指定するか、[参照] ボタンをクリックして、Windows エクスプローラープログラムの実行可能ファイルを見つけます。
4. [ 起動 ] をクリックし、[ユーザー アカウント制御] ダイアログ ボックスの [ 続行 ] をクリックします。
5. テスト アプリケーションが起動したら、アプリケーションで標準の管理タスクを実行し、完了したらアプリケーションを閉じます。
6. Standard User Analyzer で、各タブの出力を調べます。このデータを使用して、プログラムの互換性の問題を特定します。

2. アプリケーションを標準ユーザー、管理者、または混合ユーザー アプリケーションとして分類する

Windows Vista の管理アプリケーションには、多くの場合、管理と標準の両方のユーザー機能が混在しています。 その結果、Windows Vista でのアプリケーションの動作を決定する際には、いくつかのオプションを考慮する必要があります。 管理機能は、ユーザーに承認を求めることで、完全に削除することも、標準のユーザー アカウント機能から分離することもできます。

アプリケーションの分類に役立つ質問

次の質問に答えて、アプリケーションで Windows Vista 互換性の再設計が必要かどうかを判断します。

• アプリケーションは標準ユーザーとして実行されますか?
• 管理者アクセス トークンを不要にするように管理機能を修正できますか?
• 管理セクションをプログラムの機能から削除できますか?

アプリケーションは標準ユーザーとして実行されますか?

この質問に回答するには、標準ユーザーがアプリケーションまたは機能を完全に使用していることを確認します。 機能の一部でユーザーが管理者である必要がある場合、この質問に対する回答は "いいえ" です。

アプリケーションまたはコントロール パネルを標準ユーザーが使用できることを確認する方法:

• アプリケーションまたはコントロール パネルを標準ユーザーと管理者の両方として十分にテストします。 標準ユーザーと管理者の両方で、ユーザー操作がすべてまったく同じであることを確認します。
• 設定がレジストリに格納されている場所を確認します。 設定が HKLM に格納されている場合、アプリケーションまたはコントロール パネルには管理者アクセス トークンが必要になる可能性が高くなります。
• いずれかの設定がコンピューター単位の場合、アプリケーションまたはコントロール パネルには管理者アクセス トークンが必要です。
• 設定のいずれかが他のユーザーのプロファイルで何かを行う場合、アプリケーションまたはコントロール パネルには管理者アクセス トークンが必要です。

管理機能は、管理者アクセス トークンを不要にするように修正できますか?

アプリケーションまたはコントロール パネルに、完全な管理者アクセス トークンを必要とする設定または操作がある場合、標準ユーザーとして正しく動作するように変更できますか? 具体的には、プログラムは代わりにユーザーごとの設定に情報を格納できますか? できない場合、この質問に対する答えは "いいえ" です。

修正できる機能/設定の種類の良い例は、Calc.exe (Windows 電卓) です。 Windows XP では、"Scientific" と "Standard" の設定はコンピューターごとの設定でした。つまり、設定を変更するには完全な管理アクセス トークンが必要でした。 Windows Vista では、この設定はユーザーのプロファイルに格納されます。

管理セクションをプログラムの機能から削除できることを確認する方法:

• アプリケーションまたはコントロール パネルを標準ユーザーと管理者の両方として十分にテストします。 両方の種類のユーザーでエクスペリエンスを同じにすることはできますか?

• HKLM キーへの書き込みに必要なアクセス制御リスト (ACL) を下げることは可能ですか?

  メモ このコースは軽く受け入れてはいけません。 ACL によって提供される制御を下げることで、システムの全体的なセキュリティを損なわないよう注意してください。

• ユーザー インターフェイスを変更して、グローバル状態ではなくユーザーごとの状態を設定することは可能ですか (ユーザー インターフェイスを介してグローバル状態の変更を公開しない)。

プログラムの機能から管理セクションを削除できますか?

機能には、この機能が絶対に必要ですか? 管理機能や機能を切り取ることができない場合、この質問に対する答えは "いいえ" です。

管理セクションをプログラムの機能から削除できるかどうかを判断するには、次の操作を行います。

• コントロール パネルを標準ユーザーおよび管理者としてテストします。 この機能を保持するためのユーザー シナリオは何ですか?
• この設定/機能は他の場所で公開されていますか? コントロール パネルの機能が冗長である可能性があります。

アプリケーションを分類するための回答の分析

上記の質問のいずれかに対して "はい" と答えた場合

アプリケーションまたはコントロール パネル (存在する場合) で必要な変更を行って、ユーザーが完全な管理アクセス トークンを持つ必要がある項目を削除します。

次の一覧では、真の標準ユーザー アプリケーションを使用する利点について詳しく説明します。

• 機能は、すべてのユーザーに対して同様に使用できます。 ほとんどの機能では完全な管理者アクセス トークンを必要としないため、これは理想的な状態です。
• ユーザーには、フィーチャを含む昇格プロンプトは表示されません。
• 管理者アクセス トークンを必要とせず、機能の安全性が大幅に高くなります。

前のすべての質問に対して "いいえ" と答えた場合

UAC で機能を動作させるには、アプリケーションまたはコントロール パネルを変更する必要があります。

アプリケーションまたはコントロール パネルが UAC と連携することを確認します。

最後に、アプリケーションまたはコントロール パネルを標準ユーザーおよび管理者としてテストします。 この特定のアプリケーションまたはコントロール パネルに他のオプション (前の質問) を使用できないことを確認します。

3. UAC 互換性のためにアプリケーションの機能を再設計する

アプリケーションを分類し、UAC 用に再設計する必要があるかどうかを判断したら、このセクションの情報を使用します。

Windows Vista 用のアプリケーションを再設計する大きなコンポーネントは、アプリケーションのユーザー アクセス モデルを中心に調べることになります。

すべての Windows Vista アプリケーションの要件

requestedExecutionLevel を指定する

UAC を適切に動作させるには、オペレーティング システムは、昇格された特権が必要なコードと、そうでないコードを識別できる必要があります。

Windows Vista では、これらの変更により、アプリケーションを起動する必要があるコンテキストでオペレーティング システムが判断できる情報でアプリケーションをマークする必要があります。 たとえば、標準ユーザー アプリケーションは呼び出し元として実行するようにマークする必要があり、アクセシビリティ対応アプリケーションはシステムによって識別される必要があります。

Rundll32 にコンポーネントを登録しない

一部のアプリケーションでは、Windows Rundll32 実行可能ファイルを使用してコンポーネントを実行します。 ただし、このメソッドは Windows Vista の開発要件に準拠していません。 Rundll32 を直接呼び出すと、UAC 互換性の問題が発生します。 アプリケーションがその実行を実行するために Rundll32 実行可能ファイルに依存している場合、Rundll32 はアプリケーションに代わってアプリケーション情報サービス (AIS) を呼び出して UAC 昇格プロンプトを開始します。 その結果、UAC 昇格プロンプトには元のアプリケーションに関する知識がなく、昇格を要求するアプリケーションが "Windows ホスト プロセス (Rundll32) " と表示されます。昇格を要求するアプリケーションの明確な説明とアイコンがないと、ユーザーはアプリケーションを識別して、昇格しても安全かどうかを判断する方法がありません。

アプリケーションが Rundll32 を呼び出してコンポーネントを実行する場合は、次のワークフローを使用して実行呼び出しを再設計します。

1. アプリケーション用の新しい別の実行可能ファイルを作成します。
2. 新しい実行可能ファイルで、Rundll32 で指定した DLL 内のエクスポートされた関数を呼び出します。 .lib がない場合は、DLL を読み込む必要がある場合があります。
3. リソース ファイルで、実行可能ファイルの新しいアイコンを作成して追加します。 このアイコンは、アプリケーションが昇格を要求すると、ユーザー アカウント制御の昇格プロンプトに表示されます。
4. 実行可能ファイルの短くわかりやすい名前を指定します。 この名前は、アプリケーションが昇格を要求すると、ユーザー アカウント制御の昇格プロンプトに表示されます。
5. 実行可能ファイルのアプリケーション マニフェスト ファイルを作成して埋め込み、要求された実行レベルの requireAdministrator でマークします。 このプロセスの詳細については、「アプリケーション マニフェストをアプリケーションに作成して埋め込む」セクションを参照してください。
6. Authenticode は、新しい実行可能ファイルに署名します。 このプロセスの詳細については、「Authenticode Sign Your Application」セクションを参照してください。

アプリケーションのインストール解除後、ユーザーはエラーなしで再インストールできる必要があります。

標準ユーザー アプリケーションの要件

標準ユーザー アカウントで正しく動作するアプリケーションを設計する際に覚えておく必要がある事項の概要を次に示します。 開発者は、アプリケーションの設計フェーズでこれらの要件に留意する必要があります。

セットアップ

• 初回実行時に管理アクション (セットアップ プロセスの完了など) を実行しないでください。初期セットアップ プロセスの一環として行う必要があります。
• Windows ディレクトリまたはサブディレクトリに直接書き込むことはありません。 フォントなどのファイルをインストールする場合は、正しい方法を使用します。
• アプリケーションを自動的に更新する必要がある場合は、Windows インストーラー 4.0 ユーザー アカウント制御のパッチ適用など、標準ユーザーが使用するのに適したメカニズムを使用して更新プログラムを実行します。

状態の保存

• ユーザーごとの情報やユーザーが書き込み可能な情報を Program Files または Program ディレクトリに書き込まないでください。
• ファイル システムでハードコーディングされたパスを使用しないでください。 KnownFolders API と ShGetFolder を利用して、データを書き込む場所を見つけます。

標準ユーザー アカウントでの実行とテスト

LOB アプリケーションやゲームなどのユーザー アプリケーションなどの管理以外のアプリケーションを作成する場合は、標準ユーザーがアクセスできる場所にアプリケーション データを常に書き込む必要があります。 推奨される要件の一部を次に示します。

• ユーザー プロファイルにユーザーごとのデータを書き込む: CSIDL_APPDATA。
• コンピューターごとのデータを Users\All Users\Application Data: CSIDL_COMMON_APPDATAに書き込みます。
• アプリケーションは、管理 API に依存できません。 たとえば、SetTokenInformation() Windows 関数を正常に呼び出す必要があるプログラムは、標準ユーザー アカウントで失敗します。

高速ユーザー切り替え (FUS) に対応する

アプリケーションは、アプリケーションを実行するユーザー以外のユーザーによってインストールされるのがより一般的です。 たとえば、家庭では、親が子のアプリケーションをインストールすることを意味します。 企業では、SMS やグループ ポリシーアドバタイズなどの展開システムによって、管理者アカウントを使用してアプリケーションがインストールされます。

最初の実行時にユーザーごとの設定が存在しない場合は、それらを再構築します。 セットアップ プロセスが設定を処理したと想定しないでください。

管理者アプリケーションの要件

HWND プロパティを使用してフォアグラウンド アプリケーションとして確認する

バックグラウンド アプリケーションでは、セキュリティで保護されたデスクトップに自動的に移動して昇格するのではなく、タスク バーに昇格を求めるメッセージが自動的に表示されます。 昇格プロンプトがタスク バーに最小化されて表示され、アプリケーションが昇格を要求したことをユーザーに通知するために点滅します。 バックグラウンド昇格の例は、ユーザーが Web サイトを参照し、インストール ファイルのダウンロードを開始したときに発生します。 その後、インストールがバックグラウンドでダウンロードされている間、ユーザーは電子メールをチェックに移動します。 ダウンロードがバックグラウンドで完了し、インストールが開始されると、昇格はフォアグラウンド タスクではなくバックグラウンド タスクとして検出されます。 この検出により、ユーザーが別のタスク読み取り電子メールを実行している間に、インストールによってユーザーの画面のフォーカスが突然盗まれるのを防ぐことができます。 この動作により、昇格プロンプトのユーザー エクスペリエンスが向上します。

ただし、一部のフォアグラウンド アプリケーションでは、現在、Windows Vista でバックグラウンド アプリケーションとしてプロンプトが表示されます。 この動作は、親 HWND が存在しない結果です。 Windows Vista でアプリケーションがフォアグラウンド アプリケーションとして認識されるようにするには、ShellExecute、CreateElevatedComObject (COM)、またはマネージド コード呼び出しで親 HWND を渡す必要があります。

UAC 昇格メカニズムは、昇格が背景と前景のどちらであるかを判断する一環として HWND を使用します。 アプリケーションがバックグラウンド アプリケーションであると判断された場合、昇格は点滅ボタンとしてタスク バーに配置されます。 昇格を続行する前に、フォアグラウンド アクセスを要求するアプリケーションと同様に、ユーザーはボタンをクリックする必要があります。 HWND を渡さないと、アプリケーションが実際にフォアグラウンドを持っている可能性がある場合でも、これが発生します。

次のコード サンプルは、ShellExecute で HWND を渡す方法を示しています。

BOOL RunAsAdmin( HWND hWnd, LPTSTR lpFile, LPTSTR lpParameters )
{
    SHELLEXECUTEINFO   sei;
    ZeroMemory ( &sei, sizeof(sei) );

    sei.cbSize          = sizeof(SHELLEXECUTEINFOW);
    sei.hwnd            = hWnd;
    sei.fMask           = SEE_MASK_FLAG_DDEWAIT | SEE_MASK_FLAG_NO_UI;
    sei.lpVerb          = _TEXT("runas");
    sei.lpFile          = lpFile;
    sei.lpParameters    = lpParameters;
    sei.nShow           = SW_SHOWNORMAL;

    if ( ! ShellExecuteEx ( &sei ) )
    {
        printf( "Error: ShellExecuteEx failed 0x%x\n", GetLastError() );
        return FALSE;
    }
    return TRUE;
}

次のコード サンプルは、昇格モニカーを使用して CreateElevatedComObject で HWND を渡す方法を示しています。 現在のスレッドで COM が既に初期化されていることを前提としています。 昇格モニカーの詳細については、このドキュメントの手順 4 を参照してください。

HRESULT CreateElevatedComObject(HWND hwnd, REFCLSID rclsid, REFIID riid, __out void ** ppv)
{
    BIND_OPTS3 bo;
    WCHAR  wszCLSID[50];
    WCHAR  wszMonikerName[300];

    StringFromGUID2(rclsid, wszCLSID, sizeof(wszCLSID)/sizeof(wszCLSID[0])); 
    HRESULT hr = StringCchPrintf(wszMonikerName, sizeof(wszMonikerName)/sizeof(wszMonikerName[0]), L"Elevation:Administrator!new:%s", wszCLSID);
    if (FAILED(hr))
        return hr;
    memset(&bo, 0, sizeof(bo));
    bo.cbStruct = sizeof(bo);
    bo.hwnd = hwnd;
    bo.dwClassContext  = CLSCTX_LOCAL_SERVER;
    return CoGetObject(wszMonikerName, &bo, riid, ppv);

BIND_OPTS3は Windows Vista の新機能です。 これは、BIND_OPTS2から派生します。 次のように定義します。

typedef struct tagBIND_OPTS3 : tagBIND_OPTS2
{
    HWND hwnd;
} BIND_OPTS3, * LPBIND_OPTS3;

唯一の追加は、HWND フィールド hwnd です。 このハンドルは、セキュリティで保護されたデスクトッププロンプトが有効になっているときに昇格 UI の所有者になるウィンドウを表します。

次のコード サンプルは、マネージド コードで HWND を渡して、親ダイアログが HWND とその使用を確実に認識できるようにする方法を示しています。

System.Diagnostics.Process newProcess = new System.Diagnostics.Process();
System.Diagnostics.ProcessStartInfo info = new System.Diagnostics.ProcessStartInfo("D:\SomeProgram.exe");
info.UseShellExecute = true;
info.ErrorDialog = true;
info.ErrorDialogParentHandle = this.Handle;
newProcess.StartInfo = info;
newProcess.Start();

ユーザーのログオン パスの昇格を求めないでください

ユーザーがログオンしたときに起動し、昇格を必要とするアプリケーションが、ログオン パスでブロックされるようになりました。 アプリケーションがユーザーのログオン パスに昇格を求めるメッセージを表示しないようにするには、標準ユーザーと管理者の両方が、ログオンするたびに [ユーザー アカウント制御] ダイアログ ボックスに応答する必要があります。 Windows Vista は、システム トレイにアイコンを配置してアプリケーションがブロックされた場合にユーザーに通知します。 その後、ユーザーはこのアイコンを右クリックして、ユーザーのログオン時に昇格を求めるメッセージが表示されないようにブロックされたアプリケーションを実行できます。 ユーザーは、トレイ アイコンをダブルクリックして、この一覧から無効または削除するスタートアップ アプリケーションを管理できます。

タスク スケジューラを使用してユーザーの昇格を実行する方法を示す C++ コード サンプルについては、このドキュメントの「参照」セクションを参照してください。

Runas を使用して昇格されたプロセスを起動しない

Windows XP および Windows Server 2003 の [Run as... ] オプションは、Windows Vista のコンテキスト メニュー (実行可能ファイルを右クリックしたときに使用可能) の [ 管理者として実行 ] に置き換えられました。 標準ユーザーが [ 管理者として実行 ] オプションを選択すると、ローカル コンピューター上のアクティブな管理者の一覧が表示されます。 Backup Operators グループのメンバーなど、より高い特権を持つ標準ユーザーも表示されます。 管理者が [ 管理者として実行 ] オプションを選択すると、[ユーザー アカウント制御] ダイアログ ボックスで、アプリケーションを実行する前に続行するように求められます。

アプリケーションを別のユーザーとして実行するには、コマンド プロンプトで runas コマンドを使用する必要があります。

大事な runas では、バックアップ オペレーターや管理者などの特権を持つ標準ユーザーであるかどうかに関係なく、昇格されたアクセス トークンを使用してアプリケーションを起動する機能は提供されないことに注意してください。 runas コマンドを使用すると、ユーザーは異なる資格情報でアプリケーションを起動できるようになります。 別のアカウントでアプリケーションを起動するために使用する最善の方法は、サービスを使用してプログラムでアクションを実行し、コンポーネントを別のユーザーとして実行するユーザーに依存しないことです。 プログラムで runas コマンドをプログラムで使用する場合は、管理者特権のプロセスを起動するためのものではないことを確認します。

アプリケーションでアプリケーションの一部を別のユーザー アカウントで実行する必要がある場合は、コマンド プロンプト オプションを指定した runas コマンドが公開されていることを確認します。 次の表では、 runas コマンドで使用できるパラメーターについて詳しく説明します。

Runas パラメーター

パラメーター	説明
/noprofile	ユーザーのプロファイルを読み込まないように指定します。 これにより、アプリケーションの読み込み速度が速くなりますが、一部のアプリケーションが誤動作する可能性があります。
/プロファイル	ユーザーのプロファイルを読み込む必要があることを指定します。 これが既定の設定です。
/Env	ユーザーの ではなく、現在の環境を使用します。
/netonly	指定された資格情報がリモート アクセス専用の場合は、このパラメーターを使用します。
/savecred	ユーザーが以前に保存した資格情報を使用します。 このオプションは Windows XP、Home Edition では使用できません。このオプションは無視されます。
/smartcard	指定する資格情報がスマート カードからの資格情報である場合は、このパラメーターを使用します。
/user	ユーザーのユーザー名。 ユーザー名は、USER\DOMAIN または USER@DOMAIN の形式で指定する必要があります。
/showtrustlevels	/trustlevel パラメーターの引数として使用できる trustlevel を表示します。
/trustlevel	/showtrustlevels で列挙されたレベルの 1 つ。
プログラム	実行可能ファイルのコマンド ライン。

例:

runas /noprofile /user:mymachine\Denise cmd

注:

• プロンプトが表示された場合にのみ、ユーザーのパスワードを入力します。
• /profile パラメーターは /netonly パラメーターと互換性がありません。
• /savecred パラメーターは /smartcard パラメーターと互換性がありません。

コンソール アプリケーションの要件

コンソール アプリケーションは、別のユーザー インターフェイスではなく、コンソール ウィンドウにその出力を表示します。 アプリケーションを実行するために完全な管理者アクセス トークンが必要な場合は、そのアプリケーションを管理者特権のコンソール ウィンドウから起動する必要があります。

コンソール アプリケーションでは、次の操作を行う必要があります。

アプリケーションを "asInvoker" としてマークする

これを行うには、RequestedExecutionLevel == asInvoker を設定したアプリケーションのマニフェストを作成します。 このセットアップにより、管理者特権以外のコンテキストからの呼び出し元はプロセスを作成できます。これにより、手順 2 に進むことができます。

アプリケーションが完全な管理者アクセス トークンなしで実行されている場合にエラー メッセージを提供する

アプリケーションが管理者特権以外のコンソールで起動された場合、アプリケーションは簡単なメッセージを表示して終了する必要があります。 推奨されるメッセージは次のとおりです。

"アクセスが拒否されました。 選択したオプションを使用するには、管理者権限が必要です。 管理者コマンド プロンプトを使用して、これらのタスクを完了します。

また、スクリプト作成を容易にするために、起動に失敗したときにERROR_ELEVATION_REQUIREDエラー コードも返す必要があります。

スクリプトの要件

スクリプトは、定義済みの順序で実行されるアプリケーションのグループと見なされ、一方が他の順序でチャネル化された結果と見なされる場合があります。

スクリプトを UAC に準拠させるには、スクリプトのロジックを調べ、"テスト" を追加して、スクリプトでアクションを実行する前に、ユーザー (またはスクリプトを実行しているユーザー) にそのタスクを実行するための十分な権限があることを確認します。

一括操作の要件

アプリケーションによって実行されるタスクが複数のオブジェクトに対するアクションで構成されていて、その一部がユーザーの管理アクセス トークンを必要とする可能性がある場合は、初めて必要なときに昇格プロンプトを表示します。 ユーザーが昇格を承認した場合は、残りのタスクを実行します。 それ以外の場合は、バッチ操作を終了します。 この動作は、現在の複数選択/コピー/削除操作と一致します。

管理者の識別に役立つ API

• IsUserAnAdmin()
• GetTokenInformation()

管理者と標準ユーザーの間で本質的に異なるレジストリ/ハンドル アクセス許可

• MAXIMUM_ALLOWED
• KEY_WRITE
• DELETE (レジストリ キーに適用される場合)
• その他の HKLM に似たキーワード (XP でMAXIMUM_ALLOWEDで開きます):
• SHELLKEY_HKLM_EXPLORER
• SHELLKEY_HKLM_SHELL

HKLM レジストリ値と仮想化に再転送されるその他の API が適用されます

• WritePrivateProfileString(,,,"system.ini");
• CheckSectionAccess("system.ini",...);

4. UAC 互換性のためにアプリケーションのユーザー インターフェイスを再設計する

このセクションのガイドラインを使用して、UAC 互換性のためにアプリケーションのユーザー インターフェイスを開発します。 アプリケーションの開発でこれらのガイドラインに厳密に従うと、Windows Vista でアプリケーションの一貫性のある予測可能なユーザー エクスペリエンスが確保されます。

• UAC が Windows ユーザー エクスペリエンスに与える影響
• UAC ユーザー エクスペリエンスの目標
• 昇格プロンプト
• ユーザー エクスペリエンス プロセス フロー
• 標高エントリ ポイント
• ユーザー インターフェイスの実装
• アプリケーションのユーザー インターフェイスにシールド アイコンを追加するタイミング
• 管理者専用アプリケーションの主な決定事項

大事な アプリケーションのユーザー インターフェイスを処理するだけでは、UAC 互換性の要件は満たされません。 アプリケーションのコア機能は、Windows Vista 標準ユーザー モデルの要件に準拠している必要があります。 これらの要件については、前の手順「手順 3: UAC 互換性のためにアプリケーションの機能を再設計する」で詳しく説明しました。

UAC が Windows ユーザー エクスペリエンスに与える影響

ユーザー エクスペリエンスに対する最大かつ最も直接的な影響は、管理者によって認識されます。 管理者ユーザーは、管理タスクを実行するためのアクセス許可を提供する必要があります。 これに加えて、標準ユーザーは、現在ログインしているセッション内の特定の管理タスクに対するアクセス許可を管理者に付与するように依頼できるようになります。

UAC ユーザー エクスペリエンスの目標

UAC ユーザー エクスペリエンスの全体的な目標は、ユーザー エクスペリエンスの予測可能性を提供することです。

• 管理者の場合は、管理者特権のタスクを実行するためのアクセス許可を付与する必要がある場合、ユーザーは常に把握していることを意味します。

これは、ユーザーが管理者が必要とする変更を行えるように、ユーザー自身の管理者アクセス トークンを要求する行為です。

• 標準ユーザーの場合、これは、次の場合に認識されることを意味します。
  • 管理タスクに対して管理者の承認 (ホーム環境とアンマネージド環境) を提供する必要があります
  • または、 がタスク (昇格が明示的に禁止されているマネージド環境) を完了できず、ヘルプ デスクに問い合わせる必要がある場合

設計目標

UAC の設計目標を次の一覧に示します。

不要な昇格を排除する

ユーザーは、管理者アクセス トークンを必要とするタスクを実行するためにのみ昇格する必要があります。 他のすべてのタスクは、昇格の必要をなくすために設計する必要があります。 Windows Vista 以前のソフトウェアでは、HKLM または HKCR レジストリ セクションまたは Program Files または Windows システム フォルダーに書き込むことで、管理者アクセス トークンが不必要に必要になることがよくあります。

予測可能

管理者は、昇格が必要なタスクを把握する必要があります。 昇格の必要性を正確に予測できない場合は、管理タスクの同意を得る可能性が高くなります。 標準ユーザーは、管理者が実行する必要があるタスク、または管理対象環境でまったく実行できないタスクを把握する必要があります。

最小限の労力が必要

より高い特権アクセス トークンを必要とするタスクは、単一の昇格を必要とするように設計する必要があります。 複数の昇格を必要とするタスクは、すぐに面倒になります。

標準ユーザーに戻す

より高いレベルのアクセス トークンを必要とするタスクが完了したら、プログラムは標準のユーザー状態に戻す必要があります。

昇格プロンプト

昇格プロンプトは、既存の Windows ユーザー インターフェイスに基づいて構築されます。 昇格プロンプトには、昇格を要求する実行可能ファイルに関するコンテキスト情報が表示されます。コンテキストは、アプリケーションが Authenticode 署名されているかどうかによって異なります。 昇格プロンプトは、同意プロンプトと資格情報プロンプトの 2 つのバリエーションで表示されます。

同意プロンプト

管理者が管理タスクを実行しようとすると、同意プロンプトが管理承認モードで管理者に表示されます。 これは、管理承認モードの管理者向けの既定のユーザー エクスペリエンスであり、ローカルセキュリティ ポリシー マネージャー スナップイン (secpol.msc) と グループ ポリシーで構成できます。

次の図は、ユーザー アカウント制御の同意プロンプトの例です。

図 4: ユーザー アカウント制御の同意プロンプト

資格情報プロンプト

管理タスクを実行しようとすると、資格情報プロンプトが標準ユーザーに表示されます。 これは標準ユーザーの既定のユーザー エクスペリエンスであり、ローカルセキュリティ ポリシー マネージャー スナップイン (secpol.msc) と グループ ポリシーで構成できます。

次の図は、ユーザー アカウント制御資格情報プロンプトの例です。

図 5: ユーザー アカウント制御の資格情報プロンプト

Windows Vista の既定の昇格プロンプト同意ポリシー

次の表は、Windows Vista の各ユーザー アカウントの種類の既定のプロンプト スタイルの概要を示しています。

既定の昇格プロンプトの動作

ユーザー アカウントの種類	昇格プロンプトの設定
標準ユーザー	資格情報の要求
管理承認モードの管理者アカウント	同意を要求する

ユーザー エクスペリエンス プロセス フロー

UAC ユーザー エクスペリエンス プロセス フローは、次の 3 つの異なるコンポーネントで構成されます。

1. 昇格エントリ ポイント (UAC シールド アイコンを表示するコントロールやリンクなど)。
2. 昇格プロンプト (同意または管理者資格情報の要求)。
3. 昇格されたプロセス。

次のワークフロー例は、上記のコンポーネントがどのように関連しているかをまとめたものです。

1. 管理承認モードの管理者は、Windows Vista コンピューターにログオンします。
2. その後、ユーザーはコンピューターの別の管理者ユーザーを追加することにします。
3. ユーザーが [スタート] をクリックし、[コントロール パネル] をクリックし、[セキュリティ] セクションの [Windows ファイアウォール経由でプログラムを許可する] というタイトルのリンクをクリックします。このリンクは、シールド アイコンと共にインラインで表示されます。
4. ユーザーに承認を求める同意プロンプトが表示されます。
5. ユーザーが [ 続行 ] をクリックすると、管理者特権のプロセスが作成されます。
6. [Windows ファイアウォールの設定] では、ユーザーは Windows ファイアウォール設定を変更し、[ OK] をクリックして、管理者特権のプロセスを終了します。
7. ユーザーは引き続き標準ユーザーとしてコンピューター上で作業します。

メモ 昇格エントリ ポイントは状態を記憶しません (シールドされた場所やタスクから戻る場合など)。また、エントリ ポイントは昇格が発生したことを覚えていません。 その結果、ユーザーはタスク/リンク/ボタンをもう一度入力するために再昇格する必要があります。

標高エントリ ポイント

エントリ ポイントの場合、シールド アイコンは特定のコントロール (ボタン、コマンド リンク、ハイパーリンクなど) にアタッチされ、次の即時ステップで昇格が必要であることを示します。

シールド アイコン

シールド アイコンは、UAC 標高ポイントの主要なユーザー インターフェイス装飾です。 このアイコンは、Windows Vista と以前のバージョンの Windows のセキュリティ関連のアクティビティを示し、この関係は Windows Vista で継続されます。

次の図は、シールド アイコンの例です。

図 6: 盾アイコン

シールド アイコンは、UAC ユーザー エクスペリエンスの 3 つのコンポーネントすべてに重要な役割を果たしています。

Windows エクスプローラーを使用してシステムを表示すると、起動時に管理者アクセス トークンを要求するようにマークされたアプリケーションは、そのアイコンの上にシールド グリフで自動的に装飾されます。 これにより、起動時に昇格を要求するアプリケーションをユーザーが認識できるようになります。

シールド アイコンのプロパティ:

• UAC ユーザー エクスペリエンス全体で一貫した外観。
• 表示状態 (アクティブ、ホバー、無効など) は反映されません。
• 状態を記憶しません。

シールド アイコンでマークされたエントリ ポイントがユーザー エクスペリエンス内で使用できる一貫したコントロール スタイルは 3 つあります。

• UAC ボタン
• UAC ハイパーリンク
• UAC コマンド リンク

これらのスタイルは、ウィザード、プロパティ ページ、コントロール パネル フレームワーク、エクスプローラーなど、これらのユーザー インターフェイス要素が表示されるすべてのシナリオに適用されます。各スタイルは、ユーザーが UAC ユーザー インターフェイス コントロールをクリックした直後に昇格プロンプトが表示されることを意味します。

4 番目の UAC ユーザー インターフェイス エントリ ポイントである UAC アイコン オーバーレイについても、このセクションで説明します。 実行可能ファイルがアイコン オーバーレイを受け取るかどうかは、アプリケーション開発者によって制御されません。 Windows Vista は、requestedExecutionLevel が requireAdministrator に設定されている実行可能ファイルのアプリケーションのアイコンにシールド アイコンをオーバーレイします。

UAC シールド ボタン

UAC シールド ボタンは、ユーザー インターフェイス ボタンで使用する必要があります。このボタンを押すと、ユーザーに承認または資格情報の入力を求める昇格プロンプトが必要になります。

UAC シールド ボタンは、コミット ボタン (ウィザードの [次へ ] など) として、または追加の設定ユーザー インターフェイスを表示するためのボタン (プロパティ ダイアログの [設定 の変更] など) として使用できます。

UAC シールド ボタンは、次の 2 つのユーザー インターフェイス コンポーネントで構成されます。

• 盾アイコン
• テキスト ラベル

UAC シールド ボタンは、開発者が通常のボタンの代わりに使用できるように、パッケージ化されています。 UAC ボタンでは、テキスト ラベルの左側または右側にシールド アイコンをレンダリングすることもできます。 さらに、開発者は、UAC ボタンが表示されている間にシールド アイコンを非表示または表示するオプションがあります。

次のスクリーンショットは、UAC シールド ボタンの例です。

図 7: UAC シールド ボタン

UAC ハイパーリンク

UAC ハイパーリンクは、ユーザー インターフェイスのハイパーリンクで使用する必要があります。このハイパーリンクをクリックすると、ユーザーに承認または資格情報の入力を求める昇格プロンプトが必要になります。

UAC ハイパーリンクは、次のコンポーネントで構成されます。

• 盾アイコン
• ハイパーリンク コントロール

UAC ハイパーリンクは、開発者が使用するためのシールド アイコンと共にパッケージ化されていません。 開発者は、シールド アイコン リソースを取得し、ハイパーリンクの横にレンダリングする必要があります。

次のスクリーンショットは、UAC ハイパーリンクの例です。

図 8: UAC ハイパーリンク

UAC コマンド リンク

UAC コマンド リンクは、ユーザー インターフェイス ボタンで使用する必要があります。このボタンをクリックすると、ユーザーに承認または資格情報の入力を求める昇格プロンプトが必要になります。

UAC コマンド リンクは、コミット ボタンとしてのみ使用する必要があります (ダイアログ ボックスの "このオプションを実行する" など)。

UAC コマンド リンクは、次のコンポーネントで構成されます。

• 盾アイコン
• 標準コマンド リンク コンポーネント
• リンク テキスト
• テキストをメモする

UAC コマンド リンクは、開発者が通常のコマンド リンクの代わりに UAC コマンド リンクを使用できる方法でパッケージ化されています。 UAC コマンド リンクでは、コマンド リンクの左側または右側にシールド アイコンをレンダリングできます。

UAC コマンド リンクの例を次に示します。

図 9: UAC コマンド リンク

アイコン オーバーレイ

Windows Vista では、実行可能ファイルを起動するために昇格が必要な場合は、実行可能ファイルのアイコンにシールド アイコンを付けてこの事実を示す "スタンプ" を付ける必要があります。 実行可能ファイルのアプリケーション マニフェストでは、実行可能ファイルを完全な管理アクセス トークンを必要とするように指定するには、"requireAdministrator" とマークする必要があります。 シールド アイコン オーバーレイは、インストーラー検出ヒューリスティックに従って昇格が必要と見なされる実行可能ファイルにも自動的に配置されます。 たとえば、実行可能ファイルにアプリケーション マニフェストが埋め込まれていない場合でも、setup.exeという名前のファイルは自動的にシールド アイコン オーバーレイを受け取ります。

次の図は、UAC アイコン オーバーレイの例です。

図 10: UAC アイコン オーバーレイ

メモ 実行可能ファイルを使用してアプリケーション マニフェストを作成および埋め込む方法のガイダンスについては、このドキュメントの「アプリケーション マニフェストをアプリケーションに作成して埋め込む」セクションを参照してください。

ユーザー インターフェイスの実装

シールド アイコンの実装と API

このセクションでは、開発者が新しい管理アプリケーション機能を移行または実装する場合に使用できるアイコンと API に関する予備情報を提供します。

シールド アイコンの実装と API

アイコン	API
Shield	ユーザー リソース: IDI_SHIELD
Button	Button_SetElevationRequired(hwndButton)
Syslink/Hyperlink	syslink の横のレイアウト IDI_SHIELD
コマンド リンク	IDI_SHIELDを読み込み、コマンド リンク アイコンとして設定する
コンテキスト メニュー	静的コマンドの DefCM でのアイコンのサポート

ユーザー インターフェイスにシールド アイコンを追加する

小さなアイコンを追加します。

#include <shellapi.h>
SHSTOCKICONINFO sii;
sii.cbSize = sizeof(sii);
SHGetStockIconInfo(SIID_SHIELD, SHGSI_ICON | SHGSI_SMALLICON, &sii);
hiconShield  = sii.hIcon;

大きなアイコンを追加します。

SHSTOCKICONINFO sii;
sii.cbSize = sizeof(sii);
SHGetStockIconInfo(SIID_SHIELD, SHGSI_ICON | SHGSI_LARGEICON, &sii);
hiconShield  = sii.hIcon;

カスタム サイズのアイコンを追加します。

SHSTOCKICONINFO sii;
sii.cbSize = sizeof(sii);
SHGetStockIconInfo(SIID_SHIELD, SHGSI_ICONLOCATION, &sii);
hiconShield  = ExtractIconEx(sii. ...);

メモ 一般に、シールド アイコンをユーザー インターフェイスに直接追加しないでください。 コントロール内のシールド アイコンを埋め込む方法のいずれかを使用することをお勧めします。 さらに、ユーザー インターフェイスにシールド アイコンを追加するだけでは、UAC の互換性は保証されません。 また、アプリケーションのユーザー エクスペリエンス全体を処理する必要があります (要求されたExecutionLevel を追加し、標準的なユーザーバグを修正し、ユーザー インターフェイスがユーザー フレンドリで UAC 互換であることを確認します)。

ボタンにシールド アイコンを追加する

標準ボタン コントロール (PUSHBUTTON、DEFPUSHBUTTON) が強化され、BS_ICONまたはBS_BITMAPスタイルを設定しなくても、表示されるテキストと共にアイコンを追加できます。

シールド アイコンを表示するには、次のマクロ (commctrl.h で定義) を呼び出します。

Button_SetElevationRequiredState(hwndButton, fRequired);

注 hwndButton はボタンの HWND です。fRequired は、UAC シールド アイコンを表示する (TRUE) か非表示 (FALSE) かを決定します。

Windows インストーラー ボタンにシールド アイコンを追加する

内部テーブルのサポートを使用して作成された Windows インストーラー ダイアログでは、コントロールに ElevationShield 属性を設定することで、ユーザー インターフェイス ダイアログ シーケンスの最後のボタンにシールドを追加できます。

ウィザードの [次へ] ボタンにシールド アイコンを追加する

大事な UAC シールド アイコンの表示 [次へ] ボタンは、AeroWizards (PSH_AEROWIZARD) でのみサポートされています。

AeroWizard の特定のページの [次へ] ボタンにシールド アイコンを表示するには、次のコードを使用します。

case WM_NOTIFY:
    if (reinterpret_cast<NMHDR*>(lParam)->code == PSN_SETACTIVE)
    {
        // Show next button
        //
        // Note new wParam flag -- when PSWIZBF_ELEVATIONREQUIRED flag
        // is specified, it indicates that the next page will require
        // elevation, so if the next button is being shown, show it as
        // a shield button.

        SendMessage(GetParent(hwndDlg), 
                    PSM_SETWIZBUTTONS, 
                    PSWIZBF_ELEVATIONREQUIRED, 
                    PSWIZBF_NEXT);

        // return 0 to accept the activation
        SetWindowLong(hwndDlg, DWLP_MSGRESULT, 0); 
    }
    break;

タスク ダイアログ ボタンにシールド アイコンを追加する

注意 タスク ダイアログ ボタンに UAC シールド アイコンは必要ありません。 タスク ダイアログ ボタンの "押す" アクションは、タスク ダイアログをコミット/キャンセルして閉じる必要があります。 このようなボタンがユーザーに昇格プロンプトを表示するのは奇妙です。

モーダル ダイアログの昇格

モーダル ダイアログを表す COM オブジェクトを昇格するには、昇格モニカーを使用します。

タスク:

• ダイアログ ボックスを COM オブジェクトに移動します。
• ShowDialog() メソッドを公開します。
• API CreateElevatedComObject() を使用して COM オブジェクトを作成し、ShowDialog() を呼び出します。

この API は、昇格プロセスを実行した後、管理者として COM オブジェクトのインスタンスを実行します。

メモ 呼び出しがより複雑なこの API のバージョンを使用できます。 簡略化されたバージョンは、新しいバージョンの Windows Vista で使用できるようになります。

ユーザーの教育と支援のガイドライン

ユーザー インターフェイスが再考慮され、ボタンの後ろに配置された場合、ISV はボタン名の変更が保証されているかどうかを評価する必要があります。 Microsoft では、昇格タスクのボタン ラベルとして Advanced を使用することを強くお勧めします。 代わりに、[ 設定の変更] やボタンの背後にあるものを示す用語など、わかりやすいラベルを使用します。

管理者専用ユーザー インターフェイスのガイドライン

アプリケーションが常に管理者によって起動される場合は、アプリケーションのユーザー インターフェイス内にシールドを追加する必要はありません。 これは、アプリケーションが昇格され、それが行うすべてのものが昇格されるため、それ以上の昇格は必要ないためです。

メモ 管理者専用ユーザー エクスペリエンスで他の管理者ユーザー インターフェイスへのリンクがある場合、ユーザー インターフェイスは、そのターゲットを昇格して起動します。 そのため、管理のみを行うアプリケーションにシールドを配置する必要はありません。

アプリケーションのユーザー インターフェイスにシールド アイコンを追加するタイミング

管理選択アプリケーション

昇格されたプロセスまたは COM オブジェクト

初期アプリケーションは、昇格を必要とせずに起動します。 管理アクセス トークンを必要とするユーザー インターフェイス内の項目は、識別としてシールド アイコンで装飾されます。 この装飾は、その機能を使用するには管理者の承認が必要であることをユーザーに示します。 これらのボタンのいずれかが選択されていることをアプリケーションが検出すると、次の 2 つの選択肢があります。

• アプリケーションは、ShellExeucute() を使用して管理タスクを実行する 2 つ目のプログラムを起動します。 この 2 番目のプログラムは、requireAdministrator の requestedExecutionLevel でマークされるため、ユーザーは承認を求められます。 この 2 番目のプログラムは、完全な管理アクセス トークンで実行され、目的のタスクを実行できます。
• アプリケーションは、CreateElevatedComObject() を使用して COM オブジェクトを起動します。 この API は、承認後に完全な管理アクセス トークンを使用して COM オブジェクトを起動し、この COM オブジェクトは目的のタスクを実行できます。

この方法は、最も豊富なユーザー エクスペリエンスを提供し、管理機能を処理する推奨される方法です。

昇格されたプロセスまたは COM オブジェクトの要件の詳細を次に示します。

• コントロール パネルは、シールドの装飾とその必要なアーキテクチャを実装する必要があります。
• 開発者は、シールドがユーザー インターフェイス上のどこに配置するかを決定する必要があります。
• 開発者は、ビジネス ロジックをユーザー インターフェイス オブジェクトから COM オブジェクトに分離するためにアーキテクチャ作業を行う必要があります。
• シールド アイコンの OnClick イベントが検出された場合、開発者は UAC 昇格プロセスを呼び出す必要があります。

次の一覧では、昇格されたプロセスまたは COM オブジェクトを適切に設計する利点について詳しく説明します。

• これは、両方のユーザーの種類に最適な全体的なユーザー エクスペリエンスです。 ユーザー インターフェイスが起動し、すべてのユーザーが表示でき、そのユーザー インターフェイスのすべての UAC 機能に全員がアクセスできるようになります。 管理者タスクが必要な場合にのみ、ユーザーは昇格を試みてタスクを完了します。
• この作業を今すぐ行うことで、UAC 準拠の完全な前進が実現します。
• ユーザー インターフェイスと COM の分離は、アーキテクチャ上の優れた方法です。

シールド アイコンをクリックすると、アプリケーションは管理者特権のプログラムまたは管理者特権の COM オブジェクトを起動してタスクを実行します。

管理者専用アプリケーション

この場合、アプリケーションの初回起動には管理者の承認が必要です。 このメソッドは、"起動前にプロンプト" と呼ばれます。 起動すると、アプリケーションは完全な管理アクセス トークンを使用して実行されるため、必要な管理タスクを実行できます。 このメソッドは、開発者にとって最も作業の少ない方法です。 アプリケーションのマニフェストは、requireAdministrator の requestedExecutionLevel でマークされます。

大事な これは開発者にとって最小限の作業量を必要としますが、Windows Vista の他の管理アプリケーションと同様に、管理者はこのアプリケーションを使用するために昇格する必要があり、標準ユーザーはアプリケーションを使用できないことに注意してください。

管理者専用アプリケーションの要件の詳細を次に示します。

• アプリケーション マニフェストには、requireAdministrator に設定された requestedExecutionLevel マーキング セットが含まれている必要があります。
• ユーザーは、Windows が完全な管理アクセス トークンを使用してアプリケーションを起動する前に、管理者の承認を求められます。

次の一覧では、管理者専用アプリケーションを適切に設計する利点について詳しく説明します。

• セットアップ アプリケーションが管理アプリケーションである場合、オペレーティング システムは "推測" する必要はありません。
• 標準ユーザーには、操作が管理操作であるというヒントが自動的に表示されます。 たとえば、requireAdministrator とマークされたアプリケーションのアイコンが表示された場合、アイコンにはアイコンにシールドが埋め込まれています。
• Windows Vista では、アプリケーションを requireAdministrator としてマークすると、起動されると、完全な管理者アクセス トークンで実行されます。 ユーザーは、アプリケーションを実行するために昇格する必要があります (管理承認モードの管理者として、または管理者として実行を使用します)。

メモ アプリケーションをマークする requireAdministrator は、アプリケーションをサイレントモードで昇格させることはありません。 ユーザーは、アプリケーションを起動するために昇格の同意を与える必要があります。 Windows Vista でアプリケーションをマークしてサイレント モードで昇格させる方法はありません。

次の一覧では、管理者専用アプリケーションの設計に関する考慮事項の詳細を示します。

• このユーザー エクスペリエンスは、ユーザー インターフェイスが表示される前に、すべてのユーザーに昇格プロンプト (資格情報プロンプトまたは同意プロンプト) が表示されることを意味します。 また、管理者の資格情報を使用して認証するまで、現在の設定を表示できるユーザーはいないことを意味します
• セットアップ アプリケーションで requireAdministrator をマークする場合は、セットアップを実行しているユーザーが、アプリケーションを使用する可能性があるユーザーとは異なっていることを認識する必要があります。 そのため、管理セットアップ中に、HKEY_CURRENT_USER (HKCU) やその他のユーザーごとの設定 (ユーザー プロファイルへの書き込みなど) を変更しないでください。

大事な 管理アプリケーションを実行しているユーザーが、コンピューター上の通常のユーザーとは異なると想定する必要があります。

管理者アクセス トークンを必要とする実行可能ファイルは、シールド アイコン オーバーレイでマークされます。

混合アプリケーション

混合アプリケーションは、システムのすべてのユーザー (標準ユーザー、管理承認モードの管理者、バックアップオペレーターなどの間のユーザー) が実行できるアプリケーションです。 これは、"起動前のプロンプト" アプリケーションでもあります。 アプリケーションは呼び出し側のアクセス トークンを使用して実行され、標準ユーザーに対して通常どおりに起動されます (昇格プロンプトは表示されません)。その後、プログラムは実行時にその動作を変更して、取得した管理アクセス トークンに基づいてユーザーが使用できない機能を無効にする必要があります。

混合アプリケーションには、起動後に追加の管理特権を取得する機能がありません。したがって、前述の昇格されたプロセスまたは COM オブジェクト メソッドの柔軟性は提供されません。 これは、標準ユーザーよりも高いアクセス トークンを必要とするが、完全な管理者未満のアプリケーションに最も役立ちます。

たとえば、Microsoft 管理コンソール (MMC) は highestAvailable とマークされます。 真の標準ユーザーが MMC を実行すると、MMC は昇格の試行やプロンプトなしで標準ユーザー アプリケーションとして起動します。 ユーザーが管理承認モードの管理者やバックアップ オペレーターなどの "分割トークン" ユーザーである場合、オペレーティング システムは、ユーザーの "最も高い" 使用可能な特権で MMC を起動することに同意するように求められます。 バックアップ オペレーター特権を持つ標準ユーザーの場合、昇格後、MMC は標準ユーザー + バックアップ オペレーターで起動されますが、それ以上は起動されません。 管理者が MMC を起動した場合、昇格後、MMC は完全な管理者アプリケーションとして実行されます。

混合アプリケーションを適切に設計する利点は、一部の機能が無効になっている可能性がある場合でも、アプリケーションをシステムのすべてのユーザーが使用できるという点です。

次の一覧では、混合アプリケーションの設計に関する考慮事項の詳細を示します。

• 開発者は、ユーザーが使用できる管理 Windows 特権とユーザー権限に基づいて、アプリケーションの動作を動的に変更する必要があります。
• 標準ユーザーは、ユーザー・インターフェース上の管理レベルの機能に対して作用することができなくなります。 プログラムを実行すると、プロンプトの昇格が発生する可能性はありません (管理者は、ユーザー インターフェイスを開く前に昇格する必要があります)。

メモ 前の箇条書きの回避策が 1 つあります。 管理者は、標準ユーザーのコンピューターで管理者特権のコマンド プロンプトを起動し、コマンド プロンプトからアプリケーションを実行できます。 たとえば、コマンド プロンプトを右クリックし、[ 管理者として実行] を選択し、コマンド プロンプトに「applicationname.exe」と入力します。

ユーザー エクスペリエンスは、標準ユーザーと管理者の間で管理承認モードで分岐されます。

混合アプリケーションの例: バックアップ アプリケーション

アプリケーションは、Backup Operators グループのメンバーによって起動できます。 その後、プログラムは、ユーザーが使用できる最高レベルの管理 Windows 特権とユーザー権限が、プログラムの操作に十分であることを確認します。 プログラムの起動動作の詳細については、このドキュメントの「アプリケーション マニフェストのマーキングとアプリケーション起動の動作」セクションを参照してください。

Administrator-Only アプリケーションの設計に関する主な決定事項

バックエンド ビジネス オブジェクト

このセクションでは、開発者が最適なユーザー エクスペリエンスを提供する管理アプリケーションを開発するときに選択できる 3 つのモデルの概要について説明します。

• 管理 Broker モデル
• Back-End サービス モデル
• 管理 COM オブジェクト モデル

管理 ブローカー モデル

管理 Broker モデルでは、アプリケーションは 2 つの独立した実行可能ファイル (標準ユーザー実行可能ファイルと管理実行可能ファイル) に分割されます。 開発者は、アプリケーション マニフェストを使用して、標準ユーザー プログラムを asInvoker の requestedExecutionLevel でマークし、管理プログラムに requireAdministrator の requestedExecutionLevel を付けます。 ユーザーが最初に標準ユーザー プログラムを起動します。 ユーザーは、標準ユーザー プログラムが完全な管理者アクセス トークンを必要とすることを認識する操作を実行しようとすると、ShellExecute() を実行し、管理プログラムを起動します。 Windows ShellExecute() API は、マニフェストを確認し、ユーザーの完全な管理アクセス トークンを使用してアプリケーションを実行する前に、ユーザーに承認を要求します。 その後、管理プログラムは管理タスクを実行できます。

メモ 管理実行可能プログラムは、共有メモリ、ローカル RPC、または名前付きパイプを使用して、標準ユーザー実行可能ファイルとのプロセス間通信を有効にすることができます。 管理プログラムが標準ユーザー実行可能ファイルとの通信を有効にする場合、開発者は適切なセキュリティ プラクティスを使用して、下位特権プログラムからのすべての入力を検証する必要があります。

メモ 2 つ目のプログラムが起動すると、2 つのプログラム間に通信チャネルはありません

管理ブローカー モデルでは、次の一覧の詳細が使用されます。

• ウィザード - ハードウェア ウィザードで、必要なドライバーがコンピューターにインストールされていないか、企業の承認された場所に配置されていないことが認識されると、ドライバーをコンピューター ストアに移動できる管理者特権のアプリケーションが必要になります。
• Setup.exeを呼び出すAutorun.exe— ゲーム CD を初めて使用する場合、autorun.exeから必要な操作はアプリケーションを設定することです。 CD を挿入する 2 回目の既定の操作は、ゲームをプレイすることです。

管理者ブローカー モデルを使用する利点は、開発者に実装するのが最も簡単なメカニズムである可能性があります。

次の一覧では、管理 Broker モデルの使用に関するいくつかの欠点について詳しく説明します。

• アプリケーションからアプリケーションへの移行は、ユーザーに混乱を招く可能性があります。 新しいアプリケーションがモニターに "ポップアップ" している理由をユーザーが把握し続けるのは難しい場合があります。
• さらに、状態はこれら 2 つのアプリケーション間で渡すのが困難です。 たとえば、標準のユーザー コントロール パネル (CPL) とその管理者の間で状態を渡すために、同じ CPL に管理および非管理機能を持たせるようにするために、これを使用しません。 標準ユーザー CPL は、その状態をどこかに格納する必要があります。
• 多くの場合、2 つのプログラム間で機能を分割すると、レプリケートされたコードが多数存在します。

管理ブローカー モデルを実装するには、2 つのプログラム (1 つの標準ユーザーと 1 つの管理プログラム) を作成し、適切なマニフェスト requestedExecutionLevel でマークし、ShellExecute() を使用して標準ユーザー プログラムから管理プログラムを起動します。

Back-End サービス モデル

バックエンド サービス モデルでは、アプリケーションは再び 2 つの独立した実行可能ファイルに分割されます。これは、ユーザーにユーザー インターフェイスを提供する標準のユーザー実行可能ファイルと、システム上で実行されているバックエンド サービスです。 Microsoft Remote Procedure Call (RPC) は、2 つの間の通信に使用されます。 フロントエンド アプリケーションは、asInvoker の requestedExecutionLevel でマークされ、バックエンド サービスは SYSTEM として実行されています。 アプリケーションとバックエンド サービス間の通信は、RPC を使用して行われます。

バックエンド サービス モデルの 1 つの用途は、ウイルス対策プログラムやスパイウェア対策など、システムに影響を与える可能性があるプログラムを制御することです。 フロントエンド アプリケーションは、ログオンしたユーザーがサービスの側面を制御する手段を提供します。

バックエンド サービス モデルを使用する主な利点は、昇格のプロンプトが必要ない点です。

次の一覧では、バックエンド サービス モデルの使用に関するいくつかの欠点について詳しく説明します。

• サービスでは、フロントエンド アプリケーションから指示できるアクティビティの種類を制限する必要があります。 たとえば、ウイルス対策サービスを使用すると、標準ユーザーはシステムのスキャンを開始できますが、リアルタイムのウイルスチェックを無効にすることはできません。
• 不要なサービスをシステムに追加すると、システム全体に影響を与える可能性があります。 サービスが Windows Vista の実装に本当に必要であり、サービスが適切に設計されていることを確認します。

バックエンド サービス モデルを実装するには、標準のユーザー フロントエンド アプリケーションとバックエンド サービスを作成します。 製品のインストール時にシステムにサービスをインストールします。

管理 COM オブジェクト モデル

このモデルはここに含まれていますが、このドキュメントで前に詳しく説明しました。 管理者 COM オブジェクト モデルを使用すると、アプリケーションまたはコントロール パネル内から動的な管理昇格で特定の操作を実行できます。

管理者 COM オブジェクト モデルを使用する主な利点は、ユーザーに最適なユーザー エクスペリエンスを提供することです。

次の一覧では、管理者 COM オブジェクト モデルの使用に関するいくつかの欠点について詳しく説明します。

• 各アプリケーション機能を評価して管理者の機能をテストする必要があり、その機能をバックエンド COM オブジェクトによって提供する必要がある場合は、開発者にとって最も多くの作業が必要です。
• ユーザーは昇格の承認を提供する必要があります。
• 標準ユーザー アプリケーションと管理バックエンド COM オブジェクトの結果の "ユニット" は "drivable" になり、UIPI やその他の分離メカニズムによって保護されません。

管理 COM オブジェクト モデルを実装するには、標準のユーザー フロントエンド アプリケーションを作成し、管理者特権でバックエンド COM オブジェクトを起動して管理タスクを実行します。

5. アプリケーションのインストーラーを再設計する

次のベスト プラクティスは、Windows Vista または UAC 環境で適切に動作するアプリケーションのインストールに関するものです。 この一覧がすべてではありません。 UAC の要件など、Windows Vista のロゴ要件の詳細については、Windows Vista ロゴのドキュメントと Windows Vista ロゴ ガイドライン ドキュメントの最新ドラフトの詳細なバージョンを参照してください。

アプリケーションを再設計するときに、これらの要件を使用します。

セットアップ パッケージには Windows インストーラー 4.0 を使用します。

次の要件の多くは、Windows インストーラー エンジンに既に統合されています。 セットアップ パッケージに Windows インストーラーを使用すると、Windows Vista のインストール要件に従うのに役立ちます。

バージョン管理されたファイルを使用し、インストール中にファイルをダウングレードしないでください。

ファイルのバージョン管理により、セットアップが完了したときに最終的なインストール状態が正しいことを確認できます。 ファイル バージョンがない場合は、さまざまなインストール シナリオでインストールが適切に動作するように、いくつかの特別な処理が必要になります。 また、バージョン管理されたファイルをインストールする場合は、バージョン (特に共有ファイル) をダウングレードしないでください。 バージョンのダウングレードはアプリケーションに適していますが、他のアプリケーションで問題が発生する場合が多いです。 Windows インストーラー パッケージで正しいバージョンのファイルを宣言することで、Windows インストーラーはこの機能をネイティブにサポートします。

アプリケーションをインストールし、ユーザーごとのデータを異なる場所に格納します。

アプリケーションは、Programs Files ディレクトリの下のフォルダーにインストールする必要があります。 これを構成するには、Windows インストーラー パッケージの Direcotry テーブルで ProgramFilesFolder プロパティを使用できます。ユーザーごとの構成データは、\Users\username\AppData ディレクトリの下のファイルまたは HKCU ルートのレジストリ キーに格納する必要があります。 ユーザー データ、テンプレート、およびアプリケーションで作成されたファイルはすべて、\Users\username サブディレクトリ内に適切な場所があります。 これは以前は適用されませんでしたが、多くのユーザーが完全な管理者アクセス トークンを使用してプログラムを実行するため、正しい場所に情報を配置しないアプリケーションは失敗する可能性があります。 これは、仮想化がオフになっている場合に特に当てはまります。

共有コンポーネントをインストールするときは、一貫したフォルダーの場所を使用します。

共有コンポーネントは、Windows インストーラー パッケージのディレクトリ テーブルの CommonFilesFolder プロパティを使用して、Common Files ディレクトリにインストールする必要があります。 共有コンポーネントの管理は問題になる可能性があり、可能であれば避ける必要があります。 共有コンポーネントを一貫してインストールしない開発者は、古いコンポーネントを指すコンポーネント オブジェクト モデル (COM) 登録情報を取得できます。 Windows インストーラー マージ モジュール (MSM) は、共有コンポーネントをインストールするすべてのパッケージのコンテキストで共有コンポーネントが一貫してインストールできるように特別に設計されています。 共有コンポーネントの変更によって既存のアプリケーションが失敗すると、その他の問題が発生します。 この問題に対処する方法の 1 つは、Microsoft .NET (Win32) バージョン管理されたアセンブリを使用してアプリケーションをビルドすることです。

インストールが失敗した場合は、セットアップのロールバックを実行します。

部分的にインストールされたソフトウェアは、不適切なユーザー エクスペリエンスを提供する奇妙で予期しない方法で失敗する可能性があります。 Windows インストーラーでは、このロールバック機能がサポートされています。

ユーザーのプロファイル全体にアプリケーション ショートカットをインストールしないでください。

Windows のすべての既知の露出ポイントにアプリケーション アイコンを追加したくなるかもしれませんが、多くの場合、ユーザーは自分のコンピューターの制御を失ったと感じます。 その後、ユーザーは手動でこれらのショートカットを削除して、コンピューターを目的の外観に戻す必要があります。 開発者がデスクトップにアイコンを追加する場合は、インストール中にユーザーにアクセス許可を求めます。 Windows Vista では、大規模な [スタート] メニューの走査を回避するために、インストール後のアプリケーションの検出可能性と最近使用したアプリケーションの一覧に対応します。

ユーザー ログオン時にバックグラウンド アプリケーションを自動的に起動しないようにします。

インストール中にスタートアップ グループまたは実行キーにプログラムを追加することはできますが、システムにオーバーヘッドを追加します。 時間の経過と同時に、ユーザーのシステムのパフォーマンスが大幅に低下する可能性があります。 アプリケーションがバックグラウンド タスクの恩恵を受けることができる場合は、ユーザーが構成できるようにする必要があります。 また、HLKM 実行キーを使用してスタートアップ タスクを追加すると、標準ユーザー アカウントが将来の動作を変更できなくなる可能性があります。 ユーザーがログイン時にアプリケーションを起動する場合は、HKCU の実行キーに情報を格納します。

削除ロジッククリーン従います。

ユーザーは、ディスク領域を解放するだけでなく、アプリケーションがインストールされる前にその状態にコンピューターを戻すために、アプリケーションを削除することがあります。 アプリケーションのアンインストール プロセスは、アプリケーションを正しく完全に削除する必要があります。 Windows インストーラーの既定値は次の規則です。

• 共有されていないすべてのアプリケーション ファイルとフォルダー。
• 参照カウント (refcount) が 0 に達する共有アプリケーション ファイル。
• 他のプログラムによって共有される可能性があるキーを除き、レジストリ エントリ。
• インストール時にアプリケーションが作成した [スタート] メニューからのすべてのショートカット。
• ユーザー設定はユーザー データと見なされ、取り残される場合がありますが、完全にクリーン削除を行うオプションを含める必要があります。
• アンインストーラー自体 (Windows インストーラーを使用していない場合)。

6. アプリケーション マニフェストを作成してアプリケーションに埋め込む

Windows Vista では、アプリケーションをマークする正しい方法は、アプリケーションが必要とする内容をオペレーティング システムに伝えるアプリケーション マニフェストをプログラム内に埋め込むことです。 Windows Vista リリースでは、マニフェストまたは署名されていないコードを完全な管理アクセス トークンで実行できるようにするためのプロビジョニングがあります。

メモ 今後のリリースでは、昇格されたアプリケーションを実行する唯一の方法は、アプリケーションに必要な特権レベルを識別する署名付きマニフェストを用意することです。

アプリケーション マニフェスト スキーマ

アプリケーション マニフェストは、Windows Vista リリースの新機能ではありません。 マニフェストは、アプリケーション開発者がアプリケーションでテストされた DLL のバージョンなどを特定するのに役立つよう、Windows XP で使用されました。 実行レベルを指定することは、その既存のマニフェスト スキーマの拡張機能です。

Windows Vista アプリケーション マニフェストは、開発者が要求された実行レベルでアプリケーションをマークできるようにする属性で強化されました。 この形式を次に示します。

<requestedExecutionLevel
level="asInvoker|highestAvailable|requireAdministrator"
uiAccess="true|false"/>

可能な要求された実行レベルの値

値	説明	解説
asInvoker	アプリケーションは、親プロセスと同じアクセス トークンで実行されます。	標準ユーザー アプリケーションに推奨されます。 このドキュメントに記載されているガイダンスに従って、内部標高ポイントで耐火処理を行います。
highestAvailable	アプリケーションは、現在のユーザーが取得できる最高の特権で実行されます。	混合モード アプリケーションに推奨されます。 今後のリリースでアプリケーションを耐火処理する予定です。
requireAdministrator	アプリケーションは管理者に対してのみ実行され、管理者のフル アクセス トークンを使用してアプリケーションを起動する必要があります。	管理者専用アプリケーションに推奨されます。 内部標高ポイントは必要ありません。 アプリケーションは既に管理者特権で実行されています。

メモ ホスティング アプリケーションは、特定の種類のホステッド アプリケーションをサポートしている場合にのみ、標準のユーザーまたは管理者専用のアプリケーションにすることができます。 たとえば、MMC.exeは管理スナップインのみをホストし、Explorer.exeは標準ユーザー コードのみをホストします。

システムの動作

Application Markin	仮想。
覆面	はい
asInvoker	いいえ
requireAdministrator	いいえ
highestAvailable	いいえ

アプリケーション マニフェストのマーキングとアプリケーション起動の動作

このセクションでは、親プロセス アクセス トークンに応じた昇格プロンプトの動作、ユーザー アカウント制御: 管理承認モード ポリシーの管理者向けの昇格プロンプトの動作、およびユーザー アカウント制御: 標準ユーザー ポリシーの昇格プロンプトの動作、およびアプリケーションに対して要求された実行レベルマーキングの設定について詳しく説明します。

アプリケーションを実行できるかどうか、およびアプリケーションが取得できるユーザー権限と管理 Windows 特権は、アプリケーション互換性データベース内のアプリケーションの要求された実行レベルと、アプリケーションを起動したユーザー アカウントで使用できる管理特権の組み合わせによって異なります。 次の表では、このような可能な組み合わせに基づいて、考えられる実行時の動作を示します。

ローカル Administrators グループのメンバーに対するアプリケーション起動の動作

親プロセス アクセス トークン	ローカル管理者グループのメンバーの同意ポリシー	None または asInvoker	highestAvailable	requireAdministrator
標準ユーザー	プロンプトなし	アプリケーションが標準ユーザーとして起動する	アプリケーションは、完全な管理アクセス トークンを使用して起動します。プロンプトなし	アプリケーションは、完全な管理アクセス トークンを使用して起動します。プロンプトなし
標準ユーザー	同意を要求する	アプリケーションが標準ユーザーとして起動する	アプリケーションは、完全な管理アクセス トークンを使用して起動します。同意を求めるプロンプト	アプリケーションは、完全な管理アクセス トークンを使用して起動します。同意を求めるプロンプト
標準ユーザー	資格情報の要求	アプリケーションが標準ユーザーとして起動する	アプリケーションは、完全な管理アクセス トークンを使用して起動します。資格情報のプロンプト	アプリケーションは、完全な管理アクセス トークンを使用して起動します。資格情報のプロンプト
管理者 (UAC が無効)	該当なし	アプリケーションは、完全な管理アクセス トークンを使用して起動します。プロンプトなし	アプリケーションは、完全な管理アクセス トークンを使用して起動します。プロンプトなし	アプリケーションは、完全な管理アクセス トークンを使用して起動します。プロンプトなし

標準ユーザー アカウントのアプリケーション起動動作

親プロセス アクセス トークン	標準ユーザーの同意ポリシー	asInvoker	highestAvailable	requireAdministrator
標準ユーザー	プロンプトなし	アプリケーションが標準ユーザーとして起動する	アプリケーションが標準ユーザーとして起動する	アプリケーションの起動に失敗する
標準ユーザー	資格情報の要求	アプリケーションが標準ユーザーとして起動する	アプリケーションが標準ユーザーとして起動する	アプリケーションを実行する前に管理者資格情報の入力を求める
標準ユーザー (UAC が無効)	該当なし	アプリケーションが標準ユーザーとして起動する	アプリケーションが標準ユーザーとして起動する	アプリケーションが起動する可能性がありますが、後で失敗します

追加の特権を持つ標準ユーザーのアプリケーション起動動作 (バックアップ オペレーターなど)

親プロセス アクセス トークン	標準ユーザーの同意ポリシー	asInvoker	highestAvailable	requireAdministrator
標準ユーザー	プロンプトなし	標準ユーザーとしてアプリケーションが起動する	追加の特権を持つ標準ユーザーとしてアプリケーションが起動する	アプリケーションの起動に失敗する
標準ユーザー	資格情報の要求	標準ユーザーとしてアプリケーションが起動する	アプリケーションを実行する前に資格情報の入力を求める	アプリケーションを実行する前に管理者の資格情報を要求する
Standard ユーザー (UAC が無効)	該当なし	標準ユーザーとしてアプリケーションが起動する	追加の特権を持つ標準ユーザーとしてアプリケーションが起動する	アプリケーションが起動する可能性がありますが、後で失敗します

uiAccess 値

使用可能な uiAccess 値

値	説明
誤	アプリケーションは、デスクトップ上の別のウィンドウのユーザー インターフェイスへの入力を駆動する必要はありません。 アクセシビリティを提供していないアプリケーションでは、このフラグを false に設定する必要があります。 デスクトップ上の他のウィンドウ (スクリーン キーボードなど) への入力を行うために必要なアプリケーションでは、この値を true に設定する必要があります。
True	アプリケーションは、ユーザー インターフェイス制御レベルをバイパスして、デスクトップ上の高い特権ウィンドウに入力を駆動できます。 この設定は、ユーザー インターフェイスの支援技術アプリケーションにのみ使用する必要があります。

大事なuiAccess フラグが true に設定されているアプリケーションは、正しく起動するために Authenticode 署名されている必要があります。 さらに、アプリケーションはファイル システム内の保護された場所に存在する必要があります。 \Program Files\ と \windows\system32\ は、現在、2 つの許可される保護された場所です。

Microsoft Visual Studio で埋め込みマニフェストを作成する方法

Visual Studio には、ポータブル実行可能ファイル (PE) イメージのリソース セクション内に XML マニフェスト ファイルを自動的に埋め込む機能が用意されています。 このセクションでは、Visual Studio を使用して、マニフェストを含む署名付き PE イメージを作成する方法について説明します。 したがって、このマニフェストには必要な requestedExecutionLevel 属性を含めることができます。これにより、Windows Vista でアプリケーションを目的の特権レベルで実行できます。 プログラムが起動されると、マニフェスト情報が PE のリソース セクションから抽出され、オペレーティング システムによって使用されます。 マニフェストを含めるために Visual Studio グラフィカル ユーザー インターフェイス (GUI) を使用する必要はありません。 必要な変更がソース コードに含まれると、コマンド ライン ツールを使用したコンパイルとリンクも、結果の PE イメージにマニフェストが含まれます。

マニフェスト ファイル

アプリケーションをマークするには、最初にターゲット アプリケーションで使用するマニフェスト ファイルを作成します。 これは、任意のテキスト エディターを使用して行うことができます。 マニフェスト ファイルの名前は、次の例に示すように、 拡張子が .manifest のtarget.exeと同じである必要があります。

Executable: IsUserAdmin.exe 
Manifest:IsUserAdmin.exe.manifest
Sample application manifest file:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
  <assemblyIdentity version="1.0.0.0"
     processorArchitecture="X86"
     name="IsUserAdmin"
     type="win32"/> 
  <description>Description of your application</description> 
  <!-- Identify the application security requirements. -->
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="requireAdministrator"
          uiAccess="false"/>
        </requestedPrivileges>
       </security>
  </trustInfo>
</assembly>

アプリケーションに合わせて調整する必要があるマニフェストの部分は、太字でマークされます。 次に例を示します。

• アセンブリ ID
• 名前
• 型
• 説明
• requestedExecutionLevel の属性

Visual Studio 2005 for Windows Vista 専用アプリケーションを使用した C/C++ コード内でのアプリケーション マニフェストのビルド

大事な アプリケーションを Windows Vista と Windows XP の両方で実行する場合は、次のセクション「Windows XP および Windows Vista アプリケーション用の Microsoft Visual Studio 2005 を使用したマニフェストのビルドと埋め込み」で詳しく説明されている手順に従う必要があります。

次に、アプリケーションのリソース ファイル (.rc ファイル) に行を追加して、マニフェストを実行可能ファイルにアタッチし、MICROSOFT Visual Studio で PE ファイルのリソース セクションにマニフェストを埋め込む必要があります。 これを実現するには、ビルドするプロジェクトのソース コードと同じディレクトリにマニフェストを配置し、.rc ファイルを編集して次の行を含めます。

#define MANIFEST_RESOURCE_ID 1
MANIFEST_RESOURCE_ID RT_MANIFEST "IsUserAdmin.exe.manifest"

アプリケーションを再構築した後、マニフェストを実行可能ファイルのリソース セクションに埋め込む必要があります。

Microsoft Visual Studio 2005 for Windows XP および Windows Vista アプリケーションを使用したマニフェストのビルドと埋め込み

Visual Studio 2005 では、ターゲット実行可能ファイルに追加のマニフェスト ファイルを含めることを許可する C/C++ 統合開発環境 (IDE) インターフェイスは、XML に対して何らかの処理を行い、重複する xmlns タグを挿入します。 このため、Visual Studio 2005 C++ プロジェクトにマニフェストを含める方法に関する前述の方法は、アプリケーションを Windows Vista と Windows XP の両方で実行する必要がある場合は使用できません。 次の手順は、trustInfo セクションに明示的なバージョン タグを含むように変更されています。

XML で重複する名前空間宣言が生成される問題に対処するために、mt.exe ツールの修正プログラムが計画されています。 新しいバージョンのmt.exeが使用できるようになるまで、マニフェストの trustinfo セクションにバージョン タグを明示的に追加することで、マニフェストのマージの問題を回避できます。 サンプル マニフェストを次に示します。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
   <ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
      <ms_asmv2:security>
         <ms_asmv2:requestedPrivileges>
            <ms_asmv2:requestedExecutionLevel level="asInvoker">
            </ms_asmv2:requestedExecutionLevel>
         </ms_asmv2:requestedPrivileges>
      </ms_asmv2:security>
   </ms_asmv2:trustInfo>
</assembly>

C または C++ プロジェクト

次の手順では、Visual Studio 2005 で C または C++ プロジェクトの種類のマニフェストを作成する方法について詳しく説明します。

Microsoft Visual Studio 2005 で C または C++ プロジェクトのマニフェストを作成するには

1. Microsoft Visual Studio 2005 でプロジェクトを開く
2. [プロジェクト] で、[プロパティ] を選択 します。
3. [プロパティ] で、[ マニフェスト ツール] を選択し、[ 入力と出力] を選択します。
4. アプリケーション マニフェスト ファイルの名前を [ 追加のマニフェスト ファイル] に追加します。
5. アプリケーションをリビルドします。

メモ 明示的なバージョン タグを含む更新されたマニフェストを使用すると、Windows Vista と Windows XP の両方でアプリケーションを正しく実行できます。

マネージド コード (C#、J#、Visual Basic)

Visual Studio では現在、既定のマニフェストはマネージド コードに埋め込まれていません。 マネージド コードの場合、開発者は、mt.exeを使用して、ターゲット実行可能ファイルに既定のマニフェストを挿入するだけです。 手順は次のようになります。

mt.exeを使用して既定のマニフェスト ファイルをターゲット実行可能ファイルに挿入するには

1. Windows メモ帳などのテキスト エディターを使用して、既定のマニフェスト ファイル temp.manifest を作成します。
2. マニフェストを挿入するには、mt.exeを使用します。 コマンドは次のようになります。 mt.exe –manifest temp.manifest –outputresource:YourApp.exe;#1

Visual Studio のビルド後のステップとしてのアプリケーション マニフェストの追加

アプリケーション マニフェストの追加は、ビルド後の手順としても自動化できます。 このオプションは、C/C++ と C# と J# の 2 つのマネージ コード言語で使用できます。

メモ 現在、IDE には Visual Basic アプリケーションのビルド後オプションは含まれていません。

[プロジェクトのプロパティ] で、ビルド後のタスクとして次の行を配置します。

mt.exe -manifest "$(ProjectDir)$(TargetName).exe.manifest" 
-updateresource:"$(TargetDir)$(TargetName).exe;#1"

7. アプリケーションをテストする

再設計されたアプリケーションまたは新しいアプリケーションをテストして、Standard User Analyzer とのアプリケーションの互換性を確認します。 このプロセスについて詳しく説明した手順については、このドキュメントの「アプリケーションの UAC 互換性のテスト」セクションで説明しました。

次のワークフローを使用して、アプリケーションをテストします。

アプリケーションで最終的な UAC 互換性をテストするには

1. Standard User Analyzer ツールを使用してアプリケーションをテストします。
2. 管理承認モードで管理者として Windows Vista コンピューターにログオンし、プログラムを実行します。 すべての機能をテストし、ユーザー エクスペリエンスに注意してください。 それに応じて、昇格またはユーザー インターフェイスのバグを報告します。
3. 標準ユーザーとして Windows Vista コンピューターにログオンし、プログラムを実行します。 すべての機能をテストし、承認モードのユーザー エクスペリエンスの管理者と比較して、標準ユーザー エクスペリエンスの違いまたは失敗管理注意してください。 必要に応じて、昇格とユーザー エクスペリエンスのバグを報告します。

8. Authenticode がアプリケーションに署名する

アプリケーションにマニフェストが含まれるようになりました。マニフェストが検出され、アプリケーションの起動時に解析された情報が表示されます。 ただし、実行可能ファイルは改ざんされる可能性があります。 これを防ぐには、Authenticode 署名を使用してアプリケーションに署名する必要があります。 Windows Vista には、署名されていないアプリケーションが完全な管理者アクセス トークンで起動しないようにする機能があることに注意してください。 ロックダウン環境でアプリケーションを正しく動作させ、ユーザー フレンドリなユーザー インターフェイスを表示する場合は、Authenticode 署名で署名する必要があります。

アプリケーションに署名するには、makecert.exeから証明書を生成するか、VeriSign、Thawte、Microsoft CA などの商用証明機関 (CA) からコード署名キーを取得します。

メモ アプリケーションをインストールしている顧客のターゲット コンピューターでアプリケーションを信頼する場合は、商用証明書が必要です。

makecert.exe ファイルを使用して署名キー ペアを生成する場合は、1024 ビット キーのみが生成されることに注意してください。 Authenticode シグネチャは、少なくとも 2048 ビット キーである必要があります。 makecert.exe ファイルは、テスト目的でのみ使用する必要があります。

次の手順では、makecert.exeを使用して署名キー ペアを生成するための大まかな要件について詳しく説明します。 パラメーターの例とmakecert.exeは、次の手順に従います。

makecert.exeを使用して署名キーペアを生成するには

1. 証明書を生成します。
2. コードに署名します。
3. テスト証明書をインストールします。

署名手順の例

次の手順は例として提供されており、厳密に従うものではありません。 たとえば、テスト証明書の名前を証明書の名前に置き換え、手順を特定の CA と開発環境にマップするように調整します。

手順 1: 証明書を生成する

makecert -r -pe -ss PrivateCertStore -n "CN=Contoso.com(Test)" 
ContosoTest.cer

パラメーターのmakecert.exe

パラメーター	説明
/r	自己署名証明書を作成
/pe	証明書の秘密キーを署名マシンにエクスポートできるようにします。
/ss StoreName	テスト証明書を格納する証明書ストア名。 例: PrivateCertStore
/n X500Name	証明書のサブジェクトの X500 名。 例: Contoso.com(Test)
CertificateName.cer	証明書名。 例: ContosoTest.cer

手順 2: コードに署名する

Signtool sign /v /s PrivateCertStore /n Contoso.com(Test) /t 
http://timestamp.verisign.com/scripts/timestamp.dll file.exe

手順 3: テスト証明書をインストールする

テスト証明書をインストールするには

1. [コマンド プロンプト] を右クリックし、[管理者として実行] を選択して、管理者特権のコマンド ウィンドウを起動します。
2. コマンド プロンプトで、「 mmc.exe 」と入力し、Enter キーを押 します。
3. mmc で [ファイル] を選択し、[スナップインの追加と削除]を選択します。
4. [スナップインの追加と削除] で、[ 証明書] を選択し、[ 追加] をクリックし、[OK] をクリック します。
5. [証明書スナップイン] ダイアログ ボックスで、[ コンピューター アカウント ] を選択し、[ 次へ] をクリックします。
6. [コンピューターの選択] で、[ ローカル コンピューター] を選択し、[OK] をクリック します。
7. [スナップインの追加と削除] で、[OK] をクリック します。
8. [証明書] スナップインで、[ 信頼されたルート証明機関] に移動し、[ 証明書] を右クリックし、[ すべてのタスク] を選択し、[インポート] を選択 します。
9. 証明書のインポート ウィザードで、テスト証明書 ContosoTest.cer をインポートします。

9. Windows Vista ロゴ プログラムに参加する

Microsoft は、お客様がプラットフォーム機能と品質目標の包括的なベースライン定義を満たすシステムと周辺機器を特定し、エンド ユーザーに優れたコンピューティング エクスペリエンスを確保するための Windows Vista ロゴ プログラムを提供しています。

標準ユーザー向けのアプリケーションのデプロイと修正プログラムの適用

一般に、企業はユーザーのワークステーションにアプリケーションを自動でインストールする方法を検討する必要があるため、管理コストが削減されます。 この問題には基本的に 2 つの部分があります。1 つ目は、これらのアプリケーションをデプロイ用にパッケージ化する方法と、それらをデプロイするために使用するテクノロジです。 小規模なエンタープライズ環境の場合、堅牢で自動化されたデプロイ メカニズムは必要ない場合があります。

企業がその環境で実行されているソフトウェアのインベントリを既に取得していると仮定すると、次の手順では、展開のためにこれらのアプリケーションを再パッケージ化します。 Windows インストーラー形式は、ユーザーごとの設定の管理とコンピューターごとの設定を切り離す独自の機能があるため、Microsoft が推奨しています。 通常、この種の管理は、他のパッケージ形式、特に SYSTEM などのより多くの特権を持つアカウントによって実行されるデプロイ実行可能ファイルでは使用できません。 MSDN ライブラリには、Windows インストーラーに関する多くの記事が含まれています。1 つの提案は、Windows インストーラードキュメントのロードマップです。

Windows インストーラー形式には、グループ ポリシー (Microsoft IntelliMirror) と SMS を使用して、これらのアプリケーションのインストールをユーザーが制御する機能が含まれています。 ファイル拡張子またはショートカットを使用してオンデマンドでインストールを有効にするには、Windows インストーラー ベースのパッケージの次の表に、広告データ (ショートカット、拡張機能、アイコン、動詞) を設定する必要があります。 クラス、MIME、ProgID、TypeLib も設定することをお勧めします。 IntelliMirror とオンデマンドインストールの詳細については、「 マネージド アプリケーションPer-User修正プログラム の適用」を参照してください。

アプリケーションがユーザーごとにインストールされ、ClickOnce などの自動更新をサポートできるようにする他のインストーラー テクノロジがあります。 つまり、インストーラーはインストールに管理者以上の特権を必要とせず、コンピューターがネットワークに接続されている限り、ユーザーは常に最新バージョンを実行します。 また、これらのアプリケーションのインストールを制御する IT プロフェッショナルの機能にもいくつかの制限があります。

ClickOnce 配置は、ユーザーが Web サイトのマニフェスト、CD、汎用名前付け規則 (UNC) パスなどのマニフェスト リンクをクリックしたときに、クライアント側アプリケーションを自動的にインストールおよび構成する Microsoft .NET インストール テクノロジです。 既定では、アプリケーションはそれ自体を一時インターネット ファイル フォルダーにコピーし、制限された環境内で実行します。

メモ アプリケーションが完全信頼を与える IT の厳密な名前で署名されている場合でも、ファイル システムやレジストリの特定の部分へのアクセスなど、管理者権限を必要とする操作は実行できません。 ただし、ClickOnce アプリケーションはユーザーごとのアプリケーションを対象としているため、これは問題になりません。

大事な ClickOnce は、管理操作を実行するアプリケーションの配置には使用しないでください。

1 台のコンピューターへの展開

1 台のコンピューター用にアプリケーションを展開するには、管理者がそのコンピューターでアプリケーションを "発行" する必要があります。

ドメイン内のすべてのユーザーへの展開

ドメイン内のすべてのユーザーに対してアドバタイズするには、管理者は展開を通じてアプリケーションを "発行" グループ ポリシー必要があります。 現在、この機能を利用できるのは、Windows Server® 2003 オペレーティング システムと Windows 2000 Server オペレーティング システムのグループ ポリシーベースのソフトウェア展開コンポーネントのみです。

Windows インストーラー 4.0 を使用した標準ユーザーとしてのアプリケーションの修正プログラムの適用

標準ユーザー アカウントの修正プログラムを適用すると、Windows インストーラー パッケージの作成者は、将来の標準ユーザーが適用できる署名付きパッチを識別できます。 Windows インストーラー 4.0 で標準ユーザーの修正プログラムを適用できるようにするには、次の条件を満たす必要があります。

• アプリケーションは、Windows インストーラー 4.0 を使用してインストールされました。
• アプリケーションがもともとマシンごとにインストールされたものである。
• MsiPatchCertificate テーブルが存在し、元のウィンドウ インストーラー パッケージ (.msi ファイル) に設定されます。
• パッチが、MsiPatchCertificate テーブルに記載されている証明書によってデジタル署名されている。
• パッチはデジタル署名に対して検証できます。
• MSIDISABLELUAPATCHING プロパティまたは DisableLUAPatching ポリシーを設定することで、標準ユーザー アカウントのパッチ適用が無効にされていません。

Windows インストーラー 4.0 の標準ユーザー アンインストール動作

標準ユーザーによって適用される Windows インストーラー 4.0 パッチに対して想定される動作は、標準ユーザーでも削除できることです。

一般的な問題のトラブルシューティング

次のセクションでは、Windows Vista のアプリケーションで発生する一般的な問題について詳しく説明します。

次のような一般的な問題があります。

• ActiveX のインストールに関する問題
• ActiveX ドキュメントがインストールされない
• アプリケーション、フレームワーク、またはアドインが必要
• インストール/修正プログラムの適用には管理アクセス許可が必要です
• ユーザーごとのアプリケーション設定の場所
• アプリケーションの既定値は、保護されたディレクトリに保存されます

ActiveX のインストールに関する問題

ActiveX コントロールは管理者がインストールする必要があります。 通常、ActiveX コントロールは、Web ブラウザー機能を拡張して、より柔軟なユーザー インターフェイスを作成したり、通常は Web ブラウザー内で実行されているアプリケーションに対して拒否されるコンピューター リソースへのアクセスを昇格したりするために、基幹業務アプリケーションで使用されます。 ActiveX コントロールは、通常、Web ページに ActiveX コントロールへの参照を埋め込むことでインストールされます。 これにより、Microsoft インターネット エクスプローラーがローカル コンピューターに存在しない場合は、コントロールをダウンロードしてインストールします。 通常、この方法でダウンロードされた ActiveX コントロールは、標準ユーザーが書き込み可能な %HOMEPATH%\Local Settings\Temporary Internet Files ディレクトリに存在します。 ただし、インターネット エクスプローラー内で機能するには、コントロールに複数のレジストリ エントリが必要です。管理者以外では使用できません。

解像度

アプリケーションから ActiveX コントロールを削除すると、ほとんどの場合、機能が失われます。 そのため、ActiveX コントロールがサイトのコア機能の一部ではない視覚的または機能的な機能強化を提供しない限り、修復にはお勧めしません。 たとえば、株式関連以外のポータルの株式ティッカーなどです。

ほとんどの場合、SMS またはグループ ポリシーによるインストール用に ActiveX コントロールをパッケージ化することが適切なソリューションです。 ただし、ほとんどのコントロールは基本イメージに含まれないので、Web サイトは正常に失敗するようにページを変更する必要があります。 これには、不足している ActiveX コントロールを検出し、Managed Desktop ソフトウェア要求ページにリダイレクトする必要があります。

ActiveX ドキュメントがインストールされない

ActiveX ドキュメントは、Microsoft Visual Basic 4 および Microsoft Visual Basic 5 の非推奨のテクノロジです。 ActiveX コントロールと同様の方法でダウンロードできます。

解像度

Visual Basic 4 と Visual Basic 5 は非推奨であるため、アプリケーションを置き換えることをお勧めします。 クライアント インストールの一部として ActiveX ドキュメントをインストールできる必要があります。ただし、SMS またはグループ ポリシーを使用して再デプロイしなくても、ドキュメントの更新は制限されます。

アプリケーション、フレームワーク、またはアドインが必要

多くのアプリケーションは、他のソフトウェアに依存しています。既定ではインストールされていない可能性があります。これは、コンピューターで既に使用できるため、または他のアプリケーションがサードパーティが使用する再頒布可能なバイナリを提供していないためです。 通常の状況では、ユーザーは追加のソフトウェアを取得してインストールするように指示されます。 マネージド デスクトップでは、インストールできません。 たとえば、Adobe Acrobat、Microsoft Office、Office Web コンポーネント、WinZip、IT Microsoft .NET セキュリティ ポリシーなどがあります。

解像度

依存関係が特定されたら、基本イメージでパッケージ化するか、オンデマンド SMS インストールを通じて使用できるようになります。 アプリケーションでは、不足しているソフトウェアをエンド ユーザーに通知し、製造元ではなく SMS インストール サイトにユーザーを誘導する方法を変更する必要がある場合があります。

インストール/修正プログラムの適用には管理アクセス許可が必要です

プログラムをインストールするには Program Files にファイルを追加する必要があるため、常に管理アクセス許可が必要になるため、管理者特権のアクセス許可を持つユーザーとして実行する必要があります。

メモまた、SMS または グループ ポリシー を使用して、プログラムの追加または削除 (ARP) コントロール パネルと組み合わせてパッチを "プッシュ" することもできます。 ユーザーがインストールするソフトウェアを選択し、システム インストーラーによって残りの処理が行われます。ユーザーは管理者である必要はありません。 初期インストールの場合は、インストール エージェントがプッシュアウトするためのソフトウェアをパッケージ化することで、これを処理できます。ただし、一部のアプリケーションでは、一元管理されたアプリケーション モデルに合わない可能性がある頻繁な自動更新に依存しています。

更新プログラムを検出し、それ自体にパッチを適用しようとするアプリケーションは、システム ディレクトリ内のファイルを変更するアクセス許可がないため、これを行うことができません。

解像度

• SMS によるデプロイ用にアプリケーション/パッチをパッケージ化します。 アプリケーションは、アップグレードが使用可能であることを (管理アクセス許可を必要とせずに行う限り) 引き続き検出でき、プロビジョニング サイトにリダイレクトできます。
• アプリケーションで、ファイル システム、レジストリ アクセス、COM 相互運用性など、コンピューターの昇格されたアクセス許可が必要かどうかについて質問します。 そうでない場合は、Microsoft .NET サンドボックスで実行される ClickOnce 配置パッケージとしてアプリケーションを書き換える可能性があります。
• クライアント側の依存関係を使用せずに Web アプリケーションに変換します。

アプリケーション設定の場所をPer-Userする

Windows Vista の場合、実行時に変更する必要があるアプリケーション設定は、次のいずれかの場所に格納する必要があります。

• CSIDL_APPDATA
• CSIDL_LOCAL_APPDATA
• CSIDL_COMMON_APPDATA

ユーザーによって保存されたドキュメントは、CSIDL_MYDOCUMENTSに格納する必要があります。

メモ ユーザーの [ドキュメント] フォルダーが [ ドキュメントと設定] の下に保存されなくなりました。 Windows Vista では、ファイル システムの [ ユーザー ] という名前の新しいルート ディレクトリに、コンピューターのユーザーのプロファイルが含まれるようになりました。

これらのディレクトリが変更されたため、開発者は CSIDL を使用して、システムに依存しない方法で特定の既知のディレクトリへのパスを見つけることが推奨されます。 詳細については、「 CSIDLs」を参照してください。

アプリケーションでは、ファイル システムへの書き込みアクセス権が必要です。 マネージド デスクトップで実行する場合、アプリケーションには次のフォルダーとその子への書き込みアクセス許可のみが付与されます。

• CSIDL_PROFILE
• CSIDL_COMMON_APPDATA

メモ 標準ユーザーは Users\Common に書き込めません。

• C:\Users\Common>cd "Application Data"
  • C:\Users\Common\Application Data>echo File > File.txt
  • C:\Users\Common\Application Data>

アプリケーションは、次のような他の場所への書き込みを試行しないでください。

• C:\windows。
• C:\Windows\System32。
• Program Files\{application}。
• C:\{application}。

メモ これは、ユーザーがフォルダーを作成した場合に機能します。ユーザー グループのメンバーは既定で実行できます。

アプリケーションが C:\Users\Profiles\{user} を明示的に作成しようとしていますが、ユーザーは C:\Users\{user} の下にのみフォルダーを作成できるため、許可されていません。 選択した場所は、Microsoft が以前のバージョンのオペレーティング システムに Documents フォルダーを格納している場所に基づいて混乱しているように見えます。

実行時に変更する必要があるアプリケーション設定は、次のいずれかの場所に格納する必要があります。

• CSIDL_APPDATA
• CSIDL_LOCAL_APPDATA
• CSIDL_COMMON_APPDATA

ユーザーによって保存されたドキュメントは、CSIDL_MYDOCUMENTS フォルダーに格納する必要があります。

すべてのパスはハードコーディングしないでくださいが、Environment.GetFolderPath() 関数を使用する必要があります。

保護されたディレクトリに保存するアプリケーションの既定値

一部のアプリケーションでは、ユーザーがローカル コンピューターにデータを保存またはエクスポートできます。 多くの場合、ダイアログ ボックスは既定で C:\のような場所に設定され、標準ユーザーには書き込みアクセス許可がありません。 さらに、一部のアプリケーションは、オペレーティング システムからのアクセスが拒否されたため、ファイルを書き込むコードが失敗した場合に適切に応答しません。

解像度

ユーザーが自分のプロファイルにのみ書き込むことができるとします。 ユーザーが意図的に保存したドキュメントの場合は、ダイアログ ボックスを初期化して、 Documents (Environment.GetFolderPath(Environment.SpecialFolder.Personal) から開始します。 [保存] ダイアログ ボックスを使用すると、ユーザーはユーザーのプロファイル以外の場所を参照できるため、ユーザーが自分のプロファイルにあるディレクトリとは異なるディレクトリを選択した場合に正常に失敗するように、アプリケーションにロジックを含める必要があります。

リファレンス

このセクションには、仮想化リファレンスとセキュリティ設定のリファレンスが含まれています。

仮想化リファレンス

ファイルの仮想化

• 仮想化 (%SYSTEMROOT%、%PROGRAMDATA%、%PROGRAMFILES%\(サブディレクトリ)
• リダイレクト先: %LOCALAPPDATA%\VirtualStore
• 除外されたバイナリ実行可能ファイル: .exe、.dll、.sys

レジストリ仮想化:

• 仮想化 (HKLM\SOFTWARE)
• リダイレクト先: HKCU\Software\Classes\VirtualStore\MACHINE\SOFTWARE\<Application Registry Keys>
• 仮想化から除外されるキー
• HKLM\Software\Classes
• HKLM\Software\Microsoft\Windows
• HKLM\Software\Microsoft\Windows NT

適用範囲

• 仮想ストアがローミングしない
• 対応するグローバル オブジェクトはローミングされません
• 対話型の標準ユーザーに対してのみ有効
• 非対話型プロセスでは無効
• 64 ビット実行可能ファイルでは無効
• アプリケーション マニフェストで実行レベル (requestedExecutionLevel) を要求する実行可能ファイル (分離のためのモデル) では無効
• カーネル モードと偽装された呼び出し元では無効
• 管理者の書き込み可能なレジストリ キーとファイルのみが仮想化されます

UAC セキュリティ設定リファレンス

このリファレンスでは、グループ ポリシーまたはコンピューターのローカル セキュリティ ポリシーを使用して UAC を管理するために使用できるセキュリティ設定について詳しく説明します。

メモ このセクションで説明する手順は、アンマネージド コンピューターの管理を目的としています。 グループ ポリシーを使用して管理対象環境で一元的に設定を管理するには、ローカルセキュリティ ポリシー マネージャー スナップイン (secpol.msc) ではなく、Active Directory ユーザーとコンピューター (dsa.msc) を使用します。

UAC セキュリティ設定の構成

次の手順では、セキュリティ ポリシー マネージャーを使用して UAC セキュリティ設定を構成する方法について詳しく説明します。 この手順では、管理承認モードの管理者の既定のユーザー エクスペリエンスについて詳しく説明します。

セキュリティ ポリシー マネージャーを使用して UAC セキュリティ設定を表示または設定するには

1. [ スタート ] ボタンをクリックし、検索ボックスに 「secpol.msc 」と入力し、 Enter キーを押します。
2. ユーザー アカウント制御の同意プロンプトで、[ 続行] をクリックします。
3. [ローカル セキュリティ設定] で、[ ローカル ポリシー] を展開し、[ セキュリティ オプション] をクリックします。
4. 変更するセキュリティ設定を右クリックし、[プロパティ] を選択 します。

次の手順では、グループ ポリシーを使用して UAC セキュリティ設定を構成する方法について詳しく説明します。 この手順では、管理承認モードの管理者の既定のユーザー エクスペリエンスについて詳しく説明します。

グループ ポリシー オブジェクト エディターを使用して UAC セキュリティ設定を表示または設定するには

1. [ スタート ] ボタンをクリックし、検索ボックスに 「gpedit.msc 」と入力し、 Enter キーを押します。
2. ユーザー アカウント制御の同意プロンプトで、[ 続行] をクリックします。
3. グループ ポリシーで、[ユーザー構成] を展開し、[セキュリティ オプション] を展開します。
4. 変更するセキュリティ設定を右クリックし、[プロパティ] を選択 します。

UAC セキュリティ設定

次の表に、構成可能な UAC セキュリティ設定を示します。 これらの設定は、セキュリティ ポリシー マネージャー (secpol.msc) で構成することも、グループ ポリシー (gpedit.msc) を使用して一元的に管理することもできます。

UAC セキュリティ設定

設定	説明	Default value
ユーザー アカウント制御: 組み込みの管理者アカウントの承認モードを管理します。	次の 2 つの設定が可能です。 有効: 組み込みの管理者は、管理承認モードで管理者として実行されます。 無効: 管理者は、完全な管理者アクセス トークンを使用して実行されます。	新しいインストールと、組み込みの管理者がコンピューター上の唯一のローカルのアクティブな管理者ではないアップグレードでは無効になります。 ドメインに参加しているコンピューターでのインストールとアップグレードでは、組み込みの管理者アカウントは既定で無効になっています。 Windows Vista が、組み込みの管理者アカウントがコンピューター上の唯一のアクティブなローカル管理者であると判断した場合に、アップグレードが有効になります。 Windows Vista がこれを判断した場合、組み込みの管理者アカウントもアップグレード後も有効に維持されます。 ドメインに参加しているコンピューターでのインストールとアップグレードでは、組み込みの管理者アカウントは既定で無効になっています。
ユーザー アカウント制御: 管理者承認モードでの管理者に対する昇格時のプロンプトの動作	この設定には、次の 3 つの値を指定できます。 プロンプトを表示せずに昇格する: サイレント 昇格します。 資格情報の入力を求める: 続行する前に、ユーザーにログイン パスワードの入力を要求します。 同意を求める: 管理者特権を昇格する前に、ユーザーに承認を求めます。 これが既定の設定です。  この設定は、より高いアクセス許可を持つプログラムを実行する前にユーザーにプロンプトを表示する方法を決定します。 このポリシーは、UAC が有効になっている場合にのみ有効になります。	同意を要求する
ユーザー アカウント制御: 標準ユーザーに対する昇格時のプロンプトの動作	より高いアクセス許可を持つプログラムを実行する前に、ユーザーにプロンプトを表示する方法を決定します。 このポリシーは、UAC が有効になっている場合にのみ有効になります。 この設定で使用できる構成オプションを次に示します。 昇格要求を自動的に拒否する: アプリケーションが管理タスクを実行する場合、ユーザーにプロンプトは表示されません。 アプリケーションの起動に失敗し、アクセス拒否または同等のエラーがユーザーに表示されます。 資格情報の入力を求める: 続行する前に、ユーザーにログイン パスワードの入力を要求します。	資格情報の要求
ユーザー アカウント制御: アプリケーションのインストールを検出し、昇格をプロンプトする	次の 2 つの値を指定できます。 有効: Windows Vista でインストーラーが検出されると、ユーザーは同意または資格情報の入力を求められます。 無効: アプリケーションのインストールは、非決定的な方法でサイレント モードで失敗または失敗します。	Enabled
ユーザー アカウント制御: 署名され検証された実行ファイルのみを昇格する	次の 2 つの値を指定できます。 有効: 署名された実行可能ファイルのみが実行されます。 この設定により、署名されていないアプリケーションの実行がブロックされます。 無効: 署名されたコードと署名されていないコードの両方が実行されます。	無効
ユーザー アカウント制御: 安全な場所にインストールされている UIAccess アプリケーションの昇格のみ	次の 2 つの値を指定できます。 有効: システムは、%ProgramFiles% または %windir% の下から起動された実行可能ファイルに対してのみ UIAccess 特権とユーザー権限を付与します。 これらのディレクトリの ACL は、実行可能ファイルがユーザーが変更できないようにします (それ以外の場合は特権の昇格を許可します)。 他の場所から起動された UIAccess 実行可能ファイルは、追加の特権なしで起動されます (つまり、"asInvoker" を実行します)。 無効: 場所のチェックは行われず、ユーザーの承認時にすべての UIAccess アプリケーションがユーザーのフル アクセス トークンで起動されます。	Enabled
ユーザー アカウント制御: 管理者承認モードですべての管理者を実行する	次の 2 つの値を指定できます。 有効: 管理者と標準ユーザーの両方が、管理操作を実行しようとしたときにプロンプトが表示されます。 プロンプト のスタイルはポリシーに依存します。 無効: UAC は基本的に "オフ" であり、AIS サービスは自動的に開始されません。	Enabled
ユーザー アカウント制御: 昇格のプロンプト時にセキュリティで保護されたデスクトップに切り替える	次の 2 つの値を指定できます。 有効: セキュリティで保護されたデスクトップに UAC 昇格プロンプトを表示します。 セキュリティで保護されたデスクトップは、悪意のあるソフトウェアからのメッセージを排除する Windows プロセスからのみメッセージを受信できます。 その結果、セキュリティで保護されたデスクトップで同意と資格情報のプロンプトをスプーフィングすることはできません。 無効: UAC 昇格プロンプトがユーザー デスクトップに表示されます。	Enabled
ユーザー アカウント制御: 各ユーザーの場所へのファイルまたはレジストリの書き込みエラーを仮想化する	次の 2 つの値を指定できます。 有効: アプリケーション互換性データベース エントリがないアプリケーション、またはアプリケーション マニフェストで要求された実行レベルのマーキングがないアプリケーションは、UAC に準拠していません。 非準拠のソフトウェアを利用する環境では、この設定を有効にしておく必要があります。 無効: UAC 準拠アプリケーションは保護された領域に書き込まないようにし、書き込みエラーを発生させる必要があります。 その結果、UAC 準拠アプリケーションのみを使用している環境では、この設定を無効にする必要があります。 プログラム ファイルと %systemroot% に書き込もうとする準拠していないアプリケーションは、この設定が無効になっている場合、サイレント モードで失敗します。	Enabled

メモ ほとんどの場合、[ プロンプトなしで昇格 する] オプションは推奨されません。 プロンプトを表示せずに昇格すると、標準ユーザーとして実行されているアプリケーションは、ユーザーの同意なしに管理アプリケーションを起動し、UAC を効果的にバイパスできます。

タスク スケジューラのコード サンプル

次の C++ コード サンプルは、タスク スケジューラを使用してユーザーの昇格を実行する方法を示しています。 その結果、アプリケーションは管理者の資格情報を使用してログオン中に自動的に昇格でき、Windows Vista はアプリケーションをブロックしません。 このソリューションを適切に機能させるには、セットアップ中にアプリケーションの管理者ユーザーを作成する必要があります。

//---------------------------------------------------------------------
//  This file is part of the Microsoft .NET Framework SDK Code Samples.
// 
//  Copyright (C) Microsoft Corporation.  All rights reserved.
// 
//This source code is intended only as a supplement to Microsoft
//Development Tools and/or on-line documentation.  See these other
//materials for detailed information regarding Microsoft code samples.
// 
//THIS CODE AND INFORMATION ARE PROVIDED AS IS WITHOUT WARRANTY OF ANY
//KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
//IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A
//PARTICULAR PURPOSE.
//---------------------------------------------------------------------

/****************************************************************************
* Main.cpp - Sample application for Task Scheduler V2 COMAPI                * Component: Task Scheduler                          
* Copyright (c) 2002 - 2003, Microsoft Corporation 
* This sample creates a task to at the time registered to start the desired task.                                                             *
****************************************************************************/
#include "stdafx.h"
#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <comdef.h>
#include <comutil.h>
//Include Task header files - Included in Windows Vista Beta-2 SDK from MSDN
#include <taskschd.h>
#include <conio.h>
#include <iostream>
#include <time.h>

using namespace std;

#define CLEANUP \
pRootFolder->Release();\
        pTask->Release();\
        CoUninitialize();

HRESULT CreateMyTask(LPCWSTR, wstring);

void __cdecl wmain(int argc, wchar_t** argv)
{
wstring wstrExecutablePath;
WCHAR taskName[20];
HRESULT result;

if( argc < 2 )
{
printf("\nUsage: LaunchApp yourapp.exe" );
return;
}

// Pick random number for task name
srand((unsigned int) time(NULL));
wsprintf((LPWSTR)taskName, L"Launch %d", rand());

wstrExecutablePath = argv[1];

result = CreateMyTask(taskName, wstrExecutablePath);
printf("\nReturn status:%d\n", result);

}
HRESULT CreateMyTask(LPCWSTR wszTaskName, wstring wstrExecutablePath)
{
    //  ------------------------------------------------------
    //  Initialize COM.
TASK_STATE taskState;
int i;
    HRESULT hr = CoInitializeEx(NULL, COINIT_MULTITHREADED);
    if( FAILED(hr) )
    {
        printf("\nCoInitializeEx failed: %x", hr );
        return 1;
    }

    //  Set general COM security levels.
    hr = CoInitializeSecurity(
        NULL,
        -1,
        NULL,
        NULL,
        RPC_C_AUTHN_LEVEL_PKT_PRIVACY,
        RPC_C_IMP_LEVEL_IMPERSONATE,
        NULL,
        0,
        NULL);

    if( FAILED(hr) )
    {
        printf("\nCoInitializeSecurity failed: %x", hr );
        CoUninitialize();
        return 1;
    }

    //  ------------------------------------------------------
    //  Create an instance of the Task Service. 
    ITaskService *pService = NULL;
    hr = CreateElevatedComObject( CLSID_TaskScheduler,
                           NULL,
                           CLSCTX_INPROC_SERVER,
                           IID_ITaskService,
                           (void**)&pService );  
    if (FAILED(hr))
    {
        printf("Failed to CoCreate an instance of the TaskService class: %x", hr);
        CoUninitialize();
        return 1;
    }
        
    //  Connect to the task service.
    hr = pService->Connect(_variant_t(), _variant_t(), _variant_t(), _variant_t());
    if( FAILED(hr) )
    {
        printf("ITaskService::Connect failed: %x", hr );
        pService->Release();
        CoUninitialize();
        return 1;
    }

    //  ------------------------------------------------------
    //  Get the pointer to the root task folder.  This folder will hold the
    //  new task that is registered.
    ITaskFolder *pRootFolder = NULL;
    hr = pService->GetFolder( _bstr_t( L"\\") , &pRootFolder );
    if( FAILED(hr) )
    {
        printf("Cannot get Root Folder pointer: %x", hr );
        pService->Release();
        CoUninitialize();
        return 1;
    }
    
    //  Check if the same task already exists. If the same task exists, remove it.
    hr = pRootFolder->DeleteTask( _bstr_t( wszTaskName), 0  );
    
    //  Create the task builder object to create the task.
    ITaskDefinition *pTask = NULL;
    hr = pService->NewTask( 0, &pTask );

    pService->Release();  // COM clean up.  Pointer is no longer used.
    if (FAILED(hr))
    {
        printf("Failed to CoCreate an instance of the TaskService class: %x", hr);
        pRootFolder->Release();
        CoUninitialize();
        return 1;
    }
        

    //  ------------------------------------------------------
    //  Get the trigger collection to insert the registration trigger.
    ITriggerCollection *pTriggerCollection = NULL;
    hr = pTask->get_Triggers( &pTriggerCollection );
    if( FAILED(hr) )
    {
        printf("\nCannot get trigger collection: %x", hr );
CLEANUP
        return 1;
    }
  
    //  Add the registration trigger to the task.
    ITrigger *pTrigger = NULL;
    
    hr = pTriggerCollection->Create( TASK_TRIGGER_REGISTRATION, &pTrigger );     
    pTriggerCollection->Release();  // COM clean up.  Pointer is no longer used.
    if( FAILED(hr) )
    {
        printf("\nCannot add registration trigger to the Task %x", hr );
        CLEANUP
        return 1;
    }
    pTrigger->Release();

    //  ------------------------------------------------------
    //  Add an Action to the task.     
    IExecAction *pExecAction = NULL;
    IActionCollection *pActionCollection = NULL;

    //  Get the task action collection pointer.
    hr = pTask->get_Actions( &pActionCollection );
    if( FAILED(hr) )
    {
        printf("\nCannot get Task collection pointer: %x", hr );
        CLEANUP
        return 1;
    }
    
    //  Create the action, specifying that it is an executable action.
    IAction *pAction = NULL;
    hr = pActionCollection->Create( TASK_ACTION_EXEC, &pAction );
    pActionCollection->Release();  // COM clean up.  Pointer is no longer used.
    if( FAILED(hr) )
    {
        printf("\npActionCollection->Create failed: %x", hr );
        CLEANUP
        return 1;
    }

    hr = pAction->QueryInterface( IID_IExecAction, (void**) &pExecAction );
    pAction->Release();
    if( FAILED(hr) )
    {
        printf("\npAction->QueryInterface failed: %x", hr );
        CLEANUP
        return 1;
    }

    //  Set the path of the executable to the user supplied executable.
hr = pExecAction->put_Path( _bstr_t( wstrExecutablePath.c_str() ) );  

//hr = pExecAction->put_Path( (BSTR)wstrExecutablePath );  
    if( FAILED(hr) )
    {
        printf("\nCannot set path of executable: %x", hr );
        pExecAction->Release();
        CLEANUP
        return 1;
    }
    hr = pExecAction->put_Arguments( _bstr_t( L"" ) );  
//    hr = pExecAction->put_Arguments( _bstr_t( L"ArgumentsToYourExecutable--HelpFileToOpen" ) );  
   if( FAILED(hr) )
    {
        printf("\nCannot set arguments of executable: %x", hr );
        pExecAction->Release();
        CLEANUP
        return 1;
    }
    
    //  ------------------------------------------------------
    //  Save the task in the root folder.
    IRegisteredTask *pRegisteredTask = NULL;
    hr = pRootFolder->RegisterTaskDefinition(
            _bstr_t( wszTaskName ),
            pTask,
        TASK_CREATE, 
_variant_t(_bstr_t( L"S-1-5-32-545")),//Well Known SID for \\Builtin\Users group
_variant_t(), 
TASK_LOGON_GROUP,
            _variant_t(L""),
            &pRegisteredTask);
    if( FAILED(hr) )
    {
        printf("\nError saving the Task : %x", hr );
        CLEANUP
        return 1;
    }
    printf("\n Success! Task successfully registered. " );
for (i=0; i<100; i++)//give 10 seconds for the task to start
{
pRegisteredTask->get_State(&taskState);
if (taskState == TASK_STATE_RUNNING)
{
printf("\nTask is running\n");
break;
}
Sleep(100);
}
if (i>= 100) printf("Task didn't start\n");

//Delete the task when done
    hr = pRootFolder->DeleteTask(
            _bstr_t( wszTaskName ),
            NULL);
    if( FAILED(hr) )
    {
        printf("\nError deleting the Task : %x", hr );
        CLEANUP
        return 1;
    }

    printf("\n Success! Task successfully deleted. " );

//  Clean up.
    CLEANUP
    CoUninitialize();
    return 0;
}