1. Oracle Access Management管理者ガイド
  2. 他の製品とAccess Managerとの統合
  3. Microsoft SharePoint ServerとAccess Managerの統合

50 Microsoft SharePoint ServerとAccess Managerの統合

この章では、Access Managerを12c WebゲートおよびMicrosoft SharePoint Serverと統合する方法を説明します。内容は次のとおりです。

ノート:

12c WebGateを使用するAccess Managerでは、Microsoft SharePoint Server 2010、2013および2019がサポートされます。

特に明記しないかぎり、この章のすべての詳細は、OAM偽装プラグインを使用したMicrosoft SharePoint ServerおよびLDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint ServerとのAccess Managerの統合に同様に適用されます。

50.1 このリリースのサポート内容

Access ManagerとSharePointとの統合のサポートによって、次の機能が可能になります。

  • Access Managerを使用したSSOログインの前にユーザーがSharePointにアクセスするとき、ユーザーにはAccess Manager SSOログイン資格証明を求めるプロンプトが表示されます。

  • 有効なAccess Managerログイン・セッションを持つユーザーがSharePointドキュメントにアクセスするとき、SharePointによって確立される必要があります(ログインしてSharePointで認証される)。Access Managerセッションが確立されると、SharePointによってLDAPメンバーシップ・プロバイダ、OAM WNAおよび偽装を使用したAccess ManagerとSharePointの統合も実行されます。認証ステータスに基づいて、SharePointは、SharePointに格納されているドキュメントへのアクセスを許可または拒否します。

  • ユーザーがブラウザを使用してOfficeドキュメントをSharePointから開くとき、SSOセッションはMS Officeプログラムに永続化し、MS Officeプログラムを介したドキュメントへのアクセスが維持されるようにする必要があります。「Officeドキュメントのためのシングル・サインオンの構成」を参照してください。

50.2 SharePoint Serverとの統合の概要

SharePoint Serverは、Windows Server Microsoft Internet Information Services (IIS)およびWindows SharePoint Services (WSS)上に構築されたMicrosoft所有の安全でスケーラブルなエンタープライズ・ポータル・サーバーです。

SharePoint Serverは、通常、Webコンテンツおよびドキュメント管理システムと関連付けられています。SharePoint Serverは、Microsoft IIS Webサーバーと連動して、コラボレーション、ファイル共有、Webデータベース、ソーシャル・ネットワークおよびWeb公開のためのサイトを生成します。WSS機能に加えて、SharePoint Serverは、追加の機能(ニュースとトピック、MySiteの個人ビューと公開ビューなど)を組み込んでいます。

Microsoft SharePoint Serverは、コンテンツ、ビジネス・プロセスおよび情報共有の制御を拡張します。Microsoft SharePoint Serverによって、ドキュメント、ファイル、Webコンテンツおよび電子メールの一元化されたアクセスおよび制御が提供され、コラボレーション作業のためのユーザーによるポータルへのファイルの送信が可能になります。

SharePointサーバー・ファームは、Webサイト、ポータル、イントラネット、エクストラネット、インターネット・サイト、Webコンテンツ管理システム、検索エンジン、Wiki、ブログ、ソーシャル・ネットワーク、ビジネス・インテリジェンス、ワークフローをホストでき、またWebアプリケーション開発用のフレームワークを提供します。

Microsoft SharePoint Serverと統合すると、Access Managerは、ISAPIフィルタおよびISAPIモジュールを介してユーザー認証を処理します。このことによって、Access ManagerとSharePoint Serverの間のシングル・サインオンが可能になります。

SharePoint Serverは、次の認証メソッドをサポートします。

  • フォーム・ベースの認証

  • 偽装ベースの認証

  • Windows認証: ユーザーに関する情報がActive Directoryサーバーに格納されている構成に対してのみ使用

この章の統合では、Microsoft SharePoint Serverリソースおよびその他すべてのAccess Managerによって保護されているリソースへのシングル・サインオンを提供します。詳細は、次を参照してください。

50.2.1 Windowsの偽装について

特に明記しないかぎり、この章で説明する統合は、Windowsの偽装に依存します。Windowsの偽装によって、Windowsサーバー・ドメインの信頼できるユーザーは、Microsoft SharePoint Serverのターゲット・リソースをリクエストする任意のユーザーのアイデンティティを持つことができます。

この信頼できるインパーソネータは、ユーザーのアイデンティティ・コンテキストを維持し、ユーザーのかわりにリソースにアクセスします。

偽装は、ユーザーに対して透過的に行われます。アクセスは、SharePointリソースがアクセス・システム・ドメイン内のリソースであるかのように実行されます。

ノート:

Windowsの偽装は、LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverとの統合時には使用されません。

50.2.2 この統合でのフォーム・ベースの認証

3つの認証メソッドのいずれかを使用してAccess ManagerとSharePoint Serverを統合できます。LDAPサーバー(Sun Directory Serverとインスタンス用Active Directory)の一般的な使用の場合、統合に任意のLDAPサーバーを組み込めます。SharePoint Serverのフォーム・ベースの認証は要求対応型です。 ユーザーがSharePointのRelying Party (RP)の「Formsログイン」ページに資格証明を入力するとき、これらはSharePointのSecurity Token Service (STS)に渡されます。SharePoint STSは、そのメンバーシップ・プロバイダに対してユーザーを認証し、SharePoint RPに渡すSAMLトークンを生成します。SharePoint RPは、SAMLトークンを検証し、FedAuth Cookieを生成します。ユーザーは、SharePoint RPサイトへのアクセスを許可されます。

フォーム・ベースの認証では、WebGateはISAPIフィルタとして構成されます。SharePoint RPのフォーム・ログイン・ページは、ユーザーがSharePoint RPによって資格証明の入力を求められないようにカスタマイズされます。また、メンバーシップ・プロバイダは、WebGateによって設定されたOAMAuthnCookieのみを検証してユーザーを認証するようにもカスタマイズされます。

次の概要では、フォーム・ベースの認証を使用してこの統合の認証フローを説明します。

プロセス概要: フォーム・ベースの認証を使用したリクエスト処理

  1. ユーザー・リクエストはSharePoint Server RPサイトにアクセスします。

  2. サイトを保護するWebGateは、リクエストを捕捉し、リソースが保護されているかどうかを判定し、ユーザーに要求します。

  3. ユーザーはOAM資格証明を入力します。次にOAM WebGateサーバーはLDAPから資格証明を確認し、ユーザーを認証します。

    WebGateは、OAMネイティブSSO Cookie (OAMAuthnCookie)を生成します。これは、シングル・サインオンを可能にし、HTTPリクエストの(ユーザー名に対する)ユーザーIDヘッダー変数を設定し、ユーザーをSharePoint RPサイトにリダイレクトします。

  4. SharePoint RPのカスタム・ログイン・ページが呼び出され、これが、ユーザー名をヘッダー変数に渡されたユーザーIDに設定し、パスワードをOAMAuthnCookie値に設定します。ログイン・ページもこれらの資格証明をSharePoint RPサイトに自動的に送信します。

  5. SharePoint RPサイトは、資格証明をSharePoint STSに渡し、これは、ユーザー資格証明の検証のためにカスタム・メンバーシップ・プロバイダを呼び出します。

  6. カスタム・メンバーシップ・プロバイダは、OAMAuthnCookie値(パスワードとして渡された値)を取得し、HTTPリクエストの一部としてこれをWebGateによって保護されているリソースに送信してOAMAuthnCookieを検証します。

  7. OAMAuthnCookieが有効な場合、SharePoint STSは、SAMLトークンを生成し、これをSharePoint RPに渡します。

  8. SharePoint RPは、SAMLトークンを検証し、FedAuth Cookieを生成します。ユーザーは、SharePoint RPサイトへのアクセスを許可されます。

50.2.3 Windowsの偽装およびSharePoint Serverの統合を使用した認証

Windowsの偽装によって、Windowsサーバー・ドメインの信頼できるユーザーは、SharePoint Portal Serverのターゲット・リソースをリクエストする任意のユーザーのアイデンティティを引き受けることができます。この信頼できるインパーソネータは、ユーザーのアイデンティティ・コンテキストを維持し、ユーザーのかわりにリソースにアクセスします。 偽装は、ユーザーに対して透過的に行われます。アクセスは、SharePointリソースがOAMサーバー・ドメイン内のリソースであるかのように実行されます。

次の概要では、SharePoint ServerおよびWindowsの偽装を有効にした場合に認証処理フローを特定します。

プロセス概要: Windowsの偽装を使用した統合認証

  1. ユーザー・リクエストはSharePoint Portal Serverリソースにアクセスします。

  2. SharePoint Portal Serverを保護するWebGate ISAPIフィルタは、リクエストを捕捉し、ターゲット・リソースが保護されているかどうかを判定し、保護されている場合にはユーザーに認証資格証明を要求します。

  3. ユーザーが資格証明を提供し、OAMサーバーがこれを検証すると、WebGateはユーザーのブラウザにOAMAuthnCookieを設定し、シングル・サインオンを有効にします。WebGateは、impersonateというHTTPヘッダー変数も設定します。この値は次のいずれかに設定されます。

    • 認証されるユーザーのLDAP uid

    • ユーザー・アカウントがActive Directoryに存在する場合、samaccountname

  4. Access Manager HTTPモジュールIISImpersonationModule.dllは、impersonateという認可成功アクション・ヘッダー変数があるかどうかを確認します。

  5. このヘッダー変数が存在する場合、Oracle ISAPIモジュールは、このユーザーに対するKerberosチケットを取得します。

    このService for User to Self (S4U2Self)偽装トークンを使用すると、指定された信頼できるユーザーは、リクエストしているユーザーのアイデンティティを持ち、IISおよびSharePoint Portal Serverを介してターゲット・リソースにアクセスできます。

