Microsoft Entra ID

【無料】M365のユーザー・グループ情報をExcelに一括出力するレポートツールを紹介 この記事の内容 Microsoft 365管理者向けに、ユーザー・グループ情報をExcelで出力できる無料ツールを紹介します GitHubで公開されているPowerShellスクリプトを使用し、セットアップから実行まで手順を解説します ユーザー、ゲスト、グループ、Teams、共有メールボックスなど多数の情報をまとめて取得できます 出力されたExcelは日付情報付きのスナップショットとして保存され、監査や比較に活用できます スクリプトはカスタマイズ可能で、必要に応じてSharePoint情報なども追加できます ツールの概要 本ツールは、GitHubの「M365 Management」リポジトリで公開されています。リポジトリ内にはさまざまなスクリプトが含まれており、その中のインベントリ・レポート系スクリプトを使うことで、以下の情報をExcel形式で一括取得できます。 ユーザー ゲスト グループ Teamsのチーム チームのメンバー・オーナー 共有メールボックスとその権限 配布グループおよびそのメンバー セキュリティグループ 技術的にはPowerShell 7.2以降を利用し、Azure ADやExchange Onlineの情報も取得可能です。 セットアップ手順 1. ツールのダウンロード GitHubの「M365 Management」リポジトリにアクセスします 「Code」ボタンから「Download ZIP」を選択し、PCにダウンロードします ダウンロードしたZIPファイルを右クリックして「すべて展開」を実行します 2. セキュリティ設定の解除 ダウンロードしたスクリプトは、Windowsのセキュリティ機能によってブロックされる場合があります。展開前または展開後に、各ファイルのプロパティを開いて「許可する」にチェックを入れ、ブロックを解除してください。ファイルごとに解除が必要な場合があります。 3. PowerShellの起動と初期設定 展開したフォルダを開きます フォルダ内で「PWSH」と入力し、PowerShell 7のコンソールを起動します コントロールキーを押しながらクリックして、管理者として実行します 以下のコマンドを順に実行します Set-ExecutionPolicy RemoteSigned cd オール .\setup_inventory_report_prereqs.ps1 必要モジュールのインストールと認証 セットアップスクリプトを実行すると、以下のモジュールが自動でインストールされます。 Microsoft Graph ImportExcel Exchange Online Management 途中でインストールへの同意を求められますので、指示に従って「Yes」を入力してください。 また、初回のみMicrosoft Graphへのアクセス許可が必要です。ブラウザが自動起動しますので、管理者アカウントでサインインし、組織の代理としてアクセス許可を承認してください。続いてExchange Onlineへの認証も求められますので、同様にサインインします。 レポートの実行方法 セットアップが完了したら、以下のコマンドでレポートを実行します。 .\generate_m365_inventory_report.ps1 実行時にも再度認証が求められます。Microsoft GraphとExchange Onlineそれぞれに対してサインインしてください。スクリプトが自動で各コマンドレットを実行し、情報を収集してExcelファイルとして出力してくれます。 出力される内容と活用方法 スクリプト実行後、output フォルダ内にExcelファイルとログファイルが生成されます。Excelには以下の情報がシートごとにまとめられています。 ユーザー・グループ Teamsのチーム・メンバー・オーナー 配布グループとそのメンバー ファイルには日付情報も含まれるため、実行のたびにその時点のスナップショットとして保存できます。過去の状態と比較したり、組織の監査資料として活用したりするのに役立ちます。 ...

