Security and Delegation in Configuration Manager 2007 : Securing Configuration Manager Operations

Best Practices for Configuration Manager Administration

Only those users responsible for server administration should be able to log on locally to the site server or other site systems. Other users requiring access to the ConfigMgr console should install and run the console on secure administrative workstations or terminal servers dedicated to IT systems administration. 

You should also consider limiting web browsing from those systems with the Configuration Manager console installed, including site servers. Configuration Manager 2007 displays reports, online help, and other content as web pages hosted in the console’s Microsoft Management Console (MMC) window. You can use group policy to restrict browsing on systems running the console. Group policy settings to control browsing behavior in Internet Explorer are explained in http://support.microsoft.com/kb/182569.

It is particularly important to implement controls on files used in ConfigMgr operations not managed by ConfigMgr. Some examples of these files include the following:

• eXtensible Markup Language (XML) files created if you use the Transfer Site Settings Wizard to copy site settings from one site to another. These files contain details about your ConfigMgr site settings; alteration of the files could result in applying inappropriate settings at the target site.

• Managed Object Format (MOF) files used to copy queries, collections, or reports between sites. Unauthorized changes to these files could result in a variety of issues including improper targeting of advertisements and changes to object permissions.

• Files created by site backup operations. Backup files contain all data from your site database and configuration information from the site control file and site server registry. Alteration of backup files could result in unauthorized changes to the site in the event of a site restore operation.

You should use Windows access lists and possibly other controls such as FIM to protect the integrity of these files. If you use external media to store or transfer files used in ConfigMgr operations, you should implement procedures to control physical access to media at all times and consider cryptographic controls on media to prevent tampering with the files. Network file transfers should also be done in a secure manner, using the most secure network available and cryptographic controls such as IPSec. 

In addition, you should digitally sign internally developed DCM configuration data and only import configuration data that has a valid signature from a trusted publisher. Configuration data from Microsoft is always digitally signed.

Operational Security for Software Distribution

To ensure only authorized software is deployed to your ConfigMgr clients, you need to build security into all phases of your software deployment life cycle. You should carefully protect package source files throughout their development, testing, deployment, and maintenance to make sure that only authorized changes occur. ConfigMgr has no way to verify the integrity of the package source folders you point it to, so it is up to you to implement the necessary controls.

You should consider the same types of controls as for other operational files to protect the source directories and provide for secure file transfer. You might want to have your Quality Assurance (QA) team digitally sign all package files before you deploy them to production. If at all possible, you should avoid embedding sensitive information such as passwords and data source connection strings in scripts, settings files, or other files within your package source folders. If it is absolutely necessary to use embedded passwords or other confidential information, always use strong encryption and Windows access controls to protect this information.

Whenever possible, use the Download content from distribution point and run locally option when you deploy software. The client calculates a hash of the downloaded content and verifies that the hash matches the value provided in the advertisement policy before running the program. This verification is not available if you use the run from distribution point option. Keep in mind that branch distribution points and programs that directly specify a UNC path do not support the download and run option.

Another important consideration for software distribution is preventing users from leveraging advertised programs to gain elevated privileges. Figure 1 shows the Environment tab of the program Properties page with the Run with administrative rights option selected and the Allow users to interact with this program check box enabled. This combination of settings is generally not recommended except when troubleshooting a program. With these options enabled, the user can influence the execution of a program running in an administrative context, generally Local System. In some cases, the user might break out of the user interface provided by the setup program and spawn another program, such as a command shell, which would provide unlimited access to the system.

The need to install software is probably the most common reason for granting administrative access to those users who do not have system administration responsibilities. Although allowing nonprivileged users to interact with programs running in a higher privilege context is not a best practice, in some cases it might be a better practice than granting users administrative rights to allow them to install software! Depending on your business needs and security requirements, you might consider this as a convenient way to effectively provide temporary administrative access during software installation. If you have adequate resources, package all software to run silently, or use alternate software deployment methods.

