Access ManagerとOutlook Webアプリケーションの統合

51 Access ManagerとOutlook Webアプリケーションの統合

Windows環境では、ユーザー認証の後、認証アプリケーションはそのユーザーのアイデンティティを偽装できます。暗号化の主な目的は、クライアントのアイデンティティに対してアクセス・チェックをトリガーすることです。

この章では、IISで有効になっている偽造をオーバーライドするようにAccess Managerで偽装を有効にする方法について説明します。次の各トピックでは、Access ManagerとOutlook Webアプリケーション(OWA) 2010、2016および2019との統合サポートについて説明します。

ノート:

この章では、OWA 2010を例として使用して、Outlook Webアプリケーション(OWA)の構成ステップについて説明します。(このドキュメントには含めていませんが)OWA 2016および2019に同様の構成ステップを適用できます。

51.1 このリリースの新機能

Access ManagerとOutlook Webアプリケーション(OWA)との統合のサポート。

この章では、次の機能について説明します。

51.2 Outlook Webアプリケーションとの統合の概要

この項では、この章で説明する統合についての次の情報を提供します。

51.2.1 Microsoft Windowsによる偽装について

偽装により、サーバーは、クライアントができることをでき、クライアントができないことはできない、という状況になります。サービスは、クライアントのセキュリティ・コンテキストで実行すると、特定の範囲についてクライアントとして機能します。ユーザーの認証後、サービスは、偽装経由でそのユーザーのアイデンティティを受け取ります。

サービスのスレッドの1つは、アクセス・トークン(偽装トークンとも呼ばれます)を使用して、クライアントがアクセスできるオブジェクトへのアクセス権を取得します。アクセス・トークンは、クライアントの資格証明を表す保護されたオブジェクトです。偽装トークンでは、クライアント、クライアントのグループおよびクライアントの権限が識別されます。トークン内の情報は、スレッドがクライアントのかわりにリソースへのアクセスをリクエストする際に、アクセス・チェックに使用されます。サーバーがクライアントを偽装するとき、そのサーバーによって実行される操作はすべて、そのクライアントの資格証明を使用して実行されます。

偽装により、サーバーは、クライアントができることをでき、クライアントができないことはできない、という状況になります。リソースへのアクセスは、そのリソースに対してクライアントが持つ権限に応じて制限したり拡張したりできます。偽装には、クライアントとサーバーの両方の参加が必要です。クライアントは、サーバーが自分のアイデンティティを使用することを許可し、サーバーはクライアントのアイデンティティをプログラムで明示的に実装する必要があります。

偽装が終了すると、スレッドはプライマリ・トークンを使用して、クライアントのセキュリティ・コンテキストではなくサービス独自のセキュリティ・コンテキストで動作します。プライマリ・トークンは、プロセスに関連付けられているユーザー・アカウント(アプリケーションを起動したユーザー)のセキュリティ・コンテキストを示します。

サービスは、サービス独自のアカウントで実行し、サービス独自の権限を持つユーザーとして動作します。たとえば、オペレーティング・システムとともにインストールされたシステム・サービスは、ローカル・システム・アカウントで実行されます。その他のサービスは、ローカル・システム・アカウントで実行するように構成することも、ローカル・システム上またはActive Directory内の別のアカウントで実行するように構成することもできます。

IIS Webサーバーは、偽装機能を提供します。ただし、OAMサーバーは、IISの認証機能、認可機能および偽装機能をオーバーライドします。詳細は、次の項の「Windows偽装に対するAccess Manager 12cのサポート」を参照してください。

51.2.2 Windows偽装に対するAccess Manager 12cのサポート

Windows偽装のサポートを有効にして、保護対象アプリケーションに対して追加のアクセス制御を提供することができます。

信頼できるユーザーをWebgateにバインドして、認証ルールに偽装アクションが含まれるアプリケーション・ドメインによりアプリケーションを保護します。認証プロセス中、保護対象アプリケーションは偽装トークンを作成します。

詳細は、「ヘッダー変数による偽装の有効化」を参照してください。ヘッダー変数を使用して偽装を実装するための前提条件および詳細が記載されています。

