Office365 パススルー認証 Officeクライアントからの接続

こんにちは、Miyaです。

AADConnect+パススルー認証によって、シームレスなSSO構成と、社外アクセスからでもオンプレADでの認証が実施可能な環境を構築しました。
前回の記事では、ブラウザからOffice365へのパッシブ認証のデモストレーションをお見せしました。

今回は、Officeクライアントからのシングルサインオンのデモストレーションをお見せしたいと思います。
Officeクライアントからシングルサインオンするには、サーバー側とクライアント側で設定が必要になります。

スポンサーリンク:

アプリケーションサーバーの設定

まず、Officeクライアントから利用するアプリケーションサーバー毎に、ADAL(Active Directory Authentication Library)認証を有効化にしなければなりません。

ADAL認証とは、OAuthを組み込んだ認証で、従来の認証とは異なりトークンを用いた認証フローをベースに柔軟な認証基盤を構成することが可能になります。(AD FSによる接続制限なんかが有名ですね。)
TechnetのチームブログにADAL認証についてのフローを簡潔まとめている記事があり、とても参考になります。
Title:Office 製品の Office365 モダン認証フローと認証キャッシュについて
https://blogs.technet.microsoft.com/sharepoint_support/2016/08/01/modern-authentication-flow-and-cache-of-office-to-office-365/

・OAuth トークン ( JWT トークン) を複数の Office アプリケーションで共有できるため、Outlook、Skype for Business、その他各種 Office アプリケーションのいずれかで取得したトークンを再利用して、各アプリケーションの認証プロセスを短縮できる。
ただし、現時点では実装上、ほとんどのアプリケーションにおいて別のトークンとして管理しているため、このメリットを享受していないように思われます。
・ユーザー名、パスワードによる認証処理を抑制できるため、クライアント端末におけるネットワーク盗聴からアカウント情報を守ることができる。
・JWT トークンは特定の用途のアプリケーションに対するアクセス許可であり、万が一漏えいしても別の用途に使用できないため、被害を最小限に抑えることができる。
・JWT トークンはパスワード変更時に再発行の必要がないため、パスワード ポリシーによる運用影響を受けにくい (ただし JWT トークン有効期限切れ時に影響が出ることもある)。
引用 – Office 製品の Office365 モダン認証フローと認証キャッシュについて

トークンを用いた認証に切り替えることで、不用意なパスワード入力や、漏洩防止などのメリットがあります。

Title:Exchange Online と Outlook の認証キャッシュについて
https://blogs.technet.microsoft.com/exchangeteamjp/2016/07/14/authentication-cache-for-exchange-online-and-outlook/

さて、サーバー側でADAL認証の有効化する必要がある言いましたが、具体的に何をするかというとExchange OnlineとSkype for Business Onlineの認証設定をPowerShellからコマンドで変更します。

Exchange Onlineの設定方法

まずは、PowerShellから下記コマンドでExchange Onlineに接続しましょう。

下記コマンドで、Exchange OnlineのADALを有効化にし、設定の確認コマンドで”True”と表示されていればOKです。

Skype for Business Online の設定方法

Skype for Businessに接続するためには、別途モジュールをインストールする必要がありますので、こちらからモジュールのダウンロード&インストールをしましょう。

インストールが済みましたら、下記コマンドでSfBOnlineに接続します。

下記コマンドでADALを有効にし、設定の確認コマンドで”Allowed”と表示されていればOKです。

これでOffice365側の設定は完了です。

Officeクライアントからの接続

Officeクライアントもサーバー同様にADAL認証に対応させる必要があります。
現在対応しているのはOffice2013、2016となり、MSIベース・クイック実行版でソフトウェア要件が異なりますので、下記サイトから確認しましょう。
Title:Office クライアントで Office365 先進認証を使用する
https://support.office.com/ja-jp/article/Office-%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E3%81%A7-Office-365-%E5%85%88%E9%80%B2%E8%AA%8D%E8%A8%BC%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%99%E3%82%8B-776c0036-66fd-41cb-8928-5495c0f9168a

