1. Oracle Access Management管理者ガイド
  2. 他の製品とAccess Managerとの統合
  3. Windowsネイティブ認証のためのAccess Managerの構成

40 Windowsネイティブ認証のためのAccess Managerの構成

Access Managerでは、ブラウザ・ユーザーが各自のデスクトップ資格証明を使用して自動的にWebベースのシングル・サインオン・アプリケーションへの認証を行うように設定できます。これはWindowsネイティブ認証(WNA).と呼ばれています。

この章には、Active Directoryを使用して環境を準備し、この統合を実行する方法を説明する次の項が含まれています。

40.1 Access ManagerとWindowsネイティブ認証の概要

Access Managerは、Windowsネイティブ認証(WNA)とのActive Directoryのマルチドメインおよびマルチフォレスト・トポロジ統合をサポートします。

Active Directoryのディレクトリ・サービスでは、オブジェクト(ユーザー、グループ、コンピュータ、ドメイン、組織単位およびセキュリティ・ポリシー)に関する情報にデータ・ストア(ディレクトリと呼ばれる)を使用します。

関連項目:

Oracle Identity and Access Managementのシステム要件とサポート対象プラットフォーム: https://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

統合では、アプリケーションをAccess Manager認証ポリシーによって保護する必要があり、このポリシーでは、Kerberos認証スキーム(KerberosScheme)と、KerberosPlugin認証モジュールを使用したチャレンジ・メソッドとしてのWNAを組み合せて使用します。この場合は、ユーザー・アイデンティティ・ストアとしてAccess Managerに登録されたWindows Active Directoryインスタンスに、資格証明を保存する必要があります。

保護されるリソースそれぞれをアプリケーション・ドメイン内に定義します。認証ポリシーには、デフォルトのユーザー・アイデンティティ・ストアに関連付けられている認証モジュール(Kerberos)を使用する認証スキーム(KerberosScheme)が含まれています。このストアは、認証に「ユーザー名属性」の値を使用します。この値は、特定のAccess Managerリリースに応じて、Active Directoryのユーザーおよびuserprincipalname = username@domianまたはSamAccountName = usernameの値に関連付けられています。

Access Managerシングル・サインオンをWNAと組み合せると、ユーザーのログイン資格証明などが含まれたKerberosセッション・チケットが生成されます。このKerberosセッション・チケットはユーザーには表示されません。

Access Managerは、ユーザーがWindowsドメインにログインしたときに取得するKerberos資格証明を使用して、WNAと相互運用します。このクロス・プラットフォーム認証は、Kerberosプロトコルを使用するWindows間のネイティブ認証サービスのネゴシエーション動作をエミュレートすることによって実現します。このクロス・プラットフォーム認証を機能させるため、OAMサーバーは、SPNEGOトークンを解析して、認証に使用されるKerberosトークンを抽出する必要があります。

  • SPNEGOは、考えられる多数の実際のメカニズムの1つをネゴシエートするために使用されるGSSAPI (Generic Security Services Application Programming Interface)「擬似メカニズム」です。SPNEGOは、これを使用してイニシエータおよびアクセプタでKerberosメカニズムまたはNTLMSSPメカニズムのいずれかをネゴシエートできるようにするMicrosoftの「HTTPネゴシエート」認証拡張子でよく使用されます。GSSAPI実装は、ほとんどの主なKerberosの配布に含まれています。

    SPNEGOの詳細は、http://tools.ietf.org/html/rfc4559を参照してください。

  • Kerberosは、秘密キー暗号化を使用してクライアント/サーバー・アプリケーションおよびサービスに強力な認証を提供するネットワーク認証プロトコルです。Kerberosプロトコルの無料実装は、マサチューセッツ工科大学から入手でき、また市販されています。

参照:

40.1.1 Access Manager WNAログインおよびフォール・バック認証の理解

WNAを実装すると、Kerberosセッション・チケットがブラウザを介してOAMサーバーに渡されるので、ユーザーは別の資格証明のチャレンジなしに、Webアプリケーションを開くことができます。

OAMサーバーは、受信したトークンを(キー・タブを使用して)復号化し、そこから認証済ユーザーの名前を取得します。認証が成功した場合、ユーザーは自動的にWebアプリケーションへのアクセスを許可されます。

関連項目:

Oracle Identity and Access Managementのサポート対象ブラウザおよびサポート対象プラットフォーム: https://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

次の項では、2つのWNAログイン・シナリオのプロセスの概要を示します。

40.1.1.1 Access Manager WNA認証の成功

  1. ブラウザは、統合Windows認証(IWA)用に構成されます。

    これはブラウザのセキュリティ構成です。ブラウザが統合Windows認証を使用するように構成されていない場合、Kerberos認証モジュールによって保護されたリソースが要求されたときに、TGTは提供されません。ブラウザのBasic認証ウィンドウが表示され、このウィンドウで、デフォルトのアイデンティティ・ストアでUser login attributeに対して定義されている有効なユーザー名/パスワードの組合せを入力できます。

  2. Access ManagerおよびWNAによって保護されるリソースが呼び出されます。

    保護されたリソースは、イントラネット・リソースとして構成する必要があります。これは、ブラウザ設定の「ローカル・イントラネット」ゾーンにサイトを追加することによって行われます。

  3. 有効なKerberosチケットが表示されます: Http headers... Authorization: Negotiate YIIJ/...

  4. ユーザーは、認証に関してチャレンジされません。リクエストしたリソースが表示され、WNAが機能することが証明されます。

つまり、ブラウザが統合Windows認証を使用するように構成されていて、リソースがKerberos認証モジュールで保護されている場合は、次のようになります。

  • KerberosチケットをAccess Manager(ドメインにかかわりなく)が受け取ると、認証が試行されます。

    • 成功: アクセスが付与されます。

    • 失敗: Kerberosチケットの情報が提示されないかまたはデフォルトのユーザー・アイデンティティ・ストアで定義したユーザー名属性の値と一致しない場合、「不適切なユーザー名またはパスワード。」エラーが表示されます。アクセスは拒否されます。ブラウザはチケットを自動的に送信して、Access Managerとの相互作用はユーザーがロックアウトされるまで繰り返されます。ブラウザは、各交換の開始前に一時停止できません。

  • ユーザーがKerberos認証によってWindowsドメインにログオンされない場合、ブラウザはOAMに認証のためにKerberosトークンではなくNTLMトークンを送信します。Access Managerの構成方法によって、NTLMトークンの受信時にWNAフォールバック認証が使用されるか、認証が失敗します。

    ノート:

    ブラウザがNTLMトークンを送信したときにフォールバック認証を提供するようにAccess Managerを構成する必要があります。構成しないと、認証は失敗します。構成ステップについては、「WNAのNTLMフォールバックの構成」を参照してください。

    NTLMSSPは、すべてのバージョンのDCOM (Distributed Component Object Model)で使用できるセキュリティ・サポート・プロバイダです。これは、認証中にユーザーのパスワードをサーバーに実際には渡さない認証にNTLMプロトコルを使用します。

