『サインインの状態を維持しますか ?』のオン/オフをユーザーごとに制御する

Pocket

はじめに

突然ですが、Office 365 や Azure Portal にサインインする際に『サインインの状態を維持しますか?』というメッセージを目にしたことはありませんか?これは Keep me signed in (KMSI) と呼ばれる機能によって表示されるメッセージで、”はい” を選択すると、Azure AD は 90 日間有効な Session Token を永続 Cookie に含めて発行するため、利用者は次回以降のサインインが省略されるという素敵な機能です。

今回は、KMSI の基本的な動作のおさらいをした後に、本記事のタイトルに記載している通り、ユーザーごとに KMSI をオン/オフにする方法をご紹介していきます。

KMSI の動作をおさらい

ユーザーが Azure AD へサインインすると、Azure AD は Session Token をブラウザに渡します。この Session Token が有効である限り、利用者はユーザー名/パスワードを入力することなく、Azure AD からリソースにアクセスするための id_token が受け取れます。

Session Token についてはこちらの公開情報に詳細がありました。

つまり、Azure AD は Session Token を Cookie に含んで発行すること および 『サインインの状態を維持しますか?』で “はい” を選択することで、90 日間有効な Session Token を永続 Cookie に含めて発行する動作である旨が分かります。(Cookie そのものが Session Token というわけではなく、あくまで Cookie に Session Token を含める、というイメージです。)

下図は実際にユーザーがサインインした際の通信を Fiddler でキャプチャしたものです。『サインインの状態を維持しますか?』に対して “はい/いいえ” どちらを選んだとしても ESTSAUTH と ESTSAUTHPERSISTENT の 2 つの Cookie を Azure AD が発行します。

ESTSAUTH は非永続的な Cookie で、ブラウザを閉じる、もしくは 24 時間経過すると失効します。一方、ESTSAUTHPERSISTENT は永続的な Cookie であるため、ブラウザを閉じても再利用可能で、expires は Session Token と同じ 90 日後の日時が設定されていることが分かりますね。

また、有効期限内の Session Token は、再利用する度に新しく発行されるため、永続的な Cookie であれば、実質永続的にサインインを省略することが可能です。ちなみに、有効期限が切れるシナリオ以外に、サインイン画面が表示される代表的な例に下記があります。

  1. ユーザーのパスワードが変更されている
  2. サインインの際に prompt=login パラメーターが付与されている
  3. 多要素認証 (MFA) を実施する必要がある
  4. inPrivate モードのブラウザでサインインしている
  5. ブラウザが Cookie を保存できない、送信できない … など。

少し話が脱線してしまいましたが、まとめるとこんな感じでしょうか。

『サインインの状態を維持しますか?』を “はい” にした場合:

『サインインの状態を維持しますか?』 を “はい” にした場合、2回目以降のサインインは以下のようにユーザー名/パスワードの入力が省略されます。

この時、ブラウザは login.microsoftonline.com へ ESTSAUTHPERSISTENT を送信していることと、Azure AD がこの中に含まれる Session Token を検証した結果、id_token を返している様子が確認できます。

また、id_token の発行と同時に、その時点からさらに 90 日間有効な ESTSAUTHPERSISTENT が発行されています。この中には 90 日間有効な Session Token が含まれています。

『サインインの状態を維持しますか?』を “いいえ” にした場合:

次は 『サインインの状態を維持しますか?』 を “いいえ” にした場合です。”いいえ” を選択すると 24 時間有効な Session Token を非永続的な Cookie に含めて発行します。非永続的な Cookie はブラウザを閉じると同時に破棄されるため、サインイン画面が表示される動きとなります。

先ほどと同じように Fiddler でキャプチャしてみました。ブラウザは前回サインイン時に発行された ESTSAUTHPERSISTENT を送信しますが、この中には Session Token が含まれていないため、Azure AD は “AADSTS50058: A silent sign-in request was sent but no user is signed in” のエラーを返します。

Azure AD はこのエラーコードを検知すると、ユーザーにサインイン ページを返すため、結果的にサインイン画面が表示されていたようです。

『サインインの状態を維持しますか?』 をオフにするには?

永続的な Cookie に Session Token が含まれていると、先ほど確認したようにユーザーはパスワードを入力することなくリソースへアクセスすることができるため、便利ではあるのですが、これを無効にしたいといった要望は多く存在するかと思います。

KMSI を無効するには Azure Portal – [Azure Active Directory] – [会社のブランド] から設定できます。なお、下図の設定項目は少なくとも Azure AD Basic エディション もしくは Office 365 のライセンスが必要になります。

