1 Windowsアプリケーション・テンプレートの
構成と診断

この章では、特定のサインオン・シナリオを解決するためにWindowsアプリケーション・テンプレートを構成する方法と理由の理解に必要な概念について説明し、また、Windowsアプリケーション・フォームを構成およびテストする手順の推奨されるベスト・プラクティスについて、およびエージェントのアプリケーション・フォームに対する検出や応答が不安定になる可能性がある最も一般的な問題の診断と解決手順について説明します。内容は次のとおりです。

サインオン・イベントの概要
ウィンドウ検出の理解
フォームのレスポンスの理解
フォームの最適な構成の確認
フォームの構成
リポジトリへのテンプレートの公開
ウィンドウ検出のトラブルシューティング
コントロールIDを使用する場合のフォームのレスポンスのトラブルシューティング
SendKeysを使用する場合のフォームのレスポンスのトラブルシューティング
マッチングのトラブルシューティング
ログオン・ループのトラブルシューティング
Javaアプリケーションの問題のトラブルシューティング

ヒント:

この章のトラブルシューティングの手順で問題を解決できない場合は、Logon Managerのアクティビティの追跡とロギングを行い、記録された情報を分析のためにOracleサポートに送信することによって、さらにトラブルシューティングを行うことができます。このために、Oracleではトレース・コントローラ・ユーティリティ(Oracleサポートから入手可能)を提供しています。ユーティリティの使用方法の詳細は、『Enterprise Single Sign-On Suite管理者ガイド』のトレース・コントローラ・ユーティリティの使用に関する説明を参照してください。

1.1 サインオン・イベントの概要

ログオン、パスワード変更およびその他の多様なサインオン・イベントを、Logon Managerで検出して応答するように構成することができ、様々なフォーム、フィールド、コントロールおよびイベント・フローがサポートされています。

アプリケーション・ウィンドウを認識するため、エージェントは次のように、現在ログインしているユーザーのウィンドウ・メッセージ・キューを絶えず監視して応答します。

エージェントがウィンドウを検出します。新しいウィンドウを検出するたびに、エージェントは次の手順を実行します。
1. すべての使用可能なWindowsアプリケーション・テンプレートで、テンプレートに定義された識別基準の値に一致するものを検索します。(ウィンドウ・タイトル、ウィンドウ・クラスおよび実行可能ファイルの名前を含みます。)
2. ウィンドウに表示された基準に構成が一致する、1つ目のテンプレートを選択します。
3. レスポンス・プロセスを開始します。
検出されたウィンドウ内で、エージェントがフォームに応答します。エージェントはテンプレートに格納されている構成に従って、フォームのフィールドおよびコントロールとの対話方法を判断します。通常、エージェントは次の手順を実行します。
1. (オプション)フィールド・フォーカスの設定のような、アプリケーションによってログオン・フォームまたはパスワード変更フォームの起動やアクティブ化が必要になるアクションを実行します。
2. ユーザーのストア(存在する場合)から関連する資格証明を取得し、該当するフィールドに移入します。(資格証明が存在しない場合、エージェントはユーザーに格納するよう求めます。)
3. 「Logon」ボタンの押下など、資格証明をアプリケーションに送信して処理するために必要なアクションを実行します。
4. (オプション)新しいパスワードの確認など、補足情報のフォームを検出し、必要なアクションを実行します。

1.2 ウィンドウ検出の理解

Windowsメッセージ・キューまたはユーザー・インタフェース・オートメーション(UIA)APIを介して新しいウィンドウのインスタンス化を検出したエージェントは、次に示すそのウィンドウの特性値を調べ、その値を使用可能な各アプリケーション・テンプレートに格納されている値と比較し、その値が含まれるウィンドウやフォームを一意に特定します。

ウィンドウのタイトル
ウィンドウのクラス
実行可能ファイルの名前(モジュール名またはAppPath keyとも呼ばれる)
オートメーション要素ID(UIA APIを使用する場合)

注意:

アプリケーション・テンプレートは、アプリケーション・ウィンドウとそれらが含まれるフォームの検出方法、およびアプリケーション・ウィンドウに対するレスポンス方法をLogon Managerエージェントに指示するための一連の構成オプションです。

このような識別基準の値を、ターゲット・ウィンドウと、ターゲット・ウィンドウ以外のウィンドウで共有する場合、エージェントはターゲット・ウィンドウの他に、そのようなウィンドウに対しても誤って応答する場合があります。このような場合は、これらの基準に対して取り得る値をより詳細に指定するようなマッチングを使用し、その構成でウィンドウとフォームをエージェントで一意に識別できるようにする必要があります。マッチングの詳細は、「マッチングの使用によるレスポンス精度の向上」を参照してください。

一致が検出されると、エージェントは一致した1つ目のテンプレートに定義されたフォームに応答します(ユーザーをログオンさせる、パスワード変更を開始する、など)。

1.2.1 Java、SAPおよびWindows8のMetroアプリケーションの検出

Logon Managerでは、Java、SAP、およびWindows8のMetro(「Modern UI」)アプリケーションを検出して対話するため、Microsoftのユーザー・インタフェース・オートメーション(UIA)APIを利用し、プログラムでアプリケーションのフィールドおよびコントロールにアクセスします。UIAヘルパー・オブジェクト(UIAHO)は、目的とするタスク(フィールドの移入、フォームの送信など)を完了するためにコントロールと対話するだけでなく、ターゲット・ウィンドウのユーザー・インタフェースの構造ツリーを解析し、その変更をモニターします。

UIA APIにより、オートメーション要素がWindowsのデスクトップをルートとしたツリー構造に編成され、フィールドおよびコントロールがユーザーに見えるように公開されます。UIAヘルパー・オブジェクトは、アプリケーション・テンプレートで構成されているように、このツリーをフィルタリングしてターゲット・アプリケーションのウィンドウ要素のみを検出して対話します。

Logon ManagerでUIA駆動型のアプリケーション・テンプレートを構成する場合、次の形式でターゲット要素IDを記述します。

A:B:C...:n

ここで、Aはターゲット・ウィンドウのID、Bはターゲット要素のIDで、それ以降も同様です。コロンは、要素ツリー階層の次のレベルを示します。

1.3 フォームのレスポンスの理解

エージェントは、アプリケーション・ウィンドウを識別すると、フォーム(ログオン・フォーム、パスワード変更フォームなど)を含むフィールドおよびコントロールの存在をチェックします。たとえばログオン・フォームには通常、少なくともユーザー名フィールド、パスワード・フィールド、およびアプリケーションに資格証明を送信するボタンが含まれます。ログオン・フォームの例を示します。

image002.pngについては周囲のテキストで説明しています。

1.3.1 サポート対象のフォーム・タイプ

このドキュメントのリリース時点で、Logon Managerは次のタイプのフォームをWindowsアプリケーションでサポートします。

ログオン
ログオン成功(ログオンの成功を示すメッセージ)
ログオン失敗(注入された資格証明が拒否されたことを示すメッセージ)
パスワード変更
パスワードの確認(新しいパスワードを確認するように求めるダイアログ)
パスワード変更の成功(パスワード変更の成功を示すダイアログ)
パスワード変更の失敗(新しいパスワードが拒否されたことを示すダイアログ)

同じアプリケーション・ウィンドウに、(ログオンやパスワード変更などの)呼び出される機能に応じて異なるフォームを含めることができるため、そのウィンドウで表示できる複数のフォームの定義を、単一のテンプレートに含めることができます。ほとんどのアプリケーションの場合、定義する必要があるのは、Logon Managerで応答するフォームのみです。

注意:

フォームを定義することで一意の識別基準ができ、そのフォームが検出されたときにとるアクションおよびそのアクションで実行する必要がある特定の動作(資格証明の注入など)が指定されます。

Logon Managerは、ユーザーの資格証明ストアから自動的に、資格証明を取得してそれをフォーム内の適切なフィールドに移入することができるだけでなく、フォームのコントロールを操作して、アプリケーションに資格証明を送信して処理することもできます。フォームのフィールドおよびコントロールとの対話方法をエージェントに指定する構成オプションは、テンプレートに格納されています。

1.3.2 サポートされるフォーム・レスポンス方式

ターゲット・アプリケーションの設計に応じて、Logon Managerは次のいずれの方式を使用して、ターゲット・フォームのフィールドおよびコントロールと対話することができます。

1.3.2.1 コントロールID

これは、ほとんどのWindowsアプリケーションでデフォルトかつ推奨されるフォームの対話方式です。この方法は、Windows APIを使用してフォーム内のフィールドおよびコントロールを識別し、対話します。Windows API準拠のアプリケーションでは、各フィールドとコントロールの一意のコントロールIDがオペレーティング・システムに対して公開されます。エージェントはこれらのコントロールIDを検出し、コントロールIDが示すオブジェクト(パスワード・フィールド、送信ボタンなど)の用途を意味する特定のサインオン機能にバインドします。

注意:

アプリケーションで公開されるコントロールIDのいくつか、またはそのすべてが、一意ではないか動的である場合、これらをエージェントで序数(ウィンドウ内の各項目に上から下へ、左から右に割り当てられる連続したID番号)に置き換えて、検出されたフィールドとコントロールを一意に識別することができます。