ソフトウェア要件がクリアできたら、レジストリからOfficeのADAL設定を行います。
Title:Windows デバイスの Office 2013 の先進認証を有効にする
https://support.office.com/ja-jp/article/Windows-%E3%83%87%E3%83%90%E3%82%A4%E3%82%B9%E3%81%AE-Office-2013-%E3%81%AE%E5%85%88%E9%80%B2%E8%AA%8D%E8%A8%BC%E3%82%92%E6%9C%89%E5%8A%B9%E3%81%AB%E3%81%99%E3%82%8B-7dc1c01a-090f-4971-9677-f1b192d6c910

Office2016の場合、自動的にADAL認証が有効化されているため、特に設定する必要はありません。
下記サイトに、アプリ、クライアント別でレジストリの設定値に対する認証方法がまとめられています。
Title:Office 2013 クライアント アプリと Office 2016 クライアント アプリでの先進認証のしくみ
https://support.office.com/ja-jp/article/Office-2013-%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88-%E3%82%A2%E3%83%97%E3%83%AA%E3%81%A8-Office-2016-%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88-%E3%82%A2%E3%83%97%E3%83%AA%E3%81%A7%E3%81%AE%E5%85%88%E9%80%B2%E8%AA%8D%E8%A8%BC%E3%81%AE%E3%81%97%E3%81%8F%E3%81%BF-e4c45989-4b1a-462e-a81b-2a13191cf517

Outlookからの接続

それでは、Outlookから接続してみましょう。

社内

[接続]クリック。

パススルー認証

そのままパスワードの入力なしに、シームレスなSSOが確認できました。
パススルー認証

社外

アカウント名、パスワードを入力します。
パススルー認証

しばらくすると、AzureADのフォーム認証が表示されるので、パスワードを入力します。
パススルー認証
パススルー認証
パススルー認証

Skype for Businessからの接続

社内

こちらもOutlook同様、シームレスなSSOが確認できました。
パススルー認証
パススルー認証

社外

ユーザー名を入力して[サインイン]をクリックします。
パススルー認証

AzureADのフォーム認証が表示されるので、パスワードを入力します。
パススルー認証

サインインできましたね。
パススルー認証

ADALトークンの確認

さて、Officeクライアントから接続の確認ができたところで、冒頭でさらっとお話ししたADAL認証によるトークンについて確認したいと思います。

社内/社外問わず、認証に成功するとクライアントに対してトークンが発行され、資格情報マネージャーに格納されます。
コントロール パネルより [ユーザー アカウント]⇒[資格情報マネージャー] を見てみましょう。
パススルー認証

複数のMicrosoftOfficexx_Data:ADAL: が保存されているのが確認できます。
これらがADALトークンになり、キャッシュの期間中は再利用することで、不要な認証を避けることが出来ます。
尚、意図的に削除することで、再度認証することが出来ます。

ADALトークンですが、実態はアクセストークンとリフレッシュトークンの2種類が存在します。
それぞれキャッシュ期間が異なり、アクセストークンは1時間、リフレッシュトークンは14日間となっています。
アクセストークンが切れた場合、リフレッシュトークンがアクセストークンを更新する動作となり、リフレッシュトークンは最大90日間まで延長されます。

こちらのトークンのキャッシュ構成については、AzureActiveDirecotryのB2Cサービスから変更できるっぽいです。
Title:Azure Active Directory B2C: トークン、セッション、シングル サインオンの構成
https://docs.microsoft.com/ja-jp/azure/active-directory-b2c/active-directory-b2c-token-session-sso

おわりに

とまぁ、Officeクライアントからもパススルー認証が実施できるのが確認できました。
ひと手間必要となりますが、クライアント側として難しい操作がない上に、不要なアカウント名/PWの入力が省かれるので、非常に便利だと思えます。

但し、現状ではアクセス制限が出来ておらず、どの端末・ネットワークからでもOffice365のアプリケーションに接続できてしまっているため、Enterprise向けの構成ではありません。
そこで、AzureRMSやIntuneによるセキュリティサービスを加えることで、シンプルかつセキュアなクラウドサービスの構成が実現出来る?のではないでしょうか!笑

最近、MicrosoftもAzureADの機能強化を頻繁に行っていて、ドキュメントが日々更新されています。(正直追っていくのが大変です…笑)
Microsoftとしても、クラウドでのID管理を強化して、どんどんオンプレ⇒クラウドへの移行を誘致していくのでしょうか?要注目ですね。

それでは、よいWindows Serverライフをっ♪

スポンサーリンク