50.2.4 Windowsネイティブ認証に対するAccess Managerサポート

Access Managerは、Windowsネイティブ認証(WNA)のサポートを提供します。

環境には次のものが含まれます。

  • Windows 2008/R2または2012/R2サーバー

  • Internet Information Services (IIS) 7.xまたは8.x

  • Active Directory

    たとえばユーザーのディレクトリ・サーバーにNTログオンIDがある場合、またはユーザー名がすべての場所で同じ場合、ユーザーは任意のディレクトリ・サーバーに対して認証できます。Windows Server 2008で最も一般的な認証メカニズムはKerberosです。

Access ManagerによるWNAの使用はシームレスです。ユーザーは、デスクトップにログインし、Internet Explorer (IE)ブラウザを開き、保護されているWebリソースをリクエストしてシングル・サインオンを完了するときに、通常の認証とWNAの違いに気付きません。

プロセスの概要: WNA認証の使用方法

  1. ユーザーがデスクトップ・コンピュータにログインすると、Windows Domain Administrator認証スキームを使用してローカル認証が完了します。

  2. ユーザーは、Internet Explorer (IE)ブラウザを開き、アクセス・システムで保護されたWebリソースをリクエストします。

  3. ブラウザは、ローカル認証をノートにとって、KerberosトークンをIIS Webサーバーに送信します。

    ノート:

    Internet Explorerのインターネットおよび(または)イントラネットのセキュリティ・ゾーンが自動ログオンを許可するように適切に調整されていることを確認してください。

  4. IIS WebサーバーにインストールされているWebGateは、KerberosトークンをOAMサーバーに送信します。OAMサーバーは、KDC (キー配布センター)を使用してKerberosトークンをネゴシエーションします。

  5. Access Managerは、認証成功情報をWebGateに送信します。

  6. WebGateは、OAMAuthnCookieを作成し、それをブラウザに送信します。

  7. Access Managerの認可およびその他のプロセスは通常どおりに進められます。

    WebGateに対して構成されている最大セッション・タイムアウト期間が、生成されたOAMAuthnCookieに適用されます。

50.3 統合の要件

特に明記しないかぎり、この項では、この章で説明する統合に必要なコンポーネントを紹介します。次のトピックが含まれています:

50.3.1 要件の確認

特定のバージョンおよびプラットフォームについて言及している場合、それらは例示のみの目的で記載されています。最新のAccess Manager動作保証の情報は、Oracle Technology Networkにある動作保証マトリックスを参照してください:

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

50.3.2 必要なAccess Managerのコンポーネント

Access Managerは、アクセス機能およびセキュリティ機能(Webベースのシングル・サインオン、ポリシー管理、レポートと監査など)を提供します。

Microsoft SharePoint Serverと統合すると、Access Managerは、ISAPIフィルタおよびISAPIモジュールを介してユーザー認証を処理し、2つの製品間のシングル・サインオンが可能になります。表50-1のコンポーネントは、Microsoft SharePoint Server (またはLDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Server)との統合に必要です。

表50-1 コンポーネントの要件

コンポーネント 説明

12c Webゲート

ISAPIバージョン12c Webゲートは、SharePoint Serverと同じコンピュータに存在する必要があります。

この統合のコンテキスト内では、このWebGateは、WebリソースのHTTPリクエストを捕捉し、これらをOAMサーバーに転送してリクエストをしたユーザーを認証するISAPIフィルタです。認証が成功すると、WebGateは、OAMAuthnCookieを作成し、これをユーザーのブラウザに送信するため、シングル・サインオンが容易になります。WebGateは、このユーザー・セッションのHeaderVarアクションとして偽装の設定も行います。

LDAPメンバーシップ・プロバイダのシナリオの場合: 「LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverとの統合」を参照してください。

IISImpersonationModule.dll

このIISネイティブ・モジュールは、WebGateとともにインストールされます。IISImpersonationModule.dllモジュールは、認可成功アクションHeaderVarが偽装に設定されたかどうかを判定し、その場合には、このDLLファイルは、SharePoint Server Active Directoryの特別な信頼できるユーザーが元々リクエストをしたユーザーに偽装できるようにするKerberos S4U2Selfチケットを作成します。

WebGateのインストール後、IISImpersonationModule.dllを手動で構成し、偽装およびこの統合を有効にする必要があります。

LDAPメンバーシップ・プロバイダのシナリオの場合: IISImpersonationModule.dllを構成しないでください。

ディレクトリ・サーバー

Access Managerは、任意のサポートされているディレクトリ・サーバー(LDAPおよびActive Directoryを含むがこれらに限定されない)に接続できます。Access Managerは、SharePoint Serverによって使用されるActive Directoryの同じインスタンスにさえ接続できます。

いずれのケースでも、ディレクトリはSharePoint Serverおよび保護しているWebGateと同じマシン上である必要はありません。

OAMサーバー

この統合では、SharePoint Serverのインストールを保護しているWebGateが相互運用に構成されている相互運用相手のOAMサーバーのインストールも必要です。

SharePoint Serverを保護しているWebGate以外のコンポーネントをSharePoint Serverをホストしているマシンに配置する必要はありません。

関連項目: 「SharePoint Serverとの統合の準備」

50.3.3 必要なMicrosoftのコンポーネント

最小要件では、64ビット、4コアのプロセッサを指定しています。

ただし、特定のバージョンおよびプラットフォームについて言及している場合、それらは例示のみの目的で記載されています。Access Managerの最新の動作保証情報は、Microsoft SharePoint Serverの次のMicrosoftライブラリの場所を参照してください。

https://technet.microsoft.com/en-us/library/cc262485.aspx

SharePointの多目的プラットフォームでは、イントラネット・ポータル、エクストラネットおよびWebサイトの管理およびプロビジョニング、ドキュメント管理とファイル管理、コラボレーション・スペース、ソーシャル・ネットワーク・ツール、エンタープライズ検索とインテリジェンス・ツール、プロセスと情報の統合、サードパーティが開発したソリューションが可能です。

ノート:

最小要件では、64ビット、4コアのプロセッサを指定しています。ただし、特定のバージョンおよびプラットフォームについて言及している場合、それらは例示のみの目的で記載されています。Access Managerの最新の動作保証情報は、次のOracle Technology Networkを参照してください。

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

表50-2に、この統合に必要なその他のコンポーネントを示します。

関連項目:

Microsoft SharePoint Serverの次のライブラリの場所および適用可能なソフトウェアへのアクセス。

http://technet.microsoft.com/en-us/library/cc262485.aspx

表50-2 この統合のためのMicrosoftの要件

コンポーネント 説明

SharePointサイトのカスタム・ログイン・ページ

フォーム・ベースの認証を使用するように構成されたSharePointサイトにユーザーがアクセスしようとすると、ユーザーはログイン・ページにリダイレクトされ、そこで資格証明(ユーザー名およびパスワード)を入力します。カスタム・ログイン・ページは資格証明をSharePointサイトに渡します。

SharePointサイト

SharePointサーバーの全体管理アプリケーションを使用してSharePointサイトを作成します。このサイトは、http://technet.microsoft.com/en-us/library/ee806890.aspxで説明されている次のステップに従って、認証メソッドとしてフォーム・ベースの認証を使用するように構成されます。

SharePointサイトは、カスタム・メンバーシップ・プロバイダによるOAMAuthnCookieの検証成功時にSAMLトークンを生成するSharePoint STSにユーザー資格証明を渡します。SharePointサイトは、SAMLトークンをSharePoint STSから受信したときにFedAuth Cookieも生成します。SharePointサイトは、FedAuth Cookieをユーザーに渡し、ユーザーがSharePointサイトにアクセスできるようにします。

SharePointセキュリティ・トークン・サービス(STS)

SharePointサイトは、ユーザー資格証明(ユーザー名とパスワード)をSharePoint STSに渡し、これは、カスタム・メンバーシップ・プロバイダを呼び出して、これに資格証明を渡します。カスタム・メンバーシップ・プロバイダがこれに渡されたOAMAuthnCookieを検証すると、SharePoint STSは、SharePoint Relying Party (RP)に渡されるユーザーのためのSAMLトークンを生成します。

SharePoint STSのためのカスタム・メンバーシップ・プロバイダ

SharePoint STSは、(フォーム・ベースの認証によって構成された)メンバーシップ・プロバイダを呼び出します。STSは、ユーザー資格証明および(SharePointサイト上のweb.configで構成された)IISリソースのURLをCookie検証のためにカスタム・メンバーシップ・プロバイダに渡します。

メンバーシップ・プロバイダは、これに渡されたOAMAuthnCookie値が有効な場合に成功を返すようにカスタマイズされます。

カスタム・メンバーシップ・プロバイダ・ライブラリ(OAMCustomMembershipProvider.dll)はパッケージ化され、IIS Webサーバーの12c Webゲートとともにインストールされます。SharePoint Serverホストのグローバル・アセンブリ・キャッシュにライブラリをデプロイする必要があります。