51.2.3 認証済Access ManagerユーザーのExchangeへのシングル・サインオン

認証済Access ManagerユーザーのExchangeへのシングル・サインオンもWindows偽装機能を使用してサポートされます。

Outlook Web Access (OWA)は、Exchangeメール・サービスへのWebアクセスを提供し、次のいずれかで構成できます。

Exchangeサーバーと同じホスト上にないIIS Webサーバー(フロントエンド・サーバーとも呼ばれます)
Exchangeサーバーと同じホスト上にあるIIS Webサーバー(バックエンド・サーバーとも呼ばれます)

フロントエンド・サーバー構成では、フロントエンドOWAサーバーがユーザーを認証し、ユーザーのメールボックスをホストするバックエンドExchangeサーバーを決定し、そのバックエンドExchangeサーバーにリクエストを取り次ぎます。追加で渡される資格証明情報はありません。委任も行いません。バックエンドExchangeサーバー上に偽装を設定することにより、このExchangeサーバーは、アクセスの付与に際して事前に資格証明を要求する必要がなくなります。

詳細は、「Outlook Webアプリケーション(OWA)に対する偽装の設定」を参照してください。

51.2.4 要件の確認

ここでは、OAMサーバーとMicrosoft Exchange Server 2013を統合するための偽装機能の設定を示す例を示します。

原則は、アプリケーションを問わず共通です。この章で特定のバージョンおよびプラットフォームについて言及している場合、それらは例示のみの目的で記載されています。Access Managerの最新の動作保証情報は、次のOracle Technology Networkを参照してください。

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

51.3 ヘッダー変数による偽装の有効化

ヘッダー変数を使用して偽装を有効にするには、次の項の手順を完了します。

関連項目:

「Outlook Webアプリケーション(OWA)に対する偽装の設定」。

51.3.1 ヘッダー変数による偽装要件

OAMサーバーでWindows偽装を実装する前に、環境を準備して動作を確認します。

表51-1に、ヘッダー変数による偽装を有効化する場合のAccess Managerプラットフォーム要件を示します。

表51-1 ヘッダー変数による偽装要件

項目	プラットフォーム
OAM Webgate (および偽装dll)	Microsoft IIS 7.xおよびWindows Server 2008と2013
偽装dll	Webgate_install_dir\webgate\iis\lib\IISImpersonationModule.dll IISモジュールとしてインストールする必要があります。 Webサイト・ツリーの任意のレベルにインストールできます。
Kerberos Key Distribution Center (KDC)およびActive Directory	Windows Server 2008と2013
クライアントおよびサーバー・マシン	両者は、信頼関係のある同じWindows Server 2008ドメイン内にある必要があります。双方向の信頼パスが必要です。サービスがクライアントの代理として動作し、クライアントのドメインにあるチケットを要求するためです。
セキュリティ・コンテキスト	オペレーティング・システムとして動作する権限が備わっている必要があります。ノート: IWAM_Machineは推奨されません。
相互認証が必要	相互認証はリモートでサポートされます。

51.3.2 信頼できるユーザーとしての偽装の作成

HeaderVarとユーザー・プロファイル属性のどちらを使用して偽装を有効にするかにかかわらず、戻り値はActive Directoryに含まれる信頼できるユーザーである必要があります。この特別なユーザーは、偽装以外には使用しないでください。

次の手順例では、SPPSImpersonatorを新規オブジェクト - ユーザーとして使用します。SPPSImpersonatorはSharePoint偽装を示すので、OWAImpersonatorも使用できます。環境はユーザーによって異なります。

Microsoft Exchange Server 2013インストールをホストするコンピュータ上の環境に対して次のステップを実行してください。
- Windows 2008または2012: 「スタート」→「プログラム」→「管理ツール」→「Active Directoryユーザーとコンピュータ」の順に選択します。
「Active Directoryユーザーとコンピュータ」ウィンドウで、左ペインのツリーで「ユーザー」を右クリックし、「新規作成」→「ユーザー」の順に選択します。
「新規オブジェクト - ユーザー」というペインの「名」フィールドに、覚えやすい名前としてSPPSImpersonatorなどを入力します。
この同じ文字列を「ユーザーログオン名」フィールドにコピーし、「次へ」をクリックします。
次のパネルで、パスワードの選択と確認用の再入力を求められます。

