Chapter 4 - Creating Your SMS Security Strategy

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Security issues underlie virtually all aspects of network operation and affect the design and implementation of your Systems Management Server (SMS) version 2.0 site hierarchy. The potential risk to the integrity and security of information in your site make it essential to develop a security strategy—before you install SMS. Because greater security often requires more administration, you will want to balance the two.

Chapter 3, "Planning for SMS in Your Organization," introduced a process designed to help you plan a successful SMS implementation. This chapter discusses in detail the concepts and planning considerations you need to know to protect your organization's network and data. The information provided in this chapter will help you plan the types and levels of security you need to implement in your SMS sites.

Although the SMS 2.0 security system is sophisticated, the basic concept is straightforward as described in the following sections:

• Identifying Security Needs

• SMS Security Overview

• Using Windows NT File and Directory Security

• Understanding SMS System Accounts

• Understanding SMS Administrator Console Security

• Ensuring SMS Site Database Security

• Addressing Feature-Specific Security Issues

• Deciding on a Security Model

Identifying Security Needs

Addressing a topic as complex and important to your organization as network security is a daunting task. This chapter attempts to identify basic security issues that apply to all networks and addresses the compromises you must consider to develop a security system appropriate for your organization.

Security Issues

There are several issues you need to consider when you think about the security of your SMS system:

Access Control 

Who can access the SMS files on your system, the software distribution files you need to expose, and the inventory information and collected files on your site servers?

Authentication 

Who is allowed to use the SMS tools to monitor your network and possibly control your clients?

Database Security 

Who is allowed to view and change database objects?

Necessary Security Exposures 

You may also need to be aware of special situations, such as unattended software distributions, where you need to assign special administrator rights to minimize the security risk.

Security Compromises

When you assign security for your site, you want to maximize security as much as you can. A secure environment requires more administration than a less secure system. For example, allowing each administrator access to only a single collection requires more administration than allowing everyone full control to all objects in the SMS Administrator console. Throughout the process of reading this chapter and planning your security strategy, keep in mind that higher levels of security require more administration. Then, set up the security system that is most appropriate for your users and administrators.

Achieving the most secure SMS installation requires that you do the following:

• Give users only the minimum rights they require to directories, files, and SMS database objects, and the information they can access through the SMS Administrator console.

• Give service accounts only the SMS rights they require to perform their tasks. In general, minimize what the service account can do by keeping the permissions as close as possible to the local level.

• Give administrators the minimum permissions they need to do their jobs. If an administrator works only with a subset of the users on your system, create a collection of these users and give the administrator SMS permissions to that collection only.

• Unless it is absolutely necessary for an administrator to work directly on the site server, have administrators use remote consoles on Windows NT computers other than the site server. As a result, they will not require local administrator rights on the site server.

• Install the SMS site on a Windows NT member server, not a Windows NT domain controller.

Note For many security decision points, the SMS default is the minimum-security option. If you need a higher level of security at your site, you must configure it directly.

SMS Security Overview

Security in SMS 2.0 site hierarchies is designed to control access to objects in the SMS site database through the SMS Administrator console and to provide access to read and write information as needed for network administration, communication, and software distribution.

The information that SMS objects use resides in the SMS site database. However, access to these objects through the SMS Administrator console is controlled by WBEM through the SMS Provider.

The SMS Provider enforces a security model that creates SMS security objects (for example, Packages, Collections, Advertisements, Queries, Sites, and Status Messages) and creates specific SMS security rights. SMS security objects are objects in the SMS site database that have security rights administered through the SMS Administrator console. Users and user groups are granted specific SMS rights to SMS security objects.

Windows NT user and user group accounts are used to control access to the SMS security objects. SMS also includes SQL-level security; and as a consequence, direct access to an SMS site database is much more tightly controlled than in previous versions of SMS.

 

Figure 4.1 Security layers when SQL Server is installed on the site server 

Security for SMS site hierarchies consists of three layers:

• Windows NT

• WBEM/SMS Provider

• SQL database

Windows NT Security

The top layer of security for SMS installations is access control to files and directories. Windows NT file system (NTFS) security provides this control. Access control lists (ACLs), maintained by the Windows NT security architecture, protect directories and files from user accounts that are denied access.

SMS uses several Windows NT and NetWare user accounts that take advantage of the Windows NT security functionality. These System accounts are used to perform unique tasks in the SMS site. User accounts and user groups can be used to grant SMS administrators only the rights required for the administrators to perform necessary tasks in the SMS Administrator console. For more information, see "Configuring Client Connection Accounts" in Chapter 8, "Configuring SMS Sites."

WBEM Security/SMS Provider

WBEM security through the SMS Provider is the second layer of security for the SMS system. To gain access to SMS security objects through the SMS Provider, users must log on to the WBEM namespace.

