オンプレミス版 Exchange のハイブリッド先進認証


(この記事は 2017 12 6 日に Exchange Team Blog に投稿された記事 Announcing Hybrid Modern Authentication for Exchange On-Premises の翻訳です。最新情報については、翻訳元の記事をご参照ください。)

Exchange 2013 と Exchange 2016 の次回の累進的な更新プログラム (CU) で、ハイブリッド先進認証 (HMA) のサポートを開始します。Exchange Server 2016 の場合は CU8、Exchange Server 2013 の場合は CU19 になります。

HMA の概要

HMA (Word のオートコレクト機能で HAM に修正されることがありますが、正しくは HMA です) を有効にすると、クラウドから取得した認証トークンを使ってオンプレミスのアプリケーションにアクセスできます。Exchange の場合、オンプレミスのメールボックス ユーザーは、このトークン (OAuth トークン) を使ってオンプレミス版 Exchange の認証を行うことができます。魅力的な響きですが、そもそもこれらのトークンは一体どのようなもので、どのようにして入手できるのでしょうか。

これについては、ハイブリッド認証のしくみに関するブログ記事 (英語) を参照することをお勧めします。さらに、興味があれば Ignite セッション (英語) の映像もご覧いただければ、YouTube の再生回数が増えて私も嬉しいです。いずれも OAuth のコンセプトについて詳しく説明しており、HMA について理解するのに役立ちます。

簡潔な説明については以上ですが、長い説明にも耐えられるという奇特な皆様は、以下についてもお読みください。

HMA を有効にすると、Outlook は Azure AD から Access トークンと OAuth トークンを取得します。取得方法としては、パスワード ハッシュ同期またはパススルー認証用として直接取得する方法と、フェデレーション用として STS 経由で取得する方法があります。オンプレミス版 Exchange がこのトークンを受け入れると、メールボックスへのアクセスが許可されます。

トークンを取得するために使用する資格情報は、ユーザーと ID プロバイダー (iDP) の技量に応じて選択できます。標準的なものとしては、ユーザー名とパスワード、証明書、電話番号、指紋、血流、網膜スキャンなどがありますが、iDP が対応できるのであれば詩の朗読を資格情報として使用してもかまいません。

ただし、この認証を行うためには、AAD 内にユーザーの ID が格納されていなければなりません。また、Exchange ハイブリッド構成ウィザードを使って特定の設定を行う必要があります。「ハイブリッド先進認証 (HMA)」という名称はここから来ています。有効にするには Exchange Online とのハイブリッド構成を行う必要があるのです。

HMA には、「Outlook Mobile でオンプレミス版 Exchange と Microsoft Enterprise Mobility + Security のサポートを開始」のブログ記事で紹介した機能と同じテクノロジが多数採用されています。その 1 つがハイブリッド構成です。ハイブリッド構成について理解すると、手間をかけずにこれらの便利な機能を使いこなせるようになります。

HMA のしくみ

HMA のしくみについては、先ほど紹介したビデオで詳細をご説明していますが、時間のない方のために簡単に説明します。

ID フェデレーションを行っている場合の HMA は、次の図のようになります。

hma1

この図はかなりの力作で、わかりやすいものになっていると思うので、余分な説明は省きます。1 回でわからなくても、何度か目を通してみてください。

HMA を有効にするメリット

重要なポイントです。いくつかのメリットがありますが、主にセキュリティ上のメリットだと思ってください。

HMA はこれまでに Exchange で使用されていた他の認証方法よりも安全性が高いとされています (「先進的」ではわかりにくいと思い、このような表現にしました)。はっきりしない言い方をしましたが、確かな安全性を示すはっきりとした根拠があります。

HMA を有効にするということは、ユーザー認証を iDP にアウトソースするということです。つまり、Exchange は消費者として認証トークンを利用することになります。テキスト メッセージ ベースの多要素認証 (MFA)、血流分析、網膜スキャンなどを Exchange に処理させるよりも、iDP に任せたほうが確実です。Exchange は、認証が完了しユーザーがトークンを取得したことがわかればよいのであって、認証の方法まで把握する必要はありません。

したがって、Exchange の元の認証より強力な認証を選択すれば、明らかに安全性は高くなります。しかし、たとえユーザー名とパスワードを選択したとしても、いったんユーザー認証が完了すればクライアントからサーバーへパスワードを送信する必要がないため、安全性が高くなることに変わりはありません。もちろんこの点は、Basic、NTLM、Kerberos のどれを使用しているかにもよります。HMA は 100% トークン ベースです。トークンには有効期限があり、トークンを使用できるのは特定のアプリケーションやエンドポイントに限られています。

もう 1 つ重要なメリットとしては、クラウド ユーザーとオンプレミス ユーザーの認証フローが同じになるということです。メールボックスの場所にかかわらず、MFA や条件付きアクセス ポリシーが同じように適用されます。このため、安全性を保持しやすくなります。

それだけではありません。HMA を使用すると認証プロンプトの数が少なくなるため、ユーザー エクスペリエンスが向上します。いったん AAD にログインすれば、AAD トークンを使用するあらゆるアプリ、つまり Office 365 のすべてのアプリと HMA 向けに設定されたオンプレミス版 Skype for Business に自由にアクセスできるようになります。Skype for Business の HMA サポートについては、こちらの記事 (英語) を参照してください。

さらに、HMA がより先進的であることも忘れないでください。新しく、より先進的であるということは、より高機能であるということです。では次の項目に移りましょう。

HMA の価格

