SharePoint ワンタイムパスコード (OTP) が廃止されMicrosoft Entra B2B へと移行へ

OneDrive および SharePoint 内の SharePoint ワンタイムパスコードに(SPO OTP)認証が2026年7月に廃止されます。

2026年5月から、外部共有の招待と認証は SPO OTPではなく、Microsoft Entra B2B を使うようになります。

🎓SharePoint ワンタイムパスコード認証とは?

SharePoint のワンタイムパスコード認証に関しては下記の記事に詳しく書いていますが、簡単に整理するとこれまではMicrosoft 365 アカウントや Microsoft アカウントを持たない社外のユーザーに SharePoint のコンテンツを共有する際に、これまでは SharePoint 独自のワンタイムパスコード認証を使ってきていました。このワンタイムパスコード認証では Microsoft Entra ID にゲストアウントを作ることなく認証できるというものです。

しかし、今後は Microsoft Entra ID の B2B統合が自動的に有効になり、Microsoft 365 アカウントや Microsoft アカウントを持たない社外のユーザーに対しても必ず Entra ID にゲストアウントを自動生成できるようになります。ゲストアウンとがあれば、ゲストアカウントのライフサイクル管理が可能になるだけでなく、条件付きアクセスポリシーによるコントロールなどもできるようになります。

これによってEntra B2B でのゲストアカウントが利用できるようになります。現在、B2B統合は SharePoint の eSignature や社外との秘密度ラベルで暗号化したドキュメントのやり取りなどで必須の設定であり、これを明示的に行わなくてもよくなるのは朗報だといえそうです。

🎓SharePoint ワンタ

EnableAzureADB2BIntegration 設定の今後

これまでMicrosoft Entra ID とB2B統合を行うには SharePoint 管理シェルコマンドを使ってテナントのEnableAzureADB2BIntegration オプションを有効化する必要がありました。しかし、B2B統合は自動的に行われることになるため、この設定自体が無効になります。逆に、従来のようにこのオプションを無効化することもできなくなります。

⚠️外部ユーザーへの影響

すでに Entra B2B ゲストアカウントを持っている場合は特に変更はありません。

テナントに更新が適用された後

Entra B2Bゲストアカウントを持っていない外部ユーザーは、特定のユーザーと共有されるリンクは、Entra B2B Invitation Manager 経由でゲストアカウントが自動的に作成されます。認証は Entra B2B を使います(メールのOTPが有効になっている場合)。

テナントに更新が適用される前

2026年7月まで SharePoint の OTP認証は引き続き利用できます。ただし、2026年7月を過ぎると、これらの対象となるユーザーは B2B ゲストアカウントの照合ができるようになるまでアクセスが拒否されることになります。

🛠️管理者としての準備

2026年7月から、SharePoint のOTPを利用する古いリンクを使っている際に外部の共同作業を行うユーザーはアクセスが拒否される可能性があることをユーザーに通知します。

組織がEntra 経由でのEmail OTP認証を利用するのであれば、Entra External ID 設定のEmail OTP認証を無効化しないようにします。

外部共有ポリシーを見直すだけでなく、SharePoint および Entra 管理センター内のゲストへの条件付きアクセス設定を確認しておきます。

ゲストアカウントを持たない外部の共同作業者は外部共有レポートを通じて特定できます。アクセスを維持するために、事前にゲストアカウントを作成する対応も考慮しておきましょう。

⏱タイムライン

改めてタイムラインをまとめておきましょう。

2026年5月

新たに外部共有する際の招待および認証は Entra B2B に移行します。以前の SharePoint のOTPを使った認証を利用していたユーザーはB2Bゲストアカウントがなくても、引き続き特定のユーザーとの共有リンクを利用できます。

2026年7月

SharePoint のOTP認証の廃止が開始されます。ゲストアカウントがない場合は、以前の特定のユーザーとの共有リンクに基づくアクセスは拒否されます。

外部ユーザーに再びアクセスさせるには、Entra B2Bにゲストアカウントを作成する必要があり、またファイル/フォルダー/サイトの共有リンクの再作成が必要です。

2026年8月31日

廃止完了見込みです。

参考

Power Platform: HTTP with Microsoft Entra ID コネクターが廃止⇒ HTTP with Microsoft Entra ID (preauthorized) を使おう

