Office365 フェデレーションIDについて考える

こんにちは、Miyaです。

Office365を導入するにあたって、大きな検討ポイントが「ID管理をどうするのか?」というところがあります。

Office365のID管理形態はクラウドIDフェデレーションIDの二つの形態が存在し、それぞれのメリット・デメリットが在ります。

Office365導入検討時期では、自社の規模やセキュリティポリシーを精査し、どちらのID管理形態が最適かを選定する必要があります。

グローバル企業なんかでは、MIMによるID同期や、各支社のAD同士で信頼関係を構成してID統合を実現してから、Office365を導入する企業も在りますね。

本記事では、Office365のID管理形態の概要と、フェデレーションIDについて少々掘った内容を記載しています。

スポンサーリンク:

Office365の認証基盤について

Office365では、AzureADと呼ばれる、クラウドベースのユーザー認証基盤を使用しています。
AzureADではシングルサイオンのためのSAMLやWS-Federation、多要素認証のためのOAuth2.0がサポートされます。

Office365に限らず、クラウドサービスを利用する際の課題としてID管理は共通です。
クラウドサービス毎にIDを保持すると、ユーザー・管理者ともに管理が煩雑になりますし、ID管理の統合のためにもシングルサインオンは必須の機能となりました。

Office365を利用するにはAzureADに登録されているユーザーオブジェクトに対して認証を行うのですが、その形態はクラウドIDフェデレーションIDの二種類に分類されます。

クラウドID

クラウドIDとは、ユーザーの管理をAzureAD上で行う形態になります。利用者はOffice365へのサインインのため、AzureADのユーザー名/パスワードを入力し、AzureAD上で認証行います。

クラウドID

オンプレADを利用している組織では、ADとAzureADに登録されている二つのアカウントを管理する必要があるため管理が煩雑になります。

例えば、ユーザー情報の変更が発生した場合、管理者はオンプレADとAzureAD上の二つのユーザーオブジェクトを編集する必要があります。
ユーザーとしても、2つのパスワードを保持する必要がありますし、パスワードポリシーが異なれば、混乱を招くでしょう。

また、ユーザーは認証の度にInternetを経由してアカウント情報を送信するため、セキュリティ上においても好ましくありません。

一方で、クラウドのメリットはコスト面です。Office365を導入するに伴い、オンプレサーバーを構築する必要がないため、導入コスト・ランニングコストが削減されます。

フェデレーションID

フェデレーションIDとは、組織内で利用しているADを利用して認証を行う形態になります。既存ADを活用した認証であることから、シングルサインオンIDとも呼ばれています。

フェデレーションID

組織内にAADConnectと呼ばれるID同期ツールを使用して、オンプレADからAzureADにアカウント情報を同期することが前提となります。

利用者はOffice365へのサインイン時に、フェデレーションサーバーであるAD FS(Active Directory Federation Service)を経由して、オンプレADで認証処理を行います。

Office365を利用している組織で多くの割合を占めるのが、このフェデレーションIDです。

ID管理がオンプレADに統合されるため、管理者・利用者ともに運用が簡略化されます。

セキュリティの観点でみると、クラウドIDとは異なり、認証処理が組織内NWで完結されるため、セキュアな認証と言えます。
また、AD FSではクレームベースのアクセス制限設定や、ユーザー証明書を用いた端末制限が実現できるため、クラウドサービスならではの「どこからでも・どの端末からでもアクセス可能」といった課題の解決策となります。

ただ、組織内にサーバー数台を構築する必要があるため、導入コスト・ランニングコストともに費用が増加します。
認証処理もオンプレ基盤に依存するため、可用性を考慮すれば、そこそこのサーバー台数を新設する必要があります。

組織規模や組織のセキュリティポリシーに沿ってどちらかを選択しましょう。
折角のクラウドサービスなのに、オンプレサーバーが必要になっては本末転倒ですし、数十名の組織であればクラウドIDを推奨します。

逆に大規模組織となれば、運用面・セキュリティ面でクラウドIDは要件に合致しないため、必然的にフェデレーションIDとなります。

上述から、Office365利用者の中でもフェデレーションIDが断トツで多い理由がお分かりいただけたかと思います。そこで、本記事ではフェデレーションIDについて深堀りしておきます。

AD FSが必要なワケ

そもそも、シングルサインオンのために何故AD FSが必要なのかを理解しておきましょう。

オンプレ環境では、ADドメイン内に限り有効なKerberosプロトコルを利用してシングルサインオンを実現してきました。

Title:Windows Server 2016 Active Directoryの構築 Kerberosプロトコルによる認証フロー
https://miya1beginner.com/windows-server-2016-active-directory%e3%81%ae%e6%a7%8b%e7%af%89-kerberos%e3%83%97%e3%83%ad%e3%83%88%e3%82%b3%e3%83%ab%e3%81%ab%e3%82%88%e3%82%8b%e8%aa%8d%e8%a8%bc%e3%83%95%e3%83%ad%e3%83%bc