ノート:

信頼できるユーザーには、非常に強力な権限が付与されるため、非常に複雑なパスワードを選択することをお薦めします。また、「パスワードの有効期限なし」ボックスがマークされていることも確認してください。偽装モジュールは、信頼できるユーザー・アカウントを表示できる唯一のエンティティであるため、外部のエージェンシがパスワードの期限切れを発見することは非常に困難です。

図51-1 Windowsの偽装のための信頼できるユーザー・アカウントの設定

「図51-1 Windowsの偽装のための信頼できるユーザー・アカウントの設定」の説明

51.3.3 信頼できるユーザーへの権限の割当て

オペレーティング・システムの一部として機能する権限を信頼できるユーザーに付与できます。

信頼できるユーザーに権限を割り当てるには、次のようにします。

使用する環境に該当するステップを実行してください。
- Windows 2008: 「スタート」→「プログラム」→「管理ツール」→「ローカルセキュリティポリシー」の順に選択します。
  
  Webgateがインストールされているコンピュータに適用されるグループ・ポリシー・オブジェクトを変更する必要があります。
左ペインのツリーで、「ローカルポリシー」の横のプラス・アイコン(+)をクリックします。
左ペインのツリーで「ユーザー権利の割り当て」をクリックします。
右ペインで「オペレーティングシステムの一部として機能」をダブルクリックします。
「ユーザーまたはグループの追加」をクリックします。
「ユーザーまたはグループの追加」パネルで、「ユーザーとグループ名」テキスト・ボックスに信頼できるユーザーのユーザー・ログオン名(この例ではMicrosoft Exchange Server 2010 Impersonator)を入力し、「OK」をクリックして変更を登録します。

図51-2 Windowsの偽装での信頼できるユーザーの権限の構成

「図51-2 Windowsの偽装での信頼できるユーザーの権限の構成」の説明

51.3.4 信頼できるユーザーのWebGateへのバインド

信頼できるユーザーの認証資格証明を指定して、信頼できるユーザーをWebゲートにバインドする必要があります。

この手順では、OAM WebGateがAccess Managerに登録されていることが前提となっています。この手順の値は、例としてのみ提供されます。環境はユーザーによって異なります。

関連項目:

OAMエージェントの登録および管理

Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
「起動パッド」タブで、「エージェント」をクリックします。
この統合のために変更するOAM Webgate登録を見つけます。
- 有効なものすべてを見つける: 「状態」で「すべて」を選択して「検索」ボタンをクリックし、結果リスト内の目的のWebゲート名をクリックします。
Webgate登録ページで、前に作成した信頼できるユーザー・アカウントのSharePointユーザー名とパスワードを入力します。
「適用」をクリックして変更をコミットします。

Webゲートと信頼できるユーザーのバインドが作成されました。これで、Webゲートは、要求に応じて偽装を提供できるようになりました。要求は、偽装用に作成されたアプリケーション・ドメインの認可成功アクションによって作成されます。

51.3.5 アプリケーション・ドメインへの偽装レスポンスの追加

OWAリソースを保護するために、アプリケーション・ドメインを作成または構成する必要があります。

このためには、この手順で説明しているように、認可ポリシーにレスポンス(ヘッダー・タイプ・レスポンス)を追加する必要があります。

関連項目:

リソースを保護してSSOを有効化するポリシーの管理

この手順では、登録済のOAM WebGateのアプリケーション・ドメインが作成されていることを前提としています。この例のアプリーション・ドメインはMyImpersonationDomainです。環境はユーザーによって異なります。

Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
「Access Manager」セクションで、「アプリケーション・ドメイン」をクリックします。
OWAアプリケーション・ドメイン(偽装に関連するアプリケーション・ドメイン)を検索して開きます。
次のように移動します。
- 認可ポリシー
- 保護対象リソース・ポリシー
- レスポンス
「追加」ボタン、「レスポンスの追加」の順にクリックします。
フォームに次のように入力します。
- 「タイプ」リストから「ヘッダー」を選択します。
- 「名前」フィールドに、このレスポンスの一意の名前を入力します。たとえば、IMPERSONATEと入力します。
- 「値」フィールドに、このレスポンスの値を入力します。たとえば、 $user.useridと入力します。
「追加」、「適用」の順にクリックして、変更を送信します。