フィールドまたはコントロールのコントロールIDが公開されていない場合、またはサインオン・イベントを完了するために追加のアクションが必要な場合(チェック・ボックスの選択、手動による特定のフィールドのフォーカス設定など)は、そのフォームと対話するために、コントロールID方式とSendKeys方式を併用する必要がある場合もあります。

注意:

Windows 8の「Metro」アプリケーションでは、エージェントは、Microsoftユーザー・インタフェース・オートメーション(UIA)APIを利用したヘルパー・オブジェクト(UIAHO)を介してアプリケーションと対話します。この機能を使用するには、Logon Managerをインストールするときに「UI Automation」コンポーネントを選択する必要があります。

1.3.2.2 SendKeys

この方式では、キーストローク、マウス・クリックなどのユーザー入力をエミュレートすることで、エージェントはターゲット・アプリケーションと対話することができます。この方法は、エージェントがターゲット・フィールドおよびコントロールをプログラムで検出できないか、または対話できない場合に使用します。たとえば、アプリケーションがフィールドおよびコントロールのいずれのコントロールIDも公開しない場合は、フィールドに移入する個々のキーストローク、フィールドを切り替えるマウス・クリックまたは[Tab]キーストローク、ログオン・ボタンを動作させる最後のマウス・クリックを送信する必要があります。

注意:

コントロールIDによる方法を使用するようにフォーム定義を構成した場合、アプリケーションの非互換性によってLogon Managerが資格証明をプログラム的に注入することに失敗すると、Logon Managerはデフォルトで自動的にSendKeysによる方法にフォール・バックして注入を再試行し、その結果間違ったウィンドウまたはアプリケーションに資格証明が注入される可能性があります。このフォール・バックの動作を、「自動SendKeysフォールバックの無効化」の手順に従って無効にすることができます。

1.3.2.3 コントロールIDとSendKeys

これは、前述の2つの方式を組み合せて両方の長所を活かすもので、プログラムでは実行できないアクションを必要とするサインオン・シナリオの解決方法として望ましい方式です。可能な場合は常にコントロールIDを使用してフォームと対話する一方で、キーストロークおよびマウス・クリックを送信して、フィールドのフォーカス設定、チェック・ボックスの選択、エージェントがターゲット・アプリケーション内ではプログラムで実行できないその他のアクションなどのタスクを実行します。

注意:

この混合モードを実装するには、最初にSendKeysレスポンス方式を使用するようにフォームを構成し、目的のSendKeysアクションを構成し、そのアクションの構成中に、プログラム的なコントロールIDレスポンス方式を保持するアクションに対して「Inject directly into control」オプションを有効にします。

たとえば、カスケード検証のために特定の順序でフィールドに移入する必要がある場合(つまり、ユーザー名フィールドに移入されたときにかぎりパスワード・フィールドがアクティブになる場合)、コントロールIDを使用して資格証明をフィールドに注入しますが、各フィールドの注入の合間にSendKeysで[Tab]キーストロークを送信してフィールドのフォーカスを移動することになります。

1.4 フォームの最適な構成の確認

フォームの構成を行う際に、この項の情報を使用して、ターゲット・アプリケーションの要件および機能に基づいて最適な構成を確認します。

1.4.1 ログオン・フォームの最適な構成の確認

image005.pngについては周囲のテキストで説明しています。

1.4.1.1 ターゲット・ウィンドウは非一意ですか

エージェントがターゲット・ウィンドウを他のウィンドウから一意に区別できない場合(つまり、別のウィンドウのウィンドウ・タイトル、クラスまたはモジュール名、あるいはそのすべてがターゲット・ウィンドウと同一である場合)、エージェントはターゲット・ウィンドウの他にこれらのウィンドウに誤って応答する場合があります。この問題の原因および解決手順については、「ウィンドウ検出のトラブルシューティング」を参照してください。

1.4.1.2 ターゲット・ウィンドウのタイトルは空白または動的ですか

ウィンドウ・タイトルが空白の場合は特別な構成は必要ありませんが、ウィンドウ・タイトルに動的なテキストを使用している場合は正規表現または環境変数を使用して照合することができます。詳細は、「マッチングの使用によるレスポンス精度の向上」を参照してください。

1.4.1.3 ターゲット・ウィンドウのクラスは動的ですか

ターゲット・ウィンドウのウィンドウ・クラスが部分的に、または完全に動的な場合、エージェントがそのタイトルで一意にターゲット・ウィンドウを識別できるようにマッチングを使用する必要があります。詳細は、「マッチングの使用によるレスポンス精度の向上」を参照してください。

1.4.1.4 ターゲット・フィールドとコントロールが「Form」ウィザードで表示されますか

ほとんどの場合、「Form」ウィザードはターゲット・ウィンドウに存在する資格証明フィールドおよびコントロールを正常に検出して表示します。「Form」ウィザードにフィールドまたはコントロールが表示されない場合、またはリストされる項目がターゲット・ウィンドウのフィールドまたはコントロールと対応しない場合は、SendKeysを使用してフィールドまたはコントロールと対話する必要がある場合があります。詳細は、「サポートされるフォーム・レスポンス方式」を参照してください。

1.4.1.5 フォームのコントロールIDは非一意または動的ですか

サインオン用に有効にする資格証明フィールドおよびコントロールを特定したら、そのコントロールIDが一意であることを確認します。重複があった場合、アプリケーションへのLogon Managerのレスポンスの信頼性が低くなる可能性があるため、問題のフィールドおよびコントロールとの対話には序数を使用します。詳細は、「サポートされるフォーム・レスポンス方式」を参照してください。

1.4.2 パスワード変更フォームの最適な構成の確認

image009.pngについては周囲のテキストで説明しています。

image016.pngについては周囲のテキストで説明しています。

1.4.2.1 ログオン・フォームとパスワード変更フォームは同一画面上にありますか

アプリケーションによっては、ユーザー名フィールドや「Change Password」ボタンなど、ログオン関連のフィールドまたはコントロールを含むパスワード変更フォームを表示する場合があります。たとえば、次に示すログオン画面には「Change」ボタンがあります。

image002.pngについては周囲のテキストで説明しています。

この「Change」ボタンは、パスワード変更画面を起動します。

image017.pngについては周囲のテキストで説明しています。

「Auto Submit」機能が有効で、エージェントがこのようなアプリケーションに応答する場合は、パスワードの変更オプションが表示されず、ユーザーは自動的にログインされます。

ユーザーが目的のアクションを選択できるようにするには、テンプレートでログオン・フォームおよびパスワード変更フォームを定義します。エージェントは、ログオン・フォームおよびパスワード変更フォームが統合されたアプリケーションに応答する場合は、ユーザーに目的のアクション(ログオンまたはパスワード変更)を選択するように求めます。

注意:

アクション・チューザ機能に猶予期間を構成するオプションもあります(猶予期間の間は、推奨されるアクションがログオンであり、目的のアクションを選択することを求められずにユーザーがログオンすることをエージェントが自動的に想定します)。このオプションは「Action Chooser Grace Period」という名称で、アプリケーション・テンプレートの「Miscellaneous」タブで利用できます。

1.4.2.2 ログオン・フォームとは異なるタブにパスワード変更フォームはありますか

ログオン・フォームとパスワード変更フォームをテンプレートで定義します。エージェントは、パスワードの変更が開始されるとパスワード変更タブに自動的に切り替わり、パスワード変更フォーム・タブを別のウィンドウとして扱います。

注意: WinAPI仕様に完全に準拠するタブを実装するアプリケーションのみがサポートされます。

1.4.2.3 パスワード変更を開始するためにアクションは必要ですか

フォームでパスワード変更を開始するアクションが必要な場合(チェック・ボックスの選択など)に、エージェントがそのアクションをプログラム的には実行できないときは、SendKeysを使用して、アプリケーションにキーストロークまたはマウス・クリック(あるいはその両方)を送信してそのアクションを完了する必要がある場合があります。詳細は、「サポートされるフォーム・レスポンス方式」を参照してください。

1.4.2.4 ターゲット・ウィンドウは非一意ですか

エージェントがターゲット・ウィンドウを他の類似のウィンドウから一意に区別できない場合、つまりウィンドウ・タイトル、クラスおよびモジュール名がターゲット・ウィンドウと同一である別のウィンドウがインスタンス化されている場合、エージェントはターゲット・ウィンドウの他にこのようなウィンドウに誤って応答する場合があります。この問題の原因および解決手順については、「ウィンドウ検出のトラブルシューティング」を参照してください。

1.4.2.5 ターゲット・ウィンドウのタイトルは空白または動的ですか

1.4.2.6 ターゲット・ウィンドウのクラスは動的ですか

1.4.2.7 ターゲット・フィールドとコントロールが「Form」ウィザードで表示されますか

1.4.2.8 フォームのコントロールIDは非一意または動的ですか

1.4.2.9 アプリケーションで新しいパスワードの確認は必要ですか

