Oracle® Fusion Middleware Enterprise Single Sign-On Suiteリリース・ノート 11gリリース2 (11.1.2.3) E61968-01 |
|
前 |
この項では、現在のリリースのOracle Enterprise Single Sign-On Suiteのテクニカル・ノートについて説明します。
この項では、現在のリリースのLogon Managerのテクニカル・ノートについて説明します。
バージョン11.1.2.1以上では、Microsoft Active Directoryにデプロイした場合、Logon Managerの構成ポリシーが、クラスvGOSecretのその他のユーザー構成オブジェクトと一貫性があるリポジトリの場所に保存されます。Oracle Enterprise Single Sign-On管理コンソールのActive Directoryのシンクロナイザ設定セクションにある「Use secure location for storing user settings」オプションを有効化して、この新しい設定のストレージ・スキーマに移行することを強くお薦めします。
以前のバージョンのLogon Managerからアップグレードする場合は、Logon Managerのすべてのインスタンスをリリース11.1.2.1にアップグレードした場合にのみ、このオーバーライドをデプロイする必要があり、そうしない場合、Logon Manager 11.1.2.1が一度リポジトリと同期すると、以前のすべてのバージョンはそのユーザーのリポジトリと同期できなくなります。
このバージョンのKiosk Managerに付属しているアップグレードされたキーボード・ドライバにより、インストール・プロセス中に2度再起動することを求められます(古いドライバの削除時に1回、新しいドライバのインストール時に1回)。
(Oracle Enterprise Single Sign-Onの管理コンソールの「Global Agent Settings」→「Authentication」→「Smart Card」の)「Use default certificate for authentication」オプションに「No」を設定すると、ユーザーは、初回使用時(以降FTU)の登録プロセスでPINの入力を2回求められます。これは正常であり、Logon Managerがスマート・カードのキーセットを生成するために必要です。FTU後に続く認証で、必要なPINの入力は一度のみです。
Logon Managerは、高度に昇格した権限で実行されている一部のアプリケーションに対してが応答できない場合があります。たとえば、組込み管理者アカウントとしてログインしており、ローカル・セキュリティ・ポリシーが組込み管理者アカウントの管理承認モードを無効にするよう設定されている場合、その結果である権限の昇格により、それ自体が中権限アプリケーションであるLogon Managerが、昇格した権限で実行されているターゲット・アプリケーションにフックできなくなります。
XMLログ・ファイル・プラグインは、ログ・ファイルにデータを継続的に追加し、データは肥大してきます。ログ・ファイルをソリューションの一環として使用している場合は、(ユーザーのAppData\Passlogixフォルダから)ログ・ファイルを定期的にクリーンアップする必要があります。
バックアップ/リストア機能をシンクロナイザとともに使用すると、競合が発生する場合があります。デプロイされたソリューションで両方のメカニズムを利用し、バックアップ/リストアをスタンドアロン・インストールのみで使用することはお薦めできません。
ローカル・ドライブからバックアップをリストアする必要があります。ネットワーク・ドライブからリストアすることはできません。
Citrix Published ApplicationsでSendKeysを使用すると、Citrixアプリケーション・ウィンドウは表示されますが、ウィンドウにコントロールが表示されないため、SendKeysの「Set Focus」機能を使用できません。「Set Focus」が機能するには、ウィンドウのコントロールを参照する必要があります。
各フィールド間に[Enter]または[Tab]文字が含まれた通常のSendKeysを使用してCitrix Published Applicationを設定すると、これらの文字は適切に処理されません。これらは、ランダムな順序で処理されます。
問題は、フィールド間に送信された区切り文字(通常[Enter]または[Tab]文字)がCitrixアプリケーションで正しい順序で処理されないため、動作に一貫性がなくなることです。
これを解決するには、アプリケーション・テンプレートを修正してフィールド間に遅延を追加します。たとえば、現在のアプリケーション・テンプレートを次のように構成します。
[ユーザー名] [Tab] [パスワード] [Tab] [Enter]
フィールド間に遅延を追加する必要があります。
[ユーザー名] [遅延0.1秒] [Tab] [パスワード] [遅延0.1秒] [Tab] [Enter]
マシンをログオフまたは再起動すると、NetManage NS/Eliteエミュレータにより、Logon Managerに「End Program」メッセージが表示されます。この動作は、断続的にしか発生しません。
注意: 「End Program」をクリックすると、資格証明がクリーンアップされない場合があります(「Delete Local Cache」オプションを有効化している場合)。 |
この項では、現在のリリースのUniversal Authentication Managerのテクニカル・ノートについて説明します。
ドメインへの厳密なオーセンティケータにUniversal Authentication Managerを使用するマシンを追加または削除する場合、マシンを追加または削除した後、ただちに再起動する必要があります。再起動するまで厳密なオーセンティケータは機能しません。
一部のスマート・カードと一緒にRSA Authentication Client 2.0 Smart Cardミドルウェアを使用すると、ポーリング時間の競合状態および変化によって、ユーザーは、「Card is either not enrolled or not supported」というエラー・メッセージを受け取る場合があります。
このシナリオでは、2通りの処置が考えられます。
ユーザーは、「OK」をクリックして、もう一度カードの挿入を試みます。
管理者は、次のレジストリ・キーを追加して、タイムアウト値を大きくすることができます。
スマート・カード・オーセンティケータのカードおよびシリアル・タイムアウト設定(PKCS11競合状態)
値: CardTimeout = DWORD (0-5000 ms; 2000 ms (default))
キー: HKLM\SOFTWARE\Passlogix\UAM\Authenticators\ {A1B34553-8D40-42A9-8ED5-F70E3497E138}\Settings
値: SerialTimeout = DWORD (0-5000 ms; 500 ms (default))
注意: CardTimeoutは、Windowsスマート・カードAPIと競合する可能性のある特定のPKCS11モジュールに適用されます。タイムアウトを大きくすると信頼性が向上しますが、パフォーマンスに悪い影響を与える可能性があります。SerialTimeoutは、カードからシリアル番号読み取る際に、競合状態にある特定のPKCS11モジュールに適用されます。カードはサポートされているが、そのシリアル番号を読み取れない場合、この問題が発生している可能性があります。タイムアウトを大きくすると信頼性が向上しますが、パフォーマンスに悪い影響を与える可能性があります。 |
この項では、現在のリリースのAnywhereのテクニカル・ノートについて説明します。
次のLogon Manager機能は、Anywhereでサポートされていません。
Oracle Access Managerの統合。Oracle Access Managerに対するサイレント認証はサポートされていません。
Mozilla FirefoxおよびGoogle Chrome。Mozilla FirefoxおよびGoogle Chromeブラウザ経由でアクセスされたWebアプリケーションの検出および応答はサポートされていません。
Windows Authenticator v2 GINA。Windows Authenticator v2 GINAコンポーネントはサポートされていません。AnywhereはGINAのインストールをサポートしていません。
Windows Authenticator v2ネットワーク・プロバイダ。Windows Authenticator v2ネットワーク・プロバイダ・コンポーネントはサポートされていません。AnywhereはWindowsサービスのインストールをサポートしていません。
注意: Anywhereは、GINAおよびネットワーク・プロバイダ以外のすべてのWindows Authenticator v2機能をサポートしています。サポートされていないWindows Authenticator v2機能を有効化する回避策はありません。 |
Anywhereは、Program Filesフォルダではなく、ユーザーのホーム・フォルダにインストールされるため、Windows 7およびWindows Server 2008/2008 R2デプロイメント上のデフォルトのセキュリティ・ポリシーでは、不十分な権限が原因でAnywhereを実行できません。(デフォルトでは、Program Filesフォルダはセキュアな場所として認識されますが、ユーザーのホーム・フォルダはセキュアな場所として認識されません。)
この問題を解決するには、次の手順を実行します。
グループ・ポリシー・オブジェクト(GPO)を変更して、設定「ユーザー アカウント制御: セキュアな場所にインストールされた UIAccess アプリケーションのみを昇格する」を無効化します。GPOでのこの設定の場所は、「コンピューターの構成\Windows の設定\セキュリティの設定\ローカル ポリシー\セキュリティ オプション\」です。
標準的なグループ・ポリシー・プラクティスを使用して、変更したポリシーをドメインに適用します。
前述の設定の状態にかかわらず、アプリケーションは、実行するPKI署名チェックをパスする必要もあるため、ユーザーはまだ不正なコード・アクセスから保護されています。
このセキュリティ設定に関する詳細は、Microsoft TechNetの記事(http://technet.microsoft.com/en-us/library/dd834830.aspx
)を参照してください。
デフォルトでは、Microsoft IIS 6.0は、Anywhereで使用される3つのファイル・タイプ(.application、.deployおよび.manifest)を提供していません。IIS 6.0 Web Serverを使用してAnywhereをデプロイすることを計画している管理者は、Oracle Enterprise Single Sign-On Suite Plusマスター・アーカイブの「Anywhere」フォルダに含まれているIisAddMimeTypes.vbsスクリプトを実行する必要があります。
このスクリプトを実行せずにAnywhereをデプロイしようとすると、エラーHTTP 404が発生します。IIS 6.0およびサポートされていないMIMEタイプの詳細は、MicrosoftのWebサイトを参照してください。