このレスポンスは、2つ目のWebゲート・リクエスト(認可用)に使用されます。

51.3.6 偽装DLLのIISへの追加

IISは、IISImpersonationModule.dllをIIS構成に追加することで構成できます。

偽装DLLをIISに追加するには、次のようにします。

「スタート」→「管理ツール」→「インターネットインフォメーションサービス(IIS)マネージャ」の順に選択します。
IIS 7.xの左ペインで、ホスト名をクリックします。
中央ペインのIISヘッダーで、「モジュール」をダブルクリックします。
右ペインで「ネイティブモジュールを構成」をクリックして「登録」をクリックします。
ウィンドウに、モジュール名(たとえば、Oracle偽装モジュール)を入力します。
「パス」フィールドに、IISImpersonationModule.dllへのフルパスを入力します。
デフォルトでは、パスは次のとおりです。
```
Webgate_install_dir\webgate\iis\lib\IISImpersonationModule.dll
```
ここで、Webgate_install_dirはWebゲートのインストール・ディレクトリです。

ノート:

パスにスペースが存在する場合(たとえば、C:\Program Files\Oracle\...)文字列全体を二重引用符(" ")で囲みます。
「OK」をクリックして、モジュールを登録します。
新しく作成したモジュールの名前を確認し、「OK」をクリックして、各Webサイトにモジュールを適用します。
デフォルト・サイト・レベルからこのモジュールを削除します(そうしない場合、マシン・レベルで追加すると継承されます)。
このステップで追加したIISImpersonationModule.dllファイルはowaアプリケーションおよびecpアプリケーションにのみ適用され、サイト・レベルから削除されていることを確認します。

OWAに移動し、「モジュール」をダブルクリックし、「ネイティブモジュールを構成」をクリックし、目的のモジュール(たとえばOracle Impersonation Module)を選択します。

(ecp):に移動: 「モジュール」をダブルクリックし、「ネイティブモジュールを構成」をクリックし、目的のモジュール(たとえばOracle Impersonation Module)を選択します。

51.3.7 偽装のテスト

イベントビューアまたはWebページを使用して、偽装をテストできます。

偽装をテストする方法には次の2つがあります。

51.3.7.1 IIS仮想サイトの作成

Microsoft OWA 2010コンテキスト外の偽装機能をテストしたりシングル・サインオンをテストするには、IIS仮想Webサイト上のターゲットWebページが必要です。

そのような仮想Webサイトを作成するには、次のタスクを実行します。

「スタート」→「管理ツール」→「インターネットインフォメーションサービス(IIS)マネージャ」の順にクリックします。
左ペインにあるツリー上のローカル・コンピュータのアイコンの左側のプラス・アイコン(+)をクリックします。
左ペインにあるツリー上の「Webサイト」を右クリックして、メニューから「新規作成」、「Webサイト」の順に選択します。
「Webサイト作成」ウィザードでプロンプトに応答します。
仮想サイトを作成したら、このガイドで説明しているように、アプリケーション・ドメインでこれを保護する必要があります。

51.3.7.2 イベント・ビューアを使用した偽装のテスト

Windows 2008イベント・ビューアを使用して偽装のテストを実行する場合、実際のテストを実行する前にイベント・ビューアを構成する必要があります。

偽装をテストするには、次のようにします。

「スタート」メニュー→「イベントビューア」の順に選択します。
左ペインで「セキュリティ」を右クリックし、「プロパティ」をクリックします。
「セキュリティ」プロパティ・シートで「フィルタ」タブをクリックします。
すべての「イベントの種類」にチェックが付いていることおよび「イベントソース」と「分類」の各リストが「すべて」に設定されていることを確認し、「OK」をクリックして「プロパティ」シートを閉じます。

イベント・ビューアは、リソース・リクエストに関連付けられたheaderVarに関する情報が表示されるように構成されました。

図51-3 イベント・ビューアの設定の確認