ノート:

KerberosチケットがAccess Manager(ブラウザ、オペレーティング・システム、ドメイン・ログインなどには関係ない)によって識別できない場合、フォールバック・メカニズムが呼び出されます。

40.1.1.2 Access Manager WNAフォールバック認証

フォールバックは、「基本」のチャレンジ・メソッドを使用した認証スキーム「BasicScheme」および認証モジュール「LDAP」を使用します。

このLDAP認証モジュールは、LDAPプラグインを使用します。このプラグインでは、ユーザー・アイデンティティ・ストアを、ユーザー名属性に使用する属性を定義する、現在登録されている任意のユーザー・アイデンティティ・ストアとして定義できます。この認証モジュールは、コンソールを使用して変更できます。

  1. ブラウザは、統合Windows認証(IWA)用に構成されます。

    これはブラウザのセキュリティ構成です。Access Managerは、2種類のWNAフォールバック認証を処理します。

    • IWAが有効なドメイン内: OAMは、SPNEGOトークンのWNAをサポートします。しかし、構成または他の問題により、OAMはSPNEGOではなく、NTLMトークンをクライアントから受け取ります。デフォルトのフロー中に、OAMはNTLMトークンを使用して認証を試みますが、OAMにはNTLMトークンを認証する機能がないので失敗します。したがって、HandleNTLMResponse構成の導入により、OAMサーバーは基本認証のプロンプトでクライアントにチャレンジします。すなわち、ここでのフォールバックは、クライアントがOAMサーバーにNTLM認証を送信している場合、認証の基本モードのプロンプトを表示することです。詳細は、「WNAのNTLMフォールバックの構成」を参照してください。

    • IWAが無効なドメイン外: ここでは、追加の構成は必要ではありません。デフォルトで、OOTBユーザーには認証時にBASICプロンプトが表示されます。

  2. Access ManagerおよびWNAによって保護されるリソースが呼び出されます。

    保護されたリソースは、イントラネット・リソースとして構成する必要があります。これは、ブラウザ設定の「ローカル・イントラネット」ゾーンにサイトを追加することによって行われます。

  3. チケットは表示されません(NTLM/Kerberos) - Http headers... Authorization: Basic

  4. 基本認証ウィンドウのポップアップが表示されます。

  5. ユーザーは有効なユーザー名/パスワードを入力します。

  6. リクエストしたリソースが表示されます(WNAフォールバックが機能します)。

40.1.2 サポートされるKerberos認証モジュール

Windowsネイティブ認証のAccess Managerを構成する場合は、Kerberos認証モジュールまたはKerberosPlugin認証モジュールを使用します。Kerberos認証モジュールは、キー・タブ・ファイルおよびkrb5構成ファイルの名前およびプリンシパルを識別します。

KerberosPlugin認証モジュールは、同梱のプラグイン(またはAccess Manager認証拡張機能Java APIを使用して開発されたプラグイン)に依存しています。このモジュールでは、複数のプラグインが使用され、各プラグインが特定の認証機能を実行できるように編成できます。KerberosPlugin認証モジュールは、Kerberos認証モジュールよりも堅牢で豊富な機能を持ちます。KerberosPlugin認証モジュールは(プレーンWNA構成とともに)、次のアプローチをサポートします。

  • Oracle Virtual Directoryを使用したKerberosプラグイン: Oracle Virtual Directoryと統合された、編成された認証プラグインとともにAccess Managerを使用すると、複数のActive Directoryグローバル・カタログが仮想化されます

  • 複数のADGC間で検索フェイルオーバーを使用するKerberosプラグイン: Access Managerを編成された認証プラグインとともに使用します。このプラグインは、複数のActive Directoryグローバル・カタログ間でフェイルオーバー・パターンを実行します。

関連項目:

40.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)が存在するとします。

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

  • フォレスト間: 双方向、非推移的な信頼。

  • 子ドメインとその親の間: 双方向、推移的な信頼。

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

  • SPRITEユーザーには、sun.comやjava.comなどのUPN接尾辞があります。SPRITEフォレストにはtestuser.java.comが含まれています。

  • ORACLEユーザーには、myoracleco.comやoracleco.comなどの接尾辞が付きます。ORACLEフォレストにはtestuser.oracleco.comが含まれています。

  • ORACLEの子ドメインは、親ドメインのUPN接尾辞を継承します。

ノート:

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)、次の提供されたステップに従う必要があります。

  • OAMサーバーのアカウントの作成。

  • Active Directoryマルチドメインまたはマルチフォレスト・トポロジおよび信頼関係で構成されたkeytabファイルの抽出。

  • OAMサーバー(またはOAMクラスタを表すロード・バランサ)の完全修飾ホスト名にレルム名を付加したサービス・プリンシパル名(SPN)の指定。

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

表40-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ホスト名と同じです。

oam12c.example.com

OAMサーバー・ホスト名

LM.EXAMPLE.COM

LMSIB.SPRITE.COM

デフォルトのActive Directoryレルム

2つ目のActive Directoryレルム

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

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

HTTP/fully_qualified_OAMServerhostname@REALM_NAME (大文字)

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

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

40.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サーバー・ホスト名を記録します。たとえば: 

    oam12c.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/oam12c.example.com@lm.example.com -mapuser oam -pass 
examplepw -out c:\temp\oam.keytab

C:\Users\Administrator>ktpass -princ HTTP/oam12c.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/oam12c.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/oam12c.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/oam12c.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/oam12c.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/oam12c.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を機能できないことを示します。

40.3 Access Manager操作の確認

完全に機能するAccess Managerのデプロイメントが必要です。

この項のタスクは、選択する方法に関係なく必要です。この手順では、アプリケーション・ドメインを構成してリソースを保護するWebGateをインストールして登録します。そして、環境がKerberos以外の認証スキームで機能していることを確認します。

関連項目:

