The SMS databases are protected through NTFS permissions, SQL Server security, MMC custom snap-ins, and the WBEM/SMS Provider interface. The WBEM/SMS Provider interface controls both initial access to the SMS Administrator console and access to objects (either entire classes of objects or object instances within the MMC).
NTFS permissions to the SMS partition on the site server restricts access to SMS Administrator console files to members of the local Administrators group. Granting other accounts permissions to the files required to run the SMS Administrator console is accomplished by configuring NTFS permissions or by running the SMS installation routine to install the SMS Administrator console on a Windows NT/2000 computer. Even if a user installs the SMS Administrator console, access is not guaranteed. No logon screen will appear to the user. Instead the WBEM/SMS Provider interface determines whether SMS object access should be allowed or denied to the currently logged-on user.
When the SMS Administrator console is started, it verifies that the currently logged-on user is allowed to access the WBEM namespace. The WBEM namespace is a repository of management data used by WBEM-enabled applications, like the SMS Administrator console. By default, SMS assigns the SMS Admins local group (created during SMS installation) with administrative rights to access the WBEM namespace. Once access is granted to the namespace, the SMS Provider determines whether a group or user is allowed to access the objects in the site database. This access is restricted, by default, to members of the local SMS Admins group. This group initially contains only the user who installed SMS. Other accounts are granted permission to the WBEM namespace and the SMS Provider by adding them to the SMS Admins local group or adding groups or users to the WBEM namespace and granting them the Write Instance schema access level and Execute Methods attribute. The WBEMPERM.EXE application is used to grant users and groups permissions to the WBEM namespace. This application is installed on site systems in the windir\SYSTEM32\WBEM directory. For more information on WBEMPERM and the WBEM schema, see the SMS 2.0 ToolKit.
Once access is granted by WBEM, permissions to site database objects are controlled by the SMS Provider. By default, the local administrators account and the user account used to install SMS on the site server have access to administer objects in the site database. Note that only the user account used to install SMS appears in the SMS Admins group. Granting other accounts permissions to an object, whether an entire object class or an object instance, is completed from the Security Rights node in the SMS Administrator console or by accessing the Security tab of the object. Figure 12-2 shows the security components that a user must authenticate before being granted access to data in the site database.
Figure 12-2. Security components in SMS 2.0.
For additional information on Windows Management, double-click the \CHAPT12\ARTICLES\WBEM PRESENTATION FILES\PRES.PPZ file on the SMS Supplemental Course CD-ROM to watch a series of PowerPoint presentations on Windows Management. If your computer is unable to play the PRES.PPZ file, double-click SURGE.EXE in the same directory to install the PowerPoint Animation Player. After the animation player is installed, double-click the PRES.PPZ file.
Object access in the SMS Administrator console is granted to Windows NT/2000 users or groups. Only the local Administrator account and the user account used to install the site server are granted specific permissions by default. All other users or groups must be specifically added. New accounts are added from the Security Rights node in the SMS console tree, as shown in Figure 12-3.
Figure 12-3. Adding users to manage SMS objects.
Users and groups added using the Security Rights node are assigned additional Class and Instance security rights either from the Security Rights node or directly from an object class or object instance. Both methods are shown in Figure 12-4.
Figure 12-4. Granting an object class right to a user through the Security Rights node and through the properties of an object.
Figure 12-4 shows two methods for configuring object class security. Similar procedures are used to configure object instance security. To set object instance security, select a specific instance of a class, such as a query shown in the details pane of the Queries node. To configure object instance security, configure security on the Queries node itself. When you select an object instance, you are able to set both object class and object instance security; this is illustrated in Figure 12-5.
Figure 12-5. Configuring object class security or object instance security from an object instance.
Object class security provides a user with access to all instances of a specific class. For example, creating a class security right for the Collection class gives users access to all collections. An Instance security right is applied to a specific instance in the class, for example, to the All Windows 95 Systems collection.
Security rights can be assigned to the following object classes:
The specific permissions that can be assigned to objects vary with the type of object. Generally, there are permissions of Administer, Create, Delete, Modify, and Read. For collections, the Advertise and Remote Tools rights are available; for packages, the Distribute right is available.
Only the local system account and the user who installed SMS have permissions to configure security for the SMS objects. Other users may be granted the Administer object permission so that they can configure object security. This permission may be assigned to an object class or an object instance. At least one user account must be assigned the administer permission to an object. Therefore, if only one user is assigned this permission to an object, the user's Administer object permission cannot be removed without first assigning another user the Administer permission to the object.
The SMS Administrator console is an MMC snap-in. It is possible to create custom consoles that only present specific objects in the console. The custom console file is saved and made available to users as a means of restricting the objects they see and execute. For example, if the organization has multiple administrators who are responsible for various aspects of maintaining and administering SMS, a custom console can be created for each specific purpose. This allows the various administrators to perform their work without giving them access to resources they do not require. To create a custom console you must start the MMC with the following command line:
Consider an administrator whose only function is to create SMS packages for distribution. A custom MMC console could be created that only presents the Packages node. The administrator could then create packages, configure programs, and assign distribution points, but not advertise the program to any collections or perform any additional SMS administrative functions. The Packages snap-in is shown in Figure 12-6.
Figure 12-6. The packages custom snap-in.
While using custom snap-ins alone is not as secure as setting object security rights, it is a simple way to create task-specific views of SMS.
For more information on creating a custom snap-in, refer to the MMC online documentation and watch the custom console creation demonstration MMC.AVI, in \CHAPT12\DEMOS\.
This demonstration requires 800 x 600 resolution with 256 colors. Run it at a zoom setting of 100%.
The user still requires SMS security rights assigned to the objects in the custom console, or the objects will not appear.