Power Platform の HTTP with Microsoft Entra ID コネクターが 2024年8月末ごろに急遽廃止になったようです。現在、Power Automate で確認したところモダンデザイナーではそもそも旧コネクターがでてきません。コネクターの一覧でも "Deprecated" の文字があります。

後継としてはすでに提供されている HTTP with Microsoft Entra ID (preauthorized) を使うことになります。ただ、API エンドポイントによってはどうも制限がされているようです。私のお客様からも利用できないエンドポイントがあるという話は耳にしています。この辺りは、下記の新旧コネクターの比較記事が詳しいです。

What is the difference between HTTP with Microsoft Entra ID and HTTP with Microsoft Entra ID (preauthorized) connectors? - Forward Forever

なお、Microsoft Learn のコネクター説明のページは 2024年9月27日現在、日本語ページに "廃止" については書かれていません。ただし、英語の方はすでに更新されおり、廃止に言及しています。

HTTP With Microsoft Entra ID (deprecated) [DEPRECATED] - Connectors | Microsoft Learn

ちなみにさきほどご紹介した Forward Forever の記事の下にコメント欄があり、あれこれやり取りされていますが、どうも廃止は急だったようでアナウンスもなかったようですね。私もあれこれ調べましたが、廃止のアナウンスは見つけられませんでした。コメント内でも "サポートに問い合わせたら Microsoft も知らなかったようだ" とも書かれているので、いつの間にか廃止になったようです。コネクターで deprecated になるものはたくさんありますけど、こんなに早く廃止されて使えなくなるというのは珍しいように思います。

ということで、これに関して日本語の情報が見当たらなかったので備忘録として記事にしておきました。

秘密度ラベルと条件付きアクセスポリシーで重要な SharePoint サイトアクセスを制御しよう

Entra 認証コンテキストを使用すると、特定の秘密度ラベルを適用したサイトにのみ特定の条件付きアクセスポリシーを適用できるようになります。これにより特定のサイトに対して厳しい認証条件を適用することなどが可能になります。

ちなみに秘密度ラベルを使わずに直接ポリシーをサイトに適用することも可能ですが PowerShellコマンド (Set-SPOSite)を利用する必要があります。

※ただし、SharePointのルートサイトにはこのポリシーは適用できないので注意してください。

ライセンス

SharePoint サイトで認証コンテキストを利用するには、次のいずれかのライセンスが必要です。

Microsoft Syntex - SharePoint Advanced Management
Microsoft 365 E5/A5/G5
Microsoft 365 E5/A5 コンプライアンス
Microsoft 365 E5 Information Protection and Governance
Office 365 E5/A5/G5

設定手順の概要

Entra ID 管理センターで認証コンテキストを追加し、条件付きアクセスポリシーを構成する。
Microsoft Purview コンプライアンスポータルで秘密度ラベルを用意し、認証コンテキストを使用して制限を適用する。

Entra 認証コンテキストの準備

Entra 認証コンテキストは次の手順で設定できます。

まず、Entra 管理センターにアクセスします。「保護」>「条件付きアクセス」の順にアクセスし、「認証コンテキスト」をクリックします。ここで「新しい認証コンテキスト」をクリックます。認証コンテキストの追加画面で、名前と説明を指定して作成します。認証コンテキストは要件ごとに複数作成できます。

条件付きアクセスポリシーの構成

次に条件付きアクセスポリシーを作成します。名前を指定して対象となるユーザーなどを指定します。「ターゲットリソース」の設定でポリシーの適用対象として 認証コンテキストを選び、作成した認証コンテキストを選択します。

秘密度ラベルの作成

Microsoft Purview コンプライアンスポータルにアクセスし、秘密度ラベルを作成します。ラベルの範囲の定義で「グループ&サイト」を選択します。

「グループとサイトの保護設定を定義」で “外部共有および条件付きアクセス” を選択します。

「外部共有および条件付きアクセスの設定の定義」で "Microsoft Entra 条件付きアクセスを使用してラベル付き SharePoint サイトを保護する」を選択し、使用する認証コンテキストを選択します。

このように秘密度ラベルを作成したあとは、適切なラベルポリシーを作成してユーザーに発行しておきます。

SharePoint サイトへの適用

作成した秘密度ラベルをテナント管理者、サイトの管理者またはサイトの所有者が特定の SharePoint サイトに適用します。

サイトへのアクセスを実験してみましょう。結果は次の通りです。

制限事項などの詳細

