| Oracle® Fusion Middlewareディレクトリ・ベースのリポジトリでのLogon Managerのデプロイ 11gリリース2 (11.1.2.2) E51904-01 |
|
 前 |
 次 |
| Oracle® Fusion Middlewareディレクトリ・ベースのリポジトリでのLogon Managerのデプロイ 11gリリース2 (11.1.2.2) E51904-01 |
|
前 |
次 |
この章では、Microsoft AD LDS (ADAM)でのLogon Managerのデプロイメントにおけるベスト・プラクティスについて説明します。内容は次のとおりです。
AD LDS (ADAM)やAD LDSなどのディレクトリ環境にLogon Managerをデプロイする選択肢もあり、これにより、ネットワーク上の任意のマシンに対して、アプリケーション資格証明、テンプレートおよびポリシーの一括格納によるシングル・サインオン機能を実装できます。ユーザーは、このディレクトリを同期して、これらの項目をダウンロードし、新規作成または変更された資格証明で資格証明ストアを更新します。
既存のディレクトリ環境にLogon Managerを追加すると、次のような利点があります。
Logon Managerでは既存のユーザー・アカウント、グループおよびネイティブのディレクトリ権限(ACL)を使用できるため、これらの項目を個別に管理したり、他のディレクトリまたはデータベースと同期する必要がありません。
Logon Managerのデータは、既存のバックアップおよび障害時リカバリ計画によって自動的に保護されます。
専用サーバーやサーバー側のプロセスは不要で、Logon Managerのスケーラビリティとパフォーマンスは、既存のディレクトリ・インフラストラクチャの容量と堅牢性のみに依存します。
管理者のタスクが増えることはなく、また新しいツールや概念について学習する必要もありません。Logon Managerの委任管理は、ディレクトリのネイティブ機能によって行われます。
また、ディレクトリの使用によって、Logon Managerのテンプレートとポリシーの編成を見やすい階層構造で表示することもできます。現行の環境で必要な場合はフラット・モデルを使用できますが、階層を適切に設定すれば、より効率的なアクセス制御によって、トップ・ディレクトリ、エージェント、およびネットワークのパフォーマンスの安定化を図り、Logon Managerの管理を簡略化できます。
AD LDS (ADAM)は、ディレクトリ対応アプリケーションに対してデータ格納およびデータ取得を提供し、Active Directoryで必要とされる依存関係は使用されません。AD LDS (ADAM)では、Active Directoryと同じ機能が多く提供されますが、ドメインまたはドメイン・コントローラのデプロイメントは必要とされず、AD LDS (ADAM)のディレクトリ・スキーマは、Active Directoryドメインで使用している可能性があるエンタープライズ・スキーマから完全に独立しています。単一のサーバー上の複数インスタンスのAD LDS (ADAM)のそれぞれに対して、独立して管理されたスキーマを使用して、それらのインスタンスを同時に実行することができます。AD LDS (ADAM)でのLogon Managerのデプロイの利点は次のとおりです。
パイロット・デプロイメントおよび概念実証デプロイメントの理想。フルスケールのActive Directory環境を忠実に模倣する、完全に機能するAD LDS (ADAM)インスタンスは、数分で設定することができ、完全に自己包含型です(それが実行されるActive Directoryホストのみを要求します)。
簡略化デプロイメント。AD LDS (ADAM)はMicrosoftから無料で入手できます。既存のActive Directory環境でのデプロイメントは容易であり、既存のユーザー・アカウントおよびグループを再利用できます。
効率的なスケーリングおよびフォルト・トレランス。AD LDS (ADAM)はActive Directoryコードに基づいているため、そのスケーラビリティ特性はActive Directoryのものと類似しています。2つのサーバーのみで、約5,000のLogon Managerユーザーをサポートすることができ、基本的なフォルト・トレランスを確保にするのに十分です。5,000よりも多いメンバーで組織が構成されている場合、スケーラビリティおよびフォルト・トレランスの詳細はMicrosoftの熟練者に問い合せてください。
さらに、既存のActive Directory環境におけるAD LDS (ADAM)でのLogon Managerのデプロイには、次のような利点があります。
再トレーニングが最小で済みます。AD LDS (ADAM)の管理手順は、Active Directoryの管理手順と類似しています。Active Directoryのスキルを持つ管理者は、追加の努力をほとんどしなくても、AD LDS (ADAM)インスタンスをデプロイおよび保守することができ、両方のプラットフォームの管理ツールは、Active Directoryの管理ツールをミラー化します。
既存のActive Directoryのアカウントおよびポリシーを利用できます。Active Directoryのユーザー・アカウント、グループおよびポリシーを、AD LDS (ADAM)ですぐに使用できます。既存の構成およびユーザー・アカウント・データをインポート、再作成または同期する必要はありません。
次の表に、Active DirectoryとAD LDS (ADAM)の主な違いを示します。
|
機能 |
Active Directory |
AD LDS (ADAM) |
|
サーバー検出およびフェイルオーバー |
完全に自動。クライアントはリクエストをブロードキャストし、最も近い場所にあるサーバーからの応答をリスニングします。サーバーからサーバーへのフォールバックが自動であるため、フェイルオーバーは単純です。 |
ロード・バランサの使用時は自動であり、その他の場合は明示的なサーバー・リストが必要です。 ロード・バランシングの利点の詳細は、「Logon Managerデプロイメントのロード・バランシングの利点」を参照してください。ロード・バランサを使用しない場合は、接続先のサーバーのリストを、地理的近接度の順序で、クライアントに明示的に指定する必要があります。 |
|
スキーマの拡張 |
グローバル。必要なLogon Managerオブジェクト・クラスをActive Directoryスキーマに追加するには、スキーマの拡張を実行する必要があります。既存のクラスおよび属性を変更する方法はありません。管理者は、ディレクトリ上の全体としての拡張の影響(通常はごくわずか)を理解する必要があります。スキーマの拡張の詳細は、「付録B: Logon Managerリポジトリ・オブジェクトのクラスおよび属性」を参照してください。 |
ローカル。Logon ManagerをAD LDS (ADAM)にデプロイする際、ターゲットAD LDS (ADAM)インスタンスに対してのみスキーマの拡張を実行する必要があります。拡張は、Active Directoryのスキーマ拡張と同じ4つのオブジェクト・クラスで構成されます。 |
|
ユーザー・オブジェクトへの資格証明の格納 |
はい。Logon Managerアプリケーション資格証明を各ユーザー・オブジェクトに格納するオプションがあります。 |
いいえ。ユーザー資格証明はすべて、AD LDS (ADAM)インスタンス内の専用のOUに格納されます。このOUには、各Logon Managerユーザーに1つのオブジェクトが含まれます。 |
|
ユーザー・レポート |
はい。Logon ManagerをActive Directoryにデプロイすると、ディレクトリに格納されたユーザー資格証明の特定の時点の情報を取得できます。 |
いいえ。AD LDS (ADAM)環境では、Logon Managerに対する特定時点の情報のレポートはサポートされていません。(Provisioning Gatewayがインストールされている場合はAD LDS (ADAM)上で使用できます。) |
AD LDS (ADAM)およびそのアプリケーションの詳細は、次を参照してください。
ADAMのFAQ: http://www.microsoft.com/windowsserver2003/ADAM/ADAMfaq.mspx
AD LDSのFAQ: http://technet.microsoft.com/en-us/library/cc755080%28WS.10%29.aspx
Logon ManagerによってAD LDS (ADAM)内にデータを格納できるようにするには、管理コンソールを使用して、選択したAD LDS (ADAM)インスタンスのスキーマ(Active Directoryのホストのスキーマは影響されません)を拡張する必要があります。スキーマの拡張は、4つのオブジェクト・クラスを追加し、これらのタイプのオブジェクトを作成、読取り、変更、削除できるように、適切な権限を設定して行います。既存のクラスおよび属性を変更する方法はありません。
|
注意: スキーマの拡張はインストール後の手順です。手順については、「Logon ManagerのためのAD LDS (ADAM)インスタンスの準備」を参照してください。スキーマの拡張を実行する前に、(Microsoftのベスト・プラクティスで説明されているように)スキーマ・ヘルス・チェックを実行することを強くお薦めします。 |
Logon Managerによって実行されるスキーマの拡張の詳細は、次の付録を参照してください。
Logon Managerエージェントは、AD LDS (ADAM)シンクロナイザのプラグインを使用してAD LDS (ADAM)と通信します。適切に設定されている場合は、次のいずれかのイベントが発生すると同期が実行されます。
Logon Managerエージェントが起動された
アプリケーション資格証明がエンド・ユーザーによって、追加、変更または削除された
エージェントを実行しているマシンがIPアドレスを取得した、または既存のIPアドレスが変更された(Logon Managerがこれらのイベントに応答するように設定されている場合)
自動同期の間隔が経過した(設定されている場合)
ユーザーがエージェントのリフレッシュ機能を使用して同期を開始した
同期を実行している間、Logon Managerエージェントは、Logon Managerサブツリーを移動して、現在のユーザーにアクセス権が付与されているサブコンテナのコンテンツをロードし、前回の同期後に追加、変更または削除された資格証明を同期します。
Logon Managerは、ユーザーが「First-Time Use (FTU)」ウィザードを完了したときに生成される一意キーを使用してアプリケーション資格証明を暗号化します。資格証明は、エージェントのローカル・キャッシュ内、ディレクトリ内およびネットワークを移動しているときも常に暗号化された状態を維持します。Logon Managerは、設定されたアプリケーションがログオンをリクエストしたときにのみ資格証明を(ディスクではなくメモリーに対して)復号化し、ログオン・リクエストの完了後すぐにターゲット・メモリーの場所を消去します。ユーザーおよび有効なアプリケーションごとにLogon Managerが格納するデータ量はわずかです(数バイトか数キロバイト)。
ディレクトリ・サーバーが失敗すると、Logon Managerはサーバー・リストの次のサーバーに接続しようとします。リスト上のどのサーバーにもアクセスできない場合、その問題が修正されるまでは同期が使用できなくなります。使用している環境で複数の物理AD LDS (ADAM)サーバーが必要な場合、AD LDS (ADAM)サーバー間で、ネットワークからのリクエストを自動的に均等に分散させるロード・バランサを使用することを強くお薦めします。1つのサーバーがオフラインになった場合、その障害のあるマシンのワークロードを残りのサーバーで一時的に吸収することができ、エンド・ユーザーに対するフェイルオーバー透過性、および障害のあるサーバーをオンラインに戻すための十分な時間が提供されます。
Logon Managerでは、組織のニーズに合わせてディレクトリ構造を思いのままに設定できます。具体的には、データをフラット・モデルで格納するか階層構造で格納するかの選択肢があります。フラット・モデルは小規模なデプロイメントでは問題なく機能しますが、成長する大規模なデプロイメントでは最初から階層構造を使用します。サブツリーの適切な構造は次の要素によって決まります。
ユーザーの数
Logon Managerでサポートするアプリケーションの数
既存のインフラストラクチャの堅牢性
組織の構造。
次のガイドラインに従ってサブツリーを階層構造として設定することをお薦めします。
OUを使用して、部門や部署など、組織の構造に合わせたカテゴリごとにテンプレート、ポリシーおよび資格証明をグループ化します。
OUレベルでアクセスを制御します。
現在の環境で特に指定がないかぎり、継承を無効化し、Logon Managerのルート・コンテナでユーザー権限を付与しないようにします。
このように階層を設定すると、次の利点があります。
見やすくわかりやすいツリー構造。ディレクトリ・ブラウザでサブツリーを表示すると、サブツリー構造を一覧できるので全体が把握しやすくなります。
不要な権限の継承なし。ユーザーには、アクセスする必要のないサブOUに対する権限はネイティブで継承されません。これにより、ツリーの下位に継承される不要なアクセス権限を明示的に拒否せずに済みます。
ネットワーク、エージェントおよびディレクトリの堅牢なパフォーマンス。通常、大量のテンプレートおよびポリシーをダウンロードするユーザーは、自分のジョブに関連する項目のみをダウンロードするユーザーよりもネットワーク・トラフィックが多く、ディレクトリの負荷も高くなります。グループ化によって、環境のリソースが節約され、エージェントのレスポンス時間が改善されます。
管理タスクの分散。テンプレートを制御しやすいセットに整理し、アクセス権限の設定によって、ユーザーが管理できるテンプレートを決定します。権限に基づいたテンプレートのバージョン制御を実装する機能も使用できます。
低い管理オーバーヘッド。テンプレート・レベルでのアクセスの制御では、Logon Manager管理コンソールから個々のテンプレートに権限を設定する必要があり、OUレベルでのアクセスの制御は、Microsoftやサードパーティの管理ツールを使用した委任管理によって行います。
次の図は、前述のベスト・プラクティスを反映して設計されたサンプルのLogon Managerサブツリーを示しています。
サンプルのシナリオでは、ポートランド部門のユーザーは、サクラメント部門で使用するアプリケーションへのアクセスは不要で、その逆も同様であるため、各部門のテンプレートおよびポリシーは、ルートの専用サブOUに配置し、両部門が互いのサブOUにアクセスできないようにしています。つまり、具体的な実装方法は使用する環境によって決まります。
Active Directoryと異なり、AD LDS (ADAM)ではLogon Managerによってアプリケーション資格証明をユーザー・オブジェクトに格納できません。かわりに、AD LDS (ADAM)にデプロイすると、Logon Managerはアプリケーション資格証明をPeopleと呼ばれる特別なOU内にフラット形式で格納します。Peopleコンテナは、デフォルトではAD LDS (ADAM)パーティションのルートにありますが、より詳細なアクセス制御が必要な場合は、図3に示すように、テンプレートおよびポリシーに対する場合と同様に、組織内の異なる部門や領域に複数のPeopleコンテナ(それぞれに一意のパスが必要)を作成できます。次に、各部門のLogon Mangerインスタンスを構成し、その部門のPeople OU内でアプリケーション資格証明を検索します。「People OUの作成」の説明に従って、People OUを作成し、AD LDS (ADAM)シンクロナイザへのフルパスを指定する必要があります。
|
注意: コンテナ・オブジェクトは、各Logon Managerユーザーに対する最初の使用時に、ユーザー・データを公開せずに独立させておくためにPeople OU内に自動的に作成されます。 |
Provisioning Gatewayを使用しており、複数のPeople OUを利用する場合は、次の制限が適用されます。
|
注意: 単一のドメインを持つProvisioning Gatewayで複数のPeople OUを使用することはできません。 |
People OUは、AD LDS (ADAM)パーティションのルートで親コンテナ内に存在する必要があります。
親コンテナの名前は、アプリケーション資格証明が対応するPeople OU内に格納されるユーザーのドメイン(NTスタイル)の名前である必要があります。必要な場合は、個別のPeople OUを必要とする部門または領域ごとに個別のドメインを作成し、対応するユーザーをそのドメインに移動します。
フラット・モデルで開始し、ユーザーおよびプロビジョニングするアプリケーションの数が多くなると予想される場合は、階層構造への移行の準備ができるまでは、ルートの下にサブコンテナを作成し、それを使用してテンプレートとポリシーをフラットに格納します。ユーザーを追加したり、アプリケーションをさらにプロビジョニングする際には、階層に移行してなるべく早いうちに環境のパフォーマンスを確認してください(後で確認するよりも手間を省くことができます)。階層に移行するとき、新しいLogon Managerルート・コンテナとして既存のコンテナを使用し、その下にサブOUを作成します。
図3に示すように、ワークフローの各段階(開発、ステージング、本番)で専用のサブOUを作成することをお薦めします。この方法によって次のことができます。
テンプレートおよびポリシーがワークフローを通過して本番に入るときには、ワークフローの各ステージを移動するたびにこれらのシャドウ・コピーが保持されるので、テンプレートおよびポリシーに対して行われた変更をトラッキングできます。
必要に応じて、テンプレートおよびポリシーを以前のバージョンにロールバックできます。
ワークフローの各ステージで、誰がどのテンプレートおよびポリシーを使用するかを制御できます。特に、テンプレートおよびポリシーを本番に配置できるユーザーの管理には、厳格なルール設定が必要です。
必ず、隔離した環境ですべてのアプリケーション・テンプレートおよび管理オーバーライドをテストしてから、エンド・ユーザーにデプロイしてください。テストは、変更内容の確認や、本番環境で発生したとしたら、解決するのに多くのコストがかかるような潜在的な問題の解決に役立ちます。正しく構成されていないテンプレートや誤った管理オーバーライドをネットワーク全体にプッシュした場合、ミッション・クリティカルなアプリケーションへのアクセスがエンタープライズ全体で失われることがあるので、テストは大規模なデプロイメントでは特に重要です。
隔離したテスト環境をセットアップする場合は、デプロイメント・グループのメンバーのみがアクセス権を持つ専用のテスト・コンテナを作成してください。次に、このコンテナ内のLogon Managerエージェントを特定して、テンプレートと管理オーバーライドをその中に配置します。テンプレートとポリシーが意図したとおりに動作していることを確認したら、それらをターゲットの本番コンテナに移動します。
テンプレートをテストした後にシャドウ・コピーを維持しない場合、次の手順に従って、それらをテスト・コンテナからターゲットの本番コンテナに移動します。
テンプレートをディレクトリから取得します。
そのテンプレートのローカル・バックアップを作成します。
ディレクトリ内の新しい場所に、このコピーを配置します。
テンプレートを元の場所から削除します。
コンソールを使用してオブジェクトのアクセス制御リスト(ACL)を変更する場合、リポジトリに接続するために使用される接続文字列(リポジトリ・ホスト名またはIP)は、コンソールでは一意のリポジトリ識別子として扱われ、オブジェクト内に記録されます。そのため、コンソールは、同じリポジトリに接続する2つ目の一意リポジトリや2つ目のメソッドを識別できません。
これにより、同一ディレクトリに対して異なる接続文字列(IPアドレスやホスト名)を使用すると、セッション間で行われたオブジェクトへの変更が失われます。AD LDS (ADAM)環境でこの問題を回避するには、コンソールを介してオブジェクトの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管理者ガイドにある情報を補足します。
|
警告: ドメイン名やユーザー・オブジェクト・パスなどの設定は、必ず十分にテストしてからデプロイし、必要のない場合は管理オーバーライドとしてデプロイしないでください。入力ミスによるドメイン名の単純な間違いなどによって、エンド・ユーザーのワークステーションでディレクトリの同期ができなくなると、コンソールから修正内容を伝えることはできないため、他のツールを使用してユーザー・マシンに変更を適用する必要があります。 |
次の図は、AD LDS (ADAM)と同期するためのLogon Manager管理コンソールの標準的な設定を示しています。
次の項では、AD LDS (ADAM)と同期するためのLogon Managerの構成について、そのベスト・プラクティスを説明します。このガイドで説明されている設定の詳細な情報が必要な場合は、コンソールに含まれているオンライン・ヘルプを参照してください。
|
注意: 開始する前に、Logon ManagerエージェントとAD LDS (ADAM)のシンクロナイザ・プラグインがインストールされていることを確認してください(インストールされていないとコンソールにAD LDS (ADAM)関連の設定が表示されません)。インストール手順については、使用しているLogon Managerのバージョン用のインストレーション・ガイドを参照してください。 |
|
ヒント: 開発環境またはステージング環境では、Internet Explorerで「発行元証明書の取り消しを確認する」オプションを無効にして、コンソールの起動時、およびマシンがインターネットに接続されていないときの遅延をなくします。(遅延は、Internet Explorerがサーバーの証明書を検索しているとき、および認証局に接続できずにタイムアウトした場合に発生します。)このオプションは本番マシンでは無効にしないでください。 |
このマニュアルおよび他のガイドに記載されていない設定については、ご使用の環境で特に指定されていないかぎり、デフォルト値のままにすることをお薦めします。管理コンソールで設定のチェック・ボックスが選択されていない場合は、デフォルト値が自動的に有効になります。この値は、チェック・ボックスの横にある非アクティブ・フィールドに表示されます。
この項では、推奨されるグローバル・エージェント設定のベスト・プラクティスを示します。次の説明に従って設定を構成し、カスタマイズされたLogon Manager MSIパッケージにそれらを含めます。パッケージの作成手順については、Enterprise Single Sign-On Suiteインストレーション・ガイドの一括デプロイメントのためのLogon Managerのパッケージ化に関する説明を参照してください。
AD LDS (ADAM)のデプロイメントでは、ユーザー・データおよび構成データの格納にディレクトリ・オブジェクトを使用することをお薦めします(これにより、「AD LDS (ADAM)ディレクトリのサブツリーの設計」の説明に従って、階層構造での格納、ロールおよびグループ・ベースの個別のコンテナに対するアクセス制御、テンプレートおよびポリシーを使用することが可能になります)。この機能を無効にしている場合、Logon Managerは、すべてのテンプレートおよび構成データをツリーのルートの下に単一のフラット・ファイルとして格納します。
場所: 「Global Agent Settings」→「Live」→「Synchronization」
有効にするには: チェック・ボックスを選択して、ドロップダウン・リストで「Yes」を選択します。
AD LDS (ADAM)環境では、サーバーURLをLogon Managerに明示的に指定する必要があります。少なくとも2つの物理AD LDS (ADAM)サーバーを使用し、自動的および透過的なフェイルオーバーのために、それらをロード・バランサの背後に置くことをお薦めします。ロード・バランサを使用しない場合は、エンド・ユーザーと次に使用可能なサーバーとの物理的な距離によるパフォーマンス・ヒットが最小になるように、エンド・ユーザーに対する地理的近接度の順序でサーバーURLを配置します。ロード・バランシングの詳細は、「Logon Managerデプロイメントのロード・バランシングの利点」を参照してください。
場所: 「Global Agent Settings」→「Live」→「Synchronization」→「ADAMSyncExt」
設定するには: チェック・ボックスを選択して(…)ボタンをクリックし、必要な値を次に示すように(1行ごとに1つずつ)入力します。終了したら、「OK」をクリックします。
Logon ManagerでAD LDS (ADAM)にデータを格納するには、Logon Managerのルート・コンテナ(Logon Managerの構成オブジェクトが格納される)の場所を指定する必要があります。
場所: 「Global Agent Settings」→「Live」→「Synchronization」→「ADAMSyncExt」
設定するには: チェック・ボックスを選択し、(…)ボタンをクリックして必要な値を入力します。終了したら、「OK」をクリックします。
Logon ManagerリポジトリのシンクロナイザはSSLサポートが有効の状態で出荷されるので、これを無効にしないことを強くお薦めします。使用する環境では、セキュリティを最大化するために、Logon Managerおよびその他のリポジトリへのすべての接続に必ずSSLを使用してください。
|
注意: 注意: Logon Managerをデプロイする前に、SSLを使用するようにドメイン・コントローラを構成してください。手順の詳細は、 |
場所: 「Global Agent Settings」→「Live」→「Synchronization」→「ADAMSyncExt」
有効にするには(無効になっている場合): チェック・ボックスの選択を解除します。
「Credentials to use」オプションを使用して、リポジトリに対する認証を行う場合に、Logon Managerで使用する資格証明を選択します。Logon Managerがリポジトリに対して認証できない場合に、ユーザーに再認証のためのプロンプトが表示されないように、これを「Local computer credentials」に設定することをお薦めします。
|
注意: これをデフォルトの設定(「Try local computer credentials before using AD LDS (ADAM) server account」)のままにしないでください。デフォルト設定のままにすると、リポジトリとエンド・ユーザー・マシンが同じドメイン上にない場合に、認証が失敗します(無効に設定していないかぎり、再認証のプロンプトが表示されます)。 Smart Cardを使用してLogon Managerに対する認証を行う場合、ドロップダウン・メニューから「Use card's certificate」を選択することで、カードの資格証明を使用してリポジトリに対する認証を行うこともできます。詳細は、『Oracle Enterprise Single Sign-On Suite Plus管理者ガイド』を参照してください。 |
場所: 「Global Agent Settings」→「Live」→「Synchronization」→「ADAMSyncExt」
設定するには: チェック・ボックスを選択し、ドロップダウン・リストから適切なオプションを選択します。
デフォルト(AD LDS (ADAM)パーティションのルート)以外の場所にPeople OUを作成した場合、またはアプリケーション資格証明へのアクセスをより詳細に制御するために複数のPeople OUを作成した場合、「Designing the AD LDS (ADAM)ディレクトリのサブツリーの設計」の説明に従って、対応するPeople OUを使用するためにターゲットのLogon Managerインスタンスを構成する必要があります。
場所: 「Global Agent Settings」→「Live」→「Synchronization」→「ADAMSyncExt」
設定するには: 「People container」オプションの横のチェック・ボックスを選択し、Logon Managerで使用する特定のPeople OUへの完全修飾パスをフィールドに入力します。次に例を示します。
OU=People,OU=City,OU=State,OU=Country,OU=ssopartition,DC=company,DC=com
認証が失敗したかまたは切断された場合に、リポジトリに対して再認証を行うには、「Prompt when disconnected」オプションを使用して、Logon Managerがユーザーにプロンプトを表示するかどうかを決定します。これを「No」に設定することをお薦めします(こうすることで、不要な混乱およびヘルプデスクへの問合せを避けることができます)。
場所: 「Global Agent Settings」→「Live」→「Synchronization」→「ADAMSyncExt」
設定するには: チェック・ボックスを選択し、ドロップダウン・リストから適切なオプションを選択します。
このオプションは、前述した「Credentials to use」オプションに直接関連し、「Allow disconnected operation」が「No」に設定されている場合は何も効果はありません。
現在の環境が次のいずれかに該当する場合は、AD LDS (ADAM) (ADAMSyncExt)シンクロナイザ・プラグインがインストールされていて、「Synchronizer order」リストで有効になっていることを確認してください。
Logon Managerが複数のリポジトリと同期している、
Logon Managerがローミング同期を使用している、
現在の環境にKiosk Managerがインストールされている。
|
注意: 複数のリポジトリおよびローミング同期に対応するようにLogon Managerを構成する手順やKiosk Managerのインストールおよび構成方法は、このガイドでは取り扱いません。詳細は、使用しているバージョンのLogon ManagerやKiosk Managerに関するドキュメントを参照してください。 |
場所: 「Global Agent Settings」→「Synchronization」
設定するには: チェック・ボックスを選択して、(…)ボタンをクリックします。表示されるリストで、「ADAMSyncExt」の横のチェック・ボックスを選択して、「OK」をクリックします。必要に応じて、上向きまたは下向きの矢印を使用して、同期順を設定します。
ユーザーが常に最新の資格証明、アプリケーション・テンプレート、パスワード・ポリシーおよび管理オーバーライドを持つようにするには、起動時に同期を待つようにエージェントを構成します。このオプションを有効にすると、エージェントはディレクトリがオンラインかどうかを確認します。ディレクトリがオンラインの場合は、ディレクトリと正常に同期するまで、エージェントはアプリケーションのログオン・リクエストに応答しません。ディレクトリがオフラインの場合は、エージェントは同期を試行せずにすぐに起動します。
場所: 「Global Agent Settings」→「Live」→「Synchronization」
現在の環境で特に指定する必要がない場合は、デフォルト値(「Yes」)を使用してください。
最適化された同期は、Logon Managerエージェントに、前回の同期の後で変更された資格証明のみを同期するように指示します。現在の環境に応じて、次のいずれかを実行します。
ユーザーごとの資格証明が大量にある場合は、このオプションを有効にすると、デプロイメントでの同期パフォーマンスが向上します。
ユーザーごとの資格証明が4つ以下で、ユーザーごとにダウンロードしたテンプレートが大量にある場合は、このオプションを無効にすると、デプロイメントでの同期パフォーマンスが向上します。
場所: 「Global Agent Settings」→「Live」→「Synchronization」
現在の環境で特に指定する必要がない場合は、デフォルト値(「Yes」)を使用してください。
デプロイ中にディレクトリへの接続を確立できない場合には、Logon Managerエージェントが実行されないように構成します。これにより、エージェントがディレクトリに接続されていない状態で、かつローカル・キャッシュが存在しない場合に、「First Time Use」(FTU)ウィザードが完了してしまうことを回避できます。ディレクトリが使用できないときにエージェントが実行されないようにすることで、ディレクトリから切断されているのにFTUウィザードが完了して暗号化鍵の2つ目のセットが作成されてしまう、というよくある状況を回避できます。
|
注意: 必要なベスト・プラクティスの詳細は、Logon Managerベスト・プラクティス: Logon Managerエージェントの構成のガイドを参照してください。 |
場所: 「Global Agent Settings」→「Live」→「Synchronization」
設定するには:チェック・ボックスを選択して、ドロップダウン・リストから「No」を選択します。
ドメイン名やオブジェクトのパスなどのディレクトリの同期設定は、管理オーバーライドとしてデプロイしないでください。(この説明は「グローバル・エージェント設定および管理オーバーライド」を参照してください。)推奨されるオーバーライドのベスト・プラクティスについては、Logon Enterprise Single Sign-On Suite管理者ガイドのLogon Managerの構成に関する説明を参照してください。
この項では、AD LDS (ADAM)でのLogon Managerのデプロイメント・プロセスについて、その概要を説明します。デプロイメントを進める前に、このドキュメントの前の項にすべて目を通すようにしてください。MS AD LDS (ADAM)でのLogon Managerのデプロイでは、次の手順を実行する必要があります。
1.次のドキュメントを入手します。
このドキュメントの最新バージョン
Oracle Enterprise Single Sign-On Suiteインストレーション・ガイド
Oracle Enterprise Single Sign-On Suite管理者ガイド
まだの場合は、AD LDS (ADAM)をターゲット・サーバーにインストールします。AD LDS (ADAM)インストーラおよびインストール手順は、MicrosoftのWebサイトを参照してください。
Logon Manager管理者およびLogon Managerユーザーのグループを作成します。基本的な手順は、「付録E: AD LDS (ADAM)上での必要なユーザー・グループの作成」を参照してください。
「AD LDS (ADAM)インスタンスの作成」の説明に従って、Logon Managerで使用する新しいAD LDS (ADAM)インスタンスを作成します。
使用しているバージョンのLogon Manager用インストレーション・ガイドの説明に従って、ドメイン内のマシンにLogon ManagerエージェントおよびLogon Manager管理コンソールをインストールします。エージェントのインストール時には、AD LDS (ADAM)シンクロナイザが選択されていることを確認してください。
「Logon ManagerのためのAD LDS (ADAM)インスタンスの準備」の手順を完了します。
Logon Managerのクラスと属性を使用してAD LDS (ADAM)インスタンス・スキーマを拡張します。
各ユーザーのアプリケーション資格証明を格納するPeople OUを作成します。
Logon Manager構成オブジェクト・コンテナおよび必要なツリー構造を作成します。
必要な権限を付与します。
次のようにLogon Managerを構成します。
「AD LDS (ADAM)シンクロナイザの構成」の手順を完了します。
このガイドの「推奨グローバル・エージェント設定」で説明されているオプションを構成します。
Enterprise Single Sign-On Suite管理者ガイドのLogon Managerエージェントの構成に関する項で説明されているオプションを構成します。
|
注意: 該当する設定の詳細は、コンソールのオンライン・ヘルプを参照してください。 |
テスト用のマシンで次の手順を実行します。
主なテンプレートおよびポリシーのパイロット・セットを作成します。
本番環境にデプロイされる、主なテンプレート、グローバル・エージェント設定、管理オーバーライドをそれぞれテストして、エンド・ユーザーの操作性を最終調整します。
Oracle Enterprise Single Sign-On Suiteインストレーション・ガイドの大量デプロイメント用のOracle Enterprise Single Sign-On Suiteのパッケージ化の手順を完了して、カスタムMSIパッケージを作成し、エンド・ユーザーのマシンにデプロイします。
残りのアプリケーション・テンプレートの作成、テスト、デプロイメントを行います。異なるアプリケーション・タイプのプロビジョニングの詳細は、アプリケーション・テンプレートの構成および診断のガイドを参照してください。
この項では、Logon ManagerをデプロイするAD LDS (ADAM)インスタンスの作成方法について説明します。まだの場合は、AD LDS (ADAM)をターゲット・サーバーにインストールします。AD LDS (ADAM)インストーラおよびインストール手順は、MicrosoftのWebサイトを参照してください。開始する前に、次の点に注意してください。
Windows Server 2008以上のバージョンのWindows Serverオペレーティング・システム・ファミリをデプロイすることをお薦めします。Windows XPまたはWindows 7でのデプロイメントは推奨されていません。2008より前のWindows Serverバージョンへのデプロイメントはサポートされていません。
デプロイメントを簡略化するため、デフォルトのポート(SSL接続の場合は636)で実行するAD LDS (ADAM)インスタンスを作成することをお薦めします(AD LDS (ADAM)への非SSL接続はサポートされていますが、推奨されません)。カスタム・ポートを使用する場合、すべてのクライアントとターゲット・サーバーの間で開いている必要があります。
|
注意: リポジトリへの接続のタイプにかかわらず、ユーザー資格証明データは常に暗号化されたままです。 |
ディレクトリがすでに実行中であるドメイン・コントローラまたは別のサーバー上にAD LDS (ADAM)をインストールする場合、デフォルトのポートを使用できないため、ドメイン・コントローラではなくメンバー・サーバー上にLogon Managerをデプロイすることをお薦めします。
ターゲットAD LDS (ADAM)インスタンスを作成するには:
|
注意: このガイドに示したAD LDS (ADAM)設定ウィザード画面は、サポートされるWindows Serverオペレーティング・システム・ファミリのバージョン間で異なる可能性がありますが、手順はサポートされるすべてのバージョンで同一です。 |
AD LDS (ADAM)セットアップ・ウィザードを起動します。
Windows Server 2008の場合: 「スタート」→「プログラム」→「管理ツール」→「Active Directory ライトウェイト ディレクトリ サービス セットアップ ウィザード」をクリックします。
Windows Server 2008 R2の場合:
|
注意: この手順を開始する前に、「Active Directory ライトウェイト ディレクトリ サービス」ロールをサーバーに追加したことを確認してください。 |
「サーバー マネージャー」で、「役割」ノードを展開し、「Active Directory ライトウェイト ディレクトリ サービス」ロールを選択します。右側ペインで、「詳細ツール」→「AD LDS ツール」セクションを展開し、「AD LDS セットアップ ウィザード」をクリックします。
「ようこそ」画面で「次へ」をクリックします。
「セットアップ オプション」画面で、「一意のインスタンス」を選択して「次へ」をクリックします。
AD LDS (ADAM)インスタンスの名前を指定し、「次へ」をクリックします。推奨される名前はssopartitionです。
このAD LDS (ADAM)インスタンスに目的のポート番号を入力します。デフォルトのポート(389/636)を使用しない場合、ここで入力したカスタム・ポート番号をメモしてください(後でLogon Managerの構成に必要です)。
「アプリケーション ディレクトリ パーティションを作成する」を選択し、パーティションに完全修飾DNを指定します。これは、AD LDS (ADAM)インスタンスのサブツリーのルートです。DNは、ダイアログ・ボックスが示すように、cn=ではなくou=で開始する必要があり、そうしない場合は、Logon Managerのデプロイメントが失敗します。
AD LDS (ADAM)がファイルを格納する場所を指定します。ほとんどの場合、デフォルト値を受け入れてかまいません。
このAD LDS (ADAM)のインスタンスが実行に使用する権限を指定します。
「このアカウント」を選択し、「参照」をクリックして、このAD LDS (ADAM)のインスタンスに対する管理権限を持つユーザーまたはグループを指定します。Logon Managerのデプロイメント全体でロックアウトを防止するために、ターゲットAD LDS (ADAM)インスタンスに対して管理権限を持つ2つ以上のユーザーを含む専用グループを作成することをお薦めします。詳細は、「付録E: AD LDS (ADAM)上での必要なユーザー・グループの作成」を参照してください。
「このAD LDS (ADAM)インスタンス用にはLDIFファイルをインポートしない」を選択して、「次へ」をクリックします。
サマリー画面で、構成の選択内容を確認します。変更が必要な場合は「戻る」をクリックし、必要がない場合は、「次へ」をクリックしてAD LDS (ADAM)がインスタンスを作成するのを待ちます。
プロセスが完了したら、「完了」をクリックしてウィザードを終了します。
この項では、AD LDS (ADAM)をLogon Managerで使用するための基本的な準備手順について説明します。この準備では、それぞれのユーザー・オブジェクトに資格証明を格納できるように、Logon Managerのクラスと属性を使用してAD LDS (ADAM)スキーマを拡張し、必要なツリー構造を作成します。この手順を開始する前に、管理コンソールをインストール済であることを確認してください。
Logon Manager管理コンソールを起動します。デフォルトでは、コンソールのショートカットは「スタート」→「プログラム」→「Oracle」→「ESSO Suite Administrative Console」にあります。
|
注意: 開発環境またはステージング環境では、Internet Explorerで「発行元証明書の取り消しを確認する」オプションを無効にして、コンソールの起動時、およびマシンがインターネットに接続されていないときの遅延をなくします。(遅延は、Internet Explorerがサーバーの証明書を検索しているとき、および認証局に接続できずにタイムアウトした場合に発生します。)このオプションは本番マシンでは無効にしないでください。 |
コンソールで、「Repository」メニューから「Extend Schema」を選択します。コンソールに「Connect to Repository」ダイアログが表示されます。
「Server Name」フィールドに、スキーマのマスター・ドメイン・コントローラの完全修飾IPアドレス、ホスト名またはNetBIOS名を入力します。
「Repository Type」ドロップダウン・リストで、「Microsoft AD LDS (ADAM)」を選択します。
ディレクトリで接続をリスニングしているポート番号を入力します。デフォルトのポートは、SSL接続の場合は636、非SSL接続の場合は389です。
(オプション) SSLを使用するようにドメイン・コントローラを構成している場合は、「Use secure channel (SSL)」オプションを選択したままにし、使用しない場合は選択を解除します。(詳細は、「SSLのサポート」を参照してください。)
「Username/ID」および「Password」フィールドで、Logon ManagerがAD LDS (ADAM)に接続するときに使用するアカウントの資格証明を入力します。環境によっては、ユーザー名の一部に対応するドメイン名を含める必要があります(例: DOMAIN\user)。
「OK」をクリックして、コンソールがスキーマの拡張を実行するのを待ちます。コンソールに進行状況を示すステータス・ダイアログが表示されます。スキーマが正常に拡張されると、ステータス・ダイアログに確認のメッセージが表示されます。
「Close」をクリックします。
スキーマの拡張が失敗する場合、28ページの手順6の説明に従ってAD LDS (ADAM)インスタンスのDNを正しく指定したことを確認してください。DNが正しくない場合は、AD LDS (ADAM)インスタンスを削除して再作成し、この手順を繰り返します。
AD LDS (ADAM)インスタンス・スキーマを拡張した後、Logon Managerがアプリケーション資格証明の格納に使用する、少なくとも1つのPeople OUを作成する必要があります。デフォルトでは、Logon Managerは、People OUがターゲットAD LDS (ADAM)パーティションのルートにあることを予期しています。
しかし、より詳細な制御が必要な場合、「特定のPeople OUを使用するLogon Managerの構成」の説明に従って、組織の要件に基づき、ディレクトリ内の任意の場所に1つ以上のPeople OUを作成し、Logon Managerの異なるインスタンスに異なるPeople OUへの完全修飾パスを指定することができます。
People OUを作成するには:
ESSO Suite Administrative Consoleで、ツリー上の「Repository」ノードを選択します。
右側ペインで「Click here to connect」リンクをクリックします。コンソールに「Connect to Repository」ダイアログが表示されます。54ページの手順3から7の説明に従って、フィールドを入力し、「OK」をクリックして接続します。
ツリーでターゲットAD LDS (ADAM)インスタンスのルートを右クリックし、コンテキスト・メニューから「Create People Container」を選択します。
People OUがAD LDS (ADAM)インスタンスのサブツリーのルートに存在するようになったことを確認します。
前述の手順を完了した後にPeople OUが表示されない場合、またはディレクトリ内のネーミング違反やその他の問題を示すエラーを受け取った場合、AD LDS (ADAM)のドキュメントで考えられる原因および処置を参照してください。
|
注意: 既存のコンテナを使用してLogon Managerオブジェクトを格納することもできますが、その場合、ディレクトリのパフォーマンスが低下することがあります。構成オブジェクト専用のコンテナを作成することをお薦めします。 |
Logon Manager管理コンソールで、ツリー上の「Repository」ノードを選択します。
右側ペインで「Click here to connect」リンクをクリックします。コンソールに「Connect to Directory」ダイアログが表示されます。
32ページの手順3から7の説明に従って、フィールドを入力し、「OK」をクリックして接続します。
次に示すように、このツリーで対象の親コンテナを右クリックし、コンテキスト・メニューから「New Container」を選択します。
コンソールに「New Container」ダイアログが表示されます。
「New Container」ダイアログで、必要な名前を入力して「OK」をクリックします。
|
注意: 現在の環境で、このコンテナに特定の名前を必要としない場合は、デフォルト名のSSOConfigを使用することをお薦めします。 |
手順4と5を繰り返して、必要な追加のコンテナを作成します。
Logon Managerを使用できるようにするために、Logon Managerユーザーに次の権限を付与する必要があります。
Logon Managerアプリケーション・パーティションへの読取りアクセス。これにより、同期中にユーザーが構成オブジェクトおよび資格証明を読み取ることが許可されます。
People OUへの書込みアクセス。これにより、同期中にユーザーが資格証明オブジェクトを作成することが許可されます。
|
注意: この手順は、SSOUsersグループがすでに作成され、必要なユーザーがそのグループに追加されていることを前提としています。前述の権限は、個別のユーザーではなく、SSOUsersグループに対して付与します。グループを作成してそのグループにユーザーを割り当てる手順については、「付録B: Logon Managerリポジトリ・オブジェクトのクラスおよび属性」を参照してください。 |
これらの権限を付与するには:
ターゲット・サーバーに管理者としてログオンし、コマンド・プロンプトを開きます。
次のコマンドを使用して、SSOUsersグループにLogon Managerアプリケーション・パーティションへの読取りアクセスを付与します(コマンドは1行であることに注意してください)。
dsacls\\<hostname>:<port>\<sso_partition_dn> /G"<domain>\SSOUsers":gr
次のコマンドを使用して、SSOUsersグループにPeople OUへの書込みアクセスを付与します(コマンドは1行であることに注意してください)。
dsacls\\<hostname>:<port>\OU=People,<sso_partition_dn> /G "<domain>\SSOUsers":CCWS
前述のコマンドの変数は次のように置き換えます。
<hostname> - ターゲットAD LDS (ADAM)インスタンスを実行しているサーバーのURL。
<domain> - ターゲット・ドメイン名。
<port> - ターゲットAD LDS (ADAM)インスタンスが接続をリスニングしているポート。
<sso_partition_dn> - Logon Managerアプリケーション・パーティションの完全修飾DN。例: ou=ssopartition,dc=ssolab,dc=com
Logon Manager用のAD LDS (ADAM)の準備ができたら、現在の環境用にAD LDS (ADAM)シンクロナイザを構成します。テンプレート・クライアント・マシン上でこれらの設定を構成し、エンド・ユーザーへのLogon Managerのデプロイに使用するMSIパッケージに、その構成を含めます。この手順を開始する前に、Logon Manager管理コンソールおよびLogon Managerエージェント(AD LDS (ADAM)シンクロナイザ・プラグインを含む)がインストールされていることを確認します。
|
注意: ディレクトリの同期が行われる環境では機能しないので、アプリケーション・テンプレートを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」を選択します。コンソールによって、変更がレジストリに書き込まれ、エージェントが再起動されます。
