Office365 AADConnectのパススルー認証によるSSO構築②

どうも、Miyaです。

前回はAADConnectによるOffice365へのシングルサインオン構成を実現しました。
今回は、クライアント側の認証部分のデモストレーションをしてみたいと思います。

スポンサーリンク:

社内NWからの認証フロー

まず、社内NW(DCにアクセスできるNW)からの認証フローですが、ユーザー自身がADにアカウント名/PWを検証しに行くフローになります。
DCでのアカウント名/PWの検証が成功すれば、AzureADへのST(Service Ticket)を取得し、それを提示してOffice365のアプリケーションにアクセスしにいくイメージです。
パススルー認証

つまり、Active Directoryドメイン内のKerberos認証フローと同じ動きをAzureADに対して行うイメージです。
参考:Windows Server 2016 Active Directoryの構築 Kerberosプロトコルによる認証フロー

STはユーザーがアクセスしたいコンピューターオブジェクトに対して発行されるものですから、もちろんAzureADのコンピューターオブジェクトが存在するわけです。
[Active Directory ユーザーとコンピューター]のComputerコンテナを見ると、AZUREADSSOACCのコンピューターオブジェクトが確認できますね。
パススルー認証

社外NWからの認証フロー

次に、社外NWからの認証フローについて、解説します。
社外NWからは勿論DCにアクセスできませんので、アカウント名/PWの検証を、ユーザー自身で行えないですよね。
そのため、検証フローをAzureADに行ってもらい、検証が成功すれば、AzureADからアクセストークンを発行してもらうイメージです。
パススルー認証

④の部分で、アカウント名/PWの入力をした際に、その情報をAzureAD側で検証用キューに格納します。
⑤では、AADConnectにインストールされているMicrosoft AAD App Proxy Connectorサービスが送信呼び出しを実行し、AzureADにアカウント名/PWを取得しに行きます。
あとは、Microsoft AAD App Proxy Connectorサービスが、DCに対して、取得してきたアカウント名/PWの検証を行い、AzureADに結果を返すといったフローになります。

ブラウザからのアクセス

今回は、IEブラウザからOffice365のポータルページにアクセスするデモストレーションをお見せします。
シングルサインオン構成なので、社内NWの場合は、アカウント名の入力のみでポータルにアクセスでき、社外NWの場合、アカウント名/PWを入力してアクセスするフローとなります。

動作の確認も兼ねて、イベントビューワーからチケットの発行も見ていきましょう♪

社内NWからのアクセス

社内NWからはアカウント名のみでOffice365へアクセスが出来る、いわゆるシームレスなシングルサインオンの動作となります。

但し、これを実現するには、接続エンドポイントのURLをイントラネットゾーンとして定義しなければ、取得したアクセストークンを送信出来ません。
[インターネットオプション]の[セキュリティ]タブから、[ローカルイントラネット]を選択して、[サイト]をクリックします。
パススルー認証

[詳細設定]をクリックします。
パススルー認証

以下の二つのエンドポイントURLを追加します。
・https://autologon.microsoftazuread-sso.com
・https://aadg.windows.net.nsatc.net
パススルー認証

尚、こちらの設定はGPOの[ユーザーの構成]⇒[管理用テンプレート]⇒[Windows コンポーネント]⇒[Internet Explorer]⇒[インターネット コントロール パネル]⇒[セキュリティ]⇒[サイトとゾーンの割り当て一覧]から設定可能です。
パススルー認証

追加したら、IEを再起動し、Office365ポータルサイトへアクセスし、接続してみましょう。
アカウント名を入力してフォーカスアウトすれば、パスワードの入力なしにOffice365へサインインされます。

また、認証時のDCのセキュリティログを確認すると、TGTとAZUREADSSOACCに対するSTが発行されているのが確認できます。
※チケット発行のログを確認する場合は、監査ログを有効にしておきましょう。

TGT

パススルー認証

ST

パススルー認証

補足情報ですが、2017/06時点ではパススルー認証はプレビューとなっており、対応クライアントはこちらから確認できます。今後のクライアント対応についても要注目ですね。(MacのChromeからはどー接続するのだろうか?)

社外NWからのアクセス

では、同様にこちらもブラウザからOffice365ポータルサイトへアクセスする際の認証を確認してみましょう。
社内NWと異なり、ユーザー自身からDCに検証が行えないため、ポータル画面でアカウント名/PWを入力し、ポータルサイトへログインします。
ですので、見かけ上、通常の認証と変わりありませんが、裏では認証をオンプレADに委任しているフローになります。

実際にログインした際のDCのセキュリティログを確認してみましょう。

TGT

Microsoft AAD App Proxy Connector(192.168.11.206)がTGSに対して、チケットを取得しています。
パススルー認証

ST

画像のDHCP$は、AADConnectのインストールしているサーバーですw
パススルー認証

イベントログを見たところ、チケットの取得の代理人としてMicrosoft AAD App Proxy Connectorが資格情報の検証をしているっぽいです(間違っていたらすみませんw)

おわりに

IEブラウザからのシングルサインオンフローを確認しました。概ね予想通りの動作をしてくれたので安心しました。
他にもOfficeクライアントからの接続や、Macからの接続が個人的には気になるところですので、後日調査してみます。
Officeクライアントからの認証検証

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

スポンサーリンク