Security Planning
Computer management systems such as SMS are powerful systems, and they often involve many, if not all, of the computers in an organization. It is critical that the security of your management systems does not become compromised. By properly securing your management systems, you help to ensure that unauthorized persons cannot use your management systems to access or disable your organization’s computers.
SMS 2003 builds on the strong SMS 2.0 security environment in the following ways:
Provides an advanced security mode that takes advantage of LocalSystem and computer accounts that are automatically maintained by the operating system
Provides an Advanced Client that takes advantage of local system and computer accounts to run client-based tasks
Uses hashing to ensure the integrity of software distribution packages
Reduces the impact on domain controllers by eliminating the need for SMS 2.0 logon points
Eliminates the requirement that the SMS Service Account have domain administrator rights
Signs all site-to-site communications between SMS 2003 sites, and between SMS 2003 and SMS 2.0 sites running Service Pack 5
Integrates support for Active Director security environments
See Scenarios and Procedures for Microsoft Systems Management Server 2003: Security for an expanded discussion about security considerations in SMS 2003.
Note
SMS 2003 uses new ports to access the Active Directory directory service when communicating through a firewall or through a proxy server. For more information about the ports that SMS uses to communicate through a firewall or proxy server, see article number 826852 in the Microsoft Knowledge Base at https://support.microsoft.com.
Here are some important best practices to consider as you plan your SMS security strategy.
Security Best Practices for Deployment
The following topics are recommended best practices for security for you to consider as you design your deployment plan for SMS 2003.
Use Advanced Security
It is recommended that you use advanced security rather than standard security because advanced security relies primarily on the LocalSystem and computer accounts rather than on domain level accounts to carry out tasks. Standard security, like SMS 2.0 security, requires the use of many domain level accounts. For more information about advanced and standard security, see Appendix E: "Appendix E - Designing Your SMS Sites and Hierarchy."
Use Active Directory as Trusted Source
If the Active Directly schema has been extended with the SMS extensions, the management point publishes its public key in Active Directory. When Advanced Clients have to locate a management point or validate the data sent by a management point, the client extracts the public key from Active Directory.
Note
The schema must be extended in order for the management point to publish its key, and both the client and the management point must be in the same Active Directory forest, because data does not replicate across forests.
If the Advanced Client is configured in Active Directory only mode, the client tries to obtain the key only from Active Directory. Other client configuration options allow the client to fall back to other methods to obtain the management point public key.
Maintain Trusted Root Key
The trusted root key is a public/private key pair maintained at the central site. Whenever a management point is created anywhere in the hierarchy, its public key is sent to the central site where it is signed by the trusted root key. The signed, management-point public key is then sent back down to the originating management point.
When a client is first installed, it attempts to obtain the trusted root key from the central site. This is the public key of the public/private key pair, and it is distributed widely throughout the hierarchy. Upon request, a management point can provide both its own public key and the public trusted root key. It can also supply the management point’s public key, signed by the trusted root key. When the client has the public trusted root key, it uses it to authenticate any change to the management-point public key.
Note
Prior to obtaining the public trusted root key, the client trusts the public key provided by the management point.
The Advanced Client can be also be configured in secure WINS mode. When the client is configured for this mode, and when the client has obtained the trusted root key, it only accepts new management-point public keys that can be authenticated with the trusted root key.
Maintain a Single SMS Site Rather Than Multiple SMS Sites
The single site option is inherently more secure for the following reasons:
No intersite data transfer takes place, and there are no related accounts to maintain
No need to trust the administrator at another site
Although a site hierarchy with multiple sites is an important feature of SMS, and for that reason SMS has the functionality to protect the site control file, it is still a best practice to reduce the number of SMS sites in your hierarchy to minimize the potential for security attacks.
Install the Advanced Client
There are two client types to choose from:
Advanced Client
Legacy Client
The Advanced Client is inherently more secure than the Legacy Client for the following reasons:
Policies are signed to ensure that client instructions have not been modified.
Content is signed to ensure that the correct content is downloaded to the client, and the intended program is run.
Client services run under the LocalSystem security context on the computer so there is no high rights user account to be maintained.
However, Legacy Client support is an important feature of SMS that provides transparent upgrade from SMS 2.0 and provides a management solution for legacy operating systems. Nevertheless, you should migrate Legacy Clients to the Advanced Client as soon as possible to benefit from the inherent security features of the Advanced Client.
Maintain One Management Point at the Primary Site
Every primary site must have one management point that is used to manage Advanced Clients. However, if you require a secondary site you have the option of installing a proxy management point at the secondary site. For more information about proxy management points, see Appendix E: "Appendix E - Designing Your SMS Sites and Hierarchy."
In this scenario, maintaining one management point at the primary site is inherently more secure than maintaining an additional proxy management point at the secondary site for the following reasons:
No need for Advanced Clients to trust an additional management point
No need for the proxy management point to access the SMS site database remotely at the primary site
However, having the ability to configure a proxy management point is an important feature of SMS. For this reason, the same management point authentication functionality that exists at the primary site (Active Directory and trusted root key) is also used to authenticate proxy management points. Nevertheless, reducing the number of management points can minimize the potential for security attacks and you should consider this when you design your site deployment strategy.
Note
If you have to maintain a proxy management point at a secondary site, you can reduce the potential for security attacks by using IPSec to secure communications between the proxy management point and the remote SMS site database.
Maintain the Management Point on Its Own Server
You can configure a management point to run on the site server or on its own server. Configuring the management point to run on its own server option is inherently more secure for the following reason:
- A potential security attack through IIS on the management point would not necessarily compromise the site server or the SMS site database if it is maintained on the site server.
However, when you configure the management point to run on its own server, it still must communicate with the SMS site database. If you choose to replicate the SMS site database to the management point server, periodically the management point must update the Microsoft SQL Server™ database replica. Because this communication occurs across the network, it is exposed to potential security attacks.
Nevertheless, maintaining the management point on its own server can be more secure. If a security attack on the management point is successful, it is essential that the attack does not result in control of the SMS site database. The network connection between a remote management point and the SMS site database server can be physically secured, and IPSec can be used to further reduce the potential to attack communication between the management point and the SMS site database server.
Enable Secure Key Exchange
The default configuration of a primary site allows an SMS 2003 site to accept unsigned communication from SMS 2.0 sites and implements a less secure key exchange algorithm that allows SMS 2003 sites to exchange the keys used for signing data transfers between sites.
Even if the deployment is implemented as a single site, you should disable the default options to reduce the potential for security attack through the propagation of damaging site control files. Although a potential security attack is mitigated by the file system access control lists on the site server share that receives the site control file, by disabling the interoperation with sites that do not sign intersite traffic and by requiring secure key exchange between SMS sites, you can reduce the risk of security attack significantly.
Enable Advanced Security Mode
In an SMS site, there are two security modes to choose from:
Advanced security
Standard security
Advanced security mode is inherently more secure for the following reasons:
No need to specify a high rights service account such as the SMS 2.0 service account
Relies primarily on the LocalSystem and computer accounts
Credentials used have very strong passwords
Promotes good security practices
Because SMS has to be able to install services on client computers and site systems, administrators frequently supply a very high rights account – often with domain administrator rights – to carry out this task. Additionally, because a password must be changed in the domain and on the site server at the same time, administrators tend to change passwords infrequently.
By using the computer account to access network resources, and LocalSystem to access local resources, SMS has access to a set of automatically maintained credentials that have very strong passwords. In addition, rather than relying on a default security configuration, the administrator has more responsibility to use these credentials correctly when configuring the security environment for the SMS hierarchy. For example, the SMS administrator must give the site server computer account the appropriate local permissions on a remote management point so that the site server can configure the management point successfully.
There are still occasions where high rights accounts are needed for certain tasks, such as installing the Advanced Client on a computer. However, these accounts must be explicitly supplied because the SMS service account cannot be used to perform these functions, and, after being supplied, they can be maintained more easily.
Use Active Directory for Authentication
The following options are available to provide user and computer authentication services:
Active Directory
Windows NT 4.0 domains
Active Directory is inherently more secure because it provides server authentication through Kerberos. For example, when an SMS client connects to a distribution point to access content, the client can authenticate the identity of the server using Kerberos authentication. This level of authentication is not available from domain controllers that are running Windows NT 4.0, and as a result it is less secure in a Windows NT 4.0 environment.
Active Directory also supports using advanced security and allows extending the schema to provide additional security benefits, as described earlier.
Extend the Active Directory Schema
The following options are available to provide management point location and authentication services:
Extended Active Directory Schema
WINS/server locator point
Extending the Active Directory schema is inherently more secure because it leverages the basic directory infrastructure to provide a trusted source of data. The directory schema extensions are populated with the following data:
Site signing keys (used for signing intersite data transfer)
Management point signing keys (used for signing policy information)
Management point location (used by the Advanced Client to locate the management point)
This data is stored in a well-known container in the System Management container under the System container in the schema. The client is hard-coded to look for this container path as it queries the Global Catalog server for this data.
For each site to create its site object, the System Management container must exist. Next, the SMS Service Account must be granted full rights to the System Management container. After the site has generated its Active Directory site object, full rights to the Systems Management container can be removed and full permissions set only to the site object and all child objects, such as Management points and server locator points. Any time a secondary site is installed, the parent site will again need full permissions to the Systems Management container in order to create the secondary site’s site object.
The SMS site server and the management point store their certificate data in the System Management container. Each site server and management point must have access to this container so that it can write and update entries.
Note
Certificate data is stored in the System Management container. This can introduce the risk that one server could be compromised and corrupt other certificate entries which can then provide corrupt data to the client. As a result, the rights granted to each computer should be minimal so that they can only create new entries and update their own entries.
When the schema is not extended, the SMS site relies on WINS and the server locator point (SLP) to locate management points, and the trusted root key functionality is used to authenticate the management point as a valid management point. Although this provides a high level of security, there is a greater risk of failure.
Similarly, when the schema is not extended, the SMS uses less secure automatic key exchanges or relies on the administrator to manually distribute the keys to support site signing of intersite data transfers. Active Directory schema extensions provide a more secure solution that is easy to maintain. Consequently, extending the Active Directory schema is the recommended security best practice.