CustomMembershipProviderクラスは、Microsoft.Office.Server.SecurityネームスペースにあるLdapMembershipProviderクラスから派生します。

Cookie検証のIISリソース

SharePointサイトのweb.configファイルでIISリソースのURLを構成します。

HTTP検証メソッドの場合、WebGateは、カスタム・メンバーシップ・プロバイダによって送信されたリクエストを捕捉し、リクエストからOAMAuthnCookieを抽出してこれを検証します。Cookieが有効な場合、リクエストはIISリソースにリダイレクトされ、これが200 (OK)のステータス・コードを含むレスポンスをカスタム・メンバーシップ・プロバイダに返します。そうでない場合は、403(禁止)エラー・コードがカスタム・メンバーシップ・プロバイダに返されます。

50.4 SharePoint Serverとの統合の準備

IIS 12c Webゲートは、SharePoint Serverと同じコンピュータにインストールする必要があります。この統合の他のコンポーネントは、WebGateと同じホストまたはデプロイメント(Solaris、LinuxまたはWindowsプラットフォーム)の他のコンピュータに配置できます。

次の手順のタスクは、この章で説明するすべての統合シナリオで必要です。

Microsoftコンポーネントをインストールしてテストした後、ここに示すステップを実行して、統合のためにAccess Managerをインストールします。このタスクは、この章の両方の統合シナリオに適用されます。重複を避けるために、ここで示す情報は、他の場所では繰り返しません。

異なるホストをActive Directoryまたは他のディレクトリ・サービスに設定できます。Access ManagerとSharePoint Serverの両方がActive Directoryの異なるインスタンスに設定される場合、両方のインスタンスは、同じActive Directoryドメインに属する必要があります。

前提条件

「必要なMicrosoftのコンポーネント」に記載されているMicrosoftのコンポーネントをインストールしてテストします。

SharePoint Serverとの統合の準備を行います。

  1. Oracle Identity ManagementとAccess Managerをインストールします。手順については、『Oracle Identity Managementのインストールと構成』を参照してください。

  2. IIS Webサーバーの12c WebゲートをAccess Managerに登録します。

    1. Oracle Access Managementコンソールにログインします。たとえば: http://host:port/oamconsole。

    2. ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。

    3. 「起動パッド」タブで、「クイック・スタート・ウィザード」セクションの「SSOエージェント登録」をクリックします。

    4. エージェント・タイプとして「Webゲート」を選択し、「次」をクリックします。

    5. エージェント・バージョンを12cに設定し、必要な詳細(*が付いているもの)を入力します。

      • 名前
      • SharePointのユーザー名およびパスワード
      • セキュリティ・モード(エージェント・ホストはOAMサーバーと一致する必要があります)
      • ポリシーの自動作成(選択済)

      ノート:

      ベースURLを指定しないでください。

    6. 保護されているリソース・リスト: この表では、このOAMエージェントで保護する個々のリソースのURLを入力します。

    7. パブリック・リソース・リスト: この表では、公開する(保護しない)個々のリソースのURLを入力します。

    8. 「適用」をクリックして登録を送信し、確認ウィンドウで、生成されたアーティファクトの場所を確認し、ウィンドウを閉じます。

  3. 次の手順を実行します。

  4. Oracle Fusion Middleware 12cでは、Webゲート・ソフトウェアはOracle HTTP Server 12cソフトウェア・インストールの一部としてインストールされます。次のように、64ビットIIS Webゲート・インストーラを探してダウンロードします。

    1. 次のOracle Fusion Middleware 12cソフトウェア・ダウンロードに移動します。

      https://www.oracle.com/security/identity-management/technologies/downloads/

    2. ページの一番上のライセンス契約に同意をクリックします。

    3. Access Manager Webgatesの行から、該当するプラットフォームのダウンロード・リンクをクリックし、画面の指示に従います。

    4. インストールしようとする12cアクセス・システム言語パックと同じディレクトリに、Webゲート・インストーラを格納します。

  5. 使用プラットフォーム、インストール・モードおよびWebサーバー用のWebGateインストーラを起動します。

    次のステップを実行します。

    1. 画面に表示されるプロンプトに従います。

    2. Webサーバーの管理者資格証明を指定します。

    3. 言語パック - デフォルトのロケールとインストールするその他のロケールを選択して、「次へ」をクリックします。

    4. WebGateのインストールが始まります(IISImpersonationModule.dllはWebGate_install_dir\webgate\iis\libにインストールされます)。

  6. Webサーバー構成を更新する前に、WebGateアーティファクトをAdmin ServerからWebGateをホストしているコンピュータにコピーします。

    1. Oracle Access Managementコンソール(AdminServer)をホストしているコンピュータでObAccessClient.xml (およびすべての証明書アーティファクト)を探してコピーします。

      $DOMAIN_HOME/output/$Agent_Name/

      • ObAccessClient.xml
      • password.xml (必要な場合)
      • aaa_key.pem (openSSLによって生成される秘密キー)
      • aaa_cert.pem (PEM形式の署名済証明書)

    2. OAMエージェントのホストで、アーティファクトをWebGateパスに追加します。たとえば:

      • WebGate_instance_dir/webgate/config/ObAccessClient.xml
      • WebGate_instance_dir/webgate/config/

    3. WebGate Webサーバーを再起動します。

    4. (オプション。)このエージェントをホストするOAMサーバーを再起動します。このステップは推奨されますが、必須ではありません。

  7. 必要に応じて次に進み、使用中の環境内でこの統合を完了します。

50.5 Microsoft SharePoint Serverとの統合

Webアプリケーションまたはサイト・アプリケーションを新規作成することで、Microsoft SharePoint Serverと統合できます。

次の概要では、この統合のために実行する必要があるタスクと、ステップおよび詳細に関する項目について説明します。

カスタム・メンバーシップ・プロバイダ・ライブラリ(OAMCustomMembershipProvider.dll)は、パッケージ化されIIS Web Serverの10g WebGateを使用してインストールされます。次に説明するように、SharePoint Serverをホストするコンピュータのグローバル・アセンブリ・キャッシュにライブラリをデプロイする必要があります。

タスクの概要: Microsoft SharePoint Serverとの統合には次の項目が含まれます

  1. 前提条件となるタスクの実行

  2. SharePoint Serverでの新規Webアプリケーション(またはサイト・アプリケーション)の作成は、次のトピックで説明します。

  3. 「Microsoft Windowsの偽装の設定」(LDAPメンバーシップ・プロバイダでは使用しません)。

  4. 「SharePoint Serverの統合の完了」。

  5. 「Microsoft SharePoint Serverのためのシングル・サインオフの構成」。

  6. 「ディレクトリ間のユーザー・プロファイルの同期化」。

  7. 「統合のテスト」。

50.5.1 Microsoft SharePoint Serverでの新規Webアプリケーションの作成

LDAPメンバーシップ・プロバイダを使用してまたは使用せずにMicrosoft SharePoint Serverで新しいWebアプリケーションを作成できます。

Microsoft SharePoint Serverとの統合時に、LDAPメンバーシップ・プロバイダを使用してまたは使用せずにこのタスクを実行します。

Prerequisites

Microsoftのコンポーネントのインストール。「必要なMicrosoftのコンポーネント」を参照してください。