BicepでMicrosoft Entra ID上のリソースも作成可能に！ この記事の内容 BicepのテンプレートでMicrosoft Entra ID（旧Azure AD）リソースが正式サポート（GA）されました 「Microsoft Graph Bicep Extension」という仕組みにより、グループやアプリケーション登録などをBicepで宣言的に管理できます 従来は必要だったPowerShellスクリプトとの組み合わせが不要になり、構成管理を一元化できます GitHub Actionsを使ったAzureデプロイなど、実際のユースケースで威力を発揮します 今後はMicrosoft 365・Intune・Exchange Onlineなど、さらに多くのリソースへの対応拡張が期待されています Bicepとは？改めておさらい BicepはMicrosoftが提供するInfrastructure as Code（IaC）ツールです。Azureリソースの構成を宣言的に記述し、テンプレートとして管理・デプロイできる仕組みを提供しています。 これまでBicepは主にAzureリソースマネージャー（ARM）リソースを対象としていましたが、今回のアップデートからMicrosoft Graph API経由でMicrosoft Entra ID（旧Azure AD）リソースも扱えるようになりました。 これまでの課題 AzureリソースとMicrosoft Entra IDリソースはデプロイ方法が異なっており、組み合わせた構成を管理するのに手間がかかっていました。 例えば、WebアプリケーションをAzureにデプロイしてEntra ID認証を利用しようとすると、「アプリケーション登録」や「グループ」も合わせて作成する必要があります。しかしBicepだけではこれらを作成できないため、PowerShellスクリプト等で個別に作成し、そのIDをBicepテンプレートに渡すという二段構えの対応が必要でした。 新機能「Microsoft Graph Bicep Extension」の概要 今回のアップデートで追加された機能は Microsoft Graph Bicep Extension と呼ばれています。Bicepテンプレート内にEntra IDリソースを記述することで、従来のAzureリソースと同様の方法でデプロイできます。 対応しているリソースの例は以下の通りです。 Microsoft.Graph/groups（グループ） Microsoft.Graph/applications（アプリケーション登録） デプロイプロセスは従来のBicepと同じく、Azure CLIやPowerShellを使います。デプロイメントエンジンがテンプレートを処理する際、リソースごとにAzureリソースかMicrosoft Graph経由のEntra IDリソースかを自動的に振り分けて作成してくれます。 これにより、以下のような構成がBicepテンプレート1つで完結するようになりました。 Microsoft Entraのグループ作成 アプリケーション登録 グループへのメンバー追加 具体的な利用シナリオ：GitHub ActionsでのWebアプリ展開 新機能が特に威力を発揮するユースケースとして、GitHub Actionsを利用してAzure App ServiceにWebアプリを展開するケースを見てみましょう。 これまでの手順 従来は、GitHub ActionsからAzureリソースにアクセスするために以下の作業を手動で行う必要がありました。 Entra IDアプリケーション（サービスプリンシパル）を手動で作成 クライアントシークレットを発行 シークレットやアプリケーションIDをGitHubのSecretsに登録 Bicep新機能を使った手順 Microsoft Graph Bicep Extensionを活用すると、以下の構成をBicepテンプレート内で一括定義できます。 ...

