ADFSなしでOffice365へのシングルサインオンを実現する(2)

皆さんこんにちは。国井です。

前回の投稿では、KerberosをAzure ADにまで拡張することで、ADFSの要らないシングルサインオンの方法を紹介しましたが、この仕組みにはもうひとつの実装方法があります。それは「パススルー認証」というサインイン方法です。
(ちなみに、前回紹介したパスワードハッシュ同期はPHS、パススルー認証はPTAと略すそうです。初めてみたときは、「私も昔はアステル使ってたよ」とか、わけのわからないことを思い出してしまいました)

パススルー認証とは、ユーザー認証をActive Directoryに丸投げするという認証方法で、前回も登場したスライドを拝借すると、こんな感じの仕組みです。

image

③のところでAzure ADからActive Directoryへインバウンドの通信が発生しているように見えます。しかし、パススルー認証では、インバウンドの通信が発生しないよう、Azure AD Premiumでも提供されているAzure AD App Proxyという仕組みを使って、オンプレミスのActive DirectoryからAzure ADに向かってセッションを開始し、Azure ADからのパケットを待ち受ける方法を採用しています(厳密にいうと、セッションはAzure AD ConnectをインストールしたサーバーとAzure ADの間で接続します)。
そうやって、既存のオンプレミスのインフラに対する変更ができるだけ起きないようにしながら、シングルサインオンの仕組みを実現してくれています。

■ ■ ■

パススルー認証の設定ですが、パスワードハッシュ同期との違いは、サインオン方式で[パススルー認証]を選択するだけ。他はいつも同期ツールと一緒です。
(下の画面は[シングルサインオンを有効にする]にチェックがついてないけど、チェック付けておいてくださいね)

インストールが完了したら、Internet Explorerを起動します。
前回と同じくInternet Explorerのイントラネットゾーンに以下の2つのURLを入れておきます。

https://autologon.microsoftazuread-sso.com
https://aadg.windows.net.nsatc.net

ここまでできたら、Office365のサイトにアクセスし、ユーザー名を入力します。
すると、シングルサインオンすることが確認できます。

えっ、シングルサインオンできていいの?
シングルサインオンできたけど、パスワード丸投げはどこ行ったの?

そう思った方のために動きを整理しておきましょう。

★☆★ここから先は私の推測も入るので、間違っていたら誰か指摘してくださいね。★☆★

■ドメイン参加PCが社内からOffice365にサインイン
→パスワードハッシュ同期+SSO
■ドメイン未参加PCやドメイン参加のPCが社外からOffice365にサインイン

→パスワードを丸投げするパススルー認証

パススルー認証におけるシングルサインオンとは、実は「パスワードハッシュ同期+SSO」と同じことをしています。パススルー認証では「パスワードをオンプレミスに丸投げする」と言いましたが、それはサインイン画面にパスワードを入力していることを前提とした話です。パスワードを入力することのないシングルサインオンでは、丸投げするパスワードがそもそも存在しないのです。なので、(代わりに?)パスワードハッシュ同期+SSOと同じ仕組みを使って、シングルサインオンをさっさと済ませてしまいます。

一方、ワークグループのPCやドメイン参加のPCが社外からアクセスする場合は、Active Directoryにアクセスできないため、パスワードハッシュ同期+SSOで使っていたシングルサインオンのためのTGTやSTのチケットをもらえないのです。この場合には、シングルサインオンをあきらめてパススルー認証に切り替えてくれます。(パスワードハッシュ同期+SSOでもシングルサインオンできなければ、ユーザー名とパスワードを入力する認証に切り替わりますが、認証自体はオンプレミスに丸投げせず、Azure ADで行います。)

★☆★推測入り、ここまで。どうです、腹落ちしました?★☆★

実際に、オンプレミスのドメインコントローラーでイベントビューアも見てみましょう。Office365へのサインインを行ったタイミングで、Microsoft AAD App Proxy Connectorプロセスから認証が発生しているのをきっかけに、

image

TGTとSTのチケットが一気に発行されていることが確認できます。

image

image

最後にお受けすることがありそうな質問と回答を一つ。
パススルー認証+SSOも、パスワードハッシュ同期+SSOも、どちらも同じ動きをするのであれば、2つの仕組みをわざわざ作る必要なんてなかったのでは?と思うかもしれません。
しかし、パススルー認証は(これまでに何度も説明しているように)、Office365のサインイン時にオンプレミスにパスワードを転送し、認証を行うため、次の2つの特徴があります。

・パスワードをAzure ADに持たせる必要がない
・認証をオンプレミスで行うため、オンプレミスのポリシーに沿った運用ができる

オンプレミスのポリシーに沿った運用とは、Active Directoryで設定した各種ルールに沿って認証ができることを指しています。
具体的には、Active Directoryにはログオン可能な時間帯という設定がありますが、この設定をOffice365にサインインするタイミングで適用させたい(例:AM9-PM5の間だけOffice365にサインインさせたい)などが考えられます。

■参考
パススルー認証
https://docs.microsoft.com/ja-jp/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication
ADFSなしSSO
https://docs.microsoft.com/ja-jp/azure/active-directory/connect/active-directory-aadconnect-sso
Azure AD Connect User Sign on options
https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-user-signin
The things that are better left unspoken
https://dirteam.com/sander/2016/12/07/azure-ad-connect-1-1-371-0-offers-pass-through-authentication-and-seamless-single-sign-on-preview-capabilities