パスキー（Passkeys）を使った認証を試してみる

最近何かと話題の「パスキー（Passkeys）」。いろいろ調べてみましたが、一応、以下が私の認識です。

【パスキーとは？】
・FIDO2認証技術を利用しており、FIDO認証方式の1つ（だと理解している）。
・認証デバイスをPCがBluetoothで自動検出する仕組みがあるので物理的に認証デバイスを差す必要がない。
　→これは「caBLE」というパスキーの関連技術の1つ。
　→外部デバイスを利用する場合、やり取りはQRコードの読み取りからスタート。
　→MacbookのTouchIDなど内臓センサーを利用するのが楽。
・認証デバイスに入っている（認証で利用する）秘密の鍵はアカウント間で共有される。
　→故にどのデバイスでも同じアカウントでログインしていれば、認証デバイスとして使える。
　→そして、現時点では認証デバイスを固定できない（日本の企業だと受け入れられないのでは・・・）。

という事で、文字の説明だけだといまいち「何がうれしいのか？」分からないので、実際に試してみました。

■前提条件

パスキーを利用するためには、認証を行うWebサービス（SP）やSSOしている場合にはID Provider（IdP）がパスキー（FIDO2認証）に対応している必要があります（パスキーの認証技術はFIDO2を採用している）。そしてもちろん認証デバイスもパスキーをサポートしている必要があります。また、今回は外部認証デバイスとして「iPhone13」を利用するのでクライアントPC（Windows11）と認証デバイス（iPhone13）の「Bluetooth」を「ON」にしておきます（ペアリングはしなくて大丈夫です！）。これで認証時にブラウザが「Bluetooth」通信を介して認証デバイスを探したり、やり取りを行うことができます。

【前提条件】
・認証を行うWebサービス（SSO環境ではIdP）が「パスキー（FIDO2認証）」に対応している必要がある。
・利用するブラウザと認証デバイスがパスキーに対応している必要がある。
・認証を行うWebサービス（SSOしている場合にはIdP）に認証デバイスの事前登録が必要。
・クライアントPCと認証デバイスの「Bluetooth」を「ON」に設定（今回はIPhoneを利用するため）。

■パスキーを使った認証の流れ

パスキーを使った認証の大まかな流れは以下となります。

①　認証デバイス（今回はiPhone13を利用）の登録（事前準備）
②　認証時にブラウザが「パスキーがあるデバイスの選択画面」を表示
③　デバイス選択後（今回は「別のデバイス」を選択）、ブラウザが「QRコード」を表示
④　「Bluetooth」通信でデバイスを検出
⑤　認証デバイスで「QRコードを読み取り」
⑥　認証デバイスで認証（今回はiPhoneを利用しているのでFaceIDで認証）
⑦　認証完了情報を「「Bluetooth」通信で返却

↑ブラウザ上にこんな感じのポップアップが表示されます。まさかの「QRコードをスマホで読み取る」んですね。iPhoneのカメラをかざすと「パスキーでサインイン」って黄色い文字が表示されます。文字をタップするとiPhoneが「パスキーをiCloudに保存するか？」みたいなメッセージを（最初だけ）出すので、「続ける」ボタンをタップしてください。2回目以降は「保存済みのパスキーを使用してサインインしますか？」というメッセージに変わります。今回はiPhone13を利用しているので「FaceID」で顔認証すると、待ち状態になっていたブラウザ画面がログイン完了に変わっていると思います。

う～ん・・・どうでしょう・・・今回、認証デバイスとして（内臓センサーではなく）外部デバイスを利用するので、QRコードの読み取りが必要だったわけですが、追加の認証方式としてはワンタイムパスワード（OTP）のほうが簡単で手間は少ないです。もちろん、OTPはネットワークに（使い捨てのパスワードとは言え）認証クレデンシャルが流れるし、フィッシングサイトに誘導された場合の事を考えると、“パスキーの方がより安全です”という理屈は分かります。それとパスキーを使った認証、FIDO認証はそれ単体でも利用ができるセキュリティ強度を持っているので、OTPと比較するのもちょっと違うなとも思いますけどね（OTPは「パスワード認証+OTP」という形で利用され、OTP単体の認証のみではセキュリティ強度は高くないとされています）。

