Security and Delegation in Configuration Manager 2007 : Securing Administrative Access to Configuration Manager (part 1) - Administrative Access at the Operating System Level

• Distribute and run any code of his choosing on any ConfigMgr client system, using either the privileged system account or the credentials of the logged-on user. This singular ability gives the administrator virtually unlimited control over the managed environment.

• Collect and view any file from client systems. This makes all data stored in the file systems of your client systems potentially accessible to the ConfigMgr administrator.

• Interact directly with client systems through remote tools or OOB Management. On Windows 2000 systems, an administrator can use the gold-key functionality to simulate the Ctrl+Alt+Delete key combination and log on to the computer. With OOB Management, an administrator can reboot a client and interact with the system during boot sequence—potentially booting to an ISO image. This gives the administrator potential ways to view and control user activity or access the machines in an unauthorized manner.

To mitigate the risks of someone with administrative access to ConfigMgr misusing her privileges, you should follow these principles as you develop your ConfigMgr administrative model and procedures:

• Employ separation of duties wherever possible to make it more difficult to abuse administrative access. When a person is able to carry out malicious or unauthorized activity on his own, the level of effort and risk of being caught is much lower than it would be if collusion with others were necessary.

  For example, packaging software is a highly sensitive operation because malicious code can be bundled with the software package. If a separate individual tests the package, the chances of detecting the malicious code will be higher. If another person is in charge of creating advertisements to distribute the package, the administrator who introduced the malware cannot target-specific systems for attack. Having a separate individual monitoring the deployment provides a final check on the software distribution activity, because unusual activity can be detected during deployment. Although it might not be feasible to assign each of these tasks to separate individuals, involving more than one person in the process can significantly reduce your risk.

• Grant the least privilege necessary for each administrator to carry out his responsibilities. Assigning overly broad privileges to users or administrators greatly increases the chances of compromising systems or data. A common example of this is adding a user to a local Administrators group on a Windows system instead of delegating the specific rights the user needs.

• Ensure audit trails for all security sensitive actions are properly preserved and that regular audits of your IT environment include a review of ConfigMgr activity. It is true that in any environment there will be some group of individuals with authority to carry out those actions required to administer information systems. Although you cannot generally block the administrative group from all opportunities to misuse their authority, increasing the chance of detection acts as a strong deterrent and reduces the chances of repeated or ongoing breaches of security taking place. Auditing is also an area in which separation of duties should be strictly enforced; you should not ask the administrators responsible for normal operations to provide data or reports used for auditing purposes.

Your organization should maintain sound practices around the management of job roles requiring administrative access. It is important that Human Resources (HR) departments have adequate pre-employment screening practices including background checks on prospective employees. Only give this type of administrative access to those employees whose job descriptions explicitly describe systems or application administration responsibilities. Employees receiving privileged accounts or access to sensitive information should sign forms accepting the conditions for this access and acknowledging potential consequences for misuse of privileged access. Develop these forms in consultation with the Legal department to ensure compliance with applicable laws.

Recommended practices include requiring employees to take vacation time and rotating responsibilities because this can often lead to detecting unauthorized activity. High turnover in security sensitive positions greatly increases risk, and your organization should make every effort to attract and retain high-quality, stable individuals for systems administration positions. Adequate and ongoing training of system administrators that includes an emphasis on security issues is essential to ensure they follow sound practices.

Offshoring can present particular challenges in terms of obtaining reliable background information on prospective employees and prosecuting legal action if required. This must be considered in any decision to transfer administrative roles to offshore locations. Outsourcing does not alleviate a company of its duty to protect customer, employee, and other sensitive data. You should, therefore, make sure that any service providers you engage follow security practices meeting or exceeding your organizational baselines.

Keep in mind that any individual or program that gains access to the administrative user’s session or account has the same privileged access the administrator has. To reduce the chances that an intruder or piece of malicious code hijacks an administrator’s credentials, you should take the following precautions:

• All administrators should use a separate, nonprivileged account for routine activities such as checking email and accessing the Internet. Use nonprivileged accounts as the primary logon to any machine other than servers or dedicated administrative workstations. To enforce this practice, consider blocking administrator account access to mailboxes and Internet connections. Windows Vista facilitates this practice through User Access Control (UAC). You should implement UAC settings to at least prompt the user and consider requiring a password for administrative access on Vista workstations used by administrators. If administrators use workstations running earlier versions of Windows, they need to use the “run as” functionality to launch the ConfigMgr console or access a terminal server to run the console instead of running it locally.

• Pay extra attention to securing administrative workstations.
  

Administrative Access at the Operating System Level

Administrative rights to your ConfigMgr systems begin with the Active Directory (AD) forest where you deploy ConfigMgr and the individual host operating systems of your site systems.The access rights to ConfigMgr, the site systems, and the site database generally are assigned to AD users and groups. Access to the ConfigMgr infrastructure should be limited to only those personnel with direct responsibility for ConfigMgr operations or security.

