Partager via

Exchange 2013 累積更新プログラム 8 における OWA のフォームベースの認証ログオフの変更 - TMG の機能も再び利用可能に

  • Article

(この記事は 2015 年 1 月 12 日に Office Blogs に投稿された記事 OWA Forms Based Auth Logoff Changes in Exchange 2013 Cumulative Update 8 – And Good News for TMG Customers の翻訳です。最新情報については、翻訳元の記事をご参照ください。)

以前、Exchange Server 2013 CU1 をリリースした際に、OWA のログオフ方法に必要な変更を加えました。しかし残念ながら、この変更には、TMG がユーザーのログオフ試行を検出できなくなるという副作用があり、このシナリオは中断することになりました。

今回、OWA のログオフにさらなる変更を加える予定があり、この機会を利用して TMG のログオフに関する問題を同時に修正しようと考えています。これにより、全体的に改善されることは間違いありません。

なお、今回お知らせする内容は予告段階のものであり、CU8 での実装を予定しています。

どのように変更されるのかを簡単にご説明すると、ユーザーがログアウトした際に再びログオン フォームを表示する代わりに、新しい静的なログオフ ページを表示して、ブラウザーを閉じるように推奨するようになります。

これにはどのようなメリットがあるのでしょうか。1 つには、FBA 認証、基本認証、統合 Windows 認証のいずれを使用する場合にもこのメッセージが表示されるようになり、さらに一貫性の高いログオフ エクスペリエンスを実現できることが挙げられます。また、ログオンとログオフを切り離すことで、将来いずれか一方に何らかの変更を加える場合にも、もう一 方に影響を与えることがなくなります。

CU7 以前の従来の動作

OWA を使用していて、サインアウトをクリックした場合

  1. クライアントが "/owa/logoff.owa" に要求を送信し、ログオフを開始する
  2. その後、"/owa/auth/logon.aspx" への 302 リダイレクトがクライアントに送信される

結果として、ログオン ページが再び表示されます。

ECP を使用していて、サインアウトをクリックした場合

  1. クライアントが "/ecp/logoff.aspx" に要求を送信し、ログオフを開始する
  2. "/owa/logoff.owa" への 302 リダイレクトがクライアントに送信される
  3. さらに、"/owa/logon.aspx" への 302 リダイレクトがクライアントに送信される

この場合も、ログオン ページが再び表示されます。

 

CU8 の既定の動作

OWA を使用していて、サインアウトをクリックした場合

  1. クライアントが "/owa/logoff.owa" に要求を送信し、ログオフを開始する
  2. ランディング ページである "/owa/auth/signout.aspx" への 302 リダイレクトがサーバーからクライアントに送信される

結果として、新しい signout.aspx ページが表示されます。

ECP を使用していて、サインアウトをクリックした場合

  1. クライアントが "/ecp/logoff.aspx" に要求を送信し、ログオフを開始する
  2. "/owa/logoff.owa" への 302 リダイレクトがクライアントに送信される
  3. ランディング ページである "/owa/auth/signout.aspx" への 302 リダイレクトがクライアントに送信される

この場合も、新しい signout.aspx ページが表示されます。

ここまでで変更内容とその理由についておわかりいただけたかと思い ますが、では、この変更はお客様にどのように関係するのでしょうか。なぜ事前にお伝えしているのでしょう。この変更はお客様の目には見えないものであり、 大半のお客様にとっては特に気にする必要はない内容です。ただし、一部のお客様は (サポート技術情報にも記載されているように) 次のシナリオを考慮する必要があります。

TMG を使用していて、ユーザーのログオフを示す logoff.owa を監視するように設定しているとします。現在、この設定を利用している場合、CU8 で再び機能するようになります。これは朗報と言えるでしょう。

また、TMG を使用しているかどうかにかかわらず、サードパーティ製のアプリケーションを Exchange に統合している場合にも、この変更が影響する可能性があります。一部のサードパーティ製のアプリケーションは CU1 で導入された動作に依存していることが確認されています。また、少なくとも 1 つのベンダーは、CU8 の一般公開に向けて、この変更に対応するように既に修正を行っています (TAP に参加している非常に優秀なベンダーであるため、私たちも把握しているのです)。

