Partager via


ADFS を使用して Exchange Online の認証を行っている環境で認証エラーが発生する場合の調査アプローチや対処策について

こんにちは。Exchange サポートの益森です。

今回は、ADFS を使用して Exchange Online の認証を行っている環境で陥りやすい問題について紹介させていただきます。

まず、ADFS を使用して Exchange Online の認証を行っている環境の場合、ADFS のクレームルールを使用して、接続できるネットワークやアプリケーションを制御しているお客様も多いと思います。

例) 基本的には社内ネットワークからのみ接続を許可し、社外からは特定の IP アドレスやアプリケーションからしか接続を許可しない

 
<構成例>

 
そして、Office 365 環境で使用するアプリケーションや API を使用する自作プログラムにおいて、認証に失敗する (HTTP の 401 が返される) というお問い合わせをいただくことがございますが、調査した結果、ADFS のクレーム ルールによりトークンの発行に失敗していたことが原因であったというケースもございます。

例えば、Exchange Online 観点では、以下のようなシナリオおいて、ADFS のクレーム ルールによりトークンの発行に失敗したという報告をいただきやすい傾向があります。
 
1) リモート PowerShell で基本認証を使用して Exchange Online Powershell に接続する
2) EWS Managed API を使用して基本認証で Exchange Online に接続する
 
そのため、上記のようなシナリオにおける調査アプローチ (ADFS の場合) や対処策についてご紹介させていただきます。

 

1. フェデレーションサービスでトークンの発行に失敗していないか確認する

まず、認証に使用しているドメインについて、フェデレーションサービスが使用されているかどうか、以下の管理コマンドで確認します。

 - 手順
 1. インターネットに接続している任意のコンピューター上で "Windows PowerShell 用 Windows Azure Active Directory モジュール" を管理者として実行します。

 2. 起動した PowerShell にて Connect-MsolService コマンドを実行します。
 ※認証ダイアログが表示されますので、管理者ユーザーの資格情報を入力して [OK] ボタンをクリックします。

 - 参考情報
 Title: Office 365 PowerShell への接続
 URL: https://technet.microsoft.com/ja-JP/library/dn975125.aspx

 
  Get-MsolDomain
 
 結果例)
 Name   Status   Authentication
 ----   ------   --------------
 contoso.com   Verified   Federated ※Federated の場合、フェデレーションサービスにより認証されています
 contoso.onmicrosoft.com   Verified   Managed
 contoso.mail.onmicrosoft.com   Verified   Managed
 
上記結果より、認証に使用しているドメインについて、フェデレーションサービスが使用されていることが確認できた場合は、認証に失敗した時間帯において、フェデレーション  
サービス側のログを確認します。

今回は、ADFS を使用している場合の確認方法についてご案内いたします。
※必要に応じて、ADFS 管理者と連携の上、ご確認いただければと思います。

 
<監査ログの有効化>

まず、事前に ADFS 側で監査ログを有効にしておきます。
有効化の詳細な手順については以下の情報を参考にしてください。

Title : Azure AD Connect Health エージェントのインストール (AD FS の監査の有効化)
URL : /ja-jp/azure/active-directory/connect-health/active-directory-aadconnect-health-agent-install

そして、事象を再現させます。

 
<監査ログの確認>

事象を再現させた時間、ユーザーの情報を元に監査ログを確認します。
例えば、トークンの発行に失敗した場合は、以下のようなログが記録されます。
 
---
ログの名前: AD FS/Admin
ソース: AD FS
日付: 2018/07/07 18:27:05
イベント ID: 325
タスクのカテゴリ: なし
レベル: エラー
キーワード: AD FS
ユーザー: ******
コンピューター: ******
説明:
フェデレーション サービスは、発信者 'ドメイン名\ユーザー名' のトークンの発行を承認できませんでした。発信者には、証明書利用者 'urn:federation:MicrosoftOnline' のトークンを要求する権限がありません。 発信者 ID については、同じ Instance ID を持つイベント 501 を参照してください。

Instance ID a0916f0a-c8df-44ea-be14-9213997c47b8
---
 
そして、上記 Instance ID を持つイベント 501 を参照します。
 
---
ログの名前: Security
ソース: AD FS Auditing
日付: 2018/07/07 18:27:05
イベント ID: 501
タスクのカテゴリ: (3)
レベル: Information
キーワード: Classic,Audit Success
ユーザー: CONTOSO\ADFSUser
コンピューター: ADFSComputer.contoso.com
説明:

Instance ID a0916f0a-c8df-44ea-be14-9213997c47b8のイベント エントリの詳細。Instance IDが同じで別の詳細を持つイベントが他にある可能性があります。

Instance ID:
a0916f0a-c8df-44ea-be14-9213997c47b8

発信者 ID:
https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid
S-1-1-0

https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application
***** ※プロトコル

https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.3; WOW64; Trident/7.0; .NET4.0E; .NET4.0C; Microsoft Outlook 16.0.8431) ※アプリケーション
https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path
/adfs/ls/
https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork
false ※組織内からの要求かどうか
https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy
ADFSProxy ※経由したプロキシサーバー名

https://schemas.microsoft.com/2012/01/requestcontext/claims/client-request-id
56c01eee-a1a4-4b6f-bd3e-e365d8163231
https://schemas.microsoft.com/2012/01/requestcontext/claims/relyingpartytrustid
https://login.microsoftonline.com/login.srf

https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip
**.**.**.** ※フェデレーションに対する直近の接続元 IP アドレス
---
 
こちらを確認する上でのポイントは以下の通りです。

・組織内からの要求になっているか
・組織外からの要求の場合、接続元 IP アドレス、プロトコル、アプリケーションからの要求が ADFS のクレーム ルールで許可されているか

 

2. 対処策について

基本的には、1. で調査した結果を踏まえ、ADFS のクレーム ルールの見直しをすることが対処策となりますが、今回は、上述した以下のシナリオにおける対処策についてもう少し説明いたします。

1) リモート PowerShell で基本認証を使用して Exchange Online Powershell に接続する
2) EWS Managed API を使用して基本認証で Exchange Online に接続する

まず、なぜ以下のようなシナリオで意図せず認証に失敗してしまいやすいのかですが、上記のシナリオについて、既定ではアクティブ認証となり、社内ネットワークで利用している場合においても、以下のように [Exchange Online -> ADFS Proxy] の経路で認証が行われるためです。

つまり、ADFS のクレーム ルールにて、組織外からの接続は全て拒否している場合や、上記認証フローを踏まえ、接続元の IP アドレスやアプリケーションを許可していない場合は、トークンの発行に失敗してしまいます。

そのため、上記認証フローも考慮して ADFS のクレームルールを見直すことが対処策となります。

ただし、上記 Exchange Online へ接続するシナリオについては、パッシブ認証(先進認証) を使用するようにすることで、ADFS のクレームルールを変更せずに認証のエラーを回避できる可能性もあるため方法を紹介させていただきます。

1) については、Microsoft Exchange Online Powershell Module を使用することで、先進認証を使用して Exchange Online PowerShell に接続することが可能です。
 
 - 手順
 1. Internet Explorer を起動し、以下にアクセスします。
  https://outlook.office365.com/ecp

 2. [ハイブリッド] をクリックして画面右に表示される [Exchange Online PowerShell Module … ] の下にある [構成] をクリックします。

 3. Microsoft Exchange Online Powershell Module のインストール確認を求められますので [インストール] をクリックします。

 4. インストールが完了しましたら、[実行] 確認が求められますので実行し PowerShell を起動します。
  また、デスクトップにも PowerShell のショートカットが作成されてますので、そちらからの起動でも問題ございません。

 5. 以下の様に PowerShell 上で実行し、Exchange Online への接続が可能かを確認します。

  Connect-EXOPSSession -UserPrincipalName <管理者アカウントの UPN>

 上記コマンド実行後、WEB ベースの認証画面が表示されますので指定したアカウントのパスワードを入力してください。

 - 参考情報
 Title : Connect to Exchange Online PowerShell using multi-factor authentication
 URL : /en-us/powershell/exchange/exchange-online/connect-to-exchange-online-powershell/mfa-connect-to-exchange-online-powershell?view=exchange-ps

2) については、以下の技術情報の通り、ADAL 等のライブラリを使用して取得したアクセス トークンを使用して EWS リクエストを行うようにすることで、先進認証を使用することが可能です。
 
Title : OAuth を使用して、EWS アプリケーションを認証します
URL : /ja-jp/exchange/client-developer/exchange-web-services/how-to-authenticate-an-ews-application-by-using-oauth

Title : シナリオ別にみる EWS での OAuth 利用方法
URL : https://blogs.technet.microsoft.com/exchangeteamjp/2018/08/01/how-to-use-oauth-with-ews-in-some-scenarios/
 
今後とも、弊社サポート ブログをよろしくお願いいたします。

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