| Oracle Access Manager統合ガイド 10g（10.1.4.2.0） E05809-01 |
|
 戻る |
 次へ |
SharePoint Portal Serverは、セキュアかつスケーラブルなエンタープライズ・ポータル・サーバーです。この章では、Microsoft SharePoint Portal Server 2003およびSharePoint Office Server 2007との統合方法について説明します。この章のトピックは次のとおりです。
Oracle Access Managerは、Webベース・シングル・サインオン、ユーザーのセルフサービスと自己登録、ユーザー・プロビジョニング、レポートと監査、ポリシー管理、動的グループ、委任管理などの、ID管理機能とセキュリティ機能を備えています。Oracle Access Manageは、すべての先進的なディレクトリ・サーバー、アプリケーション・サーバー、Webサーバー、エンタープライズ・アプリケーションとの統合が可能です。
SharePoint Portal Serverは、セキュアかつスケーラブルなエンタープライズ・ポータル・サーバーであり、Windows Server 2003 Microsoft Internet Information Services（IIS）とWindows SharePoint Services（WSS）上で構築されます。SharePoint Portal Serverにより、SharePointのサイト、情報、アプリケーションを、1つの使用しやすいポータルに集約することができます。SharePoint Portal Serverには、WSSの機能に加えて、ニュースやトピックなどの追加機能や、個人用サイトのパーソナル・ビューとパブリック・ビューなども組み込まれています。
SharePoint Office Server 2007は、コンテンツ、ビジネス・プロセスおよび情報共有に関する制御を強化します。Office SharePoint Office Server 2007は、ドキュメント、ファイル、Webコンテンツおよび電子メールに関する集中管理されたアクセスと制御を提供し、ユーザーが共同作業のためにポータルにファイルを送信することを可能にします。
Oracle Access ManagerをSharePoint Portal Server 2003またはSharePoint Office Server 2007と統合すると、IIS用ISAPIフィルタとISAPIワイルドカード拡張機能を使用してAccess Systemによってユーザー認証が処理されます。これにより、Oracle Access ManagerとSharePoint Portal Server間のシングル・サインオンが有効になります。WSSは、すべてのSharePoint Portal Serverリソースに対するリソース・リクエスト認可を処理します。
この統合により、SharePoint Portal Server 2003およびSharePoint Office Server 2007リソースとOracle Access Managerによって保護されるその他のすべてのリソースへのシングル・サインオンが実現されます。
この統合は、Windowsの偽装に依存しています。これにより、Windowsサーバー・ドメインの信頼できるユーザーを、SharePoint Portal Server 2003またはSharePoint Office Server 2007のターゲット・リソースをリクエストする任意のユーザーのIDとみなすことができます。この信頼できるユーザーは、任意のユーザーに代わってリソースにアクセスする際に、このユーザーのIDコンテキストを保持します。
偽装は、ユーザーに対して透過的に行われます。つまり、ユーザーから見た場合、SharePointリソースがAccess Systemドメイン内のリソースであるかのようにアクセスが行われます。
SharePoint Portal Server 2003またはSharePoint Office Server 2007と正常に統合するには、Oracle Access ManagerコンポーネントとMicrosoftコンポーネントが両方とも必要です。これらのコンポーネントのインストールと構成を行う場合、統合の他に偽装もサポートするように設定する必要があります。
この項のトピックは次のとおりです。
この章に記載されているバージョンとプラットフォームの参照情報は、説明用に記載されたものです。
サポートおよび動作要件については、次のURLを参照してください。
http://www.oracle.com/technology/documentation/
この情報を参照するには、OTNに登録する必要があります。
また、この統合用にサポートされているバージョンとプラットフォームを確認するには、次に示すMetalinkを参照してください。
Metalinkの情報を表示する手順
ブラウザで、次のURLを入力します。
Metalinkにログインします。
「Certify」タブをクリックします。
「View Certifications by Product」をクリックします。
「Application Server」オプションを選択して「Submit」をクリックします。
「Oracle Identity Management」を選択して「Submit」をクリックします。
「Oracle Identity Management Certification Information 10g (10.1.4.2.0) (html)」をクリックして、「Oracle Identity Management」ページを表示します。
セクション6、Oracle Access Managerの動作保証のリンクをクリックして、動作保証マトリックスを表示します。
表17-1は、SharePoint Portal Server 2003およびSharePoint Office Server 2007との統合に必要なMicrosoftコンポーネントを示したものです。
|
注意: 必ず、SP1以上をインストールして、すべての重要な更新を適用してください。 |
表17-1 Microsoft要件
| コンポーネント | 説明 |
|---|---|
|
オペレーティング・システム |
SharePoint Serverホスト用Windows Server 注意: 5種類のエディションのいずれも使用できます。 Active Directoryドメイン・コントローラは、Windows Server 2003コンピュータ上に配置されている必要があります。このコンピュータは、SharePoint Portal Serverホストである必要はありません。 |
|
拡張サービス |
|
|
ディレクトリ・サービス |
Active Directoryです。これは、Windows Server 2003のインストール後にインストールします。SharePoint Serverは、次のように、Active Directoryドメイン・コントローラまたはActive Directoryの異なるインスタンスと直接接続することができます。
注意: ここに記載されたすべてのシナリオのSharePoint Serverにおいて、Active Directoryドメイン内のマシンにインストールされたDesktop SQLまたはSQL Serverのインスタンスのいずれかが使用されます。 |
|
SharePoint Server |
SharePoint Server。Active Directoryのインストール後、Windows Server 2003とIISがすでにインストールされているコンピュータにSharePoint Portal Server 2003またはSharePoint Office Server 2007をインストールします。 |
|
セキュリティ・サービス |
Kerberos Key Distribution Center（KDC）が、Windows Server 2003の一部として自動的にインストールされます。 |
表17-2のコンポーネントは、SharePoint ServerおよびSharePoint Portal Serverとの統合に必要なコンポーネントです。
表17-2 コンポーネントの要件
| 項目 | 要件/説明 |
|---|---|
|
WebGate |
Oracle Access Managerに同梱されているISAPIバージョンのWebGateが、SPPSと同じマシン上に配置されている必要があります。 SPPS統合のコンテキスト内において、このWebGateはWebリソースのHTTPリクエストを捕捉するISAPIフィルタとして機能し、アクセス・サーバーと連携してこのリクエストを作成したユーザーの認証を行います。認証が正常に完了すると、WebGateはObSSOCookieを作成してユーザーのブラウザに送信し、シングル・サインオンを可能にします。WebGateは、このユーザー・セッション用のHeaderVarアクションとして、偽装の設定も行います。 |
|
IISImpersonationExtension. dll |
このdllは、Authorization Success Action HeaderVarの偽装が設定されているかどうかをチェックするIISワイルドカード拡張機能です。設定されている場合、dllによってKerberos U4S2Selfチケットが作成され、SPPS Active Directory内の特別な信頼できるユーザーは最初にリクエストを作成したユーザーになれます。 ISAPI WebGateインストール・ウィザードを実行すると、WebGateディレクトリ構造内にIISImpersonationExtension.dllが自動的にインストールされます。ただし、偽装とSPPS統合を有効にするには、dllを手動で構成する必要があります。 |
|
Oracle Access ManagerDirectory |
Oracle Access Managerは、LDAPとActive Directoryなど、サポートされるディレクトリ・サービスに接続できます。SPPSによって使用されるActive Directoryの同じインスタンスとも接続できます。 いずれの場合も、SPPSやSPPSを保護するWebGateと同じマシン上にディレクトリを配置する必要はありません。 |
|
その他のコンポーネント |
SPPSを統合する場合、他の標準的なOracle Access Managerのシステム・コンポーネント（SPPSのインストールを保護するWebGateと相互運用するように構成されたアクセス・サーバーなど）もインストールする必要があります。詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。 SPPSを保護するWebGateを除き、SPPSをホストするマシン上にコンポーネントを配置する必要はありません。 注意: ポリシー・マネージャまたはWebPass、あるいはその両方をSPPSと同じIIS仮想サーバーにインストールする場合、SharePoint管理対象パスを使用してこれらのコンポーネントへのURLパスを除外する必要があります。詳細は、「SharePointで管理対象パスを定義する手順」を参照してください。ポリシー・マネージャとWebPassは、SPPSとは異なるマシンにインストールするか、少なくともSPPSをインストールしたマシンとは異なるIIS仮想サーバーにインストールするほうが簡単です。 |
Oracle Access Managerは、Windowsの偽装機能を使用してSharePoint Portal Serverリソースへのユーザー・アクセスを容易にします。
プロセスの概要: SharePoint Portal Server統合を使用したリクエストの処理
ユーザーがSharePoint Portal Serverリソースへのアクセスをリクエストします。
SharePoint Portal Serverを保護するWebGate ISAPIフィルタがこのリクエストを捕捉し、ターゲット・リソースが保護されているかどうかを確認します。保護されている場合、認証資格証明に対してユーザーのチャレンジ認証を行います。
ユーザーが資格証明を入力し、アクセス・サーバーによってこの資格証明が検証されると、WebGateによってユーザーのブラウザにObSSOCookieが設定され、シングル・サインオンが有効になります。
WebGateにより、impersonateというHTTPヘッダー変数も設定されます。この変数の値は、認証されるユーザーのLDAP uidに設定されます（ユーザー・アカウントがActive Directoryに存在する場合はsamaccountname、ユーザー・アカウントがマルチドメインActive Directoryフォレストに存在する場合はuserPrincipalNameになります）。
|
注意: この時点では偽装はまだ設定されていないため、IISはユーザーを匿名ユーザーとして認識します。 |
Oracle Access Manager ISAPIワイルドカード拡張機能IISImpersonationExtension.dllは、impersonateという名前の認可成功アクション・ヘッダー変数があるかどうかを確認します。
このヘッダー変数が存在する場合、ワイルドカード拡張機能によってユーザーのKerberosチケットが取得されます。このService for User to Self（S4U2Self）偽装トークンにより、指定された信頼できるユーザーがリクエスト・ユーザーのIDを使用し、IISとSharePoint Portal Serverによるターゲット・リソースへのアクセス権限を取得します。
この章に記載されているバージョンとプラットフォームの参照情報は、説明用に記載されたものです。完全なサポート情報は、https://metalink.oracle.comの「Certify」タブを参照してください。
SharePoint Portal Serverとの統合には、いくつかのフェーズがあります。
タスクの概要: SharePoint Portal Serverとの統合
「Microsoftのコンポーネントのインストール」の説明に従って、Microsoftのコンポーネントをインストールします。
「Oracle Access Managerのコンポーネントのインストール」の説明に従って、Oracle Access Managerをインストールします。
「偽装の設定」の説明に従って、偽装を設定します。
「SharePoint Serverとの統合の完了」の説明に従って、統合を完了します。
特に記載がないかぎり、次のソフトウェアを含むMicrosoft SharePoint Portal Server関連のすべてのコンポーネントを、同じホスト・マシンにインストールする必要があります。
Windows Server 2003
Microsoft IIS v6 Web Server
SharePoint Portal Server（および基礎となるWSS）
次のMicrosoftコンポーネントは、メインのSharePoint Portal Serverのインストールをホストするマシン以外のマシンにインストールできます。
Active Directory（インストールの場所の詳細は、表17-1を参照）。
SQL Serverは、Active Directoryドメイン・コントローラがSharePoint Portal Serverと同じマシンにインストールされている場合にかぎり、Active Directoryドメイン内のマシンにインストールする必要があります。インストールの場所の詳細は、表17-1を参照してください。
追加SharePoint Portal Serverフロント・エンド・サーバー。
Webページ、ドキュメント、アプリケーションなどのSharePoint Portal Serverリソースを格納する1台以上のバック・エンド・サーバー。
|
注意: 前述のSharePoint Portal Server関連コンポーネントをホストするすべてのマシンは、インストールするSharePoint Portal Serverサーバーと同じActive Serverドメイン内に存在する必要があります。 |
次に示すタスクの概要には、この統合用にMicrosoftのコンポーネントをインストールする場合に行う必要がある手順を説明するドキュメントへの参照情報が含まれています。
タスクの概要: Microsoftのコンポーネントのインストール
該当するMicrosoftのドキュメントに従い、SharePoint Portal ServerのインストールをホストするマシンにWindows Server 2003をインストールします。
該当するMicrosoftのドキュメントに従い、SharePoint Portal ServerのインストールをホストするマシンにIISをインストールします。
該当するMicrosoftドキュメントと『Oracle Access Managerインストレーション・ガイド』の説明に従い、Active Directoryをインストールします。また、インストール場所の考慮事項は、表17-1を参照してください。
SharePoint Portal ServerとActive Directoryドメイン・コントローラが同じマシンにある場合は、表17-1に記載されているように、Microsoft SQL Serverもそのマシンにインストールする必要があります。
SharePoint ServicesとSharePoint Portal Serverは、IISインストールのルート仮想サーバー（デフォルトでポート80を使用する）または他のIIS仮想サーバーにインストールします。
ポータルを作成して設定します。
SharePoint Portal Serverのインストール後、Oracle Access Managerと統合する前に、インストール操作を停止してSharePoint Portal Serverが適切に機能するかどうかをテストします。
ポータルを作成します。
詳細は、「ポータルを作成する手順」を参照してください。
テストのドキュメントをアップロードします。
詳細は、「ドキュメントをポータルにアップロードする手順」を参照してください。
対象ユーザーを作成します。
詳細は、「対象ユーザーを作成する手順」を参照してください。
必要に応じて、対象ユーザーを編集します。
詳細は、「対象ユーザーを編集する手順」を参照してください。
対象ユーザーをコンパイルします。
詳細は、「対象ユーザーをコンパイルする手順」を参照してください。
ポータルを作成するサーバーの「SharePoint Portal Server Central Administration」ページの「Portal Site and Virtual Server Configuration」セクションで、「Create a portal site」をクリックします。
「Portal Creation Options」セクションで、「Create a portal」をクリックします。
「Site Name」セクションの「Name」ボックスに、ポータル・サイトの名前を入力します。この名前は、ポータル・サイトのほとんどのページで最上部に表示されます。
「Site URL」セクションの「Virtual server」リストで、ポータル・サイトをホストするサーバーの既存の仮想サーバーをクリックします。
「URL」ボックスに、ユーザーがポータル・サイトへの接続に使用するURLを入力します。デフォルトでは、このURLはhttp://server_name/になります。ポート番号が80以外の仮想サーバーを選択する場合は、http://server_name:port_number/のように、ポート番号がURLの一部として表示されます。
|
注意: ローカル・サーバーのURLではなく、ロード・バランスされたURLを指定してください。 |
「Owner」セクションの「Account name」ボックスに、Domain\user_nameの形式でポータル・サイト所有者のアカウント名を入力します。ポータル・サイト所有者は、コンテンツとユーザー・アクセスを管理します。
「E-mail address」ボックスにポータル・サイト所有者の電子メール・アドレスを入力し、「OK」をクリックします。
server_nameのポータル作成確認ページで「OK」をクリックし、ポータル・サイトの作成を開始します。
ポータルが作成されると、「Operation Status」のページが表示されます。ポータル・サイトが正常に作成されると、「Operation Successful」ページが表示されます。これで、ポータル・サイトの詳細な構成を開始できます。
Webブラウザを使用して、ポータルのホーム・ページに移動します。
「Actions」リストから「Upload Document」を選択します。
「Upload Document」のページで「Browse」をクリックして追加するドキュメントに移動し、「Open」をクリックします。
複数のドキュメントを同時に追加するには、「Upload Multiple Files」をクリックします。
ライブラリ内の同じ名前のファイルを置き換えるには、「Overwrite existing file(s)?」チェック・ボックスを選択します。
「Save」をクリックして「Close」をクリックします。
対象ユーザーは、組織内のジョブやタスクに基づいています。対象ユーザーは、指定されたユーザーをターゲット・コンテンツと一致させ、他のすべてのユーザーに対してターゲット・コンテンツの表示を禁止します。構成するサイトの「Managing Audiences」ページで、「Create audience」をクリックします。
「Create audience」ページで、対象ユーザーの名前と説明を入力します。
「Satisfy all rules」または「Satisfy any of the rules」をクリックして「OK」をクリックします。
「Add Audience Rule」ページが表示されたら、サイトのコンテンツへのアクセスを制御するルールを追加します。「View Audience Properties」ページからもルールを追加できます。詳細は、対象ユーザー・ルールの追加と編集に関するMicrosoft SharePoint Portal Serverドキュメントを参照してください。
コンテンツが対象ユーザーのターゲットとなるように対象ユーザーをコンパイルします。「対象ユーザーをコンパイルする手順」を参照してください。
構成するサイトの「View Audience Properties」ページで「View Audience Properties」をクリックし、「Edit audience」をクリックします。
「Edit audience」ページで、必要に応じて対象ユーザーの名前や説明を変更します。
「Satisfy all rules」または「Satisfy any of the rules」をクリックして「OK」をクリックします。
「View Audience Properties」ページが再度表示された場合は、必要に応じて対象ユーザー・ルールの追加、削除、編集を行います。
対象ユーザーの統計を確認し、現在のメンバー数と直近のコンパイル日時を確認します。対象ユーザーおよび対象ユーザーに関連するルールの設定がすべて終了したら、対象ユーザーをコンパイルして変更を有効にします。「対象ユーザーをコンパイルする手順」を参照してください。
対象ユーザーまたは対象ユーザーに関連するルールに対して行った変更は、対象ユーザーをコンパイルするまでは有効になりません。「Manage Audiences」ページに移動し、コンパイルのステータスとコンパイルする対象ユーザーの直近のコンパイル日時を確認します。このページで、不完全な対象ユーザーの数を表示することもできます。
コンパイルを開始するか、コンパイル・スケジュールを設定します。
SharePoint Portal Server用ISAPI WebGateは、SharePoint Portal Serverと同じマシンにインストールする必要があります。その他のインストールは、同じマシンでも、異なるマシンでも実行できます。
異なるマシン（Solaris、Linux、Windowsマシン）にインストールする場合、Active Directory用に設定することができます（ホスト・マシンでWindows Server 2003が実行されている場合）。または、NetScape Directory Serverなど他のディレクトリ・サービス用に設定することもできます（マシンでSolarisやLinuxなどが実行されている場合）。
Oracle Access ManagerとSharePoint Portal Serverの両方をActive Directoryの異なるインスタンスに対して設定する場合、両方のインスタンスが同じActive Directoryドメインに属している必要があります。
SharePoint Portal Serverとの統合用にOracle Access Managerコンポーネントをインストールする手順
SharePoint Portal Serverをホストするマシンと同じマシン（または異なるマシン）に、アイデンティティ・サーバーとWebPassをインストールします。次に、『Oracle Access Managerインストレーション・ガイド』の説明に従ってアイデンティティ・システムを設定します。WebPassをインストール場合の考慮事項は、表17-2を参照してください。
『Oracle Access Managerインストレーション・ガイド』と表17-2の説明に従い、SharePoint Portal Serverをホストするマシンと同じマシン（または異なるマシン）に、ポリシー・マネージャおよびアクセス・サーバーのインスタンスを1つ以上インストールします。
統合するSharePoint Portal Serverインスタンスをホストするマシンに、ISAPI WebGateをインストールします。
パッケージの一部として、IISImpersonationExtension.dllが次のディレクトリにインストールされます。
WebGate_install_dir\access\Oblix\apps\webgate\bin\
このWebGate_install_dirは、WebGateをインストールしたディレクトリです。
ポリシー・マネージャまたはWebPassをSharePoint Portal Serverと同じIIS仮想サーバーにインストールした場合、「SharePointの管理対象パスの定義」の操作を実行してください。
ポリシー・マネージャまたはWebPassがSharePoint Portal Serverと同じIIS仮想サーバーにあり、IIS仮想サーバーと同じポートをリスニングする場合にかぎり、次の手順を実行します。たとえば、デフォルトの仮想IISサーバーは、多くのポリシー・マネージャとWebPassのインストールと同じようにポート80を使用するため、アプリケーションが使用するポートを変更するか、SharePointの管理対象パスの定義機能を使用してOracle Access Managerコンポーネントが使用するパスを除外する必要があります。
「スタート」、「管理ツール」、「SharePoint Central Administration」の順に選択します。
「Virtual Server Configuration」セクションで、「Configure virtual server settings」をクリックします。
「Virtual Server」のリストで、「Default Web Site」をクリックするか、またはSharePoint Portal ServerとOracle Access Manager両方のコンポーネントがインストールされている仮想サーバーの名前をクリックします。
「Virtual Server Management」セクションで、「Define Managed Paths」を選択します。
「Add a Path」セクションでポリシー・マネージャまたはWebPassへのパスを入力し、「Excluded path」のボタンをクリックします。
「OK」をクリックし、除外されたパスのリストにパスを追加します。
SharePoint Office Server 2007との統合は、SharePoint Portal Server 2003との統合と非常によく似ています。2つの統合のために実行する手順の多くは、同一です。
以降の項では、SharePoint Office Server 2007を使用してWebサイトを作成し設定する方法について説明します。
|
注意: SharePoint Portal Server 2003ポータル作成オブジェクト・モデルは、SharePoint Office Server 2007で廃止されました。SharePoint Office Server 2007では、ポータル・サイトは、Windows SharePoint Servicesサイトと同じプロビジョニング・プロセスを使用します。Microsoft Windows SharePoint Services 3.0サイト作成APIを使用するように、ポータル・サイトを作成するすべてのスクリプトを更新する必要があります。新しいvServer（Webアプリケーション）が必要な場合は、サイトを作成する前にWindows SharePoint Services CreateWebApplication APIを使用してください。詳細は、次のURLを参照してください。 |
タスクの概要: SharePoint Portal Serverとの統合
「Microsoftのコンポーネントのインストール」の説明に従って、Microsoftのコンポーネントをインストールします。
SharePoint Office Server 2007で新しいWebアプリケーションまたはサイト・アプリケーションを作成します。
詳細は、「SharePoint Office Server 2007で新しいWebアプリケーションを作成する手順」および「SharePoint Office Server 2007の新しいサイト・コレクションを作成する手順」を参照してください。
「Oracle Access Managerのコンポーネントのインストール」の説明に従って、Oracle Access Managerをインストールします。
「偽装の設定」の説明に従って、偽装を設定します。
「SharePoint Serverとの統合の完了」の説明に従って、統合を完了します。
SharePoint Office Server 2007で新しいWebアプリケーションを作成する手順
Windowsのデスクトップから、「スタート」、「すべてのプログラム」、「Microsoft Office Server」、「SharePoint 3.0 Central Administration」の順にクリックします。
Central Administrationのホーム・ページで、「Application Management」をクリックします。
「Application Managemetn」ページで、「SharePoint Web Application Management」セクションの「Create or Extend Web Application」をクリックします。
「Create or Extend Web Application」ページで、「Adding a SharePoint Web Application」セクションの「Create a New Web Application」をクリックします。
「Create New Web Application」ページで次の項目を構成します。
表17-3 SharePoint Office Server 2007のWebアプリケーション作成オプション
| セクション | このセクションでの構成内容 |
|---|---|
|
IIS Web Site |
このセクションでは、新しいWebアプリケーションについて、次のように設定を構成します。
|
|
Security Configuration |
このセクションでは、Webアプリケーションの認証と暗号化を、次のように構成します。
|
|
Load Balanced URL |
このWebアプリケーションでユーザーがアクセスするすべてのサイトのドメイン名のURLを入力します。このURLドメインは、Webアプリケーションのページで表示されるすべてのリンクで使用されます。デフォルトでは、このボックスには、現在のサーバー名とポートが表示されます。「Zone」フィールドは、新しいWebアプリケーションについては自動的にデフォルトに設定され、このページから変更することはできません。 |
|
Application Pool |
「Application Pool」セクションで、次のように、このWebアプリケーションについて既存のアプリケーション・プールを使用するか新しいアプリケーション・プールを作成するかを選択します。
|
|
Reset Internet Information Services |
このセクションでは、SharePoint Office Server 2007が他のファーム・サーバー上のIISを再起動することを許可するかどうかを選択します。プロセスを完了するには、ローカル・サーバーを手動で再起動する必要があります。このオプションを選択しない場合、ファーム内に複数のサーバーがあると、IIS Webサイトがすべてのサーバー上で作成されるのを待ってから、各Webサーバー上で この選択項目は、ファームにサーバーが1台しかない場合には利用できません。 |
|
Database Name and Authentication |
このセクションでは、新しいWebアプリケーションのデータベース・サーバー、データベース名および認証メソッドを選択します。 「Database Name」フィールドで、データベース名を入力するかデフォルトのエントリを使用します。「Database Authentication」フィールドで、次のように、Windows認証（推奨）とSQL認証のどちらを使用するかを選択します。
|
「OK」をクリックすると新しいWebアプリケーションが作成され、「Cancel」をクリックするとプロセスが取り消されて「Application Management」ページに戻ります。
SharePoint Office Server 2007の新しいサイト・コレクションを作成する手順
SharePoint Central Administrationのホーム・ページで、一番上のリンク・バーにある「Application Management」タブをクリックします。
「Application Management」ページで、「SharePoint Site Management」セクションの「Create Site Collection」をクリックします。
「Create Site Collection」ページの「Web Application」セクションで、サイト・コレクションをホストするWebアプリケーションを「Web Application」ドロップダウン・リストから選択するか、次のように、サイト・コレクションをホストする新しいWebアプリケーションを作成します。
表17-4 SharePoint Office Server 2007用のサイト・コレクションをホストするWebアプリケーションの作成
| セクション | このセクションでの構成内容 |
|---|---|
|
Title and Description |
サイト・コレクションのタイトルと説明を入力します。 |
|
Web Site Address |
URLタイプを選択し、サイト・コレクションのURLを指定します。 |
|
Template |
タブに分けられたテンプレート・コントロールからテンプレートを選択します。 |
|
Primary Site Collection Administrator |
サイト・コレクションのプライマリ管理者になるユーザーのユーザー・アカウント名を入力します。 テキスト・ボックスの右にある本のアイコンをクリックしてユーザー・アカウントを参照することもできます。テキスト・ボックスの右にある「Check Names」アイコンをクリックすると、ユーザー・アカウントの検証が行えます。 |
|
Secondary Site Collection Administrator (optional) |
サイト・コレクションのセカンダリ管理者になるユーザーのユーザー・アカウントを入力します。 テキスト・ボックスの右にある本のアイコンをクリックしてユーザー・アカウントを参照することもできます。テキスト・ボックスの右にある「Check Names」アイコンをクリックすると、ユーザー・アカウントの検証が行えます。 |
偽装の設定は、次の項で説明します。SharePoint Serverとの統合用に設定する場合と、他のアプリケーションで使用するために設定する場合があります。
「信頼できるユーザー・アカウントの作成」の説明に従い、SharePoint Serverに接続するActive Directoryでの偽装専用に、信頼できるユーザー・アカウントを作成します。
「信頼できるユーザーへの権限の割当て」の説明に従い、オペレーティング・システムの一部として機能する特別な権限を、信頼できるユーザーに付与します。
「WebGateへの信頼できるユーザーのバインド」の説明に従い、信頼できるユーザーの認証資格証明を指定して、信頼できるユーザーをWebGateにバインドします。
「ポリシー・ドメインへの偽装アクションの追加」の説明に従い、偽装用ポリシー・ドメインの認可成功アクションにimpersonateという名前のヘッダー変数を追加します。
「IISへの偽装dllの追加」の説明に従い、IISImpersonationExtension.dllをIIS構成に追加してIISを構成します。
「偽装のテスト」の説明に従い、偽装をテストします。
この特別なユーザーは、偽装以外には使用しないでください。
SharePoint Portal ServerのインストールをホストするWindows 2003マシンで、「スタート」、「プログラム」、「Manage Your Server」、「Domain Controller (Active Directory)」、「Manage Users and Computers in Active Directory」の順に選択します。
Active Directory Users and Computersウィンドウで、左側のペインのツリーにある「Users」を右クリックし、「New」、「User」の順にクリックします。
「New Object - User」ペインの「First name」フィールドに、覚えやすい名前（「SPPSImpersonator」など）を入力します。
これと同じ文字列を「User logon name」フィールドにコピーし、「Next」をクリックします。
以降のパネルで、パスワードの選択と、確認用としてパスワードの再入力を求める画面が表示されます。
|
注意: 信頼できるユーザーには強力な権限が付与されるため、複雑なパスワードを選択することをお薦めします。また、「Password Never Expires」ボックスを必ずチェックしてください。これは、信頼できるユーザー・アカウントを表示できるエンティティは偽装の拡張だけであるため、外部機関がパスワードの有効期限切れを検出することは困難だからです。 |
信頼できるユーザーに対して、オペレーティング・システムの一部として行動する権限を付与する必要があります。
「コントロール パネル」、「管理ツール」、「Domain Controller Security Policy」の順に選択します。
左側のペインのツリーで、「Local Policies」の隣にあるプラス・アイコン（+）をクリックします。
左側のペインのツリーで、「User Rights Assignment」をクリックします。
右側のペインの「Act as part of the operating system」をダブルクリックします。
「Add User or Group」をクリックします。
「Add User or Group」パネルで、「User and group names」テキスト・エントリ・ボックスに信頼できるユーザーのユーザー・ログイン名（この例ではSPPSImpersonator）を入力し、「OK」をクリックして変更を登録します。
信頼できるユーザーの認証資格証明を次のように指定して、信頼できるユーザーをWebGateにバインドする必要があります。
ブラウザでアクセス・システム・コンソールをポイントします。次に例を示します。
http://hostname.domain.com:port/access/oblix
この場合、hostnameはポリシー・マネージャをホストするマシンのDNS名、domainはマシンが属するサーバー・ドメインの名前、portはポリシー・マネージャがリスニングするポートの番号です。
「アクセス・システム・コンソール」、「アクセス・システム構成」、「アクセス・ゲート構成」の順に移動します。
変更するWebgateの名前を選択します。
「アクセス・ゲートの詳細」ページに、このWebGateの構成情報の概要が表示されます。このWebページの一番下に、「暗号化ユーザー名」フィールドと「暗号化パスワード」フィールドがあります。
「アクセス・ゲートの詳細」ページの一番下にある「変更」ボタンをクリックします。
「アクセス・ゲートの変更」ページが表示されたら一番下までスクロールし、このタスクで作成した信頼できるユーザーのユーザー名とパスワードを入力します。
例:
「保存」ボタンをクリックして変更をコミットし、「詳細」ページに戻ります。
これで、WebGateと信頼できるユーザーのバインドが作成されました。WebGateによる偽装を要求に応じて提供する準備ができました。要求は、偽装用に作成されたポリシー・ドメイン内の認可成功アクションによって作成されます。
SharePointリソースを保護するには、ポリシー・ドメインの作成または構成を行う必要があります。このためには、認可成功アクションを追加する際にheaderVarの戻り型を指定してnameパラメータをImpersonateに設定し、シングル・ドメインActive Directoryインストールの場合はreturn attributeパラメータをsamaccountnameに、複数ドメインActive Directoryフォレストの場合はuserPrincipalNameに設定します。
また、ドメインには、Impersonation Policy Domainなどの覚えやすい名前を選択する必要があります。
ポリシー・ドメイン作成の詳細は、『Oracle Access Manager Access System Administration Guide』を参照してください。
アクセス・システム・コンソールに移動し、次のようにログインします。
http://hostname.domain.com:port/access/oblix
この場合、hostnameはWebPassとポリシー・マネージャをホストするマシンのDNS名、domainはマシンが属するサーバー・ドメインの名前、portはポリシー・マネージャがリスニングするポートの番号です。
変更するポリシー・ドメインの認可定義のページに移動します。
「ポリシー・マネージャ」、「ポリシー・ドメイン」、PolicyName、「認可ルール」
このPolicyNameは、偽装用に特別に作成したポリシー・ドメインです（この例ではImpersonationPolicyDomain）。
現在定義されている認可ルールがリストされます。何もリストされない場合は、「追加」ボタンをクリックして認可ルールを作成するフォームに入力します。
偽装アクションを追加するルールへのリンクをクリックして説明を開きます。
「認可ルール」タブのすぐ下にある「アクション」タブをクリックします。
「認可成功」ページが表示され、「認可成功」と「認可失敗」のセクションが別々に表示されます。アクションが指定されていない場合は、アクションを追加する必要があります。アクションが指定されている場合、アクションを変更できます。
impersonateという名前のヘッダー変数を、偽装用ポリシー・ドメインの認可成功アクションに追加する必要があります。
「認可成功」ページで、「追加」ボタンまたは「変更」ボタンをクリックします。
「認可成功」領域で、戻りの詳細を入力します。
例:
Type: HeaderVarName: IMPERSONATEReturn attribute: uid or samaccountname (Active Directory username, the Windows domain user for the desired folder)
この場合、HeaderVarは戻り型、IMPERSONATEは偽装用ヘッダー変数の名前です。戻り値のuidまたはsamaccountnameは、使用されているディレクトリに基づいています。
ルールを保存します。このルールは、2番目のWebGateリクエスト（認可用）で使用されます。
サンプルの画面ショットを示します。
これで、IISImpersonationExtension.dllをIIS構成に追加してIISを構成する準備が整いました。詳細は、「IIS構成に偽装dllを追加する手順」を参照してください。
複数のWebサイトがあり、SharePoint Portal Serverと統合されているサイトと統合されていないサイトがあるときに、SharePoint Portal Serverと統合されていないWebサイトに対して偽装を有効にする場合があります。このためには、Webサイト・ツリーの任意のレベルにImpersonation.dllをインストールし、Webサイトにワイルドカード拡張機能を追加する必要があります。詳細は、「Webサイトのワイルドカード拡張機能を追加する手順」を参照してください。
「スタート」、「管理ツール」、「インターネット インフォメーション サービス (IIS) マネージャ」の順に選択します。
左側のペインのツリーで、ローカル・コンピュータのアイコンの左にあるプラス・アイコン（+）をクリックします。
左側のペインのツリーで「Webサービス拡張」をクリックします。
右側のパネルの「Oblix WebGate」をダブルクリックし、プロパティ・パネルを開きます。
「必要なファイル」タブをクリックします。
「追加」をクリックします。
「ファイルのパス」テキスト・ボックスに、IISImpersonationExtension.dllへのフルパスを入力します。
デフォルトのパスは次のとおりです。
WebGate_install_dir\access\oblix\apps\webgate\bin\ IISImpersonationExtension.dll
このWebGate_install_dirは、WebGateをインストールしたディレクトリです。
|
注意: C:\Program Files\Oracle\...などのようにパス内に空白が存在する場合は、文字列全体を二重引用符（" "）で囲んでください。 |
「OK」をクリックします。
「Webサービス拡張のプロパティ」パネルの「全般」タブをクリックし、「ファイルの場所を確認しない」ボックスが選択されていないことを確認します。
「Oblix WebGate」アイコンの左の「許可」ボタンが入力不可の状態になっていることを確認します。これは、dllがWebサービス拡張機能として実行可能な状態になっていることを示しています。
|
注意: 「許可」ボタンが入力可能な状態になっている場合は、このボタンをクリックして入力不可の状態にしてください。「許可」ボタンが入力不可になっている場合は、ハイライト表示されたファイルがIIS仮想サーバー上で実行可能な状態になっていることを示しています。 |
Webサイトのワイルドカード拡張機能を追加する手順
Oracle Access ManagerがSharePoint Serverと統合されていない場合は、次のようにWebサイトのワイルドカード拡張機能を構成します。
「スタート」、「管理ツール」、「インターネット インフォメーション サービス (IIS) マネージャ」の順にクリックします。
左側のペインのツリーで、ローカル・コンピュータのアイコンの左にあるプラス・アイコン（+）をクリックします。
左側のペインのツリーで「Webサイト」をクリックします。
該当するWebサイトを表すアイコンを右クリックし、メニューの「プロパティ」をクリックします。
「ホーム ディレクトリ」タブをクリックします。
「構成」ボタンをクリックします。
ワイルドカード・アプリケーション・マップのリスト・ボックスで、IISImpersonationExtension.dllのエントリをクリックしてハイライト表示し、「編集」をクリックします。
ボックスが選択されていないことを確認します。
偽装は、次の方法でテストできます。
「SharePoint Serverで保護されないIIS仮想サイトの作成」の説明に従い、SharePoint Serverコンテキスト外でテストを行うか、またはシングル・サインオンのテストを行います。
「イベント ビューアを使用した偽装のテスト」の説明に従い、イベント ビューアを使用します。
「Webページを使用した偽装のテスト」の説明に従い、Webページを使用します。
「偽装のネガティブ・テスト」の説明に従い、ネガティブ・テストを使用します。
SharePoint Serverコンテキスト外で偽装機能をテストするか、シングル・サインオンをテストするには、SharePoint Serverによって保護されないIIS仮想Webサイト上のターゲットWebページが必要です。このような仮想Webサイトを作成するには、次のタスクを行います。
SharePoint Serverで保護されないIIS仮想サイトを作成する手順
「スタート」、「管理ツール」、「インターネット インフォメーション サービス (IIS) マネージャ」の順に選択します。
左側のペインのツリーで、ローカル・コンピュータのアイコンの左にあるプラス・アイコン（+）をクリックします。
左側のペインのツリーで「Webサイト」を右クリックし、メニューの「新規作成」、「Webサイト」の順に移動します。
Webサイト作成ウィザードのプロンプトに従います。
仮想サイトの作成後、『Oracle Access Manager Access System Administration Guide』の説明に従い、ポリシー・ドメインを使用してサイトを保護する必要があります。
Windows 2003のイベント ビューアを使用して偽装のテストを行う場合は、実際のテストを行う前にイベント ビューアを構成する必要があります。
「スタート」メニュー、「イベント ビューア」の順に選択します。
左側のペインで「セキュリティ」を右クリックし、「プロパティ」をクリックします。
「セキュリティのプロパティ」シートの「フィルタ」タブをクリックします。
すべてのイベント・タイプがチェックされ、「イベント ソース」と「分類」のリストが「すべて」に設定されていることを確認した後、「OK」をクリックしてプロパティ・シートを閉じます。
これで、リソース・リクエストに関連するHeaderVarに関する情報を表示するようにイベント ビューアが構成されました。
新しいIIS仮想サーバー（仮想サイト）を作成します。
目的のWebページを、仮想サイト上のツリーの任意の場所に配置します。
ブラウザでこのWebページをポイントします。
偽装が適切に機能している場合、イベント ビューアによってアクセスの成功がレポートされます。
.aspページやperlスクリプトなどの動的テスト・ページを使用して偽装をテストすることもできます。これらのページやスクリプトにより、リクエストに関する情報を取得して表示できます。
サーバー変数を表示するWebページを使用して偽装をテストする手順
AUTH_USERパラメータとIMPERSONATEパラメータを表示する.aspページまたはperlスクリプトを作成します。次のリストに示すサンプル・ページのようになります。
IIS仮想サイトを作成するか、前述のタスクで作成したサイトを使用します。
前述に示したリストのサンプルのような.aspページやperlスクリプトを、新しい仮想サイトのツリーの任意の場所に配置します。
そのページをブラウザでポイントすると、AUTH_USERパラメータとIMPERSONATEパラメータが表示されます。どちらのパラメータも、リクエストを作成するユーザーの名前に設定されています。
偽装のネガティブ・テストを行うには、次の手順の説明に従い、信頼できるユーザーをWebGateからアンバインドする必要があります。
信頼できるユーザーをWebGateからアンバインドする手順
次のようなURLでアクセス・システム・コンソールにログインします。
http://hostname.domain.com:port/access/oblix
この場合、hostnameはAccess ManagerをホストするコンピュータのDNS名、domainはマシンが属するサーバー・ドメインの名前、portはAccess Managerがリスニングするポートの番号です。
「アクセス・システム・コンソール」を選択し、「アクセス・システム構成」、「アクセス・ゲート構成」の順にクリックします。
変更するWebgateの名前を選択します。
「アクセス・ゲートの詳細」ページに、このWebGateの構成情報の概要が表示されます。このWebページの一番下に、「暗号化ユーザー名」フィールドと「暗号化パスワード」フィールドがあります。
「アクセス・ゲートの詳細」ページの一番下にある「変更」ボタンをクリックします。
「アクセス・ゲートの変更」ページが表示されます。
信頼できるユーザーの資格証明を削除します。
「保存」をクリックします。
「アクセス・ゲートの詳細」ページに戻ります。
IISサーバーを再起動します。
「サーバー変数を表示するWebページを使用して偽装をテストする手順」で作成した.aspコード・ページを、ブラウザでポイントします。
エラー・メッセージのページが表示されます。AUTH_USERとIMPERSONATEの値は、偽装資格証明をWebGateにバウンドする際に必要です。
Oracle Access ManagerとSharePoint Serverとの統合を設定するには、いくつかの手順を実行する必要があります。
タスクの概要: SharePoint Serverとの統合の設定
「IISセキュリティの構成」の説明に従って、セキュリティを設定します。
「ワイルドカード拡張機能の構成」の説明に従って、統合を有効にする各SharePoint Server仮想サーバーに対してワイルドカード拡張機能を構成します。
「web.configの編集」の説明に従って、web.configファイルを編集します。
「統合のテスト」の説明に従って、統合をテストします。
手順を続行する前に、IISセキュリティを構成する必要があります。
SharePoint Server統合用にIISセキュリティを構成する手順
「スタート」、「管理ツール」、「インターネット インフォメーション サービス (IIS) マネージャ」の順に選択します。
左側のペインのツリーで、ローカル・コンピュータのアイコンの左にあるプラス・アイコン（+）をクリックします。
左側のペインのツリーで「Webサイト」をクリックします。
左側のペインのツリーで、WebGateを使用して保護するSharePoint Serverサーバーを表すアイコンを右クリックし、メニューから「プロパティ」を選択します。
SharePoint Serverサーバーのプロパティ・シートで、「ディレクトリ セキュリティ」タブをクリックします。
「ディレクトリ セキュリティ」タブの「認証とアクセス制御」セクションで、「編集」をクリックします。
「認証方法」パネルで、「匿名アクセスを有効にする」ボックスをクリックします。確認画面が表示されたら、「OK」をクリックしてタスクを完了します。
|
注意: 匿名アクセスを有効にしても、匿名ユーザーがSharePoint Serverにアクセスできるようにはなりません。匿名アクセスを有効にすることにより、IISからアクセス・システムへのアクセス制御が切断されます。 |
統合を有効にする各SharePoint Portal Server仮想サーバーに対して、ワイルドカード拡張機能を構成する準備が整いました。
SharePoint Portal Server仮想サーバーのワイルドカード拡張機能を構成する手順
「スタート」、「管理ツール」、「インターネット インフォメーション サービス (IIS) マネージャ」の順に選択します。
左側のペインのツリーで、ローカル・コンピュータのアイコンの左にあるプラス・アイコン（+）をクリックします。
左側のペインのツリーで「Webサイト」をクリックします。
SharePoint Portal Serverサーバーを表すアイコンを右クリックし、メニューの「プロパティ」をクリックします。
「ホーム ディレクトリ」タブをクリックします。
「構成」ボタンをクリックします。
ワイルドカード・アプリケーション・マップのリスト・ボックスで、IISImpersonationExtension.dllのエントリをクリックしてハイライト表示し、「編集」をクリックします。
ボックスが選択されていないことを確認します。
ファイルが存在することを確認し、「OK」を3回クリックして追加/編集パネル、「アプリケーションの構成」パネル、ポータル・サーバーのプロパティ・シートを閉じます。
次の行をweb.configファイルに追加します。
<add key = "SPS-EnforceIISAnonymousSetting" value="false" />
SharePoint Portal Server統合用にweb.configを編集する手順
Windowsエクスプローラを開き、IIS Webサイトのドキュメント・ルートに移動します。
任意のテキスト・エディタを使用してXMLファイルweb.configを開きます。
ファイルの最後にあるappSettingsマーカーを検索します。マーカーが存在しない場合は、次のようにマーカーを作成します。
<Configuration> // [Various configuration settings] <appSettings> // [Insert "<add key . . .>" here.] </appSettings > </Configuration>
|
重要: appSettingsマーカーは大文字と小文字を区別し、正確に「appSettings」となるように設定する必要があります。 |
前述のコードで示した場所に次の行を追加します。
<add key = "SPS-EnforceIISAnonymousSetting" value="false" />
web.configを保存します。
IISを再起動し、次の手順を実行して新しい設定を有効にします。
「スタート」メニュー、「インターネット インフォメーション サービス (IIS) マネージャ」の順に選択します。
左側のペインのツリーで、SharePoint Portal Serverのインストールをホストするローカル・コンピュータの名前を探してメモします。このコンピュータの名前は、IISを再起動する場合に必要になります。
ローカル・コンピュータのアイコンを右クリックし、メニューから「切断」を選択します。
接続解除を確認する警告が表示されたら、「はい」をクリックしてアクションを確認します。
ローカル・コンピュータのアイコンが左側のペインのツリーから消え、そのマシンのIISが停止したことを示します。
左側のペインのツリーで「Internet Information Services」アイコンを右クリックし、メニューの「接続」をクリックします。
「コンピュータへの接続」パネルで、SharePoint Portal Serverのインストールをホストするコンピュータの名前を入力し、「OK」をクリックしてIISを再起動します。
SharePoint Portal ServerディレクトリとOracle Access Managerディレクトリ間で、ユーザー・プロファイルを次のように同期化する必要があります。
ユーザー・データのアップロード: SharePoint Active Directory以外のディレクトリ・サーバーに対してOracle Access Managerのインストールが構成されている場合、他のディレクトリ・サーバーにあるユーザー・プロファイルをSharePoint Active Directoryにロードする必要があります。
SharePoint Portal Serverへのユーザー・プロファイルのインポート: ユーザー・プロファイルのアップロード後、Active DirectoryからSharePoint Portal Serverにプロファイルをインポートする必要があります。
SharePoint Portal Serverにユーザー・プロファイルのインポートを構成する手順
「Site Settings」に移動します。
「User Profile」、「Audiences」、「Personal Sites」の下にある「Manage Profile Database」をクリックします。
Active Directoryからのユーザー・プロファイルのインポートを構成するには、「Configure Profile Import」をクリックします。
統合を有効にする操作が完了したら、統合が機能していることを検証するテストを行います。
この項のトピックは次のとおりです。
Oracle Access Manager認証とSharePoint Portal Server認可を使用してSharePoint Portal Serverリソースにアクセスできるかどうかを検証します。
SharePoint Portal Serverとの統合をテストする手順
ブラウザを使用して任意のSharePoint Portal Server Webページに移動します。
アクセス・システムにより、資格証明のチャレンジ認証が実行されます。
必要な資格証明を指定してログインし、リクエストしたページが表示されることを確認します。
オプション: アクセス・リクエストが正常に終了したことをイベント ビューアで確認します。
シングル・サインオンもテストする必要があります。シングル・サインオンをテストするには、資格証明を入力してSharePoint Portal Serverリソースにアクセスしたユーザーが、ObSSOCookieの有効期限が切れる前に、もう一度資格証明を入力することなくSharePoint Portal Server以外のリソースにアクセスできるかどうかを確認します。たとえば、ポリシー・マネージャに定義されているリソースを使用します。
シングル・サインオンが機能している場合、もう一度資格証明を入力することなくページへのアクセスが許可されます。
SharePoint Portal Server統合用のシングル・サインオンをテストする手順
ポリシー・ドメインを使用して新しい仮想サイトを作成し、保護します（または、すでに作成されているサイトを使用します）。
Webページを、仮想サイト上のツリーの任意の場所に配置します。
ブラウザを使用して、新しい仮想サイトのページに移動します。
すでに認証に合格している場合、もう一度資格証明を指定することなくページへのアクセスが許可されます。
