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