For all practical purposes, it is impossible to prevent a domain administrator in the domain in which these users or accounts are defined from usurping administrative rights on your ConfigMgr hierarchy. However, you can make it difficult for this to happen without being noticed. You should consider the following measures to protect groups and user accounts with privileged access to any security sensitive infrastructure, including ConfigMgr:

• Restrict rights to manage administrative accounts and groups to a small group of senior administrators. You should remove any delegated rights to groups such as helpdesk personnel.

• Set auditing to record any changes to these user accounts and groups. Specify auditing of changes to AD in the highest precedence group policy that applies to your domain controllers. This is generally the Default Domain Controllers policy. You can use the GPMC to edit the auditing settings for your AD domain. The auditing policies are defined in the Default Domain Controllers policy under Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policy -> Audit Policy. The events you specify through the audit policy are recorded in the local security log of the domain controller on which the event occurs. Some specific auditing settings you might consider include

  • Audit account management— Events in the account management category include such sensitive operations as setting the password on a user account or adding a member to a group. Auditing account management is discussed at http://technet.microsoft.com/en-us/library/cc737542.aspx.

  • Audit directory service access— Events in the directory service access category include modifications to specific AD objects such as users or groups.

When you enable the directory service access auditing category through group policy, you also need to turn on auditing of the specific objects. There are several methods available to enable auditing on directory services objects. One way is to use the Active Directory Users and Computers (ADUC) tool. In general, you set the auditing at the Organizational Unit (OU) level rather than on individual objects. To enable auditing on an OU using ADUC, perform the following steps:

1.	Open Active Directory Users and Computers from the Windows Server Administrative Tools menu group.
2.	Expand the directory tree to the OU you want to audit. Right-click on the OU, and choose Properties.
3.	Click on the Security tab of the properties page; then click the Advanced button.
4.	On the Advanced Security Settings page, click on the Auditing tab and click the Add button.
5.	Enter Everyone in the Select User, Computer, or Group dialog box and click OK.
6.	In the Auditing Entry dialog box, select Descendant Group objects from the Apply onto drop-down list. Check the Successful column under Write all properties, Add/remove self as member, and any other operations you want to audit. Figure 1 displays the Auditing Entry dialog for the ConfigMgrAdmins OU in the foreground, with auditing enabled for all actions that successfully modify groups in the OU. Figure 1. Enabling auditing for all users modifying groups in the ConfigMgrAdmins OU

To track Windows and AD administration, you generally want to audit successful changes. You might also want to audit failure events of attempts to perform directory operations, to detect attempts to breach directory security by users who are not authorized administrators.

Securing the Audit Trail

One of the challenges for any security program is preserving the integrity of the audit logs. Attackers commonly try to cover their tracks by erasing or altering logs that might reveal their activities. If your system is in scope for regulatory compliance, it is essential you take measures to prevent any accidental or deliberate alterations of the audit record. For Windows security logs, the following audit settings can help detect events that might indicate a gap in audit log integrity:

• Audit policy change— Because group policy controls many of the most important security settings in your domain, you generally need to audit all policy changes. You need to review the security logs regularly for event ID 612 (An audit policy was changed). By changing audit policy, an administrator can prevent other actions from appearing in the audit logs. An unauthorized change to audit policy is a serious security breach, and you need to investigate it thoroughly.

• Audit system events— System events are events on individual servers such as startup or shutdown. Two system events of interest in protecting the integrity of audit logs are

  • Event ID 516— Internal resources allocated for the queuing of security event messages have been exhausted, leading to the loss of some security event messages.

    This event can indicate a server that is overloaded or a Denial of Service (DoS) attack against the audit subsystem. Regardless of the cause, it is an indication that your audit record is incomplete.

  • Event ID 517— The audit log was cleared.

    Clearing the audit log is an operation reserved to system administrators unless you have granted the right to manage auditing and security logs to other users through group policy. Clearing the audit log without backing it up creates a gap in the audit record. Even if the log is backed up when cleared, there is a slight window of opportunity for an administrator to perform unauthorized actions and then clear the audit log a second time without backing it up. You might detect this type of activity by comparing the timestamp on the log backup with the timestamp on the first event in the new log, and reviewing the new log for event 520. (The system time was changed.) Because of the risk of log tampering, it is best to avoid practices that require clearing the security log manually.

The maximum size of the Security log is finite, and you should carefully consider your options for setting Security log policies. You can set the event log policies locally using the Event Viewer application in the Administrative Tools program group or through group policy. To manage event log setting through group policy, edit the appropriate policy in the GPMC and navigate to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Event Log. Here are some available options for the event log:

• Maximum security log size— This is the maximum log size in kilobytes with a range of possible values from 64 through 4,194,240 (4GB). This value must be a multiple of 64. The average size of an event is approximately 500 bytes. You should, therefore, choose a value that is adequate to hold the number of events per day you estimate will occur, multiplied by the number of days in your desired retention period. For Windows 2003 Server 32-bit editions, the maximum recommended event log size is approximately 300MB. For Windows Server 2008 and all 64-bit Windows Server editions, the maximum recommended size is 4GB.

