Security and Delegation in Configuration Manager 2007 : Securing Administrative Access to Configuration Manager (part 2) - Administrative Access Within Configuration Manager

Administrative Access Within Configuration Manager

Nearly all tasks you perform using the Configuration Manager console or through other administration tools and scripts use the Windows Management Instrumentation (WMI) provider to perform the requested operations. You can apply WMI access controls to namespaces, object classes, and individual objects and assign permissions to Windows users and groups. In virtually all cases, you use the Configuration Manager console to apply permissions to ConfigMgr objects and classes rather than directly modifying WMI permissions. You might also use custom scripts to manipulate object permissions. You can assign each set of object permissions using one of two ways:

• Class permissions grant the user rights on all objects of the class. For example, class permissions on the Collections class apply to all collections.

• Instance permissions apply only to a specific instance, such as the All Windows Server Systems collection.

Most classes allow you to assign both class permissions and instance permissions; however, some classes such as the status message class do not support permissions on individual instances. The principle of least privilege suggests you should use instance permissions unless a user needs permissions on all instances of a class. Assigning permissions on a per-instance basis can become quite cumbersome, however. You need to evaluate the risk associated with assigning permissions at the class level and decide what model works best for your organization. For example, you might decide that assigning Read permissions on the package class is acceptable, but Modify permissions need to be more tightly controlled using instance permissions.

Granting Access to the Namespace

Before granting permissions to a user on object classes or individual instances of objects, you need to grant the user remote enable permission on the ROOT\SMS\site_<Site Code> namespace. You can generally do this by adding the user to the SMS Admins local group on the site server. The SMS Admins group does not have any administrative rights within ConfigMgr by default; adding a user to the SMS Admins group only grants them sufficient rights to launch the console and connect to the site database. Members of the local Administrators group have full access to all WMI namespaces by default. You do not, therefore, need to add members of the local Administrators group to the SMS Admins group.

As with any user access administration in Windows, the best practice is generally to add users to groups and assign permissions to the groups. As you plan your ConfigMgr administration model, you should create AD groups corresponding to each administrative role or identify existing AD groups containing the appropriate members. For example, you might create a ConfigMgr Software Packagers group for users needing rights to create and manage packages, or you might identify the existing Helpdesk group as needing access to remote tools. In general, you should assign the minimum permissions to each group to allow them to carry out their required functions and avoid creating overly broad groups that have more rights than they need. Add each AD group that needs access to the ConfigMgr console to the SMS Admins local group.

Managing Permissions Through the ConfigMgr Console

When you first install a ConfigMgr site, the user who installed the site and the Local System account have Full Control on the entire site and all objects it contains. No other users have access to the site. If you upgrade a site from SMS 2003, users retain their existing class and instance rights; however, only the system and the user who performs the upgrade have rights on object classes that are new to ConfigMgr. If you have a group of administrators who require Full Control on the site, one of the first tasks you should do is to copy the rights of the Local System account (NT AUTHORITY\SYSTEM) to the ConfigMgr administrative group. Perform the following steps:

1.	Add the AD group with your ConfigMgr administrators to the SMS Admins local group on the site server. If the ConfigMgr administrators are already members of the local Administrators group on the server, this step is not required.
2.	Open the ConfigMgr Console and navigate to System Center Configuration Manager -> Site Database -> Security Rights.
3.	Right-click Users and choose Manage ConfigMgr Users to launch the ConfigMgr User Wizard; then click Next at the Welcome screen.
4.	On the User Name page, select the option to add a new user and enter or browse for the appropriate group; then click Next. Figure 2 shows the User Name page with the name of the ConfigMgr administrative group entered. Figure 2. Adding the ConfigMgrAdmin Group as a ConfigMgr user principal
5.	On the User Rights page, select Copy rights from an existing ConfigMgr user or group, as displayed in Figure 3; then click Next. Figure 3. Choosing to copy rights from an existing user
6.	On the Copy Right page, select an existing administrator account from the Source user drop-down list, as shown in Figure 4 and click Next. This returns you to the User Rights page, which now displays the set of rights to be copied. Click Next to view a summary of your choices and Next again to initiate the user creation. When the operation completes you receive a confirmation that the wizard has completed successfully. Click Close to return to the ConfigMgr console. Figure 4. Copying rights from the Local System account

Microsoft recommends you restrict full ConfigMgr rights to a small group of trusted senior administrators. This model is likely to be appropriate for most organizations. In high-security settings, you might want to go a step further and strictly enforce the separation of duties principle. The ConfigMgr User Wizard allows you to modify existing users’ rights. You could, for example, assign a security administrator Administer rights on all classes and remove all rights that are not part of the Administer permission. The security administrator could then assign rights to operational personnel based on their job roles.

To modify the rights of an existing user, perform the following steps:

1.	Choose Modify an existing user on the User Name page (shown in Figure 2), and select the appropriate user from the drop-down list.
2.	On the Copy Rights page (Figure 3), choose Add another right or modify an existing one. Figure 5 shows the Add Right page with the Package class rights selected. Figure 5. Assigning rights on the Package class
3.	The exact set of permissions included with Administer varies, depending on the individual class. To see the minimum set of rights required for Administer permission on the package class, click on the Clear All button, and then select Administer from the Rights list. You cannot remove the Administer right for a class or instance from all users because that would effectively orphan the affected objects.

In addition to the user node under System Center Configuration Manager -> Site Database -> Security Rights in the ConfigMgr console, there is a Rights node where you can view and edit all class and instance rights defined in your site. Figure 6 displays the Rights node with the rights list sorted by class.

Figure 6. The ConfigMgr Console Rights node displays a list of assigned rights.