ただし、上図の設定は組織全体に影響が及ぶため、たとえばですが、『正社員は有効にして、パートナー企業は無効にしたい』、『社用パソコンを持ち出す社員だけを無効にしたい』といった要件は残念ながら実現できません。

そこで、条件付きアクセスの [セッション] 項目にある “永続的なブラウザー セッション” を使用することで、上述の要件が実現できるのです。

KMSI のオン/オフをユーザーごとに制御する

条件付きアクセスの “永続的なブラウザー セッション” は、[会社のブランド] と同じく、KMSI を制御する項目です。条件付きアクセスでは、構成したポリシーが適用される対象範囲を ユーザー/グループ単位で制御できるため、永続的なブラウザー セッションが適用される範囲を制御することができる、というわけです。

また、条件付きアクセスから構成する KMSI には、以下の特徴があります。

ポイントは、アプリケーションに “すべてのクラウド アプリ” が指定されている必要があることと、[会社のブランド] の設定 および AD FS から発行される PSSO のクレームをオーバライドするという点です。Session Token はアプリケーションにバインドされたものではないため、”すべてのクラウド アプリ” が前提であることは納得できますね。

条件付きアクセス ポリシーを作成する

ポリシーを作成するのはめちゃくちゃ簡単ですが、一応その過程をここに記録しておきます。なお、今回は下記 2 人のユーザーを用意して検証します。

Azure Portal – [Azure Active Directory] – [セキュリティ] – [条件付きアクセス] から、[+ 新しいポリシー] をクリックします。

[ユーザーとグループ] から、ポリシーを適用する対象者を選択します。今回は john.smith のみを対象に選択します。

次に、[クラウド アプリまたは操作] から、[すべてのクラウド アプリ] を選択します。

その他は特に既定値のまま編集せずに、[セッション] – [永続的なブラウザー セッション] にチェックを入れ、[常に永続的] を選択したら、ポリシーをオンの状態で作成します。

以上で条件付きアクセスのポリシー作成は完了です。次は実際にこれが動作するかを確認してみましょう。

動作を確認する

結論からいうと、想定通りに動きます。…が、”常に永続的” が適用された john.smith の初回サインイン時に『サインインの状態を維持しますか?』の画面は表示されませんでした。ただし、下記の結果を見てもわかる通り、2 回目のサインインでは、サインイン画面が表示されることなくアクセスできていることが分かります。

てっきり、『サインインの状態を維持しますか?』が表示されるものだと思ってましたが、どうやら暗黙的に Session Token が永続 Cookie に含まれて発行される動きみたいです。なお、上図の結果をサインイン アクティビティ ログを確認したところ、条件付きアクセスは適用されていました。

常に永続的” という設定名なので、まぁ納得できる動きですし、こっちのほうがしっくりきます。

おまけ:既存の Session Token を失効させる

たとえばですが、『これまで KMSI が有効だった一部ユーザーを、無効にしたい』といった要望があると仮定します。設定はもちろん可能ではあるのですが、一つ課題が残ります。

それは、”過去に発行された永続的 Cookie をブラウザは保存している” という点です。つまり、設定から反映までに最大 90 日間要することになります。

これを回避する手段として、現在発行された Session Token を無効にする方法があります。具体的には、PowerShell から Revoke-AzureADUserAllRefreshToken を実行することで、意図的に特定のユーザーに発行された Session Token を失効されることができるので、そのユーザーは次回のサインイン時にユーザー名/パスワードが求められるようになります。(Session Token の他にも PRT などあらゆるトークンを無効にします)

先ほど、Session Token が発行された john.smith に対してこのコマンドを実行してみます。

Revoke-AzureADUserAllRefreshToken -ObjectId john.smith@shmiyaza.tokyo

その後、ブラウザから Azure Portal へアクセスしてみると、AADSTS50058: A silent sign-in request was sent but no user is signed in とともサインイン画面が返される動きが確認できました。

おわりに

いかがでしたでしょうか?これまで何となく見ていた『サインインの状態を維持しますか?』の内部的な動きも確認できたので、個人的にはスッキリしました。また、後半ではユーザーごとに永続的な Session Token の発行可否が制御できました。正直、あんまり需要がないようにも思えるのですが、少しでもお役に立てたら幸いです。

それでは、よい Azure AD ライフをっ😎

Pocket

コメントを残す

メールアドレスが公開されることはありません。