同一ドメイン内であれば、クライアントはKDCから配布されるTGTやSTを取得し、あらゆるリソースへアクセスしていました。

Kerberos認証

また、自組織以外のActive Directory環境のリソースにアクセスするには、信頼関係を結ぶことによって、1回のサインインによるアクセス範囲を広げていましたね。

Title:Active Directory 信頼関係の構成

https://miya1beginner.com/active-directory-%E4%BF%A1%E9%A0%BC%E9%96%A2%E4%BF%82%E3%81%AE%E6%A7%8B%E6%88%90

しかし、Office365などのクラウドサービスでは、Active Directoryを使った認証基盤ではないため、信頼関係を結ぶことが出来ません。
近年、このようなクラウドベースのサービス増加に伴い、需要が高まったのがID管理の統合、つまりはシングルサインオンです。

シングルサインオン(英語:Single Sign-On、略称:SSO)は、一度のユーザ認証処理によって独立した複数のソフトウェアシステム上のリソースが利用可能になる特性である。この特性によって、ユーザはシステムごとにユーザIDとパスワードの組を入力する必要がなくなる。
また、アイデンティティ管理を連邦化(federate)することによって、ひとつの組織(管理ドメイン)を超えて他の管理ドメインのWebサーバにも同一のユーザIDとパスワードの組でログインできるようにする処理も、しばしば「シングルサインオン」と呼ばれている。ユーザ認証結果をクレデンシャル(SAMLアサーションやOpenID ConnectのIDトークン)によって伝えて実現させるが、通常、各Webサーバに同一のユーザIDとパスワードの組を入力する必要がある。
引用 – Wikipedia

「クラウドサービスを利用したいけど、ID管理はActive Directoryに統合したい!」なんて要望に応えれるのがAD FS(Active Directory Federation Service)です。

AD FSでは、WS-FederationやSAMLといったID情報の受け渡しのためのプロトコルを使用して、Active Directory環境以外のクラウドサービスにまでサインイン範囲を広げることを可能とします。

認証フロー

フェデレーションIDでは、サインイン処理をオンプレミスのActive Directoryに委任するイメージです。

委任する際に必要なのがやっぱり信頼関係です。

信頼関係の管理や、認証・認可の管理、ログオンチケットを発行する役割を持つのがAD FSとなります。

それでは、クライアントがOffice365への認証フローを見ていきましょう。

フェデレーションID

  1. ユーザーがOffice365にアクセス
  2. アクセスにはMFGから発行されたサービスチケットが必要なため、MFGにリダイレクト
  3. サービスチケット発行には信頼済みのADFSから発行されたログオントークンが必要なため、ADFSのURLを送信
  4. DNSサーバーでフェデレーションサービス名の名前解決
  5. ADFSにログオントークン発行の要求を送信(ID/PWの送信)
  6. ADFSがADに接続
  7. ADがADFSにログオントークンに必要なデータを送信
  8. ADFSがログオントークンを作成、ユーザーに送信
  9. ユーザーがログオントークンをMFGに送信
  10. 信頼済みADFSから発行されたログオントークンであることを検証し、ユーザーにサービスチケットを送信
  11. Office365にMFGから発行されたMFGを送信
  12. MFGから発行されたサービスチケットであることを確認し、各サービスへの接続を許可する

上述では社内環境端末のブラウザからのアクセスを想定した、いわゆるパッシブ認証になります。
しかし、クライアントアプリケーション・接続環境が異なると、認証フローも異なる点があります。

IE(ブラウザ) パッシブ認証
Office 2013(EnableADAL=1),Office 2016 パッシブ認証
Office 2013(EnableADAL=0),Ofice 2010 アクティブ認証

Title:Office365 パススルー認証 Officeクライアントからの接続
https://miya1beginner.com/office365-%e3%83%91%e3%82%b9%e3%82%b9%e3%83%ab%e3%83%bc%e8%aa%8d%e8%a8%bc-office%e3%82%af%e3%83%a9%e3%82%a4%e3%82%a2%e3%83%b3%e3%83%88%e3%81%8b%e3%82%89%e3%81%ae%e6%8e%a5%e7%b6%9a

認証コンポーネントがブラウザベースであれば、パッシブ認証に切り替わる仕組みとなっております。
Officeクライアントの場合、2016は既定でブラウザベースの認証が有効化されているのですが、2013の場合は手動でレジストリを変更する必要があります。
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クライアントに限る)によるOfficeの各アプリケーション毎の認証を省略することが可能となります。
Title:Office 製品の Office365 モダン認証フローと認証キャッシュについて
https://blogs.technet.microsoft.com/sharepoint_support/2016/08/01/modern-authentication-flow-and-cache-of-office-to-office-365/

