AzureAD Joinした端末を複数ユーザーで利用する。しかも外部IdPでSSOしているって話。

最近、お客様より「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

Microsoft365 既定のドメインを変更する影響

Microsoft365では「既定のドメイン」という設定がありまして、カスタムドメインを追加した場合（複数ドメインがある場合）、どのドメインを「既定のドメイン」とするか設定を行うことができます。（AzureAD管理画面では「既定のドメイン＝プライマリドメイン」と表示されています。）この設定は一体何なのか？変更するとどんな影響があるのか？を検証してみました。

■結論

いきなり結論ですが、「変更しても別に影響はないんじゃないの？」って感じです。既にMS365を利用している環境（Exchange OnlineやTeamsなどを利用している環境）で実際に変更してみましたが、表立って変わったことは何もありませんでした。

■既定のドメインてそもそも何？

既定のドメインはフェデレーションの設定ができません。それとたまに遭遇するのですが、フェデレーション設定するときに、管理者アカウントの情報を必要とする（MS365に接続する管理者アカウントのことです）のですが、そのアカウントがフェデレーション対象のドメインユーザーだった場合、フェデレーション設定に失敗します。なので、出来れば「xxxx.onmicrosoft.com」アカウントを利用しましょう。（「onmicrosoft.comドメイン」元々フェデレーションできませんので。）

で、本題ですが「既定のドメイン」って何ぞや？ってところなんですが、以下のような挙動に関係があります。

1. 管理画面からユーザーやグループを作成するときにデフォルトで表示されるのは既定のドメイン（プルダウンで別ドメインを選択可能。デフォルトで一番上に表示されるってだけです。）
   　
2. Teamsでチームを作成すると裏ではO365グループが作成され、メールアドレスを指定しなかった場合には「ランダム文字列＠既定ドメイン」になる。
   　
3. 配信不能通知（NDR）で組織外へ返す場合、デフォルトのFromアドレスは「postmaster@既定のドメイン」となる。これはPowerShellで変更が可能。
   　
4. 共有メールボックス、リソースメールボックスを作成時、エイリアスに「xxxx@既定のドメイン」というメールアドレスが自動的に追加される。

■実際に変更してみた

気にはなっていたので実際に変更してみました。特にTeamsのチームとかに影響はないのか？ってところが気になったので、実際に使っている状況から既定のドメインを変更してみました・・・が特に影響はありませんでした。もちろん、MS365管理画面からチームを作成したときに作成されるMS365グループのデフォルトのメールアドレスは「既定のドメイン」に設定したものになってはいましたが、そもそもチーム作成時にメールアドレスをちゃんと入れればいいですし、省略した場合に「そうなる」ってだけですね。

■まとめ

既定のドメインって何だろう？後から変更しても大丈夫なの？って思って検証してみましたが、個人的には「大丈夫でしょう」という結論です。明示的にメールアドレスを指定しなかった場合、この既定のドメインがデフォルトで使われるよ、ってぐらいですね。

今回はここまで。

Azure AD Join を実際に試してみる

最近、「Azure AD Join」や「Hybrid Azure AD Join」の話を多くいただいております。「Microsoft 365」を利用しており、かつ「Active Directory」をオンプレミスで運用している方であれば一度は調査、検討をされたのではないでしょうか？

「Azure AD Join」や「Hybrid Azure AD Join」はオンプレミスの「Active Directory」を代替する機能ではありませんが、アカウントや端末の管理を「オンプレADからAzure ADに変更する」という点では移行可能だと考えています。いわゆる「Active Directory」そのものを代替するのであれば「Azure AD Domain Services」の利用を検討してみては如何でしょうか？利用のシナリオについては以下の記事が参考になります。（ただし、Azure AD Domain Services は、既存のオンプレミス Active Directory ドメイン コントローラーを完全に置き換えるものではありません、との記載もあるので十分な検討が必要のようです。また、Hybrid Azure AD Joinは、Azure AD Joinに至るまでの暫定的なステップとのことです。）

【参考：Azure AD Domain Services の利用シナリオ】
https://jpazureid.github.io/blog/azure-active-directory/azure-ad-ds-scenario/

