Microsoft Azure is a cloud service provided by Microsoft. Microsoft Azure enables you to have virtualized computing platforms accessible through the internet. It is divided into a number of regulatory domains around the world, so that in countries with particular regulations regarding data, organizations can store and manage data in compliance with local laws.
TKU December 2019 enhances the model for Cloud Regions and Cloud Services to be segregated by account. If you discover more than one AWS Account, more than one Azure Subscription or more than one GCP Project, all the data from Cloud Region through to individual nodes within services will be clearly separated, where before it was intermingled.
As a result, the keys of all CloudRegion and CloudService nodes, and many contained nodes will change, even if you only discover a single account. If you synchronize to a CMDB, the identities of the corresponding CIs will also change.
The existing nodes are not deleted automatically with the application of the TKU. To remove the old nodes from the BMC Discovery model, you can delete the patterns that were deactivated by the new patterns in the TKU. However, the old CIs in the CMDB will not be deleted automatically. The simplest way to remove them is to perform a resynchronization.
This section describes the settings and procedures required to discover services running in Azure. It contains the following sections:
You access and configure all of your services in the Azure Public cloud using the Microsoft Azure portal and in the other clouds using the appropriate portals.
The following regulatory domains can be discovered with the latest product content update:
BMC Discovery enables you to discover your cloud services running in Microsoft Azure. The following set of Microsoft Azure services can be discovered with the latest product content update:
More detailed information on discovery of Microsoft Azure services is contained in the following Configipedia pages:
BMC Discovery enables you to discover your cloud services running in these regions. To do so, you must provide application ID and authentication key (credential) with which BMC Discovery can access the cloud, you create the access key using the Microsoft Azure portal or the the Microsoft Azure Germany portal.
Creating a credential is a two stage process, in the Microsoft Azure Portal you obtain a Directory ID, Application ID, and authentication key. Then in BMC Discovery, you use this information to add the cloud discovery credential. These two steps are mandatory for setting the Microsoft Azure discovery.
The procedure is outlined here, though the steps to do this are described fully on this Microsoft Azure web page.
Application Key–Create the Application Key (press +New client secret) in the Certificates & secrets for the application in Azure Active Directory > App registrations in the Microsoft Azure Portal. You can only copy the key when you first create it, so keep it safe.
If you lose the Application Key, you cannot retrieve it from the Microsoft Azure Portal. You must create a new application key and use the new key in the BMC Discovery cloud credential. You should keep a note of the application key until you have successfully tested the cloud credential.
Reader role is sufficient to discover everything except size and encryption (D@RE) values for VHDs used by VMs. To discover size and encryption (D@RE) values for VHDs used by VMs, you need the
Microsoft.Storage/storageAccounts/listKeys/action permission. If you only need to discover Managed Disks, the built-in
Reader role is sufficient.
Grant the application permissions (roles) to your subscriptions.
BMC Discovery will not be able to discover resources in the target subscriptions without permissions granted to your application.
When the main configuration is done, you can set the optional settings.
If you need to discover Microsoft Azure storage, you also need to grant the
Microsoft.Storage/storageAccounts/listKeys/action role for full discovery of Azure Storage. You do not need this permission if you are only using managed disks. A JSON file is provided in the BMC Discovery UI which is used with the Microsoft Azure command line tools to create a Discovery role which gives the correct permissions. Custom roles are described in the Microsoft Azure documentation.
Run the following command, depending on your Azure cli version:
az role definition create --role-definition <PATH>azure_discovery_role.json
az role create --config <PATH>azure_discovery_role.json
Assign recently created custom 'Discovery' role to the application registration which you used for BMC Discovery. (Step 1).
Create the Azure cloud credential in the same way as any other credential. The Azure cloud credential uses the Directory ID, Application ID, and Application Key as the equivalent of a username and password combination.
CyberArk–If the CyberArk integration is enabled, do not enter a key ID and secret, rather enter a CyberArk search string in this field to extract a CyberArk credential. An example search string is:
See Integrating with CyberArk Enterprise Password Vault for more information on the integration.
The Directory ID and Application ID are both GUIDs, 32 hex digits grouped 8-4-4-4-12. They are easy to transpose, and if you do so, your credential will never work, and the problem will be difficult to diagnose.
Once you have created the credential, you should test it to ensure that it works.
From the credentials page, click Devices.
If the credential test was unsuccessful, ensure that you copied the Directory ID and Application ID correctly.
The BMC Discovery appliance must be able to access Microsoft Azure using https (port 443).
To perform cloud discovery, from the Discovery Status page, use the Add New run control.
Perform a normal scan on the hosts running the VMs discovered in the cloud scan. Use the Unscanned Cloud Hosts report on the Cloud Overview dashboard to find these.
Scanning the hosts assumes that the appliance or proxy has network access to hosts running in the cloud, for example, using a VPN.
Public IP addresses do not respond to ICMP pings. You must disable "Ping before scanning", otherwise all scans are dropped reporting no response.
Once you have scanned, you can examine the results. The screen below shows a discovered VM running in Microsoft Azure.
Microsoft Azure supports Microsoft SQL Server. The Microsoft Azure API reports the database. If you only need to discover the database, these are reported as part of normal cloud discovery, and no further configuration is required.
If you need deeper database discovery, for example, you need to report the tables, or run queries for application specific data, you need to configure database discovery using integration points.
Each database server has a firewall, and you can add a rule stating which IP addresses are permitted access.To do this:
You can also configure rules on a firewall on the database, in addition to the firewall on the server, configured earlier. The server firewall and the database firewall must both permit access to BMC Discovery.
When you configure your database credential, you must specify a username and some additional JDBC parameters.
The username is of a particular form. For example:
The JDBC username is
Each server requires a different username. Consequently, each server requires a different credential for that username. In large deployments on Microsoft Azure, with many servers, you must create many database credentials. During discovery, each database credential is checked in turn, meaning a potential performance reduction, and administrative overhead in creating the database credentials.
The JDBC connection string, given in the Azure Portal, in the Database connection strings page for that database, is as follows. The italicized section shows the JDBC parameters:
JDBC (SQL authentication)
The following additional JDBC parameters must be specified in the BMC Discovery database credential:
The Microsoft Azure discovery patterns are available on the Manage > Knowledge page. They are located in the Pattern modules list, under Cloud > Microsoft Azure.
Information about tags is described here
Problem: Tenant ID is not found.
Solution: Check Directory ID in Azure Active Directory > Properties.
Problem: Application with the identifier is not found (ID is correct, but application ID is wrong or does not exist).
Solution: Check Application id or register the new one.
Problem: Invalid client secret provided (application in Azure portal is created, application key in the ADDM credentials is not set, or key is expired).
Solution: Check the security key, or add the new one.
Problem: Failed to get dynamic parameter 'subsribtionid: No values' (Directory ID, Application ID, and Security key are correct. No role is assigned to the application in Azure portal).
Solution: Assign role in More services > Subscriptions, then select Access Control (IAM) - Role Assignments.
Problem: Failed to get dynamic parameter subscriptionId: 'some request name': Authentication failure: AADSTS7000222: The provided client secret keys are expired.
Description: Keys encryption bug.
Solution: Please check if your keys contain / and + characters. Try to generate new key using manual above. Keys that will work 100% are keys exclusively with alphanumeric characters.