Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
Windows Server

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

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
1/16/2013 3:33:51 PM
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 1. To view the object security of any SMS object, select the Security tab in the object’s Properties dialog box.

Figure 1. The Security tab of the Collections 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.

Table 1. Object permissions
PermissionObject TypeDescription
AdministerAll security object typesAdministers all object classes, including assigning or modifying security rights.
AdvertiseCollectionsAdvertises existing programs to a collection.
CreateAll security object typesCreates an instance of an object type, such as a new query or collection.
DelegateAll security object types except Status MessagesGrants rights (that have been explicitly assigned to a user) for any instances created by that user.
DeleteAll security object types except Status MessagesDeletes an instance of an object type, such as a package or an advertisement.
Delete ResourceCollectionsDeletes a resource from a collection, such as a computer.
DistributePackagesDeploys a package to a distribution point.
Manage SQL CommandsSitesAllows user to create and modify SQL commands through the SMS Administrator Console.
Manage Status FiltersSitesAllows user to create and manage status filter rules through the SMS Administrator Console.
MeterSitesAllows user to apply software metering rules to a site.
ModifyAll security object types except Status MessagesMakes changes to an object, such as editing the query statement for a query.
Modify ResourceCollectionsModifies a resource in a collection.
ReadAll security object types except Status MessagesViews an instance and its properties.
Read ResourceCollectionsViews a resource in a collection.
Use Remote ToolsCollectionsInitiates a Remote Tools session with a client in a collection.
View Collected FilesCollectionsViews 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. 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.

Other -----------------
- Microsoft Systems Management Server 2003 : Security - Accounts and Groups
- Windows Server 2003 on HP ProLiant Servers : Assessment of the Enterprise - Conducting the Assessment
- Windows Server 2003 on HP ProLiant Servers : Assessment of the Enterprise - The Assessment Team
- Windows Small Business Server 2011 : Disaster Planning - Preparing for a Disaster, Restoring from Backup
- Windows Small Business Server 2011 : Disaster Planning - Planning for Disaster
- SQL Server 2008 : Security - Networking
- SQL Server 2008 : Security - Authentication mode
- Microsoft Dynamic GP 2010 : Providing clean vendor information by properly closing Purchase Orders, Protecting against information loss by printing Fixed Asset Reports
- Microsoft Dynamic GP 2010 : Protecting Dynamics GP with key security settings
- Working with the Windows Home Server Registry : Finding Registry Entries
Top 10
Windows Vista
Windows 7
Windows Azure
Windows Server