| Oracle® Fusion Middleware Enterprise Single Sign-On Suiteセキュア・デプロイメント・ガイド 11g リリース2 (11.1.2.2) E53271-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Enterprise Single Sign-On Suiteセキュア・デプロイメント・ガイド 11g リリース2 (11.1.2.2) E53271-01 |
|
前 |
次 |
この章では、Logon Managerをセキュアにデプロイする方法を説明します。
Active Directory、AD LDS (ADAM)、Oracle Internet Directory、様々なサード・パーティLDAP準拠ディレクトリなどのディレクトリ環境にLogon Managerをデプロイする選択肢もあり、これにより、ネットワーク上の任意のマシンに対して、アプリケーション資格証明、テンプレートおよびポリシーの一括格納によるシングル・サインオン機能を実装できます。ユーザーは、このディレクトリを同期して、これらの項目をダウンロードし、新規作成または変更されたユーザー名やパスワードで資格証明ストアを更新します。
既存のディレクトリ環境にLogon Managerを追加すると、次のような利点があります。
Logon Managerでは既存のユーザー・アカウント、グループおよびネイティブのディレクトリ権限(ACL)を使用できるため、これらの項目を個別に管理したり、他のディレクトリまたはデータベースと同期する必要がありません。
Logon Managerのデータは、既存のバックアップ、フェイルオーバーおよび障害時リカバリ計画によって自動的に保護されます。
専用サーバーやサーバー側のプロセスは不要で、Logon Managerのスケーラビリティとパフォーマンスは、既存のディレクトリ・インフラストラクチャの容量と堅牢性のみに依存します。
管理者のタスクが増えることはなく、また新しいツールや概念について学習する必要もありません。Logon Managerの委任管理は、ディレクトリのネイティブ機能によって行われます。
また、ディレクトリの使用によって、Logon Managerのテンプレートとポリシーの編成を見やすい階層構造で表示することもできます。現行の環境で必要な場合はフラット・モデルを使用できますが、階層を適切に設定すれば、より効率的なアクセス制御によって、トップ・ディレクトリ、エージェント、およびネットワークのパフォーマンスの安定化を図り、Logon Managerの管理を簡略化し、データ・セキュリティを向上できます。
Logon ManagerでActive Directoryにデータを格納するためには、Logon ManagerにActive Directoryスキーマの拡張を指示する必要があります。スキーマの拡張は、4つのオブジェクト・クラスを追加し、これらのタイプのオブジェクトを作成、読取り、変更、削除できるように、適切な権限を設定して行います。既存のクラスおよび属性を変更する方法はありません。Logon Managerでアプリケーション資格証明をユーザー・オブジェクトに格納する場合(推奨されるベスト・プラクティス)は、この機能に必要な権限もLogon Managerによって適用されます。
Logon Managerエージェントは、Active Directoryシンクロナイザのプラグインを使用してActive Directoryと通信します。適切に設定されている場合は、次のいずれかのイベントが発生すると同期が実行されます。
Logon Managerエージェントが起動された。
アプリケーション資格証明がエンド・ユーザーによって、追加、変更または削除された。
エージェントを実行しているマシンがIPアドレスを取得した、または既存のIPアドレスが変更された。(Logon Managerがこれらのイベントに応答するように設定されている場合)。
自動同期の間隔が経過した(設定されている場合)。
ユーザーがLogon Managerのリフレッシュ機能を使用して同期を開始した。
スクリプトがコマンド行パラメータを使用して同期を開始した。
同期を実行している間、Logon Managerエージェントは、Logon Managerツリーを移動して、現在のユーザーにアクセス権が付与されているサブコンテナのコンテンツをロードし、前回の同期後に追加、変更または削除された資格証明を同期します。
Logon Managerは、ユーザーが「First-Time Use (FTU)」ウィザードを完了したときに生成される一意キーを使用してアプリケーション資格証明を暗号化します。資格証明は、エージェントのローカル・キャッシュ内、ディレクトリ内およびネットワークを移動しているときも常に暗号化された状態を維持します。Logon Managerは、設定されたアプリケーションがログオンをリクエストしたときにのみ資格証明を(ディスクではなくメモリーに対して)復号化し、ログオン・リクエストの完了後すぐにターゲット・メモリーの場所を消去します。ユーザーおよび有効なアプリケーションごとにLogon Managerが格納するデータ量はわずかです(数バイトか数キロバイト)。
Logon Managerでは、組織のニーズに合わせてディレクトリ構造を思いのままに設定できます。具体的には、データをフラット・モデルで格納するか階層構造で格納するかの選択肢があります。フラット・モデルは小規模なデプロイメントでは問題なく機能しますが、成長する大規模なデプロイメントでは最初から階層構造を使用します。サブツリーの適切な構造は次の要素によって決まります。
ユーザーの数
Logon Managerでサポートするアプリケーションの数
既存のインフラストラクチャの堅牢性
組織の構造
Active Directoryの設計および実装については、Microsoftの次の記事で説明されているベスト・プラクティスに必ず従ってください。
http://technet.microsoft.com/en-us/library/bb727085.aspx
次のガイドラインに従ってサブツリーを階層構造として設定することをお薦めします。
OUを使用して、部門や部署など、組織の構造に合わせたカテゴリごとにテンプレートおよびポリシーをグループ化します。
OUレベルでアクセスを制御します。
現在の環境で特に指定がないかぎり、継承を無効化し、Logon Managerのサブツリーのルートでユーザー権限を付与しないようにします。
このように階層を設定すると、次の利点があります。
見やすくわかりやすいツリー構造。ディレクトリ・ブラウザでサブツリーを表示すると、サブツリー構造を一覧できるので全体が把握しやすくなります。
不要な権限の継承なし。ユーザーには、アクセスする必要のないサブOUに対する権限はネイティブで継承されません。これにより、ツリーの下位に継承される不要なアクセス権限を明示的に拒否せずに済みます。
ネットワーク、エージェントおよびディレクトリの堅牢なパフォーマンス。通常、大量のテンプレートおよびポリシーをダウンロードするユーザーは、自分のジョブに関連する項目のみをダウンロードするユーザーよりもネットワーク・トラフィックが多く、ディレクトリの負荷も高くなります。グループ化によって、環境のリソースが節約され、エージェントのレスポンス時間が改善されます。
管理タスクの分散。テンプレートを制御しやすいセットに整理し、アクセス権限の設定によって、ユーザーが管理できるテンプレートを決定します。権限に基づいたテンプレートのバージョン制御を実装する機能も使用できます。
低い管理オーバーヘッド。テンプレート・レベルでのアクセスの制御では、Logon Manager管理コンソールから個々のテンプレートに権限を設定する必要があり、OUレベルでのアクセスの制御は、Microsoftやサードパーティの管理ツールを使用した委任管理によって行います。
サンプルのシナリオでは、ポートランド部門のユーザーは、サクラメント部門で使用するアプリケーションへのアクセスは不要で、その逆も同様であるため、各部門のテンプレートおよびポリシーは、ルートの専用サブOUに配置し、両部門が互いのサブOUにアクセスできないようにしています。つまり、具体的な実装方法は使用する環境によって決まります。
図1-1は、前述のベスト・プラクティスを反映して設計されたサンプルのLogon Managerサブツリーを示しています。
|
注意: テンプレートおよびポリシーは、個々のOUに格納することをお薦めします。これを行うには、「構成オブジェクトの使用(Active Directoryのみ)」の説明に従って、構成オブジェクトの使用を有効にする必要があります。 |
フラット・モデルで開始し、ユーザーおよびプロビジョニングするアプリケーションの数が多くなると予想される場合は、階層構造への移行の準備ができるまでは、ルートの下にサブコンテナを作成し、それを使用してテンプレートとポリシーをフラットに格納します。ユーザーを追加したり、アプリケーションをさらにプロビジョニングする際には、階層に移行してなるべく早いうちに環境のパフォーマンスをモニターしてください(後で確認するよりも手間を省くことができます)。
Logon Managerエージェントの動作(ディレクトリとの相互作用も含む)は構成済の設定によって管理し、エンドユーザーのマシンへのデプロイは管理コンソールを使用してLogon Manager管理者が行います。設定は、次のいずれかのカテゴリに該当します。
グローバル・エージェント設定は、エージェントのローカル・ポリシーであり、エンド・ユーザー・マシンのWindowsレジストリに格納され、Logon Manager MSIパッケージに含まれて、エージェントにデプロイメント時の初期構成を提供します。グローバル・エージェント設定は、HKEY_LOCAL_MACHINE\Software\Passlogix (32ビット・システム)またはHKEY_LOCAL_MACHINE\Wow6432Node\Software\Passlogix (64ビット・システム)に格納されます。
管理オーバーライドはWindowsレジストリに格納されているグローバル・エージェント設定よりも優先され、エージェント用のドメイン・ポリシーを構成します。オーバーライドは、同期化の際にエージェントによって中央リポジトリからダウンロードされ、改ざん防止機能が付いた、エージェントの暗号化済ローカル・キャッシュに格納されるため、これによって、エンド・ユーザーによる変更ができないようになります。ロール/グループのセキュリティが有効な場合、管理オーバーライドはユーザーまたはグループごとに適用することも、企業全体に適用してすべてのユーザー設定の一貫性を保つこともできます。
|
注意: 管理オーバーライドを計画する際は、慎重に行ってください。オーバーライドが少なければ、格納および転送するデータも少なくなるので、中央リポジトリとの同期がより効率的になります。エンド・ユーザーのマシン上では管理オーバーライドを確認することができないため、オーバーライドの数を減らすことで不明な状況が解消され、トラブルシューティングも容易になります。 |
管理オーバーライドとグローバル・エージェント設定は、エージェントの完全な構成ポリシーを適用します。このガイドは、Logon Managerのセキュアなデプロイメントを実現するためにOracleが推奨する構成について説明し、Logon Managerに関する他の文書の情報を補足するものです。
|
警告: ドメイン名やユーザー・オブジェクト・パスなどの設定は、必ず十分にテストしてからデプロイし、必要のない場合は管理オーバーライドとしてデプロイしないでください。 |
この項では、セキュアなLogon Manager構築を実現するためにOracleに必須の、グローバル・エージェント設定について記載します。
Logon ManagerリポジトリのシンクロナイザはSSLサポートが有効の状態で出荷されるので、これを無効にしないことを強くお薦めします。使用する環境では、セキュリティを最大化するために、Logon Managerおよびその他のリポジトリへのすべての接続に必ずSSLを使用してください。
注意: Logon Managerをデプロイする前に、SSLを使用するようにドメイン・コントローラを構成してください。手順は次のMSDNの記事を参照してください。
http://msdn.microsoft.com/en-us/library/aa364671(VS.85).aspx
場所: 「Global Agent Settings」 > 「Live」 > 「Synchronization」 > [シンクロナイザ名]
有効にするには(無効になっている場合): チェック・ボックスの選択を解除します。
Active Directoryのデプロイメントでは、ユーザー・データおよび構成データの格納にディレクトリ・オブジェクトを使用することをお薦めします(これにより、「サブツリーの構築に関するガイドライン」の説明に従って、階層構造での格納、ロールおよびグループ・ベースの個別のコンテナに対するアクセス制御、テンプレートおよびポリシーを使用することが可能になります)。(この機能を無効にしている場合、Logon Managerは、すべてのテンプレートおよび構成データをツリーのルートの下に単一のフラット・ファイルとして格納します。)
場所: 「Global Agent Settings」 > 「Live」 > 「Synchronization」 
有効にするには: チェック・ボックスを選択して、ドロップダウン・リストで「Yes」を選択します。
「Credentials to use」オプションを使用して、ディレクトリに対する認証を行う場合に、Logon Managerで使用する資格証明を選択します。Logon Managerがディレクトリに対して認証できない場合に、ユーザーに再認証のためのプロンプトが表示されないように、これを「Use local computer credentials only」に設定することをお薦めします。
注意: これをデフォルトの設定「Try local computer credentials; if it fails, use directory server account」のままにしないでください。デフォルト設定のままにすると、ディレクトリとエンド・ユーザー・マシンが同じドメイン上にない場合に、認証が失敗します(無効に設定していないかぎり、再認証のプロンプトが表示されます)。
場所: 「Global Agent Settings」 > 「Live」 > 「Synchronization」 > [シンクロナイザ名] 
設定するには: チェック・ボックスを選択し、ドロップダウン・リストから適切なオプションを選択します。
Logon ManagerをActive Directoryで使用する主な利点は、それぞれのユーザー・オブジェクトの下にユーザー資格証明を格納できることです。こうすることで、次のような管理の簡略化が図れます。
個別のユーザーの資格証明を検索したり表示する操作がすばやく直感的になります。
ディレクトリからユーザーを削除すると、ユーザーのアプリケーション資格証明のキャッシュがそれぞれのユーザー・オブジェクトから自動的に削除されます。
|
注意: このオプションは、必要なスキーマの変更と権限の割当てを行わないかぎり機能しません。手順については、使用しているリポジトリのLogon Managerデプロイメント・ガイドを参照してください。 ユーザー資格証明がそれぞれのユーザー・オブジェクトの下に格納され、資格証明オブジェクトの使用が有効になっている場合、Locatorオブジェクトを使用する必要がありません。Locatorは、フラットなディレクトリ・モデルを使用する場合、ディレクトリ内のテンプレート、証明書、およびその他のオブジェクトを探す場所をLogon Manager示すポインタ・オブジェクトです。詳細は、使用しているリポジトリのLogon Managerデプロイメント・ガイドを参照してください。 |
場所: 「Global Agent Settings」 > 「Live」 > 「Synchronization」 > 「ADEXT」
有効にするには: チェック・ボックスを選択して、ドロップダウン・リストから「Under respective directory user objects」を選択します。
この項では、Logon Managerのセキュアな構成を実現するためにOracleに必須の、管理オーバーライドについて記載します。
バージョン11.1.2.0.0以上では、Microsoft Active Directoryにデプロイした場合、Logon Managerの構成ポリシーが、リポジトリのセキュアかつ暗号化された場所に保存されます。「Use secure location for storing user settings」オプションを有効にすることにより、この新しい設定のストレージ・スキーマに移行することを強くお薦めします。
|
警告: 以前のバージョンのLogon Managerからアップグレードする場合は、Logon Managerのすべてのインスタンスをリリース11.1.2.0.0以上にアップグレードした場合にのみ、このオーバーライドをデプロイする必要があり、そうしない場合、Logon Manager 11.1.2.0.0以上が一度リポジトリと同期すると、以前のすべてのバージョンはそのユーザーのリポジトリと同期できなくなります。 |
場所: 「Global Agent Settings」 > 「Live」 > 「Synchronization」 > 「ADEXT」 
設定するには: チェック・ボックスを選択して、ドロップダウン・リストから「Yes」を選択します。
次の場合に、プライマリ・オーセンティケータを選択して構成することをお薦めします。
選択したプライマリ・オーセンティケータを介してのみユーザーを認証する場合。
次項の説明に従って、FTUウィザードを無効にする場合。
特定のオーセンティケータの構成については、Administrative Consoleのヘルプを参照してください。
|
注意: この設定が空白のままで、FTUウィザードが無効な場合、最初にインストールされたログオン方法(アルファベットの降順)がデフォルトで自動的に選択されます。インストールされているオーセンティケータのリストを表示するには、設定を一時的に有効にして、そのドロップダウン・リストを確認します。 |
場所: 「Global Agent Settings」 > 「Live」 > 「User Experience」 > 「Setup Wizard」 
設定するには: チェック・ボックスを選択し、ドロップダウン・リストから希望のログオン方法を選択します。
|
注意: 元のWinAuth (WinAuth v1とも呼ばれる)オーセンティケータは非推奨となっており、以前のバージョンからのアップグレードを可能にするためにのみ製品内に残されています。Oracleサポートが明示的に指示した場合を除き、ここでは選択しないでください。 |
Logon Managerが、サポートされているすべてのオペレーティング・システムとの互換性を維持するためにアプリケーションの資格証明の暗号化に使用するデフォルトの暗号化アルゴリズム(AES (MS CAPI))は変更しないでください。Logon Managerによってサポートされているすべてのアルゴリズムが、すべてのオペレーティング・システムで機能するわけではありません。
|
警告: AES (MS CAPI)を除くすべての暗号化アルゴリズムは非推奨になっており、以前のバージョンからのアップグレードを可能にするためにのみ製品内に残されています。Oracleサポートが明示的に指示した場合を除いて、暗号化アルゴリズムを変更しないでください。 |
場所: 「Global Agent Settings」 > 「Live」 > 「Security」 
デフォルトにリセットするには(変更されている場合): チェックボックスのチェックを外します。
デフォルトでのLogon Managerは、組織のセキュリティ要件を満たす新しいポリシーと置き換える必要のある、不十分なパスワード変更ポリシーが付属しています。組込みポリシーでないことを示すために、ポリシー名には組織の名前を含めます。このポリシーは、このオプションを設定する前に作成する必要があります(パスワード変更ポリシーの作成手順については、コンソール・ヘルプを参照してください)。
場所: 「Global Agent Settings」 > 「Live」 > 「User Experience」 > 「Password Change」 
設定するには: チェック・ボックスを選択し、ドロップダウン・リストから希望のポリシーを選択します。
|
注意: デフォルトのパスワード変更ポリシーとして設定されたポリシーは、エンタープライズ全体で有効です。 |
格納済のアプリケーション・パスワードへの不正アクセスを防止するには、エージェント内でマスクされたフィールドの表示機能が呼び出されたときに認証を行うことをユーザーに求めるようにLogon Managerを構成します。このポリシーを管理オーバーライドとして構成することで、不正な管理者がローカル・マシンのレジストリに手動で設定を追加したり、初期デプロイメント時に設定が未構成のままになっている場合にローカル・ユーザーのパスワードに不正アクセスすることも防止できます。
場所: 「Global Agent Settings」 > 「Security」 
設定するには: チェック・ボックスを選択して、ドロップダウン・リストから「Yes」を選択します。
ユーザーを認証し、格納された資格証明に対するアクセス権を付与するため、Logon Managerには、オーセンティケータ・プラグインとして実装された複数の認証方式が用意されています(最も一般的な方式は、ユーザー名とパスワードです)。Active Directory環境では、Logon Managerはこの認証方法をWindows Authenticator v2 (WinAuth v2)プラグインによってサポートします。
ユーザーがLogon Managerに初めて登録する際、Logon Managerはそのユーザーの一意の認証要素を使用して資格証明ストアへのアクセスを保護します。WinAuth v2でのデプロイにおいては、デフォルトでは(明示的に異なる構成がなされていない場合)、Logon Managerはユーザーにパスフレーズを求めます。このパスフレーズは、プライマリ認証が失敗した場合、Logon Managerへのセカンダリ認証の手段を提供します。
対話型パスフレーズ・メカニズムは、Logon Managerへの初期登録時にユーザーに質問に対する回答の提示を要求するもので、デフォルトの推奨されるセキュアなセカンダリ認証方式です。(質問は管理者が定義します。)ユーザーは、オーセンティケータ・キーの暗号化に使用した要素が変更されるたびに、パスフレーズに回答してLogon Managerを認証する必要があります。この方法の主な利点は次のとおりです。
資格証明ストアに対する「第2パスワード」の役割を果たします。パスフレーズは、ユーザーのWindowsパスワードが機能しなくなった、またはパスワードにアクセスできなくなった場合に、資格証明ストアに対するアクセスを回復するために使用できます。
不正な管理者からの攻撃を防止します。不正な管理者がユーザーのパスワードを変更し、そのユーザーとしてログオンし、ユーザーの資格証明ストアにアクセスする可能性があります。しかし、パスフレーズが機能している場合、不正な管理者はパスフレーズに回答しないかぎり、ユーザーの資格証明ストアにアクセスできません。
組織において、パスワードと同様の暗号化強度ポリシーをパスフレーズ回答に対して適用することを強くお薦めします。
また、WinAuth v2は、使用している環境に応じてパスフレーズ方式のかわりに選択して使用できる、次のようなセカンダリ認証方式を提供します。
カスタム・セカンダリ認証ライブラリ - WinAuth v2セカンダリ認証APIは、ユーザー操作の必要がない、外部セカンダリ認証ライブラリによってプログラム的にパスフレーズ応答を提供できる、セカンダリ認証APIを提供します。このAPIにより、リカバリ中にLogon Managerに2次キーを送る経路を完全に制御できますが、リカバリ・プロセスのいかなる時点においても、資格証明ストアキーのセキュリティを十分に確保する必要があります。
|
注意: APIの詳細は、『Oracle Enterprise Single Sign-On Suite Plus管理者ガイド』を参照してください。 |
ユーザーのActive Directory SID - 現在ログオン中のユーザーのActive Directory SIDをWinAuth v2に対するパスフレーズ回答として警告なしに提供します。暗号化されたSIDは、エージェントのローカル・キャッシュに格納されます。このセカンダリ認証方法は、ネットワーク上でユーザーを「追跡」(同行)します。
セキュア・ランダム・キー - ランダムに生成したキーを、WinAuth v2に対するパスフレーズ回答として警告なしに提供します。このランダム・キーは、暗号化形式でActive DirectoryのユーザーのLogon Manager資格証明ストアに保存されます。キーに対する不正アクセスは、ユーザーの資格証明ストア・コンテナに対して有効な、Active Directory ACLにより自動的に制限されます。
Windows Data Protection - Windows Data Protection API (DPAPI)を使用して、セカンダリ認証をWindows Data Protectionサービスに委任します。ユーザーの資格証明ストアへのセカンダリ・アクセスは、DPAPIが(ユーザーのワークステーションのローカルで)セキュアに処理するため、もう1つの「サイレントな」セカンダリ認証方法として使用できます。ただし、DPAPIの機能はユーザーのワークステーションに限定されているため、このセカンダリ認証方法は移植性がなく、ネットワーク上のユーザーに「同行」しません。そのため、ユーザーが別のワークステーションにログオンした場合、この方法を使用できなくなります。
|
注意: Logon ManagerをWinAuth v2でデプロイする場合の詳しい要件および手順は、『Oracle Enterprise Single Sign-On Suite Plus管理者ガイド』を参照してください。 |
WinAuth v2のGINA (Graphical Identification aNd Authentication)ライブラリおよびNetwork Providerサービス・コンポーネントは、Windowsオペレーティング・システムにおけるユーザー認証メカニズムとの統合を提供します。GINAコンポーネントはWindows XPシステムのGINAチェーンに接続し、Network Providerサービスによって、GINAライブラリを使用しないWindows 7およびWindows Server 2008/2008 R2との統合が可能になります。また、Network Providerサービスによって、GINAライブラリへの変更が許可されておらず、不可能なWindows XPシステムにおける統合が可能になります。この統合には次のような利点があります。
二重認証が不要になります。統合を行わない場合、ユーザーはWindows資格証明を2回提供する必要があります - 1回はオペレーティング・システムに対し、ログオンして、デスクトップのロックを解除するかセキュアなスクリーン・セーバーを終了するため、もう1回はLogon Managerに対し、保存された資格証明にアクセスするためです。
資格証明ストアの解除をユーザーに意識させません。Logon Managerはログオン時に自動的にユーザーの資格証明に割り込み、資格証明のロックを解除するため、Logon Managerに別の設定が行われていないかぎり、ユーザーは自動シングル・サインオンを使用するためにLogon Managerを認証する必要はありません。
|
注意: Windows XPが動作するクライアント・マシンでのPassword Reset環境において、Logon ManagerをWinAuth v2でデプロイする場合、Network Providerをインストールしないでください。Password Resetとは互換性がないためです。GINAライブラリのみをインストールしてください。 |
Logon Managerがアプリケーションのログオンまたはパスワード変更フォームを正常に検出すると、資格証明をアプリケーションに注入し、送信することによって応答します。ターゲット・アプリケーションの設計に応じて、Logon Managerは次のいずれの方式を使用して、ターゲット・フォームのフィールドおよびコントロールと対話することができます。
これは、ほとんどのアプリケーションでデフォルトかつ推奨されるフォームの対話方式です。この方式では、Windows API (Windowsアプリケーション)、適切なブラウザ・ヘルパー・オブジェクト(Webアプリケーション)、またはHLLAPI(メインフレーム・アプリケーション)を使用して、フォーム内のフィールドおよびコントロールを識別し、対話します。Windows API準拠のアプリケーションでは、各フィールドとコントロールの一意のコントロールIDがオペレーティング・システムに対して公開されます。エージェントはこれらのコントロールIDを検出し、コントロールIDが示すオブジェクト(パスワード・フィールド、送信ボタンなど)の用途を意味する特定のサインオン機能にバインドします。
|
注意: アプリケーションで公開されるコントロールIDのいくつか、またはそのすべてが、一意ではないか動的である場合、これらをエージェントで序数(ウィンドウ内の各項目に上から下へ、左から右に割り当てられる連続したID番号)に置き換えて、検出されたフィールドとコントロールを一意に識別することができます。 |
フィールドまたはコントロールのコントロールIDが公開されていない場合、またはサインオン・イベントを完了するために追加のアクションが必要な場合(チェック・ボックスの選択、手動による特定のフィールドのフォーカス設定など)は、そのフォームと対話するために、コントロールID方式とSendKeys方式を併用する必要がある場合もあります。
この方式では、キーストローク、マウス・クリックなどのユーザー入力をエミュレートすることで、エージェントはターゲット・アプリケーションと対話することができます。この方法は、エージェントがターゲット・フィールドおよびコントロールをプログラムで検出できないか、または対話できない場合に使用します。たとえば、アプリケーションがフィールドおよびコントロールのいずれのコントロールIDも公開しない場合は、フィールドに移入する個々のキーストローク、フィールドを切り替えるマウス・クリックまたは[Tab]キーストローク、ログオン・ボタンを動作させる最後のマウス・クリックを送信する必要があります。
|
注意: コントロールIDによる方法を使用するようにフォーム定義を構成した場合、アプリケーションの非互換性によってLogon Managerが資格証明をプログラム的に注入することに失敗すると、Logon Managerはデフォルトで自動的にSendKeysによる方法にフォール・バックして注入を再試行します。「Logon Managerアプリケーション・テンプレートの構成と診断」の説明に従って、このフォールバック挙動を無効にできます。 |
これは、前述の2つの方式を組み合せて両方の長所を活かすもので、プログラムでは実行できないアクションを必要とするサインオン・シナリオの解決方法として望ましい方式です。可能な場合は常にコントロールIDを使用してフォームと対話する一方で、キーストロークおよびマウス・クリックを送信して、フィールドのフォーカス設定、チェック・ボックスの選択、エージェントがターゲット・アプリケーション内ではプログラムで実行できないその他のアクションなどのタスクを実行します。
|
注意: この混合モードを実装するには、最初にSendKeysレスポンス方式を使用するようにフォームを構成し、目的のSendKeysアクションを構成し、そのアクションの構成中に、プログラム的なコントロールIDレスポンス方式を保持するアクションに対して「Inject directly into control」オプションを有効にします。 |
たとえば、カスケード検証のために特定の順序でフィールドに移入する必要がある場合(つまり、ユーザー名フィールドに移入されたときにかぎりパスワード・フィールドがアクティブになる場合)、コントロールIDを使用して資格証明をフィールドに注入しますが、各フィールドの注入の合間にSendKeysで[Tab]キーストロークを送信してフィールドのフォーカスを移動することになります。
SendKeysによる方法はキーストロークをエミュレートするため、Logon Managerが資格証明を注入している間、ユーザーが適切なタイミングでフォーカスを他のアプリケーションに切り替え、プレーン・テキストに取り込むことも理論的には可能です。このため、可能な場合はコントロールIDを使用し、プログラム的な注入が不可能な場合にのみ SendKeysを使用した方式に戻すことをお薦めします。
