最近、お客様より「AzureAD Joinした端末を複数のユーザーで共有したいのですが、何か注意することありますか？外部のIdP（IDaaS）とフェデレーションしている環境でも大丈夫ですか？」との相談がありました。
いわゆる共有端末として利用するお話なのですが、教育機関や自治体では割とよくある使い方だと思います。Windowsはマルチユーザーに対応しているし、「AzureAD Joinに対応しているIDaaS」であれば特に問題ないと思ってますが、一応、検証してみました。
■注意すべき前提条件
①AzureADにJoin!して、Intuneに端末を登録する。
→ということなので、Intuneを使えるライセンスが必要です。（こちらの記事を参照）
②端末のOSが「Windows 10 / Windows 11（いずれも Professional/Enterprise）」であること。
→どちらも最新にUpdateしておくと安心ですね。
■実際に試してみる。（AzureADに参加＆端末登録）
手順としては「AzureAD Joinを実際に試してみる」と全く同じです。OSの「アカウント」設定→「職場または学校にアクセスする」→「このデバイスをAzure Active Directoryに参加させる」で端末をAzureADにJoin!させてください。外部IdPとフェデレーションしているドメインの場合、認証時に別画面内（WebView）で外部IdPへリダイレクトされるはずです。あと、Intuneへの登録も忘れずに。
で、AzureADアカウントが登録されたら一度Windowsからログオフして再度Windowsにログインしますが、デフォルトだと「Windowsのセットアップ画面？」みたいなのが表示されます。↓こいつです。これ、別のAzureADアカウントでログインしたときも初回のみですが表示されます。（問題点①）
調べてみたところこの設定は「Windows Hello for Business 」のセットアップ画面で、デバイスへのサインインにおいて、パスワードを PIN や生体認証 (顔認証、指紋認証など) に置き換えてサインインできるようにする機能とのことです。
なお、PIN や生体認証を利用してWindowsにログインする場合、Trusted Platform Module （トラステッド プラットフォーム モジュール、TPM）に格納された「プライマリ更新トークン（PRT）」という認証情報を使います。そのため、最初の1回目は（Windowsクライアントから）外部IdPに認証が走りますが、2回目以降はWindowsログイン時に外部IdPを経由しません（PRTが有効である限り）ので注意してください。
【参考TPM エラー 80090016 について（TPMやらPRTやらの説明があります。）】
https://jpazureid.github.io/blog/azure-active-directory/what-to-do-error-tpm/
■別ユーザーでログインしてみる
普通にWindowsのログオン画面で、「他のユーザー」を選択して、AzureAD Joinで利用したアカウントとは別のAzureADアカウントでログインします。
認証のタイミングでIdPにログが記録されていることを確認しました。裏でちゃんとIdPにリダイレクトされているようです（WindowsクライアントからIdPに直接パスワード認証の要求が来ていました。AzureADからリダイレクトURLなどを取得してIdPにアクセスしているようです。SAMLがクライアントのブラウザを起点にしているのと同じですね。そして、ここは多要素認証は出来ないですね。）
とりあえず、Windowsにログインできましたが、初回ログインアカウントだと「Windows Hello for Business」のセットアップ画面が表示されます。設定が完了すると普通にWindowsを利用できます。それと、OSのアカウント設定にある「職場または学校にアクセスする」にはログインしたAzureADアカウントが登録されていました。↓
と気になる文言が・・・「デバイス管理設定を変更するには管理者としてサインインします。」・・・調べてみると、複数ユーザーで端末を利用する場合、AzureADに端末登録したときに利用したアカウントが「プライマリアカウント」になり、ローカルの管理者権限を持つようで、後からログインしたAzureADアカウントはOSの「職場または学校にアクセスする」に登録はされてはいるものの、ローカルデバイスに対して管理者権限は持っていないようです。って事はソフトウェアのインストールとかできないじゃん。（問題点②）
■Windows Hello for Businessセットアップ画面を無効化したい
「問題点①」の解決方法ですが、これはIntuneの設定で解決しました。Intuneの管理画面「Microsoft Endpoint Manager admin center」の「Windows登録」-「Windows Hello for Business」を開くと「Windows Hello for Businessの構成」項目があるので「無効」を選択します。これで、Intuneに登録されたWindowsデバイスに対しては「Windows Hello for Business」が無効になります。
これで、Intuneに登録されたWindowsデバイスに対しては「Windows Hello for Business」が無効になります。つまり、あの問題の画面が出てこなくなります・・・と思ったら、「これには数分かかることがあります」の画面は出てきました！もちろん「追加の認証」や「PIN」など「Windows Hello for Business」の設定画面は表示されないので、待っていれば完了します。初回ログイン時にこの画面↓は表示されますので「Intuneの設定が効いてないじゃん！」と驚かないでください。
【参考：Azure AD 参加後に有効になる Windows Hello for Business とその無効化方法について】
https://jpazureid.github.io/blog/azure-active-directory/how-to-disable-whfb/
■管理者権限が付与されない問題
「問題点②」の解決方法ですが、これはAzureAD管理画面から「デバイス」-「デバイスの設定」にある「すべての Azure AD 参加済みデバイスに対する追加のローカル管理者」という設定があり、ここにローカルの管理者アカウントとして追加するAzureADユーザーを選択（追加）すれば良さそうです。
ちなみに設定は直ぐに反映されないのと、追加されたユーザーはローカル管理者グループに表示されないとのことで、画面上から確認はできないじゃん！状態となります。
- 設定反映の条件は、Azure AD が適切な特権を備える新しいプライマリ更新トークンを発行するために最大 4 時間が経過するか、ユーザーが、プロファイルを更新するために、ロックおよびロック解除ではなく、いったんログアウトした後でサインインした。
- ユーザーはローカル管理者グループに表示されません。アクセス許可は、プライマリ更新トークンを通じて受信されます。
【参考：Azure AD 参加済みデバイスのローカル管理者グループの管理方法】
https://docs.microsoft.com/ja-jp/azure/active-directory/devices/assign-local-admin
ということで、設定してみたところ、確かに「ローカルのAdministratorsグループ」には表示されていませんが、通常であれば権限のないフォルダ（例えば他ユーザーのプロファイルフォルダ）にアクセスしましたが、普通に見ることが出来ました。（「regedit」も管理者権限で起動することができました。）
いろいろ設定を試したところ、以下のように「管理者アカウント」の入力を求められるケースがありましたが、ログインしているAzureADアカウントを入力したところ、管理者権限で操作をすることができました。
設定を追加したり変更したりしていたので、設定の反映に時間がかかったりしていたのかなと思います。事前に全ての設定を完了した後に、最初の手順（AzureAD Join）から操作をしたところ、このような現象は出ませんでしたが、参考までに記載しておきました。
■まとめ
AzureADアカウントを共有PCで使う場合を考慮した機能がリリースされているため、現在では問題なく運用できそうな印象です。クラウドサービスは様々な機能が日々リリースされているので、ある時点で不都合があったとしても「時間が経てばそのうち解決される」って感じですね。スバラシイです。
今回はここまで。
■その他、参考情報
【Windows デバイスの登録をセットアップする】
https://docs.microsoft.com/ja-jp/mem/intune/enrollment/windows-enroll
【Intune を使用して共有 PC またはマルチユーザー デバイスでのアクセス、アカウント、および電源機能を制御する】
https://docs.microsoft.com/ja-jp/mem/intune/configuration/shared-user-device-settings
Shared Technology V 