■認証デバイス検出の仕組み

認証時にブラウザが「Bluetooth」で近くの認証デバイスと通信する仕組みは、図のようになっているようです。「caBLE（Cloud-Asisted BLE）：今は”hybird”って呼ばれている？」について詳しくないので、何となくのシーケンスです。もともとはGoogleが作った仕組みで、Googleの2段階認証プロセスにて、スマートフォンを利用する方式（「ログイン済みGoogleアプリを起動」するなど）があったと思いますが、その技術を拡張したものらしいです。

■使った感想

パスキーの利用は現時点では微妙な印象でした。パスキーのコンセプトは認証に利用する鍵をアカウントと紐づけて、そのアカウントでログインしている端末であれば鍵を共有できる、ってところが大きなポイントだと思っていますが、「鍵はデバイス間で共有されさまざまなデバイスから利用できると組織として困る」と思う方もいると思います。

なんとOktaではPasskeyの利用をブロックする仕組みがありました！
https://help.okta.com/en-us/Content/Topics/Security/mfa-webauthn.htm

Okta Help Center

また、プラットフォーマ（Google、Apple、Microsoft）間でのパスキー相互利用の問題などはこれから決まってくると思うので、現時点でパスキーを積極的に利用するモチベーションはないです・・・まだまだ仕様も変更になるようですし、時期尚早かなと思いました。

今回の検証でFIDOデバイスとしてWindows Hello/Apple FaceID/Apple TouchIDが利用できれば、パスキーを利用しなくてもしばらくは良いと感じました。

■参考資料
【Apple社サポートページ：iPhoneでパスキーを使ってサインインする】
https://support.apple.com/ja-jp/guide/iphone/iphf538ea8d0/ios

【Add registration/authentication extensions for cloud-assisted BLE #909】
https://github.com/w3c/webauthn/pull/909

今話題？のISMAP（イスマップ）って何！？

ISMAP（イスマップ）とは、「Information system Security Management and Assessment Program」の略称で、官公庁、自治体など政府がシステムを調達するときに、指標となるセキュリティ評価の制度です。ISMAPに登録されてる製品、サービスであれば、政府調達のためのセキュリティ基準を満たしているので、安心して購入ができます。

また、政府は、「原則としてISMAP取得企業からクラウドサービスを調達するように」と言っています。あくまで「原則」なので、ISMAPを取得していると有利に働くものの、取得していないからと言って全く土台に乗れないということではありませんが・・・。

更に、官公庁、自治体だけでなく、大学や教育委員会などの文教市場でも「ISMAPに対応していること」などの条件が入札仕様に（今後）入ってくることが予想されます。実際、案件の問い合わせで「ISMAPのリストに載っていますか？」って聞かれたことがありました。

■取得にかかる費用はすごく高いらしい

ISMAPの取得自体、審査がかなり厳しく、取得にかかる費用も結構高いらしいです。聞いたところによると「取得までに2,000万ぐらいかかった」とか、それ以上かかった話も聞きました。マジかよ・・・。そして資格には有効期限があるので更新する必要があるのですが、その費用も高額との話でした。ウソでしょ・・・。

サイボウズ社のサービスはISMAPに登録されていますが、登録までの苦労話を資料にまとめて公開してくれています（ありがてぇ！）。

【サイボウズ様のISMAP登録挑戦苦労話】
https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2021/12/congress2021_akeo.pdf

【ISMAP対応のクラウドサービス一覧】
https://www.ismap.go.jp/csm?id=cloud_service_list

■中小クラウンドベンダーからの視点

