近年、多くの企業がAzureやEntra IDを活用し、セキュリティ強化のために多要素認証(MFA)を導入しています。しかし、メールやOneDrive移行ツールのBitTitanが新しい認証方式に対応しきれないケースもあり、MFAを一時的に無効化しないと移行が進まない場面が増えています。この記事では、実際の事例を元にAzure/EntraでのMFA無効化方法やConditional Access設定の要点、さらにBitTitanを使う際の注意点を分かりやすくご紹介します。
Azure/EntraでのMFAを無効化する理由と課題
AzureやEntra IDを利用するうえで、MFA(多要素認証)は企業や組織のセキュリティを高める重要な仕組みです。しかし、一部の移行作業ツールでは、MFAが有効なままだと認証が通らず、移行が失敗してしまうケースがあります。特にBitTitanのようなツールは、最新の認証方式に完全対応していない場合があり、作業中にユーザーが都度MFAコードを入力しなければならなくなるなど、実務上の手間が増大することがあります。
MFAを無効化するというのはセキュリティリスクを高める行為でもあるため、本来はあまり推奨されません。しかし、どうしても移行ツールが動作しない、あるいは多人数のアカウントを素早く移行する必要があるときは、短期間のみMFAを外すという選択肢が出てきます。以下では、具体的にAzure/Entra環境でのMFA無効化に関する方法と、その際の注意点をまとめます。
MFA無効化とセキュリティリスク
MFAを無効化すると、当然ながらセキュリティレベルが低下します。アカウントの乗っ取りリスクが高まり、外部からの不正アクセスを許しやすくなる可能性があります。とくに管理者アカウントなど権限の高いアカウントは、MFA無しの状態が長引くと危険です。そのため、移行が終わったらすぐにMFAを再設定する運用が望まれます。
Security DefaultsとConditional Accessの違い
Azure/EntraでMFAを制御する際、「Security Defaults」と「Conditional Access(条件付きアクセス)」という概念があります。Security DefaultsはAzureやEntraの初期設定であり、MFAを強制的に有効化する仕組みが含まれています。一方、Conditional Accessでは、ポリシーを柔軟に設定して特定のグループやアプリケーションに限りMFAを適用しないようにすることが可能です。
Security Defaultsが有効な環境の場合は、まずこれをオフにしないと柔軟な設定ができません。しかし、Security Defaultsを単純にオフにするだけでは、移行ツールが確実に動作するとは限りません。Conditional Accessポリシー側で移行に必要なユーザーを除外設定に組み込むことが望ましいです。
MFA無効化の具体的手順
MFAを無効化しようとしてもうまくいかず、移行ツールとの認証が失敗してしまう事例が報告されています。主な原因としては、Security Defaultsが依然として有効になっている場合と、Conditional Accessポリシーの設定範囲が正しく構成されていない場合が考えられます。ここでは、それぞれに対処するための大まかな手順を解説します。
Security Defaultsの無効化
Security Defaultsを無効化する手順は以下のような流れになります。
ここではテキストだけではわかりにくいので、表を用いて手順をまとめます。
手順 | 作業内容 |
1 | Microsoft Entra管理センターに管理者アカウントでサインイン |
2 | [Identity] → [Overview] → [Properties]へ移動 |
3 | 画面下部にある「Manage security defaults」を選択 |
4 | Security defaultsを「Disabled」に変更 |
5 | 保存して設定を反映 |
Security Defaultsを無効化することで、デフォルトのMFA強制が解除されます。ただし、これだけでは全ユーザーがMFAなしでログインしてしまうため、大幅にセキュリティが下がる可能性があります。移行が終わったら、再度有効化したり、別途Conditional Accessポリシーを設定したりすることを強くおすすめします。
Conditional Accessでの除外設定
Conditional Accessを使うことで、特定のアカウントやグループのみMFAを要求しないように設定することが可能です。以下のような流れで設定します。
手順 | 作業内容 |
1 | Azure AD(Entra)の[Security] → [Conditional Access]に移動 |
2 | 新規ポリシーを作成し、対象ユーザーまたはグループを指定 |
3 | 対象のアプリケーションやクラウドサービス(例: Exchange Online, SharePoint Online)を選択 |
4 | Grant(許可)項目で多要素認証の要求をオフに設定、または例外を設定 |
5 | ポリシーを有効化し、テストを実施 |
このように、グループに「移行用ユーザー」を割り当てておき、そのグループだけはMFAを使わない設定にすることで、移行作業中の認証トラブルを最小限に抑えることができます。しかし、この方法でも環境によっては、OneDriveやSharePoint側の認証がうまくいかないケースがあるため、十分にテストしたうえで導入することが必要です。

