-
Suggestion
-
Resolution: Fixed
-
16
-
Hi everyone,
This is Alex from the Jira Service Management Data Center & Server team.
As of JSM DC version 4.22 this is now possible with the support of multiple incoming emails.
You can now configure as many dedicated email channels as required, using a custom URL specific for Microsoft GCC accounts, for better communication with customers.
For detailed instructions on how to configure a GCC account using a JSM incoming mail handler, please refer to the KB article Guide explaining how to configure a GCC account with a Jira or a Service Management mail handler using Oauth 2.0.
You can learn more about email channels here, and creating custom links using OAth 2.0 Configuration here.
Kind regards,
Alex
Jira Service Management, Data Center & Server
Issue Summary
Since Jira Service Desk 4.12, support to connect mail channels to Office 365 accounts using OAuth 2.0 has been introduced. However, it doesn't support GCC (Government Community Cloud) accounts.
It isn't supported because regular Office 365 accounts connect to outlook.office365.com whilst GCC accounts connect to outlook.office365.us.
Therefore, the connection is not established and the mail channel can't be connected using OAuth 2.0
Workaround
Manually update the hosts file of the operating system to point to the US domain. However, doing this will remove the automatic failover to a new IP address in case of outages in the primary IP address.
Example:
40.66.16.130 outlook.office365.com
- is related to
-
- Gathering Interest
- is resolved by
-
- Closed
- relates to
-
JSDSERVER-11219 'Other' option for Email service provider missing when creating new email channel
-
- Closed
-
-
- Closed
- was cloned as
-
- Gathering Interest
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JSDSERVER-6998] Office 365 using OAuth 2.0 doesn't support GCC customers
| Remote Link | Original: This issue links to "Page (Atlassian Documentation)" [ 606807 ] |
| Link | New: This issue is related to JSDSERVER-14090 [ JSDSERVER-14090 ] |
| Remote Link | New: This issue links to "Page (Confluence)" [ 704711 ] |
| Link |
New:
This issue relates to |
Thanks Julien, that was it. The app link that I was using with Jira Software (which I was trying to reuse) was pointing to the "Microsoft" service provider vs. "Custom." Recreated the app link and then the Auth method showed the new app link as an option. So selected that and was good to go. One thing I couldn't get to work was Secure POP. As with Jira Software I can only get Secure IMAP to work. Have you seen Oauth work with Secure POP and GCC-High?
Can you check the instructions from the the KB article Guide explaining how to configure a GCC account with a Jira or a Service Management mail handler using Oauth 2.0 and let us know if it helps?
To configure a JSM mail handler (=mail channel) with a GCC account, you will need to:
- configure an Oauth 2.0 integration in âš™ > Applications > Application Links using Custom in the Service Provider field (make sure not to use Microsoft)
- configure a new mail channel in Project Settings > Email Requests using Other in the Email Service Provider field (make sure not to use Microsoft)
| Description |
Original:
{panel:title=Atlassian Update – 07 March 2022|borderStyle=solid|borderColor=#ebf2f9 | titleBGColor=#ebf2f9 | bgColor=#ebf2f9}
Hi everyone, This is Alex from the Jira Service Management Data Center & Server team. As of [JSM DC version 4.22|https://confluence.atlassian.com/servicemanagement/jira-service-management-4-22-x-release-notes-1114802916.html#JiraServiceManagement4.22.xreleasenotes-requests] this is now possible with the support of multiple incoming emails. You can now configure as many dedicated email channels as required, using a custom URL specific for Microsoft GCC accounts, for better communication with customers. You can [learn more about email channels here|https://confluence.atlassian.com/servicemanagementserver/receiving-requests-by-email-939926303.html], and creating [custom links using OAth 2.0 Configuration here.|https://confluence.atlassian.com/adminjiraserver/link-to-other-applications-938846918.html] Kind regards, Alex Jira Service Management, Data Center & Server {panel} h3. Issue Summary Since Jira Service Desk 4.12, support to connect mail channels to Office 365 accounts using OAuth 2.0 has been introduced. However, it doesn't support GCC (Government Community Cloud) accounts. It isn't supported because regular Office 365 accounts connect to {{outlook.office365.com}} whilst GCC accounts connect to {{outlook.office365.us}}. Therefore, the connection is not established and the mail channel can't be connected using OAuth 2.0 h3. Workaround Manually update the hosts file of the operating system to point to the US domain. However, doing this will remove the automatic failover to a new IP address in case of outages in the primary IP address. Example: {code} 40.66.16.130 outlook.office365.com {code} |
New:
{panel:title=Atlassian Update – 07 March 2022|borderStyle=solid|borderColor=#ebf2f9|titleBGColor=#ebf2f9|bgColor=#ebf2f9}
Hi everyone, This is Alex from the Jira Service Management Data Center & Server team. As of [JSM DC version 4.22|https://confluence.atlassian.com/servicemanagement/jira-service-management-4-22-x-release-notes-1114802916.html#JiraServiceManagement4.22.xreleasenotes-requests] this is now possible with the support of multiple incoming emails. You can now configure as many dedicated email channels as required, using a custom URL specific for Microsoft GCC accounts, for better communication with customers. For detailed instructions on how to configure a GCC account using a JSM incoming mail handler, please refer to the KB article [Guide explaining how to configure a GCC account with a Jira or a Service Management mail handler using Oauth 2.0|https://confluence.atlassian.com/display/JIRAKB/Guide+explaining+how+to+configure+a+GCC+account+with+a+Jira+or+a+Service+Management+mail+handler+using+Oauth+2.0]. You can [learn more about email channels here|https://confluence.atlassian.com/servicemanagementserver/receiving-requests-by-email-939926303.html], and creating [custom links using OAth 2.0 Configuration here.|https://confluence.atlassian.com/adminjiraserver/link-to-other-applications-938846918.html] Kind regards, Alex Jira Service Management, Data Center & Server {panel} h3. Issue Summary Since Jira Service Desk 4.12, support to connect mail channels to Office 365 accounts using OAuth 2.0 has been introduced. However, it doesn't support GCC (Government Community Cloud) accounts. It isn't supported because regular Office 365 accounts connect to {{outlook.office365.com}} whilst GCC accounts connect to {{{}outlook.office365.us{}}}. Therefore, the connection is not established and the mail channel can't be connected using OAuth 2.0 h3. Workaround Manually update the hosts file of the operating system to point to the US domain. However, doing this will remove the automatic failover to a new IP address in case of outages in the primary IP address. Example: {code:java} 40.66.16.130 outlook.office365.com {code} |
Hi Alex,
When I select the built-in Microsoft handler and point my auth method to my Application Link (which I use in Jira Software for OAuth and it works), I'm seeing in the outgoing logs that it's trying to connect to the commercial .com endpoint (see comment above). When I switch the handler to Other (custom) and don't have the capability to point to my Application Link (thus can't reach my OAuth endpoints). So I'm not sure how this is supposed to work.
Hey Derek,
The custom handler doesn't allow you to select Authentication Method (e.g. the Application Link). I would think I would need both (server and auth method).
Hi it1752103726
Great to hear that you got it to work with IMAP, that's great news
As for POP, unfortunately, at Atlassian, we don't have access to GCC accounts, so we cannot perform any test with this type of accounts. Theoretically, it should be possible to configure GCC accounts with Oauth 2.0 and with both IMAP and POP, but we cannot confirm with high confidence as we do not have a way to test these scenarios.
If you are getting the error mentioned below while configuring GCC with POP+Oauth 2.0, then you might be impacted by Root Cause 10 of the KB article https://confluence.atlassian.com/jirakb/jira-mail-handler-or-service-management-mail-handler-cannot-be-configured-using-oauth-2-0-the-authorization-or-connection-test-fails-1095250181.html:
If the error does not match and you need more assistance with this configuration, then I would recommend raising a support ticket via our support portal, so that the support team can assist you further.