49 Windowsネイティブ認証のためのAccess Managerの構成
Access Managerでは、ブラウザ・ユーザーが各自のデスクトップ資格証明を使用して自動的にWebベースのシングル・サインオン・アプリケーションへの認証を行うように設定できます。これはWindowsネイティブ認証(WNA).と呼ばれています。
この章には、Active Directoryを使用して環境を準備し、この統合を実行する方法を説明する次の項が含まれています。
49.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プロトコルの無料実装は、マサチューセッツ工科大学から入手でき、また市販されています。
参照:
49.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ログイン・シナリオのプロセスの概要を示します。
49.1.1.1 Access Manager WNA認証の成功
-
ブラウザは、統合Windows認証(IWA)用に構成されます。
これはブラウザのセキュリティ構成です。ブラウザが統合Windows認証を使用するように構成されていない場合、Kerberos認証モジュールによって保護されたリソースが要求されたときに、TGTは提供されません。ブラウザのBasic認証ウィンドウが表示され、このウィンドウで、デフォルトのアイデンティティ・ストアで
User login attribute
に対して定義されている有効なユーザー名/パスワードの組合せを入力できます。 -
Access ManagerおよびWNAによって保護されるリソースが呼び出されます。
保護されたリソースは、イントラネット・リソースとして構成する必要があります。これは、ブラウザ設定の「ローカル・イントラネット」ゾーンにサイトを追加することによって行われます。
-
有効なKerberosチケットが表示されます: Http headers... Authorization: Negotiate YIIJ/...
-
ユーザーは、認証に関してチャレンジされません。リクエストしたリソースが表示され、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(ブラウザ、オペレーティング・システム、ドメイン・ログインなどには関係ない)によって識別できない場合、フォールバック・メカニズムが呼び出されます。
49.1.1.2 Access Manager WNAフォールバック認証
フォールバックは、「基本」のチャレンジ・メソッドを使用した認証スキーム「BasicScheme」および認証モジュール「LDAP」を使用します。
このLDAP認証モジュールは、LDAPプラグインを使用します。このプラグインでは、ユーザー・アイデンティティ・ストアを、ユーザー名属性に使用する属性を定義する、現在登録されている任意のユーザー・アイデンティティ・ストアとして定義できます。この認証モジュールは、コンソールを使用して変更できます。
-
ブラウザは、統合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プロンプトが表示されます。
-
-
Access ManagerおよびWNAによって保護されるリソースが呼び出されます。
保護されたリソースは、イントラネット・リソースとして構成する必要があります。これは、ブラウザ設定の「ローカル・イントラネット」ゾーンにサイトを追加することによって行われます。
-
チケットは表示されません(NTLM/Kerberos) - Http headers... Authorization: Basic
-
基本認証ウィンドウのポップアップが表示されます。
-
ユーザーは有効なユーザー名/パスワードを入力します。
-
リクエストしたリソースが表示されます(WNAフォールバックが機能します)。
49.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グローバル・カタログ間でフェイルオーバー・パターンを実行します。
49.2 Active DirectoryおよびKerberosのトポロジの準備について
この項のタスクは、選択する方法に関係なく必要です。ただし、これはOracle固有ではありません。
ノート:
次のサンプル・シナリオは、一般的なActive Directoryトポロジを表しています。Access Managerによって指示された要件でもAccess Manager用の要件でもありません。ここで使用される名前は単なる例です。環境はユーザーによって異なります。
サンプルのシナリオとして、企業内で動作する2つのActive Directoryフォレストについて検討します。
フォレスト | ドメイン名 |
---|---|
ORACLE |
|
SPRITE |
|
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)の指定。
この例では、表49-1の名前が使用されます。
表49-1 サンプル名
名前 | 説明 |
---|---|
|
KDCホスト名 KDCは、Active Directoryドメイン内のユーザーとコンピュータにセッション・チケットおよび一時セッション・キーを提供する、信頼できるネットワーク・サービスです。KDCは、Active Directoryドメイン・サービスの一部として各ドメイン・コントローラ上で実行され、ドメイン・サービスとして実装されます。KDCは、Active Directoryをアカウント・データベースとして使用します。Kerberosプロトコルの実装では、KDCは、2つのサービス(認証サービス(AS)とチケット付与サービス(TGS))を提供する単一プロセスです。 |
|
AdminServerホスト名 これは、KDCホスト名と同じです。 |
|
OAMサーバー・ホスト名 |
|
デフォルトのActive Directoryレルム 2つ目のActive Directoryレルム レルム名は、ユーザー・アカウントの場所を識別します。レルム名は、接頭辞または接尾辞のいずれかにできます。 アクセス・クライアントがユーザー資格証明を送信するとき、ユーザー名が含まれることが多いです。ユーザー名の中には2つのエレメント(ユーザー・アカウント名とユーザー・アカウントの場所)が入っています。 |
HTTP/fully_qualified_OAMServerhostname@REALM_NAME (大文字) |
ユーザー・アカウント(クライアントがサービスのインスタンスを一意に識別する名前)にはサービス・プリンシパル名(SPN)が必要です。 ノート: フォレスト全体にわたってコンピュータにサービスのインスタンスを複数インストールする場合、各インスタンスに独自のサービス・プリンシパル名がある必要があります。 |
49.2.1 Active DirectoryおよびKerberosの準備
Active DirectoryおよびKerberosを準備できます。
コマンドは、Unixオペレーティング・システムに対応しています。コマンド構文は、環境内固有のオペレーティング・システムによって異なります。
-
Oracle動作保証マトリックスを確認し、この統合に対してサポートされているバージョンのActive Directoryをインストールしていることを確認します。
https://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html
-
次のようにActive Directoryをインストールして構成します。
-
次の必要な信頼関係を備えたマルチフォレスト・トポロジが構成されていて動作する
a.Kerberosサービスをマップするユーザー・アカウント
b.これらのユーザー・アカウント(クライアントがサービスのインスタンスを一意に識別する名前)のサービス・プリンシパル名(SPN)。
c.キー・タブ・ファイル
-
Active Directoryグローバル・カタログ(ADGC)が各フォレスト内で有効になっていて動作する
-
マルチフォレスト・デプロイメント: この場合、様々なフォレストに基づくユーザーを一意に識別するネーミング属性(グローバル・カタログ内にある)が存在することを確認します。一般的に、
userprincipalname
はフォレストに対して一意で、samAccountName
はドメインに対して一意です。 -
フォレスト・アフィリエーションに関係なく、他のドメインそれぞれに直接的または間接的に信頼されている1つのドメイン。
-
-
WNA認証中に使用するAccess Managerのユーザーを作成し、このユーザー名を記録してkeytabファイル(DES暗号化なし)を生成します。
-
OAMサーバー・ホスト名を記録します。たとえば:
oam12c.example.com
-
KDCホスト名およびActive Directoryドメイン/レルムを記録します。
KDC = kdc.lm.example.com Default AD Realm = lm.example.com
-
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)
ノート:
ユーザーが管理者グループに含まれていない場合、次の手順を実行して、ユーザーのリモート・デスクトップ接続を明示的に許可します。
-
Oracle Access Managementコンソールから、「コントロール パネル」→「リモートの設定」→「システムのプロパティ」を選択して、「リモート」タブに移動します。
-
「リモート デスクトップを実行しているコンピュータからの接続を許可する」オプションを選択します。
-
「ユーザーの選択」をクリックします。
-
ユーザーを追加します。
-
「適用」をクリックします。
-
-
新しく作成したkeytabファイルをOAMサーバーの適切な場所にコピーし、権限が正しいことを確認して、Access Managerを作成したユーザーがこのファイルにアクセスして
ktpass
コマンドを実行できるようします。 -
単純な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では必要ありません。
-
keytabファイルと作成したActive DirectoryおよびAccess ManagerのユーザーのSPNを使用して、
klist
およびkinits
が機能することを確認し、その結果を記録します。-
kdestroy
-
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$
-
kdestroy
-
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
-
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$
-
-
次の手順を実行します。
成功: 「Access Manager操作の確認」を続行します。
不成功: 停止してこの統合と関係のない問題を解決します。この時点での失敗は、Access Manager WNAを機能できないことを示します。
49.3 Access Manager操作の確認
完全に機能するAccess Managerのデプロイメントが必要です。
この項のタスクは、選択する方法に関係なく必要です。この手順では、アプリケーション・ドメインを構成してリソースを保護するWebGateをインストールして登録します。そして、環境がKerberos以外の認証スキームで機能していることを確認します。
関連項目:
2つ以上の管理対象サーバーがクラスタとして動作するように構成された高可用性環境の詳細は、『高可用性ガイド』の高可用性環境の作成に関する項
- 管理者の資格証明を使用して、Oracle Access Managementコンソールにログインします。
- デフォルト・アイデンティティ・ストアの接続を確認します。
- WebゲートをOAMエージェントとして登録およびインストールし、自動ポリシー生成を受け入れます。
- リソースをアプリケーション・ドメインに追加し、リソースを保護する認証ポリシーをKerberos以外の任意の認証スキームを使用するようにカスタマイズします。
- 構成をテストし、リソース保護およびアクセスが期待どおりに機能することを確認します。
- 「Kerberosトークンを返すためのブラウザの有効化」に進みます。
49.4 Kerberosトークンを返すためのブラウザの有効化
Kerberosトークンを返すように、Internet Explorer、Mozilla Firefox、EdgeまたはChromeを構成できます。
すべてのActive Directoryサーバーで適切な手順を実行します。次のいずれかの手順を使用して、ブラウザを構成します。
ノート:
Internet Explorerブラウザでは、統合Windows認証はデフォルトで有効になっており、WNAを機能させるためにデフォルト構成を変更する必要はありません。
49.4.1 Internet ExplorerのKerberosトークンの有効化
Internet ExplorerでKerberosトークンを有効にできます。
Kerberosトークンを有効にするには、次のようにします。
49.5 KerberosPluginとOracle Virtual Directoryの統合
Oracle Virtual Directoryを使用すると、インフラストラクチャとアプリケーションのいずれかを変更する必要性を最小限に抑えるか、またはその必要性をなくして、LDAPを認識するアプリケーションを多様なディレクトリ環境に統合できます。
この項では、Oracle Virtual Directoryを使用したWNAのためのAccess Manager KerberosPlugin認証を構成するために実行する必要があるタスクについて説明します。
49.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
を使用して、ルート・コンテキスト識別名を構築します。これが使用中のデプロイメントで異なる場合、それに合わせてアダプタ・ネームスペースを調整します。
-
「Access Manager操作の確認」に記載されたタスクを実行します。
-
Oracle Identity and Access Managementのインストールおよび構成の説明に従って、Oracle Virtual Directoryをインストールします。
-
Oracle Virtual Directoryコンソールで、次のように完全修飾ドメイン名をネームスペースとして使用して、2つのActive Directoryアダプタ(フォレストごとに1つ)を作成します。
-
アダプタ1、EXAMPLEアダプタ・ネームスペース(ドメインDNS
lm.example.com
):dc=lm,dc=example,dc=com
-
アダプタ2、SPRITEアダプタ・ネームスペース(ドメインDNS
lmsib.sprite.com
):dc=lmsib,dc=sprite,dc=com
-
-
OAMクラスタをシャットダウンします。
-
AdminServerおよびすべてのOAMサーバーを再起動します。
49.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操作の確認」の各項を完了してください。
49.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ネイティブ認証の統合を有効にするステップと置き換えることができます。
-
Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
-
「プラグイン」セクションで、「認証モジュール」をクリックします。
-
「検索」をクリックし、KerberosPluginプラグインを見つけて編集のために開きます。
-
KerberosPluginページで、「ステップ」タブをクリックします。
「ステップ」タブ: ここの説明に従ってstepKTAを置き換えて、「保存」をクリックします。
-
stepKTAをクリックしてから「削除」(x)ボタンをクリックしてこのステップを削除します。
-
「追加」(+)ボタンをクリックして、次のステップをプラグインに追加します。
要素 説明 名前
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の場所
-
-
stepUIFの詳細: 次のように構成し、「保存」をクリックします。
要素 説明 KEY_LDAP_FILTER
(samAccountName={KEY_USERNAME})
KEY_IDENTITY_STORE_REF
OVD
KEY_SEARCHBASE_URL
ここは空のままにします
-
stepUIおよびstepUA: 次のように構成し、「保存」します。
要素 説明 KEY_IDENTITY_STORE_REF
OVD
-
変更を保存します。
-
OAMクラスタを再起動します。
49.6 KerberosPluginと検索フェイルオーバーの統合
Oracle Virtual Directoryデプロイメントが実行不可能で、ユーザーを検索するときにある順序または階層に基づいて検索フェイルオーバーを実行することが許容される場合、Access Managerを構成できます。
49.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)』を参照してください。
49.6.2 ADGCでの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操作の確認」の各項を完了してください。
-
Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
-
「プラグイン」セクションで、「認証モジュール」をクリックします。
-
「検索」をクリックし、KerberosPluginプラグインを見つけて編集のために開きます。
-
KerberosPluginページで、「ステップ」タブをクリックします。
「ステップ」タブ: ここの説明に従ってstepKTAを置き換えて、「保存」をクリックします。
-
stepKTAをクリックしてから「削除」(x)ボタンをクリックしてこのステップを削除します。
-
「追加」(+)ボタンをクリックして、次のステップをプラグインに追加します。
要素 説明 名前
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
-
-
stepUIF: ステップ詳細(次のように構成して保存):
要素 説明 KEY_IDENTITY_STORE_REF
ADGC1-ORACLE
KEY_SEARCHBASE_URL
{KEY_USERDOMAIN}
KEY_LDAP_FILTER
(samAccountName={KEY_USERNAME}) ノート: 信用されていないマルチドメインActive Directory環境の場合、
userPrincipalName
ユーザー属性を使用します。 -
stepUIおよびstepUA: ステップ詳細(これらのステップを構成して保存):
要素 説明 KEY_IDENTITY_STORE_REF
ADGC1-ORACLE
-
変更を保存します。
-
stepUIF2の追加: これは連動し、stepUIFが失敗した場合に実行されます。
要素 説明 KEY_IDENTITY_STORE_REF
ADGC2-SPRITE
KEY_SEARCHBASE_URL
{KEY_USERDOMAIN}
KEY_LDAP_FILTER
(samAccountName={KEY_USERNAME}) ノート: 信用されていないマルチドメインActive Directory環境の場合、
userPrincipalName
ユーザー属性を使用します。 -
stepUI2の追加: これは連動し、stepUIが失敗した場合に実行されます。
要素 説明 KEY_IDENTITY_STORE_REF
ADGC2-SPRITE
-
stepUA2の追加: これは、stepUI2が成功したときに実行されます。
要素 説明 KEY_IDENTITY_STORE_REF
それぞれADGC1-EXAMPLEおよびADGC2-SPRITE
-
ステップ詳細の追加: 「共通構成」、「プラグイン」、KerberosTokenAutheticator。
デプロイの値を入力します。
要素 説明 keytab.conf
stepKTAのkeytab.confの場所たとえば:
/refresh/home/oam.keytab
krb5.conf
stepKTAのkrb5.confの場所たとえば:
/etc/krb5.conf
-
OAMクラスタを再起動します。
49.7 Windowsネイティブ認証のためのAccess Managerの構成
Oracle Virtual Directoryを使用していてもグローバル・カタログを備えたActive Directoryを使用していても、この項は、ユーザーが実行できるステップを含む次のトピックを提供します。
49.7.1 Windowsネイティブ認証用の認証スキームの作成
有効なOracle Access Management管理者の資格証明を持つユーザーは、Windowsネイティブ認証用のアプリケーションを保護するポリシーで使用する認証スキームを定義できます。
開始する前に、次の項のいずれかを完了してください: 「KerberosPluginとOracle Virtual Directoryの統合」または「KerberosPluginと検索フェイルオーバーの統合」。
49.7.2 Windowsネイティブ認証のためのポリシーの構成
アプリケーション・ドメインおよびポリシーを編集(または作成)し、Windowsネイティブ認証のリソースを保護します。
開始する前に、「Windowsネイティブ認証用の認証スキームの作成」を完了してください。
-
Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
-
「Access Manager」セクションで、「アプリケーション・ドメイン」をクリックします。
-
「コンソールを使用したアプリケーション・ドメインの管理」の説明に従って、必要なアプリケーション・ドメインを開きます(または作成します)。
-
リソース定義: 「ポリシー・リソース定義の追加および管理」の説明に従って、リソース定義をドメインに追加します。
-
認証ポリシー:
-
「認証ポリシー」ノードを開き、次の属性を含む必要な認証ポリシーを開きます(または作成します)。
認証スキーム: KerbScheme。更新したKerberosPluginが含まれていることを確認します。
認証スキームとしてKerbSchemeを選択し、更新したKerberosPluginが含まれていることを確認します。
-
「適用」をクリックして、「確認」ウィンドウを閉じます。
-
認証ポリシーのリソース: 『Oracle Access Management管理者ガイド』の説明に従って、リソースを認証ポリシーに追加します。
-
必要なレスポンスを加えて認証ポリシーを完了します。
-
-
認可ポリシー: 「特定のリソースの認可ポリシーの定義」の説明に従って、必要なレスポンスまたは条件を加えて認証ポリシーを完成します。
49.7.3 WNAのNTLMフォールバックの構成
NTLMトークンの受信時にWNAフォールバック認証を使用するようにAccess Managerを構成できます。
詳細は、「Access Manager WNAログインおよびフォール・バック認証の理解」を参照してください。
構成するには、次のようにします。
-
OAM管理対象サーバーを停止します。
-
データベースから
oam-config.xml
ファイルをエクスポートします。詳細は、「OAM構成の更新」を参照してください。 -
次のように、
oam-config.xml
を編集します:-
次の行を探します。
<Setting Name="CredentialCollector" Type="htf:map">
-
この行の後に、次の要素を追加します(まだ存在していない場合)。
-------------------------------------------------------------------------- <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>
-
-
変更された
oam-config.xml
ファイルをデータベースにインポートします。詳細は、「OAM構成の更新」を参照してください。 -
OAMサーバー・プロセスを再起動します。
ノート:
トラブルシューティングの詳細は、「2つのBASIC認証のプロンプトが表示される」を参照してください。
49.7.4 FORMベース認証スキームへのWNAフォールバックの構成
FORMベース認証スキームへのWNAフォールバックは、認証前ルールの設定に依存しています。WNA FORMフォールバック・メカニズムをサポートするOAM_WNA_OPT_OUT cookieを確認する認証前ルールを作成してください。OAM_WNA_OPT_OUT cookieの値がTRUEに設定されている場合は、認証スキームがFORMベース認証に切り替えられます。
- データベースから
oam-config.xml
ファイルをエクスポートします。詳細は、「OAM構成の更新」を参照してください。 -
このファイルを次のように編集します。
<Setting Name="WNAOptions" Type="htf:map"> <Setting Name="HandleNTLMResponse" Type="xsd:string">FORM</Setting> </Setting>
-
NTLMおよびKerberos認証がブラウザ(ドメインにアタッチされていないブラウザなど)で機能しない場合は、OAMサーバーがレスポンスの本文に認証エラー(403)およびHTMLコンテンツを設定して応答します。OAMのデフォルトでは、「ログイン」ボタンがある認証エラー・ページが表示されます。ユーザーは、カスタマイズされたページの「ログイン」ボタンをクリックして、FORMベースの認証へのWNAのフォールバックを起動する必要があります。オプションで、CustomOptOutPageまたはIsOptOutPersistentパラメータを
oam-config.xml
に構成して、エラー・ページをカスタマイズできます。-
oam-config.xml
ファイルからすべてのHTMLコンテンツを生成するには、次のようにカスタム・オプト・アウト・ページを構成します。カスタマイズされたページのボタンがクリックされると、JavaScript関数optOut()が起動されます。次に、OAMがJavaScript関数optOut()を生成します。<Setting Name="CustomOptOutPage" Type="xsd:string">/home/custom.html</Setting>
-
OAM_WNA_OPT_OUT Cookieはデフォルトで永続Cookieとして設定されます。これを次のようにセッションCookieとして構成します。
<Setting Name="IsOptOutPersistent" Type="xsd:boolean">false</Setting>
-
oam-config.xml
をインポートします。詳細は、「OAM構成の更新」を参照してください。-
OAM_WNA_OPT_OUT cookieの値がTRUEに設定されており、認証前条件が次のように設定されているかどうかを確認します。
str(request.requestMap['Cookie']).lower().find('oam_wna_opt_out=true') >= 0
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)
というドキュメントを参照してください。
- このステップを実行しない場合、WNAおよびWNAフォールバックからFORMへの認証は次のエラーで失敗します:
-
OAMサーバー・プロセスを再起動します。
49.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>
49.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を検証するには、この手順を使用します。
- Active Directoryドメイン内のWindowsシステムに、ドメイン・ユーザーとしてログインします。
- Access Managerに登録されたホスト対象のActive Directoryに保存されているWindowsドメイン資格証明を使用して、Windows OSクライアントにサインインします。
- ブラウザ・ウィンドウを開き、使用中の環境のOAMによって保護されたアプリケーションのURLを入力します。
- Windowsドメインの資格証明でアプリケーションにログインしていて、追加のログインがないことを確認します。
49.9 WNAをDCCとともに使用するための構成
Kerberos認証プロトコルは、セキュアなネットワーク接続が確立される前にエンティティ間で相互認証を行うためのメカニズムを提供します。
この項では、Access ManagerでDCCを使用するようWindowsネイティブ認証とKerberosを構成する方法について説明します。内容は次のとおりです。
ノート:
DCCの詳細は、「資格証明コレクションおよびログインの理解」を参照してください。
49.9.2 Access Managerの構成
Kerberos認証モジュールを使用するようにAccess Managerを構成できます。
構成するには、次のようにします。
-
Kerberos認証スキームのチャレンジ・メソッドをWNAに変更します(該当する場合)。
-
Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
-
「起動パッド」タブで、「Access Manager」セクションの「認証スキーム」をクリックします。
-
KerberosSchemeを検索し、「編集」をクリックします。
-
チャレンジ・リダイレクトURLを、DCC WebゲートのURLに変更します。
たとえば、http://<DCC-WebGate-Hostname>:<Port>/
-
「適用」をクリックし、ページを閉じます。
-
-
LDAP認証モジュールのユーザー・アイデンティティ・ストアを、構成済のWindowsデータ・ストアに構成します。
-
Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
-
「起動パッド」タブで、「Access Manager」セクションの「認証モジュール」をクリックします。
-
LDAPを検索し、「編集」をクリックします。
-
ユーザー・アイデンティティ・ストアを、たとえばActive Directoryなどに変更します。
-
「適用」をクリックし、ページを閉じます。
-
-
Kerberos認証スキームを使用するように、リソースを保護するアプリケーション・ドメインを構成します。
保護されたリソースにアクセスする前に、そのURLがローカル・イントラネットのセキュリティ・サイトに追加されていることを確認します。また、「詳細設定」タブで、「セキュリティ」下の「統合Windows認証の有効化」オプションを選択します。
49.10 WNA構成のトラブルシューティング
この項では、次のエラーについて説明します。
関連項目:
My Oracle SupportのAccess Manager WNAクイック・スタート・ガイドのナレッジベース・ノート1416903.1(https://support.oracle.com/
)
49.10.1 Kinitの失敗
最初の資格証明の取得中に、Kerberosデータベースでクライアントが見つからない場合があります。
これは、「ユーザーが見つかりません」のKerberosバージョンであり、次のいずれかに関連している可能性があります。
-
プリンシパル名のミススペルまたはタイプミス
-
プリンシパルがKerberosデータベースに追加されなかったためにプリンシパルが存在しない。
-
ユーザー名がActive Directoryに存在しないまたはKerberosユーザーとして登録されなかった。
-
SPNが一意ではない。
-
Active Directory側で1つ以上の重複エントリが見つかった。
解決策は、Active Directory管理者がLDAPツリーのSPNの重複エントリを検索し、それらを削除することです。
49.10.2 「指定したユーザー名またはパスワードが正しくありません」と表示される
WNA認証スキームを使用してAccess Managerにより保護されたリソースにアクセスできない場合、エラー・メッセージが表示されます。
エラー・メッセージ「指定したユーザー名またはパスワードが正しくありません」が表示される場合は、次のことを確認します。
-
「指定したユーザー名またはパスワードが正しくありません」
-
使用されている暗号化タイプの不一致があります。
-
キータブに示されたSPNのキー・バージョン番号(kvno)が、アイデンティティ・ストアのマップされたユーザーのkvnoと一致しません。
49.10.3 ユーザー・アイデンティティ・ストアが正しく登録されていない
デフォルトでは、OAMのアイデンティティ・ストアは組込みLDAPです。別のアイデンティティ・ストア(Active DirectoryまたはOracle Unified Directoryなど)を使用する場合は、アイデンティティ・ストアを登録する必要があります。
アイデンティティ・ストアおよびそれらの登録方法の詳細は、「データ・ソースの管理」を参照してください。
-
使用しているアイデンティティ・ストアをデフォルトのストアとして設定するには、「ユーザー・アイデンティティのシステム・ストアの使用について」を参照してください。
-
使用しているユーザー・アイデンティティ・ストアを登録するには、「新しいユーザー・アイデンティティ・ストアの登録」および「ユーザー・アイデンティティ・ストア設定」の詳細を参照してください。