If you use ConfigMgr’s Wake On LAN (WOL) functionality, use Unicast wake-up packets rather than subnet-directed broadcasts for maximum security. If you choose to use subnet-directed broadcasts, be sure to follow the recommendations presented in http://technet.microsoft.com/en-us/library/bb632486.aspx. Use Out of Band Management rather than WOL if your environment supports it.

If you implement Configuration Manager 2007 R2 Application Virtualization, you should enable encrypted mode for any application virtualization streaming–enabled distribution points.

Operational Security for Operating System Deployment

The considerations that apply to securing OS deployment are similar to those for software deployment. In addition, you should pay close attention to the following points:

• Secure the reference computer by placing it in a secure network environment, blocking unauthorized access, and keeping patches and antivirus software up to date.

• Secure all boot images, OS images, drivers, and driver packages as you would secure package source files.

• Password protect all boot media, and keep media physically secure.

• User state migration can present privacy and confidentiality issues. Consider these issues as you determine the data and settings to migrate and how to protect user state data. If you decommission a user state migration point, you should manually delete all user content from the system.

• Enable encryption for all multicast packages to prevent tampering and exclude rogue computers from multicast sessions.

Operational Security for Remote Tools Administration

Remote tools access gives administrators possible opportunities to breach user privacy or obtain confidential information. To minimize the potential for abuse of remote tools functionality, consider the following measures:

• Enable notification for remote sessions to prevent users from being spied on without their knowledge. Enable the Display a visual indicator and Play a sound options on the Notification tab of the Remote Tools Client Agent property sheet. You can configure Remote Tools Client Agent properties in the console, under System Center Configuration Manager -> Site Database -> Site Management -> <Site Code> <Site Name> -> Site Settings -> Client Agents.

• Enable Ask for permission when an administrator tries to access clients on the General tab of the Remote Tools Client Agent property sheet. The Ask for permission setting provides a level of protection, but it might be circumvented on Windows 2000 computers.

  Enabling Ask for permission is a site-wide setting and prevents administrators from connecting to unattended servers or workstations. This setting might, therefore, not be appropriate for all sites.

• Windows 2000 Computers use an older and less secure technology for remote tools than Windows XP and later systems. In particular, the remote tools interface for Windows 2000 provide buttons that simulate Ctrl+Alt+Delete, Ctrl+Esc, Alt+Tab and other Alt+Key key combination to the remote computer. This functionality has been removed from the remote tools for Windows XP and later systems to limit access to unattended machines.

• To maintain consistency, do not use both group policy and ConfigMgr client agent settings to configure Remote Assistance settings. This can lead to possible conflicts and unpredictable results.

• A user who is in the permitted viewers list on the client computer can connect to the computer in various ways without using the ConfigMgr console. This bypasses collection level security. The only way to control access to remote tools is through the permitted viewers list. 

• Avoid entering passwords during a remote administrative session. Passwords could be intercepted by malicious software, or cached on the local machine.

Operational Security for Configuration Manager Inventory

Client inventory allows you to collect virtually any information about client machines through WMI. The most security sensitive capability of ConfigMgr inventory is its capability to collect files from ConfigMgr clients, which could expose any data stored in files to potential compromise if inventory functionality is misused. If you collect files containing sensitive information from clients, you should carefully monitor all collections containing these systems to ensure read resource rights are limited to the required group of administrators. You should also verify the file system permissions on the location where the files are stored adequately protect sensitive content. For maximum security, consider encrypting sensitive files on client systems to prevent exposure of sensitive data even if you collect the files.

You should also consider security issues around the file types you include in software inventory. By default, only .exe files are inventoried. Inventorying file details such as the filename might reveal confidential information, even if you do not collect the files themselves. For example, if you inventory .pst files and a user in your Finance department has a file called AAA acquisition.pst, any user with read resource rights on the client system or rights to view certain reports might learn that a proposed acquisition is under consideration.

Systems Management Server (SMS) 2003 and earlier versions of SMS did not support the use of the Configuration.mof file. Instead, Management Information Format (MIF) files were used for custom inventory collection. ConfigMgr also supports the use of MIF files for backward compatibility and addressing specialized requirements. Two distinct categories of MIF files are sometimes used for inventory collection:

• IDMIF files contain complete metadata to uniquely identify an inventory class. You can use IDMIFs to add devices to inventory that are not associated with existing client architectures, such as network printers or point of sale systems.

• NOIDMIF files allow you to inventory additional classes on existing clients, such as data collected from the system Registry or manually input by the user.

When ConfigMgr processes IDMIF and NOIDMIF files, the inventory processor component adds or modifies database tables as required to accommodate the data. However, ConfigMgr does not perform the same validation process on IDMIF and NOIDMIF files as on standard inventory files. To protect the integrity of the site database, you should consider disabling the collection of IDMIF and NOIDMIF files and replacing any required inventory customization with custom MOF files.

Operational Security for Mobile Device Management

The growing use of mobile devices to connect to enterprise information systems and store and process data presents a unique set of challenges to IT organizations. Mobile devices generally connect over networks and from physical locations not under the organization’s control. Mobile device hardware and software is less standardized than PC hardware and software, and the controls framework around mobile devices is less mature. Mobile devices can easily be lost or stolen, which can lead to compromise of any data stored on the device and provide an attacker access to email and other network content. As part of your strategy for allowing mobile devices to access network resources and data, you should always consider the risks involved and the available strategies for mitigating risk. You can use ConfigMgr mobile device management to apply several important controls to enhance device security. To enable configuration items for mobile devices and set applicable options, expand the console tree to System Center Configuration Manager -> Site Database -> Computer Management -> Mobile Device Management, right-click Configuration Items, and choose New Configuration Item. This launches the New Configuration Item Wizard. Keep in mind that not all configuration items might be applicable, depending on the mobile device OS. You can select the configuration item type you want to enable from the New Configuration Item Wizard’s Select Configuration Type page. The wizard then displays the appropriate property pages for the selected item type. Some configuration items you can use to enhance device security include

• The certificate installation configuration item specifies the certificate ConfigMgr distributes to mobile devices and the device certificate store.

• Password policies for the Windows Mobile Messaging and Security Feature Pack (MSFP) allow you to specify minimum password length, complexity requirements, and other password related parameters. You can require that the device will be wiped, meaning all data stored on the device will be erased, after a specified number of failed password attempts. Password management for Pocket PC 2003 provides some password controls but does not include device wipe capability.

• The Security Policies configuration item lets you specify policies to control running unsigned applications, cab files, or theme files, and to control autorun behavior for memory cards.

• The WiFi Properties: Authentication tab provides a number of options for controlling the behavior of devices when connecting to WiFi access points. You should enable WiFi Protected Access (WPA) or WPA preshared key (PSK) and use Temporal Key Integrity Protocol (TKIP) encryption if possible. Do not rely on wired equivalent privacy (WEP) for security. WEP is a notoriously insecure protocol.

• VPN settings allow you to configure VPN access to your corporate network.

• Registry settings allow you more granular control over device security.

Some additional controls you might consider for mobile devices include

• Full device encryption to protect all data on the device.

• Remote wipe capabilities to allow administrators to wipe lost or stolen devices.

• Bluetooth lockdown to control connections to other Bluetooth devices.

Because ConfigMgr Device Management does not provide these options, you need to use other means to implement these controls if you require them.

ConfigMgr uses cryptographic controls to protect communications with mobile device clients and ensure the integrity of policy and content downloads to those clients. The cryptographic controls require you to deploy the required certificates to these clients. For information about deploying certificates to mobile device clients, see http://technet.microsoft.com/en-us/library/bb633088.aspx. Native mode provides additional security through mutual authentication, which prevents unauthorized devices from connecting to your ConfigMgr site and can help mitigate man-in-the-middle attacks on device communications. For information about specific certificate requirements for mobile device clients in native mode sites, see http://technet.microsoft.com/en-us/library/bb693603.aspx. The Microsoft System Center Configuration Manager Mobile Device Management whitepaper provides additional information about secure communications with mobile device clients.