アプリケーションによっては、パスワードの変更を実行する際に、ユーザーに新しいパスワードの確認を求めます。ターゲット・アプリケーションでこのようなダイアログを表示する場合は、パスワード変更フォームを構成し、確認ダイアログに応答するように「Confirm Password」フォームを構成します。詳細は、「フォームの構成」を参照してください。

1.4.2.10 アプリケーションでパスワード変更の成功または失敗のダイアログ(あるいはその両方)を表示しますか

アプリケーションによっては、パスワード変更の成功または失敗を示すメッセージを表示します。その場合は、アプリケーション・テンプレートでパスワード変更の成功フォーム、またはパスワード変更の失敗フォームを定義します。詳細は、「フォームの構成」を参照してください。

1.5 フォームの構成

この項の手順は、このガイドの前の方で説明した概念および用語を使用して説明します。この項の手順を実行するときは、「フォームの最適な構成の確認」を参照して、ターゲット・アプリケーションに最も適した構成を決定してください。この項の手順を完了する前に、Logon Managerが実行されていることを確認してください。

1.5.1 コントロールIDを使用したフォームの構成

コントロールIDレスポンス方式を使用するWindowsアプリケーション・フォームを構成するには、次の手順を実行します。

Logon Manager管理コンソールを開きます。デフォルトでは、ショートカットは「Start」→「Programs」→「Oracle」→「ESSO Administrative Console」にあります。

左側のツリーで、「Applications」ノードを選択し、次のいずれかを実行します。

新規テンプレートを作成してログオン・フォームを定義する場合、右側のペインで「Add」をクリックして、「Add Application」ダイアログに、わかりやすいテンプレート名を入力し、「Finish」をクリックします。新しいテンプレートが、格納済テンプレートのリストに表示されます。

注意:

2つ以上のアプリケーション・テンプレートに対して、テンプレートのいずれかの名前が別のテンプレートの名前の先頭部分と同じになるように名前を付けると、エージェントは誤って最も短い名前を持つテンプレートを使用して、すべての対象アプリケーションに応答します。この動作を回避するには、テンプレート名が同じテキスト文字列で始まらないようにします。

ログオン・フォームの定義を既存のテンプレートに追加する場合、「Applications」ノードを拡張して目的のテンプレート(テンプレートは右側のペインに表示されます)を選択し、ペイン下部の「Add」をクリックします。

image018.pngについては周囲のテキストで説明しています。

表示された「Form」ウィザードで、ターゲット・フォームへの応答時に、エージェントと対話させるフィールドおよびコントロールを構成します。「Form Type」画面で、目的のフォーム・タイプを選択して「Next」をクリックします。
「Target Computer」画面で、次のいずれかを選択します。
- Local Computer - ローカル・マシンで実行されているターゲット・アプリケーション用。
- Remote Computer - Logon Managerがインストールされている別のマシンで実行されているターゲット・アプリケーション用。このオプションを使用するには、リモート・マシン上のLogon Managerのリモート構成を手動で有効にする必要があります。手順の詳細は、『Oracle Enterprise Single Sign-On Logon Manager管理者ガイド』を参照してください。

「Application Window」画面で、「Application type」ドロップ・ダウン・メニューから適切なアプリケーション・タイプを選択してから、ターゲット・フォームを含むウィンドウを選択します。選択したウィンドウの周囲には太い赤色の境界線が表示され、選択されたことが示されます。

注意:

複数のウィンドウのいずれかのパラメータで同じ値が使用されている場合、エージェントはターゲット・ウィンドウのみに応答するのではなく、これらすべてのウィンドウに誤って応答する可能性があります。この問題の詳細は、「ウィンドウ検出のトラブルシューティング」を参照してください。

「Credential Fields」画面で、次のようにリスト内のオブジェクトの中からターゲット・フィールドおよびコントロールを選択して構成します。

(オプション)フォームの複数のフィールドに同じデータを注入する必要がある場合(たとえば、「Password」および「Confirm Password」フィールドへのパスワードの注入)、「Allow multiple field designation」オプションを有効にします。

目的の各フィールドまたはコントロールを右クリックし、コンテキスト・メニューからその機能を選択します。

注意:

ほとんどの場合「Detect Fields」機能は正確ですが、正確性を保証するためにも、常にフィールドおよびコントロールを手動で構成することをお薦めします。

アプリケーションで、Logon ManagerがそのフィールドおよびコントロールとSendKeys方式で対話する必要がある場合(キーストロークやマウス・クリックなどのユーザー入力をエミュレートする場合)は、「Use "SendKeys" for this form instead of IDs」を選択します。アプリケーションでこのオプションが必要かどうかを確認するには、「フォームのレスポンスの理解」を参照してください。
アプリケーションで、Logon Managerがそのフィールドおよびコントロールの特定にコントロールIDではなく序数を使用する必要がある場合は、「Use ordinals instead of control IDs」を選択します。(アプリケーションでこのオプションが必要かどうかを確認するには、「フォームのレスポンスの理解」を参照してください)。

「Summary」画面で、構成の選択内容を確認します。選択したオプションを変更する場合は「Back」をクリックし、変更がない場合は「Finish」をクリックします。

表示されたテンプレート・プロパティ・ダイアログで、「OK」をクリックして新しいフォーム定義を保存します。 image023.pngについては周囲のテキストで説明しています。

注意:

テンプレートに追加のオプションを構成する必要があり、その場所と機能がわかっている場合は、ここで実行できます。このダイアログに存在するオプションの構成手順については、このガイドの後半を参照してください。

該当する場合、「リポジトリへのテンプレートの公開」の説明に従って、リポジトリに変更を公開します。

1.5.2 SendKeysを使用したフォームの構成

SendKeysレスポンス方式を使用するWindowsアプリケーション・フォームを構成するには、次の手順を実行します。

Logon Manager管理コンソールを開きます。デフォルトでは、ショートカットは「Start」→「Programs」→「Oracle」→「ESSO Administrative Console」にあります。

左側のツリーで、「Applications」ノードを選択し、次のいずれかを実行します。

新規テンプレートを作成してログオン・フォームを定義する場合、右側のペインで「Add」をクリックして、「New Application」ダイアログに、わかりやすいテンプレート名を入力し、「Finish」をクリックします。新しいテンプレートが、格納済テンプレートのリストに表示されます。

注意:

ログオン・フォームの定義を既存のテンプレートに追加する場合、「Applications」ノードを拡張して目的のテンプレート(テンプレートは右側のペインに表示されます)を選択してから、ペイン下部の「Add」をクリックします。

表示された「Form」ウィザードで、ターゲット・フォームへの応答時に、エージェントと対話させるフィールドおよびコントロールを構成します。「Form Type」画面で、目的のフォーム・タイプを選択して「Next」をクリックします。
「Target Computer」画面で、次のいずれかを選択します。
- Local Computer - ローカル・マシンで実行されているターゲット・アプリケーション用。
- Remote Computer - Logon Managerがインストールされている別のマシンで実行されているターゲット・アプリケーション用。このオプションを使用するには、リモート・マシン上のLogon Managerのリモート構成を手動で有効にする必要があります。手順の詳細は、『Oracle Enterprise Single Sign-On Logon Manager管理者ガイド』を参照してください。

注意:

「Credential Fields」画面で、「Use "Send Keys" for this form instead of IDs」を選択し、「Next」をクリックします。
「Summary」画面で、構成の選択内容を確認します。選択したオプションを変更する場合は「Back」をクリックし、変更がない場合は「Finish」をクリックします。
表示されたテンプレート・プロパティ・ダイアログで、「Fields」タブを選択します。
「Edit」をクリックして、「SendKeys」エディタ・ダイアログを表示します。

必要に応じてSendKeysアクションを構成します。各オプションの詳細は、コンソールのヘルプを参照してください。

注意:

フォームがSendKeysモードである場合に、アクションをプログラム使用(つまり、コントロールIDレスポンス方式を使用)として構成するには、アクションの「Inject directly into control」オプションを有効にします。

終了したら「OK」をクリックして変更を保存し、「SendKeys」エディタ・ダイアログを終了します。

注意:

フォーム・プロパティ・ダイアログの「OK」をクリックして、フォーム構成を保存します。
該当する場合、「リポジトリへのテンプレートの公開」の説明に従って、リポジトリに変更を公開します。

1.5.3 MS UIA(ユーザー・インタフェース・オートメーション)を使用したフォームの構成

xxxx

1.5.4 マッチングの使用によるレスポンス精度の向上

マッチングは、Logon Managerがウィンドウおよびそのウィンドウ内のフォームを、同じセッション内に存在する可能性のある他のウィンドウおよびフォームから一意に区別できるメカニズムです。マッチングという用語は、ウィンドウ・タイトルやフィールド・ラベルなどの特定のパラメータ値を、テンプレートに格納されている値と照合することを指します。

たとえば、アプリケーションで、情報メッセージ、ウィザード、ログオン・フォームなどの様々な目的に使用されるが、同じウィンドウ・タイトルとクラスを共有するダイアログ・ボックスをインスタンス化する場合があります。このような場合、エージェントのレスポンスを特定のフォームに制限するために、一意の要素に対するマッチングを構成することになります。

