Office ドキュメントを開くときの認証要求


現象


Web サーバーの Microsoft Office ドキュメントを開こうとすると、認証を求められることがあります。 技術的な詳しい理由については、マイクロソフト サポート技術情報 838028 を参照してください。  ただし、この記事では問題の対処方法を説明していません。 KB 838028 では Microsoft Office 2003 の動作について説明していますが、 新しいバージョンの Microsoft Office にも、同じ理由の動作が存在します。

このドキュメントでは、この問題の概要とさまざまな対処方法について説明します。 現時点で解決策はありません。 そのため、最適な回避策は、対象ユーザーに必要な機能と実行可能な構成によって変わります。 ほとんどの場合、妥協策が必要です。

原因


Internet Explorer が Office ドキュメントを開こうとすると、適切な Office アプリケーションが起動し、ドキュメントのパスが示されます。 次に、サーバーのドキュメントに直接アクセスが試行されます。 この動作は、他のブラウザーや他のファイルの種類とは異なります。 多くのブラウザーでは、ファイルがダウンロードされ、アプリケーションに対してローカル キャッシュのファイルを開くように指示されます。 ただし、ローカル ファイルが変更され、保存された場合、変更内容はサーバーのコピーに保存されません。

可能な限り高度なエクスペリエンスを確立するために、Office アプリケーションはまずサーバーと通信して、サーバーの種類と使用できる Web 認証プロトコルを判断します。 この処理は、アプリケーションから OPTIONS 要求をサーバーに直接送信することで行われます。

サーバーにアクセスする新しいプロセスなので、Office アプリケーションは認証を再生成する必要があります。 この方法は、ブラウザーで確立された既存の認証を新しいプロセスで使用する方法よりも安全です。 

回避策


ほとんどのイントラネットの例で、この問題を解決する最も簡単な方法は、統合 Windows 認証を使用するようにサーバーを構成してから、クライアントの自動ログオンを有効に構成することです。 認証が要求されると、現在ログオンしている Windows ユーザーのユーザー名とパスワードがサーバーに自動的に送信されます。ユーザーにプロンプトは表示されません。