ISMAP取得は相当高いハードルがあるな、という印象です。この手のものって「今後はISMAPを取得していることが大きな優位点なる！」とその時はHot！になるのですが、2～3ヶ月後には話題にもあがらなくなる、と言うのが多いので、慌てずに様子をみましょう。実際、この記事の下書きをしたのが、2022年10月頃なのですが、今は2023年2月でして、やっぱり最近はあまり聞かないワードになっています。ISMAPに対応したサービスもそれほど増えてないし、周りで騒いでいた方も最近ではめっきりですね。

という事で、ISMAPについてはいったん離れます。また再燃したら記事にしようと思います。

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からは呼び出せないようですね。

Microsoft Teamsのエラー&何度も認証を求めてくる現象について

ここ最近、Microsoft365のAPI変更やらTemasの障害やらで、いろいろ改修&アップデートしているんじゃないかな？と疑っていますが、それは良いとして、急にTemasアプリが認証を求めてきて、認証後にエラーが表示されたり、正常に認証できたその翌日にまた認証を求めて来たり・・・と不安定な動作をしていました。↓このエラー画面、よく見ません？？

繰り返しになりますが、このエラー表示、認証時に表示されたり、この画面が表示されても、Teamsアプリを再起動すると正常にログイン出来ている状態になっていたりと・・・良くわからないです。

で、「サインアウトしてみてください」のリンクをクリックすると通常は再度認証画面が表示される（表示まで1～2分ぐらいかかることがあったので、ちょっと我慢です）ことが多いので、再ログインしてみてください。正常にログインできない、あるいは翌日に再発するような場合、以下の対処をしてみてください。私はこれで解決しました。

■Windows資格情報を削除する

Windows OSの「資格情報の管理」を開いて「Windows資格情報」を表示、以下のレコードがある場合、削除してみてください。（とりあえず「SSO_POP_User」を削除してダメなら「MicrosoftAccount」も削除してみてください。）

・SSO_POP_User:user=ユーザーアカウント
・MicrosoftAccount:user=ユーザーアカウント

「MicrosoftAccount」はOSの「アカウント」設定に登録した「メールとアカウント」（組織の場合には「職場または学校にアクセスする」）の認証情報だと思います。

「SSO_POP_User」はアプリとかの認証情報なのでしょうか・・・調べても有益な情報が出てこないですね。

ちなみに自己責任で実施してください。まあ認証情報なので再認証を求められるだけでOSが壊れるとか、変なことになったことはありませんが。

この現象、1台のデバイスで複数のアカウントを利用しているような状況で良く発生するとの情報もあります。例えばMSアプリ（Word/Excelなど）はAアカウントで認証して、TeamsはBアカウントを利用しているとか。確かに私もそんな状況でした。

ということで、いろいろブラックボックスで正確なことはわかりませんが、現象が発生した時にはOSの資格情報を疑ってみてください。

【2022年4月：追記】
VPN接続している端末だとTeamsへの接続エラーが多発することを確認しました。特にBtoBで複数組織をTeamsで使い分けている環境だと組織の切り替え時にエラーが発生することが多いです。VPNを切断すると正常に利用できます。ナレッジを調べたところ「Microsoft TeamsはVPN利用：非推奨」とのことです。Google検索で「Teams VPN 非推奨 」と検索するとたくさん情報が出てきます。

・Microsoft Teamsで推奨されないテクノロジー
https://docs.microsoft.com/ja-jp/microsoftteams/microsoft-teams-online-call-flows

MS365へのプロビジョニングについて

Microsoft 365へのアカウント・グループの作成、変更、削除などの「プロビジョニング」機能はOktaなどのIDaaSにも備わっていますが、昨今、Microsoft 365の機能拡大に伴い、「やっぱり Microsoft 365へのプロビジョニングはAzure AD Connectが最も適しており安定しているなぁ～」と実感しています。