Not only can you manage users and rights through the Security Rights console nodes, you can also view and set permissions using the Security tab on the object’s Properties page. For example, you can right-click the System Center Configuration Manager -> Site Database -> Computer Management -> Collections node and choose Properties to manage security for the collections class. Right-clicking on an individual collection lets you display its Properties page and manage instance permissions for that collection. This is often the most convenient way to manage object permissions.

Characteristics of ConfigMgr Object Permissions

Keep in mind the following characteristics of ConfigMgr object permissions:

• Permissions are local to the site.

  Sites form an important security boundary in ConfigMgr. Objects propagated from parent sites are read-only at child sites, indicated by the padlock icon displayed in the user interface. Class rights, rights on local objects, and access through the local SMS Admins group are all determined locally on a primary site. This enables you to divide administrative responsibilities on a per-site basis and by feature or object set. This capability provides a convenient way to restrict administrators to a portion of the hierarchy, based on the scope of their responsibilities. This can also be useful if some sites have particular requirements such as the need to meet Payment Card Industry (PCI) standards. It might be much easier to meet such requirements by isolation at the site level than through delegation of permissions within a site.

• Permissions are cumulative across user groups, object hierarchies, and collections.

  Cumulative permissions across user groups means that if a user is in more than one group with access to a particular instance or class, that user has all rights assigned to any of the groups, and any rights explicitly assigned to the user. Cumulative permissions across object hierarchies indicate that a user with permissions on an instance and on its class has all rights assigned at either the class or the instance level. Cumulative permissions across collections means that if a resource, such as a computer or user, is a member of more than one collection, then the rights each administrator has on the resource will be the union of the rights assigned through each collection. The ConfigMgr console does not provide a way to display effective permissions on objects, so to determine the effective permissions a user has, you must consider each way in which permissions can accumulate.

• The available rights vary, depending on the object class.

  Microsoft lists the rights applicable to specific ConfigMgr classes and instances in the Technical Reference for Configuration Manager Security, located at http://technet.microsoft.com/en-us/library/bb632791.aspx.

• A user with Read access on a collection can view the collection membership and discovered properties of the collection members.

  Read resource rights are required to view inventory data.

• A user with Administer rights on a class can manage permissions on all instances of the class.

  You can allow users to create objects and manage permissions only on the objects they create by assigning them class level Create and Delegate rights.

• There is no way to explicitly deny access to a class or instance.

Some ConfigMgr object permissions are particularly important. Pay close attention to permissions on the following objects:

• The site object is by far the most important ConfigMgr object. All administrative users need Read access to the site to access other objects within the site. Other rights on the site should be restricted to a small group of senior administrators. A few particularly sensitive rights are

  • Modify— The right to modify the site allows users to change things such as client agent settings and site system properties.

  • Manage SQL commands— SQL commands declared as part of site maintenance tasks run directly against the site database, bypassing the WMI layer. Because nearly all site configuration settings and ConfigMgr objects are stored in the database, direct database access enables you to perform almost any operation possible in a ConfigMgr environment.

  • Manage status filters— Status filter rules can invoke actions including running a program in the context of the SMS Executive Service.

• Software distribution enables you to run any program or command on client machines in the context of Local System or the logged-on user. The Local System account has complete access to all resources on the machine. The logged-on user might have access to local or network resources that administrators are not allowed to touch, such as sensitive financial data or intellectual property. A program or script executing in the context of an authorized user could copy or alter data without producing a suspicious audit trail. Keep in mind that ConfigMgr can run software silently in the background, so the user is not aware of what is taking place. ConfigMgr can also run software when no user is logged on. To reduce the chances of unauthorized ConfigMgr software distribution, restrict access to the following classes:

  • Packages are the most sensitive object in software distribution. The package properties specify the location of the source files. The package’s program settings include the command line to run, and if it runs in the system or user context. Program settings also provide the capabilities to run the program hidden and to suppress program notifications. Taken together, these options allow an administrator to introduce any software of his or her choosing into your environment and control the deployment scope and the manner in which it deploys.

  • Advertisements and collections control the targeting of software distribution. A user with Read and Advertise rights on a collection can advertise any existing package to the collection, provided the user also has Read rights on the package. A user with the right to modify a collection that is the target of an advertisement or the ability to link collections to other collections can change the targets for an existing advertisement. A user with the right to modify an existing advertisement can change the properties of the advertisement, including the package and program that will execute.

• Other sensitive features with client impact include software updates and OS deployment. Some examples of why access to these classes needs to be restricted include:

  • A user with rights to modify deployment packages could prevent systems from receiving specific updates, leaving them vulnerable to attack.

  • A user with rights to modify operating system images, driver packages or other OS deployment objects could embed code into your newly deployed systems to provide backdoor access to the systems.

The above list is by no means an exhaustive compilation of the threats posed by ConfigMgr administrative access in the wrong hands, but should give you a good idea of the types of issues to consider when assigning rights within ConfigMgr.

Security for Remote Administration

Access to the ConfigMgr remote administration tools is granted through the permitted viewer’s list property of the Remote Tools Client Agent. To edit the permitted viewers list, perform the following steps:

Auditing Configuration Manager Administration

ConfigMgr generates status messages of type Audit to provide an audit record of certain security sensitive operations. Audit messages are generated for remote control of client systems and OOB Management console activity. The SMS provider also generates audit messages when a user creates or modifies an object or makes security changes on a ConfigMgr class or instance. The audit messages for security changes indicate the user making the change, the target user or group whose rights are modified, the object class, and the object ID for specific instances. The specific permissions assigned or removed are not included. Similarly, audit messages record a user making changes to an object, such as modifying a program in a software package but do not provide details such as the command line the user entered for the program. You can use the following status message queries to view audit messages:

• All Audit Status Messages from a Specific Site

• All Audit Status Messages from a Specific User