SMS Object Security

SMS generally relies on other technologies to enforce security. For example, SMS sets security on file shares and then relies on the operating system to authenticate accounts and allow only correct accounts to access the shares. The only way that SMS itself enforces security is when you access an SMS object through the SMS Provider. The SMS Provider compares the user who is attempting to access the SMS object to the SMS security permissions on that SMS object, to determine if the user has the right to access or change the objects. The SMS Provider enforces SMS object security when you access SMS objects through the SMS Administrator console or through a program that access SMS through WMI.

You can grant permissions on an SMS object to a single user or to user groups within a domain. For example, you can specify that all members of the Domain Users group can edit packages. You can specify that specific users can edit only the packages that they create. You can allow an administrator to manage all collections or just one. For each security object or object type, you can grant a number of different permissions. This granularity gives you great control over who can access SMS object types and who can access specific information in the SMS site database.

You can set object security on the seven SMS object classes listed in Table 5.9.

Table 5.9 SMS Classes for Granting Security Rights

You can configure security for SMS object types at either the class level or the instance level:

Class level

This level grants users permissions for all object types in a specific class - for example, all packages or all collections.

Instance level

This level grants permissions for a specific instance of an object type, such as the "All Windows 98 Systems" collection or a "New York City Site" collection. Because status messages are very numerous, they do not have instance-level rights.

In both cases, you grant or deny permissions on a per-user or user group basis.

For example, the class-level Read right on collections allows you to see all the collections (and the members of each collection). The instance-level Read right on one particular collection allows you to see that collection (and its members). However, you can not see any resources in any other collection.

SMS object permissions are cumulative. For example, if a user has the Read right on one collection (for example, "All Systems"), and the Use Remote Tools right on another collection ("Collection A"), then the user has the Read and Use Remote Tools rights on all systems that are members of both collections. The user can view a resource in the "All Systems" collection and use Remote Tools with that resource if that resource is also in the "Collection A" collection. If the resource is not in the "Collection A" collection, then the user cannot use Remote Tools with that resource. The fact that the user does not have the Remote Tools right in the "All Systems" collection does not mean that they are denied use of Remote Tools to all computers in the "All Systems" collection. The user is only denied use of Remote Tools to computers in the "All Systems" collection that do not have the Use Remote Tools right in any other collection that includes that computer.

Because SMS rights are cumulative, if you grant a user class security rights to an SMS security object and conflicting instance security rights to a specific SMS security object, SMS reconciles the class and instance security rights to grant the highest level of permissions. The exception to this rule is no permissions. For example, if you grant the user full permissions to all packages at the class level and Read permission to a specific package at the instance level, the user's effective permissions are full permissions to all packages including that one specific package set with read permission. If you grant the user full permissions to all packages at the class level and no permissions to a specific package at the instance level, the user's effective permissions are full permissions to all packages except the one specific package set with no permissions. Similarly, if you grant a user no permissions to all packages at the class level, and full permissions to a specific package at the instance level, the user's effective permissions are no permissions to any packages except the one specific package set with full permissions.

By default, only two accounts are granted permissions to all objects in the SMS Administrator console:

• The local system account ("NT Authority/System").

• The user account that was logged on when SMS Setup was run to set up the primary site.

You must explicitly add other accounts and grant them permissions to SMS objects. Without permissions, users who can launch the SMS Administrator console can only see the high-level nodes in the SMS Administrator console, along with the Security Rights, Online Library, and Tools. Users cannot see any data other than the Security Rights, and they cannot manipulate the Security Rights.

When granting permissions to accounts, you can grant permissions to users, local groups, global groups, universal groups, and nested global groups. However, all accounts that have SMS object security rights must also have access to the SMS WMI namespaces. You can do this by putting the accounts in the SMS Admins local group

For More Information

Did you find this information useful? Please send your suggestions and comments about the documentation to smsdocs@microsoft.com.