Microsoft SharePoint Serverで新規Webアプリケーションを作成する手順

  1. SharePoint Serverがインストールされているホストで、「集中管理」ホーム・ページを開きます: 「起動」、「すべてのプログラム」、SharePoint製品、SharePoint、「集中管理」。
  2. 「集中管理」ホーム・ページから、アプリケーション管理をクリックします。
  3. アプリケーション管理ページの「Webアプリケーション」から、「Webアプリケーションの管理」をクリックします。
  4. 左上隅で、「新規作成」ボタンをクリックして新規Webアプリケーションを作成します。
  5. 新規Webアプリケーションの作成ページで表50-3の項目を構成します。

    表50-3 Microsoft SharePoint ServerのWebアプリケーションの作成オプション

    セクション この項で構成するもの

    認証

    この項では、要求ベースの認証またはクラシック・モード認証のどちらか該当する方を選択します。

    IIS Webサイト

    この項では、次のように、新規Webアプリケーションに対して次の設定を構成します。

    • 既存のWebサイトを選択するには、「既存のWebサイトを使用する」をクリックします。

    • 新規のサイトを作成するには、「作成」をクリックします。

    • ポート・フィールドで、Webアプリケーションへのアクセスに使用するポート番号を入力します。

      新規Webサイトの場合、このフィールドにはデフォルトのポート番号が入っています。既存のサイトの場合、このフィールドには現在構成されているポート番号が入っています。

    • オプションのホスト・ヘッダー・フィールドに、WebアプリケーションにアクセスするためのURLを入力します。

    • 「パス」フィールドに、サーバー上のサイトを含むディレクトリへのパスを入力します。

      新規Webサイトの場合、このフィールドにはデフォルトのパスが入っています。既存のサイトの場合、このフィールドには現在のパスが入っています。

    セキュリティ構成

    この項では、次のように、使用中のWebアプリケーションに対して認証と暗号化を構成します。

    • 「認証プロバイダ」セクションで、適宜、「ネゴシエート(Kerberos)」または「NTLM」を選択します。

    • 「匿名を許可」セクションで、「はい」または「いいえ」を選択します。

      値が「はい」の場合、コンピュータ固有の匿名アクセス・アカウントを使用して、Webサイトへの匿名アクセスが許可されます。アカウント名はIUSR_コンピュータ名です。

    • 「Secure Sockets Layer」(SSL)セクションで、「はい」または「いいえ」を選択します。

      Webサイトに対してSSLを有効にすることを選択すると、証明書をリクエストしてインストールすることによってSSLを構成する必要があります。

    パブリックURL

    このWebアプリケーションでユーザーがアクセスするすべてのサイトのドメイン名のURLを入力します。このURLドメインは、Webアプリケーションのページに表示されるすべてのリンクで使用されます。デフォルトでは、このボックスには現在のサーバー名およびポートが移入されます。「ゾーン」フィールドは、新規Webアプリケーションのデフォルトに自動的に設定され、このページからは変更できません。

    アプリケーション・プール

    「アプリケーション・プール」セクションでは、次のように、このWebアプリケーションに対して既存のアプリケーション・プールを使用するか新規アプリケーション・プールを作成するかを選択します。

    • 既存のアプリケーション・プールを使用するには、「既存のアプリケーション・プールを使用」を選択し、ドロップダウン・メニューから使用するアプリケーション・プールを選択します。

    • 新規アプリケーション・プールを作成するには、「新規アプリケーション・プールの作成」を選択し、アプリケーション・プール名フィールドに、新規アプリケーション・プールの名前を入力するか、デフォルト名のままにします。

      「このアプリケーション・プール用のセキュリティ・アカウントを選択する」セクションで、「事前定義」を選択して既存のアプリケーション・プールのセキュリティ・アカウントを使用し、ドロップダウン・メニューからセキュリティ・アカウントを選択します。既存のアプリケーション・プールに現在使用されていないセキュリティ・アカウントを使用するには、構成可能を選択し、使用するアカウントのユーザー名を「ユーザー名」フィールドに入力し、そのアカウントのパスワードを「パスワード」フィールドに入力します。

    データベース名および認証

    この項では、新規Webアプリケーションに対してデータベース・サーバー、データベース名および認証メソッドを選択します。

    「データベース名」フィールドに、データベースの名前を入力するか、デフォルト・エントリを使用します。データベース認証フィールドで、次のように、Windows認証(推奨)を使用するかSQL認証を使用するかを選択します。

    • Windows認証を使用する場合、このオプションを選択したままにします。

    • SQL認証を使用する場合、SQL認証を選択します。「アカウント」フィールドに、SQL Serverデータベースに対して認証するためにWebアプリケーションが使用するアカウント名を入力し、「パスワード」フィールドにパスワードを入力します。

    フェイルオーバー・サーバー

    オプションで、フェイルオーバー・データベース・サーバーを指定してフェイルオーバー・サーバーを構成することを選択できます。

    サービス・アプリケーション接続

    デフォルト値を使用するか、カスタム値を選択できます。また、オプションで、Webアプリケーションが接続するサービスを選択できます。
  6. 「OK」をクリックして新規Webアプリケーションを作成するか、「取消」をクリックしてプロセスを取り消し、アプリケーション管理ページに戻ります。
  7. 「Microsoft SharePoint Serverのための新規サイト・コレクションの作成」に進みます。

50.5.2 Microsoft SharePoint Serverのための新規サイト・コレクションの作成

LDAPメンバーシップ・プロバイダを使用してまたは使用せずにMicrosoft SharePoint Serverのための新しいサイト・コレクションを作成できます。

Microsoft SharePoint Serverのために新規サイト・コレクションを作成するには:

  1. アプリケーション管理ページのサイト・コレクション・セクションから、「サイト・コレクションの作成」をクリックします。
  2. 「サイト・コレクションの作成」ページの「Webアプリケーション」セクションで、次のように、サイト・コレクションをホストするWebアプリケーションを(「Webアプリケーション」ドロップダウン・リストから)選択するか、新規Webアプリケーションを作成してサイト・コレクションをホストします。

    表50-4 SharePoint Serverのサイト・コレクションをホストするWebアプリケーションの作成

    セクション この項で構成するもの

    割当て制限テンプレート

    適宜、事前定義済の割当てテンプレートを使用してこのサイト・コレクション用に使用するリソースを制限するか、「割当てなし」を使用できます。

    タイトルと説明

    サイト・コレクションのタイトルと説明の入力

    Webサイト・アドレス

    URLタイプを選択し、サイト・コレクションのURLを指定します。

    テンプレート

    タブ付きテンプレート制御からテンプレートを選択します。

    プライマリ・サイト・コレクション管理者

    サイト・コレクションのプライマリ管理者にするユーザーのユーザー・アカウント名を入力します。

    テキスト・ボックスの右にある「ブック」アイコンをクリックしてユーザー・アカウントを参照することも可能です。テキスト・ボックスの右にある「名前の確認」アイコンをクリックしてユーザー・アカウントを確認できます。

    セカンダリ・サイト・コレクション管理者(オプション)

    サイト・コレクションのセカンダリ管理者にするユーザーのユーザー・アカウントを入力します。

    テキスト・ボックスの右にある「ブック」アイコンをクリックしてユーザー・アカウントを参照することも可能です。テキスト・ボックスの右にある「名前の確認」アイコンをクリックしてユーザー・アカウントを確認できます。
  3. この統合を終了したら次のトピックを参照してください。

50.6 Microsoft Windowsの偽装の設定

Active Directory以外のディレクトリ・サーバーを使用する場合、LDAPメンバーシップ・プロバイダを使用してください。OAMCustomMembershipプロバイダは、LDAPメンバーシップ・プロバイダの機能を利用します。

この項では、SharePoint Serverの統合または他のアプリケーションによる使用のための偽装の設定について説明します。

ノート:

LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverと統合している場合、この項をスキップしてください。Windowsの偽装はLDAPメンバーシップ・プロバイダでは使用されません。

タスクの概要: 偽装の設定

  1. 「信頼できるユーザー・アカウントの作成」の説明に従って、SharePoint Serverに接続されたActive Directoryでの偽装に対してのみ信頼できるユーザー・アカウントを作成します。
  2. 「信頼できるユーザーへの権限の割当て」の説明に従って、オペレーティング・システムの一部として機能する特別な権限を信頼できるユーザーに付与します。
  3. 「信頼できるユーザーのWebGateへのバインド」の説明に従って、信頼できるユーザーの認証資格証明を提供して、信頼できるユーザーをWebゲートにバインドします。
  4. 「偽装レスポンスの認可ポリシーへの追加」の説明に従って、アプリケーション・ドメインで偽装のための認可成功アクションにIMPERSONATEという名前のヘッダー変数を追加します。
  5. 「偽装DLLのIISへの追加」の説明に従って、IISImpersonationModule.dllをIIS構成に追加して、IISを構成します。
  6. 「偽装のテスト」の説明に従って、偽装をテストします。

50.6.1 信頼できるユーザー・アカウントの作成

信頼できるユーザー・アカウントを作成できます。この特別なユーザーは、偽装以外には使用しないでください。

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

信頼できるユーザー・アカウントを作成するには::

  1. SharePoint Serverインストールをホストしているコンピュータで次のステップを実行します。

    • Windows: 「スタート」→「プログラム」→「管理ツール」→「Active Directoryユーザーとコンピュータ」の順に選択します。

  2. 「Active Directoryユーザーとコンピュータ」ウィンドウで、左ペインのツリーで「ユーザー」を右クリックし、「新規作成」→「ユーザー」の順に選択します。
  3. 「新規オブジェクト - ユーザー」というペインの1つ目の「名前」フィールドに、覚えやすい名前(Impersonatorなど)を入力します。
  4. この同じ文字列を「ユーザー ログオン名」フィールドにコピーし、「次へ」をクリックします。
  5. 次のパネルで、パスワードの選択と確認用の再入力を求められます。

ノート:

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

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

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

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

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

信頼できるユーザーに適切な権限を与えるには::

  1. 使用中の環境で次のステップを実行します。

    • Windows: 「スタート」→「プログラム」→「管理ツール」→「ローカル セキュリティ ポリシー」の順に選択します。

  2. 左ペインのツリーで、「ローカル ポリシー」の横のプラス・アイコン(+)をクリックします。
  3. 左ペインのツリーで「ユーザー権利の割り当て」をクリックします。
  4. 右ペインで「オペレーティング システムの一部として機能」をダブルクリックします。
  5. 「ユーザーまたはグループの追加」をクリックします。
  6. 「ユーザーまたはグループの追加」パネルで、信頼できるユーザーのユーザー・ログオン名(この例ではSPPSImpersonator)をユーザー名とグループ名のテキスト入力ボックスに入力し、「OK」をクリックして変更を登録します。

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

図50-2の説明が続きます
「図50-2 Windowsの偽装での信頼できるユーザーの権限の構成」の説明

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

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

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

