Using SMS Object Security to Control the Use of SMS 2.0 Features

On This Page

Abstract
Introduction
What This Technical Paper Covers
Collection Security
Using Collection Security for Advertising
Package Security and Advertisement Security
Examples of Using SMS Object Security
Scripting SMS Object Security
Summary
For More Information

Abstract

This paper presents a systematic approach to using SMS Object Security on packages, advertisements, and collections to control SMS features, such as software advertising, the use of inventory details, and the use of remote tools.

Introduction

Systems Management Server (SMS) includes several features that can be used by your computer administrators to manage computers. These features include software distribution, inventory collection and viewing, and remote tools (such as remote control). Each of these features is very powerful, but as with any powerful feature, it must be controlled to ensure that it is not used inappropriately. SMS Object Security allows you to control SMS features.

Software distribution is a powerful feature that can help your organization solve one of your most fundamental computer management problems – installing and maintaining software. However, software advertising must be controlled in order to ensure that software is not advertised to the wrong computers, at the wrong times, or without proper configuration and testing. SMS Object Security allows you to control software distribution using collection rights, package rights, and advertisement rights.

Viewing collected inventory details and using remote tools are controlled using collection rights alone.

Note: This paper describes some of the SMS Object Security features, but other elements of SMS security can also affect the use of SMS features, as discussed in the SMS Security Essentials technical paper. The SMS Security Essentials paper is available at https://www.microsoft.com/smserver/default.mspx

What This Technical Paper Covers

This paper starts with a review of the SMS Object Security concepts and then gives some examples of how SMS Object Security can be utilized to manage how SMS features are used. The paper concludes with some sample scripts for managing SMS features in special circumstances.

The information in this paper applies to SMS 2.0 Service Pack 2 (SP2) without any product updates (sometimes called "hot fixes").

Note: This paper does not discuss the specific steps required to apply SMS Object Security. That subject is included in the SMS Administrator's Guide and SMS online Help. This paper also does not discuss object security as it applies to status messages, sites, and queries.

Collection Security

Collection security can be utilized to control how collections are used for software advertising and other purposes, as well as for controlling how resources (such as computer systems) are viewed and used.

Collection Rights

Collection security is based on SMS object rights applied to collections. The rights control what you can do with the collections and the resources that are members of the collections. Resources are computer systems, users, or user groups.

Collection rights are either class-level rights or instance-level rights. Class-level rights apply to all instances (all collections, in this case). Instance-level rights are unique to the instance (collection) itself. Instance-level rights supplement class-level rights. For example, if you only have the Read instance right for a collection, but you have the Read Resource right for the Collections class, then you will be able to view the inventory details for resources in that collection.

Changes to collection rights are immediately effective. They are enforced by the SMS Provider, which compares all operations to the granted rights at the time of the operation. Therefore, the administrator does not have to log out for the changes to become effective. Changes to rights might not appear to be immediately effective in the context sensitive menus, but the SMS Provider immediately enforces them, and a refresh of the appropriate node in the console will update the menu appropriately.

The collection rights are listed in the following table.

Table 1 Collection Rights

Note: All rights except Administer and Create require the Read right as well.

• Collection properties are:

• Collection name

• Comment

• Membership rules – direct or query

• Update schedule

Each collection can have instance security, but this security is not a property of the collection itself.

Additional Collection-Related Tasks

There are additional collection-related tasks beyond those implied by the collection rights:

• Linking one collection to another. Any collection can be linked to any other collection at any time. Collection linking is only done to ease the updating of collections, to increase the target of advertisements, and to reflect organizational relationships. It does not impose any restrictions on the collections. You can link a collection to any collection that you can read. You must have the Modify right for the collection that you are linking to. If you have a collection selected when you create a new collection, then the new collection automatically linked to the selected collection.

• Limiting one collection to another. This is done when defining rules. You can limit any collection so that it only uses the members of another collection that you can read. If you do not have the class-level collection Read right, then you must limit collections to other collections.

• Updating collection membership. You can update the collection membership of any collection (and its subcollections) that you can read.

• Using the Distribute Software Wizard. You can use the Distribute Software Wizard if you have Read, Create, and Distribute rights for the Package class; Read and Create rights for the Advertisement class; and Read, Create, and Advertise rights for the Collections class. If you don't have all these rights, or if you only have equivalent rights at the instance level, then you must use the manual equivalents for those tasks that you are authorized for. For example, if you are authorized to advertise to a particular collection, then you must create the advertisement for the collection from the context-sensitive menu available when the Advertisements node is selected.

