| Oracle® Fusion Middleware Oracle WebCenter Portalの管理 11gリリース1 (11.1.1.9.0) E51441-06 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebCenter Portalの管理 11gリリース1 (11.1.1.9.0) E51441-06 |
|
前 |
次 |
この章では、Microsoft OfficeとWebCenter Portal 11g (11.1.1.1.0)以降との統合の構成に必要なシステム管理作業の概要について説明します。
この章には次のトピックが含まれます:
Microsoft OfficeをWebCenter Portalとともに使用する方法は、『Oracle WebCenter Portalの使用』の「Microsoft OfficeおよびExplorerの統合での作業」を参照してください。
|
権限: この章のタスクを実行するには、次のロールが付与されている必要があります。
第1.8項「管理操作、ロールおよびツールの理解」も参照してください。 |
図26-1は、標準のMicrosoft Office統合トポロジを、トポロジ内における各コンポーネント固有の構成関連のメモとともに示しています。Microsoft Office統合の構成方法の詳細は、第26.2項「Microsoft Office統合の構成」を参照してください。
Microsoft Office統合を構成すると、WebCenter Portal環境内からMicrosoft OfficeアプリケーションおよびMicrosoft Office Enterprise Editionアプリケーションと対話できるようになります。Windowsの各バージョンに対応したアクティビティは、『Oracle WebCenter Portalの使用』の「Microsoft OfficeおよびExplorerの統合での作業」に記載されているマトリックスを参照してください。
Oracle HTTP Serverおよびロード・バランサ
OHS (または、ロード・バランサ)は、リクエストがSharepointサーブレットにルーティングされるように、適切に構成する必要があります。シングル・サインオンを使用している場合は、第33.6項「仮想ホストを使用したSSOの構成」の説明に従って、SSOによって保護されていない仮想ホストを作成する必要があります。これは、トポロジのエッジ・サーバーで行います(つまり、ロード・バランサまたはOHSのいずれか)。-Dnon_sso* javaパラメータは、第33.6.5項「仮想ホスト用のWebCenter Portalの構成」の説明に従って、非SSO保護仮想ホストをポイントするように設定する必要があります。
SSL有効化エントリ・ポイント
SSLをロード・バランサまたはOHSのいずれかに構成する必要があり、Microsoft Office 2010およびMicrosoft Office 2013を使用する場合にいずれかがトポロジのエッジ・サーバーです。強くお薦めしますが、MS Office 2007に必須ではありません。非SSL統合の詳細は、第26.3項「非SSL統合の構成」を参照してください。
Microsoft Officeクライアント
SSLを使用しないとセキュリティ・リスクが発生するため(ユーザーの資格証明が暗号化されずに渡される)お薦めしませんが、各クライアント・マシンのレジストリを構成してMicrosoft OfficeをHTTPで認証するようにできます。詳細は、第26.3項「非SSL統合の構成」を参照してください。
WC_Spaces管理対象サーバー
適用できるJVM引数を示し、特にどの引数がどのような条件で必要なのかについて確認します。詳細は、第26.2項「Microsoft Office統合の構成」の手順2を参照してください。
SSLがエッジ・サーバー(OHSまたはロード・バランサのいずれか)で有効になっている場合、エッジ・サーバーのSSL資格証明の「信頼できる証明書」をWC_Spacesサーバーのキーストアにインポートする必要があります(第26.4.3項「SSLの使用でドキュメントのチェックアウトが不可能になる」を参照)。
Internet Explorerまたはサポートされているブラウザ
Internet Explorerでは、ActiveXを有効にする必要があります。FirefoxやGoogle ChromeなどのInternet Explorer以外のブラウザでは、Javaプラグインをインストールする必要があります。詳細は、第26.4.1項「Officeで「編集」をクリックしてもWordが起動しない」を参照してください。
Windows/WebCenter Portalユーザー・アカウント
Windowsユーザー・アカウントとWebCenter Portalログイン・アカウントは同等の関係である必要があります。Microsoft Officeとの統合を稼働する方法によっては、WebCenter Portalユーザー・アカウントをWindowsユーザー・アカウントに独自に関連付ける必要があります。特にWindows 7では、Windows 7 WebClientによりユーザー資格証明書がWindows 7ユーザー・コンテキストにキャッシュされ、その結果、Windows 7のユーザーごとに1つのWebCenter Portalユーザーしかサポートできなくなります。詳細は、第26.4.2項「ドキュメント・ライブラリからのドキュメント編集に関する問題(Windows 7)」を参照してください。
この項では、Microsoft Officeをデスクトップ統合に対して構成する方法を説明します。その構成手順に従うには、次の要件を満たしている必要があります。
Oracle WebCenterのフロントにWeb層(Oracle HTTP Server)がインストールされている。Oracle HTTP Serverインストールの詳細は、『Oracle Web Tierインストレーション・ガイド』のOracle Web層のインストールと構成に関する項を参照してください。
Oracle HTTP Server (1つが使用されている場合にはロード・バランシング・ルーター)でSSLが構成され有効化されている。Microsoft Office 2010およびMicrosoft Office 2013を使用する場合にMicrosoft Office統合にはSSLが必要である点に注意してください。詳細は、第35.3項「SSLを使用したOracle HTTP ServerからWebCenter Portalへの接続の保護」を参照してください。
強くお薦めしますが、MS Office 2007に必須ではありません。非SSL統合の詳細は、第26.3項「非SSL統合の構成」を参照してください。
証明書がcacertsまたはWebLogicデフォルトのトラスト・ストアでシード済の既知の認証局で発行されたものではない場合、使用しているSSL証明書の公開証明書がWebLogicトラスト・ストアにインポートされている。詳細は、第35.1項「SSLを使用したブラウザからWebCenter Portalへの接続の保護」を参照してください。
WebCenter PortalがOAMで構成されている場合、OAMの管理者はリソースURLを、保護レベルをExcludedに設定して追加する必要があります。
/wcsdocs* /wcsdocs/.../* /_vti_*
リソースURLの設定の詳細は、Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service管理者ガイドのポリシーで使用するリソース定義の追加と管理に関する項を参照してください。
OHS構成で呼び出されるOAM保護は、メイン接続ポートに限定的に適用する必要があり、後述の手順で構成するセカンダリの保護されていないSharePointポート(この例では、4444)に適用しないでください。webgate.conf (場合によっては、httpd.conf)からOblixの値を削除し、メインのWebCenter接続(ポート80または7777)に対する有効な仮想ホスト・コンテナで、それらの値を置換する必要があります。その後で、後述の手順1および2で新しい仮想ホストを作成すると、ポート(この例では、4444)が作成されます。SharePointのプロトコルは、このポートを使用してOAM SSOなしで通信できます。詳細は、第33.6.4項「OAM 11g用の仮想ホストの構成」を参照してください。
|
注意: WebCenter PortalのMicrosoft Officeとの統合は、Microsoftによって確立されたSharePointサーバーとやり取りするMicrosoftデスクトップ・アプリケーション用のモデルに従います。WebCenter Portal統合では、WC_SpacesサーバーがそのモデルのSharePointサーバーのロールをエミュレートします。
クライアント側では、WindowsにログインしたユーザーがWebCenter Portalにログインする際に使用するユーザー・アカウントに関連付けられる可能性があるため、同一のWindowsユーザー・アカウントを使用した複数のWebCenter Portalアカウントへのログインを避けることが重要です。特にWindows 7 WebClientサービスでは、エミュレートされたSharePointサービスのエンドポイントにログインするために使用した資格証明書がキャッシュされるため、同一のWindowsユーザー・アカウントからWebCenter Portalへの様々なログイン・アカウントをサポートすると予期しない結果を生じます。詳細は、第26.4.2項「ドキュメント・ライブラリからのドキュメント編集に関する問題(Windows 7)」のトラブルシューティングの説明を参照してください。 |
次のいずれかの操作を実行して、Oracle HTTP Server (OHS)に<location />を追加します。
OHS_INSTANCE_HOME/config/OHS/ohs1/に格納されたOHS ssl.conf (またはOHSを非SSL環境のフロントエンドWebCenter Portalに構成する場合(お薦めしません)場合には、mod_wl_ohs.conf)ファイルに次の行を追加します。
# WebCenter Portal (previously named Spaces Application)
<location />
SetHandler weblogic-handler
WebLogicHost webcenter.example.com
WebLogicPort 8888
</location>
サンプルのOHSmod_wl_ohs.confファイルは、付録B「WebCenter PortalのOracle HTTP Server構成」を参照してください。
または下のサンプルに示すように、Microsoft Officeアプリケーションによるアクセス用OHSに仮想ホストを作成し、"/"および"/wcsdocs"の両方をこの仮想ホスト内のWC_Spacesサーバー(OAMシングル・サインオンが使用されるときに必要)にルーティングします。
# Virtual Hosts - Sharepoint
<VirtualHost *:4444>
ServerName webtier-spaces.example.com
<Location />
SetHandler weblogic-handler
WeblogicHost webcenter.example.com
WeblogicPort 8888
</Location>
<Location /webcenter>
Deny from all
</Location>
<Location /webcenterhelp>
Deny from all
</Location>
<Location /rest>
Deny from all
</Location>
...
</VirtualHost>
詳細は、第33.6項「仮想ホストを使用したSSOの構成」を参照してください。
必要なパラメータをsetDomainEnv.shファイルに追加して、下のサンプルに示すとおり確実にnon_sso_hostをエイリアスに設定します。setDomainEnv.shファイルは、次の場所に格納されています。
UNIX: DOMAIN_HOME/bin/setDomainEnv.sh
Windows: DOMAIN_HOME\bin\setDomainEnv.cmd
EXTRA_JAVA_PROPERTIES=
"${EXTRA_JAVA_PROPERTIES}
-Dnon_sso_protocol=https
-Dnon_sso_host=<hostname_of_OHS_frontend>.oracle.com
-Dnon_sso_port=4444
-Dsso_base_url=http://<hostname_of_OHS_frontend>.oracle.com:4443"
export EXTRA_JAVA_PROPERTIES
ここで:
non_sso_protocolは、Microsoft OfficeアプリケーションからWC_Spacesにアクセスする際に使用するURLのプロトコルです。
non_sso_hostは、WC_Spacesサーバーを指すホストで、OAM SSOによって保護されていません。
non_sso_portは、WC_Spacesサーバーを指すホストで、OAM SSOによって保護されていません。
sso_base_urlは、SSOにアクセスするためのURLです(通常、WebCenter Portalで使用されるものと同じ)。
詳細は、第33.5.3項「Microsoftクライアントの構成」を参照してください。
|
注意: Microsoft Officeにアクセスする際に外部で使用されるプロトコルがSSLで、資格証明書が無効の場合、次のパラメータをsetDomainEnv.shに追加します。
JAVA_OPTIONS="${JAVA_OPTIONS}
|
なんらかの理由でSSLをOHSまたはロード・バランサで構成しないインストールについては、各クライアントに対してクライアント・レジストリ情報を構成してMicrosoft Office製品に組み込まれた制限をオーバーライドする必要があります。次のMicrosoftのサポート・サイトを参照して、下の手順に従ってください。手順は、Windowsのバージョン間で多少違うことに注意してください。
http://support.microsoft.com/kb/2123563
この項には次のサブセクションが含まれます:
問題
Microsoft Officeの「編集」機能で、Internet Explorer以外のブラウザを使用した場合、Wordまたは関連のOfficeアプリケーションが起動されません。
解決策
Microsoft Office統合をIE以外のブラウザで作業するには、Javaプラグインが必要です。ブラウザでJavaプラグインを有効化してあることを確認してください。Javaプラグインのインストールの手順は、ブラウザのドキュメントを参照してください。
問題
Windows 7への最初のユーザーのログインでは、Microsoft Office統合機能を問題なく使用できます。ところが、それ以降にユーザーが同じWindows 7ログインで同じデスクトップのWebCenter Portalにログインすると、特にドキュメントのチェックインとチェックアウトの際に、問題が発生することがあります。これらの問題は、すべてのブラウザとMicrosoft Officeを停止しても解決されません。
この問題はWebClientサービスによるものです。Windowsネイティブ・サービスによりオペレーティング・システムでHTTPリクエストとWebDAVリクエストが送信され、それにより最初の資格証明書がキャッシュされます。WebClientサービスでは、他のWindows機能による使用(ユーザーがネットワークの場所を追加するなど)が対象であるため、このサービスにアクセスするたびに資格証明書が要求されるのではなくキャッシュされます。しかし、資格証明はWindows 7のログイン・ユーザーとの関連でキャッシュされ、WebCenter Portalログインとは連携していません。
したがって、WebClientサービスでは最初のユーザーの資格証明を使用して、リクエストがWebCenter Portalドキュメント・サービスに送信されます。2番目のユーザーの場合、WebCenterセキュリティ・モデルにより2番目のユーザーがアクセスしているフォルダ上のドキュメントに最初のユーザーの資格証明がアクセスできない(必要な権限がない)ため、この問題が発生します。正常にアクセスできても、最初のユーザーがチェックアウトしたように表示されます。
解決策
この問題を解決する手順は次のとおりです。
2番目のユーザーがこの機能を使用する前にマシンを再起動します。
Windowsからログアウトして、異なるWindows 7ユーザーを使用してログインします。
WebClientサービスを再起動します。
これらの解決策による問題は、システム管理者の権限が必要であり、WebClientサービスがその他のWindows 7機能によって使用されるため、サービスを停止するとそのWindows 7機能が影響を受けることがあります。この問題を回避する最も簡単な方法は、同じデスクトップとWindows 7ログインを複数のWebCenter Portalのユーザー・アカウントやFusionアプリケーションのユーザー・アカウントで共有しないようにすることです。
問題
Officeで「編集」をクリックすると、ドキュメントをチェックアウトできなかったことを示すダイアログが表示されます。数回ログインを試行すると、Microsoft Officeは開きますが、ドキュメントは読取り専用モードでチェックアウトされていません。
解決策
この問題は、特に次の環境に関連しています。
ブラウザがInternet Explorerである
OHSまたはロード・バランサがWC_Spacesサーバーのフロントに設定されていない
SSLがOHS上で有効であり、OHSで終了する(OHSからWC_Spacesサーバーへの接続が非SSLであるなど)
この症状が発生するのは、バックエンド(WC_Spacesサーバー)からOHS (またはロード・バランサ)へ2つ目のHTTPSリクエストがあるためで、WC_Spacesサーバーが信頼されていないことが原因でSSLキーの例外がスローされます。このリクエストにより、ドキュメントのチェックアウトが実行されます。
この問題を解決する手順は次のとおりです。
信頼できる証明書をOHSまたはロード・バランサからWC_Spacesサーバーへインポートします。
次の手順に従って、信頼できる証明書をOHSウォレットからエクスポートします。
OHSを管理するFusion Middleware Controlインスタンスにログインします。
「Web層」→「OHS1」を選択します。
「OHS」ドロップダウン・リストから、「セキュリティ」→「ウォレット」を選択します。
「デフォルト」をクリックします。
CN="\"Self-Signed Certificate for ohs1 \"", OU=OAS, O=ORACLE, L=REDWOODSHORES, ST=CA, C=USを選択します。
「エクスポート」をクリックします。
ファイルを保存します("ohsTrustedCertificate"などとして)。
ファイルをWC_Spacesサーバーのローカル・ディスクにコピーします。
次のkeytoolコマンドを使用して、OHSの信頼できる証明書をWLS DemoTrust.jksにインポートします。
JAVA_HOME/bin/keytool -importcert -v -alias ohscert -file /mycert/ohsTrustedCertificate -keystore /my_mw_home/wlserver_10.3/server/lib/DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase
DemoTrustKeyStorePassPhraseはDemoTrust.jksのデフォルトのパスワードです。
キーストアのパスを検出する手順は、次のとおりです。
WLSコンソールにログインします。
「環境」→「サーバー」→「WC_Spaces」を選択します。
「構成」タブを開き、「キーストア」を選択します。
問題
Internet Explorerでドキュメントの「Officeで編集」をクリックすると、Microsoft Officeが作業ウィンドウにタブを1つのみ表示して起動します。
解決策
この問題が発生するのは、ドキュメントを開いたときに「マイ・ローカル・ドラフト・フォルダを使用する」オプションがInternet Explorerで選択されたためで、その結果、ファイルはサーバーに接続されずにユーザーのローカル・フォルダにコピーされます。それ以降そのファイルにチェックインしないと、他のユーザーがFirefoxやChromeなど他のブラウザでそのドキュメントを編集する際にも同じ症状が発生します。この問題を回避するには、Internet Explorerで「マイ・ローカル・ドラフト・フォルダを使用する」オプションのプロンプトが表示されたら、どのユーザーも必ず選択を解除してください。その他のすべてのブラウザでは、「オプション」→「保存」を各MS Officeアプリケーションで必ず使用してください。
問題
Firefox使用時にWebCenter PortalからMicrosoft Officeアプリケーションに接続できません。
解決策
Java 7でのセキュリティ問題のため、Firefoxではプラグイン・リストで有効化と表示されている場合でも現在Javaプラットフォーム・プラグインがブロックされています。そのため、Microsoft Office統合が無効になります。
JavaおよびMicrosoft Officeの統合をFirefoxで使用するには、さらにプラグインのアイコンをクリックする必要があります(図26-2参照)。
ブラウザの左上のURLバーの近くに表示され、必要なサイトで明示的にJavaを有効にします。
問題
Microsoft Officeドキュメントを開く場合に認証が求められます。この問題の完全な説明は、次のMicrosoftサポート・サイトで取得できます。
http://support.microsoft.com/kb/2019105
Microsoft Knowledge Base記事のタイトルはMS Office 2003 (MicrosoftはOffice 2003のサポートを2014年4月8日に終了しました)を示していますが、基礎となる問題と解決策はすべての後続のリリースと関連しています。
解決策
KB記事によると、ほとんどのイントラネットの例の場合、この問題は、サーバーを構成して統合されたWindows認証を使用してからクライアントを構成して自動ログオンを有効化すると、最も簡単に示されます。推奨方法は、記事を参照してください