Logon Managerでは、次の基準の値に対するマッチングが可能です。

ウィンドウのタイトル(空白、および部分的または完全に動的な値を含む)
ウィンドウのクラス(特定の値に対する制限を含む)
実行可能ファイル名(モジュール名とも呼ばれる)
フィールド、コントロールまたはテキスト文字列

1.5.4.1 空白または動的値のマッチング

Microsoft .NETフレームワークでサポートされる正規表現を使用すると、基準に対してエージェントが一致すると認識する必要があるテキスト・パターンを作成することもできます。? (1文字)や* (スペースを除く文字の任意の組合せ)などのワイルドカードは、最も一般的に使用される正規表現です。

例:

Je???eは、JeanneとJessieの両方と一致します。ただし、Jeanineとは一致しません(文字列の長さも、文字の順序も一致しないためです)。
Je*eは、Jeで始まり、eで終わるすべての語と一致し、前述の3つの例は、この場合はすべて一致します。
Afx:400000:0:10011:0:*は、下6桁が変数であるすべてのウィンドウ・クラスに一致します。この場合、Afx:400000:0:10011:0:130927が一致します。

ターゲット基準(ウィンドウ・タイトルなど)に1つ以上のシステム変数(現在ログインしているユーザー名など)が含まれる場合、照合するテキスト・パターンの一部としてそれらの変数名を使用できます。たとえば、次のパターンは、「Password Expired - 」で始まり、現在ログオンしているユーザーの名前を大文字で含むウィンドウ・タイトルに一致します。

パスワードの期限切れ - %UC%%DOMAINUSER%

次を照合します。

部分的または完全に動的な値: ターゲット・パラメータ値に対して一致するテキスト文字列を作成するために、必要に応じて、正規表現、環境変数および静的テキストを使用します。
空白値: 値としてnullの正規表現^$を指定します。

注意:
空白のウィンドウ・タイトルは自動でサポートされるために、特別な構成は必要ありません。

この項の手順を実行する前に、次の手順を実行します。

Logon Manager管理コンソールを起動します。
左側のペインのツリーで「Applications」ノードを展開し、目的のテンプレートを選択します。
右側のペインで、「General」タブを選択します。
「Edit」をクリックして、フォーム・プロパティ・ダイアログを表示します。
目的の手順に進みます。

1.5.4.2 ウィンドウ・タイトルのマッチング

1つ以上の静的または動的なウィンドウ・タイトルを照合するには、次の手順を実行します。

テンプレート・プロパティ・ダイアログで、「Identification」タブを選択します。
「Window Titles」セクションで、次のいずれかを実行します。
- 新しいマッチング・ルールを追加するには、「Add」をクリックします。
- 既存のマッチング・ルールを変更するには、リストでルールを選択し、「Edit」をクリックします。
「」ダイアログで、目的のマッチング・タイプを選択します。
- 「Exact」: 入力されたとおりの文字列に正確に一致します。静的ウィンドウ・タイトルに対して使用します。
- 「Wildcard」: テキストとワイルドカードを組み合せたマッチングが可能です。空白または動的なウィンドウ・タイトルに対して使用します。
- 「Regular expression」: テキストと正規表現を組み合せたマッチングが可能です。動的ウィンドウ・タイトルに対して使用します。
詳細は、「空白または動的値のマッチング」を参照してください。
エージェントがマッチングを実行する対象のテキスト文字列を入力します。
「OK」をクリックして、新しいマッチング・ルールを追加します。
「OK」をクリックして、プロパティ・ダイアログを閉じます。

1.5.4.3 ウィンドウ・クラスのマッチング

1つ以上の静的または動的なウィンドウ・クラスを照合するには、次の手順を実行します。

フォーム・プロパティ・ダイアログで、「Matching」タブを選択します。
許可されるウィンドウ・クラスを、次のように指定します。
- 指定しようとするクラスの値が正確にはわからない場合、「Allowable Class」フィールドで「Choose」をクリックし、表示されるダイアログでターゲット・ウィンドウを選択して、「OK」をクリックします。選択したウィンドウのクラスが、「Allowable Class」フィールドに移入されます。
- エージェントで認識する必要があるクラスの正確な値を知っている場合は、「Allowable Class」フィールドにカンマ区切りのリストとして入力します。1つ以上の動的なウィンドウ・クラスを照合する場合は、「Regular Expression」チェック・ボックスを選択し、必要な正規表現をリストに含めます。
エージェントで無視する(応答しない)ウィンドウ・クラスを、次のように指定します。
- 指定しようとするクラスの値が正確にはわからない場合、「Ignore this window class」フィールドで「Choose」をクリックし、表示されるダイアログでターゲット・ウィンドウを選択して、「OK」をクリックします。選択したウィンドウのクラスが、「Ignore this Window Class」フィールドに移入されます。
  
  エージェントで認識する必要があるクラスの正確な値を知っている場合は、「Ignore this Window Class」フィールドにカンマ区切りのリストとして入力します。1つ以上の動的なウィンドウ・クラスを照合する場合は、「Regular Expression」チェック・ボックスを選択し、必要な正規表現をリストに含めます。
「OK」をクリックして、プロパティ・ダイアログを閉じます。

1.5.4.4 実行可能ファイル名のマッチング

特定の実行可能ファイル名を照合するには、次の手順を実行します。

注意:

実行可能ファイル名のマッチングでは、完全一致のみがサポートされます。ワイルドカードまたは正規表現はサポートされていません。

フォーム・プロパティ・ダイアログで、「Identification」タブを選択します。
「AppPath Keys」セクションで、次のいずれかを実行します。
- 新しいマッチング・ルールを追加するには、「Add」をクリックします。
- 既存のマッチング・ルールを変更するには、リストでルールを選択し、「Edit」をクリックします。
「AppPath Key」ダイアログで、目的の値を入力して「OK」をクリックします。
「OK」をクリックして、テンプレート・プロパティ・ダイアログを閉じます。

1.5.4.5 フィールド、コントロールまたはテキスト文字列のマッチング

「Matching」タブを使用して、現在選択しているログオンのユーザー資格証明を、同じアプリケーション内の他のログオン・フォーム、パスワード変更フォームまたはパスワード確認フォームにマップします(ここでは、これらのフォームをターゲット・フォームと呼びます)。エージェントは、ユーザーが指定する一致基準を使用して、同じ資格証明データを使用する類似フォームを区別します。これにより、エージェントは、1組のユーザー資格証明をこのような複数のフォームに適切に適用できます。また、マッチングを使用して、エージェントで無視するフォームを識別することもできます。

特定のフィールドまたはコントロールを照合するには、次の手順を実行します。

テンプレート・プロパティ・ダイアログで、「Matching」タブを選択します。
「Matches」セクションで、次のいずれかを実行します。
- 新しいマッチング・ルールを追加するには、「Add」をクリックします。
- 既存のマッチング・ルールを変更するには、リストでルールを選択し、「Edit」をクリックします。
表示された「Control Match」ウィザードで、目的のマッチング・タイプを選択します。
「Application Window」画面で、ターゲット・ウィンドウを選択します。
表示された「Match Fields」画面で、目的の一致ルールを構成します。一致させようとする各フィールド、コントロールまたはテキスト文字列について、リストで目的の項目を選択して右クリックしてから、コンテキスト・メニューから目的の一致基準を選択します。
- Class: この項目の数値のクラス値を照合するように、エージェントに指示します。
- Style: この項目の数値のスタイル値を照合するように、エージェントに指示します。
- Text: この項目で表されるテキストを照合するように、エージェントに指示します。入力を求められたら、表示されたダイアログ・ボックスに目的の一致文字列を入力して、「OK」をクリックします。
選択後に、「Next」をクリックします。

「Credential Fields」画面で、一致した場合に、エージェントがログオンを完了するために使用する資格証明フィールドおよびコントロールを選択して構成します。

目的の各フィールドまたはコントロールを右クリックし、コンテキスト・メニューからその機能を選択します。

注意:

送信ボタン(通常は「OK」、「Logon」などのラベルが付いているボタン)がリストに表示されない場合でも、Logon Managerは資格証明の注入後に、アプリケーションに送信アクションを送信します。

アプリケーションで、Logon ManagerがそのフィールドおよびコントロールとSendKeys方式で対話する必要がある場合(キーストロークやマウス・クリックなどのユーザー入力をエミュレートする場合)は、「Use "SendKeys" for this form instead of IDs」を選択します。(アプリケーションでこのオプションが必要かどうかを確認するには、「フォームのレスポンスの理解」を参照してください)。
アプリケーションで、Logon Managerがそのフィールドおよびコントロールの特定にコントロールIDではなく序数を使用する必要がある場合は、「Use ordinals instead of control IDs」を選択します。(アプリケーションでこのオプションが必要かどうかを確認するには、「フォームのレスポンスの理解」を参照してください)。
「Next」をクリックします。

「Summary」画面で、構成の選択内容を確認します。選択したオプションを変更する場合は「Back」をクリックし、変更がない場合は「Finish」をクリックします。

1.5.5 サービス・ログオンとしてのアプリケーションの構成

