Securing Service Dependencies for Configuration Manager
ConfigMgr depends on
Domain Name System (DNS) and/or WINS to provide name resolution for site
systems. Secure name resolution is an important security consideration
to keep clients or other site systems from being redirected to a rogue
site system. WINS has several known vulnerabilities that can be
exploited to compromise client systems. You should also use DNS instead
of WINS for name resolution. If possible, use Active
Directory-integrated DNS to provide high availability and enable the
option to allow only secure dynamic updates. A number of exploits exist
that target DNS, so it is especially important to apply the latest
patches to your DNS servers. For more information about securing DNS,
see http://technet.microsoft.com/en-us/library/cc770432.aspx.
You should also enable fully qualified domain names (FQDN) for all site
systems. Using the FQDN avoids the possibility that the name will be
resolved to the wrong domain or the client will fall back to NetBIOS
name resolution.
ConfigMgr
clients also use information published in AD or WINS to identify site
systems and learn other information about sites. If a client receives
incorrect site information, it could be redirected to the wrong site or
server for ConfigMgr services. You should extend the Active Directory
schema if possible and publish site information to AD instead of using
WINS. If you configure AD publishing, you need to grant all site servers
Read/Write access to the AD System Management container. To avoid granting overly broad permissions,
you should create a security group consisting of your ConfigMgr site
servers and grant that group access to the System Management container,
rather than adding the site servers to the built-in groups such as
Domain Admins.
For maximum
security, you can remove access for the site systems group from each
site object after creating it, and add permissions for the individual
site server responsible for the site instead. Managing permissions for
individual servers adds significantly to your administrative overhead.
Securing Configuration Manager Reporting
ConfigMgr reports
and queries provide access to information contained in the site
database. The site database does not generally contain confidential
business information or intellectual property; however, this type of
information might be present if you collect files as a part of software
inventory. The site database does contain a wealth of information about
your systems and infrastructure that could be of potential value to a
hacker. There might also be some privacy concerns around software
metering data or data obtained through AD user discovery. Reporting
security is therefore an important consideration, although generally
less critical than security around services with client impact such as
software distribution.
Security in Classic Reporting
To view classic
reports, a user needs access to the reporting website and Read
permissions on the report class or the report instances she runs. To
provide access to the website, add the appropriate AD users or groups to
the Reporting Users local group on each reporting point. You can assign
class and instance permissions on reports just as on any ConfigMgr
objects.
To allow users to
create and modify reports, you must add them to the SMS Admins local
group on the site server. You can then use the ConfigMgr console to
grant the users create rights on the reports class or modify rights on
the class or on specific instances. As the report builder interface
performs some validation of the report SQL statements, it is not
possible for a user to enter statements such as INSERT or UPDATE into
the report’s SQL query. You should nevertheless use caution when
assigning rights to create or modify reports, because poorly written SQL
queries can expose your database to attack.
Security in SQL Reporting Services
SQL Reporting Services
(SRS) uses a role-based model to assign permissions to Windows users and
groups. You generally assign roles to AD groups. To assign users to a
reporting services role, perform the following steps:
1. | Expand
the Configuration Manager console tree to System Center Configuration
Manager -> Site Database -> Computer Management -> Reporting
-> Reporting Services. Right-click on the report server name and
choose Properties.
|
2. | On
the Security tab, clear the Inheriting rights from the parent object
check box and use the New, Properties, and Delete buttons to invoke the
User Properties dialog box. You can use this dialog box to create,
modify, or delete role assignments.
|
Figure 6
displays the User Properties dialog box, which includes descriptions of
the available roles. By default, all report folders inherit the role
assignments you set in the Reporting Services properties. To assign
users different roles on individual report folders, expand the Report
Folders node under Reporting Services, right-click the appropriate
folder, and choose Properties. The Security tab on the folder property
sheet provides the same options as the Reporting Services Properties
Security tab described in step 2 of the preceding procedure.
The browser role
allows users to view reports. Each of the other roles provides some
ability to create and manage reports. You cannot assign the same user or
group to more than one role, although a user whose group memberships
include more than one group with an assigned role has the cumulative set
of permissions for the assigned roles. You can create new roles or
customize existing roles using SQL Server Management Studio. Keep in
mind that if you modify an existing role, the permissions available to
all users assigned to that role reflect the changes.
Best Practices for Reporting Security
To
provide the maximum confidentiality for data stored in your site
database, grant each user only those permissions necessary to view the
reports they need. Many ConfigMgr reports include details about computer
hardware, software, and network configuration that can provide valuable
information to a potential attacker. Here are some of the most
sensitive report categories:
Asset Intelligence
Desired Configuration Management – Compliance
Operating System
Software – Companies and Products
Software – Files
Software Updates – A Compliance
You can use SSL to
secure communications between users and your reporting points or
reporting services points. Before enabling SSL on your site systems, you
must install an SSL certificate as described in http://support.microsoft.com/kb/299875.
When you have the certificate installed, use the ConfigMgr console to
enable SSL for your reporting point. The SSL option is available on the
reporting point property sheet under System Center Configuration Manager
-> Site Database -> Site Management -> <Site Code> <Site Name> -> Site Settings -> Site Systems -> <Reporting Point>.
To configure SSL for SQL Reporting Services, use the Report Server
Virtual Directory page in the SQL Server 2005 Configure Report Server
tool.
