Configuring end points for Mobile Device Management

Any BMC Client Management agent can be configured to be a Mobile Device Manager. Each Mobile Device Manager has a dedicated HTTP endpoint, with default port number 1661. Depending on the underlying mobile devices platform, this endpoint may have different roles. For example, Apple devices directly connect to this HTTP endpoint once enrolled in order to get managed. On the opposite, Android devices never directly connect to BMC Client Management endpoints. They are managed via the Google servers. In both cases, the MDM dedicated endpoints can be used to enroll new mobile devices.

Because Mobile Device Managers have a dedicated HTTP endpoint, it must be possible to configure various aspects of that endpoint. The HTTP endpoint configuration includes the following elements:

The server name and port
The server SSL certificate
The list of SSL certificate authorities that shall be trusted, in order to trust the server SSL certificate above

The server name and port make it possible to deduce the MDM HTTP endpoint URL. For instance, if the server name is mdm.mycorp.com and the server port is the default 1661, then the endpoint URL will be deduced as https://mdm.mycorp.com:1661 and the enrollment URL will be deduced as https://mdm.mycorp.com:1661/mdm. The server SSL certificate is the certificate sent by the server to any client that connect and perform a TLS handshake. It is the client’s responsibility to trust (or not) the server certificate.

The MDM HTTP endpoints are the starting points for the enrollment of mobile devices. Authorized end-users can browse to one such endpoint and start the enrollment of Apple and Android devices. As such, they connect using a Web browser and answer a few questions to get their mobile device enrolled in BMC Client Management. The connection via their Web browser must be trusted, or a warning will be issued. The server SSL certificates drives this trust. If the certificate issuer is trusted by the Web browser, then there will be no warning. Otherwise, SSL certificate authorities may need to be deployed and installed for the server SSL certificate to be trusted.

For Apple devices, the MDM HTTP endpoints are critical because the management of Apple devices requires those devices to always connect to the MDM HTTP endpoint they have been enrolled to. In other words, if the iPhone device_1 was enrolled using the MDM HTTP endpoint https://mdm.mycorp.com:1661, then it will always connect back to this URL upon reception of a notification indicating that a management command is awaiting this device. Therefore, it is very important that the Apple mobile devices trust the MDM HTTP endpoint server SSL certificate. To get this possible, the enrollment process automatically installs a list of trusted certificate authorities, required to trust the server certificate. Note that this list of additional certificate authorities can be empty if the server certificate is already trusted by the Apple devices. If not, it is important to configure this list, which is referred as the list of SSL certificates authorities that shall be trusted, in the above bullet points.

Before BMC Client Management version 24.1, the following parameters had to be configured using the MobileDeviceManagement module configuration (MobileDeviceManagement.ini):

Configure the server name using the MobileDeviceManagement.ini file, [iOS] section, ServerName parameter.
Configure the server port using the MobileDeviceManagement.ini file, [iOS] section, ServerPort parameter.
Configure the server SSL certificate using the MobileDeviceManagement.ini file, [iOS] section, CertServer parameter.
Configuring the additional SSL certificate authorities was not easy tough. Certificates had to be installed in the main agent configuration.

It is still possible to configure the server parameters from the above parameters, except that the section name is renamed from [iOS] to [MobileDeviceManagement] to better reflect that the MDM endpoint is both used for Apple and Android devices. However, the above configuration approach is not user friendly as it requires to set configuration file parameters either through direct access or through operational rules. It is also cumbersome to configure multiple endpoints. Finally, managing SSL certificates this way is not ideal, and detecting the certificates that are about to or that have expired is not simple. For all these reasons, it had been decided to improve the MDM HTTP endpoints configuration using a centralized approach, directly in the user interface (Java console only).

To configure the end points for mobile device management

In the left pane select Mobile Device Management > Configuration > Server Configurations.
Right click Server Configurations and select Create Server Configuration.

Note
You can also create a server configuration using the console menu.
In the Properties dialog box, specify the following parameters.
1. Specify a Name for the new configuration for the Mobile Device Manager.
2. Specify a different Server Name for the Mobile Device Manager.
  The default port is 1661.
3. (Optional) Specify the notes for the new server end point configuration.
  
  Note
  A Mobile Device Management server configuration is a new BMC Client Management object type. Therefore, the name is simply the name of the object and has no impact on the server configuration itself. All the server configurations must have a unique name, as all the objects managed by BMC Client Management. The server name and server port are directly related to the server configuration and define respectively the name under which one or more MDM servers will be associated, and the TCP port number to which the clients will need to connect to. Standard attributes also exist for this object type, such as the administrator name and additional notes attached to this object instance. Note finally that a read only attribute defines whether the server configuration is currently activated. The reason why this flag exists is because it shall be possible to completely configure a server configuration before it can actually be used. Hence, administrators have the ability to create and configure server configurations, and to activate them only when they believe they are ready.
Click OK.
The Mobile Device Manager server configuration is defined and configured.

The system also displays the server configuration in the left navigation pane.

24_1 mobile device management left pane.png

After you select it, the system displays the general information is displayed in the General tab of the dialog box. The general information includes the data entered during the server configuration creation. It is now possible to continue the configuration. More specifically, it will be possible to register the SSL server certificate, and a list of SSL certificate authorities. Again, this list is not required if the server certificate is already trusted by the Web browsers (for the enrollment operation) and the Apple devices (for the enrollment and management operations).