で、今回は一番問い合わせが多い「Azure AD Join」を実際に試してみました。結構、細かい部分で「あぁ、そうなんだ・・・」ということがありましたので備忘録としてメモっておきます。

■Azure AD Joinを利用するメリット

「Azure AD Join」を利用するメリットは様々あるようですが、以下のような点があります。

・Microsoft Intune との連携による端末管理、条件付きアクセス ポリシーでのアクセス制御
・WindowsのサインインにAzure ADのアカウントを利用できる。
・一度Azure ADに参加すると以降はPINやWindows Helloでサインインできる。
・ブラウザの「お気に入り」などの情報がAzure AD側に保管される。
・BitLockerの回復キーをAzure AD側に保管できる。
・スクリプトを利用すると端末に対して設定が様々できる。（ログインスクリプトみたいな機能）

「Azure AD Join（Azure AD 参加）」と似たような機能で「Azure AD Register（Azure AD 登録）」というものもありまして、この辺りは以下の記事を参考にしてください。

【参考：Azure AD 登録 と Azure AD 参加 の違い】
https://jpazureid.github.io/blog/azure-active-directory/azure-ad-join-vs-azure-ad-device-registration/

■Azure AD側の準備

Azure AD側は以下の条件を満たしている必要があります。
・利用ユーザー数分の「Azure AD Premium P1」以上のライセンスを保持
・SSOドメインの場合、IdPにWS-Fed / WS-Trust でパスワード認証エンドポイントが提供されている。

クライアント側のOSエディションは以下とのことです。
・すべての Windows 11 および Windows 10 デバイス (Home エディションを除く)

■クライアント側での実際の操作

それではクライアント端末（今回はWindows 10 Enterprise）をAzureADにJoin！させてみたいと思います。

①OSの設定から「アカウント」を選択
②「職場または学校にアクセスする」を選択
③接続アイコンをクリック。
④画面下の「このデバイスをAzure Active Directoryに参加させる」をクリック。

⑤Azure ADのアカウントを入力（SSOドメインの場合はここでIdPにリダイレクトされます。）
⑥認証が完了すると「組織のネットワーク」確認画面が表示
⑦「参加する」をクリックすると完了
⑧「職場または学校にアクセスする」画面に登録したアカウントが表示されます。

ここまで完了するとAzure AD管理画面の「デバイス」に参加した端末が表示されます。「統合の種類」というカラムに「Azure AD Join」と表示されていますね。

一度、ログオフしてAzure AD アカウントでWindowsにサインインしたいと思います。

■Windowsにサインイン（再ログイン）

ローカルアカウントでサインインして設定していたので、一度Windowsからログオフして、Azure AD のアカウントでサインインします。

①Azure AD のアカウントでサインインします。
②ここからかよ・・・ちょっと待ちます。
③認証のため、電話番号を登録します。（事前に登録しておくことも可能です。）
　※入力した番号はアカウントの「認証方法」の「電話」に登録されます。（この後、説明します。）
　※Microsoft Authenticatorを利用することもできます。
④入力した番号に（今回は「電話する」を選びました）電話がかかって来るので指示に従い完了。

⑤PINの入力を求められます。（以降はプライマリ更新トークンでログインできる。）
⑥やっと完了です。

ちなみに確認のための電話番号は予め登録しておくことができます。Azure AD管理画面でアカウントの「認証方法」という項目で設定すると先ほどの電話番号登録画面は表示されず、登録した番号の選択画面に代わります。

登録済み番号を選択する画面が表示されます。メールアドレスを登録しておけば（恐らく）メール通知も可能だと思われます。

■Microsoft Intuneに自動登録させる

Azure AD Joinと同時にデバイス管理をするために「Microsoft Intune」に登録させる（恐らくアカウント切断時の自動削除も）には「Microsoft Endpoint Manager Admin Center（Azureポータルの「ホーム」から「その他サービス」-「Intune」を開くと起動します）」から「デバイス」-「デバイスの登録」を開き、「MDMユーザースコープ」と「MAMユーザースコープ」を「すべて」に設定します。

