Security and Delegation in Configuration Manager 2007 : Securing the Configuration Manager Infrastructure (part 3) - Securing Configuration Manager Accounts

Securing Configuration Manager Accounts

ConfigMgr uses are variety of accounts as part of its operating framework. Many of these accounts are required in specific situations, such as accounts to support clients or site systems in untrusted domains. Other accounts are required to support only specific services, such as Out of Band Management. You should use only the accounts required by your environment or to support specific ConfigMgr features you use. Follow best practices for configuring and managing accounts. Some general principles for managing ConfigMgr accounts include

• Use strong passwords and change those passwords regularly. If you have an enterprise password management application, you should use it to secure ConfigMgr passwords. At a minimum, keep the passwords in a secure location protected by access controls and encryption, only allow administrators access to the passwords on a need to know basis, and keep track of who knows the passwords. If a person with access to ConfigMgr passwords leaves the company or you suspect a password is compromised, change the affected passwords immediately.

• Keep track of which accounts are used where, and deprovision any accounts no longer needed. If possible, integrate account life cycle management with your enterprise change and configuration management processes.

• Configure each account with the minimum rights it needs to accomplish its job.

• Whenever you use AD accounts in ConfigMgr, allow time for newly created accounts to replicate throughout the domain before you add the accounts to ConfigMgr.

• Do not grant these accounts interactive logon rights. Occasionally you might need to log on with one of the accounts used for ConfigMgr operations for troubleshooting purposes. In such cases, grant interactive logon rights on a temporary basis and document this step in your trouble ticketing system. The Task Sequence Run As account also needs interactive logon rights on systems where a task sequence configured to use this account runs.

Microsoft provides detailed descriptions of all ConfigMgr accounts in the online documentation. To help you sort out these accounts, the next sections present ConfigMgr accounts organized into functional groups. You can find additional details about ConfigMgr accounts at http://technet.microsoft.com/en-us/library/bb693732.aspx.

Accounts to Support ConfigMgr Infrastructure

ConfigMgr uses accounts to install components on site systems and for intersite communications. Within the site server’s AD forest or in domains trusting the site server’s domain, you should use the site server machine account for these purposes rather than configuring separate accounts.

Two types of accounts are used for installation purposes:

• Site System Installation accounts are used to install and configure site systems. You specify the Site System Installation account used to manage a particular site system on the New Site System Server Wizard, General page.

• Client Push Installation accounts are used to install and configure client systems if you use the client push installation method. 

You can use either Active Directory or local accounts for site system installation and client push. These accounts need to be in the local Administrators group on the target systems. You should not add these accounts to the Domain Admins group because this would provide excessive privileges to the accounts. Instead, create groups that include the appropriate accounts and use group policy or local computer management to add those groups to the local Administrators group. The Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Restricted Groups setting allows you to administer local group membership through group policy. To limit the administrative scope of these accounts, consider using multiple accounts and granting each account access only on those systems on which you use it.

The accounts used for site-to-site communications are

• The Site Address account is used by the LAN sender to send data to other sites in your ConfigMgr hierarchy.

• The Remote Access Services (RAS) Sender Phone Book account is used to initiate connection for the RAS sender.

You can specify these accounts on in the Address properties for the destination site. These accounts require modify rights on the SMS_Site share (<ConfigMgr Install Path>\Inboxes\Despoolr.box\Receive folder) on destination site servers. You should provide this access by adding the accounts to the Site to Site Connection local group (SMS_SitetoSiteConnection_<Site Code>) on the destination site server. The RAS Sender Phone Book account also needs rights to initiate a RAS connection. You should generally use the same account for both of these roles.

Database Connection Accounts

If you have site systems that do not reside in the same AD forest as the site database server or in a domain trusted by the site database server’s domain, you need to configure accounts these systems can use to connect to the database. Within the site database server’s AD forest or in trusted domains, use the site system machine’s accounts for database connectivity. If you need database connection accounts, you should create these accounts as low privilege local accounts on the database server. You can specify a database connection account on the site system role Properties page. You will then add the accounts to predefined database roles to provide the access they require. Table 1 displays a list of these accounts and the database roles they require.