• Showing the count of collection members. You can show the count of collection members for any collection that you can read.

Inheritance of Rights

Collections can be created in several different ways. The rights that apply to the new collections vary depending on how the collections are created.

From Parent Sites

Collections created at parent sites are automatically propagated to child sites. The properties of these collections, except security, are determined at the parent site and cannot be modified at the child sites. Because security is not propagated from the parent, collections from the parent automatically have the Collections class rights applied to them but they won't have any instance-level rights until an authorized SMS administrator manually adds them.

Note: For collections that are propagated from parent sites, instance-level rights can only be granted in the Security Rights node of the SMS Administrator console, not from the Security tab of the collection's properties. The rights can be modified from the Security tab, however.

New Collections

All new collections are automatically given Read, Modify, and Delete rights for the administrator who creates the collection. This is true no matter what class or instance-level rights the administrator has. Note that the administrator does not get the Advertise right by default.

From Other Collections

Collections do not inherit rights from other collections even if they have rules that are based on other collections or if the collections are linked. However, if the administrator has rights to certain resources in one collection, then those rights can be used when using the resources from another collection. The fact that the administrator is not granted the rights to those resources in the current collection does not cause the rights to be denied. This is true for the following rights:

• Delete Resource

• Read Resource

• Use Remote Tools

• View Collected Files

Using Groups

You can use either Windows NT accounts or groups when granting SMS class and instance security rights. The accounts or groups can be local or domain accounts or groups.

Auditing Collection Security Changes

In order to keep track of collection security changes, you can use the collection-related status message queries. These include:

• Collection Member Resources Manually Deleted

• Collections Created, Modified, or Deleted

These queries can be used as the basis for more specific queries if you have other auditing requirements.

Using Collection Security to Limit Control of Clients

As discussed in this section, collection security can be used to limit which administrators can control specific computers. Through appropriate design of high-level collections and appropriate assignment of collection rights, administrators can be restricted so that they cannot create new collections that include client computers that they have not been authorized to manage. The administrators are also not able to extend their own rights in order to try to manage those computers.

These restrictions ensure that administrators cannot view the basic properties of the computers (such as computer name) or the full details of the computers (as returned by SMS hardware and software inventory, including collected files). They also are not able to advertise software to those computers or remote control them.

However, even with these restrictions, the administrators are still able to manage the computers they are authorized to manage. They are even able to create new subcollections of those computers in order to efficiently manage them in logical groupings.

Using Collection Security for Advertising

Several special topics apply to collection security:

• Collection security can be used in a variety of scenarios.

• Special strategies can be applied to using collection security for advertising.

• Collections can be limited by other collections.

• There are some limitations that apply to collection security.

Scenarios

The scenarios in which you might want to control SMS software advertising include:

• Targeting programs to any collection. You want to be able to advertise to any collection

• This is the default behavior for SMS. It requires class-level Advertise and Read rights for collections.

• Targeting programs to collections that you create. You want to be able to advertise software to collections you create but not to other collections. Also, you don't want other people to be able to advertise software to your collections.

• This is the default behavior for SMS if you and your fellow SMS administrators only have instance-level rights (as well as the class-level Create right). However, as you create new collections you will not automatically be assigned the Advertise right. Therefore, you should be given the class-level Advertise right as well, in order to avoid having to request the instance-level Advertise right for your new collections. Without Read rights to the other collections you still can't advertise to them.

• Targeting programs to specific collections created by a more senior administrator. You want to be able to advertise software to the collections, but you don't want to be able to change any of the characteristics of the collection (including security) or be able to create your own collections.

• In this case you must have the Read and Advertise rights for instances but not the Modify or Delete rights. You might optionally have the class-level Advertise right instead of the instance-level Advertise right. The senior administrator assigns these rights when he or she creates the collections.

• Targeting programs to collections created by a peer administrator. You want to be able to advertise software to collections that are created by your peer SMS administrators (who have the same level of rights that you have). You might or might not be able to change the collections; this is at the discretion of the person who created the collection. You do not want to be able to use collections not created by you or your peer administrators.

• In this case, you might have the class-level Advertise right but your peer must have the class-level Administer right in order to give you the instance-level Read right on the collection (and the instance-level Advertise right if you need it). If it is not acceptable for your peer to have the Administer right, then you can use one of the strategies outlined in the next section.

Strategies for Sharing Collections by Limited Rights Administrators

