皆さんこんにちは。国井です。
ADFSトレーニングテキスト全文公開チャレンジの8回目は第3章に入って、Office 365との連携について見ていきます。
■ ■ ■
第 2 章では、ADFS サーバーの実装方法を確認しました。第 3 章では、ID 連携機能を活用して Office 365 にアクセスできる様子について確認します。
Exchange や SharePoint 等のサービスをクラウド上で提供する Office 365 では、認証・認可の部分にAzure AD を活用しています。そのため、前の章でも解説したように Azure AD に直接ユーザーを作成して運用することも、Azure AD を STS としての活用することで ID 連携を実装することもできます。
それでは、Office 365 と Azure AD の組み合わせで利用できる、3 種類のサインイン方法について確認します。
1 つ目は「クラウド ID」とも呼ばれる、Office 365 経由で Azure Active Directory (Azure AD) に登録されたユーザーをそのまま利用する方法です。この方法は、既定の Office 365 へのサインイン方法で、Office 365を利用するときは事前に Azure AD にユーザーを作成しておく必要があります。
2 つ目はオンプレミスで使用している Active Directory ユーザーを Azure AD と同期し、Azure AD に登録されたユーザー アカウントを使って Office 365 にサインインする方法です。この方法は、Azure AD に手動でユーザーを作成する必要がないだけでなく、ユーザーは Active Directory と Azure AD で同じユーザー名とパスワードが利用できるメリットがあります。
3 つ目はオンプレミスで使用している Active Directory ユーザーを Azure AD と同期し、Active Directory に登録されたユーザー情報を用いて Office 365 へアクセスする方法です。この方法では、新しく ADFS サーバーを配置し、Active Directory に登録されたユーザー情報に基づき Office 365 へアクセスするためのトークンを発行することで、ID 連携を実現します。その結果、Active Directory ドメインにサインインしているユーザーは Office 365 に改めてサインインすることなくアクセスできます。
3 種類の Office 365 の認証方法は、いつでも自由に変更することができます。そのため、Office 365の導入を行うプロジェクトの中で、いつ認証方法を変更するかについては依存要素を考慮することなく決定できるメリットがあります。しかし、パイロットの段階から ID 連携の方法を実装することはリスクが伴うため、プロジェクト後半のフェーズで実装することも検討してください。
たとえば、Office 365導入展開のプロジェクトを 3つに分割して、徐々に理想の認証方法へ変化させていく方法があります。
このプロジェクトの最初のフェーズ (パイロット導入) では、Azure AD に直接ユーザーを作成して運用します。Azure AD に直接ユーザーを作成することで、余計な手間を排除して手軽に利用開始できるメリットがあります。
2番目のフェーズ (展開) では、オンプレミスに配置された ID ストア (Active Directory) に対してディレクトリ同期を実行します。これにより、本格的な運用を開始する前に、簡単に組織のすべてのユーザーをまとめて移行でき、かつ Active Directory と同じパスワードを利用できるメリットがあります。
もし、ディレクトリ同期を行う際、既に作られたユーザーがある場合には SMTP マッチによって既存の Azure AD アカウントを移行します (SMTP マッチについて後ほど解説します)。
3番目のフェーズ (拡張) では、複数回に渡るユーザー名とパスワードの入力処理を軽減するために、ADFS サーバーを利用した ID 連携を実装します。これにより、ユーザーは1度の資格情報の入力によって、Active Directory と Office 365 の両方にアクセスできるようになります。
Active Directory ユーザーが Office 365 にシングル サインオンを行う場合、大きく分けて 3 つのアクセス方法 (パッシブ プロファイル、リッチクライアント プロファイル、アクティブプロファイル) があります。ここでは、パッシブ プロファイルと呼ばれる、Web ブラウザー経由で Office 365 のWeb サイトにアクセスするときの認証・認可処理について解説します。
① Office 365 サイトのサインイン ページで資格情報の入力を求められる
クライアント コンピューターからOffice 365 サイトのサインインページ (https://portal.office.com/) にアクセスすると、資格情報の入力を求められます。
② 認証先を指定される
前の手順で表示されたサインインページで、ユーザー名を入力すると、シングルサインオンが可能なユーザーであるか確認します。シングル サインオン可能ユーザーであることが確認できた場合、サインイン ページでのパスワード認証を無効にし、あらかじめ決められたレルムからトークンを発行してもらうよう、クライアントコンピューターに要求します。
③ Windows ユーザーの Kerberos チケットをもとに ADFS サーバーでトークンを発行
トークンを要求されたクライアント コンピューターは Windows 統合認証を利用して資格情報を提示します。ADFS サーバーは Active Directory にアクセスして資格情報を確認し、問題がなければ認証トークンを発行します。
④ Azure AD にアクセスし、認証トークンをもとに認可を実施
クライアント コンピューターは発行されたトークンを Azure AD に提示し、認可を行います。Azure AD で認可されると、Office 365 にアクセスするためのトークンが発行されます。
⑤ Azure AD で発行されたトークンを利用して Office 365 にサインイン
クライアント コンピューターは Azure AD で発行されたトークン (認可トークン) を利用して Office 365 にサインインします。
以上の処理の結果、ユーザーはサインイン時にパスワードを入力することなく、Office 365 にアクセスできるようになります。ドメインに参加していないコンピューターからシングル サインオン ユーザーを利用して、上記のプロセスを実行する場合、③の Kerberos チケットを ADFS サーバーに提示できないため、ユーザー名とパスワードの入力を③の時点で求められます。
Active Directory ユーザーが外出先から Office 365 のシングル サインオンを行う場合、パッシブプロファイルでも異なる処理でシングル サインオン プロセスが実行されます。
① Office 365 サイトのサインイン ページで資格情報の入力を求められる
クライアント コンピューターからOffice 365 サイトのサインインページ (https://portal.office.com/) にアクセスすると、資格情報の入力を求められます。
② 認証先を指定される
前の手順で表示されたサインインページで、ユーザー名を入力すると、シングルサインオンが可能なユーザーであるか確認します。シングル サインオン可能ユーザーであることが確認できた場合、サインイン ページでのパスワード認証を無効にし、あらかじめ決められたレルムからトークンを発行してもらうよう、クライアントコンピューターに要求します。
③ Web アプリケーション プロキシにアクセスし、認証を要求
社内にいるときには Azure AD から提示された ADFS サーバーに直接アクセスすることができましたが、外出先からは社内に配置された ADFS サーバーにアクセスすることはできません。そこで、DNS サーバーによって ADFS サーバーの名前解決は Web アプリケーション プロキシ (WAP) に対して行われるように構成しておき、ユーザーはその設定に従い、WAP にアクセスします。WAP では、Active Directory ドメインの資格情報を入力し、認証を行います。
④ ユーザー認証の実施
WAP のフォーム画面から入力した資格情報は、ADFS サーバーを経由してドメインコントローラーで確認されます。
⑤ 認証トークンの発行
④で入力した資格情報が正しいものであることが確認できたら、ADFS サーバーは Office 365 にアクセスするための認証トークンを発行し、WAP 経由でクライアントに渡されます。
⑥ Azure ADにアクセスし、認証トークンをもとに認可を実施
クライアント コンピューターは発行されたトークンを Azure AD に提示し、認可を行います。Azure AD で認可されると、Office 365 にアクセスするためのトークンが発行されます。
⑦ Azure AD で発行されたトークンを利用して Office 365 にサインイン
クライアント コンピューターは Azure AD で発行されたトークン (認可トークン) を利用して Office 365 にサインインします。
このように、社外からのアクセスの場合、まだ Active Directory での認証を行っていないため、WAP にアクセスした時点で Active Directory の資格情報の入力が求められます。
Office 365 のシングル サインオン環境において、Outlook アプリケーションからメールボックスにアクセスする場合、ブラウザーアクセスとは異なる方法で認証・認可が行われます。
① Outlook から Office 365 にアクセスし、資格情報を提示
Outlook を起動し、Outlook から Office 365 にアクセスするとき、Outlook は Azure AD に登録されたユーザーの資格情報を提示します。
② 資格情報の確認先をチェック
Office 365 は Outlook クライアントから提示された資格情報を確認するため、確認先を Azure AD に確認します。
③ 資格情報を提示して認証
Azure AD に登録されたユーザーがシングルサインオン ユーザーであることが確認できた場合、WAPに資格情報を提示します。
④ 認証トークンの発行
WAP に提示された資格情報を ADFS サーバー経由で Active Directory が確認し、正しいものであることが確認できると、ADFS サーバーは認証トークンを発行し、Office 365に提示します。
⑤ Azure AD にアクセスし、認証トークンをもとに認可
Office 365 は認証トークンを Azure AD に提示します。
⑥ Azure AD から認可トークンを発行
認証トークンを受け取った Azure AD は認可トークンを Office 365 に対して発行します。
⑦ アプリケーションからのアクセスを開始
認可トークンは最終的にクライアント コンピューターに渡され、その認可トークンを利用してアプリケーションからのアクセスが開始できるようになります。
アクティブ プロファイルの場合、クライアント コンピューターから送信された資格情報をもとに、トークンの発行に関わる処理をすべてクラウド (Azure AD/Office 365) 主導で行われます。この方法では、Windows資格情報の確認を Azure AD 経由で行うため、インターネットから ADFS サーバーへのアクセス要求を受け付けられるようにするため、WAP を用意していることが特徴です。
また、WAP へのアクセスは Office 365から HTTPS プロトコルを使って行われるため、WAP には Office 365 が許可する SSL 証明書を利用していることが前提となります。
一方、Windows 資格情報は Outlook クライアントから送信されます。そのため、ユーザーが Office 365 にアクセスするために毎回ユーザー名やパスワードを入力しないようにするため、Outlook 自身に資格情報を保存 (キャッシュ) しておく必要があります。
Office 2013 / Office 2016 または Office 365 ProPlus (以降、Office 365 ProPlus と省略) では、アプリケーションを通じて行われる認証・認可部分にActive Directory Authentication Library (ADAL) と呼ばれるコンポーネントを利用し、Office 365 ProPlus アプリケーション経由での認証・認可にパッシブ プロファイルを使うようになりました。このような ADAL を利用した認証方式を先進認証 (Modern Authentication) と呼びます。ここでは、先進認証を利用して Office 365 にアクセスするときの認証・認可処理について解説します。
① Office 365 サイトで認証を要求される
Office 365 ProPlus から Office 365 サイトにアクセスすると、トークンを保有していないため、認証を要求されます。
② 認証先を指定される
前の手順で表示されたサインインページで、ユーザー名を入力 (または Office 365 ProPlus によりキャッシュされているユーザー名を提示) すると、シングル サインオンが可能なユーザーであるか確認します。シングル サインオン可能ユーザーであることが確認できた場合、サインインページでのパスワード認証を無効にし、あらかじめ決められたレルムからトークンを発行してもらうよう、クライアント コンピューターに要求します。
③ Windows ユーザーの Kerberos チケットをもとに ADFS サーバーでトークンを発行
トークンを要求された Office 365 ProPlus は Windows 統合認証を利用して資格情報を提示します。ADFS サーバーは Active Directory にアクセスして資格情報を確認し、問題がなければ認証トークンを発行します。一方、ドメインに参加していないコンピューターや Active Directory で認証していないコンピューターの場合はサインインページが表示され、資格情報の入力を求められます。
④ Azure AD にアクセスし、認証トークンをもとに認可を実施
クライアント コンピューターは ADFS サーバーから発行されたトークンを Azure AD に提示し、認可を行います。Azure AD で認可されると、Office 365 にアクセスするためのトークンが発行されます。このとき、Azure AD から発行されるトークンには、アクセス トークンとリフレッシュ トークンの 2 種類があります。
⑤ Azure AD で発行されたトークンを利用して Office 365 にアクセス
クライアント コンピューターは Azure AD で発行されたトークンのうち、アクセス トークンを利用して Office 365 にアクセスします。
以上の処理の結果、ユーザーは Outlook を含む、すべての Office アプリケーションから Office 365 にアクセスするときに、パスワードを入力する必要がなくなり、トークンを利用してアクセスできるようになります。また、アクセストークンは有効期間が 1 時間に設定され、その有効期間が切れるとリフレッシュ トークンを使って Azure AD からアクセス トークンを再取得します。リフレッシュ トークンは 14 日間有効で継続利用することにより最大で 90 日間有効なトークンで、Office アプリケーションを終了してもコンピューター内にキャッシュされます。そのため、リフレッシュ トークンが有効な限り、ADFS を利用した再認証を行わない点に注意してください。
編集後記
ADFSの接続先クラウドアプリNo1のOffice 365との連携方法にいよいよ入ってきました。
Office 365への接続方法にはブラウザーからの接続とアプリからの接続があり、どちらの方法で接続するかによってSSOの方法も違っていたりします。
アプリの接続の場合、レガシー認証と先進認証の2つのパターンがあり、レガシー認証(Office 365 と ADFS サーバーによる ID 連携 (Outlook アクセスの場合)の項目で解説した接続方法)は2021年中にサービスを終了することを既に発表しています。
そのため、会社の中でレガシー認証が使われていないかを確認し、来るべき時に向けて先進認証に切り替えていく作業が今の段階から必要になります。
これについては別の投稿で解説していますので、参考にしてみてください。