Internet Explorer で自動ログオンを許可するには、サイトがあるゾーンについてオプションを有効にする必要があります。 ローカル イントラネット ゾーンには、既定で現在のユーザー名とパスワードによる自動ログオンの構成があります。 ローカル イントラネット ゾーンは、次のように定義されています。

  • 汎用名前付け規則 (UNC) パスを使用して確立されたすべてのネットワーク接続
  • プロキシ サーバーをバイパスする Web サイト、またはピリオドを含まない名前を持つ Web サイト (http://local など)

    注: これらの Web サイトは、制限付きサイト ゾーンまたは信頼済みサイト ゾーンに割り当てられていない場合にのみ含まれます。 信頼済みゾーンには、既定でイントラネット ゾーンのみの自動ログオンの構成があります。

Windows Vista 以降のバージョンの Windows で Microsoft Office 2007 を使用して Microsoft Office ドキュメントを開くと、アプリケーションは Web クライアント サービス経由で Web サーバーに対して Web 分散オーサリングとバージョン管理 (WebDAV) を確立しようと試みます。 Windows Vista 以降、Web クライアント サービスは WinHTTP ネットワーク プロトコルを使用し、ゾーン マネージャーを使用しません。 次の条件のいずれかを満たす場合にのみ、ログオン ユーザーの資格情報が自動的に渡されます。

  • サイトが NetBIOS 名 (URL にピリオドがない)。
  • プロキシが検出され、サイトの URL がプロキシのバイパス条件を満たしている。
  • 以下のすべての条件を満たしている。
    • サイトが完全修飾ドメイン名 (FQDN)。
    • Webclnt.dll のバージョンが 6.0.6000.20729 以降。
    • サイトの URL が Web クライアント サービス パラメーターのレジストリ値 AuthForwardServerList に指定されている条件を満たしている (詳細については、サポート技術情報 943280 を参照してください)。

Windows ログオンの資格情報が、Web サイトに必要な資格情報と一致する場合、統合 Windows 認証で、Windows のユーザー名とパスワードを使用して自動的にログオンするようにクライアントを構成することができます。 インターネットに面している接続に統合 Windows 認証を使用することは推奨されません。また、サポートされていません。

現在ログオンしているユーザーの資格情報は、ドキュメントへのアクセスに必要な資格情報と異なる場合、ユーザーには資格情報の入力が求められる点に注意してください。 一般的なガイドラインとして、サイトへのアクセスに資格情報を入力する必要がある場合、通常はドキュメントを開く際にも資格情報を入力する必要があります。

統合 Windows 認証をログオン方法として使用できない場合、資格情報のプロンプトの表示が問題になる可能性があります。 この場合、次の代替方法とその欠点を考慮してください。

方法 1: 計算されたリスクがあるフル機能

フォーム ベース認証 (FBA) と永続的な Cookie を併用する

直接編集機能を維持し、Office アプリケーションからのプロンプトも表示されないようにする唯一の方法は、フォーム ベース認証と永続的な Cookie を併用してプロキシ/ファイアウォール サーバーを実装することです。 たとえば、Internet Security and Acceleration (ISA) サーバーまたは Forefront Threat Management Gateway を使用できます。 ただし、永続的な Cookie はアプリケーションを区別しないため、意図しないアプリケーションが共有認証を利用する可能性がある点に注意することをお勧めします。 タイムアウト設定を適切に構成することで、こうした他のアプリケーションからの利用を軽減することができます。 それでも、この方法はリスクの一要素になります。

HTML フォーム ベースの認証と ISA 2006 の永続的な Cookie を併用すると、ブラウザー以外のアプリケーション (Office アプリケーションなど) が Cookie を使用できますが、 これらの Cookie は "永続的" です。 ブラウザーまたは Office アプリケーションを終了しても削除されないため、ユーザーがインターネット カフェなどの公共の場所で作業している場合にアクセスされる可能性があります。 ただし、ISA サーバー設定のタイムアウト構成に基づいて、Cookie のタイムアウトが適用されます。

"個人用のコンピューターでのみ永続的な Cookie を使用する" オプションがあります。 このオプションを使用するとこの脆弱性を軽減できますが、ユーザーが FBA フォームで "個人用のコンピューター" を選択して、永続的な Cookie 機能を有効にする必要があります (ユーザーは、自分が所有している、または信頼しているコンピューターを使用している場合にのみ、"個人用のコンピューター" を選択する必要があります)。

注: Windows Vista および Internet Explorer 7 以降の既定では、信頼済みゾーンのサイトでない場合、永続的な Cookie は共有されません。 これは Internet Explorer に [保護モード] 設定があるためです。 説明と回避策については、マイクロソフト サポート技術情報 932118 を参照してください。

方法 2: 影響を軽減できるクライアント アプローチ

アプリケーションを開いたままにする

直接編集機能を維持し、FBA と永続的な Cookie を併用できないユーザーは、初回のアクセス後にアプリケーションを開いたままにすることで、複数回のプロンプトの影響を軽減できます。 アプリケーションではなくドキュメントのみを閉じると、既存のプロセスは既に認証されているため、資格情報の入力が求められることなく、同じアプリケーションを使用する別のドキュメントを開くことができます。 別のアプリケーションが必要な異なる種類のドキュメントは、サイトにアクセスする必要がある新しいアプリケーションごとに資格情報の入力が求められます。

"パスワードを保存する" オプションを選択する

ユーザーがパスワードを保存するオプションを選択して、資格情報の要求の煩わしさを軽減することもできます。 クライアント コンピューターが非公開の信頼済み環境にある場合にのみ、この方法を実行するようにします。 この方法は、公開コンピューターでは使用しないでください (多くの企業は、パスワードの保存を禁止するポリシーを設定しています)。  パスワードを保存しても要求はなくなりませんが、 フィールドにパスワードが事前に設定されるので、応答として 1 回のクリックまたはキー入力のみで認証できるようになります。 この方法を使用する場合、サイトを信頼済みサイト ゾーンに追加する必要があります。

OPTIONS の結果を事前に構成する

サポート技術情報 838028 で説明されているように、情報が以前に取得され、Office Protocol Discovery Cache にキャッシュされている場合、OPTIONS の呼び出しは実行されません。

重要: レジストリ キーまたは値を直接編集することは推奨されません。 情報を事前に構成する最も簡単な方法は、テスト コンピューターで情報を正常に構成した後に、情報をコピーして配布することです。 Office ではキャッシュが定期的にクリアされるので、保存される情報は一時的です。 既定では、約 2 週間後に情報の有効期限が切れますが、この有効期限は延長できます。 有効期限を最長 10 年間まで延長できる更新プログラムは Office 2003 Service Pack 3 に含まれており、Microsoft Office 2007 にも含まれています (サポート技術情報 916658 を参照してください)。 このレジストリ エントリを使用する方法の欠点は、Web 作成プロトコルまたはサーバーの種類が変わっても、Office 2003 は古い情報が有効であると想定することです。

Office Protocol Discovery Cache

Office Protocol Discovery Cache には、OPTIONS 要求に対して正常に応答した、開いている各 Web フォルダーのサブキー エントリが含まれています。 Office 2003 に使用されているレジストリ サブキーは次のとおりです。

HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Common\Internet\Server Cache

注: Microsoft Office 2007 も似たサブキーを使用していますが、バージョン番号は "11.0" ではなく "12.0" です。 Microsoft Office 2010 は "11.0" ではなく "14.0" を使用します。

キャッシュ エントリの最大数は、同じ Server Cache キー以下の MaxCount レジストリ値で設定できます。 最大数に達すると、Office は古いエントリを削除して使用できる領域を増やします。 領域をクリアできない場合、OPTIONS の呼び出し結果はキャッシュされません。

OPTIONS の応答を事前に構成しても、資格情報のすべての要求はなくならない可能性があります。 PROPFIND 要求または HEAD 要求から認証の要求が発生することもあります。

方法 3: Web サーバーが DAV をサポートしていない場合、または機能制限を容認できる場合の代替構成

ローカルにキャッシュされたドキュメントの使用を強制することで、追加の資格情報が要求されないようにサイトを構成することもできます。 ただし、この構成は、その URL のすべてのユーザーに影響し、直接編集機能は無効です。 そのため、ユーザーは Office アプリケーションからサーバーに直接保存することはできなくなります。 ドキュメントをオフラインで編集してからサーバーにアップロードする必要があります。 最適なアプローチは、具体的なシナリオと希望する動作によって異なります。

注: PROPFIND に対して 200 応答を返す Web サーバーも、Cookie が存在する場合に認証プロンプトを表示する可能性があります。 Windows WebClient サービスは、PROPFIND 要求を送信する場合、ターゲット ホストが PROPFIND 要求をサポートしている場合は、プロパティ、値、個々のステータスが記載された XML を含む適切な 207 MULTI-STATUS 応答が返されると想定します。 また、WebClient サービスは、ターゲット ホストが PROPFIND をサポートしていない場合は、"405 Method Not Allowed" などのエラー ステータスが返されると想定します。 ただし、WebClient サービスが、ステータス コードが 200 で、適切な形式の XML を含まない応答を受信した場合、"Invalid Parameter" エラーが内部的に生成され、評価ルーチンに渡されます。 残念ながら、サービスが期限切れの Cookie を検出した場合にも、"Invalid Parameter" エラーが生成されることがあります。 評価ルーチンは、エラーを発生させたユーザーを認識していないため、Cookie が要求にあるかどうかを確認します。 要求に Cookie がない場合、"Invalid Parameter" エラーは無視しても問題ありません。最終的に、サービスは WebDAV サーバーではないと判断します。 ただし、Cookie がある場合、サービスはその判断を下すことができません。 そのため、サービスはこのエラーを Cookie の期限切れとして扱い、"Access Denied" に変換してから、一連の呼び出しをバックアップして渡します。 最終的に "Access Denied" エラーは、資格情報の要件として解釈し、Windows 認証プロンプトを生成するコンポーネントから使用されます。 以下の代替策はいずれも、この原因に対処します。

コンテンツタイプの添付 (SharePoint 以外) を使用する

Internet Explorer から GET 要求を発行すると、ライブ編集セッションが意図されていない場合に、Web アプリケーションはコンテンツを読み取り専用のダウンロードとして明示的にマークすることができます。 カスタム Web アプリケーション (ASP、ASP.NET など) 経由でファイルを提供するサーバーの場合については、サポート技術情報 899927 を参照してください。 "Content-Disposition:Attachment" ヘッダーの使用方法について説明している「Hyperlinks from Internet Explorer to Office」(英語情報) セクションを参照してください。

サーバーがファイル システムからファイルを直接ホストしており、Office ファイルが他のファイルとは別のフォルダー内にある場合、Web サーバー構成のフォルダー レベルにヘッダーが追加されることがあります。 他のファイルが意図せずにこのヘッダーを選択しないようにする場合、このような分離が推奨されます。

特定のファイルの種類にのみ content-disposition ヘッダーを追加する必要がある場合、IIS の URL の書き換えを使用して、content-disposition ヘッダーを変更することができます。 実行方法の詳細については、次の Azure サポート チームのブログ記事を参照してください。

WebDAV と、OPTIONS 動詞および PROPFIND 動詞のサポートの両方またはいずれかを無効にする (SharePoint と SharePoint 以外)

WebDAV に使用する予定がない Web アプリケーションの場合、IIS を実行する既定のサーバーで WebDAV 機能を提供する Web サービス拡張機能を "禁止" に設定することができます (WebDAV、FrontPage Server 拡張機能などです)。 サイトが別の拡張機能で WebDAV 機能を提供している場合、その拡張機能のプロバイダーが関与する必要があります。 たとえば、Windows SharePoint Services (WSS) を使用して実行するには、サイトのクライアント統合を無効に構成するか、OPTIONS 動詞と PROPFIND 動詞を禁止するようにします (インターネット インフォメーション サービス (IIS) バージョン 6 上で OPTIONS 動詞および PROPFIND 動詞を禁止するには、web.config ファイルの <httpHandlers> 登録行から動詞を削除します。 IIS 7.0 では、要求のフィルタリング機能の HTTP の [動詞] タブを使用して動詞を否定します)。 このアプローチでは直接編集機能が無効なため、読み取り専用モードでコンテンツを開くことに注意してください。

注: Office 2010 からは、OPTIONS 要求に加え、HEAD 要求を発行されることがあります。 HEAD 要求は他の目的で他のアプリケーションに使用されることがあるため、HEAD 要求を抑制しないことをお勧めします。

匿名の OPTIONS 要求を許可する (SharePoint 以外)

サーバーの種類と Web 認証プロトコルの種類を判断するには、最初に Office から OPTIONS 呼び出しを送信します。 OPTIONS 呼び出し要求が成功するには、アクセス許可を参照または列挙する必要があります。

2 つ目の認証要求を回避するには、OPTIONS 応答のリターン ステータス値が "401" コード以外である必要があります。 Web サーバーが Web アプリケーションを使用してファイルにアクセスしている場合、OPTIONS 要求を処理するようにアプリケーションを変更できます ("405: Method Not Allowed" メッセージを使用するなど)。

ただし、ファイルが Web サーバー上のファイル システムにある場合、OPTIONS 呼び出しが成功するようにアクセス許可を変更することで、意図しない要求回避することができます。 これで、正しい形式の "200" 応答が生成されます。 IIS サーバーの場合、IIS マネージャーでサイトへの匿名アクセスを有効にしてこの処理を実行できます。

注: ネイティブ IIS WebDAV Web サービス拡張が WebDAV 機能を提供している場合にのみ、この回避策を使用してください。 FrontPage Server 拡張機能を使用している場合は、この回避策を実施しないでください。 制限付きアクセスのみを提供しているサイトでは直感的ではないように思われるかもしれませんが、 制限付きアクセスはファイルシステム レベルで実施できます。 OPTIONS 要求には、(通常はサイトのルートにある) コンテンツの列挙アクセス許可のみが必要なので、匿名アクセスに使用するアクセスのフォルダーのアクセス許可を "読み取りの拒否" および "書き込みの拒否" に変更するようにします (このアカウントは、"インターネット ゲスト アカウント" のフレンドリ名を使用して IIS マネージャーで定義することがあります)。 こうすると、OPTIONS 呼び出しには対応可能で、任意のコンテンツに対するアクセスは拒否するために必要なアクセス許可になります。 Office アプリケーションはインターネット キャッシュのドキュメントを開きます。