You might be in a situation where you have junior SMS administrators who have no class-level rights except to be able to create collections, but they want to share collections they create with their peers. Without the Administer right they can't add rights for their peers to the collections that they have created. However, you might be hesitant to grant them the Administer right because they could then give themselves the class Read right and thus manage collections they are not authorized to manage.

The following strategies could be used in this situation:

• Have a senior administrator grant Read rights. When a collection is created, the junior administrator can ask a senior administrator to grant Read rights to his peers. This is especially appropriate if the list of collections is fairly stable.

• Trust and audit. In this case, the junior administrators are given the Administer right, but you can routinely review a report of the use of collections. If a collection is used by an unauthorized administrator, then appropriate actions can be taken.

• Use a shared account. The junior administrators could all access SMS through a shared account. Thus, they could all see any collection created using that account. This accomplishes the goal of sharing collections, but it means that there would not be any accountability.

• Use equivalent collections. When an administrator creates a collection, he would document what he did to create it, and then his peers could follow the directions to create equivalent collections. This does not accomplish the goal of sharing collections, but the administrators are managing the same resources.

• Do not share collections. This does not accomplish the goal of sharing collections, but it might be acceptable if you can afford to wait for the creator of each collection to become available to manage the resources in that collection. For those times when you cannot afford to wait, a senior SMS administrator could intervene.

• Export and import collection definitions. When a collection is created the junior administrator would export its definition to a file that peer administrators can access. The peer administrators can them import the file and create equivalent collections. This can be done using WMI tools such as CIM Studio or by using the SMS Site Properties Manager tool. However, this solution is awkward and requires manipulation of the export file.

  Note: the SMS Site Properties Manager tool is included in the Microsoft BackOffice 4.5 Resource Kit. The Microsoft BackOffice 4.5 Resource Kit tools are also included with the SMS Resource Guide when purchased separately.

• Compartmentalize responsibilities. In this case, the people who create advertisements would be different from the people who create collections. This does not eliminate the need to have the class-level Administer right, but it ensures that collection creators cannot advertise to inappropriate collections.

• Scripting. The addition of collection Read rights for the appropriate staff could be done in a script. This would ease the work of the senior administrator. Or, the script could be set up as a routine task to be run on the site server so that no human intervention is required. For more details, see the "Scripting SMS Object Security" section later in this paper.

Collection Limiting

If you do not have the class-level collection Read right, then any collections you create must include rules based on collections you can read (by virtue of having the class-level Read right or instance-level Read right on those collections). If the rules are direct rules and you want to browse for collections to base them on, then you must have the Read Resource right at the class level or instance level. However, if you only have the Read right, then you can type the name of the collection.

Note: Although collections might have to be limited to other collections, they do not have to be linked to those (or any other) collections. Linking is optional.

Limitations to Collection Security

SMS 2.0 SP2 has two limitations based on its implication of collection security:

• When a new collection is created, only the administrator who created the collection is granted the Read right. The administrator can grant the right to read the collection to other administrators only if those administrators have the class-level Administer right.

• Administrators must be able to read a collection in order to be able to advertise to it. Therefore, SMS administrators can see which resources are in a collection if they are allowed to advertise to the collection.

Package Security and Advertisement Security

Package security and advertisement security can be used to control how packages and advertisements are used for software advertising. Package security and advertisement security behave in almost exactly the same way as each other, so they are discussed together in this paper. The only difference between package security and advertisement security is that packages can also have the Distribute right, which allows you to distribute them to SMS distribution points.

Package security and advertisement security are also very similar to collection security, since they are all based on SMS Object Security. Many of the same concepts apply to all three. However, collection security is unique in that it also incorporates resource-oriented concepts.

Package security allows you to manage packages, including programs. Packages define which software can be advertised using SMS.

Advertisement security allows you to manage advertisements. Advertisements are the instructions to SMS as to which collections should be targeted by the programs of your packages.

Package and Advertisement Rights

Package and advertisement security are based on SMS object rights applied to packages and advertisements, respectively. The rights control what you can do with the packages and advertisements.

As with collection rights, there are class-level and instance-level package and advertisement rights. Also like collection rights, changes to package and advertisement rights are effective immediately.

The package and advertisements rights are listed in the following table.

Table 2 Package and Advertisement Rights

Note: All rights except Administer and Create require the Read right as well.

Using Package and Advertisement Rights

Package and advertisement rights are used in much the same way as collection rights. Package definitions and advertisements are propagated from parent sites, but security rights are not propagated with them. Thus, the packages and advertisements will have the class-level rights at the child site applied to them. When packages and advertisements are created, the administrator who created them is given the Delete, Modify, and Read rights. In the case of packages, the administrator is also given the Distribute right.