無料の Azure ID またはフェデレーション ID を使用し、iDP に MFA を任せるのであれば費用はかかりませんが、Azure の高度な機能を利用する場合は有料になります。テナント管理者は、Exchange と Azure のライセンスさえあれば、ツールを実行して HMA を有効にすることができます。

HMA を有効にするために必要な条件

いくつかの前提条件があります。

  1. AAD で次の ID 設定がサポートされていること。
    1. AAD によるフェデレーション ID と、Office 365 でサポートされるオンプレミスの STS
    2. パスワード ハッシュ同期
    3. パススルー認証
  2. いずれの場合もオンプレミス ディレクトリ全体が AAD と同期していて、ログオンに使用するすべてのドメインが同期設定に含まれていること。
  3. Exchange Server が次の条件を満たしていること。
    1. すべてのサーバーが Exchange 2013 (CU19+) または Exchange 2016 (CU8+) であること
    2. 環境内に Exchange 2010 が共存していないこと
    3. MAPI over HTTP が有効になっていること (Exchange 2013 Service Pack 1 以上を新規インストールした場合、通常有効または True に設定されている)
    4. Outlook が使用するすべての仮想ディレクトリ (/AutoDiscover、/EWS、/Mapi、/OAB) で OAuth が有効になっていること
  4. ADAL をサポートするクライアントを使用すること。すなわち、クライアント側のライブラリで OAuth トークンに対応したクライアントを使用できること。これは、先進認証の機能を使用するための必要条件です。Outlook 2013 では、EnableADAL レジストリ キーを設定する必要があります。Outlook 2016 では、このキーは既定で設定済みです。Outlook 2016 for Mac は特に設定なしで機能します。Outlook モバイル (iOS、Android) のサポートは今後追加される予定です。
  5. オンプレミスの AD と Office 365 テナント間の AAD Connect のオプション機能で [Exchange hybrid deployment] が有効になっていること。
  6. ロード バランサーと Exchange サーバー間で SSL オフロードを使用していないこと。
  7. すべてのユーザー ネットワークが効率良く AAD にアクセスできること。

いくつかの条件について、少し詳しく説明します。

まず、環境内に Exchange 2010 が共存していないことという条件ですが、環境内に Exchange 2010 があると HMA を有効にすることができません。それは、最悪の場合、Exchange 2010 のメールボックスを持っているユーザーがメールにアクセスできなくなるからです。なぜこんな事態に陥るかというと、最初の接続で、匿名で OAuth が行われるからです。ユーザーは認証のために AAD にアクセスしますが、トークンを取得したとき Exchange 2010 上にメールボックスがあると、Exchange 2013/2016 から Exchange 2010 へのプロキシ サーバー経由でのアクセスが拒否されます。こうなると、もうどうしようもありません。

そうなることを防ぐために、マイクロソフトでは Exchange 2010 はサポートしないことを表明しています。また、Exchange 2010 が存在する場合、ハイブリッド構成ウィザードで OAuth を有効にすることはできません。どうか試そうとはしないでください。映画ゴーストバスターズの有名なあのシーンよりも悪いことになりかねません。

続いて、RPC/HTTP (Outlook Anywhere) ではなく MAPI/HTTP を使用することという条件についてです。この機能は MAPI/HTTP でしか機能しません。どちらにしても RPC/HTTP とはそろそろ決別の時期です。RPC/HTTP は非常に古いコードで、Office 365 ではもうサポートされていません。新しいものに切り替える良いタイミングです。

次に、すべてのユーザーの ID が AAD に格納されていることという条件についてです。HMA を有効にすると、組織全体で HMA が有効になります。したがって、Exchange に接続するすべてのユーザーに影響が及びます。先進認証をサポートするクライアントから Exchange にアクセスしようとするすべてのユーザーは、AAD にリダイレクトされます。もし一部のユーザーの ID しか AAD 内に存在しないのであれば、該当するユーザーしか認証することができません。すべてのユーザーを認証したいのであれば、すべてのユーザーの ID を AAD に格納する必要があります。

先進認証をサポートするクライアントが必要なことは言うまでもありません。さらに、すべての Exchange 仮想ディレクトリで OAuth を有効にする必要があります。OAuth は既定の設定で有効になっているので、わざわざ注意を促すことではないかもしれませんが、管理者が既定の設定を変更している可能性がないとは言えません。OAuth が有効になっているかどうかを確認する方法については、後ほど説明します。

SSL オフロードを使用するには、ロード バランサーで SSL/TLS 暗号化を無効にし、リクエストを HTTP として送信する必要があります。OAuth のコンテキストで SSL オフロードを使用すると影響があります。オーディエンス クレームの値が HTTPS レコードを指定している場合に、Exchange が HTTP 経由で復号されたリクエストを受信すると、そのリクエストは無効と見なされてしまうからです。SSL オフロードを無効にすれば、オーディエンス クレームの値が変更されても、Exchange が OAuth セッションに失敗することはなくなります。

最後に、すべてのユーザー ネットワークが AAD コメントにアクセスできるという条件についてです。この変更は、サポート対象のクライアントから Exchange まで、さらに社内から社外まで、すべての接続に影響を及ぼします。ユーザーが Exchange との接続を試行すると、サーバーとデスクの距離がたった 3 メートルであろうと、サーバーが地球の反対側のデータセンターにあろうと、HMA フローが発生します。ユーザーが有効なトークンを持っていなければ、トラフィックは AAD に送られることになります。もし複雑なネットワーク構成を使用しているなら、この点を考慮する必要があります。

HMA を有効化する方法

前提条件を確認し、準備ができたとします。準備作業の多くはクライアントに影響を及ぼすことなく行うことができます。クライアントに影響がある場合はあらかじめお知らせしますので安心してください。

