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

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 4. Note the existing class-level security permissions.

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

| 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 6. Notice the existing class and instance security permissions—SDK [No Permission] has “trickled down” to this instance.

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

| 4. | Supply a user or group name, select the appropriate permissions, and then click OK.
| 5. | Click OK again to save your configuration.
|
Figure 8
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.

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

| 2. | Click next to display the User Name page shown in Figure 10.
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.

| 3. | On the Rights page, shown in Figure 11,
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.

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

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

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

|
Consider the SMS site hierarchy illustrated in Figure 15.
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’s a child of the same parent.

To
remedy this situation, you can set security on each of the secondary
site entries under the Site Hierarchy node 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. |
|