51 Access ManagerとOutlook Webアプリケーションの統合
Windows環境では、ユーザー認証の後、認証アプリケーションはそのユーザーのアイデンティティを偽装できます。暗号化の主な目的は、クライアントのアイデンティティに対してアクセス・チェックをトリガーすることです。
ノート:
この章では、OWA 2010を例として使用して、Outlook Webアプリケーション(OWA)の構成ステップについて説明します。(このドキュメントには含めていませんが)OWA 2016および2019に同様の構成ステップを適用できます。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 ヘッダー変数による偽装の有効化
ヘッダー変数を使用して偽装を有効にするには、次の項の手順を完了します。
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
|
Kerberos Key Distribution Center (KDC)およびActive Directory |
Windows Server 2008と2013 |
クライアントおよびサーバー・マシン |
|
セキュリティ・コンテキスト |
オペレーティング・システムとして動作する権限が備わっている必要があります。 ノート: IWAM_Machineは推奨されません。 |
相互認証が必要 |
相互認証はリモートでサポートされます。 |
51.3.2 信頼できるユーザーとしての偽装の作成
HeaderVarとユーザー・プロファイル属性のどちらを使用して偽装を有効にするかにかかわらず、戻り値はActive Directoryに含まれる信頼できるユーザーである必要があります。この特別なユーザーは、偽装以外には使用しないでください。
次の手順例では、SPPSImpersonatorを新規オブジェクト - ユーザーとして使用します。SPPSImpersonatorはSharePoint偽装を示すので、OWAImpersonatorも使用できます。環境はユーザーによって異なります。
ノート:
信頼できるユーザーには、非常に強力な権限が付与されるため、非常に複雑なパスワードを選択することをお薦めします。また、「パスワードの有効期限なし」ボックスがマークされていることも確認してください。偽装モジュールは、信頼できるユーザー・アカウントを表示できる唯一のエンティティであるため、外部のエージェンシがパスワードの期限切れを発見することは非常に困難です。
51.3.4 信頼できるユーザーのWebGateへのバインド
信頼できるユーザーの認証資格証明を指定して、信頼できるユーザーをWebゲートにバインドする必要があります。
この手順では、OAM WebGateがAccess Managerに登録されていることが前提となっています。この手順の値は、例としてのみ提供されます。環境はユーザーによって異なります。
関連項目:
51.3.5 アプリケーション・ドメインへの偽装レスポンスの追加
OWAリソースを保護するために、アプリケーション・ドメインを作成または構成する必要があります。
このためには、この手順で説明しているように、認可ポリシーにレスポンス(ヘッダー・タイプ・レスポンス)を追加する必要があります。
この手順では、登録済のOAM WebGateのアプリケーション・ドメインが作成されていることを前提としています。この例のアプリーション・ドメインはMyImpersonationDomainです。環境はユーザーによって異なります。
このレスポンスは、2つ目のWebゲート・リクエスト(認可用)に使用されます。
51.3.6 偽装DLLのIISへの追加
IISは、IISImpersonationModule.dll
をIIS構成に追加することで構成できます。
偽装DLLをIISに追加するには、次のようにします。
51.3.7 偽装のテスト
51.3.7.1 IIS仮想サイトの作成
Microsoft OWA 2010コンテキスト外の偽装機能をテストしたりシングル・サインオンをテストするには、IIS仮想Webサイト上のターゲットWebページが必要です。
そのような仮想Webサイトを作成するには、次のタスクを実行します。
- 「スタート」→「管理ツール」→「インターネット インフォメーション サービス(IIS)マネージャ」の順にクリックします。
- 左ペインにあるツリー上のローカル・コンピュータのアイコンの左側のプラス・アイコン(+)をクリックします。
- 左ペインにあるツリー上の「Webサイト」を右クリックして、メニューから「新規作成」、「Webサイト」の順に選択します。
- 「Webサイト作成」ウィザードでプロンプトに応答します。
- 仮想サイトを作成したら、このガイドで説明しているように、アプリケーション・ドメインでこれを保護する必要があります。
51.3.7.2 イベント・ビューアを使用した偽装のテスト
Windows 2008イベント・ビューアを使用して偽装のテストを実行する場合、実際のテストを実行する前にイベント・ビューアを構成する必要があります。
偽装をテストするには、次のようにします。
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に登録していることを前提としています。次の手順の値は、例としてのみ提供されます。環境はユーザーによって異なります。
関連項目:
51.4.5 Outlook Webアプリケーションに対するアプリケーション・ドメインへの偽装アクションの追加
OWAリソースを保護するために、アプリケーション・ドメインを作成または構成する必要があります(/owaおよび/ecpのみ)。
IISImpersonation Module.dll
は、IIS7.xでowaアプリケーションおよびecpアプリケーションにのみ適用され、サイト・レベルから削除されていることを確認します。認証ポリシーは、複数のHTTPヘッダー変数(認証ポリシー内のヘッダー・タイプのレスポンス)を設定する必要があります。
この手順では、Access Managerに登録されたOAM WebGate (ImpersonateAgent)用のアプリケーション・ドメインがすでに存在することを前提としています。
このレスポンスは、2つ目のWebgateリクエスト(認可用)に使用されます。
51.4.6 偽装dllのIISへの追加
IISは、IISImpersonationModule.dll
をIIS構成に追加することで構成できます。
また、ユーザーの偽装に対して必要であるため、「匿名アクセスを有効にする」を設定する必要もあります。
51.4.7 IISセキュリティの構成
続行する前にIISセキュリティを構成します。図51-4に例を示します。
- 「スタート」→「管理ツール」→「インターネット インフォメーション サービス(IIS)マネージャ」の順に選択します
- 左ペインにあるツリー上のローカル・コンピュータのアイコンの左側のプラス・アイコン(+)をクリックします。
- 左ペインのツリーで「Webサイト」をクリックします。
- 中央ペインで、「IIS」の下の「認証」をダブルクリックします。
- 「匿名アクセス」が有効になっていて、「Windows認証」が無効になっていることを確認します。
51.4.8 Outlook Webアプリケーションに対する偽装のテスト
次の方法で、OWAの偽装構成をテストできます。
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を構成する必要があります。