Note: Package contents are not propagated from parent sites to child sites. The contents (files) are distributed only to the distribution points (and their sites) that are designated by authorized SMS administrators.

Windows NT groups can also be used when assigning rights for packages and advertisements. Status message queries are available to audit changes to advertisements and packages.

The same strategies that limited-rights administrators use for collections can also be used for packages and advertisements.

Examples of Using SMS Object Security

The following examples should clarify how the SMS Object Security can be used to control the use of SMS features in organizations with security concerns.

Example 1 – Multiple Groups at a Site

Consider a scenario in which your company has a location in New York City where you manufacture recreational products. One business group, called "Wings," manufactures hang gliders, glider planes, ultra-light planes, and similar vehicles. Another business group, called "Safety," manufactures parachutes, pressurized suits, life jackets, safety nets, and similar devices. As part of the corporate services, you are in the Management Information Services (MIS) department. The building has one LAN and one SMS site server. You manage the site server and the non-business unit computers, but in order to better serve their own business requirements, each of the business groups has their own technical support specialists to manage their computers. They use your site server as their primary tool for computer management.

When computers are set up they are given computer names that start with the letters W, S, or M, corresponding to the Wings, Safety, or MIS group. You have created a Wings collection that is based on a query that includes all computers with a computer name that starts with "W." You have also created a Safety collection and an MIS collection.

You are the only SMS administrator that has full class-level collection, package, and advertisement rights. The appropriate staff for the Wings and Safety groups have full rights on their respective collections. They also have collection, package, and advertisement Create rights.

To ensure accountability for the computer management functions, both of the business groups don't want the other group to be able to use the collections for their resources. Therefore, when you created the Wings, Safety and MIS collections, you gave instance Read rights only to Windows NT user groups that contain the respective Wings, Safety, and MIS technical support staff. All of the computer administrators have class-level collection Create rights and instance-level Advertise rights for their collections, but since they can only read the collection for their computers, they can only create and use new collections based on collections for their own computers. Thus, for example, the Wings administrators can be confident that the Safety and MIS staff cannot distribute software, remote control, or even view the properties of the Wings computers. The only exception is that you, as the senior SMS administrator, have the class-level Administer right and can therefore manage collections for any of the groups.

The problem is that each of the groups has multiple technical support specialists who share responsibilities. Therefore, they would like to be able to share the collections within their own group. However, when an administrator creates a collection, only he or she has rights to the collection.

Each of the groups could request that you grant the group rights to the new collections, but the groups use collections creatively and aggressively. Therefore, these requests would consume a lot of your time, and are dependent upon you always being available.

As a solution, you set up a script to run on your site server, based on the script listed in the "Scripting SMS Object Security" section later in this paper. You give each of the groups a secret value to be put into the descriptions of the new collections they create. Your script looks for that value and creates rights for the appropriate group depending on which value it finds. Since the groups can't read each other's collections, they can't discover each other's secret values.

To automate the execution of the script, you set the Task Scheduler on the site server (which is running Windows NT Server 4.0) to start automatically and to run with an account whose only privileges are to be able to connect to SMS and have the collection Administer and Read rights. You then submit the script using the AT command as CSCRIPT scriptname.VBS

Note: Windows Script Host (WSH) must be installed on the computer. WSH is available at https://www.microsoft.com/downloads/details.aspx?FamilyID=c717d943-7e4b-4622-86eb-95a22b832caa&DisplayLang=en.

WSH is included in Windows 2000.

Example 2 – Multiple Groups at Multiple Sites

Your company has outgrown its facility in New York City, so the corporate services staff, including the MIS staff, has moved into the Empire State Building. You have set up a new site server in the Empire State Building, and your old site server reports to it.

The business environment is still largely the same as in example 1, but now any collections that you create at the central site are automatically propagated to the child site. However, the security rights are not propagated, and the administrators at the child site don't have class-level rights.

Fortunately, you don't create collections very often, because the business units do most of this work. Therefore, you choose to manually maintain the security on the collections. You simply have to remember to connect to the child site after the new collections propagate, and then add the Windows NT group for the business unit technical staff as appropriate.

Scripting SMS Object Security

Using a script can be an effective means to adapt SMS Object Security to the requirements of special situations. By using scripting, routine tasks can be simplified so that they are more acceptable. More importantly, they can be set up as an automated task so that human intervention is not required.

