Permissions and Security Objects | Microsoft Systems Management Server 2.0 Administrators Companion (IT-Administrators Companion)

[Previous] [Next]

In addition to the security provided by Windows NT and through SQL Server, SMS 2.0 maintains its own object-level security for the SMS site database using the SMS Provider and Web-Based Enterprise Management (WBEM) security. By assigning specific permissions to Windows NT users and groups, the SMS Provider controls access to specific SMS objects such as packages, advertisements, and collections.

The SMS database is accessed through the SMS Administrator Console, and it is here that SMS object security is defined. The user must have a valid Windows NT account in the domain in which the site server resides. When a user launches the SMS Administrator Console, the user's account automatically logs onto WBEM, 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 WBEM user rights through the WbemPerm utility, which is installed in the WINNT\System32\WBEM folder when SMS is installed on the site server. This utility provides a GUI for assigning users and groups Read or Write permission to WBEM objects. The user must also be a member of the SMS Admins group on the site server or on the SQL server if the SMS Provider was installed there.

After the user is validated by WBEM security, 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 Windows NT Authority/System account) and the administrator who first installed the site server, as shown in Figure 16-3. To view the object security of any SMS object, select the Security tab in the object's Properties window.

Figure 16-3. The Security tab of the Collections Properties window.

Security Objects

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

Advertisements

Collections

Packages

Queries

Sites

Status Messages

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 are 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 NT 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 NT 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 No Access—you cannot access the object class.

For each class, you will identify which Windows NT users or user groups have what level of access. You will 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 16-6 describes the available permissions and their object types.

Table 16-6. Object permissions

Permission	Object Type	Description
Administer	All security object types	Administers all object classes, including assigning or modifying security rights
Advertise	Collections	Advertises existing programs to a collection
Create	All security object types	Creates an instance of an object type, such as a new query or collection
Delete	All security object types except Status Messages	Deletes an instance of an object type, such as a package or an advertisement
Delete Resource	Collections	Deletes a resource form a collection, such as a computer
Distribute	Packages	Deploys a package to a distribution point
Modify	All security object types except Status Messages	Makes changes to an object, such as editing the query statement for a query
Modify Resource	Collections	Modifies a resource in a collection
Read	All security object types except Status Messages	Views an instance and its properties
Read Resource	Collections	Views a resource in a collection
Use Remote Tools	Collections	Initiates a Remote Tools session with a client in a collection
View Collected Files	Collections	Views the files collected from a client through the Resource Explorer

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 does not 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 does not automatically grant the other three permissions.

Assigning Permissions

Permissions can be assigned to an object in two ways: you can use the Security Rights folder in the SMS Administrator Console to assign permissions to object classes and instances, or you can assign permissions at the specific object class or instance. Figure 16-4 shows the list of object classes and specific instances and their permissions that is displayed when you open the Security Rights folder. Notice that you can see the default permission as well as specific instances created.

click to view at full size.

Figure 16-4. Permissions displayed in the Security Rights folder.

To assign permissions through the Security Rights folder, follow these steps:

In the SMS Administrator Console, navigate to the Security Rights folder, select it, right-click on it, and choose New from the context menu.

Choose Class Security Right to assign permissions to an existing object class, or choose Instance Security Right to assign permissions to an existing object instance.

If you choose Class Security Right, the Security Right Properties window for the class is displayed, shown in Figure 16-5.

Figure 16-5. The Security Right Properties window for a class.

Enter the user name (or group name), select the object class, and select the permissions you want to assign. The permissions listed will vary depending on the object class you select.

Notice that the Instance field is disabled here. If you had chosen Instance Security Right in step 2, the Instance field would be available for you to specify an instance of an SMS security object.

Choose OK to save your security configuration.

TIP
You can modify any entry in the Security Rights folder simply by double-clicking on it to display its Properties window. Also, once you enter a user or group name, the name is saved for future modifications and can be selected from the User Name drop-down list.

You can also assign or modify permissions at the individual object class or instance level. This technique is preferable because it forces you to specifically choose the object whose permissions you want to modify. Follow these steps to assign or modify permissions at the object class level.

In the SMS Administrator Console, navigate to the folder whose class permissions you want to modify, right-click on it, and choose Properties from the context menu to display the object's Properties window. For this example, we will select the Queries object to display the Queries Properties window.

Select the Security tab, shown in Figure 16-6. Note the existing class-level security permissions.

Figure 16-6. The Security tab of the Queries Properties window.

To add a new user or group to the list, click the New button (the yellow star) to display the Object Class Security Right Properties window, shown in Figure 16-7.

Supply a user or group name, and select the permissions you want to apply. (As mentioned, selecting no permissions is like selecting No Access in NTFS.) Click OK to return to the Security tab of the Queries Properties window.

Figure 16-7. The Object Class Security Right Properties window.

To modify an existing entry, select that entry in the Class Security Rights list, and click the Properties button (the hand holding a piece of paper) to display the Object Class Security Right Properties window. Make the appropriate permission changes, and then click OK.

Click OK again to save your changes.

In the preceding example, we modified the permissions for the user SDK so that SDK has no permissions at the object class level for Queries. Now let's modify permissions at a specific object instance. To do so, follow these steps:

In the SMS Administrator Console, navigate to the specific object instance you want to modify, select it, and choose Properties from the context menu to display the Properties window for that instance. For this example, we will select an instance of the Queries object—Clients With Free Disk Space—to display the Clients With Free Disk Space Query Properties window.

Select the Security tab, shown in Figure 16-8. Notice the existing class and instance security permissions—SDK [No Permission] has "trickled down" to this instance.

Figure 16-8. The Security tab of the Query Properties window.

On this tab, you can modify both the class permissions for the Queries object (by clicking the New button, as we did in the preceding example) and the specific permissions for this instance.

To modify the instance permissions, click the New button in the Instance Security Rights section of the dialog box to display the Object Instance Security Right Properties window, shown in Figure 16-9.

Supply a user or group name, select the appropriate permissions, and then click OK.

Click OK again to save your configuration.

Figure 16-10 demonstrates how, in the preceding examples, instance security rights take precedence over class security rights. Notice that even though the user SDK has no permissions for the Queries object class, SDK can nevertheless read, modify, and delete the specific query Clients With Free Disk Space. This is wholly consistent with the NTFS security system. Even if you deny a user access to a folder, if the user has permissions to read a file within that folder, the user will be able to access that file through an application or from the command prompt.

Figure 16-9. The Object Instance Security Right Properties window.

Figure 16-10. Sample class and instance permissions.

REAL WORLD Using Security
Consider the SMS site hierarchy illustrated in Figure 16-11. In this model, SMS administrators are present at each site in the hierarchy. For organizational reasons, the third-level sites are secondary sites. Recall that secondary sites do not have their own SQL Server databases. Therefore, for the administrators at the secondary sites to be able to manage their sites, their SMS Administrator Console computers need to connect to the SQL Server database for their parent site. Using default security, every administrator at every secondary site can manage not only his or her own site, but also any other secondary site that is a child of the same parent.

Figure 16-11. Sample site hierarchy model.

To remedy this situation, you can set security on each of the secondary site entries under the Site Hierarchy folder in the SMS Administrator Console so that only that site's administrator has access to that site's settings. In this way, you have preserved security for each site and can still maintain the desired site structure.