Oracle® Enterprise Single Sign-On
Logon Manager ディレクトリ・ベースのリポジトリでのLogon Managerのデプロイ リリース11.1.2.1.0 B71102-02(原本部品番号:E27161-03) 2013年3月 |
Oracle Enterprise Single Sign-On Logon Manager: ディレクトリ・ベースのリポジトリでのLogon Managerのデプロイ
リリース11.1.2.1.0
B71102-02
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。
ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。
このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。
U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.
このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。
OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。
このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。
目次
Microsoft Active DirectoryへのLogon Managerのデプロイ
Logon ManagerおよびActive Directoryの環境
Logon ManagerによるActive Directoryスキーマの拡張方法
Logon ManagerとActive Directoryの同期方法
Logon Managerによるアプリケーション資格証明の処理と格納の方法
Logon Manager Active Directoryのサブツリーの設計
テンプレートおよびポリシーのバージョン制御とプリフライト・テスト
コンソールを使用したオブジェクトのアクセス制御リスト(ACL)の構成に関する注意事項
エージェントおよびコンソールのアップグレードに関する注意事項
Logon Managerによる最も近いドメイン・コントローラの検出
ディレクトリへの接続が切断された場合にユーザーにプロンプトを表示するかどうかの決定
「Synchronizer order」リストへのActive Directoryシンクロナイザの追加
起動時に同期を待つようにLogon Managerエージェントを構成する手順
Logon ManagerのためのActive Directoryの準備
手順2: ユーザー・オブジェクトへのユーザー資格証明の格納の有効化
手順3: Logon Manager構成オブジェクト・コンテナおよびサブツリー構造の作成
Microsoft AD LDS (ADAM)でのLogon Managerのデプロイ
Logon ManagerおよびAD LDS (ADAM)の環境
Active Directory対AD LDS (ADAM)
Logon ManagerによるAD LDS (ADAM)スキーマの拡張方法
Logon ManagerとAD LDS (ADAM)の同期方法
Logon Managerによるアプリケーション資格証明の処理と格納の方法
Logon Managerデプロイメントのロード・バランシングの利点
Logon ManagerのAD LDS (ADAM)サブツリーの構築に関するガイドライン
テンプレートおよびポリシーのバージョン制御とプリフライト・テスト
コンソールを使用したオブジェクトのアクセス制御リスト(ACL)の構成に関する注意事項
エージェントおよびコンソールのアップグレードに関する注意事項
特定のPeople OUを使用するLogon Managerの構成
リポジトリへの接続が切断された場合にユーザーにプロンプトを表示するかどうかの選択.
「Synchronizer Order」リストへのAD LDS (ADAM)シンクロナイザの追加
起動時に同期を待つようにLogon Managerエージェントを構成する手順
Logon ManagerのためのAD LDS (ADAM)インスタンスの準備
手順3: Logon Manager構成オブジェクト・コンテナおよびサブツリー構造の作成
手順4: Logon Managerユーザーへの必要な権限の付与
LDAPディレクトリでのLogon Managerのデプロイ
Logon Managerによるディレクトリ・スキーマの拡張方法
Logon Managerによるアプリケーション資格証明の処理と格納の方法
Logon Managerデプロイメントのロード・バランシングの利点
Logon Managerのサブツリーの構築に関するガイドライン
Logon Managerに必要な特殊ディレクトリ・オブジェクト
テンプレートおよびポリシーのバージョン制御とプリフライト・テスト
コンソールを使用したオブジェクトのアクセス制御リスト(ACL)の構成に関する注意事項
エージェントおよびコンソールのアップグレードに関する注意事項
「Enable Directory Search for Users」
ディレクトリへの接続が切断された場合にユーザーにプロンプトを表示するかどうかの決定
「Synchronizer Order」リストへのLDAPシンクロナイザの追加
起動時に同期を待つようにLogon Managerエージェントを構成する手順
手順2: Logon Managerのサブツリーのルートおよび構成オブジェクト・コンテナの作成
付録A: Logon Managerリポジトリ・オブジェクト用の最小管理権限
付録B: Logon Managerリポジトリ・オブジェクトのクラスおよび属性
付録C: Active DirectoryでのLogon Managerのトラブルシューティング
すべてのユーザーがユーザー・オブジェクトの下に資格証明を格納できない
一部のユーザーがユーザー・オブジェクトの下に資格証明を格納できない
付録D: Microsoft AD LDS (ADAM)でのLogon Managerのトラブルシューティング
ターゲットAD LDS (ADAM)インスタンスが実行中でない
AD LDS (ADAM)インスタンスがデフォルト以外のポートで実行中
AD LDS (ADAM)への接続に使用するアカウントに必要な権限がない
付録E: AD LDS (ADAM)デプロイメント上での必要なユーザー・グループの作成
付録F: Logon Managerで使用するためのOracle Internet Directoryの構成
付録G: Logon Managerで使用するためのOracle Virtual Directoryの構成
このガイドでは、Oracle Enterprise Single Sign-On Manager (Logon Manager)をMicrosoft Active Directory、Microsoft AD LDS (ADAM)、およびOracle Internet DirectoryなどのLDAPディレクトリとともにデプロイするためのベスト・プラクティスおよび推奨手順について説明します。このガイドの読者は、熟練したシステム管理者であり、ディレクトリのスキーマ、構造、セキュリティなどの周辺技術および関連する概念を十分に理解している必要があります。
Logon Managerのデプロイメントを計画する前に、このガイドに目を通し、推奨の準備手順、デプロイメント手順、短期と長期の問題を回避するためのアドバイスについて理解しておくことを強くお薦めします。
Oracleサポート・サービスでは、My Oracle Supportを通して電子支援サービスを提供しています。
詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。
このマニュアルでは次の表記規則を使用します。
用語または略語 |
説明 |
太字 |
太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。 |
イタリック |
イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。 |
固定幅フォント |
固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。 |
オラクル社ではドキュメントの正確さと最新情報の維持に努めています。このドキュメントおよびその他のドキュメントの最新版は、http://docs.oracle.com/cd/E29306_01/index.htmを参照してください。?
詳細は、このリリースのドキュメント・セットに含まれる次のドキュメントを参照してください。
・ Oracle Enterprise Single Sign-On Suite Plus
o リリース・ノート
o インストレーション・ガイド
o 管理者ガイド
o セキュア・デプロイメント・ガイド
o ユーザーズ・ガイド
・ Oracle Enterprise Single Sign-On Logon Manager
o Logon Managerアプリケーション・テンプレートの構成および診断
・ Oracle Enterprise Single Sign-On Provisioning Gateway
o 管理者ガイド
o コマンドライン・インタフェース・ガイド
o Oracle Identity Managerコネクタ・ガイド
o Sun Java System Identity Managerコネクタ・ガイド
o IBM Tivoli Identity Managerコネクタ・ガイド
・ Oracle Enterprise Single Sign-On Universal Authentication Manager
o 管理者ガイド
o ユーザーズ・ガイド
この部では、Microsoft Active DirectoryでのLogon Managerのデプロイメントにおけるベスト・プラクティスについて説明します。
内容は次のとおりです。
・ Logon ManagerおよびActive Directoryの環境
・ Logon Manager Active Directoryのサブツリーの設計
・ Logon ManagerのためのActive Directoryの準備
Oracle Enterprise Single Sign-On Logon Manager (Logon Manager)は、ユーザーとターゲット・アプリケーションの間の中間層として機能するセキュアで容易にデプロイ可能なシングル・サインオン・ソリューションです。ユーザーの認証は1回で済み、ユーザー資格証明に対する後続のすべてのリクエストはLogon Managerによって自動的に検出されて処理されます。Logon Managerの詳細は、Oracleサポートで入手できるOracle Enterprise Single Sign-On Suite Plusの技術概要ホワイト・ペーパーを参照してください。
Active Directoryなどのディレクトリ環境にLogon Managerをデプロイする選択肢もあり、これにより、ネットワーク上の任意のマシンに対して、アプリケーション資格証明、テンプレートおよびポリシーの一括格納によるシングル・サインオン機能を実装できます。ユーザーは、このディレクトリを同期して、これらの項目をダウンロードし、新規作成または変更されたユーザー名やパスワードで資格証明ストアを更新します。
既存のディレクトリ環境にLogon Managerを追加すると、次のような利点があります。
・ Logon Managerでは既存のユーザー・アカウント、グループおよびネイティブのディレクトリ権限(ACL)を使用できるため、これらの項目を個別に管理したり、他のディレクトリまたはデータベースと同期する必要がありません。
・ Logon Managerのデータは、既存のバックアップ、フェイルオーバー、および障害時リカバリ計画によって自動的に保護されます。
・ 専用サーバーやサーバー側のプロセスは不要で、Logon Managerのスケーラビリティとパフォーマンスは、既存のディレクトリ・インフラストラクチャの容量と堅牢性のみに依存します。
・ 管理者のタスクが増えることはなく、また新しいツールや概念について学習する必要もありません。Logon Managerの委任管理は、ディレクトリのネイティブ機能によって行われます。
また、ディレクトリの使用によって、Logon Managerのテンプレートとポリシーの編成を見やすい階層構造で表示することもできます。現行の環境で必要な場合はフラット・モデルを使用できますが、階層を適切に設定すれば、より効率的なアクセス制御によって、トップ・ディレクトリ、エージェント、およびネットワークのパフォーマンスの安定化を図り、Logon Managerの管理を簡略化できます。
Logon ManagerでActive Directoryにデータを格納するためには、管理コンソールを使用してActive Directoryスキーマを拡張する必要があります。スキーマの拡張は、4つのオブジェクト・クラスを追加し、これらのタイプのオブジェクトを作成、読取り、変更、削除できるように、適切な権限を設定して行います。既存のクラスおよび属性を変更する方法はありません。Logon Managerでアプリケーション資格証明をユーザー・オブジェクトに格納する場合(推奨されるベスト・プラクティス)は、この機能に必要な権限もLogon Managerによって適用されます。
注意: スキーマの拡張はインストール後の手順です。手順については、「Logon ManagerのためのActive Directoryの準備」を参照してください。スキーマの拡張を実行する前に、Microsoft MOMなどのツールを使用してスキーマ・ヘルス・チェックを実行することを強くお薦めします。
Logon Managerによって実行されるスキーマの拡張の詳細は、次の付録を参照してください。
・ 付録A: Logon Managerリポジトリ・オブジェクト用の最小管理権限
・ 付録B: 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はディレクトリ接続時のSSL暗号化をサポートしています。SSLのサポートは、通常は必要ありませんが特定のシナリオでは必要になります。詳細は、「SSLのサポート」を参照してください。
Logon Managerソフトウェアのアーキテクチャについては、このガイドでは詳しく取り扱いません。
詳細な説明が記載されたOracleのホワイト・ペーパーをお求めの場合は、オラクル社の担当者に問い合せてください。
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やサードパーティの管理ツールを使用した委任管理によって行います。
図1は、前述のベスト・プラクティスを反映して設計されたサンプルのLogon Managerサブツリーを示しています。
サンプルのシナリオでは、ポートランド部門のユーザーは、サクラメント部門で使用するアプリケーションへのアクセスは不要で、その逆も同様なので、各部門のテンプレートおよびポリシーは、ルートの専用サブOUに配置し、両部門が互いのサブOUにアクセスできないようにしています。つまり、具体的な実装方法は使用する環境によって決まります。
注意: テンプレートおよびポリシーは、個々のOUに格納することをお薦めします。
これを行うには、設定オブジェクトのユーザーを有効にする必要があります。
フラット・モデルで開始し、ユーザーおよびプロビジョニングするアプリケーションの数が多くなると予想される場合は、階層構造への移行の準備ができるまでは、ルートの下にサブコンテナを作成し、それを使用してテンプレートとポリシーをフラットに格納します。ユーザーを追加したり、アプリケーションをさらにプロビジョニングする際には、階層に移行してなるべく早いうちに環境のパフォーマンスを確認してください(後で確認するよりも手間を省くことができます)。
図1に示すように、ワークフローの各段階(開発、ステージング、本番)で専用のサブOUを作成することをお薦めします。この方法によって次のことができます。
・ テンプレートおよびポリシーがワークフローを通過して本番に入るときには、ワークフローの各ステージを移動するたびにこれらのシャドウ・コピーが保持されるので、テンプレートおよびポリシーに対して行われた変更をトラッキングできます。
・ 必要に応じて、テンプレートおよびポリシーを以前のバージョンにロールバックできます。
・ ワークフローの各ステージで、誰がどのテンプレートおよびポリシーを使用するかを制御できます。特に、テンプレートおよびポリシーを本番に配置できるユーザーの管理には、厳格なルール設定が必要です。
必ず、隔離した環境ですべてのアプリケーション・テンプレートおよび管理オーバーライドをテストしてから、エンド・ユーザーにデプロイしてください。テストは、変更内容の確認や、本番環境で発生したとしたら、解決するのに多くのコストがかかるような潜在的な問題の解決に役立ちます。正しく構成されていないテンプレートや誤った管理オーバーライドをネットワーク全体にプッシュした場合、ミッション・クリティカルなアプリケーションへのアクセスがエンタープライズ全体で失われることがあるので、テストは大規模なデプロイメントでは特に重要です。
隔離したテスト環境をセットアップする場合は、デプロイメント・グループのメンバーのみがアクセス権を持つ専用のテスト・コンテナを作成してください。次に、このコンテナ内のLogon Managerエージェントを特定して、テンプレートと管理オーバーライドをその中に配置します。テンプレートとポリシーが意図したとおりに動作していることを確認したら、それらをターゲットの本番コンテナに移動します。
テンプレートをテストした後にシャドウ・コピーを維持しない場合、次の手順に従って、それらをテスト・コンテナからターゲットの本番コンテナに移動します。
1. ディレクトリからテンプレートを取り出します。
2. そのテンプレートのローカル・バックアップを作成します。
3. ディレクトリ内の新しい場所に、このコピーを配置します。
コンソールを使用してオブジェクトのアクセス制御リスト(ACL)を変更する場合、リポジトリに接続するために使用される接続文字列(リポジトリ・ホスト名またはIP)は、コンソールでは一意のリポジトリ識別子として扱われ、オブジェクト内に記録されます。そのため、コンソールは、同じリポジトリに接続する2つ目の一意リポジトリや2つ目のメソッドを識別できません。
これにより、同一ディレクトリに対して異なる接続文字列(IPアドレスやホスト名)を使用すると、セッション間で行われたオブジェクトへの変更が失われます。Active Directory環境でこの問題を回避するには、特定のIPアドレスまたはホスト名を使用せずにリポジトリのドメインを使用します。これにより、コンソールから最も近い場所にあるDCへの接続が自動的に行われるため、接続文字列の一貫性が保たれ、オブジェクトのACLに対して行われた変更がセッション間で維持されます。
環境全体でテンプレートと設定の互換性を維持するには、常に、本番にデプロイされているエージェントの
最も古いバージョンと一致するコンソールのバージョンを使用することです。テンプレート・スキーマはリリース間で変更されるため、新しいバージョンのコンソールによって作成または変更されたテンプレートを使用すると、古いエージェントは予期しない動作をする可能性があります。このため、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レジストリに格納されているグローバル・エージェント設定よりも優先され、エージェント用のドメイン・ポリシーを構成します。オーバーライドは、同期中にエージェントによって中央リポジトリからダウンロードされ、暗号化および改ざん防止機能を持つエージェントのローカル・キャッシュに格納されるので、エンド・ユーザーからの変更は受け付けられません。ロール/グループのセキュリティが有効な場合、管理オーバーライドはユーザーまたはグループごとに適用することも、企業全体に適用してすべてのユーザー設定の一貫性を保つこともできます。
注意: 管理オーバーライドを計画する場合は慎重に行ってください。オーバーライドが少なければ、格納および転送するデータも少なくなるので、中央リポジトリとの同期がより効率的になります。エンド・ユーザーのマシン上では管理オーバーライドを確認することができないため、オーバーライドの数を減らすことで不明な状況が解消され、トラブルシューティングも容易になります。
管理オーバーライドとグローバル・エージェント設定は、エージェントの完全な構成ポリシーを適用します。このガイドの残りの部分では、推奨される最適な構成について説明し、他のLogon Managerベスト・プラクティスのガイドにある情報を補足します。
警告: ドメイン名やユーザー・オブジェクト・パスなどの設定は、必ず十分にテストしてからデプロイし、必要のない場合は管理オーバーライドとしてデプロイしないでください。入力ミスによるドメイン名の単純な間違いなどによって、エンド・ユーザーのワークステーションでディレクトリの同期ができなくなると、コンソールから修正内容を伝えることはできないため、他のツールを使用してユーザー・マシンに変更を適用する必要があります。
図2は、Active Directoryと同期するためのLogon Manager管理コンソールの標準的な設定を示しています。
次の項では、Active Directoryと同期するためのLogon Managerの構成について、そのベスト・プラクティスを説明します。このガイドで説明されている設定の詳細な情報が必要な場合は、コンソールに含まれているオンライン・ヘルプを参照してください。
注意: 開始する前に、Logon ManagerエージェントとActive Directoryのシンクロナイザ・プラグインがインストールされていることを確認してください(インストールされていないとコンソールにADが表示されません)。インストール手順については、使用しているLogon Managerのバージョン用のインストールおよび設定ガイドを参照してください。
ヒント: 開発およびステージング環境では、Internet Explorerの「発行元証明書の取り消しを確認する」オプションを無効にして、コンソールの起動時に、マシンがインターネットに接続されていない場合の遅延が起きないようにします。(この遅延は、Internet Explorerによるサーバー証明書の確認が行われて、証明書認証局にアクセスできずタイムアウトするまでの時間です。)このオプションは本番マシンでは無効にしないでください。
このガイドや他のLogon Managerベスト・プラクティスガイドで説明されていない設定は、現在の環境で特に指定がないかぎり、デフォルト値のままにすることをお薦めします。Logon Manager管理コンソールで設定のチェック・ボックスが選択されていない場合は、デフォルト値が自動的に有効になります。この値は、チェック・ボックスの横にある非アクティブ・フィールドに表示されます。
この項では、推奨されるグローバル・エージェント設定のベスト・プラクティスを示します。次の説明に従って設定を構成し、カスタマイズされたLogon Manager MSIパッケージにそれらを含めます。(パッケージの作成手順については、ベスト・プラクティス: 大規模デプロイメント用のLogon Managerの構成のガイドを参照してください。)
次の手順に従って、Logon Managerのデータの格納を構成することをお薦めします。
Active Directoryのデプロイメントでは、ユーザー・データおよび構成データの格納にディレクトリ・オブジェクトを使用することをお薦めします(これにより、「Logon Manager Active Directoryのサブツリーの設計」の説明に従って、階層構造での格納、ロールおよびグループ・ベースの個別のコンテナに対するアクセス制御、テンプレートおよびポリシーを使用することが可能になります)。この機能を無効にしている場合、Logon Managerは、すべてのテンプレートおよび構成データをツリーのルートの下に単一のフラット・ファイルとして格納します。
?場所: 「Global Agent Settings」a「Live」a「Synchronization」
有効にするには: チェック・ボックスを選択して、ドロップダウン・リストで「Yes」を選択します。
Logon ManagerでActive Directoryにデータを格納するには、Logon Managerのルート・コンテナ(Logon Managerの構成オブジェクトが格納される)の場所を指定する必要があります。
?場所: 「Global Agent Settings」a「Live」a「Synchronization」a「ADEXT」
設定するには: チェック・ボックスを選択し、(…)ボタンをクリックして必要な値を入力します。
????????????? 完了したら「OK」をクリックします。
Logon ManagerをActive Directoryで使用する主な利点は、それぞれのユーザー・オブジェクトの下にユーザー資格証明を格納できることです。こうすることで、次のような管理の簡略化が図れます。
・ 個別のユーザーの資格証明を検索したり表示する操作がすばやく直感的になります。
・ ディレクトリからユーザーを削除すると、ユーザーのアプリケーション資格証明のキャッシュがそれぞれのユーザー・オブジェクトから自動的に削除されます。
注意:? このオプションは、必要なスキーマの変更と権限の割当てを行わないかぎり機能しません。手順については、「Logon ManagerのためのActive Directoryの準備」を参照してください。
注意:? ユーザー資格証明がそれぞれのユーザー・オブジェクトの下に格納され、資格証明オブジェクトの使用が有効になっている場合、Locatorオブジェクトを使用する必要がありません。(フラット・ディレクトリ・モデルを使用している場合、Locatorは、テンプレート、資格証明およびその他のオブジェクトをディレクトリ内で検索してLogon Managerに伝えるポインタ・オブジェクトです(詳細は「付録B: Logon Managerリポジトリ・オブジェクトのクラスおよび属性」を参照)。)
?場所: 「Global Agent Settings」a「Live」a「Synchronization」a「ADEXT」
有効にするには: チェック・ボックスを選択して、ドロップダウン・リストから
「Under respective directory user objects」を選択します。
次のようにLogon Managerのリポジトリ接続設定を構成することをお薦めします。
使用している環境でこのフィールドに特定の値を入力する必要がないかぎり、Logon Managerでネットワーク上の最も近いドメイン・コントローラを検出し、同期するように設定することをお薦めします。たとえば、
エンド・ユーザーのマシンが同一ドメイン(ディレクトリとして)上にない場合は、正しいドメイン名を入力する必要があります。このフィールドに完全なURLをハードコードすると、そのDCがオフラインになったときのフォルト・トレランス(フォールバック)が失われます。
?場所: 「Global Agent Settings」a「Live」a「Synchronization」a「ADEXT」
Logon Managerが最も近いDCを検出するには: チェック・ボックスの選択を解除します(デフォルトの設定)。
設定するには: チェック・ボックスを選択して(…)ボタンをクリックし、必要な値を(1行ごとに1つずつ)入力して「OK」をクリックします。
Logon ManagerリポジトリのシンクロナイザはSSLサポートが有効の状態で出荷されるので、これを無効にしないことを強くお薦めします。使用する環境では、セキュリティを最大化するために、Logon Managerおよびその他のリポジトリへのすべての接続に必ずSSLを使用してください。
注意: Logon Managerをデプロイする前に、SSLを使用するようにドメイン・コントローラを構成してください。手順の詳細は、次のMSDN記事を参照してください。http://msdn.microsoft.com/en-us/library/aa364671(VS.85).aspx
?場所: 「Global Agent Settings」a「Live」a「Synchronization」a「ADEXT」
有効にするには(無効になっている場合): チェック・ボックスの選択を解除します。
「Credentials to use」オプションを使用して、ディレクトリに対する認証を行う場合に、Logon Managerで使用する資格証明を選択します。Logon Managerがディレクトリに対して認証できない場合に、ユーザーに再認証のためのプロンプトが表示されないように、これを「Use local computer credentials only」に設定することをお薦めします。
注意: これをデフォルトの設定(「Try local computer credentials; if it fails, use Active Directory server account」)のままにしないでください。デフォルト設定のままにすると、ディレクトリとエンド・ユーザー・マシンが同じドメイン上にない場合に、
認証が失敗します(無効に設定していないかぎり、再認証のプロンプトが表示されます)。
注意: Smart Cardを使用してLogon Managerに対する認証を行う場合、ドロップダウン・メニューから「Use card’s certificate」を選択することで、カードの資格証明を使用してリポジトリに対する認証を行うこともできます。詳細は、『Oracle Enterprise Single Sign-On Suite Plus管理者ガイド』を参照してください。
?場所: 「Global Agent Settings」a「Live」a「Synchronization」a「ADEXT」
設定するには: チェック・ボックスを選択し、ドロップダウン・リストから適切なオプションを選択します。
認証が失敗したかまたは切断された場合に、ディレクトリに対して再認証を行うには、「Prompt when disconnected」オプションを使用して、Logon Managerがユーザーにプロンプトを表示するかどうかを決定します。ユーザーの不要な混乱とそれによるヘルプデスクへの問合せを避けるために、この設定をデフォルト値の「No」のままにすることをお薦めします。
?場所: 「Global Agent Settings」a「Live」a「Synchronization」a「ADEXT」
設定するには: チェック・ボックスを選択し、ドロップダウン・リストから適切なオプションを選択します。
このオプションは、前述した「Credentials to use」オプションに直接関連し、「Allow disconnected operation」が「No」に設定されている場合は何も効果はありません。
使用している環境でこのフィールドに特定の値を入力する必要がないかぎり、Logon ManagerによってActive Directory内のユーザー・アカウントが自動的に検索されるようにしておくことをお薦めします。このフィールドにパスを間違ってハードコードしたり、そのパスを変更した場合は、このコンソール以外のツールを使用して各エンド・ユーザーのマシンを更新することが必要になります。
警告: 本番環境では、フォルト・トレランスを維持するために、このフィールドは常に空白にしてください。
ヒント: ドメインを1つのみ使用している場合や、ほとんどのユーザーが1つのプライマリ・ドメインに所属する場合は、ドメイン名を指定することで、Windowsパスワードを使用してLogon Managerに対する認証を行うときに、エンド・ユーザーがドメイン名を入力しなくて済むようになります。
?場所: 「Global Agent Settings」a「Live」a「Synchronization」a「ADEXT」
Logon Managerによるユーザー・アカウントの検索を行うには: チェック・ボックスの選択を解除します(デフォルト設定)。
設定するには: チェック・ボックスを選択して(…)ボタンをクリックし、必要な値を(1行に1つずつ)入力して「OK」をクリックします。
現在の環境が次のいずれかに該当する場合は、Active Directory (ADEXT)シンクロナイザ・プラグインがインストールされていて、「Synchronizer order」リストで有効になっていることを確認してください。
・ Logon Managerが複数のリポジトリと同期している。
・ Logon Managerがローミング同期を使用している。
・ 現在の環境にKiosk Managerがインストールされている。
注意: 複数のリポジトリおよびローミング同期に対応するようにLogon Managerを構成する手順やLogon Managerのインストールおよび構成方法は、このガイドでは取り扱いません。詳細は、『Enterprise Single Sign-On Suite Plus管理者ガイド』を参照してください。
場所: 「Global Agent Settings」a「Live」a「Synchronization」
設定するには: チェック・ボックスを選択して、(…)ボタンをクリックします。表示されるリストで、「ADEXT」の隣のチェック・ボックスを選択して、
「OK」をクリックします。必要に応じて、上向きまたは下向きの矢印を使用して、同期順を設定します。
ユーザーが常に最新の資格証明、アプリケーション・テンプレート、パスワード・ポリシーおよび管理オーバーライドを持つようにするには、起動時に同期を待つようにエージェントを構成します。このオプションを有効にすると、エージェントはディレクトリがオンラインかどうかを確認します。ディレクトリがオンラインの場合は、ディレクトリと正常に同期するまで、エージェントはアプリケーションのログオン・リクエストに応答しません。
ディレクトリがオフラインの場合は、エージェントは同期を試行せずにすぐに起動します。
?場所: 「Global Agent Settings」a「Live」a「Synchronization」
設定するには: チェック・ボックスを選択して、ドロップダウン・リストから「Yes」を選択します。
最適化された同期は、Logon Managerエージェントに、前回の同期の後で変更された資格証明のみを同期するように指示します。現在の環境に応じて、次のいずれかを実行します。
・ ユーザーごとの資格証明が大量にある場合は、このオプションを有効にすると、デプロイメントでの同期パフォーマンスが向上します。
・ ユーザーごとの資格証明が4つ以下で、ユーザーごとにダウンロードしたテンプレートが大量にある場合は、このオプションを無効にすると、デプロイメントでの同期パフォーマンスが向上します。
?場所: 「Global Agent Settings」a「Live」a「Synchronization」
現在の環境で特に指定する必要がない場合は、デフォルト値(「Yes」)を使用してください。
デプロイ中にディレクトリへの接続を確立できない場合には、Logon Managerエージェントが実行されないように構成します。これにより、エージェントがディレクトリに接続されていない状態で、かつローカル・キャッシュが存在しない場合に、「First Time Use」(FTU)ウィザードが完了してしまうことを回避できます。ディレクトリが使用できないときにエージェントが実行されないようにすることで、ディレクトリから切断されているのにFTUウィザードが完了して暗号化鍵の2つ目のセットが作成されてしまう、というよくある状況を回避できます。?
注意: この必要なベスト・プラクティスの詳細は、『Oracle Enterprise Single Sign-On Suite Plus管理者ガイド』の
Logon Managerエージェントの構成に関する項を参照してください。
?場所: 「Global Agent Settings」a「Live」a「Synchronization」
設定するには:チェック・ボックスを選択して、ドロップダウン・リストから「No」を選択します。
ドメイン名やオブジェクトのパスなどのディレクトリの同期設定は、管理オーバーライドとしてデプロイしないでください。(この説明は「グローバル・エージェント設定および管理オーバーライド」を参照してください。)推奨されるオーバーライドのベスト・プラクティスについては、Oracle Enterprise Single Sign-On Suite Plusセキュア・デプロイメント・ガイドおよび『Oracle Enterprise Single Sign-On Suite Plus管理者ガイド』のLogon Managerエージェントの構成に関する項を参照してください。
この項では、MS Active DirectoryでのLogon Managerのデプロイメント・プロセスについて、その概要を説明します。デプロイメントを進める前に、このドキュメントの前の項にすべて目を通すようにしてください。MS Active DirectoryでのLogon Managerのデプロイでは、次の手順を実行する必要があります。
1. 次のドキュメントを入手します。
・ このドキュメントの最新バージョン
・ 『Oracle Enterprise Single Sign-On Suite Plusインストレーション・ガイド』
・ 『Oracle Enterprise Single Sign-On Suite Plus管理者ガイド』
2. 使用しているバージョンのLogon Manager用インストレーション・ガイドの説明に従って、ドメイン内のマシンにLogon ManagerエージェントおよびLogon Manager管理コンソールをインストールします。エージェントのインストール時には、Active Directoryシンクロナイザ・プラグインが選択されていることを確認してください。
3. 「Logon ManagerのためのActive Directoryの準備」の手順を完了します。
a. Logon Managerのクラスと属性を使用してActive Directoryスキーマを拡張します。
b. ユーザー・オブジェクトへのユーザー資格証明の格納を有効にします。
c. 必要なツリー構造を作成して必要な権限を付与します。
4. 次のようにLogon Managerを構成します。
a. 「Active Directoryシンクロナイザの構成」の手順を完了します。
b. このガイドの「推奨グローバル・エージェント設定」で説明されているオプションを構成します。
c. 「Logon Managerの構成のテスト」の説明に従って構成をテストします。
d. 『Enterprise Single Sign-On Suite Plus管理者ガイド』のLogon Managerエージェントの構成に関する項で説明されているオプションを構成します。
注意: 該当する設定の詳細は、コンソールのオンライン・ヘルプを参照してください。オンライン・ヘルプは、コンソールの「Help」メニューから参照できます。
5. テスト用のマシンで次の手順を実行します。
・ 主なテンプレートおよびポリシーのパイロット・セットを作成します。
・ 本番環境にデプロイされる、主なテンプレート、グローバル・エージェント設定、管理オーバーライドをそれぞれテストして、エンド・ユーザーの操作性を最終調整します。
6. ベスト・プラクティス: 大量デプロイメント用のLogon Managerのパッケージ化のガイドで説明されている手順を完了して、カスタムMSIパッケージを作成し、エンド・ユーザーのマシンにデプロイします。
7. 残りのアプリケーション・テンプレートの作成、テスト、デプロイメントを行います。異なるアプリケーション・タイプのプロビジョニングの詳細は、それぞれのアプリケーション・タイプ(Windows、Web、メインフレーム)のLogon Managerベスト・プラクティスのガイドで、テンプレートの構成および診断に関する説明を参照してください。
この項では、Active DirectoryをLogon Managerで使用するための基本的な準備手順について説明します。
この準備では、それぞれのユーザー・オブジェクトに資格証明を格納できるように、Logon Managerのクラスと属性を使用してActive Directoryスキーマを拡張し、必要なツリー構造を作成します。この手順を開始する前に、次の手順が完了していることを確認してください。
1. Active Directoryスキーマに対するヘルス・チェックの実行。手順については次の記事を参照してください。http://www.microsoft.com/technet/opsmgr/2005/library/dirmgmtpack/
dirmgmtpackmom_3.mspx
2. Logon Manager管理コンソールのインストール(使用しているバージョンのLogon Manager用のLogon Managerインストレーションおよび設定ガイドの説明を参照)。
1. Logon Manager管理コンソールを起動します。デフォルトでは、コンソールのショートカットは「スタート」a「プログラム」a「Oracle」a「Logon Manager」a「Logon Manager Console」にあります。
注意: 開発およびステージング環境では、Internet Explorerの「発行元証明書の取り消しを確認する」オプションを無効にして、コンソールの起動時に、マシンがインターネットに接続されていない場合の遅延が起きないようにします。(この遅延は、Internet Explorerによるサーバー証明書の確認が行われて、証明書認証局にアクセスできずタイムアウトするまでの時間です。)このオプションは本番マシンでは無効にしないでください。
2. コンソールで、「Repository」メニューから「Extend Schema」を選択します。コンソールに「Connect to Repository」ダイアログが表示されます。
3. 「Server Name」フィールドに、スキーマのマスター・ドメイン・コントローラの完全修飾IPアドレス、ホスト名またはNetBIOS名を入力します。
4. 「Repository Type」ドロップダウン・リストで、「Microsoft Active Directory Server」を選択します。
5. ディレクトリで接続をリスニングしているポート番号を入力します。デフォルトのポートは、SSL接続の場合は636、非SSL接続の場合は389です。
6. (オプション) SSLを使用するようにドメイン・コントローラを構成している場合は、「Use secure channel (SSL)」オプションを選択したままにし、使用しない場合は選択を解除します。(詳細は、「SSLのサポート」を参照してください。)
7. 「Username/ID」および「Password」フィールドで、Logon ManagerがActive Directory
に接続するときに使用するアカウントの資格証明を入力します。環境によっては、ユーザー名の一部に対応するドメイン名を含める必要があります(例: ITSLIFE\Jim)。
8. 「OK」をクリックして、コンソールがスキーマの拡張を実行するのを待ちます。コンソールに進行状況を示すステータス・ダイアログが表示されます。スキーマが正常に拡張されると、
ステータス・ダイアログに確認のメッセージが表示されます。
スキーマの拡張が失敗した場合、トラブルシューティングの手順については付録Cの「Active Directoryスキーマの拡張の失敗」を参照してください。
9. 「Close」をクリックします。
それぞれのユーザー・オブジェクトへのユーザー資格証明の格納を有効にすると、Logon Managerによってディレクトリ内で次の変更が行われます。
・ 利用可能な上位クラスとしてuserクラスをvGOUserDataクラスに追加します。
・ すべてのユーザーにvGOUserDataオブジェクトを作成する権限を付与します。これらの権限は、ディレクトリ・ルートで付与され、ユーザー・オブジェクトまで再帰的に継承されます。
それぞれのユーザー・オブジェクトへのユーザー資格証明の格納を有効にするには、次の手順を実行します。
1. コンソールで、「Repository」メニューから、「Enable Storing Credentials Under User Object (AD Only)」を選択します。Active Directoryスキーマに変更が行われることを知らせる確認ダイアログがコンソールに表示されます。
2. 「OK」をクリックして、コンソールが変更を行うのを待ちます。変更が完了すると、次のようにコンソールに確認ダイアログが表示されます。
3. 変更が正常に行われたことを確認します。
a. Microsoft管理コンソールで、「Active Directoryスキーマ」スナップインを開きます。
スナップインがコンソールに存在しない場合は、次の手順に従ってインストールします。
http://technet2.microsoft.com/windowsserver/en/library/
??? 8c76ff67-9e9d-4fc7-bfac-ffedee8a04d41033.mspx?mfr=true
b. 「Classes」ノードを展開してvGOUserDataクラスにナビゲートします。
c. vGOUserDataクラスを右クリックし、コンテキスト・メニューから「Properties」を選択します。
d. 「vGOUserData Properties」ダイアログで、「Relationship」タブを選択します。
e. userクラスが「Possible Superior」フィールドに表示されているかどうかを確認します。
利用可能な上位クラスにuserクラスが表示されていない場合、考えられる原因および修正手順については、付録Cの「すべてのユーザーがユーザー・オブジェクトの下に資格証明を格納できない」を参照してください。
注意: 保護されているグループのメンバー(たとえば、ユーザーのACLがAdminSDHolderオブジェクトによって管理されているユーザー)は、AdminSDHolder ACLがこの機能に必要な権限で更新されるまでは、そのメンバーのユーザー・オブジェクトの下に資格証明を格納できません。この問題の修正手順については、付録Cの「一部のユーザーがユーザー・オブジェクトの下に資格証明を格納できない」を参照してください。
注意: 既存のコンテナを使用してLogon Managerオブジェクトを格納することもできますが、その場合、ディレクトリのパフォーマンスが低下することがあります。構成オブジェクト専用のコンテナを作成することをお薦めします。
1. Logon Manager管理コンソールで、左側ペインの「Repository」ノードを選択します。
2. 右側ペインで「Click here to connect」リンクをクリックします。コンソールに「Connect to Repository」ダイアログが表示されます。
3. 26から27ページの手順3から7の説明に従って、フィールドを入力し、「OK」をクリックして接続します。
4. 次に示すように、このツリーで対象の親コンテナを右クリックし、コンテキスト・メニューから「New Container」を選択します。
?
コンソールに「New Container」ダイアログが表示されます。
5. 「New Container」ダイアログで、必要な名前を入力して「OK」をクリックします。
注意: 現在の環境で、このコンテナに特定の名前を必要としない場合は、デフォルト名のSSOConfigを使用することをお薦めします。
6. 手順4と5を繰り返して、必要な追加のコンテナを作成します。
Logon Manager用のActive Directoryの準備ができたら、現在の環境用にActive Directoryシンクロナイザを構成します。テンプレート・クライアント・マシン上でこれらの設定を構成し、エンド・ユーザーへのLogon Managerのデプロイに使用するMSIパッケージに、その構成を含めます。この手順を開始する前に、Logon Manager管理コンソールおよびLogon Managerエージェント(Active Directoryシンクロナイザ・プラグインを含む)がインストールされていることを確認します。
注意: ディレクトリの同期が行われる環境では機能しないので、アプリケーション・テンプレートをMSIパッケージに含めないでください。MSIパッケージにテンプレートを直接含める機能は、特別な場合にのみ使用します。かわりに、Logon Managerエージェントによる自動取得用のディレクトリにそれらをプッシュ送信します。
1. Logon Manager管理コンソールを起動します。
2. 左側ペインで、「Global Agent Settings」ノードを右クリックして、
コンテキスト・メニューから「Import」a「From Live HKLM」を選択します。現在のエージェント設定がWindowsのレジストリからコンソールにインポートされます。
3. 「推奨グローバル・エージェント設定」および「推奨管理オーバーライド」の手順に従ってエージェントを構成します。
注意: 設定の横のチェック・ボックスが選択されていない場合は、設定のデフォルト値(チェック・ボックスの右にグレー表示されている値)が使用されます。
4. 後で参照するために、構成をXMLファイルに保存します。「File」メニューから「Save」を選択し、必要なファイル名を入力して「Save」をクリックします。設定を変更する場合は、このXMLファイルをコンソールにロードして元の選択に戻すことができます。
5. 「Tools」メニューから「Write Global Agent Settings to HKLM」を選択します。コンソールによって、変更がレジストリに書き込まれ、エージェントが再起動されます。
6. 次の項に進みLogon Managerの構成を完了します。
Logon Managerの構成が完了したら、次に示す手順でテストを行い、Logon Managerが正しく機能しない場合はエラーを修正します。
1. Logon Manager管理コンソールを起動します。
2. 左側ペインで、「Global Agent Settings」ノードを右クリックして、
コンテキスト・メニューから「Import」a「From Live HKLM」を選択します。現在のエージェント設定がWindowsのレジストリからコンソールにインポートされます。
3. 「Tools」メニューから「Test Global Agent Settings」を選択します。
4. 表示される警告を読み、「OK」をクリックして続行します。
5. 「Logon Manager Configuration Test Manager」ウィンドウが表示されます。ウィンドウの手順に従って、構成のテストを行い、エラーがある場合はそれを修正します。各オプションの詳細は、ウィンドウの右上にある「Help」(疑問符のマーク)ボタンをクリックします。
?
この部では、Microsoft AD LDS (ADAM)でのLogon Managerのデプロイメントにおけるベスト・プラクティスについて説明します。
内容は次のとおりです。
・ Logon ManagerおよびAD LDS (ADAM)の環境
・ AD LDS (ADAM)ディレクトリのサブツリーの設計
・ Logon ManagerのためのAD LDS (ADAM)インスタンスの準備
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を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によって実行されるスキーマの拡張の詳細は、次の付録を参照してください。
・ 付録A: Logon Managerリポジトリ・オブジェクト用の最小管理権限
・ 付録B: 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ソフトウェアのアーキテクチャについては、このガイドでは詳しく取り扱いません。
詳細な説明が記載されたOracleのホワイト・ペーパーをお求めの場合は、オラクル社の担当者に問い合せてください。
Logon Managerでは、組織のニーズに合わせてディレクトリ構造を思いのままに設定できます。具体的には、データをフラット・モデルで格納するか階層構造で格納するかの選択肢があります。フラット・モデルは小規模なデプロイメントでは問題なく機能しますが、成長する大規模なデプロイメントでは最初から階層構造を使用します。サブツリーの適切な構造は次の要素によって決まります。
・ ユーザーの数
・ Logon Managerでサポートするアプリケーションの数
・ 既存のインフラストラクチャの堅牢性
・ 組織の構造
次のガイドラインに従ってサブツリーを階層構造として設定することをお薦めします。
・ OUを使用して、部門や部署など、組織の構造に合わせたカテゴリごとにテンプレート、ポリシーおよび資格証明をグループ化します。
・ OUレベルでアクセスを制御します。
・ 現在の環境で特に指定がないかぎり、継承を無効化し、Logon Managerのルート・コンテナでユーザー権限を付与しないようにします。
このように階層を設定すると、次の利点があります。
・ 見やすくわかりやすいツリー構造。ディレクトリ・ブラウザでサブツリーを表示すると、サブツリー構造を一覧できるので全体が把握しやすくなります。
・ 不要な権限は継承されません。ユーザーには、アクセスする必要のないサブOUに対する権限はネイティブで継承されません。これにより、ツリーの下位に継承される不要なアクセス権限を明示的に拒否せずに済みます。
・ ネットワーク、エージェントおよびディレクトリの堅牢なパフォーマンス。通常、大量のテンプレートおよびポリシーをダウンロードするユーザーは、自分のジョブに関連する項目のみをダウンロードするユーザーよりもネットワーク・トラフィックが多く、ディレクトリの負荷も高くなります。グループ化によって、環境のリソースが節約され、エージェントのレスポンス時間が改善されます。
・ 管理タスクの分散。テンプレートを制御しやすいセットに整理し、
アクセス権限の設定によって、ユーザーが管理できるテンプレートを決定します。権限に基づいたテンプレートのバージョン制御を実装する機能も使用できます。
・ 低い管理オーバーヘッド。テンプレート・レベルでのアクセスの制御では、Logon Manager管理コンソールから個々のテンプレートに権限を設定する必要があり、OUレベルでのアクセスの制御は、Microsoftやサードパーティの管理ツールを使用した委任管理によって行います。
図3は、前述のベスト・プラクティスを反映して設計されたサンプルのLogon Managerサブツリーを示しています。
図3 Logon Managerサブツリーの推奨設計
サンプルのシナリオでは、ポートランド部門のユーザーは、サクラメント部門で使用するアプリケーションへのアクセスは不要で、その逆も同様なので、各部門のテンプレートおよびポリシーは、ルートの専用サブOUに配置し、両部門が互いのサブ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を利用する場合は、次の制限が適用されます。
・ People OUは、AD LDS (ADAM)パーティションのルートで親コンテナ内に存在する必要があります。
・ 親コンテナの名前は、アプリケーション資格証明が対応するPeople OU内に
格納されるユーザーのドメイン(NTスタイル)の名前である必要があります。必要な場合は、個別のPeople OUを必要とする部門または領域ごとに個別のドメインを作成し、対応するユーザーをそのドメインに移動します。
注意: ?単一のドメインを持つProvisioning Gatewayで複数のPeople OUを使用することは
できません。
フラット・モデルで開始し、ユーザーおよびプロビジョニングするアプリケーションの数が多くなると予想される場合は、階層構造への移行の準備ができるまでは、ルートの下にサブコンテナを作成し、それを使用してテンプレートとポリシーをフラットに格納します。ユーザーを追加したり、アプリケーションをさらにプロビジョニングする際には、階層に移行してなるべく早いうちに環境のパフォーマンスを確認してください(後で確認するよりも手間を省くことができます)。階層に移行するとき、新しいLogon Managerルート・コンテナとして既存のコンテナを使用し、その下にサブOUを作成します。
図3に示すように、ワークフローの各段階(開発、ステージング、本番)で専用のサブOUを作成することをお薦めします。この方法によって次のことができます。
・ テンプレートおよびポリシーがワークフローを通過して本番に入るときには、ワークフローの各ステージを移動するたびにこれらのシャドウ・コピーが保持されるので、テンプレートおよびポリシーに対して行われた変更をトラッキングできます。
・ 必要に応じて、テンプレートおよびポリシーを以前のバージョンにロールバックできます。
・ ワークフローの各ステージで、誰がどのテンプレートおよびポリシーを使用するかを制御できます。特に、テンプレートおよびポリシーを本番に配置できるユーザーの管理には、厳格なルール設定が必要です。
必ず、隔離した環境ですべてのアプリケーション・テンプレートおよび管理オーバーライドをテストしてから、エンド・ユーザーにデプロイしてください。テストは、変更内容の確認や、本番環境で発生したとしたら、解決するのに多くのコストがかかるような潜在的な問題の解決に役立ちます。正しく構成されていないテンプレートや誤った管理オーバーライドをネットワーク全体にプッシュした場合、ミッション・クリティカルなアプリケーションへのアクセスがエンタープライズ全体で失われることがあるので、テストは大規模なデプロイメントでは特に重要です。
隔離したテスト環境をセットアップする場合は、デプロイメント・グループのメンバーのみがアクセス権を持つ専用のテスト・コンテナを作成してください。次に、このコンテナ内のLogon Managerエージェントを特定して、テンプレートと管理オーバーライドをその中に配置します。テンプレートとポリシーが意図したとおりに動作していることを確認したら、それらをターゲットの本番コンテナに移動します。
テンプレートをテストした後にシャドウ・コピーを維持しない場合、次の手順に従って、それらをテスト・コンテナからターゲットの本番コンテナに移動します。
1. テンプレートをディレクトリから取得します。
2. そのテンプレートのローカル・バックアップを作成します。
3. ディレクトリ内の新しい場所に、このコピーを配置します。
4. テンプレートを元の場所から削除します。
コンソールを使用してオブジェクトのアクセス制御リスト(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レジストリに格納されているグローバル・エージェント設定よりも優先され、エージェント用のドメイン・ポリシーを構成します。オーバーライドは、同期中にエージェントによって中央リポジトリからダウンロードされ、暗号化および改ざん防止機能を持つエージェントのローカル・キャッシュに格納されるので、エンド・ユーザーからの変更は受け付けられません。ロール/グループのセキュリティが有効な場合、管理オーバーライドはユーザーまたはグループごとに適用することも、企業全体に適用してすべてのユーザー設定の一貫性を保つこともできます。
注意: 管理オーバーライドを計画する場合は慎重に行ってください。オーバーライドが少なければ、格納および転送するデータも少なくなるので、中央リポジトリとの同期がより効率的になります。エンド・ユーザーのマシン上では管理オーバーライドを確認することができないため、オーバーライドの数を減らすことで不明な状況が解消され、トラブルシューティングも容易になります。
管理オーバーライドとグローバル・エージェント設定は、エージェントの完全な構成ポリシーを適用します。このガイドの残りの部分では、推奨される最適な構成について説明し、他のLogon Managerベスト・プラクティスのガイドにある情報を補足します。
警告: ドメイン名やユーザー・オブジェクト・パスなどの設定は、必ず十分にテストしてからデプロイし、必要のない場合は管理オーバーライドとしてデプロイしないでください。入力ミスによるドメイン名の単純な間違いなどによって、エンド・ユーザーのワークステーションでディレクトリの同期ができなくなると、コンソールから修正内容を伝えることはできないため、他のツールを使用してユーザー・マシンに変更を適用する必要があります。
図4は、AD LDS (ADAM)と同期するためのLogon Manager管理コンソールの標準的な設定を示しています。
図4 Logon Manager管理コンソール
次の項では、AD LDS (ADAM)と同期するためのLogon Managerの構成について、そのベスト・プラクティスを説明します。このガイドで説明されている設定の詳細な情報が必要な場合は、コンソールに含まれているオンライン・ヘルプを参照してください。
注意: 開始する前に、Logon ManagerエージェントとAD LDS (ADAM)のシンクロナイザ・プラグインがインストールされていることを確認してください(インストールされていないとコンソールにAD LDS (ADAM)関連の設定が表示されません)。インストール手順については、使用しているLogon Managerのバージョン用のインストレーション・ガイドを参照してください。
ヒント: 開発およびステージング環境では、Internet Explorerの「発行元証明書の取り消しを確認する」オプションを無効にして、コンソールの起動時に、マシンがインターネットに接続されていない場合の遅延が起きないようにします。(この遅延は、Internet Explorerによるサーバー証明書の確認が行われて、証明書認証局にアクセスできずタイムアウトするまでの時間です。)このオプションは本番マシンでは無効にしないでください。
このガイドや他のLogon Managerベスト・プラクティスガイドで説明されていない設定は、現在の環境で特に指定がないかぎり、デフォルト値のままにすることをお薦めします。Logon Manager管理コンソールで設定のチェック・ボックスが選択されていない場合は、デフォルト値が自動的に有効になります。この値は、チェック・ボックスの横にある非アクティブ・フィールドに表示されます。
この項では、推奨されるグローバル・エージェント設定のベスト・プラクティスを示します。次の説明に従って設定を構成し、カスタマイズされたLogon Manager MSIパッケージにそれらを含めます。(パッケージの作成手順については、ベスト・プラクティス: 大量デプロイメント用のLogon Managerのパッケージ化のガイドを参照してください。)
AD LDS (ADAM)のデプロイメントでは、ユーザー・データおよび構成データの格納にディレクトリ・オブジェクトを使用することをお薦めします(これにより、「AD LDS (ADAM)ディレクトリのサブツリーの設計」の説明に従って、階層構造での格納、ロールおよびグループ・ベースの個別のコンテナに対するアクセス制御、テンプレートおよびポリシーを使用することが可能になります)。この機能を無効にしている場合、Logon Managerは、すべてのテンプレートおよび構成データをツリーのルートの下に単一のフラット・ファイルとして格納します。
?場所: 「Global Agent Settings」a「Live」a「Synchronization」
有効にするには: チェック・ボックスを選択して、ドロップダウン・リストで「Yes」を選択します。
AD LDS (ADAM)環境では、サーバーURLをLogon Managerに明示的に指定する必要があります。少なくとも2つの物理AD LDS (ADAM)サーバーを使用し、自動的および透過的なフェイルオーバーのために、それらをロード・バランサの背後に置くことをお薦めします。ロード・バランサを使用しない場合は、エンド・ユーザーと次に使用可能なサーバーとの物理的な距離によるパフォーマンス・ヒットが最小になるように、エンド・ユーザーに対する地理的近接度の順序でサーバーURLを配置します。ロード・バランシングの詳細は、「Logon Managerデプロイメントのロード・バランシング」を参照してください。
場所: 「Global Agent Settings」a「Live」a「Synchronization」a「ADAMSyncExt」
設定するには: チェック・ボックスを選択して(…)ボタンをクリックし、必要な値を次に示すように(1行ごとに1つずつ)入力します。終了したら、「OK」をクリックします。
Logon ManagerでAD LDS (ADAM)にデータを格納するには、Logon Managerのルート・コンテナ(Logon Managerの構成オブジェクトが格納される)の場所を指定する必要があります。
場所: 「Global Agent Settings」a「Live」a「Synchronization」a「ADAMSyncExt」
設定するには: チェック・ボックスを選択し、(…)ボタンをクリックして必要な値を入力します。
????????????? 完了したら「OK」をクリックします。
Logon ManagerリポジトリのシンクロナイザはSSLサポートが有効の状態で出荷されるので、これを無効にしないことを強くお薦めします。使用する環境では、セキュリティを最大化するために、Logon Managerおよびその他のリポジトリへのすべての接続に必ずSSLを使用してください。
注意: Logon Managerをデプロイする前に、SSLを使用するようにドメイン・コントローラを構成してください。手順の詳細は、次のMSDN記事を参照してください。http://msdn.microsoft.com/en-us/library/aa364671(VS.85).aspx
場所: 「Global Agent Settings」a「Live」a「Synchronization」a「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」a「Live」a「Synchronization」a「ADAMSyncExt」
設定するには: チェック・ボックスを選択し、ドロップダウン・リストから適切なオプションを選択します。
デフォルト(AD LDS (ADAM)パーティションのルート)以外の場所にPeople OUを作成した場合、またはアプリケーション資格証明へのアクセスをより詳細に制御するために複数のPeople OUを作成した場合、「Designing the AD LDS (ADAM)ディレクトリのサブツリーの設計」の説明に従って、対応するPeople OUを使用するためにターゲットのLogon Managerインスタンスを構成する必要があります。
場所: 「Global Agent Settings」a「Live」a「Synchronization」a「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」a「Live」a「Synchronization」a「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」a「Synchronization」
設定するには: チェック・ボックスを選択して、(…)ボタンをクリックします。表示されるリストで、「ADAMSyncExt」の横のチェック・ボックスを選択して、「OK」をクリックします。必要に応じて、上向きまたは下向きの矢印を使用して、同期順を設定します。
ユーザーが常に最新の資格証明、アプリケーション・テンプレート、パスワード・ポリシーおよび管理オーバーライドを持つようにするには、起動時に同期を待つようにエージェントを構成します。このオプションを有効にすると、エージェントはディレクトリがオンラインかどうかを確認します。ディレクトリがオンラインの場合は、ディレクトリと正常に同期するまで、エージェントはアプリケーションのログオン・リクエストに応答しません。
ディレクトリがオフラインの場合は、エージェントは同期を試行せずにすぐに起動します。
?場所: 「Global Agent Settings」a「Live」a「Synchronization」
現在の環境で特に指定する必要がない場合は、デフォルト値(「Yes」)を使用してください。
最適化された同期は、Logon Managerエージェントに、前回の同期の後で変更された資格証明のみを同期するように指示します。現在の環境に応じて、次のいずれかを実行します。
・ ユーザーごとの資格証明が大量にある場合は、このオプションを有効にすると、デプロイメントでの同期パフォーマンスが向上します。
・ ユーザーごとの資格証明が4つ以下で、ユーザーごとにダウンロードしたテンプレートが大量にある場合は、このオプションを無効にすると、デプロイメントでの同期パフォーマンスが向上します。
?場所: 「Global Agent Settings」a「Live」a「Synchronization」
現在の環境で特に指定する必要がない場合は、デフォルト値(「Yes」)を使用してください。
デプロイ中にディレクトリへの接続を確立できない場合には、Logon Managerエージェントが実行されないように構成します。これにより、エージェントがディレクトリに接続されていない状態で、かつローカル・キャッシュが存在しない場合に、「First Time Use」(FTU)ウィザードが完了してしまうことを回避できます。ディレクトリが使用できないときにエージェントが実行されないようにすることで、ディレクトリから切断されているのにFTUウィザードが完了して暗号化鍵の2つ目のセットが作成されてしまう、というよくある状況を回避できます。?
注意:? 必要なベスト・プラクティスの詳細は、Logon Managerベスト・プラクティス: Logon Managerエージェントの構成のガイドを参照してください。
?場所: 「Global Agent Settings」a「Live」a「Synchronization」
設定するには:チェック・ボックスを選択して、ドロップダウン・リストから「No」を選択します。
ドメイン名やオブジェクトのパスなどのディレクトリの同期設定は、管理オーバーライドとしてデプロイしないでください。(この説明は「グローバル・エージェント設定および管理オーバーライド」を参照してください。)推奨されるオーバーライドのベスト・プラクティスについては、Logon Managerベスト・プラクティス: Logon Managerエージェントの構成のガイドを参照してください。
この項では、AD LDS (ADAM)でのLogon Managerのデプロイメント・プロセスについて、その概要を説明します。デプロイメントを進める前に、このドキュメントの前の項にすべて目を通すようにしてください。MS AD LDS (ADAM)でのLogon Managerのデプロイでは、次の手順を実行する必要があります。
1. 次のドキュメントを入手します。
・ このドキュメントの最新バージョン
・ 『Oracle Enterprise Single Sign-On Suite Plusインストレーション・ガイド』
・ 『Oracle Enterprise Single Sign-On Suite Plus管理者ガイド』
2. まだの場合は、AD LDS (ADAM)をターゲット・サーバーにインストールします。AD LDS (ADAM)インストーラおよびインストール手順は、MicrosoftのWebサイトを参照してください。
3. Logon Manager管理者およびLogon Managerユーザーのグループを作成します。基本的な手順は、「付録E: AD LDS (ADAM)デプロイメント上での必要なユーザー・グループの作成」を参照してください。
4. 「AD LDS (ADAM)インスタンスの作成」の説明に従って、Logon Managerで使用する新しいAD LDS (ADAM)インスタンスを作成します。
5. 使用しているバージョンのLogon Manager用インストレーション・ガイドの説明に従って、ドメイン内のマシンにLogon ManagerエージェントおよびLogon Manager管理コンソールをインストールします。エージェントのインストール時には、AD LDS (ADAM)シンクロナイザが選択されていることを確認してください。
6. 「Logon ManagerのためのAD LDS (ADAM)インスタンスの準備」の手順を完了します。
a. Logon Managerのクラスと属性を使用してAD LDS (ADAM)インスタンス・スキーマを拡張します。
b. 各ユーザーのアプリケーション資格証明を格納するPeople OUを作成します。
c. Logon Manager構成オブジェクト・コンテナおよび必要なツリー構造を作成します。
d. 必要な権限を付与します。
7. 次のようにLogon Managerを構成します。
a. 「AD LDS (ADAM)シンクロナイザの構成」の手順を完了します。
b. このガイドの「推奨グローバル・エージェント設定」で説明されているオプションを構成します。
c. 「Logon Managerの構成のテスト」の説明に従って構成をテストします。
d. 『Enterprise Single Sign-On Suite Plus管理者ガイド』のLogon Managerエージェントの構成に関する項で説明されているオプションを構成します。
注意: 該当する設定の詳細は、コンソールのオンライン・ヘルプを参照してください。
8. テスト用のマシンで次の手順を実行します。
・ 主なテンプレートおよびポリシーのパイロット・セットを作成します。
・ 本番環境にデプロイされる、主なテンプレート、グローバル・エージェント設定、管理オーバーライドをそれぞれテストして、エンド・ユーザーの操作性を最終調整します。
9. ベスト・プラクティス: 大量デプロイメント用のLogon Managerのパッケージ化のガイドで説明されている手順を完了して、カスタムMSIパッケージを作成し、エンド・ユーザーのマシンにデプロイします。
10. 残りのアプリケーション・テンプレートの作成、テスト、デプロイメントを行います。異なるアプリケーション・タイプのプロビジョニングの詳細は、それぞれのアプリケーション・タイプ(Windows、Web、メインフレーム)のLogon Managerベスト・プラクティスのガイドで、テンプレートの構成および診断に関する説明を参照してください。
この項では、Logon ManagerをデプロイするAD LDS (ADAM)インスタンスの作成方法について説明します。まだの場合は、AD LDS (ADAM)をターゲット・サーバーにインストールします。AD LDS (ADAM)インストーラおよびインストール手順は、MicrosoftのWebサイトを参照してください。開始する前に、次の点に注意してください。
・ Windows Server 2003以上のバージョンのWindows Serverオペレーティング・システム・ファミリをデプロイすることをお薦めします。(AD LDS (ADAM)はWindows 2000をサポートしていません)。
Windows XPまたはWindows 7でのデプロイメントは推奨されていません。
・ デプロイメントを簡略化するため、デフォルトのポート(SSL接続の場合は636)で実行するAD LDS (ADAM)インスタンスを作成することをお薦めします(AD LDS (ADAM)への非SSL接続はサポートされていますが、推奨されません)。カスタム・ポートを使用する場合、すべてのクライアントとターゲット・サーバーの間で開いている必要があります。
注意: リポジトリへの接続のタイプにかかわらず、ユーザー資格証明は常に暗号化されたままです。
・ ディレクトリがすでに実行中であるドメイン・コントローラまたは別のサーバー上にAD LDS (ADAM)をインストールする場合、デフォルトのポートを使用できないため、ドメイン・コントローラではなくメンバー・サーバー上にLogon Managerをデプロイすることをお薦めします。
ターゲットAD LDS (ADAM)インスタンスを作成するには:
注意: このガイドに示したAD LDS (ADAM)設定ウィザード画面は、サポートされるWindows Serverオペレーティング・システム・ファミリのバージョン間で異なる可能性がありますが、手順はサポートされるすべてのバージョンで同一です。
1. AD LDS (ADAM)セットアップ・ウィザードを起動します。
・ Windows Server 2003の場合:
「スタート」a「プログラム」a「ADAM」a「ADAM インスタンスの作成」をクリックします。
・ Windows Server 2008の場合:
「スタート」a「プログラム」a「管理ツール」a「Active Directory ライトウェイト ディレクトリ サービス セットアップ ウィザード」をクリックします。
・ Windows Server 2008 R2の場合:
注意: この手順を開始する前に、「Active Directory ライトウェイト ディレクトリ サービス」ロールをサーバーに追加したことを確認してください。
i. 「サーバー マネージャー」で、「役割」ノードを展開し、「Active Directory ライトウェイト ディレクトリ サービス」ロールを選択します。
ii. 右側ペインで、「詳細ツール」a「AD LDS ツール」セクションを展開し、
「AD LDS セットアップ ウィザード」をクリックします。
2. 「ウィザードの開始」画面で「次へ」をクリックします。
3. 「セットアップ オプション」画面で、「一意のインスタンス」を選択して「次へ」をクリックします。
4. AD LDS (ADAM)インスタンスの名前を指定し、「次へ」をクリックします。推奨される名前はssopartitionです。
5. このAD LDS (ADAM)インスタンスに目的のポート番号を入力します。デフォルトのポート(389/636)を使用しない場合、ここで入力したカスタム・ポート番号をメモしてください(後でLogon Managerの構成に必要です)。
6. 「アプリケーション ディレクトリ パーティションを作成する」を選択し、パーティションに完全修飾DNを指定します。これは、AD LDS (ADAM)インスタンスのサブツリーのルートです。DNは、ダイアログ・ボックスが示すように、cn=ではなくou=で開始する必要があり、そうしない場合は、Logon Managerのデプロイメントが失敗します。
7. AD LDS (ADAM)がファイルを格納する場所を指定します。ほとんどの場合、デフォルト値を受け入れてかまいません。
8. このAD LDS (ADAM)のインスタンスが実行に使用する権限を指定します。
9. 「このアカウント」を選択し、「参照」をクリックして、このAD LDS (ADAM)のインスタンスに対する管理権限を持つユーザーまたはグループを指定します。Logon Managerのデプロイメント全体でロックアウトを防止するために、ターゲットAD LDS (ADAM)インスタンスに対して管理権限を持つ2つ以上のユーザーを含む専用グループを作成することをお薦めします。詳細は、「付録E: AD LDS (ADAM)デプロイメント上での必要なユーザー・グループの作成」を参照してください。
10. 「このAD LDS (ADAM)インスタンス用にはLDIFファイルをインポートしない」を選択して、「次へ」をクリックします。
11. サマリー画面で、構成の選択内容を確認します。変更が必要な場合は「戻る」をクリックし、必要がない場合は、「次へ」をクリックしてAD LDS (ADAM)がインスタンスを作成するのを待ちます。
12. プロセスが完了したら、「完了」をクリックしてウィザードを終了します。
この項では、AD LDS (ADAM)をLogon Managerで使用するための基本的な準備手順について説明します。この準備では、それぞれのユーザー・オブジェクトに資格証明を格納できるように、Logon Managerのクラスと属性を使用してAD LDS (ADAM)スキーマを拡張し、必要なツリー構造を作成します。この手順を開始する前に、使用しているバージョンのLogon Manager用のLogon Managerインストレーション・ガイドの説明に従って、Logon Manager管理コンソールをインストール済であることを確認してください。
1. Logon Manager管理コンソールを起動します。デフォルトでは、コンソールのショートカットは「スタート」a「プログラム」a「Oracle」a「ESSO Suite Administrative Console」にあります。
注意: 開発およびステージング環境では、Internet Explorerの「発行元証明書の取り消しを確認する」オプションを無効にして、コンソールの起動時に、マシンがインターネットに接続されていない場合の遅延が起きないようにします。(この遅延は、Internet Explorerによるサーバー証明書の確認が行われて、証明書認証局にアクセスできずタイムアウトするまでの時間です。)このオプションは本番マシンでは無効にしないでください。
2. コンソールで、「Repository」メニューから「Extend Schema」を選択します。コンソールに「Connect to Repository」ダイアログが表示されます。
3. 「Server Name」フィールドに、スキーマのマスター・ドメイン・コントローラの完全修飾IPアドレス、ホスト名またはNetBIOS名を入力します。
4. 「Repository Type」ドロップダウン・リストで、「Microsoft AD LDS (ADAM)」を選択します。
5. ディレクトリで接続をリスニングしているポート番号を入力します。
デフォルトのポートは、SSL接続の場合は636、非SSL接続の場合は389です。
6. (オプション) SSLを使用するようにドメイン・コントローラを構成している場合は、「Use secure channel (SSL)」オプションを選択したままにし、使用しない場合は選択を解除します。(詳細は、「SSLのサポート」を参照してください。)
7. 「Username/ID」および「Password」フィールドで、Logon ManagerがAD LDS (ADAM)
に接続するときに使用するアカウントの資格証明を入力します。環境によっては、ユーザー名の一部に対応するドメイン名を含める必要があります(例: DOMAIN\user)。
8. 「OK」をクリックして、コンソールがスキーマの拡張を実行するのを待ちます。コンソールに進行状況を示すステータス・ダイアログが表示されます。スキーマが正常に拡張されると、
ステータス・ダイアログに確認のメッセージが表示されます。
9. 「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を作成するには:
1. ESSO Suite Administrative Consoleで、ツリー上の「Repository」ノードを選択します。
2. 右側ペインで「Click here to connect」リンクをクリックします。コンソールに「Connect to Repository」ダイアログが表示されます。54ページの手順3から7の説明に従って、フィールドを入力し、「OK」をクリックして接続します。
3. ツリーでターゲットAD LDS (ADAM)インスタンスのルートを右クリックし、コンテキスト・メニューから
「Create People Container」を選択します。
4. People OUがAD LDS (ADAM)インスタンスのサブツリーのルートに存在するようになったことを確認します。
前述の手順を完了した後にPeople OUが表示されない場合、またはディレクトリ内のネーミング違反やその他の問題を示すエラーを受け取った場合、AD LDS (ADAM)のドキュメントで考えられる原因および処置を参照してください。
注意: 既存のコンテナを使用してLogon Managerオブジェクトを格納することもできますが、その場合、ディレクトリのパフォーマンスが低下することがあります。構成オブジェクト専用のコンテナを作成することをお薦めします。
1. Logon Manager管理コンソールで、ツリー上の「Repository」ノードを選択します。
2. 右側ペインで「Click here to connect」リンクをクリックします。コンソールに「Connect to Directory」ダイアログが表示されます。
3. 32ページの手順3から7の説明に従って、フィールドを入力し、「OK」をクリックして接続します。
4. 次に示すように、このツリーで対象の親コンテナを右クリックし、コンテキスト・メニューから「New Container」を選択します。
コンソールに「New Container」ダイアログが表示されます。
5. 「New Container」ダイアログで、必要な名前を入力して「OK」をクリックします。
注意: 現在の環境で、このコンテナに特定の名前を必要としない場合は、デフォルト名のSSOConfigを使用することをお薦めします。
6. 手順4と5を繰り返して、必要な追加のコンテナを作成します。
Logon Managerを使用できるようにするために、Logon Managerユーザーに次の権限を付与する必要があります。
・ Logon Managerアプリケーション・パーティションへの読取りアクセス。これにより、同期中にユーザーが構成オブジェクトおよび資格証明を読み取ることが許可されます。
・ People OUへの書込みアクセス。これにより、同期中にユーザーが資格証明オブジェクトを作成することが許可されます。
注意: この手順は、SSOUsersグループがすでに作成され、必要なユーザーがそのグループに追加されていることを前提としています。前述の権限は、個別のユーザーではなく、SSOUsersグループに対して付与します。グループの作成およびグループへのユーザーの割当ての手順は、「付録B: 必要なユーザー・グループの作成」を参照してください。
これらの権限を付与するには:
1. ターゲット・サーバーに管理者としてログオンし、コマンド・プロンプトを開きます。
2. 次のコマンドを使用して、SSOUsersグループにLogon Managerアプリケーション・パーティションへの読取りアクセスを付与します(コマンドは1行であることに注意してください)。
dsacls \\<hostname>:<port>\ <sso_partition_dn> /G ?
"<domain>\SSOUsers":gr
3. 次のコマンドを使用して、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エージェントによる自動取得用のディレクトリにそれらをプッシュ送信します。
1. Logon Manager管理コンソールを起動します。
2. 左側ペインで、「Global Agent Settings」ノードを右クリックして、
コンテキスト・メニューから「Import」a「From Live HKLM」を選択します。現在のエージェント設定がWindowsのレジストリからコンソールにインポートされます。
3. 「推奨グローバル・エージェント設定」および「推奨管理オーバーライド」の手順に従ってエージェントを構成します。
注意: 設定の横のチェック・ボックスが選択されていない場合は、設定のデフォルト値(チェック・ボックスの右にグレー表示されている値)が使用されます。
4. 後で参照するために、構成をXMLファイルに保存します。「File」メニューから「Save」を選択し、必要なファイル名を入力して「Save」をクリックします。設定を変更する場合は、このXMLファイルをコンソールにロードして元の選択に戻すことができます。
5. 「Tools」メニューから「Write Global Agent Settings to HKLM」を選択します。コンソールによって、変更がレジストリに書き込まれ、エージェントが再起動されます。
6. 次の項に進みLogon Managerの構成を完了します。
この部では、LDAPディレクトリでのLogon Managerのデプロイメントにおけるベスト・プラクティスについて説明します。
内容は次のとおりです。
・ Logon Managerディレクトリのサブツリーの設計
Oracle Enterprise Single Sign-On Logon Managerは、ユーザーとターゲット・アプリケーションの間の中間層として機能するセキュアで容易にデプロイ可能なシングル・サインオン・ソリューションです。ユーザーの認証は1回で済み、ユーザー資格証明に対する後続のすべてのリクエストはLogon Managerによって自動的に検出されて処理されます。Logon Managerの詳細は、Oracleサポートで入手できるOracle Enterprise Single Sign-On Suite Plusの技術概要ホワイト・ペーパーを参照してください。
ディレクトリ環境に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つのオブジェクト・クラスを追加し、これらのタイプのオブジェクトを作成、読取り、変更、削除できるように、適切な権限を設定して行います。既存のクラスおよび属性を変更する方法はありません。
注意: スキーマの拡張はインストール後の手順です。手順については、「Logon Managerのためのディレクトリの準備」を参照してください。スキーマの拡張を実行する前に、(Microsoftのベスト・プラクティスで説明されているように)スキーマ・ヘルス・チェックを実行することを強くお薦めします。
Logon Managerによって実行されるスキーマの拡張の詳細は、次の付録を参照してください。
・ 付録A: Logon Managerリポジトリ・オブジェクト用の最小管理権限
・ ?付録B: 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は、ユーザーが「First-Time Use (FTU)」ウィザードを完了したときに生成される一意キーを使用してアプリケーション資格証明を暗号化します。資格証明は、エージェントのローカル・キャッシュ内、ディレクトリ内およびネットワークを移動しているときも常に暗号化された状態を維持します。Logon Managerは、設定されたアプリケーションがログオンをリクエストしたときにのみ資格証明を(ディスクではなくメモリーに対して)復号化し、ログオン・リクエストの完了後すぐにターゲット・メモリーの場所を消去します。ユーザーおよび有効なアプリケーションごとにLogon Managerが格納するデータ量はわずかです(数バイトか数キロバイト)。
注意: 認証時にユーザーからディレクトリに送信される資格証明が暗号化されるように、SSLサポートを有効にすることをお薦めします。SSLが有効でない場合、それらの資格証明はクリア・テキストで送信され、パケット・スニファによる傍受が可能になります。詳細は、「SSLのサポート」を参照してください。
ディレクトリ・サーバーが失敗すると、Logon Managerはサーバー・リストの次のサーバーに接続しようとします。リスト上のどのサーバーにもアクセスできない場合、その問題が修正されるまでは同期が使用できなくなります。使用している環境で複数の物理ディレクトリ・サーバーが必要な場合、それらのサーバー間で、ネットワークからのリクエストを自動的に均等に分散させるロード・バランサを使用することを強くお薦めします。1台のマシンがオフラインになった場合、そのワークロードを残りのマシンで一時的に吸収することができ、エンド・ユーザーに対するフェイルオーバー透過性、および障害のあるマシンをオンラインに戻すための十分な時間が提供されます。
警告: ロード・バランサの背後で同期のレプリケーションを使用する複数のLDAPサーバーでのLogon Managerのデプロイは、アクティブ-アクティブ(ロード・バランシング済)シナリオにおける高可用性に対してサポートされておらず、アクティブ-パッシブ(フェイルオーバー)シナリオでのみサポートされます。詳細は、Oracle Supportに連絡してください。
Logon Managerソフトウェアのアーキテクチャについては、このガイドでは詳しく取り扱いません。
詳細な説明が記載されたOracleのホワイト・ペーパーをお求めの場合は、オラクル社の担当者に問い合せてください。
Logon Managerでは、組織のニーズに合わせてディレクトリ構造を思いのままに設定できます。具体的には、データをフラット・モデルで格納するか階層構造で格納するかの選択肢があります。フラット・モデルは小規模なデプロイメントでは問題なく機能しますが、成長する大規模なデプロイメントでは最初から階層構造を使用します。サブツリーの適切な構造は次の要素によって決まります。
・ ユーザーの数
・ Logon Managerでサポートするアプリケーションの数
・ 既存のインフラストラクチャの堅牢性
・ 組織の構造
次のガイドラインに従ってサブツリーを階層構造として設定することをお薦めします。
・ OUを使用して、部門や部署など、組織の構造に合わせたカテゴリごとにテンプレートおよびポリシーをグループ化します。
・ OUレベルでアクセスを制御します。
・ 現在の環境で特に指定がないかぎり、継承を無効化し、Logon Managerのルート・コンテナでユーザー権限を付与しないようにします。
このように階層を設定すると、次の利点があります。
・ 見やすくわかりやすいツリー構造。ディレクトリ・ブラウザでサブツリーを表示すると、サブツリー構造を一覧できるので全体が把握しやすくなります。
・ 不要な権限は継承されません。ユーザーには、アクセスする必要のないサブOUに対する権限はネイティブで継承されません。これにより、ツリーの下位に継承される不要なアクセス権限を明示的に拒否せずに済みます。
・ ネットワーク、エージェントおよびディレクトリの堅牢なパフォーマンス。通常、大量のテンプレートおよびポリシーをダウンロードするユーザーは、自分のジョブに関連する項目のみをダウンロードするユーザーよりもネットワーク・トラフィックが多く、ディレクトリの負荷も高くなります。グループ化によって、環境のリソースが節約され、エージェントのレスポンス時間が改善されます。
・ 管理タスクの分散。テンプレートを制御しやすいセットに整理し、
アクセス権限の設定によって、ユーザーが管理できるテンプレートを決定します。権限に基づいたテンプレートのバージョン制御を実装する機能も使用できます。
・ 低い管理オーバーヘッド。テンプレート・レベルでのアクセスの制御では、Logon Manager管理コンソールから個々のテンプレートに権限を設定する必要があり、OUレベルでのアクセスの制御は、Microsoftやサードパーティの管理ツールを使用した委任管理によって行います。
図5は、前述のベスト・プラクティスを反映して設計されたサンプルのLogon Managerサブツリーを示しています。
図5 Logon Managerサブツリーの推奨設計
サンプルのシナリオでは、ポートランド部門のユーザーは、サクラメント部門で使用するアプリケーションへのアクセスは不要で、その逆も同様なので、各部門のテンプレートおよびポリシーは、ルートの専用サブOUに配置し、両部門が互いのサブ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オブジェクト。このオブジェクトは、LDAPユーザー・アカウントをPeople OUに格納されているユーザーのアプリケーション資格証明にリンクします。ユーザーがログインすると、Logon Managerは、vGOLocatorオブジェクトが見つかるまでツリーをユーザーのオブジェクトから上に移動します。vGOLocatorオブジェクトによって、Logon ManagerにPeople OUへのパスが提供されます。
注意: 13ページの図に示されるように、このオブジェクトは、ディレクトリのユーザー・アカウント・コンテナに置くことをお薦めします。必要に応じて、推奨はされませんが、ディレクトリ・ツリーのルートに置くこともできます。
vGOLocatorは、最低限でも、ユーザー・アカウントがあるコンテナと同じレベルに置く必要があります。
図5に示すように、ワークフローの各段階(開発、ステージング、本番)で専用のサブOUを作成することをお薦めします。この方法によって次のことができます。
・ テンプレートおよびポリシーがワークフローを通過して本番に入るときには、ワークフローの各ステージを移動するたびにこれらのシャドウ・コピーが保持されるので、テンプレートおよびポリシーに対して行われた変更をトラッキングできます。
・ 必要に応じて、テンプレートおよびポリシーを以前のバージョンにロールバックできます。
・ ワークフローの各ステージで、誰がどのテンプレートおよびポリシーを使用するかを制御できます。特に、テンプレートおよびポリシーを本番に配置できるユーザーの管理には、厳格なルール設定が必要です。
必ず、隔離した環境ですべてのアプリケーション・テンプレートおよび管理オーバーライドをテストしてから、エンド・ユーザーにデプロイしてください。テストは、変更内容の確認や、本番環境で発生したとしたら、解決するのに多くのコストがかかるような潜在的な問題の解決に役立ちます。正しく構成されていないテンプレートや誤った管理オーバーライドをネットワーク全体にプッシュした場合、ミッション・クリティカルなアプリケーションへのアクセスがエンタープライズ全体で失われることがあるので、テストは大規模なデプロイメントでは特に重要です。
隔離したテスト環境をセットアップする場合は、デプロイメント・グループのメンバーのみがアクセス権を持つ専用のテスト・コンテナを作成してください。次に、このコンテナ内のLogon Managerエージェントを特定して、テンプレートと管理オーバーライドをその中に配置します。テンプレートとポリシーが意図したとおりに動作していることを確認したら、それらをターゲットの本番コンテナに移動します。
テンプレートをテストした後にシャドウ・コピーを維持しない場合、次の手順に従って、それらをテスト・コンテナからターゲットの本番コンテナに移動します。
1. ディレクトリからテンプレートを取り出します。
2. そのテンプレートのローカル・バックアップを作成します。
3. ディレクトリ内の新しい場所に、このコピーを配置します。
4. テンプレートを元の場所から削除します。
コンソールを使用してオブジェクトのアクセス制御リスト(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レジストリに格納されているグローバル・エージェント設定よりも優先され、エージェント用のドメイン・ポリシーを構成します。オーバーライドは、同期化の際にエージェントによって中央リポジトリからダウンロードされ、改ざん防止機能が付いた、エージェントの暗号化済ローカル・キャッシュに格納されるため、これによって、エンド・ユーザーによる変更ができないようになります。ロール/グループのセキュリティが有効な場合、管理オーバーライドはユーザーまたはグループごとに適用することも、企業全体に適用してすべてのユーザー設定の一貫性を保つこともできます。
注意: 管理オーバーライドを計画する場合は慎重に行ってください。オーバーライドが少なければ、格納および転送するデータも少なくなるので、中央リポジトリとの同期がより効率的になります。エンド・ユーザーのマシン上では管理オーバーライドを確認することができないため、オーバーライドの数を減らすことで不明な状況が解消され、トラブルシューティングも容易になります。
管理オーバーライドとグローバル・エージェント設定は、エージェントの完全な構成ポリシーを適用します。このガイドの残りの部分では、推奨される最適な構成について説明し、他のLogon Managerベスト・プラクティスのガイドにある情報を補足します。
警告: ドメイン名やユーザー・オブジェクト・パスなどの設定は、必ず十分にテストしてからデプロイし、必要のない場合は管理オーバーライドとしてデプロイしないでください。入力ミスによるドメイン名の単純な間違いなどによって、エンド・ユーザーのワークステーションでディレクトリの同期ができなくなると、コンソールから修正内容を伝えることはできないため、他のツールを使用してユーザー・マシンに変更を適用する必要があります。
図6は、LDAPディレクトリと同期するためのLogon Manager管理コンソールの標準的な設定を示しています。
図6 Logon Manager管理コンソール
次の項では、LDAPと同期するためのLogon Managerの構成について、そのベスト・プラクティスを説明します。このガイドで説明されている設定の詳細な情報が必要な場合は、コンソールに含まれているオンライン・ヘルプを参照してください。
注意: 開始する前に、Logon ManagerエージェントとLDAPのシンクロナイザ・プラグインがインストールされていることを確認してください(インストールされていないとコンソールにAD設定が表示されません)。インストール手順については、使用しているLogon Managerのバージョン用の
インストレーション・ガイドを参照してください。
ヒント: 開発およびステージング環境では、Internet Explorerの「発行元証明書の取り消しを確認する」オプションを無効にして、コンソールの起動時に、マシンがインターネットに接続されていない場合の遅延が起きないようにします。(この遅延は、Internet Explorerによるサーバー証明書の確認が行われて、証明書認証局にアクセスできずタイムアウトするまでの時間です。)このオプションは本番マシンでは無効にしないでください。
このガイドや他のLogon Managerベスト・プラクティスガイドで説明されていない設定は、現在の環境で特に指定がないかぎり、デフォルト値のままにすることをお薦めします。Logon Manager管理コンソールで設定のチェック・ボックスが選択されていない場合は、デフォルト値が自動的に有効になります。この値は、チェック・ボックスの横にある非アクティブ・フィールドに表示されます。
この項では、推奨されるグローバル・エージェント設定のベスト・プラクティスを示します。次の説明に従って設定を構成し、カスタマイズされたLogon Manager MSIパッケージにそれらを含めます。(パッケージの作成手順については、ベスト・プラクティス: 大規模デプロイメント用のLogon Managerの構成のガイドを参照してください。)
Logon Managerの同期設定の構成を開始する前に、サポートされているどのディレクトリを使用しているかをLogon Managerに通知する必要があります。これによって、Logon Managerはリポジトリ構造を正しく解釈し、リポジトリの組込みデータ構造を干渉することなく、データを格納できます。
使用可能な選択肢は次のとおりです。
・ Unspecified LDAP Directory (デフォルト)
・ Generic LDAP Directory
・ Novell eDirectory
・ Oracle Directory Server Enterprise Edition
・ IBM Tivoli Directory Server
・ Oracle Internet Directory
・ Siemens DirX Directory Server
注意: リポジトリがリストされていない場合、アップグレード時に下位互換性用のドロップダウン・リストから「Unspecified LDAP Directory」(デフォルト)を選択し、それ以外の場合は、「Generic LDAP Directory」を選択します。
?場所: 「Global Agent Settings」a「Live」a「Synchronization」a「LDAPExt」
設定するには: チェック・ボックスを選択し、ドロップダウン・リストからリポジトリを選択します。
LDAP環境では、サーバーURLをLogon Managerに明示的に指定する必要があります。少なくとも2つの物理ディレクトリ・サーバーを使用し、自動的および透過的なフェイルオーバーのために、それらをロード・バランサの背後に置くことをお薦めします。ロード・バランサを使用しない場合は、エンド・ユーザーと次に使用可能なサーバーとの物理的な距離によるパフォーマンス・ヒットが最小になるように、エンド・ユーザーに対する
地理的近接度の順序でサーバーURLを配置します。ロード・バランシングの詳細は、
「Logon Managerデプロイメントのロード・バランシングの利点」を参照してください。
場所: 「Global Agent Settings」a「Live」a「Synchronization」a「LDAPExt」
設定するには: チェック・ボックスを選択して(…)ボタンをクリックし、必要な値を次に示すように(1行ごとに1つずつ)
入力します。終了したら、「OK」をクリックします。
Logon ManagerでActive Directoryにデータを格納するには、Logon Managerのルート・コンテナ(Logon Managerの構成オブジェクトが格納される)の場所を指定する必要があります。
?場所: 「Global Agent Settings」a「Live」a「Synchronization」a「LDAPEXT」?????????
設定するには: チェック・ボックスを選択し、(…)ボタンをクリックして必要な値を入力します。
????????????? 完了したら「OK」をクリックします。
LDAPディレクトリをデプロイする際、ユーザー・データおよび構成データの格納にディレクトリ・オブジェクトを使用することをお薦めします(これにより、「Logon Managerディレクトリのサブツリーの設計」の説明に従って、階層構造での格納、ロールおよびグループ・ベースの個別のコンテナに対するアクセス制御、テンプレートおよびポリシーを使用することが可能になります)。この機能を無効にしている場合、Logon Managerは、すべてのテンプレートおよび構成データをLogon Managerツリー・コンテナに単一のフラット・ファイルとして格納します。
?場所: 「Global Agent Settings」a「Live」a「Synchronization」
有効にするには: チェック・ボックスを選択して、ドロップダウン・リストで「Yes」を選択します。
Logon ManagerリポジトリのシンクロナイザはSSLサポートが有効の状態で出荷されるので、これを無効にしないことを強くお薦めします。使用する環境では、セキュリティを最大化するために、Logon Managerおよびその他のリポジトリへのすべての接続に必ずSSLを使用してください。
注意: このオプションを有効にする前に、環境をSSL接続用に構成する必要があります。
場所: 「Global Agent Settings」a「Live」a「Synchronization」a「LDAPEXT」
有効にするには(無効になっている場合): チェック・ボックスの選択を解除します。
ディレクトリ内のユーザー・アカウントがあるコンテナの場所を指定する必要があります。ディレクトリ内の複数の場所にユーザー・アカウントが格納されている場合、複数のパスを指定できます。このオプションを構成するときは、次のガイドラインに従います。
・ 「Enable Directory Search for Users」オプションが有効になっている場合、ここで値としてディレクトリ・ルートを指定しないでください。そのようにすると、ユーザーが無効なユーザー名を入力した場合にLogon Managerによってディレクトリ全体が解析されます。
・ 指定したパスの範囲が広すぎた場合の余分なアカウント検索を避けるため、パスを指定する際はできるかぎり限定します。一方、場所の数が多すぎる場合、ここに共通の親コンテナを指定すると、構成の複雑さを軽減できます。
場所: 「Global Agent Settings」a「Live」a「Synchronization」a「LDAPEXT」
Logon Managerによるユーザー・アカウントの検索を行うには: チェック・ボックスの選択を解除します(デフォルト設定)。
設定するには: チェック・ボックスを選択して(…)ボタンをクリックし、必要な値を次に示すように(1行ごとに1つずつ)入力します。終了したら、「OK」をクリックします。
ディレクトリ内のユーザー・アカウントへの正確なパスを指定しない場合(たとえば、ユーザー・アカウントが多数の場所に広がっている場合など)、このオプションを有効にすると、「Specify the Path(s) to User Accounts」に設定された1つ以上の場所にあるユーザー・アカウントをLogon Managerで検索できます。
場所: 「Global Agent Settings」a「Live」a「Synchronization」a「LDAPEXT」a「Special Purpose」
設定するには: チェック・ボックスを選択して、ドロップダウン・メニューから「Yes」を選択します。
Novel eDirectoryを使用している場合、「Naming attribute string」オプションの値をcnに設定する必要があります。その他のLDAPディレクトリの場合は、ディレクトリ・チームにこのオプションの構成方法を問い合せてください。
場所: 「Global Agent Settings」a「Live」a「Synchronization」a「LDAPEXT」a「Special Purpose」
設定するには: チェック・ボックスを選択し、希望の値を入力します。
認証が失敗したかまたは切断された場合に、ディレクトリに対して再認証を行うには、
「Prompt when disconnected」オプションを使用して、Logon Managerがユーザーにプロンプトを表示するかどうかを決定します。この設定をデフォルト値の「No」のままにすることをお薦めします(こうすることで、不要な混乱とそれによるヘルプデスクへの問合せを避けられます)。
場所: 「Global Agent Settings」a「Live」a「Synchronization」a「LDAPEXT」
設定するには: チェック・ボックスを選択し、ドロップダウン・リストから適切なオプションを選択します。
このオプションは、前述した「Credentials to use」オプションに直接関連し、「Allow disconnected operation」が「No」に設定されている場合は何も効果はありません。
特定のシナリオでは、1つ以上のオーセンティケータでLDAP同期資格証明を共有することにより、エンド・ユーザーが受け取る認証プロンプトの数を減らすことができます。詳細は、「オーセンティケータの選択と構成」を参照してください。
場所: 「Global Agent Settings」a「Live」a「Synchronization」a「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」a「Live」a「Synchronization」
設定するには: チェック・ボックスを選択して、(…)ボタンをクリックします。表示されるリストで、「LDAPEXT」の横のチェック・ボックスを選択して、「OK」をクリックします。必要に応じて、上向きまたは下向きの矢印を使用して、同期順を設定します。
プロンプトが表示されたときに入力する資格証明がエンド・ユーザーにわかるように、このオプションを使用してディレクトリ認証プロンプトに説明的なタイトルを付けることをお薦めします。
場所: 「Global Agent Settings」a「Live」a「Synchronization」a「LDAPEXT」
設定するには: チェック・ボックスを選択し、希望のテキストを入力します。
ユーザーが常に最新の資格証明、アプリケーション・テンプレート、パスワード・ポリシーおよび管理オーバーライドを持つようにするには、起動時に同期を待つようにエージェントを構成します。このオプションを有効にすると、エージェントはディレクトリがオンラインかどうかを確認します。ディレクトリがオンラインの場合は、ディレクトリと正常に同期するまで、エージェントはアプリケーションのログオン・リクエストに応答しません。
ディレクトリがオフラインの場合は、エージェントは同期を試行せずにすぐに起動します。
?場所: 「Global Agent Settings」a「Live」a「Synchronization」
設定するには: チェック・ボックスを選択して、ドロップダウン・リストから「Yes」を選択します。
最適化された同期は、Logon Managerエージェントに、前回の同期の後で変更された資格証明のみを同期するように指示します。現在の環境に応じて、次のいずれかを実行します。
・ ユーザーごとの資格証明が大量にある場合は、このオプションを有効にすると、デプロイメントでの同期パフォーマンスが向上します。
・ ユーザーごとの資格証明が4つ以下で、ユーザーごとにダウンロードしたテンプレートが大量にある場合は、このオプションを無効にすると、デプロイメントでの同期パフォーマンスが向上します。
?場所: 「Global Agent Settings」a「Live」a「Synchronization」
現在の環境で特に指定する必要がない場合は、デフォルト値(「Yes」)を使用してください。
デプロイ中にディレクトリへの接続を確立できない場合には、Logon Managerエージェントが実行されないように構成します。これにより、エージェントがディレクトリに接続されていない状態で、かつローカル・キャッシュが存在しない場合に、「First Time Use」(FTU)ウィザードが完了してしまうことを回避できます。ディレクトリが使用できないときにエージェントが実行されないようにすることで、ディレクトリから切断されているのにFTUウィザードが完了して暗号化鍵の2つ目のセットが作成されてしまう、というよくある状況を回避できます。?
注意: 必要なベスト・プラクティスの詳細は、Logon Managerベスト・プラクティス: Logon Managerエージェントの構成のガイドを参照してください。
場所: 「Global Agent Settings」a「Synchronization」
設定するには:チェック・ボックスを選択して、ドロップダウン・リストから「No」を選択します。
ドメイン名やオブジェクトのパスなどのディレクトリの同期設定は、管理オーバーライドとしてデプロイしないでください。(この説明は「グローバル・エージェント設定および管理オーバーライド」を参照してください。)推奨されるオーバーライドのベスト・プラクティスについては、Logon Managerベスト・プラクティス: Logon Managerエージェントの構成のガイドを参照してください。
この項では、LDAPディレクトリでのLogon Managerのデプロイメント・プロセスについて、その概要を説明します。デプロイメントを進める前に、このドキュメントの前の項にすべて目を通すようにしてください。LDAPディレクトリでのLogon Managerのデプロイでは、次の手順を実行する必要があります。
1. 次のドキュメントを入手します。
・ このドキュメントの最新バージョン
・ 『Oracle Enterprise Single Sign-On Suite Plusインストレーション・ガイド』
・ 『Oracle Enterprise Single Sign-On Suite Plus管理者ガイド』
2. 使用しているバージョンのLogon Manager用インストレーション・ガイドの説明に従って、ドメイン内のマシンにLogon ManagerエージェントおよびLogon Manager管理コンソールをインストールします。エージェントのインストール時には、LDAPシンクロナイザ・プラグインが選択されていることを確認してください。
3. 「Logon Managerのためのディレクトリの準備」の手順を完了します。
a. Logon Managerのクラスと属性を使用してディレクトリ・スキーマを拡張します。
b. 各ユーザーのアプリケーション資格証明を格納するPeople OUを作成します。
c. vGOLocatorオブジェクトを作成します。
d. 構成オブジェクト・コンテナおよび必要なツリー構造を作成します。
4. 次のようにLogon Managerを構成します。
a. 「オーセンティケータの選択と構成」の手順を完了します。
b. 「LDAPシンクロナイザの構成」の手順を完了します。
c. このガイドの「推奨グローバル・エージェント設定」で説明されているオプションを構成します。
d. Enterprise Single Sign-On Suite管理者ガイドのLogon Managerエージェントの構成に関する項で説明されているオプションを構成します。
e. 「Logon Managerの構成のテスト」の説明に従って構成をテストします。
注意: 該当する設定の詳細は、コンソールのオンライン・ヘルプを参照してください。オンライン・ヘルプは、コンソールの「Help」メニューから参照できます。
5. テスト用のマシンで次の手順を実行します。
・ 主なテンプレートおよびポリシーのパイロット・セットを作成します。
・ 本番環境にデプロイされる、主なテンプレート、グローバル・エージェント設定、管理オーバーライドをそれぞれテストして、エンド・ユーザーの操作性を最終調整します。
6. 『Enterprise Single Sign-On Suite Plusインストレーション・ガイド』の大量デプロイメント用のLogon Managerのパッケージ化の手順を完了して、カスタムMSIパッケージを作成し、エンド・ユーザーのマシンにデプロイします。
7. 残りのアプリケーション・テンプレートの作成、テスト、デプロイメントを行います。異なるアプリケーション・タイプのプロビジョニングの詳細は、Logon Managerアプリケーション・テンプレートの構成および診断のガイドを参照してください。
この項では、ディレクトリをLogon Managerで使用するための基本的な準備手順について説明します。
この準備では、それぞれのユーザー・オブジェクトに資格証明を格納できるように、Logon Managerのクラスと属性を使用してディレクトリ・スキーマを拡張し、必要なツリー構造を作成します。この手順を開始する前に、使用しているバージョンのLogon Manager用のインストールおよび設定ガイドの説明に従って、Logon Manager管理コンソールをインストール済であることを確認してください。
1. Logon Manager管理コンソールを起動します。デフォルトでは、コンソールのショートカットは「スタート」a「プログラム」a「Oracle」a「Logon Manager Console」にあります。
注意: 開発およびステージング環境では、Internet Explorerの「発行元証明書の取り消しを確認する」オプションを無効にして、コンソールの起動時に、マシンがインターネットに接続されていない場合の遅延が起きないようにします。(この遅延は、Internet Explorerによるサーバー証明書の確認が行われて、証明書認証局にアクセスできずタイムアウトするまでの時間です。)このオプションは本番マシンでは無効にしないでください。
2. コンソールで、「Repository」メニューから「Extend Schema」を選択します。コンソールに「Connect to Repository」ダイアログが表示されます。
3. 「Server Name」フィールドに、スキーマのマスター・ドメイン・コントローラの完全修飾IPアドレス、ホスト名またはNetBIOS名を入力します。
4. 「Repository Type」ドロップダウン・リストで、目的のLDAPディレクトリ・タイプを選択します。
5. ディレクトリで接続をリスニングしているポート番号を入力します。デフォルトのポートは、SSL接続の場合は636、非SSL接続の場合は389です。
6. (オプション) SSLを使用するようにディレクトリ・サーバーが構成されている場合は、「Use secure channel (SSL)」オプションを選択したままにし、使用しない場合は選択を解除します。(詳細は、「SSLのサポート」を参照してください。)
7. 「Username/ID」および「Password」フィールドで、Logon Managerがディレクトリ
に接続するときに使用するアカウントの資格証明を入力します。環境によっては、ユーザー名の一部に対応するドメイン名を含める必要があります(例: DOMAIN\user)。
8. 「OK」をクリックして、コンソールがスキーマの拡張を実行するのを待ちます。コンソールに進行状況を示すステータス・ダイアログが表示されます。スキーマが正常に拡張されると、
ステータス・ダイアログに確認のメッセージが表示されます。
9. 「Close」をクリックします。
注意: 既存のコンテナを使用してLogon Managerデータを格納することもできますが、その場合、ディレクトリのパフォーマンスが低下することがあります。サブツリーのルートとして専用のコンテナを作成することをお薦めします。
1. Logon Manager管理コンソールで、ツリー上の「Repository」ノードを選択します。
2. 右側ペインで「Click here to connect」リンクをクリックします。コンソールに「Connect to Repository」ダイアログが表示されます。
3. 29ページの手順3から7の説明に従って、フィールドを入力し、「OK」をクリックして接続します。
4. Logon Managerのサブツリーのルートとして機能するコンテナを作成します。
a. 次に示すように、このツリーで対象の親コンテナを右クリックし、コンテキスト・メニューから「New Container」を選択します。
コンソールに「New Container」ダイアログが表示されます。
b. 「New Container」ダイアログで、必要な名前を入力して「OK」をクリックします。
注意: 現在の環境で、このコンテナに特定の名前を必要としない場合は、デフォルト名のESSOを使用することをお薦めします。
5. Logon Manager構成オブジェクト・コンテナ(SSOConfig)を作成します。
a. 次に示すように、このツリーでLogon Managerのサブツリーのルートを右クリックし、コンテキスト・メニューから「New Container」を選択します。
b. ?コンテナに「New Container」ダイアログが表示されます。
c. 「New Container」ダイアログで、必要な名前を入力して「OK」をクリックします。
注意: 現在の環境で、このコンテナに特定の名前を必要としない場合は、デフォルト名のSSOConfigを使用することをお薦めします。
6. 手順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を作成するには:
1. Logon Manager管理コンソールで、ツリー上の「Repository」ノードを選択します。
2. 右側ペインで「Click here to connect」リンクをクリックします。コンソールに「Connect to Directory」ダイアログが表示されます。29ページの手順3から7の説明に従って、フィールドを入力し、「OK」をクリックして接続します。
3. ツリーでLogon Managerサブツリーのルートを右クリックし、「Create People Container」を選択します。
4. People OUがターゲットの場所に存在するようになったことを確認します。
前述の手順を完了した後にPeople OUが表示されない場合、またはディレクトリ内のネーミング違反やその他の問題を示すエラーを受け取った場合、ディレクトリのベンダーのドキュメントで考えられる原因および処置を参照してください。
People OUを作成すると、ユーザー・アカウントをPeople OUに格納されているユーザー・アプリケーション資格証明にリンクするvGOLocatorポインタ・オブジェクトを作成する必要があります。
注意: 少なくともユーザー・アカウントを保持するコンテナと同じレベルにvGOLocatorオブジェクトを作成する必要があります。vGOLocatorは、ディレクトリのユーザー・アカウント・コンテナ内に置くのが理想的です。
vGOLocatorオブジェクトを作成するには:
1. Logon Manager管理コンソールで、ツリー上の「Repository」ノードを選択します。
2. 右側ペインで「Click here to connect」リンクをクリックします。コンソールに「Connect to Repository」ダイアログが表示されます。31ページの手順3から7の説明に従って、フィールドを入力し、「OK」をクリックして接続します。
3. 次に示すように、このツリーでディレクトリのユーザー・アカウント・コンテナ(Sun Directory Serverベースの例ではdc=oracle,ou=People)を右クリックし、コンテキスト・メニューから「Add Locator Object」を選択します。
4. 表示される「Add Locator Object」ダイアログで、次の手順を実行します。
a. 「Name」フィールドにdefaultと入力します。
b. 「Forwarding Location」フィールドに、People OUを保持するコンテナへの
フルパスを入力します。(または、ツリーを使用して、ターゲット・コンテナにナビゲートして選択
できます。)
c. 「OK」をクリックします。
5. vGOLocatorオブジェクトが目的の場所に存在することを確認します。
オーセンティケータは、Logon Managerのユーザーを一意に認証するために必要です。LDAP環境では、構成に基づいて、次のいずれかのオーセンティケータを選択できます。
・ Windowsパスワード・オーセンティケータ(バージョン2)。次の条件が満たされる場合、認証プロンプトが表示されないようにできるため、このオーセンティケータの使用をお薦めします(詳細は、「オーセンティケータとのLDAPシンクロナイザ資格証明の共有」を参照してください)。
o ユーザーにActive DirectoryまたはNTドメイン・アカウントがあります。
o 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エージェントによる自動取得用のディレクトリにそれらをプッシュ送信します。
1. Logon Manager管理コンソールを起動します。
2. 左側ペインで、「Global Agent Settings」ノードを右クリックして、
コンテキスト・メニューから「Import」a「From Live HKLM」を選択します。現在のエージェント設定がWindowsのレジストリからコンソールにインポートされます。
3. 「推奨グローバル・エージェント設定」および「推奨管理オーバーライド」の手順に従ってエージェントを構成します。
注意: 設定の横のチェック・ボックスが選択されていない場合は、設定のデフォルト値(チェック・ボックスの右にグレー表示されている値)が使用されます。
4. 後で参照するために、構成をXMLファイルに保存します。「File」メニューから「Save」を選択し、必要なファイル名を入力して「Save」をクリックします。設定を変更する場合は、このXMLファイルをコンソールにロードして元の選択に戻すことができます。
5. 「Tools」メニューから「Write Global Agent Settings to HKLM」を選択します。コンソールによって、変更がレジストリに書き込まれ、エージェントが再起動されます。
6. 次の項に進みLogon Managerの構成を完了します。
この部では、このガイドの前半の説明を補足する資料を示します。
付録の内容は次のとおりです。
・ 付録A: Logon Managerリポジトリ・オブジェクト用の最小管理権限
・ 付録B: Logon Managerリポジトリ・オブジェクトのクラスおよび属性
・ 付録C: Active DirectoryでのLogon Managerのトラブルシューティング
・ 付録D: Microsoft AD LDS (ADAM)でのLogon Managerのトラブルシューティング
・ 付録E: AD LDS (ADAM)デプロイメント上での必要なユーザー・グループの作成
・ 付録F: Logon Managerで使用するためのOracle Internet Directoryの構成
・ 付録G: Logon Managerで使用するためのOracle Virtual Directoryの構成
・
この付録では、Logon Managerが機能するために特定のLogon Managerオブジェクトに付与する必要がある最小管理権限を示します。
注意: この付録の情報は参考用です。デフォルトでは、リポジトリ・スキーマを拡張すると、Logon Managerによって自動的に適切な権限が設定されます。
必要に応じて、これらの権限を手動で付与し、リポジトリで直接修正できます。
Logon Managerによってテンプレートやポリシーなどの構成項目が格納される各コンテナには、次の管理権限を付与する必要があります。
・ 内容の一覧表示
・ すべてのプロパティの読取り
・ すべてのプロパティの書込み
・ 削除
・ 読取り権限
・ 権限の変更
・ 所有者の変更
・ vGOConfigオブジェクトの作成
・ vGOConfigオブジェクトの削除
・ 組織単位オブジェクトの作成
・ 組織単位オブジェクトの削除
ユーザー資格証明を監査するには、vGOUserDataオブジェクトとvGOSecretオブジェクトに次の管理権限を付与する必要があります。
vGOUserDataオブジェクト:
・ 内容の一覧表示
・ すべてのプロパティの読取り
vGOSecretオブジェクト:
・ 内容の一覧表示
・ すべてのプロパティの読取り
ユーザー資格証明を削除するには、vGOUserDataオブジェクトとvGOSecretオブジェクトに次の管理権限を付与する必要があります。
注意: 資格証明を削除できるユーザーは、それらを監査することもできます。
vGOUserDataオブジェクト:
・ 内容の一覧表示
・ すべてのプロパティの読取り
・ 削除
・ サブツリーの削除
・ すべての子オブジェクトの削除
vGOSecretオブジェクト:
・ 内容の一覧表示
・ すべてのプロパティの読取り
・ 削除
・ サブツリーの削除
・ すべての子オブジェクトの削除
この付録では、スキーマの拡張の際に、Logon Managerによってディレクトリに追加されるディレクトリ・クラス、属性およびアクセス権限について説明します。
vGOUserDataオブジェクトはアプリケーション資格証明を格納するコンテナです。(資格証明は、タイプvGOSecretのオブジェクトとして格納されます。)
属性:
属性名 |
構文 |
フラグ |
vGOSecretData |
大/小文字が区別されない文字列 |
Singled Valued、Synchronize |
vGORoleDN |
未使用 |
|
その他のオプションの属性 |
ou、dn、cn、o |
アクセス権限: ユーザーは、自分のユーザー・オブジェクトにある前述の属性に対して、読取りおよび書込みを行うことができます。
管理者には完全な権限がありますが、このオブジェクトの暗号化された子(vGOSecret)を
読み取ることはできません。
vGOSecretオブジェクトは、各ユーザーのアプリケーション資格証明を格納するオブジェクトや削除したオブジェクトなど、すべてのユーザーの機密情報を格納します。これは、補助クラスとしてvGOUserDataオブジェクトに追加されます。
属性:
属性名 |
構文 |
フラグ |
vGOSecretData |
大/小文字が区別されない文字列 |
Singled Valued、Synchronize |
vGOSharedSecretDN |
未使用 |
|
その他のオプションの属性 |
ou、dn、cn、o |
アクセス権限: vGOUserDataオブジェクトから継承されており、すべてのユーザーがこのオブジェクトを読み取ることができますが、所有者のみがこのオブジェクトに書き込むことができ、所有者または管理者のみがこのオブジェクトを削除できます。
vGOConfigは、アプリケーション・テンプレート、パスワード生成ポリシー、管理オーバーライドなどのLogon Manager構成オブジェクトを格納するコンテナです。
属性:
属性名 |
構文 |
フラグ |
vGOConfigType |
大/小文字が区別されない文字列 |
Singled Valued、Synchronize |
vGOConfigData |
大/小文字が区別されない文字列 |
Singled Valued、Synchronize |
vGORoleDN |
未使用 |
|
その他のオプションの属性 |
ou、dn、cn、o |
アクセス権限: すべてのユーザーには、このオブジェクト内の属性に対して読取り専用権限があります。
管理者には完全な権限があります。
vGOLocatorClassはポインタ・オブジェクト・クラスです。このクラスのオブジェクトは、ユーザー資格証明の格納先をLogon Managerエージェントに伝えます。
属性:
属性名 |
構文 |
フラグ |
vGOLocatorAttribute |
大/小文字が区別されない文字列 |
Single Valued |
その他のオプションの属性 |
dn、cn、o |
アクセス権限: すべてのユーザーには、このクラスのすべてのオブジェクトに関して、これらの属性に対する読取り/比較/検索の権限があります。
この付録では、Logon Managerのデプロイメント中に発生する可能性のある問題について説明し、それらの問題の解決方法を示します。
ADスキーマの拡張に失敗した場合は、次の手順に従って原因を特定し、修正します。
1. 次の項目を確認してから、スキーマの拡張をもう一度試してみます。
・ 拡張を実行しているマシンが、ディレクトリと同じドメインに属している。
・ スキーマのマスターDCに対して拡張を実行している。
・ スキーマ管理者としてログオンしている。
2. それでもスキーマの拡張に失敗する場合は、Logon Manager管理コンソールをスキーマ・マスターDCに直接インストールして、スキーマの拡張をローカルで実行します。この解決方法はネットワークの問題(DNSの問題など)をすべて除外するので、ADスキーマにエラーがないかぎり失敗しません。
3. それでもスキーマを拡張できない場合は、スキーマが破損している可能性があります。
MicrosoftのMOMツールを使用してスキーマの状態を確認し、使用しているスキーマが、次のMS TechNetの記事で説明されているMicrosoftのベスト・プラクティスに準拠していることを確認します。http://technet.microsoft.com/en-us/library/bb727085.aspx
ユーザー・オブジェクトへの資格証明の格納を有効にしている場合、Logon Managerによって、vGOUserDataタイプおよびvGOSecretタイプのオブジェクトを作成する権限がすべてのユーザーに付与されます。これらの権限は、ディレクトリ・ルートで付与され、それぞれのユーザー・オブジェクトのすべてに継承されます。これらの権限が付与されていないか、または適切に継承されていない場合、それぞれのユーザー・オブジェクトの下にアプリケーション資格証明を格納できません。次のような原因が考えられます。
・ 必要な権限が付与されていない。Logon Manager管理コンソールで、「Repository」メニューから「Enable storage of credentials under the user object (AD only)」を選択し、Logon Managerによって必要な権限が付与されるように設定する必要があります。
・ 権限が、ユーザー固有の子ドメインではなく親ドメインで付与されており、子ドメインに適切に伝播されていない。このような場合、親ドメインのDCで実行しているコンソールを使用して必要な権限を自動的に付与するか、またはそれぞれの子ドメインのルートで権限を手動で付与して、それらがユーザー・オブジェクトまで伝播するのを待ちます。
注意: この問題が特定のユーザー・グループ(管理者、パワー・ユーザーなどの保護されたグループのメンバー)のみに関連する場合は、「一部のユーザーがユーザー・オブジェクトの下に資格証明を格納できない」を参照してください。
ユーザー・オブジェクトに資格証明を格納するために必要な権限は、ツリー・ルートで付与され、ユーザー・オブジェクトに継承されます。一部のユーザー(管理者などの保護されたユーザー・グループのメンバー)だけがユーザー・オブジェクトの下に資格証明を格納できない場合、その原因として最も可能性の高いのは、AdminSDHolderオブジェクトによる権限の継承のブロックです。すべての保護されたグループのACLを制御する、オブジェクトのACLは、デフォルトで権限の継承を禁止しています。この問題の詳細は、http://support.microsoft.com/kb/817433にあるMSナレッジ・ベースの記事を参照してください。
次の保護されたユーザー・グループは、この問題による影響を受けることがわかっています。
・ Enterprise Admins
・ Schema Admins
・ Domain Admins
・ Administrators
・ Account Operators
・ Server Operators
・ Print Operators
・ Backup Operators
・ Cert Publishers
この特定の問題が存在するかどうかを確認するには、次の手順を実行します。
1. ドメイン管理者としてプライマリDCにログインします。
2. Microsoft管理コンソールを開き、
「Active Directoryユーザーとコンピュータ」スナップインをロードします。
3. 「表示」メニューから、「拡張機能」を選択します。
4. 関連するユーザー・オブジェクトにナビゲートし、右クリックして「プロパティ」を選択します。
5. 表示されるダイアログで、「セキュリティ」タブを選択します。
6. 「詳細設定」をクリックします。「セキュリティの詳細設定」ダイアログが表示されます。
7. ダイアログで、次の設定を確認します。
a. 「親からの継承可能なアクセス許可を...」チェック・ボックスの選択が解除されている。
b. 手順6の図で強調表示されている権限がリストに存在しない。
前述の条件が満たされている場合、ユーザー・オブジェクトはディレクトリ・ルートから必要な権限を継承していません。
この問題を修正するには、手動でAdminSDHolderオブジェクトのACLを変更して、vGOConfigタイプとvGOUserDataタイプのオブジェクトを作成する権限を付与する必要があります。手順は次のとおりです。
1. ドメイン管理者としてプライマリDCにログインします。
2. Microsoft管理コンソールで、「Active Directoryスキーマ」スナップインを開きます。
3. 左側のツリーで、「クラス」ノードをドリル・ダウンして、「vGOUserData」ノードを見つけます。
4. 「vGOUserData」クラスを右クリックし、コンテキスト・メニューから「プロパティ」を選択します。
5. 表示されたダイアログで、「関係」タブを選択します。
6. 「上位クラスの追加」ボタンをクリックします。
7. 表示されるダイアログのドロップダウン・リストから「コンテナ」を選択して「OK」をクリックします。
「コンテナ」クラスが「利用可能な上位クラス」フィールドに表示されます。
8. 「OK」をクリックして、プロパティ・ダイアログを閉じます。
9. Microsoft管理コンソールで、「Active Directoryユーザーとコンピュータ」スナップインを開きます。
10. 「表示」メニューから、「拡張機能」を選択します。
11. 次の場所に存在する「AdminSDHolder」コンテナに移動します。
cn=AdminSDHolder,cn=System,dc=<domainName>,dc=<domainSuffix>
12. 「AdminSDHolder」コンテナを右クリックして「プロパティ」を選択します。
13. 「プロパティ」ダイアログで、「セキュリティ」タブを選択して「詳細設定」をクリックします。
14. 「セキュリティの詳細設定」ダイアログで、「追加」をクリックします。
15. 「ユーザー、コンピュータ、またはグループの選択」ダイアログで、SELFと入力して「OK」をクリックします。
16. 「アクセス許可エントリ」ダイアログで、次の手順を実行します。
a. 「適用先」ドロップダウン・リストで、「このオブジェクトとすべての子オブジェクト」を選択します。
注意: vGOUserDataオブジェクトの作成権限と削除権限が権限リストに表示されない場合は、「適用先」ドロップダウン・リストから、かわりとして「ユーザー オブジェクト」を選択します。同様の事例は、異なるバージョンやパッチのActive Directoryと、基礎となるオペレーティング・システム間で発生します。
b. 権限リストで、強調表示されている次の権限の「許可」チェック・ボックスを選択します。
c. 「OK」をクリックします。
17. SDプロパゲータ(SDPROP)・プロセスを起動して、ネットワーク全体に即座に変更を伝播します。SDプロパゲータ・プロセスの起動手順は、http://support.microsoft.com/kb/251343にあるMicrosoftナレッジ・ベースの記事を参照してください。
注意: この手順で前述の権限を「このオブジェクトのみ」に適用するバージョンがある場合でも無視してください。これは非推奨であり、現在は前述の手順が優先します。
Logon ManagerでターゲットAD LDS (ADAM)インスタンスに接続できない場合、ADSIEditツールを使用してAD LDS (ADAM)インスタンスに直接接続してみてください。それでも接続できない場合は、考えられる原因を次に示します。
AD LDS (ADAM)インスタンスは、ターゲット・サーバー上でサービスとして実行されます。ターゲット・サーバーのコンピュータの管理MMC
スナップインを使用して、次のようにしてAD LDS (ADAM)インスタンスが実行中であるかどうかを確認します。
1. 「コンピュータの管理」コンソールを開きます。(最も早いのは、「マイ コンピュータ」を右クリックしてコンテキスト・メニューから「管理」を選択する方法です。)
2. 左側ペインで「サービス」を選択します。コンソールに、システムにインストールされているサービスのリストが表示されます。
3. リストでAD LDS (ADAM)インスタンスを見つけます。
4. インスタンスのステータスが「停止」の場合、次のようにして開始します。
a. インスタンスをダブルクリックします。インスタンスのプロパティ・ダイアログ・ボックスが表示されます。
b. 「スタートアップの種類」オプションが「自動」に設定されていることを確認します(設定されていない場合は設定します)。
c. 「開始」をクリックして、インスタンスの初期化を待ちます。
d. 「OK」をクリックしてプロパティ・ダイアログ・ボックスを閉じます。
インスタンスのステータスが「開始」であるのにまだ接続できない場合、間違ったポートを使用してインスタンスに接続している可能性があります。詳細は次の項を参照してください。
カスタム・ポートを使用するようにAD LDS (ADAM)インスタンスを構成している場合、AD LDS (ADAM)インスタンスに接続する際に、Logon Manager (およびADSIEditなどの他のソフトウェア)にそのポートを使用することを指示する必要があります。この問題をトラブルシューティングするには、次の手順を実行します。
・ ターゲットAD LDS (ADAM)インスタンスが実行されているポートを確認するには、AD LDS (ADAM)のドキュメントを参照してください。
・ Logon ManagerがAD LDS (ADAM)への接続に使用するポートを確認(および修正)するには、コンソールの「サーバー」フィールドの内容を調べます。たとえば、dc1.company.com:9448のように、サーバーURLに特定のポート番号を追加していないかぎり、Logon Managerによってデフォルトのポート(SSL接続の場合は636、非SSL接続の場合は389)が使用されます。
Logon ManagerがAD LDS (ADAM)に接続できない場合、AD LDS (ADAM)への接続に使用するユーザー・アカウントに必要な権限があるかどうかを確認します。ユーザー・アカウントの権限を確認および設定するには、オペレーティング・システムおよびAD LDS (ADAM)のドキュメントを参照してください。
この付録では、AD LDS (ADAM)インスタンスにデプロイされたLogon Managerで使用するために、Active DirectoryにSSOAdminsおよびSSOUsersグループを作成する方法について説明します。
・ SSOAdmins。このグループには、ターゲットAD LDS (ADAM)インスタンスに対する管理権限を持つユーザーが少なくとも2人含まれます。また、このグループには、アプリケーション・テンプレートを作成およびプッシュする必要があるユーザーも含まれます。
注意:? インスタンスを作成する際は、このグループを管理ユーザー・グループとして指定してください。単一ユーザーを指定すると、その単一ユーザーがアクセスできなくなった場合に、
Logon Managerデプロイメントからロックアウトされる危険性があります。
・ SSOUsers。このグループには、他のすべてのLogon Managerユーザーが含まれます。
SSOAdminsおよびSSOUsersグループを作成し、必要なユーザーをこれらのグループに入れるには:
注意:? この手順では、どのユーザーがどのグループに属するかが決定済であり、ターゲット・ユーザー・アカウントがすでに存在することを前提としています。
1. 管理者としてドメイン・コントローラにログオンします。
2. 「Active Directory ユーザーとコンピュータ」コンソール・スナップインを開きます。
3. コンソールで、ターゲット・ドメインを展開して「ユーザー」ノードを右クリックします。
4. コンテキスト・メニューで、「新規」a「グループ」を選択します。
5. 「新しいオブジェクト - グループ」ダイアログで、次の手順を実行します。
a. 前述のグループ名を入力します。
b. グループのスコープの「グローバル」を選択します。
c. グループの種類の「セキュリティ」を選択します。
d. 「OK」をクリックします。
新しいグループが、コンソールの右側ペインのオブジェクト・リストに表示されます。
6. オブジェクトのリストで、作成したグループをダブルクリックします。グループ・プロパティ・ダイアログ・ボックスが表示されます。
7. グループ・プロパティ・ダイアログで、次の手順を実行します。
a. 「メンバー」タブを選択します。
b. 「追加」をクリックします。
c. 表示されるダイアログ・ボックスで、次の手順を実行します。
i. ターゲット・ユーザー名を入力し、「名前の確認」をクリックしてユーザー名を確認します。エラーを受け取った場合、スペルミスがあれば修正し「名前の確認」を再びクリックします。
ii. ユーザーの名前が検証されたら「OK」をクリックします。
d. グループに含む追加ユーザーごとに手順7bおよび7cを繰り返します。
e. 必要なユーザーをグループに追加したら、「OK」をクリックしてグループ・プロパティ・ダイアログ・ボックスを閉じます。
8. 手順4から7を繰り返して、SSOUsersグループを作成して構成します。
Oracle Internet DirectoryでLogon Managerを使用するには、次のようにOracle Internet Directoryで匿名バインディングを有効にし、アクセス制御チェック機能を無効にします。
・ ブラウザを起動し、Oracle Directory Services Managerを開きます。
・ スーパー・ユーザーorcladminとしてログオンします。
・ 「ディレクトリに接続」をクリックしてターゲット・インスタンスを選択します。
・ 「データ・ブラウザ」タブをクリックします。
・ 次の場所にナビゲートします: cn=oid1,cn=osdldapd,cn=subconfigsubentry
orclanonymousbindsflagの値を2から1に変更し、「適用」をクリックします。
・ アクセス制御チェックの有効化機能を無効にします。
a. Oracle Enterprise Manager Fusion Middleware Controlアプリケーションで、ターゲットのOracle Internet Directoryインスタンスを見つけます。
b. 「Oracle Internet Directory」メニューから、「管理」a「サーバー・プロパティ」を選択します。
c. 「サーバー・プロパティ」画面で、「アクセス制御チェックの有効化」オプションを無効にします。
d. 「適用」をクリックします。
Oracle Virtual DirectoryでLogon Managerを使用するには、次のようにOracle Internet Directoryで匿名バインディングを有効にし、アクセス制御チェック機能を無効にします。
・ すべてのLDAPサーバーのユーザー・コンテナをOracle Virtual Directoryディレクトリ情報ツリーの同じサブツリーにマップします。たとえば、同じOVDインスタンスにマップされたDSEEおよびOIDサーバーの正しいレイアウトは次のとおりです。
・ ou=dsee,ou=users,dc=corp,dc=com (Oracle DSEEユーザー・エントリ用)
・ ou=oid,ou=users,dc=corp,dc=com (OIDユーザー・エントリ用)
これにより、Logon Managerのロケータ・ベースのユーザー検索メカニズムが、異なるサーバー上のユーザーを検索できるようになります。
・ マップされたLDAPサーバーで匿名バインディングが有効であることを確認します。ユーザー・リスト・エントリに対する
検索権限を匿名ユーザーに付与します。
・ アクセス制御チェックの有効化機能を無効にします。
a. Oracle Enterprise Manager Fusion Middleware Controlアプリケーションで、ターゲットのOracle Virtual Directoryインスタンスを見つけます。
b. 「Oracle Virtual Directory」メニューから、「管理」a「サーバー・プロパティ」を選択します。
c. 「サーバー・プロパティ」画面で、「アクセス制御チェックの有効化」オプションを無効にします。
d. 「適用」をクリックします。