以下に記事を生成します。 Microsoft推奨！クラウドネイティブ移行戦略 この記事の内容 Windows 10のサポート終了を機に、クラウドネイティブ管理への移行が推奨されています MicrosoftはWindows 11とIntuneを組み合わせた5ステップの移行戦略を提示しています Active DirectoryやConfiguration Managerからの段階的な移行方法を解説します グループポリシーやアプリケーション管理をIntuneへ移行する際の注意点を紹介します Entra ID Joinによる完全クラウドネイティブ管理の実現方法と、デバイス移行の選択肢を説明します はじめに：なぜクラウドネイティブ管理が注目されるのか 従来、多くの企業ではオンプレミスのActive DirectoryやConfiguration Manager（コンフィギュレーションマネージャー）を用いてWindowsデバイスを管理してきました。しかし、クラウドサービスの進化と業務環境の多様化により、場所を問わず一元管理が可能な「クラウドネイティブ管理」への移行が強く推奨されています。 クラウドネイティブ管理により、デバイスの導入・構成・更新・廃棄をインターネット経由で集中管理できます。セキュリティの強化や運用コストの削減、ユーザー体験の向上が期待できる点が、多くの組織から注目を集めている理由です。 移行全体像と必要な5ステップ Microsoftが示すクラウドネイティブ移行は、主に以下の5つのステップで進められます。 ステップ1：環境の準備 移行を始める前に、現在の環境を整えることが重要です。 ハードウェア要件の確認 Windows 11へのアップグレードには、TPM 2.0の搭載など、所定のハードウェア要件を満たす必要があります。まずは既存デバイスが要件を満たしているか確認しましょう。 OSのアップデート Windows 10デバイスは、最新バージョン（例：22H2）までアップデートし、すべてのパッチを適用しておくことが推奨されます。状態はパッチ管理ツールやレポート機能で確認できます。 ID同期とハイブリッドジョインの構成 Active DirectoryとMicrosoft Entra ID（旧Azure AD）との同期設定を行い、アカウント情報をクラウドに統合します。グループポリシーを活用してハイブリッドジョインも構成しましょう。 Intune環境とライセンスの準備 Microsoft Intune（エンドポイント管理サービス）が利用できるよう、ライセンスと権限を事前に確認しておきます。 共同管理（Co-management）の設定 Configuration ManagerとIntuneの共同管理設定を行い、管理対象を段階的にIntuneへ移行できるよう準備します。 ステップ2：グループ管理のIntune移行 グループポリシーの整理 既存のグループポリシー（GPO）の構成を見直し、必要に応じて整理・簡素化します。Microsoft Intuneの「グループアナリティクス」機能を活用すると、どの設定がIntuneで再現できるかを効率よく分析できます。 管理対象の切り替え 共同管理の設定を使って、デバイスの管理ワークロードをConfiguration ManagerからIntuneへ順次切り替えていきます。 重複・矛盾設定の回避 グループポリシーとIntuneで競合が起きないよう、設定の重複や矛盾を避けることが重要です。なお、MDMWinsOverGP ポリシーはMicrosoftから推奨されていないため、使用には注意が必要です。 段階的な展開 新しいポリシーや設定は、まずパイロットグループでテストし、問題がなければ全体展開する流れが安全です。 ステップ3：Windows 11へのデバイスアップグレード Windows Update for Businessやパッチ管理グループを活用し、対象デバイスを順次Windows 11にアップグレードします。進捗状況はダッシュボード等でモニタリングしながら、計画的に進めましょう。 ステップ4：アプリケーション管理のIntune移行 既存アプリケーションの棚卸し Configuration Managerで配布中のアプリケーションをリストアップし、Intuneで展開可能かどうかを確認します。この機会に不要なアプリも整理しておくとよいでしょう。 パッケージ化と展開 Intuneで配布できるよう、Microsoft Win32 Content Prep Toolなどを活用してアプリケーションをパッケージ化します。インストール・アンインストールコマンドや検証方法も事前に明確にしておきましょう。 ...

