【Office365】 脱ADFS!! 次世代の認証機能まとめ -其ノ壱-

皆さん、こんにちはMiyaです。

今回は、昨年GAされた「パススルー認証・パスワードハッシュ同期・シームレスシングルサインオン」を振り返ります。

「いまさら?」感は否めませんが、最近これらの新機能についてよく引き合いをいただくことがあり、自身の整理のためにも一度まとめておこうと思いました。

Office365を導入検討している、もしくは既に運用している方も、これらの新しい新機能は非常に魅力的に感じますが、蓋を開けてみると想像していたものとはかけ離れていたってことも有り得るので、本記事を参考に理解いただければと思います。

スポンサーリンク:

それぞれの概要

まず、それぞれの機能について簡単に触れておきましょう。

今回紹介する3つの機能は、いずれもAADConnectのみで構成可能な認証方式+SSOです。

パススルー認証

パスワードハッシュ同期(以下PHS)、パススルー認証(以下PTA)が認証方式、シームレスシングルサインオン(以下sSSO)がサインインオプションになります。

パススルー認証

これまでOffice365と言えばAD FSを中継したフェデレーションIDが一般的でしたが、これらの認証方式でもSSOが出来ることから次期認証方式として今注目を浴びていますね。

パススルー認証

PTAは認証Agentを仲介したオンプレADの認証です。文字通りクラウドへの認証要求をオンプレにパススルーする感じです。

パススルー認証

クラウドで認証するクラウドIDに対して、オンプレミスADで認証する方式をフェデレーションIDと呼んでいました。

Title:Office365 フェデレーションIDについて考える
https://miya1beginner.com/office365-federationid-adfs

フェデレーションIDを構成するためには、AD FSもしくはサードパーティの認証プロパイダーが必須であり、導入・運用ともに難易度が高いのが難点です。

Title:Windows Server 2016 AD FS + Office365のフェデレーションIDの構成①
https://miya1beginner.com/office365-federationid-adfs1
Title:Windows Server 2016 AD FS + Office365のフェデレーションIDの構成②
https://miya1beginner.com/office365-federationid-adfs2

PTAはAADConnectだけでフェデレーションIDを構成可能+ウィザード形式で設定は非常に簡単という優れものです。

しかし、PTAでAD FSのすべての機能をカバーできるわけではないので、「これでAD FS要らずだ!」とはなりません。

AD FSの機能として魅力的であったのが、クレームベースによるアクセス制限が設けれる点でしたが、PTAにはアクセス制限の設定は一切ございません。

Title:Windows Server 2016 の AD FS のアクセス制御ポリシー
https://docs.microsoft.com/ja-jp/windows-server/identity/ad-fs/operations/access-control-policies-in-ad-fs

そのため、「特定IPアドレス以外からの認証はすべて拒否する」や「社外からのOutlook接続は拒否する」などなど…セキュリティポリシーに違反しないようリソースへのアクセス制限を構成したいなら、最低でもAzureADの条件付きアクセス、複雑な制限にはIntuneのライセンスが必要になります

パススルー認証

Title:Azure Active Directory の条件付きアクセス
https://docs.microsoft.com/ja-jp/azure/active-directory/active-directory-conditional-access-azure-portal
Title:Intune での条件付きアクセスの一般的な使用方法
https://docs.microsoft.com/ja-jp/intune/conditional-access-intune-common-ways-use

AzureADの条件付きアクセスを利用するにはAzure P1ライセンス、IntuneでMDM、MAMするにはIntuneライセンスが必要です。

Title:Azure Active Directory の価格
https://azure.microsoft.com/ja-jp/pricing/details/active-directory/
Title:Enterprise Mobility+Security 料金オプション
https://www.microsoft.com/ja-jp/cloud-platform/microsoft-intune-pricing

正直安くはないです。条件付きアクセスだけのライセンスではないため、その他のサービスの導入計画を立てた上で購入を検討されたほうが稟議も通りやすくなるでしょう。(大変だと思いますが…)

私の経験談にはなりますが、導入・運用のコスト面が比較的低いサードパーティのクラウド認証プロパイダーを利用する構成に落ち着くことが多いです。

パスワードハッシュ同期

PHSとはオンプレADのパスワードをAzureADに同期し、AzureADで認証を行う認証方式です。

パスワード同期

PHSは元からAADConnectの機能としてあるパスワード同期機能です。そのため、PHSそのものは新機能ではなく、「PHSがsSSOのサポート対象に含まれる」点がUpdateされた箇所になります。

パスワード同期

先の構成図を見てお分かりかと思うが、認証にオンプレを経由しない(=オンプレに障害点がない)ことから、Microsoft推奨の構成みたいです。

パスワードハッシュ同期

たまに「クラウドにパスワードは置けない」と意見を貰いますが、細かく言うとパスワードを複雑なアルゴリズムで算出したハッシュ値になるので、それが第三者に渡ったところでリソースに不正アクセスされる心配はございません。

Title:Azure AD Connect 同期でパスワード同期を実装する
https://docs.microsoft.com/ja-jp/azure/active-directory/connect/active-directory-aadconnectsync-implement-password-synchronization

尚、アクセス制御についてはPTAを同様で、AzureAD側で設ける必要があります。

シームレスシングルサインオン

お待たせしました。いよいよsSSOの話になります。

PTAやPHSを導入することで受けれる一番の恩恵が本機能のアカウント名のみでサインインが完了するsSSO機能です。

シングルサインオン

