Share via

Security Best Practices in MDM

  • Article

2/9/2009

The following describes some security best practices for your System Center Mobile Device Manager infrastructure.

  • Only use object identifiers for certificate templates from the same MDM instance
    MDM 2008 SP1 supports multiple instances in one domain or across a forest, which provides flexibility and increased manageability for companies that deploy MDM in an enterprise-wide topology.

    Adding authorized certificate template object identifiers from another MDM instance could compromise the security boundaries of an MDM instance.

  • Users should not be administrators of more than one MDM instance
    To better separate roles, we recommend that you do not make the same users administrators of more than one MDM instance.

  • Require strong enrollment passwords
    The enrollment process uses an enrollment password to grant access to managed devices and establish their identity on the company network. A strong enrollment password helps keep the company network environment more secure. A strong password makes it more difficult for an attacker to impersonate a device and then join the domain. This could result in compromised company data.

    Note

    To help keep the company environment more secure, we recommend that you require strong passwords, even if users can only access the server on an internal network. An example would be to require a strong password by authorized IT personnel who perform device enrollment for the user. Then, the IT person can give the fully enrolled device to the user.

    The longer the enrollment validity period, the longer the password length should be. We recommend that you require a 10-character minimum password for a 24-hour enrollment period. If the enrollment period is longer than 24 hours, the password should be longer to maintain the same effective strength.

    You should use the default alphanumeric character set configuration unless there is a compelling business reason to use numeric-only enrollment passwords.

  • Prevent unsigned code from running
    To help protect the device against spoofing and privilege elevation, you should prevent untrusted or unknown code from executing on Windows Mobile 6.1. To do this, you must restrict application execution by configuring the Application Disable policies, or other security policies, to allow only applications signed by trusted authorities to run.

    You can use the following Group Policy settings to prevent unsigned code from running. These policies are under Computer Configuration\Administrative Templates\Windows Mobile Setting\Application Disable:

    • Allow specified unsigned applications to run as privileged
    • Allow specified unsigned applications to run as Normal

    The following shows other Group Policy settings that you can use to block unsigned code from running:

    • Block unsigned .cab file installation
    • Block unsigned theme installation
    • Block unsigned applications from running on a device
    • Turn off user prompts on unsigned files

    For MDM software distribution, you should assign the correct permission model for running an application. Configure applications to run in normal mode whenever possible. Applications that run as normal cannot call trusted APIs or write to protected areas of the registry. System files are read only.

    Configure applications to run as privileged only when they must have the highest permissions. Applications that run as privileged can call any API, write to protected areas of the registry, and have full access to system files. Few applications, if any, need to run in privileged mode. Privileged applications can threaten the integrity of the device by changing the operating system environment.

    For information about the Windows Mobile 6.1 security model, see this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkID=119251.

    For more information about the Group Policy settings, see Security Policies in MDM.

  • Allow only trusted users to access IIS settings
    The security of MDM depends on the correct configuration of Internet Information Services (IIS). After you install MDM, you should not configure the IIS metabase or change IIS settings that are related to MDM.

    We strongly recommend that you do not manually adjust IIS settings in MDM, unless instructed otherwise. Do not change the IIS configuration for the following Web sites:

    MDM Enrollment Server

    • EnrollmentAdmin
    • Enrollment

    MDM Device Management Server

    • MobileDeviceManagerAdmin
    • MobileDeviceManager

    MDM Gateway Server

    • Gateway Management Web site
  • Do not modify Web configuration files
    All MDM Web services have a Web.config file. You should not modify Web configuration files. Changes to the Web.config files may adversely affect MDM performance, or lead to failures within the system.
  • Run Setup files from a protected location
    Run Setup (.msi) files and Active Directory configuration files only from a protected location. It is important to run Setup from a protected location and not from a network share.

  • Implement firewall rules for MDM Gateway Server and MDM DM Server
    Communication always initiates from MDM Device Management Server to MDM Gateway Server. Configure your firewall accordingly.

    For information about configuring your firewall, see the MDM Firewall Settings Worksheet in the MDM Planning Guide.

  • Do not block applications that are needed for basic device functionality
    Only block applications that you know you want to block.

    Be careful not to block applications that are needed for basic device functionality, such as the ability to make a telephone call or an emergency telephone call.

  • Do not block the file extensions used by MDM
    MDM servers and services use files that have .asmx and .ashx extensions for basic functionality. Do not block the following file extensions on the respective servers:

    • MDM Enrollment Server – The enrollment service and the enrollment administration service use .asmx files.
    • MDM Device Management Server – The device management service uses .ashx files, while the device management administration service uses .asmx files.
    • MDM Gateway Server – The Alerter agent and VPN agent use .ashx files.

  • Set root certification authorities expiration time in such a way that renewal is not needed
    You cannot renew the root certification authority in Windows Mobile.

    We recommend that you follow the best practices for PKI as outlined in the PKI documentation:

  • Set device certificate expiration time long enough to allow for automatic renewal
    A managed Windows Mobile device automatically renews the device certificate as long as the device can connect to the issuing certification authority through Mobile VPN. If the device is offline when the certificate expires, the device will need to be wiped and enrolled into MDM again.

    We recommend that you do not change the certificate expiration default value, or that you set it to at least five times longer than the longest period you anticipate a user's device may be offline. This increases the chance that the device will be online when the device attempts to renew the certificate. For example, if a user's device might be offline for as much as a month, then set the device certificate expiration value to at least 5 months.

    For more information on configuring the certification authority when you deploy MDM, see Configure a Certification Authority for MDM.

  • Write trace log files to a protected area
    Trace log files may contain Group Policy object (GPO) information. Make sure that you write the log files to a protected area on disk.

  • Harden the MDM Gateway Server before you install it in a potentially hazardous environment
    A potentially hazardous environment includes the perimeter network.

    You can harden the server by using the Security Configuration Wizard included with Windows Server 2003 Service Pack 1 (SP1) and later.

    Apply best practices for making the server that is running IIS for MDM Enrollment Server as secure as possible. This is known as hardening the computer. For more information about how to harden the TCP/IP stack, see this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkId=105660

  • Apply the appropriate Group Policy models to devices
    By using Group Policy settings, you can enable or disable many managed device capabilities. Use the Active Directory Group Policy (ADGP) Service to manage device configuration. For more information, see Enforce Group Policy Settings on Managed Devices.

See Also

Concepts

Security Considerations in Mobile Device Manager