Accounts Used for OS Deployment and Software Distribution

ConfigMgr operating system deployment (OSD) requires accounts to carry out several specific task sequence actions. These accounts are specified in the task sequence properties. Table 2 displays the task sequence accounts with information about their usage and required permissions.

OSD accounts are generally AD domain accounts; however, you have the option to use local accounts for the Capture Operating System Image account and the Task Sequence Run As account.

In addition to the accounts listed in Table 2, both OSD and software distribution use the Network Access account to access network resources when the client computer account and/or current user does not have access. You can configure the Network Access account in the ConfigMgr console on the General tab of the Computer Client Agent property sheet, found under System Center Configuration Manager -> Site Database -> Site Management -> <Site Code> <Site Name> -> Site Settings -> Client Agents. Generally, you need this account only for client computers in workgroups or untrusted domains, or for use during operating system deployment before the computer has joined the domain. Grant the account domain user permissions only. By default Domain Users have access to package shares on distribution points. If you remove this access or use a Universal Naming convention (UNC) path to specify the content location, you must grant the Network Access account Read permission if clients will use this account to access the content.

For granular access to packages, you can specify one or more Package Access accounts on a per package basis. Package Access accounts can be in any Windows user or group, or the built-in Users, Administrators or Guests groups. You generally use existing groups as Package Access accounts rather than creating accounts for this purpose. You can configure a Package Access account in the ConfigMgr console, under System Center Configuration Manager -> Site Database -> Computer Management -> Software Distribution -> Packages -> <package name> -> Access Accounts. The default Package Access accounts are Users with Read permission and Administrators with Full Control. In general, you change these defaults only to restrict packages to which you do not want all users to have access. Occasionally you might also need to grant Modify permission to the Users group if a setup program needs to write back to the source folder. Unless your security requirements are extremely low, you should not allow Guests access to anything on your network.

Accounts Used for Out of Band Management

Because the management controller has low-level system access on managed clients, it is critically important that OOB management access should be as secure as possible. The Intel Active Management Technology (AMT) Management Engine uses three accounts that reside in the AMT BIOS extension (MEBx) firmware to provide OOB management functionality on client systems with supported OOB management controllers. These accounts are used for provisioning and remote administration. In addition, ConfigMgr uses a set of AD user accounts or groups to manage permissions for OOB Management.

You can configure your site to use the three accounts that reside in the BIOS extensions through the Out of Band Management Properties sheet, located under System Center Configuration Manager -> Site Database -> Site Management -> <Site Code> <Site Name> -> Site Settings -> Component Configuration in the ConfigMgr Console. Here are the three accounts:

• MEBx account— This account is used for initial authentication to the AMT firmware. The MEBx account is named admin, with the default password admin. If you or your computer manufacturer has configured the management controller with a different password, you need to use the AMT Provisioning and Discovery account for provisioning instead of the MEBx account. ConfigMgr sets the MEBx account password during the provisioning process. You can specify the password on the OOB Properties General tab, or you can specify specific values for each computer in a comma-separated values (CSV) file and import them with the Import Computer for Out of Band Management Wizard. For instructions on running the Import Computer for Out of Band Management Wizard, see http://technet.microsoft.com/en-us/library/cc161950.aspx.

• AMT Provisioning and Discovery account— You can use this account to provision those computers provisioned previously using a different AMT management solution. Specify the account name and password on the OOB Properties Provisioning Settings tab. You might need to specify more than one AMT Provisioning and Discovery account if you have computers provisioned with different usernames and passwords.

• AMT Remote Admin account— This account is used by the OOB service point to manage AMT network interface features. The AMT Remote Admin account is named admin, with the default password admin. During provisioning ConfigMgr resets the default password to a random strong value. If the password was previously changed locally, ConfigMgr sets the password to match the MEBx account password. If the password was reset through another AMT management solution, see http://technet.microsoft.com/en-us/library/cc161983.aspx for options for migrating to ConfigMgr.