この設定には制限事項が比較的たくさんあります。実際に利用するときおよび最新情報の確認は下記の Microsoft Learn の記事を参照してください。

SharePoint サイトと OneDrive の条件付きアクセスポリシー - SharePoint in Microsoft 365 | Microsoft Learn

Edge for Business: 複数のプロファイルとMicrosoft Teams

Microsoft Edge for Business が Edge のリリースバージョン 116 (Stable) から展開されており、個人の Microsoft アカウント (MSA) と Microsoft Entra ID のアカウントのプロファイルを明確に分離して管理できるようになりました。お気に入り、キャッシュやストレージなどは個人用と仕事用とで明確に分かれるわけです。Edge for Business の概要はIT系のメディアのニュースなどでも取り上げられていますし、この記事の一番下に Microsoft 社からの公式情報のリンクも掲載しているため、これ以上は触れません。

その代わり、私が遭遇したトラブルと対処法について触れておきたいと思います。

プロファイルの自動切換えと Microsoft Teams

さて、表題の話に移りましょう。Edge for Business には自動的にプロファイルを切り替える機能が備わっています。これにより例えば、一般的なサイトは仕事とは直接関係ないので個人のプロファイルで閲覧し、仕事で利用するサイトへのは Entra ID アカウントのプロファイルに自動的に切り替えることができる利点があります。この設定はEdgeの「設定」>「プロファイル」>「プロファイルの基本設定」にあります。

この画面の下の「サイトのプロファイル設定」に注目してください。私の環境では既定では、teams.microsoft.com のサイトが追加され、「個人プロファイルに切り替える」ようになってるのです。

ここが本題に関わるのです。

仕事では Microsoft 365 の研修を定期的に行っているため私自身は複数のアカウントを用意し、これを切り替えてデモすることが多いのですが、いつからかプロファイルを切り替えて Microsoft 365 のアプリ起動メニューから Microsoft Teams のWeb版にアクセスしようとすると、どうやっても個人のプロファイルが起動し、個人アカウントに紐づけている Microsoft 365 開発者用テナント側の Teams が開いてしまう。このプロファイルの自動切換えを把握していなかったのです。

既定で「切り替え」なっていた設定を「切り替えない」に変えたところ、従来通り、各プロファイルの Web版のTeams にアクセスできるようになりました。

ということで、新機能が登場したらなべく早く情報をキャッチアップしておかないとダメですね～。

以上、情報共有でした!

[参考]

Azure AD PowerShell v2

Azure AD を管理するのに PowerShell をよく使いますが、従来の MSOnline モジュール (Azure Active Directory PowerShell v1) は廃止予定となっており、これから新規にスクリプト開発をする際には新しい AzureAD モジュール (Azure Active Directory PowerShell v2) を使っていくようにしたほうがよいでしょう。とはいえ、まだ AzureAD モジュールでは利用できない機能もあるため、まだ MSOnline モジュールも使うことがあります。※使い分ける必要があるのは厄介ですが、仕方ありません。

たとえば、削除した Office 365 グループの復元をするには、この AzureAD モジュールが必要です。

削除済みの Office 365 グループを復元する

従来の MSOnline モジュールとの大きな違いは、 Graph API が実装されていることです。(これは勝手な推測ですが) この新しい実装により Office 365 グループのように Azure AD にグループを作成するだけでなく、同時に関連するSharePointサイトを作成し、Exchange Online 上にメールボックスを作成しているようなケースでも、これら含めて復元できるようになるということであるようです。

詳しくは下記を参照してください。

Overview of Azure PowerShell

An overview of Azure PowerShell with links to installation and configuration.

Office 365 グループの復元についての注意

ところで、このAzureADモジュールですが、モジュールが General Availability リリースと Public Preview リリースと2種類あります。

2017/4現在だと下記の通りです。

機能的な違いがあるため気を付ける必要があるのですが、必ずしも GA のものがよいわけではありません。前述の Office 365 グループの復元に関しては Public Preview を使う必要があります。理由は、記載されている "Get-AzureADMSDeletedGroup" などのコマンドがないためです。GA からは削除されているようですね。しかし、本格運用はともかく、まずは検証したいということであれば、今のところPreview を使うしかないわけです。

このようにサポートされているコマンドに違いがありますので、利用するコマンドは果たしてどちらがよいか、確認するようにしましょう。

カテゴリ「Entra ID (Azure AD)」の6件の投稿

🎓SharePoint ワンタイム パスコード認証とは?