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: ; max-width: ; width: ; height: ; } } 概要 インスタンスは、 OAuth 2.0 認証をサポートするプロバイダーの場合、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 メールボックスを排他的に使用することを前提としています。インスタンスは読み込み後にサーバーからメールを削除します。したがって、異なるサービスやユーザー間で共有されるメールボックスを使用することはお勧めしません。各サービスまたはユーザーは、インスタンスのメール操作に干渉します。 開始する前に メール - IMAP と SMTP の OAUTH サポート プラグインをインストールします。 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.Send」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レコードの [デバッグ出力を有効にする] オプションをオンにします。これにより、インスタンスとメールサーバー間のすべての通信がノードログに出力されます。すべてのノードまたは選択したノードから localhost ログをダウンロードする方法 に従って、ノードログをダウンロードしてください。関連する行には、DEBUG: SMTP や DEBUG: IMAP などが含まれます 2022-09-20 00:20:37 (002) worker.3 worker.3 txid=3359b621874e DEBUG: SMTP: enable SASL2022-09-20 00:29:27 (018) worker.6 worker.6 txid=c96bfae9878e DEBUG: IMAP: AUTH: PLAIN この情報は、接続が失敗しているステージを特定するのに役立つ可能性があるため、必要に応じてメールアドミニストレーターおよび Azure アドミニストレーターと共有してください。トラブルシューティング後は、特に本番インスタンスでは、これらのオプションは、メールコンテンツを含むすべてのメールトラフィックを出力してノードログに出力するため、忘れずにデバッグをオフにしてください。これにより、ノードログが数ギガバイト後に切り捨てられ、ノードログが他の問題のトラブルシューティングに役に立たなくなる可能性があります。 既知のエラー エラー:アクティブなメールアカウントの OAuth リフレッシュトークンがありません。手動による再認証が必要です。アカウント="" 「 メールアカウントアクセスの許可 をクリックしてアクセス権とリフレッシュトークンを取得します。」ステップでシークレット/プライベートウィンドウ とローカルログイン (必要に応じて 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レコードの 1 つがアクティブ = False に設定されている場合、アクセストークンは 「メールアクセストークンのリフレッシュ」 スケジュール済みジョブによって自動的に更新されません。これは 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（[My IP Information] カタログアイテムで確認できる、お客様のネットワークへの接続に使用する 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"