信頼できるユーザーをWebGateにバインドする手順

  1. Oracle Access Managementコンソールに移動します。

    たとえば:

    http://hostname:port/oamconsole

    ここで、hostnameはOracle Access Managementコンソールをホストしているコンピュータの完全修飾DNS名、portはOAMサーバー用に構成されたリスニング・ポート、oamconsoleはOracle Access Managementコンソールです。

  2. ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。

  3. 「起動パッド」タブで、「クイック・スタート・ウィザード」セクションの「SSOエージェント登録」をクリックします。

  4. エージェント・タイプとして「Webゲート」を選択し、「次」をクリックします。

  5. バージョンを12cに設定し、必要な詳細(*が付いているもの)を入力して、このWebゲートを登録します。

  6. 保護されているリソース・リスト: この表では、表14-9にあるように、このOAMエージェントで保護する個々のリソースのURLを入力します。

  7. パブリック・リソース・リスト: この表では、表14-9にあるように、公開する(保護しない)個々のリソースのURLを入力します。

  8. 「ポリシーの自動作成」: 新規ポリシーの作成をチェックします(または、クリアして別のWebGateと同じホスト識別子を使用してポリシーを共有します(表14-9))。

  9. 「適用」をクリックして、登録を送信します。

  10. 「確認」ウィンドウで、生成されたアーティファクトの場所を確認し、ウィンドウを閉じます。

  11. ナビゲーション・ツリーで、「エージェント」ページを開きます。

  12. SharePointの要件: Sharepointインパーソネータ・フィールドに信頼できるユーザー資格証明を入力し、「適用」をクリックします。

  13. 次のようにアーティファクトをコピーします(またはWebGateをインストールしてからこれらのアーティファクトをコピーします)。

    1. Oracle Access Managementコンソールのホストで、更新されたOAMエージェントの構成ファイルObAccessClient.xml (およびすべての証明書アーティファクト)を検索します。たとえば:

      $DOMAIN_HOME/output/$Agent_Name/ObAccessClient.xml

    2. エージェントをホストしているコンピュータで、アーティファクトをコピーします。たとえば

      • 12c WebGate/AccessClient: $WebGate_instance_dir/webgate/config/ObAccessClient.xml
      • ObAccessClient.xml

    3. 「偽装レスポンスの認可ポリシーへの追加」に進みます。

50.6.4 偽装レスポンスの認可ポリシーへの追加

SharePointリソースを保護するアプリケーション・ドメインおよび基本ポリシーは、WebGateをAccess Managerに登録したときに作成されました。戻りタイプを「ヘッダー」として認可成功アクション(レスポンス)を追加し、名前をIMPERSONATEに設定し、レスポンス値を$user.userid (シングルドメインのActive Directoryインストールの場合は"samaccountname"、マルチドメインのActive Directoryフォレストの場合は"userPrincipalName")とする必要があります。

偽装レスポンスを認可ポリシーに追加するには::

  1. コンソール・ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
  2. 「起動パッド」タブで、「Access Manager」セクションの「アプリケーション・ドメイン」をクリックします。
  3. 目的のドメインを検索して、編集のために開きます。
  4. 「認証ポリシー」タブをクリックし、目的のポリシーを編集のために開きます。

    "目的のドメイン"とは、偽装専用に作成したアプリケーション・ドメイン(Impersonationなど)のことです。"目的のポリシー"は、エージェント登録中に作成されたデフォルトのポリシーです。デフォルトでは、ユーザーが作成するまでポリシー・レスポンスは存在しません。

  5. 「ポリシー」ページで「レスポンス」タブをクリックし、「追加」(+)ボタンをクリックして、次の操作を実行します。

    • 「タイプ」リストから「ヘッダー」を選択します。

    • 「名前」フィールドに、このレスポンスの一意の名前を入力します: IMPERSONATE

    • 「値」フィールドに、このレスポンスの値を入力します。たとえば: $user.userid。

  6. 「追加」をクリックして、2つ目のWebゲート・リクエスト(認可用)に使用されるレスポンスを保存します。

50.6.5 偽装DLLのIISへの追加

偽装DLLをIISに追加できます。

この統合のためにIIS Webサーバーを構成するには、すべてのサイト(中央管理およびWebサービスを含む)でIISImpersonationModule.dllを登録して構成します。

または、複数のWebサイトがあり、その一部がAccess Managerに統合されていて、残りが統合されていない場合、Access Managerに統合されてしるWebサイトに対してのみ偽装を有効にする必要があります。そのためには、統合が必要なサイトのみでネイティブ・モジュールを構成する必要があります。参照:

50.6.5.1 IISに対するImpersonationModuleの構成および登録

IISに対してImpersonationModuleを構成および登録できます。

IISに対してImpersonationModuleを構成して登録するには:

  1. 「スタート」→「管理ツール」→「インターネット インフォメーション サービス(IIS)マネージャ」の順に選択します。
  2. IISの左ペインで、ホスト名をクリックします。
  3. 中央ペインで、「IIS」ヘッダーの下の「モジュール」をダブルクリックします。
  4. 右ペインで「ネイティブ モジュールを構成」をクリックして「登録」をクリックします。
  5. ウィンドウに、モジュール名(たとえば、Oracle偽装モジュール)を入力します。
  6. 「パス」フィールドに、IISImpersonationModule.dllへのフルパスを入力します。

    デフォルトでは、パスは次のとおりです。

    WebGate_Install_DIR\webgate\iis\lib\Impersonation.dll

    ここで、WebGate_install_dirはWebGateインストールのディレクトリです。

    ノート:

    パスにスペースが存在する場合(たとえば、C:\Program Files\Oracle\...)文字列全体を二重引用符(" ")で囲みます。

  7. 「OK」をクリックして、モジュールを登録します。
  8. 新しく作成したモジュールの名前を確認し、「OK」をクリックして、各Webサイトにモジュールを適用します。
  9. IISImpersonationModule.dllをIISのネイティブ・モジュールとして追加します。
    偽装モジュールの登録の構成
  10. IISImpersonationModule.dllは、サイト・レベルでのみネイティブ・モジュールとして構成します(グローバル・レベルではありません)。
    サイト・レベルでの偽装モジュールの構成
  11. IISImpersonationModule.dllは、統合のためにサイト・レベルでHttpモジュール内のSPWindowsClaimAthenticationHttpModuleの上側に配置する必要があります。SPWindowsClaimAthenticationHttpModuleの上側にIISImpersonationModule.dllを移動するには、すべてのネイティブ・モジュールをIISグローバル・レベルでHttpモジュールからロック解除する必要があります。
    SPWindowsClaimAthenticationHttpModuleの上側に偽装モジュールを移動する、

50.6.6 偽装のテスト

統合を完了する前に、テストして偽装が正しく機能していることを確認できます。

偽装をテストする方法は次のとおりです。

関連項目:

偽装の構成が正しく機能することを確認した後に、「SharePoint Serverの統合の完了」を参照してください。

50.6.6.1 SharePoint Serverによって保護されていないIIS仮想サイトの作成

SharePoint Server外の偽装機能をテストするまたはシングル・サインオンをテストするには、SharePoint Serverによって保護されていないIIS仮想Webサイト上にターゲットWebページが必要です。

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

SharePoint Serverによって保護されていないIIS仮想サイトを作成するには:

  1. 「スタート」→「管理ツール」→「インターネット インフォメーション サービス(IIS)マネージャ」の順に選択します。
  2. 左ペインにあるツリー上のローカル・コンピュータのアイコンの左側のプラス・アイコン(+)をクリックします。
  3. 左ペインにあるツリー上のWebサイトを右クリックして、メニューの「新規作成」、「Webサイト」に移動します。
  4. 「Webサイト作成」ウィザードでプロンプトに応答します。
  5. 仮想サイトを作成した後、これをアプリケーション・ドメインのポリシーで保護する必要があります。
50.6.6.2 イベント・ビューアを使用した偽装のテスト

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

イベント・ビューアを使用して偽装をテストするには::

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

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

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

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

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

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

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

サーバー変数を表示するWebページを使用して偽装をテストするには:

  1. パラメータAUTH_USERおよびIMPERSONATEを表示する.aspページまたはPerlスクリプトを作成します。これは、次のリストに示すサンプル・ページに似せることができます。

    サンプルの.ASPページ・コード:

    <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>
  2. IIS仮想サイトを作成するかまたは前のタスクで作成したものを使用します。
  3. 新規仮想サイトのツリーのどこかに.aspページまたはPerlスクリプト(前のリストのサンプルなど)を配置します。
  4. ブラウザで表示するページを指定し、要求を発行するユーザーの名前にAUTH_USERとIMPERSONATEの両方を設定します。
50.6.6.4 偽装のネガティブ・テスト

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

信頼できるユーザーをWebGateからアンバインドするには::

  1. Oracle Access Managementコンソールで、Webゲートを探します。
  2. 必要なWebGate登録ページを開いて、信頼できるユーザーの資格証明を削除します。
  3. 「適用」をクリックして変更を保存します。
  4. ブラウザ・ウィンドウでIISサーバーを再起動し、保護されているコード・ページ(信頼できるユーザーが以前アクセスできたページ)に移動します。
  5. ページが表示されるというメッセージを受信することを確認します。AUTH_USERとIMPERSONATEの値は、偽装資格証明をWebGateにバインドするために必要です。
  6. 信頼できるユーザーをWebGate登録ページにリストアします。

50.7 SharePoint Serverの統合の完了

Access ManagerとSharePoint Serverとの統合を設定するためには、複数の手順を実行する必要があります。

LDAPメンバーシップ・プロバイダを使用して構成されたSharePoint Serverと統合している場合、この項をスキップしてください。

タスクの概要: SharePoint Serverの統合の完了

  1. 「IISセキュリティの構成」の説明に従って、IISセキュリティを設定します。
  2. 「SharePoint Serverの統合のテスト」の説明に従って、統合をテストします。

50.7.1 IISセキュリティの構成

続行する前にIISセキュリティを構成します。