Logon Managerで最初にアプリケーション・ウィンドウが検出された後に、そのコンテンツが変更される場合は、アプリケーションをサービス・ログオンとして構成する必要があります。

注意:

このオプションを有効にすると、Logon Managerはアプリケーションのウィンドウの更新がないかアクティブにポーリングし、CPU時間の消費が増えるため(ポーリング対象のウィンドウの追加ごとに増加する)、他の検出オプションをすべて使用した後でのみ使用してください。

アプリケーションをサービス・ログオンとして構成するには、次の手順を実行します。

目的のテンプレートを開きます。
「Miscellaneous」タブを選択し、「Service Logon」チェック・ボックスをチェックします。
アプリケーションのウィンドウ・クラスを取得します。
1. 「General」タブを選択します。
2. フォーム定義のリストで、ログオン・フォームを選択し、「Edit」をクリックします。
3. フォーム・プロパティ・ダイアログで「Matching」タブを選択し、「Allowable Class」フィールドに存在する値を書き留めます(これは、Logon Managerによってアプリケーションで検出されたウィンドウ・クラスです)。
変更を保存し、更新されたテンプレートをリポジトリにプッシュします(該当する場合)。
アプリケーションのウィンドウ・クラスを、ウィンドウ・クラスのリストに追加します(エージェントはこれをシステム・サービスとして認識します)。
1. グローバル・エージェント設定のセットをロードします。
2. 左側のツリーで、「Global Agent Settings」→「End-User Experience」→「Application Response」→「Windows Application」の順にナビゲートします。
3. 「Supported Window Classes for Services」オプションの横のチェック・ボックスがまだ選択されていない場合は、これを選択します。
4. 前述のオプションの横のフィールドに、手順3cで書き留めたウィンドウ・クラスを既存のクラスのリストに、セミコロンで区切って追加します。
変更を保存し、更新した「Supported Window Classes for Services」設定を、管理オーバーライドの一部としてリポジトリにプッシュします。

1.5.6 自動SendKeysフォールバックの無効化

Logon Managerがアプリケーションにプログラム的に応答(コントロールID方式を使用)することができない場合、デフォルトでは、それは自動的にSendKeysレスポンス方式にフォール・バックして、注入を再試行します。特定のシナリオでは、この自動フォールバック動作が望ましくない場合があります(たとえば、Logon Managerは間違ったウィンドウまたはアプリケーションに資格証明を誤って注入し、その資格証明がエンド・ユーザーに公開される場合があります)。この自動フォールバック動作を無効にするには、次のいずれかを実行します。

特定のフォーム定義の自動SendKeysフォールバックを無効にするには、フォームのプロパティ・ダイアログの「Options」タブで「Fall back to SendKeys if direct injection fails」オプションを無効にします。
自動SendKeysフォールバックをグローバルに無効にするには、「Global Agent Settings」→「<Target Settings Set>」→「User Experience」→「Application Response」の下の「Allow fallback from control IDs to SendKeys」オプションを、「No」に設定し、変更をリポジトリに公開します。

1.6 フォームの構成のテスト

フォームを作成して構成したら、公開前に次の手順を実行してテストします。

左側のツリーの「Applications」ノードを展開し、ターゲット・テンプレートにナビゲートします。
ターゲット・テンプレートを右クリックし、コンテキスト・メニューから「Test」を選択します。
表示された「Logon Manager Template Test Manager」ウィンドウで、次の手順を実行します。
1. 「Forms」ペインで、ターゲット・フォームを選択します。
2. 「Interactions」ペインに表示される手順に従います。
3. エージェントが期待どおりにアプリケーションに応答し、テストが正常に完了した場合、「Finish」をクリックします(エージェントが期待どおりにアプリケーションに応答しなかった場合は、「Close」をクリックし、この項のトラブルシューティング・フローチャートに従って問題を確認して修正し、手順1-3を繰り返して修正後の構成をテストします)。

1.6.1 ログオン・フォームの構成のテスト

image043.pngについては周囲のテキストで説明しています。

1.6.1.1 エージェントはウィンドウを検出しますか

エージェントにテンプレートが提供されると、自動レスポンス機能が明示的に無効化されていないかぎり、ターゲット・アプリケーションに自動的に応答します。エージェントがアプリケーションへの応答に失敗した場合は、「ウィンドウ検出のトラブルシューティング」を参照してください。

1.6.1.2 エージェントは資格証明を注入しますか

資格証明がユーザーのストア内のターゲット・アプリケーションに対して格納されている場合、エージェントはアプリケーションの検出に成功すると、資格証明を適切なフィールドに注入します。「Auto-Submit」機能が明示的に無効化されていないかぎり、エージェントは自動的に資格証明の送信も行います。資格証明の注入に失敗した場合は、「コントロールIDを使用する場合のフォームのレスポンスのトラブルシューティング」および「SendKeysを使用する場合のフォームのレスポンスのトラブルシューティング」を参照してください。

1.6.1.3 ログアウトでログオン・ループが発生しますか

アプリケーションによってはログアウト時にログオン画面を表示しますが、この場合、それによってエージェントがログオン・ループに入り、エージェントを停止しないかぎり、事実上ユーザーはアプリケーションからログアウトできなくなります。これが発生した場合は、「ログオン・ループのトラブルシューティング」を参照してください。

1.6.1.4 エージェントはアプリケーションの再起動後に適切に応答していますか

ターゲット・アプリケーションが停止され、再起動されると、エージェントはアプリケーションに応答し、ユーザーをログオンさせる必要があります。ログオンが発生しない場合は、アプリケーションがユーザー領域ではなくシステム領域で動作することが可能であり、その際はエージェントが監視するパッシブ・メッセージ・キューのかわりにアクティブなポーリングが必要になります。これに該当する場合は、「サービス・ログオンとしてのアプリケーションの構成」を参照してください。

1.6.2 パスワード変更フォームの構成のテスト

image047.pngについては周囲のテキストで説明しています。

1.6.2.1 エージェントはウィンドウを検出しますか

エージェントにテンプレートが提供されると、自動レスポンス機能が明示的に無効化されていないかぎり、ターゲット・アプリケーションに自動的に応答します。エージェントがアプリケーションへの応答に失敗した場合は、「ウィンドウ検出の理解」を参照してください。

1.6.2.2 エージェントは資格証明を注入および送信しますか

エージェントはパスワードの変更を検出すると、「Auto Submit」機能が明示的に無効化されていないかぎり、資格証明を適切なフィールドに注入し、アプリケーションに送信します。資格証明の注入が不安定であるか、まったく行われない場合は、「コントロールIDを使用する場合のフォームのレスポンスのトラブルシューティング」および「SendKeysを使用する場合のフォームのレスポンスのトラブルシューティング」を参照してください。

1.6.2.3 新しいパスワードはアプリケーションのパスワード・ポリシーを満たしますか

Logon Managerで生成される新規パスワードがアプリケーション独自のパスワード・ポリシーを満たさない場合、パスワード変更は失敗します。これに該当するかどうかを確認する場合は、現在エージェントにデプロイされているパスワード生成ポリシーを、ターゲット・アプリケーションのパスワード・ポリシーと比較し、パスワード変更の失敗の原因となる可能性がある非一貫性をすべて修正します。

1.6.2.4 エージェントはパスワード変更フォームにログオンと同様に応答しますか

エージェントがパスワード変更フォームに対して、ログオン・フォームと同様に応答する場合(つまり、エージェントがユーザーの現在格納されている資格証明を注入および送信する場合)は、次の項目をチェックします。

テンプレートの構成ミス(誤ったフォーム・タイプ、フィールドおよびコントロール定義など)
パスワード変更フォームに動的ウィンドウ・タイトルまたはクラスが含まれるかどうかを確認し、それに応じてテンプレートを構成します。
マッチングを使用している場合は、正しいマッチング・タイプを使用しているかどうかを確認し、マッチング文字列にエラーがないか検証します。

1.7 リポジトリへのテンプレートの公開

アプリケーション・テンプレートのテストが正常に終了したら、リポジトリ内の選択したターゲット・コンテナにディレクトリ形式の階層で(デフォルト)、またはフラット形式の構成ファイルとして公開することで、エンドユーザー・マシンに配付できます。

注意:

Logon Managerをリポジトリとともにデプロイする方法およびリポジトリ・ツリー構築のベスト・プラクティスの詳細は、ご使用のプラットフォームに適した『ディレクトリ・ベースのリポジトリでのLogon Managerのデプロイ』ガイドを参照してください。

この手順を実行する前に、リポジトリの構造および構成を熟知していることを確認します。

目的のテンプレートおよびその他の構成オブジェクトを選択し、リポジトリに公開するには、次の手順を実行します。

Logon Manager管理コンソールを起動します。
「Applications」ノードを右クリックし、コンテキスト・メニューから「Publish…」を選択します。「Publish to Repository」ダイアログが表示されます。

「Available configuration objects」リストで、目的のオブジェクトにナビゲートして選択します。

注意:

オブジェクトが構成されているカテゴリのみが、このリストに表示されます。たとえば、パスワード生成ポリシーが存在しない場合、対応するカテゴリはこのリストに表示されません。