24_1 mobile device management general tab.png

Note

The certificates tab is empty, by default.

24_1 mobile device management cert tab.png

To add a certificate for mobile device management

Right click on the Certificates tab and select Add Certificate.
In the Add Certificate pop-up box, specify the following parameters.
1. Specify a Certificate Type for the new certificate.
2. Specify a Certificate File for the new certificate.
3. Specify a Private Key File for the new certificate.
4. Specify a secret Password for the new certificate.
  
  Note
  Each server configuration must include one SSL server certificate and may include zero to many SSL certificate authorities. The server certificate is referred as End-Entity Certificate in the popup whereas certificate authorities are referred as Trusted Certificate Authority. When importing the server certificate, it is possible to select the certificate and private key files as separate entities. In this case, use the Certificate File … button to select the certificate file and use the Private Key File … button to select the certificate private key file. If the private key file is encrypted, use the Password field to enter the private key password. If the private key is not encrypted, the password field can be left empty. If the selected certificate and private key do not match, the import will fail. To configure the server certificate, it is also possible to select a PKCS12 or PFX file. In this case, both the certificate and private key are bundled in a single file, reason why it is not required to select a private key file. The Password field shall be used to enter the PKCS12/PFX file password.
  When configuring a certificate authority, no private key is required. In this case, simply select the certificate file to import using the Certificate File … button. Note that in all cases, certificates can be imported in text file format (PEM) or binary file format (DER).
  Before importing certificates, it is possible to visualize the content using the rightmost icon of the Certificate File row. If all the entered information is correct, the certificate content is displayed. Note that it is possible to import a certificates chain instead of a single certificate file. In this case, the display operation gives access to all the certificates in the chain:
Click OK.

The server configuration certificate is displayed.

After importing the certificates, the system displays the certificates in the Certificates tab. Each entry includes the certificates count, in case certificates chains are imported.
Right click a certificate row and select View Certificate. The system displays the certificate details.

Note

You can also view the certificate details using the console menu. Select a certificate row and click the button.

24_1 mobile device management cert menu option.png

Standard operations are available for the server configurations, including the ability to delete, cut, copy and paste server configurations. These same operations are available at the certificate level where administrators can delete, cut, copy and paste certificates. Note that when a server configuration is copied and then pasted, the associated certificates are also copied and pasted to the new server configuration. These operations make it possible to easily clone configurations for testing purpose.

Important

The above sections describe the interactions between the mobile device management HTTP endpoints and the clients. But it is important to understand that when the client is an Apple mobile device, then the server certificate must follow a set of rules defined by Apple. If these rules are not followed, then the enrollment and management operations may fail. To know more about the rules, see https://support.apple.com/en-us/103769. The SSL server certificate must:

Have a key size greater than or equal to 2048 bits.
Have been signed using a SHA-2 algorithm.
Have their server name included in the certificate Subject Alternative Name.
Contain the id-kp-serverAuth OID in the extended key usage.
Have a validity period less than or equal to 825 days.

Mobile device management server configurations can be associated to one or more Mobile Device Managers. In this case, they automatically acquire and apply the server configuration. Note that assigning the same configuration to multiple Mobile Device Managers is only relevant if these servers must share the same configuration (including the server name). This is for example the case when such servers are behind a load balancer. The server configuration assignment can be done by selecting and configuring the Mobile Device Manager.

24_1 mobile device manager configuration.png

In the above image above, one device has been selected as Mobile Device Manager. However, it is not assigned to any mobile device management server configuration. In this case, the Mobile Device Manager continues to configure the various elements using its MobileDeviceManagement.ini configuration files. A server configuration can be assigned or unassigned at any time, in which case the information is notified directly to the device so it can perform the required reconfiguration operations.

To assign a server configuration to the Mobile Device Manager using the context menu

Right click the relevant Mobile Device Manager row and select Assign Server Configuration.
In the Select the Server Configuration popup box, select the desired server configuration and click OK. The configuration is assigned, and the device is automatically notified.

Important

The operation above will likely lead to a configuration error on the Mobile Device Manager. The reason is because you have created and assigned a server configuration, while it is still inactive. As a consequence, the Mobile Device Manager cannot get its content and will proceed with a reconfiguration based on its MobileDeviceManagement.ini configuration file. You can see this in the Mobile Device Manager log file:

2023/12/12 15:58:20 Vision64Database W [19428] Inactive server configuration is assigned to device 1000

To rectify the error and activate the configuration using the context menu

Right click the relevant Mobile Device Manager row and select Activate Server Configuration.
Note
You can also activate the configuration using the console menu. Select a Mobile Device Manager row and click the button.

The server configuration activation now performs additional verifications. For example, the Apple requirements are verified.

24_1 server config verification.png

The system notifies the verification information to the Mobile Device Manager. Because the configuration is now active, the reconfiguration is done using its content. The Mobile Device Manager log file indicates this:

'2023/12/12 16:06:12 MobileDeviceManagement I [24232] We are assigned to server configuration 'MyCorp Test Configuration.'

You can also assign a Mobile Device Manager and a server configuration while adding a mobile device

In the left pane select Mobile Device Management > Mobile Device Manager.
Right click Mobile Device Manager and select Add Device.

The displays.
In the Add a new Mobile Device Manager pop-up box, select the relevant configuration or retain the default No Server Configuration entry otherwise.