執筆者コメント: 一度移行用ユーザーをグループから外すのを忘れていて、MFAなしのまま数日放置していたことがあります。セキュリティリスクを考えると、作業後には確実に元に戻す運用ルールを作っておくべきだと痛感しました。
BitTitanによるメール・OneDrive移行のポイント
BitTitanは、メールやOneDriveを含むMicrosoft 365(旧Office 365)環境の移行を自動化・簡易化する便利なツールです。ユーザーやフォルダー構造、データをスムーズに移行できるメリットがありますが、最新の認証方式に完全対応していない場合があります。そのため、MFAが有効化された状態だと移行エンジンが認証に失敗し、プロセスが止まってしまうことがあるのです。
BitTitanが抱える認証問題
BitTitanがうまく動作しない背景には、MicrosoftがLegacy Authentication(従来の認証方式)を段階的に非推奨・無効化している点があります。これまでの移行ツールは、古いプロトコルに依存していることが多く、Modern AuthenticationやOAuth 2.0などへの完全対応が遅れていると、MFA環境下でのログインがうまくいきません。メール移行は通っても、OneDriveやSharePointの移行でエラーになるケースが多いようです。
Conditional Accessを使っても動かない場合
Conditional Accessで特定ユーザーをMFA適用対象外にしても、BitTitanが要求する認証レベルやプロトコルが複雑なため、SharePointやOneDriveへのアクセス認可が途中で引っかかることがあります。実際に検証してみると、メール移行は成功するのに、ファイル移行がエラーを出して停止するという事例も多く報告されています。
この場合、ツール側のアップデートを待つか、部分的に手動で移行するか、別の移行ツールに切り替えるなどの対応が必要になるでしょう。
一部を手作業で移行する際の注意点
BitTitanが完全に機能しない場合、メールだけをBitTitanで行い、OneDriveやSharePointのデータを手動(または別ツール)で移行するという手段があります。ただし、手動移行には手間と時間がかかりやすく、ファイルのメタデータや共有設定が移行されないなどの問題が発生することも考えられます。作業前に必要なファイル構成や権限設定を十分確認し、移行後に整合性チェックを行うことが重要です。
移行後のベストプラクティスとセキュリティ再強化
移行作業が終わったら、セキュリティを再度高める必要があります。MFAを無効化したまま放置していると、外部からの攻撃に対して脆弱になる可能性があるため、移行後の環境では以下のようなポイントを徹底しましょう。
MFAの再有効化
移行終了直後、もしくは移行用アカウントを使い終わったら、すみやかにMFAを再度有効化します。Security Defaultsをオフにしたままにするならば、Conditional Accessポリシーで全ユーザーにMFAを適用するルールを必ず作っておきましょう。管理者アカウントには特に厳格なMFAを設定するなど、セキュリティレベルを保つ工夫が大切です。
ログの監視と監査
移行後はどのアカウントがどのようにサインインしているかを監視し、意図しないアクセスが行われていないかをチェックします。Azure AD(Entra)にはサインインログや監査ログがあり、これらを活用することで不審な動きを早期に発見できます。移行によって作られたテストアカウントなどは不要になったら速やかに削除し、権限を整理することも忘れないようにします。
サポートへの依頼と別ツールの検討
BitTitanのサポートが迅速ではない場合、Microsoft 365の管理画面から直接Microsoftのサポートに問い合わせる方法もあります。また、サードパーティー製の移行ツールやMicrosoft提供の別ツールを検討するのも一つの手段です。クラウドサービスは日々更新されるため、特に大きな移行プロジェクトでは最新情報を常にキャッチアップし、必要に応じてツールを見直す姿勢が重要です。