「>>」をクリックして、選択したオブジェクトを「Selected objects to be published」リストに移動します。(このリストからオブジェクトを除去して公開しないようにするには、オブジェクトを選択して、「<<」をクリックします。)

選択したオブジェクトを公開する対象のコンテナを選択します。

以前、目的のコンテナに公開したことがある場合は、「Target Repository」ドロップダウン・リストからそれを選択します。

以前、目的のコンテナに公開したことがない場合、または目的のコンテナ・パスが「Target Repository」ドロップダウン・リストに表示されない場合は、「Browse」機能を使用して目的のコンテナを検索して選択する必要があります。

「Browse」をクリックして、ディレクトリ・ツリーを参照します。

注意:
ディレクトリにまだ接続していない場合は、必要な接続情報を提供するようにコンソールから求められます。

表示された「Browse for Repository」ダイアログで、目的のコンテナにナビゲートして選択します。 image050.pngについては周囲のテキストで説明しています。

注意:

新しいコンテナを作成する場合は、目的の親コンテナを右クリックし、コンテキスト・メニューから「New Container」を選択し、新しいコンテナの目的の名前を入力し、「OK」をクリックしてプロセスを完了します。

(オプション)構成オブジェクトをフラット形式で格納する必要がある環境の場合は、個々のオブジェクトとしてでなく、構成ファイルで「Store selected items」チェック・ボックスを選択します。

注意:

目的のコンテナに存在する場合、このオプションを選択することで、既存の構成ファイルに格納されているすべての項目が上書きされます。

(オプション)初回使用オブジェクト(FTUList)を作成する場合は、対応するチェック・ボックスを選択します。

注意: このオプションは、手順6でフラット形式での構成オブジェクトの格納を選択した場合のみ、アクティブになります。

「Publish」をクリックします。コンソールは、選択したオブジェクトをターゲット・リポジトリに公開します。

注意:

公開プロセスが完了するまで、ダイアログを終了したり、コンソールを閉じようとしないでください。オブジェクトが公開されると、ダイアログは自動的に閉じます。

公開プロセスの詳細は、Logon Manager管理コンソールのヘルプを参照してください。

1.8 ウィンドウ検出のトラブルシューティング

不安定なウィンドウ検出を診断するには、次のステップを使用します。

image055.pngについては周囲のテキストで説明しています。

1.8.1 エージェントはウィンドウを検出しますか

エージェントがウィンドウを検出しない場合は、ターゲット・フォーム定義のプロパティ・ダイアログの「Options」タブにある「Auto-Recognize」オプションが有効になっていることを最初に確認し、有効である場合は次のステップに進みます。

1.8.2 エージェントがターゲット・ウィンドウのみでなく、他のウィンドウにも応答しますか

テンプレートで定義されている特性を備えるすべてのウィンドウにエージェントが応答するため、デフォルトのフォーム構成(フォーム・ウィザードを完了することによって作成)を使用すると、本来無視する必要があるウィンドウに対して不要なレスポンスが行われることがあります。エージェントがターゲット・ウィンドウを一意に識別できるように、できるだけ特定されるようなテンプレートを構成する必要があります。

注意:

この状況は、エージェントが一意に区別できない複数のサインオン・イベントが発生しているため、重複イベント・モデルと呼ばれることがあります。

より詳細なレスポンス・コントロールが必要かどうかを判断するには、テンプレートを作成するときに「Form Wizard」ウィンドウ内のリストで、重複するウィンドウ・タイトル、モジュール名およびウィンドウ・クラスを調べます。次の例では、Login Testerアプリケーションの2つのインスタンスがモジュール(親プロセス)名とウィンドウ・クラス値を共有しているため、エージェントには同じアプリケーションとして認識されます。

このような場合は、ウィンドウとフォームをエージェントで一意に識別できる基準値に、さらに詳細な制約を設定するようなマッチングを使用する必要があります。

image057.pngについては周囲のテキストで説明しています。

1.8.3 「Logon Using Logon Manager」トレイ・アイコン・オプションを使用したときに、エージェントはウィンドウを検出しますか

エージェントのシステム・トレイ・アイコンの「Logon Using Logon Manager」オプションを使用して手動でウィンドウ検出を実行してから、次のいずれかを実行します。

エージェントがウィンドウを検出した場合は、アプリケーションをサービス・ログオンとして構成する必要があることがあります(次のステップに進みます)。
エージェントのトレイ・アイコンから「Logon Using Logon Manager」オプションを使用して手動で検出を起動しても、エージェントがターゲット・ウィンドウを検出しなかった場合は、ウィンドウ・タイトルやクラスの入力ミスのような、共通構成エラーのテンプレートを確認し、ウィンドウ・タイトルまたはクラスが動的であるかどうかを確認して、テンプレートを適切なものに構成し直してください。

1.8.4 サービスまたは現行ユーザー以外のユーザーでアプリケーションを実行していますか

アプリケーションが、ユーザー領域(現在ログインしているユーザーのアカウント下)ではなく、システム領域(SYSTEMアカウントの下)で動作しているか、または、アプリケーションが現在ログインしているユーザーとは異なるユーザー・アカウントで起動されている場合は、サービス・ログオンとして構成する必要があります。これによってエージェントは、現在ログオンしているユーザーのWindowsメッセージ・キューにあるイベントに対して受動的に応答するのではなく、アプリケーションをアクティブにポーリングすることができます。手順については、「サービス・ログオンとしてのアプリケーションの構成」を参照してください。

1.8.5 ウィンドウ・タイトルを検出後に変更しましたか

エージェントがウィンドウを検出した後、そのウィンドウに対する応答を開始する前にターゲット・ウィンドウのタイトルを変更した場合(たとえば、ログオン・フォームを起動したときにウィンドウ・タイトルを変更する場合)、そのアプリケーションをサービス・ログオンとして構成する必要があります。これによってエージェントは、現在ログオンしているユーザーのWindowsメッセージ・キューにあるイベントに対して受動的に応答するのではなく、アプリケーションをアクティブにポーリングすることができます。手順については、「サービス・ログオンとしてのアプリケーションの構成」を参照してください。

1.9 コントロールIDを使用する場合のフォームのレスポンスのトラブルシューティング

image060.pngについては周囲のテキストで説明しています。

1.9.1 エージェントがフィールドに移入してもログオンが送信されませんか

資格証明の挿入が、自動的に送信されたものではなかった場合、まず「Auto-Submit」オプションがアプリケーションで有効になっていることを確認します。「Auto Submit」を有効化しても、エージェントからアプリケーションに送信されない場合は、エージェントがフォールドに移入してから資格証明が送信されたかどうかを確認した後で、[Enter]を押します。資格証明が送信される場合は、テンプレートからSubmitアクションを削除し、これによってエージェントでデフォルトのsubmitアクション([Enter]キーストローク)を使用できるようになります。

1.9.2 アプリケーションは、注入された資格証明を拒否しますか

送信された資格証明がアプリケーションで拒否される場合は、そのアプリケーション・テンプレートでWM_CHARスタイルのメッセージングを有効にし、これによってエージェントが代替APIを使用して、ウィンドウのフィールドとコントロールと対話します。これを行うには、テンプレートの「General」タブを選択し、ターゲット・フォームを選択して「Edit」をクリックし、フォームのプロパティ・ダイアログの「Options」タブで、「Use WM_CHAR messages to fill controls」チェック・ボックスを選択します。

1.9.3 フィールドへの移入が不安定ですか

エージェントによるフィールドへの移入が不安定(誤った値、切り捨てられた値、文字化けした値または空白の値を取り込むなど)なときは、1つ以上のターゲットのコントロールIDが動的である場合があります。このような場合、コントロールIDのかわりに序数を使用して、フォーム内のフィールドとコントロールを一意に識別します。序数は、エージェントによってウィンドウ内の各オブジェクトに対して、上から下、左から右に割り当てられる連続したID番号で、これによってエージェントは検出されたフィールドとコントロールをコントロールIDとは別に一意に識別することができます。

コントロールIDではなく序数を使用するようにフォームを切り替えるには、テンプレートの「General」タブでフォームを選択し、「Edit」をクリックして、フォーム・プロパティ・ダイアログで「Wizard」をクリックします。その後、「コントロールIDを使用したフォームの構成」の手順に従ってフォーム定義を再作成しますが、「Credential Fields」画面が表示された場合は、「Use ordinals instead of control IDs」チェック・ボックスを選択します。ウィザードで行う新しい構成の選択によって、既存のフォーム定義が上書きされます。

序数を使用しても引き続き問題が発生する場合は、アプリケーションと対話する方法にSendKeysを使用することを検討します。詳細は、「SendKeysを使用したフォームの構成」を参照してください。

1.10 SendKeysを使用する場合のフォームのレスポンスのトラブルシューティング

image061.pngについては周囲のテキストで説明しています。

1.10.1 事前入力されたフィールドによって誤ったログオンが発生しますか