This security layer also includes control of the SMS Administrator console objects that WBEM provides through the SMS Provider. SMS security objects are created for the SMS site database. SMS-specific security rights must be granted to user accounts or user groups if they are to modify (or even see) the objects in the SMS Administrator console. You can grant users security rights to SMS security objects as a class (such as Read rights to collections), or you can grant rights to specific instances of an object (such as Administer rights on a specific collection).

Several classes of the SMS Provider schema are described in "Attribute Classes (SMS Provider/WBEM Classes) for the System Resource Object Type (SMS_G_System)" in Appendix E, "Attributes, Attribute Classes, and WBEM Class Names." The entire Windows Management schema is described in the SMS Toolkit.

SQL Database Security

The third level of security for SMS is provided by SQL database security. SMS uses the SQL account identified in the setup process for transactions involving the SMS site database. Because access to the SMS site database is through the SMS Provider, there is no need for an SMS administrator to directly access the SMS database to retrieve data.

Using Windows NT File and Directory Security

SMS requires that you install a site server on an NTFS partition so Windows NTFS security can be used to secure the SMS file structure from unauthorized users.

By default, security for the directories and files under the \SMS share is set at the file system level, with only local administrators being granted permission. Security for lower directories and files is open, with all users given full control. A good working knowledge of Windows NTFS security is required to set up the security at your site at an optimal level.

When SMS Setup creates these directories and accounts, there are default permissions set on the directories. Table 4.1 shows common SMS shares and the share and directory permissions given to each share by default.

Table 4.1 Share Names and Directories Created by SMS 

Share name	Default share permissions	Directory	Default directory permissions	Comments
SMS_<site code>	Everyone–Full Control	\SMS Located on site servers	Administrators–Full Control  SMSServer_<site code>–Read	Root directory for SMS on site servers.
CINFO	Everyone–Full Control	\SMS\Cinfo Located on site servers	Administrators –Full Control	Stores predefined report information created by users.
SMS_SITE	Everyone–Full Control	\SMS\Inboxes\ Despooler.box\ Receive Located on site servers	Administrators–Full Control  SMSServer_<site code>–Full Control	Used to transfer data from a child site to its parent.
CAP_<site code>	Everyone–Full Control	\CAP_<site code> Located on CAPs	Domain Admins–Full Control  Domain Guests–Read Domain Users–Read Inboxes below this share need Write permission for Domain Users and Domain Guests.	Stores information from clients at the site server and from the site server at clients, including software distribution data, inventory data, and other data. Always exists on CAP.
SMSLOGON	Everyone–Full Control	\SMSLOGON Located on logon points	Administrators–Full Control  Everyone–Read These inboxes are found below the SMSlogon share: Ccr.box Ddr.box Inventory.box Sinv.box Statusmsg.box They require Write permission for Domain Users and Domain Guests.	The logon point directories under SMSLOGON are stored on an NTFS partition. To write records, everyone must have Change permissions to the \SMS\Inbox: \Ddr.box \Ccr.box \Inventory.box \Sinv.box \Statusmsg.box directories.
LICMTR	Everyone–Full Control	Software Metering Located on license servers	Administrators–Full Control  Everyone–Change Everyone–Change to directions: Ccr.box Ddr.box Inventory.box Sinv.box Statusmsg.box Server Operators–Change System–Full Control	Stores software data cache and license server application files.

Users who have no access permissions to SMS directories cannot see the contents of the directories.

Understanding SMS System Accounts

The SMS 2.0 security system uses multiple accounts for different site and client functions. With this architecture, SMS system accounts do not require Domain Admins rights. The following sections describe the different types of SMS system accounts, why they are important, and how to use them. Topics include:

• SMS site system accounts

• SMS accounts for NetWare site systems

• Netware Logon Points

• SMS accounts on Windows NT clients

SMS Site System Accounts

The SMS Service account is the most commonly used SMS 2.0 system account. Most SMS services use the SMS Service account to access SMS site systems. SMS site systems must communicate within and between sites, particularly with the site server. SMS uses Windows NT accounts for these communications. NetWare site systems require additional SMS accounts, as do Windows NT clients in the site.

Note By default, the SMS Service account is not used by the system to access the SMS site database. The account used to access the SMS site database is defined during the SMS setup process or in the Site Properties console item in the SMS Administrator.

SMS Service Account (SMSService)

The SMS service account (SMSService) is created during the SMS installation process. During installation, you choose a name and a password for this very important account. On the site server, the main use of this account is to communicate with SMS services on site systems that run Windows NT. Each site has its own SMS Service account.

Tip To maximize security, rename the SMS Service account and choose an obscure name. This account is powerful, so limit access to it.

