Microsoft Systems Management Server 2003 : Permissions and Security Objects (part 1)

The SMS database is accessed through the SMS Administrator Console, and it’s here that SMS object security is defined. The user must have a valid Windows account in the domain in which the site server resides. When a user launches the SMS Administrator Console, the user’s account automatically accesses WMI, which validates the user’s permission. The user must be a member of the local SMS Admins group on the SMS Administrator Console computer, be a local Administrator, or be specifically granted WMI user rights using the WMI Control tool. The WMI Control tool is a Microsoft Management Console (MMC) snap-in. This utility provides an interface for assigning users and groups Read or Write permission to WMI objects. The user must also be a member of the SMS Admins group on the site server or on the server running SQL if the SMS Provider was installed there.

After WMI security validates the user, the SMS Provider validates the account and launches the SMS Administrator Console, displaying those objects for which the user has been given permission. By default, permission to all SMS objects is granted to the local system account (the NT Authority\System account) and the administrator who first installed the site server, as shown in Figure 1. To view the object security of any SMS object, select the Security tab in the object’s Properties dialog box.

1. Security Objects

Security can be established for the following eight SMS object classes:

• Advertisement

• Collection

• Packages

• Report

• Query

• Site

• Software Metering Rule

• Status Message

For most classes two kinds of security configuration are possible: class and instance. Class security is similar to NTFS folder permissions. Just as a folder’s NTFS permissions apply by default to all the files within the folder, so is class security applied to all members of the object class. In other words, any permissions you set for the object class Collections will apply to each collection, whether they’re the default collections or new collections you create.

Instance security is similar to NTFS file security. Just as you can set permissions on files different from those set at the folder level, you can also set security on individual members of an object class. For example, you might give the Windows group Finance Helpdesk no permission to the object class Collections yet still allow the group to read and manage the specific collection Finance Clients.

Establishing class and instance security for SMS objects is much the same as creating access control lists (ACLs) for Windows files, folders, and printers. In fact, many of the same principles apply. Permissions are always assigned to users or groups. Members of a group implicitly inherit the permissions for that group. No permissions granted is the same as Deny Access—you can’t access the object class.

For each class, you’ll identify which Windows users or user groups have what level of access. You’ll then refine that access at the instance level for each object. The permissions list reads much like NTFS permissions, with the addition of some permissions specific to SMS tasks and functions, such as remote control. Table 1 describes the available permissions and their object types.

Each object type must have at least one account granted Administer permission to prevent the possibility that SMS administrators could be locked out of the SMS Administrator Console. In fact, SMS doesn’t allow you to remove the last account with Administer permission from an object type, nor can you delete your own Administer permission on any given object.

When a user creates a new instance of an object, the user is automatically assigned Read, Modify, and Delete permissions for that instance. Granting Administer permission doesn’t automatically grant the other three permissions.

Here’s how the Delegate right works. This right allows a user to be able to grant the same level of permissions the user has been granted on an object class to other users or groups on new objects in the same class that the user creates. Simple, right? Here’s an example. Suppose that UserX has Create and Delegate permissions on the Collections class. Suppose, too, that UserX has Read, Read Resource, and Use Remote Tools permissions on the Finance collection instance. UserX can create a new collection because UserX has Create permissions on the Collection class. However, UserX can also delegate the Read, Read Resource, and Use Remote Tools permissions to other users or groups for the new collection.

I suggest that you spend a little time experimenting with object permissions if securing SMS objects beyond the defaults is a goal—for example, if you plan to create custom SMS Administrator Consoles. In some cases the combination of class and instance permissions that you set can have an effect on what the user can ultimately do. The best example of this involves collections. For each collection you can set a Read permission and a Read Resource permission. Read allows the user to see the collection and the members contained in the collection. However, if the user tries to view the inventory of a computer contained in a collection, Read permission isn’t enough. The user would also require the Read Resource permission.

In a similar fashion, permissions assigned—or not assigned—on one object class can affect a user’s ability to use other objects effectively. For example, suppose UserX can execute a query. The query is designed to return a list of computers from the SMS database. If UserX doesn’t also have Read permissions on the collections that contain the computers you expect the query to display, UserX won’t be able to view those computers in the query results window. As a result, the query results might not be accurate for that user. Like everything else we’ve talked about with SMS so far, it pays to test out your permission settings before you roll them out into a production environment.