| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11gリリース2 (11.1.2.2) for All Platforms B69533-09 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11gリリース2 (11.1.2.2) for All Platforms B69533-09 |
|
前 |
次 |
Access Managerでは、Microsoft Internet Explorerユーザーが各自のデスクトップ資格証明を使用して自動的にWebベースのシングル・サインオン・アプリケーションへの認証を行うように設定できます。これはWindowsネイティブ認証(WNA)と呼ばれています。
この章には、Active Directoryを使用して環境を準備し、この統合を実行する方法を説明する次の項が含まれています。
Access Managerは、Windowsネイティブ認証(WNA)とのActive Directoryのマルチドメインおよびマルチフォレスト・トポロジ統合をサポートします。Active Directoryのディレクトリ・サービスは、オブジェクト(ユーザー、グループ、コンピュータ、ドメイン、組織単位およびセキュリティ・ポリシー)に関するすべてのディレクトリ情報にデータ・ソース(ディレクトリと呼ばれる)を使用します。
|
関連項目: Oracle Identity and Access Management 11gR1のシステム要件とサポート対象プラットフォーム:https://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html |
この章で説明する統合では、アプリケーションは、KerberosPlugin認証メソッドを使用したチャレンジ・メソッドとしてWNAとともにKerberos認証スキーム(KerberosScheme)を使用するAccess ManagerOracle Access Manager認証ポリシーによって保護される必要があります。この場合は、ユーザー・アイデンティティ・ストアとしてAccess Managerに登録されたWindows Active Directoryインスタンスに、資格証明を保存する必要があります。
言い換えると、保護されたリソースそれぞれがAccess Managerのアプリケーション・ドメインで定義されます。認証ポリシーには、デフォルトのユーザー・アイデンティティ・ストアに関連付けられている認証モジュール(Kerberos)を使用する認証スキーム(KerberosScheme)が含まれています。このストアは、認証に「ユーザー名属性」の値を使用します。この値は、特定のAccess Managerリリースに応じて、Active Directoryのユーザーおよびuserprincipalname = username@domianまたはSamAccountName = usernameの値に関連付けられています。
Access Managerシングル・サインオンをWNAと組み合せると、ユーザーのログイン資格証明などが含まれたKerberosセッション・チケットが生成されます。このKerberosセッション・チケットはユーザーには表示されません。
Access Managerは、Windowsネイティブ認証(WNA)と相互運用し、ユーザーがWindowsドメインにログインしたときに取得したKerberos資格証明を使用します。このクロス・プラットフォーム認証は、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プロトコルの無料実装は、マサチューセッツ工科大学から入手でき、また市販されています。
詳細な情報は、次を参照してください:
WNAが実装されていることで、ユーザーは資格証明のチャレンジを別途行うことなくWebアプリケーションをクリックできます。これは、Kerberosセッション・チケットがブラウザを通じてOAMサーバーに渡されるためです。OAMサーバーは、受信したトークンを復号化(キー・タブを使用)して、そこから認証済ユーザーの名前を抽出します。認証が成功すると、ユーザーはWebアプリケーションへのアクセスが自動的に許可されます。
|
関連項目: Oracle Identity and Access Management 11gR1のサポート対象ブラウザおよびサポート対象プラットフォーム:https://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html |
この項では、いくつかのWNAログイン・シナリオについて説明します。
処理の概要: 正常なAccess ManagerのWNA認証
ブラウザは、統合Windows認証(IWA)用に構成されます。
Access ManagerおよびWNAによって保護されるリソースが呼び出されます。
有効なKerberosチケットが表示されます: Http headers... Authorization: Negotiate YIIJ/...
ユーザーは、認証に関してチャレンジされません。リクエストしたリソースが表示され、WNAが機能することが証明されます。
つまり、ブラウザが統合Windows認証を使用するように構成されていて、リソースがAccess Manager Kerberos認証モジュールで保護されている場合は、次のようになります。
KerberosチケットをAccess Manager(ドメインにかかわりなく)が受け取ると、認証が試行されます。
成功: アクセスが付与されます。
失敗: Kerberosチケットの情報が提示されないかまたはデフォルトのユーザー・アイデンティティ・ストアで定義したユーザー名属性の値と一致しない場合、「不適切なユーザー名またはパスワード。」エラーが表示されます。アクセスは拒否されます。ブラウザはチケットを自動的に送信して、Access Managerとの相互作用はユーザーがロックアウトされるまで繰り返されます。ブラウザは、各交換の開始前に一時停止できません。
ユーザーがKerberos認証によってWindowsドメインにログオンされない場合、ブラウザはOAMに認証のためにKerberosトークンではなくNTLMトークンを送信します。Access Managerの構成方法によって、NTLMトークンの受信時にWNAフォールバック認証が使用されるか、認証が失敗します。
|
注意: ブラウザがNTLMトークンを送信したときにフォールバック認証を提供するようにAccess Managerを構成する必要があります。構成しないと、認証は失敗します。構成手順については、第50.7.3項「WNAのNTLMフォールバックの構成」を参照してください。 |
NTLMSSPは、すべてのバージョンのDCOM (Distributed Component Object Model)で使用できるセキュリティ・サポート・プロバイダです。これは、認証中にユーザーのパスワードをサーバーに実際には渡さない認証にNTLMプロトコルを使用します。
使用するブラウザは、統合Windows認証を使用するように構成されず、Access Manager Kerberos認証モジュールによって保護されるリソースがリクエストされるとき、TGTは提供されません。ブラウザの基本認証ウィンドウが表示され、ここで、Access ManagerのUser login attributeのデフォルトのアイデンティティ・ストアで定義された有効なユーザー名/パスワードの組合せを入力できます。
|
注意: KerberosチケットがAccess Manager(ブラウザ、オペレーティング・システム、ドメイン・ログインなどには関係ない)によって識別できない場合、フォールバック・メカニズムが呼び出されます。 |
WNAフォールバック認証: フォールバックは、チャレンジ・メソッド「Basic」と認証モジュール「LDAP」による認証スキーム「BasicScheme」を使用します。この認証モジュールは、コンソールを使用して変更できます。
このLDAP認証モジュールは、LDAPプラグインを使用します。このプラグインでは、ユーザー・アイデンティティ・ストアを、ユーザー名属性に使用する属性を定義する、現在登録されている任意のユーザー・アイデンティティ・ストアとして定義できます。
処理の概要: Access ManagerのWNAフォールバック認証
ブラウザは、統合Windows認証(IWA)用に構成されます。
Access Manager WNAによって保護されるリソースがリクエストされます。
チケットは表示されません(NTLM/Kerberos) - Http headers... Authorization: Basic
基本認証ウィンドウのポップアップが表示されます。
ユーザーは有効なユーザー名/パスワードを入力します。
リクエストしたリソースが表示されます(WNAフォールバックが機能します)。
Access Managerでは、次の方法がサポートされます。
Oracle Virtual Directoryを使用したKerberosプラグイン: Oracle Virtual Directoryと統合された、編成された認証プラグインとともにAccess Managerを使用すると、複数のActive Directoryグローバル・カタログが仮想化されます
複数のADGC間で検索フェイルオーバーを使用するKerberosプラグイン: Access Managerを編成された認証プラグインとともに使用します。このプラグインは、複数のActive Directoryグローバル・カタログ間でフェイルオーバー・パターンを実行します。
この項のタスクは、選択する方法に関係なく必要です。
ここで説明する完全に構成された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という形式のPre-Windowsユーザー名はサポートされません。 |
WNAのデフォルト・アイデンティティ・ストア・ユーザー名属性
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)の指定。
サンプル名
この例では、表50-1の名前が使用されます。
表50-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)が必要です。 注: フォレスト全体にわたってコンピュータにサービスのインスタンスを複数インストールする場合、各インスタンスに独自のサービス・プリンシパル名がある必要があります。 |
次の手順のコマンドは、Unixオペレーティング・システム用です。コマンド構文は、環境内固有のオペレーティング・システムによって異なります。
Active DirectoryおよびKerberosを準備するには:
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つのドメイン。
Access Managerのユーザーを作成し、WNA認証中に使用し、このユーザー名を記録してkeytabファイル(DES暗号化なし)を生成します。
OAMサーバー・ホスト名を記録します。例:
oam11g.example.com
KDCホスト名およびActive Directoryドメイン/レルムを記録します。
KDC = kdc.lm.example.com Default AD Realm = lm.example.com
OAMサーバー・クライアントが使用しているActive Directoryユーザーのサービス・プリンシパル名(SPN)を作成し、その結果(暗号化タイプを含む)を記録します。例:
ktpass -princ <protocol/oamserver_host> -pass <mypassword> -mapuser <user from step 1> -out <path_to_filename>
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)
|
注意: ユーザーが管理者グループに含まれていない場合、次の手順を実行して、ユーザーのリモート・デスクトップ接続を明示的に許可します。
|
新しく作成した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/oam11g.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/oam11g.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/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$
次のように進めます:
成功: 「Oracle固有の前提条件となるタスクの実行」に進みます。
不成功: 停止してこの統合と関係のない問題を解決します。この時点での失敗は、Access Manager WNAを機能できないことを示します。
完全に機能するAccess Managerのデプロイメントが必要です。この項のタスクは、選択する方法に関係なく必要です。関連項目:
この手順では、アプリケーション・ドメインを構成してリソースを保護するWebGateをインストールして登録します。そして、環境がKerberos以外の認証スキームで機能していることを確認します。
|
注意: この章の情報はAccess Managerに基づいています。 |
|
関連項目: 2つ以上の管理対象サーバーがクラスタとして動作するように構成された高可用性環境の詳細に関する『Oracle Fusion Middleware高可用性ガイド』 |
Access Manager環境を検証するには:
次の手順を使用して、Kerberosトークンを返すようにInternet ExplorerブラウザまたはMozilla Firefoxブラウザを構成します。すべてのActive Directoryサーバーで適切な手順を実行します。
|
注意: Internet Explorerブラウザでは、統合Windows認証はデフォルトで有効になっており、WNAを機能させるためにデフォルト構成を変更する必要はありません。 |
Internet ExplorerでKerberosトークンを有効化する手順は、次のとおりです。
Active Directoryドメイン内のWindowsホストに、ドメイン・ユーザーとしてサインインします。
Internet Explorerブラウザを開きます。
「ツール」メニューから「インターネット オプション」をクリックし、「セキュリティ」→「ローカル イントラネット」→「詳細設定」をクリックします。
「詳細設定」タブで、「セキュリティ」セクションの「統合Windows認証を使用する」の横にあるボックスを選択して「OK」をクリックします。
Oracle Access Manager CCホストまたはドメイン名をローカル・イントラネット・ゾーンに追加します(http://node.host:portの形式を使用(portは必須ではない))。例:
http://oam11g.example.com
Internet Explorerブラウザを再起動して、変更を有効にします。
Mozilla FirefoxでKerberosトークンを有効化する手順は、次のとおりです。
ブラウザのアドレス・バーに、about:configと入力します。
Oracle Access Manager CCホストまたはドメイン名をnetwork.negotiate-auth.trusted-urisの下にnetwork.negotiate-auth.trusted-uris=http://oam11g.example.comとして追加します。
複数のURIはカンマで区切られています。
Oracle Virtual Directoryでは、インフラストラクチャまたはアプリケーションを変更することなく、またはその必要性を最小限に抑えながら、LDAP対応のアプリケーションを様々なディレクトリ環境に統合できます。この項では、Oracle Virtual DirectoryとのWNAのためのAccess Manager KerberosPlugin認証を構成するために実行する必要があるタスクを説明します。
この項では、次のトピックと手順について説明します。
タスクの概要: Access Manager KerberosPluginと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 Fusion Middleware Oracle Identity Manager管理者ガイド』のIdentity Virtualization Library (libOVD)アダプタの管理に関する項を参照してください。
次の手順では、信頼できるドメインでOAMサーバーのアカウントを作成します。また、完全修飾ドメイン名をネームスペースとして使用して、2つのActive Directoryアダプタ(フォレストごとに1つ)を作成します。
デフォルトでは、Active Directoryはdcを使用して、ルート・コンテキスト識別名を構築します。これが使用中のデプロイメントで異なる場合、それに合わせてアダプタ・ネームスペースを調整します。
この統合のためにOracle Virtual Directoryをデプロイするには:
「Access Managerの操作の確認」の説明に従ってタスクを実行します。
『Oracle Fusion Middleware 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サーバーを再起動します。
有効な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にOracle Virtual Directoryを登録するには:
Oracle Access Managementコンソールから、「データ・ソース」ノードを開きます。
「ユーザー・アイデンティティ・ストア」ノードをクリックし、ツール・バーの「追加」ボタンをクリックします。
Oracle Virtual Directoryインスタンスについての必要な値を入力します。例:
OVDldap://ovd_host.domain.com:389cn=Administrator,cn=users,dc=lm,dc=example,dc=com********dc=comuserprincipalnamedc=comデフォルト・ストア: 「デフォルト・ストア」ボタンをクリックし、これをAccess Managerのユーザー・アイデンティティ・ストアにします。
「適用」をクリックして登録を送信し、「確認」ウィンドウを閉じます。
AdminServerおよびOAMサーバーを再起動します。
ネイティブ認証モジュールから必要とする十分な柔軟性が提供されない場合、特定の要求を満たすために設計されたプラグインを使用してカスタム認証モジュールを作成できます。
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ネイティブ認証の統合を有効にするステップと置き換えることができます。
OVDのAccess Manager KerberosPluginを設定するには
Oracle Access Managementコンソールから、次を開きます。
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/oam11g.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クラスタを再起動します。
Oracle Virtual Directoryデプロイメントが実行不能で、ユーザーを検索するときにある順序または階層に基づいて検索フェイルオーバーを実行することが受け入れられる場合、この項の説明に従ってAccess Managerを構成できます。
タスクの概要: Access Manager KerberosPluginと検索フェイルオーバーの統合
次の前記の項のタスクの完了
「Oracle固有の前提条件となるタスクの実行」(検索フェイルオーバーに必要ではないこの統合のためのOracle Virtual Directoryの統合に関する項を除く)
次の項のタスクの実行
有効なOracle Access Management管理者の資格証明を持つユーザーは、次のタスクを実行して、Oracle Access Managementの個別のユーザー・アイデンティティ・ストアとして各Active Directoryグローバル・カタログ(ADGC)を関連する検索ベースおよびネーミング属性に登録できます。
前提条件
Kerberosサービスをマップするユーザー・アカウント、それらのアカウントのサービス・プリンシパル名(SPN)、およびキー・タブ・ファイルを含む、完全に構成されたMicrosoft Active Directory認証サービスが設定されている必要があります。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護 11g リリース1 (10.3.3)』を参照してください。
Microsoft Active Directoryグローバル・カタログをAccess Managerに登録するには:
Oracle Access Managementコンソールから、「データ・ソース」ノードを開きます。
「ユーザー・アイデンティティ・ストア」ノードをクリックし、ツール・バーの「追加」ボタンをクリックします。
最初のADGCについての必要な値を入力します。例:
ADGC1-EXAMPLEldap://ADGC1_host.domain.com:389cn=Administrator,cn=users,dc=lm,dc=example,dc=comdc=lm,dc=example,dc=comuserprincipalnamedc=lm,dc=example,dc=comデフォルト・ストア: 「デフォルト・ストア」ボタンをクリックします。
「適用」をクリックして変更を送信し、確認ウィンドウを閉じます。
これらのステップを繰り返し、適切な検索ベースおよびネーミング属性を備えた2つ目のADGC (ADGC2-SPRITE)を追加します。
ADGC2-SPRITEldap://ADGC2_host.domain.com:389cn=Administrator,cn=users,dc=lm,dc=example,dc=comdc=lmsib,dc=example,dc=comuserprincipalnamedc=lmsib,dc=example,dc=comAdminServerおよびOAMサーバーを再起動します。
ネイティブ認証モジュールから必要とする十分な柔軟性が提供されない場合、特定の要求を満たすために設計されたプラグインを使用してカスタム認証モジュールを作成できます。
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管理者の資格証明を持つユーザーは、次のタスクを実行して、KerberosPluginのステップを作成したADGCを指すステップと置き換えるかまたは更新できます。これらは、その等価物と連動します(最初のステップでADGCが失敗した場合、2つ目のADGCが使用されます)。
前提条件
Active Directory/Kerberosトポロジの準備
ADGCのためにAccess Manager KerberosPluginを設定するには:
Oracle Access Managementコンソールから、次を開きます。
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/oam11g.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クラスタを再起動します。
Oracle Virtual Directoryを使用していてもグローバル・カタログを備えたActive Directoryを使用していても、この項は、ユーザーが実行できるステップを含む次のトピックを提供します。
有効なOracle Access Management管理者の資格証明を持つユーザーは、次のタスクを実行して、Windowsネイティブ認証用アプリケーションを保護するポリシーで使用するAccess Managerの認証スキームを定義できます。
前提条件
KerberosPluginとOracle Virtual Directoryの統合
または
Access Manager KerberosPluginと検索フェイルオーバーの統合
WNAのKerberos認証スキームを作成するには:
Oracle Access Managementコンソール、「起動パッド」を開き、「Access Manager」セクションの「認証スキーム」をクリックします。
「認証スキームの検索」ページが開きます。
「検索」で、「名前」ボックスにKerberosSchemeと入力し、「検索」をクリックします。
検索結果で「KerberosScheme」をクリックして開きます。
次の属性を設定(または確認)します。
「チャレンジ・メソッド」: WNA
「認証モジュール」: KerberosPlugin
デプロイメントのKerberosSchemeの構成を終了します。
「適用」をクリックして、「確認」ウィンドウを閉じます。
この手順では、アプリケーション・ドメインおよびポリシーを編集(または作成)し、Windowsネイティブ認証のリソースを保護します。
前提条件
Windowsネイティブ認証のAccess Managerポリシーを設定するには:
Oracle Access Managementコンソール、「起動パッド」を開き、「Access Manager」セクションの「アプリケーション・ドメイン」をクリックします。
「コンソールを使用したアプリケーション・ドメインおよびポリシーの管理」の説明に従って、必要なアプリケーション・ドメインを開きます(または作成します)。
リソース定義: 「ポリシー・リソース定義の追加および管理」の説明に従って、リソース定義をドメインに追加します。
認証ポリシー:
「認証ポリシー」ノードを開き、次の属性を含む必要な認証ポリシーを開きます(または作成します)。
認証スキーム: KerbScheme。更新したKerberosPluginが含まれていることを確認します。
認証スキームとしてKerbSchemeを選択し、更新したKerberosPluginが含まれていることを確認します。
「適用」をクリックして、「確認」ウィンドウを閉じます。
認証ポリシーのリソース: 『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の説明に従って、リソースを認証ポリシーに追加します。
必要なレスポンスを加えて認証ポリシーを完了します。
認可ポリシー: 「特定にリソースに対する認可ポリシーの定義」の説明に従って、必要なレスポンスまたは条件を加えて認証ポリシーを完了します。
次の手順に従って、NTLMトークンの受信時にWNAフォールバック認証を使用するようAccess Managerを構成します。詳細は、第50.1.1項「Access ManagerのWNAログインおよびフォールバック認証」を参照してください。
OAM管理対象サーバーを停止します。
次のファイルを安全な場所にバックアップします。
<WLS domain>/config/fmwconfig/oam-config.xml
<WLS domain>/config/fmwconfig/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サーバー・プロセスを再起動します。
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/oam11g.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>
統合Windows認証(IWA)は、特定のWindowsオペレーティング・システムに含まれているSPNEGO、KerberosおよびNTLMSSPの認証プロトコルを使用するMicrosoft製品と関連付けられています。統合Windows認証(IWA)という用語は、Microsoft Internet Information Services、Internet Explorerおよび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クライアントにサインインします。
Internet Explorerのブラウザ・ウィンドウを開き、使用中の環境のOAMによって保護されたアプリケーションのURLを入力します。
Windowsドメインの資格証明でアプリケーションにログインしていて、追加のログインがないことを確認します。
Kerberos認証プロトコルは、セキュアなネットワーク接続が確立される前にエンティティ間で相互認証を行うためのメカニズムを提供します。この項では、Access ManagerでDCCを使用するようWindowsネイティブ認証とKerberosを構成する方法について説明します。内容は次のとおりです。
Kerberosプロトコルを使用するようAccess Managerを初期化するには、次の手順を実行します。
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暗号化は使用しないでください。 |
ktpassコマンドによって生成されたkeytab出力をコピーし、Access Managerサーバー上の適切な場所に配置します。
それに応じてAccess Managerサーバー上の/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
|
Access Managerマシン上でkinitコマンドを実行し、Kerberosチケットを取得します。
kinit -k -t <keytab file> <SPN>@<Realm>
例:
kinit -k -t foobar1.keytab HTTP/adc.example1.com@EXAMPLE.COM
klistコマンドを使用して、Access Managerマシン上でKerberosチケットを検証します。
klist
次の手順により、Kerberos認証モジュールを使用するようAccess Managerを構成します。
Kerberos認証スキームのチャレンジ・メソッドをWNAに変更します(該当する場合)。
「起動パッド」から「認証スキーム」をクリックします。
KerberosSchemeを見つけて、「編集」をクリックします。
チャレンジ・リダイレクトURLを、DCC WebゲートのURLに変更します。
例: http://<DCC-WebGate-Hostname>:<Port>
「適用」をクリックし、ページを閉じます。
LDAP認証モジュールのユーザー・アイデンティティ・ストアを、構成済のWindowsデータ・ストアに構成します。
「起動パッド」から「認証モジュール」をクリックします。
LDAPを見つけて、「編集」をクリックします。
ユーザー・アイデンティティ・ストアを、たとえばActive Directoryなどに変更します。
「適用」をクリックし、ページを閉じます。
Kerberos認証スキームを使用するように、リソースを保護するアプリケーション・ドメインを構成します。
保護されたリソースにアクセスする前に、そのURLがローカル・イントラネットのセキュリティ・サイトに追加されていることを確認します。また、「詳細設定」タブで、「セキュリティ」下の「統合Windows認証の有効化」オプションを選択します。
この項では次のトピックを記載しています:
|
関連項目: My Oracle SupportのAccess Manager WNAクイック・スタート・ガイドのナレッジベース・ノート1416903.1(https://support.oracle.com/) |
エラー
初期資格証明取得時にKerberosデータベースでクライアントが見つかりません
原因
これはKerberosバージョンの「ユーザーが見つかりません」です。次のいずれかと関係がある場合があります。
プリンシパル名のミススペルまたはタイプミス
プリンシパルがKerberosデータベースに追加されなかったためにプリンシパルが存在しない。
ユーザー名がActive Directoryに存在しないまたはKerberosユーザーとして登録されなかった。
SPNが一意ではない。
Active Directory側で1つ以上の重複エントリが見つかった。
解決策
Active Directory管理者にLDAPツリーを検索してもらい、SPNの重複エントリを探して、それを削除する。
WNA認証スキームを使用してAccess Managerによって保護されたリソースにアクセスできません。エラー: 「指定したユーザー名またはパスワードが正しくありません」
エラー
「指定したユーザー名またはパスワードが正しくありません」
原因
Access Managerが使用するアイデンティティ・ストアがWindows Active Directoryを指していない可能性があります。デフォルトでは、アイデンティティ・ストアは組込みLDAPです。
解決策
Active Directory (Oracle Access Managementコンソール、システム構成、、データ・ソース、ユーザー・アイデンティティ・ストア)を登録し、ActiveDirectoryを作成します。
「デフォルト・ストアおよびシステム・ストアの設定」で説明するように、Active Directoryをデフォルト・ストアに設定します。