To minimize administrative overhead, keep the SMSService user name–it is generally used in documentation and is easily remembered.

In either case, put a secure password on this account and do not allow access to this password except as needed.

Most of the SMS services running on a site server use the SMS service account, including:

• SMS Executive Service

• SMS Site Component Manager

• SMS SQL Monitor

• Crystal Info services (if installed)

• SMS Client Configuration Manager (for Windows NT accounts)

Note SMS site server components do not use the SMS Service account for NetWare NDS site system administration. Instead, site server components that configure NDS site systems use a NetWare Site System Network Connection account. In cases where adequate NetWare Bindery Site System Network Connection accounts do not exist, the site system attempts to use the SMS Service account to configure and manage Bindery site systems. For more information, see "SMS Accounts for NetWare Site Systems" later in this chapter.

By default, the SMS Service account is a member of the local Administrators, Domain Users, and Domain Admin groups. The account is not necessarily in the same domain as the site server. The SMS Service account is granted Log on as a service rights on site systems so that the SMS services can start and run.

Tip To maximize security, remove the SMS Service account from the Domain Admin group and add it to the local Administrators group for the site server, client access point (CAP), SQL Server, logon points, and the software metering server.

To minimize administrative overhead, add the SMS Service account to the Domain Administrators global group of each Windows NT domain in which SMS site systems or clients reside. This is the default setting.

SMS System Accounts

Table 4.2 lists the default account names of SMS system accounts other than the SQL service account. To maximize security, you can change the names of some accounts within your installation. Other accounts cannot be changed.

Table 4.2 SMS 2.0 SMS System Accounts 

This default account name	Performs these tasks	Defaults with these rights	Comments
SMSService (SMS Service Account)	Used by SMS services on Windows NT computers to access the SMS site systems in a site.	Member of local Administrators Log on as a service rights on site servers and CAPs	Operates on all site systems except CAPs and distribution points. Mandatory account. One account per site. Created during primary or secondary site setup. Default name is SMSService, but the name and password can be changed during the SMS Setup process.
SMSLogonSvc (SMS Logon Service Account)	Used by the SMS NT Logon Discovery Agent service. Used when SMS components running on other site systems require access to the site server.	Log on as a service rights on all domain controllers Local Administrators Domain Users (not Domain Admins)	Operates on logon points. Mandatory account. Created automatically when you enable Windows Networking Logon Client Installation or Windows Networking Logon Client Discovery. Recreated by the Logon Manager if the account name, password, or permissions change.
SMSS vc_sitecode_xxxx   (SMS Remote Service Account)	Used to run the SMS Executive service on site systems containing CAPs (other than the site server ). The SMS_Executive service uses an SMS Remote Service account when on a remote server. Remote SQL (SMSdbmon.exe) runs under this account	Local administrator on the CAP Domain User (not Domain Admins) Log on as a service rights to the CAP server	Operates on CAPs. Creates an SMS Remote Service account for the CAP automatically (except for site servers) when you assign the CAP role to a site system.
SMSServer_ sitecode   (SMS Server Network Connection Account)	Provides services on the site server access to site systems if the SMSService account fails. Used by SMS NT Logon Discovery Agent service to access the site server when transferring discovery data. Used by Inbox Manager component of the SMS Executive service to access the site server when transferring data. Used by SMS services running on remote site systems to access the SMS registry keys and certain directories on the site server. Used to retrieve inventory data from CAPs. Used to establish communication between site system services and the site server.	Read permission to the \SMS directory. Domain User in the site server domain. Full Control for the SMS_SITE share on the site server. Granted permission to write DDRs.	Operates on site servers and logon points. Mandatory account. On logon points, create one account for each domain in the site. Each will be tried in turn until one succeeds. One account per site server. Created for the site server during SMS Setup process. Any site system reset recreates this account and password. To create, click Site Settings, Connection Accounts, Site System.
SMS Site Address Account	Used to establish communication between sites. Used to connect parent and child sites and to transfer inventory, data discovery records, or status messages to the SMS site share.	Read, Write, Execute, and Delete permissions to the \SMS\Inboxes\ Despoolr.box Receive directory on the site server you want to communicate with.	Operates on primary and secondary site servers. Optional account. Modified in Systems Management Server (Addresses). When creating addresses for other sites, one account assigned for each sender address.
SWMAccount  (Software Metering Service Account)	Runs the Software Metering service on software metering servers.	Account does not contact the site server. If account is remote from the site server, access to resources on the site server is not required.	Operates on license servers. Mandatory when software metering is enabled. Created when you create a software metering server from the SMS Administrator console. Modify account in Systems Management Server (Site Systems).

SMS Accounts for NetWare Site Systems

When you integrate SMS 2.0 with Novell NetWare servers and clients, you must verify that the proper accounts exist in the NetWare security system. The following table describes NetWare system accounts.