• Retain security log— This specifies the minimum age that an event in the security log can be overwritten if the retention method (discussed in the next bullet) for the security log is By Days. If you use this method, you should set this policy to a large enough value to ensure the logs will be backed up before events are overwritten.

• Retention method for security log— This setting allows you to choose one of three options:

  • Overwrite events by days— This setting allows events to be overwritten only after the number of days specified in the Retain security log policy setting. This setting might cause events not being written if a large number of audited events have filled up the log, and is susceptible to an attack on the audit record by flooding the system with a large number of meaningless audit events before committing an actual security breach.

  • Overwrite events as needed— This setting is the default method and causes the oldest events to drop from the logs in a first in, first out (FIFO) fashion. Overwriting security events might cause a loss of information if there are a large number of audited events, and is susceptible to an attack on the audit records from flooding the system with a large number of meaningless audit events after an actual security breach occurs.

  • Do not overwrite events (clear log manually)— This setting prevents events from being overwritten. This setting might prevent events from being written if a large number of audited events fills up the log, and is susceptible to an attack on the audit records by flooding the system with a large number of meaningless audit events before committing an actual security breach. Generally, you only use this setting if you also set the Audit: Shut down system immediately if unable to log security audits policy under Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options. Setting the policy to shut down the system when unable to log security audits should only be considered in highly secure environments where audit requirements outweigh availability concerns!

Windows Server 2008 and Windows Vista provide additional group policy options for event log management, found under Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Event Log Service. These options allow you to automatically archive the event log when it reaches its maximum size. You are still limited by the available storage capacity of the partition where the security log is stored. For additional information about event log policy options, see http://technet.microsoft.com/en-us/library/cc778402.aspx. For information about recommended size settings for event logs and relocating your event logs, see http://support.microsoft.com/kb/957662.

Securing Site System Local Administration

The built-in local Administrators group on any Windows system has complete and unrestricted access to the computer. Even without specific administrative rights within ConfigMgr, a member of the Administrators group on a ConfigMgr site system could potentially alter files, Registry settings, or other items related to system configuration in ways that would affect ConfigMgr services. By default, the Domain Admins group for the local domain is part of the local Administrators group. You should consider removing the Domain Admins group and replacing it with the appropriate AD group that has direct responsibility for server administration of the site system. For non-client facing site systems, you might also consider removing the Domain Users group from the local Users group. The remaining built-in groups, such as Backup Operators and Power Users, should not contain any members unless required for your administrative processes. You should generally not create local users or groups on site systems other than those required by ConfigMgr. As with all Windows systems, you should rename the built-in Administrator account, set a strong password for that account, and use appropriate procedures to manage access to the account password. You should also disable the built-in Guest account.

You can use the Computer Management tool to manage local users and groups. You can also use domain-based group policy to enforce consistent settings for most local account settings across multiple servers. To manage local accounts through the computer management tool, perform the following steps:

To control local account and group settings though group policy, you can use the GPMC to edit either the Default Domain Policy or a policy linked to the appropriate OU for your site systems. The following nodes in the group policy tree contain settings controlling the behavior of local accounts and groups:

• Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options includes settings such as Accounts: Rename administrator account, which you can use to apply changes to all systems on which the policy is applied.

• Computer Configuration -> Windows Settings > Security Settings -> Restricted Groups allows you to specify restricted groups, such as Administrators, and specify the membership of those groups.

Although Microsoft does not supply a tool to automate changes to the local Administrator account password across multiple systems, a number of third-party tools and scripts are available that supply this functionality.

Just as auditing AD administration helps detect and deter misuse of domain level administrative privileges, auditing actions by administrators on site systems is an important part of your control framework. You can use group policy settings in the Default Domain Policy, a policy linked to the appropriate OU for your site systems or local group policy to enable the appropriate auditing. The most important auditing categories you should enable include the following:

• Audit account management— Local user accounts and groups should rarely change, so auditing local account management on site systems will generate relatively little overhead.

• Audit policy change— As with account management, policy changes should rarely occur locally on servers. When changes do occur, you want to know about it.

• Audit object access— On the site system itself, you will be interested in auditing changes that might affect ConfigMgr functioning, such as modifications to files or server configuration. These might generate a considerable amount of audit events, so you need to set the audit policies carefully.

As with the directory service access, auditing object access requires the policy to be set and auditing to be applied to specific objects. There are various ways to set object level auditing; for example, you can use Windows Explorer to set auditing on file system objects, and you can use the Registry Editor to set auditing on Registry keys. Here are some objects you might want to audit on ConfigMgr site systems:

• Package source files

• Site control file

• Client source files

• The HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\MP\Certificates registry subtree

As with any auditing, you should use caution and test your local audit settings thoroughly to avoid excessive auditing. Auditing large numbers of Registry keys can have a severe performance impact.