Azure AD 管理の PowerShell について。
すでに以前から公表されていますが、2022年12月以降に以下のモジュールは廃止されます。
7月頃のブログ情報に、利用確認する方法についても記載されています。
今後は、Microsoft Graph API への移行検討が必要とされています。
Azure AD Graph / MSOnline PowerShell モジュール利用状況の調べ方 | Japan Azure Identity Support Blog
Microsoft Graph PowerShell SDK の開始についてはこちら。
Get started with the Microsoft Graph PowerShell SDK | Microsoft Docs
ゲストユーザーの招待など、Azure AD の B2B コラボレーションにおいて、「アンマネージド Azure AD アカウント」は廃止され、新しく作成されないことが発表されました。
Say goodbye to unmanaged Azure AD accounts for B2B collaboration - Microsoft Tech Community
まず「アンマネージド Azure AD アカウント」とは何か？ ですが、これは「管理者が存在しない Azure AD 」に存在するアカウントのことです。
そのような状況がなぜ発生するか具体的に説明すると、
例えば、 Azure AD が存在していない example.com の A-san@example.com が電子メールでゲスト招待された場合、A-san は Azure AD ベースの ID を作成するために「セルフサービス サインアップ」を利用することができました。
電子メールで確認されたユーザーのセルフサービス サインアップ - Azure AD - Microsoft Entra | Microsoft Docs
これを利用すると、電子メールのドメイン名が検証され、そのドメイン名の Azure AD ベースのアカウントが作成されますが、管理者不在の Azure AD アカウント（つまりアンマネージド Azure AD アカウント） が発生することになります。
このアカウントは管理者が不在な状態なため、B2B で招待する側、される側、双方で管理上の問題が発生していました。
今回の発表によると、SAML／WS-Fed のフェデレーションや Gmail アカウントかを確認し、それらでなければ「ワンタイムパスコード認証」が利用されることになります。
B2B ゲスト ユーザーのワンタイム パスコード認証 - Azure AD - Microsoft Entra | Microsoft Docs
もしも、ワンタイムパスコード認証が無効になっている場合は、Microsoft アカウントの作成が促されます。
なお、以前にアンマネージド Azure AD アカウントで招待されているアカウントについては、引き続き機能するそうです。
Exchange Online で基本認証が廃止される予告については、昨年11月に書きました。
Exchange Online での基本認証の廃止予告 - tos-akibaのブログ
これについて、アップデート情報の発表がありました。
Basic Authentication Deprecation in Exchange Online – September 2022 Update - Microsoft Tech Community
上記によると、10月1日よりテナントをランダムに選択し、MAPI、RPC、オフラインアドレス帳（OAB）、Exchange Webサービス（EWS）、POP、IMAP、Exchange ActiveSync（EAS）、リモート PowerShell の基本認証が無効化されます。
変更される場合は、7日前にメッセージセンターへ通知されます。
アップデートの追加発表によると、
この変更についてまだ準備ができていないお客様のために、10月1日以降に基本認証がオフになった場合、セルフサービス診断を使用して１回だけ、基本認証を再び有効にできるそうです。
ただし有効なのは 2022年12月末までで、2023年以降は基本認証は永久に無効になります。
なお、SMTP AUTH については、2022年10月1日に基本認証が無効になっていても使用可能で、理由は、プリンターやスキャナーなど多くのデバイスが先進認証を使用するよう更新できないため、だそうです。
しかし、SMTP AUTH による基本認証の使用もやめる方向へ強くお勧めされています。
オンプレミスの Azure MFA Server からクラウドの Azure AD MFA へ移行するユーティリティツールがパブリックプレビューされています。
Azure MFA Server 移行ツール | Japan Azure Identity Support Blog
オンプレミスの Azure MFA Server は、2019年7月からすでに新規ダウンロードは停止されており、クラウドベースの Azure MFA への移行が推奨されています。
この移行ツールは、Azure MFA Server の最新バージョンに含まれています。
移行用の Azure AD グループを作り、段階的なロールアウトでユーザーを順次、移行することもできます。
移行ステップの詳細については、こちらにガイドされています。
MFA サーバー移行ユーティリティを使用して Azure AD MFA に移行する方法 - Azure Active Directory - Microsoft Entra | Microsoft Docs
オンプレミスの Azure MFA Server や ADFS Server はクラウドへ移行して撤去できれば、サーバーの運用管理も削減することができます。
7月頃にマイクロソフトの研究チームから、多要素認証（MFA）を回避してセッション Cookie を盗難し不正なアクセスを行う Microsoft 365 への多数の攻撃があったことが報告されています。
（詳細な図解も以下に）
From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud - Microsoft Security Blog
この AiTM（adversary-in-the-middle）フィッシング攻撃は、2021年9月以降、10,000以上の組織が標的にされました。
これは、フィッシングサイトへのアクセスを正規のサイトへプロキシするサーバーを置き、そこを踏ませることで HTTP パケットやセッション Cookie を盗み取ります。
プロキシなので、視覚的には正規サイトのログイン画面が表示されるため、URL が疑わしい事に気付かないと判りにくいのです。
認証後のセッション Cookie を取得されてしまうと、それを利用して「認証済み」状態ができてしまうため、MFA が設定されていてもスキップされてしまいます。
レポートによるとこの攻撃の最初は「音声メッセージがあります」というフィッシングメールで、添付された HTML ファイルを開いてしまうとフィッシング用のプロキシへリダイレクトされ、Azure AD のログイン画面が表示されます。
疑わしいメールの添付ファイルは、不用意に開かない事は重要ですね。
厄介なのは、ログイン画面が組織のブランディング設定で例えば会社の写真を設定してあった場合もそれが正しく表示されるため、不正な誘導に気付きにくいのです。
攻撃者は、ここで得たセッション Cookie を利用して Exchange Online へ侵入し、さらに内部からの擬装メールによる詐欺行為を行っていたそうです。
しかしだからと言って、MFA の有効性が無くなった訳ではなく、ID セキュリティ向上のために MFA の実装自体は重要です。
また Microsoft 365 では、Azure AD の条件付きアクセスで、Endpoint Manager の管理下でポリシー準拠した端末からのアクセスならば許可するポリシー設定が出来たり、疑わしいアクティビティを検知する幾つかの機能により、盗難された資格情報による攻撃から保護する包括的な手段が提供されています。
多層防御の考え方に則り、攻撃を早く検知することも重要です。
昨日の投稿に引き続き、Microsoft 365 Defender ポータルの「アクションと報告」＞「報告」画面にある「ユーザーから報告されたメッセージ」について。
ここには、ユーザーが Outlook や Outlook on the web 上から報告したフィッシングメールや迷惑メール、および迷惑メールではない誤検知のメール報告が一覧されます。
ユーザー側の操作は、例えば Outlook on the web のメニューではこちら。
迷惑メールフォルダに入っている場合は「迷惑メールではない」と報告できます。
Outlook の場合は、メッセージレポート アドイン を追加することで、リボンのメニューに追加されます。
メッセージのレポートまたはフィッシング アドインのレポートを有効にする - Office 365 | Microsoft Docs
また、これらのユーザーからの報告の送信先を、直接 Microsoft へ送信許可するか、一旦、組織のメールボックスへ送信し、管理者が確認してから送信するかは、ポリシー設定で構成できます。
「ポリシーとルール」＞「脅威ポリシー」の「その他」にある「ユーザーから報告されたメッセージの設定」です。
ここで、組織のメールボックスに一旦送信させるユーザー申請メールボックスとする場合は、幾つか設定を加える必要があります。
スパム、フィッシング、悪意のあるメールとしてユーザーが報告した電子メール設定 - Office 365 | Microsoft Docs
Microsoft 365 Defender ポータルで、疑わしい電子メール、URL、添付ファイルをマイクロソフトへ送信して分析の上、ブロックできるようになりました。
Introducing tenant blocks via admin submissions - Microsoft Tech Community
メニューの場所は、「アクションと報告」の「報告」画面です。
メールの場合は、メッセージ ID を入力するかメール自体のファイルをアップロードします。
メッセージ ID は、「エクスプローラー」(Microsoft Defender for Office 365 が有効な場合）で検索してメールの詳細情報からも参照できます。
上記画面キャプチャには表示されていませんが、「〇迷惑メール」のさらに下に、その送信者またはドメインからのメールをすべてブロックするオプションが選択できるようになります。
提出を管理する - Office 365 | Microsoft Docs
また逆に、ブロックする必要がない誤検知であることをマイクロソフトへ報告することもできます。
許可リストはマイクロソフトが管理しており、「テナント許可／禁止リスト」に許可を追加することはできないため、この誤検知の申請から行う必要があります。
テナント許可/禁止リストを使用して電子メールを許可またはブロックする - Office 365 | Microsoft Docs