Table 4.3 SMS 2.0 NetWare System Accounts 

This default account name	Performs these tasks	Defaults with these rights	Comments
SMSLogonSvc  (NetWare NDS Site System Connection Account)	Used by the Logon Service Manager and the Inbox Manager to connect to the site systems Used to access SMS sites, servers, container objects, and volumes.	Admin permissions to the NDS objects	Operates on NDS objects. Mandatory account. To create, click Site Settings, Connection Accounts, Site Systems. To enhance security, create separate accounts for NetWare CAPs and distribution points.

SMSLogonSvc 

(NetWare Bindery Site System Connection Account)

Used by the Logon Service Manager and the Inbox Manager to connect to the site systems. Used to access SMS sites, servers, container objects, and volumes.

Supervisor equivalence

Operates on NetWare Bindery objects. Mandatory account. To create, click Site Settings, connection Accounts, Site Systems. To enhance security, create separate accounts for NetWare CAPs and distribution points.

Before you use NetWare Bindery servers or NDS container objects and volumes in an SMS site, each server, container object, and volume must be accessible by at least one NetWare Site System Connection account. For example, when you specify a NetWare NDS logon point, there must be at least one NetWare NDS Site System Connection account for the specified object container and volume. For greater security, you can create separate Site System Connection accounts for NetWare CAPs and NetWare distribution points.

NetWare Site System Connection Accounts must be created in both the SMS Administrator console at the primary site server and on the NetWare site system itself. The account must have the same password at both locations. The Logon Server Manager and the Inbox Manager use the site system network connection accounts to connect to the site systems.

When specifying a NetWare Site System Connection account for NetWare Bindery servers or NDS objects, you must grant the account Supervisor equivalence on the Bindery server and Admin permissions to the NDS objects.

To create an SMS Site System Connection account for NetWare Bindery or NetWare NDS, in the SMS Administrator console, click Site Settings, Connection Accounts, and Site Systems. For more information about creating these accounts, see "Site System Connection Accounts" in Chapter 8, "Configuring SMS Sites."

NetWare Logon Points

If you use NDS, you must:

• Specify explicitly the container object for the SMS login script modification and the volume where the SMS logon point components are installed.

• Set up a separate NetWare NDS Site System Network Connection account that has full permissions to the volumes and container objects you specify.

When installing logon point components on NetWare Bindery servers, SMS searches the specified bindery server for the volume with the most available space (at least 50 MB free). However, you can manually create the \Smslogon directory on the root of the volume you want to use as the source for logon point files.

SMS NetWare Bindery Logon Installation and Discovery methods modify the login scripts of any NetWare Bindery servers you specify–but only if script modification is enabled. SMS NDS Logon Discovery and Installation methods modify the login scripts for container objects you specify.

SMS Accounts for Windows NT Clients

One of the advantages of SMS 2.0 is that you can install software on Windows NT clients by using accounts that have lower-level rights than the SMS Service account. In previous versions of SMS, the SMS Service account (in the Domain Admins group) was used to perform these operations. Of the client accounts available to you in SMS 2.0, the only required account is the SMS Client Network Connection account. SMS Setup automatically creates this account.

The following table lists common client-related security tasks you will need to perform, the types of client accounts to use, and where in SMS these accounts are created.

Table 4.4 Client-Related SMS 2.0 Security Accounts 

This account	Performs these tasks	Defaults with these rights and privileges	Comments
SMSClient_ sitecode   (SMS Client Network Connection account)	Used by clients to connect to CAPs and distribution points, transfer data, and retrieve configuration settings.	Granted Read permissions on CAPs and distribution points, Write permissions to the inboxes on the CAP and logon point, and can access the files as a user does.	Operates on clients. Account is mandatory. Created automatically at SMS Setup. If the client participates in multiple sites, account must be trusted in all the sites or you must have one account for each site. Accounts are tried in turn until one succeeds. Create additional accounts by navigating to Client in the SMS Administrator console.
(SMS Windows NT Client Software Installation Account)	Creates security context for software distributions to Windows NT clients. Required only when an unattended software distribution must access network resources in a security context not otherwise available.	Requires the necessary rights to access the network resources required for the package. Create security when account is created.	To use this account, set option when you configure the software distribution component. Modify this account in Systems Management Server (Component Configuration). Create this account manually on the client (high security) or add it to Domain Admins group (low administration).
(SMS Client Remote Installation Account)	Installs SMS client software on Windows NT clients. Used in NetWare environments. Provides access when current user does not have administrative rights. Performs server discovery. Provides access when no user is logged on.	Domain users	Operates on Windows NT and NetWare. Optional account. Mandatory account for NetWare NDS or NetWare Bindery environments. For NetWare, low-rights users are authenticated against a domain controller. SMSService account is used if this account does not exist. Modify this account in Systems Management Server (site code - site name).