アプリケーションによっては、ログオン・フォームの表示時にログオン・フィールドの事前入力を行うことがあります(たとえば、ユーザー名のフィールドに、最後に正常にログオンしたユーザーの名前が事前入力されているなど)。1つ以上の[Backspace]または[Delete]キーストロークを送信して、資格証明を注入する前に、事前入力されたフィールドをクリアする必要がある場合があります。

1.10.2 カーソルは常に同じフィールドで開始して、フォーカスを保持しますか

カーソルが必ずしも同じフィールドで開始せず、エージェントによる移入前にフィールドがフォーカスを失う場合は、特定のホットキーの組合せ([Alt]+[U]など)または標準のWindowsキー([Tab]、矢印など)によるフィールドへのナビゲートがアプリケーションで許可されるかどうかを確認します。キーストロークを使用してフィールドにナビゲートできない場合は、次の例に示すとおり、エージェントがフィールド内でクリックできるように、ターゲット・フィールド内の座標ポイントを指定したマウス・クリック・アクションを使用します。

image062.pngについては周囲のテキストで説明しています。

1.10.3 単一のフィールドに複数の値が注入されますか

エージェントが単一のフィールドに複数の値(ユーザー名とパスワードなど)を挿入する場合は、エージェントによるSendKeysアクションの起動が非常に早いため、アプリケーションが適切に応答できていない可能性があります。このような場合は、資格証明の注入の信頼性が高まるまで、アクションの起動速度を低下させます。これを行うには、他のアクションとの間に遅延アクションを挿入するか、「End-User Experience」→「Response」の下にある「SendKeys event interval」グローバル・エージェント設定を「Use for slow system」または「Use for very slow system」に設定します。

1.10.4 ジャーナル・フックを使用するSendKeysに切り替えると、注入の信頼性が回復しますか

前述の手順の提案を試した後もエージェントが引き続き単一のフィールドに複数の値を注入する場合は、フォームの対話方法をジャーナル・フックを使用するSendKeysに切り替えます。これを行うには、アプリケーション・テンプレートで「General」タブを選択して目的のフォームを選択し、「Edit」をクリックして「Fields」タブを選択し、「Transfer Method」オプションを「SendKeys using Journal Hook」に設定します。

注意:

「"SendKeys" with journal hooks」オプションを使用すると、エージェントが代替APIを使用してキーストロークおよびマウス・クリックをアプリケーションに送信するため、これは通常、Citrix環境で最も効果的です。

image063.pngについては周囲のテキストで説明しています。

1.10.5 注入された値から文字が欠落していますか

注入されたフィールド値から個々の文字が欠落している場合は、エージェントによるSendKeysアクションの起動が非常に早いため、アプリケーションが適切に受け入れることができていない可能性があります。このような場合は、資格証明の注入の信頼性が高まるまで、アクションの起動速度を低下させます。これを行うには、他のアクションとの間に遅延アクションを挿入するか、「End-User Experience」→「Response」の下にある「SendKeys event interval」グローバル・エージェント設定を「Use for slow system」または「Use for very slow system」に設定します。

1.10.6 マウス・クリック・アクションを使用してフィールドにフォーカスすると、ログオンに成功しますか

ログオンに引き続き失敗する場合は、マウス・クリック・アクションを使用してフォーム内のすべてのフィールドおよびコントロールに対してフォーカスを設定することを検討します。各マウス・クリック・アクションではクリック対象のフィールドまたはコントロールの正確な座標が必要になるため、マウス・クリックが成功するには座標が固定されている必要があることに注意してください。したがって、ウィンドウのサイズが変更されたり、別の解像度で表示されるとコンテンツの位置が変わるような場合は、マウス・クリック・アクションの信頼性が低下する可能性があります。

前述のどの手順でも問題を解決できない場合は、Oracleサポートに連絡してください。

1.11 マッチングのトラブルシューティング

image066.pngについては周囲のテキストで説明しています。

1.11.1 ターゲット・フィールドまたはコントロールは「Control Match」ウィザードで認識されますか

「Show all fields」オプションを有効にしても、マッチング対象のフィールドまたはコントロールが「Control Match」ウィザードに表示されない場合、マッチングを実行できない場合があります。このような場合は、Oracleサポートに連絡してください。

image067.pngについては周囲のテキストで説明しています。

1.11.2 フォームのコントロールIDは非一意または動的ですか

1つ以上のターゲットのコントロールIDが一意でない場合、または動的な場合は、コントロールIDのかわりに序数を使用して、フォーム内のフィールドとコントロールを一意に識別します。序数は、エージェントによってウィンドウ内の各オブジェクトに対して、上から下、左から右に割り当てられる連続したID番号で、これによってエージェントは検出されたフィールドとコントロールをコントロールIDとは別に一意に識別することができます。

1.12 ログオン・ループのトラブルシューティング

一部のアプリケーションではログアウト時にログオン・フォームが表示されるため、Logon Managerがログオン・フォームを認識してアプリケーションへの再ログインを自動的に行う原因となります。これによって無限ログオン・ループが作成され、アプリケーションからログアウトできません。管理者は、このループの発生を防ぐために最後のログオン以降、設定された期間内はLogon Managerがアプリケーションにログオンするのを禁止するログオン猶予期間機能を有効にすることを選択できます。

image069.pngについては周囲のテキストで説明しています。

1.12.1 ログアウト後のフォームは、標準ログオン・フォームと異なりますか

ログアウト時に表示されるログオン・フォームがアプリケーションの標準のログオン・フォームと大きく異なっている場合は、マッチングだけでなく「Logon Loop Grace Period」を検討することをお薦めします。(マッチングの詳細は、「マッチングの使用によるレスポンス精度の向上」を参照してください)。フォームを一意に区別できない場合は、次で説明する「Logon Loop Grace Period」機能を使用します。

1.12.2 「Logon Loop Grace Period」オプションを構成すると、ログオン・ループは解決されますか

ログアウト後のフォームを標準ログオン・フォームと一意に区別できない場合は、指定された猶予期間が完全には経過していない場合にエージェントが同じアプリケーションに自動的にログオンするのを防ぐ猶予期間を構成します。

ログオン・ループ猶予期間タイマーを構成するには、次の手順を実行します。

Logon Manager管理コンソールで目的のテンプレートを開き、「Miscellaneous」タブを選択します。
「Logon Loop Grace Period」フィールドで、ドロップダウン・リストから目的の操作モードを選択します。
- 「Prompt」 - エージェントは、猶予期間が有効なときにアプリケーションのログオン・フォームを検出した場合、ログオンを完了するか、アプリケーションを無視するかを尋ねるプロンプトを表示します。
- 「Silent」 - エージェントは、猶予期間が有効なときにアプリケーションのログオン・フォームを検出した場合、アプリケーションを無視し、ユーザーのログオンを行いません。
- 「None」 - 猶予期間タイマーを非アクティブ化します。エージェントは、アプリケーションのログオン・フォームを検出するたびにアプリケーションに応答します。
猶予期間が有効なときにエージェントに実行させる内容に応じて、次のいずれかを実行します。
- アプリケーションの実行可能ファイルの起動が検出されるたびにエージェントがユーザーのログオンを行うようにするには、「Reset for each process」チェック・ボックスを選択します。
- 猶予期間が経過するまでエージェントがアプリケーションを無視するようにするは、「Reset for each process」チェック・ボックスを空白のままにします。

変更を保存してリポジトリにコミットします(該当する場合)。

注意:

ログオン猶予期間タイマーを構成しても、ログオン・ループが特定のフォーム定義で発生する場合は、フォーム定義の「Options」タブの「Adhere to logon loop grace period」オプションが有効になっていることを確認します。

この方法でもアプリケーションのログオン・ループが解決されない場合は、Oracleサポートに連絡してください。

1.13 Javaアプリケーションの問題のトラブルシューティング

Javaアプリケーション固有の問題を診断し解決するには、次のステップを使用します。

image072.pngについては周囲のテキストで説明しています。

1.13.1 インストールしたJREはサポートされているブランドおよびバージョンですか

サポートされるJREのリストについては、ご使用のバージョンのLogon Managerのリリース・ノートを参照してください。インストールしたJREがサポートされていない場合は、Logon Managerを現在のJREがサポートされるリリースにアップグレードするか、現在のJREをご使用のリリースのLogon Managerでサポートされるバージョンに置き換える必要があります。

1.13.2 Oracle JInitiator、あるいは開発元がOracleまたはIBM以外の別のJREを使用していますか

Logon Managerを、Oracle JInitiatorまたはOracle/IBM以外のJREとともにデプロイした場合の問題は報告されていませんが、このようなJREを使用した場合のLogon Managerの適切な動作についてはサポートおよび保証されません。

1.13.3 JHOはロードされていますか

場合によっては、Javaアプリケーション起動時に、構成上の問題によってJHOがロードされない場合があります。JHOがインストールされ実行されていることを確認するには、Microsoft Spy++ (Microsoft Visual Studioに付属)、またはSysInternals Process Explorerなどのプロセス・ビューア・ツールを使用して、JVM実行可能ファイルがssojho.dll子スレッドを生成したことを確認してください。