執筆者コメント: 私自身、小規模移行ならBitTitanで十分だと思っていましたが、最近の認証変更に追いついていない様子を実感しています。サポートに時間をかけているとスケジュールが崩れるので、小規模でも手動で確実に移行してしまう方が楽な場合もありました。
まとめ: トラブルを最小化しつつスムーズに移行するコツ
Azure/Entra上でMFAを無効化して移行ツールを使う場合は、次のような流れを心がけるとスムーズです。
1. 移行の計画とバックアップ
移行前に、対象となるメールやOneDriveのデータ量、ユーザー数、権限設定などを整理します。必要に応じてバックアップを取ることで、移行中にデータが破損・消失してもリカバリーしやすくなります。
2. MFA無効化・例外設定の実施
Security Defaultsをオフにするか、Conditional Accessポリシーで例外を設定して、対象ユーザーだけMFAを適用しないようにします。ここで誤って管理者アカウントを常時MFAなしにしておくと高リスクなので注意が必要です。
3. 移行の実行と検証
BitTitanなどのツールを使って移行を行い、ログを確認しながらエラーが出ないかをチェックします。メール移行はうまくいっても、OneDriveやSharePointで躓く例があるので、必ず実際にファイルや共有権限が正しく移行されているかテストしましょう。
4. 移行終了後のMFA再有効化
移行が完了したらすみやかにMFAを再度有効化します。特定のユーザーやアカウントのみ例外にしていた場合は、漏れなく設定を元に戻しましょう。セキュリティを疎かにしないためにも、再度Security Defaultsを有効にする、またはConditional AccessポリシーでMFAを強制する仕組みを戻しておくことが不可欠です。
5. 別ツールやサポートの活用
もしBitTitanでどうしても対応が難しい場合、Microsoftのサポートに連絡したり、他の移行ツール(例: Quest製品やAvePointなど)を検討したりする選択肢もあります。移行プロセスには多くの要因が絡むため、1つのツールでうまくいかないときには別のアプローチを試すことが成功への近道です。
最終的なアドバイス
AzureやEntraでMFAがデフォルトになりつつある現状では、移行時にMFAを無効化するのは例外的な対応であると認識してください。短期間であれば問題ないかもしれませんが、恒常的にオフにしておくのはリスクが高いです。BitTitanを含む移行ツールは、Microsoftの認証方式の更新に追随してアップデートされることが多いので、定期的にバージョン情報やドキュメントを確認し、最新バージョンを使うようにしましょう。移行後は必ずMFAを再有効化し、セキュリティログの確認やアカウントの整理などを丁寧に行うことをおすすめします。



執筆者コメント: 最初は「MFAを切れば移行できるはずだ」と安易に考えてしまいましたが、実際には想定外のエラーが出たり、どうにか移行を完了しても設定を元に戻し忘れてトラブルになったりしました。これから移行に取り組む方は、ぜひ計画的に実施してください。
参考: コマンドや設定ファイル例
場合によってはPowerShellを使って移行や認証設定を確認・操作することもあります。例えばSecurity Defaultsが有効かどうかを確認するコマンドは現在公式では提供されていませんが、Azure AD PowerShellモジュールやGraph APIを利用してDirectory Settingを確認する手法も考えられます。下記のコードはあくまで概念的なサンプルですが、参考程度にご覧ください。
# 以下のコードはイメージです。実際のコマンドとは異なる場合があります。
Connect-AzureAD
# Security Defaults無効化の状態を確認(概念的な例)
Get-AzureADDirectorySetting | Where-Object {$_.DisplayName -eq "SecurityDefaults"}
このようにPowerShellでAzure AD(Entra)のディレクトリ設定を確認できる場合がありますが、実環境ではUIで操作したほうがわかりやすいと感じる場面も多いです。
また、BitTitan自体の設定ファイルや管理コンソールにおいても、移行対象とするサービスや認証方式を明示的に確認できるメニューが存在する場合があります。そちらも併せて確認し、最新のドキュメントを参照しながら作業を進めるのがおすすめです。
おわりに
AzureやEntraのMFAはセキュリティの要となる機能ですが、移行ツールが完全対応していない場合には工夫が必要です。Security Defaultsの解除やConditional Accessポリシーでの例外設定によって、一時的にMFAを無効化し、BitTitanや他のツールを使って円滑に移行を行うことができます。とはいえ、移行後はセキュリティを再度強化し、MFAを有効化することが最も大切です。ツールや環境によって手順や不具合のパターンはさまざまなので、常に最新の情報をチェックしながら慎重に進めてください。この記事が、移行作業に取り組む際の一助になれば幸いです。
コメント