Tip To maximize security, create an SMS Client Remote Installation account and set a secure password. This optional account must be created manually.

For a mid level of security, create an SMS Client Remote Installation account and add this account to the Domain Admins group.

To minimize administrative overhead, do not create an SMS Client Remote Installation account. The Client Configuration manager uses the SMS service account instead.

Understanding SMS Administrator Console Security

You create security based on SMS Administrator console functionality by customizing the view that your administrators have of the SMS Administrator console. You set permissions on object classes and instances by using the Security console item in the SMS Administrator console.

Just as access to the SMS site is defined by Windows NT user accounts, the Security console item provides general site security for SMS database objects. SMS determines which console items the user can see and which tasks the user can perform by verifying the security rights of the user account that is logged on to the SMS Administrator console. These permissions explicitly grant rights to SMS security objects, and the SMS Provider translates these rights into SMS site database access. Understanding the roles of user accounts, WBEM security, and SMS Provider security in the SMS security process is critical to creating secure access to your SMS site information.

Before users can access any SMS security objects and data from the SMS Administrator console, they must have the following security rights:

• A Windows NT user account that is a member of the site server domain or that is a member of a domain that has a trust relationship with the site server domain.

• Either implicit or explicit Windows NT access to the directory where the SMS Administrator console files are located.

• A WBEM user account that has access to the SMS Provider.

  By default, members of the SMSAdmins group on the local computer or members of the local Administrators group have this WBEM access. You can add other accounts using the WbemPerm tool. 

• Permissions for the appropriate SMS security objects.

Note User accounts running the SMS Administrator console on the site server must also have Full Control permissions to the \SMS directory.

User and User Group Permissions

There are two types of permissions for Windows NT user accounts: explicit and implicit*. Explicit permissions* are those granted directly to a user account; no other users are affected. Implicit permissions are those granted to a user group account. Adding a user to that group grants the group's permissions to that user; removing a user from the group takes away the group's permissions from that user.

Tip To maximize security, assign permissions only to individuals. Then, assign only the permissions each individual needs to perform required tasks. This method makes it easier to trace who is performing which tasks within your site.

To minimize administrative overhead, create new groups and assign permissions to the groups rather than to individual users. Then, you can change individual users' permissions by adding them to or removing them from groups. Also, if you need to grant new permissions, you can grant them to all members of a group in a single operation.

User and group permissions are additive or cumulative. When a user accesses the SMS Administrator console, that user's set of permissions is based on the sum of that user's explicit (user) and implicit (user group) permissions. A user's security level is always the least restrictive of that user's explicit and implicit permissions.

Note To access the \SMS share, Windows NT users or user groups that work directly on the site server computer must be members of the local Administrators group on that server. This permission grants more rights than most administrators require.

To maximize security, restrict access to the console on the site server and require most SMS administrators to use remote SMS Administrator consoles run from computers other than the site server. Remote consoles do not require local Administrator access to the site server and are less of a security risk.

If a user obtains access to the SMS site database across domains, you must set up a trust relationship between the site server domain and the user's domain. Or, create an account on the site server domain that has the same user name and password as the user's domain.

WBEM and SMS Provider Security Architecture

In addition to using Windows NT and SQL Security, SMS 2.0 maintains security for database information with the SMS Provider and WBEM security. This sophisticated security system is designed to control access to core SMS objects such as packages and collections, and to provide access to the read and write information that network administration, site configuration, client Help desk support, and software distribution require.

The SMS Provider imposes a security model that uses SMS object types, creates specific SMS security permissions, and uses Windows NT user and user group accounts to control access to SMS objects.

When a user logs on from the SMS Administrator console, the current user account automatically logs on to WBEM, which validates the account for WBEM permissions. If the user is not a member of SMSAdmins group or a local Administrator on that computer, access to WBEM is denied–unless the user is specifically granted WBEM user rights.

Tip The SMSAdmins group is a local group on each computer. If the SMS Provider is located on a different computer than the site server, the user attempting to access security objects on the SMS Administrator console must have a single account that is a member of SMSAdmins group (or some other account with WBEM access) on both computers.

• To maximize security, use the WbemPerm tool to create specific access for each administrator, as directed in the WBEM Toolkit.

• For mid-level security, assign each administrator to the SMSAdmins group on both the site server and the SQL database server. This group has much less security access than local administrators.

• To minimize administrative effort, add each administrator to the Domain Admins group in the site server's domain.

After account validation, WBEM passes the account name to the SMS Provider. The SMS Provider validates the user account, and then the objects for which the user has permissions appear in the SMS Administrator console. For information about managing WBEM security for SMS on Windows NT computers, see the WBEM Toolkit.