条件付きアクセスまとめ：設計・運用のベストプラクティス この記事の内容 Microsoft Entraの条件付きアクセスについて、MVP・トレーナーとして著名なクニースグル氏のブログ記事「All About Identity」の要点を解説します ポリシー設計における「シンプルさを保つ」戦略と、評価軸を用いた管理手法を紹介します Intune・PowerShell・Defender for Cloud Appsなど、他のMicrosoftサービスとの高度な連携パターンを説明します COBO・COPE・BYODといったデバイス管理モデルごとのアクセス制御の考え方を整理します 現場で起こりがちなトラブルとその解決策、および設計の原点に立ち返る視点を提供します 条件付きアクセスの基礎とよくある課題 今回は、Microsoft Entraの「条件付きアクセス」について、非常に参考になるブログ記事をご紹介します。 この記事は、長年Microsoft MVPとして活躍され、多くのIT技術者のトレーナーも務めるクニースグル氏が運営するブログ「All About Identity」に掲載された「条件付きアクセスまとめ」というエントリです。 企業のセキュリティ担当者であれば、「条件付きアクセスの設定を見直したい」「運用を引き継いだけれど、複雑でよくわからない」といった悩みを抱えることがあるでしょう。条件付きアクセスは非常に強力な機能ですが、独特の癖もあります。クニースグル氏の記事では、そうした課題を解決するための骨太な情報が体系的にまとめられています。 記事では、まず「条件付きアクセスとは何か」という基本から、分かりやすい図解を交えて丁寧に解説されています。さらに、具体的な設定例と共に、それに伴うトラブルシューティングについても詳しく触れられています。例えば、「IT担当者が緊急時にアクセスできなくなった」「社内IPアドレスが固定されていない環境でどう対応するか」といった、現場で起こりがちな問題とその解決策が示されています。 時には「そもそも実現したいことは何か？」という原点に立ち返り、別のアプローチを検討する視点も提供されており、多角的に理解を深めることができます。 ポリシー設計のベストプラクティス：シンプルさを保つ戦略 複雑なポリシーは管理を困難にするため、記事では「ポリシーはシンプルに保つべき」という原則が強調されています。そのために、明確な評価軸を設けてポリシーを定義し、運用していくことの重要性が提言されています。 評価軸を定めることで、「どのユーザー」のための「どのポリシー」なのかが明確になります。これにより、ポリシーの数が増えても、それぞれの役割が明確であるため、管理が煩雑になるのを防ぐことができます。 ただし、「シンプルにする」こと自体が目的ではありません。「どのようにシンプルさを維持するか」という戦略を持つことが不可欠です。その戦略を立てる上で、評価軸を持つという考え方は非常に有効なアプローチです。 各種Microsoftサービスとの高度な連携 条件付きアクセスは、他のMicrosoftサービスと連携することで、さらに強力なセキュリティを実現できます。記事では、以下のような連携パターンが紹介されています。 Microsoft Intune との連携 コンプライアンスポリシーを利用して、組織のセキュリティ要件を満たしたデバイスのみアクセスを許可する構成が可能です。デバイスの健全性を条件付きアクセスの判断材料として活用できます。 PowerShell によるポリシー管理 スクリプトを用いて、ポリシーの構成や状態を効率的にチェックする手法が紹介されています。多数のポリシーを一括で確認・管理する際に特に有効です。 Microsoft Entra ID P2 の高度な機能 P2ライセンスで利用可能になる高度な機能との連携により、よりきめ細かなアクセス制御が実現できます。 Microsoft Defender for Cloud Apps との連携 アプリケーションレベルでの詳細なセッション制御が可能になります。具体的には、印刷やコピー＆ペーストのブロックといった操作制限を実装できます。 この連携は特に注目すべき点で、高コストなVDI（仮想デスクトップ基盤）を導入せずとも、情報漏洩リスクを低減できる有効な手段として紹介されています。VDI代替手段として検討する価値があります。 デバイスの種類に応じたアクセス制御 記事では、デバイスの管理モデルごとにポリシーを使い分けるアプローチも紹介されています。以下の3つのモデルを定義し、それぞれに適したポリシーを適用します。 モデル 正式名称 概要 COBO Company-Owned, Business-Only 企業所有・業務専用デバイス COPE Company-Owned, Personally-Enabled 企業所有・個人利用可能デバイス BYOD Bring Your Own Device 個人所有デバイス このようにデバイスの利用形態ごとにポリシーを分けることで、セキュリティと利便性のバランスを取ることが可能になります。各モデルで求められるセキュリティ要件は異なるため、一律の制御ではなくモデルに応じた最適なポリシーを設計することが重要です。 ...