SharePoint Serverの統合のためにIISセキュリティを構成するには:

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

図50-4 偽装認証

図50-4の説明が続きます
「図50-4 偽装認証」の説明

50.8 LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverとの統合

このシナリオでは、Access Managerは、SharePoint Security Token Service (STS)を使用してSharePoint Serverと統合されます。これには、IISへのISAPI WebGateインストール、Access Managerの構成およびHeaderVarの統合を実現するために必要なステップが含まれます。

ノート:

この統合には、64ビットISAPI WebGateのみがサポートされます。

次の概要では、この統合のために実行する必要があるタスク(前提条件を含む)と、各タスクに必要な情報がある場所について説明します。

「タスクの概要: LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverとの統合」

  1. この統合の準備

    1. 説明に従って、「必要なMicrosoftのコンポーネント」をインストールします。

    2. 「Microsoft SharePoint Serverでの新規Webアプリケーションの作成」の説明に従って、SharePoint Webサイトを作成します。

    3. 「Microsoft SharePoint Serverのための新規サイト・コレクションの作成」の説明に従って、SharePointサイト・コレクションを構成します。

    4. SharePointのドキュメントの説明に従って、要求ベースの認証タイプ(LDAPメンバーシップ・プロバイダを使用)を使用して、作成したWebサイトをLDAPディレクトリに対して構成します。

    5. LDAPディレクトリに存在するユーザーがSharePoint Webサイトにログインして適切なロールを取得できることを確認します。

    6. SharePointのドキュメントの説明に従って、構成をテストして、LDAPディレクトリに存在するユーザーがSharePoint Webサイトにログインして適切なロールを取得できることを確認します。

  2. 「LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint ServerのためのAccess Managerのインストール」の説明に従って、すべてのタスクを実行します。

    このタスクには、IIS対応12c Webゲートのインストールと、個別のSharePoint WebサイトのためのWebGate.dllの構成が含まれます。

  3. 「LDAPメンバーシップ・プロバイダを使用するための認証スキームの構成」の説明に従って、この統合の認証スキームを追加します。

  4. 「ディレクトリ・サーバーが同期化されていることの確認」の説明に従って、必要に応じてディレクトリ・サーバーを同期化します。

  5. 「Officeドキュメントのためのシングル・サインオンの構成」の説明に従って、Officeドキュメントのシングル・サインオンを構成します。

  6. 「Microsoft SharePoint Serverのためのシングル・サインオフの構成」の説明に従って、シングル・サインオフを構成します。

  7. 「統合のテスト」の説明に従って、統合をテストして問題なく機能することを確認して終了します。

50.8.1 LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverとの統合について

前のシナリオ「Microsoft SharePoint Serverとの統合」では、Windows認証の使用方法を説明しています。そのシナリオでは、認証および認可は、Active Directoryに存在するユーザーに対して実行されます。Access Managerは、統合のためにWindowsの偽装を使用しました。

この項で説明する統合の場合、LDAPメンバーシップ・プロバイダのサポートは、HeaderVarベースの統合によって実現されます。ISAPI WebGateフィルタは、WebリソースのHTTPリクエストを捕捉し、OAMサーバーと連動して、リクエストをしたユーザーを認証します。認証が成功すると、WebGateは、OAMAuthnCookieを作成し、これをユーザーのブラウザに送信して、シングル・サインオン(SSO)を容易にします。WebGateは、このユーザー・セッションのHeaderVarアクションとしてOAM_REMOTE_USERの設定も行います。SharePointのOracleカスタム・メンバーシップ・プロバイダは、HTTP検証メソッドを使用してObSSOCookieを検証します。これにより、Access Managerのカスタム・メンバーシップ・プロバイダは、HTTP/HTTPSリクエストを保護されたリソースに対して実行します。その後で、Access Managerは認可の成功時にOAM_REMOTE_USERで返されたユーザー・ログインを検証して比較します。

関連項目:

この章で説明するこの統合と他の統合の処理の違いについては、「SharePoint Serverとの統合の概要」を参照してください。

要件: この統合では、Microsoft SharePoint Serverに次の要件があります。

  • LDAPメンバーシップ・プロバイダと統合されている必要があり、Windows認証を使用することは許可されない

  • 要求ベースの認証を使用してWebサイトで構成したIISImpersonationModule.dllを持つことは許可されない

関連項目:

「統合の要件」

50.8.2 LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint ServerのためのAccess Managerのインストール

LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverと統合するためのインストールを準備できます。

Prerequisites

前の「LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverとの統合について」のステップ1を実行します。

LDAPメンバーシップ・プロバイダを含む統合のデプロイメントを準備するには:

  1. Oracle Identity ManagementおよびAccess Managerをインストールします。

  2. IIS WebGateゲートをプロビジョニングしてインストールします。

  3. 保護の対象となるSharePoint WebサイトでWebgate.dllを構成します。たとえば:

    1. インターネット・インフォメーション・サービス(IIS)マネージャを起動します(「スタート」→「管理ツール」→「Internet Information Services (IIS) Manager」をクリックします)。

    2. 「Webサイト」で、保護するSharePoint Webサイトの名前をダブルクリックします。

    3. 中央ペインで、「IISフィルタ」をダブルクリックし、右ペインで「追加」をクリックします。

    4. フィルタ名をOracle WebGateと入力します。

    5. Webgate.dllファイルに次のパスを入力します。 

      WebGate_install_dir\webgate\iis\lib

    6. これらの変更を保存して適用します。

    7. 中央ペインで、「認証」をダブルクリックします。

    8. Internet Information Services設定が正しいことを確認します。匿名認証とフォーム認証が有効になっており、Windows認証が無効になっている必要があります。

      ノート:

      要求ベースの認証をAccess Managerで使用する場合、SharePointサイトのWindows認証を無効にする必要があります。

    9. これらの変更を保存して適用します。

  4. IIS WebサイトでConfigureIISWebGate.batツールを実行します。

    ノート:

    ConfigureIISwebgate.batツールを実行する際は、サイト名を英数字にする必要があります。

    例: configureIISwebgate -w C:\Oracle_WebGateInstance -oh C:\Oracle_WebGateHome -site "Default WebSite"

  5. 「LDAPメンバーシップ・プロバイダを使用するための認証スキームの構成」に進みます。

50.8.3 LDAPメンバーシップ・プロバイダを使用するための認証スキームの構成

統合にLDAPメンバーシップ・プロバイダが含まれる場合、3つのAccess Manager認証メソッドのみがサポートされます。

LDAPメンバーシップ・プロバイダを使用したSharePointのための認証スキームを構成するには::

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
  2. 「起動パッド」タブで、「Access Manager」セクションの「作成」(+)ドロップダウン・メニューから「認証スキームの作成」を選択します。
  3. 「認証スキーム」ページで、次の項目を入力します。

    「名前」: このスキームの一意の名前を入力します。たとえば: SharePoint w/LDAP-MP

    説明: オプション

  4. 「認証レベル」: スキームのセキュリティのレベルを選択します。
  5. 「チャレンジ・メソッド」を選択します。

    SharePoint Webサイトのルート(/)に対する基本認証

    SharePoint Webサイトのルート(/)に対する「チャレンジ・リダイレクト」を使用したフォーム認証

    SharePoint Webサイトのルート(/)に対するクライアント資格証明認証

  6. 「チャレンジ・リダイレクト」: 必要に応じて、チャレンジ・リダイレクト値を入力します。
  7. リストの中から「認証モジュール」を選択します。
  8. 「チャレンジ・パラメータ」: 必要に応じて、チャレンジ・パラメータ値を入力します。
  9. 「チャレンジURL」: 資格証明コレクションのために資格証明コレクタがリダイレクトするURL。
  10. 「適用」をクリックして新しいスキームを送信し、確認ウィンドウで詳細を確認します。
  11. オプション: 「デフォルトとして設定」ボタンをクリックして、新しいアプリケーション・ドメインでこれを自動的に使用し、確認ウィンドウを閉じます。
  12. ナビゲーション・ツリーで、新しいスキームがリストされていることを確認し、ページを閉じます。

50.8.4 FBAを使用したSharePoint ServerとOAM 12cの統合

Access Managerは、FBA (OAMCustomMembershipProvider)を使用してSharePoint 2013 OAM 12cと統合されます。この統合の場合は、次のステップを実行する必要があります。

  1. WebGateプロファイル(統合に使用するプロファイル)を更新します。ユーザー定義パラメータIISIntegrationMode=trueを入力します。
  2. Office統合と「エクスプローラで開く」機能のサポートのために、認証スキームの「チャレンジ・パラメータ」をssoCookie=max-age=<time in seconds>に更新し、永続CookieとしてOAMAuthnCookieを作成して、そのCookieをWebDAVブラウザに伝播します。
  3. 次のコマンドを使用して、GAC (グローバル・アセンブリ・キャッシュ)にOAMCustomMembershipProvider.dllを追加します。
    gacutil -I OAMCustomMembershipProvider.dll
  4. SharePoint WebサービスSecureTokenServiceApplicationのweb.configを更新し、SecureTokenServiceApplicationメンバーシップ・プロバイダで次の行を置き換えます。

    ノート: サンプルweb.configは、<physical path of the SecurityTokenServiceApplication>\web.configにあります。たとえば、C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\WebServices\SecurityToken\web.configです。 

    type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" 
    type="Oracle.OAMCustomMembershipProvider, OAMCustomMembershipProvider, Version=12.2.1.4, Culture=neutral, PublicKeyToken=52e6b93f6f0427a1"
    ノート: 次のgacutilコマンドを実行して、web.configファイルで更新されるバージョン番号を取得します:
    .\gacutil.exe -l OAMCustomMembershipProvider
  5. SharePointサイトのdefault.apsxを更新して、</asp:login>タグの後ろに次の内容を追加します。

    ノート: サンプルdefault.aspxは、<physical path of the site>\_forms\default.aspxにあります。たとえば、C:\inetpub\wwwroot\wss\VirtualDirectories\3823\_forms\default.aspxです。 

    <asp:HiddenField EnableViewState="false" ID="loginTracker" runat="server" Value="autoLogin" /> 