2つ以上の管理対象サーバーがクラスタとして動作するように構成された高可用性環境の詳細は、『高可用性ガイド』の高可用性環境の作成に関する項

  1. 管理者の資格証明を使用して、Oracle Access Managementコンソールにログインします。
  2. デフォルト・アイデンティティ・ストアの接続を確認します。
  3. WebゲートをOAMエージェントとして登録およびインストールし、自動ポリシー生成を受け入れます。
  4. リソースをアプリケーション・ドメインに追加し、リソースを保護する認証ポリシーをKerberos以外の任意の認証スキームを使用するようにカスタマイズします。
  5. 構成をテストし、リソース保護およびアクセスが期待どおりに機能することを確認します。
  6. 「Kerberosトークンを返すためのブラウザの有効化」に進みます。

40.4 Kerberosトークンを返すためのブラウザの有効化

Kerberosトークンを返すように、Internet Explorer、Mozilla Firefox、EdgeまたはChromeを構成できます。

すべてのActive Directoryサーバーで適切な手順を実行します。次のいずれかの手順を使用して、ブラウザを構成します。

ノート:

Internet Explorerブラウザでは、統合Windows認証はデフォルトで有効になっており、WNAを機能させるためにデフォルト構成を変更する必要はありません。

40.4.1 Internet ExplorerのKerberosトークンの有効化

Internet ExplorerでKerberosトークンを有効にできます。