できれば、テスト環境またはラボ環境で HMA のテストを実施してから実稼働環境に移行することをお勧めします。認証の変更は慎重に行う必要があります。ユーザー全員がメールを使えなくなるようなことがあってはなりません。

それでは、手順を説明します。まず、Azure Active Directory の設定を行います。

クライアントがオンプレミスの Exchange に接続するために使用する可能性があるすべての URL を AAD に登録し、これらのエンドポイントに対してトークンが発行されるようにします。社内、社外のすべての名前空間もこの対象となります。AAD は社内、社外を問わずすべての接続の既定の認証手段になるからです。ヒント: Exchange の SSL 証明書をチェックし、すべての名前が含まれていることを確認します。

次のコマンドレットを実行し、追加/検証の必要な URL を AAD に登録します。

Get-MapiVirtualDirectory | FL server,*url*
Get-WebServicesVirtualDirectory | FL server,*url*
Get-OABVirtualDirectory | FL server,*url*>

クライアントが接続する可能性のあるすべての URL が https サービス プリンシパル名 (SPN) としてリストに含まれていることを確認します。

    1. こちらの指示 (英語) に従って AAD テナントに接続します。
    2. Exchange 関連の URL の場合、次のコマンドを実行します。AppId の末尾が 02 になっている点に注意してください。

      Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 |
      select -ExpandProperty ServicePrincipalNames

      出力結果は次のようになります。

      [PS] C:\WINDOWS\system32> Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 | select -ExpandProperty ServicePrincipalNames
      https://autodiscover.contoso.com/
      https://mail.contoso.com/
      00000002-0000-0ff1-ce00-000000000000/*.outlook.com
      00000002-0000-0ff1-ce00-000000000000/outlook.com
      00000002-0000-0ff1-ce00-000000000000/mail.office365.com
      00000002-0000-0ff1-ce00-000000000000/outlook.office365.com
      00000002-0000-0ff1-ce00-000000000000/contoso.com
      00000002-0000-0ff1-ce00-000000000000/autodiscover.contoso.com
      00000002-0000-0ff1-ce00-000000000000/contoso.mail.onmicrosoft.com
      00000002-0000-0ff1-ce00-000000000000/autodiscover.contoso.mail.onmicrosoft.com
      00000002-0000-0ff1-ce00-000000000000/mail.contoso.com
      00000002-0000-0ff1-ce00-000000000000

    3. 既に社内および社外の MAPI/HTTP、EWS、OAB、および AutoDiscover https レコードがある場合 (https://mail.contoso.comhttps://mail.corp.contoso.com など)、次のコマンドを使って追加します。完全修飾のドメイン名は正しい名前空間で置き換えます。既存のレコードが含まれている場合は、追加行を削除します。

      $x= Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000
      $x.ServicePrincipalnames.Add("https://mail.corp.contoso.com/")
      $x.ServicePrincipalnames.Add("https://owa.contoso.com/")
      Set-MSOLServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 -ServicePrincipalNames $x.ServicePrincipalNames

    4. 手順 2 を繰り返して、レコードが追加されたことを確認します。すべての URL の https://namespace エントリを探します。<span class="consoletext"00000002-0000-0ff1-ce00-000000000000/namespace エントリではないことに注意してください。

例を見てみましょう。

[PS] C:\WINDOWS\system32> Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 | select -ExpandProperty ServicePrincipalNames
https://autodiscover.contoso.com/
https://mail.contoso.com/
https://mail.corp.contoso.com/
https://owa.contoso.com/

00000002-0000-0ff1-ce00-000000000000/*.outlook.com
00000002-0000-0ff1-ce00-000000000000/outlook.com
00000002-0000-0ff1-ce00-000000000000/mail.office365.com
00000002-0000-0ff1-ce00-000000000000/outlook.office365.com
00000002-0000-0ff1-ce00-000000000000/contoso.com
00000002-0000-0ff1-ce00-000000000000/autodiscover.contoso.com
00000002-0000-0ff1-ce00-000000000000/contoso.mail.onmicrosoft.com
00000002-0000-0ff1-ce00-000000000000/autodiscover.contoso.mail.onmicrosoft.com
00000002-0000-0ff1-ce00-000000000000/mail.contoso.com
00000002-0000-0ff1-ce00-000000000000

次に、EvoSts 認証プロバイダーが存在していることを確認します。ハイブリッド構成ウィザードで作成した Exchange 管理シェルを使います。

Get-AuthServer | where {$_.Name -eq "EvoSts"}

HMA2

存在しない場合は、ここから最新のハイブリッド構成ウィザードをダウンロードして実行します。環境内に Exchange 2010 (エッジ トランスポート サーバーを含む) があると、この認証プロバイダーは作成されません。

Outlook が使用する可能性があるすべての Exchange 仮想ディレクトリで OAuth が有効になっていることを確認します。

次のコマンドレットを実行します。なお、-ADPropertiesOnly は使用しないでください。正しく機能しないことがあります。

Get-MapiVirtualDirectory | FL server,*url*,*auth*
Get-WebServicesVirtualDirectory | FL server,*url*,*oauth*
Get-OABVirtualDirectory | FL server,*url*,*oauth*
Get-AutoDiscoverVirtualDirectory | FL server,*oauth*

すべての仮想ディレクトリで OAuth が有効になっていることを確認します。次のような出力結果が得られます。特にハイライトされている箇所に注目してください。

[PS] C:\Windows\system32>Get-MapiVirtualDirectory | fl server,*url*,*auth*
Server : EX1
InternalUrl : https://mail.contoso.com/mapi
ExternalUrl : https://mail.contoso.com/mapi
IISAuthenticationMethods : {Ntlm, OAuth, Negotiate}
InternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}
ExternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}

[PS] C:\Windows\system32> Get-WebServicesVirtualDirectory | fl server,*url*,*auth*
Server : EX1
InternalNLBBypassUrl :
InternalUrl : https://mail.contoso.com/EWS/Exchange.asmx
ExternalUrl : https://mail.contoso.com/EWS/Exchange.asmx
CertificateAuthentication :
InternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth}
ExternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth}
LiveIdNegotiateAuthentication :
WSSecurityAuthentication : True
LiveIdBasicAuthentication : False
BasicAuthentication : False
DigestAuthentication : False
WindowsAuthentication : True
OAuthAuthentication : True
AdfsAuthentication : False

[PS] C:\Windows\system32> Get-OabVirtualDirectory | fl server,*url*,*auth*
Server : EX1
InternalUrl : https://mail.contoso.com/OAB
ExternalUrl : https://mail.contoso.com/OAB
BasicAuthentication : False
WindowsAuthentication : True
OAuthAuthentication : True
InternalAuthenticationMethods : {WindowsIntegrated, OAuth}
ExternalAuthenticationMethods : {WindowsIntegrated, OAuth}

[PS] C:\Windows\system32>Get-AutodiscoverVirtualDirectory | fl server,*auth*
Server : EX1
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth}
ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth}
LiveIdNegotiateAuthentication : False
WSSecurityAuthentication : True
LiveIdBasicAuthentication : False
BasicAuthentication : True
DigestAuthentication : False
WindowsAuthentication : True
OAuthAuthentication : True
AdfsAuthentication : False

出力結果を確認したら、必要に応じていくつかの場所に OAuth を追加する必要があります。すべてのサーバーに一貫した設定を行う必要があります。10 台のサーバーのうちたった 1 台の設定が間違っているだけで台なしになりますので、確実にトラブルシューティングを行ってください。

(メモ: なぜ Get-AutodiscoverVirtualDirectory コマンドレットに *url* を含めなかったかおわかりでしょうか。答えはコメント セクションを参照してください。なお、この問題に正解しても賞品は出ませんので、悪しからず。)

認証方法を追加する場合のヒントを紹介します。/Mapi 以外については、-OAuthAuthentication プロパティを $True に設定します。必要な作業はこれだけです。

一方、/Mapi については、認証方法を明示的に追加する必要があります。@Add PowerShell は使わないでください。オンライン コースで学んだことがあっても、同僚が「ECP のような子供騙しは使わないんだ」と言ったとしても、@Add PowerShell の使用は避けてください。期待どおりに動作しないことがあるからです。

組織内のすべての Mapi 仮想ディレクトリに OAuth を追加するには、次のようにします。

Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -IISAuthenticationMethods Ntlm, OAuth, Negotiate

この時点で影響を受けるクライアントはありません。万一仮想ディレクトリの設定に失敗した場合も、OAuth を追加するだけで済みます。ここからの作業は、クライアントに多少の影響があります。したがって、通常の業務時間外に行うことをお勧めします。

次の点を確認してください。

  1. Azure AD の設定のセクションの手順をすべて完了したことを確認します。必要な SPN がすべて揃っていることを確認します。
  2. Outlook が使用するすべての仮想ディレクトリで OAuth が有効になっていることを確認します。
  3. クライアントが最新の状態で、HMA 対応であることを確認します。これは、サポート要件 (機械翻訳) に記載されているバージョンからわかります。
  4. これから行う作業内容についてユーザーに周知します。
  5. EvoSts 認証プロバイダーを既定のプロバイダーに設定します。この手順は、Outlook 2016 for Mac および OAuth をサポートするネイティブ EAS クライアントに影響を及ぼします。

    Set-AuthServer EvoSTS -IsDefaultAuthorizationEndpoint $true

  6. Windows Outlook の OAuth クライアント機能を有効にします。

    Set-OrganizationConfig -OAuth2ClientProfileEnabled $True

これで完了です。たった 2 つのコマンドレットですべての準備が完了します。エネルギーは効率良く使えということですね。

HMA を使用していることを確認するには

HMA を有効にしたら、次回から新しい認証フローを使ってクライアントを認証する必要があります。HMA を有効にしただけでは、クライアントの再認証は行われません。

HMA を有効にした後、HMA が機能しているかどうかを確認するには、まず Outlook を再起動します。これで、クライアントは先進認証フローを使用するようになります。

Office 365 の ADAL が生成した認証ダイアログを確認してください。ユーザー名を入力すると、ADFS を使用しているときと同じようにオンプレミスの IDP にリダイレクトされます。統合認証が設定されている場合は特に何も表示されませんが、プロンプトが表示される場合はパスワードを入力します。AAD の設定によっては、MFA が必要になります。

接続に成功したら、Outlook の [Connection Status] ダイアログを確認します (Ctrl キーを押しながら Outlook のトレイ アイコンを右クリック)。[Authn] 列に「Bearer」と表示されていれば、HMA を使用しています。

hma3

お疲れ様でした。帰宅準備をする前に、他の人たちも問題なく設定を完了できていることを確認してください。

問題発生 - HMA のトラブルシューティング

このセクションを読んでいるということは、何か問題が発生したということでしょう。来年までこのセクションを公開しないでおこうかと思いましたが、それではお困りの方もいらっしゃると思いますので、やめておきます。

もし何かうまくいかない場合は、まずここまでのすべての手順を実行したかどうか確認してください。一部だけや理解できたものだけではなく、すべての手順を実行しなければうまくいきません。ビュッフェ スタイルの食事ではありませんから、好みの手順だけ選んで実行しても意味がありません。

すべての手順を確かに実行したのにうまくいかない場合は、トラブルシューティングを行いましょう。

少しだけ後戻りしてもよいのであれば、最後の 2 つのコマンドレットをもう一度実行してください。ただし、今回は設定を False にします。Exchange で IISReset を複数回実行しなければならない可能性があります。パフォーマンスを向上させるため、あちこちで設定がキャッシュされているからです。しかし、最後の 2 つのコマンドを実行すれば、少なくとも元の状態に戻すことができます (この作業を行う前に、瞬時に詳しいトレースを取得することができます。このトレースは、何がうまくいかないのかを特定するのに役立ちます)。

今すぐ設定を元に戻したくない場合は、トラブルシューティングが必要になります。

まず、クライアントで何らかの警告ダイアログが表示されたか、証明書のエラーがあったかについて思い返してください。たとえば信頼された証明機関から発行されていない、名前の不一致があるなどです。このような問題が発生すると、フローが停止してしまいます。クライアントにとって最も重要なことは、通信相手のエンドポイントを信頼することです。通信相手のエンドポイントには、Exchange、AAD (login.windows.net および login.microsoftonline.com)、ADFS、使用している iDP などがあります。クライアントがサイトを保護している証明書の発行機関を信頼していれば、問題はありません。名前の翻訳などが行われると、警告が表示されたり、警告なしで失敗したりします。

最近の例を紹介します。このケースでは、Web アプリケーション プロキシ (WAP) を使って Exchange を公開していました。これはパススルー モードで行う必要があります。このケースにおける AutoDiscover の公開ルールは、外部向けに autodiscover.contoso.com を使用することです。しかし WAP 公開ルールは、トラフィックを社内の mail.contoso.com に送信するように設定されていました。Outlook は AAD で https://autodiscover.contoso.com という名前のリソースのトークンを取得しようとするので、この処理は失敗します。Outlook はトークンを WAP に渡します。WAP は target URI として https://mail.contoso.com を使ってトークンを Exchange に送信します。すると、トークン内の URI と WAP が使用する URI が一致しないので、エラーになります。したがって、この方法は試さないでください。このようなエラーをどのように検出するかは、後で説明します。

証明書に問題がない場合、他の点をチェックする必要があります。トラフィックを追跡してみましょう。個人的に私が気に入っているツールは Fiddler (英語) ですが、他のツールを使ってもかまいません。

Fiddler や同様のツールでは、クライアントとサーバーの間でやり取りされるすべての内容をキャプチャできます。Basic 認証を使用する場合は、Basic 認証の証明書がキャプチャされます。Fiddler が追跡するすべての内容をキャプチャして、同僚やマイクロソフトと共有することは避けてください。マイクロソフトにお客様自身のパスワードを送信しないでください。テスト アカウントを使用するか、Fiddler について十分に学び、パスワードを削除してください。

Fiddler のインストール方法と使用方法については、Fiddler の開発元である Telerik のサイトを参照してください。ここでは、私が個人的に学んだ HMA のデバッグ方法を紹介します。

Fiddler ルート証明書を信頼されたルート ストアにインストールすると、Fiddler は man-in-the-middle プロキシとして機能し、選択したクライアントからのトラフィックをキャプチャするようになります。すべてのトラフィックは TLS で暗号化されているので、HTTPS 復号を有効にする必要があります ([Tools]、[Options]、[HTTPS] の順に選択)。

ADFS を使用している場合は、ADFS の URL の復号をスキップするように Fiddler を設定するか、ADFS のセキュリティを若干ゆるめて、トラフィックが適切にキャプチャされるようにします。なお、この設定はデバッグ目的でトラフィックをキャプチャする場合にのみ行います。デバッグが終わったら元に戻します。まず iDP の復号を回避します。もしこれが問題の原因であると考えられる場合は、再度ここに戻ってきます。

フェデレーション サーバーがサポートする認証の拡張保護のレベルをオフに設定します。

Set-AdfsProperties -extendedprotectiontokencheck none

キャプチャが完了したら、既定の設定に戻します。

Set-AdfsProperties -extendedprotectiontokencheck Allow

ADFS の役立つ設定については、こちらの記事 (英語) を参照してください。

キャプチャを実行します。まず Fiddler を起動し、次に Outlook を起動します。その他のアプリケーションやブラウザーはすべて閉じておくことをお勧めします。そうすることで Fiddler のノイズを防ぐことができます。Fiddler と Outlook に注意を払いつつ、Outlook を使ってログインを試行します。または問題の再現を試み、トレースを中断します (F12)。

何が起こったかを分析します。個人的には、画面の左側にトラフィックを表示し、右側の上部にリクエスト、下部に応答を表示するのが好みですが、各自ご自由に設定していただいてかまいません。Fiddler は各フレームに情報を表示し、それぞれをリクエストと応答に分割します。この点だけわかっていれば十分です。

次のようなフローが表示されます。

クライアントが Exchange に接続し、空の 'Bearer' ヘッダーを送信します。これは Exchange に OAuth を行うことを暗示しますが、まだトークンを取得していません。Bearer と何らかの文字列を送信するとしたら、それはお客様自身のトークンになります。

以下に例を 2 つ示します。チェックするヘッダー セクションは Security です。これは Fiddler のヘッダー ビューを使用しています。Security ヘッダーの内容を確認してください。左側に Bearer、右側に Bearer とトークンを表示します。

hma4 hma5

Exchange が応答します。Fiddler の同じパケットの下部で、トークン (AAD へのリンク) を取得できます。

hma6

右にスクロールすると authorization_uri (AAD) が表示されます。

hma7

通常、Outlook はこの場所にアクセスし、認証を行い、トークンを取得して、Exchange に戻ります。Exchange に戻ったら、Bearer とトークンを使って接続を試行します。接続に成功したら完了です。

うまくいったでしょうか。

クライアントの障害

クライアントが空の Bearer ヘッダーを送信しない場合、Bearer が実行されません。これにはいくつかの原因が考えられます。

まず、Bearer をサポートしない Outlook 2010 を使用している可能性があります。この場合は、Outlook をアップグレードしてください。

あるいは、Outlook 2013 を使用しているが、EnableADAL レジストリ キーを設定するのを忘れているのかもしれません。この場合は、以下のリンクを参照してください。

Outlook 2016 を使用していて、EnableADAL が既定で設定されており、それでもなおヘッダーが送信されないのだとしたら、原因は何でしょう。

おそらく、だれかがレジストリをいじったか、GPO を使ってレジストリ キーを設定したのかもしれません。レジストリを編集した 3 日後に車の衝突事故を起こした人を知っています。ですから、警告は無視しないようにお願いします。

この記事のようにキーが設定されていることを確認してください。

Outlook 2016 for Mac でも MA を無効にできます (既定の設定では有効)。ターミナルから次のコマンドを実行して、既定の設定に戻すことができます。

defaults write com.microsoft.Outlook DisableModernAuth -bool NO

クライアントがヘッダーを送信しない場合、このようにして対処します。再度ヘッダーが送信されるかどうか確認してください。

Auth_URI の障害

次に、サーバーが authorization_uri を返さないか、不正な authorization_uri を返している可能性があります。

authorization_uri が返されない場合、EvoSts AuthServer で IsDefaultAuthorizationEndpoint が $true に設定されていません。以下のコマンドでチェックします。

Set-AuthServer EvoSts -IsDefaultAuthorizationEndpoint $true

期待したとおりの値が返ってこない場合、正しい AuthServer が既定のサーバーに設定されていることを確認します。このフローでは AAD の使用しかサポートされません。オンプレミスの ADFS エンドポイントを設定すれば AAD なしでも機能するというのは間違いです。うまくいきませんので、あえて試そうとはしないでください。Exchange 2019 のリリースを待ってください。ああ、つい口が滑ってしまいました。

組織レベルで HMA が有効になっているのに、期待どおりの authorization_uri が得られない場合は、接続しようとしている Outlook 仮想ディレクトリで OAuth が有効になっていません。すべてのサーバーのすべての仮想ディレクトリに OAuth が有効になっていることを確認してください。「HMA を有効化する方法」のセクションに戻り、仮想ディレクトリをチェックしてください。

設定にまったく問題がないのに、クライアントが反応しない場合もあります。その場合は、応答の以下の部分をチェックしてください。

HTTP/1.1 401 Unauthorized
Content-Length: 0
Server: Microsoft-IIS/8.5 Microsoft-HTTPAPI/2.0
request-id: a8e9dfb4-cb06-4b18-80a0-b110220177e1
Www-Authenticate: Negotiate
Www-Authenticate: NTLM
Www-Authenticate: Basic realm="autodiscover.contoso.com"
X-FEServer: CONTOSOEX16
x-ms-diagnostics: 4000000;reason="Flighting is not enabled for domain 'gregt@contoso.com'.";error_category="oauth_not_available"
X-Powered-By: ASP.NET
WWW-Authenticate: Bearer client_id="00000002-0000-0ff1-ce00-000000000000", trusted_issuers="00000001-0000-0000-c000-000000000000@f31f3647-5d87-4b69-a0b6-73f62aeab14c", token_types="app_asserted_user_v1 service_asserted_app_v1", authorization_uri="https://login.windows.net/common/oauth2/authorize"
Date: Thu, 13 Jul 2017 18:22:13 GMT
Proxy-Support: Session-Based-Authentication

これは興味深い応答です。トークンを取得せよ (www-authenticate) と言っているのに、x-ms-diagnostics では取得するなと言っています。Exchange ではこの指示が理解されないのでしょうか。

この場合、OAuth は有効になっているが、Outlook for Windows では有効になっていません。上記の 2 つのコマンドのうち一方しか実行していないか、両方を実行したにもかかわらず、コマンドの実行が完了していない可能性があります。

以下を実行して、OAuth2ClientProfileEnabled プロパティが $true に設定されていることを確認してください。

(Get-OrganizationConfig).OAuth2ClientProfileEnabled

その他の障害

トークンを取得し、Exchange で、組織レベルで OAuth が有効になっていて、すべての仮想ディレクトリの設定にも問題がないのに、まだ接続に失敗する場合があります。何が問題なのでしょうか。

この場合は、エラーらしきものがないか、サーバーの応答を詳しく見ていく必要があります。エラーは通常英語で出力されています。わかりやすいとは限らないのですが、いくつか例を紹介します。

SPN の欠落

クライアントが AAD にアクセスした結果、トークンと次のエラーを取得することがあります。

Location: urn:ietf:wg:oauth:2.0:oob?error=invalid_resource&error_description=AADSTS50001%3a+The+application+named+https%3a%2f%2fmail.contoso.com%2f+was+not+found+in+the+tenant+named+contoso.com.++This+can+happen+if+the+application+has+not+been+installed+by+the+administrator+of+the+tenant+or+consented+to+by+any+user+in+the+tenant.++You+might+have+sent+your+authentication+request+to+the+wrong+tenant.%0d%0aTrace+ID%3a+cf03a6bd-610b-47d5-bf0b-90e59d0e0100%0d%0aCorrelation+ID%3a+87a777b4-fb7b-4d22-a82b-b97fcc2c67d4%0d%0aTimestamp%3a+2017-11-17+23%3a31%3a02Z

名前の不一致

このエラーについては既に取り上げました。クライアントとサーバー間のデバイスで、使用する名前が異なっています。トークンは特定の URI を対象に発行されますから、その名前を変更すると、次のような結果になります。

HTTP/1.1 401 Unauthorized
Content-Length: 0
WWW-Authenticate: Bearer client_id="00000002-0000-0ff1-ce00-000000000000", trusted_issuers="00000001-0000-0000-c000-000000000000@8da56bec-0d27-4cac-ab06-52ee2c40ea22,00000004-0000-0ff1-ce00-000000000000@contoso.com,00000003-0000-0ff1-ce00-000000000000@8da56bec-0d27-4cac-ab06-52ee2c40ea22", token_types="app_asserted_user_v1 service_asserted_app_v1", authorization_uri="https://login.windows.net/common/oauth2/authorize", error="invalid_token"
Server: Microsoft-IIS/8.5 Microsoft-HTTPAPI/2.0
request-id: 5fdfec03-2389-42b9-bab9-c787a49d09ca
Www-Authenticate: Negotiate
Www-Authenticate: NTLM
Www-Authenticate: Basic realm="mail.contoso.com"
X-FEServer: RGBMSX02
x-ms-diagnostics: 2000003;reason="The hostname component of the audience claim value 'https://autodiscover.contoso.com' is invalid";error_category="invalid_resource"
X-Powered-By: ASP.NET
Date: Thu, 16 Nov 2017 20:37:48 GMT

SSL オフロード

前のセクションで述べたように、トークンは特定の URI に対して発行されます。また、トークンにはプロトコルの値が含まれています (https://)。ロード バランサーが SSL をオフロードすると、Exchange が受信するリクエストは HTTP 経由になるため、https:// で始まるプロトコルの値と一致せず、エラーになります。

Content-Length →0
Date →Thu, 30 Nov 2017 07:52:52 GMT
Server →Microsoft-IIS/8.5
WWW-Authenticate →Bearer client_id="00000002-0000-0ff1-ce00-000000000000", trusted_issuers="00000001-0000-0000-c000-000000000000@00c118a9-2de9-41d3-b39a-81648a7a5e4d", authorization_uri="https://login.windows.net/common/oauth2/authorize", error="invalid_token"
WWW-Authenticate →Basic realm="mail.contoso.com"
X-FEServer →CTSINPUNDEVMB02
X-Powered-By →ASP.NET
request-id →2323088f-8838-4f97-a88d-559bfcf92866
x-ms-diagnostics →2000003;
reason="The hostname component of the audience claim value is invalid. Expected 'https://mail.contoso.com'. Actual 'http://mail.contoso.com'.";error_category="invalid_resource"

不明なユーザー

すべてのユーザーを AAD と同期するというアドバイスに従っていますか。

HTTP/1.1 401 Unauthorized
Cache-Control: private
Server: Microsoft-IIS/7.5
request-id: 63b3e26c-e7fe-4c4e-a0fb-26feddcb1a33
Set-Cookie: ClientId=E9459F787DAA4FA880A70B0941F02AC3; expires=Wed, 25-Oct-2017 11:59:16 GMT; path=/; HttpOnly
X-CalculatedBETarget: ex1.contoso.com
WWW-Authenticate: Bearer client_id="00000002-0000-0ff1-ce00-000000000000", trusted_issuers="00000001-0000-0000-c000-000000000000@cc2e9d54-565d-4b36-b7f0-9866c19f9b17"
x-ms-diagnostics: 2000005;reason="The user specified by the user-context in the token does not exist.";error_category="invalid_user"
X-AspNet-Version: 4.0.30319
WWW-Authenticate: Basic realm="mail.contoso.com"
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
X-FEServer: E15
Date: Tue, 25 Oct 2016 11:59:16 GMT
Content-Length: 0

パスワードの変更

ユーザーがパスワードを変更した場合、新しい Refresh/Access トークン ペアを取得して再認証する必要があります。

HTTP/1.1 400 Bad Request
Cache-Control: no-cache, no-store
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.5
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
x-ms-request-id: f840b3e7-8740-4698-b252-d759825e0300
P3P: CP="DSP CUR OTPi IND OTRi ONL FIN"
Set-Cookie: esctx=AQABAAAAAABHh4kmS_aKT5XrjzxRAtHz3lyJfwgypqTMzLvXD-deUmtaub0aqU_17uPZe3xCZbgKz8Ws99KNxVJSM0AglTVLUEtzTz8y8wTTavHlEG6on2cOjXqRtbgr2DLezsw_OZ7JP4M42qZfMd1mR0BlTLWI3dSllBFpS9Epvh5Yi0Of5eQkOHL7x97IDk_o1EWB7lEgAA; domain=.login.windows.net; path=/; secure; HttpOnly
Set-Cookie: x-ms-gateway-slice=008; path=/; secure; HttpOnly
Set-Cookie: stsservicecookie=ests; path=/; secure; HttpOnly
X-Powered-By: ASP.NET
Date: Thu, 16 Nov 2017 20:36:16 GMT
Content-Length: 605
{"error":"invalid_grant","error_description":"AADSTS50173: The provided grant has expired due to it being revoked. The user might have changed or reset their password. The grant was issued on '2017-10-28T17:20:13.2960000Z' and the TokensValidFrom date for this user is '2017-11-16T20:27:45.0000000Z'\r\nTrace ID: f840b3e7-8740-4698-b252-d759825e0300\r\nCorrelation ID: f3fc8b2f-7cf1-4ce8-b34d-5dd41aba0a02\r\nTimestamp: 2017-11-16 20:36:16Z","error_codes":[50173],"timestamp":"2017-11-16 20:36:16Z","trace_id":"f840b3e7-8740-4698-b252-d759825e0300","correlation_id":"f3fc8b2f-7cf1-4ce8-b34d-5dd41aba0a02"}

Unicorn Rampage

Unicorn Rampage が発生してすべてのトークンが無効になった場合、次のような出力が得られます。

HTTP/1.1 400 Bad Unicorn
Cache-Control: no-cache, no-store, not-bloody-safe
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.5
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
x-ms-request-id: f840b3e7-8740-4698-b252-d759825e0300
P3P: CP="DSP CUR OTPi IND OTRi ONL FIN"
Set-Cookie: esctx=AQABAAAAAABHh4kmS_aKT5XrjzxRAtHz3lyJfwgypqTMzLvXD-deUmtaub0aqU_17uPZe3xCZbgKz8Ws99KNxVJSM0AglTVLUEtzTz8y8wTTavHlEG6on2cOjXqRtbgr2DLezsw_OZ7JP4M42qZfMd1mR0BlTLWI3dSllBFpS9Epvh5Yi0Of5eQkOHL7x97IDk_o1EWB7lEgAA; domain=.login.windows.net; path=/; secure; HttpOnly
Set-Cookie: x-ms-gateway-slice=008; path=/; secure; HttpOnly
Set-Cookie: stsservicecookie=ests; path=/; secure; HttpOnly
X-Powered-By: ASP.NET
Date: Thu, 16 Nov 2017 20:36:16 GMT
Content-Length: 605
{"error":"unicorn_rampage","error_description":"The Unicorns are on a rampage. It’s time go home” '2017-11-16T20:27:45.0000000Z'\r\nTrace ID: f840b3e7-8740-4698-b252-d759825e0300\r\nCorrelation ID: f3fc8b2f-7cf1-4ce8-b34d-5dd41aba0a02\r\nTimestamp: 2017-11-16 20:36:16Z","error_codes":[50173],"timestamp":"2017-11-16 20:36:16Z","trace_id":"f840b3e7-8740-4698-b252-d759825e0300","correlation_id":"f3fc8b2f-7cf1-4ce8-b34d-5dd41aba0a02"}

明らかに問題が発生していますが、強い味方である Fiddler を使えばデバッグできます。注意深く見ていると、答えが見つかることがよくあります。

トークンの表示

最後にちょっとしたおまけとして、実際のアクセス トークンがどのようなものなのか見てみましょう。それほど驚くものではないので、気軽に確認してください。

Fiddler のリクエスト ウィンドウ (画面上部) を見てください。ヘッダーと値が表示されています。ここで値を右クリックし、[Send to Text Wizard] を選択します。さらに、[Transform] を [From Base64] に設定します。または、値全体をコピーし、https://jwt.io (英語) などのサイトを使って、読み取り可能なフォーマットに変更します。

{
"aud": "https://autodiscover.contoso.com/",
"iss": "https://sts.windows.net/f31f3647-5d87-4b69-a0b6-73f62aeab14c/",
"acr": "1",
"aio": "ASQA2/8DAAAAn27t2aiyI+heHYucfj0pMmQhcEEYkgRP6+2ox9akUsM=",
"amr": [
"pwd"
],
"appid": "d3590ed6-52b3-4102-aeff-aad2292ab01c",
"appidacr": "0",
"e_exp": 262800,
"enfpolids": [],
"family_name": "Taylor",
"given_name": "Greg",
"ipaddr": “100.100.100.100",
"name": "Greg Taylor (sounds like a cool guy)",
"oid": "7f199a96-50b1-4675-9db0-57b362c5d564",
"onprem_sid": "S-1-5-21-2366433183-230171048-1893555995-1654",
"platf": "3",
"puid": "1003BFFD9ACA40EE",
"scp": "Calendars.ReadWrite Contacts.ReadWrite Files.ReadWrite.All Group.ReadWrite.All Mail.ReadWrite Mail.Send Privilege.ELT Signals-Internal.Read Signals-Internal.ReadWrite Tags.ReadWrite user_impersonation",
"sub": "32Q7MW8A7kNX5dPed4_XkHP4YwuC6rA8yBwnoROnSlU",
"tid": "f31f3647-5d87-4b69-a0b6-73f62aeab14c",
"unique_name": "GregT@contoso.com",
"upn": "GregT@contoso.com",
"ver": "1.0"
}

どうでしたか。私は、"enfpolids" 列が空欄になっているのを見てほっとしているところです。まるで医師から診断を受けるときのような心境です。

まとめ

この記事では、HMA のメリットと安全性が高い理由について説明しました。さらに、HMA の使用準備、有効化する方法、トラブルシューティングの方法についても取り上げました。

他の変更を導入する場合と同じく、HMA を導入するときも慎重に計画し、実行に移す必要があります。特に認証の設定を行うときは十分に注意してください。ユーザーが接続できなくなったら深刻な問題になります。

HMA については、マイクロソフト内でも数か月前から試行錯誤を繰り返してきました。うまく動作しなかったときには、どんなに SPN が恋しかったか知れません。しかし、十分に時間を取って適切に準備すれば、より強力で高品質な最新の認証手段を手に入れられます。

ご健闘をお祈りいたします。

 

Greg Taylor
Office 365 カスタマー エクスペリエンス担当
主任プログラム マネージャー

※ 本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。

Skip to main content