「MDMユーザースコープ」と「MAMユーザースコープ」の意味がイマイチ分からなくて、いろいろ調べたけどやっぱり分からないです。なので、両方とも「すべて」に設定しました。

【参考：Windows デバイスの登録をセットアップする】
https://docs.microsoft.com/ja-jp/mem/intune/enrollment/windows-enroll

それと、サインインに利用するアカウント（ユーザー）は以下のライセンスが付与されていないとIntuneが利用できない（セットアップでエラーになります）ので注意してください。

■まとめ

今回「Azure AD Join」を実際に試しましたが、Azure AD にジョインさせることが目的ではなく、その後の管理が重要ですので、ようやく入口に立っただけですね。これから「どんな機能があって、何が便利なの？」という点を調べていこうと思います・・・が、機能がいっぱいで複雑に絡み合っていて、アップデートも頻繁でいろいろ変わるから正直ツライなぁ～と。導入や運用管理をまるっと外部にお任せするのがいいかもね・・・高いと思うけど。今回はここまで。

【2022年8月12日：追記】
一応、それっぽく書いたつもりでしたが、問い合わせが多いので記載しておきます。AzureADにJoin!した後、一度Windowsにログインすると「プライマリ更新トークン（PRT）」という認証情報をOSで保持します。以降のWindowsログインはこの情報を使います。そのため外部IdPと連携しているような場合、認証サーバーにリダイレクトされない（認証サーバーを経由しない）ので、認証サーバー側にログが残りません。まあ、PINでWindowsログインできるのは、このPRTのおかげですし、便利ですよね。

Authenticator Assurance Level（AAL）について

NIST（National Institute of Standards and Technologyの略で「米国国立標準技術研究所」と訳されてます）が出している米国政府向けに言及したデジタルアイデンティティフレームワークのガイドライン「NIST Special Publication 800-63-3」というのがありまして、以下の内容が記載されています。

・SP 800-63A
IDの登録プロセスと提示されたIDの証明などのID保証レベル（Identity Assurance Level）について定義しているドキュメント

・SP 800-63B
認証保証レベル（Authenticator Assurance Level）とライフサイクル管理について定義しているドキュメント

・SP 800-63C
フェデレーションIDシステムの実装およびフェデレーション保証レベル（Federation Assurance Level）について定義しているドキュメント

最近、「認証の保証レベル（AAL）」について話題になっているので、調べてみました。AALのレベルは「1～3まで」定義されているのですが、一般的な企業用途では「AAL2」が現実的かなと思いました。「AAL3」だと多要素認証デバイスに「ハードウェアトークンが必須」だったりするので、銀行とか金融系以外は運用的に厳しいのが現状だと思われます。

■Authenticator Assurance Level 2 について

個人的にAAL2の要点は「Authenticator（認証デバイス）の定義」とパスワード運用に関わるお話かなと思いますが、「Authenticatorのライフサイクル管理」や「セッション管理」、「プライバシーに関する考慮事項」などの記載もありますので、一度、原文を読むことをお勧めします。（Google翻訳だと分かりにくい訳になってしまうので、英語で読むことをお勧めします！）

【Authenticator（認証デバイス）の定義】

「Memorized Secret」はいわゆる”パスワード”と置き換えると分かりやすいと思います。パスワードは「パスフレーズ」が前提となっており、その運用についても以下のような記載があります。

パスフレーズとは文章をパスワードにするような方法で、例えば「私はゲームが好きです/特にPC88のDragonSlayer2が好きです」→「watasihagamegadsukidesu/tokuniPC88noDragonSlayer2gasukidesu」という文字列を設定する、といった考え方です。

【パスワード運用のガイドライン】

【ガイドラインの順守・許容表現について】
• SHALL(するものとする)およびSHALL NOT(しないものとする)
　- 厳密に従う必要があり、逸脱が許可されていない要件。
• SHOULD(すべきである)およびSHOULD NOT(すべきではない)
　-  いくつかの可能性の中で特定の推奨があることを示している。
　-  行動指針を推奨するが、必須であることまでは要求しない。
• MAY(してもよい)およびNEED NOT(しなくてよい)
　- 行動指針が許容できることを示す。