「図51-3 イベント・ビューアの設定の確認」の説明
新規IIS仮想サーバー(仮想サイト)を作成します。
仮想サイト上のツリーのどこかにターゲットWebページを配置します。
Webページでブラウザを指します

偽装が正しく機能している場合、イベント・ビューアがアクセス試行の成功を報告します。

51.3.7.3 Webページを使用した偽装のテスト

リクエストに関する情報を返し、表示できる.aspページやPerlスクリプトなどの動的テスト・ページを使用して偽装をテストすることも可能です。

偽装をテストするには、次のようにします。

パラメータAUTH_USERおよびIMPERSONATEを表示する.aspページまたはPerlスクリプトを作成します。次のサンプル・ページのようなコードになります。

<TABLE border=1>
<TR>
<TD>Variable</TD>
<TD>&nbsp&nbsp</TD>
<TD>Value</TD></TR>
<%for each servervar in request.servervariables%>
<TR>
<TD><%=servervar%></TD>	
<TD>&nbsp&nbsp</TD>
<TD><%=request.servervariables(servervar)%>&nbsp</TD>
</TR>

IIS仮想サイトを作成するかまたは前のタスクで作成したものを使用します。
新規仮想サイトのツリーのどこかに .aspページまたはPerlスクリプト(前のリストのサンプルなど)を配置します。
ブラウザでそのページに移動します。ページに、リクエストしたユーザーの名前に設定されたAUTH_USERとIMPERSONATEの両方が表示されます。

51.4 Outlook Webアプリケーション(OWA)に対する偽装の設定

分散Exchange/OWAシングル・サインオン環境では、各サーバーで、Access Managerに現在のユーザーを偽装させる必要があります。偽装を有効にするには、偽装アプリケーション・ドメインの認可ポリシーの「レスポンス」タブにHTTPヘッダーを追加する必要があります。

スタンドアロンOWA環境および分散OWA環境の両方でテスト済のソリューションを次に示します。

『Oracle Identity and Access Managementのインストールおよび構成』の説明に従って、Access Manager 12cをインストールします。
『Oracle Access Management管理者ガイド』で説明しているように、すべてのOWAクライアント・サーバー上にOAM Webゲートをインストールします。
Webゲート登録ページで、アクセス・ゲートを使用するバックエンド・サーバーのWebゲートのIPチェックを無効にします(リクエストがユーザーのブラウザではなくフロントエンド・サーバーから転送されるため)。
「Outlook Webアプリケーションに対して偽装を設定するための前提条件」の説明に従って、OWAが統合Windows認証を使用していなことを確認します。
「Outlook Webアプリケーションに対する信頼できるユーザー・アカウントの作成」の説明に従って、Active Directoryでの偽装に対してのみ信頼できるユーザー・アカウントを作成します。
「Outlook Webアプリケーションの信頼できるユーザーへの権限の割当て」の説明に従って、オペレーティング・システムの一部として機能する特別な権限を信頼できるユーザーに付与します。
「信頼できるOutlook Webアプリケーション・ユーザーのWebゲートへのバインド」の説明に従って、信頼できるユーザーの認証資格証明を提供して、信頼できるユーザーをWebゲートにバインドします。
「Outlook Webアプリケーションに対するアプリケーション・ドメインへの偽装アクションの追加」の説明に従って、(偽装アプリケーション・ドメインで)認証ポリシーの「レスポンス」タブにimpersonateという名前のヘッダー変数を追加します。
「偽装dllのIISへの追加」の説明に従って、IISImpersonationModule.dllをIIS構成に追加して、IISを構成します。
「Outlook Webアプリケーションに対する偽装のテスト」の説明に従って、偽装をテストします。

関連項目:

「ヘッダー変数による偽装の有効化」。

51.4.1 Outlook Webアプリケーションに対して偽装を設定するための前提条件

Outlook Webアプリケーションに対する偽装の設定を続行する前に、OWAが統合Windows (または他の)認証を使用していないことを確認します。

そうでない場合は、次のステップを使用して、Windows認証によるOWAを設定できます。

