Oracle® Fusion Middlewareディレクトリ・ベースのリポジトリでのLogon Managerのデプロイ 11gリリース2 (11.1.2.2) E51904-01 |
|
![]() 前 |
![]() 次 |
Oracle Enterprise Single Sign-On Logon Managerは、ユーザーとターゲット・アプリケーションの間の中間層として機能するセキュアで容易にデプロイ可能なシングル・サインオン・ソリューションです。ユーザーの認証は1回で済み、ユーザー資格証明に対する後続のすべてのリクエストはLogon Managerによって自動的に検出されて処理されます。Logon Managerの詳細は、Oracleサポート・サービスから入手できる、Oracle Enterprise Single Sign-On Suite技術概要のホワイト・ペーパーを参照してください。
ディレクトリ環境にLogon Managerをデプロイする選択肢もあり、これにより、ネットワーク上の任意のマシンに対して、アプリケーション資格証明、テンプレートおよびポリシーの一括格納によるシングル・サインオン機能を実装できます。ユーザーは、このディレクトリを同期して、これらの項目をダウンロードし、新規作成または変更されたユーザー名やパスワードで資格証明ストアを更新します。
既存のディレクトリ環境にLogon Managerを追加すると、次のような利点があります。
Logon Managerでは既存のユーザー・アカウント、グループおよびネイティブのディレクトリ権限(ACL)を使用できるため、これらの項目を個別に管理したり、他のディレクトリまたはデータベースと同期する必要がありません。
Logon Managerのデータは、既存のバックアップおよび障害時リカバリ計画によって自動的に保護されます。
専用サーバーやサーバー側のプロセスは不要で、Logon Managerのスケーラビリティとパフォーマンスは、既存のディレクトリ・インフラストラクチャの容量と堅牢性のみに依存します。
管理者のタスクが増えることはなく、また新しいツールや概念について学習する必要もありません。Logon Managerの委任管理は、ディレクトリのネイティブ機能によって行われます。
また、ディレクトリの使用によって、Logon Managerのテンプレートとポリシーの編成を見やすい階層構造で表示することもできます。現行の環境で必要な場合はフラット・モデルを使用できますが、階層を適切に設定すれば、より効率的なアクセス制御によって、トップ・ディレクトリ、エージェント、およびネットワークのパフォーマンスの安定化を図り、Logon Managerの管理を簡略化できます。
注意: Oracle Identity ManagerとともにLogon Managerをデプロイするには、Oracle Identity Managerで匿名バインド・オプションを有効にする必要があります(匿名バインドが無効化されている場合は、Logon ManagerはOracle Identity Managerにバインドされません)。 |
Logon Managerでディレクトリにデータを格納するためには、管理コンソールを使用してディレクトリ・スキーマを拡張する必要があります。スキーマの拡張は、4つのオブジェクト・クラスを追加し、これらのタイプのオブジェクトを作成、読取り、変更、削除できるように、適切な権限を設定して行います。既存のクラスおよび属性を変更する方法はありません。
注意: 注意: スキーマの拡張はインストール後の手順です。手順については、「スキーマの拡張」を参照してください。スキーマの拡張を実行する前に、(Microsoftのベスト・プラクティスで説明されているように)スキーマ・ヘルス・チェックを実行することを強くお薦めします。 |
Logon Managerによって実行されるスキーマの拡張の詳細は、次の付録を参照してください。
Logon Managerエージェントは、LDAPシンクロナイザのプラグインを使用してLDAPディレクトリと通信します。適切に設定されている場合は、次のいずれかのイベントが発生すると同期が実行されます。
Logon Managerエージェントが起動された。
アプリケーション資格証明がエンド・ユーザーによって、追加、変更または削除された。
エージェントを実行しているマシンがIPアドレスを取得した、または既存のIPアドレスが変更された(Logon Managerがこれらのイベントに応答するように設定されている場合)。
自動同期の間隔が経過した(設定されている場合)。
ユーザーがエージェントのリフレッシュ機能を使用して同期を開始した。
同期を実行している間、Logon Managerエージェントは、Logon Managerサブツリーを移動して、現在のユーザーにアクセス権が付与されているサブコンテナのコンテンツをロードし、前回の同期後に追加、変更または削除された資格証明を同期します。
注意: Logon Managerでは、Active DirectoryまたはAD LDS (ADAM)以外のLDAPディレクトリの認証時に、サーバーの自動配置もWindows資格証明の使用もサポートされないため、WindowsおよびLogon Managerに対する認証に加えてディレクトリを認証するプロンプトがエンド・ユーザーに表示されます。特定のシナリオでは、この余分のプロンプトが表示されないようにできます。詳細は、「オーセンティケータの選択と構成」を参照してください。 |
ディレクトリ・サーバーが失敗すると、Logon Managerはサーバー・リストの次のサーバーに接続しようとします。リスト上のどのサーバーにもアクセスできない場合、その問題が修正されるまでは同期が使用できなくなります。使用している環境で複数の物理ディレクトリ・サーバーが必要な場合、それらのサーバー間で、ネットワークからのリクエストを自動的に均等に分散させるロード・バランサを使用することを強くお薦めします。1台のマシンがオフラインになった場合、そのワークロードを残りのマシンで一時的に吸収することができ、エンド・ユーザーに対するフェイルオーバー透過性、および障害のあるマシンをオンラインに戻すための十分な時間が提供されます。
警告: ロード・バランサの背後で同期のレプリケーションを使用する複数のLDAPサーバーでのLogon Managerのデプロイは、アクティブ-アクティブ(ロード・バランシング済)シナリオにおける高可用性に対してサポートされておらず、アクティブ-パッシブ(フェイルオーバー)シナリオでのみサポートされます。詳細は、Oracleサポート・サービスに連絡してください。 |
Logon Managerは、ユーザーが「First-Time Use (FTU)」ウィザードを完了したときに生成される一意キーを使用してアプリケーション資格証明を暗号化します。資格証明は、エージェントのローカル・キャッシュ内、ディレクトリ内およびネットワークを移動しているときも常に暗号化された状態を維持します。Logon Managerは、設定されたアプリケーションがログオンをリクエストしたときにのみ資格証明を(ディスクではなくメモリーに対して)復号化し、ログオン・リクエストの完了後すぐにターゲット・メモリーの場所を消去します。ユーザーおよび有効なアプリケーションごとにLogon Managerが格納するデータ量はわずかです(数バイトか数キロバイト)。
注意: 認証時にユーザーからディレクトリに送信される資格証明が暗号化されるように、SSLサポートを有効にすることをお薦めします。SSLが有効でない場合、それらの資格証明はクリア・テキストで送信され、パケット・スニファによる傍受が可能になります。詳細は、「SSLのサポート」を参照してください。 |
Logon Managerでは、組織のニーズに合わせてディレクトリ構造を思いのままに設定できます。具体的には、データをフラット・モデルで格納するか階層構造で格納するかの選択肢があります。フラット・モデルは小規模なデプロイメントでは問題なく機能しますが、成長する大規模なデプロイメントでは最初から階層構造を使用します。サブツリーの適切な構造は次の要素によって決まります。
ユーザーの数
Logon Managerでサポートするアプリケーションの数
既存のインフラストラクチャの堅牢性
組織の構造。
次のガイドラインに従ってサブツリーを階層構造として設定することをお薦めします。
OUを使用して、部門や部署など、組織の構造に合わせたカテゴリごとにテンプレートおよびポリシーをグループ化します。
OUレベルでアクセスを制御します。
現在の環境で特に指定がないかぎり、継承を無効化し、Logon Managerのルート・コンテナでユーザー権限を付与しないようにします。
このように階層を設定すると、次の利点があります。
見やすくわかりやすいツリー構造。ディレクトリ・ブラウザでサブツリーを表示すると、サブツリー構造を一覧できるので全体が把握しやすくなります。
不要な権限の継承なし。ユーザーには、アクセスする必要のないサブOUに対する権限はネイティブで継承されません。これにより、ツリーの下位に継承される不要なアクセス権限を明示的に拒否せずに済みます。
ネットワーク、エージェントおよびディレクトリの堅牢なパフォーマンス。通常、大量のテンプレートおよびポリシーをダウンロードするユーザーは、自分のジョブに関連する項目のみをダウンロードするユーザーよりもネットワーク・トラフィックが多く、ディレクトリの負荷も高くなります。グループ化によって、環境のリソースが節約され、エージェントのレスポンス時間が改善されます。
管理タスクの分散。テンプレートを制御しやすいセットに整理し、アクセス権限の設定によって、ユーザーが管理できるテンプレートを決定します。権限に基づいたテンプレートのバージョン制御を実装する機能も使用できます。
低い管理オーバーヘッド。テンプレート・レベルでのアクセスの制御では、Logon Manager管理コンソールから個々のテンプレートに権限を設定する必要があり、OUレベルでのアクセスの制御は、Microsoftやサードパーティの管理ツールを使用した委任管理によって行います。
次の図は、前述のベスト・プラクティスを反映して設計されたサンプルのLogon Managerサブツリーを示しています。
サンプルのシナリオでは、ポートランド部門のユーザーは、サクラメント部門で使用するアプリケーションへのアクセスは不要で、その逆も同様であるため、各部門のテンプレートおよびポリシーは、ルートの専用サブOUに配置し、両部門が互いのサブOUにアクセスできないようにしています。つまり、具体的な実装方法は使用する環境によって決まります。
フラット・モデルで開始し、ユーザーおよびプロビジョニングするアプリケーションの数が多くなると予想される場合は、階層構造への移行の準備ができるまでは、ルートの下にサブコンテナを作成し、それを使用してテンプレートとポリシーをフラットに格納します。ユーザーを追加したり、アプリケーションをさらにプロビジョニングする際には、階層に移行してなるべく早いうちに環境のパフォーマンスを確認してください(後で確認するよりも手間を省くことができます)。階層に移行するとき、新しいLogon Managerルート・コンテナとして既存のコンテナを使用し、その下にサブOUを作成します。
LDAPディレクトリと正常に同期するために、Logon Managerでは、同期を試行する前に次のディレクトリ・オブジェクトが構成されていることが必要です。
People OU。Active Directory以外のディレクトリでLogon Managerをデプロイすると、アプリケーション資格証明はユーザー・オブジェクトに格納できません。かわりに、資格証明は、Peopleと呼ばれる特別なOU内にフラット形式で格納されます。「People OUの作成」の説明に従ってこのOUを作成する必要があります。
注意: このOUは、Sun Directory ServerがLDAPユーザー・アカウントの格納に使用するPeopleコンテナとは無関係です。 Logon Manager構成オブジェクト・コンテナ(SSOConfig)の内部にPeople OUを配置しないでください。そのようにすると、テンプレートのロード時に、ディレクトリにかなりの不必要な負荷を与えて、すべてのLogon Managerユーザーの資格証明をLogon Managerによって解析することになります。 |
vGOLocatorオブジェクト。このオブジェクトは、People OUに格納されているユーザーのアプリケーション資格証明にLDAPユーザー・アカウントをリンクします。ユーザーがログインすると、Logon Managerは、vGOLocatorオブジェクトが見つかるまでツリーをユーザーのオブジェクトから上に移動します。vGOLocatorオブジェクトによって、Logon ManagerにPeople OUへのパスが提供されます。
注意: 13ページの図に示されるように、このオブジェクトは、ディレクトリのユーザー・アカウント・コンテナに置くことをお薦めします。必要に応じて、推奨はされませんが、ディレクトリ・ツリーのルートに置くこともできます。vGOLocatorは、最低限でも、ユーザー・アカウントがあるコンテナと同じレベルに置く必要があります。 |
図2に示すように、ワークフローの各段階(開発、ステージング、本番)で専用のサブOUを作成することをお薦めします。この方法によって次のことができます。
テンプレートおよびポリシーがワークフローを通過して本番に入るときには、ワークフローの各ステージを移動するたびにこれらのシャドウ・コピーが保持されるので、テンプレートおよびポリシーに対して行われた変更をトラッキングできます。
必要に応じて、テンプレートおよびポリシーを以前のバージョンにロールバックできます。
ワークフローの各ステージで、誰がどのテンプレートおよびポリシーを使用するかを制御できます。特に、テンプレートおよびポリシーを本番に配置できるユーザーの管理には、厳格なルール設定が必要です。
必ず、隔離した環境ですべてのアプリケーション・テンプレートおよび管理オーバーライドをテストしてから、エンド・ユーザーにデプロイしてください。テストは、変更内容の確認や、本番環境で発生したとしたら、解決するのに多くのコストがかかるような潜在的な問題の解決に役立ちます。正しく構成されていないテンプレートや誤った管理オーバーライドをネットワーク全体にプッシュした場合、ミッション・クリティカルなアプリケーションへのアクセスがエンタープライズ全体で失われることがあるので、テストは大規模なデプロイメントでは特に重要です。
隔離したテスト環境をセットアップする場合は、デプロイメント・グループのメンバーのみがアクセス権を持つ専用のテスト・コンテナを作成してください。次に、このコンテナ内のLogon Managerエージェントを特定して、テンプレートと管理オーバーライドをその中に配置します。テンプレートとポリシーが意図したとおりに動作していることを確認したら、それらをターゲットの本番コンテナに移動します。
テンプレートをテストした後にシャドウ・コピーを維持しない場合、次の手順に従って、それらをテスト・コンテナからターゲットの本番コンテナに移動します。
ディレクトリからテンプレートを取り出します。
そのテンプレートのローカル・バックアップを作成します。
ディレクトリ内の新しい場所に、このコピーを配置します。
テンプレートを元の場所から削除します。
コンソールを使用してオブジェクトのアクセス制御リスト(ACL)を変更する場合、リポジトリに接続するために使用される接続文字列(リポジトリ・ホスト名またはIP)は、コンソールでは一意のリポジトリ識別子として扱われ、オブジェクト内に記録されます。そのため、コンソールは、同じリポジトリに接続する2つ目の一意リポジトリや2つ目のメソッドを識別できません。
これにより、同一ディレクトリに対して異なる接続文字列(IPアドレスやホスト名)を使用すると、セッション間で行われたオブジェクトへの変更が失われます。LDAP環境でこの問題を回避するには、コンソールを介してオブジェクトのACLを変更する際に、常に同じ接続文字列(IPアドレスまたはホスト名)を使用します。
環境全体でテンプレートと設定の互換性を維持するには、常に、本番にデプロイされているエージェントの最も古いバージョンと一致するコンソールのバージョンを使用することです。テンプレート・スキーマはリリース間で変更されるため、新しいバージョンのコンソールによって作成または変更されたテンプレートを使用すると、古いエージェントは予期しない動作をする可能性があります。このため、Logon Managerを新しいリリースにアップグレードしている場合は、すべてのデプロイされたエージェント・インストールをアップグレードしてから、コンソールをアップグレードすることを強くお薦めします。
注意: テンプレートに何も変更を行っていない場合でも、テンプレートをリポジトリに戻すと、現在インストールされているコンソールのデータ・スキーマを使用して再書込みが行われます。 |
Logon Managerエージェントの動作(ディレクトリとの相互作用も含む)は構成済の設定によって管理し、エンドユーザーのマシンへのデプロイはLogon Manager管理コンソールを使用してLogon Manager管理者が行います。設定は、次のいずれかのカテゴリに該当します。
グローバル・エージェント設定は、エージェントのローカル・ポリシーであり、エンド・ユーザー・マシンのWindowsレジストリに格納され、Logon Manager MSIパッケージに含まれて、エージェントにデプロイメント時の初期構成を提供します。グローバル・エージェント設定は、HKEY_LOCAL_MACHINE\Software\Passlogix (32ビット・システム)またはHKEY_LOCAL_MACHINE\Wow6432Node\Software\Passlogix (64ビット・システム)に格納されます。
注意: HKLMハイブを変更できるユーザーは、そのグローバル・エージェント設定を変更できるため、意図した場所からエージェントの動作を変更することができます。エンド・ユーザーが設定を変更できないようにするには、管理オーバーライドでその設定をデプロイします。 |
管理オーバーライドはWindowsレジストリに格納されているグローバル・エージェント設定よりも優先され、エージェント用のドメイン・ポリシーを構成します。オーバーライドは、同期化の際にエージェントによって中央リポジトリからダウンロードされ、改ざん防止機能が付いた、エージェントの暗号化済ローカル・キャッシュに格納されるため、これによって、エンド・ユーザーによる変更ができないようになります。ロール/グループのセキュリティが有効な場合、管理オーバーライドはユーザーまたはグループごとに適用することも、企業全体に適用してすべてのユーザー設定の一貫性を保つこともできます。
注意: 管理オーバーライドを計画する際は、慎重に行ってください。オーバーライドが少なければ、格納および転送するデータも少なくなるので、中央リポジトリとの同期がより効率的になります。エンド・ユーザーのマシン上では管理オーバーライドを確認することができないため、オーバーライドの数を減らすことで不明な状況が解消され、トラブルシューティングも容易になります。 |
管理オーバーライドとグローバル・エージェント設定は、エージェントの完全な構成ポリシーを適用します。このガイドの残りの部分では、推奨される最適な構成について説明し、Enterprise Single Sign-On Suite管理者ガイドにある情報を補足します。
警告: ドメイン名やユーザー・オブジェクト・パスなどの設定は、必ず十分にテストしてからデプロイし、必要のない場合は管理オーバーライドとしてデプロイしないでください。入力ミスによるドメイン名の単純な間違いなどによって、エンド・ユーザーのワークステーションでディレクトリの同期ができなくなると、コンソールから修正内容を伝えることはできないため、他のツールを使用してユーザー・マシンに変更を適用する必要があります。 |
次の図は、LDAPディレクトリと同期するためのLogon Manager管理コンソールの標準的な設定を示しています。
次の項では、LDAPと同期するためのLogon Managerの構成について、そのベスト・プラクティスを説明します。このガイドで説明されている設定の詳細な情報が必要な場合は、コンソールに含まれているオンライン・ヘルプを参照してください。
注意: 開始する前に、Logon ManagerエージェントとLDAPのシンクロナイザ・プラグインがインストールされていることを確認してください(インストールされていないとコンソールにAD設定が表示されません)。インストール手順については、使用しているLogon Managerのバージョン用のインストレーション・ガイドを参照してください。 |
ヒント: 開発環境またはステージング環境では、Internet Explorerで「発行元証明書の取り消しを確認する」オプションを無効にして、コンソールの起動時、およびマシンがインターネットに接続されていないときの遅延をなくします。(遅延は、Internet Explorerがサーバーの証明書を検索しているとき、および認証局に接続できずにタイムアウトした場合に発生します。)このオプションは本番マシンでは無効にしないでください。 |
このマニュアルに記載されていない設定については、ご使用の環境で特に指定されていないかぎり、デフォルト値のままにすることをお薦めします。Logon Manager管理コンソールで設定のチェック・ボックスが選択されていない場合は、デフォルト値が自動的に有効になります。この値は、チェック・ボックスの横にある非アクティブ・フィールドに表示されます。
この項では、推奨されるグローバル・エージェント設定のベスト・プラクティスを示します。次の説明に従って設定を構成し、カスタマイズされたLogon Manager MSIパッケージにそれらを含めます。(パッケージの作成手順については、Enterprise Single Sign-On Suiteインストレーション・ガイドの一括デプロイメントのためのLogon Managerのパッケージ化に関する説明を参照してください。)
Logon Managerの同期設定の構成を開始する前に、サポートされているどのディレクトリを使用しているかをLogon Managerに通知する必要があります。これによって、Logon Managerはリポジトリ構造を正しく解釈し、リポジトリの組込みデータ構造に干渉することなく、データを格納できます。
注意: リポジトリがリストされていない場合、アップグレード時に下位互換性用のドロップダウン・リストから「Unspecified LDAP Directory」(デフォルト)を選択し、それ以外の場合は、「Generic LDAP Directory」を選択します。サポートされているディレクトリのリストについては、Oracle Fusion Middlewareの動作保証マトリックスを参照してください。 |
場所: 「Global Agent Settings」→「Live」→「Synchronization」→「LDAPExt」
設定するには: チェック・ボックスを選択し、ドロップダウン・リストからリポジトリを選択します。
LDAP環境では、サーバーURLをLogon Managerに明示的に指定する必要があります。少なくとも2つの物理ディレクトリ・サーバーを使用し、自動的および透過的なフェイルオーバーのために、それらをロード・バランサの背後に置くことをお薦めします。ロード・バランサを使用しない場合は、エンド・ユーザーと次に使用可能なサーバーとの物理的な距離によるパフォーマンス・ヒットが最小になるように、エンド・ユーザーに対する地理的近接度の順序でサーバーURLを配置します。ロード・バランシングの詳細は、「Logon Managerデプロイメントのロード・バランシングの利点」を参照してください。
場所: 「Global Agent Settings」→「Live」→「Synchronization」→「LDAPExt」
設定するには: チェック・ボックスを選択して(…)ボタンをクリックし、必要な値を次に示すように(1行ごとに1つずつ)入力します。終了したら、「OK」をクリックします。
Logon ManagerでActive Directoryにデータを格納するには、Logon Managerのルート・コンテナ(Logon Managerの構成オブジェクトが格納される)の場所を指定する必要があります。
場所: 「Global Agent Settings」→「Live」→「Synchronization」→「LDAPEXT」
設定するには: チェック・ボックスを選択し、(…)ボタンをクリックして必要な値を入力します。終了したら、「OK」をクリックします。
LDAPディレクトリをデプロイする際、ユーザー・データおよび構成データの格納にディレクトリ・オブジェクトを使用することをお薦めします(これにより、「Logon Managerディレクトリのサブツリーの設計」の説明に従って、階層構造での格納、ロールおよびグループ・ベースの個別のコンテナに対するアクセス制御、テンプレートおよびポリシーを使用することが可能になります)。この機能を無効にしている場合、Logon Managerは、すべてのテンプレートおよび構成データをLogon Managerツリー・コンテナに単一のフラット・ファイルとして格納します。
場所: 「Global Agent Settings」→「Live」→「Synchronization」
有効にするには: チェック・ボックスを選択して、ドロップダウン・リストで「Yes」を選択します。
Logon ManagerリポジトリのシンクロナイザはSSLサポートが有効の状態で出荷されるので、これを無効にしないことを強くお薦めします。使用する環境では、セキュリティを最大化するために、Logon Managerおよびその他のリポジトリへのすべての接続に必ずSSLを使用してください。
注意: このオプションを有効にする前に、環境をSSL接続用に構成する必要があります。 |
場所: 「Global Agent Settings」→「Live」→「Synchronization」→「LDAPEXT」
有効にするには(無効になっている場合): チェック・ボックスの選択を解除します。
ディレクトリ内のユーザー・アカウントがあるコンテナの場所を指定する必要があります。ディレクトリ内の複数の場所にユーザー・アカウントが格納されている場合、複数のパスを指定できます。このオプションを構成するときは、次のガイドラインに従います。
「Enable Directory Search for Users」オプションが有効になっている場合、ここで値としてディレクトリ・ルートを指定しないでください。そのようにすると、ユーザーが無効なユーザー名を入力した場合にLogon Managerによってディレクトリ全体が解析されます。
指定したパスの範囲が広すぎた場合の余分なアカウント検索を避けるため、パスを指定する際はできるかぎり限定します。一方、場所の数が多すぎる場合、ここに共通の親コンテナを指定すると、構成の複雑さを軽減できます。
場所: 「Global Agent Settings」→「Live」→「Synchronization」→「LDAPEXT」
Logon Managerによるユーザー・アカウントの検索を行うには: チェック・ボックスの選択を解除します(デフォルト設定)。
設定するには: チェック・ボックスを選択して(…)ボタンをクリックし、必要な値を次に示すように(1行ごとに1つずつ)入力します。終了したら、「OK」をクリックします。
ディレクトリ内のユーザー・アカウントへの正確なパスを指定しない場合(たとえば、ユーザー・アカウントが多数の場所に広がっている場合など)、このオプションを有効にすると、「Logon Manager構成オブジェクトへのパスの指定」で設定された1つ以上の場所にあるユーザー・アカウントをLogon Managerで検索できます。この機能ではディレクトリへの匿名バインド・アクセスが必要なため、ディレクトリへの匿名バインド・アクセス権を付与せずにディレクトリ検索機能を有効にする場合は、「Bind User DN」および「Bind User Password」フィールドを使用して、ディレクトリ検索権限を持つユーザーを指定する必要があります。
場所: 「Global Agent Settings」→「Live」→「Synchronization」→「LDAPEXT」→「Special Purpose」
設定するには: チェック・ボックスを選択して、ドロップダウン・メニューから「Yes」を選択します。
Novel eDirectoryを使用している場合、「Naming attribute string」オプションの値をcnに設定する必要があります。その他のLDAPディレクトリの場合は、ディレクトリ・チームにこのオプションの構成方法を問い合せてください。
場所: 「Global Agent Settings」→「Live」→「Synchronization」→「LDAPEXT」→「Special Purpose」
設定するには: チェック・ボックスを選択し、希望の値を入力します。
認証が失敗したかまたは切断された場合に、ディレクトリに対して再認証を行うには、「Prompt when disconnected」オプションを使用して、Logon Managerがユーザーにプロンプトを表示するかどうかを決定します。この設定をデフォルト値の「No」のままにすることをお薦めします(こうすることで、不要な混乱とそれによるヘルプデスクへの問合せを避けられます)。
場所: 「Global Agent Settings」→「Live」→「Synchronization」→「LDAPEXT」
設定するには: チェック・ボックスを選択し、ドロップダウン・リストから適切なオプションを選択します。
このオプションは、前述した「Credentials to use」オプションに直接関連し、「Allow disconnected operation」が「No」に設定されている場合は何も効果はありません。
特定のシナリオでは、1つ以上のオーセンティケータでLDAP同期資格証明を共有することにより、エンド・ユーザーが受け取る認証プロンプトの数を減らすことができます。詳細は、「オーセンティケータの選択と構成」を参照してください。
場所: 「Global Agent Settings」→「Live」→「Synchronization」→「LDAPEXT」
設定するには: チェック・ボックスを選択し、ターゲット・オーセンティケータの名前をカンマで区切って入力します。
使用しているオーセンティケータに応じて、次のオーセンティケータ識別文字列を使用します。
オーセンティケータ |
識別文字列 |
Windows v1 (非推奨) |
WinAuth |
Windows v2 |
MSAuth |
LDAP v1 |
LDAP |
LDAP v2 |
LDAPAuth |
現在の環境が次のいずれかに該当する場合は、LDAP (LDAPEXT)シンクロナイザ・プラグインがインストールされていて、「Synchronizer Order」リストで有効になっていることを確認してください。
Logon Managerが複数のリポジトリと同期している。
Logon Managerがローミング同期を使用している。
現在の環境にKiosk Managerがインストールされている。
注意: 複数のリポジトリおよびローミング同期に対応するようにLogon Managerを構成する手順やKiosk Managerのインストールおよび構成方法は、このガイドでは取り扱いません。詳細は、使用しているバージョンのLogon ManagerやKiosk Managerに関するドキュメントを参照してください。 |
場所: 「Global Agent Settings」→「Live」→「Synchronization」
設定するには: チェック・ボックスを選択して、(…)ボタンをクリックします。表示されるリストで、「LDAPEXT」の横のチェック・ボックスを選択して、「OK」をクリックします。必要に応じて、上向きまたは下向きの矢印を使用して、同期順を設定します。
プロンプトが表示されたときに入力する資格証明がエンド・ユーザーにわかるように、このオプションを使用してディレクトリ認証プロンプトに説明的なタイトルを付けることをお薦めします。
場所: 「Global Agent Settings」→「Live」→「Synchronization」→「LDAPEXT」
設定するには: チェック・ボックスを選択し、希望のテキストを入力します。
ユーザーが常に最新の資格証明、アプリケーション・テンプレート、パスワード・ポリシーおよび管理オーバーライドを持つようにするには、起動時に同期を待つようにエージェントを構成します。このオプションを有効にすると、エージェントはディレクトリがオンラインかどうかを確認します。ディレクトリがオンラインの場合は、ディレクトリと正常に同期するまで、エージェントはアプリケーションのログオン・リクエストに応答しません。ディレクトリがオフラインの場合は、エージェントは同期を試行せずにすぐに起動します。
場所: 「Global Agent Settings」→「Live」→「Synchronization」
設定するには: チェック・ボックスを選択して、ドロップダウン・リストから「Yes」を選択します。
最適化された同期は、Logon Managerエージェントに、前回の同期の後で変更された資格証明のみを同期するように指示します。現在の環境に応じて、次のいずれかを実行します。
ユーザーごとの資格証明が大量にある場合は、このオプションを有効にすると、デプロイメントでの同期パフォーマンスが向上します。
ユーザーごとの資格証明が4つ以下で、ユーザーごとにダウンロードしたテンプレートが大量にある場合は、このオプションを無効にすると、デプロイメントでの同期パフォーマンスが向上します。
場所: 「Global Agent Settings」→「Live」→「Synchronization」
現在の環境で特に指定する必要がない場合は、デフォルト値(「Yes」)を使用してください。
デプロイ中にディレクトリへの接続を確立できない場合には、Logon Managerエージェントが実行されないように構成します。これにより、エージェントがディレクトリに接続されていない状態で、かつローカル・キャッシュが存在しない場合に、「First Time Use」(FTU)ウィザードが完了してしまうことを回避できます。ディレクトリが使用できないときにエージェントが実行されないようにすることで、ディレクトリから切断されているのにFTUウィザードが完了して暗号化鍵の2つ目のセットが作成されてしまう、というよくある状況を回避できます。
注意: この必要なベスト・プラクティスの詳細は、Enterprise Single Sign-On Suite管理者ガイドのLogon Managerエージェントの構成に関する項を参照してください。 |
場所: 「Global Agent Settings」→「Synchronization」
設定するには:チェック・ボックスを選択して、ドロップダウン・リストから「No」を選択します。
ドメイン名やオブジェクトのパスなどのディレクトリの同期設定は、管理オーバーライドとしてデプロイしないでください。(この説明は「グローバル・エージェント設定および管理オーバーライド」を参照してください。)推奨されるオーバーライドのベスト・プラクティスについては、Enterprise Single Sign-On Suite管理者ガイドのLogon Managerの構成に関する説明を参照してください。
この項では、LDAPディレクトリでのLogon Managerのデプロイメント・プロセスについて、その概要を説明します。デプロイメントを進める前に、このドキュメントの前の項にすべて目を通すようにしてください。LDAPディレクトリでのLogon Managerのデプロイでは、次の手順を実行する必要があります。
次のドキュメントを入手します。
このドキュメントの最新バージョン
Oracle Enterprise Single Sign-On Suiteインストレーション・ガイド
Oracle Enterprise Single Sign-On Suite管理者ガイド
使用しているバージョンのLogon Manager用インストレーション・ガイドの説明に従って、ドメイン内のマシンにLogon ManagerエージェントおよびLogon Manager管理コンソールをインストールします。エージェントのインストール時には、LDAPシンクロナイザ・プラグインが選択されていることを確認してください。
「Logon Managerのためのディレクトリの準備」の手順を完了します。
Logon Managerのクラスと属性を使用してディレクトリ・スキーマを拡張します。
各ユーザーのアプリケーション資格証明を格納するPeople OUを作成します。
vGOLocatorオブジェクトを作成します。
構成オブジェクト・コンテナおよび必要なツリー構造を作成します。
次のようにLogon Managerを構成します。
「オーセンティケータの選択と構成」の手順を完了します。
「LDAPシンクロナイザの構成」の手順を完了します。
このガイドの「推奨グローバル・エージェント設定」で説明されているオプションを構成します。
Enterprise Single Sign-On Suite管理者ガイドのLogon Managerエージェントの構成に関する項で説明されているオプションを構成します。
注意: 該当する設定の詳細は、コンソールのオンライン・ヘルプを参照してください。オンライン・ヘルプは、コンソールの「Help」メニューから参照できます。 |
テスト用のマシンで次の手順を実行します。
主なテンプレートおよびポリシーのパイロット・セットを作成します。
本番環境にデプロイされる、主なテンプレート、グローバル・エージェント設定、管理オーバーライドをそれぞれテストして、エンド・ユーザーの操作性を最終調整します。
Enterprise Single Sign-On Suiteインストレーション・ガイドの大量デプロイメント用のEnterprise Single Sign-On Suiteのパッケージ化の手順を完了して、カスタムMSIパッケージを作成し、エンド・ユーザーのマシンにデプロイします。
残りのアプリケーション・テンプレートの作成、テスト、デプロイメントを行います。異なるアプリケーション・タイプのプロビジョニングの詳細は、Logon Managerアプリケーション・テンプレートの構成および診断のガイドを参照してください。
この項では、ディレクトリをLogon Managerで使用するための基本的な準備手順について説明します。この準備では、それぞれのユーザー・オブジェクトに資格証明を格納できるように、Logon Managerのクラスと属性を使用してディレクトリ・スキーマを拡張し、必要なツリー構造を作成します。この手順を開始する前に、管理コンソールをインストール済であることを確認してください。
Suite管理コンソールを起動します。
注意: 開発環境またはステージング環境では、Internet Explorerで「発行元証明書の取り消しを確認する」オプションを無効にして、コンソールの起動時、およびマシンがインターネットに接続されていないときの遅延をなくします。(遅延は、Internet Explorerがサーバーの証明書を検索しているとき、および認証局に接続できずにタイムアウトした場合に発生します。)このオプションは本番マシンでは無効にしないでください。 |
コンソールで、「Repository」メニューから「Extend Schema」を選択します。コンソールに「Connect to Repository」ダイアログが表示されます。
「Server Name」フィールドに、スキーマのマスター・ドメイン・コントローラの完全修飾IPアドレス、ホスト名またはNetBIOS名を入力します。
「Repository Type」ドロップダウン・リストで、目的のLDAPディレクトリ・タイプを選択します。
ディレクトリで接続をリスニングしているポート番号を入力します。デフォルトのポートは、SSL接続の場合は636、非SSL接続の場合は389です。
(オプション) SSLを使用するようにディレクトリ・サーバーが構成されている場合は、「Use secure channel (SSL)」オプションを選択したままにし、使用しない場合は選択を解除します。(詳細は、「SSLのサポート」を参照してください。)
「Username/ID」および「Password」フィールドで、Logon Managerがディレクトリに接続するときに使用するアカウントの資格証明を入力します。環境によっては、ユーザー名の一部に対応するドメイン名を含める必要があります(例: DOMAIN\user)。
「OK」をクリックして、コンソールがスキーマの拡張を実行するのを待ちます。コンソールに進行状況を示すステータス・ダイアログが表示されます。スキーマが正常に拡張されると、ステータス・ダイアログに確認のメッセージが表示されます。
「Close」をクリックします。
注意: 既存のコンテナを使用してLogon Managerデータを格納することもできますが、その場合、ディレクトリのパフォーマンスが低下することがあります。サブツリーのルートとして専用のコンテナを作成することをお薦めします。 |
Logon Manager管理コンソールで、ツリー上の「Repository」ノードを選択します。
右側ペインで「Click here to connect」リンクをクリックします。コンソールに「Connect to Repository」ダイアログが表示されます。
29ページの手順3から7の説明に従って、フィールドを入力し、「OK」をクリックして接続します。
Logon Managerのサブツリーのルートとして機能するコンテナを作成します。
次に示すように、このツリーで対象の親コンテナを右クリックし、コンテキスト・メニューから「New Container」を選択します。
コンソールに「New Container」ダイアログが表示されます。
「New Container」ダイアログで、必要な名前を入力して「OK」をクリックします。
注意: 現在の環境で、このコンテナに特定の名前を必要としない場合は、デフォルト名のESSOを使用することをお薦めします。 |
Logon Manager構成オブジェクト・コンテナ(SSOConfig)を作成します。
次に示すように、このツリーでLogon Managerのサブツリーのルートを右クリックし、コンテキスト・メニューから「New Container」を選択します。
コンソールに「New Container」ダイアログが表示されます。
「New Container」ダイアログで、必要な名前を入力して「OK」をクリックします。
注意: 現在の環境で、このコンテナに特定の名前を必要としない場合は、デフォルト名のSSOConfigを使用することをお薦めします。 |
手順5を繰り返して、必要な追加のコンテナを作成します。
Logon Managerユーザー用にアプリケーション資格証明を保持するPeople OUを作成する必要があります。People OUはLogon Managerのサブツリーのルートに置くことをお薦めします。
注意: Logon Manager構成オブジェクト・コンテナ(SSOConfig)の内部にPeople OUを配置しないでください。そのようにすると、テンプレートのロード時に、ディレクトリにかなりの不必要な負荷を与えて、すべてのLogon Managerユーザーの資格証明をLogon Managerによって解析することになります。 Sun Directory Serverでは、ディレクトリのルートにあるPeopleという名前のコンテナにユーザー・アカウントが格納されます。Logon Managerアプリケーション資格証明の格納にはそのコンテナを使用せず、かわりに、Logon Manager People OUを別の親コンテナ内に作成してください。 |
People OUを作成するには:
Logon Manager管理コンソールで、ツリー上の「Repository」ノードを選択します。
右側ペインで「Click here to connect」リンクをクリックします。コンソールに「Connect to Directory」ダイアログが表示されます。29ページの手順3から7の説明に従って、フィールドを入力し、「OK」をクリックして接続します。
ツリーでLogon Managerサブツリーのルートを右クリックし、「Create People Container」を選択します。
People OUがターゲットの場所に存在するようになったことを確認します。
前述の手順を完了した後にPeople OUが表示されない場合、またはディレクトリ内のネーミング違反やその他の問題を示すエラーを受け取った場合、ディレクトリのベンダーのドキュメントで考えられる原因および処置を参照してください。
People OUを作成すると、ユーザー・アカウントをPeople OUに格納されているユーザー・アプリケーション資格証明にリンクするvGOLocatorポインタ・オブジェクトを作成する必要があります。
注意: 少なくともユーザー・アカウントを保持するコンテナと同じレベルにvGOLocatorオブジェクトを作成する必要があります。vGOLocatorは、ディレクトリのユーザー・アカウント・コンテナ内に置くのが理想的です。 |
vGOLocatorオブジェクトを作成するには:
Logon Manager管理コンソールで、ツリー上の「Repository」ノードを選択します。
右側ペインで「Click here to connect」リンクをクリックします。コンソールに「Connect to Repository」ダイアログが表示されます。31ページの手順3から7の説明に従って、フィールドを入力し、「OK」をクリックして接続します。
次に示すように、このツリーでディレクトリのユーザー・アカウント・コンテナ(Sun Directory Serverベースの例ではdc=oracle,ou=People)を右クリックし、コンテキスト・メニューから「Add Locator Object」を選択します。
表示される「Add Locator Object」ダイアログで、次の手順を実行します。
「Name」フィールドにdefaultと入力します。
「Forwarding Location」フィールドに、People OUを保持するコンテナへのフルパスを入力します。(または、ツリーを使用して、ターゲット・コンテナにナビゲートして選択できます。)
「OK」をクリックします。
vGOLocatorオブジェクトが目的の場所に存在することを確認します。
オーセンティケータは、Logon Managerのユーザーを一意に認証するために必要です。LDAP環境では、構成に基づいて、次のいずれかのオーセンティケータを選択できます。
Windowsパスワード・オーセンティケータ(バージョン2)。次の条件が満たされる場合、認証プロンプトが表示されないようにできるため、このオーセンティケータの使用をお薦めします(詳細は、「オーセンティケータとのLDAPシンクロナイザ資格証明の共有」を参照してください)。
ユーザーがActive DirectoryまたはNTドメイン・アカウントを持っている。
LDAPディレクトリ資格証明がActive DirectoryまたはNTドメインと同期されている。
LDAPオーセンティケータ(バージョン2)。マシン・ログオンに基づいてユーザーを一意に識別できない場合(たとえば、ユーザーが総称的にログインするキオスクやその他の環境において、またはユーザーがActive DirectoryまたはNTドメイン・アカウントを持っていない場合)は、このオーセンティケータを使用します。このシナリオでは、同期とユーザー資格証明が同一でないかぎり、追加の認証プロンプトがユーザーに表示されます(詳細は、「オーセンティケータとのLDAPシンクロナイザ資格証明の共有」を参照してください)。
Logon Manager用のLDAPの準備ができたら、現在の環境用にLDAPシンクロナイザを構成します。テンプレート・クライアント・マシン上でこれらの設定を構成し、エンド・ユーザーへのLogon Managerのデプロイに使用するMSIパッケージに、その構成を含めます。この手順を開始する前に、Logon Manager管理コンソールおよびLogon Managerエージェント(LDAPシンクロナイザ・プラグインを含む)がインストールされていることを確認します。
注意: ディレクトリの同期が行われる環境では機能しないので、アプリケーション・テンプレートをMSIパッケージに含めないでください。MSIパッケージにテンプレートを直接含める機能は、特別な場合にのみ使用します。かわりに、Logon Managerエージェントによる自動取得用のディレクトリにそれらをプッシュ送信します。 |
Logon Manager管理コンソールを起動します。
左側ペインで、「Global Agent Settings」ノードを右クリックして、コンテキスト・メニューから「Import」→「From Live HKLM」を選択します。現在のエージェント設定がWindowsのレジストリからコンソールにインポートされます。
「推奨グローバル・エージェント設定」および「推奨管理オーバーライド」の手順に従ってエージェントを構成します。
注意: 設定の横のチェック・ボックスが選択されていない場合は、設定のデフォルト値(チェック・ボックスの右にグレー表示されている値)が使用されます。 |
後で参照するために、構成をXMLファイルに保存します。「File」メニューから「Save」を選択し、必要なファイル名を入力して「Save」をクリックします。設定を変更する場合は、このXMLファイルをコンソールにロードして元の選択に戻すことができます。
「Tools」メニューから「Write Global Agent Settings to HKLM」を選択します。コンソールによって、変更がレジストリに書き込まれ、エージェントが再起動されます。