Azure Identity Support JapanHexohttps://jpazureid.github.io/blog/All rights reserved 2026, Azure Identity Support Japan日本マイクロソフトの Azure Active Directory と AD FS に関するサポート情報のブログです。Japan Azure Identity Support Blog2026-05-06T09:09:28.037ZAzure Identity Support Japan
この設定により、ベースライン スコープのみを要求する認証リクエストにおいて、条件付きアクセスのリソース評価で Windows Azure Active Directory の代わりに指定したカスタム アプリケーションが使用されるようになります。
ステップ 2 でこのカスタム アプリケーションを CA ポリシーの対象外に設定済みのため、結果として従来と同等の除外動作が実現されます。 なお、発行されるトークンの audience (aud クレーム) 自体は Windows Azure Active Directory や Microsoft Graph のままであり、アプリケーションの動作に影響はありません。
お手元の Intune MDM 登録 + Entra ID へのデバイス登録済みの Apple デバイスがどちらのシナリオで構成されたものであるかを見分ける場合、特徴的な差異として [SCEP デバイス ID 証明書が視認できるかどうか] という見方があります。 以下は iOS デバイスの例ですが [設定] - [一般] - [VPN とデバイス管理] から、Intune 登録時にインポートされている Management Profile の詳細を確認する流れです。
Management Profile をタップ
詳細をタップ
SCEP デバイス ID 証明書あり = キーチェーン利用
SCEP デバイス ID 証明書なし = Secure Enclave 利用
この実装変更が展開されるとどのような影響が発生するか
この実装変更がロールアウトされた後に Intune MDM 登録 + Entra ID へのデバイス登録をしたデバイスの一部のアプリにおいてデバイス ID を提示できなくなります。 その結果、条件付きアクセスでデバイス ID の提示を必要とするポリシーを構成している場合に一部アプリでのサインインがブロックされます。
上記の判定条件やアクセス制御はいずれも クライアント アプリ/ブラウザからの認証要求時に、デバイス ID が Entra ID に提示される ことで適切に判定を受けることが可能な機能です。 つまり、クライアント アプリ/ブラウザが認証時にデバイス ID を提示できないと、Entra ID は [どのデバイスからの認証要求であるか] を判定する情報が得られず、未登録デバイスと判定することになります。
上述の条件付きアクセス ポリシーを構成している環境において、それぞれの OS ごとで動作するアプリケーションへの影響を以下の表にまとめました。
iOS の場合
区分
説明
MSAL 対応アプリ／ブラウザ
特に対応は不要です。なお、Microsoft の 1st party アプリや Edge ブラウザは MSAL に対応しています。3rd party アプリが MSAL に対応しているかどうかは、アプリ提供元への確認が必要です。
非 MSAL 対応アプリ／ブラウザ
Enterprise SSO プラグイン機能を有効にすることで、Secure Enclave に格納されたデバイス ID の取得と認証時の提示が行えるようになります。
macOS の場合
区分
説明
MSAL 対応アプリ／ブラウザ
Enterprise SSO プラグイン機能を有効にすることで、Secure Enclave に格納されたデバイス ID の取得と認証時の提示が行えるようになります。
非 MSAL 対応アプリ／ブラウザ
Enterprise SSO プラグイン機能を有効にすることで、Secure Enclave に格納されたデバイス ID の取得と認証時の提示が行えるようになります。
A: 認証ブローカーとは、アプリに代わって認証の処理を行うコンポーネントを指します。 OS 上で起動するアプリは、認証に関わるやり取りをアプリ自身のプロセス上で実行せず、別のプロセスに委任する (認証に関する処理を任せる) 作りが広く一般的です。 これは OS の種類にかかわらず、以下のように言えます。
Windows の場合、Outlook や Teams などの Office (1st party) アプリでは WAM (Web Account Manager) と呼ばれる OS の認証ブローカーに認証の処理を任せる 3rd party アプリの場合、アプリの作りによって WAM に任せる作りのアプリもあれば、Edge WebView に任せる作りのアプリ、自分自身のプロセスで対応する (他プロセスに委任しない) アプリもある
iOS の場合、Office (1st party) アプリは、Microsoft Authenticator に認証の処理を任せる 3rd party アプリの場合、アプリの作りによって認証ブローカーである Microsoft Authenticator に任せる作りのアプリもあれば、Safari WebView に任せる作りのアプリ、自分自身のプロセスで対応する (他プロセスに委任しない) アプリもある
Android の場合、Office (1st party) アプリは、Intune Company ポータル アプリに認証の処理を任せる 3rd party アプリの場合、アプリの作りによって認証ブローカーである Intune Company ポータル アプリに任せる作りのアプリもあれば、Chrome WebView に任せる作りのアプリ、自分自身のプロセスで対応する (他プロセスに委任しない) アプリもある
上記の Microsoft の認証ブローカーに認証処理を委任できるアプリは、1st / 3rd party 製であるかどうかにかかわらず [MSAL (先進認証のライブラリ) に対応したアプリ] という言い方も可能です。
FAQ3
Q: Enterprise SSO を有効にすることによる影響はありますか。
A: Apple の OS に対して Enterprise SSO を有効化することで、Safari の認証処理がアドイン/強化される (ブラウザ単位ではなく、デバイスとして保持する認証情報を利用できるようになる) ことになります。 そのため、Safari もしくは [Safari WebView を認証ブローカーとする作りのアプリ] がその恩恵を受けることになります。
そのため [Safari ブラウザ、もしくは認証ブローカーとして Safari WebView を使用する 3rd party アプリの利用時、これまでは対話的な認証画面が表示されて認証操作を行っていたが、Intune に MDM 登録を行っているユーザーとして SSO が行えるようになり、かつ認証時にデバイス ID 情報も提示できるようになる] という影響/効果が生じることが期待値となります。
なお、前述のとおり MSAL も Safari WebView も認証処理に使用していない 3rd party アプリの場合、該当アプリの [アプリ バンドル ID] を指定することで、同様の影響/効果を得られる可能性もあります。 繰り返しになりますが該当アプリの実装に依存するため Microsoft として Enterprise SSO の効果が得られるかどうかに関して確証を持ったご案内ができない点、あらかじめご了承ください。
上記内容が皆様の参考となりますと幸いです。どちら様も素敵な Entra ID ライフをお過ごしください。
a. Microsoft Entra ID アカウントの ImmutableId と、同期しようとするオンプレミス AD の sourceAnchor が一致する
b. テナントのプロパティ BlockCloudObjectTakeoverThroughHardMatch が Falseである
c. 対象の Entra ID アカウントの OnPremisesObjectIdentifier 属性が空である (New)
これまでは a. b. の条件を満たせばハードマッチが行われていましたが、今回の動作変更によって c. の条件が追加されます。
一度でもオンプレミス AD からユーザー同期を行うと、 OnPremisesObjectIdentifier 属性には同期元ユーザーの object ID の値が設定されます。オンプレミス AD から新しいオブジェクトを同期する際に今回の動作変更が適用されますので、OnPremisesObjectIdentifier 属性が空である場合にハードマッチが行われます。
1-2. ハードマッチの動作が変更された後のハードマッチ手順について
動作変更後もハードマッチを実施するには、 OnPremisesObjectIdentifier 属性が空である必要があるため、管理者が事前に Microsoft Graph API を用いて同期済みユーザーの OnPremisesObjectIdentifier をクリアする必要があります。 ハードマッチを利用する際の シナリオをもとに、以下でご説明いたします。
シナリオ: オンプレミス AD の非同期ユーザーと、既存の Entra ID ユーザーを紐づける場合
オンプレミス AD フォレストの移行や出向などの理由により、既存の Entra ID ユーザーに紐づく同期元のオンプレミスユーザーを変更する場合がございます。 このシナリオでは、Entra ID にある既存のユーザー A’ について、同期元となっているオンプレミスユーザーをドメイン X にいるユーザー A からドメイン Y にいるユーザー B に交換します。
変更前: ドメイン X On-prem user A -> Entra ID user A’ ドメイン Y On-prem user B
変更後: ドメイン X On-prem user A ドメイン Y On-prem user B -> Entra ID user A’
最新の Windows 11 では certutil -deletehellocontainer コマンドを実行すると Windows Hello for Business だけでなくその Windows 上に保存されたパスキーもクリアされます。 このため、その Windows 11 上に Windows Hello for Business 以外のパスキーを保存している場合は、certutil -deletehellocontainer コマンド実行前に他のデバイスでパスキーをセットアップしておくなどして、その Windows 上でパスキーがクリアされた後もそのアカウントでサインインできるように準備してください。
certutil -deletehellocontainer コマンドはこれまで、 既にプロビジョニングされた Windows Hello for Business をリセットする方法 として利用されていました。 certutil -deletehellocontainer コマンドは Windows Hello for Business のプロビジョニングによって作成されたキー情報が保存されるコンテナ空間をクリアするコマンドです。 最新の Windows 11 ではこのコンテナ空間にパスキーも保存されるようになりました。 このため certutil -deletehellocontainer コマンドでこのコンテナ空間をクリアすると、Windows Hello for Business だけでなくその Windows 11 上に保存されたパスキーもクリアされることになるという仕組みです。 よって certutil -deletehellocontainer コマンドを実行する際には事前準備が必要という流れになります。
補足
その Windows 11 上に保存されているパスキーは「スタート」 > 「設定」 > 「アカウント」 > 「パスキー」で確認することができます。 (下図では一番上にリストされている ***.onmicrosoft.com が Windows Hello for Business の情報で、残りの 2 つが他のサイトで作成したパスキーです。)
こんにちは、Azure & Identity サポート チームの長谷川です。今回は Microsoft Entra ID にローカル管理者パスワードがバックアップされているデバイス一覧を取得する方法のサンプルを紹介します。
Windows LAPS の機能を利用すると、Microsoft Entra 参加済みデバイスと Microsoft Entra ハイブリッド参加済みデバイスのローカル管理者アカウントとそのパスワード情報を Entra ID 上に保存することができます。この Entra ID 上に保存したローカル管理者アカウントの情報は、管理者が Entra 管理センター上でデバイスごとに確認することができます。しかしながら、Entra 管理センター上では一覧としてダウンロードする機能は実装されておりません。そこで、Microsoft Graph PowerShell モジュールのコマンドを使用して Microsoft Entra ID にローカル管理者パスワードがバックアップされているデバイス一覧を CSV に出力する方法のサンプルを紹介します。
A. デバイスの管理方法の変更が組織で行われない限り、特別問題が生じることはありません。組織にてデバイスの管理を Microsoft Entra ハイブリッド参加構成に変更を行った場合に、その事前に Microsoft Entra 登録を構成していた場合、Microsoft Entra 登録 と Microsoft Entra ハイブリッド参加の状態の 2 つのデバイスが Microsoft Entra ID に重複登録されてしまう可能性があります。構成変更をする場合には、予め下記をご参照ください。
Azure 証明機関の詳細 ドキュメントに記載されている すべてのルートおよび下位 CA を信頼してください。
「DigiCert Global Root G2」ルートおよびその下位証明機関 (2025 年 9 月以降ドキュメント化) を信頼する設定になっていることを確認してください。
クライアント側の DigiCert Global Root CA へのピン留め設定がある場合はすべて削除してください。
サービス中断を回避するため、今すぐ設定を更新してください。
ヘルプとサポート:
DigiCert 証明書に関する詳細は DigiCert のドキュメント をご参照ください。
証明書のピン留めに関するガイダンスは Azure ドキュメント をご確認ください。
Microsoft Q&A のコミュニティで専門家に質問できます。
サポート契約をお持ちで技術支援が必要な場合は、サポート リクエスト を作成してください。
続いて、本通知に関する補足情報を Q&A 形式で記載いたします。
よくあるご質問
Q. 通知が行われた環境ではすべて対応が必要になりますか？
A. お客様の環境で特殊な制御を実施していない場合は、今回の対応は不要です。今回の通知は、現在利用されている証明書のみを明示的に信頼するように構成している (ピン留めを設定している) 環境やアプリケーションにのみ影響があります。これは環境側の構成であるため、弊社側ではお客様の環境でピン留めを設定しているか否かの判別ができないことから、すべてのお客様に通知を実施しております。
なお、Windows OS では既定で「ルート証明書更新プログラム」という機能が有効になっており、これにより既に必要なルート証明書がインストール済みであることが想定されます。この仕組みについては、以下の Windows サポートによる技術ブログに詳細があります。たとえば、この動作を無効にするポリシーやレジストリを設定していないかどうかの確認手順についても記載がありますため、参考となりましたら幸いです。
まず、Satya Nadella が直接電話してきたことに驚きました。次に思ったのは、「本当に？僕に ID の仕事を？」ということです。しかし、その後 2 時間、彼は ID が Microsoft のエンタープライズ戦略の基盤であり、クラウドへの移行を推進するために助けが必要なんだと説明してくれました。
3 週間後、私はこれまでで最高といえる仕事を始めることになりました。オンプレミスの Active Directory をクラウドに移行し、Azure Active Directory として進化させ、さらに Microsoft Entra という完全な ID およびアクセス管理ソリューションへと発展させる仕事です。その旅は本当に素晴らしいものでしたが、ID の仕組み自体は根本的には変わっていません。
そして今、はるかに大きなイノベーションの波が始まっています。
AI という大波
1 年前、上司の Joy Chik にこう言われました。「AI に注力して、来たるべき未来に備える方法を考えてほしい」と。
それ以来、私は AI ツールを試し、自分のエージェントを作り、戦略をまとめ、世界中の顧客、業界アナリスト、AI 専門家と話をしてきました。だからこそ、次の波は、人間の働き方や経済の仕組みを、産業革命、電気革命、インターネット革命、モバイル革命と同じように根本から変えると確信しています。
※ KPMG AI Quarterly Pulse Survey | Q3 2025. September 2025. n= 130 U.S.-based C-suite and business leaders representing organizations with annual revenue of $1 billion or more.
※ James Bono, Beibe Cheng, and Joaquin Lozano, Randomized Controlled Trials for Conditional Access Optimization Agent, October 2025, Microsoft Corporation.
これは単に ChatGPT を API に接続したものではありません。私のチームやお客様対応チームが、効果的な条件付きアクセス ポリシーを構築する中で得た知識とノウハウを詰め込んだ、目的特化型のエージェントです。このエージェントは、テナントとすべての条件付きアクセス ポリシーを継続的に分析し、ポリシーの重複を検出し、保護されていないユーザーやアプリケーションを見つけ、ワンクリックでギャップを修正するのを支援します。また、除外設定されていないブレークグラス アカウントや、除外が多すぎるポリシーなど、リスクのある構成も特定できます。
ガバナンスやライフサイクル管理に穴があると、特にアクセス レビューで全員が圧倒されることになります。そこで、私たちはこの課題に取り組み、エージェントの ID ガバナンス戦略のためのフレームワークを構築しています。
エージェントのセキュア アクセス: Microsoft Entra Agent ID
まもなく、エージェントをエンタープライズ レベルの ID として管理、保護、ガバナンスできるようになります。
Microsoft BUILD で、AI エージェントを Microsoft Entra に統合すること を発表しました。私たちの目標はシンプルです。従業員 ID に適用している保護と制御を、AI エージェントにも提供することです。Microsoft Entra では、エージェントを新しい ID タイプとして追加し、アクセス管理、セキュリティ、ID ガバナンスの機能を開発しています。これらのエージェント ID は、Foundry、Copilot Studio、Security Copilot、そしてサードパーティ プラットフォームなど、エージェント作成に使うツールにあらかじめ構成されます。
Microsoft Entra は、幅広いパートナーやアプリケーションのエコシステムを支えています。私たちは業界全体で協力し、すべてのエージェント型 ID システムとの統合を可能にし、セキュリティ リスクを低減し、専門家、学術機関、標準化団体で合意したベスト プラクティスに沿った共通標準を採用できるよう取り組んでいます。
8 月に、グループの Source of Authority（SOA）変換の機能を使用することで、組織がクラウド上でレガシー グループを管理できるようになりました。この機能により、オンプレミス環境をより簡素化でき、Active Directory（AD）に依存するアプリにもガバナンスを拡張できることを紹介しました。本日、ハイブリッド環境のセキュリティ体制の強化に役立つ以下の 2 つの重要なアップデートを発表いたします。
グループの SOA 変換が一般公開されました。
ユーザーの SOA 変換がパブリック プレビューとなりました。
このアップデートが重要な理由
Active Directory (AD) とクラウドの両方で ID を管理する煩雑さは長年の悩みの種でした。以下の新しい機能により、その煩わしさが解消されます。
ユーザーの Source of Authority (SOA) 変換を利用すると、AD から同期されたユーザーをクラウド上で編集可能なオブジェクトに変換することができます。この機能により、組織の運用上の負荷が軽減され、クラウド上でのユーザー管理、条件付きアクセス、MFA、パスワードレス認証などの高度な ID の機能が利用できるようになります。
グループの Source of Authority (SOA) 変換を利用すると、AD から同期されたセキュリティ グループを Microsoft Entra ID で編集可能なクラウド オブジェクトに変換することができます。またこの機能を利用しながらも、オプションとしてクラウド同期のライトバックの機能を追加で設定することで、オンプレミスのアプリとの互換性を維持することも可能です。グループの SOA では、メールが有効なセキュリティ グループや配布リストをクラウド上の Exchange で管理されるグループに変換することもでき、不要になったグループを AD から削除するのにも役立ちます。
これらの機能を組み合わせて利用することで、組織は AD への投資を最小限に抑えるとともに、ライフサイクル管理がよりシンプルになり、ゼロトラストのセキュリティ体制を強化することができます。
シナリオ - ユーザーの SOA とグループの SOA を用いたハイブリッド ID のセキュリティ強化
とある組織がクラウド ファーストの ID のモデルへ移行しようとしているとしましょう。しかしその組織は依然として重要なオンプレミスのアプリケーションに依存しています。この組織の ID 担当チームは、クラウドへの完全移行を待つ代わりに、まずリスクの高いユーザーの一部をユーザーの SOA 変換を使ってクラウドで編集可能なユーザー ID に変換することにしました。同時に、それらオンプレミスのアプリケーションに関連する AD 上のセキュリティ グループをグループの SOA 変換を利用してクラウドへ移行し、Microsoft Entra ID 上で完全に管理できるようにすることで、セキュリティとガバナンス機能を強化することが可能となりました。
このユーザーの SOA とグループの SOA を組み合わせたアプローチは、組織に対して即時に利益をもたらします。IT 管理者は Microsoft Entra 管理センターや Microsoft Graph API を用いて、ユーザー ID、グループ、アクセス ポリシーを一元管理でき、運用をシンプルにして複雑さを軽減できます。これまで手動のプロセスによって行われていたガバナンスは、エンタイトルメント管理、アクセス レビュー、ライフサイクル ワークフローによって自動化され、これにより重要なアプリケーションのコンプライアンスがより強化されます。
セキュリティは劇的に向上します。従業員はクラウドとオンプレミスの両方のアプリに対して、Microsoft Entra ID の資格情報 (パスワードレス オプションを含む) でサインインできるようになります。リスクベースの条件付きアクセス ポリシーがシームレスに適用されることで、パスワード疲労攻撃や資格情報の乱立を減らし、ゼロトラストの原則が強化されます。
移行は柔軟に進めることができます。一部のユーザーとグループから変換を開始することで、業務が中断されることなく、既存の同期フローも維持できます。時間をかけて独自のペースで Microsoft Graph API や Microsoft Entra 管理センターを使用しながらクラウドへの変換対象を拡大していくことが可能です。
マイクロソフトは Microsoft Entra に高度な AI 駆動のセキュリティ機能を導入し、インテリジェントな自動化を通じて ID 保護を強化しています。Microsoft Entra の Security Copilot は、アクセスのガバナンスを改善するために AI に基づく知見と推奨事項を組織に提供し、加えて条件付きアクセスの最適化エージェントは、新たな脅威に効果的に対応するとともに、対応プロセスをより効率化するために継続的にポリシーを分析します。これらのソリューションにより、セキュリティ運用の中核に AI が統合され、より効率的な意思決定、強固な防御、そして ID 管理におけるより高い保証レベルの実現を支援します。
2026 年 9 月 30 日までに最新バージョンの Microsoft Entra Connect へアップグレードが必要
[お客様によっては対応が必要です]
Microsoft は、Active Directory と Microsoft Entra ID 間の安全な同期をサポートするために、ファーストパーティーのサービス プリンシパルである Microsoft Entra AD Synchronization Service (アプリ ID: 6bf85cfa-ac8a-4be5-b5de-425a0d0dc016) を導入しました。このアプリケーションは、Microsoft Entra Connect を経由したオンプレミスから Entra ID への同期に不可欠であり、管理センターのエンタープライズ アプリケーションの個所から管理可能です。
Microsoft Entra Connect は現在、このファーストパーティ アプリケーションを使って Active Directory と Microsoft Entra ID 間の同期を行っています。お客様は 2026 年 9 月 までにバージョン 2.5.79.0 以降へのアップグレードが必要です。
以前にお知らせした とおり、リクエストの送信者が My Access ポータルで、保留中のアクセス パッケージの承認者の名前と E メール アドレスを直接確認できるようになります。この機能は、透明性を高め、依頼者と承認者間のコミュニケーションを効率化することを目的としています。既定では、ゲストを除くすべてのメンバーはテナント レベルで承認者を確認でき、この設定は Microsoft Entra 管理センターのエンタイトルメント管理にて変更することも可能です。アクセス パッケージのレベルでは、管理者や所有者が詳細設定を使用することで、承認者の見える/見えないを変更したり、テナント設定を上書きしたりが可能です。
Microsoft は、Microsoft Entra テナントの所有権の追跡を目的として、請求に使用されているアカウント情報を活用し、無料の Microsoft Entra ID Free サブスクリプションを今後各テナントに展開します。10 月から Microsoft 365 および Azure ポータルにこのサブスクリプションが登場しますが、お客様側の対応は不要で、請求や機能にも影響を与えません。これはテナントの所有権を安全に管理するためのものです。
Microsoft Entra: 認証情報の登録と管理の UX を刷新
[お客様による対応は不要です]
Microsoft Entra は 2025 年 11 月に認証情報の登録および管理インターフェースを更新し、使いやすさとアクセシビリティを向上させます。お客様側での対応は特に必要ありませんが、スムーズな移行のため、事前にヘルプデスクに情報を共有しておくことをお勧めします。本変更に関してコンプライアンス上の懸念はございません。
Microsoft Graph PowerShell を利用したオブジェクト管理について、グローバル管理者等の強いロール権限を持たないユーザーに PowerShell を使用させたい場面]]>
Microsoft Graph PowerShell アクセス許可の付与2026-05-06T09:09:28.462ZAzure Identity Support Japan
こんにちは、Azure & Identity サポート チームの長谷川です。
Microsoft Entra Connect 同期 (以下 MEC と表記) では AD FS を構成および管理することができます。その際には MEC のウィザードから「フェデレーションの管理」の項目を用いて AD FS を構成しますが、この構成の際、以下の画面のとおり MSIS7612 エラーが発生し AD FS の構成に失敗することがあります。このエラーが発生すると、その時の IssuerUri (クレーム ルール) の設定値次第ではフェデレーションの信頼関係が崩れ、フェデレーション ユーザーの認証にも影響が生じます。本ブログではこのエラーについて説明します。
MSIS7612 とは
MSIS7612 は AD FS の証明書利用者信頼を構成する際に指定した各識別子のいずれかが、すでに AD FS で構成済みの証明書利用者信頼で既に利用されている (重複している) 際に表示されるエラーです。各識別子は AD FS 上での重複は許されず一意である必要があります。
MEC で MSI7612 が記録されるパターン
以下の条件が重なっている場合に、MEC のウィザードから Microsoft Entra ID 用の証明書利用者信頼を更新しようとすると MSIS7612 エラーが発生します。
AD FS を利用しており、すでに Microsoft Entra ID 用の証明書利用者信頼を構成している。
AD FS 上の Microsoft Entra ID 用の証明書利用者信頼の表示名が「Microsoft Office 365 ID プラットフォーム Worldwide」以外となっている (例: 「Microsoft Office 365 Identity Platform」や「Microsoft Office 365 Identity Platform Worldwide」など)。
MEC で AD FS を管理している。
MEC をインストールしている Windows Server の OS の言語設定を英語以外の言語 (日本語) にしている。
MEC を最新版にアップグレードした。
MEC で MSI7612 が記録される理由
MEC で Microsoft Entra ID 用の証明書利用者信頼を更新しようとした場合、MEC は AD FS に対して証明書利用者信頼の有無を検索します。この検索の際には証明書利用者信頼の表示名も利用します。しかしながら、MEC がこの検索に利用する証明書利用者信頼の表示名は OS の言語設定に依存して変わる動作になっています。MEC は、日本語環境の場合は「Microsoft Office 365 ID プラットフォーム Worldwide」という表示名で証明者利用者信頼を検索します。
既に AD FS 上で構成されている Microsoft Entra ID 用の証明書利用者信頼の表示名が「Microsoft Office 365 Identity Platform」もしくは「Microsoft Office 365 Identity Platform Worldwide」の場合、MEC が検索に使用する表示名である「Microsoft Office 365 ID プラットフォーム Worldwide」とは名前が異なるため、MEC は証明書利用者信頼がまだ AD FS 上に構成されていないと誤認します。この結果、MEC は新たに Microsoft Entra ID 用の証明書利用者信頼を AD FS 上に構成しようとします。実際には Microsoft Entra ID 用の証明書利用者信頼は構成済みであるため、識別子の重複が検出されます。その結果 MSIS7612 が記録されます。
MEC で MSI7612 が記録された際の影響
この MSIS7612 が表示された場合、MEC によりすでに Microsoft Entra ID 側のフェデレーション構成のアップデートが行われ、その後の AD FS 側の更新処理が失敗したという状況です。つまり Microsoft Entra ID 側のフェデレーション構成は更新されたが AD FS 側は未更新という状況のため、Microsoft Entra ID 上の IssuerUri の値と AD FS によって発行される IssuerUri の値に不一致が生じる可能性があります。これらの値が不一致となった場合、フェデレーション信頼の構成が崩れ、結果としてそのドメインをもつユーザーがフェデレーション認証する際に AADSTS50107 エラーが発生し、ユーザーは Microsoft Entra ID へのサインインに失敗するようになります。
MEC で MSI7612 を回避する方法
MEC をインストールしている Windows Server OS の言語設定を日本語にしている場合は、AD FS 上の Microsoft Entra ID 用の証明書利用者信頼の表示名を「Microsoft Office 365 ID プラットフォーム Worldwide」に変更することで MEC での証明書利用者信頼を更新が可能になります (大文字、小文字、スペースの位置、カタカナ部分などは変えずにまったく同じ文字列にしてください)。表示名の変更手順は以下のとおりです。
SAML 連携時に必ず必要となるのは Name ID (名前識別子) 属性です。Name ID 属性には IdP (Entra ID) で認証を完了したユーザーの識別子が埋め込まれれます。この Name ID (名前識別子) 属性には、さまざまな形式が用意されており、アプリによっては適切に構成することが必要です。SAML 連携を構成する際に、Entra ID が既定でどの「名前識別子の形式」を利用すべきかアプリ側から指示があるはずですので、その指示に合わせて指定ください。指示がない場合は、念のためアプリ側に確認することをおすすめします。
「一意のユーザー識別子 (名前 ID)」の中にある「名前識別子の形式」
「名前識別子の形式」は Name ID (名前識別子) がどのような形式であるかを指定する箇所です。SAML 連携を構成する際に、アプリ側から指示があるはずですので、その指示に合わせて指定ください。
Note
「名前識別子の形式」が未指定であっても、アプリが SAML 要求の中でその形式を明示していればその形式が利用されます。つまり、アプリから Microsoft Entra ID へ送られる SAML 要求の中で形式が指定されている場合は、SAML 要求の中で指定された「名前識別子の形式」に従って、Entra ID は SAML 応答を生成します。この場合、「属性とクレーム」にて「名前識別子の形式」を指定していても、SAML 要求の中で指定された形式が優先されます。
一方で、アプリから Microsoft Entra ID へ送られる SAML 要求において、「名前識別子の形式」が指定されていない場合は、「属性とクレーム」の個所にて設定する「一意のユーザー ID」の「名前識別子の形式」に指定した形式で、SAML 応答が作成されます。このため、SAML 応答に意図した値が反映されているか念のため確認ください。
Microsoft Authenticator アプリは、Microsoft が提供している認証用のアプリです。Microsoft Entra ID や Microsoft アカウントを利用しているお客様は、まずそのサービスの利用にあたりサインインが必要になります。このサインインの体験をよりスムーズかつ安全にするために Microsoft Authenticator アプリが開発されました。Microsoft Authenticator アプリはサインインの流れの中で、特に多要素認証 (MFA) をより簡単かつ安全にするためにデザインされています。
SMS や音声通話を MFA で利用されているお客様に置かれましては、ぜひ Microsoft Authenticator アプリを活用した「Better」および「Best」な認証方式に移行ください。ここからは、これら「Better」および「Best」な認証方式について紹介します。
Better: プッシュ通知による MFA
この方式は、パスワードで認証した後に Microsoft Authenticator アプリにプッシュ通知が届き、アプリ側でその通知を承認することで認証を完了する仕組みです。信頼性の低い電話網を利用する SMS や音声通話に対し、暗号化された通信を使用することで、通信経路の安全性を確保しています。また、大量の認証リクエストをユーザーに送るなどして、ユーザーに誤って承認させる手法 (MFA 疲労攻撃) への対策として、「数値の一致」機能や「アプリケーション名の表示」機能、「地理的な場所の表示」機能が導入されています。
数値の一致機能では、サインイン画面に表示される 2 桁の数字を Microsoft Authenticator アプリに入力することで認証が完了します。これはユーザーが必ず認証画面の前におり、画面に表示された番号を見ながら Microsoft Authenticator アプリを操作して承認するということを確実にするための仕組みです。加えて、Microsoft Authenticator アプリの画面には、サインインしようとしているアプリの名前やサインインが開始されたユーザーの地理的な場所を表示するよう構成することもできます。これらの情報により、ユーザーはその要求が確かに自分自身により意図して開始されたものであることを確認して承認することが可能となります。
例えば、ユーザーが画面の前にいない状態で、見知らぬ MFA 要求がスマートフォンに通知されたとしても、ユーザーは正しい数字を知らないため、通知に応答することができません。またユーザーが PC の画面の前にいたとしても、サインインしようとしているアプリとは異なるアプリ名が Microsoft Authenticator アプリに表示されていたり、ユーザーが存在しない場所 (外国など) が Microsoft Authenticator アプリに表示されていたりする場合は、それが自分自身の意図したサインインではないということに気づくことができます。これにより、ユーザーがフィッシングに気づきやすくなります。
なお、現状では秘密の質問を認証方法の一つとして提供し続ける予定です。しかし、米国政府が発行している ID 標準 (NIST Special Publication 800-63B) では、ユーザー認証の方法として秘密の質問の利用が非推奨であることが挙げられます。弊社ではお客様に選択肢を提供するという意味で秘密の質問を認証方法の一つとして提供を続けますが、秘密の質問はパスワードと同様に記憶に基づく認証方法であり、認証強度の低い方法です。このため、秘密の質問ではなく、他の認証方法の利用も是非ご検討ください。
Microsoft Entra Private Access は、オンプレミス、リモート、ハイブリッド環境全体で、一貫した ID およびネットワークのセキュリティ制御を提供します。ドメインで認証されるリソースへのすべての認証要求を条件付きアクセス ポリシーで検証することで、ユーザーの場所に関係なく、ネットワーク境界に基づく暗黙的な信頼から継続的な検証へと環境を移行可能になります。
すべてのリソースを対象とした ID 中心のゼロ トラスト
Microsoft Entra Private Access は、重要なオンプレミス リソースに対して ID ベースの制御を追加することで、ZTNA を強化します。管理者は SPN (Service Principal Name) レベルで詳細なポリシーを設定できます。これは例えば cifs/* ファイル共有に対して MFA を要求したり、MSSQL/* サーバーへ準拠デバイスでのアクセスを許可したり、機密性の高い RDP サーバーに対してステップアップ認証を適用したりというものです。これにより、リスクに基づいてポリシーを分けたり、サービスへのアクセスをきめ細かく制御したりが可能になります。
シームレスなユーザー体験と強力な制御
管理インターフェースは Microsoft Entra 管理センター内の Global Secure Access に統合されており、ドメイン コントローラーの登録、アプリケーション セグメント (SPN) の構成、条件付きアクセス ポリシーの割り当てを一元的に行えます。ポリシーは Private Access センサーに動的に配布され、再起動を必要とせず、効率的かつ一貫した適用が可能です。
Microsoft Defender からのセキュリティ スコアの推奨事項が Microsoft Entra ID の推奨事項として利用可能になりました
昨年、弊社は Microsoft Entra ID の推奨事項に対して、セキュリティの改善につながる新たな情報を追加することで、お客様が組織のセキュリティ体制を強化し、リスクの特定と軽減に役立つ実用的なヒントを得られるようにしました。Microsoft Entra ID の推奨事項は、AI やエージェントベースの脅威が高度化する中で、信頼できるセキュリティ アドバイザーとしての役割を果たすことを目的としています。加えて、Microsoft のセキュリティ製品群におけるベスト プラクティスと業界標準をこの機能にまとめ、単一のプラットフォーム上でセキュリティを確保しながら、従業員の生産性向上とゼロ トラストの実現を支援することも目指しています。
セキュリティ体制の確立は、ID にまつわる脅威の検出と対応 (Identity Threat Detection and Response, ITDR) を成功させるための重要なステップです。Microsoft は、ID とアクセス管理のベスト プラクティスに Defender のセキュリティ情報を組み合わせることで、継続的にセキュリティを強化できる仕組みを提供しています。現在 パブリック プレビュー 中の Microsoft Defender for Identity から新たに 24 件の ID セキュリティ スコア推奨事項 が追加され、組織のセキュリティ体制に対しての可視性がさらに向上しました。これらの推奨事項は、ID ベースのサイバー攻撃の防止、検出、対応を支援するだけでなく、ID チームとセキュリティチーム間の連携強化にも貢献します。
ローカル管理者パスワード ソリューション (LAPS) は、ドメインに参加しているコンピューターのローカル アカウント パスワードの管理機能を提供するものです。パスワードは AD に保存され、ACL により保護されるため、対象となるユーザーのみが読み取りやリセットを要求できます。Microsoft ではお客様環境に LAPS を導入することをお勧めしています。
10. Microsoft Entra Connect AD DS コネクタ アカウントのパスワードをローテーションする
コネクター アカウントは、オンプレミスとクラウドの間で ID を同期する上で重要な役割を果たします。コネクター アカウントのパスワードが 90 日以上変更されていない場合、ハイブリッド ID 環境の弱点となる可能性があります。特に権限の高いのサービス アカウントの場合、侵害のリスクを高めますので、定期的なローテーションが推奨されます。
11. Microsoft Entra Connect AD DS コネクタのエンタープライズまたはドメイン管理者アカウントを置き換える
Microsoft Entra Connect AD DS コネクターのアカウントが Domain Admins や Enterprise Admins グループに所属している場合、アカウントの権限が強すぎます。Entra Connect 用のアカウントに強すぎる権限を与えると、攻撃対象範囲が広がり、最小特権の原則にも違反します。これらの特権を削除するか、そのグループ メンバーシップを含めてこれらの特権を持たないアカウントに置き換えることをお勧めします。
12. VPN 統合を構成する
Microsoft Defender for Identity が提供するユーザー アカウント情報を活用することで、攻撃の調査を行う際の複雑さを低減できます。これは特に Defender for Identity が表示するユーザー アクティビティや異常な VPN 接続の検出を組み合わせて活用することで効果を発揮します。Microsoft Defender for Identity の VPN 統合ソリューションを用いると、VPN ソリューションからアカウント情報を収集し、IP アドレスや接続が発信された場所など、ユーザーの VPN 接続をユーザー プロファイルの画面に表示できます。
弊社がエンタープライズ環境のネットワークを分析すると、攻撃者が標的に至るまでに複雑な攻撃経路をたどっているということが分かります。この推奨事項は、Microsoft Defender for Identity が提供する高度な行動分析機能とエンティティ間の紐づけ機能を利用して、どのネットワーク セグメントやアクセス制御を活用すれば、攻撃者が横方向に移動して重要な企業資産に到達する前に、それをブロックできるかを特定することを目的としています。この分析結果は、統合された Microsoft Entra ID のセキュリティ推奨事項の画面から確認できます。
また、そのほかの対応方法としては、ユーザー ID をスクリプトやその他のタスクによる自動化を実現する際に利用しないようにする、ということが考えられます。お客様によっては、スクリプトやその他のタスクによる自動化を実現するために、Microsoft Entra ID のユーザー ID をサービス アカウントとして利用されているかと存じます。このような場合にもこのフェーズ 2 の影響が及びます。フェーズ 2 の展開が完了し、MFA が義務付けされると、非対話的にサービスとして認証しているユーザー ID は、MFA の要求に対応できず、スクリプトやその他のタスクによる自動化が停止することになります。弊社ではこのような自動化を実行するためのサービス アカウントとしてユーザー ID を利用することは、以前からおすすめしておりません。
スクリプトやその他のタスクによる自動化では、ユーザー ID ではなく、サービス プリンシパルやマネージド ID といった ワークロード ID の利用が推奨です。ユーザー ID から ワークロード ID に移行することで、今回の変更の影響を受けないようにするとともに弊社の推奨事項に沿った構成になりますので、ぜひご検討ください。フェーズ 2 の MFA の義務付けはユーザー ID にのみ適用され、ワークロード ID には適用されません。
上記の影響を受けるアプリケーションを利用しているユーザーや、スクリプトやその他のタスクによる自動化を実行するために Microsoft Entra ID のユーザー ID をサービス アカウントとして利用せざるを得ないお客様においては、それらのユーザー ID が利用できる MFA の方法をご準備ください。例えば、認証用の電話番号や Microsoft Authenticator アプリなどです。フェーズ 2 による MFA の義務付けが実施されると、MFA の方法が未登録のユーザーには MFA 方法の登録が要求されます。登録画面に沿ってご要望の MFA の方法を登録ください。
PS C:\test > New-AzStorageAccount -ResourceGroupName MyResourceGroup -Name mystorageaccount -Location westus -SkuName Standard_GRS -MinimumTlsVersion TLS1_2 New-AzStorageAccount: Resource 'mystorageaccount' was disallowed by policy. Reasons: 'Sample Text: To resolve this error, set up MFA at aka.ms/setupMFA. If you set up MFA and are still receiving this error, reach out to your Entra administrator to restore your Azure security default.'. See error details for policy resource IDs.
Run the cmdlet below to authenticate interactively; additional parameters may be added as needed.
PS C:\test> az storage account create -n mystorageaccount -g MyResourceGroup -l westus --sku Standard_LRS Run the command below to authenticate interactively; additional arguments may be added as needed: az logout az login --tenant "f9800b67-61ea-4627-80e5-e7fc741e2497" --scope "https://management.core.windows.net//.default" --claims-challenge "eyJhY2Nlc3NfdG9rZW4iOnsiYWNycyI6eyJlc3NlbnRpYWwiOnRydWUsInZhbHVlcyI6WyJwMSJdfX19" (RequestDisallowedByPolicy) Resource 'mystorageaccount' was disallowed by policy. Reasons: 'Sample Text: To resolve this error, set up MFA at aka.ms/setupMFA. If you set up MFA and are still receiving this error, reach out to your Entra administrator to restore your Azure security default.'. See error details for policy resource IDs. Code: RequestDisallowedByPolicy Message: Resource 'mystorageaccount' was disallowed by policy. Reasons: 'Sample Text: To resolve this error, set up MFA at aka.ms/setupMFA. If you set up MFA and are still receiving this error, reach out to your Entra administrator to restore your Azure security default.'. See error details for policy resource IDs. Target: mystorageaccount
A. ユーザー ID は、Azure Portal (https://portal.azure.com) > [Microsoft Entra ID] > [ユーザー] のブレードで表示される ID を指します。[ユーザー] ブレードに表示される ID は、人間の従業員に割り当てられる ID で、人間がブラウザーやアプリから利用することを意図して作られたものです。
一方で、ワークロード ID は、スクリプト、アプリケーション、サービス、コンテナーなど、システムに割り当てられる ID を指しています。ワークロード ID は、Azure Portal (https://portal.azure.com) > [Microsoft Entra ID] > [エンタープライズ アプリケーション] のブレードで表示されます。より具体的には “アプリケーション (サービス プリンシパル)” や “マネージド ID” というオブジェクトとして Entra ID に登録されます。
以下の弊社技術ブログにて、サービス プリンシパルおよびマネージド ID の概要やご利用方法などの詳細についてご紹介しておりますので、こちらの内容も併せてご参照ください。
# Use the application ID as the username, and the secret as password $credentials = Get-Credential Connect-AzAccount -ServicePrincipal -Credential $credentials -Tenant <tenant ID>
[Preview]: Users must authenticate with multi-factor authentication to delete resources の場合 : DenyAction [Preview]: Users must authenticate with multi-factor authentication to create or update resources の場合 : Deny