■AuthnContextClassRef（認証コンテキストクラス）について

AuthnContextとはIdPがSPに応答するSAMLレスポンスに「どんな認証を方式を利用したか？」という情報が埋め込まれる要素です。SAMLリクエストに含めることが可能で、「認証方式を指定」することができます。

例えばSP①はパスワード認証でOKだが、SP②は証明書認証が必要です、という場合、SAMLリクエストは以下のようになります。

＜samlp:RequestedAuthnContext xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ＞
　＜saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"＞
　　　urn:oasis:names:tc:SAML:2.0:ac:classes::X509
　＜/saml:AuthnContextClassRef＞
＜/samlp:RequestedAuthnContext＞

この認証コンテキストクラスについて、AALやFALのドキュメントに具体的な記述は無いようですが、今後はAALと合わせて普及する可能性もあるのでチェックしておくのが良さそうです。

今回はここまで。

【参考にさせていただいた資料】
・NIST Special Publication 800-63-3（原文）
　https://pages.nist.gov/800-63-3/sp800-63-3.html
・認証にまつわるセキュリティの新常識（Internet Week ショーケース in 仙台）
　https://www.nic.ad.jp/sc-sendai/program/iwsc-sendai-d2-6.pdf
・NIST SP 800-63-3の概要と今回の改訂がもたらす影響（JIPDEC）
　https://www.jipdec.or.jp/library/report/20171127.html
・OASIS Authentication Context for the OASIS SAML V2.0
　http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf

AzureADをIdPにしてGoogle WSとSAML連携する

AzureADをIdPとしてGoogle WSとSAML連携をしようと思って設定をしました。SAML連携なので特に問題ないと思って設定しましたが、ちょっとだけつまづいたのでメモとして残しておきます。また、主だった設定の流れは検索すればすぐに情報が出てくるので割愛します。

■SSO連携設定

AzureADの管理コンソールの「エンタープライスアプリケーション」から「Google Cloud / G Suite Connector by Microsoft」を検索して追加します。プラグインの追加を求められるのですが、一般的なSAML連携なので「プラグインって必要なの？」と思いつつ、追加しておきます。実はこれがワナでした。

■ポイント①：識別子（エンティティID）の設定

SAMLの詳細な設定にて、識別子（エンティティID）は以下を設定してください。
・https://google.com/a/ your-domain
・https://google.com
・google.com/a/your-domain
・google.com

この設定に間違いや不足があると、SSOログイン時に以下のエラーが発生します。

■ポイント②：送信属性はNameIDのみ

プラグインを追加した関係で「送信属性とクレーム」の「追加の要求」に余計な属性が追加されています。これがワナでして、Google WSとのSSO連携では「一意のユーザー識別子 (名前 ID)」（NameID）のみ設定すればOKです。余計な設定をしているとSSOログイン時に以下のエラーが発生します。

SAML Responseに不要な属性があっても無視するSPが多いなか、Googleさんは厳密にチェックしているようです。そのため、不要な属性をSAML Responseに含めないようにしてください。必要な「送信属性とクレーム」は「一意のユーザー識別子 (名前 ID)」だけです。

—2022年11月追記—
根本的な原因は「Attribute」に2バイト文字（姓名）が含まれているからでした。日本の場合、姓名に2バイト文字は含まれると思いますよ！ということで認証には不要なので「ユーザー識別子」だけでいいですね。

ちなみに、「一意のユーザー識別子 (名前 ID)」にはUPN以外にカスタム属性なども設定できますので、UPNとは全く別の値も利用できます。AzureADアカウントのUPNが「test001@test.com」だけど、Google WSのアカウントは「Hideo@kojipro.jp」とか、結構こんなケースは多いのでは。。。

■ポイント③：ログアウトURLはちょっと違うよ

Google WS側のSSO設定画面にある「ログアウトURL」の設定ですが、AzureAD側に表示される「https://login.microsoftonline.com/xxxx/saml2」だとうまくいきません。以下のURLを設定してください。

・https://login.windows.net/common/wsfederation?wa=wsignout1.0

■まとめ