シームレスなシングルサインオンの動作は非常に単純です。利用者が直接オンプレADにAzureADへのST(サービスチケット)を取得しに行き、Office365へアクセスする流れです。

シングルサインオン

上図からお分かりいただけると思うのですが、利用者の端末がADに接続できる環境(=社内NW)であるということが前提です

その他にも前提条件がありますが、詳細は連載の中で取り上げるので本記事では省略させて下さい。

パススルー認証をもっと理解する

さて、まず本テーマの第一弾のPTAについて、詳しく触れていきましょう。

PTAは認証Agentを経由してオンプレADでの認証(=フェデレーションID)を実現できる優れた機能です。

AD FSが居らずしてフェデレーションIDが構成出来るんですから管理者にとっては救世主ですが、本当に自社環境に適合するのか?を検討するためにも技術的にも理解しておくと良いでしょう。

前提条件

★PTA認証を利用するには先進認証が必須
Officeクライアントを利用する場合、ADALに対応しているクライアントを利用する必要があります。
「ADALって?」という方は下記のTechnetBlogを参考ください。モダン認証とはADALのことを指します。

Title:Office 製品の Office365 モダン認証フローと認証キャッシュについて
https://blogs.technet.microsoft.com/sharepoint_support/2016/08/01/modern-authentication-flow-and-cache-of-office-to-office-365/

★Exchange Online,Skype for BusinessのOauth2が有効化されていること

Officeクライアントとは別にサーバー側でもADAL対応する必要があります。

テナントを作成した時期にもよりますが、今では既定で有効になっていることから追加構成は不要です。

不安な場合は、PowerShellから確認できるので確認しておくと良いでしょう。
Office,サーバー側のADAL対応について以下にまとめた記事があるので参考にして下さい。

Title:Office365 パススルー認証 Officeクライアントからの接続
https://miya1beginner.com/office365-パススルー認証-officeクライアントからの接続

認証フロー

PTAの認証フローは特に難しくありません。認証AgentがADに接続できない端末の代理でオンプレADに認証するイメージです。

パススルー認証

「へぇ」と感じたのが、⑤の通信にはHTTPSのOut-boundのみであること。どうやら認証Agentはパスワード検証キューに格納された認証要求を常に覗いて待ち受けているみたいです。

あと、AD FSではフェデレーションIDに指定したドメインでAzureADにユーザーを新規作成しようとすると怒られますが、PTAは作成できるみたいです。もちろん認証はAzureADです。

パススルー認証

冗長化

PTA認証は必ず認証Agentを経由する必要があるので、Agentがダウンしてもクラウド認証へフォールバックすることはありません。結果、利用者はOffice365へサインイン出来なくなるのです。

パススルー認証

認証Agentの実態はAADApplicationProxyConnectorと呼ばれるコンポーネントで、それを適当なWindows Server 2012R2以降のサーバーにインストール・構成してあげることで冗長構成(Act-Act?)が可能になります。

パススルー認証

インストール・構成手順は簡単です。過去に記事でまとめているので参考にして下さい。

Title:Office365 パススルー認証 コネクタの冗長化
https://miya1beginner.com/office365-パススルー認証-コネクタの冗長化

パススルー認証の構成

PTAの構成手順も実は過去に取り上げているので、詳細は下記ページを参考にして下さい。

Title:Office365 AADConnectのパススルー認証によるSSO構築①
https://miya1beginner.com/office365-aadconnectのパススルー認証によるsso構築①
Title:Office365 AADConnectのパススルー認証によるSSO構築②
https://miya1beginner.com/office365-aadconnectのパススルー認証によるsso構築②

AD FSと比較するとSSL証明書やWAP(WebApplicationProxy)等の準備が無いので、コスト的にも時間的にもサクサク作れちゃいますね。素晴らしい。

まとめ

とまぁ、PTAで構成することでAD FSとおさらばが出来るので、要件次第では脱ADFSが可能になります。

いけてる点

・認証基盤がオンプレADに統一される
・通信にIn-boundがない
・低コストで導入・運用が可能
・sSSOがサポートされる(ドメイン参加端末のみ)

導入に向けての課題

・ADAL対応のOfficeに切り替えが必要
・Azureの条件付きアクセスが必要
・AzureADではレガシー認証は制御対象外

3つ目のレガシー認証とは従来のBasic認証(=ADALではない)を指します。AzureAD側で条件付きアクセスを実装しても、レガシー認証の端末であればどこからでもアクセスできてしまうのが現状です。

近日ブロック予定ですが、「ブロックした時の影響がー・・」と騒ぐことが予想できるので少し先になりそう。ちなみに、現状はこれらの問題を防ぐためにAD FSのクレームルールを実施しろとのこと。ナンセンスですね。

Title:最新の認証を使用していないアプリをブロックする (ADAL)
https://docs.microsoft.com/ja-jp/intune/app-modern-authentication-block

おわりに

いかがでしたか?Office365を検討されている方も、既にAD FSで導入している方にも魅力的な機能ですよね。

AD FSからの切り替え(アクセス制限諸々)は大変ですが、これから導入するのであればPTAを本格的に検討すべきかなぁと思います。

AD FSは既に古い構成になりつつあるので、今後はMicrosoftもパススルー認証やパスワード同期を軸に機能更新していくのではないでしょうか。

今回はPTAのお話になりましたが、次回はPHSを紹介したいと思います。

それでは、良いOffice365ライフをっ♪

スポンサーリンク