もちろんIDaaSも悪くはないのですが、様々な理由によりマイクロソフト社が提供している「Azure AD Connect」が最適だとの結論に私自身も達しています。以下にその理由を記載していきたいと思います。

■Azure AD Connect を利用すべき理由　その①

Azure AD Connect V2 では、専用のAPIエンドポイントが用意されており、他の3rdパーティー製品では利用できません。このエンドポイントはV2になって更にパフォーマンスが向上しているそうです。

Microsoft がデプロイした Azure AD Connect 用の新しいエンドポイント (API) では、Azure Active Directory に対する同期サービス操作のパフォーマンスが向上しています。 新しい V2 エンドポイントを利用すると、Azure AD に対するエクスポートとインポートのパフォーマンスが明らかに向上していることがわかるでしょう。 この新しいエンドポイントでは、次のものがサポートされています。

・メンバー数が最大 250,000 までのグループの同期
・Azure AD に対するエクスポートとインポートのパフォーマンスの向上

【Azure AD Connect 同期 V2 エンドポイント API】
https://docs.microsoft.com/ja-jp/azure/active-directory/hybrid/how-to-connect-sync-endpoint-api-v2

MS365へのプロビジョニングをPowerShellで頑張っているサービスも見受けられますが、パフォーマンス的にちょっと厳しいし、エラーも多く発生して「同期できない、エラーが出力されている」など安定しない場合があります。

■Azure AD Connect を利用すべき理由　その②

Microsoft 365側に作成されたグループやデバイス情報、パスワードをオンプレミスのActive Directoryに書き戻すことができます。

■ デバイス情報の書き戻し（Device Writeback）
MS365の認証時に「組織がデバイスを管理できるようにする」などで「はい」を選択するとデバイス情報がAzureADに登録されます。この情報をADに書き戻す機能ですでね。

■ グループの書き戻し（Group Writeback）
昨今「Microsoft 365 グループ」の利用が多くなっていますが、このグループはADには作成できないので、MS365側で管理者が作成することになります。その情報をADに書き戻す、という使い方になりますね。

■ パスワードの書き戻し（Password Writeback）
MS365側（というかAzureAD側）でパスワードを変更した場合、ADに書き戻す機能です。パスワードの運用はAzureAD側で実施するのが良い（セキュリティが高い）と思うのでこの機能は便利かも知れませんね。

このような機能はマイクロソフト社以外の製品では実現不可能かと思います。また、「今は使わないから」という意見もあるかも知れませんが、クラウドサービスはものすごい速さでアップデートされるので、直ぐに「この機能を使いたい！」となる可能性もあります。その意味でも親和性が高い「Azure AD Connect」を選択しておくべきかなと思います。

■Azure AD Connectを利用すべき理由　その③

プレビュー機能の発表にあるように今後は様々な機能が利用できるようになりそうです。例えば注目しているのは「段階的ロールアウト」機能です。この機能は「ユーザー単位でフェデレーションする/しない」を設定できるため、まずは数人で試してみて、問題なければ全ユーザーをフェデレーション移行する、ということが可能になります。

—- 2023年10月追記 —
「段階的ロールアウト」はフェデレーション構成からクラウド認証に戻す際に利用する機能のようです。逆ができればいいのですが。

【段階的なロールアウトを使用してクラウド認証に移行する】
https://learn.microsoft.com/ja-jp/azure/active-directory/hybrid/connect/how-to-connect-staged-rollout
———————————

この機能に関しては、Azure AD Connectがないと利用出来ないわけではありませんが、ADとのパスワードハッシュ同期機能を利用していれば、スムーズに移行できると思います。

■まとめ

Microsoft 365へのプロビジョニングはどう考えても「Azure AD Connect 一択」かなと思います。オンプレミスにあるADとAzrueADとの連携、Windows 10、Windows 11というクライアントOSとの親和性・・・別の仕組みで構築してしまうといろいろと不便な事が出てきそうです。

今回はここまで。