The following script can be run on the site server to ensure that all collections can be read by anyone in your junior SMS administrators Windows NT domain group.

Note: You must change the first two lines to reflect the values that are appropriate for your site. Also, wrapped lines might have to be unwrapped.

sitecode="B2K"
SMSJuniorAdmins="BEIGE\SMS Junior Admins"
Dim lLocator
Set lLocator = CreateObject("WbemScripting.SWbemLocator")
Dim WbemServices
Set WbemServices = lLocator.ConnectServer( , "root\sms\site_" & 	 sitecode)
'work through the list of collections
Dim Collection
Dim Collections
Dim Right
Dim Rights
Dim AlreadySet
Dim newRight
Set Collections = WbemServices.ExecQuery("Select * From SMS_Collection")
For Each Collection In Collections
    'ignore this special collection
    If Collection.CollectionID <> "COLLROOT" Then  
       Wscript.Echo Collection.Name & "  " &  Collection.CollectionID
       AlreadySet = False
       Set Rights = WbemServices.ExecQuery("Select * From SMS_UserInstancePermissionNames WHERE ObjectKey=1 AND InstanceKey='" & Collection.CollectionID & "'")
       For Each Right in Rights
           Wscript.Echo "         " & Right.Username & "  " &  Right.PermissionName
    If Right.Username = SMSJuniorAdmins Then 	 	 	 	 	 AlreadySet=True
       Next
       If Not AlreadySet Then
          Set newRight = WbemServices.Get("SMS_UserInstancePermissions").SpawnInstance_()
          newRight.UserName = SMSJuniorAdmins
          newRight.ObjectKey = 1 'collections
          newRight.InstanceKey = Collection.CollectionID
          newRight.InstancePermissions = 1+2 'just Read & Modify
          newRight.Put_
       End If
    End If
Next

The InstancePermissions should be set to the sum of the following values for the rights you want to grant.

Table 3 Rights and Values for Instance Permissions

The script can be easily adjusted to assign different groups to each collection based on a collection naming convention, the name of person who created the collection (and who therefore already has instance rights for it), etc.

If you want to adjust the script so that it adds the Windows NT groups that the person who created the collection is a member of, then you will need to enumerate those groups. This can be done using the following section of a script. This can be useful if you have a fairly large number of junior SMS administrators and they are in various Windows NT groups.

Dim oUser
Dim GroupObj
Set oUser=GetObject("WinNT://BEIGE/Administrator")
For Each GroupObj in oUser.Groups
 WScript.Echo GroupObj.Name
Next

This code depends on Active Directory Service Interfaces (ADSI) 2.5 being available on the computer that the script is run on. This is true for all Windows 2000 computers, but for other Windows computers ADSI 2.5 must be installed. This can be done using the files from this location:

https://www.microsoft.com/ntserver/nts/downloads/other/ADSI25/default.asp

Summary

SMS Object Security is very flexible. By understanding the significance of rights, how they are assigned, and how they can be used, you can use SMS Object Security to effectively manage the use of SMS features.

When appropriate, a little creativity with SMS scripting can allow you to automate SMS Object Security to handle special requirements.

For More Information

For more information about SMS, visit our Web site at https://www.microsoft.com/smserver/default.mspx

For additional information about SMS security, see the SMS Security Essentials technical paper at https://www.microsoft.com/smsmgmt/techdetails/secessentials.asp

For additional information about SMS software distribution, see the SMS Administrator's Guide. The SMS Administrator's Guide is included in electronic form with SMS, and can be ordered in paper form using these instructions:

• If you obtained SMS through the Select or Open program, you can order copies of the SMS 2.0 Administrator's Guide by calling Microsoft World Wide Fulfillment at 1-800-248-0655. Use part number 271-00617.

• If you did not get SMS through the Select or Open programs, you can call Microsoft Supplemental and Replacement Parts, at 1-800-360-7561 and request the SMS 2.0 Administrator's Guide, Part No. 271-00617.

For introductory, tutorial, and reference information on Windows scripting, see https://msdn.microsoft.com/scripting/

For peer assistance on Windows scripting issues see the following newsgroups on msnews.microsoft.com

• microsoft.public.scripting.wsh

• microsoft.public.scripting.vbscript

For more information about scripting SMS operations, and for the SMS software development kit (SDK) itself, see https://msdn.microsoft.com/downloads/

For more information about Windows Management Instrumentation (WMI), and for the WMI SDK itself, see https://msdn.microsoft.com/library/en-us/wmisdk/wmi/wmi_start_page.asp