「このデバイス上のすべてのデスクトップ アプリと Web サイトに自動的にサインインしますか?」の意味 この記事の内容 このプロンプトは「自動サインイン設定」ではなく、Microsoft Entra ID へのデバイス登録を行うものです 安易に「OK」を押すと、将来の Microsoft Entra ハイブリッド参加構成時に重複登録の問題が発生する可能性があります 一度登録したデバイスの解除は管理者だけでは完結できず、ユーザー側の手動操作が必要です 最も効果的な対策は、レジストリ設定によってプロンプト自体を事前に無効化することです このプロンプトが表示される場面 WindowsでMicrosoft 365などのサービスにサインインする際、次のようなメッセージが表示されることがあります。 「このデバイス上のすべてのデスクトップ アプリと Web サイトに自動的にサインインしますか?」 一見すると、サインインの手間を省いてくれる便利な機能のように思えます。しかし、このメッセージの本当の意味を理解せずに「OK」をクリックすると、特に組織のIT管理者にとって後々大きな問題に発展する可能性があります。 メッセージの正体：デバイス登録の確認画面です このプロンプトが表示される背景には、WAM（Web Account Manager） と呼ばれるWindowsの認証フレームワークが関係しています。 そして、この画面の最も重要な目的は、単なる自動サインイン設定ではありません。実際には、「お使いのデバイスを Microsoft Entra ID（旧 Azure Active Directory）に登録するかどうか」 をユーザーに問いかけているのです。 「自動的にサインインしますか？」という分かりやすい言葉の裏で、組織のディレクトリにデバイスを登録するという重要な処理が行われようとしています。この点が、多くのユーザーにとって直感的でなく、混乱を招く原因となっています。 各選択肢がもたらす結果 プロンプト画面ではいくつかの選択肢が表示されます。それぞれの選択が実際に何を行うのかを正確に理解しておきましょう。 「OK」をクリックした場合 デバイスは 「Microsoft Entra 登録済み（Microsoft Entra Registered）」 という状態で、組織の Microsoft Entra ID に登録されます。 「組織がデバイスを管理できるようにする」にチェックを入れて「OK」した場合 Microsoft Entra ID への登録に加え、組織が Microsoft Intune によるデバイスの自動登録を構成している場合、デバイスは Intune の管理下にも置かれます。このチェックボックスは、Intune の自動登録が有効になっているユーザーにのみ表示されることがあります。 ...

【全EntraID管理者必見！】条件付きアクセスの「全てのリソース+除外設定」の挙動に注意が必要！ この記事の内容 Microsoft Entra ID の条件付きアクセスで「すべてのクラウドアプリ」を対象にしたポリシーに除外設定を加えると、意図しない挙動が発生することがあります 除外設定を追加しただけで、デバイス準拠要求のポリシーが特定のアプリに効かなくなる現象を実際に検証・確認しました この挙動はバグではなく、Microsoft の公式ドキュメントに記載されている仕様です User.Read や profile、openid などの低権限スコープのみを要求するアプリは、除外設定がある場合にポリシー適用から自動的に外れます セキュリティ要件によっては「すべてのクラウドアプリ＋除外設定」という構成が意図したとおりに機能しない可能性があり、既存ポリシーの見直しが必要です 前提：準拠デバイスを要求するポリシーの基本動作 まず、基本的な動作を確認します。Entra ID の条件付きアクセスポリシーを新規に作成し、「すべてのクラウドアプリ」へのアクセスに対して「準拠しているとしてマーク済みのデバイスが必要」という制御を設定します。 このポリシーを「レポート専用モード」で有効化し、Intune などに登録されていない非準拠デバイスから Entra ID 認証を試みます。 この設定では、非準拠デバイスからのアクセスはブロックされるはずです。実際にサインインログを確認すると、期待どおり「失敗」と記録され、失敗の理由として「準拠しているデバイスが必要」と表示されます。ここまでは、多くの管理者が期待する通りの動作です。 問題の挙動：除外設定を追加した途端、ポリシーが効かなくなる ここからが本題です。先ほど作成したポリシーに、ほんの少し変更を加えます。 対象リソースの設定で「すべてのクラウドアプリ」を選択した状態のまま、「対象外とするクラウドアプリ」に、現在テストしている認証とは全く関係のないアプリケーションを1つだけ追加します。 この状態で、再度、非準拠デバイスから Entra ID 認証（今回の検証では OP-SSH ログイン）を試みます。 ポリシーの意図としては、特定のアプリを除外しただけであり、それ以外のアプリには引き続きデバイス準拠の要求が適用されるはずです。しかし実際のサインインログを確認すると、結果は「成功」となり、条件付きアクセスポリシーは「適用なし」と表示されてしまいます。 つまり、関係のないアプリを1つ除外設定に追加しただけで、デバイスの準拠を求める制御が効かなくなってしまったのです。 なぜこのような挙動になるのか？公式ドキュメントの記述 この一見不可解な動作は、バグではなく Microsoft の公式ドキュメントに記載されている仕様です。 「すべてのリソースにアプリの除外がある場合の条件付きアクセスの動作」という項目に、次のような記述があります。 すべてのリソースを対象にしながらポリシーから除外するリソースがある場合、誤ってユーザーアクセスをブロックしないように、特定の低い権限のスコープがポリシーの適用から除外されます。 具体的には、以下のような基本的なユーザープロファイル読み取りに相当する、特権レベルの低いアクセス許可のみを要求するアプリケーションは、ポリシーの対象から自動的に外れます。 U p o s r p e o e r f n . i i R l d e e a d 今回の検証で利用した SSH ログインツールは、認証時にこれらの「基本的な情報」しか要求していませんでした。そのため、ポリシーに除外設定が加わったことで、この「低い権限スコープは許可する」という仕様が適用され、デバイス準拠のチェックをすり抜けてしまったというのが真相です。 ...

