マイクロソフト、Exchange Online メールボックスへの IMAP4 および POP3 アプリケーション アクセスを開始
戦術的な動きは良いが、正しい戦略ではない
私はマイクロソフトの戦術的な必要性を理解していますが POP3 および IMAP4 プロトコルの使用を希望するプログラムに対して OAuth 2.0 許可を有効にするには、以下の手順を実行します。 Exchange Online から電子メールを取得するには、Exchange Online IMAP4 および POP3 アクセスの正しい戦略ではないと思います。基本的に、マイクロソフトは、開発者にMicrosoft Graph APIへの変更を強制するのではなく、アンティークメッセージングプロトコルの継続的な使用を促進しています。私はそれが間違っていると思うが、私はマイクロソフトがそれをやっている理由を知っている。
Exchange Online の大規模な基本認証のターンオフは、わずか 88 日後に迫っています。10 月 1 日は、マイクロソフトが Exchange Online の 7 つの電子メール接続プロトコルを無効にし始めた時点を示しています。マイクロソフトがすべてのテナントを処理するには時間がかかりますが、最終的にはPOP3、IMAP4、Exchange ActiveSync などのプロトコルの使用を希望するユーザーは、先進認証を使用する以外に選択肢はありません。つまり、ユーザー名とパスワードだけでは不十分です。
マイクロソフトは、Exchange から基本認証を削除する準備を 2 年以上前から行ってきました。Exchange Online の規模、製品の歴史、プロトコルとデバイスの数が組み合わさって、無数の複雑さが生じます。 iOS および iPadOS デバイス上の Apple のデバイスメールアプリのプロファイルを自動的にアップグレードする このプロジェクトに関連する詳細な計画と技術的実行の種類の良い例です。
POP3 または IMAP4 を使用してプログラムでメールボックスからメッセージを取得するアプリケーションを使用している企業がいくつあるかはわかりません。Microsoft の伝説的なテレメトリが潜在的な顧客満足度の問題を検出するには、顧客が準備するのに十分な時間内に回答がリリースされずにターンオフが進行した場合に、十分な存在が必要です。
登録済みアプリと IMAP4/POP3 のアクセス許可
Microsoft のソリューションは、お客様が Azure AD 登録済みアプリを作成し、アプリが IMAP4 または POP3 を使用してメールボックスと対話できるようにするために必要なアクセス許可を割り当てることです。図 1 は、 イマップ。アクセスアスペル アプリへのアクセス許可。POP3 アクセスに対する同等のアクセス許可は次のとおりです。 ポップ。アクセスアスペル.
アクセス許可を割り当てた後、管理者は、アプリがアクセス許可を使用してユーザーのメールボックスにアクセスすることを許可することに同意する必要があります。
ここには奇妙なものは何もありません。アプリは同じプロセスに従って、Graph API アクセス許可を使用して、ユーザー アカウントから Microsoft 365 グループまでの他の種類の情報にアクセスできるようにします。唯一の違いは、IMAP4 プロトコルと POP3 プロトコルを介してアクセスを制御するための 2 つの特定のアクセス許可が存在することです。
サービス プリンシパルとオンライン交換
登録済みのアプリには サービス プリンシパルこれは、グラフAPIアーキテクトの言葉を借りれば、「アクセス許可のための便利な所有者。" Exchange Online には、新しい PowerShell コマンドレット 新しいサービスプリンシパル IMAP4 または POP3 アクセス許可を保持するアプリのサービス プリンシパルを認識させます。この例では、 $ClientId 変数は、アプリケーションのアプリケーション識別子またはクライアント識別子を保持し、 $ServiceId 変数は、サービスプリンシパルのオブジェクト識別子を保持し、 $TenantId 変数はテナント識別子を保持します。
$ServiceId = (Get-MgServicePrincipal -All | ? {$_.displayname -eq "POP3 and IMAP4 OAuth 2.0 Authorization"} | Select -ExpandProperty Id)
New-ServicePrincipal -AppId $ClientId -ServiceId $ServiceId -Organization $TenantId
サービス プリンシパルが Exchange Online に登録されると、管理者は メールボックスの追加アクセス許可 メールボックスへの通常の代理人アクセスの付与と同様に、サービス プリンシパルに受信アクセス許可を割り当てるコマンドレット。
Add-MailboxPermission -Identity "Kim.Akers@office365itpros.com" -User $ServiceId -AccessRights FullAccess
通過する際には、これはすべて私の側で理論的であることに注意してください。 新しいサービスプリンシパル コマンドレットは、アクセス権を持つテナントではまだ利用できません。いずれにせよ、理論は明確です:
- 登録済みのアプリを作成します。
- アプリに適切なアクセス許可を割り当てます。
- アプリのサービス プリンシパルを Exchange Online に認識させます。
- アプリのサービス プリンシパルを使用して、特定のメールボックスへの代理人アクセスを取得します。
アプリケーションへのアクセス
Exchange Online メールボックスにアクセスするために IMAP4 または POP3 を使用する必要はありませんが、必要なアクセス許可を含む OAuth 2.0 アクセス トークンを取得できることをテストしたかったのです。運用環境での使用では、アプリは認証に証明書を使う必要があります。テストするために、私はclを使用しましたient シークレットで、この PowerShell コードを実行しました。
$Uri = "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token"
$Body = @{
client_id = $ClientId
scope = "https://ps.outlook.com/.default"
client_secret = $AppSecret
grant_type = "client_credentials" }
# Get OAuth 2.0 Token
$TokenRequest = Invoke-WebRequest -Method Post -Uri $Uri -ContentType "application/x-www-form-urlencoded" -Body $Body -UseBasicParsing
# Unpack Access Token
$Token = ($tokenRequest.Content | ConvertFrom-Json).access_token
次に、アクセス トークンを確認し、期待されるアクセス許可が存在することがわかりました (図 2)。すべてが順調で、アプリにはメールボックスにアクセスする権限があります。
実用的だが間違った戦略
開発者はおそらく、Microsoftのアプローチはコードの変更が最小限に抑えられることを意味するため、歓迎するでしょう。彼らがする必要があるのは、基本認証を使用してメールボックスにサインインするコードを、アクセストークンを取得するコードに置き換えることだけです。その後、メールボックス内のメッセージにアクセスするための残りのアプリ コードが機能するはずです。
実際的なことですが、マイクロソフトのアプローチは短期的な戦術的な勝利だと思います。長期的な解決策は、Outlook Graph API に移行してメールボックスにアクセスすることです。これは、異なる権限を持つ同じ登録済みアプリのアプローチを使用しますが、より機能的です。いずれにせよ、アプリ開発者は遅かれ早かれグラフを受け入れる必要があります SMTP 経由で電子メールを送信するには.SMTP AUTH プロトコルは、電子メール接続の基本認証を削除しようとする Microsoft の取り組みに対する現在の例外ですが、その例外は永遠に続くわけではありません。
私は10月1日の日付が近すぎて、開発者にアプリケーションを再コーディングするように頼むには近すぎると思います。ただし、テナントに Exchange Online IMAP4 または POP3 メールボックス アクセスを利用するアプリがある場合は、これらの古いプロトコルをダンプし、将来のためのより良い基盤を構築することを検討してください。時間があれば…
このような洞察は簡単には得られません。テクノロジーを知り、舞台裏の見方を理解する必要があります。の知識と経験から利益を得る Office 365 for IT プロフェッショナル Office 365とより広いMicrosoft 365エコシステムをカバーする最高の電子書籍を購読することでチーム。