プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle Access Management管理者ガイド
11g リリース2 (11.1.2.3) for All Platforms
E61950-08
目次へ移動
目次
前
前 		次
次

57.2 Active DirectoryおよびKerberosのトポロジの準備について

完全に構成されたMicrosoft Active Directory認証サービス設定が必要です。Active DirectoryとKerberosクライアントが連動します。

この項のタスクは、選択する方法に関係なく必要です。ただし、これはOracle固有ではありません。

ノート:

次のサンプル・シナリオは、一般的なActive Directoryトポロジを表しています。Access Managerによって指示された要件でもAccess Manager用の要件でもありません。ここで使用される名前は単なる例です。環境はユーザーによって異なります。

サンプルのシナリオとして、企業内で動作する2つのActive Directoryフォレストについて検討します。

フォレスト ドメイン名

ORACLE

lm.example.com

SPRITE

lmsib.sprite.com

ORACLEフォレスト内に子ドメイン(child.lm.example.com)が存在するとします。

信頼は次のように要求されます。

接尾辞と継承は次のとおりです。

ノート:

DOMAIN\USERNAMEという形式の事前Windowsユーザー名はサポートされません。

WNAとの統合では、デフォルト・アイデンティティ・ストアに定義されているUser Name Attributeは、Active DirectoryユーザーのsamAccountNameの値と一致する属性にできます。

また、環境で使用する暗号化の種類を理解している必要があります。場合によっては、「このアカウントにDES暗号化タイプを使用する」を有効にしてユーザーを作成する場合があります。ただし、Active DirectoryはDES暗号化を使用しません。

ノート:

次の手順で作成するkeytabファイルはRC4-HMAC暗号化を使用します。

Access ManagerはJGSS/JDK6がサポートするものをサポートします。使用可能なTGT暗号化の制限事項は、サポートされる最も一般的でないまたは最下位の暗号化(KDC、Keytab、オペレーティング・システム、Kerberosクライアント)であるピースによって決まります。Access Managerは、どのKerberos暗号化タイプもサポートしません。これは、認定される汎用セキュリティ・サービス(GSS)/Kerberos jdk暗号化タイプによって決まります。Access Managerは、暗号化タイプに依存せず、TGT暗号化を使用しません。SPNEGOトークンの一部として、Access Managerは、ktpass/keytabコマンド実行時にサービス(ここではAccess Manager)が登録したキーで暗号化されたサービス・チケットのみを検索します。

ノート:

次の手順で作成するkeytabファイルはRC4-HMAC暗号化を使用します。

暗号化は、異なるOS (Kerberosサーバー/クライアントとして動作するWindows/Linux)の間の通信に使用されます。OAMサーバーは、ユーザーの資格証明の抽出元であるSPNEGOトークンのみを必要とします。Access Managerによって使用されるWindowsクライアント(ブラウザ)、Windows KDCおよび汎用セキュリティ・サービス(GSS)の各クラス間のこの3つの否定プロセスで使用される暗号化は、使用されるバージョンに依存します(これは一致する必要があります)。

関連項目:

Access ManagerがサポートするKerberos暗号化タイプの詳細のMy Oracle Support [Doc 1212906.1](https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1212906.1)

信頼できるドメインでは(たとえば、ルート・ドメインlm.example.com)、次の提供されたステップに従う必要があります。

この例では、表57-1の名前が使用されます。

表57-1 サンプル名

名前 説明

kdc.lm.example.com

KDCホスト名

KDCは、Active Directoryドメイン内のユーザーとコンピュータにセッション・チケットおよび一時セッション・キーを提供する、信頼できるネットワーク・サービスです。KDCは、Active Directoryドメイン・サービスの一部として各ドメイン・コントローラ上で実行され、ドメイン・サービスとして実装されます。KDCは、Active Directoryをアカウント・データベースとして使用します。Kerberosプロトコルの実装では、KDCは、2つのサービス(認証サービス(AS)とチケット付与サービス(TGS))を提供する単一プロセスです。

kdc.lm.example.com

AdminServerホスト名

これは、KDCホスト名と同じです。

oam11g.example.com

OAMサーバー・ホスト名

LM.EXAMPLE.COM

LMSIB.SPRITE.COM

デフォルトのActive Directoryレルム

2つ目のActive Directoryレルム

レルム名は、ユーザー・アカウントの場所を識別します。レルム名は、接頭辞または接尾辞のいずれかにできます。