Azure MonitorでSecure Webhookを作成する方法 / Microsoft Entra ID この記事の内容 Azure MonitorのAction GroupでSecure Webhookを構成し、認証されたアクセスのみを許可する方法を解説します Microsoft Entra ID（旧Azure Active Directory）のアクセストークンを用いた認証・認可の仕組みを紹介します Secure Webhook用のサービスプリンシパル作成からアプリケーションロールの割り当てまでの手順を説明します PowerShellスクリプト（SecureWebhookSetup.ps1）を使ったセットアップ方法も紹介します Webhook呼び出し時のBearerトークン検証による安全なシステム連携の実現方法をまとめます Azure MonitorとAction Groupの概要 Azure Monitorは、クラウドサービスやリソースの監視・通知を行うプラットフォームです。監視イベントを検知した際、Action Groupを通じてメール送信やWebhook呼び出しなど、さまざまなアクションを実行できます。 Webhookは外部システムと連携する際によく使われる仕組みですが、セキュリティの観点からそのままでは不十分なケースがあります。そこで「Secure Webhook」を利用することで、認証されたアクセスのみを許可する、より安全な構成が実現できます。 Secure Webhookの仕組み Secure Webhookでは、Microsoft Entra IDで認証されたトークンを利用してWebhookの呼び出しを制御します。 Azure MonitorがAction Group経由でWebhookを呼び出す際、Entra IDから取得したアクセストークンをHTTPヘッダーに含めて送信します。Webhook側はこのトークンを検証することで、呼び出し元の認証と権限確認を行うことができます。 前提条件 セットアップを始める前に、以下の準備が必要です。 PowerShellのMicrosoft Graphモジュールをインストールしておくこと 適切なスコープでMicrosoft Graphに接続しておくこと Microsoft Graphへの接続には、以下のコマンドを使用します。 Connect-MgGraph -Scopes "..." これらの準備を行うことで、後続の手順で必要なコマンドレットが利用可能になります。 Secure Webhook用サービスプリンシパルの作成 Azure MonitorのSecure Webhook機能を利用するには、Microsoftが提供するファーストパーティのアプリケーション（マルチテナント型）を、自テナント内にサービスプリンシパルとして登録する必要があります。 まず、サービスプリンシパルが既に存在するかどうかを確認します。存在しない場合は新たに作成します。 このサービスプリンシパルはMicrosoftが提供する決まったIDを持つアプリケーションであるため、ユーザーが任意のIDを指定するものではありません。テナント内には「エンタープライズアプリケーション」として登録されます。 アプリケーションの登録とロールの設定 ステップ1：アプリケーションの登録 Microsoft Entra ID（Azure Active Directory）の「アプリケーション登録」から、新しいアプリケーションを作成します。 ステップ2：アプリケーションロールの作成 作成したアプリケーションに対して、「Action Group Secure Webhook」用の新しいアプリケーションロールを追加します。 ステップ3：サービスプリンシパルへのロール割り当て 前の手順で作成したSecure Webhook用のサービスプリンシパルに、ステップ2で作成したアプリケーションロールを割り当てます。この操作にはPowerShellの以下のコマンドレットを使用します。 ...