Previous Section
 < Day Day Up > 
Next Section


Permissions and Security Objects

In addition to the security provided by Windows and through SQL Server, SMS 2003 maintains its own object-level security for the SMS site database using the SMS Provider and WMI security. By assigning specific permissions to Windows 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'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 17.4. To view the object security of any SMS object, select the Security tab in the object's Properties dialog box.

Click To expand
Figure 17.4: The Security tab of the Collections Properties dialog box.

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 17.10 describes the available permissions and their object types.

Table 17.10: 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.

Delegate

All security object types except Status Messages

Grants rights (that have been explicitly assigned to a user) for any instances created by that user.

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 from a collection, such as a computer.

Distribute

Packages

Deploys a package to a distribution point.

Manage SQL Commands

Sites

Allows user to create and modify SQL commands through the SMS Administrator Console.

Manage Status Filters

Sites

Allows user to create and manage status filter rules through the SMS Administrator Console.

Meter

Sites

Allows user to apply software metering rules to a site.

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 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, as discussed in the section 'Custom SMS Administrator Consoles' later in this chapter. 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.

Assigning Permissions

You can assign permissions to an object in four ways: you can use the Security Rights node in the SMS Administrator Console to assign permissions to object classes and instances, you can assign permissions at the specific object class or instance, you can use the SMS User Wizard, or you can clone an existing user. Figure 17.5 shows the list of object classes and specific instances and their permissions that's displayed when you open the Security Rights node. Notice that you can see the default permission as well as specific instances created.

Click To expand
Figure 17.5: Permissions displayed in the Security Rights node.

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

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

  2. 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.

  3. If you choose Class Security Right, the Security Right Properties dialog box for the class is displayed, as shown in Figure 17.6.

    Click To expand
    Figure 17.6: The Security Right Properties dialog box 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.

  4. Choose OK to save your security configuration.

    Tip 

    You can modify any entry in the Security Rights node simply by double- clicking it to display its Properties dialog box. 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:

  1. In the SMS Administrator Console, navigate to the node whose class permissions you want to modify, right-click it, and choose Properties from the context menu to display the object's Properties dialog box. For this example, we'll select the Queries object to display the Queries Properties dialog box.

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

    Click To expand
    Figure 17.7: The Security tab of the Queries Properties dialog box.

  3. 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 dialog box, shown in Figure 17.8.

    Click To expand
    Figure 17.8: The Object Class Security Right Properties dialog box.

  4. Supply a user or group name and then 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 dialog box.

  5. 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 dialog box. Make the appropriate permission changes and then click OK.

  6. 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:

  1. 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 dialog box for that instance. For this example, we'll select an instance of the Queries object-Clients With Free Disk Space-to display the Clients With Free Disk Space Query Properties dialog box.

  2. Select the Security tab, shown in Figure 17.9. Notice the existing class and instance security permissions-SDK [No Permission] has 'trickled down' to this instance.

    Click To expand
    Figure 17.9: The Security tab of the Query Properties dialog box.

    In 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.

  3. 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 dialog box, shown in Figure 17.10.

    Click To expand
    Figure 17.10: The Object Instance Security Right Properties dialog box.

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

  5. Click OK again to save your configuration.

Figure 17.11 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.

Click To expand
Figure 17.11: Sample class and instance permissions.

You can use the SMS User Wizard to add a new user and assign class or instance permissions to that user, modify the permissions of an existing user, or copy the permissions of another user to an existing or new user. This wizard is intuitive to use, so I won't go into a lot of detail about running it.

Follow these steps to use the SMS User Wizard:

  1. In the SMS Administrator Console, right-click Security Rights, and from the context menu select All Tasks and then Manage SMS Users to display the Welcome page as shown in Figure 17.12.

    Click To expand
    Figure 17.12: SMS User Wizard Welcome page.

  2. Click next to display the User Name page shown in Figure 17.13. On this page you can choose to modify an existing user name or remove an existing user by selecting that user from the drop-down list, or you can add a new user by browsing among existing user names or typing in the new user. If you choose to remove a user, when you click Next, you'll go directly to the Finish page where you can click Finish and you're done. Otherwise, when you click Next, you'll be presented with the Rights page.

    Click To expand
    Figure 17.13: SMS User Wizard User Name page.

  3. On the Rights page, shown in Figure 17.14, if you select the option The Listed Rights Are Sufficient, you can simply click Next and you'll be taken to the Finish page. This option is a verification that nothing more needs to be done.

    Click To expand
    Figure 17.14: SMS User Wizard Rights page.

    If you select the option Add Another Right Or Modify an Existing One and click Next, the Add A Right page is displayed, as shown in Figure 17.15. Here you can select the class, instance, and permission you wish to assign and click Next to go back to the Rights page, verify that the listed rights are sufficient, and then click Next to go to the Finish page.

    Click To expand
    Figure 17.15: SMS User Wizard Add A Right page.

    If you select the option Copy Rights From An Existing SMS User Or User Group, the Copy Rights page is displayed, as shown in Figure 17.16.

    Click To expand
    Figure 17.16: SMS User Wizard Copy Rights page.

    Select the user you want to copy from the Source User drop-down list, select the permissions you want to copy, and then click Next to go back to the Rights page, verify that the listed rights are sufficient, and then click Next to go to the Finish page.

  4. When you get to the Finish page, review the information one more time and then click Finish.

Finally, you can copy the class and instance permissions of an existing user to another user. To do so, follow these steps:

  1. Navigate to the Security Rights node in the SMS Administrator Console and select it to display the list of all users and their permissions.

  2. Right-click the user whose class and instance permissions you want to copy and from the context menu select All Tasks and then Clone SMS User to display the Clone SMS User dialog box shown in Figure 17.17. Enter the name of the user you want to copy the permissions to. Select whether to copy the Class Security Rights or Instance Security Rights and then click OK.

    Click To expand
    Figure 17.17: Clone SMS User dialog box.



Previous Section
 < Day Day Up > 
Next Section