The SMS Provider uses an SMS account to interact with the SMS site database. However, this process is transparent to the user at the SMS Administrator console. Regardless of the SQL Server security type specified in SQL Server Setup (Integrated, Mixed, or Standard), the account that the SMS Provider uses to talk to SQL Server is determined as follows:

• Whether SQL Server is on the same computer or another computer, if the SMS Provider is installed on the site server, SMS Provider uses the SMS Service account to communicate with SQL Server.

• If the SMS Provider is installed on the computer running SQL Server and if the computer is not the site server, SMS Provider uses the SMS Remote Service account to communicate with SQL Server.

For information about installing the SMS Provider on a separate computer running SQL Server, see "Preparing SQL Server" in Chapter 6, "Installing SMS 2.0 Sites." For more information about the SMS Service account and the SMS Site System Connection account, see "SMS Site System Accounts," earlier in this chapter.

By default, the SMSAdmins local group is created on the site server and on the SQL database server (if the SMS Provider is running on the SQL database server). Members of this local group receive access to the SMS WBEM namespace and can receive access to the SMS site database through the SMS Administrator console. All administrators who log on to the SMS Administrator console must be added to this group, even if they are logged on from a remote console. Because members of the local Administrators group are also granted access to the SMS WBEM namespace, users can also be members of the local administrators group.

Tip You can grant access to the WBEM namespace to a user that is not in the SMSAdmins group by using the WbemPerm tool to add the user and specifying Write Instance and Execute Methods permissions.

Defining Object Security

The Security console item of the SMS Administrator console allows you to set permissions on object classes and instances. 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.

You must explicitly add other accounts and grant them permissions to SMS object types using the Security Rights console item in the SMS Administrator console. Users who do not have permissions for various object type classes or instances will not see those objects in their SMS Administrator console tree. Users who have partial permissions for SMS Administrator console items will see only those items for which they have permissions. For information about changing security using the Security Rights console item, see "Configuring Site Security" in Chapter 8, "Configuring SMS Sites."

You can use six SMS classes (object types) to give administrators access to console items in the SMS Administrator console:

Table 4.5 SMS Classes for Granting Security Rights 

Object class	Console item
SMS_Advertisement	Advertisements
SMS_Collection	Collections
SMS_Package	Packages
SMS_Query	Queries
SMS_Site	Sites
SMS_StatusMessage	Status Messages

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 95 Systems Collection or the NYC site.

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

You can grant these security rights to a single user or to user groups within a domain. For example, you can specify that all packages can be edited by members of the Domain Users group. Or, 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 provides you with more control over who can get access to SMS object types and specific information in the SMS site database.

Object Permissions

For each class or instance, you specify permissions such as Create, Administer, or Delete Resource. Some permissions are specific to an object type. For example, the Distribute and Advertise permissions only apply to Package object types. Note that resource permissions are handled with collection object type classes and instances.

Table 4.6 describes each permission and the security object types for which they are available.

Table 4.6 Object Type Permissions 

Permission	Applies to	Grants the ability to
Administer	All security object types	Administer all security object types. Assign or remove any user security rights for a class of objects or for individual object types in that class to yourself or to any other user. There must always be at least one account with Administer rights on any object. You cannot remove the last Administrator, nor can you change your own Administer rights You must explicitly grant other permissions appropriate to the object type.
Advertise	Collection object type class and instances	Advertise to a collection. This permission does not grant the ability to create advertisements–that requires Create permission on the advertisement object type.
Create	All security object types	Create an instance of an object type.
Delete	All security object types and instances (except status message instances)	Delete an instance of an object type.
Delete Resource	Collection object type class and instances	Delete a resource from a collection.
Distribute	Package object type class and instances	Send packages to distribution points.
Modify	All security object types and instances (except status message type and instances)	Modify an instance of an object type.
Modify Resource	Collection object type class and instances	Modify a resource in a collection.
Read	All security object types and instances (except status message instances)	View an instance and its properties.
Read Resource	Collection object type class and instances.	Read a resource in a collection.
Use Remote Tools	Collection object type class and instances	Use Remote Tools on a resource.
View Collected Files	Collection object type class and instances	View the files collected from a client.

For each object type, there must always be at least one user with Administer permission. This approach prevents administrators from being locked out of an SMS system. As a result, it is not possible to delete the final user on a particular object type with the Administer permission. Also, you cannot delete your own Administer rights on an object.

Note Granting the Administer permission to a user does not automatically give the user Create, Modify, or Delete permissions for that object type.

Users who create an object are automatically assigned Read, Modify, and Delete permissions for that object type instance. For information about how to configure security rights, see "Configuring Site Security" in Chapter 8, "Configuring SMS Sites," or see "Security Configuration Overview" in SMS Help.