<% 
bool autoLogin = loginTracker.Value == "autoLogin"; 
%> 
<script runat="server"> 
void Page_Load() 
{
	signInControl.LoginError += new EventHandler(OnLoginError); 
	NameValueCollection headers = Request.ServerVariables; 
	NameValueCollection queryString = Request.QueryString; 
	string loginasanotheruser = queryString.Get("loginasanotheruser"); 
	string username = Request.ServerVariables.Get("HTTP_OAM_REMOTE_USER"); 
	bool isOAMCredsPresent = username != null && username.Length > 0; 
	bool signInAsDifferentUser = loginasanotheruser != null && loginasanotheruser.Contains("true"); 
		if (isOAMCredsPresent) 
	{
		//Handling For UTF-8 Encoding in HeaderName 
		if (username.StartsWith("=?UTF-8?B?") && username.EndsWith("?=")) 
		{
			username = username.Substring("=?UTF-8?B?".Length, username.Length - 12); 
			byte[] decodedBytes = Convert.FromBase64String(username); 
			username = Encoding.UTF8.GetString(decodedBytes); 
		}
	}
		if (isOAMCredsPresent && loginTracker.Value == "autoLogin" && !signInAsDifferentUser) 
	{
		bool status=Microsoft.SharePoint.IdentityModel.SPClaimsUtility.AuthenticateFormsUser(new Uri(SPContext.Current.Site.Url),username,"dummy"); 		if(status)
		{
			if (Context.Request.QueryString.Keys.Count > 1) 
			{
				Response.Redirect(Context.Request.QueryString["Source"].ToString()); 
			}
			else 
			Response.Redirect(Context.Request.QueryString["ReturnUrl"].ToString()); 
		}
		else
		{
			loginTracker.Value = ""; 
		}
	}
}
void OnLoginError(object sender, EventArgs e) 
{
	loginTracker.Value = ""; 
}
</script> 
</asp:Content>

    ノート:

    前述のステップの実行後、ログイン時に次のエラーが発生した場合は、ステップ4と5で実行した構成の変更内容を元に戻してから、SharePointサイトへのアクセスを試行します。サイトへのログインは、OAMログインとSharePointログインの後に可能になります。それでもSharePointサイトにアクセスできない場合は、SharePointサーバーの代替アクセス・マッピングを構成してからSharePointサイトにアクセスしてみると、OAMログインとSharePointログインの後にサイトにアクセスできるようになります。ステップ4と5を再構成します。 

    Line 73: { 
Line 74: 
Line 75: bool 
status=Microsoft.SharePoint.IdentityModel.SPClaimsUtility.AuthenticateFormsUser(new Uri(SPContext.Current.Site.Url),username,"dummy"); 
Line 76: if(status){ 
Line 77: if (Context.Request.QueryString.Keys.Count > 1) 
Source File: 
c:\inetpub\wwwroot\wss\VirtualDirectories\3261\_forms\Default.aspx Line:75
Stack Trace: 
[NullReferenceException: Object reference not set to an instance of an object.] 
ASP._forms_default_aspx.Page_Load() in c:\inetpub\wwwroot\wss\VirtualDirectories\3261\_forms\Default.aspx:75 
Microsoft.SharePoint.WebControls.UnsecuredLayoutsPageBase.OnLoad(EventArgs e) +299 
Microsoft.SharePoint.IdentityModel.Pages.FormsSignInPage.OnLoad(EventArgs e) +18 
System.Web.UI.Control.LoadRecursive() +94 
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +2935
  6. IISサイトのHandlerMappingからOracleWebGateExtensionを削除します。

50.8.5 ディレクトリ・サーバーが同期化されていることの確認

Access Managerに対して構成されているディレクトリ・サーバーのユーザーは、SharePointによって使用されるディレクトリ・サーバーと同期している必要があります(これらが異なる場合)。

これは、この章の他の統合シナリオで実行したタスクと同じです。ただし、SharePointの統合にLDAPメンバーシップ・プロバイダが含まれている場合、LDAPコマンドをサポートするディレクトリ・サーバーを使用できます。

関連項目:

「ディレクトリ間のユーザー・プロファイルの同期化」

50.8.6 統合のテスト

これは、この章の他の統合シナリオで実行したタスクと似ています。LDAPメンバーシップ・プロバイダを使用して構成した場合、違いはありません。

関連項目:

「SharePoint Serverの統合のテスト」

50.9 Officeドキュメントのためのシングル・サインオンの構成

Officeドキュメントのためのシングル・サインオンは、認証スキームで永続Cookieを設定することによって実現できます。

OAM 12cを使用してこれを行うには、認証スキームにssoCookie=max-ageを設定する必要があります。こうすることによって、複数セッション継続する永続Cookieが作成されます。

ノート:

Windowsネイティブ認証に基づく統合の場合には、永続Cookieパラメータを設定する必要はありません。

  1. Oracle Access Managementコンソールにログインします。
  2. 使用する「認証スキーム」を探し、ページを開きます。
  3. 「チャレンジ・パラメータ」で、次を追加します。
      ssoCookie=max-age=1000000

    ここで、time-in-secondsは、Cookieが期限切れになるまでの時間間隔を表します。たとえば、ssoCookie=max-age=3600は、Cookieが1時間(3600秒)で期限切れになるように設定します。

  4. 変更内容を保存します。
  5. OAM Webゲートの集中ログアウトを構成します。

50.10 Microsoft SharePoint Serverのためのシングル・サインオフの構成

ユーザーがSharePoint Serverから「ログアウト」ボタンをクリックすると、手動ログアウトされます。ユーザーがSharePoint Serverサイトから「ログアウト」ボタンをクリックしたときにAccess Managerのログアウトもトリガーされるように、Access ManagerでSharePoint ServerのログアウトURLを構成できます。

安全にために、常に、サインオフした後にブラウザ・ウィンドウを閉じることをお薦めします。ユーザー・セッション全体がOAMAuthnCookieによって制御されていると、Cookieタイムアウトが発生します。次のユースケースについて考えてみます。

  • FedAuth Cookieがタイムアウトになり、OAMAuthnCookieが依然として有効: OAMAuthnCookieが存在するため、ユーザーは再チャレンジされません。新規FedAuth Cookieが生成されます(以前説明した同じフローを使用)。

  • OAMAuthnCookieがタイムアウトになり、FedAuth Cookieが依然として有効: 各リクエストがWebGateによって捕捉されるため、ユーザーは再び資格証明を求められます。

Access Managerは、ユーザー・セッションに単一のログアウト(グローバル・ログアウトまたは集中管理ログアウトとも呼ばれる)を提供します。Access Managerでは、単一のログアウトはアクティブなユーザー・セッションを終了するプロセスを意味します。

このトピックは、SharePointとの統合に関してシングル・サインオフを構成する方法を説明します。シングル・サインオフは、ユーザー・セッションを削除します。

50.10.1 SharePoint Serverでのカスタム・ログアウトURLの構成

SharePoint Serverでカスタム・ログアウトURLを構成できます。

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

  1. WebGateのために生成されたアーティファクトから、logout.htmlをSharePoint Serverサイトに追加します。
  2. C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\CONTROLTEMPLATESを探します。
  3. \CONTROLTEMPLATESで、次のタグを追加してwelcome.ascxを変更します。たとえば:
    <SharePoint:MenuItemTemplate runat="server" id="ID_OverrideLogout" Text="Custom Logout"       
   	  ClientOnClickNavigateUrl="/logout.html?end_url=_layouts/SignOut.aspx"
     Description="My Custom Logout"
   MenuGroupId="200"
   Sequence="100"
   UseShortId="true" />
  4. 「保存」をクリックします。
  5. 匿名認証を使用して、アプリケーション・ドメインの2つのURL(/_layouts/SignOut.aspxと/_layouts/closeConnection.aspx)を保護します。
  6. 「偽装を使用したSharePoint Serverでのログアウトの構成」に進みます。

50.10.2 偽装を使用したSharePoint Serverでのログアウトの構成

偽装を使用してSharePoint Serverでログアウトを構成できます。偽装を構成していない場合、この手順をスキップできます。

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

  1. signout.aspxをC:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTSから同じパスのMySignout.aspxにコピーします。
  2. MySignout.aspxの(<asp:content contentplaceholderid="PlaceHolderAdditionalPageHead" runat="server">)の下に、次のスクリプト詳細を追加します。
    <script runat="server">       
private void Page_Load(object sender, System.EventArgs e){
 Response.Status = "302 Moved Temporarily";
 Response.AddHeader("Location", "/logout.html?end_url=/_layouts/SignOut.aspx");}
</script>
  3. Save.
  4. 偽装の場合、このURL _layouts/Mysignout.aspxをSharePoint Serverのカスタム・ログアウトURLとして使用します。
  5. 「統合のテスト」に進みます。

50.11 Access ManagerとWindowsネイティブ認証の設定

この項では次のトピックを記載しています:

50.11.1 Access Manager WNAの設定

Windowsネイティブ認証を使用するようにAccess Managerを構成します。

50.11.2 SharePoint Serverを使用したWNAの設定

次の概要では、Access ManagerおよびSharePoint Serverを使用してWNAを設定するために実行する必要があるタスクを説明します。

タスクの概要: SharePoint Serverを使用したWNAの設定

  1. 次の前提条件となるタスクを実行します。

  2. 「WNAおよびSharePoint ServerのためのAccess Managerのインストール」の説明に従って、Access Managerをインストールします。

    このステップには、IIS対応WebGateのインストールと個別のSharePoint WebサイトのためのWebgate.dllの構成が含まれます。

  3. 次のようにActive Directory認証プロバイダを構成します。

    1. WebLogicコンソールにログインします。

    2. 「セキュリティ・レルム」に移動し、使用する「レルム」をクリックします。

    3. 「プロバイダ」タブに移動し、「新規」をクリックします。

    4. プロバイダ名を入力し、タイプActiveDirectoryAuthenticatorを選択して「OK」をクリックします。

    5. 新しく作成したプロバイダを選択し、「制御フラグ」を「十分」に変更して、保存します。

    6. 「プロバイダ固有」タブに移動し、Active Directoryの詳細を入力して、これらを保存します。

  4. 「WNA実装のテスト」を実行します。

50.11.3 WNAおよびSharePoint ServerのためのAccess Managerのインストール

「SharePoint Serverを使用したWNAの設定」のステップ1で説明しているすべての前提条件を実行した後、このタスクを実行します。この統合シナリオでほとんどのAccess Managerコンポーネントをインストールすることは、他のシチュエーションの場合と同じです。

IIS WebGateのインストールは、他の任意のWebGateのインストールと似ています。WebGateは、IIS v7 Webサーバーを使用してインストールする必要があります。後で、これを特定のSharePoint Webサイト・レベルで構成して保護できます。IISの場合、WebGateを「Webサイト」レベルで構成する必要があります。Microsoft SharePoint Serverの場合、WebGateを特定のSharePoint Webサイト・レベルで構成して保護する必要があります。

WNAおよびSharePoint ServerのためにAccess Managerをインストールするには:

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

  2. 次のようにしてISAPI Webゲートをインストールします。

    • Webゲートのインストール

    • IIS WebサーバーのためのWebコンポーネントのインストール

      次に、保護の対象となるSharePoint WebサイトでWebgate.dllを構成します。Webgate.dllを「Webサイト・レベル」で構成すると、IIS Webサーバー上のすべてのWebサイトが保護されます。しかし、Webgate.dllを「SharePoint Webサイト」で構成すると想定されるWebサイトのみが保護されます。

  3. 保護の対象となるSharePoint WebサイトでWebgate.dllを構成します。たとえば:

    1. インターネット・インフォメーション・サービス(IIS)マネージャを起動します(「スタート」→「プログラム」→「管理ツール」→「Internet Information Services (IIS) Manager」をクリックします)。

    2. 「Connections」ペインでhostnameを選択します。

    3. host nameの「Home」ペインで「ISAPI Filters」をダブルクリックし、Webgate.dllを検索します。存在する場合は選択して、「Action」ペインの「Remove」をクリックします。

    4. 「Connection」ペインの「Sites」の下で、WebGateフィルタを構成するWebサイト名をクリックします。

    5. 「Home」ペインで「ISAPI Filters」をダブルクリックします。

    6. 「Actions」ペインで「Add…」をクリックします。

    7. 「Add ISAPI Filter」ダイアログ・ボックスの「Filter name」テキスト・ボックスに、ISAPIフィルタの名前としてWebGateと入力します。

    8. 「Executable」ボックスにWebGate ISAPIフィルタ・ファイルのファイル・システム・パスを入力するか、省略記号ボタン(...)をクリックしてWebGate.dll ISAPIフィルタ・ファイルを含むフォルダに移動し、「OK」をクリックします。 

      WebGate_install_dir\access\oblix\apps\Webgate\bin\Webgate.dll

  4. 仮想ディレクトリの作成

    1. 「Sites」ペインを開き、ISAPIフィルタ(Webgate.dll)を構成したばかりのWebサイトを選択します。

    2. 「Action」ペインで「View Virtual Directories」をクリックし、「Add Virtual Directory」を選択します。

    3. 「Alias」フィールドにaccessを指定し、WebGateの\accessフォルダの物理パスを指定します(または、省略ボタン(...)をクリックして\accessフォルダに移動して、「OK」をクリックします)。 

      WebGate_install_dir\access\

  5. 仮想ディレクトリの権限の設定:

    1. ステップ3で作成したaccess仮想ディレクトリを選択します。

    2. accessの「Home」ペインで「Handler Mappings」をダブルクリックします。「Action」ペインで「Edit Feature Permissions…」を選択します。

    3. 「読取り」、「スクリプト」、「実行」を選択し、「OK」をクリックします。

  6. Windowsネイティブ認証を使用するようにAccess Managerを構成します。

  7. Microsoft SharePointで新規Webアプリケーションを作成するときに、Microsoft SharePoint Server認証をクラシック・モード認証に構成します。「認証プロバイダ」セクションで、ネゴシエート(Kerberos)を選択します。

  8. IISで新しく作成したSharePointサイトに移動します。

    1. 「認証」、Windows認証、詳細設定の順に開きます。

    2. 「Kernelモード認証を有効にする」を選択します。

    3. プロバイダを選択して、NTLMプロバイダを削除します。

    4. Negotiate:Kerberosを追加し、これを最上位レベルに移動します。

    5. IISを再起動します。

  9. 「WNA実装のテスト」に進みます。

50.11.4 WNA実装のテスト

次のステップを使用して、WNA実装が正しく動作していることを確認します。

WNA実装をテストするには:

  1. Windowsドメイン・ユーザー(またはADユーザーまたはADユーザー・アカウント)としてマシンにログインします。

    ログイン・アカウントは、Access Managerのユーザーであることも必要です。

  2. 保護されたリソースのURLを入力します。

50.12 ディレクトリ間のユーザー・プロファイルの同期化

SharePoint ServerのディレクトリとAccess Managerのディレクトリの間でユーザー・プロファイルを同期化する必要があります。

特に明記しないかぎり、このタスクは、この章のすべての統合シナリオで実行する必要があります。

ノート:

統合にLDAPメンバーシップ・プロバイダが含まれている場合、LDAPコマンドをサポートする任意のディレクトリ・サーバーを使用できます。

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

  • ユーザー・データのアップロード—Access ManagerのインストールがSharePoint Active Directory以外の任意のディレクトリ・サーバーに対して構成されている場合、他のディレクトリ・サーバーにあるユーザー・プロファイルをSharePoint Active Directoryにロードする必要があります。

    「統合のテスト」に進みます。

50.13 統合のテスト

タスクを完了して統合を有効にした後、テストして統合が動作していることを確認する必要があります。

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

50.13.1 SharePoint Serverの統合のテスト

Access Managerの認証とSharePoint Serverの認可を使用してSharePoint Serverのリソースにユーザーがアクセスできることを確認できます。

SharePoint Serverの統合をテストするには::

  1. ブラウザを使用して、任意のSharePoint Server Webページに移動します。

    資格証明を求められます。

  2. 必要な資格証明を提供してログインします。
  3. リクエストしたページを表示できることを確認します。
  4. オプション: イベント・ビューアを確認して、アクセス・リクエストが成功したことを確認します。

50.13.2 SharePoint Serverの統合のためのシングル・サインオンのテスト

資格証明を提供し、SharePoint Serverリソースにアクセスしたユーザーが(OAMAuthnCookieが期限切れになる前に)再び資格証明を提供せずに非SharePoint Serverリソースにアクセスできることを示してシングル・サインオンをテストすることもできます。

たとえば、Policy Managerで定義したリソースを使用します。シングル・サインオンが動作している場合、再び資格証明を提供する必要なく、ページへのアクセスが付与されます。

SharePoint Serverの統合のためにシングル・サインオンをテストするには::

  1. アプリケーション・ドメインを使用して新規仮想サイトを作成して保護します(または、すでに作成したものを使用します)。
  2. この仮想サイトのツリーのどこかにWebページを配置します。
  3. ブラウザを使用して、新規仮想サイトのページに移動します。

    すでに認証をパスしている場合、再び資格証明を提供する必要なく、ページへのアクセスが付与されます。

50.14 トラブルシューティング

50.14.1 Internet ExplorerがSSL経由によるファイルのダウンロードを実行できない

この問題は、サーバーがCache-control:no-storeヘッダーまたはCache-control:no-cacheヘッダーを送信している場合に発生します。WebGateは、構成パラメータを提供して、これらのヘッダーの設定を制御します。

次に、パラメータとそのデフォルト値を示します。

CachePragmaHeader no-cache

CacheControlHeader no-cache

WebGate構成を変更して、これらのヘッダーをまったく設定しないようにできます(これらのパラメータの値は空白のままになります)。こうすることによって、Access Managerはキャッシング動作を制御しなくなります。