Exchange管理コンソールを開きます。
「サーバーの構成」に移動し、「クライアントアクセス」をクリックします。
「Outlook Web Access」を選択して、「プロパティ」をクリックします。
「プロパティ」ダイアログ・ボックスで、「認証」タブをクリックします。
すべての認証方法をクリア(選択解除)します。
「適用」をクリックし、「OK」をクリックします。
IISサーバーを再起動します。
「Outlook Webアプリケーションに対する信頼できるユーザー・アカウントの作成」に進みます。

51.4.2 Outlook Webアプリケーションに対する信頼できるユーザー・アカウントの作成

この特別なユーザーは、偽装以外には使用しないでください。信頼できるユーザーには、非常に強力な権限が付与されるため、非常に複雑なパスワードを選択することをお薦めします。

また、「パスワードの有効期限なし」ボックスがマークされていることも確認してください。偽装モジュールは、信頼できるユーザー・アカウントを表示できる唯一のエンティティであるため、外部のエージェンシがパスワードの期限切れを発見することは非常に困難です。

Outlook Webアプリケーションに対する信頼できるユーザー・アカウントを作成するには、次のようにします。

Windows 2008マシンで、「スタート」→「プログラム」→「管理ツール」→「Active Directoryユーザーとコンピュータ」の順に選択します。
「Active Directoryユーザーとコンピュータ」ウィンドウで、左ペインのツリーで「ユーザー」を右クリックし、「新規作成」→「ユーザー」の順に選択します。
「新規オブジェクト - ユーザー」というペインの「名」フィールドに、OWAImpersonatorなどの覚えやすい名前を入力します。
この同じ文字列を「ユーザーログオン名」フィールドにコピーし、「次へ」をクリックします。
次のパネルで、パスワードの選択と確認用の再入力を求められます。
「Outlook Webアプリケーションの信頼できるユーザーへの権限の割当て」に進みます。

51.4.3 Outlook Webアプリケーションの信頼できるユーザーへの権限の割当て

オペレーティング・システムの一部として機能する権限を信頼できるユーザーに与える必要があります。

Outlook Webアプリケーションの信頼できるユーザーに権限を割り当てるには、次のようにします。

「コントロールパネル」から「管理ツール」を選択し、「ドメインコントローラセキュリティポリシー」(コンピュータがドメイン・コントローラである場合)または「ローカルセキュリティポリシー」をクリックします。
左ペインのツリーで、「ローカルポリシー」の横のプラス・アイコン(+)をクリックします。
左ペインのツリーで「ユーザー権利の割り当て」をクリックします。
右ペインで「オペレーティングシステムの一部として機能」をダブルクリックします。
「ユーザーまたはグループの追加」をクリックします。
「ユーザーまたはグループの追加」パネルで、信頼できるユーザーのユーザー・ログオン名(この例ではOWAImpersonator)をユーザー名とグループ名のテキスト・ボックスに入力し、「OK」をクリックして変更を登録します。
「信頼できるOutlook Webアプリケーション・ユーザーのWebゲートへのバインド」に進みます。

51.4.4 信頼できるOutlook Webアプリケーション・ユーザーのWebゲートへのバインド

信頼できるユーザーの認証資格証明を指定して、信頼できるユーザーをWebゲートにバインドする必要があります。

Webゲートと信頼できるユーザーのバインドが作成されると、Webゲートは要求に応じて偽装を提供できるようになります。要求は、偽装用に作成されたアプリケーション・ドメインの認可ポリシーで設定されたレスポンスによって作成されます。

次の手順では、12c Webゲート(ImpersonateAgent)をAccess Managerに登録していることを前提としています。次の手順の値は、例としてのみ提供されます。環境はユーザーによって異なります。

関連項目:

OAMエージェントの登録および管理

Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
「起動パッド」タブで、「エージェント」をクリックします。
この統合のために変更するOAM WebGate登録を見つけます。たとえば、ImpersonateAgentです。
- 「すべて」が有効になっているものを見つける: 「状態」で「すべて」を選択し、「検索」ボタンをクリックします。結果リスト内の目的のWebgate名をクリックします。
Webgate登録ページを開いて、事前に作成している信頼できるユーザー・アカウントのSharePointユーザー名とパスワードを入力します。
「適用」をクリックして変更をコミットします。