Consider how granting permissions to various user groups in your organization can address their specific needs. For example, if your Help Desk technicians have a user group, you can grant that group Use Remote Tools permission for Collections. If users who are not SMS administrators want to view and query inventory collected from clients, you might grant those users Read permission to Collections and Queries.

Tip To maximize security, grant permissions to each administrator carefully at the instance level, unless they require permissions at the class level. For each administrator, create a collection of the accounts that the administrator manages and grant permissions only to that collection. As a result, each administrator sees only those security objects to which access is granted.

For mid-level security, have your administrators log on to the SMS Administrator console remotely.

To minimize administrative overhead, give all administrators or some administrators full control of all objects in the SMS site database. The easiest way to do this is to create or use a group that has the correct permissions. Then, as you add administrators to the site, you can simply add them to the group.

Creating a Secure SMS Administrator Console

To create a secure SMS Administrator console, implement the following steps in order:

• Create user groups (using the Windows NT User Manager for Domains) based on function, for example, SMS Help Desk, Sales, SMS Package Administration, SMS Help Desk Accounting, and SMS Reports Administration. For information about SMS roles you may have in your organization, see "Assigning SMS Management Roles" in Chapter 3, "Planning for SMS in Your Organization."

• Create user groups for each SMS administrator role and add users to these groups.

• Determine the necessary object security for each SMS administrator role and assign it to the user group for that role. Use the Security console item of the SMS Administrator console.

• Install SMS on remote computers with only the Administrator console and the tools. Use the SMS software distribution feature to distribute and install the software.

Ensuring SMS Site Database Security

The interface with the SMS site database is provided by the SMS system, so you do not need to configure it. When you run SMS, you should never have to access the SQL Server database directly. Your only concern in regard to database security is to ensure that unauthorized persons cannot access your SMS site database directly. To this end, if any of your administrators access your database directly, use accounts other than the required sa account. And you must decide which type of security to enable for SQL Server.

SQL Server Account

When you install SQL Server, the sa account is created for you–it cannot be removed from a SQL Server installation. If you select the Standard security option when you installed SQL Server, by default, the SMS services use the sa account to access the SMS site database and the software metering database.

Each primary site requires a SQL Server account. The account used is dependent upon the type of SMS Setup option you choose and the kind of SQL Server security implemented.

You specify the SQL Server account during SMS setup. You can change the user account for the SQL Server account on the Accounts tab in the Site Properties dialog box in the SMS Administrator console.

SQL Server Standard Security

SQL Server standard security means that in order to connect to a SQL Server database, you must enter a user account and a password. If you use the SMS Express Setup option, the sa account is used to access the database. If you use the Custom Setup option, SMS Setup prompts you to specify the account you want to use when the system accesses SQL Server. No other accounts are necessary, because WBEM security controls access to the SMS site database. This customized approach is the maximum security option.

Tip To maximize security, set an obscure password on the SQL sa account and do not use it. Very few people should know this password. Create a different user account with access only to the SMS site database within SQL server, and use that account in case anyone accesses the SMS site database directly. In most cases, however, direct access to the database is not necessary.

SQL Server Integrated Security

With SQL Server integrated security, you can map a set of Windows NT user and user group accounts to accounts in the SQL database. Then, SMS passes through the account of the logged on user to SQL for validation when you need data access. You are never prompted for a user account or password. If the logged-on user has no access, you are denied.

If you choose integrated security when you install SQL Server, SMS uses the account the user logged on with to access SQL Server. This account is generally used by the SMS services, because in SMS, WBEM and the SMS Provider control user access to the SQL Server database. In this case, no special accounts are required. This is a minimum administration overhead option.

Note If you use SQL Server integrated security, keep in mind that if you grant a Windows NT user group access to the SMS site database, this permission is not dynamic. As new users are added to the Windows NT user group, they are not given SQL Server security rights unless you add them individually.

To use SMS integrated security, create the SMS Service account in User Manager for Domains before you install SQL Server. Then, as you install SQL Server, you can add this account to the SQL Server security system.

Warning You must use named pipes for communication so that SQL Server integrated security can communicate with the SMS site database. Any other option is invalid with SMS.

SQL security is a complicated subject. You should be familiar with the SQL Server documentation on this subject before attempting to set security for your SQL server.

Addressing Feature-Specific Security Issues

In addition to SMS accounts and security objects, you should also identify and address security issues related to the specific SMS features you plan to use. For example, when you design your sites, you should be aware that CAPs and distribution points require NTFS partitions. This section describes feature-specific security issues and provides some suggestions of how to address them.

Software Distribution

If you use SMS software distribution, keep these potential security risks in mind:

Programs 