Kerberosトークンを有効にするには、次のようにします。

  1. Active Directoryドメイン内のWindowsホストに、ドメイン・ユーザーとしてサインインします。
  2. Internet Explorerブラウザを開きます。
  3. 「ツール」メニューから「インターネット オプション」をクリックし、「セキュリティ」→「ローカル イントラネット」→「詳細設定」をクリックします。
  4. 「詳細設定」タブで、「セキュリティ」セクションの「統合Windows認証を使用する」の横にあるボックスを選択して「OK」をクリックします。
  5. Oracle Access Manager CCホストまたはドメイン名をローカル・イントラネット・ゾーンに追加します(http://node.host:portの形式を使用(portは必須ではない))。たとえば:
    http://oam12c.example.com
  6. Internet Explorerブラウザを再起動して、変更を有効にします。

40.4.2 Mozilla FirefoxのKerberosトークンの有効化

Mozilla FirefoxでKerberosトークンを有効にできます。

Kerberosトークンを有効にするには、次のようにします。

  1. ブラウザのアドレス・バーに、about:configと入力します。
  2. Oracle Access Manager CCホストまたはドメイン名をnetwork.negotiate-auth.trusted-urisの下にnetwork.negotiate-auth.trusted-uris=http://oam12c.example.comとして追加します。

    複数のURIはカンマで区切られています。

40.4.3 EdgeまたはChromeのKerberosトークンの有効化

EdgeまたはChromeブラウザでKerberosトークンを有効にできます。

Kerberosトークンを有効にするには、次のようにします。

  1. Active Directoryドメイン内のWindowsホストに、ドメイン・ユーザーとしてサインインします。
  2. 「コントロール パネル」を開きます。
  3. 「ネットワークとインターネット」オプションを選択し、「インターネット オプション」をクリックし、「セキュリティ」→「ローカル イントラネット」→「詳細設定」をクリックします。
  4. 「詳細設定」タブで、「セキュリティ」セクションの「統合Windows認証を使用する」の横にあるボックスを選択して「OK」をクリックします。
  5. Oracle Access Manager CCホストまたはドメイン名をローカル・イントラネット・ゾーンに追加します(http://node.host:portの形式を使用(portは必須ではない))。たとえば:
    http://oam12c.example.com
  6. EdgeまたはChromeブラウザを再起動して、変更を有効にします。

40.5 KerberosPluginとOracle Virtual Directoryの統合

Oracle Virtual Directoryを使用すると、インフラストラクチャとアプリケーションのいずれかを変更する必要性を最小限に抑えるか、またはその必要性をなくして、LDAPを認識するアプリケーションを多様なディレクトリ環境に統合できます。

この項では、Oracle Virtual Directoryを使用したWNAのためのAccess Manager KerberosPlugin認証を構成するために実行する必要があるタスクについて説明します。

  1. この項では次のタスクを実行します。
  2. Windowsネイティブ認証のためのAccess Managerの構成
  3. Kerberosトークンを返すためのブラウザの有効化
  4. Access Managerによって保護されたリソースでのWNAの検証

40.5.1 統合のためのOracle Virtual Directoryの準備

Oracle Virtual Directoryは、アダプタを経由して他のディレクトリと通信します。Oracle Virtual Directoryをアイデンティティ・ストアとして使用し始める前に、使用するディレクトリそれぞれへのアダプタを作成する必要があります。

その手順は、接続先のディレクトリに応じて若干異なります。Oracle Internet Directory、Active Directory、Oracle Directory Server Enterprise Edition (ODSEE)またはOracle Unified Directoryの使用を選択すると、Oracle Identity Managementサーバーのインストールおよび構成時に、必要なアダプタが作成され、構成されます。アダプタの管理の詳細は、『Oracle Identity Management Suite統合ガイド』のIdentity Virtualization Library (libOVD)アダプタの管理に関する項を参照してください。

次の手順では、信頼できるドメインでOAMサーバーのアカウントを作成します。また、完全修飾ドメイン名をネームスペースとして使用して、2つのActive Directoryアダプタ(フォレストごとに1つ)を作成します。デフォルトでは、Active Directoryはdcを使用して、ルート・コンテキスト識別名を構築します。これが使用中のデプロイメントで異なる場合、それに合わせてアダプタ・ネームスペースを調整します。

  1. 「Access Manager操作の確認」に記載されたタスクを実行します。

  2. Oracle Identity and Access Managementのインストールおよび構成の説明に従って、Oracle Virtual Directoryをインストールします。

  3. Oracle Virtual Directoryコンソールで、次のように完全修飾ドメイン名をネームスペースとして使用して、2つのActive Directoryアダプタ(フォレストごとに1つ)を作成します。

    1. アダプタ1、EXAMPLEアダプタ・ネームスペース(ドメインDNS lm.example.com): 

      dc=lm,dc=example,dc=com

    2. アダプタ2、SPRITEアダプタ・ネームスペース(ドメインDNS lmsib.sprite.com): 

      dc=lmsib,dc=sprite,dc=com

  4. OAMクラスタをシャットダウンします。

  5. AdminServerおよびすべてのOAMサーバーを再起動します。

  6. 「WNAのデフォルト・ストアとしてのOracle Virtual Directoryの登録」に進みます。

40.5.2 WNAのデフォルト・ストアとしてのOracle Virtual Directoryの登録

有効なOracle Access Management管理者の資格証明を持つユーザーは、Windowsネイティブ認証と相互運用するAccess Managerのユーザー・ストアとしてOracle Virtual Directoryを登録できます。

Windowsネイティブ認証の場合、ユーザー資格証明はMicrosoft Active Directoryにある必要があります。Access Directoryは、Oracle Virtual Directoryインスタンスで管理できます。Access Managerによるシングル・サインオンの場合、各ユーザー・アイデンティティ・ストアを登録して、Access Managerと連動する必要があります。

通常、userprincipalnameは、Windowsログイン名を反映します。Access ManagerによるWNAの場合、ユーザー検索ベースおよびグループ検索ベースを空白のままにするかまたは前提条件となるタスクを実行中に構成した両方のアダプタに共通の識別名パスを入力します。開始する前に、「Active DirectoryおよびKerberosのトポロジの準備について」および「Access Manager操作の確認」の各項を完了してください。

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「構成」をクリックします。
  2. 「ユーザー・アイデンティティ・ストア」をクリックします。
  3. 「OAM IDストア」セクションで、「作成」をクリックします。
  4. Oracle Virtual Directoryインスタンスについての必要な値を入力します。たとえば:
    • 名前: OVD
    • LDAP URL: ldap://ovd_host.domain.com:389
    • プリンシパル: cn=Administrator,cn=users,dc=lm,dc=example,dc=com
    • 資格証明: ********
    • ユーザー検索ベース: dc=com
    • ユーザー名属性: userprincipalname
    • グループ名: cn
    • グループ検索ベース: dc=com
    • LDAPプロバイダ: Oracle Virtual Directory
  5. デフォルト・ストア: 「デフォルト・ストア」ボタンをクリックし、これをAccess Managerのユーザー・アイデンティティ・ストアにします。
  6. 「適用」をクリックして登録を送信し、「確認」ウィンドウを閉じます。
  7. AdminServerおよびOAMサーバーを再起動します。
  8. 「Access Manager KerberosPluginおよびOVDを使用した認証の設定」に進みます。

40.5.3 Access Manager KerberosPluginおよびOVDを使用した認証の設定

ネイティブ認証モジュールから必要とする十分な柔軟性が提供されない場合、特定の要求を満たすために設計されたプラグインを使用してカスタム認証モジュールを作成できます。

KerberosPluginは、リソースをリクエストするユーザーの資格証明(Kerberosチケット(SPNEGOトークン)の暗号化されたユーザー名)と一致する資格証明マッピング・モジュールです。デフォルトでは、KerberosPluginは、dcコンポーネントを使用してドメインDNS名を対応する識別名にマップします。ただし、マッピングが異なる場合、名前:値のトークンのセミコロン(;)で区切られたリストとして正しいマッピングを指定できます。たとえば: 

LM.EXAMPLE.COM:dc=lm,dc=example,dc=com;LMSIB.SPRITE.COM:dc=lmsib,dc=sprite,dc=com

有効なOracle Access Management管理者の資格証明を持つユーザーは、次のタスクを実行して、Oracle Access Managementコンソールを使用してデフォルトのKerberosPluginのステップをWindowsネイティブ認証の統合を有効にするステップと置き換えることができます。

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。

  2. 「プラグイン」セクションで、「認証モジュール」をクリックします。

  3. 「検索」をクリックし、KerberosPluginプラグインを見つけて編集のために開きます。

  4. KerberosPluginページで、「ステップ」タブをクリックします。

    「ステップ」タブ: ここの説明に従ってstepKTAを置き換えて、「保存」をクリックします。

    1. stepKTAをクリックしてから「削除」(x)ボタンをクリックしてこのステップを削除します。

    2. 「追加」(+)ボタンをクリックして、次のステップをプラグインに追加します。

      要素 説明

      名前

      stepKTA

      クラス

      KerberosTokenAuthenticator

    ステップの詳細:

    この新しいstepKTAを編集してステップ編成値をNULL (ステップ削除時に定義済)から次のデフォルト値に変更します。 

    On Success: StepUIF Failure Failure

    また、この新しいstepKTAにパラメータKEY_DOMAIN_DNS2DN_MAP(以前作成)が含まれていることを確認し、デプロイメントに適切な値を入力し、「保存」をクリックします。

    要素 説明

    KEY_DOMAIN_DNS2DN_MAP

    デプロイメントのActive Directoryフォレスト。たとえば:

    LM.EXAMPLE.COM:dc=lm,dc=example,dc=com;LMSIB.SPRITE.COM:dc=lmsib,dc=sprite,dc=com

    ノート: デフォルトでは、DNドメイン名a.b.cは、dc=a、dc=b、dc=cにマップされます。マッピングが異なる場合のみパラメータを指定する必要があります。そうでなければ、これを使用せずデフォルトの動作のままにすることが最善です。

    サービス・プリンシパル

    HTTP/oam12c.example.com@LM.EXAMPLE.COM

    keytab.conf

    stepKTAのkeytab.confの場所

    krb5.conf

    stepKTAのkrb5.confの場所

  5. stepUIFの詳細: 次のように構成し、「保存」をクリックします。

    要素 説明

    KEY_LDAP_FILTER

    (samAccountName={KEY_USERNAME})

    KEY_IDENTITY_STORE_REF

    OVD

    KEY_SEARCHBASE_URL

    ここは空のままにします

  6. stepUIおよびstepUA: 次のように構成し、「保存」します。

    要素 説明

    KEY_IDENTITY_STORE_REF

    OVD

  7. 変更を保存します。

  8. OAMクラスタを再起動します。

  9. 「Windowsネイティブ認証のためのAccess Managerの構成」に進みます。

40.6 KerberosPluginと検索フェイルオーバーの統合

Oracle Virtual Directoryデプロイメントが実行不可能で、ユーザーを検索するときにある順序または階層に基づいて検索フェイルオーバーを実行することが許容される場合、Access Managerを構成できます。

  1. 次に示された前の項のタスクを完了します。
  2. この項では次のタスクを実行します。
  3. 「Windowsネイティブ認証のためのAccess Managerの構成」
  4. 「Access Managerによって保護されたリソースでのWNAの検証」

40.6.1 Microsoft Active DirectoryインスタンスのAccess Managerへの登録

有効なOracle Access Management管理者の資格証明を持つユーザーは、関連する検索ベースおよびネーミング属性を含む各Active Directoryグローバル・カタログ(ADGC)をOracle Access Management用の個々のユーザー・アイデンティティ・ストアとして登録できます。

Kerberosサービスをマップするユーザー・アカウント、それらのアカウントのサービス・プリンシパル名(SPN)、およびキー・タブ・ファイルを含む、完全に構成されたMicrosoft Active Directory認証サービスが設定されている必要があります。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護 11g リリース1 (10.3.3)』を参照してください。

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「構成」をクリックします。
  2. 「ユーザー・アイデンティティ・ストア」をクリックします。
  3. 「OAM IDストア」セクションで、「作成」をクリックします。
  4. 最初のADGCについての必要な値を入力します。たとえば:
    • 名前: ADGC1-EXAMPLE
    • LDAP URL: ldap://ADGC1_host.domain.com:389
    • プリンシパル: cn=Administrator,cn=users,dc=lm,dc=example,dc=com
    • 資格証明: ********
    • ユーザー検索ベース: dc=lm,dc=example,dc=com
    • ユーザー名属性: userprincipalname
    • グループ検索ベース: dc=lm,dc=example,dc=com
    • LDAPプロバイダ: AD
  5. デフォルト・ストア: 「デフォルト・ストア」ボタンをクリックします。
  6. 「適用」をクリックして変更を送信し、確認ウィンドウを閉じます。
  7. これらのステップを繰り返し、適切な検索ベースおよびネーミング属性を備えた2つ目のADGC (ADGC2-SPRITE)を追加します。
    • 名前: ADGC2-SPRITE
    • LDAP URL: ldap://ADGC2_host.domain.com:389
    • プリンシパル: cn=Administrator,cn=users,dc=lm,dc=example,dc=com
    • 資格証明: ********
    • ユーザー検索ベース: dc=lmsib,dc=example,dc=com
    • ユーザー名属性: userprincipalname
    • グループ検索ベース: dc=lmsib,dc=example,dc=com
    • LDAPプロバイダ: AD
  8. AdminServerおよびOAMサーバーを再起動します。
  9. 「ADGCでのKerberosPluginの設定」に進みます。

40.6.2 ADGCでのKerberosPluginの設定

ネイティブ認証モジュールから必要とする十分な柔軟性が提供されない場合、特定の要求を満たすために設計されたプラグインを使用してカスタム認証モジュールを作成できます。KerberosPluginはリソースを暗号化されたKerberosチケットにリクエストするユーザーの資格証明(ユーザー名およびパスワード)と一致する資格証明マッピング・モジュールです。デフォルトでは、KerberosPluginは、dcコンポーネントを使用してドメインDNS名を対応する識別名にマップします。

ただし、マッピングが異なる場合、名前:値のトークンのセミコロン(;)で区切られたリストとして正しいマッピングを指定できます。たとえば:

LM.EXAMPLE.COM:dc=lm,dc=example,dc=com;LMSIB.SPRITE.COM:dc=lmsib,dc=sprite,dc=com

有効なOracle Access Management管理者の資格証明を持つユーザーは、次のタスクを実行して、作成したADGCを指すステップでKerberosPluginのステップを置き換えるかまたは更新できます。これらは、その等価物と連動します(最初のステップでADGCが失敗した場合、2つ目のADGCが使用されます)。開始する前に、「Active DirectoryおよびKerberosのトポロジの準備について」および「Access Manager操作の確認」の各項を完了してください。

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。

  2. 「プラグイン」セクションで、「認証モジュール」をクリックします。

  3. 「検索」をクリックし、KerberosPluginプラグインを見つけて編集のために開きます。

  4. KerberosPluginページで、「ステップ」タブをクリックします。

    「ステップ」タブ: ここの説明に従ってstepKTAを置き換えて、「保存」をクリックします。

    1. stepKTAをクリックしてから「削除」(x)ボタンをクリックしてこのステップを削除します。

    2. 「追加」(+)ボタンをクリックして、次のステップをプラグインに追加します。

      要素 説明

      名前

      stepKTA

      クラス

      KerberosTokenAuthenticator

    新規stepKTAの詳細:

    この新しいstepKTAにパラメータKEY_DOMAIN_DNS2DN_MAP(以前作成)が含まれていることを確認し、デプロイメントの値を入力します。

    要素 説明

    KEY_DOMAIN_DNS2DN_MAP

    		 
    LM.EXAMPLE.COM:dc=lm,dc=example,dc=com;LMSIB.SPRITE.COM:dc=lmsib,dc=sprite,dc=com

    サービス・プリンシパル

    HTTP/oam12c.example.com@LM.EXAMPLE.COM

    keytab.conf

    stepKTAのkeytab.confの場所たとえば:

    /refresh/home/oam.keytab

    krb5.conf

    stepKTAのkrb5.confの場所

    /etc/krb5.conf

  5. stepUIF: ステップ詳細(次のように構成して保存):

    要素 説明

    KEY_IDENTITY_STORE_REF

    ADGC1-ORACLE

    KEY_SEARCHBASE_URL

    {KEY_USERDOMAIN}

    KEY_LDAP_FILTER

    (samAccountName={KEY_USERNAME}) ノート: 信用されていないマルチドメインActive Directory環境の場合、userPrincipalNameユーザー属性を使用します。

  6. stepUIおよびstepUA: ステップ詳細(これらのステップを構成して保存):

    要素 説明

    KEY_IDENTITY_STORE_REF

    ADGC1-ORACLE

  7. 変更を保存します。

  8. stepUIF2の追加: これは連動し、stepUIFが失敗した場合に実行されます。

    要素 説明

    KEY_IDENTITY_STORE_REF

    ADGC2-SPRITE

    KEY_SEARCHBASE_URL

    {KEY_USERDOMAIN}

    KEY_LDAP_FILTER

    (samAccountName={KEY_USERNAME}) ノート: 信用されていないマルチドメインActive Directory環境の場合、userPrincipalNameユーザー属性を使用します。

  9. stepUI2の追加: これは連動し、stepUIが失敗した場合に実行されます。

    要素 説明

    KEY_IDENTITY_STORE_REF

    ADGC2-SPRITE

  10. stepUA2の追加: これは、stepUI2が成功したときに実行されます。

    要素 説明

    KEY_IDENTITY_STORE_REF

    それぞれADGC1-EXAMPLEおよびADGC2-SPRITE

  11. ステップ詳細の追加: 「共通構成」、「プラグイン」、KerberosTokenAutheticator。

    デプロイの値を入力します。

    要素 説明

    keytab.conf

    stepKTAのkeytab.confの場所たとえば: /refresh/home/oam.keytab

    krb5.conf

    stepKTAのkrb5.confの場所たとえば: /etc/krb5.conf

  12. OAMクラスタを再起動します。

  13. 「Windowsネイティブ認証のためのAccess Managerの構成」に進みます。

40.7 Windowsネイティブ認証のためのAccess Managerの構成

Oracle Virtual Directoryを使用していてもグローバル・カタログを備えたActive Directoryを使用していても、この項は、ユーザーが実行できるステップを含む次のトピックを提供します。

40.7.1 Windowsネイティブ認証用の認証スキームの作成

有効なOracle Access Management管理者の資格証明を持つユーザーは、Windowsネイティブ認証用のアプリケーションを保護するポリシーで使用する認証スキームを定義できます。

開始する前に、次の項のいずれかを完了してください: 「KerberosPluginとOracle Virtual Directoryの統合」または「KerberosPluginと検索フェイルオーバーの統合」。

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
  2. 「Access Manager」セクションの「認証スキーム」をクリックします。
  3. 「検索」で、「名前」ボックスにKerberosSchemeと入力し、「検索」をクリックします。
  4. 検索結果で「KerberosScheme」をクリックして開きます。

    次の属性を設定(または確認)します。

    チャレンジ・メソッド: WNA

    認証モジュール: KerberosPlugin

  5. デプロイメントのKerberosSchemeの構成を終了します。
  6. 「適用」をクリックして、「確認」ウィンドウを閉じます。
  7. 「Windowsネイティブ認証のためのポリシーの構成」に進みます。

40.7.2 Windowsネイティブ認証のためのポリシーの構成

アプリケーション・ドメインおよびポリシーを編集(または作成)し、Windowsネイティブ認証のリソースを保護します。

開始する前に、「Windowsネイティブ認証用の認証スキームの作成」を完了してください。

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。

  2. 「Access Manager」セクションで、「アプリケーション・ドメイン」をクリックします。

  3. 「コンソールを使用したアプリケーション・ドメインの管理」の説明に従って、必要なアプリケーション・ドメインを開きます(または作成します)。

  4. リソース定義: 「ポリシー・リソース定義の追加および管理」の説明に従って、リソース定義をドメインに追加します。

  5. 認証ポリシー:

    1. 「認証ポリシー」ノードを開き、次の属性を含む必要な認証ポリシーを開きます(または作成します)。

      認証スキーム: KerbScheme。更新したKerberosPluginが含まれていることを確認します。

      認証スキームとしてKerbSchemeを選択し、更新したKerberosPluginが含まれていることを確認します。

    2. 「適用」をクリックして、「確認」ウィンドウを閉じます。

    3. 認証ポリシーのリソース: 『Oracle Access Management管理者ガイド』の説明に従って、リソースを認証ポリシーに追加します。

    4. 必要なレスポンスを加えて認証ポリシーを完了します。

  6. 認可ポリシー: 「特定のリソースの認可ポリシーの定義」の説明に従って、必要なレスポンスまたは条件を加えて認証ポリシーを完成します。

  7. 「Access Manager構成ファイルの確認」に進みます。

40.7.3 WNAのNTLMフォールバックの構成

NTLMトークンの受信時にWNAフォールバック認証を使用するようにAccess Managerを構成できます。

詳細は、「Access Manager WNAログインおよびフォール・バック認証の理解」を参照してください。

構成するには、次のようにします。

  1. OAM管理対象サーバーを停止します。

  2. 次のファイルを安全な場所にバックアップします。

    <WLS domain>/config/fmwconfig/oam-config.xml

  3. <WLS domain>/config/fmwconfig/oam-config.xmlを次のように変更します。

    1. 次の行を探します。

      <Setting Name="CredentialCollector" Type="htf:map">

    2. この行の後に、次の要素を追加します(まだ存在していない場合)。

      --------------------------------------------------------------------------
       <Setting Name="WNAOptions" Type="htf:map">
       <Setting Name="HandleNTLMResponse" Type="xsd:string">BASIC</Setting>
       </Setting>
 
--------------------------------------------------------------------------

      次のパラメータがすでに存在する場合:

      <Setting Name="HandleNTLMResponse" Type="xsd:string">DEFAULT</Setting>

      HandleNTLMResponseの値を、DEFAULTからBASICに変更します。たとえば: 

      <Setting Name="HandleNTLMResponse" Type="xsd:string">BASIC</Setting>

  4. OAMサーバー・プロセスを再起動します。

    ノート:

    トラブルシューティングの詳細は、「2つのBASIC認証のプロンプトが表示される」を参照してください。

40.7.4 FORMベース認証スキームへのWNAフォールバックの構成

OAM_WNA_OPT_OUTは、OAMサーバーによって設定されたホスト・スコープの暗号化Cookieの永続性です。このCookieは、Cookieを提示しているブラウザがWNA認証をサポートしていないときに、OAMサーバーがFORMベースの認証でユーザーにチャレンジすることを示しています。TRUEに設定すると、OAM_WNA_OPT_OUT Cookieにより、保護されたリソースが表示される前に、OAMが認証スキームをDEFAULTまたはBASICからFORMベースに変更します。
NTLMトークンの受信時に、OAMサーバーが他の認証メカニズムにフォールバックします。HandleNTLMResponseがBASICに設定されていると、OAMサーバーがBASIC認証スキームにフォールバックします。

FORMベース認証スキームへのWNAフォールバックは、認証前ルールの設定に依存しています。WNA FORMフォールバック・メカニズムをサポートするOAM_WNA_OPT_OUT cookieを確認する認証前ルールを作成してください。OAM_WNA_OPT_OUT cookieの値がTRUEに設定されている場合は、認証スキームがFORMベース認証に切り替えられます。

  1. データベースからoam-config.xmlファイルをエクスポートします。詳細は、「OAM構成の更新」を参照してください。

  2. このファイルを次のように編集します。

    <Setting Name="WNAOptions" Type="htf:map">
<Setting Name="HandleNTLMResponse" Type="xsd:string">FORM</Setting>
</Setting>

  3. NTLMおよびKerberos認証がブラウザ(ドメインにアタッチされていないブラウザなど)で機能しない場合は、OAMサーバーがレスポンスの本文に認証エラー(403)およびHTMLコンテンツを設定して応答します。OAMのデフォルトでは、「ログイン」ボタンがある認証エラー・ページが表示されます。ユーザーは、カスタマイズされたページの「ログイン」ボタンをクリックして、FORMベースの認証へのWNAのフォールバックを起動する必要があります。オプションで、CustomOptOutPageまたはIsOptOutPersistentパラメータをoam-config.xmlに構成して、エラー・ページをカスタマイズできます。

    1. oam-config.xmlファイルからすべてのHTMLコンテンツを生成するには、次のようにカスタム・オプト・アウト・ページを構成します。カスタマイズされたページのボタンがクリックされると、JavaScript関数optOut()が起動されます。次に、OAMがJavaScript関数optOut()を生成します。 

      <Setting Name="CustomOptOutPage" Type="xsd:string">/home/custom.html</Setting>
    2. OAM_WNA_OPT_OUT Cookieはデフォルトで永続Cookieとして設定されます。これを次のようにセッションCookieとして構成します。
      <Setting Name="IsOptOutPersistent" Type="xsd:boolean">false</Setting>
  4. oam-config.xmlをインポートします。詳細は、「OAM構成の更新」を参照してください。
  5. OAM_WNA_OPT_OUT cookieの値がTRUEに設定されており、認証前条件が次のように設定されているかどうかを確認します。
    str(request.requestMap['Cookie']).lower().find('oam_wna_opt_out=true') >= 0
  6. oam-config.xmlでenableWhiteListValidationがtrueに設定されている場合は、WNAで保護されたリソースのURLをホワイトリストURLセクションに定義する必要があります。

    ホワイトリストURLセクション内のWNAで保護されたすべてのリソースをホワイトリストに登録するというのは、膨大な作業です。次のパターンとワイルドカードを使用して、必要なエントリの数を減らすことができます:

    http://oamwna1.vm.oracle.com/printenv_ecc_wna.pl

    または

    http://oamwna1.vm.oracle.com

    または

    http://*.vm.oracle.co

    前述のオプションのいずれかを保護リソースとしてホワイトリストURLセクションに追加すると、サンプルoam-config.xmlファイルは次のようになります:
    <Setting Name="WhiteListURLs" Type="htf:map">
       <Setting Name="Wild-Domain" Type="xsd:string">http://*.vm.oracle.com</Setting>
   </Setting>

    ノート:

    • このステップを実行しない場合、WNAおよびWNAフォールバックからFORMへの認証は次のエラーで失敗します:

      システム・エラー。アクションを再試行してください。このエラーが続く場合は、管理者に連絡してください。

    • このエラーの詳細は、https://support.oracle.comで、Oracle Access Manager (OAM)のWindowsネイティブ認証(WNA)がシステム・エラーで失敗する(Doc ID 2815777.1)というドキュメントを参照してください。

  7. OAMサーバー・プロセスを再起動します。

OAMサーバーがFORMベース認証スキームでフォールバックします。

40.7.5 Access Manager構成ファイルの確認

Access Manager構成ファイルoam-config.xmlを確認できます。

次の例に示すように、oam-config.xmlファイルに次の情報が指定されていることを確認します。

  • krb5.confファイルへのパス

  • keytabファイルへのパス

  • KDCに接続するプリンシパル

oam-config.xml

<Setting Name="KerberosModules" Type="htf:map">
   <Setting Name="6DBSE52C" Type="htf:map">
      <Setting Name="principal"           Type="xsd:string">HTTP/oam12c.example.com@LM.EXAMPLE.COM
      </Setting>
      <Setting Name="name" Type="xsd:string">XYZKerberosModule</Setting>
      <Setting Name="keytabfile"           Type="xsd:string">/refresh/home/oam.keytab
      </Setting>
      <Setting Name="krbconfigfile" Type="xsd:string">/etc/krb5.conf</Setting>
   </Setting>
</Setting>

40.8 Access Managerによって保護されたリソースでのWNAの検証

統合Windows認証(IWA)は、特定のWindowsオペレーティング・システムに含まれているSPNEGO、KerberosおよびNTLMSSPの認証プロトコルを使用するMicrosoft製品と関連付けられています。

統合Windows認証(IWA)という用語は、Microsoft Internet Information Services、ブラウザおよびMicrosoftのActive Directoryの間で発生する自動認証プロセス用に使用されます。

ノート:

IWAは、HTTPネゴシエート認証、NT認証、NTLM認証、ドメイン認証、Windows統合認証、Windows NTチャレンジ/レスポンス認証、Windows認証など別の名前で呼ばれることもあります。

WNA認証は内部的に行われます。Access Managerと統合すると次のようになります。

  • ユーザーは、認証のためにAccess Managerにリダイレクトされます。

  • OAMサーバーは、リソースがWNAのチャレンジ・メソッドでAccess Managerによって保護されている場合、wwwネゴシエート・ヘッダーを使用した認証をリクエストします。

  • 統合Windows認証(IWA)用に構成されたブラウザは、Kerberos SPNEGOトークンを復号化するためにOAMサーバーに送信します。

  • OAMサーバーは、受信したユーザーSPNEGOトークンを復号化(キー・タブを使用)して、ユーザーをCookieとともにリダイレクトしてエージェントに戻し、リソースにアクセスできるようになります。

Access Managerによって保護されたリソースでのWNAを検証するには、この手順を使用します。

  1. Active Directoryドメイン内のWindowsシステムに、ドメイン・ユーザーとしてログインします。
  2. Access Managerに登録されたホスト対象のActive Directoryに保存されているWindowsドメイン資格証明を使用して、Windows OSクライアントにサインインします。
  3. ブラウザ・ウィンドウを開き、使用中の環境のOAMによって保護されたアプリケーションのURLを入力します。
  4. Windowsドメインの資格証明でアプリケーションにログインしていて、追加のログインがないことを確認します。

40.9 WNAをDCCとともに使用するための構成

Kerberos認証プロトコルは、セキュアなネットワーク接続が確立される前にエンティティ間で相互認証を行うためのメカニズムを提供します。

この項では、Access ManagerでDCCを使用するようWindowsネイティブ認証とKerberosを構成する方法について説明します。内容は次のとおりです。

ノート:

DCCの詳細は、「資格証明コレクションおよびログインの理解」を参照してください。

40.9.1 Kerberosプロトコルの初期化

Kerberosプロトコル用にAccess Managerを初期化できます。

初期化するには、次のようにします。

  1. Windowsデータ・ストアでktpassコマンドを実行し、サービス、レルム、ユーザーおよびユーザー・パスワードを該当する値で置き換えます。 
    ktpass -princ <SPN>@<REALM> -pass <Password> -mapuser <UserName> 
 -out <Keytab file name>

    たとえば:

    ktpass -princ HTTP/adc.example1.com@EXAMPLE.COM -pass Welcome1 -mapuser anil@example.com -out foobar2.keytab

    このコマンドはSPNを作成し、それを前のステップで作成したローカル・サービス・アカウントに関連付けます。

    ノート:

    RC4-HMAC暗号化のみがサポートされます。DES暗号化は使用しないでください。

  2. ktpassコマンドによって生成されたキータブ出力をコピーし、DCCホスト・マシン上の適切な場所に配置します。
  3. これに応じて、DCCホスト・マシン上の/etc/krb5.confファイルを変更します。

    たとえば:

    [loggings]
 default = FILE:/scratch/anikukum/krb/krb5libs.log
 kdc = FILE:/scratch/anikukum/krb/krb5kdc.log
 admin_server = FILE:/scratch/anikukum/krb/krbadmin.log

[libdefaults]
 default_realm = EXAMPLE.COM
 ticket_lifetime = 24h
 forwardable = yes
 dns_lookup_realm = false
 dns_lookup_kdc = false
 default_tkt_enctypes = rc4-hmac
 default_tgs_enctypes = rc4-hmac
 permitted_enctypes = rc4-hmac
 clockskew = 3600
 
[realms]
 EXAMPLE.COM = {
  kdc = adc.example1.com
  admin_server = adc.example1.com
  default_domain = EXAMPLE.COM
 }
 
[domain_realm]
example.com = EXAMPLE.COM.example.com = EXAMPLE.COM

    ノート:

    マルチドメインActive Directory環境の場合、次に示すように、ドメインごとにエントリを追加します。

    [realms]
 EXAMPLE.COM = {
  kdc = adc.example1.com
  admin_server = adc.example1.com
  default_domain = EXAMPLE.COM
 }
 
 SPRITE.COM = {
  kdc = lmsib.sprite.com
  admin_server = lmsib.sprite.com
  default_domain = SPRITE.COM
 }
 
[domain_realm]
example.com = EXAMPLE.COM
.example.com = EXAMPLE.COM
sprite.com = SPRITE.COM
.sprite.com = SPRITE.COM
  4. DCCホスト・マシンでkinitコマンドを実行し、Kerberosチケットを取得します。
    kinit  -k -t <keytab file>  <SPN>@<Realm>

    たとえば:

    kinit -k -t foobar1.keytab HTTP/adc.example1.com@EXAMPLE.COM
  5. klistコマンドを使用して、DCCホスト・マシン上のKerberosチケットを検証します。
    klist

40.9.2 Access Managerの構成

Kerberos認証モジュールを使用するようにAccess Managerを構成できます。

構成するには、次のようにします。

  1. Kerberos認証スキームのチャレンジ・メソッドをWNAに変更します(該当する場合)。

    1. Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。

    2. 「起動パッド」タブで、「Access Manager」セクションの「認証スキーム」をクリックします。

    3. KerberosSchemeを検索し、「編集」をクリックします。

    4. チャレンジ・リダイレクトURLを、DCC WebゲートのURLに変更します。

      たとえば、http://<DCC-WebGate-Hostname>:<Port>/

    5. 「適用」をクリックし、ページを閉じます。

  2. LDAP認証モジュールのユーザー・アイデンティティ・ストアを、構成済のWindowsデータ・ストアに構成します。

    1. Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。

    2. 「起動パッド」タブで、「Access Manager」セクションの「認証モジュール」をクリックします。

    3. LDAPを検索し、「編集」をクリックします。

    4. ユーザー・アイデンティティ・ストアを、たとえばActive Directoryなどに変更します。

    5. 「適用」をクリックし、ページを閉じます。

  3. Kerberos認証スキームを使用するように、リソースを保護するアプリケーション・ドメインを構成します。

    保護されたリソースにアクセスする前に、そのURLがローカル・イントラネットのセキュリティ・サイトに追加されていることを確認します。また、「詳細設定」タブで、「セキュリティ」下の「統合Windows認証の有効化」オプションを選択します。

40.10 WNA構成のトラブルシューティング

この項では、次のエラーについて説明します。

関連項目:

My Oracle SupportのAccess Manager WNAクイック・スタート・ガイドのナレッジベース・ノート1416903.1(https://support.oracle.com/)

40.10.1 Kinitの失敗

最初の資格証明の取得中に、Kerberosデータベースでクライアントが見つからない場合があります。

これは、「ユーザーが見つかりません」のKerberosバージョンであり、次のいずれかに関連している可能性があります。

  • プリンシパル名のミススペルまたはタイプミス

  • プリンシパルがKerberosデータベースに追加されなかったためにプリンシパルが存在しない。

  • ユーザー名がActive Directoryに存在しないまたはKerberosユーザーとして登録されなかった。

  • SPNが一意ではない。

  • Active Directory側で1つ以上の重複エントリが見つかった。

解決策は、Active Directory管理者がLDAPツリーのSPNの重複エントリを検索し、それらを削除することです。

40.10.2 「指定したユーザー名またはパスワードが正しくありません」と表示される

WNA認証スキームを使用してAccess Managerにより保護されたリソースにアクセスできない場合、エラー・メッセージが表示されます。

エラー・メッセージ「指定したユーザー名またはパスワードが正しくありません」が表示される場合は、次のことを確認します。

  • 「指定したユーザー名またはパスワードが正しくありません」

  • 使用されている暗号化タイプの不一致があります。

  • キータブに示されたSPNのキー・バージョン番号(kvno)が、アイデンティティ・ストアのマップされたユーザーのkvnoと一致しません。

40.10.3 ユーザー・アイデンティティ・ストアが正しく登録されていない

デフォルトでは、OAMのアイデンティティ・ストアは組込みLDAPです。別のアイデンティティ・ストア(Active DirectoryまたはOracle Unified Directoryなど)を使用する場合は、アイデンティティ・ストアを登録する必要があります。

アイデンティティ・ストアおよびそれらの登録方法の詳細は、「データ・ソースの管理」を参照してください。

40.10.4 2つのBASIC認証のプロンプトが表示される

OAMがWNA用に構成され、クライアント・ブラウザがIWA用に構成されていない場合、WNAの保護リソースにアクセスするときに、2つのBASIC認証プロンプトが表示されることがあります。

Weblogic Serverから1つのプロンプト、2番目はOAMからです。これを回避するには、HTTP基本認証要求を無視するようにWebLogic Serverを構成する必要があります。

  1. すべてのWebLogic管理対象サーバーおよび管理サーバーを停止します。
  2. config.xmlファイルのコピーを作成します。

    $WLS_DOMAIN/config/config.xml

  3. config.xmlファイルの<security-configuration>セクションの終わりに、次のパラメータを追加します。

    <enforce-valid-basic-auth-credentials>false</enforce-valid-basic-auth-credentials>

    このパラメータは、<cross-domain-security-enabled>false</cross-domain-security-enabled>パラメータの前に追加する必要があります。

  4. WebLogic環境を再起動します。