アクセス・クライアントがユーザー資格証明を送信するとき、ユーザー名が含まれることが多いです。ユーザー名の中には2つのエレメント(ユーザー・アカウント名とユーザー・アカウントの場所)が入っています。

HTTP/fully_qualified_OAMServerhostname@REALM_NAME (大文字)

ユーザー・アカウント(クライアントがサービスのインスタンスを一意に識別する名前)にはサービス・プリンシパル名(SPN)が必要です。

ノート: フォレスト全体にわたってコンピュータにサービスのインスタンスを複数インストールする場合、各インスタンスに独自のサービス・プリンシパル名がある必要があります。

57.2.1 Active DirectoryおよびKerberosの準備

Active DirectoryおよびKerberosを準備できます。

コマンドは、Unixオペレーティング・システムに対応しています。コマンド構文は、環境内固有のオペレーティング・システムによって異なります。

  1. Oracle動作保証マトリックスを確認し、この統合に対してサポートされているバージョンのActive Directoryをインストールしていることを確認します。

    https://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

  2. 次のようにActive Directoryをインストールして構成します。

    • 次の必要な信頼関係を備えたマルチフォレスト・トポロジが構成されていて動作する

      a.Kerberosサービスをマップするユーザー・アカウント

      b.これらのユーザー・アカウント(クライアントがサービスのインスタンスを一意に識別する名前)のサービス・プリンシパル名(SPN)。

      c.キー・タブ・ファイル

    • Active Directoryグローバル・カタログ(ADGC)が各フォレスト内で有効になっていて動作する

    • マルチフォレスト・デプロイメント: この場合、様々なフォレストに基づくユーザーを一意に識別するネーミング属性(グローバル・カタログ内にある)が存在することを確認します。一般的に、userprincipalnameはフォレストに対して一意で、samAccountNameはドメインに対して一意です。

    • フォレスト・アフィリエーションに関係なく、他のドメインそれぞれに直接的または間接的に信頼されている1つのドメイン。

  3. WNA認証中に使用するAccess Managerのユーザーを作成し、このユーザー名を記録してkeytabファイル(DES暗号化なし)を生成します。

  4. OAMサーバー・ホスト名を記録します。次に例を示します。

    oam11g.example.com

  5. KDCホスト名およびActive Directoryドメイン/レルムを記録します。

    KDC = kdc.lm.example.com
Default AD Realm = lm.example.com

  6. OAMサーバー・クライアントが使用しているActive Directoryユーザーのサービス・プリンシパル名(SPN)を作成し、その結果(暗号化タイプを含む)を記録します。

    このユーザー名は、user_name@example.comという形式にしてください(example.comはActive Directoryのドメイン名)。次に例を示します。

    ktpass -princ <protocol/oamserver_host> -pass <mypassword> -mapuser <user from step 3> -out <path_to_filename>

    ノート:

    ktpass、kinitおよびklistコマンドを使用してユーザー名を入力する際は、大文字小文字が一貫していることを確認してください。最初のコマンドの実行時に小文字でユーザー名を入力した場合は、残りのコマンドの実行時にも小文字で入力する必要があります。

    たとえば、keytabと構成を/etc/krb5.confファイルに作成するために、コマンドで使用する大文字小文字は一致している必要があります。keytab (後述)を作成するのにktpassが実行される場合、KDCサーバーのホスト名はlm.example.comになります。これはすべて小文字のため、/etc/krb5.confファイルの構成も小文字である必要があります。大文字小文字が一致しているかぎり、大文字と小文字の区別は問題になりません。

    ktpass -princ HTTP/oam11g.example.com@lm.example.com -mapuser oam -pass 
examplepw -out c:\temp\oam.keytab