You can delegate administrative access to OOB Management by specifying AD users or groups as AMT User accounts on the OOB properties AMT Settings tab. Figure 5 shows the AMT User Account Settings dialog box with permissions selected to allow the user to view general information and hardware information from clients and read the AMT event log. Click the AMT User Accounts Settings dialog box Help button to see a description of each access type. You can add up to eight AMT users or groups.

Accounts Used for Software Updates

ConfigMgr uses two accounts for software updates:

• Software Update Point Proxy Server account— The SUP uses the Software Update Point Proxy Server account to authenticate to a proxy server or firewall to synchronize with Microsoft Updates or an upstream WSUS server. You can use any account that can authenticate to your proxy server or firewall and access the site for WSUS synchronization for this account. To specify a Software Update Point Proxy Server account, expand the ConfigMgr console to System Center Configuration Manager -> Site Database -> Site Management -> <Site Code> <Site Name> -> Site Settings -> Site Systems -> <Software Update Point>, right-click the ConfigMgr software update point, and choose Properties. On the General tab, check the boxes for Use a proxy server when synchronizing and Use credentials to connect to the proxy server, and then click the Set button to enter the account information.

• Software Update Point Connection account— WSUS services use the Software Update Point Connection account to configure settings and request synchronization. This account is required only if the SUP role is assigned to a remote server or Network Load Balancing (NLB) cluster. This account must be a member of the local Administrators group on the software update point server. To specify a Software Update Point Connection account, expand the ConfigMgr console to System Center Configuration Manager -> Site Database -> Site Management -> <Site Code> <Site Name> -> Site Settings -> Component Configuration. Right-click on Software Update Point Component, and choose Properties. If you selected the option for the active software update point on either a remote server or NLB cluster, the page displays a Software Update Point Connection account section. Use the Set button to enter the account credentials.

Accounts Used with Health State References

If you use Configuration Manager NAP and have system health validator points in a separate forest from the site server, ConfigMgr uses two accounts to manage health state references:

• Health State Reference Publishing account— ConfigMgr uses the Health State Reference Publishing account to publish health state references to AD. The Health State Reference Publishing account requires Read/Write permissions on the AD Systems Management container in the forest in which Health State References are stored.

• Health State Reference Querying account— The system health validator points uses the Health State Reference Querying account to read health state references from AD. The Health State Reference Querying account requires Read permission on the AD Systems Management container in the forest in which Health State References are stored.

You can configure both of these accounts on the Health State Reference tab of the System Health Validator Point Component Properties dialog box, under System Center Configuration Manager -> Site Database -> Site Management -> <Site Code> <Site Name> ->Site Settings -> Component Configuration in the ConfigMgr console. If the system health validator points are in the same AD forest as the site server, these accounts are not required.

Miscellaneous Accounts

Configuration Manager 2007 uses additional accounts to authenticate Internet-based clients to a proxy server or firewall and for ConfigMgr Release 2 (R2) client status reporting. These accounts are

• Proxy Account for Internet-Based Clients— Clients authenticating to a proxy server or firewall to access an Internet-based management point use the Proxy Account for Internet-Based Clients. You can use any account that can authenticate to your proxy server or firewall and access the management point for this account. You can configure the Proxy Account for Internet-Based Clients on the client through the Internet tab of the Configuration Management Control Panel Applet.

• Client Status Reporting Service account— Configuration Manager 2007 R2 Client Status Reporting (CSR) uses the Client Status Reporting Service account for its core functionality. You can use either the Local System account on the client status reporting point or a domain or local user account for this role. You specify the Client Status Reporting Service account when you install Client Status Reporting. The Client Status Reporting Service account must be a local Administrator on the client status reporting host system and also must have the smsdbrole_CH role in the site database and Read access to the management point policy request log files. If you use the client ping feature, the Client Status Reporting Service account must also be a local Administrator on each client system.