Azure Cloud Discovery URLs

[Joshua Comeau]

What URLs are required to be accessible by the Mid Server Network for Azure Cloud Discovery to work

[Slava Savitsky]

I am not sure what URLs you are referring to. There is Service account-based discovery and IP-based discovery? Which one are you trying to use?

Have a look at the following product documentation articles:

Exploring Cloud Discovery

Azure Cloud Discovery

[Joshua Comeau · Accepted solution]

Hope this helps users on configuring Azure Cloud Discovery:

Please make sure the internal network connection is enabled between the MID Servers and the Azure Cloud API endpoints. Can you please check if you are able to access the URLs from the MID server through Postman: (You may need to make sure traffic is not blocked by proxy)
https://management.azure.com/subscriptions?api-version=2016-09-01
https://management.azure.com/providers/Microsoft.Management/managementGroups?api-version=2018-03-01-...

-How to execute AWS & Azure REST APIs using Postman from MID server
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0713124

Please Whitelist the urls which are necessary for executing the cloud discovery.
Ensure that the MID server(s) used for Azure Cloud Resource Discovery have access to the following URLs:
*.windows.net
*.azure.com
*.azure.net
*.microsoftonline.com

Please whitelist the resources which are most essential for your organization
Here is the link for Azure resources.
Also, you can whitelist only those resources that discovery is capable of discovering via cloud discovery.
https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-services-resource-pro...

Please double check all the above with your network and azure team and add if they are missing anything and run discovery and check the results.



For the certificates -

Since this is Azure discovery, and we're trying to connect to Azure - specifically in this case via this URL - https://management.azure.com/subscriptions?api-version=2016-09-01 - it will try and go to a trusted Microsoft/Azure check authority from their certificate - this one http://oneocsp.microsoft.com/ocsp - it won't be in our documentation as it's an Azure OCSP check and not a ServiceNow one.

I've had a look into their documentation - linked below for reference, and they advise if you have an environment where firewall rules are set to allow outbound calls to only specific Certificate Revocation List (CRL) download and/or Online Certificate Status Protocol (OCSP) verification locations, you'll need to allow the following CRL and OCSP URLs. For a complete list of CRL and OCSP URLs used in Azure, see the Azure CA details article.

http://crl3.digicert.com
http://crl4.digicert.com
http://ocsp.digicert.com
http://crl.microsoft.com
http://oneocsp.microsoft.com
http://ocsp.msocsp.com

https://learn.microsoft.com/en-us/azure/security/fundamentals/tls-certificate-changes

In summary, allowing access from the MID host to the OCSP Authority - http://oneocsp.microsoft.com - should allow for the check to complete, which in turn will allow the connection to the Azure Endpoint - please arrange with your network teams to allow this access and we'll review once the access is provided.


To identify and check the certificates are required :

- So the MID server was trying to make a REST call to https://management.azure.com/subscriptions?api-version=2016-09-01 but if there was an issue with SSL certificate verification. The issue should be related to network connection or SSL certificate.

- check if there is a network path between the MID Server and the target endpoint

- Does the connection need to go through proxy (with certificate) to reach the endpoint

- Use 3rd-party tools like OpenSSL and wireshark to help identify what SSL certificates are involved in the network connection.