次に示す例は、Process ExplorerでのSun JVM実行可能ファイルjavaw.exeのプロパティ・ボックスを示しており、ssojho.dll子スレッドが実行中であることがわかります。

image073.jpgについては周囲のテキストで説明しています。

JHOがターゲットJREに対してロードされていない場合は、(ホーム・ディレクトリにある)ユーザーの.java.policyファイルで、JHOが必要とする権限が付与されているかどうかを確認します(次の項で説明します)。

1.13.4 JHOで必要な権限の検証および修復

JHOは、ターゲットJREのコンテキストで適切に動作できるように、ユーザーの.java.policyファイルを通じて付与される特定の権限のセットを必要とします。これらの権限が有効でない場合、Logon ManagerはJavaアプリケーションを検出することも、それに応答することもできません。

1.13.4.1 必要な権限が付与されているかどうかの確認

Logon Managerが起動するたびに、権限はテンプレート.java.policyファイル(%INSTALLDIR%\v-GO SSO\Helper\Java)から、ユーザーの.java.policyファイル(ユーザーのホーム・ディレクトリ)にコピーされます。これらの権限は、Javaアプリケーションが起動されるたびにJHOに自動的に付与されます。

必要な権限がJHOに付与されていない疑いがある場合は、Logon Managerの起動後に、JHOを参照している例外のうち欠落する権限に関する例外がないか、JREのログを確認してください。そのような例外が存在する場合、必要な権限は付与されていません。次のいずれかの原因が考えられます。

ユーザーの.java.policyファイルに、JHOで必要な権限が含まれていない。
ターゲットJREのセキュリティ設定が(通常はJREのjava.securityファイルに保存される)、ユーザーの.java.policyファイルを参照しない。

1.13.4.2 欠落したJHO権限の修復

必要なJHO権限がユーザーの.java.policyファイルに含まれていない場合、そのファイルのACLによってLogon Managerがそのファイルに権限を書き込めない可能性があるため、ファイルのACLを調べて書込み権限が拒否されていないかを確認してください。

ACLが適切で、必要な権限がユーザーの.java.policyファイルに存在しない場合は、次のいずれかを実行します。

ユーザーの.java.policyファイルに、保持する必要がある他の権限または構成情報が含まれている場合は、このファイルを編集して欠落しているJHO権限を手動で追加します。
ユーザーの.java.policyファイルに、保持する必要がある他の権限または構成情報が含まれていない場合は、このファイルを削除してからLogon Managerを再起動すると、ファイルが再作成されて必要な権限が自動的に挿入されます。

注意:

JREがそのベンダーによって更新され、将来のリリースで1つ以上の新しい権限が導入される場合がありますが、JHOでそれが必要になったとしても、Logon Managerのリリース時点ではそれが考慮されていない可能性があります。その場合は、Logon ManagerおよびターゲットJavaアプリケーションの起動後に、欠落する権限に関する例外がないかJREのエラー・ログを確認し、その権限をLogon Managerの.java.policyテンプレート・ファイルに追加して、次回Logon Managerを起動したときにユーザーの.java.policyファイルを通じてその権限が付与されるようにします。

1.13.5 Java Helper Object (JHO)の動作の構成

Logon Managerは、JHOの次の側面の動作を制御できる、グローバルなエージェント設定を提供します。

特定のJREバージョンを除外
特定のJREベンダーを除外
Javaアプレットのロードを考慮したレスポンス遅延を定義
JREの初期化を考慮したレスポンス遅延を定義
レスポンス再試行間の遅延を定義
レスポンス再試行の最大数を定義
JHOが認識または無視する特定の階層、ウィンドウ、コンポーネントおよび注入タイプのイベントを定義する

これらの設定は、管理コンソールのツリーの次の場所にあります。

「Global Agent Settings」→「Live」→「User Experience」→「Application Response」→「Java Applications」

image074.pngについては周囲のテキストで説明しています。

これらの設定および構成方法の詳細は、コンソールのヘルプを参照してください。さらに精度の高い制御を行う場合、Logon Managerではレジストリ設定が提供されています(次の項で説明します)。これらの設定は熟練した管理者のみが行うことをお薦めします。

1.13.5.1 手動による特定のJREに対するJHOの制限

前述のコンソール設定以外に、Logon Managerでは非常に精度の高い包含および除外ルールを作成できるレジストリ設定が提供されています(包含および除外ルールは、Logon Managerがターゲット・アプリケーションに対してJHOをロードするかどうかを決定する際に使用します)。Java Virtual Machine (JVM)実行可能ファイル、JARファイル、およびJHOで考慮されるコマンドライン・パラメータを、正規表現を使用して指定できます。

これらの設定を構成する際には、次の点に注意してください:

設定の対象となる値を省略すると、指定されているデフォルトが使用されます(値を設定すると、一致しない値はすべて無視されます)。
JHOは最初に包含ルールを処理し、その後除外ルールを処理します。
N接尾辞は、特定のアプリケーションに属する設定をバンドルする一意の数値識別子です。JHOは、このバンドルを昇順に順次処理します。N接尾辞は、1から始まる正の整数です。
トレース・ロギング・ユーティリティを使用して、アプリケーションのホストJVM実行可能ファイルおよび起動コマンドを確認できます。Javaトレース・ログの先頭部分は、アプリケーションのホストJVMおよび起動コマンドを示します。

設定は、Windowsレジストリの次のパスにあります。HKEY_LOCAL_MACHINE\SOFTWARE\Passlogix\Extensions\AccessManager\JHO

設定は、次のカテゴリに分けられます。

JHO包含ルール
JHO除外ルール
許可されるJava Runtime Environment (JRE)バージョン

1.13.5.1.1 JHO包含ルール

これらの設定は、ホストJVM実行可能ファイル、アプリケーションJARファイル、およびターゲット・アプリケーションに対してJHOをロードするためのコマンドライン・パラメータを指定する場合に使用します。値は、大/小文字が区別されない正規表現です。

設定

説明

JhoIncludeHostNameN

アプリケーションのホストJVM実行可能ファイルを指定します。

たとえば、アプリケーションがjava.exeまたはjavaw.exeという名前のJVM実行可能ファイルによってホストされている場合にJHOをロードするには、値をJhoIncludeHostName1=.*javaw?\.exeのように設定し、値を指定しない場合のデフォルトでは、

すべての実行可能ファイルが受け入れられます(つまり、JHOはどのような実行可能ファイルに対してもロードされます)。

JhoIncludeHostCommandLineN

アプリケーションの起動に使用されるコマンドを指定します。通常、コマンド文字列には、JVM実行可能ファイルのフルパスと名前、JARファイル、および必要なすべてのコマンドライン・パラメータが含まれます。

たとえば、アプリケーションのJARファイルがLogin.jarという名前の場合のみJHOをロードする場合(コマンドの残り部分は異なっていても許容される)、値を次のように設定します。JhoIncludeHostCommandLine1=.*Login\.jar.*値を指定しない場合のデフォルト:すべてのコマンド文字列が受け入れられます(つまり、どのようなコマンドでもJHOはロードされます)。

1.13.5.1.2 JHO除外ルール

これらの設定は、ホストJVM実行可能ファイル、アプリケーションJARファイル、およびJHOがターゲット・アプリケーションを無視するためのコマンドライン・パラメータを指定する場合に使用します。値は、大/小文字が区別されない正規表現です。

設定	説明
JhoExcludeHostNameN	アプリケーションのホストJVM実行可能ファイルを指定します。たとえば、ホストJVM実行可能ファイルの名前が"java.exe"または"javaw.exe"の場合にJHOがアプリケーションを無視するようにするには、値を次のように設定します。JhoExcludeHostName1=.*javaw?\.exe値を指定しない場合のデフォルト:空白(つまり、JHOはアプリケーションを無視しません)
JhoExcludeHostCommandLineN	アプリケーションの起動に使用されるコマンドを指定します。通常、コマンド文字列には、JVM実行可能ファイルのフルパスと名前、JARファイル、および必要なすべてのコマンドライン・パラメータが含まれます。たとえば、JARファイルの名前が"Login.jar"の場合にJHOがアプリケーションを無視するようにするには(ただし、コマンドの残りの部分は非間接的)、値を次のように設定します。JhoExcludeHostCommandLine1=.Login\.jar.値を指定しない場合のデフォルト:空白(つまり、JHOはアプリケーションを無視しません)

1.13.5.1.3 許可されるJava Runtime Environment (JRE)バージョン

これらの設定では、JHOがロードされる目的のJRE/JDKバージョンを指定可能であり、この指定範囲外のバージョンはすべて無視され、JHOはロードされません。

どちらの設定の値もx.y.zという形式である必要があります。

xは、メジャー・バージョンです。
yは、マイナー・バージョンです。
zは、リリース・タイプ(機能、メンテナンスまたは更新)、およびインストールされているJREのビルドID (1.6.0_07など)を示します。

設定

説明

JhoMinimumJavaVersion

許可されるJRE/JDKバージョンの下限を指定します。

デフォルト値:

1.2 (JHOでサポートされる最も古いJREバージョン)

JhoMaximumJavaVersion

許可されるJRE/JDKバージョンの上限を指定します。