When you use the Windows NT Client Software Installation account to run a program, the account context is likely to have more rights than the user account. This situation presents a potential security risk. Be sure to protect executable files that have advanced rights.

Using package files to enhance security 

By default, Domain Users and Domain Guests have Read permission for package shares on distribution points. If you want the package files to be more secure, explicitly remove permissions for those groups.

For additional security considerations for software distribution, see "Preparing Security" in Chapter 12, "Distributing Software."

Network Monitor

In unscrupulous hands, Network Monitor's powerful functionality is potentially dangerous. Consider when to use Network Monitor in your system, where to install it, and who will have access to it. If you decide not to take advantage of the powerful troubleshooting features of Network Monitor, consider installing it on a computer in each of your subnets anyway. The new Monitor Control Tool that ships with Network Monitor 2.0 provides the Security Monitor, which you can use to watch for unauthorized data-capture activity through Network Monitor or the Monitor Control Tool. You can specify the MAC address of computers that you want to capture network data, and you can force unauthorized instances of Network Monitor 2.0 to stop a data capture.

You can also run other monitors to detect potential security risks, such as frames that originated outside of your network (an event that might signify an Internet break-in attempt) or half-open connections on your Web servers. For a discussion of more network monitoring security considerations, see "Network Monitor Security" in Chapter 16, "Using SMS for Network Maintenance."

Deciding on a Security Model

As with most systems, the level of security you implement in your SMS system is directly proportional to the amount of administration required to maintain it. That is, the more secure you want your SMS system, the more administration it will require. The following sections propose three basic security models for your consideration.

In many cases, the SMS default is minimal administration. If you need more security, you must configure it.

Maximizing Security

The following suggestions provide you with options for an increased level of security within your organization:

• Install the site server on a Windows NT server that is not a domain controller.

• Grant each site system only local Administrator rights for SMS services and functions.

• Grant Read and Write permissions on the SMS_SITE share only to the SMS Site Address account.

• Do not use pass-through authentication in your system. Pass-through authentication is assigning the same user name and password to two accounts, one in each of two domains.

• Ensure that no accounts are members of the Domain Admins group.

  Add the SMS Service account to the local Administrators group on the following site systems:

  • Site server

  • SQL Server

  • Logon points

  • CAPs

  • Software metering server

• Restrict Network Monitor capture permissions to certain machines.

• For each administrator's user account, specify only the specific object type permissions that the user needs to perform assigned tasks.

Keep in mind that following these steps results in more accounts, files, and directories to manage.

Warning You should carefully plan and test your security strategy for SMS. These suggestions are general and may not apply in all cases.

Mid-Level Security

The following suggestions provide options for a balance of security with administrative overhead within your organization:

• Install the site server on a Windows NT server that is not a domain controller.

• Grant each site system only local Administrator rights for SMS services and functions.

• Carefully limit the accounts that are members of the Domain Admins group.

• Specify object type permissions for the primary administrator user accounts and for specific groups and individuals that require limited access.

This level of security requires less administration of accounts but maintains a more secure system.

Minimizing Administration

To minimize administrative effort in your SMS system, use the SMS Service account for everything in your system (and use an SMS Server Network Connection account for any NetWare site systems). Then, assign administrator accounts to the Domain Admins group and grant those accounts complete permissions for all object types in the SMS Administrator console.

Although this results in a significant reduction in administration overhead, giving all services and components an account that is a member of the Domain Admins group is a considerable security risk.

Table 4.7 provides tips to help you achieve your security objectives.

Table 4.7 Security Decisions for Your SMS Site 

Decision point	Tip for maximum security	Tip for minimum administration
Granting administrators permissions to SMS database objects.	Grant permissions carefully at the instance level, unless they require permissions at the class level.	Give all or some administrators full control of all objects in the SMS site database.
User and user group permissions.	Assign permissions only to individuals. Assign each individual only the permissions they need to perform assigned tasks.	Create new groups and assign permission only to the groups, not individual users. Then, you can change user permissions by adding or removing users from groups.
SMS Service Account.	Do not use the default name for this account. Give account a secure password. Do not make account a domain administrator.	Use the default name for this account. Give the account a password your administrators remember.
NetWare Site System Connection Accounts.	Create separate accounts for each NetWare CAP and distribution point.	Use the same account name for each account.
SMS Client Remote Installation Account.	Create a new account with a secure password.	Allow the system to use the SMS Service account.
SMSAdmins group.	Create a group similar to SMSAdmins but with a different name, or use WbemPerm to assign each administrator the necessary rights.	Use the SMSAdmins group and make sure each administrator is a member of this group.
Database Logons.	Give the sa account an obscure password and do not use it.	Use the sa account for SMS transactions.
Database security types.	Choose standard security.	Choose integrated security.