先進認証利用時のADFSによるアクセス制御について

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

最近はOffice 2016, 2013を利用する企業も増えてきており、Office 365へのアクセスにADFSを利用している場合であれば「先進認証」を活用される企業も増えてきていると思います。
先進認証はブラウザーからSSOするときと同じように、パッシブプロファイルっぽいSSOアクセスを実現するものですが、認証・認可によってクライアントが受け取るトークンはブラウザーとは異なるものになります。

ブラウザーのSSOの場合はブラウザーを再起動すれば、改めて認証・認可を行い、トークンを発行しますが、Outlookなどのアプリケーションからの先進認証によるSSOの場合は一度トークンを発行すると、長い期間キャッシュを持つことになります。
そのため、ADFSサーバーでアクセス制御の設定を行っても、キャッシュを利用してしまうため、そもそもADFSサーバーにアクセスすることがなくなり、結果的にアクセス制御設定を無視してアクセスできてしまうという課題があります。

このような課題を乗り越えて、毎回ADFSサーバーにアクセスし、アクセス制御設定をチェックしてほしいという場合には、キャッシュを明示的に削除しなければなりません。
そこで今回は先進認証を利用しているケースにおいて、キャッシュを明示的に削除する方法について紹介します。

【基本】先進認証利用時のトークン

ADFSを利用している環境で、先進認証を利用している場合、Azure ADでは主に2種類のトークンを発行します。

・リフレッシュトークン
・アクセストークン (ベアラー)

まず、リフレッシュトークンはユーザー単位で発行されるトークンで、ざっくり言うとユーザー認証に成功したことを示すトークンです。トークンは14日間キャッシュされ、継続して利用していると最長で90日キャッシュされる、非常に長い有効期限に設定されていることが特徴です。リフレッシュトークンの情報はコントロールパネルの資格情報マネージャーから確認できます。
(ユーザー単位の発行だそうなんですが、実際には複数の資格情報が確認できます。なぜ？)

続いてアクセストークンは、Office 365の各サービスにアクセスするためのトークンで、有効期限は1時間と短く設定されています。
発行されたトークンの情報はレジストリの
HKEY_CURRENT_USER\Software\Microsoft\Office\
<バージョン番号>\Common\Identity\Identities\ <GUID>￥<GUID>\TicketCache
に保存されます。下の画面を見るとわかるように、サービス種類ごとに別々のトークンが発行されます。

予約時に発行されたチケットとボーディングチケット

最近は少なくなりましたが、航空券って予約した時に発券されるチケット(今はeチケットなどと呼ばれている、アレです)と、搭乗当日にカウンターで発行されるチケット(ボーディングチケット)の2種類がありました。私は数年ほど前、アメリカワシントンの空港で予約した時に発券されたチケットをもとにカウンターでボーディングチケットを発券してもらい、乗り場に向かいました。ところが、海外で様々なトラブルを引き起こす私のことなので、ボーディングチケットを乗り場に向かう最中に無くしてしまいました。
そこで私はゴリ押しでボーディングチケットなしで乗ろうと思い、
国井：「オレ、国井だけど、乗せてくれ」
係員：「は？何言っているの？だったら、予約した時のチケットを見せろ」
国井：「はい、どうぞ」
係員：「OK。ボーディングチケットを再発行しといたよ」
え、予約した時のチケットがあったら、ボーディングチケットって再発行されるの？？
予約した時のチケットとボーディングチケットって、
アクセストークンが使えなくなったら、リフレッシュトークンを使ってアクセストークンを再発行する、リフレッシュトークンとアクセストークンの関係みたいですね。
何が言いたいかと言えば、どちらもチケット(トークン)がなくなったからといって、最初から手続きをやり直さなくてもいいってことです。

2つのトークンの関係は以下のMSさんのブログでも紹介されているので合わせて参考にして欲しいのですが、ユーザー認証後に受け取るデータがリフレッシュトークン(ブログ内ではauthentication_codeと表現)、authentication_codeをもとにOffice365にアクセスするための認可情報をアクセストークン(ブログ内ではOAuth JWTトークンと表現)と、パケットフローと共に紹介されております。

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

話が長くなりましたが、
以上のことから、Officeアプリから先進認証でOffice 365にアクセスした場合、最初だけADFSサーバーを利用した認証・認可を行うけれど、それ以降は14日～90日間はADFSサーバーを使うことがなくなることがわかります。
(事実、ADFSサーバーにはトークン発行のログが一切記録されません)

先進認証のキャッシュを削除する

先進認証のキャッシュを残さないようにして、ADFSサーバーによるアクセス制御をチェックさせるには、上記の場所からキャッシュを消せばいいのです。
消し方は次のとおりです。
アクセストークンの削除は次のコマンドレットを実行します。

cmdkey /list | where {$_ -match 'LegacyGeneric'} | foreach { cmdkey /delete "$($_.split()[-1])" }

一方、リフレッシュトークンの削除は以下のとおり。

reg delete HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\
<バージョン番号>\Common\Identity\Identities\
<GUID>\<GUID>\TicketCache

両方をクライアントコンピューターから削除したうえで、Outlookを起動すると、きちんとADFSサーバーにアクセスし、アクセス制御をチェックしたうえで、トークンが発行されます。

※2021年10月12日追記
既存のリフレッシュトークンはRevoke-AzureADUserAllRefreshTokenコマンドレットによりクラウド側から強制的に利用できなくすることが可能です。これを使えば、レジストリの情報をデバイスごとに削除するなんてことをする必要がなくなります。

ADFSサーバーのイベントビューアを見ると、イベントID 1200のログ(Windows Server 2016の場合)がセキュリティログに記録されることが確認できます。

UserAgentの項目を拡大してみると、Microsoft Outlookって書いてあることがわかります。
(ちなみにSkype for Business クライアントの場合、それとわかるUserAgent文字列を残さないんですよね。。)

■　■　■

もうひとつの方法として、
Azure AD側で発行するトークンの期間をカスタマイズすることで、キャッシュをいつまでも使わず、トークン発行を頻繁に行うように構成することができます。

Azure Active Directory における構成可能なトークンの有効期間
https://docs.microsoft.com/ja-jp/azure/active-directory/active-directory-configurable-token-lifetimes

本文中にもありますが、設定にはAzure AD Premium P1のライセンスが必要になるので、注意してください。

【おまけ】Skype for Business Onlineの先進認証設定

Exchange Onlineと同様にSkype for Business Onlineで先進認証を利用する場合も事前設定が必要ですので、https://www.microsoft.com/ja-jp/download/details.aspx?id=39366　からダウンロードしたツールを使って、以下のコマンドレットを実行しておいてください。

Import-Module SkypeOnlineConnector
$sfbsession=New-CsOnlineSession
Import-PSSession $sfbsession
Set-CsOAuthConfiguration -ClientAdalAuthOverride Allowed

【余談】SharePoint Onlineへの先進認証
SharePoint Onlineへのアクセスに先進認証を利用する場合、SharePoint Online側で行うべき設定は無いのですが、先進認証を利用している/いないでアクセス制御ができるようです。