ということで「つまづきポイント」をメモっておきました。Googleのプラグインって何なんでしょうね？自動IDプロビジョニングとか、その辺の機能を使うための設定が省力化できるってことかな。。。

【参考：チュートリアル:Azure Active Directory シングル サインオン (SSO) と Google Cloud (G Suite) Connector の統合】
https://docs.microsoft.com/ja-jp/azure/active-directory/saas-apps/google-apps-tutorial

Set-AzureADUserExtension で AzureADのカスタム属性に値をセットする＆確認する方法

AzureAD側で用意されているカスタム属性「extensionattribute1～15」に値をセットしたくて調べていましたが、あまり情報がないのでまとめておきます。特にセットした値をPowerShellで確認する方法が見当たらないなくて、いろいろ試したけど結局、「Microsoft Graph Explore」から確認することになりました。詳しくは記事を読み進めていただければと思います。

■extensionattributeに値をセットする

カスタム属性に値をセットするためには「Set-AzureADUserExtension」コマンドを利用します。このコマンドを利用するために「Windows PowerShell SE」から「Install-Module AzureAD」コマンドでモジュールをインポートしてください。詳細はこちらの記事を参照していただければと思います。

①「Connect-AzureAD」コマンドでAzureADに接続
②「Get-AzureADUser -SearchString “検索文字列” | Select-Object *」で「ObjectID」を調査
③「Set-AzureADUserExtension -ObjectId xxxxx -ExtensionName extensionattribute5 -ExtensionValue “値”」

②では「Select-Object *」なのでたくさん情報が表示されると思いますが、最初のほうに「ObjectID」が表示されていると思います。③のコマンドではカスタム属性「extensionattribute5」に値をセットしています（なんとなく5番に値を入れてみました）。コマンドの実行結果は（成功、エラーなど）何も表示されません。ということで「ちゃんと値がセットされているか？」を確認したいと思います。

■extensionattributeにセットした値を確認する

簡単なPowerShellコマンドから確認できると思っていましたができませんでした（ご存じの方、教えてください）。「Get-AzureADUser -ObjectId xxxxx | Select-Object -ExpandProperty ExtensionProperty」コマンドで確認できそうだったのですが、独自で追加した拡張属性の値は表示されるけど用意されている「extensionattribute」は表示できませんでした。何でやねん！？ということで「Microsoft Graph Explore」を使って「Graph API」を利用して確認します。最初はスクリプト作ろうかと思いましたが「Microsoft Graph Explore」はブラウザから利用でき、ソフトウェアのインストールなどはないので手軽に使えます。ということで、これでいきます。

■Microsoft Graph Exploreから値を確認する

まずは「Microsoft Graph Explore」のサイトにアクセスしてAzureADの管理者アカウントでログインしてください。ログインすると「Graph API」を実行することができます。

Microsoft Graph Explorer URL：https://developer.microsoft.com/ja-jp/graph/graph-explorer

①AzureADの管理者アカウントでログインしてください。
②デフォルト（GET / v1.0）でOKです。
③「Graph API」コマンド（URL）を入力します。「extensionattribute」を取得するURLは以下です。
　 https://graph.microsoft.com/v1.0/users/ObjectIDの値?$select=onPremisesExtensionAttributes
④クエリ（入力したコマンド）を実行します。

■まとめ

「extensionattribute1～15」は「AzureAD Connect」を利用するとオンプレミスの「Active Directory」から同期できる属性でもあります。「Graph API」のクエリにも「onPremisesExtensionAttributes」とあるので”オンプレAD向けのカスタム属性”という意味が強いのかなと思っています。

ちなみにこの「extensionattribute1～15」は、SAML Responseの「NameID」や「Attribute」に利用することができます。

それにしてもPowerShellから簡単に確認できればよかったのですが・・・。
「The onPremisesExtensionAttributes is a property just for the User object in Microsoft Graph.you could not get it with command like Get-AzureADUser.（onPremisesExtensionAttributesはMicrosoftGraphのUserオブジェクト専用のプロパティです。Get-AzureADUserのようなコマンドでは取得できません。）」という記述も見かけたので、PowerShellからは呼び出せないようですね。