Webgateと信頼できるユーザーのバインドが作成されます。これで、Webgateは、要求に応じて偽装を提供できるようになりました。要求は、偽装用に作成されたアプリケーション・ドメインの認可成功アクションによって作成されます。

51.4.5 Outlook Webアプリケーションに対するアプリケーション・ドメインへの偽装アクションの追加

OWAリソースを保護するために、アプリケーション・ドメインを作成または構成する必要があります(/owaおよび/ecpのみ)。

IISImpersonation Module.dllは、IIS7.xでowaアプリケーションおよびecpアプリケーションにのみ適用され、サイト・レベルから削除されていることを確認します。認証ポリシーは、複数のHTTPヘッダー変数(認証ポリシー内のヘッダー・タイプのレスポンス)を設定する必要があります。

この手順では、Access Managerに登録されたOAM WebGate (ImpersonateAgent)用のアプリケーション・ドメインがすでに存在することを前提としています。

関連項目:

リソースを保護してSSOを有効化するポリシーの管理

Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
「Access Manager」セクションで、「アプリケーション・ドメイン」をクリックします。
OWA2010アプリケーション・ドメイン(偽装に関連するアプリケーション・ドメイン)を検索して開きます。
次のように移動します。
- 認可ポリシー
- 保護対象リソース・ポリシー
- レスポンス
「追加」ボタン、「レスポンスの追加」の順にクリックします。
フォームに次のように入力します。
- 「タイプ」リストから「ヘッダー」を選択します。
- 「名前」フィールドに、このレスポンスの一意の名前を入力します。たとえば、IMPERSONATEと入力します。
- 「値」フィールドに、このレスポンスの値を入力します。たとえば、 $user.useridと入力します。
「追加」、「適用」の順にクリックして、変更を送信します。
次の項「偽装DLLのIISへの追加」に進みます。

このレスポンスは、2つ目のWebgateリクエスト(認可用)に使用されます。

51.4.6 偽装dllのIISへの追加

IISは、IISImpersonationModule.dllをIIS構成に追加することで構成できます。

また、ユーザーの偽装に対して必要であるため、「匿名アクセスを有効にする」を設定する必要もあります。

「スタート」→「管理ツール」→「インターネットインフォメーションサービス(IIS)マネージャ」の順に選択します
IIS 7.xの左ペインで、ホスト名をクリックします。
中央ペインで、「IIS」ヘッダーの下の「モジュール」をダブルクリックします。
右ペインで「ネイティブモジュールを構成」をクリックして「登録」をクリックします。
ウィンドウに、モジュール名(たとえば、Oracle偽装モジュール)を入力します。
「パス」フィールドに、IISImpersonationModule.dllへのフルパスを入力します。
デフォルトでは、パスは次のとおりです。
```
Webgate_install_dir\webgate\iis\lib\IISImpersonationModule.dll
```
ここで、Webgate_install_dirはWebゲートのインストール・ディレクトリです。

ノート:

パスにスペースが存在する場合(たとえば、C:\Program Files\Oracle\...)文字列全体を二重引用符(" ")で囲みます。
「OK」をクリックして、モジュールを登録します。
新しく作成したモジュールの名前を確認し、「OK」をクリックして、各Webサイトにモジュールを適用します。

51.4.7 IISセキュリティの構成

続行する前にIISセキュリティを構成します。図51-4に例を示します。

図51-4 偽装認証

「図51-4 偽装認証」の説明

「スタート」→「管理ツール」→「インターネットインフォメーションサービス(IIS)マネージャ」の順に選択します
左ペインにあるツリー上のローカル・コンピュータのアイコンの左側のプラス・アイコン(+)をクリックします。
左ペインのツリーで「Webサイト」をクリックします。
中央ペインで、「IIS」の下の「認証」をダブルクリックします。
「匿名アクセス」が有効になっていて、「Windows認証」が無効になっていることを確認します。

51.4.8 Outlook Webアプリケーションに対する偽装のテスト

次の方法で、OWAの偽装構成をテストできます。

51.4.8.1 イベント・ビューアを使用した偽装のテスト

