diff --git a/active-directory-federation-service/2019adfs/index.html b/active-directory-federation-service/2019adfs/index.html index 3b3aa2041cb..1a977a97df4 100644 --- a/active-directory-federation-service/2019adfs/index.html +++ b/active-directory-federation-service/2019adfs/index.html @@ -15,7 +15,7 @@ - + @@ -156,7 +156,7 @@
アカウント名: user01@contoso.com
アカウント ドメイン:
エラー情報:
失敗の原因: ユーザー名を認識できないか、またはパスワードが間違っています。
@@ -259,9 +259,9 @@例外情報:
-System.IdentityModel.Tokens.SecurityTokenValidationException: user01@contoso.com
+System.IdentityModel.Tokens.SecurityTokenValidationException: user01@contoso.com
場所 Microsoft.IdentityServer.Service.Tokens.MSISWindowsUserNameSecurityTokenHandler.ValidateToken(SecurityToken token)
上記内容が少しでもお客様の参考となりますと幸いです。
製品動作に関する正式な見解や回答については、お客様環境などを十分に把握したうえでサポート部門より提供させていただきますので、ぜひ弊社サポート サービスをご利用ください。
この度、Microsoft Entra サポート チームより、最近 Entra の利用を始めたお客様を対象に初学者向けのブログ シリーズを開始することといたしました。本記事は、その Entra ID 初学者向けシリーズの第 1 弾「条件付きアクセス 入門」です。
本記事の対象者
記事概要
本記事では、Microsoft Entra 条件付きアクセスを初めて学習/導入する方を対象に、基礎的な概念や設定方法を分かりやすく解説します。また、現場でよくある質問や課題を例に、具体的な対応策も紹介します。最後に、サインイン ログの読み解き方についても簡単に解説します。IT 管理者の方々にとって日々の運用に役立ちましたら嬉しいです!
条件付きアクセスは、ユーザーが Entra ID と連携したリソースにアクセスする際に、特定の条件に基づいてポリシーを適用し、リソースへのアクセスを制御する仕組みです。これにより、必要なユーザーだけが適切な状況でリソースにアクセスできるようになりセキュリティを高めることが可能です。条件付きアクセス ポリシーが適用されるのは、ユーザーが Entra ID にサインインした後、Entra ID がクラウド上のリソースに対して各種のトークンを発行する直前となります。
条件付きアクセスの流れ:
ポリシーの適用条件や制御に具体的に設定できる値については後述します。
より細かい説明については 改めて知る Microsoft Entra 条件付きアクセス の記事もご覧ください。
初学者にとって押さえておくと躓きにくいポイントと、おすすめの Identity チーム公式ブログをご紹介します。条件付きアクセス初学者の方に是非意識していただきたい考え方はこちらです。
条件付きアクセスは、サインインに対してアクセス権を付与する (アクセスを許可) するという考え方ではなく、設定した条件に合うサインインに制御 (制限) をかけるという考え方です。
条件に合致した場合にサインインに対して適用される制御 (制限) としては、「アクセスのブロック」や「多要素認証を要求する」、「Microsoft Entra ハイブリッド参加済みデバイスが必要」というものがあります。実際の画面とその考え方は以下の画像のとおりです。
条件付きアクセスは、ポリシーが適用される条件を満たした場合に、アクセスをブロックもしくは制御するためのものあり、条件を満たしたものを許可するというものではありません。ファイアーウォールのルールのような「既定ですべてブロックがあり、そのうえで一部を許可する」というイメージではない点に注意ください。ID とパスワードという最低限の認証を突破した後に、条件に合うものに追加の制御 (もしくはブロック) を適用するというイメージです。
改めて、「アクセスを許可する」というものではなく、「特定の条件を満たした場合に制御が適用される (条件を満たさなかった場合は制御が適用されない)」というイメージになります。
詳細は以下の記事もご覧ください:
条件付きアクセスが制御の対象とするのは、「アプリケーション」ではなく「リソース」へのアクセスです。ここで言う「リソース」というのは、Entra ID と連携して動作している Web アプリケーション (Salesforce や自社開発のWeb アプリケーションなど) や、PC 上で動作するクライアント アプリケーションがクラウド上からデータを取得する際のアクセス先 (Web API) とお考え下さい。
例えば Outlook クライアントを Windows 上で利用して、Microsoft 365 の E メールを利用している場合、ユーザーは単に Outlook クライアントにサインインしているだけと思うはずですが、実際にはインターネット (Microsoft 365) 上から Email のデータを取得してくるにあたり Exchange Online の Web API を利用しています。Outlook クライアントは Exchange Online というクラウド上の “リソース” を使用しており、この Exchange Online が条件付きアクセスの適用対象となります。このため、条件付きアクセスの設定画面では、Outlook というリソースは出てきません。
他にも例えば、ユーザーが Windows 上で Teams のネイティブ クライアント アプリにアクセスしたとします。この時、ユーザーは Teams のネイティブ クライアント アプリにだけアクセスしているわけではありません。実際は、Teams のクラウド側の Web サービスに加え、SharePoint Online、Exchange Online、Microsoft Planner という複数の Web API にアクセスをしています。つまり、Teams のクライアントは、それが使用するデータのもととなっている複数のクラウド上の “リソース” にアクセスしています。Teams はこれらリソースの一つでもアクセスができないと (条件付きアクセスでブロックされると)、正常に動作しません。
このようにユーザーがサインインしているアプリが、別のクラウド上の Web API (リソース) を呼び出すということは一般的であり、これはサービスの依存関係とも呼ばれます。条件付きアクセスを利用する際に意識するべき依存関係については 条件付きアクセスのサービスの依存関係 に解説されていますのでご覧ください。
そのほかの条件付きアクセスの動作の仕組みやよくある質問に関しては Azure AD の条件付きアクセスに関する Q&A の記事もご覧ください。
条件付きアクセス ポリシーにて設定可能な値の概要は以下のとおりです。まず、条件について以下に概要をおまとめしました。条件付きアクセス ポリシーでは、まず大きく適用対象のユーザーと適用対象のリソースを選択する必要があります。これらに加えて、さらにネットワークの場所やクライアント OS の種類など細かく適用条件を選択することが可能です。
上記の囲まれた部分の構成が終わったら、次にその条件に合致したときにどのような制御を適用するかを決めます。それが以下の画面です。
条件に合致したときにアクセスを許可する場合、許可に際して適用される制御の内容を選択します。例えば、条件に合致したときに多要素認証を求めたい場合は「多要素認証を要求する」にチェックを付けます。
なお、条件に合致したときにセッションに対しても制御を適用することが可能です。例えば、サインインの頻度という制御を適用すると、8 時間毎に再認証をユーザーに求めるということも可能です (頻繁な再認証はセキュリティをむしろ低下させるため推奨しておりません)。
各設定値の詳細は 条件付きアクセス ポリシーの構築 の公開情報もご覧ください。
これまでの説明をもとに、条件付きアクセス ポリシーの理解向上に役立ついくつかのお問い合わせ例をご紹介いたします。
以下のようなお問い合わせがあったとします。
以下を満たす条件付きアクセスポリシーを作成したい。
<シナリオ A>
社外からの Office 365 へのアクセスは準拠済みのデバイスのみに制限したい<シナリオ B>
Android / iOS に対しては指定した IP アドレスの範囲からしかアクセスを許可しない
これらの場合、ポリシーの構成としては、すべてのネットワークの場所に対して「準拠済みのデバイスを要求する」もしくは「アクセスをブロックする」と構成して、ポリシーの対象外の場所に「社内」や「指定した IP アドレスの範囲」を指定します。各シナリオを言い換えると以下のようになります。
<シナリオ A>
全ての場所ですべてのユーザーに対し、Office 365 にアクセスする際は準拠済みのデバイスを必要とするが、社内はその対象外とする。
<シナリオ B>
Android / iOS に対してはすべての場所 (指定した IP アドレスの範囲はその対象外) ですべてのユーザーとアプリに対してアクセスをブロックする。
これらを実際のポリシーの構成に落とし込むと以下のようになります。このように、要望されているシナリオを条件付きアクセス ポリシーの構成に合うように少し変換して構成ください。
<シナリオ A の設定例>
<シナリオ B の設定例>
以下のようなお問い合わせがあったとします。
以下条件付きアクセスポリシーを設定をしたが、適用されない。オフィス以外の場所からのアクセスはブロックしたい。
ターゲット リソースが指定されていないため、何もポリシーの対象となっておらず機能しません。以下は割り当てをするときに必ず指定する必要があるものです:
前述のとおり、条件付きアクセスは、条件に合ったものに対して制御を適用するというものですので、ポリシーが適用される条件についてはすべて指定するようにご注意ください。
以下のようなお問い合わせがあったとします。
条件付きアクセスにて、「デバイスは準拠しているとしてマーク済みである必要があります」の制御を適用された状態にしました。新しいデバイスの Intune 登録は可能でしょうか。
このお客様は、条件付きアクセスにて「デバイスは準拠しているとしてマーク済みである必要があります」の制御を適用にした際に、これから Intune 登録しようとしているデバイスはこの条件を満たせない (登録しようとしているその時点ではデバイスはまだ非準拠である) ため、新規の Intune 登録がブロックされるのではないかと懸念してこのようなお問い合わせをされました。
このシナリオは条件付きアクセスで考慮されており、Bootstrap シナリオと呼ばれます。この Bootstrap シナリオに当たる以下の場合は、条件付きアクセス ポリシー適用の対象となるユーザーとリソースを設定していても、制御が適用されません:
この時、条件付きアクセス ポリシーとしては、制御が適用されないという結果になりますので、サインイン ログ上は、条件付きアクセス ポリシーの適用が失敗したと表示される場合があります。しかしながら、これは想定された動作であるため心配いただく必要はありません。
詳細は 準拠しているデバイス、ハイブリッド参加済みデバイス、または MFA を必須にする の公開情報もご覧ください。
以下のようなお問い合わせがあったとします。
Teams 以外のすべてのアプリをブロックし、Teams はポリシーの対象外としている。しかし、Teams にアクセスできないのはなぜでしょうか。
Microsoft Entra 条件付きアクセスのサービス依存関係が原因です。前述のとおり、Teams にアクセスするためには、Microsoft SharePoint Online や Microsoft Exchange Online のリソースにアクセスする必要があります。しかし、このシナリオでは Teams のみがポリシーの対象外であり、Microsoft SharePoint Online や Microsoft Exchange Online は条件付きアクセス ポリシーの適用対象となります。このため、Teams アプリが使用しているリソースがブロックされる状態であり、結果的に Teams にもアクセスできません。
Teams のみをユーザーに利用させたいというお客様は多くいらっしゃいますが、Teams のこのような性質により、Teams のみユーザーに利用させるということは極めて困難です。条件付きアクセス ポリシーの観点では、Microsoft SharePoint Online や Microsoft Exchange Online も条件付きアクセスポリシーで許可いただく必要があります。結果としてユーザーは Outlook や SharePoint Online にもアクセスが可能となります。弊社としてはこういった依存関係を考慮して、条件付きアクセスポリシーの対象および対象外としては Office 365 の利用をお勧めしています。
詳細は 条件付きアクセスのサービスの依存関係 の公開情報もご覧ください。
条件付きアクセスに起因してサインインがブロックされた場合、その概要がサインイン画面に表示されます。この時、「詳細」をクリックするか、画面右下の … をクリックすると、エラーの詳細を確認可能です。サインイン時のエラー画面にて表示される以下の情報を控えてサインイン ログを検索すると詳細な情報を得ることが出来ます。
なお、これらの情報は弊社サポート チームにとっても重要な情報であるため、サインインに関連した調査を依頼される際には弊社サポートにもこの情報をぜひご提供ください。
Entra ID のサインイン ログを確認するには以下の手順を実施ください。
適当なサインイン ログの内容をクリックすると、以下のように情報が表示されます。[基本情報] タブにその概要が表示されます。ここで注目したい値は以下のとおりです。
[条件付きアクセス] タブでは以下の内容などを確認することが可能です。ポリシーの適用が思ったように行われない場合は、この画面を見て各ポリシーの適用状況をご確認ください。
今回の初学者向けシリーズ第 1 弾では条件付きアクセスについて解説しました。特にご注目いただきたい点をまとめると以下のとおりです。
上記内容をご覧いただけましたら、是非以下の資料についてもご覧ください。
ブログ
公開情報
]]>本記事は、2024 年 12 月 5 日に米国の Microsoft Entra Blog で公開された Enhance end-user experiences with Custom OTP Email Provider Support を意訳したものになります。ご不明点等ございましたらサポート チームまでお問い合わせください。
現代のデジタル時代において、シームレスなユーザー体験を提供することは、ブランドの強化、ユーザーの信頼獲得、ビジネスの成長にとって非常に重要です。Microsoft External ID の一般提供 (GA) により、一般消費者向けに高度なセキュリティとコンプライアンスを備えたユーザー体験が構築可能となりました。弊社は管理者と開発者の両方にとってシンプルでシームレスな体験を提供することを目指しており、直近のブログでは、モバイル アプリケーション向けに完全にカスタマイズ可能な ネイティブ認証 や 管理者向けの組み込みセキュリティ コントロール を紹介しました。
この取り組みの次のステップとして、External ID を利用しているアプリで、よりブランドのカスタマイズが行えるよう、新しいカスタム認証拡張機能を追加しました。カスタマイズとブランディングは、エンドユーザーがアプリケーションをスムーズに利用し、そこに企業ブランドのアイデンティティを反映させるという意味で非常に重要な機能です。ここからは、シニア プロダクト マネージャーの Sasha Mars より、Microsoft Entra 管理センターでこの新しい拡張機能の利用方法について紹介してもらいます。
こんにちは皆さん
今日は、新しくリリースされたカスタム認証拡張機能を紹介いたします 。この拡張機能により、サインアップ、サインイン、パスワード忘れの際に発生するワン タイム パスコードの利用において、マイクロソフトやマイクロソフト以外の E メール プロバイダーとの統合が可能になります。ぜひ、本日よりパブリック プレビューをお試しください。
今回お話しするカスタマイズ機能は、ユーザー体験をより細かくコントロールしたいというフィードバックに基づいて追加されました。顧客向けアプリを構築する場合、Azure AD B2C プラットフォームでの経験から、企業ブランドごとにカスタマイズされたユーザー体験を提供するということが顧客と企業の間の信頼関係を構築する上で非常に重要であることがわかっています。
この新しいカスタム認証拡張機能を使用すると、Microsoft Entra External ID が既定で提供する E メール サービスの代わりに、Azure Communication Services や他のサード パーティーの E メール プロバイダーなどお好みの E メール プロバイダーを利用でき、カスタマイズしたデザインと操作感を実現可能になります。
代わりに Azure Function App を作成することも可能です。この場合、HTTP トリガー関数を作成して、その関数の既定の設定値を更新ください。
EmailOtpSend カスタム認証拡張機能は、Microsoft Entra 管理センターのカスタム認証拡張のブレードで設定できます。そこで新しいカスタム認証拡張機能を登録し、それをアプリケーションに接続し、カスタム E メール プロバイダーをアプリケーションに割り当てます。
ここで、管理者が実際に独自の Email プロバイダーを設定 - BYOE (Bring Your Own Email) - し、API を使用して自動化する流れを見てみましょう。
基本設定 - ここでは EmailOtpSend のイベントの種類を選択できます。
エンドポイントの設定 - API エンドポイントを設定します。
API の認証 - API エンドポイントへの呼び出しを安全に行うためのフローを構成します。
アプリケーション - EmailOtpSend のイベントを割り当てるアプリケーションを指定します。
Microsoft Entra External ID テナントをまずご用意の上、ぜひ EmailOtpSend によるカスタム認証拡張機能をお試しください。
カスタム認証拡張機能の詳細については、こちら をご覧ください。
いつも皆様からのフィードバックをお待ちしております。以下のリンクより新機能に関するご意見をお寄せください。
Sasha Mars
Senior Product Manager, Microsoft Identity and Network Access
LinkedIn: Sasha Mars | LinkedIn
今回は、2024 年 11 月 19 日に米国の Microsoft Entra (Azure AD) Blog で Sarah Scott によって公開された Security Copilot is now embedded in Microsoft Entra を抄訳し、サポートチームにて補足したものになります。
Copilot は現在 Teams や Outlook など様々なサービスに組み込まれ、より簡単に利用できるようになっています。たとえば Copilot を PowerPoint で使ってプレゼンテーションを共同作成したり、Excel ファイルの分析を行うなども可能です。ただ、 ID 管理の観点では Copilot はこれまで利用できる機能がなく、「Entra 管理センターでも Copilot の機能を活用したい」と思われていた方もいらっしゃるかと思います。今回、Entra 管理センターにも Copilot の機能が組み込まれ、トラブル シューティングなどに活用できるようになりました!ぜひ下記で利用方法や役立つシナリオをご覧ください!ご不明点などございましたら遠慮なくサポートへお問い合わせください。
本日、Microsoft Entra 管理センターにおける Microsoft Security Copilot のパブリック プレビューを 発表 しました。この統合により、2024 年 4 月にスタンドアロン版の Security Copilot で一般提供された すべての ID スキル (具体的にはユーザーの詳細、グループの詳細、サインイン ログ、監査ログ) と、管理者やセキュリティ アナリストが直接 Microsoft Entra 管理センターで使用できる新しい ID 関連の機能が提供されるようになりました。また、ID 関連のリスク調査をよりよく行えるようにする新しいスキルも追加しました。12 月には、さらに範囲を広げ、Security Copilot と Microsoft Entra のスタンドアロンのバージョンと管理センターに組み込まれたバージョンの両方に App Risk Management 専用のスキルを追加する予定です。これらの機能により、ID 管理者とセキュリティ アナリストは、Microsoft Entra に登録されたアプリケーションとワークロード ID に影響を与えるリスクをより適切に特定、理解、修復できるようになります。
Security Copilot が Microsoft Entra に組み込まれたことで、ID 管理者は、AI を用いた自然言語によるまとめ (ID にまつわる背景情報や知見をまとめたもの) を得つつセキュリティ インシデントに対応することができ、ID の侵害に対してより一層の備えが可能となります。また、Copilot は管理センターに組み込まれれているため、管理センターから離れることなく、ID 関連のリスクやサインインの問題の解決などのトラブル シューティング作業を迅速に行うことが可能です。
パブリック プレビューでは、最初の Copilot スキルは ID のセキュリティとアクセスのトラブル シューティングに重点を置いており、これにより ID およびアクセス管理タスクの時間短縮と精度向上を目標としています。これは、ID とネットワーク アクセスの様々な課題 (ネットワーク アクセス、先進のアクセス制御、さらにその先を含む) に対応する、より包括的な生成 AI ソリューションをお届けするという弊社の目標に向けたほんの始まりにすぎません。ID とアクセスのシナリオで使用される生成 AI はまだ登場したばかりですが、急速に進化していることも事実であり、製品としての成功はお客様とのよりよいコラボレーションにかかっています。パブリック プレビューにいち早く参加することで、製品の成長に合わせて、主要なシナリオへの対応やスキルの改善にお客様も参画可能です。弊社はお客様と共に、今日のニーズに応えるとともに、今後の課題を先取りするソリューションを構築していきたいと考えています。
プレビューを早期にお使いのお客様から見えてきたその価値は目を見張るものがあります。Security Copilot IT Admin Efficiency Study によると、Entra 管理センターに組み込まれた Security Copilot を使用して、IT 管理者がアクセス失敗のトラブルシューティングを行うと、より短時間かつ正確にその対応を完了でき、さらに今後も業務で Copilot を使用したいと考える人が圧倒的に多いことがわかりました。結果は以下のとおりです:
弊社では ID 管理者の皆様の普段の業務フローにおいて Security Copilot を活用できるということが重要であると考えているため、Microsoft Entra 管理センターで直接 Copilot を利用できるようにしました。ナビゲーション バーにある Copilot ボタンをクリックすることで Security Copilot にアクセスできます。
Copilot が支援できるタスクがどういったものかをまず最初に理解しやすくするため、Copilot のチャットのパネルを初めて開いたときにスターター プロンプトというものを表示するようにしました。これはクリックするだけで実行できるプロンプトです。スターター プロンプトの一覧から選択するか、サインインログのトラブルシューティングや ID 関連のリスクの調査などの質問を Copilot に行うことが可能です。例えば「テナント内のリスク高のユーザーを表示してください」、「[ユーザー名] に MFA が要求されたのはなぜですか」、「[ユーザー名] の直近のサインインに適用された条件付きアクセス ポリシーはどれですか」などの質問が挙げられます。最後に、チャットの会話の流れに基づいて、より内容を深堀していくようなプロンプトも提案されますので、問題をさらに調査することが可能です。以下の画像もご覧ください。
なお、Azure ポータルと Microsoft Entra 管理センターの両方に「Copilot」のボタンがありますが、Azure ポータル上のボタンは Azure 向けの Copilot です。今回のブログで紹介している Entra 向けの Copilot とは異なるため、Entra 向けの Copilot を利用したい場合は、 Microsoft Entra 管理センターから Copilot にアクセスください。
ID 管理者、セキュリティ アナリスト、ネットワーク セキュリティ管理者はすべて、組織全体のアクセスを保護し、ID を管理するという目標を共有しています。当社は、これらの管理者が抱える職責を果たすにあたり直接的なサポートができるよう Security Copilot のスキル開発を進めており、注力している点としては以下が挙げられます。
これらの重点分野を中心に機能と機能を構成することで、Security Copilot と Microsoft Entra をご利用のお客様に対し、AI に基づく知見、自動化、推奨事項を提供し、お客様がより多くのことを実現できるようにしたいと思っています。これは具体的には、業務フローの効率化や、ID とリソースの保護など上記重点項目に関連する特定の業務をより早く、かつ正確に完了させるということです。
パブリック プレビューでは、以下の 2 つの重要なシナリオにおいて ID 管理者とセキュリティ アナリストを支援するスキルを提供いたします:
お客様の企業規模が成長し、ID に関連するリスクがより複雑になるにつれ様々な課題が生じますが、この解決を支援するというのが本スキルの目標です。攻撃の量と巧妙さが増すにつれ、アクセス ガバナンスとポリシーの強制を適切に行うことが非常に重要になっています。
4 月の発表 では、高リスクと判定されたユーザーを管理者が迅速に特定し解決するというシナリオについて解説しました。管理者は、Copilot が自動生成したまとめをもとに、ユーザーのリスク状態について分析情報を即座に得るとともに、実施すべき推奨事項も Copilot から得ることでセキュリティ インシデントを解消して問題を解決するということが可能です。
さらに、管理者が自由にプロンプトでの対話を通じてリスクの高いユーザーをより詳細に調査できる新機能を導入しました。これによりリスク レベルの上昇やリスクの高いサインインなどに関してさらなる知見が得られます。リスクのあるアプリケーションや未使用のアプリケーション、特定のアプリケーションに付与されたアクセス許可などの調査については、12 月にスタンドアロンと組み込み版の両方で追加される予定です。
ID 管理者は、セキュリティと効率性、ユーザーの生産性のバランスを取りながら、アクセス侵害にも対応するという責務を抱えており、ID に関するリスクが増すにつれ ID 管理者の負荷も増すばかりです。これに対応するため、管理者は Copilot を使用してサインインログのトラブルシューティング作業を自動化し、Microsoft Entra 内のユーザーやグループの詳細、サインインログ、監査ログ、および診断ログに関する実用的な知見をもとに具体的な対応項目を得るということが可能です。これらの機能により、管理者は重要な情報を迅速に収集し、トラブルシューティングをより早く行うことで、運用の効率化を実現できます。
サインインの失敗や条件付きアクセスの競合、ロールとアクセス許可の変更など、アクセスに関する問題が発生した場合、管理者は管理センターで Security Copilot を使用することでその原因を特定できます。Copilotを使用すると、認証方法からアカウントの状態まで、ユーザーの詳細を数秒で収集できるため、ユーザーの資格情報または構成に問題があるかどうかを迅速に判断できます。同様に、グループの詳細を使用して、アクセスに影響する可能性のあるグループのメンバー情報や所有者を簡単に確認できます。
サインイン ログの調査については、Copilot に特定のユーザーの最近のアクティビティや失敗した試みをピンポイントで要約するよう促すことができ、ブロックされたサインインや特定の IP アドレスに関連する潜在的なセキュリティ上の問題など、アクセス失敗の原因を簡単に診断できます。アクセス許可の変更や監査ログで異常が検出された場合などより複雑なシナリオの場合は、Security Copilot に事象の切り分けを依頼するとともに、その異常がどのようなものかの説明も即座に行わせることができます。これには、所有者の変更やアクセス権の追加による特権の昇格など、潜在的な攻撃の特定も含まれ、設定の不備によりセキュリティ リスクが拡大するのを防げます。
最後に、診断ログの機能により、Security Copilot がポリシーの健全性を評価し、構成とログ収集が正しく設定されていることを確認することも可能です。これにより、組織が脆弱な状態とならないよう先んじて構成の不備を特定可能です。
Security Copilot は、従量課金の柔軟な価格設定であるため、すぐに使い始めることができ、お客様のニーズと予算に応じて利用を拡大するということも可能です。Security Copilot はすでにどのお客様でも購入が可能であるものの、Microsoft Entra 管理センターでの利用は パブリック プレビュー 中となります。このブログで取り上げたほとんどのシナリオは現在パブリック プレビューで利用可能であり、弊社ではプレビュー期間中もこれらのシナリオをサポートするスキルについて、その品質と範囲を強化していく予定です。改めまして、すでに Microsoft Entra をお使いの皆様がこのプレビューに参加し、Microsoft Entra の Security Copilot がより一層皆様のお役に立てるようぜひフィードバックをお寄せください。
Security Copilot を用いることで、セキュリティおよび IT 部門が AI を活用し、さらにそのスキルセットを強化できるということが実証されています。これは、お客様の組織がビジネス上の目標を達成するために生成 AI を安全に活用できることを示す大きなマイルストーンであります。お客様ならびにパートナー様が目指している、あらゆる場所から、あらゆる ID で、あらゆるリソースに安全にアクセスするというゴールに向け、弊社も皆様と共に歩んでまいる所存です。
Security Copilot の導入方法についてはこちらの資料をご覧ください。また、貴社の営業担当者にもお問い合わせいただき、そのメリットについてご確認ください。
Sarah Scott
Principal Manager, Product Management
本記事は、2024 年 11 月 19 日に米国の Microsoft Entra (Azure AD) Blog で公開された Defeating Adversary-in-the-Middle phishing attacks の抄訳です。ご不明点等ございましたらサポート チームまでお問い合わせください。
本日は ID に関連した高度な攻撃への対処に関する連載記事の第 2 回目をお届けします。
多要素認証 (MFA) を採用しているユーザーの割合が 40% を超えた今、傾向として 2 つの状況が浮かび上がってきています。1 つ目は、攻撃者が MFA で保護されていないアカウントの侵害に成功している割合が高くなっていることです。より多くのライオンがより少ない獲物を追いかけているような状況のため、ライオンの餌食となる獲物はより多くのリスクに直面しています。過去 1 年間で、当社は毎秒 7,000 件のパスワード攻撃をブロックしており、これは前年比で 75% 増加しました。2 つ目は、MFA の普及により、攻撃者は MFA で保護されたアカウントを侵害する別の方法を見つけることを余儀なくされていることです。このため、トークン窃取 (前回のブログ のテーマ) や Adversary-in-the-Middle (AiTM) フィッシング攻撃 (今回のブログのテーマ) のような高度な攻撃が増加しており、このブログ シリーズではここに焦点を当てていきます。
ほとんどの攻撃には依然としてパスワードが関係しているため、何よりもまず、パスワード関連の攻撃の 99% 以上を阻止できる MFA をオンにしましょう。MFA を計画的に展開し強制していくことは、あらゆる ID セキュリティの計画において最も重要な部分です。
最初のブログ「トークン窃取によるサイバー攻撃の防止策」では、トークン窃取を伴う攻撃に対する 8 つの実践的な対策を紹介しました。トークン窃取とは異なり、AiTM フィッシング攻撃は、すでにユーザーに発行された有効なトークンを盗むわけではありません。それどころか、ユーザーを騙して正規の Web サイトにそっくりなページに誘導することで、ユーザーに認証情報を入力させ、MFA を実行するなど攻撃者に代わって認証を行わせます。これにより攻撃者は被害者の情報を使って本物の Web サイトにサインインすることで、攻撃者のデバイスに直接トークンが発行されるというものです。
このブログでは、AiTM フィッシング攻撃がどのように行われるのか、また AiTM フィッシング攻撃からユーザーを守るために何ができるのかについて説明していきます。
上のアニメーション GIF は、このシリーズの 最初のブログ から転載したもので、ユーザー エージェント (デバイスまたはアプリケーション)、ID プロバイダー (IdP)、およびリライング パーティー間の通常のトークンの流れを示しています。ユーザー エージェントがアクセスを要求すると、IdP は ID を証明するよう要求します。ユーザー エージェントが認証情報を提供すると、IdP はトークンを返し、ユーザー エージェントはトークンをリライング パーティーに提示してリソースにアクセスできるようになります。ユーザー エージェントは、例えるなら遊園地で乗り物に乗るためのチケットを購入する来場者といえますし、IdP は遊園地の乗り物のチケットを販売するチケット売り場、リライング パーティーは来場者からチケットを確認して受け取り、乗り物に乗れるようにする係員のようなものです。
MFA が導入される以前は、下の図が示すように、フィッシング攻撃は容易に実行が可能でした。攻撃者 (右側) は、被害者 (左側) に対し、悪意のある偽のリンクを含んだそれっぽい欺瞞の電子メールまたはインスタント メッセージを送信します。例えば、「アカウントの確認を行う必要がある」もしくは「アクセス権を失わないよう緊急で対応する必要がある」などのように被害者に今すぐ行動をとるよう急かすような内容です。被害者となるユーザーがリンクをクリックすると、ユーザー名とパスワードの入力を求める偽サイトが表示されます。ユーザーがこれに応じると、偽サイトは認証情報を盗み取って、エラー メッセージや悪意のあるページを表示します。
このようなフィッシング攻撃では、攻撃者は正規のサイトやその IdP とやりとりする必要がないことに着目ください。パスワードを盗んだら、そのあとに攻撃者は正規のサイトにアクセスし、盗んだパスワードを使用していつでも好きなときに不正なサインインを行うことが可能です。
そこで MFA の登場です。
従来の MFA の流れは、IdP がテキスト、電話、または認証アプリへのプッシュ通知を通じて直接ユーザーのデバイスまたはアプリケーションに通知した認証コードを、ユーザーが数分以内に入力する必要があるというものです。言い換えれば、MFA の通知は、フィッシング サイト経由でユーザーの認証情報を盗もうとする攻撃者を迂回して行われます。ユーザーがサインイン画面を操作していなくても MFA が試行される可能性はあるため、ユーザーがゴルフに出かけているにもかかわらず、要求した覚えのない MFA 通知 (テキストや電話) を受け取るという場合があり得ます。この場合、盗んだパスワードで「いつでも好きな時に」不正なサインインをするという従来の攻撃を試みる攻撃者は困ったことになります。ユーザーの応答がない場合、攻撃が失敗するからです。
MFA を迂回するためには、攻撃者は攻撃の流れを変える必要があります。MFA の一連の流れの間、被害者となるユーザーを継続的にその流れに巻き込み続けなければなりません。そのためには、被害者と IdP で行われる認証のやり取りのその中間に攻撃者が挟まるようにし、流れの一方では被害者と攻撃者が、もう一方では攻撃者と IdP が直接やり取りするようにします。このようにして、攻撃者は被害者を操り、ユーザー名、パスワード、および検証コードを提供させるのです。そうすれば認証の一連の流れが成立しますので、攻撃者は被害者のアカウントにアクセスできるようになります。
この双方向のやりとりの間、攻撃者は被害者に対してはサインイン画面になりすまし、IdP に対しては被害者になりすますということを行います。攻撃者は正規の IdP の UI をスクレイピングして被害者に提示し、被害者が IdP へ資格情報を提示したら攻撃者はそれをキャプチャして、正規の IdP に提示します。
フィッシング サイトに誘導された被害者は、偽のサインイン画面とやり取りします。攻撃者はそのやり取りをキャプチャし、正規の IdP に伝えます。正規の IdP が MFA チャレンジを発行すると、被害者は偽サイトに表示された偽の MFA 通知とやり取りしてそれに応答します。攻撃者は被害者の応答をキャプチャし、正規の IdP にそれを横流しして認証の一連の流れを完成させます。IdP は攻撃者に対して有効なトークンを発行し、攻撃者は被害者のアカウントへの侵入に成功します。
前回のブログでは、トークンの窃取を遊園地のチケット売り場でチケットを購入した後にスリに遭うことに例えました。AiTM フィッシングは、騙されて間違ったチケット売り場に行かされるようなものと言えるでしょう。
入場料が 10% 割引になるというチラシに惹かれたあなた (ユーザー エージェント) は、正規にみえるチケット売り場に行き、シーズン パス (トークン) の購入を依頼します。偽の係員 (攻撃者) はあなたの ID とクレジット カードを要求します。あなたがそれらを渡すと、係員はそれらを共犯者に渡し、共犯者は正規のチケット売り場 (IdP) に走り、あなたの ID とクレジット カードを使ってパスを購入しようとします。
クレジット カードでの取引を承認するにあたり、カード会社があなたに SMS で PIN コードを送ります。正規のチケット売り場はそれをカード会社に提示することが求められます。チケット売り場がコードを要求すると、共犯者が偽のチケット売り場に戻ってあなたから PIN コードを受け取り、正規の売り場に戻ってその PIN で購入を完了し、シーズン パスをポケットに入れます。このように走り回るような例だとかなり面倒に思うかもしれませんが、デジタルなやりとりではすべてが即座に行われますので、正規のユーザーがこれを見破るのはかなりの困難を伴うということを覚えておいてください。
共犯者があなたの ID とクレジット カードを持って戻ってくると、偽の係員はそれをあなたに返し、クレジット カードでの取引ができなかったと言うのです。残念ですが、あなたが支払ったシーズン パスをあなた以外のだれかが乗り物の係員 (リライング パーティー) に提示し、その人が乗り物を楽しむということになります。
適切なポリシーを構成して MFA を実施することで、攻撃者が認証情報を盗んだとしても、好きなときに何度も認証を完了するということはほぼ不可能になりますが、攻撃者はこの AiTM フィッシングの手法を使ってトークンを取得し、少なくともそのトークンの有効期限が切れるまでは何らかの危害を加えることができます。
MFA をバイパスする攻撃の詳細については、ブログ ポスト「君達の資格情報は全ていただいた!」を参照ください。
続いて、Microsoft がこれらの攻撃にどのように対応しているのか見ていきましょう。まず、最も確実な対策であるパスキーから始め、その他の多層防御のオプションについて説明します。
トークン保護の機能がトークン窃取攻撃を防ぐ決定的な方法であるのと同様に、新しい種類の資格情報を用いることでユーザーが AiTM フィッシング攻撃の餌食になることをほぼ防ぐことが可能です。フィッシングに耐性のある資格情報は、機密情報を公開しない暗号的な手法を使用しているため、攻撃者が認証プロセスを傍受したり複製したりすることができず、より安全です。Microsoft Entra ID がサポートする認証方法 のうち、パスキー、証明書ベース認証 (CBA)、および Windows Hello for Business はフィッシング耐性があります。最も強い保護を提供することで、米国のサイバーセキュリティ向上に関する大統領令 などの規制要件を満たしています。
最新の業界標準であるパスキーはすでに採用が広がっています。高いセキュリティ保証を提供するため、パスキーは 公開鍵暗号方式 を使用し、ユーザーとの直接のやり取りを必要とします。以下のような 3 つの重要な特性により、パスキーのフィッシングはほぼ不可能と言えます:
パスキーは、目に見えないインクで書かれた特別な ID カードのようなもので、意図された場所で、本人が提示した場合にのみ明らかにすることができます。この場合、この特別な ID カードは、遊園地の正規のチケット売り場で、生体認証または PIN を使ってロックを解除したときにのみ機能します。
Microsoft Entra ID のフィッシングに強い認証方法については、ビデオ シリーズ をご覧ください。
AiTM 攻撃は、フィッシングに耐性のある認証情報でサインインするユーザーに対しては効果がありませんが、フィッシングに耐性のある認証情報をすべてのユーザーに展開するには時間がかかります。OATH トークンや単純な承認による MFA を使用している場合でも、攻撃者が AiTM 攻撃を実行するのをはるかに困難にする追加の安全策を設定することが可能です。
MFA およびパスワードレス認証に Microsoft Authenticator アプリをご使用ください。Authenticator アプリは、MFA の要求が正当なものか、潜在的なセキュリティ脅威であるかをユーザーが判断できるように、追加の情報を提供します。
「No, it’s not me」の選択肢を押したユーザーは、Entra ID Protection にリスク シグナルとして情報が送信され、リスク ポリシーによりユーザーに即座に何らかの対応を求めることが可能です。さらに、当社の ID セキュリティ アルゴリズムが、異常な IP アドレスや既知の悪質な IP アドレスからのサインイン試行を検出した場合は、MFA 通知も抑制されます。
Microsoft Authenticator を使用したパスワードレス認証の設定方法については、ドキュメント を参照ください。
AiTM 攻撃はユーザーを騙して悪質な Web サイトに誘導することが必要なため、ユーザーがそういったサイトに誘導されないようにできるだけ多くのバリケードを設ける必要があります。例えば、ポリシーによる制限を設けることで、攻撃者は活動が制限され、攻撃者の移動範囲を大幅に制限するとともに攻撃者の活動を特定してブロックすることも容易になります。
Microsoft Entra ID のポリシーで、マネージドおよび準拠済みデバイスを使用しているユーザーにのみトークンを発行するという構成にしていた場合はどうなるでしょう。攻撃者がユーザーに代わってトークンを要求するには、まずユーザーが使用するマネージドおよび準拠済みデバイス上にフィッシング サイトを構成し、デバイスの電源は常にオンにした状態でエンドポイント保護も回避する必要があります。さらには発行されたトークンをポリシーで指定された更新期間内に使用しながら、トークンの自動失効につながるリスクのしきい値はトリガーしないようにするということも必要です。これらのハードルはかなり高いと言えるでしょう。
攻撃者が AiTM フィッシング攻撃を仕掛けるにあたり使用するマルウェアへの感染を防ぐには、ポリシーを構成してすべてのデバイスを準拠済みとすること、最新のエンドポイント保護を実行していること、そしてすべての Windows ユーザーがデバイスの管理者権限ではなく標準ユーザーとして実行されていることを強制ください。
管理対象デバイスを要求するポリシーの構成方法については、ドキュメント を参照ください。
条件付きアクセスを使用して、IP アドレス範囲を使用して準拠済みネットワークの境界を定義できます。ネットワーク境界を確立すると、ネットワーク境界外のデバイスへのトークンの発行や再発行ができなくなるため、攻撃者はその境界内で活動することを余儀なくされます。そのため、攻撃者は管理された準拠デバイス上でユーザー応答を不正利用する必要があるだけでなく、そのデバイスもネットワーク境界内で動作している必要があります。
Entra Internet Access と Entra Private access では、エンドポイントにエージェントをインストールし、アクセスを要求するユーザーが信頼できるネットワークから来たかどうかを確認するリアルタイムの準拠ネットワーク チェックが実施されます。もしネットワーク境界内にいなければ、条件付きアクセスは即座にリクエストを拒否します。
条件付きアクセスを使用して準拠ネットワークの境界を定義するための詳細な手順は、こちらの ドキュメント を参照ください。
また、条件付きアクセスを使用して準拠ネットワークのチェックを有効にするための詳細な手順は、こちらの ドキュメント を参照ください。
ユーザーがフィッシング リンクをクリックすると、Windows と Microsoft Edge に統合されたセキュリティ機能である Microsoft Defender SmartScreen が、ユーザーおよび業界から報告されているフィッシング サイトやマルウェア サイトの動的リストとその URL を照合します。一致するサイトが見つかった場合、そのサイトが安全でないと報告されていることをユーザーに警告し、そのサイトに進むには追加の手順を踏む必要が生じます。SmartScreen はまた、ダウンロードされたファイルやアプリケーションをスキャンし、悪意のあるファイルや望ましくない可能性のあるファイルをブロックします。
Microsoft Defender for Endpoint のネットワーク保護は、SmartScreen の適用範囲を拡大し、信頼性の低い Web サイトに接続しようとするすべての外向きの HTTP(S) トラフィックを OS レベルでブロックします。ネットワーク保護を有効にするには、Intune、PowerShell、グループ ポリシー、または Microsoft Configuration Manager を使用いただけます。また、Microsoft Defender for Office 365 ポータルのテナント許可/ブロック リストを構成して、ユーザーがアクセスできるサイトを制限することもできます。
Microsoft Defender を使用して URL をブロックする方法については、こちらの ドキュメント を参照ください。
また、Microsoft Defender for Endpoint のネットワーク保護を有効にする方法については、こちらの ドキュメント を参照ください。
万が一、上記すべての対策が失敗した場合も、異常検知の機能で攻撃のブロックと修復が可能です。
ユーザーがセッションを開始したり、アプリケーションにアクセスしようとすると、Microsoft Entra ID Protection はユーザーとセッションのリスク要因に通常と異なる (異常な) 要素がないかを調べます。以下は、リスク レベルを高める異常の例です:
条件付きアクセスポリシーを構成すると、リスクに基づく対応が可能です。ユーザーまたはセッションのリスクレベルが上昇したときに、自動的に実行される修復ステップを定義できます。
リスク検出の詳細については、こちらの ドキュメント を参照ください。
例えば、リスクが高まった場合に MFA による 再認証を要求する ような条件付きアクセス ポリシーを構成することができます。この場合、正当なユーザーはその場にいないことが多く、攻撃者とやり取りして再認証の手助けをしてしまうということが起きないので、AiTM フィッシング攻撃を阻止できます。条件付きアクセスは通常、トークンの更新時にリスク レベルをチェックするため、攻撃者がなんとか正規のトークンを手に入れたとしても、攻撃を受けるのはそのトークンの有効期間内に限られます。
継続的アクセス評価 (CAE) は、Teams、Exchange Online、SharePoint Online などのアプリケーションやサービスでネイティブにサポートされており、これらのアプリケーション用のアクセス トークンをリアルタイムで無効にできます。この発動条件には、ユーザーのネットワークの場所の変更も含まれます。
リスク ベースの条件付きアクセス ポリシーを作成する詳細な手順については、こちらの ドキュメント を参照ください。
CAE を使用した厳密なロケーション ポリシーを適用する詳細な手順については、こちらの ドキュメント も参照ください。
攻撃者が資格情報とセッション Cookie の傍受に成功した場合、攻撃者はそれらを使用してビジネス E メール詐欺 (BEC) や認証情報の収集などの他の攻撃を開始することが一般的です。AiTM フィッシング攻撃を示す複数の Microsoft 365 Defender シグナルが検知されると、Defender XDR は侵害されたユーザー アカウントを自動的に Entra およびオンプレミスの Active Directory で無効にし、セッション Cookie も無効化します。また、セッション トラフィックを監視し、攻撃者が機密データをネットワーク外に持ち出すことを防ぐようポリシーを適用します。
Defender XDR を使用して AiTM フィッシング攻撃を阻止する詳細な手順については、ブログ記事 Automatically disrupt adversary-in-the-middle (AiTM) attacks with XDR をご覧ください。
AiTM フィッシング攻撃の可能性を示すイベントのアラートを受信した場合、Microsoft Sentinel ポータルまたは他の SIEM で調査することが可能です。Microsoft Sentinel は特定のインシデントについて、その重大度、発生時期、関与したエンティティの数、トリガーとなったイベントなどの重要な詳細を提供します。その後、調査マップを表示して、潜在的なセキュリティ脅威の範囲と根本原因を確認できます。
Sentinel を使用してインシデントを検出および調査するための詳細な手順については、ブログ記事 Identifying Adversary-in-the-Middle (AiTM) Phishing Attacks through 3rd-Party Network Detection を参照ください。
当社の検出データによると、AiTM フィッシング攻撃は過去 1 年間で 146 % 増加しています。パスキーはこれらの攻撃に対して最も効果的なソリューションであるため、今すぐパスキーの導入を計画し、実行に移すことを強くお勧めします。それまでの間に、このブログで紹介しているその他の多層防御の推奨事項を取り入れ、ユーザーを可能な限り安全に保つこともご検討ください。
安全にお過ごしください!
Alex Weinert
この方法では、Microsoft Entra 参加済みデバイスおよび Microsoft Entra ハイブリッド参加済みデバイスのデバイス オブジェクトの所有者を変更することができます。
なお、Microsoft Entra registered デバイスの所有者は変更できませんのでご注意ください。
対象デバイスが Microsoft Intune に登録されているか否かで手順が変わりますので、それぞれ紹介します。
Microsoft Intune に登録している場合、以下の手順で Microsoft Intune デバイスのプライマリ ユーザーを変更することで Microsoft Entra ID 上に登録されたデバイス オブジェクトの所有者を変更することができます。
Microsoft Intune 管理センター (intune.microsoft.com) に Intune 管理者でサインインします。
[デバイス] - [すべてのデバイス] へ移動します。
対象のデバイスを選択します。
[管理] から [プロパティ] を押下します。
[プライマリ ユーザーの変更] を押下して、新たにそのデバイスの所有者にする Entra ユーザーに変更します。
[保存] を押下します。
Microsoft Intune に登録していない場合、GUI から簡単に Microsoft Entra ID 上に登録されたデバイス オブジェクトの所有者を変更する方法はありません。
この場合、Microsoft Graph PowerShell を利用した次の手順で変更することができます。
PowerShell を管理者権限で起動します。
以下のコマンドを実行し、Microsoft Graph PowerShell モジュールを作業端末にインストールします。
Install-Module Microsoft.Graph -Force |
以下のコマンドを実行し、表示されるユーザー認証画面で、テナントのグローバル管理者のユーザーで認証を行います。([要求されているアクセス許可] という画面が表示された場合は、[承諾] を押下します)
※もしグローバル管理者を利用しない場合は、実行するユーザーに二つのロール (クラウド アプリケーション管理者と Intune 管理者) が付与されていれば実行可能です。
Connect-MgGraph -Scopes "Directory.AccessAsUser.All" |
以下のコマンドを順番に実行して、対象のデバイス オブジェクトから所有者情報を変更します。
$userId="新たに所有者にしたいユーザーの ObjectId を指定" |
※実行時の参考画像
作業が終わりましたら以下のコマンドで PowerShell セッションを切断します。
Disconnect-MgGraph |
本サンプル コードは、あくまでも説明のためのサンプルとして提供されるものであり、製品の実運用環境で使用されることを前提に提供されるものではありません。
本サンプル コードおよびそれに関連するあらゆる情報は、「現状のまま」で提供されるものであり、商品性や特定の目的への適合性に関する黙示の保証も含め、明示・黙示を問わずいかなる保証も付されるものではありません。
マイクロソフトは、お客様に対し、本サンプル コードを使用および改変するための非排他的かつ無償の権利ならびに本サンプル コードをオブジェクト コードの形式で複製および頒布するための非排他的かつ無償の権利を許諾します。
但し、お客様は以下の 3 点に同意するものとします。
(1) 本サンプル コードが組み込まれたお客様のソフトウェア製品のマーケティングのためにマイクロソフトの会社名、ロゴまたは商標を用いないこと
(2) 本サンプル コードが組み込まれたお客様のソフトウェア製品に有効な著作権表示をすること
(3) 本サンプル コードの使用または頒布から生じるあらゆる損害(弁護士費用を含む)に関する請求または訴訟について、マイクロソフトおよびマイクロソフトの取引業者に対し補償し、損害を与えないこと
本記事では Microsoft Entra ID 上に登録されたデバイス オブジェクトの所有者を変更する方法を紹介しました。製品動作に関する正式な見解や回答については、お客様環境などを十分に把握したうえでサポート部門より提供しますので、ぜひ弊社サポート サービスをご利用ください。
]]>BitLocker 回復キーは従来、オンプレミスの AD サーバー上やファイル サーバー上、もしくは紙に印刷して保存されておりました。
Microsoft Entra ID にデバイス登録もしくは参加した Windows デバイスにおいては、従来の方法に加え、Microsoft Entra ID 上のデバイス オブジェクトに紐づける形でクラウド上に BitLocker 回復キーを保存するオプションが用意されております。
本ブログでご案内する方法は、この Microsoft Entra ID 上のデバイス オブジェクトに紐づける形でクラウド上に保存された BitLocker 回復キーをテナント単位で一括取得するというものになります。
現状、Microsoft Entra ID に登録されている BitLocker 回復キーは GUI から一括で取得することができません。そこで Microsoft Graph PowerShell モジュールのコマンドを使用して Microsoft Entra ID に登録されているデバイス一覧および BitLocker 回復キーを含む場合は回復キーも含めて CSV に出力する方法のサンプルを紹介します。
PowerShell を管理者権限で起動します。
以下のコマンドを実行し、Microsoft Graph PowerShell モジュールをインストールします。(既にモジュールがインストールされている場合はスキップしてください)
Install-Module Microsoft.Graph -Force |
以下のコマンドを実行し、グローバル管理者でサインインします。([要求されているアクセス許可] という画面が表示された場合は、[承諾] を押下します)
※もしグローバル管理者を利用しない場合は、実行するユーザーに二つのロール (クラウド アプリケーション管理者とクラウド デバイス管理者) が付与されていれば実行可能です。
Connect-MgGraph -Scopes "Device.Read.All,BitlockerKey.Read.All" |
以下のコマンドを順に実行して、Bitlocker 回復キーも含むデバイス オブジェクト一覧を CSV としてデスクトップに出力します。(KeyId、KeyCreatedDateTime、Key が出力されていないデバイスは BitLocker 回復キーが Microsoft Entra ID に保存されていないデバイスです。)
$outfile = "$env:USERPROFILE\Desktop\DevicelistIncludingKey.csv" |
作業完了後、以下のコマンドでセッションを切断し作業を終了します。
Disconnect-MgGraph |
下図の赤枠が BitLocker 関連情報で、”Key” の項目が BitLoker 回復キーです。
本サンプル コードは、あくまでも説明のためのサンプルとして提供されるものであり、製品の実運用環境で使用されることを前提に提供されるものではありません。
本サンプル コードおよびそれに関連するあらゆる情報は、「現状のまま」で提供されるものであり、商品性や特定の目的への適合性に関する黙示の保証も含め、明示・黙示を問わずいかなる保証も付されるものではありません。
マイクロソフトは、お客様に対し、本サンプル コードを使用および改変するための非排他的かつ無償の権利ならびに本サンプル コードをオブジェクト コードの形式で複製および頒布するための非排他的かつ無償の権利を許諾します。
但し、お客様は以下の 3 点に同意するものとします。
(1) 本サンプル コードが組み込まれたお客様のソフトウェア製品のマーケティングのためにマイクロソフトの会社名、ロゴまたは商標を用いないこと
(2) 本サンプル コードが組み込まれたお客様のソフトウェア製品に有効な著作権表示をすること
(3) 本サンプル コードの使用または頒布から生じるあらゆる損害(弁護士費用を含む)に関する請求または訴訟について、マイクロソフトおよびマイクロソフトの取引業者に対し補償し、損害を与えないこと
本記事では Microsoft Entra ID 上に保存された BitLocker 回復キーの一括取得方法を紹介しました。製品動作に関する正式な見解や回答については、お客様環境などを十分に把握したうえでサポート部門より提供しますので、ぜひ弊社サポート サービスをご利用ください。
]]>本記事は、2024 年 12 月 5 日に米国の Microsoft Entra (Azure AD) Blog で公開された Action required: Azure AD Graph API retirement の抄訳です。ご不明点等ございましたらサポート チームまでお問い合わせください。
Azure AD Graph API サービスの廃止 は 2024 年 9 月に開始され、新規および既存のアプリケーションの両方に影響を与えます。現在、Azure AD Graph の廃止の第 1 フェーズを完了しており、新規のアプリケーションは、利用を延長するよう構成されていない限り、Azure AD Graph API を使用することはできません。Microsoft Graph は、Azure AD Graph API に代わるものであり、Azure AD Graph API を利用している場合は直ちに Microsoft Graph に移行し、Azure AD Graph API を使用する今後の開発を行わないようにすることを強く推奨します。
今回の廃止については繰り返しお伝えしてきましたが、再確認として、主要なマイルストーンを以下の通り再掲します:
フェーズ開始日 | 既存のアプリへの影響 | 新規のアプリへの影響 |
---|---|---|
2024 年 9 月 1 日 | なし | すべての新しいアプリでは Microsoft Graph を使用する必要があります。 blockAzureAdGraphAccess を false に設定して 2025 年 6 月 30 日まで Azure AD Graph へのアクセスを延長して許可するようにアプリが構成 されていない限り、新しいアプリが Azure AD Graph API を使おうとするとブロックされます。 |
2025 年 2 月 1 日 | アプリケーションは、blockAzureAdGraphAccess を false に設定して Azure AD Graph アクセスへのアクセスを延長して許可するように構成 されていない限り、Azure AD Graph API にリクエストを行うことができません。 この影響に備えるには、本記事の手順に沿って対応を実施ください。 | 同上 |
2025 年 7 月 1 日 | Azure AD Graph が完全に廃止されます。Azure AD Graph API へのリクエストは機能しません。 | 同上 |
影響を受けないようにするには、テナントが Azure AD Graph の廃止に対応できるよう、今すぐ 対策を講じる ことが重要です。以下の 2 つのステップ に従って、Azure AD Graph API を使用しているテナント内のアプリケーションを特定し、対策を実施ください。
Azure AD Graph の廃止に備える最初のステップは、Azure AD Graph API を使用しているアプリケーションを特定することです。弊社では、お客様のテナントで Azure AD Graph API をアクティブに使用しているアプリケーションとサービス プリンシパルを特定できる Microsoft Entra の推奨事項 の機能を 2 つ提供しています。これらの推奨事項は次のとおりです:
これらの推奨事項に示されている情報は、お客様のテナントにおける Azure AD Graph API の実際の使用状況に基づいており、Azure AD Graph の廃止に際し注意が必要なアプリを見つけるのに最適なリソースです。推奨事項にはアプリケーションが一覧表示され、アプリケーションが実行している操作に関する情報が提供されます。これにより、移行の必要がある Azure AD Graph API の使用状況を明確にすることができます。
これらの推奨事項にアクセスするには、Microsoft Entra 管理センターで、[ID] > [概要] > [推奨設定] を参照ください。
補足情報: 影響を受けるアプリケーションをスクリプトを使用して確認する
Microsoft Entra の推奨事項から情報をエクスポートしたり、定期的なレポートを自動化したりする場合は、Microsoft Entra Recommendations API または Microsoft Graph PowerShell を使用いただけます。
Import-Module Microsoft.Graph.Beta.Identity.DirectoryManagement |
Microsoft Entra の 2 つの推奨事項によりアプリが特定できたら、これら Azure AD Graph API を使用する各アプリケーションに対して対応が必要になります。「アプリケーションの移行」の推奨事項と「サービス プリンシパルの移行」の推奨事項の両方で示されたアプリケーションに対し、Azure AD Graph API ではなく Microsoft Graph API を使用するように開発者がアプリを更新する必要があります。2025 年 6 月 30 日までは Azure AD Graph を使用できるように、利用延長 を設定することができます。
お客様のテナントで作成されたアプリケーションと、ベンダーが提供するアプリケーションのサービス プリンシパルとでは、次のステップと必要なアクションが異なります。
「廃止中の Azure AD Graph API から Microsoft Graph にアプリケーションを移行する」に示されている影響を受けるリソースは、お客様のテナントで作成されたアプリケーションです。これらのそれぞれについて、次のことを行う必要があります:
ドキュメント:
「廃止中の Azure AD Graph API から Microsoft Graph にサービス プリンシパルを移行する」に示されている影響を受けるリソースは、サービス プリンシパル (ソフトウェア ベンダーが提供しテナントで使用されているアプリケーション) です。
これらのサービス プリンシパルのそれぞれについて、アプリケーションを提供したベンダーに問い合わせ、Azure AD Graph API への呼び出しを Microsoft Graph API に置き換えたアップデートがすでに利用可能かどうかを確認ください。
テナントで Azure AD Graph を使用しているサービス プリンシパルの一部は、Microsoft から提供されている可能性があります。これらについては、Azure AD Graph API の代わりに Microsoft Graph を使用する、以下のようなアップデートが利用可能です:
Microsoft Office、Microsoft Visual Studio Legacy、Microsoft Intune など、一部の Microsoft アプリケーションでは、Azure AD Graph API を使用しないようにするアップデートがまだ提供されていません。これらのアプリケーションについては、今後代替のバージョンが利用可能になったときに、Azure AD Graph API 廃止に関するブログの更新情報としてお知らせする予定です。これらのアプリケーションには、Azure AD Graph の利用延長が施されますので、アプリケーションをアップデートするために十分な猶予が与えられる予定です。
アプリの Microsoft Graph への移行が完了していない場合、この廃止を延長することができます。アプリの authenticationBehaviors 構成で blockAzureADGraphAccess 属性を false に設定すると、アプリは 2025 年 6 月 30 日まで Azure AD Graph API を使用できるようになります。詳細なドキュメントは こちら をご覧ください。
この設定を false に設定しない限り、新しいアプリケーションが Azure AD Graph API にアクセスしようとすると 403 エラー が発生します。2024 年に Microsoft Graph への移行が完了しないすべての既存アプリケーションについては、今すぐこの設定を計画ください。
詳細情報: 2025 年 6 月 30 日まで Azure AD Graph の拡張アクセスを許可する - Microsoft Graph|Microsoft Learn
Microsoft Graph は、Microsoft が提供する純正の API です。Microsoft Entra サービスや Microsoft Teams、Microsoft Intune などの Microsoft 365 サービスにアクセスするための単一の統一エンドポイントを提供します。すべての新機能は、Microsoft Graph を通じてのみ利用可能になります。また、Microsoft Graph は Azure AD Graph よりも安全性と耐障害性に優れています。
Microsoft Graph は、Azure AD Graph で利用可能だったすべての機能と、ID 保護や認証方法などの新しい API を備えています。Microsoft Graph のクライアント ライブラリは、再試行処理、安全なリダイレクト、透過的な認証、ペイロード圧縮などの機能をビルトインでサポートしています。
Azure AD Graph から Microsoft Graph への移行は、以下のツールやドキュメントを利用することで簡単に行うことができます:
また、必要に応じて、アプリケーションのアクセスを 2025 年 6 月 30 日まで延長することができます: 2025 年 6 月 30 日まで Azure AD Graph の拡張アクセスを許可する - Microsoft Graph|Microsoft Learn
Kristopher Bash
Product Manager, Microsoft Graph
LinkedIn
本記事は、2024 年 12 月 6 日に米国の Microsoft Entra Blog で公開された What’s new in Microsoft Entra - November 2024 を意訳したものになります。ご不明点等ございましたらサポート チームまでお問い合わせください。
ID セキュリティの状況は、かつてないほどのスピードで変化しています。世界的な出来事や急速に進化する AI によりサイバーセキュリティ環境が変化する中、セキュリティの維持はこれまで以上に重要になっています。サイバー攻撃の規模と影響の増大に対処するために、Microsoft は Secure Future Initiative (SFI) というイニシアティブを開始し、Microsoft のもつ力を最大限に活用して組織と製品全体のサイバーセキュリティを強化する取り組みを進めています。この取り組みは、社内の知見と、お客様、政府、パートナーからの貴重なフィードバックの両方を反映したものであり、セキュリティの未来を形作るために最も価値のある部分に焦点を当てて取り組んでいます。
先月の Microsoft Ignite では、進化する脅威の状況を先取りし、AI 時代における安全なアクセスを確保するため、次のようないくつかの重要な更新情報を発表しました。
これらの更新の詳細については、Microsoft コミュニティ ハブのブログ「Ignite: Microsoft Entra の AI と SASE のイノベーション」を参照ください。
そして本日は、2024 年 10 月から 11 月にかけての Microsoft Entra 全体でのセキュリティ改善とイノベーションについて、製品ごとに整理してお伝えいたします。
詳細については、Microsoft Entra の新機能 の動画で製品更新プログラムの概要をご覧いただくとともに、Microsoft Entra 管理センターの 新機能 ブレードでも詳細な情報をご覧いただけます。
新機能
変更のお知らせ
[お客様によっては対応が必要]
Microsoft の Secure Future Initiative に則り、セキュリティ既定値群が有効になっている場合に多要素認証 (MFA) の登録を 14 日間スキップできる選択肢を削除する 予定です。すべてのユーザーは、セキュリティ既定値群が有効になった後、最初のログイン時に MFA を登録する必要があります。この変更は、2024 年 12 月 2 日以降に新しく作成されたテナントに影響し、2025 年 1 月からは既存のテナントにロールアウトされます。
[お客様によっては対応が必要]
2025 年 1 月中旬以降、Microsoft Authenticator でのパスキーの GA (一般提供開始) 後、パスキー (FIDO2) の認証方法ポリシーがキー制限なしで有効になっているお客様は、FIDO2 セキュリティ キーに加えて Microsoft Authenticator のパスキーも自動的に有効になります。セキュリティ情報のページでは、ユーザーは認証方法として Microsoft Authenticator にパスキーを追加するという選択肢が表示されるようになります。さらに、条件付きアクセスの認証強度ポリシーでパスキーの認証が適用される場合、パスキーを持たないユーザーは、Microsoft Authenticator にパスキーを登録するように求められます。この変更を有効にしたくないお客様は、パスキー (FIDO2) の認証方法ポリシーでキー制限を有効に変更ください。詳細については、こちら をクリックしてください。
[お客様によっては対応が必要]
2024 年 10 月より、Microsoft はより多くの API で段階的にアクセス トークンを暗号化しています。この変更により、Microsoft が所有する API のアクセス トークンの形式が変更されます。
必要なアクション: クライアント アプリケーションは、アクセス トークンを解読不可能な文字列として扱う必要があり、読み取り、検証、または解析を試みないでください。アクセス トークンを解析して検証する必要があるのは、アクセス トークンの意図された受信者である Web API のみであり、お客様のクライアント アプリケーションではありません。
その理由: アプリケーションが特定のトークン形式を前提としている場合 (GUID ではなく ‘aud’ クレームに URI を期待するなど)、トークン形式が変更されると、その前提が崩れ機能上の問題が発生する可能性があります。
お客様のクライアント アプリケーションが現在アクセス トークンを解析している場合は、Microsoft ID プラットフォームの ドキュメント で説明されているベスト プラクティスに沿ってコードを確認および更新ください。
[お客様によっては対応が必要]
セキュリティに対する継続的な取り組みとして、2025 年 1 月 15 日以降に Microsoft Graph 用に発行されるトークンに若干の変更を加えます。クライアント アプリケーションが不必要にアクセス トークンを解析し、特定の形式の aud クレーム を期待している場合、アプリケーションに影響が生じる可能性があります。
ドキュメント で説明されているように、アクセス トークンを解析および検証する必要があるのはリソース API のみです。クライアント アプリケーションは、この変更または将来の変更によって影響受けないよう、アクセス トークンを解読不可能な文字列として扱うよう対応ください。
[お客様によっては対応が必要]
適切な権限を持つユーザーのみが機密性の高いセキュリティ アドバイザリを受け取れるように、2025 年 2 月 28 日以降、Azure Service Health の ロールベースのアクセス制御 (RBAC) に変更 を加える予定です。この変更を行うにあたり、弊社では以下の対応を行います。
以下に示すいずれかの方法でセキュリティ アドバイザリを受け取っている場合に本変更の影響を受ける可能性があります。
Azure ポータルを使用している場合:
Resource Health API を使用してイベントにアクセスしている場合:
Azure Resource Graph を使用している場合:
Microsoft Learn にアクセスして、これらの変更の詳細を確認し、Azure のセキュリティ問題に関する最新情報を入手ください。
[お客様によっては対応が必要]
11 月 14 日に、ハードウェア OATH トークンのパブリック プレビューに関し、新しいバージョンをリリースしました。この更新では、エンド ユーザーによる自己割り当て、アクティブ化、および委任された管理者のアクセスがサポートされています。詳細については、公開ドキュメント を参照ください。
この更新を利用するには、MS Graph API を使用してトークンを作成します。新しいユーザー体験は、廃止されるまで旧バージョンと並行して実行され、廃止は Microsoft Entra の新機能 と M365 メッセージ センターの投稿を通じて発表されます。
今すぐ移行するには、古いトークンを削除し、MS Graph を使用して新しいプレビューでトークンを再作成します。一般提供された際には、MS Graph API を使用して、ユーザーに影響を与えずユーザーごとにトークンを移行できるようになります。
[お客様によっては対応が必要]
2024 年 12 月から、インドおよびその他の国のユーザーは、WhatsApp を介して MFA テキスト メッセージを受信できるようになります。認証方法として MFA のテキスト メッセージの受信が有効になっており、すでに電話に WhatsApp がインストールされているユーザーのみがこのユーザー体験を利用できます。WhatsApp を使用しているユーザーに到達できない場合、またはインターネットに接続していない場合は、すぐに通常の SMS の通信経路にフォールバックします。さらに、WhatsApp 経由で初めて OTP を受信するユーザーには、SMS テキスト メッセージで動作の変更が通知されます。
Microsoft Entra の従業員向け (Workforce) テナントにて、現在テキスト メッセージの認証方法を利用している場合は、この今後の変更についてヘルプデスクに事前に通知することをお勧めします。さらに、ユーザーが WhatsApp 経由で MFA テキスト メッセージを受信しないようにしたい場合は、組織の認証方法としてテキスト メッセージを無効にすることが可能です。なお、Microsoft Authenticator やパスキーなど、より最新で安全な方法の使用に移行し、電話回線やメッセージング アプリの方法は極力控えることを強くお勧めします。この更新は、お客様側での変更なく既定で有効になります。詳細については、電話認証のドキュメント をご覧ください。
この変更の展開は自動的に行われ、管理者の操作は必要ありません。この変更についてユーザーに通知し、必要に応じて関連ドキュメントを更新することをおすすめします。
[お客様によっては対応が必要]
Azure AD Graph API サービスの廃止 は 2024 年 9 月に開始され、最終的には新しいアプリケーションと既存のアプリケーションの両方に影響します。現在、Azure AD Graph の提供終了の第 1 フェーズの展開が完了しており、新しいアプリケーションは利用延長の構成を行っていない限り、Azure AD Graph API を使用できません。Microsoft Graph は Azure AD Graph API に代わるものであり、今すぐに Azure AD Graph API から Microsoft Graph に移行し、Azure AD Graph API を使用した開発は止めることを強くお勧めします。
Azure AD Graph API サービスの段階的な廃止のタイムライン
フェーズの開始日 | 既存のアプリへの影響 | 新しいアプリへの影響 |
2024 年 9 月 1 日 | なし | blockAzureAdGraphAccess を false に設定し、Azure AD Graph へのアクセスを延長するようにアプリが構成されていない限り、新しいアプリは Azure AD Graph API の使用をブロックされます。新しいアプリでは Microsoft Graph を使用する必要があります。 |
2025 年 2 月 1 日 | blockAzureAdGraphAccess を false に設定し、Azure AD Graph へのアクセスを延長するようにアプリが構成されていない限り、アプリは Azure AD Graph API を使用できません。 | |
2025 年 7 月 1 日 | Azure AD Graph は完全に廃止されます。Azure AD Graph API への要求は機能しません。 |
サービスの中断を避けるため、弊社のガイダンス に従いアプリケーションを Microsoft Graph API に移行ください。
アプリの Azure AD Graph アクセスを 2025 年 7 月まで延長する必要がある場合
Microsoft Graph へのアプリの移行が完全に完了していない場合は、この廃止を延長できます。アプリケーションの authenticationBehaviors の構成で blockAzureADGraphAccess 属性を false に設定すると、アプリケーションは 2025 年 6 月 30 日まで Azure AD Graph API を使用できるようになります。その他のドキュメントについては、こちら を参照ください。
この設定が false に設定されていない限り、新しいアプリケーションが Azure AD Graph API にアクセスしようとすると 403 エラー が発生します。2024 年に Microsoft Graph への移行が完了しないすべての既存のアプリケーションについては、今すぐこの構成を設定することを計画ください。
Azure AD Graph API を使用しているテナント内のアプリケーションが不明な場合
テナントで Azure AD Graph API を現在も使用しているアプリケーションとサービス プリンシパルに関する情報を示す 2 つの Entra 推奨事項の機能 を提供しています。これらの新しい推奨事項を利用することで、影響を受けるアプリケーションとサービス プリンシパルを特定し、Microsoft Graph への移行をお進めください。
参照:
[お客様によっては対応が必要]
2024 年 3 月 30 日の時点で、従来の Azure AD PowerShell、Azure AD PowerShell Preview、MS Online モジュールは 非推奨 になりました。これらのモジュールは 2025 年 3 月 30 日まで引き続き機能しますが、その後は廃止され、機能を停止します。Microsoft Graph PowerShell SDK はこれらのモジュールの移行先であり、できるだけ早くスクリプトを Microsoft Graph PowerShell SDK に移行する必要があります。
テナントでの Azure AD PowerShell の使用状況を特定するには、Entra の推奨事項 である「廃止中の Azure AD Graph API から Microsoft Graph にサービス プリンシパルを移行する」を使用いただけます。この推奨事項では、AzureAD PowerShell など、テナントで Azure AD Graph API を使用しているベンダー アプリケーションが表示されます。Microsoft Entra サインイン ログ も、テナント内の MS Online と Azure AD PowerShell から行われたログインを特定するために使用できます。Azure Active Directory PowerShell というアプリケーション名を持つサインイン イベント (対話型および非対話型) があれば、それは MS Online クライアントや Azure AD PowerShell クライアントによって行われたものだと判断できます。
弊社では、Microsoft Entra を管理するための PowerShell に新規および将来の大幅な投資を行っており、その具体的な例として Microsoft Entra PowerShell モジュールのパブリック プレビューが挙げられます。この新しいモジュールは、Microsoft Graph PowerShell SDK をベースに構築されており、実際の利用シナリオに重点を置いたコマンドレットを提供します。Microsoft Graph PowerShell SDK のすべてのコマンドレットと完全に相互運用できるため、よりシンプルでドキュメントも整備されたコマンドを用いて複雑な操作を実行できます。このモジュールには、非推奨の AzureAD モジュールからの移行を簡略化するための下位互換性オプションも用意されています。
[お客様による対応は必要なし]
2024 年 12 月 11 日以降、M365 製品へのサインアップによって作成されたテナントには、”Microsoft Entra ID Free” というラベルの付いた新しいサブスクリプションが含まれます。このロールアウトは、2025 年 2 月 7 日までにすべての製品のサインアップ フローをカバーするように拡大されます。
新しく作成されたテナントの場合、このサブスクリプションは Entra ポータルおよび Azure ポータルの [All Billing Subscriptions] の配下、または M365 管理センターの [Subscriptions] ページにある課金サブスクリプションの一覧に表示されます。これはテナント レベルのサブスクリプションであり、関連する課金はなく、お客様の対応も必要ありません。
将来的には、このサブスクリプションは、同じ請求先アカウントで作成されたすべての新しいテナントを追跡するために使用され、お客様はすべての新しいテナントの棚卸が可能となるとともに、お客様がテナントの管理アクセス権を失った場合でもテナントの所有権を実証できるようになります。お客様がどのようなテナントを保持しているかすべて特定したい場合、詳細については https://aka.ms/TenantDiscoveryFAQ をご覧ください。
[お客様による対応は必要なし]
以前にお知らせ したように、My Access に新しい Microsoft Entra ID ガバナンスの機能が追加され、推奨されるアクセス パッケージのリスト機能が導入されました。これにより、ユーザーは長いリストをスクロールすることなく、最も関連性の高いアクセス パッケージ (類似したユーザーが使用しているアクセス パッケージと以前の要求を参考に算出) をすばやく表示できます。これは、オプトインのプレビューとして 12 月末までにすべての Microsoft Entra ID Governance のお客様に展開され、変更を強調するための製品内メッセージも併せて表示されます。必要に応じて、関連するドキュメントに更新された画面デザインを反映することをご検討ください。
新機能
変更のお知らせ
[お客様によっては対応が必要]
Microsoft Identity Manager (MIM) 2016 で導入された MIM ハイブリッド レポート機能 は非推奨とされています。この機能は、MIM ハイブリッド レポート エージェントが MIM サービスから Microsoft Entra にイベント ログを送信することで、セルフサービス パスワード リセット (SSPR) を利用したパスワードリセットとセルフサービス グループ管理 (SSGM) のレポートが Microsoft Entra 監査ログで確認可能となるものでした。この機能は、Azure Arc エージェントを使用してこれらのイベント ログを Azure Monitor に送信する方法に置き換えられ、結果としてより柔軟なレポートが可能になります。2025 年 11 月になると、MIM ハイブリッド レポート エージェントによって使用されるクラウド エンドポイントは使用できなくなるため、お客様は Azure Monitor または同様のものに移行ください。その他の MIM および Entra ID Connect Health 機能は、この非推奨の影響を受けません。
新機能
変更のお知らせ
[お客様による対応は必要なし]
2025 年 1 月より、Entra External ID の属性収集のページに対する重要な更新が生じます。ユーザーがサインアップすると、既定の属性とカスタム属性の両方の各入力フィールドの横にラベルが常時表示されるようになります。この機能強化には、次の 2 つの目的があります。
新機能
どうぞよろしくお願いいたします
Shobhit Sahay
]]>本記事は、2024 年 11 月 19 日に米国の Microsoft Entra Blog で公開された Ignite: AI and SASE innovations in Microsoft Entra を意訳したものになります。ご不明点等ございましたらサポート チームまでお問い合わせください。
Microsoft Ignite に際しセキュリティの専門家がシカゴに集まり、リモートでも世界中から何千もの人がイベントを視聴するなか、ID に関連した様々な脅威から組織を守る立場が如何に難しいものであるかということを思い知らされます。サイバー空間の犯罪者は、攻撃の規模と巧妙さを増し続けています。実際、Microsoft Entra は現在、毎秒 7,000 件以上のパスワード攻撃をブロックしており、これは 1 年前から 75% 以上も増加しています。
このように脅威が増大する中でも、Microsoft は Microsoft Security Copilot により業界をリードする「責任ある AI」など、高度な多層防御の機能を提供することに引き続き取り組んでいます。本日は、ゼロ トラスト戦略の基盤である ID とネットワーク アクセスに関し、セキュリティ保護に役立つ Microsoft Entra の最新ニュースをお届けします。
まず、Microsoft Entra の Security Copilot のパブリック プレビューを拡大します。この新しい機能では、Security Copilot が Microsoft Entra 管理センターに直接組み込まれるため、管理センターで Copilot が提供する ID のスキルに直接かつ簡単にアクセスできます。
また、Security Copilot は、皆様が日々の日常的な作業や複雑な作業を実施するときに、Microsoft Entra 管理センターで推奨事項を作成し、分析情報を提供してくれます。これにより以下のような支援が得られます:
さらに、Microsoft Entra でアプリケーションやワークロード ID を管理しているお客様向けには、12 月に、リスクの特定、理解、修復に役立つ新しいスキル セットが提供されます。例えば、Security Copilot に “攻撃に使用されている可能性のあるアプリや侵害された可能性のあるアプリはどれ?” や “使用されていないアプリを表示して” というプロンプトを送った後、さらに “これらを削除するにはどうすればよい?” というプロンプトを提示することも可能です。
自然言語処理やデータの関連付け、コンテキストに基づく分析情報などの生成 AI の機能により、ID とアクセス管理のワークフローがより簡単かつ効率的になります。最新のユーザー テスト では、Microsoft Entra で Security Copilot を使用している管理者は、サインインのトラブルシューティング タスクを 46% も少ない時間で完了し、さらに 47% 高い精度で完了していることもわかりました。
詳細については、Microsoft Security Copilot is now embedded within the Microsoft Entra admin center の記事もご覧ください。
ネットワーク セキュリティに対して ID 中心のアプローチを取ることで、サイバー空間におけるリスクを軽減し、高度な脅威に対する保護を強化するだけでなく、ユーザー体験も向上します。Microsoft Entra Suite の一部である Microsoft Security Service Edge (SSE) ソリューション は、ネットワーク セキュリティ、ID、エンドポイント全体のアクセス制御を統合することで、ゼロ トラストの実装とネットワーク変革を加速します。
弊社が提供する SSE ソリューションの 2 つの要素である Microsoft Entra Private Access と Microsoft Entra Internet Access は、2024 年 7 月から一般提供されています。本日は、SSE に関していくつかの機能拡張を紹介します。
Microsoft Entra Private Access は、ID 中心のゼロ トラスト ネットワーク アクセス (ZTNA) ソリューションにより、従来の VPN を刷新するとともに、ユーザーをネットワーク全体にアクセスさせるのではなく、任意の社内リソースやアプリケーションにのみ安全に接続できるようにします。新機能により、従来の VPN からの移行がよりシンプルになり、ユーザーがリソースに簡単に接続できるようになります。
Microsoft Entra Internet Access は、ID 中心のセキュア Web ゲートウェイ (SWG) ソリューションを使用して、すべてのインターネットおよび SaaS アプリケーションとリソースに安全にアクセスできるようにします。新しい機能により、お客様は脅威からより一層守られるのです。
もしお客様が現在、オンプレミス ネットワークの簡素化や、高価な機器の最新ネットワーク ソリューションへの置き換えを検討中であれば、セキュア アクセス サービス エッジ (SASE) フレームワークという、ユーザー、システム、エンドポイント、リモート ネットワークをアプリケーションやリソースに安全に接続する仕組みについてもぜひご検討いただきたく思います。
Microsoft Entra は、他の SSE、SASE、およびネットワーク ソリューションとシームレスに連携し、高度な攻撃から組織を保護するための統合管理機能と可視化機能を提供します。例えば、Netskope の Advanced Threat Protection (ATP) と Data Loss Prevention (DLP) を皮切り (プライベート プレビュー中) に、他のプロバイダーの ネットワーク セキュリティ機能を統合中 です。また、大手プロバイダーの SD-WAN および接続ソリューションを Microsoft Entra と統合 して、包括的な SASE ソリューションを提供しています。
詳細については、Enhancing security with Microsoft’s Security Service Edge solution and SASE partners をご覧ください。
毎日 78 兆ものセキュリティ シグナルから得られる分析情報により、Microsoft Entra はパスワード攻撃だけでなく、MFA 攻撃や認証後の攻撃など、より高度で検出が困難な攻撃に対しても、プロアクティブでリアルタイムの保護を提供しています。サイバー攻撃の犯罪者は、パスワード攻撃をより早く、さらに拡大するために AI を使用しており、パスワード攻撃は依然として ID 関連の攻撃の 99% 以上を占めています。悪意のある攻撃者は一連の攻撃の始まりから終わりまでを完全に自動化している状況のため、多層防御の戦略は組織を保護するために必須となっています。
従来、セキュリティ管理者はログをくまなく調べ、パスワード スプレー攻撃の有無を特定していました。この度、Microsoft Entra ID Protection を機能強化し、パスワード スプレー攻撃をリアルタイムで検出できるようになりました。サインイン フロー中に攻撃を遮断することで、リスクの修復を数時間から数秒にまで短縮します。
リスクベースの条件付きアクセスはこの新しいシグナルに自動的に応答し、セッション リスクを引き上げるとともに、危険なサインイン試行に対して直ちに MFA などを要求し、パスワード スプレーの試行をその場で遮断します。この最新の検出機能は、近日パブリック プレビューが開始され、AitM (Adversary-in-the-Middle) フィッシングや トークン窃取 などの高度な攻撃に対する既存の検出と連動し、最新の攻撃も包括的にカバーします。
詳細情報: Microsoft Entra ID Protection は、Microsoft Entra ID P2 プランまたは Microsoft Entra Suite プランで利用でき、どちらも 無料試用版 が利用可能です。
攻撃者は、多要素認証 (MFA) の採用増加に対応して、AitM フィッシングやソーシャル エンジニアリングの手法を強化してユーザーの認証情報を盗もうとしています。パスキーは、これらの高度な攻撃やパスワード攻撃に対抗すると同時に、サインインをより安全かつシンプルにします。
パスキーは、W3C WebAuthn 標準をサポートする任意のインターネット リソースへのサインインを可能にする、強力でフィッシング耐性のある認証方法です。パスキーは、FIDO2 規格が継続的に発展したものといえます。
Microsoft Authenticator のパスキーは、低コストでフィッシングに強い資格情報を提供し、ユーザーがモバイル デバイスから直接アクセスできるため、個別のセキュリティ キーを購入する必要性が減ります。本日、Microsoft Authenticator for iOS および Android のデバイスに紐づくパスキーのサポートが一般提供となりましたことをお知らせします。併せて、登録とサインインのユーザー体験が向上し、パスキーを登録する前にユーザーのデバイス上の Microsoft Authenticator アプリの正当性を確認するアテステーションのサポートが可能になったことも発表します。
Microsoft Entra ID でのフィッシングに強いパスワードレス認証のデプロイを開始するにはこちらをどうぞ
Microsoft Entra External ID を使用すると、社員のアクセスを保護するのと同じように、顧客やビジネス ゲストのアクセスを保護できます。Microsoft Entra ID と ID Governance でおなじみの使い慣れたツールを用いることで、これらの外部 ID をより簡単に保護、管理、および統制可能です。
ブランドやコーポレート アイデンティティに合わせてデザインされたネイティブなユーザー体験は、エンドユーザー体験を向上させ、ブランドのロイヤリティを高め、最終的にビジネスの成長を加速させるために重要です。9 月から一般提供が開始された External ID の ネイティブ認証 により、開発者は細部までカスタマイズされたネイティブ モバイル認証体験を数分で構築できます。
直近で、外部向けの Web アプリとモバイル アプリ向けの新しいセキュリティとカスタマイズのオプションをリリースしました:
詳細については、Microsoft Entra External ID のドキュメントおよび開発者向けリソース をご覧ください。
お客様が統合された Microsoft Entra 管理センターで作業している場合でも、Azure ポータルを使用している場合でも、弊社は 更新、導入、運用の透明性を提供する ことで、ID とネットワーク アクセスのセキュリティ体制の監視と最適化をより容易にしようと取り組んでいます。お客様からの継続的なフィードバックを組み込んだ次の機能が一般公開されました:
Ignite に直接参加する場合でも、オンラインで参加する場合でも、こちらのイベント情報を参考 に、Microsoft Entra の新しいイノベーションについて是非ご覧ください。
Ignite で Microsoft Entra セッションのライブ配信または録画をぜひご視聴ください:
BRK313 – 11 月 20 日 (水) | 午後 1 時 15 分から午後 2 時 00 分 CDT
https://aka.ms/Ignite2024/BRK313
ゼロ トラストのアクセス制御に加え、従業員、顧客、パートナーのアクセスを保護し、あらゆるクラウドでの安全なアクセスを確立するための ID およびネットワーク セキュリティ ソリューションに関する最新のイノベーションと発表のディープ ダイブのセッションです。さらに、生成 AI と管理センターのツール群がチームの効率とスケーラビリティをどのように向上させるかをご覧いただけます。
BRK314 – 11 月 20 日 (水) | 午前 9 時 45 分 – 午前 10 時 30 分 CDT
https://aka.ms/Ignite2024/BRK314
ID は、最初の防衛線です。しかし、ID のソリューションとネットワーク アクセス ソリューションが連携せず単独で運用されている場合、複雑さが増し、ポリシーに一貫性がなくなる懸念があります。ID とネットワークで条件付きアクセスを統合することで、ゼロ トラスト アーキテクチャをよりシンプルに実現する方法を紹介します。Microsoft Entra Suite を使用して、従業員のオンボーディング作業を刷新し、リモート アクセスを最新化するとともに、オンプレミスのアプリケーションやインターネット リソースへのアクセスを保護する方法をご覧ください。
BRK326 – 11 月 21 日 (木) | 午前 9 時 45 分 – 午前 10 時 30 分 CDT
https://aka.ms/Ignite2024/BRK326
ID とネットワーク全体で統一されたアプローチを用い、ゼロ トラストの道のりをより加速する方法をご覧ください。このセッションでは、Microsoft の ID 中心のセキュリティ サービス エッジ (SSE) ソリューションを用いることで、プライベート、オンプレミス、インターネット、SaaS のすべてのアプリケーションとリソースへのアクセスをどのようにしてあらゆる面から保護していけるかというのを探ります。Microsoft のテクノロジ パートナーについても説明がありますので、組織のセキュリティ体制をさらに強化いただけます。
Joy Chik
President of Identity and Network Access at Microsoft
本記事は、2024 年 7 月 3 日に米国の Microsoft Entra (Azure AD) Blog で公開された Microsoft Entra certificate-based authentication enhancements を意訳したものになります。ご不明点等ございましたらサポート チームまでお問い合わせください。
Microsoft Entra の証明書ベースの認証 (CBA) の最新の機能をご紹介します。CBA は、フィッシングに強く、パスワード不要で、Active Directory フェデレーション サービス (AD FS) などのオンプレミスのフェデレーション基盤に依存せずに、PIV/CAC カードなどの X.509 証明書を使用してユーザーを認証するための便利な方法です。CBA は、すでに PIV/CAC カードを使用しており、フィッシングに強い認証を必要とする 大統領令 14028 に準拠しようとしている連邦政府機関にとって特に重要となります。
本日は、今年初めに導入 された多くの改善点の一般提供を発表します。ユーザー名バインド、アフィニティ バインド、認証ポリシー ルール、条件付きアクセスの高度な CBA オプションはすべて GA となりました。また、新機能である 発行者ヒント のパブリック プレビューを発表できることを嬉しく思います。発行者ヒント 機能は、ユーザーが認証に適した証明書を簡単に識別できるようにすることで、ユーザー体験を大幅に向上させます。
Microsoft Entra のプリンシパル プロダクト マネージャーである Vimala Ranganathan より、フィッシングに強い多要素認証 (MFA) に向けた取り組みに役立つこれらの新機能について説明します。
ご意見があればぜひお寄せください!
Alex Weinert
皆さん、こんにちは。Microsoft Entra のプリンシパル プロダクト マネージャーである Vimala Ranganathan です。本日は、新しい発行者ヒント機能と、一般提供が開始される機能について説明いたします。
発行者ヒント 機能は、ユーザーが認証に適した証明書を簡単に識別できるようにすることで、ユーザー体験を向上させます。テナント管理者によって有効にすると、Microsoft Entra ID は TLS ハンドシェイクの一部として Trusted CA Indication という情報を送り返します。ここでいう Trusted CA (CA) というのは、テナントによって Entra の信頼ストア にアップロードされた認証局 (CA) のサブジェクトのことを表します。クライアントまたはネイティブ アプリケーションは、サーバーから返されたヒントを使用して、証明書選択画面に表示される証明書をフィルターし、信頼ストア内の CA によって発行されたクライアント認証証明書のみをユーザーに表示します。
また、以下の機能が一般公開 (GA) となりました。各機能の詳細については、パブリック プレビューを知らせるブログである「Microsoft Entra 証明書ベース認証 (CBA) の機能強化」を参照ください。
CBA ユーザー名バインド: CBA は、追加で残りの 3 つのユーザー名バインドのサポートを追加し、オンプレミスの Active Directory と同等の機能を提供するようになりました。追加された 3 つの証明書バインドは以下のとおりです。詳細については ユーザー名バインド ポリシーを構成する を参照ください。
CBA アフィニティ バインド: CBA アフィニティ バインドを使用すると、管理者はテナント レベルでアフィニティのバインド設定を構成でき、高アフィニティまたは低アフィニティ マッピングを使用するカスタム ルールを作成することで、お客様が現在使用している多くの潜在的なシナリオをカバーできるようになります。詳しくは ユーザー名のバインド ポリシー をご覧ください。
CBA 認証ポリシー ルール: 認証の強度を単一要素または多要素としていずれとして扱うかを決定できます。また、複数のカスタム認証バインドのルールを作成し、証明書の属性 (発行者またはポリシー OID、または発行者と OID の組み合わせ) に基づいて、証明書に関する既定の保護レベルを割り当てることもできます。詳細については、「認証バインディング ポリシーの構成」を参照ください。
条件付きアクセスにおける高度な CBA の設定項目: 証明書の発行者またはポリシー OID のプロパティに基づいて特定のリソースへのアクセス可否を制御できます。認証強度の高度なオプションの詳細については、こちらをご覧ください。
Microsoft Entra CBA の詳細については、こちら と Microsoft の 大統領令 14028 に対する取り組みをご覧ください。-
昨年、多くの連邦政府および規制業界のお客様が、段階的ロールアウトの機能を活用して、AD FS から Microsoft Entra ID にシームレスに移行し、CBA を使用してエンド ユーザーに使い慣れたサインイン体験を提供できています。実際、過去 12 か月で、米国政府のお客様に対するフィッシング耐性のある認証が 1,400% 以上増加しました。
フィードバックは Microsoft Entra コミュニティ でお寄せください。弊社は、証明書失効リスト (CRL) の制限の撤廃、新しい認証局の信頼ストア、B2B 外部ゲストユーザーのリソーステナントでの CBA サポート、iOS UX の強化など、さらなる機能強化を実現するために取り組んでいます。
]]>Microsoft では Secure Future Initiative の取り組みのひとつとして、ID とシークレットの保護を継続的に強化するために取り組みを進めています。今回、取り組みの一環として 2024 年 11 月 11 日に以下のブログにて発表を行い、続けて Microsoft 365 管理センターのメッセージ センターより「MC933540 : Microsoft 365 admin center multifactor authentication enforcement」が通知されました。
Announcing mandatory multifactor authentication for the Microsoft 365 admin center
通知内容の概要としましては、2025 年 2 月 3 日以降、Microsoft 365 管理センターにアクセスするすべてのユーザー アカウントに MFA (Multifactor Authentication) の要求を開始するという内容であり、これはテナント レベルで段階的にロールアウトされます。メッセージ センターで通知した MC933540 の内容について抄訳したものを以下に記載いたしますのでご確認ください。
Microsoft 365 管理センターの多要素認証の施行
Microsoft 365 管理センターへのアクセスに対して多要素認証 (MFA) を実装することにより、管理アカウントの侵害リスクを大幅に軽減し、不正なアクセスを防ぎ、機密データを保護します。 標準のユーザー名とパスワード認証に加えて、追加の認証を要求する MFA の制御を有効化することで、攻撃者によるデータの盗難を困難にし、フィッシング、クレデンシャル スタッフィング攻撃、ブルートフォース攻撃、パスワード再利用攻撃などの不正なアクセスを防ぎます。当社および製品全体でサイバー セキュリティを向上させるための継続的な取り組みの一環として、2025 年 2 月 3 日から、Microsoft は Microsoft 365 管理センターへのサインイン時にすべてのユーザーに MFA の使用を求めるようになります。この要件は、今後数週間のうちにテナントレベルで段階的に展開されます。
今すぐ実施いただきたいこと:
- グローバル管理者: 組織内における MFA の設定を完了ください。組織での MFA 設定は、aka.ms/MFAWizard の MFA 設定ガイドを参照するか、Microsoft 365 Business Premium の多要素認証を設定する を参照ください。
- Microsoft 365 管理センターにアクセスするユーザー: aka.ms/mfasetup にアクセスして、MFA に利用可能な認証方法が登録されているか確認ください。
本通知の変更が組織に与える影響:
Microsoft 365 管理センターにサインインできるようにするために、管理者に対して MFA の方法を追加し、必要に応じてテナントに対して MFA を有効にする必要があります。準備のためにできること:
- MFA の方法を設定していない場合は、2025 年 2 月 3 日までに MFA を設定ください。
- 既に MFA を設定している場合は、特に追加の操作は必要ありません。Microsoft 365 管理センターにアクセスするすべてのユーザーが MFA 用の認証方法を追加していることを確認することをお勧めします。
- グローバル管理者:組織内における MFA の設定を完了ください。組織での MFA 設定は、aka.ms/MFAWizard の MFA 設定ガイドを参照するか、Microsoft 365 Business Premium の多要素認証を設定する を参照ください。
- Microsoft 365 管理センターにアクセスするユーザー: aka.ms/mfasetup にアクセスして、MFA に利用可能な認証方法が登録されているか確認ください。
- 2025 年 2 月 3 日までに MFA 要件の準備が整わない場合、管理者は https://aka.ms/managemfaforazure のページから施行日の延期を申請することができます。Azure ポータルの MFA 施行延期は Microsoft 365 管理センターにも適用されることに注意ください。
詳細については、こちらのブログ記事の FAQ を参照ください。
なお、以下の弊社サポート ブログでお伝えした Azure Portal へのサインインに対して MFA を義務付ける取り組みとは、ロールアウトの開始日が異なります。
Azure Portal などのリソースに対する MFA の要求は、フェーズ 1 が 2024 年 10 月 15 日より順次ロールアウトしており、各テナントへの展開を開始しておりますが、本ブログの対象となる Microsoft 365 管理センターに対する MFA の要求は、2025 年 2 月 3 日がロールアウトの開始日です。一方で、ロールアウトの開始日を延期するための申請は同じ仕組みを利用しております。そのため、Azure Portal などのリソースに対する MFA の要求 (フェーズ 1) に関して延長申請を既に実施いただいているお客様は、Microsoft 365 管理センターに対する MFA 要求も併せて延期が適用された状態となります。
なお、Microsoft 365 管理センターに対する MFA 要求を延長申請した場合のロールアウト開始日は 2025 年 3 月 15 日です。これは、Azure Portal などのリソースに対する MFA の要求を延長した場合と同じ日程となります。
延長申請のための操作に関しましては、以下のブログをご参照ください。
MC862873 - Azure ポータル (および Azure CLI 等) の MFA 義務付けの延長申請について | Japan Azure Identity Support Blog
本通知の適用を待たずに Azure Portal や Microsoft 365 管理センターへのアクセスに対して MFA を要求されたい場合、条件付きアクセスの機能を利用することで実現可能です。弊社としてはこの MFA の強制を待たず、速やかに MFA を要求することをお勧めします。設定方法に関しては、以下の公開情報をご参考ください。
Microsoft 管理ポータルに多要素認証を要求する - Microsoft Entra ID | Microsoft Learn
本通知に関する補足情報を Q & A 形式で記載いたします。参考になりましたら幸いです。
A. いいえ、2025 年 2 月 3 日からテナント レベルで段階的に展開されます。複数の Microsoft 365 テナントを持つ組織の場合、テナントごとに異なる日程で適用される場合があります。
A. いいえ。このセキュリティ対策は、Microsoft 365 を利用する組織とユーザーを保護するために必要な設定となるため、すべてのテナントに適用され、回避する設定および方法はございません。
A. いいえ、Microsoft 365 管理センターへのアクセスするユーザー全てに強制されます。組織で緊急アクセス用アカウントを用意いただいている場合、このアカウントに対しても MFA が要求されます。緊急アクセス用アカウントに対しては FIDO2 セキュリティ キーを利用した MFA の方法を利用することがおすすめですので、併せてご検討いただけますと幸いです。
A. Azure Portal などのリソースに対する MFA の要求に関して延長申請を既に実施いただいているお客様は、Microsoft 365 管理センターに対する MFA 要求も併せて延長申請された状態となります。延長申請後のロールアウトの開始日は 2025 年 3 月 15 日であり、Azure Portal などのリソースに対する MFA の要求を延長した場合と同じ日程となります。
A. 本通知によって影響のある操作は Microsoft 365 管理センターへアクセスするユーザーのみとなります。Microsoft 365 管理センターにアクセス可能なユーザーは、管理者ロールを持つユーザーのみです。アクセス可能なロールに関する説明は以下の公開情報をご参照ください。
Microsoft 365 管理センターの管理者ロールについて - Microsoft 365 admin | Microsoft Learn
A. いいえ。この要件は、現時点では Microsoft Graph PowerShell または API の使用には影響しません。
]]>今回は、2024 年 10 月 29 日に米国の Microsoft Entra (Azure AD) Blog で Joseph Dadzie によって公開された Manage Microsoft Entra ID role assignments with Microsoft Entra ID Governance と、11 月 5 日に Kaitlin Murphy によって公開されました Microsoft Entra ID Governance for government を分かりやすく日本語におまとめしなおしたものになります。ご不明点などございましたらお気軽にサポートへお問い合わください。
2024 年 11 月 1 日より、Microsoft Entra ID Governance が、米国政府コミュニティクラウド (GCC)、GCC-High、および国防総省のクラウド環境において、連邦政府機関、州政府、地方政府、および政府請負業者向けに利用できるようになりました!Entra ID Governance は、2023 年 7 月 1 日に商用顧客向けに提供を開始した機能で、アクセス パッケージをはじめとするエンタイトルメント管理や、ライフサイクル ワークフローなどの機能が含まれています。この機能の開始後、強い要望があったため、今年初めに教育機関 (EDU) とフロント ライン ワーカー (FLW) のお客様にも提供を拡大しました。そして今回新たに、Entra ID Governance 製品を米国政府機関のお客様もご利用いただけるようになりました。
Microsoft Entra ID Governance は、組織が「適切なユーザーが適切なタイミングで適切なアプリやリソースにアクセスできるように」支援する機能です。自分の会社でも使えそうだろうかと悩むお客様もいらっしゃるかと思いますが、たとえば海外では、Rijksmuseum (アムステルダム国立美術館) のような公共機関でも利用されています。
アムステルダム国立美術館は、フェルメールからゴッホまで、オランダの芸術と歴史の中でもっとも有名な作品が多く収蔵されている美術館ですが、ここでは研究や保存、美術館の清掃などに至るまで 1,000 人以上の人々を雇用しています。アムステルダム国立美術館では、Excel シートや独自のデータベースを手作業で管理していたことで、「従業員が役割を変更したり、新しいシステムにアクセスしたりしようとしたときに、不整合や更新作業の遅延でエラーが起きやすい」もしくは「契約終了後のユーザーもシステムにアクセスできてしまっていた」といった課題がありました。しかし、現在は Entra ID Governance を使用して管理負担を軽減し、ユーザー体験が向上したことで、ユーザーのアクセス管理に費やす時間を減らすことができています。このお客様の事例の全文は英語とはなりますが Microsoft Customer Story-The Rijksmuseum saves hours in identity management with Microsoft Entra ID Governance. でご覧いただくことが可能です。
商業、教育、フロント ライン ワーカーのお客様と同様に、Entra ID Governance は、政府機関が要件に準拠し、Zero Trust の原則に従うことを支援します。KuppingerCole は最近、ID ガバナンスのシナリオの概要と Entra ID Governance のレビューを含む ホワイト ペーパー を発行しました。
次のステップとして、Microsoft Entra ID Governance をご検討中のお客様には以下をお勧めします:
ユーザーが不要な権限を保持しないよう、特権 ID 管理 (PIM) の機能をすでに多くのお客様の環境でご利用いただいていると思います。PIM の機能を利用すると、割り当てられた最小特権ロールに必要な時だけ (ジャスト イン タイム - JIT) アクセスすることができ、必要なタイミングで、必要な時間だけ特権ロールを使用することができます。このアプローチでは、IT 管理者が持つ権限の数をできるだけ減らし、必要なユーザーが必要なタイミングのみ権限を利用できるようにすることで、組織内の攻撃対象領域を最小限に抑えています。
しかし、「必要な時だけ特権を使えるようにする」PIM の機能は便利である一方、すべての管理者がこのように一定期間のみ特権を利用したいわけではありません。組織内の一部の管理者は、特定のアプリケーションなどリソースを限定して、管理者ロールを長期間保持する必要が時にはあります。
このような場合、以前より Microsoft Entra ID Governance を使用して、エンタイトルメント管理のアクセス パッケージを通して管理することを案内してきました。たとえば以前に案内した アクセス パッケージを利用した一括でのアクセス権の管理 のブログでは、アクセス パッケージ内のリソースとしてグループを追加し、そのグループに Microsoft Entra ロールを割り当てることで、間接的にロールの割り当てを管理できる点を案内しています。
今回のアップデートでは、以前のように「事前にロールを割り当てたグループをパッケージに追加する」ような操作を行わなくても、Microsoft Entra ロールを直接ユーザーとグループに割り当てることができるようになりました!これにより、以下のことが可能になります:
この機能は、次のようなシナリオで使用いただけます:
アクセス パッケージ ポリシーにより Microsoft Entra ID ロールの割り当てを管理することで、リクエストから承認、ロールのプロビジョニングまで、ロールの割り当てライフサイクル全体を制御できます。
ここからは、Microsoft Entra ID Governance を活用して、役割割り当てのライフサイクルを管理する方法について説明します。
ある組織のサポート部門が新しく 50 人の IT ヘルプデスク スタッフを雇用して事業を拡大するとします。この場合、もし管理者だったらどのような操作が必要になるでしょうか。一般的には、ユーザーを 1 人ずつ作成し、それぞれのユーザーにロールを割り当てていくような流れを想像されるかと思いますが、各ユーザーに Microsoft Entra のロールを手動で割り当てることは効率的ではなく、ID のアクセス管理 (IAM) チームが繰り返しこういった作業を手作業で行うと、コンプライアンスや監査要件を満たすことも難しくなります。
このような場合、エンタイトルメント管理のアクセス パッケージを使うと、この操作を合理的に行うことが可能となります。具体的には、テナント管理者は必要なロールを含むアクセス パッケージを作成し、IT スタッフが My Access ポータルを介してアクセス権を申請できるようにします。IT スタッフによって申請されたパッケージ要求の承認作業は、ヘルプデスク部門のマネージャーに委任するように構成しておくようにします。IAM チームは、Microsoft Entra ID Governance ポリシーに加え、ユーザーによるセルフ サービス (ユーザーが自らサービスを申し込む) 機能を利用することで、こまごまとした作業に時間を取られることなく、組織のセキュリティ的な課題に集中することができます。
なお、ヘルプデスク管理者のロールをアクティブな状態でパッケージに割り当てた場合、 IT スタッフにパッケージが割り当てられるとすぐにヘルプデスク管理者の特権が利用可能となってしまいます。本来、ヘルプデスク管理者のロールが必要なのは、パスワードのリセットなど一部の業務を行うときのみです。このような永続的な権限を制限するには、アクセス パッケージの作成時に、「資格のある割り当て」の設定でヘルプデスク管理者を構成し、必要なときにのみ特権 ID 管理 (PIM) を通してロールをアクティブ化してもらうような運用にします。
以下の 3 つの手順で簡単に設定することができるので、手順を案内します。
アクセス パッケージを作成し、Microsoft Entra ロールである「Helpdesk Administrator」を「Eligible member」として、「Service Support Administrator」ロールを「Active member」として追加します。Eligible Member は「資格のある割り当て」を示します。Active Member は「アクティブな割り当て」を示します。このため、このパッケージ構成の場合、ユーザーがパッケージを要求して割り当てが行われると、サービス サポート管理者は常に特権を利用でき、必要な時だけヘルプデスク管理者の特権も利用できるようなイメージになります。
誰がこのパッケージを要求できるのかを「アクセス権を要求できるユーザー」を指定し、承認の設定を行います。たとえば今回の場合、IT ヘルプデスクの部門のユーザーが要求できるようなパッケージを作成したいので、社内 (自分のディレクトリ内) に所属しているだけではなく、 IT ヘルプデスクというグループに所属しているユーザーのみが要求できるように構成しました。
下に少しスクロールすると、承認の設定も表示されます。今回は、マネージャーに承認操作を行わせたいので、「承認者としてのマネージャー (Manager as Approver)」を選択します。必要に応じて、承認ステージを 2 や 3 に増やす、理由を要求する、何日以内に決定しないといけないかを指定する、ユーザーの代わりにマネージャーがパッケージを要求できるかを指定するなど様々な設定がありますので、ご要望やご要件に応じてカスタマイズも可能です。
定期的なアクセス レビューを設定すると、アクセスが不要になった場合に役割の割り当てを削除することもできます。この設定は「ライフサイクル」タブの設定で可能ですので下記に案内します。
なお、「要求」から「ライフサイクル」のメニューまでには「要求元情報」というメニューもありますが、これはユーザーがパッケージを要求するときに質問を表示させ、回答してもらうようなことができる画面です。ユーザーから情報を収集したいといったご要望がある際に利用できます。
「ライフ サイクル」タブで、有効期限とアクセス レビューの必要性を設定します。レビューの頻度を選択し、誰がレビューを行うかを指定できます。
これらのガバナンスの仕組みを適用することで、すべての IT 管理者に最小限の特権アクセスを保証し、不必要なアクセスや潜在的な悪用のリスクを低減することができます。この新機能をライフサイクル ワークフローなどの他のガバナンス機能と組み合わせることで、IT 管理者が組織を離れたり役割を変更したりしたときに、役割の割り当てが自動的に削除されるようにすることも可能です。これにより、組織はよりスムーズで安全な運用が可能になります。
ライフサイクル ワークフローの活用方法については、以前 ライフサイクル ワークフローを利用した簡易人事システムの紹介 にて紹介いたしました。人事異動や新入社員対応でも活用できる機能となりますので、ぜひあわせてご覧ください。
すでに Microsoft Entra ID Governance ライセンスをお持ちのお客様はすぐにこの機能をご利用いただけます。もしライセンスをお持ちでないお客様は、無料試用版のライセンスで利用を開始いただくか、すでにお持ちの P1/P2 ライセンスからアップグレードすることも可能です。ライセンスを購入する場合は、ライセンス パートナーからオンラインで購入するか、Microsoft 365 管理センターより直接ライセンスを購入ください。
]]>本記事は、2024 年 11 月 6 日に米国の Microsoft Entra Blog で公開された Built-in security controls for external-facing apps を意訳したものになります。ご不明点等ございましたらサポート チームまでお問い合わせください。
今年の初めに、Microsoft Entra External ID の一般提供を発表しました。これは、次世代の CIAM ソリューションであり、組織は完全にカスタマイズ可能なコンシューマー向けのユーザー体験をアプリに組み込むと共に、エンタープライズ レベルのセキュリティとコンプライアンスを享受することが可能です。弊社は、お客様からのフィードバックに基づいて革新的な機能を定期的に展開し、管理者と開発者の日常の業務をより簡素にし、改善することに取り組んでいます。例えば、完全にカスタマイズ可能なモバイル アプリケーションを作成できるようにする ネイティブ認証の一般提供 に関する最近の発表もぜひご覧ください。
本日は、Microsoft Entra External ID を使用したエンドツーエンドの ID セキュリティ戦略の構築に関し、包括的な分析情報を提供するという、セキュリティの中でも重要な側面に焦点を絞ってお話ししたいと思います。これらの堅牢なセキュリティ対策を行うことで、ビジネスを守るというだけでなく、アプリのエンドユーザーの信頼と満足度も高め、ユーザー体験がシームレスで安全であるという安心感をも与えることができるということを弊社は目指しています。では、プリンシパル プロダクト マネージャーの Pawan Nrisimha より、External ID に組み込まれたエンタープライズ レベルのセキュリティ制御について詳しく説明してもらいます。
Microsoft Entra External ID のエンドツーエンドかつ幾層にも及ぶセキュリティ戦略は、全体の機能を支える基盤としての Core Protection 層から始まり、Microsoft Entra ID を活用している従業員だけでなく、外部ユーザーに対しても核となるセキュリティ機能を拡張していくというものです。わずかワンクリックで、リアルタイムおよびオフラインの堅牢な保護機能を有効化し、すべてのユーザーをエンタープライズ レベルのセキュリティで保護することが可能になります。現時点では、ブルート フォース保護、一般的なネットワーク周りの HTTP 保護、アカウント保護、アクセス制御などの核となる保護機能に注力しており、これらの保護は External ID のテナントを作成すると既定で有効になります。
ID に関連するサービスを提供する最大のプロバイダーの 1 つとして、弊社はお客様のアプリケーションに対してますます多くの攻撃が行われていることを目の当たりにしています。例えば、DDoS 攻撃が増え続けており、6 月にはすべてのお客様で 1 日あたり約 4,500 件の攻撃がありました。External ID を使用すると、大量の要求でサービスをダウンさせようとする試みを効果的に防ぐことが可能です。Microsoft Entra External ID を使用して外部テナントを作成すると、このような堅牢なセキュリティ対策が 既定で有効 になり、これらの増大するサイバー空間の脅威からアプリケーションを保護できます。既定では、External ID はパスワード スプレー攻撃からエンドユーザーを保護する機能も提供しています。パスワード スプレー攻撃は今年に入り、1 秒あたり 7,000 件に達しています。機密性の高いユーザー データを危険にさらす不正アクセスの試みがあったとしても、すべてのコア セキュリティ制御によりアプリケーションが保護されます。
このグラフから、お客様が実際に大規模な DDoS 攻撃に直面しており、攻撃者は膨大なリクエストをサーバーに送信していることが分かります。Microsoft Entra External ID に 組み込まれた DDoS 保護 は、異常なトラフィック パターンを検出し、攻撃を緩和する処理を有効化することで、悪意のあるトラフィックを除外し、正当な要求を許可してサービスが中断されないようにします。
同様に、次のグラフに示されている Slow Loris 攻撃では、Microsoft Entra External ID は、実害が生じる前にアイドル状態の接続を特定して破棄することで攻撃を防いでいます。このような堅牢な保護により、サービス品質に影響を与えることなく大量の同時リクエストが処理され、アプリの安全性だけでなくエンド ユーザーの信頼も保たれることになるのです。(Microsoft 内部データ)
弊社は、潜在的な脅威に先手を打つべくシステムを継続的に更新していますのでご安心ください。
ここまでで、外部テナントの作成時に既定で有効になる保護機能について説明してきました。お客様のアプリのセキュリティをさらに強化するために、条件付きアクセス ポリシーをカスタマイズして多要素認証 (MFA) を求めることで、侵害のリスクが 99.22% と大幅に減少し (2023 年 Microsoft デジタル防衛レポート)、不正アクセスが防止されるだけでなく、フィッシングやアカウント乗っ取りなどの脅威に対する堅牢な防御が提供されます。外部テナントで構成できるさまざまな MFA 方法の詳細については、弊社ドキュメント をご覧ください。
ここまでで、テナント作成時から有効な既定のセキュリティ機能についてご理解いただけたと存じます。次に、お客様が自社の ID に関するセキュリティ要件について確認され、さらに高度な脅威が存在しているという点についても理解が得られましたら、ぜひ以下に紹介します External ID のプレミアム セキュリティ機能についてもご検討ください。今後数か月の間に、包括的な外部 ID セキュリティ ブログの連載を開始し、Web Application Firewall (WAF) の統合、不正サインアップの防止、サインイン アカウントの乗っ取り保護、そして最後にオフラインでの脅威ハンティングのための SIEM/SOAR ツールに関する情報を公開する予定です。
Microsoft Entra External ID を使用して、安全で美しく、使い心地の良いアプリを数分で構築できます。今すぐ aka.ms/TryExternalID にアクセスしてお試しください。
]]>本記事は、2024 年 10 月 31 日に米国の Microsoft Entra Blog で公開された Update to security defaults を意訳したものになります。ご不明点等ございましたらサポート チームまでお問い合わせください。
弊社では Secure Future Initiative の一環として、セキュリティに対するアプローチを進化させており、設計の段階からセキュリティ対策を組み込んでおく (Secure by Design) こと、セキュリティ機能が既定の状態で有効になっている (Secure by default) こと、セキュリティを守った運用を行う (Secure Operations) ことという 3 つのセキュリティ原則に沿っています。セキュリティ機能が既定の状態で有効になっている (Secure by default) とは、セキュリティによる保護が既定の設定として有効化され、強制されていることを意味します。Microsoft Entra では、セキュリティ既定値群の機能がその例であり、最初からすべての新しいテナントで有効化され、Entra の ID とリソースに対するベースラインとしての保護レベルが提供されます。弊社はセキュリティ既定値群を利用する組織がより十分に保護されるよう、認証方法に関する要件を更新し、セキュリティをさらに向上するよう努めています。
そこで今回、セキュリティ既定値群が有効な場合、多要素認証 (MFA) の登録を 14 日間スキップするオプションを廃止することにしました。これにより、すべてのユーザーはセキュリティ既定値群が有効になった後の最初のログイン時に MFA を登録する必要があります。この措置により、14 日の間にアカウントが侵害されるリスクを軽減することが可能になります。これは MFA が ID に基づく攻撃の 99.2% 以上をブロックできるためです。この変更は、2024 年 12 月 2 日以降に新しく作成されたテナントに適用され、2025 年 1 月から既存のテナントに展開されます。
この更新は、皆様に安全で信頼性の高い ID サービスを提供するための継続的な取り組みの一環です。そのため、お客様のテナントで条件付きアクセスを使用していない場合は、セキュリティ既定値群の機能を有効にすることをお勧めします。セキュリティ既定値群は、よくある脅威からユーザーとリソースを保護するためのシンプルで効果的な方法です。
これらの今後の更新とユーザーが必要とする準備につきましては、ドキュメント をご覧ください。
Nitika Gupta
Group Product Manager, Identity
本記事は、2024 年 10 月 23 日に米国の Microsoft Entra (Azure AD) Blog で公開された The latest enhancements in Microsoft Authenticator の抄訳です。ご不明点等ございましたらサポート チームまでお問い合わせください。
皆さん、こんにちは。
この度は、フィッシング耐性のある認証でユーザーをより保護できるよう、Microsoft Entra ID の 3 つの大きな機能強化を発表できることを嬉しく思います:
これらの機能強化は、国家のサイバーセキュリティ向上に関する米国大統領令 14028 を遵守するためだけでなく、安全なデジタル ID に依存するすべての組織とユーザーを保護するためにも極めて重要です。さらに詳細を見てみましょう!
5 月の World Password Day において、より高いセキュリティ アシュアランスを必要とする組織を対象に、iOS および Android 用の Microsoft Authenticator においてデバイスに紐づくパスキーのサポートのパブリック プレビューを発表しました。そしてこの度、この機能に新機能を追加しました!
パブリック プレビューの期間中、パスキーの登録が煩雑でエラーが発生しやすいというお客様からの貴重なフィードバックをいただきました。ノート PC から登録する際、19 ものステップを踏んだり、デバイスの Bluetooth を有効にするなどの重要な前提条件を見逃したり、サポートされていないプロバイダーでパスキーを設定したりしたユーザーもいました。このようなフィードバックに基づき、私たちは登録フローを改善し、ユーザーが確実にパスキーを登録できるよう、よりカスタマイズされたユーザー体験を提供するようにしました。また最初に Authenticator アプリにサインインするようユーザーを誘導することで、登録プロセスを最適化しました。このアプローチにより、シームレスなユーザー体験が提供され、前提条件を満たした状況でユーザーを誘導し、デバイス間の切り替えも大幅に削減されました。
ユーザー体験の強化に加え、アプリとしての正当性確認を導入することでセキュリティ体制も強化しました。Android と iOS の API を活用し、パスキーの登録前にユーザーのデバイス上の Microsoft Authenticator アプリの正当性を検証します。
この 2 つの機能は現在プレビュー中です。近々予定されている一般提供に向けて、ぜひ組織内でこれらの機能の試験運用を開始し、フィードバックを共有ください。
パスキーを利用するには、当社の ドキュメント をご覧ください。Microsoft Entra ID のパスキー サポートの詳細については、当初の発表である パブリック プレビュー: パスキーのサポートを Microsoft Entra ID に拡張 をご覧ください。
Microsoft Authenticator のパスキー サポートのパブリック プレビュー更新と並行して、Android 上でのブローカーを経由した Microsoft アプリケーション内でのパスキー (FIDO2) 認証のパブリック プレビューも開始しました。Android 14 以上のデバイスに Microsoft Authenticator アプリまたは Microsoft Intune Company Portal アプリが認証ブローカーとしてインストールされている場合、ユーザーは Microsoft Authenticator アプリで FIDO2 セキュリティ キーまたはパスキーを使用して、Teams や Outlook などの Microsoft アプリケーションにサインインできるようになりました。
Android 13 でのブローカーを経由した Microsoft アプリへの FIDO2 セキュリティ キーのサインイン機能は、今後数ヶ月以内に提供される予定です。
iOS と Android の Microsoft Authenticator が FIPS 140 に準拠しました。iOS 版の Authenticator アプリは 2022 年 12 月から FIPS 140 に準拠しています が、Android の Authenticator アプリの FIPS 140 準拠バージョンは 2024 年 9 月にリリースされました。
Microsoft Authenticator の FIPS 140 準拠は、連邦政府機関が 大統領令 (EO) 14028 “国家のサイバー セキュリティの改善” の要件を満たすこと、ならびに医療機関が EPCS (Electronic Prescriptions for Controlled Substances) の要件を満たすのに重要な役割を果たします。
パスキー、パスワードレスの電話によるサインイン、多要素認証 (MFA)、ワンタイム パスワード コードを含む、Authenticator を使用した Microsoft Entra ID のすべての認証は FIPS 準拠と見なされます。この機能を有効にするために、Microsoft Authenticator または Microsoft Entra 管理センターで構成を変更する必要はありません。Android の Microsoft Authenticator バージョン 6.2408.5807 以降のユーザーは、Microsoft Entra ID 認証が既定で FIPS 140 準拠となります。
Android 上の Microsoft Authenticator は、WolfSSL Inc. の wolfCrypt モジュールを使用して、FIPS 140-3 レベル 1 準拠を実現しています。使用されている認証の詳細については、暗号モジュール検証プログラム の情報を参照ください。
これらのリリースにより、Microsoft Authenticator のユーザー体験とセキュリティ体制が大幅にレベルアップし、フィッシングへの対策を実施しやすくなりました。フィッシング対策をまだ検討されていない場合は、ぜひご検討ください。更新された パスワードレス デプロイ ガイド を使用して、この取り組みをぜひ開始ください。
これらの新機能をお試しいただき、ご意見をお聞かせいただけることを楽しみにしています。
ありがとうございます。
Nitika Gupta
今回は、2024 年 10 月 9 日に米国の Microsoft Entra (Azure AD) Blog において、Shobhit Sahay によって公開された What’s new in Microsoft Entra - September 2024 を分かりやすく日本語におまとめしなおしたものになります。ご不明点などございましたらお気軽にサポートへお問い合わせをいただけますと幸いです。
まず、業界で最も包括的なセキュア アクセス ソリューションの一つである Microsoft Entra Suite の一般提供を開始したことをお知らせします。攻撃経路の 66% が十分に安全でない資格情報に関与しているなか、Microsoft Entra Suite は、クラウドおよびオンプレミスのアプリへの最小特権アクセスを可能にすることで、セキュリティ侵害を防ぎます。これにより、ネットワーク アクセス、ID 保護、ガバナンス、および資格情報の検証が統合され、オンボーディングの効率化、リモート アクセスの刷新、アプリおよびリソースへの安全なアクセスが実現されます。Microsoft Entra Suite のトライアル をぜひ開始ください。
また、昨年 11 月に、弊社はサイバー攻撃の増加に対抗するために Secure Future Initiative (SFI) を立ち上げました。セキュリティは今や弊社のすべての意思決定を左右する要因となっており、2024 年 9 月に発行された SFI の進捗報告書 に詳細がまとめられています。本日は、2024 年 7 月から 9 月にかけての Microsoft Entra における新しいセキュリティ改善と革新を製品ごとに整理して共有します。
Microsoft Entra の新機能 のビデオもぜひご覧になり、製品のアップデートの概要を確認するとともに、詳細情報については Microsoft Entra 管理センターの 新機能ブレード や公開情報 もご覧ください。
下記に、各サービスの新機能と、変更についてのアナウンスをおまとめしました。利用環境によって対応が必要なものもございますので、利用している機能について確認のうえ、必要に応じて対処ください。
内容 | 対応が必要かどうか |
---|---|
Microsoft Entra 管理センターでの MFA 強制適用の予定 | お客様によっては対応が必要 |
Apple 社製デバイスのキーチェーンに基づくデバイス ID の廃止 | お客様によっては対応が必要 |
Microsoft Entra Connect を最新バージョンにアップグレード | お客様によっては対応が必要 |
login.microsoftonline.com の新しい認証局 (CA) | お客様によっては対応が必要 |
企業向けデータ保護機能に関する Microsoft Copilot の更新 | 対応の必要なし |
すべての Android ユーザーにおける既定でのブラウザー アクセス (EBA) 有効化 | 対応の必要なし |
Microsoft Entra Connect Sync および Cloud Sync の Directory Synchronization Accounts (DSA) ロールの権限制限 | 対応の必要なし |
SSO 登録ダイアログの今後の改善予定 | 対応の必要なし |
内容 | 対応が必要かどうか |
---|---|
重要な更新: Azure AD Graph の廃止 | お客様によっては対応が必要 |
重要な更新: AzureAD PowerShell および MSOnline PowerShell の廃止 | お客様によっては対応が必要 |
Microsoft Entra Admin Center でのライセンス割り当ての変更が非サポートに | お客様によっては対応が必要 |
Microsoft Graph 用 Bicep テンプレートでの動的な型のバージョン管理 | お客様によっては対応が必要 |
Entra ポータルでのレガシーなユーザー認証方法の管理画面の廃止 | 対応の必要なし |
ブラウザ アクセスの有効化 (EBA) UI の廃止 | 対応の必要なし |
自分のグループにおける管理者設定の変更延期 | 対応の必要なし |
セキュリティ情報におけるサインイン方法の選択画面のユーザー インターフェイスの更新 | 対応の必要なし |
プロビジョニング UX の刷新 | 対応の必要なし |
内容 | 対応が必要かどうか |
---|---|
アクセス パッケージの探し方が一覧からの選択ベースから検索ベースに移行 | お客様によっては対応が必要 |
内容 | 対応が必要かどうか |
---|---|
Microsoft Entra Internet Access および Microsoft Entra Private Access の今後のライセンス強制 | お客様によっては対応が必要 |
[対応が必要な場合があります]
お客様に最高レベルのセキュリティを提供するという弊社のコミットメントの一環として、Azure にサインインするユーザーに多要素認証 (MFA) を要求することを 以前に発表 しました。MFA の適用範囲には、Azure ポータルと Intune 管理センターに加え、Microsoft Entra 管理センター も含まれます。この変更は段階的に展開されるため、お客様においては対応を順次進めるようご対応ください。段階的な展開フェーズの詳細は下記のとおりです:
フェーズ 1: 2024 年 10 月 15 日 以降、Entra 管理センター、Azure ポータル、および Intune 管理センターへのサインインに MFA が必要になります。この施行は、全世界の全テナントに順次展開されていきます。このフェーズでは、Azure Command Line Interface、Azure PowerShell、Azure モバイルアプリ、Infrastructure as Code(IaC)ツールなど、他の Azure クライアントには影響を及ぼしません。
フェーズ 2:2025 年初頭から、Azure CLI、Azure PowerShell、Azure モバイルアプリ、および Infrastructure as Code(IaC)ツールのサインイン時にMFAを段階的に実施します。
弊社からは、すべての Entra のグローバル管理者に電子メールおよび Azure サービス正常性の通知をとおして 60 日の事前通知を送付し、強制の開始日と必要な対応についてお知らせする予定です。加えて、Azure ポータル、Entra 管理センター、M365 メッセージセンターでも追加の通知を行う予定です。
弊社では、この MFA の強制に備えるにあたり一部のお客様でより長い準備期間が必要なことも承知しております。このため、複雑な環境や技術的障壁のあるお客様向けに延長期間を設けます。弊社からの通知には、お客様テナントでの MFA 強制の開始時期を延長する手順、延長期間、そのリンクも含まれる予定です。詳細については、MC862873 - Azure ポータル (および Azure CLI 等) の MFA 義務付けの延長申請について もご覧ください。
[対応が必要な場合があります]
今年初め、Microsoft Entra ID プラットフォームにおける Apple デバイスのキーチェーンに基づくデバイス ID の廃止を 発表 しました。 以前発表した 2026 年 6 月の非推奨の日程は、弊社がコミットメントとする安全な設計と既定の設定への対応の一環として、2025 年 6 月に前倒しされました。この変更は、デバイスのセキュリティを強化し、お客様のデータをより適切に保護するために行われます。
この変更が実施されると、Microsoft Entra ID によって管理される新規登録された Apple デバイスは、Apple の Secure Enclave に基づく、強力なハードウェア ベースのシークレットを使用するようになります。詳細については、この非推奨に関する最新のドキュメント をご覧ください。お客様とアプリケーションの開発ベンダーの皆様におかれましては、この新しいデータ ストアとの互換性に問題がないかソフトウェアのテストを進めることをお勧めします。
[対応が必要な場合があります]
2024 年 10 月上旬に Microsoft Entra Connect Sync の新バージョンをリリースする予定です。このバージョンでは、バックエンドのサービス変更が含まれており、当社のセキュリティがさらに強化されます。サービスの中断を避けるため、お客様は 2025 年 4 月上旬までにそのバージョン (2.4.XX.0) にアップグレードする必要があります (正確な期限はバージョン リリース時に発表されます)。
今後のリリース予定については、ロードマップ をご覧ください。Connect Sync の 2025 年初頭のリリースと同時に、サポートされているお客様には自動アップグレードを行います。自動アップグレードをご希望のお客様は、自動アップグレードが構成されていること をご確認ください。
サービス変更の最小要件と予想される影響の一覧については、こちらの記事 をご覧ください。アップグレード関連のガイダンスについては、ドキュメント をご覧ください。
Note
Microsoft Entra Connect のバージョンアップに関するお知らせは、 Microsoft 365 管理センター上のメッセージ センターにおいても、MC906491 にてお知らせしております。また、2024 年 10 月 7 日に バージョン 2.4.18.0 が既にリリース済みです。
Entra Connect のアップグレードに関しては、長期間アップグレードを行わなかったことで、廃止期限やサポート期限が切れたお客様からよくお問い合わせいただいております。アップグレード手順の詳細などは下記ブログでも案内しておりますので、期限に余裕をもって準備ならびに対処を実施くださいますようお願い申し上げます。
[対応が必要な場合があります]
Microsoft Entra ID は、login.microsoftonline.com ドメインのサーバー証明書に新しい認証局 (CA) を導入します。現在、login.microsoftonline.com への接続には、DigiCert の証明書が使用されています。2024 年 10 月 1 日以降、Microsoft Azure CA によって発行された証明書も提示される可能性があります。このアップデートは、Entra ID のセキュリティを強化し、耐障害性を向上させるためのものです。これにより Microsoft Azure CA を信頼していないお客様や、クライアント側を DigiCert の証明書に固定しているお客様は、認証に失敗する可能性があるため、影響を受ける可能性があります。
推奨される対策:
問題の発生を防ぐために、Azure 証明書の公開ドキュメント に記載されているすべてのルート認証局および下位認証局を信頼することを推奨します。この文書には、1 年以上前から Microsoft Azure CA が含まれています。login.microsoftonline.com ドメインを使用している Entra ID ユーザーにおいては、シームレスな移行のために、DigiCert へのクライアント側の固定をすべて解除し、新しい Azure CA を信頼することが重要です。中断のない安全なサービスを保証する方法の詳細については、パブリック PKI のクライアント互換性に関するドキュメント をご確認ください。
[対応不要です]
先月、Microsoft Entra アカウントを持つユーザー向けの無料の Microsoft Copilot サービスにいくつかのアップデートを行い、データ セキュリティ、プライバシー、コンプライアンスを強化し、ユーザー体験をよりシンプルなものにしました。ユーザーが Entra アカウントでサインインすると、Microsoft Copilot によりエンタープライズ データ保護 (EDP) が提供され、エンタープライズ環境および教育向けに設計された、より新しくシンプルな、広告なしのユーザー インターフェイスにユーザーは誘導されます。
Microsoft Copilot の EDP を使用すると、データは外部で利用されることなく、基盤モデルの学習に使用されることもありません。EDP の詳細については、当社のドキュメント を参照ください。
また、お客様が Entra アカウントに加えて Microsoft 365 サブスクリプションをお持ちの場合、Microsoft Copilot をピン留めすることでアプリ内アクセスを有効にできます。Microsoft Copilot をピン留めすると、9 月中旬から Microsoft 365 アプリ内でも Microsoft Copilot が表示されるようになり、Microsoft Teams と Outlook にも近日中にこの機能が追加される予定です。Microsoft Copilot のチャット履歴などの追加機能は、Microsoft 365 のサブスクリプションを契約しているユーザーも利用できます。
Microsoft 365 サブスクリプションの有無にかかわらず、これらの変更に関する追加情報については、当社の ブログおよび FAQ をご覧ください。
Microsoft Copilot のこれらのアップデートについては、今後のさらなる機能をお楽しみにお待ちください。9 月中旬より前に、エンタープライズ データ保護機能を搭載した Microsoft Copilot のアップデートを試用されたい場合は、プライベート プレビューをご利用いただけます (数に限りがあります)。お申し込みは フォーム にご記入ください。
[対応不要です]
継続的なセキュリティ強化の一環として、Android 用の Authenticator および Company Portal アプリにおける Enable Browser Access (EBA) のユーザー インターフェイスが廃止されます。その結果、すべての Android ユーザーでブラウザーでのアクセスが既定で有効になります。この変更は自動的に行われるため、管理者や Android ユーザーからの対応は必要ありません。
[対応不要です]
継続的なセキュリティ強化の一環として、特権をもつ “ディレクトリ同期アカウント” ロールから未使用の権限を削除しました。このロールは、Connect Sync および Cloud Sync が Entra ID と Active Directory オブジェクトを同期するためにのみ使用されます。この機能強化の恩恵を受けるために、お客様が何らかの対応を行う必要はありません。変更されたロール権限の詳細については、ドキュメント を参照ください。
[対応不要です]
ユーザーが Windows デバイスにアカウントを追加する際のエンド ユーザー体験について、いくつかの改善を行っています。SSO 登録ダイアログ (同意画面) の表示内容を改善し、エンドユーザーから見える選択項目とその影響をわかりやすくする予定です。この変更には、画面上に ‘Learn more’ のリンクを表示する変更も含まれます。このリンクをクリックすると、ユーザーが十分な情報を得た上で項目を選択できるよう、より詳細な情報を提供する Microsoft Learn の記事が開きます。新しい SSO 登録ダイアログは、2024 年 10 月から順次導入される予定です。詳細は こちら をご覧ください。
[対応が必要な場合があります]
Azure AD Graph API サービスの廃止 は 2024 年 9 月 1 日に開始され、最終的には新規および既存のアプリケーションの両方に影響を与えます。今後数週間かけて廃止に向けたフェーズを開始します。新しいアプリケーションは、アクセスを延長するよう設定されていない限り、Azure AD Graph API を使用できなくなります。 Microsoft Graph が Azure AD Graph APIs の移行先です。Azure AD Graph API を利用されているお客様は直ちに Microsoft Graph に移行し、Azure AD Graph API を使用した今後の開発を行わないようにすることを強く推奨します。
フェーズ開始日 | 既存アプリへの影響 | 新規アプリへの影響 |
---|---|---|
2024 年 9 月 1 日 | なし。 | なし。 |
2025 年 2 月 1 日 | アプリケーションは、blockAzureAdGraphAccess を false に設定して Azure AD Graph へのアクセスを延長して許可するようにアプリが構成されている場合を除き Azure AD Graph API へのリクエストを行うことができなくなります。 | 新しいアプリでは、blockAzureAdGraphAccess を false に設定して Azure AD Graph アクセスを延長して許可するようにアプリが構成されている場合を除き、 Azure AD Graph API の使用がブロックされます。新しいアプリでは Microsoft Graph を使用するとを強く推奨します。 |
2025 年 7 月 | Azure AD Graph が完全に廃止されます。Azure AD Graph API リクエストは機能しなくなります。 | Azure AD Graph が完全に廃止されます。Azure AD Graph API リクエストは機能しなくなります。 |
必要な対応:
サービスの中断を避けるために、アプリケーションを Microsoft Graph API に移行する手順 に従って、アプリを移行ください。
アプリの Azure AD Graph アクセスを 2025 年 7 月まで延長する必要があるお客様へ
アプリがまだ Microsoft Graph に移行を完了していない場合は、この廃止期限を延長可能です。アプリケーションの authenticationBehaviors の構成で blockAzureADGraphAccess 属性を false に設定すると、アプリケーションは 2025 年 6 月 30 日まで Azure AD Graph API を使用できます。詳細なドキュメントは こちら をご覧ください。
この設定を false に設定しない限り、新しいアプリケーションは Azure AD Graph API にアクセスしようとすると 403 エラーを受け取ります。2024 年に Microsoft Graph への移行が完了しない既存のアプリケーションについては、今すぐこの設定を行うようご対応ください。
Azure AD Graph API を使用しているテナント内のアプリケーションを特定する必要があるお客様へ
Microsoft Entra の推奨事項 は、テナントを安全で健全な状態にするための推奨事項を提供し、同時に、Entra ID で利用可能な機能の価値をお客様が最大化できるようにする機能です。
この機能では、テナント内で Azure AD Graph API を頻繁に使用しているアプリケーションとサービス プリンシパルに関する情報を表示する 2 つの Entra の推奨事項 を提供します。これらの新しい推奨事項は、影響を受けるアプリケーションとサービス プリンシパルを特定し、お客様が Microsoft Graph に移行しやすくするよう支援します。
参考:
[対応が必要な場合があります]
2024 年 3 月 30 日をもって、レガシーの Azure AD PowerShell、Azure AD PowerShell Preview、および MS Online モジュールは非推奨 となりました。これらのモジュールは 2025 年 3 月 30 日まで機能し続けますが、それ以降は廃止され、機能しなくなります。Microsoft Graph PowerShell SDK が、これらのモジュールの代替となるため、できるだけ早くスクリプトを Microsoft Graph PowerShell SDK に移行する必要があります。
テナントでの Azure AD PowerShell の使用状況を確認するために、「Migrate Service Principals from the retiring Azure AD Graph API to Microsoft Graph」 と題された Entra 推奨事項 を使用することができます。この推奨事項は、AzureAD PowerShell を含め、テナント内で Azure AD Graph API を使用しているアプリケーションを表示します。
最近ですが、Microsoft Entra PowerShell モジュールのパブリック プレビューが開始されました。この新しいモジュールは、Microsoft Graph PowerShell SDK をベースに構築され、シナリオに特化したコマンドレットを提供します。Microsoft Graph PowerShell SDK のすべてのコマンドレットと完全に相互運用可能で、シンプルでドキュメント化されたコマンドで複雑な操作を実行できます。また、このモジュールは 非推奨の AzureAD モジュールからの移行をより簡単にするための下位互換性オプションも提供しています。
Microsoft Graph API は最近、「ユーザーごとの MFA」設定の読み取りおよび構成が 可能となりました。Microsoft Graph PowerShell SDK コマンドレットでも近日中に利用できるようになる予定です。
[対応が必要な場合があります]
これは、9 月中旬に Microsoft Entra 管理センターおよび Microsoft Azure 管理ポータルでのユーザーおよびグループのライセンス割り当ての変更がサポートされなくなったことの再度のお知らせです。今後は、これらのポータルでのライセンス割り当ては読み取り専用となります。ポータルからユーザーとグループのライセンス割り当てを変更する場合は、Microsoft 365 管理センター にアクセスする必要があります。なお、この変更は API や PowerShell モジュールには影響しません。ライセンス割り当てに関する問題が発生した場合は、Microsoft 365 サポートまでご連絡ください。詳細については、こちらをクリック ください。
[対応が必要な場合があります]
2024 年 10 月に、Microsoft Graph 用の Bicep テンプレート (パブリック プレビュー) に機能更新が実施されます。この動的な型の機能は、ベータ版と v1.0 の両方で、Microsoft Graph Bicep 型のセマンティック バージョニングを可能にします。Bicep ファイルの編集中に、現在の方法である Nuget パッケージを使用するのでなく、Microsoft artifact レジストリ から参照される Microsoft Graph Bicep 型のバージョンを指定可能になります。動的な型を使用することで、将来的に破壊的変更が生じても、古いバージョンのリソース型を使用する既存の Bicep ファイルのデプロイに影響を与えることなく、既存の Microsoft Graph Bicep リソース型を使用し続けることができます。
既定で用意されている型は非推奨になり、2025 年 1 月 24 日に廃止されます。廃止日まで、現在の既定の型は新しい動的な型と共存します。Microsoft Graph Bicep の型の変更は、新しいバージョンの動的型でのみ利用可能となります。
必要なアクション:
Bicep テンプレートの展開が失敗しないようにするため、2025 年 1 月 24 日までに新しい動的な型に切り替えるようご対応ください。この切り替えには、bicepconfig.json とメインの Bicep ファイルを少し更新する必要があります。さらに、更新された、または新しい Microsoft Graph リソース タイプを利用するには、Bicep ファイルが使用する型バージョンを更新する必要があります。次のステップについては、こちらをクリック ください。
[対応不要です]
2024 年 10 月 31 日より、Entra ポータルのレガシーなユーザー インターフェイス (UI) でユーザーの認証方法を管理する機能を廃止します。その代わりに、レガシーな UI と完全な互換性を持ち、最新の方法 (Temporary Access Pass、パスキー、QR+Pin など) と設定を管理できる新しい UI を提供します。これは、エンド ユーザーが自身の認証方法を管理する方法や、Entra にサインインする機能には影響しません。詳しくは、Microsoft Entra 多要素認証のユーザー認証方法の管理 をご覧ください。
[対応不要です]
EBA は、Android ブローカー アプリ (Company Portal や Authenticator など) の機能で、Entra ID のデバイス登録証明書を Android デバイス上のグローバル キーチェーンに複製する機能です。これにより、Chrome などのブローカーと統合されていないブラウザでも、Entra のデバイス準拠ポリシーに対応するために必要なデバイス認証用の証明書にアクセスできるようになります。
全体的なセキュリティ強化の一環として、Entra ID のデバイス登録証明書と Android デバイス ID をハードウェアに固定して紐づけるよう移行を進めています。これにより、将来的にトークン保護ポリシーが適用可能になり、さらにデバイス準拠ポリシーを迂回できないようにすることも可能になります。この移行により、デバイス ID がハードウェアにバインドされるようになるため、EBA UI では鍵を複製してエクスポートすることができなくなります。Authenticator および Company Portal アプリの Enable Browser Access (EBA) UI は廃止され、ブラウザー アクセス (Chrome など) はデバイス登録時に自動的に有効化される予定です。
この機能は、Intune MDM ユーザーには既に提供されています。今回の変更は、VMWare や Jamf モバイル デバイス管理 (MDM) ソフトウェアを使用しているユーザーなど、Intune 以外のユーザーを対象としたものです。この変更は、2025 年上半期にすべてのお客様に適用されます。現時点では、お客様側での対応は何も必要ありません。
[対応不要です]
Microsoft Entra 管理センターのセルフサービスのグループ管理の設定には「My Groups のグループ機能にアクセスできるユーザーを制限する」という設定があり、この設定は 2024 年 6 月に廃止予定であるということが 2023 年 10 月に発表 されました。この変更は現在も引き続き検討中であり、当初の廃止予定は一旦延期されました。新しい廃止予定日は今後発表される予定です。
[対応不要です]
2024 年 8 月より、セキュリティ情報ページの「サインイン方法の追加」ダイアログが更新されました。サインイン方法の説明が改善され、新しい見た目や使い心地になりました。この変更により、ユーザーが「サインイン方法の追加」をクリックすると、最初に、組織の認証方法ポリシーで許可されている、利用可能な最も強力な方法の登録が推奨されます。また、ユーザーは「その他のオプションを表示」を選択し、ポリシーで許可されているすべての利用可能なサインイン方法から選択することもできます。管理者の操作は必要ありません。
[対応不要です]
現在のアプリケーション/HR プロビジョニングとクロステナント同期の UX を刷新します。この変更には、新しい概要ページに加え、アプリケーションへの接続、スコープ、および属性マッピングを構成するユーザー体験の刷新が含まれます。新しいユーザー体験には、現在お客様が利用可能なすべての機能が含まれており、お客様による対応は必要ありません。新しいユーザー体験は、2024 年 10 月末から順次提供を開始しますが、2024 年 1 月までは既存のユーザー体験をご利用いただけます。
[対応が必要な場合があります]
My Access において、ユーザーにお勧めのアクセス パッケージが一覧で表示されるという新機能が追加されます。これにより、ユーザーはアクセス パッケージの一覧をスクロールして探すことなく、最も関連性の高いアクセス パッケージを素早く閲覧できるようになります。テナントにあるすべてのアクセス パッケージを一覧して検索することも可能です。この変更は、10 月末までにプレビュー (オプトイン) としてすべてのお客様に展開され、展開後はこの変更についてお知らせする製品内のメッセージが画面上に表示されます。11 月末までにオプトアウトのプレビューに移行し、12 月に一般提供を開始する予定です。
[対応が必要な場合があります]
2024 年 10 月初旬より、Microsoft Entra Internet Access および Microsoft Entra Private Access のライセンス強制が Microsoft Entra 管理センターで開始されます。これは、2024 年 7 月に開始された Microsoft Entra Internet Access および Microsoft Entra Private Access の一般提供から 90 日間の通知期間に続くものです。Global Secure Access の詳細については、こちら をご覧ください。
どちらのライセンスも 30 日間のトライアルが可能です。 価格については こちら をご覧ください。
Shobhit Sahay
]]>本記事は、2024 年 9 月 18 日に米国の Azure Active Directory Identity Blog で公開された Microsoft Entra Internet Access now generally available - Microsoft Community Hub を意訳したものになります。ご不明点等ございましたらサポート チームまでお問い合わせください。
ハイブリッドな働き方が増すにつれ、ID とネットワークのセキュリティ専門家たちは組織を守るための最前線に立たされています。従来のセットワーク セキュリティのツールでは、統合性、複雑性、スケーラビリティという、どこからでもアクセスが可能という昨今のネットワーク環境の要件を満たせなくなっており、組織はセキュリティ リスクと劣悪なユーザー体験にさらされています。これを解決するために、ネットワーク セキュリティと ID を一体化した保護が必要です。ID とネットワークの制御がセキュリティの制御に高度に組み込まれることで、暗黙的な信頼なく、すべてのユーザー、デバイスおよびアプリケーションに対して、必要な対象に必要最低限の特権が許可されるというゼロ トラストの概念に基づく環境を提供可能となります。
2024 年 7 月 11 日に Microsoft Entra Suit の 一般提供を発表 しました。この Microsoft Entra Suit には Security Service Edge (SSE) ソリューションの一部である Microsoft Entra Internet Access が含まれております。Microsoft Entra Internet Access は、ID を中心に据えたセキュア ウェブ ゲートウェイ (SWG) ソリューションにより、すべてのインターネットおよび SaaS アプリケーションやリソースへのアクセスを保護します。これにより、ID およびネットワーク アクセスの制御が単一のゼロ トラスト ポリシー エンジンを通じて統合され、これまでカバーできていなかったセキュリティの抜け穴が解消されるとともに、サイバー脅威のリスクを最小限に抑えることが可能となります。我々のソリューションは、Microsoft Entra ID をシームレスに統合し、複数の場所 (ツールなど) でユーザー、グループおよびアプリケーションを管理する負担を軽減します。ユニバーサル条件付きアクセス、文脈を意識したネットワーク保護およびウェブ コンテンツ フィルターによってユーザー、デバイスおよびアプリケーションを保護しますので、バラバラな複数のネットワーク セキュリティ ツールの管理に悩むことはなくなります。
Entra ID との強力な統合によって、条件付きアクセスや継続的なアクセス評価 (CAE) をインターネット上のリソースやクラウド アプリケーションなど、Entra ID とフェデレーションしていない 外部の対象にまで拡張 できます。条件付きアクセスとの統合により、組織に合わせてカスタマイズしたネットワーク保護ポリシーを柔軟に適用し、デバイス、ユーザー、場所およびリスク条件を活用しながら、きめ細かい制御を強制することが可能になります。さらに、Microsoft Entra Internet Access はトークン再生攻撃からの防御やデータ流失の制御などの強化されたセキュリティ機能も提供します。
Microsoft Entra Internet Access により ネットワークを対象としたセキュリティ ポリシーを条件付きアクセスと連携させる ことができるようになるため、SWG のポリシーを強制するにあたり、お客様は様々なシナリオに対応できる新たなツール得ることになります。Web カテゴリ フィルター により、事前に用意された ウェブ カテゴリ にもどづいて広範なインターネット アクセス先を許可/ブロックするような構成を実現できます。さらにきめ細かいポリシーを構成したい場合は、完全修飾ドメイン名 (FQDN) フィルターを利用して、特定のエンドポイント用のポリシーを設定したり、既定の Web カテゴリー ポリシーを上書きしたりすることも可能です。
例えば、会計部門のチームに重要な会計アプリケーションへアクセスを許可する一方で、組織のほかの部門からアクセスを制限するようなポリシーを作成できます。また、Entra ID Protection によってユーザー リスクが上昇したメンバーに対しては、動的にユーザーのリスク レベルに対応し、これら重要なリソースへのアクセスを制限するリスクベースのフィルター ポリシーを追加することも可能です。これにより組織に対し、より強力な保護を提供することができます。さらに別の例としては、Microsoft Entra Internet Access、条件付きアクセス、および Entra ID Govermance ワークフローを組み合わせて活用することで、Dropbox に Just-In-Time アクセスを実現し、ほかのすべての外部ストレージ サイトへのアクセスはブロックするいうことも可能です。
今後、TLS インスペクションおよび URL フィルターの機能を追加し、Web フィルター ポリシーでさらにきめ細かい制御ができるようにする予定です。加えて、既知の悪意あるインターネット サイトへのユーザーによるアクセスを防ぐために、脅威インテリジェンス (TI) のフィルターも追加する予定です。
新機能である 準拠ネットワーク の制御により、Microsoft 365 アプリケーションを含め Entra ID とフェデレーションしているインターネット アプリケーションに対し、準拠ネットワークのチェック機能を条件付きアクセスと組み合わせて適用できるため、認証プレーン全体でトークン再生攻撃を防ぐことが可能となります。この機能により、ユーザーがアプリケーションにアクセスする際に、SSE のセキュリティ機能を迂回できないようにできます。送信元 IP を用いた場所に基づく強制には、煩雑な IP 管理に加え、支店ネットワークを経由してアクセスしてくるユーザーとトラフィックの紐づけという固有の問題点がありますが、準拠ネットワークの機能を用いればその欠点も解消可能です。
Microsoft Entra Internet Access では OS やブラウザに依存せず、すべての管理対象デバイスで ユニバーサル テナント制限 の制御を有効にできます。テナント制限 v2 は強力なデータ流出防止機能であり、外部の ID およびアプリケーションへアクセス可能/不可能かを許可または拒否リストできめ細かく選定することにより、管理対象デバイスおよびネットワークに対する外部からのアクセスのリスクを管理可能となります。
従来のサードパーティ SEE ソリューションはユーザーの送信元 IP を隠し、プロキシー サーバーの IP アドレスだけを見せますが、これでは Entra ID ログの信頼性が低下し、条件付きアクセスの制御においても制御の正確性が損なわれます。我々のソリューションでは、Entra ID の監査ログやリスク評価において可能な限り エンドユーザーの送信元 IP を復元 します。これにより、条件付きアクセス ポリシーで送信元 IP ベースの場所チェックを引き続き利用できますので、後方互換性も維持できます。
弊社はグローバル規模でプロキシを展開しており、インターネットへ流れるトラフィックを最適化するためにユーザーの近くにエンドポイントを展開し、通信に必要なホップ数を削減しています。ユーザーからわずか数ミリ秒の距離にある弊社のグローバル セキュア エッジを経由して、リモートワークをしている従業員や支店とをつなげることができるのです。弊社はインターネット プロバイダーや SaaS サービスと数千のピアリングの接続を保持しており、加えて、Microsoft 365 および Azure のようなサービスには Microsoft WAN 基盤へ直接トラフィックを送ることにより、追加の通信ホップによるパフォーマンス劣化を回避しつつ、全体のユーザー エクスペリエンスを向上させています。
弊社が提供する製品内の包括的なレポートとダッシュボードにより、お客様は手軽に詳細情報を確認でき、組織全体のエコシステムを完全に把握可能です。包括的なネットワークとポリシー監視のログを通して展開状況を監視でき、緊急な脅威も特定でき、さらに迅速に問題に対処できます。このダッシュボードでは、ユーザー、デバイスおよび Microsoft の SSE ソリューションを経由した接続先の概要情報を確認可能です。企業内で行われるクロステナント アクセスの状況や、よくアクセスしているネットワーク接続先、その他のポリシーの解析情報も表示しています。
Microsoft SSE の クライアント と リモートネットワーク のアーキテクチャによりネットワーク アクセスとセキュリティが効率されます。デバイスで動作する Global Secure Access クライアントは現在 Windows と Android で利用可能です。MacOS と iOS 用のものは近日に公開されます。拠点間の接続は、ネットワーク デバイスから Microsoft の SSE エッジサービスへの Site-To-Site 接続に基づいて動作します。Microsoft トラフィック はすでに一般公開されていますが、インターネット アクセス プロファイル も近日に追加される予定です。エンドユーザーのデバイスと拠点ネットワーク間の通信モデルは Microsoft の SSE エッジを経由して保護およびトンネリングされています。さらに、弊社は HPE Aruba と Versa とパートナー提携を行い、弊社の SSE ソリューションと SD-WAN ソリューションとを統合するべく取り組んでいます。近日には他のパートナーとも追加の提携を行う予定です。
Microsoft の SSE の独自の利点の 1 つは サードパーティの SSE ソリューション と既定で互換性がある点です。これにより必要な通信だけを Microsoft の SSE エッジに流れるようにできます。例えば、Microsoft トラフィック プロファイルを利用して、Microsoft 365 と Entra ID の通信だけを管理し、Microsoft アプリケーションへのアクセスのパフォーマンスを最適化しつつ、他の通信は別のプロバイダーで管理するように構成可能です。トラフィック転送プロファイルの構成はシンプルなので、インターネットおよび Microsoft 365 を含めた SaaS アプリケーションへの通信を正確に制御できます。トラフィック プロファイルはユーザーごとに設定できますので、組織の要件に応じてグループ単位で割り当てることもできます。
Microsoft Entra Internet Access は強力な ID 中心の SWG ソリューションであり、インターネットおよび SaaS アプリケーションへの通信をセキュリティで保護します。ID、エンドポイントおよびネットワークを横断して条件付きアクセスに統合することより、ハイブリッドな職場環境の要件を満たし、高度なサイバー攻撃にも対処できます。この戦略的な取り組みにより、セキュリティの強化だけでなく、ユーザー体験の最適化も実現されます。これこそが、クラウド ファーストの環境への移行をリードていくという Microsoft のコミットメントを示しています。
Microosft Entra Internet Access のブログや Microsoft Entra Private Access の Deep Dive にもご注目ください。より詳細については、弊社の直近の Tech Accelerator product deep dives もご覧ください。
利用を開始したい場合は、Microsoft の営業担当に連絡し、トライアルを開始して、一般公開された Microsoft Entra Internet Access と Microsoft Entra Private Access をお試しください。このソリューションをよりよくするために、ご意見がありましたら是非お知らせください。
Anupma Sharma, Principal Group Product Manager
]]>こんにちは、Azure & Identity サポート チームの 西口 です。
今回は Microsoft Entra ID (ME-ID) のデバイス オブジェクトの属性について解説します。ME-ID に登録できるデバイスの概要については、以下のブログを参照ください。
ある ME-ID のデバイス オブジェクトの属性情報を確認すると一口に言っても以下のような複数の見方があります。
上記のように、1 つのデバイス オブジェクトを [複数の見方] で把握することが可能ですが、例えば [Microsoft Entra 管理センターから、あるデバイス オブジェクトの情報を参照した時] と [Graph Explorer で同じデバイス オブジェクトの情報を取得した時] で、微妙に表示されている属性名が異なることや表示されている/されていない属性の差があることで、それぞれの見方で得た情報の対応付けで困ったことはありませんか?
上記のようなお悩みを抱えている方に向けて、本ブログはデバイス オブジェクトの代表的な確認方法と、それぞれの方法で参照した属性の対応付けについて紹介します。
ME-ID というディレクトリ上に登録された、種類がデバイスであるオブジェクト レコードのことを意味します。以下の公開情報の Microsoft Graph API のデバイス リソース型の説明にも含まれていますが、デバイス オブジェクトには複数のプロパティ情報が含まれています。
デバイス リソース型 - Microsoft Graph v1.0 | Microsoft Learn
それでは、以下のデバイス オブジェクトの代表的な 3 つの確認方法をご紹介します。
a. Microsoft Entra 管理センターでの確認方法
b. Graph Explorer での確認方法
c. Microsoft Graph PowerShell での確認方法
Microsoft Entra 管理センターのポータルからデバイス オブジェクトの情報を参照する手順は以下の通りです。
上記の操作をすると以下のようにデバイス オブジェクトの情報が表示されます。以下の表示結果からは、該当デバイス オブジェクトの複数の属性情報 (名前やデバイス ID など) を把握することができますが、実はこれが該当デバイスの属性情報のすべてではありません。
なお、Microsoft Entra 管理センターからでは確認できない属性は、以降にご案内する b. Graph Explorer や c. Microsoft Graph PowerShell の方法から確認できます。
ME-ID のデバイス オブジェクトの属性の一覧と、上記の [Microsoft Entra 管理センターで確認できるデバイスの属性] との対応付けは、4 章の [デバイス オブジェクト属性の各確認方法で表示される内容の比較表] に記載の表 1 をご確認ください。
Graph Explorer からデバイス オブジェクトの情報を参照する手順は以下の通りです。
ブラウザーから Graph Explorer にアクセスしてサインインします。
左のブレードの [ID とアクセス] > Azure AD デバイスの一覧を選択します。
Modify permissions から Device.Read.All を同意します。
クエリ として、https://graph.microsoft.com/v1.0/devices/{確認したいデバイスのオブジェクト ID
を指定し、Run query をクリックします。
上記の操作をすると以下のようにデバイス オブジェクトの情報が表示されます。以下の表示結果からは、Microsoft Entra 管理センターで確認できるデバイス オブジェクトの属性の数より多くの属性を確認できました。
ご参考: 弊社環境での Graph Explorer でのデバイス オブジェクトの情報取得例
Microsoft Graph API クエリ: https://graph.microsoft.com/v1.0/devices/03305133-d59c-4f4e-b6cb-2ad2c5d1a6f1
出力結果:
ME-ID のデバイス オブジェクトの属性の一覧と、上記の [Graph Explorer で確認できるデバイスの属性] との対応付けは、4 章の [デバイス オブジェクト属性の各確認方法で表示される内容の比較表] に記載の表 1 をご確認ください。
上記の a. および b. はブラウザーを用いて情報が確認できましたが、Microsoft Graph PowerShell でデバイス オブジェクトの情報を取得するには、最初に作業する端末上に PowerShell モジュールのインストールが必要です。インストール方法については以下の参考情報があります。
MSOnline / AzureAD PowerShell から Graph PowerShell SDK への移行について 3_インストール・接続編
Microsoft Graph PowerShell からデバイス オブジェクトの情報を参照する手順は以下の通りです。
Windows のスタートボタンから Windows PowerShell を起動します。
以下のコマンドを入力し、Microsoft Graph で ME-ID テナントにサインインします。認証画面が表示されるので、サインインしたい ME-ID テナントのユーザーとしてサインインします。
Connect-MgGraph -Scopes “Device.Read.All”
Get-MgDevice -DeviceId コマンドで確認したいデバイスのオブジェクト ID を入力します。
Get-MgDevice -DeviceId “オブジェクト ID” | fl
※ 少々紛らわしくて恐縮ですが、-DeviceId パラメーターで指定するのは [(デバイス ID ではなく) オブジェクト ID] です。
今回使った Get-MgDevice コマンドの詳細につきましては、英語の公開情報ですが、以下に記載があります。
Get-MgDevice (Microsoft.Graph.Identity.DirectoryManagement) | Microsoft Learn
上記の操作をすると以下のようにデバイス オブジェクトの情報が表示されます。以下の表示結果からは、Microsoft Entra 管理センターより多くの該当デバイス オブジェクトの属性情報を把握することができます。また、OnPremisesSecurityIdentifier については項目に表示されますが、値は入りません。
ご参考: 弊社環境での Microsoft Graph PowerShell でのデバイス オブジェクトの情報取得例
ME-ID のデバイス オブジェクトの属性の一覧と、上記の [Microsoft Graph PowerShell で確認できるデバイスの属性] との対応付けは、4 章の [デバイス オブジェクト属性の各確認方法で表示される内容の比較表] に記載の表 1 をご確認ください。
上記の 3 つの確認方法で得られた情報を、以下の表 1 にまとめました。N/A の記載は [その項目の表示が存在していない] ことを意味します。Microsoft Entra 管理センターで表示されている属性名と、実際のオブジェクトの属性名では微妙に表記が異なっていることも確認できます。これは、ポータル上でオブジェクトの情報を確認する際に、見えている情報の意味が分かりやすいよう表現を変えている場合があるためです。たとえば、Microsoft Entra 管理センターで見ることができる “準拠している” は、isCompliant に対応していることが以下の表 1 からわかります。また、Microsoft Entra 管理センターから得ることができない情報については、Graph Explorer / Microsoft Graph PowerShell で確認でき、Graph Explorer / Microsoft Graph PowerShell いずれも同じ情報を得られることがわかりました。以下の表 1 を元に、お客様のご用途に合うデバイス オブジェクトの確認方法をご利用ください。
これまで、デバイス オブジェクトの属性情報を確認する複数の方法についてご紹介しました。この複数の視点での情報の見方がどのような場合に役立つのか、という例として、条件付きアクセス ポリシーでデバイス フィルター条件でのアクセス制御を行う際の設定シナリオを元に例をご紹介します。条件付きアクセスのデバイスのフィルターに関しては、以下の公開情報にてご案内しております。
条件付きアクセス ポリシーの条件としてのデバイスのフィルター - Microsoft Entra ID | Microsoft Learn
デバイスのフィルターで利用可能なデバイス属性は複数ありますが、Microsoft Entra 管理センターでデバイス オブジェクトを参照した際は、これまでのご案内の通り一部の属性情報のみが確認可能です。そこで、Microsoft Graph PowerShell や Graph Explorer も併用いただくことで利用したい属性の情報をご確認いただくことが可能です。
以下に [デバイスのフィルターで利用可能な属性] という視点で、抜き出した状態で上記 a. b. c. それぞれの確認方法で取得可能なデバイス オブジェクトの属性情報の対応をおまとめしました。
※ mdmAppId は [該当の ME-ID デバイスが MDM 管理されている] 場合、MDM 管理アプリケーションのアプリケーション ID 表示されますので、以下の表 3 に対応表をまとめました。
本ブログでは、デバイス オブジェクトの属性の代表的な確認方法と、対応付けについてをまとめ、デバイス情報の活用例をご紹介しました。これらの情報を条件付きアクセスのデバイスのフィルターの作成などのシナリオでご活用ください。
なお、2024 年 9 月現在の情報を元に本記事を作成しております。
]]>Microsoft Entra Connect 2.3.20 のインストールおよびアップグレードを試みた際にエラーが出力され、インストールおよびアップグレードに失敗します。もしくは、インストールおよびアップグレードには成功しますが、その後の同期処理に失敗します。これは Microsoft Entra Connect と Microsoft Entra ID の間で TLS 1.2 にて通信を行えていない事が原因です。以下に、問題が発生した場合に出力される可能性のあるエラー例をお伝えします。
インストールを試みた際に、インストール ウィザードの構成画面にて、”An error occurred executing Configure AAD Sync task: An error occurred while sending the request.” のエラーが表示されインストールに失敗する事象が確認されております。
インストール時のエラー画面例:
また、アップグレードを試みた際に、インストール ウィザードの資格情報入力画面にて、正しい権限を持つ有効なアカウントを入力したのにも関わらず、エラーが出力される事象が発生するとのお問い合わせを多数お寄せいただいております。
アップグレード時のエラー画面例:
アップグレード以降の同期サイクルにおいて、Microsoft Entra ID のコネクタにおける Import 処理や Export 処理が、”no-start-ma” や “stopped-extension-dll-exeption”, “stopped-server” などが記録されて失敗する事象を確認しています。
Synchronization Service Manager の例:
システム イベント ログの例:
アプリケーション イベント ログの例:
Microsoft Entra Connect と Microsoft Entra ID の間で TLS 1.2 にて通信を行えていない事がエラー発生の原因です。Microsoft Entra Connect のバージョン 1.2.65.0 以降では、 Microsoft Entra ID との通信に対して TLS 1.2 のみの使用が完全にサポートされております。また、Microsoft Entra Connect 2.3.20 では、導入サーバーにてレジストリにて TLS 1.2 を明示的に有効化することがインストールの要件となっております。
Microsoft Entra Connect 2.3.20 のインストールおよびアップグレードを行う前に、導入サーバーにてレジストリに TLS 1.2 を有効化する値を登録して明示的に有効化する必要がございます。以下に、TLS 1.2 のレジストリ登録状況の確認方法と TLS 1.2 のレジストリ登録方法を記載いたします。
まず、Microsoft Entra Connect を導入するサーバーで PowerShell を管理者権限で開き、下記のドキュメントに記載された [TLS 1.2 をチェックするための PowerShell スクリプト] を実行し、TLS 1.2 のレジストリ登録状況を確認します (スクリプトを実行した結果、Value が Not Found となっている場合は、TLS 1.2 用のレジストリが構成されていないと判断可能です)。
Microsoft Entra Connect に対する TLS 1.2 の強制 | TLS 1.2 をチェックするための PowerShell スクリプト
TLS 1.2 が構成されていないことを示す出力の例:
適切な TLS 1.2 構成を示す出力の例:
まず、下記のドキュメントに記載された [TLS 1.2 を有効にする PowerShell スクリプト] を実行し、レジストリに TLS 1.2 を登録して明示的に有効化します。
Microsoft Entra Connect に対する TLS 1.2 の強制 | TLS 1.2 を有効にする PowerShell スクリプト
次に、導入サーバーを再起動します。これらのレジストリを登録することにより、これまで .NET Framework アプリケーションが TLS 1.2 以外を用いて通信を行っていた場合には TLS 1.2 を用いて通信を行うようになります。一般的には TLS 1.2 が推奨されており、 TLS 1.2 を用いて通信を行うことに問題はございませんが、もし問題が生じた際にはこれらのレジストリを削除頂いた上で、再度再起動頂くことで元の状態に戻すことが可能です。
TLS 1.2 のレジストリを設定後も同期が行えない、インストールが行えない場合には弊社サポートまでお問い合わせください。
]]>本記事は、2024 年 7 月 26 日に米国の Microsoft Entra (Azure AD) Blog で公開された Migrate ADAL apps to MSAL with enhanced insights の抄訳です。ご不明点等ございましたらサポート チームまでお問い合わせください。
Microsoft Entra 管理センターのサインイン ワークブックの大幅なアップデートを発表いたします。このツールは、Azure Active Directory Authentication Libraries (ADAL) から Microsoft Authentication Libraries (MSAL) へ移行する組織で有用活用いただけるものです。これらのアップデートは、ADAL を利用するアプリケーションの関連データについて包括的な分析情報を提供することで、ADAL の移行プロセスを最適化することを目的としています。
弊社は 2020 年 6 月に ADAL の終了を、2023 年 6 月にセキュリティ アップデートのサポート終了を 発表 しました。つまり、ADAL を使用しているアプリケーションは最新のセキュリティ機能を利用できず、将来のセキュリティの脅威に対して脆弱なままとなります。クライアント アプリケーションの認証と認可のセキュリティ態勢と耐障害性を改善するために、ADAL を使用しているアプリケーションを MSAL に移行することを強くお勧めします。
MSAL は、マネージド ID、継続的アクセス評価 (CAE)、パスキー、その他もろもろなど、Microsoft Entra ID の最新のセキュリティ機能をサポートしています。このたび更新されたサインイン ワークブックはこの移行に不可欠なツールであり、移行を実行するにあたって十分な情報に基づいた意思決定に必要な分析情報とデータを提供します。
サインイン ワークブックは、テナント内で ADAL を使用しているアプリケーションを一元的かつ詳細に表示したいという要望を持つ管理者向けに再設計されています。これらの追加された分析情報により、MSAL への移行を成功させるための ADAL アプリケーションの特定、調査、検証が容易になります。
以下は、最新の機能強化で得られるものの一覧です:
まずは、ワークブックにアクセスして、すべての ADAL アプリケーションと、それらに関連する詳細のリストを取得する ことから始めましょう。移行ガイド では、ADAL を使用するアプリケーションから MSAL を使用するアプリケーションに移行するためのすべての手順について説明しています。
Neha Goel
Senior Product Manager, Microsoft
Note
本記事は Technet Blog の更新停止に伴い https://blogs.technet.microsoft.com/jpazureid/2018/04/18/aad-notification/ の内容を移行したものです。
元の記事の最新の更新情報については、本内容をご参照ください。
Azure Identity サポートの橋本です。
-日本時間の 4 月 18 日に、一部の Azure AD Connect のご利用者様 (テナント管理者) 宛に、以下のような、”Action required: your sync solution is no longer supported and you need to upgrade to a newer version “ という件名のメールが AAD Notification aad-notification-noreply@azureemail.microsoft.com より配信されました。
+日本時間の 4 月 18 日に、一部の Azure AD Connect のご利用者様 (テナント管理者) 宛に、以下のような、”Action required: your sync solution is no longer supported and you need to upgrade to a newer version “ という件名のメールが AAD Notification aad-notification-noreply@azureemail.microsoft.com より配信されました。
本メールは弊社システムにより誤って配信されてしまったメールであることが確認できました。
DirSync や ADSync をご利用の場合はアップグレードいただく必要がございますが、Azure AD Connect をすでにご利用の場合は必要ございません。
diff --git a/azure-active-directory-connect/aadc-import-export-config-upgrade/index.html b/azure-active-directory-connect/aadc-import-export-config-upgrade/index.html index 6cbce8d585c..ecfdaf41fee 100644 --- a/azure-active-directory-connect/aadc-import-export-config-upgrade/index.html +++ b/azure-active-directory-connect/aadc-import-export-config-upgrade/index.html @@ -14,7 +14,7 @@ - + @@ -154,7 +154,7 @@③ [ソースアンカー] に属性が表示されます。
ソースアンカーが objectGUID に設定されている場合は、事前に mS-DS-ConsistencyGuid に変更しておく必要があります。
-・なぜ変更する必要があるの?
objectGUID はオブジェクト (ここではユーザーのこと) ごとに一意の変更不可の値で、別のユーザー (上図でいうと移行先のフォレストの 12345@contoso.com) には同じ値を設定できません。
よって、ハードマッチで切り替えを行うことができません。(ハードマッチについては後述します。)
一方、mS-DS-ConsistencyGUID 属性値は変更が可能なので、移行元の旧同期ユーザー (上図で言うと 12345@contoso.local) で使用している値と同じ値を移行先の新同期ユーザー (上図で言うと移行先のフォレストの 12345@contoso.com) でも保持させることができるため、ハードマッチによる切り替えを行うことができます。
・なぜ変更する必要があるの?
objectGUID はオブジェクト (ここではユーザーのこと) ごとに一意の変更不可の値で、別のユーザー (上図でいうと移行先のフォレストの 12345@contoso.com) には同じ値を設定できません。
よって、ハードマッチで切り替えを行うことができません。(ハードマッチについては後述します。)
一方、mS-DS-ConsistencyGUID 属性値は変更が可能なので、移行元の旧同期ユーザー (上図で言うと 12345@contoso.local) で使用している値と同じ値を移行先の新同期ユーザー (上図で言うと移行先のフォレストの 12345@contoso.com) でも保持させることができるため、ハードマッチによる切り替えを行うことができます。
・ソースアンカーを変更するリスクは?
ソースアンカーを変更する場合のリスクを気にされる方も多いと思いますが、AADC は通常 objectGUID の値を Base64 でエンコードし、初回の同期処理で Azure AD の ImmutableID の値にセットします。
つまり、ソースアンカーを mS-DS-ConsistencyGuid に変更しても、ImmutableID の値は元の objectGUID をエンコードした値のまま変わりません。
したがって、同じ ImmutableID の値が mS-DS-ConsistencyGuid に書き戻されるため、既存の同期ユーザーが同期できなくなるといった影響は生じません。
では、以下の手順でソースアンカーを mS-DS-ConsistencyGuid に変更します。
既にソースアンカーを mS-DS-ConsistencyGuid または objectGUID 以外に設定されている方は、この項目はスキップして次に進んでください。
① 構成ウィザードを起動し、 [追加のタスク] で [ソースアンカーの構成] を選択し、[次へ] をクリックします。
既存の AD フォレストのユーザーの mS-DS-ConsistencyGuid の値が、新 AD フォレストのユーザーの mS-DS-ConsistencyGuid にコピーされていることを確認します。
もしコピーができていない場合は、以下の手順で値をコピーします。
① contoso.local の サーバー マネージャーで、[ツール] > [Active Directory ユーザーとコンピューター] を開きます。
-② 同期対象のユーザー (12345@contoso.local) の[属性エディター] で、 mS-DS-ConsistencyGuid を選択し、[編集] をクリックします。
② 同期対象のユーザー (12345@contoso.local) の[属性エディター] で、 mS-DS-ConsistencyGuid を選択し、[編集] をクリックします。
③ 値をコピーし、[OK] をクリックします。
④ メモ帳にコピーした値を貼り付けます。
⑤ 移行先フォレストの contoso.com の サーバー マネージャーで、[ツール] > [Active Directory ユーザーとコンピューター] を開きます。
-⑥ 同期対象のユーザー (12345@contoso.com) の[属性エディター] で、 mS-DS-ConsistencyGuid を選択し、[編集] をクリックします。
⑥ 同期対象のユーザー (12345@contoso.com) の[属性エディター] で、 mS-DS-ConsistencyGuid を選択し、[編集] をクリックします。
⑦ 値を入れ、[OK] をクリックします。
⑧ [OK] を押して、プロパティ画面を閉じます。
すべての同期ユーザーが同様に値がコピーされていることを確認します。
diff --git a/azure-active-directory-connect/aboutSoftMatching/index.html b/azure-active-directory-connect/aboutSoftMatching/index.html index 05831b39816..20517ce24b5 100644 --- a/azure-active-directory-connect/aboutSoftMatching/index.html +++ b/azure-active-directory-connect/aboutSoftMatching/index.html @@ -25,7 +25,7 @@ - + @@ -169,7 +169,7 @@テナントの管理者に対しては、Azure AD Connect のアップグレード機能に問題があり、最新版へ手動アップグレードすることを促すメールが通知されます。
本メールを受け取った管理者は、本ブログに記載された [対象の確認方法] を参照し、現在の AADC 設定を確認いただきますようお願いいたします。
※送信元 : AAD Notification [aad-notification-noreply@azureemail.microsoft.com]
+※送信元 : AAD Notification [aad-notification-noreply@azureemail.microsoft.com]
2017/6/8 追記
diff --git a/azure-active-directory-connect/azure-ad-connect-117490/index.html b/azure-active-directory-connect/azure-ad-connect-117490/index.html index b58460769ab..5a523aeec45 100644 --- a/azure-active-directory-connect/azure-ad-connect-117490/index.html +++ b/azure-active-directory-connect/azure-ad-connect-117490/index.html @@ -15,7 +15,7 @@ - + @@ -156,7 +156,7 @@feedback - 共有 + 共有
A. 同期処理での問題について、以前通知は 2 種類ありましたが、現在は統一されています。下記手順にてご確認ください。
-Azure AD Connect Health Agent : azure-noreply@microsoft.com
+Azure AD Connect Health Agent : azure-noreply@microsoft.com
Azure AD Connect Health Agent 通知先設定手順
設定箇所 : [Azure ポータル] - [Azure AD Connect] - [Azure AD Connect Health] - [同期エラー] - [通知設定]
設定項目 : 追加の電子メール受信者
diff --git a/azure-active-directory-connect/basic-points-directory-synchronization/index.html b/azure-active-directory-connect/basic-points-directory-synchronization/index.html index 37a397753db..13f0584d1b8 100644 --- a/azure-active-directory-connect/basic-points-directory-synchronization/index.html +++ b/azure-active-directory-connect/basic-points-directory-synchronization/index.html @@ -17,7 +17,7 @@ - + @@ -158,7 +158,7 @@構成ウィザードの設定項目ではこのような呼称ではないのですが、同期先である AAD 同期ユーザーの UserPrincipalName (UPN、名前) を決定する、同期元オンプレミス AD ユーザーの属性の指定を UPNSource と、この Blog では呼称します。
デフォルトではオンプレミス AD ユーザーの UPN 属性の値が選択され、この値が AAD 同期ユーザー側の UPN の値になります。
オンプレミス AD ユーザーの UPN と AAD ユーザーの UPN を同じ値にすることができないようなご都合があるケースもあるかと思います。
例えば、元々オンプレミス AD のドメイン名を contoso.local としており、これからご利用になる AAD に登録するカスタム ドメインを contoso.com にするようなケースにおいては、オンプレミス AD 側のドメイン名を contoso.com に変えることができない、というような場合です。
このような場合においても、オンプレミス AD の [代替 UPN サフィックス] の機能を使用して、contoso.com を代替 UPN として登録してオンプレミス AD ユーザーの UPN を username@contoso.com にすることは可能です。
しかし、オンプレミス AD ユーザーの UPN 値に依存した他のシステムがあり、AD ユーザーの UPN を変えられない、という場合もあるかと思います。
このような場合においても、オンプレミス AD の [代替 UPN サフィックス] の機能を使用して、contoso.com を代替 UPN として登録してオンプレミス AD ユーザーの UPN を username@contoso.com にすることは可能です。
しかし、オンプレミス AD ユーザーの UPN 値に依存した他のシステムがあり、AD ユーザーの UPN を変えられない、という場合もあるかと思います。
このようなケースでは、UPNSource の設定として UPN 属性を選択できず、例えば mail 属性などを選択される場合もありますが、このような [UPNSource として UPN 属性以外を選択する] 構成を一般的に [(UPN 以外の属性を UPN の代わりに指定する) 代替 ID 構成] と呼びます。
AADC 構成ウィザードにて、SourceAnchor と UPNSource それぞれの設定値を選択する画面を以下にご紹介します。
なお、サンプル csv の原本も以下からダウンロード可能です。拡張子を .txt から .csv にしてご参照ください。
AADexportSample
この場合の対処としては、オンプレミス AD にて新 AD ユーザーの mail 属性値を変更して同期を行い、再度目的の値に戻して同期を行います。具体的な作業は次のとおりです。
そもそものお話として、上記のような症状が発生することが無いよう削除する情報を先に AAD に同期して、追加する情報は後から同期する運用をぜひ留意いただければ幸いです。
以下の技術情報でも、AADC のアーキテクチャに関する情報を公開しておりますので、興味を持っていただけた方はぜひ併せてご参照ください。
PasswordResetService
Event ID: 31001
PasswordResetRequestStart, Details: user1@contoso.com
PasswordResetService
Event ID: 31001
PasswordResetRequestStart, Details: user1@contoso.com
ADSync
Event ID: 405
Call sync ldap_bind for DomainName=CONTOSO.COM, UserName=MSOL_xxxxxxxxx.
ADSync
Event ID: 403
ImpersonationHelper call LogonUser for DomainName=CONTOSO.COM, UserName=MSOL_xxxxxxxxx.
ADSync
Event ID: 405
Call sync ldap_bind for DomainName=CONTOSO.COM, UserName=MSOL_xxxxxxxxx.
PasswordResetService
Event ID: 31002
TrackingId: xxxxxxxxx-xxxx-xxxxxxxxx-xxxxxxxxx, PasswordResetSuccess, Details: Context: cloudAnchor: User_xxxxxxxxx-xxxxxxxxx, SourceAnchorValue: xxxxxxxxxxxxxxxxxx, UserPrincipalName: user1@contoso.com, unblockUser: True
PasswordResetService
Event ID: 31002
TrackingId: xxxxxxxxx-xxxx-xxxxxxxxx-xxxxxxxxx, PasswordResetSuccess, Details: Context: cloudAnchor: User_xxxxxxxxx-xxxxxxxxx, SourceAnchorValue: xxxxxxxxxxxxxxxxxx, UserPrincipalName: user1@contoso.com, unblockUser: True
Self-service password reset flow activity progress
User submitted a new password
Reset user password
Update StsRefreshTokenValidFrom Timestamp
diff --git a/azure-active-directory-connect/port-used-by-aadc/index.html b/azure-active-directory-connect/port-used-by-aadc/index.html index cf9f06bb081..1c98805f1f1 100644 --- a/azure-active-directory-connect/port-used-by-aadc/index.html +++ b/azure-active-directory-connect/port-used-by-aadc/index.html @@ -20,7 +20,7 @@ - + @@ -161,7 +161,7 @@アクセス レビューが開始されると、レビュー対象者の元に azure-noreply@microsoft.com からメールが届くので、[レビューを開始する(Review Access)] をクリックします。
+アクセス レビューが開始されると、レビュー対象者の元に azure-noreply@microsoft.com からメールが届くので、[レビューを開始する(Review Access)] をクリックします。
以下のような画面が表示されるので、セルフ レビューを実施します。
@@ -326,7 +326,7 @@上記まではゲスト ユーザー自身にレビューを実施してもらう手順となりますが、もしゲスト ユーザーの数が少ない場合などは管理者が代表してレビューを行うことも可能です。この場合の手順を後述します。
アクセス レビューが開始されると、レビュー対象者の元に azure-noreply@microsoft.com からメールが届くので、[レビューを開始する] をクリックします。
+アクセス レビューが開始されると、レビュー対象者の元に azure-noreply@microsoft.com からメールが届くので、[レビューを開始する] をクリックします。
ユーザーの状況を確認します。各ユーザーを選択すると、 [承認する] と [拒否] がクリックできるようになるので、承認もしくは拒否を指定します。
diff --git a/azure-active-directory/Important-Update-to-deviceRegistrationPolicy-Resource-Type-for-MS-Graph-Beta-API-Version/index.html b/azure-active-directory/Important-Update-to-deviceRegistrationPolicy-Resource-Type-for-MS-Graph-Beta-API-Version/index.html index 6ffdf31d2b9..20e6a50e37b 100644 --- a/azure-active-directory/Important-Update-to-deviceRegistrationPolicy-Resource-Type-for-MS-Graph-Beta-API-Version/index.html +++ b/azure-active-directory/Important-Update-to-deviceRegistrationPolicy-Resource-Type-for-MS-Graph-Beta-API-Version/index.html @@ -14,7 +14,7 @@ - + @@ -155,7 +155,7 @@以下に、2022 年 6 月分として発表された機能変更の一覧をご紹介します。
マイクロソフトでは、直近でアプリ登録にて構成できるアクセス許可の最大数について、弊社が定めた制限が適用されるよう変更しました。この制限を超えたアプリはアクセス許可に対する同意を行うことができず、動作しない状態となります。2022 年 10 月 31日より、”requiredResourceAccess” 属性にすでに 400 以上アクセス許可を構成されているアプリは、この制限値以上のアクセス許可を追加することができなくなる予定です。現在アプリにすでに構成されているアクセス許可は維持されますが、新たにアクセス許可を追加するためには、合計数が弊社にて定められた制限値以下となるよう、アプリの所有者にて既存のアクセス許可を削除する必要があります。この対応を行うことで、お客様がアクセス許可に同意できずアプリが利用できない状態になることを回避可能となります。詳細については、アプリごとの要求されたアクセス許可の制限 および サポートされているアカウントの種類別の検証の相違点 をご参照ください。
2022 年 8 月 31 日より、すべてのサービスにおいて、”Directory.AccessAsUser.All” に対して、既定で管理者の同意を要求するようになります。Azure AD Graph (graph.windows.net) および Microsoft Graph (graph.microsoft.com) のいずれにおいてもアクセス許可が要求された場合は既定で管理者の同意が必要になります。以前は、特定のシナリオでは、既定で本アクセス許可に対して管理者の同意は不要でした。この変更は、新たな同意の要求にのみ影響し、セキュリティを向上させるとともに、”Directory.AccessAsUser.All” の挙動を現在のドキュメントの動作に合わせるものです。詳細については、アクセス許可スコープ をご参照ください。
-グループ関連のメール送信が、より新しく、向上したサービスに切り替わります。以下のシナリオにおけるグループ関連のメールは従来のままですが、新しいエイリアス (msgroupsteam@microsoft.com) から送信されるようになります:
+グループ関連のメール送信が、より新しく、向上したサービスに切り替わります。以下のシナリオにおけるグループ関連のメールは従来のままですが、新しいエイリアス (msgroupsteam@microsoft.com) から送信されるようになります:
例) 削除対象のディレクトリ名が contoso.onmicrosoft.com の場合: temp@conotoso.onmicrosoft.com
手順 5. で作成したグローバル管理者のアカウントで https://portal.azure.com にサインインします。
今回の影響は、フローの 9 において セルフサービスサインアップアカウントが作成される場合においてユーザーのホーム テナントが存在しない場合、あるいは検証済みのテナントではない場合に生じます。
-フロー 9 について abc.onmicrosoft.com というテナントに user1@contoso.com というユーザーを招待しようとしたときを例に説明します。
+フロー 9 について abc.onmicrosoft.com というテナントに user1@contoso.com というユーザーを招待しようとしたときを例に説明します。
Azure AD にカスタム ドメインとして contoso.com というドメイン名を登録したテナントがすでに存在している。
contoso.com ドメイン名を登録したテナントには user1@contoso.com は存在しない。
Azure AD にカスタム ドメインとして contoso.com というドメイン名を登録したテナントがすでに存在している。
contoso.com ドメイン名を登録したテナントには user1@contoso.com は存在しない。
<前提条件>
Azure AD にカスタム ドメインとして contoso.com というドメイン名を登録したテナントが存在していない。
user1@contoso.com は Azure AD のアカウントとして Azure AD のどのテナントにも存在しない。
<前提条件>
Azure AD にカスタム ドメインとして contoso.com というドメイン名を登録したテナントが存在していない。
user1@contoso.com は Azure AD のアカウントとして Azure AD のどのテナントにも存在しない。
<動作>
現状は contoso.com が紐づくセルフ サインアップ テナントが自動で作成され、その自動で作成されたテナントに user1@contoso.com が自動で作成されます。2021 年 10 月以降は、このパターンでの自動テナント作成が行われなくなり、結果的にゲスト ユーザーの招待は失敗する見込みです。
<動作>
現状は contoso.com が紐づくセルフ サインアップ テナントが自動で作成され、その自動で作成されたテナントに user1@contoso.com が自動で作成されます。2021 年 10 月以降は、このパターンでの自動テナント作成が行われなくなり、結果的にゲスト ユーザーの招待は失敗する見込みです。
なお、セルフサービス サインアップとは、電子メール ドメインに基づいた ID がどの Azure AD にも存在しない場合に自動でユーザーが作成されることを指します。
後述に関連する公開情報もございますので、必要に応じご確認いただけると幸いです。
今後、数週間のうちに、認証方法のポリシーに新しい制御方法を追加し、Azure AD で利用可能な認証方法を一箇所で簡単に管理できるようにする予定です。このアップデートにより、認証方式をよりきめ細やかに管理することが可能になります。たとえば、認証方法を全ユーザーでオン/オフにするのではなく、認証方法のスコープとして特定のグループを指定することができるようになります。これにより、すべてのシナリオで、SMS のような安全性の低い認証方法の使用を管理し、認証強度を使用してシナリオ固有の要件に対応することが可能になります。これらを組み合わせることで、パスワードレスかつフィッシング耐性のある未来へ踏み出すために必要な制御を行えるようになります。
-ぜひ皆様にもお試しいただきたく思います。フィードバックは authstrengthfeedback@microsoft.com、Azure フォーラム、または Twitter で @AzureAD をタグ付けして、意見をお聞かせください。
+ぜひ皆様にもお試しいただきたく思います。フィードバックは authstrengthfeedback@microsoft.com、Azure フォーラム、または Twitter で @AzureAD をタグ付けして、意見をお聞かせください。
Inbar and Namrata
diff --git a/azure-active-directory/authenticator-mobile-only-setup/index.html b/azure-active-directory/authenticator-mobile-only-setup/index.html index 7ba84e3605a..800a8e2cc22 100644 --- a/azure-active-directory/authenticator-mobile-only-setup/index.html +++ b/azure-active-directory/authenticator-mobile-only-setup/index.html @@ -32,7 +32,7 @@ - + @@ -175,7 +175,7 @@なお、Azure ポータルから Azure AD B2C テナントにアクセスしてユーザー (admin@contosob2c.onmicrosoft.com など) を作成いただき、グローバル管理者権限を付与することで、このユーザーを管理者としてご利用いただくことも可能です。その場合、直接 Azure AD B2C テナントにアクセスするためテナントの切り替えが不要となるほか、Graph Explorer などで Azure AD B2C テナントに対して API 呼び出しを実施いただくことも可能になります。このため、検証用に Azure AD B2C テナントに対しメンバー ユーザーとして管理ユーザーを作成いただくことをお勧めします。
Azure AD B2C のサインアップ フローで作成されたアカウントは、コンシューマー ユーザー アカウントと呼ばれます。コンシューマー ユーザー アカウントは、サインアップ フロー以外に Azure ポータル、あるいは Microsoft Graph API を利用して作成することが可能です。
技術的にはコンシューマー アカウントは、連携している IdP のアカウント情報、またはローカル アカウントのメール アドレスを “ID プロパティ” として保持しています。ID プロパティ (identities 属性) のほか、表示名 (DisplayName) や拡張属性 (extension) を Microsoft Graph API を利用することで編集、またはユーザーの新規作成を行うことが可能です。
詳細については、以下の公開情報をご確認ください。
-Azure AD B2C テナントにはコンシューマー ユーザー以外にも、管理用の Azure AD ユーザーを登録することが可能です。これらの職場アカウント (B2B ゲストユーザーを含む) は管理ユーザーとして Azure AD を直接利用することができ、Azure ポータルにサインインをしユーザーを操作を行う、Microsoft Graph API を呼び出すといったことが可能です。上記の admin@contosob2c.onmicrosoft.com がこの例に該当します。
+Azure AD B2C テナントにはコンシューマー ユーザー以外にも、管理用の Azure AD ユーザーを登録することが可能です。これらの職場アカウント (B2B ゲストユーザーを含む) は管理ユーザーとして Azure AD を直接利用することができ、Azure ポータルにサインインをしユーザーを操作を行う、Microsoft Graph API を呼び出すといったことが可能です。上記の admin@contosob2c.onmicrosoft.com がこの例に該当します。
diff --git a/azure-active-directory/azure-ad-certificate-based-authentication-cba-on-mobile-now/index.html b/azure-active-directory/azure-ad-certificate-based-authentication-cba-on-mobile-now/index.html index 45bfc02a9b0..1fe0152cf50 100644 --- a/azure-active-directory/azure-ad-certificate-based-authentication-cba-on-mobile-now/index.html +++ b/azure-active-directory/azure-ad-certificate-based-authentication-cba-on-mobile-now/index.html @@ -21,7 +21,7 @@ - + @@ -162,7 +162,7 @@1. ユーザー名・パスワードが誤っている
ドメイン参加時に指定したアカウントが Azure AD Domain Services に同期されているアカウントであるか、並びにパスワードが正しいかをご確認ください。
いずれも問題がない場合には一度 Azure AD 上でパスワードの変更・リセットをご実施ください。
また、 Azure AD Domain Services に Azure AD から同期したユーザーでサインインを試行する場合には、 NetBIOS 形式 (contoso\user) ではなく、 UPN 形式 (user@contoso.onmicrosoft.com 等) でサインインしてください。
Azure AD から Azure AD Domain Services に同期したユーザーは Azure AD の UPN と同じ UPN を持ちます。
NetBIOS 名の場合、名前の長さなどが要因で Azure AD 上のユーザー名と異なる名前が設定されている可能性があります。
また、 Azure AD Domain Services に Azure AD から同期したユーザーでサインインを試行する場合には、 NetBIOS 形式 (contoso\user) ではなく、 UPN 形式 (user@contoso.onmicrosoft.com 等) でサインインしてください。
Azure AD から Azure AD Domain Services に同期したユーザーは Azure AD の UPN と同じ UPN を持ちます。
NetBIOS 名の場合、名前の長さなどが要因で Azure AD 上のユーザー名と異なる名前が設定されている可能性があります。
Azure AD から Azure AD Domain Services に同期される属性や内容は次のリンクの情報を参照ください。
2. Azure AD Domain Services を構築する前から Azure AD 上に存在するユーザーを利用している (そしてパスワード ハッシュが Azure AD Domain Services に同期されていない)
diff --git a/azure-active-directory/azure-ad-ds-scenario/index.html b/azure-active-directory/azure-ad-ds-scenario/index.html index b1edd58edd9..5c1c71a89b4 100644 --- a/azure-active-directory/azure-ad-ds-scenario/index.html +++ b/azure-active-directory/azure-ad-ds-scenario/index.html @@ -15,7 +15,7 @@ - + @@ -156,7 +156,7 @@招待 E メールは下記のようなメールです。
-アドレス: invites@microsoft.com
件名: 組織内のアプリケーションにアクセスするための <招待者> さんからの招待
アドレス: invites@microsoft.com
件名: 組織内のアプリケーションにアクセスするための <招待者> さんからの招待
Note
件名に招待者の名前がない場合、ProxyAddresses 属性に値が入っていないユーザーで招待操作を行ったことが考えられます。この場合、特定のユーザー名の代わりにテナント名が記載されます。
もし、招待されたユーザーが E メールを利用できない場合や、E メール ボックスの作成前の場合は、招待の再送信後に表示される下記、「招待 URL ※」をコピーして、何らかの手段でその URL を招待されたユーザーにお渡しください。招待されたユーザーは、その URL にブラウザーからアクセスすることで招待の完了作業を進めることができます。
@@ -191,9 +191,9 @@上記内容でもご要望の動作が完了しない場合は、ぜひ弊社サポート サービスをご利用ください。その際は下記の情報を事前にご提供いただけると幸いです。
例としては、「招待 E メールが届かない」、「招待 E メールは届くが招待の操作が完了しない」、「招待は完了したが、その後に目的のリソースにアクセスできない」などが挙げられます。それぞれ、上記の情報を添えてお問い合わせを発行いただけますと幸いです。
diff --git a/azure-active-directory/azuread-clientsecrets-202104/index.html b/azure-active-directory/azuread-clientsecrets-202104/index.html index deea16f07b6..46e10a188c0 100644 --- a/azure-active-directory/azuread-clientsecrets-202104/index.html +++ b/azure-active-directory/azuread-clientsecrets-202104/index.html @@ -15,7 +15,7 @@ - + @@ -158,7 +158,7 @@A. ホーム テナント側で招待に使用した 2 つの E メール アドレスが同じ 1 つのアカウントに紐づいているために、 新しいゲスト ユーザー オブジェクトが作成されなかったことが考えられます。
-たとえば、user1@adatum.com と user1_tokyo@adatum.com という二つの異なる E メール アドレスが、どちらも同じユーザー アカウントに紐づいているとします。具体的には、どちらの E メール アドレスに E メールを送信しても同じユーザーに届く状態です。このような状態で、まず user1@adatum.com を招待するとそのテナント上にゲスト ユーザー オブジェクトが作成されます。その後、同じテナント上でさらに user1_tokyo@adatum.com を招待しても、新しいゲスト ユーザー オブジェクトは作成されません。これはこれら二つの E メール アドレスの実体が一つのユーザー オブジェクトであるからです。
-より詳細には、user1@adatum.com のゲスト ユーザーがいる状態で、Azure ポータルの画面から user1_tokyo@adatum.com のアドレスを招待すると、以下のような動作となります (2023/4/28 現在)。
+たとえば、user1@adatum.com と user1_tokyo@adatum.com という二つの異なる E メール アドレスが、どちらも同じユーザー アカウントに紐づいているとします。具体的には、どちらの E メール アドレスに E メールを送信しても同じユーザーに届く状態です。このような状態で、まず user1@adatum.com を招待するとそのテナント上にゲスト ユーザー オブジェクトが作成されます。その後、同じテナント上でさらに user1_tokyo@adatum.com を招待しても、新しいゲスト ユーザー オブジェクトは作成されません。これはこれら二つの E メール アドレスの実体が一つのユーザー オブジェクトであるからです。
+より詳細には、user1@adatum.com のゲスト ユーザーがいる状態で、Azure ポータルの画面から user1_tokyo@adatum.com のアドレスを招待すると、以下のような動作となります (2023/4/28 現在)。
なお、上記のとおり、この動作はホーム テナント側でユーザー アカウントがどのような状態になっているかで決まります。そのため、アドレスのドメイン名や名前のみで一概に決まるものではございません。例えば、test1@contoso.com と test@contoso.jp という一見似たような E メール アドレスであっても、これらの E メール アドレスがホーム テナントで別々のユーザーに登録されていれば、ゲスト ユーザー オブジェクトは通常どおり 2 つ作成されます。
+なお、上記のとおり、この動作はホーム テナント側でユーザー アカウントがどのような状態になっているかで決まります。そのため、アドレスのドメイン名や名前のみで一概に決まるものではございません。例えば、test1@contoso.com と test@contoso.jp という一見似たような E メール アドレスであっても、これらの E メール アドレスがホーム テナントで別々のユーザーに登録されていれば、ゲスト ユーザー オブジェクトは通常どおり 2 つ作成されます。
「ホーム テナント側でアカウントが紐づいているかどうか」は、招待するリソース テナント側からのお問い合わせでは確認できないため、招待されるホーム テナントの管理者様に確認を依頼ください。
A. ゲスト ユーザーであっても、サインインはホーム ディレクトリにて行われます。そのため、まずはゲスト ユーザーがホーム ディレクトリにサインインができるかを切り分けてください。ホーム ディレクトリにもサインインができない場合には、ホーム ディレクトリ側での対応が必要となりますので招待した側のディレクトリの管理者で対応できません。一方で、ホーム ディレクトリにはサインインができるが、招待したディレクトリにはサインインができない場合には、招待した側のディレクトリにて調査します。
ゲスト ユーザーのよくある サインインができない問題については、2.招待された側のよくある質問 に記載しています。
-A. E メールを受信できないユーザーであっても招待することが可能です。(E メールを受信できないユーザーとは xxx@contso.onmicrosoft.com のような Azure AD 上のユーザーも含みます)。E メールを受信できないアカウントの場合、招待 E メールを受け取ることができないため、直接リンクを利用して招待に承諾します。以下の URL をゲスト ユーザーに送付し、招待への承諾を依頼ください。
+A. E メールを受信できないユーザーであっても招待することが可能です。(E メールを受信できないユーザーとは xxx@contso.onmicrosoft.com のような Azure AD 上のユーザーも含みます)。E メールを受信できないアカウントの場合、招待 E メールを受け取ることができないため、直接リンクを利用して招待に承諾します。以下の URL をゲスト ユーザーに送付し、招待への承諾を依頼ください。
https://portal.azure.com/<招待先ディレクトリのテナントID> |
E メールを利用しない招待については、B2B コラボレーションの招待の利用 - Azure AD | Microsoft Docs を参照ください。(直接リンクによる利用の項に記載があります)
diff --git a/azure-active-directory/biometrics-keep-your-fingers-close/index.html b/azure-active-directory/biometrics-keep-your-fingers-close/index.html index 1cfaea160a0..168d3941c7a 100644 --- a/azure-active-directory/biometrics-keep-your-fingers-close/index.html +++ b/azure-active-directory/biometrics-keep-your-fingers-close/index.html @@ -14,7 +14,7 @@ - + @@ -155,7 +155,7 @@Conditional Access チームのプログラムマネージャーである Daniel Wood が、これらの変更が組織のセキュリティ確保にどのように役立つかを説明するブログを書いてくれました。
フィードバックや質問がありましたら、intelligentaccesspm@microsoft.com までご連絡ください。
Conditional Access チームのプログラムマネージャーである Daniel Wood が、これらの変更が組織のセキュリティ確保にどのように役立つかを説明するブログを書いてくれました。
フィードバックや質問がありましたら、intelligentaccesspm@microsoft.com までご連絡ください。
管理者が最新の認証クライアントとレガシ認証クライアントを対象としたポリシーを簡単に作成できるように、管理者の操作性を簡素化しました。
既定では、クライアントアプリの条件が構成されていない場合、新しく作成する条件付きアクセスポリシーでは、すべてのクライアントアプリが対象になります。
レガシー認証クライアントからのサインインは、MFA をサポートしておらず、デバイスの状態情報を Azure AD に渡しません。そのため、MFA や準拠デバイスを要求するなどを条件付き アクセス ポリシーのアクセス制御の要件に含めた場合には、レガシー認証はブロックされます。
レガシー認証を使用しなければならないアカウントがある場合は、明示的に例外をポリシーで設定し、ブロックされないようにすることができます。
レガシー認証クライアントのみを対象とする条件付きアクセスポリシーを作成する場合は、クライアントアプリの構成の 「はい」、 「いいえ」 を切り替える箇所を 「はい」 に切り替え、Exchange ActiveSync クライアントと他のクライアントを選択したまま、ブラウザーとモバイルアプリとデスクトップクライアントの選択を解除します。
新しいポリシーを作成する前に、組織で誰がレガシー認証を使用しているかを理解しておくとよいでしょう。サインイン時に組織で使用されているクライアントアプリとプロトコルを確認するには、「サインイン」ページに移動し、クライアントアプリの種類で結果をフィルタリングします。
-今回の変更により、レガシ認証をブロックすることで、管理者が組織のセキュリティを確保しやすくなることを願っています。フィードバックや質問がありましたら、daniel.wood@microsoft.com までご連絡ください。
+今回の変更により、レガシ認証をブロックすることで、管理者が組織のセキュリティを確保しやすくなることを願っています。フィードバックや質問がありましたら、daniel.wood@microsoft.com までご連絡ください。
diff --git a/azure-active-directory/cae-overview/index.html b/azure-active-directory/cae-overview/index.html index f95c054c843..28cd77a8b28 100644 --- a/azure-active-directory/cae-overview/index.html +++ b/azure-active-directory/cae-overview/index.html @@ -17,7 +17,7 @@ - + @@ -160,7 +160,7 @@みなさんは CAE (Continuous Access Evaluation: 継続的アクセス評価) という機能をご存知でしょうか。
2021 年 11 月現在、以下のようなお知らせがあり、目にされた方も多いのではないかと思います。
ヒント
上記の設定でパスワード有効期限を 90 日などに設定している環境でも、システム用アカウントなど、一部のユーザーだけ無期限にしたいシナリオがあるかと思います。この場合は、上記の設定に加え、そのアカウントに対してのみ Update-MgUser コマンドで DisablePasswordExpiration を設定することで、個別に無期限にできます。詳細は、個別のユーザーのパスワードを無期限に設定する の情報をご確認ください。
ゲスト ユーザーのパスワード有効期限は、ゲストがもともと登録されているホーム テナントの組織で管理されています。そのため、ゲストを招待したテナント側 (リソース テナント側) では管理する必要がなく、ホーム テナント側の組織の設定を確認します。ゲスト ユーザーが user@outlook.com などの Microsoft アカウントの場合は、各サービスで定義されているパスワード ポリシーが適用されます。
+ゲスト ユーザーのパスワード有効期限は、ゲストがもともと登録されているホーム テナントの組織で管理されています。そのため、ゲストを招待したテナント側 (リソース テナント側) では管理する必要がなく、ホーム テナント側の組織の設定を確認します。ゲスト ユーザーが user@outlook.com などの Microsoft アカウントの場合は、各サービスで定義されているパスワード ポリシーが適用されます。
パスワード ポリシー関連でよくある質問をおまとめしております。
A: はい、テナント側の CloudPasswordPolicyForPasswordSyncedUsersEnabled オプションを適用することで可能です。 Entra ID 側からパスワードを変更するためには、Entra Connect でパスワード ライトバックを有効にする必要もあります。
以下のコマンドを実行すると、Entra ID 側のユーザーにもパスワード有効期限を設定することができます。
@@ -230,7 +230,7 @@A: 直近でポリシーが変更されている場合は、Microsoft Entra ID の監査ログで確認することが可能です。Set password policy のアクティビティでフィルターをかけたのちに、開始者(アクター)に記載のユーザーを確認ください。
A: そのドメインについては、テナントのパスワード有効期限が無期限になっていることを示しています。
A: 以前は Microsoft 365 ポータルの右上にベル アイコンが表示されていましたが、通知設定自体が廃止されたため、”もうすぐ期限切れ” の通知は現在送信されません。
-A: 端末にログオンし、Windows のデスクトップを表示するところまでは、パスワードが切れていても実施できます。Azure ポータルや Microsoft 365 管理センター、Exchange Online など Entra ID と連携するクラウド上のリソースにサインインした時にパスワード変更が求められます。端末に UPN (例: user@contoso.onmicrosoft.com) などでサインインした場合には、端末ログオン後、右下に以下のメッセージが表示される動作を現時点で確認しております。こちらもパスワード変更の際の目安となりましたら幸いです。
+A: 端末にログオンし、Windows のデスクトップを表示するところまでは、パスワードが切れていても実施できます。Azure ポータルや Microsoft 365 管理センター、Exchange Online など Entra ID と連携するクラウド上のリソースにサインインした時にパスワード変更が求められます。端末に UPN (例: user@contoso.onmicrosoft.com) などでサインインした場合には、端末ログオン後、右下に以下のメッセージが表示される動作を現時点で確認しております。こちらもパスワード変更の際の目安となりましたら幸いです。
A: Azure ポータル上から簡単に確認することはできません。 PowerShell で取得した値をもとに計算ください。テナントに設定されている有効期限を確認するには以下のように実施ください。
ここでは、弊社が公開しているマルチテナント アプリケーション “Microsoft Graph Explorer” を例に説明します。
“Microsoft Graph Explorer” は、Microsoft Graph REST API 要求を簡単に作成し、対応する応答を表示できる開発者ツールです。このアプリケーションは、弊社の Azure AD テナント (microsoft.com) の [アプリの登録] 上で、マルチテナント アプリケーションとして登録されています。
userA@contoso.comでのサインインが成功します。
+userA@contoso.comでのサインインが成功します。
次回以降 userA が Graph Explorer にアクセスする際は、openid, profile, User.Read, offline_access のアクセス許可への同意が要求されることはありません。
diff --git a/azure-active-directory/entitlement-management-ga/index.html b/azure-active-directory/entitlement-management-ga/index.html index 5ee801a057a..a425d6fac1f 100644 --- a/azure-active-directory/entitlement-management-ga/index.html +++ b/azure-active-directory/entitlement-management-ga/index.html @@ -22,7 +22,7 @@ - + @@ -163,7 +163,7 @@そこで本記事では、テナントへのアクセスが失われないようマイクロソフトとして推奨する Azure AD テナント運用のベスト プラクティスを紹介いたします。
まずは、このような事態を未然に防ぐために、Azure AD 管理者が確認しておくべきことを以下におまとめしました。
Office 365 や Azure AD の利用を開始した直後のタイミングでは、そのテナントにはグローバル管理者ロールを持つアカウントが 1 つのみ存在しています。このため、引き継ぎなくそのアカウントの管理者が退職するなどすると、だれもそのテナントを管理できなくなります。
-このような事態を防ぐため、社内の IT 部門において、必ず 2-3 名の信頼できるテナント管理者を任命し、それぞれの管理者ごとに Azure AD のユーザー (ゲスト ユーザーではなくテナント内のメンバーであり xxx@contoso.onmicrosoft.com のような UPN を持つクラウド ユーザー) を発行することをお勧めします。ここで、一つの管理者アカウント (Azure AD ユーザー) を複数名で使いまわすことはお勧めしません。これは、アカウントが使いまわされることで、どの管理者がいつサインインし、どのような操作を行ったかの監査が困難となるためです。必ず異なる UPN と異なるパスワードで、管理者の数だけ、管理専用の Azure AD ユーザーを発行ください。グローバル管理者のロールを持つユーザーの数は、テナント全体で 5 人未満がおすすめです。また、グローバル管理者のロールを持つユーザーには MFA を構成することを強くお勧めします。
+このような事態を防ぐため、社内の IT 部門において、必ず 2-3 名の信頼できるテナント管理者を任命し、それぞれの管理者ごとに Azure AD のユーザー (ゲスト ユーザーではなくテナント内のメンバーであり xxx@contoso.onmicrosoft.com のような UPN を持つクラウド ユーザー) を発行することをお勧めします。ここで、一つの管理者アカウント (Azure AD ユーザー) を複数名で使いまわすことはお勧めしません。これは、アカウントが使いまわされることで、どの管理者がいつサインインし、どのような操作を行ったかの監査が困難となるためです。必ず異なる UPN と異なるパスワードで、管理者の数だけ、管理専用の Azure AD ユーザーを発行ください。グローバル管理者のロールを持つユーザーの数は、テナント全体で 5 人未満がおすすめです。また、グローバル管理者のロールを持つユーザーには MFA を構成することを強くお勧めします。
その他の推奨事項 (特に MFA の構成など) については、Azure AD ロールのベスト プラクティス もご覧ください。
なお、いわゆる一人情シスなど、グローバル管理者ロールを持つユーザーが一名しか確保できない場合は、後述の緊急アクセス アカウントを必ず作成ください。2-3 名のテナント管理者を任命できる場合でも、緊急アクセスアカウントの準備を極力お勧めいたします。
また、Azure AD の管理者アカウントとして Microsoft アカウントを使用しているお客様は、上記のとおり管理者アカウントとして Azure AD のユーザーを利用することを特にご検討ください。Microsoft アカウントはコンシューマー向けの無料アカウントであり、その復旧を Azure 技術サポートで支援することはできません。Azure 技術サポートから支援を受けるには、Microsoft アカウントではなく、Azure AD の組織アカウントをご利用ください。
diff --git a/azure-active-directory/ga-system-preferred-multifactor-authentication/index.html b/azure-active-directory/ga-system-preferred-multifactor-authentication/index.html index f1cdc1177a0..bbc6537f082 100644 --- a/azure-active-directory/ga-system-preferred-multifactor-authentication/index.html +++ b/azure-active-directory/ga-system-preferred-multifactor-authentication/index.html @@ -18,7 +18,7 @@ - + @@ -160,7 +160,7 @@以下のコマンドを実行し、Enrollment ID (GUID の形式となる想定) が表示されるかを確認します (表示されない場合は以下の 4. から 7. の手順は実施しないでください)。
Get-ChildItem HKLM:\Software\Microsoft\Enrollments | ForEach-Object {Get-ItemProperty $_.pspath} | where-object {$_.DiscoveryServiceFullURL} | Foreach-Object {$_.PSChildName} |
以下のコマンドを実行し、Enrollment ID を変数に格納します。
$EnrollmentGUID = Get-ChildItem HKLM:\Software\Microsoft\Enrollments | ForEach-Object {Get-ItemProperty $_.pspath} | where-object {$_.DiscoveryServiceFullURL} | Foreach-Object {$_.PSChildName} |
foreach ($Key in $RegistryKeys) {if (Test-Path -Path $Key) {Get-ChildItem -Path $Key | Where-Object {$_.Name -match $EnrollmentGUID} | Remove-Item -Recurse -Force -Confirm:$false -ErrorAction SilentlyContinue}} |
以下のコマンドを実行し、デバイス登録のタスクを削除します。**変数 $EnrollmentGUID がブランクの状態で以下のコマンドを実行すると必要なタスクが削除される恐れがありますので注意ください (念のため IF 文で誤削除を予防しています)。**
+以下のコマンドを実行し、デバイス登録のタスクを削除します。変数 $EnrollmentGUID がブランクの状態で以下のコマンドを実行すると必要なタスクが削除される恐れがありますので注意ください (念のため if 文で誤削除を予防しています)。
if ($EnrollmentGUID -eq $null) {Write-Warning "EnrollmentGUID is NULL"} elseif ($EnrollmentGUID -eq "") {Write-Warning "EnrollmentGUID is BLANK (but it is not NULL)"} else {Get-ScheduledTask | Where-Object {$_.Taskpath -match $EnrollmentGUID} | Unregister-ScheduledTask -Confirm:$false} |
MEHJ の再登録を行うに際して既存の情報をクリアしておきます。
diff --git a/azure-active-directory/hashicorp-s-azure-ad-provider-migrates-to-microsoft-graph/index.html b/azure-active-directory/hashicorp-s-azure-ad-provider-migrates-to-microsoft-graph/index.html index 8e9e2d7b406..b781fb9a6a3 100644 --- a/azure-active-directory/hashicorp-s-azure-ad-provider-migrates-to-microsoft-graph/index.html +++ b/azure-active-directory/hashicorp-s-azure-ad-provider-migrates-to-microsoft-graph/index.html @@ -15,7 +15,7 @@ - + @@ -158,7 +158,7 @@この時点で Azure AD Join は完了しているので確認します。
Windows 10 コンピューターにログオンし、dsregcmd /status コマンド レットを実行すると、下記のとおり、AzureAdJoined が YES になっていることが分かります。
PRT を取得するためには、Azure AD に同期済みのオンプレミス AD ユーザーでログオンする必要があるのは、フェデレーション ドメインの場合でも同様です。
Azure AD に同期済みの下記「test001@xxx.work」で Windows 10 コンピューター (Windows10-18091) にログオンします。
PRT を取得するためには、Azure AD に同期済みのオンプレミス AD ユーザーでログオンする必要があるのは、フェデレーション ドメインの場合でも同様です。
Azure AD に同期済みの下記「test001@xxx.work」で Windows 10 コンピューター (Windows10-18091) にログオンします。
資格情報を入力してログオンします。
コマンドプロンプトを起動し、このタイミングで dsregcmd /status のコマンドレットをたたくと AzureADPrt の値が YES になることが確認できます。
現在、目次の「1. ~ 6.」までの作業が完了しています。
Azure AD にデバイスは登録されましたが、まだ Hybrid Azure AD Join の構成は完了してません。
最後の工程として、 Azure AD に同期済みの Azure AD ユーザーにて、対象の Windows 10 コンピューターにサインインし認証が成功したあとに、 Azure AD から PRT (Primary Refresh Token) を取得する必要があります。
オンプレミス AD から Azure AD に同期済みの test001 から test003 のユーザーがいますので、対象の Windows 10 コンピューターに test001@xxx.work ユーザーでサインインします。
+オンプレミス AD から Azure AD に同期済みの test001 から test003 のユーザーがいますので、対象の Windows 10 コンピューターに test001@xxx.work ユーザーでサインインします。
資格情報を入力し、サインインします。
diff --git a/azure-active-directory/how-to-deploy-cloud-kerberos-trust/index.html b/azure-active-directory/how-to-deploy-cloud-kerberos-trust/index.html index cce6c3f0340..8b4e9d7ce33 100644 --- a/azure-active-directory/how-to-deploy-cloud-kerberos-trust/index.html +++ b/azure-active-directory/how-to-deploy-cloud-kerberos-trust/index.html @@ -15,7 +15,7 @@ - + @@ -159,7 +159,7 @@下記のように、個人アカウントや別テナントの職場または学校アカウント (組織アカウント) を追加した (Azure AD B2B の機能を利用した) 場合に、ユーザーの種類が「ゲスト」として追加されます。
-これ以外の Azure のサブスクリプションのサインアップで利用した個人アカウントや組織内のドメイン (上記の例の場合: contso.com) をユーザー名 (例: test@contoso.com) に持つユーザーは「メンバー」として登録されます。また、現在は利用できないクラシック ポータル (旧ポータル) より追加した外部ユーザーについては「メンバー」として登録されております。
+これ以外の Azure のサブスクリプションのサインアップで利用した個人アカウントや組織内のドメイン (上記の例の場合: contso.com) をユーザー名 (例: test@contoso.com) に持つユーザーは「メンバー」として登録されます。また、現在は利用できないクラシック ポータル (旧ポータル) より追加した外部ユーザーについては「メンバー」として登録されております。
既定ではゲスト ユーザーに対しては、 Azure AD のデータへのアクセスが制限されています。このため、ゲスト ユーザーで Azure AD テナントにサインインした場合、招待された Azure AD のユーザーの一覧を参照することはできませんし、各種設定の参照および変更も制限されています。もちろん、サブスクリプションに対する権限を付与していない場合は、サブスクリプションのリソースを操作することもできません。一般ユーザーとゲスト ユーザーがそれぞれできること (アクセス許可の比較) は、こちらをご参照ください。
diff --git a/azure-active-directory/mfa-reset-2022/index.html b/azure-active-directory/mfa-reset-2022/index.html index 2412300e2ac..dd209faaaf5 100644 --- a/azure-active-directory/mfa-reset-2022/index.html +++ b/azure-active-directory/mfa-reset-2022/index.html @@ -18,7 +18,7 @@ - + @@ -160,7 +160,7 @@より多くの SaaS アプリケーションを採用するにつれ、SAML トークンで送信する必要のあるユーザー属性 (クレーム) の要件がアプリケーションごとに異なることに気付くと思います。たとえば、Box を使用している一部のお客様は、すべてのユーザーの proxyAddresses を SAML トークンに含めるという要件があります。しかし、このように複数の値を持つ属性は、これまで Azure AD のクレーム発行の仕組みでは利用できませんでした。
今回、新たなユーザー属性を Azure AD のクレームとして追加しました。これらの新しい属性は、Azure Portal にて「属性およびクレーム」の設定もしくは Microsoft Graph のクレーム マッピング ポリシーにおいてソースとして使用することができます。これにより、より多くのアプリケーションを AD FS や他の ID プロバイダーから、Azure AD に移行することができます。現在サポートされている新しい属性をすべて確認するには、弊社のクレーム マッピングの公開情報をご覧ください。
-多くのお客様は、AD FS 上に SaaS アプリケーションを追加し、ユーザー クレームに対して追加の情報を付け加えるよう構成しています。例えば、一部のお客様では Salesforce のユーザー名にインスタンス名 (例: user@domain.com.stage) を含めるように構成しており、AD FS が NameID クレームを発行する際には、末尾に適切な値を付け加えてます。これまで、Azure AD では、テナントで確認されていない UPN ドメイン (@domain.com) を NameID に含めることができなかったため、このようなことはできませんでした。今回パブリック プレビューとなったこの新機能では、確認されていないドメインにおいても、NameID に情報を追加できるようになりました。
+多くのお客様は、AD FS 上に SaaS アプリケーションを追加し、ユーザー クレームに対して追加の情報を付け加えるよう構成しています。例えば、一部のお客様では Salesforce のユーザー名にインスタンス名 (例: user@domain.com.stage) を含めるように構成しており、AD FS が NameID クレームを発行する際には、末尾に適切な値を付け加えてます。これまで、Azure AD では、テナントで確認されていない UPN ドメイン (@domain.com) を NameID に含めることができなかったため、このようなことはできませんでした。今回パブリック プレビューとなったこの新機能では、確認されていないドメインにおいても、NameID に情報を追加できるようになりました。
加えて、ドメインの検証を行わずとも NameID のクレームに対して結合の変換機能を使用することが可能です。結合の変換も、他のクレームと同じように NameID クレームで使用できるようになり、より柔軟な変換が可能になりました。
部分文字列の関数 についても、クレーム設定 UI にて一般提供が開始されました。ソース属性から特定の文字を抽出して作成されたクレームを必要とするアプリケーションでは、この部分文字列の関数を使用可能です。
diff --git a/azure-active-directory/new-capolicy-for-csp-account/index.html b/azure-active-directory/new-capolicy-for-csp-account/index.html index e4b7c8afe5b..0a68e717984 100644 --- a/azure-active-directory/new-capolicy-for-csp-account/index.html +++ b/azure-active-directory/new-capolicy-for-csp-account/index.html @@ -16,7 +16,7 @@ - + @@ -159,7 +159,7 @@数日間レポート専用モードでポリシーを監視し、ポリシーの影響を理解できたら、レガシー認証のブロックを開始する準備が整ったと言えるでしょう。最も簡単な方法は、ポリシーの状態を レポート専用 から オン に変更することです。または、まだ準備ができていないユーザーがおり、それらに対してレポート専用モードでレガシー認証をブロックした場合の影響を監視し続けたい場合は、レガシー認証をブロックする条件付きアクセス ポリシーを別個に作成します。
条件付きアクセスに加えて、従来の認証をサービス側またはリソース側 (認証プラットフォーム側ではなく) でブロックすることも可能です。たとえば、Exchange Online では、ユーザーに対して POP3 または IMAP4 を無効にすることができます。ここで問題となるのは、レガシー認証と最新の認証が両方可能なプロトコル (EWS、MAPI など) を完全にブロックできないということです。この問題を解決するために、Exchange Online は認証ポリシーと呼ばれる機能をリリースしました。プロトコルの接続は、Azure AD または AD FS に対して資格情報をチェックする前に拒否されるため、認証前にポリシーが強制されます。
-このブログ記事が、組織内のレガシー認証をブロックするために必要なすべての情報を提供できていれば幸いです。ご質問がある場合は、以下のコメント欄でこのブログ記事に返信するか、弊社チーム (intelligentaccesspm@microsoft.com) にメールを送る、もしくは Twitter で Alex (@alex_t_weinert) と私 (@daniel_e_wood) まで連絡ください。
+このブログ記事が、組織内のレガシー認証をブロックするために必要なすべての情報を提供できていれば幸いです。ご質問がある場合は、以下のコメント欄でこのブログ記事に返信するか、弊社チーム (intelligentaccesspm@microsoft.com) にメールを送る、もしくは Twitter で Alex (@alex_t_weinert) と私 (@daniel_e_wood) まで連絡ください。
diff --git a/azure-active-directory/non-destructive-pin-reset/index.html b/azure-active-directory/non-destructive-pin-reset/index.html index 3b029925812..e4f214b44bb 100644 --- a/azure-active-directory/non-destructive-pin-reset/index.html +++ b/azure-active-directory/non-destructive-pin-reset/index.html @@ -15,7 +15,7 @@ - + @@ -158,7 +158,7 @@Azure サブスクリプションと Azure AD はそれぞれ独立したものです。
管理者についてもそれぞれ独立していますので Azure サブスクリプションの管理者であっても Azure AD の全体管理者でなければ、 Azure AD の管理 (ユーザー追加、削除など) はできません。同様に Azure AD の全体管理者であっても、必ずしも紐づく Azure サブスクリプションの管理者ではありません。
例えば次のような関係を考えてみましょう。
-company1 という会社ではすでに Azure AD を保持しており、その Azure AD のディレクトリ名は company1com.onmicrosoft.com です。この Azure AD にはカスタムドメインとして company1.com というドメイン名が紐づけられています (*注3)。以下の図では user1@company1.com というアカウントが Azure のサブスクリプションを作成した状態での関係を示しています。
+company1 という会社ではすでに Azure AD を保持しており、その Azure AD のディレクトリ名は company1com.onmicrosoft.com です。この Azure AD にはカスタムドメインとして company1.com というドメイン名が紐づけられています (*注3)。以下の図では user1@company1.com というアカウントが Azure のサブスクリプションを作成した状態での関係を示しています。
-user1@company1.com というアカウントは Azure のサブスクリプションのアカウント管理者でありサービス管理者です。そのため、サブスクリプション内のすべての権限を持ちます。例えばこのサブスクリプション内で仮想マシンを作成したり、仮想ネットワークを設定したりすることができます。しかし、関連づけられている Azure AD に対しては user1 は管理者権限を持ちません。Azure AD に対して管理者権限を必要とする作業を実施する場合には admin1@company1com.onmicrosoft.com または admin2@company1.com という全体管理者に、作業を依頼するか、あるいは自身に Azure AD の権限を与えてくれるように依頼する必要があります。
+user1@company1.com というアカウントは Azure のサブスクリプションのアカウント管理者でありサービス管理者です。そのため、サブスクリプション内のすべての権限を持ちます。例えばこのサブスクリプション内で仮想マシンを作成したり、仮想ネットワークを設定したりすることができます。しかし、関連づけられている Azure AD に対しては user1 は管理者権限を持ちません。Azure AD に対して管理者権限を必要とする作業を実施する場合には admin1@company1com.onmicrosoft.com または admin2@company1.com という全体管理者に、作業を依頼するか、あるいは自身に Azure AD の権限を与えてくれるように依頼する必要があります。
別のパターンを考えてみます。
-ここでは Microsoft アカウントの user2@outlook.com を指定して Azure サブスクリプションを作成しています。この例の outlook.com のように企業に紐づかない Microsoft アカウントを利用して Azure サブスクリプションを作成した場合など、サブスクリプション作成時に利用したアカウントが所属する Azure AD が無い場合には、新規で Azure AD ディレクトリが自動的に作成されます。この場合、特に役割の追加作業をしていなくても Azure サブスクリプションのアカウント管理者 = Azure AD の全体管理者になります。
-この場合でも以下のようにサブスクリプションに別のアカウント user3@outlook.com を所有者として追加した場合には、このアカウントは Azure AD の管理者ではありませんので、もしそのアカウントにも権限を付与したいのであれば user2@outlook.com が、 user3@outlook.com を全体管理者にする作業が必要です。
+ここでは Microsoft アカウントの user2@outlook.com を指定して Azure サブスクリプションを作成しています。この例の outlook.com のように企業に紐づかない Microsoft アカウントを利用して Azure サブスクリプションを作成した場合など、サブスクリプション作成時に利用したアカウントが所属する Azure AD が無い場合には、新規で Azure AD ディレクトリが自動的に作成されます。この場合、特に役割の追加作業をしていなくても Azure サブスクリプションのアカウント管理者 = Azure AD の全体管理者になります。
+この場合でも以下のようにサブスクリプションに別のアカウント user3@outlook.com を所有者として追加した場合には、このアカウントは Azure AD の管理者ではありませんので、もしそのアカウントにも権限を付与したいのであれば user2@outlook.com が、 user3@outlook.com を全体管理者にする作業が必要です。
diff --git a/azure-active-directory/subscription-azuread/index.html b/azure-active-directory/subscription-azuread/index.html index 2b27c92b826..0bcecec24eb 100644 --- a/azure-active-directory/subscription-azuread/index.html +++ b/azure-active-directory/subscription-azuread/index.html @@ -18,7 +18,7 @@ - + @@ -159,7 +159,7 @@注 3: Azure AD では必ず設定される xxxxx.onmicrosoft.com というドメイン名に加えてカスタムドメイン名を追加することができます。カスタムドメイン名を追加するためには、そのドメインに対して権限を持っている (ドメインのゾーンをインターネットで名前解決でき、そのゾーンを管理している) 必要があります。詳しくはこちらのサイトを参照ください。
これは会社で利用しているアカウントを Microsoft アカウントとして登録しているケースが当てはまります。(* 現在は新規で職場または学校アカウントとして登録されているアカウントを Microsoft アカウントとしても登録することはできなくなっています。詳しくはリンクを参照ください)
同じユーザー名であっても Microsoft アカウントと職場または学校アカウントは別物で、サブスクリプションの権限が割り当たっているユーザーもどちらかの種類のユーザーになります。
-例えば、Azure AD に職場または学校アカウントの user01@contoso.com が登録されている状況でそのユーザーにサブスクリプションの権限を付与した場合、下記のように Microsoft アカウントは同じユーザー名であるもののサブスクリプションの権限を所有していないことになります。
+例えば、Azure AD に職場または学校アカウントの user01@contoso.com が登録されている状況でそのユーザーにサブスクリプションの権限を付与した場合、下記のように Microsoft アカウントは同じユーザー名であるもののサブスクリプションの権限を所有していないことになります。
よって、Azure ポータル にログインする際に下記のように、2 種類のアカウントが表示される場合には、サブスクリプションの権限を割り当てた種類のアカウントを選択してログインする必要があります。
diff --git a/azure-active-directory/support-q-and-a/index.html b/azure-active-directory/support-q-and-a/index.html index b479a3253d6..29f5be34fe9 100644 --- a/azure-active-directory/support-q-and-a/index.html +++ b/azure-active-directory/support-q-and-a/index.html @@ -15,7 +15,7 @@ - + @@ -156,7 +156,7 @@識別子がローカルで一意である場合、ID プロバイダーはドメイン内のユーザー間で値が重複しないように検出し、重複を防止します。ローカルでの一意性が強制されていれば、シングル サインオン (SSO) 時に 2 つの異なる ID プロバイダーのアカウントが同じ文字列で表されることはありません。しかし、現在の ID 基盤では、ユーザーが複数の組織や企業、学校などのコミュニティに属している場合があり、それらのコミュニティが重複または反復する通信チャネルを保持している可能性は十分にあります。
テスト用アカウントと本番用アカウントを持っている社員は、両方のアカウントで同じ電話番号を設定するかもしれません。また、非従業員が企業間コラボレーションのために招待されたゲスト アカウントと顧客アカウントを持ち (ID プロバイダの小売サービスを使用するため)、両方とも同じ電子メール アドレスを使用する場合もあります。これらの例では、電子メールと電話番号はローカルで一意ではなく、アカウントを区別するには不十分です。しかし、トークンに含めるペイロードとしては許容されます。これは、これら属性がトークン内で一意性の要件を持たないペイロードの一部であり、トークンの Subject (一意性の要件がある) に関する追加情報を提供するためのものだからです。
セクション 5.7 の 2 つ目の節は、属性のライフサイクルに言及しています。電子メール アドレスおよび電話番号とユーザーとの紐づけが解かれるタイミングとしては様々なものがあり得ます。問題はその次に何が起こるかです。識別子が 2 つの異なるタイミングで 2 つの異なるユーザに割り当てられると、後に割り当てられたユーザーが、その前に割り当てられていたユーザーの権限とデータを得てしまうリスクがあります。
-例えば、ある組織が Fred Smith という人を雇い、fsmith@company.com という電子メール アドレスを割り当てたとします。Fred がやがて退職し、Frida Smith が採用され、同じ電子メール アドレスが割り当てられました。この時、例え電子メール アドレスが同じでも、トークンの Subject は Fred と Frida で異なる値である必要があります。これにより、Frida が Fred のデータにアクセスする可能性を防ぐことができます。
+例えば、ある組織が Fred Smith という人を雇い、fsmith@company.com という電子メール アドレスを割り当てたとします。Fred がやがて退職し、Frida Smith が採用され、同じ電子メール アドレスが割り当てられました。この時、例え電子メール アドレスが同じでも、トークンの Subject は Fred と Frida で異なる値である必要があります。これにより、Frida が Fred のデータにアクセスする可能性を防ぐことができます。
企業の合併や買収のような事が生じた際に、社外のゲストやパートナーで連絡先情報の変更が生じる可能性についても考慮が必要です。例えば A 社が B 社を買収した場合には、社員の連絡先情報 (電子メール アドレスなど) を変更する必要が生じますが、同時にユーザーが引き続き SSO 可能とすることが重要です。トークンの Subject は、社名の変更、企業の移行、新しい市外局番へのオフィスの移転、その他のイベントが生じても影響を受けないだけの安定性が必要となります。
実例を見ていきましょう。Frida という会計士がいるとします。この人は Company3 という企業で働き、Company1 と Company2 という企業にサービスを提供しています (Company2 では 2 つの部門で働いている)。Frida の専門は RP.com という SaaS の会計アプリケーションで、彼女は一日中そのアプリケーションで様々な顧客のために業務を行っています。Frida が持っている電子メール アドレスは 1 つだけで、これは雇用主である Company3 から得たものです。彼女が 4 つの ID プロバイダーのアカウントにサインインし、RP.com に SSO しようとするとどうなるでしょうか?
diff --git a/azure-active-directory/the-latest-enhancements-in-microsoft-authenticator/index.html b/azure-active-directory/the-latest-enhancements-in-microsoft-authenticator/index.html index 0d4cba8162e..c9bc1fab77e 100644 --- a/azure-active-directory/the-latest-enhancements-in-microsoft-authenticator/index.html +++ b/azure-active-directory/the-latest-enhancements-in-microsoft-authenticator/index.html @@ -18,7 +18,7 @@ - + @@ -160,7 +160,7 @@