ご利用のサードパーティ ベンダー製ソリューションがこの変更に対応しておらず、CU8 をインストールした途端に利用できなくなった場合には、どうすればよいでしょうか。これには 2 種類の対処法があります。

  1. Exchange 用のサードパーティ製アドイン アプリを開発しているのに、なぜ Exchange チームのブログを確認していないのかとベンダーに問い合わせます。そして、CU8 以降のデプロイメントで動作するようにアプリが修正される時期を確認します。
  2. 従来 (CU1 以降) の動作に一時的に戻すことができます。この変更は CU8 以降のみでサポートされます。従来の動作に戻す機能は将来の更新時に削除される可能性があるため、この方法を慢性的に利用しないようにしてください。ま た、CU9 以降では web.config に対する手動での変更がすべてリセットされますので、ご注意ください。

従来のログオフ モードを有効にする (signout.aspx へのリダイレクトを無効にする) には、3 つの web.config ファイルに変更を加えます。

 

クライアント アクセスのロールを担うサーバーの以下のファイル

 %ExchangeInstallPath%\FrontEnd\HttpProxy\OWA\web.config

メールボックスのロールを担うサーバーの以下のファイル

 %ExchangeInstallPath%\ClientAccess\OWA\web.config

 %ExchangeInstallPath%\ClientAccess\ECP\web.config

次の行を修正します (変更する前に、必ず web.config のバックアップを作成してください)。

<add key="LogonSettings.SignOutKind" value="LegacyLogOff" />

以下のように変更します ( !- - と末尾の - - を追加することで、コメント行として扱われ、実行されなくなります)。

<!-- add key="LogonSettings.SignOutKind" value="LegacyLogOff" /-->

変更は AppPools によって自動的にリサイクルされます。ただし、AppPools が無効になっている場合は、手動でリサイクルを行う必要があります。

エントリが存在しない場合や、"DefaultSignOut" またはその他の値になっている場合は、ログオフ後に signout.aspx ページが表示されます (既定)。

 

 

繰り返しになりますが、次の累計更新プログラムではこの手動での修正がリセットされるため、CU9 のリリース後に再度修正を行ってください。とはいえ、サードパーティ製アプリを動作させるためにこの変更を行うのであれば、そのアプリが新しい動作に対応 するように更新されることが理想的ではありますが…。

最後の おそらく最も重要なシナリオ は、この変更が行われることによってインストール順序の依存が発生する場合です。さいわい、このようなケースはほとんど存在しませんが、該当する場合には注意が必要です。

簡単に言うと、ユーザーのメールボックスが CU8 のメールボックス サーバー上に存在し、CU6 以前の CAS 経由で接続していると、OWA のログオフ時にこの変更による問題が発生します。CU7 の CAS を利用している場合はどうかと思われる方もいらっしゃるでしょう。CU7 では、この問題が発生しないように、コードに十分な変更が加えられています。まとめると、CU7 (または CU8) の CAS や、CU7 以降のマルチロール サーバーのみを使用している場合には、まったく問題ありません。

問題が発生しないようにするにはどうすればよいのでしょうか。最良の方法は、もちろん、最新の更新プログラムを利用することです。すべてのサーバーに CU7 を適用すれば、何も心配はありません。

しかし、CU6 以前のサーバーを利用していて、CU8 をインストールするまでの期間にユーザーが OWA を使用する可能性がある場合もあると思います。

CAS と MBX のロールを (どういうわけか) 個別に設定している場合、先に CAS を更新することを推奨します。その後、任意の順序で各メールボックス サーバーを更新します。これが最も簡単な解決策です。

あるいは、すべてのサーバーがマルチロールで (すばらしい)、CU6 以前である場合は、以下の 3 つの選択肢があります。

  CU8 のロールアウトを開始する前に、すべてのサーバーを CU7 にアップグレードする。

  アップグレード期間中に問題が発生する可能性があることを了承したうえで、そのまま使用を続ける。

  ローリング アップグレードを実行し、すべての着信接続がアップグレードした CU8 の CAS のみに到達するように負荷分散プールを適切に設定します。この実行方法がわからない場合は、1 番目のオプションを選択してください。

この記事をお読みになって、サーバーを正常に CU8 に更新するための注意事項についてご理解いただけましたら幸いです。また、TMG をご愛用の皆様が、再び正常に機能するログオフ エクスペリエンスにご満足いただけることを願っています。

 

Greg Taylor
Office 365 カスタマー エクスペリエンス担当
主任 PM マネージャー