C:\Users\Administrator>ktpass -princ HTTP/oam11g.example.com@LM.EXAMPLE.COM
-mapuser oam -pass welcome1 -out c:\temp\oam.keytab
Targeting domain controller: kdc.lm.example.com
Using legacy password setting method
Successfully mapped HTTP/oam11g.example.com to oam.
WARNING: pType and account type do not match. This might cause problems.
Key created.
Output keytab to c:\temp\oam.keytab:
Keytab version: 0x502
keysize 80 HTTP/oam11g.example.com@lm.example.com ptype 0 (KRB5_NT_
UNKNOWN) vno 3 etype 0x17 (RC4-HMAC) keylength 16 (0xa3a685f89364d4a
5182b028fbe79ac38)

    ノート:

    ユーザーが管理者グループに含まれていない場合、次の手順を実行して、ユーザーのリモート・デスクトップ接続を明示的に許可します。

    1. Oracle Access Managementコンソールから、「コントロール パネル」→「リモートの設定」→「システムのプロパティ」を選択して、「リモート」タブに移動します。

    2. 「リモート デスクトップを実行しているコンピュータからの接続を許可する」オプションを選択します。

    3. 「ユーザーの選択」をクリックします。

    4. ユーザーを追加します。

    5. 「適用」をクリックします。

  7. 新しく作成したkeytabファイルをOAMサーバーの適切な場所にコピーし、権限が正しいことを確認して、Access Managerを作成したユーザーがこのファイルにアクセスしてktpassコマンドを実行できるようします。

  8. 単純なOAMサーバーKerberosのkrb5.confまたはkrb5.ini構成を作成します。次に例を示します。

    [libdefaults]
default_realm = lm.example.com
ticket_lifetime = 600
clock_skew = 600

[realms]
lm.example.com = { -- 
kdc = kdc.lm.example.com
admin_server = kdc.lm.example.com 
default_domain = lm.example.com
}
[domain_realm] 
lm.example.com =LM.EXAMPLE.COM
.lm.example.com = LM.EXAMPLE.COM

    ノート:

    OAMアカウントは、すべてが信頼する1つのドメイン(lm.example.com)に作成します。これは、lmsib.sprite.comでは必要ありません。

  9. keytabファイルと作成したActive DirectoryおよびAccess ManagerのユーザーのSPNを使用して、klistおよびkinitsが機能することを確認し、その結果を記録します。

    1. kdestroy

    2. klist [-k] [-t <keytab_filename>]。次に例を示します。

      bash-3.2$ klist -k -t -K -e FILE:/refresh/home/oam.keytab
Keytab name: FILE:/refresh/home/oam.keytab
KVNO Timestamp Principal
---- ----------------- ---------------------------------------------------
3 12/31/69 19:00:00 HTTP/oam11g.example.com@lm.example.com (ArcFour 
with HMAC/md5)(0xa3a685f89364d4a5182b028fbe79ac38)
bash-3.2$

    3. kdestroy

    4. kinit [-k] [-t <keytab_filename>] [<principal>]。次に例を示します。

      klist -k -t -K -e FILE:/refresh/home/oam.keytab

bash-3.2$ kinit -V -k -t /refresh/home/oam.keytab 
HTTP/oam11g.example.com@lm.example.com
Authenticated to Kerberos v5

    5. klist -e

      bash-3.2$ klist -e
Ticket cache: FILE:/tmp/krb5cc_8000
Default principal: HTTP/oam11g.example.com@lm.example.com

Valid starting Expires Service principal
02/25/12 18:46:55 02/25/12 18:56:55 krbtgt/LM.EXAMPLE.COM@LM.EXAMPLE.COM
Etype (skey, tkt): ArcFour with HMAC/md5, AES-256 CTS mode with 96-bit 
SHA-1 HMAC

Kerberos 4 ticket cache: /tmp/tkt8000
klist: You have no tickets cached
bash-3.2$

  10. 次のように進めます。

    成功: 「Access Manager操作の確認」を続行します。

    不成功: 停止してこの統合と関係のない問題を解決します。この時点での失敗は、Access Manager WNAを機能できないことを示します。

57.2.1.1 クロスフォレスト信頼がないマルチフォレスト環境用のWNAの構成

フォレスト間で信頼関係が確立されていないときは、Kerberos認証モジュールではなくKerberosPluginを使用して、複数のフォレストまたはドメインに対してKerberos認証を構成してください。  

各フォレストには、OAMがWNAを使用して認証するために使用するサービス・プリンシパル名(SPN)を設定する必要があります。各フォレストに対してKTAプラグインを追加して、フォレストに対応するSPNを指定する必要があります。KTAプラグインに適切にフォールバックするように、各KTAプラグインの「ステップ・オーケストレーション」タブの失敗条件とエラー条件を変更します。成功条件を満たすと、指定されたSPNを使用して、特定のフォレストに対してKerberosトークンが検証されたことが保証されるようにします。

前
前 		次
次
目次へ移動
目次