イベントビューアを使用して偽装をテストできます。

テストするには、次のようにします。

「スタート」メニューから「イベントビューア」を選択します。
左ペインで「セキュリティ」を右クリックし、「プロパティ」をクリックします。
「セキュリティ」プロパティ・シートで「フィルタ」タブをクリックします。
すべての「イベントの種類」にチェックが付いていることおよび「イベントソース」と「分類」の各リストが「すべて」に設定されていることを確認し、「OK」をクリックして「プロパティ」シートを閉じます。
イベント・ビューアは、リソース・リクエストに関連付けられたheaderVarに関する情報が表示されるように構成されました。
新規IIS仮想サーバー(仮想サイト)を作成します。
仮想サイト上のツリーのどこかにターゲットWebページを配置します。
ブラウザに、WebページのURLを入力します。

偽装が正しく機能している場合、イベント・ビューアがアクセス試行の成功を報告します。

51.4.8.2 Webページを使用した偽装のテスト

偽装をテストするには、リクエストに関する情報を返し、それを表示できる動的テスト・ページを使用できます。

テストするには、次のようにします。

AUTH_USERおよびIMPERSONATEパラメータが表示される、a.aspページまたはPerlスクリプトを作成します。

このサンプル・ページのようになります:

<TABLE border=1>
<TR>
<TD>Variable</TD>
<TD>&nbsp&nbsp</TD>
<TD>Value</TD></TR>
<%for each servervar in request.servervariables%>
<TR>
<TD><%=servervar%></TD>
<TD>&nbsp&nbsp</TD>
<TD><%=request.servervariables(servervar)%>&nbsp</TD>
</TR>

IIS仮想サイトを作成するかまたは前のタスクで作成したものを使用します。
仮想サイトのツリーの任意の場所に、前記のサンプルのようなa.aspページまたはPerlスクリプトを配置します。
ブラウザで表示するページを指定し、要求を発行するユーザーの名前にAUTH_USERとIMPERSONATEの両方を設定します。

51.4.8.3 偽装のネガティブ・テストの実行

信頼できるユーザーをWebゲートからアンバインドすると、偽装のネガティブ・テストを実行できます。

実行するには、次のようにします。

Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
「起動パッド」タブで、「エージェント」をクリックします。
目的のWebゲートを検索し、編集のために開きます。
Webゲート登録ページで、信頼できるユーザーの資格証明を削除します。
「適用」をクリックして変更を保存します。
ブラウザ・ウィンドウでIISサーバーを再起動し、保護されているコード・ページ(信頼できるユーザーが以前アクセスできたページ)に移動します。
メッセージ・ページが表示されることを確認します。AUTH_USERとIMPERSONATEの値は、偽装資格証明をWebgateにバインドするために必要です。
信頼できるユーザーをWebGate登録ページにリストアします。

51.5 Outlook Webアプリケーションに対するAccess Manager WNAの設定

Access Manager 12cは、Windowsネイティブ認証(WNA)で動作できます。

この項では、Outlook Webアプリケーション(OWA)に対するWindowsネイティブ認証(WNA)を使用するAccess Managerの設定について説明します。

次の手順では、IISサイトのフロントエンドOWAのWNAを有効にする方法を説明します。これは、Kerberosサービスをマップするユーザー・アカウント、これらのアカウントのサービス・プリンシパル名(SPN)およびキー・タブ・ファイルを含む、完全に構成されたMicrosoft Active Directory認証サービスが設定されていることを前提としています。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護 11g リリース1 (10.3.3)』E13707-03を参照してください。

「Windowsネイティブ認証のためのAccess Managerの構成」の説明に従って、Windowsネイティブ認証(WNA)を使用するようにAccess Managerを構成する必要があります。

前提条件のタスクをすべて実行します。
IIS認証(フロントエンド・サイト上のOWA)を開きます。
「Windows認証」を有効にします。
「プロバイダ」をクリックします。
「ネゴシエート」を「プロバイダ」に追加して、リストの一番上に移動します。

図owa_wna.jpgの説明
『Oracle Access Management管理者ガイド』の説明に従って、IISでOWAを保護するためのポリシーを作成します。