また、社外環境からの接続となれば、社内NWに位置するAD FSサーバーに接続出来ないため、認証・認可依頼を要求することが出来ません。
そこで、登場するのがWebApplicationProxyと呼ばれる、AD FSの認証・認可依頼を代わりに行ってくれるリバースプロキシです。

AD FSはドメイン参加が必須のサーバーであることから、外部公開することは危険です。
そのため、リバースプロキシをDMZに設置して、WAP⇔AD FS間の443/TCPをPermitとするルールをF/Wに書くのが一般的でしょう。

それぞれのクライアント別認証フローをまとめておきました。ご参考下さい。

フェデレーションID

フェデレーションID

フェデレーションID

アクティブ認証では、社内・社外問わずWAPを経由して認証・認可依頼を要求するフローとなります。
これはアクティブ認証の特性なんですが、RPであるOffice365が利用者の代理で認証を要求するため、必然的に社外接続になるんです。

証明書の要件

AD FSではSSL証明書トークン署名証明書が必要となります。

SSL証明書は、AD FS/WAP⇔クライアント間の通信保護に利用します。サブジェクト名がAD FSのフェデレーションサービス名と一致する信頼された証明書をAD FS/WAPにインポート/バインドします。

サーバーとクライアント間のSSL証明書となるため、サードパーティ製の信頼された証明機関から購入するのが一般的ですが、検証で環境構築する際は自己証明書でも構いません。

もう一方のトークン署名証明書は、MFGが信頼済み組織内のAD FSが発行したトークンであることを検証するために使用します。

AD FSがログオントークンをユーザーに配布する際に、トークン署名証明書でトークンにデジタル署名します。
MFGがログオントークンを受け取ったときに、信頼済みAD FSから発行されたログオントークンであることを検証後、ユーザーにサービスチケットを配布します。

トークン署名証明書は管理者が用意するものではなく、AD FSとOffice365のフェデレーションをセットアップする際に自動で自己証明書を作成してくれます。

クレーム・クレームルール

クレームの解説に入る前に、AD FSの基本的な動作について解説しておきます。

AD FSにユーザーがトークン発行を求める時に、AD FSではユーザーが正しいことを検証するために、信頼済みの認証プロパイダーに確認します。

この認証プロパイダーをAD FS用語で「要求プロパイダー」と呼び、Active Directoryドメイン環境でセットアップすると、自動で信頼済み要求プロパイダーとして登録されます。

話を戻してクレームとは、信頼済みの要求プロパイダーの属性ストアから特定のユーザーに関する情報(UPN、メールアドレス、User-Agent…など)のステートメントになります。

クレームルールは、証明書利用者信頼で定義されているアクセス許可、拒否を定義した規則の集合体です。

クレームルール

特定のユーザーに関するクレームセットをクレームルールに基づいて、証明書認証信頼にアクセスさせるか、させないかを定義します。
例アクえば、特定グローバルIPアドレスの要求に対してのみログオントークンを配布するルールは以下のような記述になります。

exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”]) &&
NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip”, Value=~“xxx.xxx.xxx.xxx”])
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

パススルー認証によるフェデレーション

AD FSによるフェデレーションIDのフローを解説しましたが、導入コスト・ランニングコストの費用が発生します。
これらのサーバーを新設しなくてもフェデレーションIDが構成出来るのが、AADConnectのパススルー認証です。

Title:Office365 AADConnectのパススルー認証によるSSO構築①
https://miya1beginner.com/office365-aadconnect%e3%81%ae%e3%83%91%e3%82%b9%e3%82%b9%e3%83%ab%e3%83%bc%e8%aa%8d%e8%a8%bc%e3%81%ab%e3%82%88%e3%82%8bsso%e6%a7%8b%e7%af%89%e2%91%a0

Title:Office365 AADConnectのパススルー認証によるSSO構築②
https://miya1beginner.com/office365-aadconnect%e3%81%ae%e3%83%91%e3%82%b9%e3%82%b9%e3%83%ab%e3%83%bc%e8%aa%8d%e8%a8%bc%e3%81%ab%e3%82%88%e3%82%8bsso%e6%a7%8b%e7%af%89%e2%91%a1

パススルー認証では、Kerberosプロトコルから発行されるSTをAzureADで使用できるよう構成する機能です。
AD FSによるフェデレーションIDに比べてコストや敷居が低いのに対して、クレームベースのアクセス制限が設けれない課題があります。

そのため、AzureADのアクセス制御やIntuneのサービスでアクセス制限してあげる必要がありますね。

TechSummit 2017の”脱AD FS”セッションでも話に挙がりましたが、今後はパススルーやパスワードハッシュ同期を活用して、オンプレミスに依存しないOffice365を推奨するみたいです。

スポンサーリンク