OAuth2 を使用して Microsoft Office365 で SMTP および IMAP メールアカウントを構成する方法<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: ; width: auto; height: auto; } } 概要 インスタンスは、 OAuth 2.0 認証 サポートするプロバイダー向け) を使用してメールアカウントに接続するように構成できます。 この記事では、Microsoft Office365 アカウントで使用するための OAuth プロバイダーの設定に焦点を当てます。構成が完了すると、OAuth2 認証権限許可タイプを使用して、Microsoft Azure OAuth サーバーからアクセス権を取得し、トークンを更新できるようになります。 この記事には Microsoft 製品構成画面のスクリーンショットの例が含まれていますが、ServiceNow は Microsoft 製品のサポートを提供していません。Office365 または Exchange の構成と管理に関する質問は、メールアドミニストレーターに直接お問い合わせください。スクリーンショットはテスト用の Azure システムに属しており、テスト中に ServiceNow で機能した一連の構成を示しています。構成や画面が異なる場合があります。ServiceNow はお客様を支援するよう努めていますが、インスタンスからのログの収集に関する支援のみを提供できます。 メール管理者および Azure/Office365 管理者と協力して、Azure および Office 365 テナントを構成する必要があります。 Microsoftは、ここでOAuthのサポートを発表し、文書化しています。 MicrosoftのIMAPおよびSMTPサービスでのOAuth 2.0のサポートのMicrosoft 公式ドキュメント OAuth 2.0 で SMTP/IMAP を構成するため 排他的メールボックスアクセスServiceNow インスタンスは、IMAP メールボックスを排他的に使用することを前提としています。インスタンスは、読み込み後にサーバーからメールを削除します。したがって、異なるサービスやユーザー間で共有されるメールボックスを使用することはお勧めしません。各サービスまたはユーザーは、インスタンスのメール操作を妨害します。 開始する前に Email - IMAP and SMTP プラグインをインストールします。 1.Microsoft Azure Active Directory へのアプリケーションの登録 の記事を使用して、Azure Active Directory にアプリケーションを登録します。Azure アプリケーションで以下を設定してください。 ServiceNow OAuth リダイレクト URL を構成 トークンを要求するときに ID を証明するために、アプリケーションのクライアントシークレットを作成します。 SMTP/IMAP および offline_access 用の Azure アプリケーションで OAuth スコープを構成します ( ドキュメントに従ってリフレッシュトークンを取得するため)。Azure では、適切に機能するために User.Read スコープを使用することを推奨しているため、これは削除しないでください。最終的な API 権限を以下に示します。 2.ServiceNow for Microsoft での OAuth の構成 Microsoft の OAuth2 認証権限許可フローを使用して oauth_entity レコードを構成します。この記事のすべての URL は Azure テナントに固有であり、テナントの URL は異なる場合があることに注意してください。Azure アドミニストレーターから正しい URL を取得してください。 1.Microsoft OAuth エンドポイントを次のように構成します 認証 URL:https://login.microsoftonline.com/[Azure テナント ID]/oauth2/v2.0/authorizeトークン URL:https://login.microsoftonline.com/[Azure テナント ID]/oauth2/v2.0/tokenリダイレクト URL:{Instance_URL}/oauth_redirect.do 2.OAuth エンティティスコープ: a.名前: "IMAP.AccessAsUser.All"OAuth スコープ:「https://outlook.office.com/IMAP.AccessAsUser.All」 b. 名前: "SMTP.送信」OAuth スコープ:「https://outlook.office.com/SMTP.Send」 c.名前:「offline_access」OAuth スコープ:「offline_access」 3.ステップ #2 で作成したすべてのスコープで「OAuth エンティティプロファイルスコープ」を構成します。 4.oauth_entity_profileレコードとoauth_entityレコードの両方に同じスコープがあることを確認します 5.OAuth 2.0 認証を使用して SMTP/IMAP メールアカウントを作成し、メールアカウントの OAuth プロファイル フィールドで上記の OAuth エンティティプロファイルを参照します。ドキュメントを参照してください: メールの OAuth 2.0 を有効にします。 非常に重要:次の手順でユーザー名とパスワードの入力を求められない場合、アカウントはメールを送信できません。次の手順のために、シークレットウィンドウでローカル管理者アカウントとしてログインしていることを確認してください。 説明:それ以外の場合、SMTP または IMAP アカウントは個人の AD アカウントで承認され、インスタンスでメールを送受信することはできません。 6.「メールアカウントアクセスの承認」 アクションを使用して、アクセス権を取得し、トークンを更新します。シークレット/プライベート ウィンドウ とローカル ログイン (必要に応じて side_door.do) を使用して、個人アカウントが Microsoft SSO ログインによって取得されないようにする必要があります。自分の認証情報ではなく、メールアカウントのユーザー名/認証情報を入力する必要があります。Azure に既にログインしているときに承認しようとすると、ポップアップ ウィンドウが表示されず、承認が成功したように見える場合があります。ただし、インスタンスは、メールアカウントではなく、ユーザー自身の認証情報のアクセストークンを受信します。この場合、インスタンスがユーザーのアカウントを使用してメールボックスにアクセスし、失敗するため、接続をテストするとエラーが発生します。 注:KB2071947にあるスクリプト - バックグラウンドを使用して、JWT (アクセストークン) を検証し、メールアカウントアクセスが適切に承認されているかどうかを確認できます。 (注:インスタンスには、問題のメールボックスへの接続に使用する有効/アクティブな Oauth トークン (IMAP または SMTP) が必要です。これにより、接続が確立されたら、問題のメールボックスにメールデータをプッシュできます。お持ちでない場合は、メールアカウントレコードで使用されている Oauth プロファイルに移動すると、[OAuth トークンを取得] へのリンクが表示されます。クリックして新しいトークンを取得します。 ) トークンのリフレッシュ システム管理者ユーザーに「admin」ロールがあることを確認します。OAuth 2.0 の実装では、サードパーティのメールアカウントごとに、メールプロバイダーからアクセス権とリフレッシュトークンを取得する必要があります。トークンは自動的にインスタンス データベースに保存されます。https://<instance>.service-now.com/nav_to.do?uri=sysauto_script.do?sys_id=35faf162eb233100469a20425206fedc のスケジュール済みジョブは、メールアクセストークンが有効かどうかを定期的にチェックします。アクセストークンが有効でなくても、リフレッシュトークンが有効な場合、インスタンスは自動的に新しいアクセストークンを再生成します。 スケジュール済みジョブは、システムアドミニストレーターとして実行するように構成されています admin ロールが必要です。このロールがないと、トークンをoauth_credentialテーブルに格納するときにトークンの更新操作が失敗します。アクセストークンの有効期限が切れると、メールアカウントへのアクセスは失敗します。 参照: OAuth を使用した IMAP、POP、または SMTP 接続の認証 追加のログ記録 インスタンスがメールボックスに接続できない場合は、sys_email_accountレコードの [デバッグ出力を有効にする] オプションをオンにしてください。これにより、インスタンスとメールサーバー間の通信がすべてノードログに出力されます。ノードログをダウンロードするには、 すべてのノードまたは選択したノードからローカルホストログをダウンロードする方法 に従ってください。関連する行には、次のような DEBUG: SMTP または DEBUG: IMAP が含まれます。 2022-09-20 00:20:37 (002) worker.3 worker.3 txid = 3359b621874e デバッグ:SMTP:SASL を有効にする2022-09-20 00:29:27 (018) worker.6 worker.6 txid = c96bfae9878e デバッグ:IMAP:認証:プレーン 接続が失敗しているステージを特定するのに役立つ可能性があるため、必要に応じてこの情報をメールアドミニストレーターおよび Azure アドミニストレーターと共有してください。トラブルシューティング後、特に本番インスタンスでは、これらのオプションがノードログに出力されるメールコンテンツを含むすべてのメールトラフィックを出力するため、デバッグをオフにすることを忘れないでください。これにより、ノードログが数ギガバイト後に切り捨てられる可能性があり、ノードログは他の問題のトラブルシューティングに役に立たなくなります。 既知のエラー エラー:アクティブなメールアカウントに OAuth リフレッシュトークンがありません。手動による再認証が必要です。account="" ステップ「 メールアカウントアクセスの承認をクリックして、アクセス権を取得し、トークンを更新します。シークレット/プライベートウィンドウ とローカルログイン (必要に応じて side_door.do) を使用します。自分の認証情報ではなく、メールアカウントのユーザー名/認証情報を入力する必要があります。 エラー:invalid_request、AADSTS90002:テナント「xxxxxx-xxxxx-xxxxx」が見つかりません。正しいテナント ID があり、正しいクラウドにサインインしていることを確認してください。これは、テナントにアクティブなサブスクリプションがない場合に発生する可能性があるため、サブスクリプションアドミニストレーターに確認してください。 認証 URL とトークン URL の Azure テナント ID が Azure ポータルのテナント ID と一致していることを確認します。 エラー:接続に失敗しました。メール送信者接続が無効です。:SMTP サーバーに接続できません:smtp.office365.com、理由:<[ユーザー名] フィールドで構成された M365 メール>、メッセージ: 接続に失敗しました。 登録済みの Azure アプリに割り当てられた API アクセス許可スコープは、Microsoft Graph リソース用です。メールボックスには、Graph API にアクセスできないライセンス (Exchange Online(プラン 1) など) が割り当てられている場合があります。Office 365 E5 などのサポートされているライセンスに切り替えると、問題が解決するはずです。 エラー:メールアクセストークンが更新されていません sys_email_accountにリンクされているoauth_entityレコードのいずれかがアクティブ = False に設定されている場合、[メールアクセストークンをリフレッシュ (Refresh Email Access Token)] スケジュール済みジョブによってアクセストークンは自動的に更新されません。これは PRB1588339 を介して追跡される既知の問題であり、修正プログラムは Utah パッチ 1 で利用できます。 エラー:java.io.ExpiringCache.cleanup によって発生したノードのジョブがキューに格納されたため、IMAP メールが処理されませんでした これは PRB1635023 で追跡される既知の問題であり、修正プログラムは Vancouver で入手できます。 メールエラーを受信しました:OAuth トークンが存在しないか、パスワードリセット後に有効期限が切れました エラー:アカウントが接続されているように見えても、メールは送信されなくなりました IMAP アカウントでパスワードが変更されている場合は、トークンを再プルする必要があります。KB1295058を参照してください。 エラー:接続に失敗しました。メール送信者接続が無効です。:SMTPサーバーに接続できません:outlook.office365.com、xxxxxxxxxメッセージ:SMTP host:outlook.office365.comから悪い挨拶を受け取りました、ポート:993、応答:*OK Microsoft Exchange IMAP4サービスの準備ができました。 ポート 993 は Microsoft IMAP サーバー用です。Microsoft SMTP サーバーに使用する正しいポートは 587 です。 その他の考慮事項: インスタンス IP ([自分の IP] 情報カタログアイテムで顧客のネットワークに接続するためのもの) を、office365.com を介してメールを送信するための信頼できる IP としてホワイトリストに登録できるかどうか、メールアドミニストレーターと話し合うのが賢明かもしれません。 その他のサポートドキュメントには、次のものが含まれます。 Microsoft Graph アプリケーションのアクセス許可ベースのアクセス:"https://docs.wpo365.com/article/166-send-email-using-microsoft-graph-with-application-level-permissions" Graph API セットアップに関する ServiceNow 開発者ブログ:"https://www.servicenow.com/community/developer-blog/reading-email-using-microsoft-graph-api/ba-p/3084506" アプリケーション アクセス ポリシーを使用して特定の共有メールボックスへの Graph API アクセスを制限することに関する Microsoft のガイダンス:"https://learn.microsoft.com/en-us/answers/questions/2149155/permissions-to-access-shared-mailbox-to-read-and-s" OAuth と Graph API を使用したグラフベースのメール読み取りに関する ServiceNow のドキュメント:"https://www.servicenow.com/docs/bundle/yokohama-platform-administration/page/administer/notification/concept/read-email-using-ms-graph.html?state=seamless"